RFC 8614

Updated Processing of Control Flags for BGP Virtual Private LAN Service (VPLS)

📅 published June 2019, from ietf

RFC 8614: Updated Processing of Control Flags for BGP Virtual Private LAN Service (VPLS) 🎀

Okay bestie, let's get the basics down first 💖 RFC 8614 is called "Updated Processing of Control Flags for BGP Virtual Private LAN Service (VPLS)," and it came out in June 2019 as a Standards Track document in the IETF stream (ISSN 2070-1721). The authors are R. Singh and K. Kompella from Juniper Networks, plus S. Palislamovic from Nokia 🫶. It updates RFC 4761, and the title block doesn't list any other RFC it updates. RFC 4761 is the one that explains how BGP sets up a VPLS, so this RFC is a total glow-up on it ✨

Abstract

This document updates the meaning of the Control Flags field in the "Layer2 Info Extended Community" used for BGP Virtual Private LAN Service (VPLS) Network Layer Reachability Information (NLRI) as defined in RFC 4761. Yep, it updates RFC 4761 again, because that's the main character here 💅

Status of This Memo

This is an Internet Standards Track document 🔥

It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check Section 2 of RFC 7841 📚

For the current status of this document, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc8614.

Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. 🌈

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Simplified BSD License.

Table of Contents 🗺️

   1. Introduction ....................................................2
      1.1. Terminology ................................................3
   2. Problem Description .............................................3
   3. Updated Meaning of Control Flags in the Layer2 Info Extended
      Community .......................................................3
      3.1. Control Word (C-Bit) .......................................4
      3.2. Sequence Flag (S-Bit) ......................................4
   4. Using Point-to-Multipoint (P2MP) LSPs as Transport for
      BGP VPLS ........................................................5
   5. Illustrative Diagram ............................................6
   6. Treatment of C-Bits and S-Bits in Multihoming Scenarios .........7
      6.1. Control Word (C-Bit) .......................................7
      6.2. Sequence Flag (S-Bit) ......................................7
   7. Security Considerations .........................................8
   8. IANA Considerations .............................................8
   9. References ......................................................8
      9.1. Normative References .......................................8
      9.2. Informative References .....................................9
   Authors' Addresses .................................................9

1. Introduction 🌸

Okay so "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling" [RFC4761] is the one that explains the concepts and signaling for using the Border Gateway Protocol (BGP) to set up a VPLS 💜 It defines the BGP VPLS Network Layer Reachability Information (NLRI), which is how a Provider Edge (PE) router may ask other PEs in the same VPLS to include (or not) the Control Word (CW) and sequencing information in VPLS frames sent to that PE.

The CW helps prevent the misordering of IPv4 or IPv6 Pseudowire (PW) traffic over Equal-Cost Multipath (ECMP) paths or Link Aggregation Group (LAG) bundles 🍓 [RFC4385] describes the format for the CW that may be used over point-to-point PWs and over a VPLS. Along with [RFC3985], [RFC4385] also describes sequence number usage for VPLS frames.

However, [RFC4761] does not specify the behavior of PEs in a mixed environment where some PEs support CW/sequencing and others do not 🙈

1.1. Terminology

Now for the rules-of-the-game bit 🧐

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

2. Problem Description 🧩

So [RFC4761] specifies the VPLS BGP NLRI, and each PE uses it to advertise the behavior it expects from all the other PEs participating in the same VPLS 👑 The NLRI indicates the VPLS label that the various PE routers referred to in the NLRI should use when forwarding VPLS traffic to this PE. On top of that, by using the Control Flags, this PE specifies whether the other PEs (in the same VPLS) should use the CW or sequenced delivery for frames forwarded to this PE. Those are the C-bits and the S-bits in the Control Flags, respectively, as specified in Section 3.2.4 in [RFC4761] 💅

Here's the rule from [RFC4761]: if the advertising PE sets the C-bits and S-bits, the receiving PE MUST, respectively, insert a CW and include sequence numbers when forwarding VPLS traffic to the advertising PE 🫶

But in a BGP VPLS deployment, there are often going to be cases where a PE receiving the VPLS BGP NLRI doesn't have the ability to insert a CW or include sequencing information inside PW frames 😭 So the behavior of CW processing and sequencing needs to be specified in more detail.

This document updates the meaning of the Control Flags in the Layer2 Info Extended Community in the BGP VPLS NLRI. It also specifies the forwarding behavior for a mixed-mode environment, where not every PE in a VPLS has the ability or the configuration to honor the Control Flags received from the PE advertising the BGP NLRI ✨

3. Updated Meaning of Control Flags in the Layer2 Info Extended Community 🦋

[RFC4761] doesn't allow the CW setting to be negotiated. In a typical implementation, if a PE sets the C-bit, it expects to receive VPLS frames with a CW, and it will send frames the same way. If the PEs at the two ends of a PW don't agree on the setting of the C-bit, the PW doesn't come up 💀 The behavior is similar for the S-bit.

This memo updates the meaning of the C-bit and the S-bit in the Control Flags 🌈

3.1. Control Word (C-Bit)

If a PE sets the C-bit in its NLRI, it means that the PE has the ability to send and receive frames with a CW.

  • If the PEs at both ends of a PW set the C-bit, CWs MUST be used in both directions of the PW.
  • If both PEs send a C-bit of 0, CWs MUST NOT be used on the PW.

These two cases work just like they always did ✨

But if the PEs at both ends of the PW don't agree on the setting of the C-bit, CWs MUST NOT be used in either direction on that PW, but the PW MUST NOT be prevented from coming up due to this mismatch 🙃 So the PW still comes up, it just won't use the CW in either direction. This is a change from [RFC4761], where the PW didn't come up in that situation.

3.2. Sequence Flag (S-Bit)

If a PE sets the S-bit in its NLRI, it means that the PE has the ability to set sequence numbers as described in Section 4.1 in [RFC4385] and to process sequence numbers as described in Section 4.2 in [RFC4385] 🔢

  • If the PEs at both ends of a PW set the S-bit, non-zero sequence numbers MUST be used in both directions of the PW.
  • If both PEs send an S-bit of 0, sequence numbers MUST NOT be used on the PW.

These two cases work just like they always did 💖

[RFC4761] doesn't allow the S-bit setting to be negotiated either. In a typical implementation, if the PE sets the S-bit in the advertised NLRI, it expects to receive VPLS frames with non-zero sequence numbers, and it will send outgoing frames over the PW with non-zero sequence numbers.

This memo further specifies the expected behavior when the PEs at the ends of the PW advertise differing S-bit values. If the PEs at both ends of the PW don't agree on the setting of the S-bit, then the PW SHOULD NOT come up 🚫 This is to avoid running into out-of-sequence ordering scenarios when the multiple PEs enabling multihoming for a site have differing S-bit advertisements, as described in Section 4.2 in [RFC4385].

However, if a deployment is known to not use multihoming, a user-configurable way to override this recommendation MAY be provided by an implementation, whereby the PW is allowed to come up. In that case, the PE advertising the S-bit as 0 should set sequence numbers in the frames as 0, and the PW receiving the frames should not expect to receive non-zero sequence numbers 🧚

4. Using Point-to-Multipoint (P2MP) LSPs as Transport for BGP VPLS 🌷

BGP VPLS can be used over point-to-point Label Switched Paths (LSPs) acting as transport between the VPLS PEs. Alternately, BGP VPLS may also be used over Point-to-Multipoint (P2MP) LSPs, with the source of the P2MP LSP rooted at the PE advertising the VPLS BGP NLRI 🦄

In a network that uses P2MP LSPs as transport for a VPLS, there may be some PEs that support the CW while others may not. The behavior is similar for the sequencing of VPLS frames 🫧

In such a setup, a source PE that supports CW should set up two different P2MP LSPs such that:

  • One P2MP LSP will transport CW-marked frames to those PEs that advertised the C-bit as 1.
  • The other P2MP LSP will transport frames without the CW to those PEs that advertised the C-bit as 0.

Using two different P2MP LSPs to deliver frames with and without the CW to different PEs ensures that a P2MP root PE honors the C-bit advertised by the other P2MP PEs 👑

However, the set of leaves on the two P2MP LSPs (rooted at the given PE) MUST NOT contain any PEs that advertised a value for the S-bit different from what the root PE itself is advertising 😤 PEs that advertised their S-bit values differently (from what the P2MP root PE advertised) will not be on either of the P2MP LSPs. This ensures that the P2MP root PE is sending VPLS frames only to those PEs that agree on the setting of the S-bit.

The ingress router for the P2MP LSP should send separate NLRIs for the cases of using the CW and for not using the CW 💅

Okay so bestie, we're picking up right where we left off and this part is where the multihoming drama lives 💅🦋 Let's go!

5. Illustrative Diagram ✨

Okay, first up is the picture! 🌸 It's a whole VPLS setup with a bunch of PEs and CEs, and the customer sites are labelled A1 through A5. It's giving main character energy for sure 💖

                                                          -----
                                                         /  A1 \
           ----                                     ____CE1     |
          /    \          --------       --------  /    |       |
         |  A2 CE2-      /        \     /        PE1     \     /
          \    /   \    /          \___/          | \     -----
           ----     ---PE2                        |  \
                       |                          |   \   -----
                       | Service Provider Network |    \ /     \
                       |                          |     CE5  A5
                       |            ___           |   /  \     /
                        \          /   \         PE4_/    -----
                        PE3       /     \       /
                |------/  \-------       -------
         ----  /   |    ----
        /    \/    \   /    \               CE = Customer Edge Device
       |  A3 CE3    --CE4 A4 |              PE = Provider Edge Router
        \    /         \    /
         ----           ----                A<n> = Customer site n

                        Figure 1: Example of a VPLS

Now the setup, ngl this is the spicy part 🌶️ Imagine a VPLS configured with the PEs exactly as drawn. PE1 is the one we're watching, and it's CW enabled and sequencing enabled 🔥 PE2 and PE3 are also CW enabled and sequencing enabled, so they're the cool kids 😎 PE4 though? It's NOT CW enabled and it can't include sequence numbers 💀

