The MPLS WG Archive

["Rijsman, Bruno" <BRijsman@unispherenetworks.com>]

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:raszuk@cisco.com]
Sent: Sunday, December 31, 2000 7:53 AM
To: Yakov Rekhter
Cc: Rijsman, Bruno; 'mpls@UU.NET'; 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.