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

From: Loa Andersson <[email-masked]>
Date: Wed, 03 Apr 2013 07:59:10 +0200

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 <[email-masked]> 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: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Jeff Wheeler <[email-masked]>
Date: Wed, 3 Apr 2013 02:38:03 -0400

> the same time. Time is no remedy, you can do it now, in a year or

That is an easily solved control-plane problem.

An easily solved control-plane problem is greatly preferable to the
problem you are creating, which increases the heat/power/density
challenges of building future LSRs, and makes existing ones unable to
implement new features due to the deeper label stack.

Was there no consideration of what problems are caused by a deeper
label stack?  That seems to be the case.

-- 
Jeff S Wheeler <[email-masked]>
Sr Network Operator  /  Innovative Network Concepts

---

From: Loa Andersson <[email-masked]>
Date: Wed, 03 Apr 2013 12:45:20 +0200

Jeff,

I want to see separate discussions on separate problems.

The way I read some of the mails in this discussion is that if we
increase the number of with one, the label stack will be one label
deeper.

I seriously doubts this, it is potentially not true even in the
were the new special purpose label is present in the label stack.
Some special purpose labels changes what is in the stack in such a way
that there are fewer labels.

Do we have any hard figures on the relationship between the number
of available number of special purpose labels and the depth of the
label stack?

Same for the number of labels to be processed, do we know which
effect special purpose labels have on how many labels that need to
be processed.

/Loa

On 2013-04-03 08:38, Jeff Wheeler wrote:
<snip>

--

---

From: Jeff Wheeler <[email-masked]>
Date: Thu, 4 Apr 2013 03:30:06 -0400

> I want to see separate discussions on separate problems.

There are only two proposals which create different, related problems.
 Discussing them separately is only useful to understand what those
problems are.  I think that's been thoroughly dealt with.  Thus, you
are left with a choice: which problems are the lesser set of evils?
There is no point in handling them separately at this stage.

> were the new special purpose label is present in the label stack.

You don't know what future special-purpose labels will be used for.
None of us do.  If one is needed for something like a future iteration
of Entropy Labels, then the cost of forwarding all traffic using that
feature will be increased.  That means the data-plane needs more
power, area, and produces more heat; all of which decrease the useful
forwarding density.

You should only have a doubt about this if you foresee a system that
reserves all the remaining "legacy" special-purpose labels (not
needing 15 prefix) for high traffic-bearing features, and allocates
the extended ones (requiring 15 prefix) to future features that are
unlikely to be included in packets with enough frequency to impact
data-plane performance or density.

You have not proposed such a system yet.  Do you think one is needed?
If so, then every "legacy" value handed out now decreases the number
available for future high-traffic special purpose labels before the
costs get high.  This dramatically changes the urgency of this draft.

> of available number of special purpose labels and the depth of the

I do not understand your question.

> effect special purpose labels have on how many labels that need to

Yes, we do know this.  If your proposal is adopted, then every packet
labeled with an extended special-purpose label must process one
additional label.  This is obvious.  Did I misunderstand your question
again?

This is a very simple issue.  Imagine if the [7] Entropy Label
Indicator were, in fact, [15][7].  Then, every packet using Entropy
Labels for hashing would have a larger size (uses bandwidth) and would
require more NPU time to process, unless the LSR is already beyond its
maximum label processing depth, in which case the forwarding behavior
might be unspecified because it will not be able to find the Bottom of
Stack.

I hope you can understand why I am so concerned about this.  It is at
least *possible* to upgrade control-plane software and implement my
suggestion.  It is *impossible* to make deployed hardware able to
process a deeper label stack than its original design requirement.

It is further *impossible* to process a deeper label stack in FUTURE
LSRs without additional costs (head/power/area.)  That's why I think
your proposed solution is, frankly, very foolish.