< draft-ietf-bess-spbm-evpn-00.txt   draft-ietf-bess-spbm-evpn-01.txt >
BESS Working Group Dave Allan, Jeff Tantsura BESS Working Group Dave Allan, Jeff Tantsura
Internet Draft Ericsson Internet Draft Ericsson
Intended status: Standards Track Don Fedyk Intended status: Standards Track Don Fedyk
Expires: February 2016 HP Expires: April 2016 HP
Ali Sajassi Ali Sajassi
Cisco Cisco
July 2015 September 2015
Shortest Path Bridging, MAC Mode Support over EVPN Shortest Path Bridging, MAC Mode Support over EVPN
draft-ietf-bess-spbm-evpn-00 draft-ietf-bess-spbm-evpn-01
Abstract Abstract
This document describes how Ethernet Shortest Path Bridging MAC mode This document describes how Ethernet Shortest Path Bridging MAC mode
(802.1aq) can be combined with EVPN in a way that interworks with (802.1aq) can be combined with EVPN to interwork with PBB-PEs as
PBB-PEs as described in the PBB-EVPN solution. This is achieved via described in the PBB-EVPN solution. This is achieved via
operational isolation of each Ethernet network subtending an EVPN operational isolation of each Ethernet network subtending an EVPN
core while supporting full interworking between the different core while supporting full interworking between the different
variations of Ethernet networks. variations of Ethernet networks.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance This Internet-Draft is submitted to IETF in full conformance
with the provisions of BCP 78 and BCP 79. with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Internet-Drafts are working documents of the Internet
skipping to change at page 2, line 19 skipping to change at page 2, line 19
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described document must include Simplified BSD License text as described
in Section 4.e of the Trust Legal Provisions and are provided in Section 4.e of the Trust Legal Provisions and are provided
without warranty as described in the Simplified BSD License. without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................2
1.1. Authors......................................................3 1.1. Requirements Language........................................3
1.2. Requirements Language........................................3
2. Conventions used in this document..............................3 2. Conventions used in this document..............................3
2.1. Terminology..................................................3 2.1. Terminology..................................................3
3. Solution Overview..............................................4 3. Solution Overview..............................................4
4. Elements of Procedure..........................................5 4. Elements of Procedure..........................................5
4.1. PE Configuration.............................................5 4.1. PE Configuration.............................................5
4.2. DF Election..................................................6 4.2. DF Election..................................................6
4.3. Control plane interworking ISIS-SPB to EVPN..................6 4.3. Control plane interworking ISIS-SPB to EVPN..................6
4.4. Control plane interworking EVPN to ISIS-SPB..................7 4.4. Control plane interworking EVPN to ISIS-SPB..................7
4.5. Data plane Interworking 802.1aq SPBM island or PBB-PE to 4.5. Data plane Interworking 802.1aq SPBM island or PBB-PE to
EVPN..............................................................8 EVPN..............................................................8
4.6. Data plane Interworking EVPN to 802.1aq SPBM island..........8 4.6. Data plane Interworking EVPN to 802.1aq SPBM island..........8
4.7. Data plane interworking EVPN to 802.1ah PBB-PE...............8 4.7. Data plane interworking EVPN to 802.1ah PBB-PE...............8
4.8. Multicast Support............................................8 4.8. Multicast Support............................................8
5. Other Aspects..................................................8 5. Other Aspects..................................................9
5.1. Flow Ordering................................................8 5.1. Transit......................................................9
5.2. Transit......................................................8
6. Acknowledgements...............................................9 6. Acknowledgements...............................................9
7. Security Considerations........................................9 7. Security Considerations........................................9
8. IANA Considerations............................................9 8. IANA Considerations...........................................10
9. References.....................................................9 9. References....................................................10
9.1. Normative References.........................................9 9.1. Normative References........................................10
[RFC4761] Kompella (ed.), "Virtual Private LAN Service (VPLS)
Using BGP for Auto-Discovery and Signaling", IETF RFC 4761, January
2007 9
9.2. Informative References......................................10 9.2. Informative References......................................10
10. Authors' Addresses...........................................10 10. Authors' Addresses...........................................11
1. Introduction 1. Introduction
This document describes how Ethernet Shortest Path Bridging MAC mode This document describes how Ethernet Shortest Path Bridging MAC mode
(802.1aq) along with PBB-PEs and PBBNs (802.1ah) can be supported by (SPBM) along with Provider Backbone Bridging Provider Edges (PBB-PEs)
EVPN such that each island is operationally isolated while providing and Provider Backbone Bridged Networks (PBBNs) can be supported by
full L2 connectivity between them. Each island can use its own Ethernet VPNs (EVPNs) such that each SPBM island is operationally
control plane instance and multi-pathing design, be it multiple ECT isolated while providing full L2 connectivity between the different
sets, or multiple spanning trees. types of PBBNs where desired. Each SPBM island uses its own control
plane instance and multi-pathing design, be it multiple equal cost
The intention is to permit both past, current and emerging future tree sets, or multiple spanning trees.
versions of Ethernet to be seamlessly integrated to permit large
scale, geographically diverse numbers of Ethernet end systems to be
fully supported with EVPN as the unifying agent.
1.1. Authors
David Allan, Jeff Tantsura, Don Fedyk, Ali Sajassi 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.2. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [RFC2119]. document are to be interpreted as described in RFC2119 [RFC2119].
2. Conventions used in this document 2. Conventions used in this document
2.1. Terminology 2.1. Terminology
BEB: Backbone Edge Bridge BEB: Backbone Edge Bridge
BGP: Border Gateway Protocol
B-MAC: Backbone MAC Address B-MAC: Backbone MAC Address
B-VID: Backbone VLAN ID B-VID: Backbone VLAN ID
CE: Customer Edge CE: Customer Edge
DA: Destination Address
DF: Designated Forwarder DF: Designated Forwarder
ESI: Ethernet Segment Identifier ESI: Ethernet Segment Identifier
EVPN: Ethernet VPN EVPN: Ethernet VPN
IB-BEB: A BEB that has both an I-component (customer layer VLAN IB-BEB: A BEB that has both an I-component (customer layer VLAN
aware bridge) and a B-component (backbone layer VLAN aware aware bridge) and a B-component (backbone layer VLAN aware
bridge) bridge)
ISIS-SPB: IS-IS as extended for SPB ISIS-SPB: IS-IS as extended for SPB
I-SID: I-Component Service ID I-SID: I-Component Service ID
NLRI: Network Layer Reachability Information NLRI: Network Layer Reachability Information
PBB: Provider Backbone Bridging (802.1ah)
PBBN: Provider Backbone Bridged Network PBBN: Provider Backbone Bridged Network
PBB-PE: Co located 802.1ah BEB and EVPN PE PBB-PE: Co located 802.1ah BEB and EVPN PE
PE: Provider Edge PE: Provider Edge
SPB: Shortest Path Bridging SPB: Shortest Path Bridging
SPBM: Shortest Path Bridging MAC mode SPBM: Shortest Path Bridging MAC mode
SPBM-PE: Co-located 802.1aq SPBM<->EVPN interworking function and SPBM-PE: Co-located 802.1aq SPBM<->EVPN interworking function and
EVPN PE EVPN PE
3. Solution Overview 3. Solution Overview
The EVPN solution for 802.1aq SPBM incorporates control plane The EVPN solution for 802.1aq SPBM incorporates control plane
interworking in the PE to map ISIS-SPB [RFC6329] information elements interworking in the PE to map ISIS-SPB [RFC6329] information elements
into the EVPN NLRI information and vice versa. This requires each PE into the EVPN Next Layer Reachabilty Information (NLRI) and vice
to act both as an EVPN BGP speaker and as an ISIS-SPB edge node. versa. This requires each PE to act both as an EVPN BGP speaker and
Associated with this are procedures for configuring the forwarding as an ISIS-SPB edge node. Associated with this are procedures for
operations of the PE such that an arbitrary number of EVPN subtending configuring the forwarding operations of the PE such that an
SPBM islands may be interconnected without any topological or arbitrary number of EVPN subtending SPBM islands may be
multipathing dependencies. This model also permits PBB-PEs as defined interconnected without any topological or multipathing dependencies.
in [PBB-EVPN] to be seamlessly communicate with the SPB islands. This model also permits PBB-PEs as defined in [PBB-EVPN] to
seamlessly communicate with the SPBM islands.
+--------------+ +--------------+ +----+ +---+
| | | | |PBB |---|CE2|
| | | | |PE3 | +---+
+-----+ +----+ | | +----+ +---+ +-----+ +----+ | | +----+
| |-----|SPBM| | | |PBB |---|CE2| | |-----|SPBM| | |
|SPBM | |PE1 | | IP/MPLS | |PE1 | +---+ |SPBM | |PE1 | | IP/MPLS |
+---+ |NTWK1| +----+ | Network | +----+ +---+ |NTWK1| +----+ | Network |
|CE1|-| | | | |CE1|-| | | |
+---+ | | +----+ | | +---+ | | +----+ | |
| |-----|SPBM| | | +----+ +-----+ | |-----|SPBM| | | +----+ +-----+
+-----+ |PE2 | | | |SPBM| |SPBM | +---+ +-----+ |PE2 | | | |SPBM| |SPBM | +---+
+----+ | | |PE3 |---|NTWK2|-|CE3| +----+ | | |PE5 |---|NTWK2|-|CE3|
+--------------+ +----+ +-----+ +---+ +--------------+ +----+ +-----+ +---+
Figure 1: PBB and SPBM EVPN Network Figure 1: PBB and SPBM EVPN Network
Each EVPN is identified by a route target. The route target Figure 1 illustrates the generalized space addressed by this memo.
identifies the set of SPBM islands and PBB-PEs that are allowed to SPBM networks may be multi-homed onto an IP/MPLS network that
communicate. Each SPBM island is administered to have an associated implements EVPN for the purpose of interconnect with other SPBM
Ethernet Segment ID (ESI) associated with it. This manifests itself networks, and/or PBB PEs. The multipathing configuration of each SPBM
as a set of Ethernet segments, where each ESI is unique within the network can be unique as the backbone VLAN ID (B-VID) configuration
route target. (how multi-pathing is performed in SPBM) is not propagated across the
BGP acts as a common repository of the I-SID attachment points for IP/MPLS network implementing EVPN. As with PBB networking the B-VID
the set of subtending PEs/SPBM islands. This is in the form of B-MAC is local to the SPBM network so in SPBM a B-MAC associated with B-VID
address/I-SID/Tx-Rx-attribute tuples. BGP filters leaking I-SID is advertised with the supported I-SIDs at the PBB gateway.
information into each SPBM island on the basis of locally registered
interest. If an SPBM island has no BEBs registering interest in an I- Each EVPN is identified by a route target. I-SID Based Load-balancing
SID, information about that I-SID from other SPBM islands, PBB-PEs or in [PBB-EVPN] which allows multiple gateways per B-VID (each with
different I-SIDs) across the EVPN is supported by the interworking
between PBBNs and SPBM networks. However SPBM only allows a single
active designated forwarder 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
associated Ethernet Segment ID (ESI) 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 subtending 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. 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 For each B-VID in an SPBM island, a single SPBM-PE MUST be elected
the designated forwarder for the B-VID. An SPBM-PE may be a DF for the designated forwarder (DF) for the B-VID. An SPBM-PE may be a DF
more than one B-VID. This is described further in section 5.2. The for more than one B-VID. This is described further in section 4.2.
SPBM-PE originates IS-IS advertisements as if it were an IB-BEB that The SPBM-PE originates IS-IS advertisements as if it were an IB-BEB
proxies for the other SPBM islands and PBB PEs in the EVPN defined by that proxies for the other SPBM islands and PBB PEs in the EVPN
the route target, but the PE typically will not actually host any I- defined by the route target, but the PE typically will not actually
components. host any I-components.
An SPBM-PE that is a DF for a B-VID MUST strip the B-VID tag 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 information from frames relayed towards the EVPN. The DF MUST also
insert the appropriate B-VID tag information into frames relayed insert the appropriate B-VID tag information into frames relayed
towards the SPBM island on the basis of the local I-SID/B-VID towards the SPBM island on the basis of the local I-SID/B-VID
bindings advertised in ISIS-SPB. bindings advertised in ISIS-SPB.
4. Elements of Procedure 4. Elements of Procedure
A PE MUST implement the following procedures: A PE MUST implement the following procedures:
skipping to change at page 5, line 42 skipping to change at page 6, line 12
At SPBM island commissioning a PE is configured with: At SPBM island commissioning a PE is configured with:
1) The route target for the service instance. Where a route target 1) The route target for the service instance. Where a route target
is defined as identifying the set of SPBM islands, PBBNs and PBB- is defined as identifying the set of SPBM islands, PBBNs and PBB-
PEs to be interconnected by the EVPN. PEs to be interconnected by the EVPN.
2) The unique ESI for the SPBM island. Mechanisms for deriving a 2) The unique ESI for the SPBM island. Mechanisms for deriving a
unique ESI for the SPBM island are out of scope. unique ESI for the SPBM island are out of scope.
And the following is configured as part of commissioning an ISIS-SPB The following is configured as part of commissioning an ISIS-SPB
node: node:
1) A Shortest Path Source ID (SPSourceID) used for algorithmic 1) A Shortest Path Source ID (SPSourceID) used for algorithmic
construction of multicast addresses. Note this is required for construction of multicast addresses. Note this is required for
SPBM BEBs independent of the EVPN operation. SPBM BEB operation independent of the EVPN operation.
2) The set of VLANs (identified by B-VIDs) used in the SPBM island 2) The set of B-VIDs used in the SPBM island and multi-pathing
and multi-pathing algorithm IDs to use. The set of B-VIDs and algorithm IDs to use for each. The set of B-VIDs and multi-
multi-pathing algorithms used may be different in different pathing algorithms used may be different in different domains.
domains. Therefore the B-VID is local to an SPBM domain and is Therefore the B-VID is local to an SPBM domain and is removed for
removed for frames carried over the IP/MPLS network. frames carried over the IP/MPLS network.
A type-1 Route Distinguisher for the node can be auto-derived. The A type-1 Route Distinguisher for the node can be auto-derived. The
actual procedure is out of scope of this document. actual procedure is out of scope of this document.
4.2. DF Election 4.2. DF Election
PEs self appoint in the role of DF for a B-VID for a given SPBM PEs self appoint themselves for the role of DF for a B-VID for a
island. The procedure used is as per section 8.5 of [RFC7432] given SPBM island. The procedure used is as per section 8.5 of
"Designated Forwarder election". [RFC7432] "Designated Forwarder election".
A PE that assumes the role of DF for a given B-VID is responsible for 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 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 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 is responsible for withdrawing the associated information from BGP
and ISIS-SPB respectively. The actual information exchanged is and ISIS-SPB respectively. The actual information exchanged is
outlined in the following sections. outlined in the following sections.
4.3. Control plane interworking ISIS-SPB to EVPN 4.3. Control plane interworking ISIS-SPB to EVPN
When a PE receives an SPBM service identifier and unicast address When a PE receives an SPBM service identifier and unicast address
skipping to change at page 7, line 19 skipping to change at page 7, line 31
- a locally assigned MPLS label - a locally assigned MPLS label
Similarly in the scenario where a PE became elected DF for a B-VID in 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 an operating network, the IS-IS database would be processed in order
to construct the NLRI information associated with the new role of the to construct the NLRI information associated with the new role of the
PE. PE.
If the BGP database has NLRI information for the I-SID, and this is If the BGP database has NLRI information for the I-SID, and this is
the first instance of registration of interest in the I-SID from the the first instance of registration of interest in the I-SID from the
SPB island, the NLRI information with that tag is processed to SPBM island, the NLRI information with that tag is processed to
construct an updated set of SPBM service identifier and unicast construct an updated set of SPBM service identifier and unicast
address sub-TLVs to be advertised by the PE. address sub-TLVs to be advertised by the PE.
The ISIS-SPB information is also used to keep current a local table 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 indexed by I-SID to indicate the associated B-VID for processing of
frames received from EVPN. When an I-SID is associated with more than frames received from EVPN. When an I-SID is associated with more than
one B-VID, only one entry is allowed in the table. Rules for one B-VID, only one entry is allowed in the table. Rules for
preventing this are out of scope of this memo. preventing this are out of scope of this memo.
4.4. Control plane interworking EVPN to ISIS-SPB 4.4. Control plane interworking EVPN to ISIS-SPB
skipping to change at page 8, line 19 skipping to change at page 8, line 28
label stack to be added to the frame for forwarding in the EVPN. 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 PE strips the B-VID information from the frame, adds the label
information to the frame and forwards the resulting MPLS packet. information to the frame and forwards the resulting MPLS packet.
4.6. Data plane Interworking EVPN to 802.1aq SPBM island 4.6. Data plane Interworking EVPN to 802.1aq SPBM island
When a PE receives a packet from the EVPN it may infer the B-VID to When a PE receives a packet from the EVPN it may infer the B-VID to
overwrite in the SPBM frame from the I-SID or by other means (such as overwrite in the SPBM frame from the I-SID or by other means (such as
via the bottom label in the MPLS stack). via the bottom label in the MPLS stack).
If the frame has a local multicast DA, it overwrites the SPsourceID If the frame has a local multicast destination address (DA), it
in the frame with the local SPsourceID. overwrites the SPsourceID in the frame with the local SPsourceID.
4.7. Data plane interworking EVPN to 802.1ah PBB-PE 4.7. Data plane interworking EVPN to 802.1ah PBB-PE
A PBB-PE actually has no subtending PBBN nor concept of B-VID so no A PBB-PE actually has no subtending PBBN nor concept of B-VID so no
frame processing is required. frame processing is required.
A PBB-PE is required to accept SPBM encoded multicast DAs as if they A PBB-PE is required to accept SPBM encoded multicast DAs as if they
were 802.1ah encoded multicast DAs. The only information of interest were 802.1ah encoded multicast DAs. The only information of interest
being that it is a multicast frame, and the I-SID encoded in the being that it is a multicast frame, and the I-SID encoded in the
lower 24 bits. lower 24 bits.
4.8. Multicast Support 4.8. Multicast Support
Not addressed by this memo. 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. Other Aspects
5.1. Flow Ordering 5.1. Transit
When per I-SID multicast is implemented via PE replication, a stable
network will preserve frame ordering between known unicast and
broadcast/unknown/multicast traffic (e.g. race conditions will not
exist). This cannot be guaranteed when multicast is used in the EVPN.
5.2. Transit
Any PE that does not need to participate in the tandem calculations Any PE that does not need to participate in the tandem calculations
at the B-MAC layer may use the IS-IS overload bit to exclude SPBM at the B-MAC layer may use the IS-IS overload bit to exclude SPBM
tandem paths and behave as pure interworking platform. tandem paths and behave as pure interworking platform.
6. Acknowledgements 6. Acknowledgements
The authors would like to thank Peter Ashwood-Smith, Martin Julien The authors would like to thank Peter Ashwood-Smith, Martin Julien
and Janos Farkas for their detailed review of this draft. and Janos Farkas for their detailed review of this draft.
7. Security Considerations 7. Security Considerations
Security issues associated with incorrect interconnect of customer Security issues associated with incorrect interconnect of customer
LANs cannot be directly addressed by implementations of this LANs cannot be directly addressed by implementations of this
document, as it requires misconfiguration in the Shortest Path document, as it requires misconfiguration in the Shortest Path
Bridging domains. The identifiers so administered have global Bridging domains. The identifiers so administered have global
significance to the larger system. They are relayed transparently by significance to the larger system. They are relayed transparently by
EVPN and only policed in the SPBM domains. 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.
Security issues exist when SPBM domains are incorrectly cross There are only two identifiers unique to this solution provisioned at
connected together via EVPN which will result in back-holing or an SPBM-PE at service turn up; the route target and the ESI. The ESI
incorrect delivery of data with associated privacy issues. This would needs to be unique and common to all SPBM-PEs connected to a common
be a consequence of conflicting administration of SPBM LAN SPBM network, or PBBN else portions of the overall network will not
identifiers. share reachability (EVPN will assume that separate networks are
interconnected by SPBM). Security issues exist when SPBM domains are
incorrectly cross connected together via EVPN which will result in
back-holing or incorrect delivery of data with associated privacy
issues. This could be achieved by provisioning the incorrect RT value
at an SPBM-PE or associating the RT with the wrong interface. This
can be avoided via care in route target provisioning at SPBM-PEs for
service adds and changes.
Most of the issues associated with securing the BGP control plane are The potentially most destructive behavior of the overall system would
reflected in the security considerations section of [RFC4761]. be frequent changes to the DF elections for a given ESI. This would
require SPBM-PEs to frequently flap in the form of either the node
continuously resetting or links flapping in a form that keeps
severing and re-connecting the SPBM-PE from either the IP/MPLS
network or the subtending 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].
8. IANA Considerations 8. IANA Considerations
No IANA assignments are required by this document. No IANA assignments are required by this document.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4761] Kompella (ed.), "Virtual Private LAN Service (VPLS) Using [RFC4761] Kompella (ed.), "Virtual Private LAN Service (VPLS) Using BGP
BGP for Auto-Discovery and Signaling", IETF RFC 4761, for Auto-Discovery and Signaling", IETF RFC 4761, January 2007
January 2007
[RFC6329] Fedyk et.al. "IS-IS Extensions Supporting IEEE 802.1aq [RFC6329] Fedyk et.al. "IS-IS Extensions Supporting IEEE 802.1aq
Shortest Path Bridging", IETF RFC 6329, April 2012 Shortest Path Bridging", IETF RFC 6329, April 2012
[RFC7432] Aggarwal et.al. "BGP MPLS Based Ethernet VPN", IETF work [RFC7432] Aggarwal et.al. "BGP MPLS Based Ethernet VPN", IETF RFC
in progress, IETF RFC 7432, February 2015 7432, February 2015
9.2. Informative References 9.2. Informative References
[802.1aq] [802.1aq]
802.1aq(2012) IEEE Standard for Local and Metropolitan 802.1aq(2012) IEEE Standard for Local and Metropolitan
Area Networks: Bridges and Virtual Bridged Local Area Area Networks: Bridges and Virtual Bridged Local Area
Networks - Amendment 9: Shortest Path Bridging Networks - Amendment 9: Shortest Path Bridging
[PBB-EVPN] Sajassi et.al. "PBB E-VPN", IETF work in progress, [PBB-EVPN] Sajassi et.al. "PBB E-VPN", IETF work in progress,
draft-ietf-l2vpn-pbb-evpn-10, May 2015 draft-ietf-l2vpn-pbb-evpn-10, May 2015
 End of changes. 33 change blocks. 
101 lines changed or deleted 129 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/