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

From: "Rijsman, Bruno" <[email-masked]>
Date: Wed, 20 Dec 2000 18:10:07 -0500

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?

Bruno Rijsman.

---

From: Yakov Rekhter <[email-masked]>
Date: Sat, 30 Dec 2000 15:18:50 -0800

Bruno,

> 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: Robert Raszuk <[email-masked]>
Date: Sun, 31 Dec 2000 04:53:15 -0800

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,

> 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: