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

From: Pablo Frank <[email-masked]>
Date: Fri, 22 Mar 2013 17:13:32 -0400

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.  :-)

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 but because these labels can be outside the 0-15 range, existing
implementations will include them in their hash.  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.

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?

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.

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

---

From: Loa Andersson <[email-masked]>
Date: Mon, 25 Mar 2013 10:56:14 +0100

Pablo,

tnx for comment - see inline please-

> probably not urgent.  In other words, let's not be hasty on this one and

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.

> 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:

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

-- 

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

---

From: Eric Rosen <[email-masked]>
Date: Mon, 25 Mar 2013 10:55:43 -0400

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

Loa> 1. the renaming of "reserved labels" to "special purpose labels", to
Loa>    align with how IANA uses the word "reserved".

Loa> 2. The procedures to deprecate and retire special purpose labels.

What is the urgency?

Loa> if you find a special purpose label that you don't recognize you should
Loa> silently drop that packet. So a packet with an unrecognized extension
Loa> label should not get into the hashing at all.

If an unrecognized label rises to the top of the label stack, the packet
should be dropped.  However, I don't think there's any requirement for a
router to drop a packet just because there's an unrecognized special purpose
label somewhere in the stack.  So if hashing is done on the entire stack, I
think Pablo is right that labels from the extended special purpose label
space will get into the hash.

Whether that really makes any difference is another matter.  

Pablo> This will have the effect that current implementations will add
Pablo> unintended entropy when it sees these labels.

Are there specific scenarios in which packets that should stay in order can get
different special purpose labels pushed on their stacks, but cannot get
different dynamically assigned labels pushed on their stacks?

Loa> I'd really would like to allocate 0-1023 after 15 for the extended
Loa> special purpose

How about 0-63?  Or 0-255?  

If the WG were to decide that Pablo's point is valid, one could deal with it
by treating several of the currently unused special purpose labels (I think
there are nine available) as extension labels, each identifying a new 4-bit
extended special purpose label space.  That scheme would satisfy Pablo's
criteria, but would not require more than two label stack entries to
represent any of the special purpose labels.  (I guess each such label space
would have to assign 7 as the entropy label.)

I'm not advocating this scheme, but I do think it is better than using the
cardinality of a sequence of 15's to identify a particular special purpose
label space ;-)

With regard to Jeff's suggestion to just expand the special purpose label
space by several bits, I think the problem is the following.  There are
bound to be routers in the network that do not know that 17, say, is now a
special purpose label.  Such routers may bind dynamically 17 to a FEC or
tunnel.  This will add an exciting bit of unpredictability to the handling
of packets carrying that label.

Jeff> Plenty of routers exist that are unwilling to look at a label stack
Jeff> deeper than 3..5 labels.

I'm guessing that "unwilling to look at" means that the high speed memory
used to hold the packet header cannot hold more than 3 to 5 labels.  This
would only be a problem for a P router if it had to interpret (in the fast
path) an extended special purpose label and 2-4 regular labels (or a couple
of special purpose labels) in order to dispatch the packet properly.  It
might be interesting to examine such scenarios, if someone can present them
without getting overly emotional about it ;-)

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 25 Mar 2013 16:39:57 +0100

Eric,

About urgency -
I just tried say when working e.g.  IANA we would benefit from getting the terminology
right. 

About retiring special purpose labels -
We could start the retirement process  for not used labels if we have the process in place. 

I didn't say "urgent" - just that I don't want to wait, while something else is discussed. 

About number extend labels -
As I said I'm prepared to discuss and that I've a preference.

/Loa

Sent from iPAD n
On 25 mar 2013, at 15:55, Eric Rosen <[email-masked]> wrote:

> Loa> silently drop that packet. So a packet with an unrecognized extensiontgi wouldn't cel

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 25 Mar 2013 23:53:31 -0400

In message <[email-masked]>
> tnx for comment - see inline please-

Loa,

A few comments inline.

Curtis

> with an unrecognized extension label should no get into the hashing

It is.  If the 15 is not on the top of the stack, then the LSR MUST
NOT drop the packet.  In doing the hash, an older LSR would skip over
the 15 but then incorrectly hash on the next label if it fell outside
of the 0-15 range.

> and that it should have be taken out of the draft.

+1

> interpretation in both spaces.

