doc: Add RFC documents

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]
+