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

[Curtis Villamizar <[e-mail]>]

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.


> >  3.  Providing a means to carry indication of large flow as described
> >      in draft-yong-pwe3-enhance-ecmp-lfat-01.txt and
> >      draft-yong-pwe3-lfc-fat-pw-01.txt without changing the use of TC
> >      in a forwarding LSP label.
>  
> I'm unclear how a single, reserved label would be a means of signaling
> a large vs. small flow.  How can a single label represent two states
> (large vs. small flow)?

That's the slightly ugly part.  If ELI carries a TTL=0 then it can't
be used to forward and among those that discussed this (in one of the
"hallway sessions" near the registration desk) it was not seen as too
horribly ugly if TC meaned something else in the ELI label stack entry
only.

Lucy has a different way to do multipath and this is an enabler.  If
your LSRs don't use it, then it does no harm as long as the hashed
entropy value is there too.


> Thanks,
>  
> -shane

Thanks for the input on this.

Curtis


> > This would reuse one reserved label for three purposes.
> > 
> > This email is to gauge the reaction to this proposal (preferably among
> > those familiar with these drafts) before taking the time to write a
> > new draft proposing that a reserved label be allocated.
> > 
> > Curtis
> > _______________________________________________
> > mpls mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mpls
>  
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3