Re: [mpls] Label encoding in LDP

Hi Ramakrishna,

Per my understanding, RFC 3036 says that 20-bit value to be filled in to 32-bit field. It doesn't say that it should be encoded in 20 most significant bits, hence, it is to be encoded in 20 least significant bits. RFC 3036 refers to RFC 3032 regarding what is 20-bit label entity, not regarding label value positioning in 32-bit field. On the other hand, RFC 5036 provides additional figure, where it is explicitly shown, that label value to be encoded in 20 most significant bits of 32-bit field, like it is being done for label value in label stack entry per RFC 3032. However, "label" and "label in label stack entry" are not the same things, though they are both - label field in Generic Label TLV in RFC 3036 and label stack entry in RFC 3032 - 32 bits in length. Hence, in your case netbsd implementation and another commercial implementation follow encoding rules from RFC 3036.

This difference between RFC 3036 and RFC 5036 means that implementations, that follow RFC 5036 in part of generic label encoding, are not backward compatible with RFC 3036 based implementations.

> 21 июня 2019 г., в 14:50, Ramakrishna Rao Desetti <ramakrishnadtv@gmail.com> написал(а):
> 
> 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 <mailto: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 <mailto: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 <mailto:mpls@ietf.org>
>> https://www.ietf.org/mailman/listinfo/mpls <https://www.ietf.org/mailman/listinfo/mpls>
> 