Subject: [mpls] comments on draft-kompella-mpls-special-purpose-labels-02

From: Eric Rosen <[email-masked]>
Date: Mon, 18 Mar 2013 14:05:22 -0400

A few comments:

- The extended special purpose label space has about a million possible
  values (16 - 1048559), with an allocation policy of "standards action".
  This encourages squatting on "unofficial" codepoints while discouraging
  the publication of non-standards-track drafts describing the use of those
  codepoints.

  I think it would be better to have a much smaller piece of the label space
  to be allocated under the "standards action" policy.

- With a large extended special purpose label space, why do we need a
  process for reusing deprecated (non-extended) special purpose label
  values?  Especially when we already know that "IETF-wide surveys" don't
  necessarily determine correctly whether some feature is actually in use
  somewhere.

- "an arbitrary string of consecutive extension labels is legal, and
  semantically equivalent to a single extension label"

  I don't see the sense of this.  It will only lead to interoperability
  issues when some implementation puts in lots of extraneous labels and some
  other implementation can't handle it properly (as mentioned in the
  Security Considerations).

- Section 3, point 4, on the possible use of codepoint 3, doesn't seem to
  make any change to existing process or usage.  I'm not sure why it is even
  in the document.

- The fact that every special purpose label has a corresponding extended
  special purpose label seems problematic to me.  Suppose some
  implementation decides that when it needs to push "IPv4 explicit null" on
  a packet, it is always going to use the extended special purpose label.
  This seems perfectly legal, but will not interoperate with other
  implementations that understand "IPv4 explicit null" but that don't
  support the extended special purpose label space.

- From section 3.1:

       An extension label MUST be followed by another label L (and thus
       MUST have the bottom-of-stack bit clear).  L MUST be interpreted
       as an "extended special purpose label" from a new registry
       created by this document (see Section 5).  Whether or not L has
       the bottom-of-stack bit set depends on whether other labels
       follow L. Only L is interpreted as an extended special purpose
       label; labels following L are interpreted as normal.

  If all labels following a special purpose label "are interpreted as
  normal", it follows that there can only be one special purpose label in
  the stack.  I don't think that's the intention.

  Probably the final sentence should be "an extension label only affects the
  interpretation of the label immediately below it".

---

From: "William Ivory (wivory)" <[email-masked]>
Date: Mon, 18 Mar 2013 21:25:04 +0000

Hi Eric,

Given you're also at Cisco, and given this would be my first post to the IETF MPLS list, I thought I'd run this past you first ... (-:  Couple of points inline...

>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>>Eric Rosen (erosen)
>>Sent: 18 March 2013 18:05
>>To: MPLS
>>Subject: [mpls] comments on draft-kompella-mpls-special-purpose-labels-02
>>
>>A few comments:
>>

Using extended labels increases packet size.  This could cause unexpected issues with MTU at pinch points in a network, and could also possibly lead to faster exhaustion of hardware resources as the extra labels will need to be programmed in hardware.

>>  Security Considerations).

Isn't it better to allow for an arbitrary number now, rather than only allow one now, then have to extend in future, and end up with devices in the network supporting all 3 possible levels of support (or lack of)?

Thanks,

William

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

---

From: "William Ivory (wivory)" <[email-masked]>
Date: Mon, 18 Mar 2013 21:28:24 +0000

Oh well, guess I ran it past everyone.  Points still stand I hope!

William

>>William Ivory (wivory)
>>Sent: 18 March 2013 21:25
>>To: Eric Rosen (erosen); MPLS
>>Subject: Re: [mpls] comments on draft-kompella-mpls-special-purpose-labels-
>>02
>>
>>Hi Eric,
>>
>>Given you're also at Cisco, and given this would be my first post to the IETF
>>MPLS list, I thought I'd run this past you first ... (-:  Couple of points inline...
>>
>>>>From: [email-masked] [mailto:[email-masked]] On Behalf
>>>>Of Eric Rosen (erosen)
>>>>Subject: [mpls] comments on
>>>>draft-kompella-mpls-special-purpose-labels-02
>>>>
>>>>A few comments:
>>>>
>>>>  I think it would be better to have a much smaller piece of the label
>>>> space  to be allocated under the "standards action" policy.
>>>>
>>Using extended labels increases packet size.  This could cause unexpected
>>issues with MTU at pinch points in a network, and could also possibly lead to
>>faster exhaustion of hardware resources as the extra labels will need to be
>>programmed in hardware.
>>
>>>>
>>>>  I don't see the sense of this.  It will only lead to
>>>> interoperability  issues when some implementation puts in lots of
>>>> extraneous labels and some  other implementation can't handle it
>>>> properly (as mentioned in the  Security Considerations).
>>
>>Isn't it better to allow for an arbitrary number now, rather than only allow one
>>now, then have to extend in future, and end up with devices in the network
>>supporting all 3 possible levels of support (or lack of)?
>>
>>Thanks,
>>
>>William
>>
>>>>
>>>> normal", it follows that there can only be one special purpose label
>>>> in  the stack.  I don't think that's the intention.
>>>>
>>>>  Probably the final sentence should be "an extension label only
>>>> affects the  interpretation of the label immediately below it".
>>>>
>>>>
>>>>
>>>>
>>>>

