Subject: [mpls] new published draft-kompella-mpls-special-purpose-labels-01

From: Loa Andersson <[email-masked]>
Date: Wed, 24 Oct 2012 12:13:05 +0200

Working Group,

the decreasing number of "reserved labels" has been of concern
for some time. draft-kompella-mpls-special-purpose-labels-01 proposes
a way to increase the the number of special purpose labels.

We propose to take the current label 15 and use it as an extension
label, i.e. any label that follows label 15 should be interpreted
as belonging to the new "extension registry" that we propose.

We also propose changing the name of the special purpose labels
from "reserved labels" to "special purpose labels"; the main reason here
is that in the IANA registries "reserved" has an another meaning.

Please review the draft and comment to the list.

/Loa
-- 

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 24 Oct 2012 11:30:28 -0400

On the whole, it looks good. I'm curious who's going to have the
responsibility of running the process in section 3.2. IANA? (probably
not). The WG chairs?  What if there's no longer an MPLS working group
at some point? This should be clarified.

Thanks,
Andy

On Wed, Oct 24, 2012 at 6:13 AM, Loa Andersson <[email-masked]> wrote:
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Loa Andersson <[email-masked]>
Date: Wed, 24 Oct 2012 17:43:48 +0200

Andy,

this is in the category "good questions", when Scott Bradner were our AD
he always said that there should be a "caretaker" appointed when a wg
is closed But I don't know if this has been done consistently.

/Loa

--

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 24 Oct 2012 18:39:04 +0100

Hi Andy,

Section 3.2 is about withdrawing reserved labels. I suspect that we will all be
retired long before the MPLS WG closes down :-)

However, bullet (a) of 3.2 says:

       A label value that has been assigned from the "Special Purpose
       MPLS Label Values" may be deprecated by IETF consensus with
       review by the MPLS working group (or designated experts if the
       working group or a successor does not exist).

So a designated expert (appointed by the IESG as with all designated experts)
will be required. If one has not been appointed at the time of retirement of the
label, IANA would ask the IESG to appoint one. I think this would be the same
expert(s) as for label allocation. 

The other steps in the process just ask for RFCs (i.e. publication requests for
I-Ds) on specific tracks. I suppose that whoever wants to retire a label will
write the RFCs.

Did we miss any other decision points?

Cheers,
Adrian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Andrew G. Malis
> Sent: 24 October 2012 16:30
> To: Loa Andersson
> Cc: [email-masked]
> Subject: Re: [mpls] new published draft-kompella-mpls-special-purpose-labels-
> 01
>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 25 Oct 2012 09:01:02 -0400

Adrian,

I was more thinking about someone having the responsibility to do
steps b and c after specific amounts of time have passed. It's easy
for that kind of thing to be forgotten, esp. when it's volunteer work.

Cheers,
Andy

---

From: <[email-masked]>
Date: Thu, 25 Oct 2012 14:19:22 +0000

Hello,

>Please review the draft and comment to the list.

I agree that's a question that the WG should consider well in advance.

Two questions:
- How many special purpose labels do we think we would need? (before I retire)
- As STD & software & hardware change are required anyway before deployment, is there an obvious reason against extending the current range from 16 values to let's say 128 values? (depending on the 1rst question).

Thanks,
Regards,
Bruno

>/Loa

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 25 Oct 2012 16:36:38 +0100

My thoughts,

Bruno, we wish you a long and prosperous working life.
However, if we are creating a registry, it might as well be large.

Extending the special label space from 0-15 to (say) 0-127 is not backward
compatible. There is no way for a new implementation supporting special label 16
to know whether it is connected to another new implementation or to an old
implementation that has picked 16 to label a data packet.

Using 15 with a special meaning is same because an implementation that does not
recognise 15 is required to drop the packet.

With regard to the (infinite) nesting, we could simply define that labels 0-15
MUST NOT appear after label 15 making the new registry run 16 to 1048575

Yes, it is a really good idea to explain the rules for hashing.

Cheers,
Adrian

> [email-masked]
> Sent: 25 October 2012 15:19
> To: Loa Andersson; [email-masked]
> - As STD & software & hardware change are required anyway before
> deployment, is there an obvious reason against extending the current range
from
> 16 values to let's say 128 values? (depending on the 1rst question).
> 
> Thanks,
> Regards,
> Bruno
> 
> >/Loa
> >--
> >
> >
> ______________________________________________________________
> ___________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> France Telecom - Orange decline toute responsabilite si ce message a ete
altere,
> deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> If you have received this email in error, please notify the sender and delete
this
> message and its attachments.
> As emails may be altered, France Telecom - Orange is not liable for messages
that
> have been modified, changed or falsified.
> Thank you.
>

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 25 Oct 2012 09:48:21 -0700

Hi Bruno,

> - How many special purpose labels do we think we would need? (before I retire)

I think the purpose here is to _prepare_ for the case where more special purpose labels are needed, not that we need them now or in our working lifetimes.  Background: there was quite a long gap of time with no new special purpose labels, and then of a sudden, two new requests (for the ELI and for an ISIS label).  Understandably, there was pushback.

So, it would be nice to have technical discussions about whether a new special purpose label is needed, what it means, how it would be used, etc., without worrying about scarcity.

> - As STD & software & hardware change are required anyway before deployment, is there an obvious reason against extending the current range from 16 values to let's say 128 values? (depending on the…

You're right that any new special purpose label, even in the current space of 0-15, needs hardware and software changes to be useful.  But there is also the potential issue that older implementations may not understand the new label, and the specification for the new label MUST take this into account.  

Re-purposing an existing space of regular labels poses a very different problem.  If a current implementation signals label 16 (say as a PW label), but 16 is re-classified as a special purpose label (say as the Evil Label, which spammers insert in the stack to indicate they are doing Bad Things, a la RFC 3514), much havoc could ensue.

In a previous incarnation of my working life, a proposal to increase the special purpose label space from 0-15 to 0-31 was viewed with deep concern; I can't speak for Cisco, but I believe the reaction was similar there.

Kireeti.

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 25 Oct 2012 09:58:03 -0700

Hi Adrian,

> MUST NOT appear after label 15 making the new registry run 16 to 1048575

While we could specify this, there are a host of ways people could do silly but innocuous things with the label stack, such as insert 52 explicit nulls, or 93 sets of ELI+EL.

This is a case where my allergy against MUSTs breaks out in full-blown, throat-closing glory … which may be an excellent reason for the suggestion :-)

Kireeti.