Subject: Re: [mpls] new published draft-kompella-mpls-special-purpose-labels-01 (Adrian Farrel)

From: "George Swallow (swallow)" <[email-masked]>
Date: Thu, 1 Nov 2012 21:20:04 +0000

My opinion is that we should just make labels 0-15 in the new space
reserved in the sense of MUST not be sent and dropped on receipt.  I don't
think 16 LFIB entries of "treat the same as label 0" will challenge much
hardware.  And if they are that cramped then they won't be able to choke
down the new label space in the fast path anyway.

If we limit the new space to 6 bits that gives us 48 new reserved labels
which seems a large enough a devil's playground.  We would always have the
option of extending the reserved range or adding a dynamic range.

...George

On 10/25/12 6:17 PM, "Eric Rosen (erosen)" <[email-masked]> wrote:

>
>Stewart> Whilst I think that we should make the whole label space
>available
>Stewart> to SLs, I think that we should try hard to compress the used
>range
>Stewart> to as small a space as possible so that the fast path gets the
>Stewart> option of parsing the SL without having to invoke the heavyweight
>Stewart> lookup that is needed to do a full 20 bit lookup. That would
>Stewart> suggest that the SL set could usefully start at 0 so that it was
>as
>Stewart> compact as possible allowing a faster L15 parser.
>
>Kireeti> I see the logic of this, but in the entropy label draft, we did
>Kireeti> state that someone wishing to do load balancing could scan the
>Kireeti> label stack for the ELI (label 7), and use just the next label
>for
>Kireeti> hashing.  I think that's a nice optimization; however, reusing
>Kireeti> label 7 would break that.
>
>Kireeti> Considering backward compatibility, there are two choices:
>
>Kireeti> a) either allow 0-15 following the extension label, but keep the
>Kireeti>    meaning the same as a "regular" SL; OR
>
>Kireeti> b) disallow 0-15 following the extension label.
>
>It seems to me that Kireeti's argument above leads rather to the following
>two choices:
>
>a) Define label 7 in the extended special purpose label registry to have
>the
>   same meaning it has in the non-extended special purpose label
>registry, or
>
>b) Disallow label 7 following the extension label.
>
>The argument for applying this same choice to labels 0 and 2 seems to be
>the
>following: 
>
>Kireeti> Assume for a second that we all decide that having a protocol
>Kireeti> identifier is a Good Thing (note: this is just a Thought
>Kireeti> Experiment; please start a separate thread on the merits or
>Kireeti> demerits of such a notion; also, see
>Kireeti> draft-bitar-mpls-isis-explicit-null-label).
>
>Kireeti> Assume further that all the labels from 0-15 have been assigned.
>Kireeti> So, we have to use an extended special purpose labels for ISIS,
>Kireeti> Appletalk and NetBUI.  We already have explicit nulls for IPv4
>and
>Kireeti> IPv6.  Would you rather:
>
>Kireeti> a) have quite different ways (and label stack depths) to announce
>Kireeti>    the payload type:
>
>Kireeti>    0 -> IPv4
>Kireeti>    2 -> IPv6
>Kireeti>    15, 24 -> ISIS
>Kireeti>    15, 25 -> Appletalk
>Kireeti>    (etc.)
>
>Kireeti> b) unify these as:
>Kireeti>    15, 0 -> IPv4
>Kireeti>    15, 2 -> IPv6
>Kireeti>    15, 24 -> ISIS
>Kireeti>    15, 25 -> Appletalk
>Kireeti>    (etc.)
>
>Kireeti> c) create new code points for IPv4 and IPv6, while keeping the
>old ones:
>Kireeti>    0 -> IPv4
>Kireeti>    15, 22 -> IPv4
>Kireeti>    2 -> IPv6
>Kireeti>    15, 23 -> IPv6
>Kireeti>    15, 24 -> ISIS
>Kireeti>    15, 25 -> Appletalk
>Kireeti>    (etc.)
>
>Kireeti> I'm not a hardware or microcode guy, but (b) sounds like a
>Kireeti> reasonable option to me.
>
>To me, the best option is a.  Why make the stack longer for IP just
>because
>someone somewhere is still using Appletalk?  I think most implementations
>can handle variable length rewrite strings.  BTW, you forgot DECnet.
>
>I definitely wouldn't allow the silliness of having an arbitrarily long
>sequence of extension labels mean the same thing as a single extension
>label. 
>
>I'm also skeptical about whether we really need the extended special
>purpose
>label registry to have 20-bit values.  Maybe 4 bits is too little, but 8
>should be more than sufficient.  Any more than 8 bits and there is very
>little point to requiring the "standards action" allocation policy, as it
>becomes very easy to "squat" on codepoints.  (In fact, even 8 bits can be
>enough to encourage squatting; just look at the number of 8-bit codepoints
>that have been assigned values like 128 or 129 ;-))
>
>BTW, once there is an extension label, one can ask whether the extension
>label should just be interpreted as a "context label" that identifies a
>second per-platform label space.  A second per-platform label space could
>be
>divided into special purpose labels and dynamically assigned labels, just
>like the existing per-platform label space.  The draft should be clear
>about
>whether this use is allowed, prohibited, or just out of scope.
>
>Kireeti> So, it would be nice to have technical discussions about whether
>a
>Kireeti> new special purpose label is needed, what it means, how it would
>be
>Kireeti> used, etc., without worrying about scarcity.
>
>That seems likely to lead to a "just say yes" policy, in which we will end
>up with hundreds of special purpose labels, each implemented by only a
>subset of vendors.  If hardware/microcode needs to have a priori awareness
>of the special purpose labels, there still is scarcity, even if the
>scarcity
>is not imposed by the protocol syntax.
>
>Kireeti> While we're on the subject of special purpose labels, could the
>Kireeti> authors of RFC 5331 comment on whether a reserved (aka special
>Kireeti> purpose) label can be signaled as an upstream label? The RFC is
>Kireeti> silent on the subject,
>
>I think there are really two separate questions here:
>
>- When doing dynamic upstream label assignment, is it legal to assign
>label
>  values 0-15?
>
>  I think it would not be wise to do this, as it falls into the category
>of
>  "asking for trouble".  Probably it should have been prohibited.
>
>- What should you do in a context where you believe a particular label is
>  upstream-assigned, but (a) it has a value in the range 0-15, and (b)
>that
>  value has not been dynamically bound?
>
>  I am not aware of any situation in which this would be legal, but I'd be
>  interested in hearing other opinions.
>
>  
>_______________________________________________
>mpls mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mpls

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 2 Nov 2012 01:51:37 -0000

Hi George,

I'm not saying "no", but I am worried.

The label entry will be the same format as any other label entry in the stack.
So there are 20 bits available in the entry for a label.

If we restrict it to 6 bits, it will imply the other bots are available to be
"squatted". If we have a use for these bits then lets discuss. Otherwise, I
prefer that we keep the label as 20 bits (which is what the hardware will expect
to process) and just use the allocation policy to keep a tight rein on any
devils.

Cheers,
Adrian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> George Swallow (swallow)
> Sent: 01 November 2012 21:20
> To: Eric Rosen (erosen); Kireeti Kompella
> Cc: [email-masked]; 'Vivek Kumar'
> Subject: Re: [mpls] new published draft-kompella-mpls-special-purpose-labels-
> 01 (Adrian Farrel)
>

---

From: Eric Rosen <[email-masked]>
Date: Fri, 02 Nov 2012 13:45:59 -0400

Adrian> I prefer that we keep the label as 20 bits (which is what the
Adrian> hardware will expect to process)

This is not correct; to interpret a "special purpose label", hardware has
never had to do a 20-bit lookup.  We should not require that implementations
of this draft need to do a 20-bit lookup in order to process the extended
special purpose labels.

Adrian> If we restrict it to 6 bits, it will imply the other bits are
Adrian> available to be "squatted".

