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

From: Curtis Villamizar <[email-masked]>
Date: Mon, 02 Aug 2010 09:50:29 -0400

In message <[email-masked]>
Shane Amante writes:
>  
> Curtis,
>  
> On Jul 30, 2010, at 14:02 GMT+02:00, Curtis Villamizar wrote:
> > In message <[email-masked]>
> > Shane Amante writes:
> >> On Jul 30, 2010, at 11:06 GMT+02:00, Curtis Villamizar wrote:
>  
> [--snip--]
>  
> >>> 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.
>  
> Understood.
>  
> I would note that in draft-kompella-mpls-entropy-label-01 it is NOT envisioned that there will be a "standalone ELI" in all cases.  Specifically, in the case where application labels are in use, (e.g.: 2547 VPN's, 6PE, etc.), the application label itself is intended to serve the purpose of an ELI, indicating that the label that immediately follows the application label is an entropy-label, i.e.:
>  
> +----------------+
> |  Tunnel Label  |
> +----------------+
> |   App. Label   |
> +----------------+
> | Entropy Label  |
> +----------------+
>  
> In these cases, there wouldn't be a reserved label used for a ELI in the label stack.  Thus, I'm not sure you can count on the LFC-bit *only* being set in entropy-labels that are immediately preceded by a reserved ELI label.
>  
> So, with respect to LFC, IMO it's:
> a)  orthogonal to the discussion of whether or not a reserved label for the ELI is absolutely _required_ or just nice-to-have; and,
> b)  the MPLS WG needs to weigh in with a definitive answer on whether changing the semantics of the MPLS TC is appropriate to accommodate end-users who desire LFC.
>  
> -shane

This doesn't work in the following cases:

  1.  P2MP (multiple egress, therefore multiple ELI values).

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

Since Lucy's large flow work needed TC, using TTL=0, and reserving one
TC bit for large flow seemed to do no harm.

I spoke to Stewart and Kireeti about this at IETF.  Perhaps either or
both of them could weigh in on this topic on the list.

Curtis

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 5 Aug 2010 07:08:51 -0700

Hi Curtis,

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

>      (midpoints must know to look past the ELI to include the entropy

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.

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 05 Aug 2010 18:00:35 -0400

In message <[email-masked]>
Kireeti Kompella writes:
> 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

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
>  

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

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

Curtis

---

From: John E Drake <[email-masked]>
Date: Mon, 9 Aug 2010 13:28:24 -0700

Comments inline

Sent from my iPhone

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Curtis Villamizar
> Sent: Thursday, August 05, 2010 3:01 PM
> To: Kireeti Kompella
> Cc: [email-masked]; [email-masked]
> Subject: Re: [PWE3] [mpls] ELI as a reserved label
> 
> 
> > c) *all* receivers must agree whether an ELI is needed and if so,
> what
> > the value of the ELI is.
> >

JD:  Agreed

> > Of course, if any receiver is unwilling or unable to process ELs,
> then
> > we're back to not using them.
> 
> 

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. 

> is the marking of large flows and I could easily do without that.

JD:  Agreed

> 
> > Kireeti.
> 
> Curtis
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3

---

From: Yong Lucy <[email-masked]>
Date: Tue, 10 Aug 2010 10:15:17 -0500

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

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Kireeti Kompella
> Sent: Thursday, August 05, 2010 9:09 AM
> To: [email-masked]
> Subject: Re: [mpls] [PWE3] ELI as a reserved label
> 
> Hi Curtis,
> 
> whether ELs will be used.  If ELs are to be used, the label stack looks
> like:
> 
> tunnel label
> 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
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls