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

Kireeti,

Thank you for proposing a solution for P2MP. It seems that using one
reserved label for ELI makes the solution simpler. 

I understand that current proposal for ELI is to let egress LER distributing
labeled packets and IP packets. Curtis and I have talked about this at
Maastricht and thought that if we could adjust a special label for this
purpose, we might extend ELI usage for general ECMP function. We see some
beneficial to let both LER and LSR to understand ELI as mentioned in Curtis
e-mail and understand this is a stretch for current ECMP function. However,
if we anticipate more and more usage of ECMP in IP/MPLS network, current
ECMP capability will shortly show the weakness in dealing with different
kind of scenarios. Thus, it is worth to think of a reserve label for ELI. 

Although when application label is used, there is no need to use ELI in
current scenario; there may be still benefit to use ELI on the stack to make
consistent process by LER and LSR. It can apply to PW PE and P as well
(FAT-PW). This will make ELI as unique symbol on the stack (followed by
EL/LBL) for ECMP/LAG/Link bundle/composite link.   

This is my 2c. 

Regards,
Lucy

> -----Original Message-----
> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of
> Kireeti Kompella
> Sent: Thursday, August 05, 2010 9:09 AM
> To: curtis@occnc.com
> Cc: mpls@ietf.org; pwe3@ietf.org
> Subject: Re: [mpls] [PWE3] ELI as a reserved label
> 
> 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.
> 
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls