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

[Curtis Villamizar <[e-mail]>]

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