Subject: [mpls] Entropy labels -- ELI

From: Kireeti Kompella <[email-masked]>
Date: Fri, 9 Dec 2011 09:26:05 -0800

Hi,

In Taipei, we brought up (not for the first time) the idea to make the Entropy Label Indicator (ELI -- a label that indicates that the next label in the stack is an Entropy Label) a reserved label, rather than signaling it.  To recap the main reasons for doing so:

a) (core) LSRs can recognize that the label stack has an ELI to do various interesting things:
   i) avoid going deeper into the packet for hashing (e.g., to look for an IP header);
   ii) hash labels up to (but not beyond) the first EL; and
   iii) know that an EL exists in the stack, and thus avoid adding another (hierarchical tunnels, CsC).

b) For the p2mp and mp2mp cases, signaling an ELI means using upstream label allocation methods.  While this is certainly doable, it would be a whole lot less complicated if this was not needed, as would be the case if the ELI was a reserved label.

The only potential downside is that legacy LSRs freak out (technical term) on seeing a previously unused reserved label in the stack.  Since ELIs should never be used for forwarding, and the use of ELs and thus ELIs is agreed upon by the LERs via signaling, this should not be an issue, but I'd like to hear from implementors if this is a concern.

Action: I'd like to request the MPLS WG chairs to close on this issue, and to begin the process of allocating such a reserved label if the WG is in favor.

Thanks,
Kireeti.

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 12 Dec 2011 09:55:41 +0000

> Action: I'd like to request the MPLS WG chairs to close on this issue, and to begin the process of allocating such a reserved label if the WG is in favor.

I have this nagging worry that with the recent interest in reserved 
labels we are going to run out - we have 9 left for the whole lifetime 
of MPLS, and am beginning to worry that we need to consider using adding 
some subtyping to reserved labels - i.e. a typed reserved label reserved 
label (a 0..15) + reserved label subtype (a 16..Label).

Stewart

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 12 Dec 2011 15:22:49 +0200

Stewart, and all,
A couple of comments if you do not mind.

1. Dynamics of consumption of the reserved labels
-	In January 2001 RFC 3032 has allocated 4 out of 16 reserved labels (0, 1 2 and 3). 
	This was the starting point of the  MPLS standardization, so you see a kind of a "big bang" event.
	After that the trend changes
-	 In November 2002 RFC 3429 has assigned label 14 has for OAM purposes. Note that it took almost 3 years after the initial burst
-	In September 2009 RFC 5586 has assigned label 13 for G-ACh. It took more than 6 years for that one
- 	One way to interpret this data is to say that one reserved label is consumed every 5-6 years, thus leaving ~50 years until exhaustion
-	Alternatively you could say that the time it takes to allocate a reserved label grows exponentially 
	(in which case it would take ~12 years to reserve the ELI:-). If this model is correct, we have ~1000 years before
	The last reserved label is allocated.
-	 The bottom line - I would not worry that much about exhaustion of the reserved labels' space.
 
2. Typed reserved labels: IMHO and FWIW this is not a very good idea because it would increase the depth of the label stack...

Regards,
     Sasha

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Stewart Bryant
> Sent: Monday, December 12, 2011 11:56 AM
> To: Kireeti Kompella
> Cc: [email-masked]
> Subject: Re: [mpls] Entropy labels -- ELI
> 
> > In Taipei, we brought up (not for the first time) the idea to make the
> Entropy Label Indicator (ELI -- a label that indicates that the next label in the
> stack is an Entropy Label) a reserved label, rather than signaling it.  To recap
> the main reasons for doing so:
> >
> > b) For the p2mp and mp2mp cases, signaling an ELI means using upstream
> label allocation methods.  While this is certainly doable, it would be a
> whole lot less complicated if this was not needed, as would be the case if
> the ELI was a reserved label.
> >
> > The only potential downside is that legacy LSRs freak out (technical term)
> on seeing a previously unused reserved label in the stack.  Since ELIs should
> never be used for forwarding, and the use of ELs and thus ELIs is agreed
> upon by the LERs via signaling, this should not be an issue, but I'd like to
> hear from implementors if this is a concern.
> >
> > Action: I'd like to request the MPLS WG chairs to close on this issue, and to
> begin the process of allocating such a reserved label if the WG is in favor.
> >
> > Thanks,
> > Kireeti.
> >
> >
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

---

From: Kireeti Kompella <[email-masked]>
Date: Mon, 12 Dec 2011 11:14:42 -0800

> -	 The bottom line - I would not worry that much about exhaustion of the reserved labels' space.

I like your analysis!  (except the part about ~12 years to reserve the ELI!)

Stewart mentioned that only 9 reserved labels are left, so there's one more hanging out somewhere.  Also note that 3 is never actually seen in a label stack (in the data plane), so one may reuse that with due care.

> 2. Typed reserved labels: IMHO and FWIW this is not a very good idea because it would increase the depth of the label stack...

Increasing the depth of the label stack per se is not a big deal, imho.  Labels are cheap at 4 bytes a pop; consider IP-in-IP or PBB tunneling, at 24 bytes a pop :-)

One approach is to wait (between 50 and 1000 years, by your analysis) till there is only one reserved label left, and use that as an indicator for more reserved labels, i.e., sub-typing.

