Subject: Re: [mpls-tp] [PWE3] Proposal of using GAL for PW

From: <[email-masked]>
Date: Thu, 1 Jul 2010 08:44:17 +0100

I support your view Luca (and others who have said the same) for several reasons, 2 important ones being:
 
-    The CW has largely useless functional fields even with MPLS IMO...ergo why it could indeed be optional there.  But with MPLS-TP this is even more starkly true.  For example, a key requirement of a transport network is ordered delivery of client symbols (this is part of a larger 'transparency' requirement) so we should have no use for the Seq No. field of the CW.  Similarly, a major use of the CW was the unfortunate 1st nibble PID-type hack to avoid ECMP problems.  Again, since MPLS-TP is supposed to be a transport network we must have control over the vector of a connection's routing and its resource management.  So ECMP, and hence the 1st nibble hack, is not required.
 
-    MPLS-TP should have critical CP/MP protocols run logically OOB wrt the traffic DP.  This not only applies to MPLS-TP LSPs but also LSPs supporting PWs....but see note below:

Note:    In a properly designed co-ps mode MPLS-TP transport network all clients should be treated equally/transparently.   This has 2 immediate consequences:
    * PWs should not exist as a special case of a client
    * We should not have traditional LSP nested sublayering...again this is a special case of a (MPLS) client.
 
There are some rather important issues related to misconnectivity across all combinations of nested MPLS-TP layers, nested MPLS-TP sublayers and PW layers here (noting that all look alike in the traffic DP)....put simply, we must have exactly the same CV OAM containing consistent SA (relating to the layer network concerned, eg PW access points have AII-based addresses whereas MPLS-TP has global ID or ICC based addressing).  This is important for 2 reasons:
-    we cannot predict a priori where misconnectivity will happen across a set of nested LSPs which can contain some arbitrary combination of MPLS-TP layers, MPLS-TP sublayers and PW layers...so a trail termination point of any of these entities must be able to parse/understand what arrives in DP OAM messages under misconnectivity
-    in order to accurately/quickly identify an offending source of misconnectivity, network operators require that a CV message carry absolute SA information of the misconnected source....and to be quite clear here, this cannot be some some locally/node-unique-only generated 'discriminator' value...it must be a pukka SA.
 
Further....although PWs should not exist if MPLS-TP was a properly designed transport network, since these will continue to exist we should be reusing the same CP/MP protocols and reusing the same OOB techniques to set-up/tear-down MPLS-TP LSPs and PW LSPs.  Specifically we should only be using RSVP-TE signalling in both cases.  However, I understand we have a problem here in that RSVP-TE signalling does not currently support the AII based addressing of PWs and so we have to also have T-LDP signalling.  
 
regards, Neil

________________________________

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Luca Martini
	Sent: 01 July 2010 04:23
	To: Andrew G. Malis
	Cc: [email-masked]; [email-masked]; HUANG Feng F; [email-masked]
	Subject: Re: [mpls-tp] [PWE3] Proposal of using GAL for PW

	Andy,
	
	I have to disagree that there was any consensus about this issue.
	If anything , there was consensus that there is no written statement that we must  to use the CW in MPLS-TP.
	
	At the end we needed more input from service providers that have deployed PWs.  The point is not whether there is hardware support for the CW, but whether we even want to use it in many cases where it adds absolutely no value. For example ATM PWs in cell mode , where it add almost 10% overhead with no benefit. Another case where the CW is not useful is the ethernet PW without network link load balancing, where we add 4 bytes to every packet just to occasionally send a status , or OAM message.
	
	I would like to propose update the rfc5586 to allow the use of the GAL in PWs without the CW.
	
	This makes the use of the GAL very symmetric among PWs and MPLS-TP LSPs. This makes it easy to process by hardware based implementations.
	
	Luca

	Andrew G. Malis wrote: 

		Larry and Feng,
		
		This issue has previously been discussed at length by the working
		group, both at the Anaheim meeting and by email, for example in emails
		with the subject line "Possible Contradiction re use of GAL in
		pwe3-static-pw-status". There was rough consensus that for MPLS-TP
		applications and/or when PW OAM is desired, PW implementations are
		mature enough (it has been 10 years now, after all) that the time has
		come to require the implementation of the CW for all PWs, including
		Ethernet.
		
		Cheers,
		Andy
		
		On Wed, Jun 30, 2010 at 6:34 AM, HUANG Feng F
		<[email-masked]> <mailto:[email-masked]>  wrote:

			it is reasonable to support GAL in MPLS-TP PW OAM, it is more generic, because CW is an option RFC4448 for Ethernet over MPLS.
			
			4.6.  The Control Word
			
			xxxx

			The features that the control word provides may not be needed for a
			  given Ethernet PW.  For example, ECMP may not be present or active on
			  a given MPLS network, strict frame sequencing may not be required,
			  etc.  If this is the case, the control word provides little value and
			  is therefore optional.  Early Ethernet PW implementations have been
			  deployed that do not include a control word or the ability to process
			  one if present.  To aid in backwards compatibility, future
			  implementations MUST be able to send and receive frames without the
			  control word present.
			xxxx

			B.R.
			Feng Huang

			-----Original Message-----
			From: [email-masked] [mailto:[email-masked]] On Behalf Of Larry
			Sent: 2010年6月30日 17:38
			To: [email-masked]; [email-masked]
			Cc: [email-masked]
			Subject: [PWE3] Proposal of using GAL for PW
			
			Dear all:
			
			    In section 4.2 in RFC5586, it is defined that GAL MUST NOT be used with PWs in MPLS-TP. The PWE3 control word [RFC4385] MUST be present when the ACH is used to realize the associated control channel.
			    In real application, a lot of MPLS and MPLS-TP equipments do not support control word. It is proposed to use the GAL to identify associated control channel in PW layer.
			
			Best regards,
			
			                Han Li
			
			********************************************************************
			Han Li, Ph.D
			China Mobile Research Institute
			Unit 2, 28 Xuanwumenxi Ave, Xuanwu District, Beijing 100053, China
			Fax: +86 10 63601087
			MOBILE: 13501093385
			********************************************************************

		_______________________________________________
		pwe3 mailing list
		[email-masked]
		https://www.ietf.org/mailman/listinfo/pwe3

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 01 Jul 2010 09:39:12 +0200

