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

[Loa Andersson <[e-mail]>]

Jeff,

replacing 0..15 with 0..N gives you a red flag day. All LSRs in
your network needs to be updated a the same time. And if you have
MPLS inter-connectivity between your mpls network and someone
other networkz, you have to update all LSRs in all networks at
the same time. Time is no remedy, you can do it now, in a year or
in ten years.

/Loa

On 2013-03-28 23:08, Jeff Wheeler wrote:
> On Thu, Mar 28, 2013 at 10:11 AM, Curtis Villamizar <[e-mail]> wrote:
>> 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.
>
> 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.
>

-- 


Loa Andersson                        email: [e-mail]
Senior MPLS Expert                          [e-mail]
Huawei Technologies (consultant)     phone: [phone]