---

From: Eric Rosen <[email-masked]>
Date: Tue, 19 Mar 2013 13:03:02 -0400

> issues with MTU at pinch points in a network,

Suppose one has a choice between (a) reusing a deprecated codepoint from the
special purpose label space, and (b) using a new codepoint from the extended
special purpose label space.  The risk of (a) is that you later find that
you have a customer with a legacy system that still uses the deprecated
codepoint.  The risk of (b) is that the label stack is 32 bits longer for
each occurrence of the label, and this is the factor that pushes some
packets over the MTU.

IMHO, (b) is the much more cost-effective strategy.  Lower risk, and lower
cost to work around it if it happens.

> and could also possibly lead to faster exhaustion of hardware resources as
> the extra labels will need to be programmed in hardware.

Even if we deprecated and reused every special purpose label from the
non-extended space, that would only be 16 labels.  I hope that 16 labels in
the extended space will not exhaust the hardware resources.

With regard to the issue of allowing an arbitrary number of "extension
labels":

> Isn't it better to allow for an arbitrary number now, rather than only
> allow one now, then have to extend in future

There will never be a need for an arbitrary number of extension labels,
because the semantics of an arbitrary number of extension labels (according
to the draft) is the same as the semantics of a single extension label.

I wonder if there is a terminological issue here.  An extended special
purpose label is represented by a pair of contiguous label stack entries.
The topmost entry of the pair is the "extension label" (label value 15), and
the bottommost entry of the pair is a label from the extended special
purpose registry.  It should be possible to have an arbitrary number of such
pairs in the label stack.  But I don't see the value of having an arbitrary
number of contiguous "15"s followed by a label from the extended special
purpose registry.

---

From: "William Ivory (wivory)" <[email-masked]>
Date: Wed, 20 Mar 2013 12:25:44 +0000

>> From: Eric Rosen (erosen)
>> Sent: 19 March 2013 17:03
>> To: William Ivory (wivory)
>> Cc: Eric Rosen (erosen); MPLS
>> Subject: Re: [mpls] comments on draft-kompella-mpls-special-purpose-labels-02
>> 
>> 
>> > Using extended labels increases packet size.  This could cause
>> > unexpected issues with MTU at pinch points in a network,
>> 
>> Suppose one has a choice between (a) reusing a deprecated codepoint from the special purpose
>> label space, and (b) using a new codepoint from the extended special purpose label space.  The
>> risk of (a) is that you later find that you have a customer with a legacy system that still uses the
>> deprecated codepoint.  The risk of (b) is that the label stack is 32 bits longer for each occurrence
>> of the label, and this is the factor that pushes some packets over the MTU.
>> 
>> IMHO, (b) is the much more cost-effective strategy.  Lower risk, and lower cost to work around it
>> if it happens.
[] 
>From my (admittedly short) experience of MPLS, MTU is a consistent problem in the field.  There's risk in both approaches, and while I'm happy if the consensus is for (b), I think the possible impact on existing network configurations should not be ignored.

>> 
>> > and could also possibly lead to faster exhaustion of hardware
>> > resources as the extra labels will need to be programmed in hardware.
>> 
>> Even if we deprecated and reused every special purpose label from the non-extended space,
>> that would only be 16 labels.  I hope that 16 labels in the extended space will not exhaust the
>> hardware resources.
[] 
16 wouldn't be a problem IMO.  Was (mistakenly) thinking it was the whole label space to consider, not just 16.

