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

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>
Kireeti Kompella writes:
>  
> Hi Curtis,
>  
> On Aug 2, 2010, at 06:50 , Curtis Villamizar wrote:
>  
> > This doesn't work in the following cases:
> > 
> >  1.  P2MP (multiple egress, therefore multiple ELI values).
>  
> Let's step back a bit.
>  
> I think we're all agreed for p2mp that:
> a) _if_ an ELI is needed, it must be the same ELI for all receivers;
> b) *all* receivers must agree to process an EL;
> c) *all* receivers must agree whether an ELI is needed and if so, what
> the value of the ELI is. 
>  
> As  a reminder, we have mechanisms for upstream label allocation.
>  
> Here's my opinion:
>  
> For p2mp, use the signaling for app labels (if any) to also agree on
> whether ELs will be used.  If ELs are to be used, the label stack
> looks like:
>  
> tunnel label
> app label (p2mp PW/mVPN/...)
> EL
> payload
>  
> In this case, there is no need for an ELI.


The case for hierarchy and P2MP is weak.  Perhaps we will never need a
P2MP LSP that carries both MPLS and MPLS-TP LSP inside it, but if we
did, then the ELI would be needed.

I'm willing to solve that problem when and if it comes up and accept
that for now, ELI is not needed on P2MP.


> For cases where there isn't an app label (IP mcast over p2mp LSPs),
> use an upstream label allocation method to assign an ELI distinct from
> all app labels over the p2mp LSP (note that the ingress LSR is
> responsible for all upstream assignments, apps and ELI).  The label
> stack looks like this:
>  
> tunnel label
> ELI (upstream allocated)
> EL
> payload
>  
> Of course, if any receiver is unwilling or unable to process ELs, then
> we're back to not using them.


Right.  But if the ingress selects the ELI, the set of egress may end
up with many label values allocated as ELI.


> >  2.  Label stack depth is limited in order to accommodate MPLS-TP
> >      (midpoints must know to look past the ELI to include the entropy
> >      label in the hash).
>  
> IMHO, an MPLS-TP box should be able to process labels to any depth
> (note that "process" in this case is simply hashing).  I'll read and
> comment on your draft, but if the primary reason for moving ELs/ELIs
> "up" the stack is for depth-limited h/w, I'm not convinced.


The depth limit is because a MPLS-TP LSP may be carrying more than one
PW.  If it is, then the PW label can't be considered in the hash,
otherwise the MPLS-TP LSP will not all be on the same path and OAM
will be affected.  It is particularly hard to get the LM right.

I'm not saying I like MPLS-TP, but if we are going to carry MPLS-TP in
the same large LSP that also carry non-TP traffic, we have to limit
the stack depth and that signaling is carried across the midpoint LSR
for the outer label only.


> As for changing the semantics of the TC of ELs/ELI, I'm with Shane
> that that's something that the MPLS WG as a whole should agree on.
> Whether or not this is "not too horribly ugly" is a matter of opinion
> :-) (and more importantly, what the hardware folks say!)


I'm not fond of changing the TC bits at all.  The label below the
forwarding label is used for hash only which is why the "not too
horribly ugly" assessment.  The only thing lost by not allowing this
is the marking of large flows and I could easily do without that.

> Kireeti.

Curtis