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

[Kireeti Kompella <[e-mail]>]

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.

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.

>  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.



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!)

Kireeti.