>> There will never be a need for an arbitrary number of extension labels, because the semantics of
>> an arbitrary number of extension labels (according to the draft) is the same as the semantics of a
>> single extension label.
>> 
>> I wonder if there is a terminological issue here.  An extended special purpose label is
>> represented by a pair of contiguous label stack entries.
>> The topmost entry of the pair is the "extension label" (label value 15), and the bottommost entry
>> of the pair is a label from the extended special purpose registry.  It should be possible to have an
>> arbitrary number of such pairs in the label stack.  But I don't see the value of having an arbitrary
>> number of contiguous "15"s followed by a label from the extended special purpose registry.
[] 
Maybe I've completely misunderstood the proposal, but isn't the idea that we have:

- [0-14][unreserved label]...
- [15][0-14 representing next 15 reserved labels][unreserved label] ...
- [15][15][0-14 representing 2nd new set of 15 reserved labels][unreserved label] ...

?

William

---

From: Jeff Wheeler <[email-masked]>
Date: Thu, 21 Mar 2013 14:11:33 -0400

> - [15][15][0-14 representing 2nd new set of 15 reserved labels][unreserved label] ...

My understanding of the text is [15][15][x] means exactly the same
thing as [15][x].  In S3.1 "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.")

What you are getting is 1M new special-purpose labels by prefixing
with 15.  It is basically generalizing the concept used by Entropy
Labels.

MTU issues are not trivial but having a deeper and deeper label stack
is a vexing problem.  Many routers will choke on a packet that has
more than N labels, where N is often <= 5.  It would be wise to
consider simply expanding the number of reserved/specal-purpose labels
by growing them from 0..15 to 0..X.

Do any routers exist where it is easier to deploy support for extended
special purpose labels than for simply growing the reservation?  My
suspicion is no.  If no, then this draft is very foolish.

The "eats up forwarding label space" argument doesn't really work.  If
networks are constrained for forwarding label space then they are
going to run out, whether or not a few hundred or a few tens of
thousand of additional reservations are made.  What I'm saying is, if
a network couldn't afford to give up 0..65535 now, then it is going to
out-grow the 20-bit label space in a week anyway, so it is already
screwed.  Of course most equipment does not have room in FIB for a
fully-populated LFIB anyway.

In short, my $0.02 is this draft is exploring the wrong solution.
-- 
Jeff S Wheeler <[email-masked]>
Sr Network Operator  /  Innovative Network Concepts

---

From: Saku Ytti <[email-masked]>
Date: Fri, 22 Mar 2013 09:14:00 +0200

> special purpose labels than for simply growing the reservation?  My

I'm quite interested in this as well. If someone can think of practical
example of MPLS product in use, where by HW labels 16 through say 16k will
be used and cannot not be used via software update, it would be easy to
disregard option of extending space.

I'm not concerned of trio or ezchip style products, I'm sure those will
adapt with very low cost to what we can think of essentially 8B mpls label
when certain 20b magic exists. But 'l3 switch' style products might be
problematic (7600, brocade, EX8k)

How commonly do we foresee the need for multiple subsequent SP labels, such
as [ 15 ext1 15 ext2 15 ext3 igp vpn ]? If this seems common, what would be
the implications of dedicating one bit in SP label for EOE or
end-of-extension?  So we'd have [15 ext1 ext2 ext3 igp vpn] with EOE bit
off in ext[12] and on in ext3.

-- 
  ++ytti

---

From: Loa Andersson <[email-masked]>
Date: Fri, 22 Mar 2013 10:25:53 +0100

On 2013-03-21 19:11, Jeff Wheeler wrote:
<snip>
> by growing them from 0..15 to 0..X.
<snip>

Specifying is easy, implementing is harder, operating is worse!
Label stack processing is mostly or at least commonly in HW. You
would need to do a HW change of your entire network the day you 
introduce the first router with the "grown label space", otherwise
treatment of labels 15 to X will be non-deterministic

/Loa

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Jeff Wheeler <[email-masked]>
Date: Fri, 22 Mar 2013 21:39:23 -0400

On Fri, Mar 22, 2013 at 5:25 AM, Loa Andersson <[email-masked]> wrote:
> would need to do a HW change of your entire network the day you introduce
> the first router with the "grown label space", otherwise