Ciao Luca,

> that we must to use the CW in MPLS-TP.

I agree with this.

> At the end we needed more input from service providers that have 
> deployed PWs. The point is not whether there is hardware support for the 
> CW, but whether we even want to use it in many cases where it adds 
> absolutely no value. For example ATM PWs in cell mode , where it add 
> almost 10% overhead with no benefit. Another case where the CW is not 
> useful is the ethernet PW without network link load balancing, where we 
> add 4 bytes to every packet just to occasionally send a status , or OAM 
> message.
> 

I  support this

> This makes the use of the GAL very symmetric among PWs and MPLS-TP LSPs. 
> This makes it easy to process by hardware based implementations.

I agree, consistency is very important, it causes less mistakes
in maintaining a network., and also for implementations (HW and SW).

Best regards, Huub.

>> <[email-masked]>  wrote:
>>    
>>> From:[email-masked]  [mailto:[email-masked]] On Behalf Of Larry
>>> Sent: 2010年6月30日 17:38
>>> To:[email-masked];[email-masked]
>>> Cc:[email-masked]
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp

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

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 01 Jul 2010 07:14:49 -0400

I  agree with Andy’s assertion. This service provider’s experience is
that making the CW mandatory going forward (and hopefully retrofitting
existing PW protocol specs) would improve implementation interoperability.

    --Tom

On 6/30/10 11:22 PM, "Luca Martini" <[email-masked]> wrote:

> At the end we needed more input from service providers that have deployed PWs.
> The point is not whether there is hardware support for the CW, but whether we
> even want to use it in many cases where it adds absolutely no value. For
> example ATM PWs in cell mode , where it add almost 10% overhead with no
> benefit. Another case where the CW is not useful is the ethernet PW without
> network link load balancing, where we add 4 bytes to every packet just to
> occasionally send a status , or OAM message.
> 
> This makes the use of the GAL very symmetric among PWs and MPLS-TP LSPs. This
> makes it easy to process by hardware based implementations.
> 
> Luca
> 
> 
> Andrew G. Malis wrote:
>>  
>> Larry and Feng,
>> 
>> <[email-masked]>
>> <mailto:[email-masked]>  wrote:
>>   
>>  
>>>  
>>> it is reasonable to support GAL in MPLS-TP PW OAM, it is more generic,
>>> because CW is an option RFC4448 for Ethernet over MPLS.
>>> 
>>> 4.6.  The Control Word
>>> 
>>> xxxx
>>> 
>>> 
>>>     In section 4.2 in RFC5586, it is defined that GAL MUST NOT be used with
>>> PWs in MPLS-TP. The PWE3 control word [RFC4385] MUST be present when the ACH
>>> is used to realize the associated control channel.
>>>     In real application, a lot of MPLS and MPLS-TP equipments do not support
>>> control word. It is proposed to use the GAL to identify associated control
>>> channel in PW layer.
>>> 
>>> Best regards,
>>> 
>>>                 Han Li
>>>

---

From: Giles Heron <[email-masked]>
Date: Thu, 01 Jul 2010 14:22:17 +0100

Not sure I agree.

Many CPs have deployed PWs with no CW.   Adding a CW to all packets just to
enable occasional OAM messages seems like overkill.

But the downside of adding GAL is that it’s a fourth OAM mode for PWEs (back
to your point about interoperability).  Too many options!

Giles

On 01/07/2010 12:14, "Tom Nadeau" <[email-masked]> wrote:

> 
>     I  agree with Andy’s assertion. This service provider’s experience is that
> making the CW mandatory going forward (and hopefully retrofitting existing PW
> protocol specs) would improve implementation interoperability.
> 
>     --Tom
> 
> 
> 
>> At the end we needed more input from service providers that have deployed
>> PWs.  The point is not whether there is hardware support for the CW, but
>> whether we even want to use it in many cases where it adds absolutely no
>> value. For example ATM PWs in cell mode , where it add almost 10% overhead
>> with no benefit. Another case where the CW is not useful is the ethernet PW
>> without network link load balancing, where we add 4 bytes to every packet
>> just to occasionally send a status , or OAM message.
>> 
>>>> PWs in MPLS-TP. The PWE3 control word [RFC4385] MUST be present when the
>>>> ACH is used to realize the associated control channel.
>>>>     In real application, a lot of MPLS and MPLS-TP equipments do not
>>>> support control word. It is proposed to use the GAL to identify associated
>>>> control channel in PW layer.
>>>> 
>>>> Best regards,
>>>> 
>>>>                 Han Li
>>>>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 01 Jul 2010 09:31:21 -0400

On 7/1/10 9:22 AM, "Giles Heron" <[email-masked]> wrote:

> TOM: The question would be in those cases: do those CPs have multi-vendor
> implementations and how difficult is it for them to handle operational issues
> as well as interoperability of those implementations?  The operators that have
> presented/discussed this at the last PWE3 meeting seemed to voice a resounding
> desire to have a consistent method rather than 3, 4 or N options.
> 
> TOM: Precisely the point of requiring one way to do things.  Too many options
> is ok to get the kinks worked out of implementations, but going forward it
> seems better to narrow things as Andy’s original note asserted.
> 
>     --Tom
> 
> 
> 
> Giles
> 
>>>>>     In section 4.2 in RFC5586, it is defined that GAL MUST NOT be used
>>>>> with PWs in MPLS-TP. The PWE3 control word [RFC4385] MUST be present when
>>>>> the ACH is used to realize the associated control channel.

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 1 Jul 2010 10:08:36 -0700

Hi,

I agree with Andy and Tom. The best way forward is to mandate control word (VVCV Type 1) for future implementations, rather than introduce VCCV Type 4.

Thanks,
Shahram

From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas D. Nadeau
Sent: Thursday, July 01, 2010 6:31 AM
To: Giles Heron; Luca Martini; Andrew G. (Andy) Malis
Cc: [email-masked]; [email-masked]; HUANG Feng F; [email-masked]
Subject: Re: [mpls-tp] [PWE3] Proposal of using GAL for PW

Many CPs have deployed PWs with no CW.   Adding a CW to all packets just to enable occasional OAM messages seems like overkill.

TOM: The question would be in those cases: do those CPs have multi-vendor implementations and how difficult is it for them to handle operational issues as well as interoperability of those implementations?  The operators that have presented/discussed this at the last PWE3 meeting seemed to voice a resounding desire to have a consistent method rather than 3, 4 or N options.

But the downside of adding GAL is that it’s a fourth OAM mode for PWEs (back to your point about interoperability).  Too many options!

TOM: Precisely the point of requiring one way to do things.  Too many options is ok to get the kinks worked out of implementations, but going forward it seems better to narrow things as Andy’s original note asserted.

    --Tom

Giles

    I  agree with Andy’s assertion. This service provider’s experience is that making the CW mandatory going forward (and hopefully retrofitting existing PW protocol specs) would improve implementation interoperability.

    --Tom

Luca

Andrew G. Malis wrote:

Larry and Feng,

Cheers,
Andy

4.6.  The Control Word

xxxx

B.R.
Feng Huang

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Larry
Sent: 2010年6月30日 17:38
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [PWE3] Proposal of using GAL for PW

Dear all:

Best regards,

                Han Li

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 1 Jul 2010 10:13:36 -0700

Giles,

CW is not just for identifying OAM messages. It normalizes the packet format and makes the job of parsers much simpler. It allows you to identify the payload type without knowing the PW label context. It also improves interoperability and could also simplify many other applications such as 1588 over MPLS.

Regards,
Shahram

From: [email-masked] [mailto:[email-masked]] On Behalf Of Giles Heron
Sent: Thursday, July 01, 2010 6:22 AM
To: Tom Nadeau; Luca Martini; Andy Malis
Cc: [email-masked]; [email-masked]; HUANG Feng F; [email-masked]
Subject: Re: [mpls-tp] [PWE3] Proposal of using GAL for PW

Not sure I agree.

Giles

    --Tom

Luca

Andrew G. Malis wrote:

Larry and Feng,

Cheers,
Andy

4.6.  The Control Word

xxxx

B.R.
Feng Huang

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Larry
Sent: 2010年6月30日 17:38
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [PWE3] Proposal of using GAL for PW

Dear all:

Best regards,

                Han Li

---

From: Giles Heron <[email-masked]>
Date: Thu, 01 Jul 2010 15:42:20 +0100

I’m all up for narrowing it down.  But then the question is what do we
narrow down to?  For the future GAL might be a better option than CW (at
least in the TP case where we don’t have to worry about ECMP etc.)

On 01/07/2010 14:31, "Tom Nadeau" <[email-masked]> wrote:

>> as well as interoperability of those implementations?  The operators that
>> have presented/discussed this at the last PWE3 meeting seemed to voice a
>> resounding desire to have a consistent method rather than 3, 4 or N options.
>> 
>>>>>> support control word. It is proposed to use the GAL to identify
>>>>>> associated control channel in PW layer.
>>>>>> 
>>>>>> Best regards,
>>>>>> 
>>>>>>                 Han Li
>>>>>>

---

From: Sam Aldrin <[email-masked]>
Date: Thu, 1 Jul 2010 10:55:06 -0700

As deployments with no CW already exist, mandating CW in not a  
preferred option. Also, I believe, mandating CW just to support OAM is  
an overkill.

Were the Multi-segment scenarios considered here? Not all the segments  
necessarily support CW, whereby, having GAL label support is a better  
option.

cheers
-sam
On Jul 1, 2010, at 10:08 AM, Shahram Davari wrote:

> Hi,
>
> I agree with Andy and Tom. The best way forward is to mandate  
> control word (VVCV Type 1) for future implementations, rather than  
> introduce VCCV Type 4.
>
> Thanks,
> Shahram
>
> Many CPs have deployed PWs with no CW.   Adding a CW to all packets  
> just to enable occasional OAM messages seems like overkill.
>
> TOM: The question would be in those cases: do those CPs have multi- 
> vendor implementations and how difficult is it for them to handle  
> operational issues as well as interoperability of those  
> implementations?  The operators that have presented/discussed this  
> at the last PWE3 meeting seemed to voice a resounding desire to have  
> a consistent method rather than 3, 4 or N options.
>
> But the downside of adding GAL is that it’s a fourth OAM mode  
> for PWEs (back to your point about interoperability).  Too many  
> options!
>
> TOM: Precisely the point of requiring one way to do things.  Too  
> many options is ok to get the kinks worked out of implementations,  
> but going forward it seems better to narrow things as Andy’s  
> original note asserted.
>
>     --Tom
>
>
>
> Giles
>
>     I  agree with Andy’s assertion. This service  
> provider’s experience is that making the CW mandatory going  
> forward (and hopefully retrofitting existing PW protocol specs)  
> would improve implementation interoperability.
>
>     --Tom
>
>
>
> deployed PWs.  The point is not whether there is hardware support  
> for the CW, but whether we even want to use it in many cases where  
> it adds absolutely no value. For example ATM PWs in cell mode ,  
> where it add almost 10% overhead with no benefit. Another case where  
> the CW is not useful is the ethernet PW without network link load  
> balancing, where we add 4 bytes to every packet just to occasionally  
> send a status , or OAM message.
>
> This makes the use of the GAL very symmetric among PWs and MPLS-TP  
> LSPs. This makes it easy to process by hardware based implementations.
>
> Luca
>
>
> Andrew G. Malis wrote:
>
> Larry and Feng,
>
> <[email-masked]> <mailto:[email-masked] 
> >  wrote:
>
>
>
> it is reasonable to support GAL in MPLS-TP PW OAM, it is more  
> generic, because CW is an option RFC4448 for Ethernet over MPLS.
>
> 4.6.  The Control Word
>
> xxxx
>
>
>     In section 4.2 in RFC5586, it is defined that GAL MUST NOT be  
> used with PWs in MPLS-TP. The PWE3 control word [RFC4385] MUST be  
> present when the ACH is used to realize the associated control  
> channel.

---

From: Giles Heron <[email-masked]>
Date: Thu, 01 Jul 2010 19:10:26 +0100

Hi Shahram,

I didn’t say CW was only for identifying OAM messages - I said adding it
just to enable occasional OAM messages was overkill.

The CW has half a dozen uses (the first 3 of which were the “original”
ones):
1) enabling small PWE payloads over Ethernet links
2) carrying L2 flags where the L2 header is stripped (e.g. FR)
3) sequence numbering
4) fragmentation (RFC4623).  Stole a couple of spare CW bits.
5) avoiding PWE packets aliasing IP where ECMP implementations “walk the
stack” and then look at the first nibble after the stack (nice side effect)
6) OAM indicator for in-band VCCV.  Stole a spare CW bit.

So let’s consider the Ethernet PWE case over MPLS-TP

1) Ethernet PWE packets are by definition larger than the minimum Ethernet
payload
2) There are no L2 flags in Ethernet
3) Sequence numbering is rarely used - and isn’t needed in the MPLS-TP case
4) I’m not aware of anyone implementing fragmentation for Ethernet PWE
5) There’s no ECMP when you’re doing MPLS-TP
6) the only one that applies (hence my comment)

As for the parsing thing that seems a bit odd to me.  Surely VCCV only tells
you that the payload is a PWE rather than IP?  It doesn’t tell you what sort
of PWE it is.

Sure, CW would help interop if everyone had one.  But with Ethernet PWE the
history is that nobody ever used them so I’m not sure we make our lives any
easier by mandating them now.

As for 1588 (and anything else we might try to squeeze into VCCV) that’s
another question.  I’d think we’re more likely to carry 1588 over Ethernet
over PWE, or over VCCV (and VCCV can be carried by mechanisms other than the
CW).

So the key argument for mandating CW would seem to be ensuring that OAM
traffic follows the same path as data traffic.  In the TP case I’d expect to
see that behaviour anyway (as any intermediate hops will label switch
without looking deep enough into the packet to spot the VCCV identifier –
whether that identifier is CW, router alert, TTL, or GAL).

Giles

On 01/07/2010 18:13, "Shahram Davari" <[email-masked]> wrote:

> Giles,
>  
> CW is not just for identifying OAM messages. It normalizes the packet format
> and makes the job of parsers much simpler. It allows you to identify the
> payload type without knowing the PW label context. It also improves
> interoperability and could also simplify many other applications such as 1588
> over MPLS.
>  
> Regards,
> Shahram
>  
> 
> it is reasonable to support GAL in MPLS-TP PW OAM, it is more generic, because
> CW is an option RFC4448 for Ethernet over MPLS.
> 
> 4.6.  The Control Word
> 
> xxxx
> 
>

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 1 Jul 2010 11:29:03 -0700

Giles,

I don’t want yet another VVCV type. If you are not using CW then just use RAL or TTL=1. Besides you proposal only works for MPLS-TP and not MPLS, where there is a Entropy label below PW label.

Thx
SD

From: Giles Heron [mailto:[email-masked]]
Sent: Thursday, July 01, 2010 11:10 AM
To: Shahram Davari; Tom Nadeau; Luca Martini; Andy Malis
Cc: [email-masked]; [email-masked]; HUANG Feng F; [email-masked]
Subject: Re: [mpls-tp] [PWE3] Proposal of using GAL for PW

Hi Shahram,

I didn’t say CW was only for identifying OAM messages - I said adding it just to enable occasional OAM messages was overkill.

The CW has half a dozen uses (the first 3 of which were the “original” ones):
1) enabling small PWE payloads over Ethernet links
2) carrying L2 flags where the L2 header is stripped (e.g. FR)
3) sequence numbering
4) fragmentation (RFC4623).  Stole a couple of spare CW bits.
5) avoiding PWE packets aliasing IP where ECMP implementations “walk the stack” and then look at the first nibble after the stack (nice side effect)
6) OAM indicator for in-band VCCV.  Stole a spare CW bit.

1) Ethernet PWE packets are by definition larger than the minimum Ethernet payload

