summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8614.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8614.txt')
-rw-r--r--doc/rfc/rfc8614.txt507
1 files changed, 507 insertions, 0 deletions
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<n> = 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,
+ <https://www.rfc-editor.org/info/rfc2119>.
+
+ [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,
+ <https://www.rfc-editor.org/info/rfc4761>.
+
+ [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, <https://www.rfc-editor.org/info/rfc4385>.
+
+ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
+ RFC 2119 Key Words", BCP 14, RFC 8174,
+ DOI 10.17487/RFC8174, May 2017,
+ <https://www.rfc-editor.org/info/rfc8174>.
+
+
+
+
+
+
+
+
+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,
+ <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
+
+
+
+
+
+
+
+
+
+
+
+Singh, et al. Standards Track [Page 9]
+