Re: [mpls] Concerns about draft-kompella-mpls-special-purpose-labels-02

[Loa Andersson <[e-mail]>]

Pablo,

tnx for comment - see inline please-

On 2013-03-22 22:13, Pablo Frank wrote:
> Hello draft-kompella-mpls-special-purpose-labels authors,
>
> I'll preface my comments by saying that while I think the intent of this
> draft is certainly laudable, the matter of reserved-label exhaustion is
> probably not urgent.  In other words, let's not be hasty on this one and
> let's get it right.  :-)

The reason for this draft been posted now was that we wanted to address
the issue before it becomes urgent, so yes I agree.

However there is one (maybe two) things in the draft that is a little
more urgent than the extension of the special purpose label space.

1. the renaming of "reserved labels" to "special purpose labels", to
    align with how IANA useses the word "reerved".
2. The procedures to deprecate and retire special purpose labels.

If we find that the discussion on how to extend the special purpose
label space drags out, then I guess we could break out those to items
in a separate draft. But let keep in the draft for some time.

>
> My first concern involves backwards compatibility with mpls multipath
> solutions.  In particular, it's important that implementations that hash
> label stacks for the purposes of ECMP or LAG should ignore reserved
> labels.  I would think the same thing should apply to extended special
> purpose labels

yes that is true
  but because these labels can be outside the 0-15 range,
> existing implementations will include them in their hash.

I don't think this is true - if you find a special purpose label that
you don't recognize you should silently drop that packet. So a packet
with an unrecognized extension label should no get into the hashing
at all.

> This will
> have the effect that current implementations will add unintended entropy
> when it sees these labels.
>That's probably a bad effect and I doubt it
> was intended.  Conversely, this is exactly the desired behaviour of
> ELI+Entropy which this proposal appears to be modeled on.
>
> My second concern involves the size of the extended special purpose
> label range and how that will impact very high-speed hardware designs.
>   As it currently stands, detecting a reserved label is trivially simple
> and since the set of reserved labels is so small, the handling of said
> labels can be either implemented in a very small lookup resource or even
> hard-coded.  Since the proposed extended special purpose label space is
> now 20-bits wide, this becomes a much more expensive lookup resource in
> terms of chip area, lookup cycles, etc.  If jumping from 4-bits to
> 20-bits is "free", I'd be less concerned.  But IMO, it's not free and
> may very well be an overreaction given that the rate of reserved label
> allocation does not appear to be growing exponentially.

I'd be fully open to discuss how many special purpose labels that is
needed, I saw Curtis talking about 0-1023, would that address your
concern?

>
> The third concern is a relatively minor issue with how the draft appears
> to allow arbitrarily long strings of label 15 and seems to mandate that
> they should be treated as a single occurence of label 15.  I could see
> some implementations being vulnerable to DOS attack if they parse the
> label stack recursively.  Is there a particular motivation for this
> requirement or am I reading it wrong?

In the last version of the document we said that 15 in the extended
space is "reserved", my personal opinion is that 15,15 is not allowed
and that it should have be taken out of the draft.
>
> A possible solution that addresses all of these concerns, that
> admittedly is not very elegant, is to use each consecutive occurance of
> label 15 to extend the reserved label space by another 15 labels.  In
> other words:
> - labels 0-14 are the original (classic) reserved labels if they are not
> preceeded by label 15.
> - Unless they are preceeded by label 15, in which case labels 0-14 are
> really mapped to special purpose labels 16-30.
> - Unless they are preceeded by two consecutive label 15s, in which case
> labels 0-14 are really mapped to special purpose labels 32-46.
> - etc.
> To address my 3rd concern, an implementation would discard a string of
> label 15s if they exceeded the range of labels that it supported.

I'd really would like to allocate 0-1023 after 15 for the extended
special purpose, with some of the as listed in the draft, have a common
interpretation in both spaces.

/Loa
>
> Yeah, I know, yuck.  But it does work and has the virtue of being
> backwards-compatible with existing mpls multipath techniques and
> allowing a much more gradual ramp for the hardware lookup tables.
>
> It also assumes that the rate of reserved label allocation will remain
> more or less linear over time.  It may, in fact, decrease given that
> GACh channel-types can probably address many future needs.
>
> regards,
> Pablo
>
>
>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>

-- 


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