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

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 18 Apr 2010 14:30:43 +0100

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

---

From: Zhi-Wei Lin <[email-masked]>
Date: Sun, 18 Apr 2010 16:46:31 -0400

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:

> In the liaison from the ITU-T (
> https://datatracker.ietf.org/documents/LIAISON/file984.pdf) there is a
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 19 Apr 2010 10:23:33 +0200

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,

Thanks
Zhi

Hi MPLS-TP list,

Thanks,
Adrian and Nurit

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 20 Apr 2010 12:38:39 +0100

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

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 21 Apr 2010 08:34:31 +0200

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,

Cheers,
Adrian
----- Original Message -----
From: "Maarten Vissers" <[email-masked]>
To: "'Zhi-Wei Lin'" <[email-masked]>; "'Adrian Farrel'" 
<[email-masked]>

> 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
> 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
>
>
>
> Nurit and I are working on the Survivability Framework and the review 
> from the ITU-T.
>
> 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.
>
> 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.
>
> (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

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 23 Apr 2010 22:29:19 +0100

Hi Zhi,

I think I read this as you saying that you would prefer for extra traffic to 
be included in the document, but if it is left out you would not be too 
upset.

Cheers,
Adrian
----- Original Message ----- 
From: "Zhi-Wei Lin" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Sunday, April 18, 2010 9:46 PM
Subject: Re: [mpls-tp] Description of Extra Traffic in Survivability 
Framework

> traffic
> allow
>> from
>> scope

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 23 Apr 2010 22:27:44 +0100

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

---

From: Zhi-Wei Lin <[email-masked]>
Date: Sun, 25 Apr 2010 09:41:32 -0400

Hi Adrian,

I want to make sure that MPLS-TP network allows me to set up preemptible
MPLS-TP connections to re-use capacity normally reserved by high-priority
connections. If a failure occurs, the preemptible connection may be dropped
to allow high priority connection to re-route.

I thought this was what extra traffic was meant for. However, from Maarten's
email it sounds like he's saying what I'm looking for is inherent in
MPLS-TP. If that's the case, then yes I would not be upset to exclude it.

Thanks
Zhi

On Fri, Apr 23, 2010 at 5:29 PM, Adrian Farrel <[email-masked]> wrote:

> Hi Zhi,
>
> I think I read this as you saying that you would prefer for extra traffic
> to be included in the document, but if it is left out you would not be too
> upset.
>
> Cheers,
> Adrian
> ----- Original Message ----- From: "Zhi-Wei Lin" <[email-masked]>

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Sun, 25 Apr 2010 20:56:22 +0200

I also think that since both come for free, we should keep the text in
the framework document. 
Best regards,
Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Adrian Farrel
Sent: Saturday, April 24, 2010 12:28 AM
To: Maarten Vissers
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Description of Extra Traffic in
SurvivabilityFramework

Yeah. Agree.

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
> such traffic, and in the transport path/higher order/virtual path
layer 
> such
> within a linear protected connection. Such traffic is naturally
supported 
> in
> notified and fully pre-empted in the event of the backup path needing
to 
> be
> My answer (FWIW) is "both". That is, we should support best-effort
(which 
> is

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 26 Apr 2010 07:38:49 +0200

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 

-----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.

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

> 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.
>
> 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).
>
>> operators are familiar with, and how much do we want to integrate 
> Operators with Ethernet based packet transport network are familiar 
> with SNCP which does not support extra traffic.
>
> Regards,
> Maarten
>
>
>
> support "over-subscription" which provides an excellent way to 
> distinguish guaranteed and best-effort traffic.
>
> to be used to carry protected (i.e. higher priority) traffic.
>
> (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
>> 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 
>> 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
>>
>>  _____
>>
>> 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
>>
>>
>>
>> Support for extra traffic (as defined in [RFC4427]) is not required 
>> in MPLS-TP and MAY be omitted from the MPLS-TP specifications.
>>
>> 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.
>>
>> the general survivability model in case anyone wishes to work on 
>> extra traffic in the future.
>>

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 26 Apr 2010 07:43:58 +0200

Nurit,

Extra Traffic support doesn't come for free. Refer to my response to
Adrian's email.

Regards,
Maarten 

-----Original Message-----
From: Sprecher, Nurit (NSN - IL/Hod HaSharon)
[mailto:[email-masked]] 
Sent: zondag 25 april 2010 20:56
To: Adrian Farrel; Maarten Vissers
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] Description of Extra Traffic in
SurvivabilityFramework

I also think that since both come for free, we should keep the text in the
framework document. 
Best regards,
Nurit

-----Original Message-----
Of ext Adrian Farrel

Yeah. Agree.

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

a 
> don't
have
layer 
supported 
> Operators with Ethernet based packet transport network are familiar
with
> support "over-subscription" which provides an excellent way to
distinguish
to 
(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
is
traffic
to
>> As I stated in my previous email, I believe there are some
differences
to
in
>> scope of MPLS-TP, but that there is no requirement for a
specification
>> the general survivability model in case anyone wishes to work on
extra

---

From: "BUSI ITALO" <[email-masked]>
Date: Mon, 26 Apr 2010 09:10:17 +0200

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

> 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.
> 
> 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.
> 
> (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 
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 26 Apr 2010 07:58:04 +0100

I think you are wrong.

Extra traffic is end-to-end on the protection domain.
The protection switching protocol is also end-to-end on the protection 
domain.
No additional messages or coordination are needed.

Thanks,
Adrian
----- Original Message ----- 
From: "Maarten Vissers" <[email-masked]>
To: "'Adrian Farrel'" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Monday, April 26, 2010 6:38 AM
Subject: RE: [mpls-tp] Description of Extra Traffic in Survivability 
Framework

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 26 Apr 2010 09:59:04 +0200

Hi Adrian,

> I think you are wrong.

I don't think so.

> The protection switching protocol is also end-to-end
 > on the protection domain.

The bridge and selector are more complicated.

Regards, Huub.

> ----- Original Message ----- From: "Maarten Vissers"
> <[email-masked]>

-- 
================================================================
                   http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...