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

From: "Shahram Davari" <[email-masked]>
Date: Thu, 1 Nov 2012 22:04:13 +0000

Kireeti,

Is the draft proposing to always use label 15 even if one wants to use  label 0-14? In that case this draft won't be backward compatible with existing HW.

My suggestion is to keep the behavior of label 0-14 as-is. And for extended labels one must use label 15 followed by label 16 to XXX. This means Label 0-15 can't follow label 15. I think XXX=64  should be good enough. This would allow for HW registers rather than 20-bit lookup.

Thanks
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kireeti Kompella
Sent: Thursday, October 25, 2012 11:23 AM
To: Vivek Kumar
Cc: [email-masked]
Subject: Re: [mpls] new published draft-kompella-mpls-special-purpose-labels-01 (Adrian Farrel)

On Oct 25, 2012, at 06:10 , "Vivek Kumar" <[email-masked]> wrote:

> Hi Adrain,

I wouldn't say that -- Adrian is stimulating and fun, and if one does feel drained after talking with him, it's just the effort of keeping up.

>      Thanks for keeping us in job :) 
>      Having extension approach is good idea but the recursive nature means more possibility which result in more work for SW/HW without any extra benefit. Less the possibilities more deterministic the behavior .
> 
>   Since the idea of the draft  is to expand reserved label space , having only one extension label (15) will make things simpler.  

With or without recursion, only one extension label is proposed.

> The recursive label approach is not giving any additional information or scope but merely testing the system if it can handle Exten-label->Exten-label-> Exten-label->Exten-label ->...

I agree that a string of extension labels doesn't add info to the stack.  However,  that's not the goal.

Assume for a second that we all decide that having a protocol identifier is a Good Thing (note: this is just a Thought Experiment; please start a separate thread on the merits or demerits of such a notion; also, see draft-bitar-mpls-isis-explicit-null-label).

Assume further that all the labels from 0-15 have been assigned.  So, we have to use an extended special purpose labels for ISIS, Appletalk and NetBUI.  We already have explicit nulls for IPv4 and IPv6.  Would you rather:
a) have quite different ways (and label stack depths) to announce the payload type:
    0 -> IPv4
    2 -> IPv6
    15, 24 -> ISIS
    15, 25 -> Appletalk
    (etc.)
b) unify these as:
    15, 0 -> IPv4
    15, 2 -> IPv6
    15, 24 -> ISIS
    15, 25 -> Appletalk
    (etc.)
c) create new code points for IPv4 and IPv6, while keeping the old ones:
    0 -> IPv4
    15, 22 -> IPv4
    2 -> IPv6
    15, 23 -> IPv6
    15, 24 -> ISIS
    15, 25 -> Appletalk
    (etc.)

I'm not a hardware or microcode guy, but (b) sounds like a reasonable option to me.  You may have deeper insights.

And yes, I wish I had a more convincing example to hand; hopefully, though, I've given you a sense of the possibilities.  And no, I'm not wedded to this; I just don't like limiting possibilities with no real purpose.

> One more question, the new special action label range (16 - 1048559/75) need to be excluded or included when doing ECMP using MPLS labels as inputs (draft-ietf-mpls-entropy-label-06 ) ?

Agree with John's logic here -- the new special purpose labels (0-1048575) MUST be excluded from ECMP.  Will add to next revision (along with Bruno's suggestion to specify what happens if the extension label is the last label in the stack).

Kireeti.

_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 26 Oct 2012 08:35:32 +0100

On 25/10/2012 19:27, Kireeti Kompella wrote:
> Hi Stewart,
>
> On Oct 25, 2012, at 06:23 , Stewart Bryant <[email-masked]> wrote:
>
>> Whilst I think that we should make the whole label space
>> available to SLs, I think that we should try hard to compress
>> the used range to as small a space as possible so that
>> the fast path gets the option of parsing the SL without
>> having to invoke the heavyweight lookup that is needed
>> to do a full 20 bit lookup. That would suggest that
>> the SL set could usefully start at 0 so that it was
>> as compact as possible allowing a faster L15 parser.
> I see the logic of this, but in the entropy label draft, we did state that someone wishing to do load balancing could scan the label stack for the ELI (label 7), and use just the next label for hashing.  I think that's a nice optimization; however, reusing label 7 would break that.
>
> Considering backward compatibility, there are two choices:
> a) either allow 0-15 following the extension label, but keep the meaning the same as a "regular" SL; OR
> b) disallow 0-15 following the extension label.
>
> Kireeti.
>
Yes, I had forgotten about the deep dive stack parsers in the P router 
just looking for L7.

- Stewart

---

From: Pablo Frank <[email-masked]>
Date: Wed, 7 Nov 2012 11:37:13 -0500

>From a hardware / microcode perspective, once you decide to support even a
modestly-large range of extended special purpose labels AND you will only
implement a subset of the available values, the temptation is to use a
small internal CAM.  An 8-bit or 16-bit CAM is not a particularly expensive
hardware block, assuming the # entries is relatively small.  In this case,
it's not so important that one try to re-use labels 0-15 to conserve the
extended special purpose labels.  If OTOH, you're trying to implement this
as a register-based lookup or small internal table of, say, 64 entries or
less then there's a stronger case to try to re-use labels 0-15.

As for Kireeti's option (a) or (b), I think (a) is probably easier for
hardware to implement.  If we were to choose (b), would you expect hardware
to drop these disallowed extended SPLs?  That would actually require extra
datapath logic and/or force the implementer to use separate lookup
resources for classic SPLs and extended SPLs.  It you do go with (a), it
does create a funny situation where 15 might be followed by 15.  Maybe we
just hold our noses when this happens and keep going?

regards,
Pablo

On Fri, Oct 26, 2012 at 3:35 AM, Stewart Bryant <[email-masked]> wrote:

>> I see the logic of this, but in the entropy label draft, we did state
>> that someone wishing to do load balancing could scan the label stack for
>> the ELI (label 7), and use just the next label for hashing.  I think that's
>> a nice optimization; however, reusing label 7 would break that.
>>
> ______________________________**_________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/mpls<https://www.ietf.org/mailman/listinfo/mpls>
>