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

[Pablo Frank <[e-mail]>]

A few more comments below PF>>

On Mon, Mar 25, 2013 at 10:55 AM, Eric Rosen <[e-mail]> wrote:

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

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

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

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.

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 ;-)


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