Unless you expect the WG to be assigning a million or so codepoints for
special purpose labels, any 20-bit scheme will leave plenty of unassigned
values that can be misappropriated.   Allocation policies don't really
provide disincentive to "squatting" unless there is a real likelihood of
"codepoint clash".

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 4 Nov 2012 04:13:00 -0000

Eric,

On your second point, I agree. Indeed, believing the other 14 bits might get
used for something else might stop someone pouncing on them.

On the first point I am confused (nothing new there).
I infer from what you say that a node receiving a label is somehow able to know
whether to look only at the bottom 4 bits, or whether to count all 20 bits.
Possibly you intended to say "extended special purpose label". In that case you
are right: we could define that following a label 15 only 6 (or whatever) of the
20 label bits are actually relevant. My question is whether that is helpful to
silicon or not (I do not currently own a silicon foundry) since you could argue
that it is useful to always cut 20 bits form the label stack entry or you could
argue that you can cut different amounts according to the previous label (viz
15).

I don't actually care about the solution here, but I would like to be certain
that we do the best thing for silicon as well as good enough for the MPLS
features.

Cheers,
Adrian

> From: Eric Rosen [mailto:[email-masked]]
> Sent: 02 November 2012 17:46
> To: [email-masked]
> Cc: 'George Swallow (swallow)'; 'Eric Rosen (erosen)'; 'Kireeti Kompella';
> [email-masked]; 'Vivek Kumar'

---

From: Eric Rosen <[email-masked]>
Date: Mon, 05 Nov 2012 11:42:40 -0500

> whether to look only at the bottom 4 bits, or whether to count all 20

I think the usual logic is something like the following:

- Extract 20-bit label field

- If high-order 16 bits are zero, dispatch on lower-order four bits (coded
  in-line). 

- Else do 20-bit lookup and dispatch based on the results from the lookup.

With this logic, if a special purpose label is present, the 20-bit lookup
can be avoided.  This can be beneficial, as the 20-bit lookup is often the
most expensive part of the processing.  Note that if there is a special
purpose label, it is likely that processing the packet will require another
label or IP lookup, depending upon what follows the special purpose label.

> you could argue that it is useful to always cut 20 bits form the label
> stack entry

This issue isn't masking off the bits to extract the label field, it's that
you can quickly determine that you have a special purpose label, and you can
skip the more expensive 20-bit lookup.

> I do not currently own a silicon foundry

But surely you've been an assembler language programmer! ;-)

---

From: Eric Gray <[email-masked]>
Date: Tue, 6 Nov 2012 20:16:16 +0000

Eric (Rosen),

	I am having some trouble understanding how what you describe is not simply
an isomorphism of a "20-bit look-up."

	If you examine the first 16 bits (to see if they are all zeros), and then look at the
last 4 bits, you have examined all 20 bits.

	It is easy enough to imagine an implementation that does exactly what you've
described, but difficult to see why such an implementation might be considered to be
"definitive."

	If it is possible that you will do a 20-bit look-up in at least some non-null subset 
of all cases, then the hardware needs to support this.  Having it also explicitly support a
"special case" handling mechanism for the case where the first 16 bits are all zeros may
be considered by at least some implementers as more complex than supporting the
basic 20-bit look-up with the results associated with the "special case" labels simply
"hard-wired" in.

	The part I'm having the most trouble with is the notion that an implementation 
would be optimized for the (hopefully) unusual case of "special case" labels, rather than
being optimized for the (probable) common case where the label has meaning assigned
for the purpose of forwarding packets.

	The process you describe gets a result after two (presumed) separate lookup
operations: a first one that determines if the first 16 bits are all zero, followed by a
second step where either the last 4 bits are used to pick a special cases result, or the
entire 20 bit label is examined (with the first 16 bits presumably being examined yet a 
second time).

	This would seem to be sub-optimal.

	If the implementation does not - in fact - do this as 2 separate lookups, than it
is performing steps that are logically identical to a 20-bit lookup in a single step.