So here's the flow. PE1 advertises a VPLS BGP NLRI with the C/S-bits both set to 1 💜 PE2 and PE3 hear that and start putting the CW and non-zero sequence numbers in the VPLS frames they send back to PE1, just like Section 4 in [RFC4385] says 🦋 PE4 can't do any of that, so it just... doesn't 🙈

Here's the catch. PE1 expects all the other PEs to send CW-containing frames with non-zero sequence numbers, and PE4 literally cannot deliver that 😭 So, as per [RFC4761], the PW between PE1 and PE4 does not come up. Bestie, that's a whole no 💀

BUT, and this is the iconic twist ✨ this document is about how an implementation should handle BGP VPLS when only SOME of the PEs support the CW and/or frame sequencing 👑 PE1 won't bring up the PW with PE4 because of the S-bit mismatch, UNLESS local configuration on PE1 and PE4 overrides it, as laid out in Section 3.2 🎀 And if PE4 instead advertised a C-bit of 0 and an S-bit of 1, the PW between PE1 and PE4 WOULD come up even with the CW mismatch 🌈

Now the data plane stuff, it's very cute actually 🧚 PE1 only strips the CW from VPLS frames received from PEs that said they want CW-marked frames. So PE2 and PE3? Stripped ✂️ And PE1 expects those PW frames to have non-zero sequence numbers, like Section 4.2 in [RFC4385] describes 💖 PE1 does NOT strip the CW from frames coming from PE4, and it expects PE4 to send frames with non-zero sequence numbers. Spoiler: PE4 is sending all its PW frames to PE1 with a non-zero sequence number 🫶

6. Treatment of C-Bits and S-Bits in Multihoming Scenarios ✨

Okay bestie, multihoming is where things get messy and I'm obsessed 😭 Different PEs can effectively represent the same service destination endpoint, so it's tempting to think the end-to-end PW setup should follow the same CW rules on both the primary and the backup designated forwarders 🦋

6.1. Control Word (C-Bit) 🌸

Here's the thing though: in the multihoming case, each PW SHOULD be evaluated independently 💅 Using the topology from Section 5, the PW between PE2 and PE1 could have the CW signaled via the extended community and actually use it in the VPLS frame. Meanwhile, the PE2-to-PE4 PW would NOT insert the CW because of a C-bit mismatch 💀 Everything else about how the other PEs behave in multihoming should just follow [VPLS-MULTIHOMING] 🎀

6.2. Sequence Flag (S-Bit) 🧚

For S-bits, the rules for end-to-end PW establishment SHOULD follow the same behavior as Section 3.2 describes 💖 Same energy as the CW situation: the S-bit evaluation SHOULD be independent per PW 🔥

Now the example. CE5 is connected to multiple PEs, PE4 and PE1 🦋 PE4 doesn't set the S-bit in its advertised NLRI, so there's an S-bit mismatch between PE1 and PE4, and that mismatch blocks the PW from coming up 😭 That leaves only ONE PW, between PE1 and PE2, for this multihomed site 🌈

So even though CE5 is physically multihomed, there's no PW between PE2 and PE4, because PE4 can't send frames with non-zero sequence numbers. Basically CE5 is not really multihomed, bestie 💀🫶

7. Security Considerations 🔐

Okay this section is serious, so buckle up 👑

This document updates the behavior specified in [RFC4761], and the security considerations in [RFC4761] still apply 💅 This document is mostly about BGP VPLS behavior for PEs when the C-bit value, the S-bit value, or both are different from what another PE in the VPLS is advertising 🦋

Any bit-flipping media errors that cause a C/S-bit mismatch between PEs do NOT hurt PW availability 🌈 Instead, they cause CWs to not be used, or they cause the NLRI-advertising PE to not expect non-zero sequenced frames, depending on whether the C-bit or the S-bit is the one that got mismatched 🙈 And honestly? That's no worse than before, when a bit-flipping error causing a C/S-bit mismatch would stop the PW from coming up at all ✨

8. IANA Considerations 🧚

Good news, this one's easy: this document has no IANA actions 🎀

9. References 📚

9.1. Normative References 💜

9.2. Informative References 🌸

  • [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, DOI 10.17487/RFC3985, March 2005, <https://www.rfc-editor.org/info/rfc3985>.
  • [VPLS-MULTIHOMING] Kothari, B., Kompella, K., Henderickx, W., Balus, F., and J. Uttaro, "BGP based Multi-homing in Virtual Private LAN Service", Work in Progress, draft-ietf-bess-vpls-multihoming-03, March 2019.

Authors' Addresses 🫶

  • Ravi Singh Juniper Networks 1133 Innovation Way Sunnyvale, CA 94089 United States of America Email: ravis@juniper.net
  • Kireeti Kompella Juniper Networks 1133 Innovation Way Sunnyvale, CA 94089 United States of America Email: kireeti@juniper.net
  • Senad Palislamovic Nokia 600 Mountain Avenue Murray Hill, NJ 07974-0636 United States of America Email: Senad.palislamovic@nokia.com
📦 where this page comes from