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

[Giles Heron <[e-mail]>]

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" <[e-mail]> 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
>  
> 
> From: Giles Heron [mailto:[e-mail]]
> Sent: Thursday, July 01, 2010 11:10 AM
> To: Shahram Davari; Tom Nadeau; Luca Martini; Andy Malis
> Cc: [e-mail]; [e-mail]; HUANG Feng F; [e-mail]
> 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.
> 
> 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" <[e-mail]> 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
>  
> 
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Giles Heron
> Sent: Thursday, July 01, 2010 6:22 AM
> To: Tom Nadeau; Luca Martini; Andy Malis
> Cc: [e-mail]; [e-mail]; HUANG Feng F; [e-mail]
> Subject: Re: [mpls-tp] [PWE3] Proposal of using GAL for PW
> 
> 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" <[e-mail]> 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
> 
> 
> 
> On 6/30/10 11:22 PM, "Luca Martini" <[e-mail]> wrote:
> 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
> <[e-mail]> <mailto:[e-mail]>
> 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: [e-mail] [mailto:[e-mail]] On Behalf Of Larry
> Sent: 2010年6月30日 17:38
> To: [e-mail]; [e-mail]
> Cc: [e-mail]
> 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: [phone]
> MOBILE: [phone]
> ********************************************************************
> 
>     
>  
> 
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3
> 
>   
>   
> 
> 
> 
> _______________________________________________
> mpls-tp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls-tp
> 
> 
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3
>