doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc7734.txt b/doc/rfc/rfc7734.txt
new file mode 100644
index 0000000..bd69b84
--- /dev/null
+++ b/doc/rfc/rfc7734.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                     D. Allan, Ed.
+Request for Comments: 7734                                   J. Tantsura
+Category: Standards Track                                       Ericsson
+ISSN: 2070-1721                                                 D. Fedyk
+                                                                     HPE
+                                                              A. Sajassi
+                                                                   Cisco
+                                                            January 2016
+
+
+  Support for Shortest Path Bridging MAC Mode over Ethernet VPN (EVPN)
+
+Abstract
+
+   This document describes how Ethernet Shortest Path Bridging MAC mode
+   (SPBM) can be combined with Ethernet VPN (EVPN) to interwork with
+   Provider Backbone Bridging Provider Edges (PBB PEs) as described in
+   the PBB-EVPN solution (RFC 7623).  This is achieved via operational
+   isolation of each Ethernet network attached to an EVPN core while
+   supporting full interworking between the different variations of
+   Ethernet networks.
+
+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 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7734.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Allan, et al.                Standards Track                    [Page 1]
+
+RFC 7734                 SPBM Support over EVPN             January 2016
+
+
+Copyright Notice
+
+   Copyright (c) 2016 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
+   (http://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.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Requirements Language ......................................3
+   2. Conventions Used in This Document ...............................3
+      2.1. Terminology ................................................3
+   3. Solution Overview ...............................................4
+   4. Elements of Procedure ...........................................5
+      4.1. PE Configuration ...........................................5
+      4.2. DF Election ................................................6
+      4.3. Control-Plane Interworking ISIS-SPB to EVPN ................6
+      4.4. Control-Plane Interworking EVPN to ISIS-SPB ................7
+      4.5. Data-Plane Interworking SPBM Island or PBB PE to EVPN ......8
+      4.6. Data-Plane Interworking EVPN to SPBM Island ................8
+      4.7. Data-Plane Interworking EVPN to PBB PE .....................8
+      4.8. Multicast Support ..........................................8
+   5. Other Aspects ...................................................8
+      5.1. Transit ....................................................8
+   6. Security Considerations .........................................9
+   7. References .....................................................10
+      7.1. Normative References ......................................10
+      7.2. Informative References ....................................10
+   Acknowledgments ...................................................11
+   Authors' Addresses ................................................11
+
+
+
+
+
+
+
+
+
+
+
+
+Allan, et al.                Standards Track                    [Page 2]
+
+RFC 7734                 SPBM Support over EVPN             January 2016
+
+
+1.  Introduction
+
+   This document describes how Ethernet Shortest Path Bridging MAC mode
+   (SPBM) [IEEE.802.1Q] along with Provider Backbone Bridging Provider
+   Edges (PBB PEs) and Provider Backbone Bridged Networks (PBBNs) can be
+   supported by Ethernet VPNs (EVPNs) such that each SPBM island is
+   operationally isolated while providing full L2 connectivity between
+   the different types of PBBNs where desired.  Each SPBM island uses
+   its own control-plane instance and multipathing design, be it
+   multiple equal-cost tree sets or multiple spanning trees.
+
+   The intention is to permit past, current, and emerging future
+   versions of Ethernet to be seamlessly interconnected to permit large-
+   scale, geographically diverse numbers of Ethernet end systems to be
+   fully supported with EVPN as the unifying system.
+
+1.1.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+2.  Conventions Used in This Document
+
+2.1.  Terminology
+
+   Terms used in this document are used as specified in IEEE
+   802.1Q-2014, which incorporates earlier IEEE 802.1 projects.
+
+   BEB: Backbone Edge Bridge
+   BGP: Border Gateway Protocol
+   B-MAC: Backbone MAC
+   B-VID: Backbone VLAN ID
+   CE: Customer Edge
+   DA: Destination Address
+   DF: Designated Forwarder
+   ESI: Ethernet Segment Identifier
+   EVPN: Ethernet VPN
+   IB-BEB: A BEB that has both an I-component (customer-layer VLAN-aware
+           bridge) and a B-component (backbone-layer VLAN-aware bridge)
+   ISIS-SPB: IS-IS as extended for SPB
+   I-SID: Backbone Service Instance Identifier
+   NLRI: Network Layer Reachability Information
+   PBB: Provider Backbone Bridging as in Clauses 25 and 26 of
+        [IEEE.802.1Q]
+   PBBN: Provider Backbone Bridged Network
+   PBB PE: Co-located BEB and EVPN PE
+   PE: Provider Edge
+
+
+
+Allan, et al.                Standards Track                    [Page 3]
+
+RFC 7734                 SPBM Support over EVPN             January 2016
+
+
+   SPB: Shortest Path Bridging
+   SPBM: Shortest Path Bridging MAC mode as in Clauses 27 and 28 of
+         [IEEE.802.1Q]
+   SPBM-PE: Co-located SPBM<->EVPN interworking function and EVPN PE
+
+3.  Solution Overview
+
+   The EVPN solution for SPBM, as specified in [IEEE.802.1Q],
+   incorporates control-plane interworking in the PE to map ISIS-SPB
+   [RFC6329] information elements into the EVPN Next Layer Reachability
+   Information (NLRI) and vice versa.  This requires each PE to act both
+   as an EVPN BGP speaker and as an ISIS-SPB edge node.  Associated with
+   this are procedures for configuring the forwarding operations of the
+   PE such that an arbitrary number of EVPN-attached SPBM islands can be
+   interconnected without any topological or multipathing dependencies.
+   This model also permits PBB PEs as defined in [RFC7623] to seamlessly
+   communicate with the SPBM islands.
+
+                            +--------------+ +----+   +---+
+                            |              | |PBB |---|CE2|
+                            |              | |PE3 |   +---+
+         +-----+     +----+ |              | +----+
+         |     |-----|SPBM| |              |
+         |SPBM |     |PE1 | |   IP/MPLS    |
+   +---+ |NTWK1|     +----+ |   Network    |
+   |CE1|-|     |            |              |
+   +---+ |     |     +----+ |              |
+         |     |-----|SPBM| |              | +----+   +-----+
+         +-----+     |PE2 | |              | |SPBM|   |SPBM | +---+
+                     +----+ |              | |PE5 |---|NTWK2|-|CE3|
+                            +--------------+ +----+   +-----+ +---+
+
+               Figure 1: PBB and SPBM EVPN Network
+
+   Figure 1 illustrates the generalized space addressed by this memo.
+   SPBM networks may be multihomed onto an IP/MPLS network that
+   implements EVPN for the purpose of interconnecting with other SPBM
+   networks and/or PBB PEs.  The multipathing configuration of each SPBM
+   network can be unique as the backbone VLAN ID (B-VID) configuration
+   (how multipathing is performed in SPBM) is not propagated across the
+   IP/MPLS network implementing EVPN.  As with PBB networking, the B-VID
+   is local to the SPBM network, so in SPBM a B-MAC associated with the
+   B-VID is advertised with the supported I-SIDs at the PBB gateway.
+
+   Each EVPN is identified by a route target.  I-SID-based load-
+   balancing as specified in [RFC7623] allows multiple gateways per
+   B-VID (each with different I-SIDs) across the EVPN; it is supported
+   by the interworking between PBBNs and SPBM networks.  However, SPBM
+
+
+
+Allan, et al.                Standards Track                    [Page 4]
+
+RFC 7734                 SPBM Support over EVPN             January 2016
+
+
+   only allows a single active designated forwarder (DF) per B-VID as
+   described below.  The route target identifies the set of SPBM islands
+   and PBB PEs that are allowed to communicate.  Each SPBM island is
+   administered to have an Ethernet Segment ID (ESI) Label extended
+   community associated with it.
+
+   BGP acts as a common repository of the I-Component Service ID (I-SID)
+   attachment points for the set of attached PEs / SPBM islands.  This
+   is in the form of {B-MAC address, I-SID, Tx-Rx-attribute} tuples.
+   BGP distributes I-SID information into each SPBM island on the basis
+   of locally registered interest.  If an SPBM island has no Backbone
+   Edge Bridges (BEBs) registering interest in a particular I-SID,
+   information about that I-SID from other SPBM islands, PBB PEs, or
+   PBBNs MUST NOT be leaked into the local ISIS-SPB routing system.  For
+   each B-VID in an SPBM island, a single SPBM-PE MUST be elected the DF
+   for the B-VID.  An SPBM-PE can be a DF for more than one B-VID.  This
+   is described further in Section 4.2.  The SPBM-PE originates IS-IS
+   advertisements as if it were an IB-BEB that proxies for the other
+   SPBM islands and PBB PEs in the EVPN defined by the route target, but
+   the PE typically will not actually host any I-components.
+
+   An SPBM-PE that is a DF for a B-VID MUST strip the B-VID tag
+   information from frames relayed towards the EVPN.  The DF MUST also
+   insert the appropriate B-VID tag information into frames relayed
+   towards the SPBM island on the basis of the local I-SID/B-VID
+   bindings advertised in ISIS-SPB.
+
+4.  Elements of Procedure
+
+   A PE MUST implement and perform the following procedures.
+
+4.1.  PE Configuration
+
+   At SPBM island commissioning a PE is configured with:
+
+   1) The route target for the service instance.  Where a route target
+      is defined as identifying the set of SPBM islands, PBBNs and
+      PBB PEs are to be interconnected by the EVPN.
+
+   2) The unique ESI for the SPBM island.  Mechanisms for deriving a
+      unique ESI for the SPBM island are out of scope.
+
+   The following is configured as part of commissioning an ISIS-SPB
+   node:
+
+   1) A Shortest Path Source ID (SPSourceID) used for algorithmic
+      construction of multicast addresses.  Note this is required for
+      SPBM BEB operation independent of the EVPN operation.
+
+
+
+Allan, et al.                Standards Track                    [Page 5]
+
+RFC 7734                 SPBM Support over EVPN             January 2016
+
+
+   2) The set of B-VIDs used in the SPBM island and multipathing
+      algorithm IDs to use for each.  The set of B-VIDs and multipathing
+      algorithms used can be different in different domains.  Therefore,
+      the B-VID is local to an SPBM domain and is removed for frames
+      carried over the IP/MPLS network.
+
+   A Type 1 Route Distinguisher for the node can be auto-derived.  The
+   actual procedure is out of scope for this document.
+
+4.2.  DF Election
+
+   PEs self-appoint themselves for the role of DF for a B-VID for a
+   given SPBM island.  The procedure used is as per Section 8.5
+   (Designated Forwarder Election) of [RFC7432].
+
+   A PE that assumes the role of DF for a given B-VID is responsible for
+   originating specific information into BGP from ISIS-SPB and vice
+   versa.  A PE that ceases to perform the role of DF for a given B-VID
+   is responsible for withdrawing the associated information from BGP
+   and ISIS-SPB, respectively.  The actual information exchanged is
+   outlined in the following sections.
+
+4.3.  Control-Plane Interworking ISIS-SPB to EVPN
+
+   When a PE receives an SPBM service identifier and unicast address
+   sub-TLV as part of an ISIS-SPB MT capability TLV, the PE checks if it
+   is the DF for the B-VID in the sub-TLV.
+
+   If it is the DF, and there is new or changed information, then a
+   MAC/IP advertisement route NLRI is created for each new I-SID in the
+   sub-TLV.  Changed information that results in modification to
+   existing NLRI is processed accordingly.  NLRI creation/modification
+   will ensure:
+
+   -  the Route Distinguisher is set to that of the PE.
+
+   -  the ESI is that of the SPBM island.
+
+   -  the Ethernet Tag ID contains the I-SID (including the Tx/Rx
+      attributes) copied from the SPBM service identifier and unicast
+      address sub-TLV.  The encoding of I-SID information is as per
+      Figure 2.  (See [RFC6329] for details on the T bit and R bit.)
+
+
+
+
+
+
+
+
+
+Allan, et al.                Standards Track                    [Page 6]
+
+RFC 7734                 SPBM Support over EVPN             January 2016
+
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |T|R| Reserved  |                 I-SID                         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+          Figure 2: I-SID Encoding in the Ethernet Tag ID Field
+
+   -  the MAC address is copied from the SPBM service identifier and
+      unicast address sub-TLV
+
+   -  a locally assigned MPLS label (which may be common with other NLRI
+      originated by the PE and is used to map EVPN traffic to the SPBM
+      network)
+
+   Similarly, in the scenario where a PE became elected DF for a B-VID
+   in an operating network, the IS-IS database would be processed in
+   order to construct the NLRI associated with the new role of the PE.
+
+   If the BGP database has NLRI for the I-SID, and this is the first
+   instance of registration of interest in the I-SID from the SPBM
+   island, the NLRI for the I-SID is processed to construct an updated
+   set of SPBM service identifier and unicast address sub-TLVs to be
+   advertised by the PE.
+
+   The ISIS-SPB information is also used to keep current a local table
+   indexed by I-SID to indicate the associated B-VID for processing of
+   frames received from the EVPN.  When an I-SID is associated with more
+   than one B-VID, only one entry is allowed in the table.  Rules for
+   preventing this are out of scope for this memo.
+
+4.4.  Control-Plane Interworking EVPN to ISIS-SPB
+
+   When a PE receives a BGP NLRI that has new information, the PE checks
+   if it is the elected DF to communicate this information into ISIS-SPB
+   by checking if the I-SID in the Ethernet Tag ID locally maps to the
+   B-VID for which it is an elected DF.  Note that if no BEBs in the SPB
+   island have advertised any interest in the I-SID, it will not be
+   associated with any B-VID locally, and therefore will not be of
+   interest.  If the I-SID is of local interest to the SPBM island and
+   the PE is the DF for the B-VID to which the I-SID is locally mapped,
+   a SPBM service identifier and unicast address sub-TLV are
+   constructed/updated for advertisement into ISIS-SPB.
+
+   The NLRI advertised into ISIS-SPB is also used to locally populate a
+   forwarding table indexed by B-MAC + I-SID that points to the label
+   stack to impose on the SPBM frame.  The bottom label in the stack is
+   that obtained from the NLRI.
+
+
+
+Allan, et al.                Standards Track                    [Page 7]
+
+RFC 7734                 SPBM Support over EVPN             January 2016
+
+
+4.5.   Data-Plane Interworking SPBM Island or PBB PE to EVPN
+
+   When a PE receives a frame from the SPBM island in a B-VID for which
+   it is a DF, it looks up the B-MAC/I-SID information to determine the
+   label stack to be added to the frame for forwarding in the EVPN.  The
+   PE strips the B-VID information from the frame, adds the label
+   information to the frame, and forwards the resulting MPLS packet.
+
+4.6.  Data-Plane Interworking EVPN to SPBM Island
+
+   When a PE receives a packet from the EVPN, it can infer the B-VID to
+   overwrite in the SPBM frame from the I-SID or by other means (such as
+   via the bottom label in the MPLS stack).
+
+   If the frame has a local multicast destination address (DA), it
+   overwrites the SPSourceID in the frame with the local SPSourceID.
+
+4.7.  Data-Plane Interworking EVPN to PBB PE
+
+   A PBB PE actually has no attached PBBN nor concept of B-VID, so no
+   frame processing is required.
+
+   A PBB PE is required to accept SPBM-encoded multicast DAs as if they
+   were PBB-encoded (i.e., using the Backbone Service Instance Group
+   address) for multicast DAs.  The only information of interest is that
+   it is a multicast frame and the I-SID encoded in the lower 24 bits.
+
+4.8.  Multicast Support
+
+   Within a PBBN domain, Ethernet unicast and multicast end services are
+   supported.  PBB can tunnel multicast traffic in unicast PBB frames
+   when using head-end replication.  This is the only form of multicast
+   traffic interworking supported by this document.  Native PBB
+   multicast forwarding over EVPN, PE replication, or optimizing PBB
+   multicast across the EVPN is not addressed by this memo.
+
+5.  Other Aspects
+
+5.1.  Transit
+
+   Any PE that does not need to participate in the tandem calculations
+   at the B-MAC layer can use the IS-IS overload bit to exclude SPBM
+   tandem paths and behave as a pure interworking platform.
+
+
+
+
+
+
+
+
+Allan, et al.                Standards Track                    [Page 8]
+
+RFC 7734                 SPBM Support over EVPN             January 2016
+
+
+6.  Security Considerations
+
+   Security issues associated with incorrect interconnection of customer
+   LANs cannot be directly addressed by implementations of this
+   document, as it requires misconfiguration in the Shortest Path
+   Bridging domains.  The identifiers so administered have global
+   significance to the larger system.  They are relayed transparently by
+   EVPN and only policed in the SPBM domains.  Therefore, care is
+   required in synchronization of identifiers that need to be common for
+   inter-domain operation.
+
+   There are only two identifiers unique to this solution provisioned at
+   an SPBM-PE at service turn-up: the route target and the ESI.  The ESI
+   needs to be unique and common to all SPBM-PEs connected to a common
+   SPBM network or PBBN, else portions of the overall network will not
+   share reachability.  (The EVPN will assume that separate networks are
+   interconnected by SPBM.)  Security issues exist when SPBM domains are
+   incorrectly cross-connected together via EVPN; this will result in
+   black-holing or incorrect delivery of data with associated privacy
+   issues.  This error may occur by provisioning the incorrect RT value
+   at an SPBM-PE or associating the RT with the wrong interface.  This
+   error can be avoided by consistency-checking the route target
+   provisioning at SPBM-PEs when performing service additions and/or
+   changes.
+
+   The behavior that is potentially most destructive to the overall
+   system is frequent changes to the DF elections for a given ESI.  This
+   would occur if the SPBM-PEs continuously had their links go up and
+   down in a such a way that the SPBM-PE was being severed from and
+   reconnected to either the IP/MPLS network or the attached SPBM
+   network.  Either of these scenarios would result in significant
+   control-plane traffic as DF associated information was advertised and
+   withdrawn from both the SPBM and BGP control planes.  Dual-homing of
+   SPBM-PEs on both networks would minimize the likelihood of this
+   scenario occurring.
+
+   The issues associated with securing the BGP control plane
+   (independent of this particular memo) are reflected in the Security
+   Considerations section of [RFC4761].
+
+
+
+
+
+
+
+
+
+
+
+
+Allan, et al.                Standards Track                    [Page 9]
+
+RFC 7734                 SPBM Support over EVPN             January 2016
+
+
+7.  References
+
+7.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,
+              <http://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,
+              <http://www.rfc-editor.org/info/rfc4761>.
+
+   [RFC6329]  Fedyk, D., Ed., Ashwood-Smith, P., Ed., Allan, D., Bragg,
+              A., and P. Unbehagen, "IS-IS Extensions Supporting IEEE
+              802.1aq Shortest Path Bridging", RFC 6329,
+              DOI 10.17487/RFC6329, April 2012,
+              <http://www.rfc-editor.org/info/rfc6329>.
+
+   [RFC7432]  Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
+              Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
+              Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
+              2015, <http://www.rfc-editor.org/info/rfc7432>.
+
+7.2. Informative References
+
+   [IEEE.802.1Q]
+              IEEE, "IEEE Standard for Local and metropolitan area
+              networks--Bridges and Bridged Networks", IEEE 802.1Q-2014,
+              DOI 10.1109/ieeestd.2014.6991462, December 2014.
+
+   [RFC7623]  Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W.
+              Henderickx, "Provider Backbone Bridging Combined with
+              Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623,
+              September 2015, <http://www.rfc-editor.org/info/rfc7623>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Allan, et al.                Standards Track                   [Page 10]
+
+RFC 7734                 SPBM Support over EVPN             January 2016
+
+
+Acknowledgments
+
+   The authors would like to thank Peter Ashwood-Smith, Martin Julien,
+   and Janos Farkas for their detailed reviews of this document.
+
+Authors' Addresses
+
+   Dave Allan (editor)
+   Ericsson
+   300 Holger Way
+   San Jose, CA  95134
+   United States
+
+   Email: david.i.allan@ericsson.com
+
+
+   Jeff Tantsura
+   Ericsson
+   300 Holger Way
+   San Jose, CA  95134
+   United States
+
+   Email: jeff.tantsura@ericsson.com
+
+
+   Don Fedyk
+   Hewlett-Packard Enterprise
+   153 Taylor Street
+   Littleton, MA  01460
+   United States
+
+   Email: don.fedyk@hpe.com
+
+
+   Ali Sajassi
+   Cisco
+   170 West Tasman Drive
+   San Jose, CA  95134
+   United States
+
+   Email: sajassi@cisco.com
+
+
+
+
+
+
+
+
+
+
+Allan, et al.                Standards Track                   [Page 11]
+