Loa, can you give any example of such hardware?

I believe this draft is a huge mistake, and that mistake is probably based
on the wrong assumption you've posted (quoted above.)

Any feature introduced by extended special-purpose labels is not going to
be supported by routers without at least new software.  If routers exist
that are not capable of taking additional processing steps (such as punt to
CPU, forward as IPv4/IPv6, use entropy label) based on an arbitrary label
value, then these routers simply will not be able to support new features.
 They will not break.

So we're not talking about breaking anyone's deployed hardware.  At worst,
new features might not be able to be supported.  However, I suspect vendors
were not so fantastically stupid as to hard-wire 0..15 special action label
range into their ASICs without making it possible to install a LFIB entry
so arbitrary labels can also take a special action.

If there are such fantastically stupid vendors, it's probably not a good
idea to punish everyone else for their rather obvious mistake.

This adds MTU complexity and wastes bandwidth / wire-time whenever extended
S-P labels are in use.

If you are going to make those sacrifices, I think you should be able to
give at least one example of a router that actually forces you to do it
this way.

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 22 Mar 2013 23:03:45 -0400

> give at least one example of a router that actually forces you to do it

Many LSR use a table for the ILM.  Since the receving end specifies
which label to use in both LDP and RSVP-TE (and PW), an LSR with less
than the full 20 bits of space can be assured that all labels it will
ever see will fall within that table.

A TCAM can be used as an ILM but it is much less power efficient.  It
is though common where a TCAM is used for IP routes (or MAC lookups)
and the power is already in the power budget for that use of the chip.

If the IETF is assigning the labels and decides to put a label up high
in the number space (for example a block of experimental or vendor
assigned, which I hope to never see), then the table approach won't
work.  The existing reserved space (0-15) is well within any LSR's ILM
table size.

I'm liking Pablo's suggestion a little bit because of the small
extension to the space, except for the problem of LSR that don't know
the meaning of 15 and then misinterpret the next label (for example,
as ELI).  So I like using 15 and then a small space such as 17-1023.
The worst an LSR will do with that is hash on it, so maybe any further
labels that can't be hashed on can go into the old space.

If we assign 1,000 special purpose labels, we are going to need a lot
bigger micro-programable engine instruction spaces than we have in
some existing chips that do OAM that way.  So I think ~1000 is plenty
big enough.

Curtis

---

From: Jeff Wheeler <[email-masked]>
Date: Sat, 23 Mar 2013 19:21:52 -0400

> ever see will fall within that table.

I don't think anyone has suggested this is a problem for PE -- except
carrier-of-carrier PE.  Ignoring that case for now, keep in mind that
a PE isn't going to signal willingness to accept entropy labels, or
any future feature, that might require the use of extended
special-purpose labels.

Aside from carrier-of-carrier issues, there is no sense in even
discussing PEs.  Either they'll support it, or they won't; but PEs are
in a position to choose.

> as ELI).  So I like using 15 and then a small space such as 17-1023.

The 15 prefix is my gripe.  I do not believe hardware exists that
can't inter-operate in a P role if 16-1023 (or whatever) suddenly
became reserved labels.  If the community can't come up with a single
example of such hardware, then it shouldn't penalize everyone with
this ridiculous prefix label.

Plenty of routers exist that are unwilling to look at a label stack
deeper than 3..5 labels.  This draft just adds to label bloat, and
that costs data-plane processing time or makes features impossible to
implement without new hardware.

I also would like to understand why several consecutive 15 labels
should be processed.  That seems pointless.  Is there a reason for it?

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 25 Mar 2013 22:06:39 -0400

> discussing PEs.  Either they'll support it, or they won't; but PEs are

I suspect that you didn't get the point I was making.  This has
nothing to do with LDP P vs PE roles.

The point is that currently an LSR with a smaller that 2^20 (roughly 1
million) ILM that is table based, can insure that all label forwarded
to it by legitimate traffic falls within its ILM table.

> this ridiculous prefix label.

I don't think we are supposed to mention vendor products, but ...

I worked closely with two chip vendors.  Both of their high end chip
designs (which are very different from each other) could handle this
with only microcode changes (ie: in the field).  I think that for both
this is true for a few past generations as well.  I worked not nearly
as closely with a third and I think their current and some recent past
chips could handle this (ie: label 15 followed by another label that
is automatically interpreted as "special"), though they are already a
bit stack depth challenged.

