Different encoding of PW label between LDP-VPLS and BGP-VPLS

[ShahriarBasiri]

Dear Community,

While using Wireshark for checking VPLS control packets, I noticed that the format of encoding PW label in LDP-VPLS is different than BGP-VPLS.

In LDP-VPLS, as shown below, a label mapping message is transferred between PEs targeted session. There is a generic label in this control message which is 4 bytes but 20 lowest bits are actually used for label encoding.

 

But in the case of BGP-VPLS, as shown below, 3 bytes are considered for representing PW label block base in BGP update message, and ironically, 3 experimental bits and 1 bottom of stack bit are also included in this message (while they are not included in LDP-VPLS case). It is also interesting that Wireshark understand this behavior and it discards 4 lowest bits when calculating label base.

Interestingly, the format of encoding PW label is not stated in RFC 4761 and RFC 4762 and I know at least one implementation that is different than Cisco which considers the whole 3 bytes as label base in BGP-VPLS case.

Best Regards.

[Harold Ritter]

Hi @ShahriarBasiri ,

The encoding of the label stack is defined in RFC3032, section 2.1.

 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

The label value field is limited to 20 bits (2^20 = 1,048,576 labels). Any vendor not following this RFC would not be compliant. Can you tell us a bit more about this specific implementation.

Regards,

[ShahriarBasiri]

Dear @Harold Ritter,

You're right. That's how a label is encoded in mpls packets. My question is why in the LDP-VPLS signaling the "exp" and "s" bits are not sent while in BGP-VPLS signaling they are included in the NLRI.

Regards.

[Harold Ritter]

Hi @ShahriarBasiri ,

The experimental bits and bottom of stack bit do not need it to be advertised or handle at the control plane level. They rather need to be set at the data plane level.

The BGP based VPLS signalling does not advertise a label, but rather a label block as per RFC4761, section 3.2.2. 

   +------------------------------------+
      |  Length (2 octets)                 |
      +------------------------------------+
      |  Route Distinguisher  (8 octets)   |
      +------------------------------------+
      |  VE ID (2 octets)                  |
      +------------------------------------+
      |  VE Block Offset (2 octets)        |
      +------------------------------------+
      |  VE Block Size (2 octets)          |
      +------------------------------------+
      |  Label Base (3 octets)             |
      +------------------------------------+

These 2 RFC do not mention anything about the experimental and bottom of stack bits, as it doesn't belong there.

Regards, 

[ShahriarBasiri]

Dear @Harold Ritter ,
Yes, These bits do not need it to be advertised at the control plane level, but please check the wireshark screenshots I sent above. If you pay attention to the value and binary representation of the label base in BGP message, there is "0001" appended to the label base while in LDP message the 20 lowest bits represent the label.

[Harold Ritter]

Hi @ShahriarBasiri ,

That is correct. It looks like the additional 4 bits at the end would represent the experimental and bottom of stack bits. I am not sure what might be the purpose, as RFC4761 does not mention anything about it. But, as I mentioned before, the label base is 20 bits and properly interpreted in the packet capture as 24320 (0x05F00 or 0b0000 0101 1111 0000 0000), so no issue with interoperability as you were initially concerned about.

Regards,

[ShahriarBasiri]

Dear @Harold Ritter ,

Yes, Wireshark interprets it correctly (It's maybe based on Cisco implementation), but here is the problem:

PE1 shows local label base as 24320 which is correct (4 lowest bits are not considered as a part of label) but the other PE interprets it as 389121 which is representation of lowest 20 bits (4 lowest bits are considered as a part of label).

I also didn't find anything about it in RFC4761 and I'm wondering why RFC doesn't specify exactly how to encode label in the message.

Best Regards.

[Harold Ritter]

Hi @ShahriarBasiri ,

I agree the way they display the label is very confusing indeed, but it does not mean that they will not interoperate with Cisco. You need to check the label they use at the data plane level. Can you test the data plane and perform a packet capture?

Regards,

[ShahriarBasiri]

Hi @Harold Ritter ,

This is a data plane packet captured in the provider network:

As you can see, the outer label is 389123 which is label-base (389121) + VE-ID (3) - 1, while the other PE expects to receive 24322.

Best Regards.

[Harold Ritter]

Hi @ShahriarBasiri ,

 The outer label is actually 24324. It is in the label block range and appears to be the VPLS label. 389123 is the inner label and the bottom of stack label as well. Is it possible that this bottom of stack label could be a flow label defined by RFC8395? Please check the LFIB on the egress router to see what is the entry corresponding to 24324.

One more question, is traffic flowing properly?

Regards,

[ShahriarBasiri]

Hi @Harold Ritter  ,

No. CEs can't ping each other.

FAT is not configured on PEs and there are just 2 labels in data-plane packets. 24324 is tunnel label and 389123 is the VPLS label. To be sure, I checked the last link in the provider network (after PHP) and the only label in the packet was 389123.
Best Regards.

[Harold Ritter]

Hi @ShahriarBasiri ,

Sorry for the delay, as I was attending CiscoLive last week. To be quite frank, most of the other vendors I have worked with Interop quite well with Cisco. I am kind of curious about this specific vendor, which don't seem to play well with the Cisco implementation and most probably with other vendors implementation as well. Can you tell us a bit more about that vendor.

Regards,

[ShahriarBasiri]

Hello @Harold Ritter  ,

Thank you for your replies. This is an old version of IPInfusion OcNOS. I checked their latest version and it is now compatible with other vendors (Now the label is encoded in high-order 20 bits).

I'm still wondering whether this behavior is inconsistent with L2VPN RFCs?

It seems that newer RFCs for other protocols have considered this issue. during this week, I found that RFC 8277 explicitly mentions which 20 bits should be used to encode a label in NLRI. As @MHM Cisco World  mentioned, RFC 8317 Also explicitly states that the label should be encoded in high-order 20 bits. But to best of my knowledge, none of the L2VPN RFCs specify how exactly the label should be encoded and this ambiguity in RFCs has caused these 2 different implementations.

[Harold Ritter]

Hi @ShahriarBasiri ,

I believe it was just an RFC misinterpretation on their behalf. The label base should definitely not contain the experimental and bottom of stack bit. They have corrected their mistake and are now able to interoperate with the other vendors out there. At the end of the day, that is what really counts.

Regards,

[MHM Cisco World]

https://community.cisco.com/t5/service-providers-knowledge-base/behavior-change-evpn-esi-label-encoding-in-bgp-extended/ta-p/3992302

check this