As for the parsing thing that seems a bit odd to me.  Surely VCCV only tells you that the payload is a PWE rather than IP?  It doesn’t tell you what sort of PWE it is.

Sure, CW would help interop if everyone had one.  But with Ethernet PWE the history is that nobody ever used them so I’m not sure we make our lives any easier by mandating them now.

As for 1588 (and anything else we might try to squeeze into VCCV) that’s another question.  I’d think we’re more likely to carry 1588 over Ethernet over PWE, or over VCCV (and VCCV can be carried by mechanisms other than the CW).

So the key argument for mandating CW would seem to be ensuring that OAM traffic follows the same path as data traffic.  In the TP case I’d expect to see that behaviour anyway (as any intermediate hops will label switch without looking deep enough into the packet to spot the VCCV identifier - whether that identifier is CW, router alert, TTL, or GAL).

Giles

Regards,
Shahram

Not sure I agree.

Giles

    --Tom

Luca

Andrew G. Malis wrote:

Larry and Feng,

Cheers,
Andy

4.6.  The Control Word

xxxx

B.R.
Feng Huang

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Larry
Sent: 2010年6月30日 17:38
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [PWE3] Proposal of using GAL for PW

Dear all:

Best regards,

                Han Li

---

From: Giles Heron <[email-masked]>
Date: Thu, 01 Jul 2010 19:32:04 +0100

The entropy label is optional, surely?

I’ve never seen one in the wild – but then maybe I’m behind the times...

On 01/07/2010 19:29, "Shahram Davari" <[email-masked]> wrote:

> Giles,
>  
> I don’t want yet another VVCV type. If you are not using CW then just use RAL
> or TTL=1. Besides you proposal only works for MPLS-TP and not MPLS, where
> there is a Entropy label below PW label.
>  
> Thx
> SD
>  
> 
> I didn’t say CW was only for identifying OAM messages - I said adding it just
> to enable occasional OAM messages was overkill.
> 
> see that behaviour anyway (as any intermediate hops will label switch without
> looking deep enough into the packet to spot the VCCV identifier – whether that
> identifier is CW, router alert, TTL, or GAL).
> 
> Giles
>

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 1 Jul 2010 11:35:20 -0700

!mmm so if one used entropy then they can’t have OAM?

-SD

Sent: Thursday, July 01, 2010 11:32 AM

I’ve never seen one in the wild - but then maybe I’m behind the times...

Thx
SD

Hi Shahram,

Giles

Regards,
Shahram

Not sure I agree.

Giles

    --Tom

Luca

Andrew G. Malis wrote:

Larry and Feng,

Cheers,
Andy

4.6.  The Control Word

xxxx

B.R.
Feng Huang

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Larry
Sent: 2010年6月30日 17:38
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [PWE3] Proposal of using GAL for PW

Dear all:

Best regards,

                Han Li

---

From: Giles Heron <[email-masked]>
Date: Thu, 01 Jul 2010 20:26:55 +0100

That wasn’t what I said.  I said entropy labels are optional.  Most MPLS PWs
don’t have them.

Presumably if we did GAL with a PWE it could come after the entropy label?

Giles

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 1 Jul 2010 13:25:25 -0700

Dear Giles,
the problem is that the entropy label and the GAL both must be at the
bottom of stack as corresponding normative documents suggest.

Regards,
Greg

2010/7/1 Giles Heron <[email-masked]>:
> That wasn't what I said.  I said entropy labels are optional.  Most MPLS PWs
> don't have them.
>
> !mmm so if one used entropy then they can't have OAM?
>
> -SD
>
>
> I've never seen one in the wild - but then maybe I'm behind the times...
>
> I don't want yet another VVCV type. If you are not using CW then just use
> RAL or TTL=1. Besides you proposal only works for MPLS-TP and not MPLS,
> where there is a Entropy label below PW label.
>
> Thx
> SD
>
>
> I didn't say CW was only for identifying OAM messages - I said adding it
> The CW has half a dozen uses (the first 3 of which were the "original"
> ones):
> 5) avoiding PWE packets aliasing IP where ECMP implementations "walk the
> stack" and then look at the first nibble after the stack (nice side effect)
> So let's consider the Ethernet PWE case over MPLS-TP
>
> 3) Sequence numbering is rarely used - and isn't needed in the MPLS-TP case
> 4) I'm not aware of anyone implementing fragmentation for Ethernet PWE
> 5) There's no ECMP when you're doing MPLS-TP
> you that the payload is a PWE rather than IP?  It doesn't tell you what sort
> of PWE it is.
>
> history is that nobody ever used them so I'm not sure we make our lives any
> As for 1588 (and anything else we might try to squeeze into VCCV) that's
> another question.  I'd think we're more likely to carry 1588 over Ethernet
> traffic follows the same path as data traffic.  In the TP case I'd expect to
> without looking deep enough into the packet to spot the VCCV identifier -
> interoperability and could also simplify many other applications such as
> 1588 over MPLS.
>
> Regards,
> Shahram
>
>
> But the downside of adding GAL is that it's a fourth OAM mode for PWEs (back
>     I  agree with Andy's assertion. This service provider's experience is

---

From: Giles Heron <[email-masked]>
Date: Thu, 1 Jul 2010 22:03:46 +0100

Sure, but that could be changed I suspect.  Logically you'd want OAM  
under the entropy label so you can test all paths, right?

Sent from my iPhone

On 1 Jul 2010, at 21:25, Greg Mirsky <[email-masked]> wrote:

>> From: [email-masked] [mailto:[email-masked]] On  
>> Behalf
>> Of Giles Heron
>> just to
>> If anything , there was consensus that there is no written  
>> statement that we
>> must  to use the CW in MPLS-TP.
>>
>> deployed
>> I would like to propose update the rfc5586 to allow the use of the  
>> GAL in
>> PWs without the CW.
>>
>> LSPs.
>> generic,
>> From: [email-masked] [mailto:[email-masked]] On  
>> Behalf Of
>> Larry
>> Sent: 2010年6月30日 17:38
>> used with
>> support

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 1 Jul 2010 15:19:00 -0700

Dear Giles,
requirement to have the entropy label as BoS is, as I understand it,
to avoid additional label signaling and state. If PW label is not
BoS/EoS then PE implies that the next label is the entropy and simply
pops it. Now it's been suggested that after entropy there might be a
GAL. For such scenario an EI will be required. I don't see that this
path is better than PW CW.

Regards,
Greg

On Thu, Jul 1, 2010 at 2:03 PM, Giles Heron <[email-masked]> wrote:
> Sure, but that could be changed I suspect.  Logically you'd want OAM under
> the entropy label so you can test all paths, right?
>
> Sent from my iPhone
>
>>> If anything , there was consensus that there is no written statement that
>>> we
>>> ACH

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 1 Jul 2010 17:19:34 -0700

Hi Luca,

Note that many implementations drop PW packets with GAL label as error packets.

Thanks,
Shahram

From: [email-masked] [mailto:[email-masked]] On Behalf Of Luca Martini
Sent: Wednesday, June 30, 2010 8:23 PM
To: Andrew G. Malis
Cc: [email-masked]; [email-masked]; HUANG Feng F; [email-masked]
Subject: Re: [mpls-tp] [PWE3] Proposal of using GAL for PW

Andy,

Luca

Andrew G. Malis wrote:

Larry and Feng,

Ethernet.

Cheers,

Andy

<[email-masked]><mailto:[email-masked]> wrote:

4.6.  The Control Word

xxxx

  control word present.

xxxx

B.R.

Feng Huang

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

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Larry

Sent: 2010年6月30日 17:38

To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Cc: [email-masked]<mailto:[email-masked]>

Dear all:

Best regards,

                Han Li

Han Li, Ph.D

Fax: +86 10 63601087

MOBILE: 13501093385

pwe3 mailing list

[email-masked]<mailto:[email-masked]>

---

From: Pei Zhang(联通集团技术部) <[email-masked]>
Date: Fri, 2 Jul 2010 09:04:07 +0800

Hi, 

I agree with Han's proposal. The CW on many equipments is option in our network. 

Pei Zhang
Technology Department, 
China Unicom Network Communications Group Company Limited
Mobile: +86-15601359026
E-Mail: [email-masked]

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Larry
发送时间: 2010年6月30日 17:38
收件人: [email-masked]; [email-masked]
抄送: [email-masked]
主题: [mpls-tp] Proposal of using GAL for PW

Dear all:

Best regards,

                Han Li

---

From: [email-masked]
Date: Thu, 1 Jul 2010 21:05:13 -0400

Hi Huub and Luca,

I also support the use of GAL on the PW.  I think that this has two 
advantages:
It supports OAM in the PW with or without a CW.
As Luca and Huub point out below, it makes the OAM processing uniform for 
LSPs and PW, this gives the additional benefit of simplifying the task of 
detecting miss connections between LSPs and PWs (as pointed out by Neil 
Harrison).

Regards,

Malcolm

Huub van Helvoort <[email-masked]> 
Sent by: [email-masked]
01/07/2010 03:39 AM
Please respond to
[email-masked]

To
Luca Martini <[email-masked]>
cc
[email-masked], [email-masked]
Subject
Re: [mpls-tp] [PWE3] Proposal of using GAL for PW

Ciao Luca,

I agree with this.

I  support this

Best regards, Huub.

>>>      In section 4.2 in RFC5586, it is defined that GAL MUST NOT be 
used with PWs in MPLS-TP. The PWE3 control word [RFC4385] MUST be present 
when the ACH is used to realize the associated control channel.

---

From: [email-masked]
Date: Fri, 2 Jul 2010 09:13:25 +0800

hi,all
i think that cw should be option part ,
we should consider to be compatible with old equipments
 
best regards
liu

"Shahram Davari" <[email-masked]> 
发件人:  [email-masked]
2010-07-02 01:08

收件人
"Thomas D. Nadeau" <[email-masked]>, "Giles Heron" 
<[email-masked]>, "Luca Martini" <[email-masked]>, "Andrew G. 
(Andy) Malis" <[email-masked]>
抄送
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>, HUANG Feng F <[email-masked]>, 
"[email-masked]" <[email-masked]>
主题
Re: [mpls-tp] [PWE3]   Proposal of using GAL for PW

Hi,
 
I agree with Andy and Tom. The best way forward is to mandate control word 
(VVCV Type 1) for future implementations, rather than introduce VCCV Type 
4.
 
Thanks,
Shahram
 
From: [email-masked] [mailto:[email-masked]] On Behalf 
Of Thomas D. Nadeau

Many CPs have deployed PWs with no CW.   Adding a CW to all packets just 
to enable occasional OAM messages seems like overkill.

TOM: The question would be in those cases: do those CPs have multi-vendor 
implementations and how difficult is it for them to handle operational 
issues as well as interoperability of those implementations?  The 
operators that have presented/discussed this at the last PWE3 meeting 
seemed to voice a resounding desire to have a consistent method rather 
than 3, 4 or N options.

But the downside of adding GAL is that it’s a fourth OAM mode for PWEs 
(back to your point about interoperability).  Too many options!

