Re: [PWE3] [mpls] ELI as a reserved label

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>
John E Drake writes:
>  
> Curtis,
>  
> In the current proposal the EL is always at the bottom of the stack.   
> A transit router has access to the entire stack and can use the EL for  
> load balancing, so I don't see any purpose in moving the ELI/EL up the  
> stack, nor do I see any explanation of how this could be accomplished.

I know what is in the current proposal.

This is the purpose to putting it higher (from N prior emails):

  2.  Extending any use of entropy-label to any arbitrary position in
      the label stack such that in an aggregation LSP with aggregates
      both MPLS-TP and MPLS LSP, load split on the MPLS LSPs is
      simplified and not impacted by limiting label stack depth for
      the MPLS-TP LSPs.  This is when label stack hash is limited to
      support MPLS-TP as proposed in
      draft-villamizar-mpls-tp-multipath-00.txt .

The mechanism is simple.  It was considered obvious enough not to need
to be explained, but here it is.

  1.  The LER for an LSP carrying other LSP computes a hash as if it
      were load balancing, even if it were a single link.

  2.  This LER pushes three labels, 1) the forwarding label, 2) an
      ELI, and 3) the result of the hash.

Now you know the purpose and the mechanism.

> If we wanted to bring MPLS-TP into the entropy label context, wouldn't  
> it be simpler for the endpoints to always place the same value in the  
> EL?

The point is to limit the depth of stack inspection in order to allow
MPLS-TP to take a single path.

In doing this we don't want to break MPLS load split.  There are two
ways to not break MPLS load split.

  1.  Continue to look past the label stack at the first nibble and
      hash based on IPv4 or IPv6 src/dst rather than label stack.
      This requires all PW to use CW and requires OAM under GAL to
      avoid a 4 or 6 in the first nibble and requires MPLS-TP to add
      an encapsulation to IP that avoids 4 or 6 in the first nibble.

  2.  Disable hash on payload for the MPLS LSP carrying some MPLS-TP
      and MPLS and add an entropy label (as I described above) to the
      MPLS (without the -TP) only, with no entropy label on MPLS.

      The midpoint LSR must know the ELI value for the given LSP (for
      that forwarding label).  This requires either:

          a.  another 20 bit value to look up at forwarding time, or
	  b.  a fixed value for ELI

The midpoint LSR in the example where a MPLS LSP was carrying some
MPLS-TP LSP would have hash depth limited to two labels.  Reserved
labels would be skipped (without adding them to the hash) and the next
label considered in the count.  This covers GAL that is not at BOS and
covers ELI that is not at BOS.  Both GAL and ELI not at BOS are
relaxations of what is now speicified (before you jump on that too).

This is covered in draft-villamizar-mpls-tp-multipath-00.txt and
(again) your review of that work would be appreciated.

> Thanks,
>  
> John

I hope this is more clear now.

Thanks for the feedback and for prompting an explanation of the
mechanism.  Its likely others will benefit from reading these
additional details that were not in the original email.

Curtis


> Sent from my iPhone
>  
> On Aug 2, 2010, at 8:39 PM, "Curtis Villamizar" <[e-mail]>  
> wrote:
>  
> >
> > In message <[e-mail]>
> > John E Drake writes:
> >>
> >> Hi,
> >>
> >> I think there is a misunderstanding.  EL support is loosely coupled
> >> between the ingress and egress and intermediate nodes have no
> >> knowledge of its usage.   Further, the ELI is normally *not* present.
> >> The normal mode of operation is for the egress to see a label for
> >> which it is expecting to see BOS set.  The fact that it isn't tells
> >> the egress that an EL is present.
> >
> > John,
> >
> > You are jumping in without understanding the context of the
> > discussion.
> >
> > If stack depth used for hash is purposely limited for the purpose of
> > supporting a client MPLS-TP within an MPLS LSP, then the ELI and the
> > EL allow the label carrying entropy to be moved up the stack to where
> > it would be visible to the hash.
> >
> > For example, if an MPLS LSP carried one MPLS-TP LSP and one very large
> > IP/MPLS LSP, the forwarding label could be followed by ELI and then
> > EL.  If the hash is limited to two, then MPLS-TP is unaffected.  If
> > the midpoint LSR do not know the value of ELI being used, they cannot
> > look past it at the third label in the stack.
> >
> > This could also be solved by the ingress padding all LSP not using ELI
> > (by signaling an additional LSP that does nothing) but that is a very
> > ugly solution.
> >
> >> ELI is for IPv4/6 forwarding where there is no label in which to  
> >> check
> >> for BOS not being set.  Effectively, the ELI becomes that label.
> >
> > That was the original use, to avoid looking past BOS at the first
> > nibble.  Keeping that behaviour (looking past BOS) solves the
> > multipath with MPLS-TP case since the hash is not label stack based,
> > as long as MPLS-TP always uses a control word.  That is too limitiing
> > as MPLS-TP may also want to carry IP.
> >
> >> This renders any transit router usage of an ELI with a reserved value
> >> moot since most of the time it won't be there.
> >>
> >> Wrt p2mp, we cannot add either an EL or a reserved value ELI unless
> >> *all* receivers have indicated that they can receive it.
> >
> > Yes we all agree on that.
> >
> >> Thanks,
> >>
> >> John
> >
> > btw- The length of messages that you send from a phone never ceases to
> > amaze me.
> >
> > Curtis
> >
> >> Sent from my iPhone
> >>
> >> On Aug 2, 2010, at 10:18 AM, "Curtis Villamizar" <[e-mail]>
> >> wrote:
> >>
> >>>
> >>> In message <[e-mail]>
> >>> Shane Amante writes:
> >>>>
> >>>> Hi Curtis,
> >>>>
> >>>> I had some time to think about this some more on the plane ride  
> >>>> home.
> >>>> See below.
> >>>>
> >>>> On Jul 30, 2010, at 14:02 GMT+02:00, Curtis Villamizar wrote:
> >>>>> In message <[e-mail]>
> >>>>> Shane Amante writes:
> >>>>>>
> >>>>>> Curtis,
> >>>>>>
> >>>>>> On Jul 30, 2010, at 11:06 GMT+02:00, Curtis Villamizar wrote:
> >>>>>>> The Entropy Label Indicator (ELI) is called for in
> >>>>>>> draft-kompella-mpls-entropy-label-01.txt
> >>>>>>>
> >>>>>>> After brief discussion with Stewart and with Kireeti and Lucy
> >>>>>>> Yong,
> >>>>>>> there were three uses of ELI that would benefit from making the
> >>>>>>> ELI a
> >>>>>>> reserved label.  It may be premature to make any such request
> >>>>>>> and the
> >>>>>>> remaining reserved label number space is sparse, so this will be
> >>>>>>> floated as a separate draft, and put on hold awaiting
> >>>>>>> advancement of
> >>>>>>> the drafts that depend on it.
> >>>>>>>
> >>>>>>> The three benefits of making ELI a reserved label are in:
> >>>>>>>
> >>>>>>> 1.  Extending any use of entropy-label to P2MP (where there are
> >>>>>>>   multiple egress and the possibility of each egress requiring a
> >>>>>>>   separate entropy label value is problematic for the ingress).
> >>>>>>>
> >>>>>>> 2.  Extending any use of entropy-label to any arbitrary position
> >>>>>>> in
> >>>>>>>   the label stack such that in an aggregation LSP with  
> >>>>>>> aggregates
> >>>>>>>   both MPLS-TP and MPLS LSP, load split on the MPLS LSPs is
> >>>>>>>   simplified and not impacted by limiting label stack depth for
> >>>>>>>   the MPLS-TP LSPs.  This is when label stack hash is limited to
> >>>>>>>   support MPLS-TP as proposed in
> >>>>>>>   draft-villamizar-mpls-tp-multipath-00.txt .
> >>>>>>
> >>>>>> I agree there are benefits to a reserved label for the above two
> >>>>>> applications.  Most importantly, a receiving node would have  
> >>>>>> pretty
> >>>>>> clearly semantics that what [immediately] follows a reserved  
> >>>>>> ELI is
> >>>>>> the entropy-label, regardless of where the ELI is in the MPLS  
> >>>>>> label
> >>>>>> stack and without needing to be in the signaling path to know
> >>>>>> what is
> >>>>>> the ELI value.
> >>>>>
> >>>>> "Now don't be sad ... 'cause two out of three aint bad".   
> >>>>> [meatloaf]
> >>>>>
> >>>>> Its good to hear that you consider these to be useful.
> >>>>>
> >>>>> Note that an ingress LSR still needs to determine that egress LSR
> >>>>> understands ELI to do anything.  To support MPLS-TP in MPLS the
> >>>>> ingress needs to veryify that all LSR on the path support MPLS  
> >>>>> in a
> >>>>> way that provides a compliant path for a contained TP LSP, but
> >>>>> that is
> >>>>> out of scope of this discussion.
> >>>>
> >>>> I need to revise my statements wrt entropy-labels and P2MP LSP's.
> >>>> After thinking about this some more, I no longer believe it makes
> >>>> sense to use a reserved ELI value for P2MP LSP's.  More  
> >>>> specifically,
> >>>> for a given P2MP LSP, all receivers /MUST/ agree to receive entropy
> >>>> labels, because it would be silly to (for example) expect core  
> >>>> LSR's
> >>>> to strip-off the ELI and an entropy-label mid-flight toward  
> >>>> receivers
> >>>> that don't understand (or, can't receive) entropy-labels.  The
> >>>> ramifications of this are that if a head-end detects any  
> >>>> receivers of
> >>>> a P2MP LSP that can't receive entropy-labels, then the head-end
> >>>> LER/LSR must either: a) re-signal the whole P2MP LSP toward all
> >>>> receivers so that the head-end will not send any entropy-labels at
> >>>> all
> >>>> on the P2MP LSP; or, b) signal 2 separate P2MP LSP's: one for
> >>>> entropy-label capable receivers and a second for non-entropy-label
> >>>> capable receivers.  I don't know that we want to mandate one of  
> >>>> those
> >>>> two behaviors over the other, because SP's may make separate  
> >>>> choices
> >>>> depending on whether they want to avoid extra replication in the
> >>>> network at the expense of not being able to do flow-based
> >>>> load-balancing, i.e.: Option (a), or don't mind the extra  
> >>>> replication
> >>>> of (potentially) 2 parallel P2MP trees on the same links in order  
> >>>> to
> >>>> attain some amount of flow-based load-balancing of the P2MP  
> >>>> traffic.
> >>>
> >>> The use of a reserved label doesn't remove the requirement to figure
> >>> out if the egress can support ELI.  It just removes the  
> >>> requirement to
> >>> put a separate ELI label on for each egress.
> >>>
> >>> If some P2MP paths don't need to load balance (no multipath on that
> >>> leg) but other paths do, as long as all egress can support ELI, then
> >>> at worst it is 8 bytes of overhead that some paths don't need.
> >>>
> >>> I don't see an alternative for P2MP in your paragraph above.  Are  
> >>> the
> >>> branch points assumed to selectively add a different ELI (or none)  
> >>> and
> >>> should branch point remove ELI and the entropy label if ELI is not
> >>> needed downstream or to the next branch point?  Would this be a lot
> >>> more complicated with different values of ELI per egress (and  
> >>> possibly
> >>> also per branch point)?
> >>>
> >>>> So, in summary, I no longer see that draft-kompella-mpls-entropy-
> >>>> label
> >>>> has a requirement for reserved labels for either P2P or P2MP LSP's
> >>>> (scenario 1 in your original e-mail).  Furthermore, I still  
> >>>> maintain
> >>>> that discussion of LFC and use of the MPLS TC field for  
> >>>> indication of
> >>>> large vs. small flows is orthogonal to
> >>>> draft-kompella-mpls-entropy-label (scenario 3 in your original
> >>>> e-mail).  I haven't read draft-villamizar-mpls-tp-multipath-00
> >>>> (scenario 2 in your original e-mail) so I can't speak to whether or
> >>>> not there is a requirement for a reserved label there.
> >>>
> >>> OK.
> >>>
> >>>> Anyway, perhaps this will save you some time in that you don't need
> >>>> to
> >>>> write a whole new draft as you originally proposed and, instead,  
> >>>> may
> >>>> only need to look at modifying your original draft.  :-)
> >>>
> >>> For load balance to work with stack limited, then all midpoints  
> >>> would
> >>> need to know what ELI was being used.
> >>>
> >>> This is a bit like each P2MP needing to know which ELI is needed
> >>> downstream of it, but not quite as bad.
> >>>
> >>> OTOH, putting the ELI that is being used on a P2P LSP in the PATH or
> >>> RESV message for that P2P LSP would solve this for "Use of Multipath
> >>> with MPLS-TP and MPLS" aka draft-villamizar-mpls-tp-multipath-00.  I
> >>> could reference draft-kompella-mpls-entropy-label and make the  
> >>> request
> >>> that you put the ELI label in the PATH or RESV message somewhere.
> >>>
> >>>> On a separate note, we intend to update
> >>>> draft-kompella-mpls-entropy-label shortly to cover P2MP LSP's  
> >>>> (RSVP &
> >>>> mLDP), plus add details surrounding labelled BGP and RSVP P2P LSP's
> >>>> so
> >>>> that we have a more thorough treatment of all use cases to  
> >>>> hopefully
> >>>> make all of this more clear.  (In fact, I got a good start on this
> >>>> text on this on the plane ride home :-).
> >>>
> >>> OK.  Just try to get the ELI into the PATH or RESV so all LSR on the
> >>> PATH can see it.
> >>>
> >>> BTW - There are some implications for facilities FRR.  On the
> >>> facilities backup path there is no per LSP PATH or RESV message to
> >>> look at to see what value of ELI is being used.  If the facilities
> >>> backup path is over multipath (ie: LAG, bundle, or RSVP ECMP), then
> >>> the value of ELI will not be known.  This might force detour style  
> >>> FRR
> >>> or use of GMPLS path protection (or segemenbt which is more
> >>> detour-like).  A fixed ELI would help here too (allowing bypass  
> >>> FRR).
> >>>
> >>>> -shane
> >>>
> >>> Maybe we should continue offline and then go back to the list.
> >>>
> >>> Curtis