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

[Greg Mirsky <[e-mail]>]

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 <[e-mail]> 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
>
> On 1 Jul 2010, at 21:25, Greg Mirsky <[e-mail]> wrote:
>
>> 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 <[e-mail]>om>:
>>>
>>> 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
>>>
>>>
>>> On 01/07/2010 19:35, "Shahram Davari" <[e-mail]> wrote:
>>>
>>> !mmm so if one used entropy then they can't have OAM?
>>>
>>> -SD
>>>
>>>
>>> From: Giles Heron [mailto:[e-mail]]
>>> Sent: Thursday, July 01, 2010 11:32 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
>>>
>>> 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
>>>
>>>
>>> _______________________________________________
>>> pwe3 mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/pwe3
>>>
>>>
>