Subject: Re: [mpls] new published draft-kompella-mpls-special-purpose-labels-01 (Adrian Farrel)

From: "Vivek Kumar" <[email-masked]>
Date: Thu, 25 Oct 2012 05:36:00 +0000

Hi,
  Just curious on Section 3.1 statement  "  In particular, an arbitrary string of consecutive extension labels is  legal, and semantically equivalent to a single extension label (note  that this string of extension labels MUST be followed by an extended  special purpose label that is not the extension label).".

 Does this mean it will allow recursive extension labels like Exten-label->Exten-label->"Standard Action label"  ? Any special reason not to restrict only one extension label in MPLS header ?

Regards,
Vivek

----------------------------------------------------------------------

Message: 1
Date: Wed, 24 Oct 2012 11:30:28 -0400
From: "Andrew G. Malis" <[email-masked]>
To: Loa Andersson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [mpls] new published
	draft-kompella-mpls-special-purpose-labels-01
Message-ID:
	<CAA=[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1

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:
> 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
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

------------------------------

Message: 2
Date: Wed, 24 Oct 2012 17:43:48 +0200
From: Loa Andersson <[email-masked]>
To: "Andrew G. Malis" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [mpls] new published
	draft-kompella-mpls-special-purpose-labels-01
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

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

On 2012-10-24 17:30, Andrew G. Malis wrote:
> 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:
>> 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
>> _______________________________________________
>> mpls mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mpls

-- 

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

------------------------------

Message: 3
Date: Wed, 24 Oct 2012 18:08:31 +0100
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: [email-masked]
Subject: [mpls] AD review of draft-ietf-mpls-ipv6-pw-lsp-ping
Message-ID: <[email-masked]>
Content-Type: text/plain;	charset="us-ascii"

Thanks for this document. I have done my usual AD review and have 
nothing to add except for some minor comments on the IANA section.
If you could make an update that would be very helpful.

You do not need to wait for the submission gates to reopen on 5th
November. If you send me the file(s) for submission I will get the
Secretariat to post them.

Thanks,
Adrian

---

Section 6

It appears you are asking to *replace* the pointer to RFC 4379 for the
three IPv4 sub-TLVs. I don't think you should do that because they are
defined in 4379. So add the word "also".

OLD
   Update the names of the Value fields of these three Sub-TLVs, adding
   the "IPv4" qualifier (see Section 2), and update the Reference to
   point to this document:
NEW
   Update the names of the Value fields of these three Sub-TLVs, adding
   the "IPv4" qualifier (see Section 2), and update the Reference to
   also point to this document:
END

---

Section 6 usefully calls out TBD1 and TBD2, but the rest of the document
uniformly uses TBD. If you could update to always use TBD1 and TBD2 this
will ensure that the RFC Editor works with IANA to get this right.

---

In Section 6, please explicitly ask IANA to make the appropriate entries
in the Type 21 sub-TLVs list.

------------------------------

Message: 4
Date: Wed, 24 Oct 2012 18:39:04 +0100
From: "Adrian Farrel" <[email-masked]>
To: "'Andrew G. Malis'" <[email-masked]>, "'Loa Andersson'"
	<[email-masked]>
Cc: [email-masked]
Subject: Re: [mpls] new	published
	draft-kompella-mpls-special-purpose-labels-01
Message-ID: <[email-masked]>
Content-Type: text/plain;	charset="us-ascii"

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
> 
> 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:
> > 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
> > _______________________________________________
> > mpls mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mpls
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

------------------------------

_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

End of mpls Digest, Vol 102, Issue 53
*************************************

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 25 Oct 2012 13:41:29 +0100

Hello,

Well, we were looking for a format that would make things as hard as possible
for the chip vendors :-)

We wanted labels 0-15 (i.e. what are now to be called the special labels) to
preserve their meaning in the extended space.
Thus 15->3 has the same meaning as 3.

We were not sure that this was important, but it seemed like the right thing to
do.

That meant that 15->15 has the same meaning as 15.

And hence 15->15->3 has the same meaning as 3.

I would say that the authors were not strongly wedded to this. If there was
group-think that the whole extended special label range (0-1048575) should be
new, we could probably live with it.

Actually, a chip manufacturer could help here. Assuming that label 15 means you
throw the label and look at the next one, does it make things easier or harder
to find a special label value (say 3) and have one or two ways of handling it
depending on whether you have just found a label 15?

Cheers,
Adrian

> Vivek Kumar
> Sent: 25 October 2012 06:36
> To: [email-masked]
> 01 (Adrian Farrel)
>   Just curious on Section 3.1 statement  "  In particular, an arbitrary string
of
> consecutive extension labels is  legal, and semantically equivalent to a
single
> extension label (note  that this string of extension labels MUST be followed
by an
> extended  special purpose label that is not the extension label).".
> 
>  Does this mean it will allow recursive extension labels like
Exten-label->Exten-
> label->"Standard Action label"  ? Any special reason not to restrict only one
> extension label in MPLS header ?
> 
> Regards,
> Vivek
> 
> 
draft-kompella-mpls-special-purpose-labels-

---

From: "Vivek Kumar" <[email-masked]>
Date: Thu, 25 Oct 2012 13:10:50 +0000

Hi Adrain,
      Thanks for keeping us in job :) 
      Having extension approach is good idea but the recursive nature means more possibility which result in more work for SW/HW without any extra benefit. Less the possibilities more deterministic the behavior .

   Since the idea of the draft  is to expand reserved label space , having only one extension label (15) will make things simpler.  The recursive label approach is not giving any additional information or scope but merely testing the system if it can handle Exten-label->Exten-label-> Exten-label->Exten-label ->...

One more question, the new special action label range (16 - 1048559/75) need to be excluded or included when doing ECMP using MPLS labels as inputs (draft-ietf-mpls-entropy-label-06 ) ?

Regards,
Vivek

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Thursday, October 25, 2012 6:11 PM
To: Vivek Kumar; [email-masked]
Subject: RE: [mpls] new published draft-kompella-mpls-special-purpose-labels-01 (Adrian Farrel)

Hello,

Cheers,
Adrian

of
single
by an
Exten-label->Exten-

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 25 Oct 2012 14:23:28 +0100

Adrian

You are going to have to trap 0..15 anyway, and special
case the already defined set, because you don't know if
the already defined labels will come as themselves or
after L15.

However its quite an interesting question as to
whether anyone would want to put a 15 before
an existing RL, I cannot at the moment see why
you would make the stack parsing more complex
by doing that.

Whilst I think that we should make the whole label space
available to SLs, I think that we should try hard to compress
the used range to as small a space as possible so that
the fast path gets the option of parsing the SL without
having to invoke the heavyweight lookup that is needed
to do a full 20 bit lookup. That would suggest that
the SL set could usefully start at 0 so that it was
as compact as possible allowing a faster L15 parser.

You could think of two L15 label sets, 0..not very many
which were intended for fast h/w operations, and top
bit set to as many as you like which were intended
to be dispatched to a slower parsing process.

Stewart

On 25/10/2012 13:41, Adrian Farrel wrote:
> .

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: John E Drake <[email-masked]>
Date: Thu, 25 Oct 2012 14:19:02 +0000

Vivek,

According to the Entropy Label draft, all special (nee reserved) labels are to be ignored when performing load balancing.  I think a statement to this effect should be included in this draft.

Yours irrespectively,

John

> Sent: Thursday, October 25, 2012 6:11 AM
> To: [email-masked]; [email-masked]
> Subject: Re: [mpls] new published draft-kompella-mpls-special-purpose-
> labels-01 (Adrian Farrel)
> 
> Hi Adrain,
>       Having extension approach is good idea but the recursive nature
> means more possibility which result in more work for SW/HW without any
> extra benefit. Less the possibilities more deterministic the behavior .
> 
>    Since the idea of the draft  is to expand reserved label space ,
> having only one extension label (15) will make things simpler.  The
> recursive label approach is not giving any additional information or
> scope but merely testing the system if it can handle Exten-label-
> >Exten-label-> Exten-label->Exten-label ->...
> 
> One more question, the new special action label range (16 - 1048559/75)
> need to be excluded or included when doing ECMP using MPLS labels as
> inputs (draft-ietf-mpls-entropy-label-06 ) ?
> 
> Regards,
> Vivek
> 
> 
> Well, we were looking for a format that would make things as hard as
> possible for the chip vendors :-)
> 
> We wanted labels 0-15 (i.e. what are now to be called the special
> labels) to preserve their meaning in the extended space.
> We were not sure that this was important, but it seemed like the right
> thing to do.
> 
> I would say that the authors were not strongly wedded to this. If there
> was group-think that the whole extended special label range (0-1048575)
> should be new, we could probably live with it.
> 
> Actually, a chip manufacturer could help here. Assuming that label 15
> means you throw the label and look at the next one, does it make things
> easier or harder to find a special label value (say 3) and have one or
> two ways of handling it depending on whether you have just found a
> label 15?
> 
> Cheers,
> Adrian
> 
> 
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of Vivek Kumar
> > consecutive extension labels is  legal, and semantically equivalent
> to
> > a
> single
> > label->"Standard Action label"  ? Any special reason not to restrict
> > label->only one
> > > 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.
> > >
> as
> > > belonging to the new "extension registry" that we propose.
> > >
> from
> > > "reserved labels" to "special purpose labels"; the main reason here
> > 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
> >
> > > 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
> > >
> > >> 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.
> > >>
> > >> from "reserved labels" to "special purpose labels"; the main
> reason
> > >> here is that in the IANA registries "reserved" has an another
> meaning.
> > >>
> > Section 6 usefully calls out TBD1 and TBD2, but the rest of the
> > document uniformly uses TBD. If you could update to always use TBD1
> > and TBD2 this will ensure that the RFC Editor works with IANA to get
> this right.
> >
> > ---
> >
> > In Section 6, please explicitly ask IANA to make the appropriate
> > entries in the Type 21 sub-TLVs list.
> >
> >
> >
> > Section 3.2 is about withdrawing reserved labels. I suspect that we
> > will all
> be
> > 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
> > 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.
> >
> > > From: [email-masked] [mailto:[email-masked]] On
> Behalf
> > > Of Andrew G. Malis
> > > 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
> > >
> for
> > > > some time. draft-kompella-mpls-special-purpose-labels-01 proposes
> > > > from "reserved labels" to "special purpose labels"; the main
> > > > reason here is that in the IANA registries "reserved" has an
> another meaning.
> > > >

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 25 Oct 2012 11:22:45 -0700

