draft-ietf-bess-spbm-evpn-02.txt   rfc7734.txt 
BESS Working Group Dave Allan, Jeff Tantsura
Internet Draft Ericsson
Intended status: Standards Track Don Fedyk
Expires: May 2016 HP
Ali Sajassi
Cisco
October 2015 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
Shortest Path Bridging, MAC Mode Support over EVPN Support for Shortest Path Bridging MAC Mode over Ethernet VPN (EVPN)
draft-ietf-bess-spbm-evpn-02
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 to interwork with PBB-PEs as (SPBM) can be combined with Ethernet VPN (EVPN) to interwork with
described in the PBB-EVPN solution. This is achieved via Provider Backbone Bridging Provider Edges (PBB PEs) as described in
operational isolation of each Ethernet network attached an EVPN core the PBB-EVPN solution (RFC 7623). This is achieved via operational
while supporting full interworking between the different variations isolation of each Ethernet network attached to an EVPN core while
of Ethernet networks. supporting full interworking between the different variations of
Ethernet networks.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance
with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Status of This Memo
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six This is an Internet Standards Track document.
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work
in progress".
The list of current Internet-Drafts can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/ietf/1id-abstracts.txt. (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.
The list of Internet-Draft Shadow Directories can be accessed at Information about the current status of this document, any errata,
http://www.ietf.org/shadow.html. and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7734.
This Internet-Draft will expire on February 2016. Copyright Notice
Copyright and License Notice Copyright (c) 2016 IETF Trust and the persons identified as the
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(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
respect to this document. Code Components extracted from this to this document. Code Components extracted from this document must
document must include Simplified BSD License text as described include Simplified BSD License text as described in Section 4.e of
in Section 4.e of the Trust Legal Provisions and are provided the Trust Legal Provisions and are provided without warranty as
without warranty as described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction...................................................2 1. Introduction ....................................................3
1.1. Requirements Language........................................3 1.1. 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 SPBM Island or PBB PE to EVPN ......8
EVPN..............................................................8 4.6. Data-Plane Interworking EVPN to SPBM Island ................8
4.6. Data plane Interworking EVPN to 802.1aq SPBM island..........8 4.7. Data-Plane Interworking EVPN to 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. Transit ....................................................8
5.1. Transit......................................................9 6. Security Considerations .........................................9
6. Security Considerations........................................9 7. References .....................................................10
7. IANA Considerations...........................................10 7.1. Normative References ......................................10
8. Acknowledgments...............................................10 7.2. Informative References ....................................10
9. References....................................................10 Acknowledgments ...................................................11
9.1. Normative References........................................10 Authors' Addresses ................................................11
9.2. Informative References......................................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
(SPBM) along with Provider Backbone Bridging Provider Edges (PBB-PEs) (SPBM) [IEEE.802.1Q] along with Provider Backbone Bridging Provider
and Provider Backbone Bridged Networks (PBBNs) can be supported by Edges (PBB PEs) and Provider Backbone Bridged Networks (PBBNs) can be
Ethernet VPNs (EVPNs) such that each SPBM island is operationally supported by Ethernet VPNs (EVPNs) such that each SPBM island is
isolated while providing full L2 connectivity between the different operationally isolated while providing full L2 connectivity between
types of PBBNs where desired. Each SPBM island uses its own control the different types of PBBNs where desired. Each SPBM island uses
plane instance and multi-pathing design, be it multiple equal cost its own control-plane instance and multipathing design, be it
tree sets, or multiple spanning trees. multiple equal-cost tree sets or multiple spanning trees.
The intention is to permit past, current and emerging future versions The intention is to permit past, current, and emerging future
of Ethernet to be seamlessly interconnected to permit large scale, versions of Ethernet to be seamlessly interconnected to permit large-
geographically diverse numbers of Ethernet end systems to be fully scale, geographically diverse numbers of Ethernet end systems to be
supported with EVPN as the unifying system. fully supported with EVPN as the unifying system.
1.1. 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 RFC 2119 [RFC2119].
2. Conventions used in this document 2. Conventions Used in This Document
2.1. Terminology 2.1. Terminology
BEB: Backbone Edge Bridge Terms used in this document are used as specified in IEEE
BGP: Border Gateway Protocol 802.1Q-2014, which incorporates earlier IEEE 802.1 projects.
B-MAC: Backbone MAC Address
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: I-Component Service ID
NLRI: Network Layer Reachability Information
PBB: Provider Backbone Bridging (802.1ah)
PBBN: Provider Backbone Bridged Network
PBB-PE: Co located 802.1ah BEB and EVPN PE
PE: Provider Edge
SPB: Shortest Path Bridging
SPBM: Shortest Path Bridging MAC mode
SPBM-PE: Co-located 802.1aq SPBM<->EVPN interworking function and
EVPN PE
3. Solution Overview 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
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
The EVPN solution for 802.1aq SPBM incorporates control plane 3. Solution Overview
interworking in the PE to map ISIS-SPB [RFC6329] information elements
into the EVPN Next Layer Reachability Information (NLRI) and vice The EVPN solution for SPBM, as specified in [IEEE.802.1Q],
versa. This requires each PE to act both as an EVPN BGP speaker and incorporates control-plane interworking in the PE to map ISIS-SPB
as an ISIS-SPB edge node. Associated with this are procedures for [RFC6329] information elements into the EVPN Next Layer Reachability
configuring the forwarding operations of the PE such that an Information (NLRI) and vice versa. This requires each PE to act both
arbitrary number of EVPN attached SPBM islands can be interconnected as an EVPN BGP speaker and as an ISIS-SPB edge node. Associated with
without any topological or multi-pathing dependencies. This model this are procedures for configuring the forwarding operations of the
also permits PBB-PEs as defined in [PBB-EVPN] to seamlessly 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. communicate with the SPBM islands.
+--------------+ +----+ +---+ +--------------+ +----+ +---+
| | |PBB |---|CE2| | | |PBB |---|CE2|
| | |PE3 | +---+ | | |PE3 | +---+
+-----+ +----+ | | +----+ +-----+ +----+ | | +----+
| |-----|SPBM| | | | |-----|SPBM| | |
|SPBM | |PE1 | | IP/MPLS | |SPBM | |PE1 | | IP/MPLS |
+---+ |NTWK1| +----+ | Network | +---+ |NTWK1| +----+ | Network |
|CE1|-| | | | |CE1|-| | | |
skipping to change at page 4, line 36 skipping to change at page 4, line 35
+-----+ +----+ | | +----+ +-----+ +----+ | | +----+
| |-----|SPBM| | | | |-----|SPBM| | |
|SPBM | |PE1 | | IP/MPLS | |SPBM | |PE1 | | IP/MPLS |
+---+ |NTWK1| +----+ | Network | +---+ |NTWK1| +----+ | Network |
|CE1|-| | | | |CE1|-| | | |
+---+ | | +----+ | | +---+ | | +----+ | |
| |-----|SPBM| | | +----+ +-----+ | |-----|SPBM| | | +----+ +-----+
+-----+ |PE2 | | | |SPBM| |SPBM | +---+ +-----+ |PE2 | | | |SPBM| |SPBM | +---+
+----+ | | |PE5 |---|NTWK2|-|CE3| +----+ | | |PE5 |---|NTWK2|-|CE3|
+--------------+ +----+ +-----+ +---+ +--------------+ +----+ +-----+ +---+
Figure 1: PBB and SPBM EVPN Network Figure 1: PBB and SPBM EVPN Network
Figure 1 illustrates the generalized space addressed by this memo. Figure 1 illustrates the generalized space addressed by this memo.
SPBM networks may be multi-homed onto an IP/MPLS network that SPBM networks may be multihomed onto an IP/MPLS network that
implements EVPN for the purpose of interconnect with other SPBM implements EVPN for the purpose of interconnecting with other SPBM
networks, and/or PBB PEs. The multipathing configuration of each SPBM networks and/or PBB PEs. The multipathing configuration of each SPBM
network can be unique as the backbone VLAN ID (B-VID) configuration network can be unique as the backbone VLAN ID (B-VID) configuration
(how multi-pathing is performed in SPBM) is not propagated across the (how multipathing is performed in SPBM) is not propagated across the
IP/MPLS network implementing EVPN. As with PBB networking the B-VID 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 B-VID is local to the SPBM network, so in SPBM a B-MAC associated with the
is advertised with the supported I-SIDs at the PBB gateway. 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
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.
Each EVPN is identified by a route target. I-SID Based Load-balancing
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 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 designated forwarder (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 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 and perform the following procedures: A PE MUST implement and perform the following procedures.
4.1. PE Configuration 4.1. PE Configuration
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
PEs to be interconnected by the EVPN. PBB PEs are 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.
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 BEB operation independent of the EVPN operation. SPBM BEB operation independent of the EVPN operation.
2) The set of B-VIDs used in the SPBM island and multi-pathing 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 multi- algorithm IDs to use for each. The set of B-VIDs and multipathing
pathing algorithms used can be different in different domains. algorithms used can be different in different domains. Therefore,
Therefore the B-VID is local to an SPBM domain and is removed for the B-VID is local to an SPBM domain and is removed for frames
frames carried over the IP/MPLS network. 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 for this document.
4.2. DF Election 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].
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 of
[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
sub-TLV as part of an ISIS-SPB MT capability TLV it checks if it is sub-TLV as part of an ISIS-SPB MT capability TLV, the PE checks if it
the DF for the B-VID in the sub-TLV. 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 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 MAC/IP advertisement route NLRI is created for each new I-SID in the
sub-TLV. Changed information that results in modification to existing sub-TLV. Changed information that results in modification to
NLRI are processed accordingly. 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 Route Distinguisher is set to that of the PE.
- the Ethernet tag ID contains the I-SID (including the Tx/Rx - the ESI is that of the SPBM island.
attributes). The encoding of I-SID information is as per figure 2.
- 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.)
0 1 2 3 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 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 | |T|R| Reserved | I-SID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: I-SID encoding in the Ethernet tag-ID field Figure 2: I-SID Encoding in the Ethernet Tag ID Field
- the MAC address is copied from the sub-TLV - the MAC address is copied from the SPBM service identifier and
unicast address sub-TLV
- a locally assigned MPLS label - 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 Similarly, in the scenario where a PE became elected DF for a B-VID
an operating network, the IS-IS database would be processed in order in an operating network, the IS-IS database would be processed in
to construct the NLRI information associated with the new role of the order to construct the NLRI 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 for the I-SID, and this is the first
the first instance of registration of interest in the I-SID from the instance of registration of interest in the I-SID from the SPBM
SPBM island, the NLRI information with that tag is processed to island, the NLRI for the I-SID is processed to construct an updated
construct an updated set of SPBM service identifier and unicast set of SPBM service identifier and unicast address sub-TLVs to be
address sub-TLVs to be advertised by the PE. 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 the EVPN. When an I-SID is associated with more
one B-VID, only one entry is allowed in the table. Rules for than 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 for this memo.
4.4. Control plane interworking EVPN to ISIS-SPB 4.4. Control-Plane Interworking EVPN to ISIS-SPB
When a PE receives a BGP NLRI that has new information, it checks if When a PE receives a BGP NLRI that has new information, the PE checks
it is the elected DF to communicate this information into ISIS-SPB by if it is the elected DF to communicate this information into ISIS-SPB
checking if the I-SID in the Ethernet Tag ID locally maps to the B- by checking if the I-SID in the Ethernet Tag ID locally maps to the
VID it is an elected DF for. Note that if no BEBs in the SPB island B-VID for which it is an elected DF. Note that if no BEBs in the SPB
have advertised any interest in the I-SID, it will not be associated island have advertised any interest in the I-SID, it will not be
with any B-VID locally, and therefore not of interest. If the I-SID associated with any B-VID locally, and therefore will not be of
is of local interest to the SPBM island and the PE is the DF for the interest. If the I-SID is of local interest to the SPBM island and
B-VID that the I-SID is locally mapped to, a SPBM service identifier the PE is the DF for the B-VID to which the I-SID is locally mapped,
and unicast address sub-TLV is constructed/updated for advertisement a SPBM service identifier and unicast address sub-TLV are
into ISIS-SPB. constructed/updated for advertisement into ISIS-SPB.
The NLRI information advertised into ISIS-SPB is also used to locally The NLRI advertised into ISIS-SPB is also used to locally populate a
populate a forwarding table indexed by B-MAC+I-SID that points to the forwarding table indexed by B-MAC + I-SID that points to the label
label stack to impose on the SPBM frame. The bottom label in the stack to impose on the SPBM frame. The bottom label in the stack is
stack being that obtained from the NLRI. that obtained from the NLRI.
4.5. Data plane Interworking 802.1aq SPBM island or PBB-PE to EVPN 4.5. Data-Plane Interworking SPBM Island or PBB PE to EVPN
When an PE receives a frame from the SPBM island in a B-VID for which 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 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 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 SPBM Island
When a PE receives a packet from the EVPN it can infer the B-VID to 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 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 destination address (DA), it If the frame has a local multicast destination address (DA), it
overwrites the SPSourceID 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 PBB PE
A PBB-PE actually has no attached PBBN nor concept of B-VID so no A PBB PE actually has no attached 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 PBB-encoded (i.e., using the Backbone Service Instance Group
being that it is a multicast frame, and the I-SID encoded in the address) for multicast DAs. The only information of interest is that
lower 24 bits. it is a multicast frame and the I-SID encoded in the lower 24 bits.
4.8. Multicast Support 4.8. Multicast Support
Within a PBBN domain Ethernet Unicast and Multicast end services are Within a PBBN domain, Ethernet unicast and multicast end services are
supported. PBB can tunnel multicast traffic in Unicast PBB frames supported. PBB can tunnel multicast traffic in unicast PBB frames
when using head end replication. This is the only form of multicast when using head-end replication. This is the only form of multicast
traffic interworking supported by this document. Native PBB multicast traffic interworking supported by this document. Native PBB
forwarding over EVPN, PE replication or optimizing PBB multicast multicast forwarding over EVPN, PE replication, or optimizing PBB
across the EVPN is not addressed by this memo. multicast across the EVPN is not addressed by this memo.
5. Other Aspects 5. Other Aspects
5.1. Transit 5.1. 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 can use the IS-IS overload bit to exclude SPBM at the B-MAC layer can use the IS-IS overload bit to exclude SPBM
tandem paths and behave as pure interworking platform. tandem paths and behave as a pure interworking platform.
6. Security Considerations 6. Security Considerations
Security issues associated with incorrect interconnect of customer Security issues associated with incorrect interconnection 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. Therefore care is required EVPN and only policed in the SPBM domains. Therefore, care is
in synchronization of identifiers that need to be common for inter- required in synchronization of identifiers that need to be common for
domain operation. inter-domain operation.
There are only two identifiers unique to this solution provisioned at 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 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 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 SPBM network or PBBN, else portions of the overall network will not
share reachability (EVPN will assume that separate networks are share reachability. (The EVPN will assume that separate networks are
interconnected by SPBM). Security issues exist when SPBM domains are interconnected by SPBM.) Security issues exist when SPBM domains are
incorrectly cross connected together via EVPN which will result in incorrectly cross-connected together via EVPN; this will result in
back-holing or incorrect delivery of data with associated privacy black-holing or incorrect delivery of data with associated privacy
issues. This could be achieved by provisioning the incorrect RT value issues. This error may occur by provisioning the incorrect RT value
at an SPBM-PE or associating the RT with the wrong interface. This 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 error can be avoided by consistency-checking the route target
service adds and changes. provisioning at SPBM-PEs when performing service additions and/or
changes.
The potentially most destructive behavior of the overall system would The behavior that is potentially most destructive to the overall
be frequent changes to the DF elections for a given ESI. This would system is frequent changes to the DF elections for a given ESI. This
require SPBM-PEs to frequently flap in the form of either the node would occur if the SPBM-PEs continuously had their links go up and
continuously resetting or links flapping in a form that keeps down in a such a way that the SPBM-PE was being severed from and
severing and re-connecting the SPBM-PE from either the IP/MPLS reconnected to either the IP/MPLS network or the attached SPBM
network or the attached SPBM-Network. Either of these scenarios would network. Either of these scenarios would result in significant
result in significant control plane traffic as DF associated control-plane traffic as DF associated information was advertised and
information was advertised and withdrawn from both the SPBM and BGP withdrawn from both the SPBM and BGP control planes. Dual-homing of
control planes. Dual homing of SPBM-PEs on both networks would SPBM-PEs on both networks would minimize the likelihood of this
minimize the likelihood of this scenario occurring. scenario occurring.
The issues associated with securing the BGP control plane The issues associated with securing the BGP control plane
(independent of this particular memo) are reflected in the security (independent of this particular memo) are reflected in the Security
considerations section of [RFC4761]. Considerations section of [RFC4761].
7. IANA Considerations
No IANA assignments are required by this document.
8. Acknowledgments
The authors would like to thank Peter Ashwood-Smith, Martin Julien 7. References
and Janos Farkas for their detailed review of this draft.
9. References 7.1. Normative 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,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC4761] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private
Requirement Levels", BCP 14, RFC 2119, March 1997. 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>.
[RFC4761] Kompella (ed.), "Virtual Private LAN Service (VPLS) Using [RFC6329] Fedyk, D., Ed., Ashwood-Smith, P., Ed., Allan, D., Bragg,
BGP for Auto-Discovery and Signaling", IETF RFC 4761, A., and P. Unbehagen, "IS-IS Extensions Supporting IEEE
January 2007 802.1aq Shortest Path Bridging", RFC 6329,
DOI 10.17487/RFC6329, April 2012,
<http://www.rfc-editor.org/info/rfc6329>.
[RFC6329] Fedyk et.al. "IS-IS Extensions Supporting IEEE 802.1aq [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Shortest Path Bridging", IETF RFC 6329, April 2012 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>.
[RFC7432] Aggarwal et.al. "BGP MPLS Based Ethernet VPN", IETF RFC 7.2. Informative References
7432, February 2015
9.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.
[802.1aq] 802.1aq (2012), IEEE Standard for Local and [RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W.
Metropolitan Area Networks: Bridges and Virtual Bridged Henderickx, "Provider Backbone Bridging Combined with
Local Area Networks - Amendment 9: Shortest Path Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623,
Bridging September 2015, <http://www.rfc-editor.org/info/rfc7623>.
[PBB-EVPN] Sajassi et.al. "PBB E-VPN", IETF work in progress, Acknowledgments
draft-ietf-l2vpn-pbb-evpn-10, May 2015
[802.1Q] 802.1Q (2011), IEEE Standard for Local and metropolitan The authors would like to thank Peter Ashwood-Smith, Martin Julien,
area networks--Media Access Control (MAC) Bridges and and Janos Farkas for their detailed reviews of this document.
Virtual Bridged Local Area Networks
10. Authors' Addresses Authors' Addresses
Dave Allan (editor) Dave Allan (editor)
Ericsson Ericsson
300 Holger Way 300 Holger Way
San Jose, CA 95134 San Jose, CA 95134
USA United States
Email: david.i.allan@ericsson.com Email: david.i.allan@ericsson.com
Jeff Tantsura Jeff Tantsura
Ericsson Ericsson
300 Holger Way 300 Holger Way
San Jose, CA 95134 San Jose, CA 95134
USA United States
Email: jeff.tantsura@ericsson.com Email: jeff.tantsura@ericsson.com
Don Fedyk Don Fedyk
Hewlett-Packard Hewlett-Packard Enterprise
153 Tayor Street 153 Taylor Street
Littleton, MA, 01460 Littleton, MA 01460
USA United States
don.fedyk@hp.com
Email: don.fedyk@hpe.com
Ali Sajassi Ali Sajassi
Cisco Cisco
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134, San Jose, CA 95134
USA United States
Email: sajassi@cisco.com Email: sajassi@cisco.com
 End of changes. 92 change blocks. 
299 lines changed or deleted 306 lines changed or added

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