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

[Curtis Villamizar <[e-mail]>]

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