> Hi Adrain,

I wouldn't say that -- Adrian is stimulating and fun, and if one does feel drained after talking with him, it's just the effort of keeping up.

>   Since the idea of the draft  is to expand reserved label space , having only one extension label (15) will make things simpler.  

With or without recursion, only one extension label is proposed.

> The recursive label approach is not giving any additional information or scope but merely testing the system if it can handle Exten-label->Exten-label-> Exten-label->Exten-label ->…

I agree that a string of extension labels doesn't add info to the stack.  However,  that's not the goal.

Assume for a second that we all decide that having a protocol identifier is a Good Thing (note: this is just a Thought Experiment; please start a separate thread on the merits or demerits of such a notion; also, see draft-bitar-mpls-isis-explicit-null-label).

Assume further that all the labels from 0-15 have been assigned.  So, we have to use an extended special purpose labels for ISIS, Appletalk and NetBUI.  We already have explicit nulls for IPv4 and IPv6.  Would you rather:
a) have quite different ways (and label stack depths) to announce the payload type:
    0 -> IPv4
    2 -> IPv6
    15, 24 -> ISIS
    15, 25 -> Appletalk
    (etc.)
b) unify these as:
    15, 0 -> IPv4
    15, 2 -> IPv6
    15, 24 -> ISIS
    15, 25 -> Appletalk
    (etc.)
c) create new code points for IPv4 and IPv6, while keeping the old ones:
    0 -> IPv4
    15, 22 -> IPv4
    2 -> IPv6
    15, 23 -> IPv6
    15, 24 -> ISIS
    15, 25 -> Appletalk
    (etc.)

I'm not a hardware or microcode guy, but (b) sounds like a reasonable option to me.  You may have deeper insights.

And yes, I wish I had a more convincing example to hand; hopefully, though, I've given you a sense of the possibilities.  And no, I'm not wedded to this; I just don't like limiting possibilities with no real purpose.

> One more question, the new special action label range (16 - 1048559/75) need to be excluded or included when doing ECMP using MPLS labels as inputs (draft-ietf-mpls-entropy-label-06 ) ?

Agree with John's logic here -- the new special purpose labels (0-1048575) MUST be excluded from ECMP.  Will add to next revision (along with Bruno's suggestion to specify what happens if the extension label is the last label in the stack).

Kireeti.

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 25 Oct 2012 11:27:37 -0700

Hi Stewart,

> as compact as possible allowing a faster L15 parser.

I see the logic of this, but in the entropy label draft, we did state that someone wishing to do load balancing could scan the label stack for the ELI (label 7), and use just the next label for hashing.  I think that's a nice optimization; however, reusing label 7 would break that.

Considering backward compatibility, there are two choices:
a) either allow 0-15 following the extension label, but keep the meaning the same as a "regular" SL; OR
b) disallow 0-15 following the extension label.

Kireeti.

---

From: Eric Rosen <[email-masked]>
Date: Thu, 25 Oct 2012 18:17:08 -0400

Stewart> Whilst I think that we should make the whole label space available
Stewart> to SLs, I think that we should try hard to compress the used range
Stewart> to as small a space as possible so that the fast path gets the
Stewart> option of parsing the SL without having to invoke the heavyweight
Stewart> lookup that is needed to do a full 20 bit lookup. That would
Stewart> suggest that the SL set could usefully start at 0 so that it was as
Stewart> compact as possible allowing a faster L15 parser.

