Subject: Re: [PWE3] Entropy/Flow and GAL (was:Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt)

From: Pablo Frank <[email-masked]>
Date: Thu, 4 Aug 2011 14:23:39 -0400

Curtis,

Why does it matter if the entropy/flow labels are above or below the GAL?
 What advantage is gained by putting such labels below the GAL?

To me, putting the GAL in-between the PW (or LSP) label and the Flow (or
Entropy) label just feels out of place.  I should only really care about a
GAL if I encounter it as a result of disposing of the labels either because
they've been popped or because the TTL has expired.  When the PW label gets
terminated and all of a sudden, I encounter a GAL, it seems awkward because
in my mind, I have not finished terminating the PW layer.  There is still
this flow label that I need to dispose of... so the hardware has to remember
that it saw a GAL and continue processing labels.  It seems much cleaner if
we finish dealing with the multipath labels before considering whether it's
carrying normal data or an associated channel.

If anything, I see an advantage in having the GAL below the flow label
because it allows the option of monitoring individual paths (assuming, of
course, that GAL is excluded from the hash).

regards,
Pablo

----- Original Message -----
> From: Curtis Villamizar [mailto:[email-masked]]
> Sent: Thursday, August 04, 2011 06:38 AM
> To: Shahram Davari
> Cc: [email-masked] <[email-masked]>; Giles Heron <
> [email-masked]>; Thomas Nadeau <[email-masked]>; Yaakov
> Stein <[email-masked]>; [email-masked] <[email-masked]>; Robert Rennison <
> [email-masked]>
> Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt
>
>
> In message <
> [email-masked]
> >
> "Shahram Davari" writes:
> >
> > Hi Curtis,
> >
> > Even if we assume this format (which is not yet incorporated in the
> > fat-pw draft), then most hardware assume ACH is right after GAL. In
> > this case how is the HW supposed to examine the ACH channel Type to
> > decide how to process the packet? (unless you assume there is one
> > engine that can process all OAM packet types such as BFD, AIS, PSC,
> > LSP-ping, LDI, LKR, LM, DM, etc)
> >
> > Thx
> > Shahram
>
>
> Shahram,
>
> This doesn't need to go in the fat-pw draft.  It needs to go into the
> draft-nadeau-pwe3-vccv-2-02 draft because it only affects OAM traffic
> when some other feature, fat-pw or other, puts a label under the PW
> label.  The GAL goes after the PW and before the other labels.  A
> proper multipath distribution will skip any reserved label and use the
> rest of the label stack to load balance.  This allows spraying across
> the entropy space or testing a spacific payload label stack that has
> yielded trouble.
>
> Hardware that assumes ACH is right after GAL when the S-bit is not set
> on the GAL is broken.
>
> The payload (ACH) is after the BOS (aka S-bit = 1).
>
> The IETF has never been sympathetic of broken hardware and should not
> be since we would halt progress.
>
> If the hardware is broken, then the fat-pw label can be omitted but
> only one path through any multipath would be tested.  It would still
> work for TP, but not work in general.  PW does not require TP.  The
> fat-pw work is explicitly done for multipath because multipath is used
> a lot in deployed networks and isn't going away.
>
> Curtis
>
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Wednesday, August 03, 2011 4:53 PM
> > To: Shahram Davari
> > Cc: [email-masked]; Giles Heron; Thomas Nadeau; Yaakov Stein;
> [email-masked]; Robert Rennison
> > Subject: Re: [PWE3] Poll for WG adoption of
> draft-nadeau-pwe3-vccv-2-02.txt
> >
> >
> > In message <
> [email-masked]
> >
> > "Shahram Davari" writes:
> > >
> > > Hi Curtis,
> > >
> > > You are absolutely correct if there is no Entropy label. But with
> > > Entropy label most implementation assume a Entropy label to be BoS and
> > > below the PW label.
> > >
> > > This draft doesn't even talk about whether the GAL should be BoS or
> > > the Entropy Label? In either case adding GAL would make the packet
> > > un-parsable by most HW.
> > >
> > > Thx
> > > Shahram
> >
> >
> > That should be covered in this work.  At least it was covered in WG
> > email.  PW, then GAL, then fat-pw (aka Flow label, which is different
> > from Entropy label in MPLS).
> >
> > 0                   1                   2                   3
> > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |                            PW Label                           |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |                              GAL                              |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |     ... additional labels (ie: fat-pw) may be present         |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |0 0 0 1|Version|   Reserved    |  Associated Channel Type      |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |                                                               |
> > ~                        VCCV Message Body                      ~
> > |                                                               |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> > The above would be a better choice.  The VCCV is always after the
> > label entry with BOS (S-bit = 1).
> >
> > The flow label (or entropy label) must not be a reserved label.
> > Therefore there is no ambiguity.  In draft-ietf-pwe3-fat-pw-07 section
> > 1.2 (page 5) you will find.
> >
> >    Note that the flow label MUST NOT be an MPLS reserved label (values
> >    in the range 0..15) [RFC3032], but is otherwise unconstrained by the
> >    protocol.
> >
> >
> > The flow label below GAL is needed so that all data paths which the PW
> > can take are exercised by OAM (ie: LSP Ping used within VCCV).
> >
> > Curtis
> >
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]
> > > Sent: Wednesday, August 03, 2011 4:05 PM
> > > To: Shahram Davari
> > > Cc: Giles Heron; Thomas Nadeau; Yaakov Stein; [email-masked]; Robert
> Rennison
> > > Subject: Re: [PWE3] Poll for WG adoption of
> draft-nadeau-pwe3-vccv-2-02.txt
> > >
> > >
> > > In message <
> [email-masked]
> >
> > > "Shahram Davari" writes:
> > > >
> > > > Giles,
> > > >
> > > > Adding GAL to PW requires HW change, so why not just add CW and use
> > > > VVCV Type 1?  Also what is wrong with TTL approach for non-CW?
> > > >
> > > > Thx
> > > > Shahram
> > >
> > >
> > > Shahram,
> > >
> > > Adding GAL to an MPLS label stack requires hardware support.  The
> > > hardware need not know if the label above the GAL is an MPLS label or
> > > a PW label, just that the next label is GAL and the label over it is
> > > not a SWAP.  Unless we are talking about incredibly inflexible parser
> > > hardware, like none I've encounted recently, there should be no
> > > problem noticing a GAL below the POP or PW label and then directing
> > > the packet to OAM processing.  Any remaining labels must be removed
> > > and hopefully no implementation neglects to look for BOS before
> > > deciding where the payload is supposed to be.
> > >
> > > TTL is best reserved for traceroute only (in the MS-PW case).  In this
> > > case TTL-expire would occur where a label swap was called for and a
> > > GAL would be below the label containing the expired TTL.  Since LDP
> > > can have transient loops, this avoids having lots of packets sent to
> > > the OAM engine should such a loop occur in a LDP signaled MPLS PSN.
> > >
> > > This yield one way to do OAM with or without CW.  A GAL label is below
> > > the label for which action is taken (POP or PW termination) or below a
> > > label for which TTL has expired.  This method applied to LSP and PW.
> > >
> > > I think mandating CW would be just as good a solution, but one that
> > > was rejected so this is the best we have.
> > >
> > > Curtis
> > >
> > >
> > > > -----Original Message-----
> > > > From: Giles Heron [mailto:[email-masked]]
> > > > Sent: Wednesday, August 03, 2011 11:10 AM
> > > > To: Thomas Nadeau; Shahram Davari
> > > > Cc: [email-masked]; Yaakov Stein; Robert Rennison
> > > > Subject: Re: [PWE3] Poll for WG adoption of
> draft-nadeau-pwe3-vccv-2-02.txt
> > > >
> > > > Agreed - some operators won't want to use a CW, and on that basis I
> support
> > > > this draft.
> > > >
> > > > Sure, it'll take a while to move away from the router alert label and
> TTL
> > > > approaches, but the GAL approach is definitely better than either of
> > > > those...
> > > >
> > > > Giles
> > > >
> > > > On 02/08/2011 12:59, "Thomas Nadeau" <[email-masked]>
> wrote:
> > > >
> > > > >
> > > > > On Aug 1, 2011, at 6:28 PM, Shahram Davari wrote:
> > > > >
> > > > >> Hi,
> > > > >>
> > > > >> I also don¹t support this draft since I don¹t think to solve the
> problem we
> > > > >> need yet a 4th type of VCCV. The best solution is to mandate CW.
> > > > >
> > > > > While I am with you, that argument went out the window during the
> debates we
> > > > > had over the past 3 IETF meetings. Operators
> > > > > were very clear that they do not want to mandate the use of a CW.
> Hence,
> > > > > Luca and I came up with this solution that narrows the
> > > > > scope to 2 modes, one that handles the CW case and one that doesn't
> while
> > > > > still both modes providing predictable OAM capabilities
> > > > > for the PW.
> > > > >
> > > > > --Tom
> > > > >
> > > > >
> > > > >>
> > > > >> Shahram
> > > > >>
> > > > >> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of
> > > > >> Robert Rennison
> > > > >> Sent: Sunday, July 31, 2011 7:40 PM
> > > > >> To: Alexander Vainshtein; Yaakov Stein; Bocci, Matthew (Matthew);
> > > > >> [email-masked]
> > > > >> Subject: Re: [PWE3] Poll for WG adoption of
> draft-nadeau-pwe3-vccv-2-02.txt
> > > > >>
> > > > >> I do Not support the draft,
> > > > >>
> > > > >> After hearing the results of the earlier user deployment  poll I
> thought,
> > > > >> ³ ok  the way out of this mess is to migrate towards using the
> CW². Then I
> > > > >> see this proposal and wondered what am I missing.  I¹ve still not
> seen the
> > > > >> light of why adding a fourth type will simplify matters, hence in
> the absence
> > > > >> of me understanding how this will simplify matter versus
> complicate things,
> > > > >> I¹m against it.
> > > > >>
> > > > >> Rob
> > > > >>
> > > > >> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of
> > > > >> Alexander Vainshtein
> > > > >> Sent: Sunday, July 31, 2011 12:45 AM
> > > > >> To: Yaakov Stein; Bocci, Matthew (Matthew); [email-masked]
> > > > >> Subject: Re: [PWE3] Poll for WG adoption of
> draft-nadeau-pwe3-vccv-2-02.txt
> > > > >>
> > > > >> Hi all,
> > > > >> I do NOT support this draft for the same reasons that Yaakov has
> indicated.
> > > > >>
> > > > >> Regards,
> > > > >>      Sasha
> > > > >>
> > > > >> From: [email-masked] [[email-masked]] On Behalf Of
> Yaakov Stein
> > > > >> [[email-masked]]
> > > > >> Sent: Friday, July 29, 2011 3:58 AM
> > > > >> To: Bocci, Matthew (Matthew); [email-masked]
> > > > >> Subject: Re: [PWE3] Poll for WG adoption of
> draft-nadeau-pwe3-vccv-2-02.txt
> > > > >>
> > > > >> I do not support !    and I can not understand how anyone can
> support it !
> > > > >>
> > > > >> We do NOT need a fourth VCCV type, there are too many already.
> > > > >>
> > > > >> I completely agree with the part that says if there is a CW then
> the ACh
> > > > >> should be marked by it.
> > > > >>
> > > > >> I do NOT agree that if the CW is not used then we should use a
> non-PW method
> > > > >> developed for MPLS-TP.
> > > > >> I do NOT agree that there is any way to deprecate the use of TTL
> expiry to
> > > > >> mark the ACh.
> > > > >> I do NOT agree that we should change mechanisms that have been
> widely
> > > > >> deployed for many years now,
> > > > >> without an extremely pressing reason.
> > > > >>
> > > > >> Were the proposal to be that for PWs that traverse ONLY MPLS-TP to
> have the
> > > > >> ADDITIONAL option
> > > > >> for ACh marking, I might be convinced not to object as strongly.
> > > > >> However, since I don't think that PWs can be limited in this
> matter (the MPLS
> > > > >> WG adopted the "seamless" draft)
> > > > >> it would be difficult to convince me that such a limitation is
> possible.
> > > > >>
> > > > >> I would have enthusiastically support this proposal had it been
> brought 8
> > > > >> years ago.
> > > > >> It's too late for this now.
> > > > >>
> > > > >> Y(J)S
> > > > >>
> > > > >> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of
> > > > >> Bocci, Matthew (Matthew)
> > > > >> Sent: Thursday, July 28, 2011 21:02
> > > > >> To: [email-masked]
> > > > >> Subject: [PWE3] Poll for WG adoption of
> draft-nadeau-pwe3-vccv-2-02.txt
> > > > >>
> > > > >> This email begins a two week poll to help assess if there is
> consensus to
> > > > >> adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group
> draft.
> > > > >>
> > > > >> Please indicate whether or not you support adoption of this draft,
> and also
> > > > >> send any comments to the PWE3 list.
> > > > >>
> > > > >> This poll will end on Friday 12th August.
> > > > >>
> > > > >> Regards,
> > > > >>
> > > > >> Matthew & Andy
> > > > >> This e-mail message is intended for the recipient only and
> contains
> > > > >> information which is CONFIDENTIAL and which may be proprietary to
> ECI
> > > > >> Telecom. If you have received this transmission in error, please
> inform us by
> > > > >> e-mail, phone or fax, and then delete the original and all copies
> thereof.
> > > > >> This e-mail message is intended for the recipient only and
> contains
> > > > >> information which is CONFIDENTIAL and which may be proprietary to
> ECI
> > > > >> Telecom. If you have received this transmission in error, please
> inform us by
> > > > >> e-mail, phone or fax, and then delete the original and all copies
> thereof.
>
>
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3
>

---

From: John E Drake <[email-masked]>
Date: Thu, 4 Aug 2011 11:36:43 -0700

Pablo,

At least wrt entropy label, the reasons why it needs to be at the bottom of stack are detailed in the draft in some detail.  The GAL is in exactly the same place in the stack relative to the labels above it whether or not the entropy label is used.  The fact that the bottom of stack bit is not set in the GAL tells the egress that an entropy label is present in the stack after it and needs to be discarded.l

Thanks,

John

Sent from my iPhone

From: [email-masked] [mailto:[email-masked]] On Behalf Of Pablo Frank
Sent: Thursday, August 04, 2011 11:24 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [PWE3] Entropy/Flow and GAL (was:Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt)

Curtis,

Why does it matter if the entropy/flow labels are above or below the GAL?  What advantage is gained by putting such labels below the GAL?

To me, putting the GAL in-between the PW (or LSP) label and the Flow (or Entropy) label just feels out of place.  I should only really care about a GAL if I encounter it as a result of disposing of the labels either because they've been popped or because the TTL has expired.  When the PW label gets terminated and all of a sudden, I encounter a GAL, it seems awkward because in my mind, I have not finished terminating the PW layer.  There is still this flow label that I need to dispose of... so the hardware has to remember that it saw a GAL and continue processing labels.  It seems much cleaner if we finish dealing with the multipath labels before considering whether it's carrying normal data or an associated channel.