--
Eric (Gray)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Rosen
Sent: Friday, November 02, 2012 1:46 PM
To: [email-masked]
Cc: [email-masked]; 'Vivek Kumar'
Subject: Re: [mpls] new published draft-kompella-mpls-special-purpose-labels-01 (Adrian Farrel)

This is not correct; to interpret a "special purpose label", hardware has never had to do a 20-bit lookup.  We should not require that implementations of this draft need to do a 20-bit lookup in order to process the extended special purpose labels.

Unless you expect the WG to be assigning a million or so codepoints for special purpose labels, any 20-bit scheme will leave plenty of unassigned
values that can be misappropriated.   Allocation policies don't really
provide disincentive to "squatting" unless there is a real likelihood of "codepoint clash".

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 6 Nov 2012 21:40:50 +0000

Hi Eric (Gray).

Let me explain this from chip perspective. As you probably know 20-bit lookup is expensive since it either requires a Hash table or a TCAM. Also note that any chip has a limitation on the number of MPLS labels that can be looked up per-packet (let's call this N). 

Now let's discuss the special labels. Special Labels as described in this draft  adds one Label to the Label stack depth. This means if you want to use the existing 20-bit lookup you will consume one of the Label lookups and therefore you can now only support (N-1) forwarding labels.

The solution that Eric Rosen has proposed solves this problem. Since looking at the first 14-bit is easy, just do a HW comparison with zero and then have a small direct index table (64 entries) to do the special label lookup. Such table is cheap. You could even implement it in Registers.

Hope this helps.

Regards,
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Gray
Sent: Tuesday, November 06, 2012 12:16 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; Vivek Kumar
Subject: Re: [mpls] new published draft-kompella-mpls-special-purpose-labels-01 (Adrian Farrel)

Eric (Rosen),

--
Eric (Gray)

---

From: Eric Gray <[email-masked]>
Date: Wed, 7 Nov 2012 15:06:15 +0000

George,

	I am pretty sure we would not "always have the option of extending the reserved bits"
if the requirement was that the bits are currently required to NOT be set and ignored.  Too many
opportunities for proprietary cheats that use one or another of the "Reserved" bits, and all you 
would need is for one or more of those to become popular in deployment and these cheats will
be part of the "installed base."

	This is what I believe Adrian is referring to with his comment about "squatting."

--
Eric

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of George Swallow (swallow)
Sent: Thursday, November 01, 2012 5:20 PM
To: Eric Rosen (erosen); Kireeti Kompella
Cc: [email-masked]; 'Vivek Kumar'
Subject: Re: [mpls] new published draft-kompella-mpls-special-purpose-labels-01 (Adrian Farrel)

My opinion is that we should just make labels 0-15 in the new space reserved in the sense of MUST not be sent and dropped on receipt.  I don't think 16 LFIB entries of "treat the same as label 0" will challenge much hardware.  And if they are that cramped then they won't be able to choke down the new label space in the fast path anyway.

If we limit the new space to 6 bits that gives us 48 new reserved labels which seems a large enough a devil's playground.  We would always have the option of extending the reserved range or adding a dynamic range.

...George

On 10/25/12 6:17 PM, "Eric Rosen (erosen)" <[email-masked]> wrote:

>Stewart> option of parsing the SL without having to invoke the 
>Stewart> heavyweight lookup that is needed to do a full 20 bit lookup. 
>Stewart> That would suggest that the SL set could usefully start at 0 
>Stewart> so that it was
>as
>Kireeti> I see the logic of this, but in the entropy label draft, we 
>Kireeti> did state that someone wishing to do load balancing could scan 
>Kireeti> the label stack for the ELI (label 7), and use just the next 
>Kireeti> label
>for
>It seems to me that Kireeti's argument above leads rather to the 
>following two choices:
>
>a) Define label 7 in the extended special purpose label registry to 
>have the
>The argument for applying this same choice to labels 0 and 2 seems to 
>be the
>following: 
>
>Kireeti> So, we have to use an extended special purpose labels for 
>Kireeti> ISIS, Appletalk and NetBUI.  We already have explicit nulls 
>Kireeti> for IPv4
>and
>because someone somewhere is still using Appletalk?  I think most 
>implementations can handle variable length rewrite strings.  BTW, you 
>forgot DECnet.
>
>purpose label registry to have 20-bit values.  Maybe 4 bits is too 
>little, but 8 should be more than sufficient.  Any more than 8 bits and 
>there is very little point to requiring the "standards action" 
>allocation policy, as it becomes very easy to "squat" on codepoints.  
>(In fact, even 8 bits can be enough to encourage squatting; just look 
>at the number of 8-bit codepoints that have been assigned values like 
>128 or 129 ;-))
>
>BTW, once there is an extension label, one can ask whether the 
>extension label should just be interpreted as a "context label" that 
>identifies a second per-platform label space.  A second per-platform 
>label space could be divided into special purpose labels and 
>dynamically assigned labels, just like the existing per-platform label 
>space.  The draft should be clear about whether this use is allowed, 
>prohibited, or just out of scope.
>
>Kireeti> So, it would be nice to have technical discussions about 
>Kireeti> whether
>a
>Kireeti> new special purpose label is needed, what it means, how it 
>Kireeti> would
>be
>That seems likely to lead to a "just say yes" policy, in which we will 
>end up with hundreds of special purpose labels, each implemented by 
>only a subset of vendors.  If hardware/microcode needs to have a priori 
>awareness of the special purpose labels, there still is scarcity, even 
>if the scarcity is not imposed by the protocol syntax.
>
>Kireeti> While we're on the subject of special purpose labels, could 
>Kireeti> the authors of RFC 5331 comment on whether a reserved (aka 
>Kireeti> special
>Kireeti> purpose) label can be signaled as an upstream label? The RFC 
>Kireeti> is silent on the subject,
>
>  I think it would not be wise to do this, as it falls into the 
>category of
>  I am not aware of any situation in which this would be legal, but I'd 
> be  interested in hearing other opinions.
>
>

---

From: Eric Gray <[email-masked]>
Date: Wed, 7 Nov 2012 15:20:03 +0000

Shahram,

	Thanks for the clarification.

--
Eric

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: Tuesday, November 06, 2012 4:41 PM
To: Eric Gray; [email-masked]; [email-masked]
Cc: [email-masked]; Vivek Kumar
Subject: RE: [mpls] new published draft-kompella-mpls-special-purpose-labels-01 (Adrian Farrel)
Importance: High

Hi Eric (Gray).

Hope this helps.

Regards,
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Gray
Sent: Tuesday, November 06, 2012 12:16 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; Vivek Kumar
Subject: Re: [mpls] new published draft-kompella-mpls-special-purpose-labels-01 (Adrian Farrel)

Eric (Rosen),

	I am having some trouble understanding how what you describe is not simply an isomorphism of a "20-bit look-up."

	If you examine the first 16 bits (to see if they are all zeros), and then look at the last 4 bits, you have examined all 20 bits.

	It is easy enough to imagine an implementation that does exactly what you've described, but difficult to see why such an implementation might be considered to be "definitive."

	If it is possible that you will do a 20-bit look-up in at least some non-null subset of all cases, then the hardware needs to support this.  Having it also explicitly support a "special case" handling mechanism for the case where the first 16 bits are all zeros may be considered by at least some implementers as more complex than supporting the basic 20-bit look-up with the results associated with the "special case" labels simply "hard-wired" in.

	The part I'm having the most trouble with is the notion that an implementation would be optimized for the (hopefully) unusual case of "special case" labels, rather than being optimized for the (probable) common case where the label has meaning assigned for the purpose of forwarding packets.

	The process you describe gets a result after two (presumed) separate lookup
operations: a first one that determines if the first 16 bits are all zero, followed by a second step where either the last 4 bits are used to pick a special cases result, or the entire 20 bit label is examined (with the first 16 bits presumably being examined yet a second time).

	If the implementation does not - in fact - do this as 2 separate lookups, than it is performing steps that are logically identical to a 20-bit lookup in a single step.

--
Eric (Gray)