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

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

In message <[email-masked]>
Maarten Vissers writes:
>  
> Adrian,
>  
> The 'damage' of including support for extra traffic is a more complex
> APS/protection switching protocol state machine, which requires unnecessary
> design time, testing time and bug fixing.
>  
> Regards,
> Maarten 

Maarten,

Fpr those that have already figured out how to do this in a way that
only temporarily affects the lowest priority traffic after a fault we
should not prohibit extra traffic which is allowed in GMPLS and is
optional.  Since it is optional you can avoid the design time, testing
time and bug fixing if you prefer.

Curtis

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]] 
> Sent: vrijdag 23 april 2010 23:28
> To: Maarten Vissers
> Cc: [email-masked]; [email-masked]
> Subject: Re: [mpls-tp] Description of Extra Traffic in Survivability
> Framework
>  
> Yeah. Agree.
>  
> Question is: where does this leave us?
>  
> Best-effort comes for free in MPLS-TP since TC is already in MPLS.
>  
> Extra traffic comes for free in MPLS-TP since LSP preemption is already in
> MPLS.
>  
> Seems to me that if neither one requires effort, we should describe both in
> the framework and let the operators decide which they want to deploy. If you
> are right (no demand for extra traffic) I don't believe any damage will have
> been done.
>  
> Cheers,
> Adrian
>  
> ----- Original Message -----
> From: "Maarten Vissers" <[email-masked]>
> To: "'Adrian Farrel'" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Wednesday, April 21, 2010 7:34 AM
> Subject: RE: [mpls-tp] Description of Extra Traffic in Survivability
> Framework
>  
>  
> > Adrian,
> >
> > The applicability of extra traffic in linear protection switching has 
> > a very limited application scope, and is hardly used in transport 
> > networks.
> > Reason
> > is that extra (i.e. pre-emptable) traffic typically does not exists 
> > between the end points of a linear protection switching instance; i.e. 
> > in the transport service/lower order/virtual channel layer customers 
> > don't have such traffic, and in the transport path/higher 
> > order/virtual path layer such traffic does not exist either.
> >
> > Pre-emptable traffic exists in a few cases between intermediate points 
> > within a linear protected connection. Such traffic is naturally 
> > supported in packet transport networks by the normal drop eligible and 
> > priority markings.
> > This was the reason why extra traffic is not supported in ETH SNC 
> > protection (G.8031).
> >
> >> How much do we want this to look like the transport networks that the 
> >> operators are familiar with, and how much do we want to integrate 
> >> with normal packet behaviors?
> >
> > Operators with Ethernet based packet transport network are familiar 
> > with SNCP which does not support extra traffic.
> >
> > Regards,
> > Maarten
> >
> >
> >
> > -----Original Message-----
> > From: Adrian Farrel [mailto:[email-masked]]
> > Sent: dinsdag 20 april 2010 13:39
> > To: Maarten Vissers; 'Zhi-Wei Lin'
> > Cc: [email-masked]; [email-masked]
> > Subject: Re: [mpls-tp] Description of Extra Traffic in Survivability 
> > Framework
> >
> > Hi,
> >
> > Yes, I have some sympathy with this point.
> >
> > I guess the different between per-packet pre-emption and per-flow 
> > pre-emption is worth consideration.
> >
> > What you describe is per-packet pre-emption. It is a good mechanism to 
> > support "over-subscription" which provides an excellent way to 
> > distinguish guaranteed and best-effort traffic.
> >
> > The difference, as I see it (and as described in the Survivability
> > Framework) is that the entire extra traffic flow (that is, an LSP) is 
> > notified and fully pre-empted in the event of the backup path needing 
> > to be used to carry protected (i.e. higher priority) traffic.
> >
> > It may be that the question we should ask is...
> >
> > How much do we want this to look like the transport networks that the 
> > operators are familiar with, and how much do we want to integrate with 
> > normal packet behaviors?
> >
> > My answer (FWIW) is "both". That is, we should support best-effort 
> > (which is already part of MPLS) and we should support extra traffic 
> > (which is already part of the management plane, OAM, and the GMPLS 
> > control plane). In other words, I don't think there is substantial 
> > cost to supporting both mechanisms, but we can offer operators a 
> > significant amount of flexibility of function and operation of their 
> > networks.
> >
> > Cheers,
> > Adrian
> > ----- Original Message -----
> > From: "Maarten Vissers" <[email-masked]>
> > To: "'Zhi-Wei Lin'" <[email-masked]>; "'Adrian Farrel'"
> > <[email-masked]>
> > Cc: <[email-masked]>; <[email-masked]>
> > Sent: Monday, April 19, 2010 9:23 AM
> > Subject: RE: [mpls-tp] Description of Extra Traffic in Survivability 
> > Framework
> >
> >
> >> Rationale to not support extra traffic in packet transport networks 
> >> is that connections with preemtable traffic are already supported in 
> >> packet transport networks; i.e. connections with drop eligible 
> >> traffic and/or low priority traffic that may be pushed away when high 
> >> priority, non-drop eligible traffic is applied at the input port of a 
> >> link. The advantage of this latter traffic is that it does not have 
> >> to start/end at the location of the protection switch end points.
> >>
> >> Regards,
> >> Maarten
> >>
> >>  _____
> >>
> >> From: [email-masked] [mailto:[email-masked]] On 
> >> Behalf Of Zhi-Wei Lin
> >> Sent: zondag 18 april 2010 22:47
> >> To: Adrian Farrel
> >> Cc: [email-masked]; [email-masked]
> >> Subject: Re: [mpls-tp] Description of Extra Traffic in Survivability 
> >> Framework
> >>
> >>
> >> Hi Adrian, Nurit,
> >>
> >> As I stated in my previous email, I believe there are some 
> >> differences between a TDM network and a packet network. In packet 
> >> network, much traffic is best effort - and even most higher priority 
> >> traffic are bursty in nature (except the TDM PWE stuff). I believe 
> >> extra traffic feature fits nicely with transport of best effort type 
> >> traffic in a packet network that MPLS-TP is targeting.
> >>
> >> However, if extra traffic is not supported, then having the ability 
> >> to allow for oversubscription would in my view accomplish the same 
> >> thing, with support for (1:1)^n.
> >>
> >> Thanks
> >> Zhi
> >>
> >>
> >>
> >> On Sun, Apr 18, 2010 at 9:30 AM, Adrian Farrel <[email-masked]>
> >> wrote:
> >>
> >>
> >> 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:05:42 +0200

Curtis,

Optional in a standard implies mandatory for a manufacturer and optional to
use for an operator.

If there is a network need for "extra traffic" in a linear protection
switching application, then we have to specify it, design it and test it. If
there is no network application, then we should leave it out. 

Regards,
Maarten 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: vrijdag 7 mei 2010 2:17
To: Maarten Vissers
Cc: 'Adrian Farrel'; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Description of Extra Traffic in Survivability
Framework

Maarten Vissers writes:
> APS/protection switching protocol state machine, which requires 
> unnecessary design time, testing time and bug fixing.
>  
> Regards,
> Maarten

Maarten,

Curtis

---

From: John E Drake <[email-masked]>
Date: Fri, 7 May 2010 07:20:13 -0700

-1

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Maarten Vissers
> Sent: Friday, May 07, 2010 7:06 AM
> To: [email-masked]

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Sun, 9 May 2010 10:47:18 +0200

Maarten,
Optional means that the protocol may define a solution for it. Nothing
about implementations. 
Best regards,
Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext John E Drake
Sent: Friday, May 07, 2010 5:20 PM
To: Maarten Vissers; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Description of Extra Traffic inSurvivability
Framework

-1

> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Optional in a standard implies mandatory for a manufacturer and
optional
> to
> switching application, then we have to specify it, design it and test
it.
> If
> > Extra traffic comes for free in MPLS-TP since LSP preemption is
already
> in
> > MPLS.
> >
> > Seems to me that if neither one requires effort, we should describe
both
> in
> > the framework and let the operators decide which they want to
deploy. If
> you
> > are right (no demand for extra traffic) I don't believe any damage
will
> have
with

---

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

In message <[email-masked]>
Maarten Vissers writes:
> optional to use for an operator.

Exactly.

> it. If there is no network application, then we should leave it out.

There is a need so as a competitor I strongly recommend that you leave
it out.  :-)