Re: [mpls] Label encoding in LDP

Hi Alexander,

My impression is that RFC 5036 and RFC 3036 do not differ in terms of
intended label encoding.
However, RFC 5036 does add more material to clarify the intended encoding.

Thanks,
Ramakrishna.

On Thu, Jun 20, 2019 at 9:30 PM Alexander Okonnikov <
alexander.okonnikov@gmail.com> wrote:

> Hi Ramakrishna,
>
> It seems that many of implementations follow RFC 3036 in part of General
> Label TLV encoding, while claim support of RFC 5036. RFC 5036 specifies
> another format of encoding, as you mentioned, though it doesn't notice that
> difference in section 7.
>
> 20 июня 2019 г., в 13:45, Ramakrishna Rao Desetti <
> ramakrishnadtv@gmail.com> написал(а):
>
> Hi,
>
> I request a clarification on label encoding in LDP.
> The reason is it appears implementations do not seem to follow what is
> specified
> in the LDP standard.
>
> I have reproduced the relevant text from RFC 5036:
>
> "
> 3.4.2.1.  Generic Label TLV
>
>    An LSR uses Generic Label TLVs to encode labels for use on links for
>    which label values are independent of the underlying link technology.
>    Examples of such links are PPP and Ethernet.
>
>     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
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |0|0| Generic Label (0x0200)    |      Length                   |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |     Label                                                     |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    Label
>       This is a 20-bit label value represented as a 20-bit number in a 4
>       octet field as follows:
>
>        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                             |                       |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>       For further information, see [RFC3032].
> "
>
> I have tested with 3 systems: Netbsd, wireshark, and a popular commercial
> vendor.
>
> In all these cases, the label is encoded as shown below:
>
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |     Label                                                     |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> But from the RFC, it should be encoded as shown below:
>
>       This is a 20-bit label value represented as a 20-bit number in a 4
>       octet field as follows:
>
>        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                             |                       |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Note that these two representations are not same.
>
> For example, suppose label is 3. Then in the first representation, it is
> sent
> on the wire as:
>
> 0x00, 0x00, 0x00, 0x03.
>
> Where as, in the 2nd representation, it is sent on the wire as:
>
> 0x00, 0x00, 0x30, 0x00.
>
> Am I missing something?
>
> I request your comments.
>
> Thanks and regards,
> Ramakrishna DTV.
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>
>
>