TOM: Precisely the point of requiring one way to do things.  Too many 
options is ok to get the kinks worked out of implementations, but going 
forward it seems better to narrow things as Andy’s original note 
asserted.

    --Tom

Giles

    I  agree with Andy’s assertion. This service provider’s experience 
is that making the CW mandatory going forward (and hopefully retrofitting 
existing PW protocol specs) would improve implementation interoperability.

    --Tom

I have to disagree that there was any consensus about this issue.
If anything , there was consensus that there is no written statement that 
we must  to use the CW in MPLS-TP.

At the end we needed more input from service providers that have deployed 
PWs.  The point is not whether there is hardware support for the CW, but 
whether we even want to use it in many cases where it adds absolutely no 
value. For example ATM PWs in cell mode , where it add almost 10% overhead 
with no benefit. Another case where the CW is not useful is the ethernet 
PW without network link load balancing, where we add 4 bytes to every 
packet just to occasionally send a status , or OAM message.

I would like to propose update the rfc5586 to allow the use of the GAL in 
PWs without the CW.

Luca

Andrew G. Malis wrote: 

Larry and Feng,

Cheers,
Andy

On Wed, Jun 30, 2010 at 6:34 AM, HUANG Feng F
<[email-masked]> <
mailto:[email-masked]>  wrote:

4.6.  The Control Word

xxxx

B.R.
Feng Huang

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of 
Larry
Sent: 2010年6月30日 17:38
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [PWE3] Proposal of using GAL for PW

Dear all:

Best regards,

                Han Li

 

 

 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 1 Jul 2010 18:27:25 -0700

Dear Malcolm and All,
would use of GAL on the PWs deprecate VCCV then? Or VCCV will remain
for PWs that are required to use CW? I'm concern if we're adding
another option then vendors will have to support both mechanisms and,
most worrisome to me, interwork between them.

Regards,
Greg

2010/7/1 <[email-masked]>
>
> Hi Huub and Luca,
>
> I also support the use of GAL on the PW.  I think that this has two advantages:
> As Luca and Huub point out below, it makes the OAM processing uniform for LSPs and PW, this gives the additional benefit of simplifying the task of detecting miss connections between LSPs and PWs (as pointed out by Neil Harrison).
>
> Regards,
>
> Malcolm
>
>
>
>

---

From: [email-masked]
Date: Fri, 2 Jul 2010 09:35:39 +0800

Yes，I also support the use of GAL on the PW considering that a CW is
optional in PW.

Jian

                                                                           
             Pei Zhang(联通                                                
             集团技术部)                                                   
             <hq-zhangp@chi                                         收件人 
             naunicom.cn>           "Larry" <[email-masked]>,     
             发件人:                <[email-masked]>, <[email-masked]>    
             mpls-tp-bounce                                           抄送 
             [email-masked]             [email-masked]                  
                                                                      主题 
                                    [mpls-tp] 答复:  Proposal of using GAL 
             2010-07-02             for PW                                 
             09:04                                                         

Hi,

I agree with Han's proposal. The CW on many equipments is option in our
network.

Pei Zhang
Technology Department,

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表
Larry
发送时间: 2010年6月30日 17:38
收件人: [email-masked]; [email-masked]
抄送: [email-masked]
主题: [mpls-tp] Proposal of using GAL for PW

Dear all:

Best regards,

                Han Li

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 2 Jul 2010 08:14:33 +0300

Hi all,
It seems that GAL, as a technique for identifying OAM packets, could be problematic in MPLS (not MPLS-TP1) environments with enabled ECMP. OAM packets would not necessarily be fate-sharing with the user packets.
Do I miss something?

Regards,
     Sasha

________________________________
From: [email-masked] [[email-masked]] On Behalf Of Shahram Davari [[email-masked]]
Sent: Friday, July 02, 2010 3:19 AM
To: Luca Martini; Andrew G. Malis
Cc: [email-masked]; [email-masked]; HUANG Feng F; [email-masked]
Subject: Re: [mpls-tp] [PWE3] Proposal of using GAL for PW

Hi Luca,

Thanks,
Shahram

Andy,

Luca

Andrew G. Malis wrote:

Larry and Feng,

Ethernet.

Cheers,

Andy

4.6.  The Control Word

xxxx

  control word present.

xxxx

B.R.

Feng Huang

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

Sent: 2010年6月30日 17:38

Dear all:

Best regards,

                Han Li

Han Li, Ph.D

Fax: +86 10 63601087

MOBILE: 13501093385

pwe3 mailing list

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 02 Jul 2010 10:24:15 +0100

> !mmm so if one used entropy then they can’t have OAM?

Not so. The GAL goes above the entropy label (S=0), so gets parsed
first. This works for both PHP and not PHP, and both LSP and PW.

- Stewart

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 2 Jul 2010 10:41:39 -0700

Dear Stewart,
if use of the entropy label implies non-MPLS-TP environment, then this
scenario is outside of scope of RFC 5586 and location of GAL on the
label stack is up for specification. In case if use of entropy label
in MPLS-TP network is expected we have second proposed to RFC 5586
change (first - to change that GAL mast not be used on PWs in MPLS-TP
network).

Regards,
Greg

2010/7/2 Stewart Bryant <[email-masked]>:
> Not so. The GAL goes above the entropy label (S=0), so gets parsed first.
> This works for both PHP and not PHP, and both LSP and PW.
>
> - Stewart
>
>
>
>
>

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 02 Jul 2010 23:16:52 +0100

Greg

Correct, a ST document would need to update RFC5586.

Stewart

On 02/07/2010 18:41, Greg Mirsky wrote:
> 2010/7/2 Stewart Bryant<[email-masked]>:
>    

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: "BUSI, ITALO (ITALO)" <[email-masked]>
Date: Mon, 5 Jul 2010 10:17:18 +0200

I agree with Stewart.

The GAL MUST be at the BoS in MPLS-TP where ECMP is not applicable and entroy labels MUST NOT be used.

In other MPLS environments (e.g., where entropy labels are used), RFC 5886 does not place any restriction on the position of the GAL within the label stack.

Italo

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: venerdì 2 luglio 2010 11.24
To: Shahram Davari
Cc: Andy Malis; [email-masked]; [email-masked]; [email-masked]; HUANG, Feng F (Feng)
Subject: Re: [mpls-tp] [PWE3] Proposal of using GAL for PW

Not so. The GAL goes above the entropy label (S=0), so gets parsed first. This works for both PHP and not PHP, and both LSP and PW.

- Stewart

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 5 Jul 2010 11:38:41 +0300

Hi all,
IMHO and FWIW, while RFC 5586  (5886 looks like a typo to me) does not place any restrictions on using GAL in non-TP environments, its usefulness in these environments (where various forms of multipath, including usage of entropy labels,  cannot be precluded) for OAM purposes is somewhat problematic:
Adding GAL to the label stack changes this for the multipath mechanisms based on stack hashing, and fate-sharing of OAM and user traffic packets is not guaranteed any more.

My 2c,
     Sasha

From: [email-masked] [mailto:[email-masked]] On Behalf Of BUSI, ITALO (ITALO)
Sent: Monday, July 05, 2010 11:17 AM
To: [email-masked]; Shahram Davari
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [PWE3] [mpls-tp] Proposal of using GAL for PW

I agree with Stewart.

Italo

- Stewart

---

From: "BUSI, ITALO (ITALO)" <[email-masked]>
Date: Mon, 5 Jul 2010 14:28:47 +0200

Sasha,

what you say is correct but it is applicable to any environment where you use OAM together with ECMP. I do not see anything specific with GAL and PW.

Italo

________________________________
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: lunedì 5 luglio 2010 10.39
To: BUSI, ITALO (ITALO); [email-masked]; Shahram Davari
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [PWE3] [mpls-tp] Proposal of using GAL for PW

Hi all,

My 2c,
     Sasha

I agree with Stewart.

Italo

- Stewart

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 5 Jul 2010 15:41:34 +0300

Italo,
Lots of thanks for a prompt response. However, IMHO it is not correct.

E.g., BFD for MPLS LSP (as defined RFC 5884) and BFD in VCCV (as defined in RFC 5885) will provide correct connectivity failure indications regardless of ECMP based on MPLS stack hashing because the same label stack will be used by user traffic and OAM packets.

Do you think I've missed something?

Regards,
     Sasha

From: BUSI, ITALO (ITALO) [mailto:[email-masked]]
Sent: Monday, July 05, 2010 3:29 PM
To: Alexander Vainshtein; [email-masked]; Shahram Davari
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [PWE3] [mpls-tp] Proposal of using GAL for PW

Sasha,

Italo

My 2c,
     Sasha

I agree with Stewart.

Italo

- Stewart

---

From: "HUANG Feng F" <[email-masked]>
Date: Tue, 6 Jul 2010 16:01:10 +0800

Dear Sasha,
   In MPLS-TP transport network environment, because it is strict connected oriented, ECMP is not supported.
B.R.
Feng

From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: 2010年7月5日 20:42
To: BUSI ITALO
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [PWE3] [mpls-tp] Proposal of using GAL for PW

Italo,

Do you think I’ve missed something?

Regards,

     Sasha

Sasha,

Italo

	Hi all,

	My 2c,

	     Sasha

	I agree with Stewart.

	Italo

		-SD

		- Stewart

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 6 Jul 2010 11:50:25 +0300

Dear Feng,
Lots of thanks for a comment. I fully agree with you that it is safe to use GAL for OAM in MPLS-PT environments because disallow usage of any form of ECMP is explicitly disallowed there.

What I have been trying to explain is that in more generic MPLS environments GAL-based OAM is not necessarily fate-sharing with the user traffic., while other OAM techniques are not affected by ECMP.

To me this is one more reason not to use GAL for PW OAM.

Regards,
     Sasha

From: HUANG Feng F [mailto:[email-masked]]
Sent: Tuesday, July 06, 2010 11:01 AM
To: Alexander Vainshtein; BUSI ITALO
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [PWE3] [mpls-tp] Proposal of using GAL for PW

Dear Sasha,

Regards,
     Sasha

Sasha,

Italo

My 2c,
     Sasha

I agree with Stewart.

Italo

- Stewart

---

From: Luca Martini <[email-masked]>
Date: Tue, 06 Jul 2010 08:55:14 -0600

BUSI, ITALO (ITALO) wrote:
> In other MPLS environments (e.g., where entropy labels are used), RFC 
> 5886 does not place any restriction on the position of the GAL within 
> the label stack.
>
Where does it say that Entropy labels must not be used in MPLS-TP ?
( not that they are useful at all in MPLS-TP , but in a mixed network 
maybe....)

Luca

> Italo
>
>     ------------------------------------------------------------------------
>     *From:* [email-masked] [mailto:[email-masked]]
>     *On Behalf Of *Stewart Bryant
>     *Sent:* venerdì 2 luglio 2010 11.24
>     *To:* Shahram Davari
>     *Cc:* Andy Malis; [email-masked]; [email-masked];
>     [email-masked]; HUANG, Feng F (Feng)
>     *Subject:* Re: [mpls-tp] [PWE3] Proposal of using GAL for PW
>
> ------------------------------------------------------------------------
>