Seeing 15 on the top of stack and interpreting the next label as a
special label is not hard.  Instead of a table of 16 special
operations, there is a table of 1024 (or some number).  A few existing
OAM designs (not a good option, but..) pack a vector and send it off
to an FPGA or ASIC on the side.  In the few designs I've run into that
do this, the packing is quite flexible, so packing the 4 bits of old
reserved space, or 10 bits of new special lable space might be
possible with in-field firmware change.  In either case, the OAM FPGA
or ASIC would need change.

Seeing 0-14 on the stack when looking for entropy and skipping it is
not hard to do.  Seeing a 15 on the stack and skipping two labels is
also not hard.  Except for some of the most poorly designed chips I
know of (and there are some bad ones out there), this is quite doable,
in some with in-field firmware upgrade, though others might need a
tweak making it a next gen feature.

For any new special purpose label that falls outside of the 0-14
range, backwards compatibility will have to be discussed.

It is also worth pointing out that there is time to change designs
before the first 16-1023 special purpose label is assigned, which I
hope won't be soon after this draft.  This draft is about future
proofing should the remaining 6 bits be used up (I think its 6).

> implement without new hardware.

Bad hardware is no reason to not move forward.  In 2000 there were
plenty of routers in the field that could not forward MPLS at all.

It is up to providers to use features that can be supported by their
deployed base of hardware, not for IETF to halt progress based on the
mistakes of vendors in the past.

> should be processed.  That seems pointless.  Is there a reason for it?

I entirely agree with that.  It is complete nonsense.

I would like to see 15 followed by 0-15 be declared to be an error.

Curtis

---

From: Jeff Wheeler <[email-masked]>
Date: Tue, 26 Mar 2013 04:58:09 -0400

> to it by legitimate traffic falls within its ILM table.

You expressed concern that some hardware would be unable to cope with
reserved labels 16-1023 but could cope with [15][X] and I disagree.
If Entropy Labels doesn't break this hardware, then neither will any
possible expanded reserved label scheme -- except those that make the
label stack too deep.

This draft makes the label stack deeper.  There is zero benefit to
that.  I'll respond to your other remarks below, as you've actually
argued my position for me.

> I worked closely with two chip vendors.  Both of their high end chip

This working group is basing an obviously bad design decision on the
assumption that some hardware exists that somehow could not cope with
simply expanding the reserved label range from 0-15 to 0-1023.

If these hardware makers are concerned about their products
inter-operating, then they should speak up.  It shouldn't be your
responsibility.

I argue that there are zero such chips deployed with such an
incredibly stupid design that they would, in any way, break if the
0-15 range is just made 0-Bigger.

0-Bigger is technically superior, in every way, to the 15 prefix
proposed in this draft.

If you want to do the technically inferior solution, then please
justify it.  Otherwise, let these makers of old or badly-designed
chips express their concern.

> plenty of routers in the field that could not forward MPLS at all.

You can't argue that "bad hardware is no reason to move forward," but
then support a bad design, like this 15 prefix before new reserved
labels; and justify it by saying there is some hardware that can't
support an extended range.

Which do you want?  Supporting the bad hardware that no one has been
able to name, and no one has even claimed exists, even without naming
it?

Or would you like a technically superior solution, which is very
simply, changing 0-15 to 0-1023 (or whatever value is agreeable.)

Making the label stack deeper for no reason is really stupid.  If you
can show some reason to do it, I am certainly willing to listen.  "Bad
hardware" that no one claims exists in the field is not a reason.

> I would like to see 15 followed by 0-15 be declared to be an error.

I disagree strongly with the 15 prefix concept.  However, if it does
keep momentum, I agree that [15][15] should be undefined behavior, and
that should be explicitly documented as undefined.  This covers
routers that don't know about 15.

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 28 Mar 2013 10:11:17 -0400

> 0-Bigger is technically superior, in every way, to the 15 prefix

You are obviously not getting what is being proposed.  Please start by
more carefully reading draft-kompella-mpls-special-purpose-labels-02

   An extension label MUST be followed by another label L (and thus
   MUST have the bottom-of-stack bit clear).  L MUST be interpreted as
   an "extended special purpose label" from a new registry created by
   this document (see Section 5).  Whether or not L has the
   bottom-of-stack bit set depends on whether other labels follow
   L. Only L is interpreted as an extended special purpose label;
   labels following L are interpreted as normal.