If anything, I see an advantage in having the GAL below the flow label because it allows the option of monitoring individual paths (assuming, of course, that GAL is excluded from the hash).

regards,
Pablo

----- Original Message -----
From: Curtis Villamizar [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, August 04, 2011 06:38 AM
To: Shahram Davari
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Giles Heron <[email-masked]<mailto:[email-masked]>>; Thomas Nadeau <[email-masked]<mailto:[email-masked]>>; Yaakov Stein <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Robert Rennison <[email-masked]<mailto:[email-masked]>>
Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt

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

Shahram,

Curtis

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
> Cc: [email-masked]<mailto:[email-masked]>; Giles Heron; Thomas Nadeau; Yaakov Stein; [email-masked]<mailto:[email-masked]>; Robert Rennison
> In message <[email-masked]<mailto:[email-masked]>>
> "Shahram Davari" writes:
> >
> > Hi Curtis,
> >
> > From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
> > Cc: Giles Heron; Thomas Nadeau; Yaakov Stein; [email-masked]<mailto:[email-masked]>; Robert Rennison
> > In message <[email-masked]<mailto:[email-masked]>>
> > "Shahram Davari" writes:
> > >
> > > Giles,
> > >
> > > From: Giles Heron [mailto:[email-masked]<mailto:[email-masked]>]
> > > Cc: [email-masked]<mailto:[email-masked]>; Yaakov Stein; Robert Rennison
> > > Agreed - some operators won't want to use a CW, and on that basis I support
> > > this draft.
> > >
> > > Sure, it'll take a while to move away from the router alert label and TTL
> > > On 02/08/2011 12:59, "Thomas Nadeau" <[email-masked]<mailto:[email-masked]>> wrote:
> > >
> > > >
> > > >> I also don¹t support this draft since I don¹t think to solve the problem we
> > > > While I am with you, that argument went out the window during the debates we
> > > > were very clear that they do not want to mandate the use of a CW.   Hence,
> > > > scope to 2 modes, one that handles the CW case and one that doesn't while
> > > >> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
> > > >> Robert Rennison
> > > >> [email-masked]<mailto:[email-masked]>
> > > >> After hearing the results of the earlier user deployment  poll I thought,
> > > >> ³ ok  the way out of this mess is to migrate towards using the CW². Then I
> > > >> see this proposal and wondered what am I missing.  I¹ve still not seen the
> > > >> light of why adding a fourth type will simplify matters, hence in the absence
> > > >> of me understanding how this will simplify matter versus complicate things,
> > > >> I¹m against it.
> > > >>
> > > >> Rob
> > > >>
> > > >> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
> > > >> Alexander Vainshtein
> > > >> To: Yaakov Stein; Bocci, Matthew (Matthew); [email-masked]<mailto:[email-masked]>
> > > >> I do NOT support this draft for the same reasons that Yaakov has indicated.
> > > >>
> > > >> Regards,
> > > >>      Sasha
> > > >>
> > > >> From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] On Behalf Of Yaakov Stein
> > > >> [[email-masked]<mailto:[email-masked]>]
> > > >> To: Bocci, Matthew (Matthew); [email-masked]<mailto:[email-masked]>
> > > >> I do not support !    and I can not understand how anyone can support it !
> > > >>
> > > >> I completely agree with the part that says if there is a CW then the ACh
> > > >> should be marked by it.
> > > >>
> > > >> I do NOT agree that if the CW is not used then we should use a non-PW method
> > > >> developed for MPLS-TP.
> > > >> I do NOT agree that there is any way to deprecate the use of TTL expiry to
> > > >> mark the ACh.
> > > >> I do NOT agree that we should change mechanisms that have been widely
> > > >> Were the proposal to be that for PWs that traverse ONLY MPLS-TP to have the
> > > >> ADDITIONAL option
> > > >> However, since I don't think that PWs can be limited in this matter (the MPLS
> > > >> it would be difficult to convince me that such a limitation is possible.
> > > >>
> > > >> I would have enthusiastically support this proposal had it been brought 8
> > > >> years ago.
> > > >> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
> > > >> Bocci, Matthew (Matthew)
> > > >> To: [email-masked]<mailto:[email-masked]>
> > > >> Subject: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt
> > > >>
> > > >> This email begins a two week poll to help assess if there is consensus to
> > > >> adopt draft-nadeau-pwe3-vccv-2-02.txt as a PWE3 working group draft.
> > > >>
> > > >> Please indicate whether or not you support adoption of this draft, and also
> > > >> This e-mail message is intended for the recipient only and contains
> > > >> information which is CONFIDENTIAL and which may be proprietary to ECI
> > > >> Telecom. If you have received this transmission in error, please inform us by
> > > >> e-mail, phone or fax, and then delete the original and all copies thereof.
> > > >> This e-mail message is intended for the recipient only and contains
> > > >> information which is CONFIDENTIAL and which may be proprietary to ECI
> > > >> Telecom. If you have received this transmission in error, please inform us by
> > > >> e-mail, phone or fax, and then delete the original and all copies thereof.

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

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 04 Aug 2011 22:53:55 -0400