Kireeti> I see the logic of this, but in the entropy label draft, we did
Kireeti> state that someone wishing to do load balancing could scan the
Kireeti> label stack for the ELI (label 7), and use just the next label for
Kireeti> hashing.  I think that's a nice optimization; however, reusing
Kireeti> label 7 would break that.

Kireeti> Considering backward compatibility, there are two choices:

Kireeti> a) either allow 0-15 following the extension label, but keep the
Kireeti>    meaning the same as a "regular" SL; OR

Kireeti> b) disallow 0-15 following the extension label.

It seems to me that Kireeti's argument above leads rather to the following
two choices:

a) Define label 7 in the extended special purpose label registry to have the
   same meaning it has in the non-extended special purpose label registry, or

b) Disallow label 7 following the extension label.

The argument for applying this same choice to labels 0 and 2 seems to be the
following: 

Kireeti> Assume for a second that we all decide that having a protocol
Kireeti> identifier is a Good Thing (note: this is just a Thought
Kireeti> Experiment; please start a separate thread on the merits or
Kireeti> demerits of such a notion; also, see
Kireeti> draft-bitar-mpls-isis-explicit-null-label).

Kireeti> Assume further that all the labels from 0-15 have been assigned.
Kireeti> So, we have to use an extended special purpose labels for ISIS,
Kireeti> Appletalk and NetBUI.  We already have explicit nulls for IPv4 and
Kireeti> IPv6.  Would you rather:

Kireeti> a) have quite different ways (and label stack depths) to announce
Kireeti>    the payload type:

Kireeti>    0 -> IPv4
Kireeti>    2 -> IPv6
Kireeti>    15, 24 -> ISIS
Kireeti>    15, 25 -> Appletalk
Kireeti>    (etc.)

Kireeti> b) unify these as:
Kireeti>    15, 0 -> IPv4
Kireeti>    15, 2 -> IPv6
Kireeti>    15, 24 -> ISIS
Kireeti>    15, 25 -> Appletalk
Kireeti>    (etc.)

Kireeti> c) create new code points for IPv4 and IPv6, while keeping the old ones:
Kireeti>    0 -> IPv4
Kireeti>    15, 22 -> IPv4
Kireeti>    2 -> IPv6
Kireeti>    15, 23 -> IPv6
Kireeti>    15, 24 -> ISIS
Kireeti>    15, 25 -> Appletalk
Kireeti>    (etc.)

Kireeti> I'm not a hardware or microcode guy, but (b) sounds like a
Kireeti> reasonable option to me.

To me, the best option is a.  Why make the stack longer for IP just because
someone somewhere is still using Appletalk?  I think most implementations
can handle variable length rewrite strings.  BTW, you forgot DECnet.

I definitely wouldn't allow the silliness of having an arbitrarily long
sequence of extension labels mean the same thing as a single extension
label. 

I'm also skeptical about whether we really need the extended special purpose
label registry to have 20-bit values.  Maybe 4 bits is too little, but 8
should be more than sufficient.  Any more than 8 bits and there is very
little point to requiring the "standards action" allocation policy, as it
becomes very easy to "squat" on codepoints.  (In fact, even 8 bits can be
enough to encourage squatting; just look at the number of 8-bit codepoints
that have been assigned values like 128 or 129 ;-))

BTW, once there is an extension label, one can ask whether the extension
label should just be interpreted as a "context label" that identifies a
second per-platform label space.  A second per-platform label space could be
divided into special purpose labels and dynamically assigned labels, just
like the existing per-platform label space.  The draft should be clear about
whether this use is allowed, prohibited, or just out of scope.

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

That seems likely to lead to a "just say yes" policy, in which we will end
up with hundreds of special purpose labels, each implemented by only a
subset of vendors.  If hardware/microcode needs to have a priori awareness
of the special purpose labels, there still is scarcity, even if the scarcity
is not imposed by the protocol syntax.

Kireeti> While we're on the subject of special purpose labels, could the
Kireeti> authors of RFC 5331 comment on whether a reserved (aka special
Kireeti> purpose) label can be signaled as an upstream label? The RFC is
Kireeti> silent on the subject,

I think there are really two separate questions here:

- When doing dynamic upstream label assignment, is it legal to assign label
  values 0-15?

  I think it would not be wise to do this, as it falls into the category of
  "asking for trouble".  Probably it should have been prohibited.

- What should you do in a context where you believe a particular label is
  upstream-assigned, but (a) it has a value in the range 0-15, and (b) that
  value has not been dynamically bound?

  I am not aware of any situation in which this would be legal, but I'd be
  interested in hearing other opinions.