How about 16-1023 following 15?  With 0-15 following 15 being
considered an error.  Then 10 bits can be passed to the OAM gorp.

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 26 Mar 2013 00:05:00 -0400

> cardinality of a sequence of 15's to identify a particular special purpose

No one is proposing to use the cardinality of a sequence of 15's and
in fact most of us are trying to get two 15s in a row to be an error
and I'm pushing for 0-15 following 15 to be an error.

> of packets carrying that label.

17 would have no special meaning unless it directly follows 15.

> without getting overly emotional about it ;-)

By unwilling to look at, Jeff means unwilling to use them in the
multipath hash.

In PWE order (bottom to top).

PWE3 flow label
PWE3 PW label
EL
ELI
LDP
EL
ELI
RSVP-TE

OK.  That is 8.  Wedge 15 and new improved special label in there
(somewhere).  OTOH, only the top three (TE, ELI, EL) need to be looked
at if the gadget support EL.

Curtis

---

From: Jeff Wheeler <[email-masked]>
Date: Tue, 26 Mar 2013 05:20:32 -0400

> What is the urgency?

See below.

> of packets carrying that label.

Precisely -- today you can use 17 as a forwarding label.  I argue that
the best solution is to expand the existing special-purpose label
space, so PE routers must first stop allocating 17 and friends;
otherwise P routers will think an FEC label is an SP label, and create
an inter-op problem.

It's questionable whether or not the existing special-purpose label
space will ever be exhausted.  This is plenty of time for PE routers
to receive software updates that no longer allocate 16-1023 (or
whatever) as forwarding labels.

> without getting overly emotional about it ;-)

As Curtis points out, it may also be a problem for hashing.  If the
router cannot find the BoS then it can't hash on the payload.  The
wisdom of payload estimation hashing has proven to be questionable at
best, but a deeper and deeper label stack causes more problems than
just MTU.

Whether you call it register size, compute cycles per packet, or
whatever, the fact is that many routers exist that are limited to 3..5
labels before the router's behavior becomes unspecified or degraded.

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

---

From: Pablo Frank <[email-masked]>
Date: Wed, 27 Mar 2013 10:26:47 -0400

A few more comments below PF>>

> Whether that really makes any difference is another matter.

PF>> It might be useful if the authors of RFC 6790 could comment on why
exactly reserved/special-purpose labels MUST NOT be included in a transit
LSR's hash (afaik, this is the first normative reference that states this
explicitly).  Probably the key reason is for GAL.  I imagine it's not very
helpful to have your LM/DM packets misordered with respect to the flow that
they are trying to monitor.

PF>> But I wonder if this really matters for the other currently defined
SPLs though and whether it will matter for future proposed SPLs.  It may be
*okay* if we simply note in the document that new SPLs allocated from the
extended SPL space may not have this property respected by older transit
LSRs.  Perhaps this even becomes a criteria to determine which space you
should request a new SPL from.  i.e. if your proposed SPL does not require
strict flow ordering wrt the LSP it is associated with, then such SPLs
should be allocated out of the extended space.  We may want to "protect" /
"reserve" the remaining labels in the 0-14 space for uses that require
strict ordering (btw, there's 8 left, not including  label 15).
 Ironically, that has the unfortunate consequence of making this matter
more urgent, not less.  :-)

> How about 0-63?  Or 0-255?

PF>> In the long-term, it probably doesn't matter that much because
hardware will adapt.  In the short-term, looking at some existing hardware
designs, the difference between, say, 16-1023 and 16-255 can be
significant.  In one NPU that I've used (not naming names but I imagine
some of you can guess), having a 10-bit space could force me to use a
16-bit CAM instead of an 8-bit CAM.  The difference in access-time is a
factor of 4.  That'll add up especially when there's at least two of these
labels now.

> cardinality of a sequence of 15's to identify a particular special purpose

PF>> Hey, I didn't say that I *liked* the cardinality idea.  Part of the
reason I suggested it was because I'm kinda hoping that we never actually
get to the 2nd 15.  Your suggestion works as well but it requires us to act
now, whereas my (admittedly quite awful) idea lets us ignore the problem
for hopefully several decades.

PF>> OTOH, if my concerns about SPL misordering only applies to a sub-set
of the SPLs then I'm leaning more towards a scheme where 0-14 is reserved
for legacy and ordering-dependent SPLs and 16-255/1023 is made available
"immediately" for less-strict uses.

cheers,
Pablo