In message <[email-masked]>
Pablo Frank writes:
>  
> Curtis,
>  
> Why does it matter if the entropy/flow labels are above or below the
>  GAL?  What advantage is gained by putting such labels below the GAL?

The purpose of the GAL is to drive OAM processing.  On a PW only the
label immediately below the GAL has to be inspected, not all labels
between the PW and BOS, except to find the last label with S=0.

On an LSP there may be many labels before the BOS, so every label
would have to be searched for GAL on every packet.

Always putting GAL below the label being acted on immediately
identifies the OAM context (the label above the GAL indicates the OAM
context).

> To me, putting the GAL in-between the PW (or LSP) label and the Flow
> (or Entropy) label just feels out of place.  I should only really care
> about a GAL if I encounter it as a result of disposing of the labels
> either because they've been popped or because the TTL has expired.
> When the PW label gets terminated and all of a sudden, I encounter a
> GAL, it seems awkward because in my mind, I have not finished
> terminating the PW layer.  There is still this flow label that I need
> to dispose of... so the hardware has to remembe= r that it saw a GAL
> and continue processing labels.  It seems much cleaner if we finish
> dealing with the multipath labels before considering whether it's
> because it allows the option of monitoring individual paths (assuming,
> of course, that GAL is excluded from the hash).

You can monitor individual paths.  The hash has to skip over reserved
labels, not terminate on reserved labels.

If you are doing this, then the position in the label stack of the GAL
indicates the context of the OAM.

> > Stein <[email-masked]>; [email-masked] <[email-masked]>; Robert Rennison =
> <
> > Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.t=
> xt
> >
> >
> > In message <
> > [email-masked]=
> om
> > >
> > "Shahram Davari" writes:
> > >
> > > Hi Curtis,
> > >
> > The payload (ACH) is after the BOS (aka S-bit =3D 1).
> >
> > [email-masked]=
> om
> > >
> > > "Shahram Davari" writes:
> > > >
> > > > Hi Curtis,
> > > >
> > > > Entropy label most implementation assume a Entropy label to be BoS an=
> d
> > > > below the PW label.
> > > >
> > > label entry with BOS (S-bit =3D 1).
> > >
> > [email-masked]=
> om
> > >
> > > > "Shahram Davari" writes:
> > > > >
> > > > > Giles,
> > > > >
> > > > TTL is best reserved for traceroute only (in the MS-PW case).  In thi=
> s
> > > > This yield one way to do OAM with or without CW.  A GAL label is belo=
> w
> > > > the label for which action is taken (POP or PW termination) or below =
> a
> > > > > Sure, it'll take a while to move away from the router alert label a=
> nd
> > TTL
> > > > > approaches, but the GAL approach is definitely better than either o=
> f
> > > > > those...
> > > > >
> > > > > Giles
> > > > >
> > > > > >> I also don=B9t support this draft since I don=B9t think to solve=
>  the
> > problem we
> > > > > > scope to 2 modes, one that handles the CW case and one that doesn=
> 't
> > while
> > > > > >> To: Alexander Vainshtein; Yaakov Stein; Bocci, Matthew (Matthew)=
> ;
> > > > > >> [email-masked]
> > > > > >> =B3 ok  the way out of this mess is to migrate towards using the
> > CW=B2. Then I
> > > > > >> see this proposal and wondered what am I missing.  I=B9ve still =
> not
> > seen the
> > > > > >> light of why adding a fourth type will simplify matters, hence i=
> n
> > the absence
> > > > > >> I=B9m against it.
> > > > > >> Were the proposal to be that for PWs that traverse ONLY MPLS-TP =
> to
> > have the
> > > > > >> ADDITIONAL option
> > > > > >> Please indicate whether or not you support adoption of this draf=
> t,
> > and also
> > > > > >> information which is CONFIDENTIAL and which may be proprietary t=
> o
> > ECI
> > > > > >> e-mail, phone or fax, and then delete the original and all copie=
> s
> > thereof.
> > > > > >> information which is CONFIDENTIAL and which may be proprietary t=
> o
> > ECI
> > > > > >> e-mail, phone or fax, and then delete the original and all copie=
> s
> > thereof.

---

From: Pablo Frank <[email-masked]>
Date: Fri, 5 Aug 2011 12:01:34 -0400

So I read the draft but could not see the justification.  In fact, I believe
there's actually a flaw with what's proposed.

Section 6 (OAM and Entropy Labels) suggests that by setting S=0 and placing
the GAL above the entropy label, that this makes it "effectively function as
an application label".  But this is not so.  The GAL is an extra label that
would normally sit below the application label.  Application labels that are
expecting entropy labels are identified in your proposal either explicitly
in the LFIB or implicitly by the presence of an ELI after the AL.  In either
case, it's the label(s) above the GAL that trigger entropy label handling,
not the GAL itself.

Then following the procedures in 4.3, the Egress LSR would inspect the S bit
of the application/ELI label, and according to the text, would then pop the
next label, assuming it was an entropy label.  Unfortunately, you've now
popped the GAL and what's really left is the entropy label.

It seems to me that we've gotten here because the GAL and Entropy label both
want to be the BOS.  You've tried to get around it by relaxing the BOS
restriction on GAL but I think it works much more cleanly if you go the
other way.  Instead of saying that Entropy labels always need to be BOS, why
not simply say that they must immediately follow the application/ELI label?
 That way, the procedures in 4.3 always work trivially.  A router that does
not understand or expect entropy labels doesn't need to be confused by
strange labels following the GAL, and the hardware implementations likely
will be simpler (and cheaper).  It also means I can
build hierarchical multipath LSPs if I really want to... :-)

regards,
Pablo

On Thu, Aug 4, 2011 at 2:36 PM, John E Drake <[email-masked]> wrote:

> Pablo,****
>
> ** **
>
> At least wrt entropy label, the reasons why it needs to be at the bottom of
> stack are detailed in the draft in some detail.  The GAL is in exactly the
> same place in the stack relative to the labels above it whether or not the
> entropy label is used.  The fact that the bottom of stack bit is not set in
> the GAL tells the egress that an entropy label is present in the stack after
> it and needs to be discarded.l  ****
>
> ** **
>
> Thanks,****
>
> ** **
>
> John ****
>
> ** **
>
> Sent from my iPhone****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
> *Pablo Frank
> *Sent:* Thursday, August 04, 2011 11:24 AM
> *To:* [email-masked]
> *Cc:* [email-masked]; [email-masked]; [email-masked]
> *Subject:* Re: [PWE3] Entropy/Flow and GAL (was:Poll for WG adoption of
> draft-nadeau-pwe3-vccv-2-02.txt)****
>
> ** **
>
> Curtis,****
>
> ** **
>
>  What advantage is gained by putting such labels below the GAL?****
>
> ** **
>
> carrying normal data or an associated channel.  ****
>
> ** **
>
> course, that GAL is excluded from the hash).****
>
> ** **
>
> regards,****
>
> Pablo****
>
> ** **
>
> https://www.ietf.org/mailman/listinfo/pwe3****
>
> ** **
>

---

From: John E Drake <[email-masked]>
Date: Fri, 5 Aug 2011 09:50:54 -0700

An application label is a label in which you expect to see BOS set but which isn't, followed by an entropy label which is a non-reserved label with BOS set.  Repeat as necessary.

As both Curtis and I have said, in order to process the GAL payload correctly, the stack above the GAL should be the same whether or not an entropy label is present.

Sent from my iPhone

From: Pablo Frank [mailto:[email-masked]]
Sent: Friday, August 05, 2011 9:02 AM
To: John E Drake
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [PWE3] Entropy/Flow and GAL (was:Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt)

So I read the draft but could not see the justification.  In fact, I believe there's actually a flaw with what's proposed.

Section 6 (OAM and Entropy Labels) suggests that by setting S=0 and placing the GAL above the entropy label, that this makes it "effectively function as an application label".  But this is not so.  The GAL is an extra label that would normally sit below the application label.  Application labels that are expecting entropy labels are identified in your proposal either explicitly in the LFIB or implicitly by the presence of an ELI after the AL.  In either case, it's the label(s) above the GAL that trigger entropy label handling, not the GAL itself.

Then following the procedures in 4.3, the Egress LSR would inspect the S bit of the application/ELI label, and according to the text, would then pop the next label, assuming it was an entropy label.  Unfortunately, you've now popped the GAL and what's really left is the entropy label.

It seems to me that we've gotten here because the GAL and Entropy label both want to be the BOS.  You've tried to get around it by relaxing the BOS restriction on GAL but I think it works much more cleanly if you go the other way.  Instead of saying that Entropy labels always need to be BOS, why not simply say that they must immediately follow the application/ELI label?  That way, the procedures in 4.3 always work trivially.  A router that does not understand or expect entropy labels doesn't need to be confused by strange labels following the GAL, and the hardware implementations likely will be simpler (and cheaper).  It also means I can build hierarchical multipath LSPs if I really want to... :-)

regards,
Pablo

On Thu, Aug 4, 2011 at 2:36 PM, John E Drake <[email-masked]<mailto:[email-masked]>> wrote:
Pablo,

Thanks,

John

Sent from my iPhone

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Pablo Frank
Sent: Thursday, August 04, 2011 11:24 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [PWE3] Entropy/Flow and GAL (was:Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt)

Curtis,

regards,
Pablo

----- Original Message -----
From: Curtis Villamizar [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, August 04, 2011 06:38 AM
To: Shahram Davari
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Giles Heron <[email-masked]<mailto:[email-masked]>>; Thomas Nadeau <[email-masked]<mailto:[email-masked]>>; Yaakov Stein <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Robert Rennison <[email-masked]<mailto:[email-masked]>>
Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt

Shahram,

Curtis

---

From: Pablo Frank <[email-masked]>
Date: Fri, 5 Aug 2011 16:27:43 -0400

Thanks John,

Some PF> questions/comments below:

On Fri, Aug 5, 2011 at 12:50 PM, John E Drake <[email-masked]> wrote:

> An application label is a label in which you expect to see BOS set but
> which isn’t, followed by an entropy label which is a non-reserved label with
> BOS set.  Repeat as necessary.
>

PF> The term "application label" is used repeatedly through the draft but
isn't really defined anywhere.  I suggest that you and rest of the authors
add a definition to the text.  The definition that you give above doesn't
make a lot of sense to me since I don't know how to interpret "expect to see
a BOS set but which isn't".  I've interpreted application label to refer to
the LSP for which the ingress LSR parsed the payload and generated an
entropy label.   I don't think the GAL (or any other reserved label) falls
into this category.  I think you may have to update 4.3 to say something
about how reserved labels are skipped until you find the first non-reserved
label and pop that as your entropy label.  Ugh.

> As both Curtis and I have said, in order to process the GAL payload
> correctly, the stack above the GAL should be the same whether or not an
> entropy label is present.
>

PF> I assume that any multi-path capable router's OAM implementation will be
aware of (and possibly even care about) the entropy labels regardless of
where they are in the label stack.  Or are you worried about transit nodes
who's OAM implementation may not be entropy-label aware?

> Sent from my iPhone****
>
> ** **
>
> *From:* Pablo Frank [mailto:[email-masked]]
> *Sent:* Friday, August 05, 2011 9:02 AM
> *To:* John E Drake
> *Cc:* [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> So I read the draft but could not see the justification.  In fact, I
> believe there's actually a flaw with what's proposed.  ****
>
> ** **
>
> not the GAL itself.****
> Then following the procedures in 4.3, the Egress LSR would inspect the S
> bit of the application/ELI label, and according to the text, would then pop
> the next label, assuming it was an entropy label.  Unfortunately, you've now
> popped the GAL and what's really left is the entropy label.****
>
> ** **
>
> It seems to me that we've gotten here because the GAL and Entropy label
> both want to be the BOS.  You've tried to get around it by relaxing the BOS
> build hierarchical multipath LSPs if I really want to... :-)****
>
> ** **
>
> regards,****
>
> Pablo****
>
> ** **
>
> On Thu, Aug 4, 2011 at 2:36 PM, John E Drake <[email-masked]> wrote:**
> **
>
> Pablo,****
>
>  ****
>
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****

---

From: John E Drake <[email-masked]>
Date: Sat, 6 Aug 2011 05:53:03 -0700

Sent from my iPhone

From: Pablo Frank [mailto:[email-masked]]
Sent: Friday, August 05, 2011 1:28 PM
To: John E Drake
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [PWE3] Entropy/Flow and GAL (was:Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt)

Thanks John,

On Fri, Aug 5, 2011 at 12:50 PM, John E Drake <[email-masked]<mailto:[email-masked]>> wrote:
An application label is a label in which you expect to see BOS set but which isn't, followed by an entropy label which is a non-reserved label with BOS set.  Repeat as necessary.

PF> The term "application label" is used repeatedly through the draft but isn't really defined anywhere.  I suggest that you and rest of the authors add a definition to the text.  The definition that you give above doesn't make a lot of sense to me since I don't know how to interpret "expect to see a BOS set but which isn't".  I've interpreted application label to refer to the LSP for which the ingress LSR parsed the payload and generated an entropy label.   I don't think the GAL (or any other reserved label) falls into this category.  I think you may have to update 4.3 to say something about how reserved labels are skipped until you find the first non-reserved label and pop that as your entropy label.  Ugh.

JD:   I am told this is the way most hardware developed over the past fifteen works - first scan stack for  the label with the BOS set and then get to work.  The original text was written several years ago and the GAL material added about a year ago, so there is probably some additional text editing required.  Btw, as RFC5586 indicates,  there is no technical reason for the GAL to be BOS.
As both Curtis and I have said, in order to process the GAL payload correctly, the stack above the GAL should be the same whether or not an entropy label is present.

PF> I assume that any multi-path capable router's OAM implementation will be aware of (and possibly even care about) the entropy labels regardless of where they are in the label stack.  Or are you worried about transit nodes who's OAM implementation may not be entropy-label aware?

JD:  LSP Traceroute (the control plane) needs to be updated because its usage of labels, as opposed to IP addresses, has some issues.  The data plane, by design, is completely oblivious to entropy labels  and I am told that most existing hardware does not use reserved labels in load balancing.

Sent from my iPhone

From: Pablo Frank [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, August 05, 2011 9:02 AM
To: John E Drake
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [PWE3] Entropy/Flow and GAL (was:Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt)

regards,
Pablo

Thanks,

John

Sent from my iPhone

Curtis,

regards,
Pablo

----- Original Message -----
From: Curtis Villamizar [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, August 04, 2011 06:38 AM
To: Shahram Davari
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Giles Heron <[email-masked]<mailto:[email-masked]>>; Thomas Nadeau <[email-masked]<mailto:[email-masked]>>; Yaakov Stein <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Robert Rennison <[email-masked]<mailto:[email-masked]>>
Subject: Re: [PWE3] Poll for WG adoption of draft-nadeau-pwe3-vccv-2-02.txt

Shahram,

Curtis