The MPLS WG Archive

[Robert Raszuk <raszuk@cisco.com>]

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