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

Comments inline

Sent from my iPhone

> -----Original Message-----
> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of
> Curtis Villamizar
> Sent: Thursday, August 05, 2010 3:01 PM
> To: Kireeti Kompella
> Cc: mpls@ietf.org; pwe3@ietf.org
> Subject: Re: [PWE3] [mpls] ELI as a reserved label
> 
> 
> In message <0A475913-EE22-491C-A883-F09E02058DC9@juniper.net>
> 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.

JD:  Agreed

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

JD:  One of your proposed solutions was to enable MPLS-TP OAM multipath.  I think that this is a better approach, since we may want to use MPLS-TP OAM in non MPLS-TP situations and the existing MPLS OAM tools already support multipath. 

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

JD:  Agreed

> 
> > Kireeti.
> 
> Curtis
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www.ietf.org/mailman/listinfo/pwe3