The MPLS WG Archive

[Robert Raszuk <raszuk@cisco.com>]

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.