All I'm suggesting to change this is that we restrict L to be in the
range 16-1023 rather than use the whole 20 bit range.

No one at all it proposing just increasing the range from 0-15 to
0-1023.  I hope that is now clear.

If the LSR can't handle any new extension and 15+L is on top of stack,
it will barf (drop packet) either on the 15 (doesn't support
extensions at all) or barf on L (doesn't support that extension).  Any
extension has to state in the RFC how this is avoided (for example,
RFC6790 has a negociation between ingress and egress that prevents an
egress having to POP an ELI and EL if it doesn't support that aspect
of RFC6790 forwarding.

The other concern is hashing for multipath.  If the LSR doesn't handle
ELI (and even if it does since RFC6790 says SHOULD in this case), it
could hash on the EL (and maybe even the ELI) and keep going.  Also if
it doesn't know about the "extension label" then it will hash on L and
may even hash on the 15.  Any proposals to use the extension label (or
any existing special purpose label aka reserved label) needs to also
consider this backwards compatibility issue.

Any provider making use of extensions must consider what is written
about backwards compatibility in the RFC that define the extension and
then also consider what their existing installed base of LSR will do.
The provider always has the option to disable any new extension that
would have bad effects due to older LSR in their network and all they
lose is the potential benefit of the extension.

> chips express their concern.

See above.

> simply, changing 0-15 to 0-1023 (or whatever value is agreeable.)

The reason we should not extend the range is that the values 16-1023
can still be used as forwarding labels if they are not followed by 15.
Older LSR would commonly request labels starting with 16 and up making
the simple range extension highly problematic.

If something like GAL is proposed, then an upgraded LSR could
potentially send a special purpose label to an older LSR that is using
that label as a forwarding label.

> hardware" that no one claims exists in the field is not a reason.

But we are making it one deeper for a good reason and only when/if
some future, yet to be defined extensions use the 15+L extension
mechanism.  At that time the WG can decide whether backwards
compatibility is sufficiently considered and a network operator can
decide whether to deploy it given their installed base.

For many existing hardware designs, the ability to skip 0-15 in the
hash is quite easy to implement, if they don't already to that.
Skipping 15+L is not that much harder to do.  A lot of chips today
have full access to the first 256 bytes anywhere in the pipeline and
can skip a few (same as they can skip an entire header).  Some of the
hashing engines are very limited and this will have to be considered
in the backwards compatibility section of any RFC defining an
extension, whether using the 0-14 range or using 15+L.

Curtis

---

From: Jeff Wheeler <[email-masked]>
Date: Thu, 28 Mar 2013 18:08:39 -0400

> that label as a forwarding label.

I don't agree.  An SP label shouldn't end up at top-of-stack unless
the receiving LSR has signalled support for that extension.

The problem is not top-of-stack issues, but middle-of-stack.  If PE2
is legacy and assigns label 17 for an application label, but P1, P2,
etc. are aware that is a new SP label that has some defined purpose,
they may take action on that packet based on the specification of SP
17.

All that needs to happen here is 0..15 be replaced with 0..N and
enough time to pass before the 0..15 space is exhausted that you can
reasonably expect all PEs in a network to receive software upgrades
before any features are specified and deployed to P nodes using SP
values > 15.  This is a very reasonable expectation given the likely
huge lead-time before any such extended SP labels are required to be
allocated (if ever.)

The question is, which of these is more likely:
1) networks depend on PE that can't receive this software upgrade in
many years time; or
2) networks depend on P that can't gain hardware ability to process
deeper label stack in many years time

In both cases, the time-frame is years; but #2 is where hardware
limitations on label stack depth arise.  Folks in this WG have argued
that hardware limits are an issue for changing 0..15 to 0..N and there
is no evidence of that.  There is a large body of evidence that many
routers have degraded or unspecified behavior once label stack grows
beyond a certain depth, and these routers continue to be sold into
customer networks today.  I do not expect that will change, or grow by
2 labels, because of this draft.  Do you?

Quite simply, to have extended SP labels based on my suggestion, all a
customer must do is request his vendor produce software updates to not
use 16..N as forwarding labels.  To have them based on this draft, he
may need to replace all of his hardware.  I think we can all agree
that software updates are more realistic.