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

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>
John E Drake writes:
>  
> Curtis,
>  
> What you are doing is speculating that our EL solution could be  
> morphed to solve a problem for which the requirements are ill-defined.

Yes.  morphing ELI was the context of the discussion.  I spoke to
Kireeti and Stewart at the IETF meeting and then sent an email to the
list.  As to ill defined this is from earlier in the thread:

  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 .

Others thought the goal was well defined.  There was a third goal that
dropped off somewhere in the thread because it required modifying the
use of TC on the ELI label.

I look forward to your review of draft-villamizar-mpls-tp-multipath-00
at which point you can comment on whether the goals in that draft are
well enough defined.

> You refuse to understand that ELI is required in only a few cases and  
> we do not want to make it mandatory.

I'm not refusing to understand what ELI was proposed for, just
pointing out that it could be more useful with some change.  That
should have been clear at the start of this thread.

At this point the only change that we (other participating in this
thread up until now) may have agreement on is putting the
(non-reserved label) ELI in the PATH or RESV message if ELI is used
for RSVP as well as LDP.  This is so that the midpoint LSR will see it
and can treat it appropriately.  Since ELI has to be passed egress to
ingress, this "request" may be a NOOP (it must be in the RESV in that
case or PATH and RESV for bidirectional LSP).

> Have you actually read the I-D or are you simply assuming that it  
> mirrors your pre-conceived notions?

Yes.  I both attended the PWE3 meeting where it was presented and read
the draft.  The subject line is "ELI as a reserved label" and the
first message of this thread clearly indicates that I was proposing a
change to ELI and the reasons for the suggestion.

The entire RSVP signaling section is TBD and MPLS-TP is currently out
of scope.  Authors indicated that they do intend to fill in the RSVP
section and that if very minor modification could help accommodate
coexistance of MPLS-TP and MPLS it would be considered.

At this point the Shane has strongly indicated that a reserved label
is undesirable.  Stewart made the same comment at the PWE3 meeting,
but was willing to consider it if there was a high value add.  It may
be off the table at this point.

> John

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