Subject: Re: [mpls-tp] Description of Extra Traffic in Survivability Framework

From: Curtis Villamizar <[email-masked]>
Date: Thu, 06 May 2010 20:56:36 -0400

Italo,

You are partially right in your statement "there is no requirement to
develop protocol solutions to support extra-traffic in MPLS-TP".
However I disagree with the statement "It is therefore my strong
feeling that MPLS-TP protection switching would benefit from not
supporting extra-traffic."

GMPLS already supports an ability to put extra traffic on a protect
path.  Protection itself is imperfect (apparently this itself is a
revalation to some - in the US there are currently multiple faults in
Tennessee, just as an example).  Shared mesh protection is very handy
in a packet network.  Zero reservation FRR is actually the most
popular protection mechanism in packet networks today.

In zero reservation FRR there is no attempt to reserve capacity for
protection.  The protection paths are simply diverse with working
paths.  This works in practice in networks where the high priority
traffic is a minority.  With the high bandwidth demands of the
Internet, this is almost universally true in provider packet networks.
The FRR paths are only used to achieve sub 50 msec protection for that
minority of high priority traffic.  The lower priority traffic is
simply congested a little until reroute of the working path is
completed (which does use reservations).  Soft preempt also insures
that multiple high priority LSP don't stop on each other when there is
plenty of best effort traffic that can be stomped on instead.  The
reroute that relieves low priority traffic congestion today takes a
few seconds, maybe sub-second depending on network size.

The e2e shared mesh protection is a bit more of an orderly affair.
This is usually done with offline computation to insure that
protection is adequate for any single SRLG fault.  When a single fault
occurs, no congestion occurs, not even interim congestion.  But
multiple faults do regularly occur and if they do, the highest
priority traffic is still carried without loss (except the <<50 msec
due directly to the fault) and typically only the lowest priority
traffic experiences interim congestion until a reroute can releive the
congestion.  If there are LSP that carry only high priority traffic,
then the MPLS setup and holding priorities come into play, but
typically all services are on a single LSP using TC bits for QoS.

btw- Shared mesh OTN using GMPLS could in principle do the same except
preemption is needed when a multiple fault occurs and any extra
traffic must be preempted on a fault.  I don't know of an
implementation that goes that far (yet).

This is what existing packet networks can do.  Therefore it truely
comes for free for some because at least some vendors have already
done it, just not the newcomers to (IP/MPLS) packet networking.  I
don't think a goal of MPLS-TP should be to criple MPLS.

Curtis

In message <[email-masked]>
"BUSI ITALO" writes:

Adrian,

> It is our understanding that this means that extra traffic is 
> within scope of MPLS-TP, but that there is no requirement for 
> a specification to be produced, and that implementations are 
> not required to support extra traffic.
>  

During the development of RFC5654 we had intensive debate about how to
interpret these requirements. We have agreed that the requirements are
for the solution and not for the implementation as described in section
1.1. of RFC5654.

As a consequence, my view is that there is no requirement to develop
protocol solutions to support extra-traffic in MPLS-TP.

As described by Maarten, support of extra-traffic is making APS more
complex and slower.

It is therefore my strong feeling that MPLS-TP protection switching
would benefit from not supporting extra-traffic.

Italo

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: domenica 18 aprile 2010 15.31
> To: [email-masked]; [email-masked]
> Subject: [mpls-tp] Description of Extra Traffic in 
> Survivability Framework
> 
> Hi MPLS-TP list,
> 
> Nurit and I are working on the Survivability Framework and 
> the review from the ITU-T.
> 
> Section 4.3.3 is about "extra traffic". It is based on RFC 
> 5654 section
> 2.5.1.1 which says....
> 
>    Support for extra traffic (as defined in [RFC4427]) is not
>    required in MPLS-TP and MAY be omitted from the MPLS-TP
>    specifications.
> 
> It is our understanding that this means that extra traffic is 
> within scope of MPLS-TP, but that there is no requirement for 
> a specification to be produced, and that implementations are 
> not required to support extra traffic.
> 
> We also believe that the Survivability Framework should 
> include a description of extra traffic to give an overview of 
> how it fits into the general survivability model in case 
> anyone wishes to work on extra traffic in the future.
> 
> In the liaison from the ITU-T
> (https://datatracker.ietf.org/documents/LIAISON/file984.pdf) 
> there is a proposed major deletion of text from section 
> 4.3.3. No explanation of this deletion is provided, but we 
> are assuming that it is because the ITU-T feels that there is 
> no requirement to support extra traffic.
> 
> Nurit and I would like to hear the views of the MPLS-TP 
> community on this issue.
> 
> Thanks,
> Adrian and Nurit 
> 
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
> 
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 07 May 2010 16:00:43 +0200

Curtis,

I am not sure if I understand your definition of "extra traffic" in your
response. Could you help me by clarifying it using the following example.

The example illustrates a p2p subnetwork connection protected PW or service
LSP 1 with endpoints in nodes A and H and protection end points in nodes C
and G. The working connection is running from C via D-E-F to G. The
protection connection is running from C via I-J-K-L to G.

|<-------- PW/service-LSP 1 -------------->|
|                                          |
A --- B --- C ---- D --- E --- F --- G --- H
             \-- I -- J -- K -- L --/
                     /           \
               V -- W             X -- Y -- Z
               |                            |
               |<---- PW/service-LSP 2 ---->|

In addition there is a unprotected preemptable PW or service LSP 2 with
endpoints in nodes V and Z, running over a subset of the links used by the
protection connection (i.e. links between nodes J-K and K-L). As long as the
protection connection is not used to carry the PW/svc-LSP traffic from A to
H, the bandwidth is used by traffic of the second PW/svc-LSP (V-Z).

The alternative case is the case in which the unprotected, preemptable
PW/svc-LSP 2 from V to Z shares all the links over which the protection
connection is running. I.e. the connection is V-W-C-I-J-K-L-G-X-Y-Z.

|<-------- PW/service-LSP 1 -------------->|
|                                          |
A --- B --- C ---- D --- E --- F --- G --- H
           / \-- I -- J -- K -- L --/ \
     V -- W                            X -- Y -- Z
     |                                           |
     |<----------- PW/service-LSP 2 ------------>|

Do you consider the 
- first case and not the second case as a description of "extra traffic", or
- second case and not the first case as a description of "extra traffic", or
- both the first and second cases as a description of "extra traffic"
in a protection application?

Thanks,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Curtis Villamizar
Sent: vrijdag 7 mei 2010 2:57
To: BUSI ITALO
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Description of Extra Traffic in Survivability
Framework

Italo,

You are partially right in your statement "there is no requirement to
develop protocol solutions to support extra-traffic in MPLS-TP".
However I disagree with the statement "It is therefore my strong feeling
that MPLS-TP protection switching would benefit from not supporting
extra-traffic."

GMPLS already supports an ability to put extra traffic on a protect path.
Protection itself is imperfect (apparently this itself is a revalation to
some - in the US there are currently multiple faults in Tennessee, just as
an example).  Shared mesh protection is very handy in a packet network.
Zero reservation FRR is actually the most popular protection mechanism in
packet networks today.

In zero reservation FRR there is no attempt to reserve capacity for
protection.  The protection paths are simply diverse with working paths.
This works in practice in networks where the high priority traffic is a
minority.  With the high bandwidth demands of the Internet, this is almost
universally true in provider packet networks.
The FRR paths are only used to achieve sub 50 msec protection for that
minority of high priority traffic.  The lower priority traffic is simply
congested a little until reroute of the working path is completed (which
does use reservations).  Soft preempt also insures that multiple high
priority LSP don't stop on each other when there is plenty of best effort
traffic that can be stomped on instead.  The reroute that relieves low
priority traffic congestion today takes a few seconds, maybe sub-second
depending on network size.

The e2e shared mesh protection is a bit more of an orderly affair.
This is usually done with offline computation to insure that protection is
adequate for any single SRLG fault.  When a single fault occurs, no
congestion occurs, not even interim congestion.  But multiple faults do
regularly occur and if they do, the highest priority traffic is still
carried without loss (except the <<50 msec due directly to the fault) and
typically only the lowest priority traffic experiences interim congestion
until a reroute can releive the congestion.  If there are LSP that carry
only high priority traffic, then the MPLS setup and holding priorities come
into play, but typically all services are on a single LSP using TC bits for
QoS.

btw- Shared mesh OTN using GMPLS could in principle do the same except
preemption is needed when a multiple fault occurs and any extra traffic must
be preempted on a fault.  I don't know of an implementation that goes that
far (yet).

This is what existing packet networks can do.  Therefore it truely comes for
free for some because at least some vendors have already done it, just not
the newcomers to (IP/MPLS) packet networking.  I don't think a goal of
MPLS-TP should be to criple MPLS.

Curtis

In message
<[email-masked]>
"BUSI ITALO" writes:

Adrian,

> It is our understanding that this means that extra traffic is within 
> scope of MPLS-TP, but that there is no requirement for a specification 
> to be produced, and that implementations are not required to support 
> extra traffic.
>  

During the development of RFC5654 we had intensive debate about how to
interpret these requirements. We have agreed that the requirements are for
the solution and not for the implementation as described in section 1.1. of
RFC5654.

As described by Maarten, support of extra-traffic is making APS more complex
and slower.

It is therefore my strong feeling that MPLS-TP protection switching would
benefit from not supporting extra-traffic.

Italo

> Subject: [mpls-tp] Description of Extra Traffic in Survivability 
> Framework
> 
> Hi MPLS-TP list,
> 
> Nurit and I are working on the Survivability Framework and the review 
> from the ITU-T.
> 
> It is our understanding that this means that extra traffic is within 
> scope of MPLS-TP, but that there is no requirement for a specification 
> to be produced, and that implementations are not required to support 
> extra traffic.
> 
> We also believe that the Survivability Framework should include a 
> description of extra traffic to give an overview of how it fits into 
> the general survivability model in case anyone wishes to work on extra 
> traffic in the future.
> 
> there is a proposed major deletion of text from section 4.3.3. No 
> explanation of this deletion is provided, but we are assuming that it 
> is because the ITU-T feels that there is no requirement to support 
> extra traffic.
> 
> Nurit and I would like to hear the views of the MPLS-TP community on 
> this issue.
> 
> Thanks,
> Adrian and Nurit
>

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 23 May 2010 10:32:18 -0400

Extra traffic in this context is working traffic that is on capacity
set aside but not yet used for protection.  It comes in many forms.
It requires one of three conditions to be useful: 1) the traffic is
compressible (in the INTSERV sense), or 2) the lower priority traffic
can be moved to another path if protection of higher priority traffic
is activated, 3) its OK for the lower priority traffic to lose (some
or all) capacity.

The first condition mystifies people with a "hard reservations" mind
set but is the most common.  That is the reasoning behind sizing a LAG
or other parallel links at N+1 for large N, just in case a card goes,
but using the spare bandwidth to accomodate traffic burts that are
above normal traffic levels.  The second can be used with soft-preempt
for implementations which implement soft-preempt and have the working
path rerouted over the old protect (at full bandwidth and causing
preemption).  These only work in the packet world (not applicable to
circuits which are unable to share capacity dynamically) and any
interim congestion is handled with diffserv or DS-TE prioritization of
traffic rather than through MPLS signaled (or management plane
provisioned) bandwidth reservations associated with the protect LSP.

This is not done in practice in the circuit world because of the need
to hard preempt the "extra" working traffic (plus the need for
stateful setup of time slots within NE for the protect traffic to
flow once "activated" - ie: its not as fast today - yet).

Curtis

In message <[email-masked]>
Maarten Vissers writes:

Curtis,

Do you consider the 

Thanks,
Maarten

-----Original Message-----

Italo,

Curtis

In message

Adrian,

Italo