From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8614.txt | 507 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 507 insertions(+) create mode 100644 doc/rfc/rfc8614.txt (limited to 'doc/rfc/rfc8614.txt') diff --git a/doc/rfc/rfc8614.txt b/doc/rfc/rfc8614.txt new file mode 100644 index 0000000..b11e264 --- /dev/null +++ b/doc/rfc/rfc8614.txt @@ -0,0 +1,507 @@ + + + + + + +Internet Engineering Task Force (IETF) R. Singh +Request for Comments: 8614 K. Kompella +Updates: 4761 Juniper Networks +Category: Standards Track S. Palislamovic +ISSN: 2070-1721 Nokia + June 2019 + + + Updated Processing of Control Flags for + BGP Virtual Private LAN Service (VPLS) + +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. This document updates RFC 4761. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8614. + +Copyright Notice + + 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, as 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 are provided without warranty as + described in the Simplified BSD License. + + + + + +Singh, et al. Standards Track [Page 1] + +RFC 8614 Control Flags for BGP VPLS June 2019 + + +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 + + "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and + Signaling" [RFC4761] describes the concepts and signaling for using + the Border Gateway Protocol (BGP) to set up a VPLS. It specifies the + BGP VPLS Network Layer Reachability Information (NLRI) by which a + Provider Edge (PE) router may require other PEs in the same VPLS to + include (or not) the Control Word (CW) and sequencing information in + VPLS frames sent to this PE. + + The use of 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. + + + + + + + + + + +Singh, et al. Standards Track [Page 2] + +RFC 8614 Control Flags for BGP VPLS June 2019 + + +1.1. Terminology + + 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 + + [RFC4761] specifies the VPLS BGP NLRI by which a given PE advertises + the behavior expected by the multiple PEs participating in the same + VPLS. The NLRI indicates the VPLS label that the various PE routers, + which are referred to in the NLRI, should use when forwarding VPLS + traffic to this PE. Additionally, 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. These are + indicated by the C-bits and the S-bits, respectively, in the Control + Flags, as specified in Section 3.2.4 in [RFC4761]. + + [RFC4761] requires that 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. + + However, in a BGP VPLS deployment, there would often be cases where a + PE receiving the VPLS BGP NLRI may not have the ability to insert a + CW or include sequencing information inside PW frames. Thus, the + behavior of CW processing and sequencing needs to be further + specified. + + 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] does not allow for 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 will send frames the same way. If the PEs + at the two ends of a PW do not agree on the setting of the C-bit, the + PW does not 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. + + + + +Singh, et al. Standards Track [Page 3] + +RFC 8614 Control Flags for BGP VPLS June 2019 + + +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 behave as before. + + However, if the PEs at both ends of the PW do not 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 will still come up but will not use the CW in + either direction. This behavior is changed from the behavior + described in [RFC4761] where the PW does not come up. + +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 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 behave as before. + + [RFC4761] does not allow for 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 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 do not 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 that are 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 utilize multihoming, a user-configurable way to override + + + +Singh, et al. Standards Track [Page 4] + +RFC 8614 Control Flags for BGP VPLS June 2019 + + + 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. + + + + + + + + + + + +Singh, et al. Standards Track [Page 5] + +RFC 8614 Control Flags for BGP VPLS June 2019 + + +5. Illustrative Diagram + + ----- + / 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 = Customer site n + + Figure 1: Example of a VPLS + + In the above topology, let there be a VPLS configured with the PEs as + displayed. Let PE1 be the PE under consideration that is CW enabled + and sequencing enabled. Let PE2 and PE3 also be CW enabled and + sequencing enabled. Let PE4 not be CW enabled or have the ability to + include sequence numbers. PE1 will advertise a VPLS BGP NLRI, + containing the C/S-bits marked as 1. PE2 and PE3, on learning of the + NLRI from PE1, will include the CW and non-zero sequence numbers in + the VPLS frames being forwarded to PE1 as described in Section 4 in + [RFC4385]. However, PE4, which does not have the ability to include + a CW or include non-zero sequence numbers, will not. + + As per [RFC4761], PE1 would expect all other PEs to forward + CW-containing frames that have non-zero sequence numbers. That + expectation cannot be met by PE4 in this example. Thus, as per + [RFC4761], the PW between PE1 and PE4 does not come up. + + However, this document addresses how an implementation should support + BGP VPLS in a network where a subset of the BGP VPLS PEs support the + CW and/or frame sequencing. PE1 will not bring up the PW with PE4 + due to the S-bit mismatch, unless overridden by local configuration + on PE1 and PE4 as specified in Section 3.2. If PE4 instead was to + advertise a C-bit of 0 and an S-bit of 1, then the PW between PE1 and + PE4 would come up despite the CW mismatch. Additionally, PE1 would + set up its data plane such that it will strip the CW only for those + + + +Singh, et al. Standards Track [Page 6] + +RFC 8614 Control Flags for BGP VPLS June 2019 + + + VPLS frames that are received from PEs that have indicated their + desire to receive CW-marked frames. So, PE1 will set up its data + plane to strip the CW only for VPLS frames received from PE2 and PE3, + and it will expect to process PW frames containing non-zero sequence + numbers as described in Section 4.2 in [RFC4385]. PE1 will set up + its data plane to not strip the CW from frames received from PE4, and + it would expect PE4 to send frames with non-zero sequence numbers. + All frames sent by PE4 to PE1 over the PW would have a non-zero + sequence number. + +6. Treatment of C-Bits and S-Bits in Multihoming Scenarios + +6.1. Control Word (C-Bit) + + In a multihomed environment, different PEs may effectively represent + the same service destination endpoint. It could be assumed that the + end-to-end PW establishment process should follow the same rules when + it comes to CW requirements, meaning that setting the C-bit would be + enforced equally toward both primary and backup designated + forwarders. + + However, in the multihoming case, each PW SHOULD be evaluated + independently. Assuming the network topology specified in Section 5, + there could be the case where the PW between PE2 and PE1 could have + the CW signaled via the extended community and would be used in the + VPLS frame, while the PE2-to-PE4 PW would not insert the CW in the + VPLS frame due to a C-bit mismatch. The multihoming behavior of the + rest of the PEs should simply follow the rules specified in + [VPLS-MULTIHOMING]. + +6.2. Sequence Flag (S-Bit) + + In a multihomed environment, different PEs may effectively represent + the same service destination endpoint. In this case, the rules for + end-to-end PW establishment SHOULD follow the same behavior as that + described in Section 3.2 when it comes to S-bit requirements. + Consider the case described in Section 5 with CE5 having a connection + to multiple PEs (multihomed) to PE4 and PE1. The PW's behavior is + similar to that for the CW scenario such that the S-bit evaluation + SHOULD be independent per PW. So, in the case where PE4 does not set + the S-bit in its advertised NLRI, there is an S-bit mismatch between + PE1 and PE4. This mismatch prevents the PW establishment between PE1 + and PE4. So, only one PW -- between PE1 and PE2 -- would be + established for the multihomed site shown. Thus, even though CE5 is + physically multihomed, due to PE4's lack of support for sending + frames with non-zero sequence numbers, there would be no PW between + PE2 and PE4. CE5 would effectively not be multihomed. + + + + +Singh, et al. Standards Track [Page 7] + +RFC 8614 Control Flags for BGP VPLS June 2019 + + +7. Security Considerations + + This document updates the behavior specified in [RFC4761]. The + security considerations discussed in [RFC4761] apply. This document + essentially addresses BGP VPLS behavior for PEs when the C-bit value, + the S-bit value, or both values advertised by a given PE are + different from what another PE in the VPLS is advertising. Any + bit-flipping media errors leading to causing this mismatch of + C/S-bits between PEs do not adversely affect the availability of the + PWs. Rather, they cause CWs to not be used or cause the + NLRI-advertising PE to not expect non-zero sequenced frames, for the + C-bit and the S-bit, respectively, being mismatched across PEs. This + is no worse than the previous behavior where any bit-flipping media + errors leading to a mismatch of the C/S-bits between PEs would cause + the PW to not come up. + +8. IANA Considerations + + This document has no IANA actions. + +9. References + +9.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private + LAN Service (VPLS) Using BGP for Auto-Discovery and + Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, + . + + [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, + "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for + Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, + February 2006, . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in + RFC 2119 Key Words", BCP 14, RFC 8174, + DOI 10.17487/RFC8174, May 2017, + . + + + + + + + + +Singh, et al. Standards Track [Page 8] + +RFC 8614 Control Flags for BGP VPLS June 2019 + + +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, + . + + [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 + + + + + + + + + + + +Singh, et al. Standards Track [Page 9] + -- cgit v1.2.3