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

[Kireeti Kompella <[e-mail]>]

On Oct 25, 2012, at 06:10 , "Vivek Kumar" <[e-mail]> 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.