Subject: Re: Encoding of MPLS label in MP-REACH-NLRI question

From: Robert Raszuk <[email-masked]>
Date: Mon, 01 Jan 2001 04:52:44 -0800

True Bruno,

I think it would indeed benefit all current mpls-vpn customers the most
(they should speak up here) not vendors if they prefer to mess with per
neighbour knobs either on the cisco side or any other vendor's side or
simply support adjusting the draft a bit. 

R.

> "Rijsman, Bruno" wrote:
> 
> I would not be opposed to changing both draft-rosen-rfc2547bis-02 and
> draft-ietf-mpls-bgp4-mpls-04 to say that the label should be encoded as
> "label.0001" instead of "1000.label".
> 
> If we keep the drafts the way they are now, then any vendor who wants to
> comply with the draft *and* interoperate with Cisco must have a knob to
> select between the two encodings ("neighbor ... shifted-label-encoding"?),
> and I don't see how that would benefit anyone.
> 
> -- Bruno.
> 
> -----Original Message-----
> From: Robert Raszuk [mailto:[email-masked]]
> Sent: Sunday, December 31, 2000 7:53 AM
> To: Yakov Rekhter
> Cc: Rijsman, Bruno; [email-masked]'; BGP exploder (E-mail); IDRP exploder
> (E-mail)
> Subject: Re: Encoding of MPLS label in MP-REACH-NLRI question
> 
> Yakov & Bruno,
> 
> draft-ietf-mpls-bgp4-mpls-04.txt says:
> 
> b) Label:
> 
>          The Label field carries one or more labels (that corresponds to
>          the stack of labels [MPLS-ENCAPS]). Each label is encoded as 3
>          octets, where the high-order bit contains "Bottom of Stack" (as
>          defined in [MPLS-ENCAPS]). The following high-order three bits
>          must be zero.  The remaining 20 bits contain the label value.
> 
> while [MPLS-ENCAPS] draft-ietf-mpls-label-encaps-08.txt defines it as:
> 
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> Label
>    |                Label                  | Exp |S|       TTL     |
> Stack
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> Entry
> 
>                        Label:  Label Value, 20 bits
>                        Exp:    Experimental Use, 3 bits
>                        S:      Bottom of Stack, 1 bit
>                        TTL:    Time to Live, 8 bits
> 
> So I think what happened was that Cisco followed the label encapsulation
> draft rather then the encoding description in Carrying Label Information
> in BGP-4 draft. The shipping encoding is as Bruno observed following:
> 
> *      +---------------------------+
> *      |   Length (1 octet)        |
> *      +---------------------------+
> *      |   Label (3 octets)        |
> *      +---------------------------+
> *      .............................
> *      +---------------------------+
> *      |   Prefix (variable)       |
> *      +---------------------------+
> *
> * That is:
> *      1 octet for the length in bits of the NLRI
> *      A tag(label) stack where each stack item is represented by 3
> octets
> *        according to draft-ietf-mpls-lable_encaps-01.txt:
> *           20 bits of tag, 3 bits of COS, 1 bit bottom of tag(label)
> stack.
> *      The prefix.
> 
> The reason being was that the code for this was written before the first
> issue of the draft bgp4-mpls-00 which came out in April-1998. We may
> call it a bug or not but the facts are that the only widely deployed
> implementation of L3 mpls-vpns is cisco's at this point and changing the
> current encoding will be quite hard.
> 
> Yakov,
> 
> > Looks like a bug to me, as without setting the bottom-of-stack to
> > 1, there is no way to find out how many labels are carried in the
> 
> As you see we set the S bit, but in the way Label.0001 rather then
> 1000.Label
> 
> R.
> 
> > Yakov Rekhter wrote:
> >
> > Bruno,
> >
> > > A brief question about draft-rosen-rfc-2547bis-02:
> > >
> > > What is the proper encoding of an MPLS label in a labeled vpnv4 prefix
> in an
> > > MP-REACH-NLRI attribute? Draft-rosen-rfc2547bis-02 refers to
> > > draft-ietf-mpls-bgp4-mpls-04  which says that the "label is encoded as 3
> > > octets, where the high-order bit contains bottom-of-stack. The following
> > > high-order three bits must be zero. The remaining 20 buts contain the
> label
> > > value."
> > >
> > > Given this, I would expect label 1000 (decimal) to be encoded as
> 80.03.e8
> > > (hex). However, one major vendor encodes it as 00.3e.81 (hex).
> Similarly, I
> > > would expect label 28 (decimal) to be encoded as 80.00.1c (hex) but the
> > > major vendor encodes it as 00.01.c1 (hex).
> > >
> > > Am I missing something, or does the vendor have a bug?
> >
> > Looks like a bug to me, as without setting the bottom-of-stack to
> > 1, there is no way to find out how many labels are carried in the
> > MP_REACH_NLRI, and therefore no way to find out where the address
> > prefix part of MPL_REACH_NLRI begins.
> >
> > Yakov.

---

From: "Rijsman, Bruno" <[email-masked]>
Date: Sun, 31 Dec 2000 10:49:15 -0500

-- Bruno.

-----Original Message-----
From: Robert Raszuk [mailto:[email-masked]]
Sent: Sunday, December 31, 2000 7:53 AM
To: Yakov Rekhter
Cc: Rijsman, Bruno; [email-masked]'; BGP exploder (E-mail); IDRP exploder
(E-mail)

Yakov & Bruno,

b) Label:

    0                   1                   2                   3

Yakov,

R.

in an
label
80.03.e8
Similarly, I

---

From: Eric Rosen <[email-masked]>
Date: Thu, 04 Jan 2001 11:24:42 -0500

Right now the draft says:

        The Label  field carries one or more  labels (that corresponds
        to the  stack of labels [MPLS-ENCAPS]). Each  label is encoded
        as  3 octets,  where the  high-order bit  contains  "Bottom of
        Stack" (as defined in [MPLS-ENCAPS]). The following high-order
        three bits  must be  zero. The remaining  20 bits  contain the
        label value.

Barring objection, I will change this to:

        The Label  field carries one or more  labels (that corresponds
        to the  stack of labels [MPLS-ENCAPS]). Each  label is encoded
        as 3  octets, where the  high-order 20 bits contain  the label
        value,  the following  three bits  must be  zero, and  the low
        order  bit   contains  "Bottom   of  Stack"  (as   defined  in
        [MPLS-ENCAPS]).

and reissue the draft.

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 05 Jan 2001 13:12:05 -0800

Eric,

>         order  bit   contains  "Bottom   of  Stack"  (as   defined  in

I also wonder whether we need "the following three bits must be zero"...

Yakov.