BTW, did you have any comments on the original email -- on allocating a reserved label for the ELI?

Kireeti.

---

From: Francesco Fondelli <[email-masked]>
Date: Mon, 12 Dec 2011 20:23:22 +0100

On Mon, Dec 12, 2011 at 8:14 PM, Kireeti Kompella <[email-masked]> wrote:
>
> Stewart mentioned that only 9 reserved labels are
> left, so there's one more hanging out somewhere.  Also
> note that 3 is never actually seen in a label stack (in the
> data plane), so one may reuse that with due care.

"reuse" hmm... I'm curious... is label 14 in use nowadays ?

(just thinking out loud here -- obsolete 3429, take back label 14 and
use it as ELI)

ciao
fra

---

From: Kireeti Kompella <[email-masked]>
Date: Mon, 12 Dec 2011 15:27:05 -0800

> (just thinking out loud here -- obsolete 3429, take back label 14 and

Works for me!

Kireeti.

---

From: "Shahram Davari" <[email-masked]>
Date: Mon, 12 Dec 2011 15:37:45 -0800

This was tried for GAL and was not accepted since ITU said they there are deployments of Label=14.

Thx
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Francesco Fondelli
Sent: Monday, December 12, 2011 11:23 AM
To: Kireeti Kompella
Cc: [email-masked]; Stewart Bryant
Subject: Re: [mpls] Entropy labels -- ELI

ciao
fra

---

From: "Shahram Davari" <[email-masked]>
Date: Mon, 12 Dec 2011 15:41:08 -0800

Hi,

I actually like Stewart's idea. We could even use the TTL and Cos fields of a new Reserved label as Sub-type if label stack depth is an issue.

Thanks
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Monday, December 12, 2011 1:56 AM
To: Kireeti Kompella
Cc: [email-masked]
Subject: Re: [mpls] Entropy labels -- ELI

Stewart

---

From: Sam Aldrin <[email-masked]>
Date: Mon, 12 Dec 2011 16:28:52 -0800

I doubt reclaiming label 14 is that easy, given that there could be deployments and may not worth the pain. Subtype idea sounds interesting and seems to be a more workable solution.

Cheers
Sam

Sent from my iPad

---

From: "t.petch" <[email-masked]>
Date: Tue, 13 Dec 2011 11:25:56 +0100

----- Original Message -----
From: "Alexander Vainshtein" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, December 12, 2011 2:22 PM

> - In November 2002 RFC 3429 has assigned label 14 has for OAM purposes. Note
that it took almost 3 years after the initial burst
> - One way to interpret this data is to say that one reserved label is consumed
every 5-6 years, thus leaving ~50 years until exhaustion
> - The bottom line - I would not worry that much about exhaustion of the
reserved labels' space.

I think that Stewart is right to be cautious.  I first encountered MPLS in 2003
and heard little of it for many years, but now its use is exploding, and with
its use in MPLS-TP, and especially with two different flavours of OAM within
that genre, I expect that the demand for labels will rise exponentially, not
linearly, leading to exhaustion within 5 years.

I think it urgent that we define an escape mechanism now, 2011, reserving one
label to say 'we have run out - look elsewhere' so that manufacturers can start
looking at how to do that and what the implications are.

Whether ELI should be an original label or an escaped label would drop out of
that.

Tom Petch

> 2. Typed reserved labels: IMHO and FWIW this is not a very good idea because
it would increase the depth of the label stack...
> > >     i) avoid going deeper into the packet for hashing (e.g., to look for
an IP
> > header);
> > >     iii) know that an EL exists in the stack, and thus avoid adding
another
> > (hierarchical tunnels, CsC).
> > >
> This e-mail message is intended for the recipient only and contains
information which is CONFIDENTIAL and which may be proprietary to ECI Telecom.
If you have received this transmission in error, please inform us by e-mail,
phone or fax, and then delete the original and all copies thereof.

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 13 Dec 2011 16:39:30 +0200

Kireeti, 
Lots of thanks for a prompt response.

Here are some answers (in the order of presumed relevance)"

1. I support assignment of a reserved label as the ELI. In addition to the reasons you've indicated it would simplify 
     processing in the data path (please see some details below)

2. Increasing the depth of the label stack may be important. I am aware of several data path implementations that impose restrictions
    on the number of labels in the stack they can process at wirespeed - and these restrictions may be quite non-trivial to overcome!
    BTW, one of the advantages of using a reserved label as the ELI IMHO is that it would allow simple exclusion of entropy label
    from the label lookup process for such implementations: a reserved label means that it can be hardcoded in the NP microcode while
    a signaled label must be still looked up.

3. I sincerely hope hat assigning a reserved label for ELI would not require 12 years. However, I am aware of at least two
     drafts (both in the L2VPN WG) which, in spite of being implemented and deployed, have been on the table for the last
     10-11 years and still have not been approved. I just hope that they would not be considered as a precedent in this case...

My 2c,
     Sasha

________________________________________
From: Kireeti Kompella [[email-masked]]
Sent: Monday, December 12, 2011 9:14 PM
To: Alexander Vainshtein
Cc: Kireeti Kompella; Stewart Bryant; [email-masked]
Subject: Re: [mpls] Entropy labels -- ELI

Kireeti.