draft-ietf-bess-spbm-evpn-01.txt   draft-ietf-bess-spbm-evpn-02.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: April 2016 HP Expires: May 2016 HP
Ali Sajassi Ali Sajassi
Cisco Cisco
September 2015 October 2015
Shortest Path Bridging, MAC Mode Support over EVPN Shortest Path Bridging, MAC Mode Support over EVPN
draft-ietf-bess-spbm-evpn-01 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 (802.1aq) can be combined with EVPN to interwork with 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 attached an EVPN core
core while supporting full interworking between the different while supporting full interworking between the different variations
variations of Ethernet networks. 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
Engineering Task Force (IETF), its areas, and its working Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working groups. Note that other groups may also distribute working
documents as Internet-Drafts. documents as Internet-Drafts.
skipping to change at page 2, line 36 skipping to change at page 2, line 36
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..................................................9 5. Other Aspects..................................................9
5.1. Transit......................................................9 5.1. Transit......................................................9
6. Acknowledgements...............................................9 6. Security Considerations........................................9
7. Security Considerations........................................9 7. IANA Considerations...........................................10
8. IANA Considerations...........................................10 8. Acknowledgments...............................................10
9. References....................................................10 9. References....................................................10
9.1. Normative References........................................10 9.1. Normative References........................................10
9.2. Informative References......................................10 9.2. Informative References......................................10
10. Authors' Addresses...........................................11 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) along with Provider Backbone Bridging Provider Edges (PBB-PEs)
and Provider Backbone Bridged Networks (PBBNs) can be supported by and Provider Backbone Bridged Networks (PBBNs) can be supported by
skipping to change at page 4, line 13 skipping to change at page 4, line 14
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 Next Layer Reachabilty Information (NLRI) and vice into the EVPN Next Layer Reachability Information (NLRI) and vice
versa. This requires each PE to act both as an EVPN BGP speaker and 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 as an ISIS-SPB edge node. Associated with this are procedures for
configuring the forwarding operations of the PE such that an configuring the forwarding operations of the PE such that an
arbitrary number of EVPN subtending SPBM islands may be arbitrary number of EVPN attached SPBM islands can be interconnected
interconnected without any topological or multipathing dependencies. without any topological or multi-pathing dependencies. This model
This model also permits PBB-PEs as defined in [PBB-EVPN] to also permits PBB-PEs as defined in [PBB-EVPN] to seamlessly
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 5, line 19 skipping to change at page 5, line 21
Each EVPN is identified by a route target. I-SID Based Load-balancing 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 in [PBB-EVPN] which allows multiple gateways per B-VID (each with
different I-SIDs) across the EVPN is supported by the interworking different I-SIDs) across the EVPN is supported by the interworking
between PBBNs and SPBM networks. However SPBM only allows a single between PBBNs and SPBM networks. However SPBM only allows a single
active designated forwarder per B-VID as described below. The route active designated forwarder per B-VID as described below. The route
target identifies the set of SPBM islands and PBB-PEs that are target identifies the set of SPBM islands and PBB-PEs that are
allowed to communicate. Each SPBM island is administered to have an allowed to communicate. Each SPBM island is administered to have an
associated Ethernet Segment ID (ESI) extended community associated associated Ethernet Segment ID (ESI) extended community associated
with it. with it.
BGP acts as a common repository of the I Component Service ID (I-SID) 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 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 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 distributes I-SID information into each SPBM island on the basis of
locally registered interest. If an SPBM island has no backbone edge locally registered interest. If an SPBM island has no backbone edge
bridges (BEBs) registering interest in a particular I-SID, bridges (BEBs) registering interest in a particular I-SID,
information about that I-SID from other SPBM islands, PBB-PEs or 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 (DF) for the B-VID. An SPBM-PE may be a DF 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. 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 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 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 defined by the route target, but the PE typically will not actually
host any I-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 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 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
skipping to change at page 6, line 21 skipping to change at page 6, line 21
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 multi-pathing
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 multi-
pathing algorithms used may be different in different domains. pathing algorithms used can be different in different domains.
Therefore the B-VID is local to an SPBM domain and is removed for Therefore the B-VID is local to an SPBM domain and is 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 themselves for the role of DF for a B-VID for a 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 given SPBM island. The procedure used is as per section 8.5 of
skipping to change at page 8, line 24 skipping to change at page 8, line 24
4.5. Data plane Interworking 802.1aq SPBM island or PBB-PE to EVPN 4.5. Data plane Interworking 802.1aq SPBM island or PBB-PE to EVPN
When an PE receives a frame from the SPBM island in a B-VID for which When an 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 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 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 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 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 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
Within a PBBN domain Ethernet Unicast and Multicast end services are Within a PBBN domain Ethernet Unicast and Multicast end services are
skipping to change at page 9, line 10 skipping to change at page 9, line 10
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 multicast
forwarding over EVPN, PE replication or optimizing PBB multicast forwarding over EVPN, PE replication or optimizing PBB multicast
across the EVPN is not addressed by this memo. 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 may 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 pure interworking platform.
6. Acknowledgements
The authors would like to thank Peter Ashwood-Smith, Martin Julien
and Janos Farkas for their detailed review of this draft.
7. Security Considerations 6. 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. Therefore care is required EVPN and only policed in the SPBM domains. Therefore care is required
in synchronization of identifiers that need to be common for inter- in synchronization of identifiers that need to be common for inter-
domain operation. domain operation.
skipping to change at page 9, line 46 skipping to change at page 9, line 42
issues. This could be achieved by provisioning the incorrect RT value issues. This could be achieved 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 can be avoided via care in route target provisioning at SPBM-PEs for
service adds and changes. service adds and changes.
The potentially most destructive behavior of the overall system would The potentially most destructive behavior of the overall system would
be frequent changes to the DF elections for a given ESI. This would 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 require SPBM-PEs to frequently flap in the form of either the node
continuously resetting or links flapping in a form that keeps continuously resetting or links flapping in a form that keeps
severing and re-connecting the SPBM-PE from either the IP/MPLS severing and re-connecting the SPBM-PE from either the IP/MPLS
network or the subtending SPBM-Network. Either of these scenarios network or the attached SPBM-Network. Either of these scenarios would
would result in significant control plane traffic as DF associated result in significant control plane traffic as DF associated
information was advertised and withdrawn from both the SPBM and BGP information was advertised and withdrawn from both the SPBM and BGP
control planes. Dual homing of SPBM-PEs on both networks would control planes. Dual homing of SPBM-PEs on both networks would
minimize the likelihood of this scenario occurring. minimize the likelihood of this 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].
8. IANA Considerations 7. IANA Considerations
No IANA assignments are required by this document. No IANA assignments are required by this document.
8. Acknowledgments
The authors would like to thank Peter Ashwood-Smith, Martin Julien
and Janos Farkas for their detailed review of this draft.
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 BGP [RFC4761] Kompella (ed.), "Virtual Private LAN Service (VPLS) Using
for Auto-Discovery and Signaling", IETF RFC 4761, January 2007 BGP for Auto-Discovery and Signaling", IETF RFC 4761,
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 RFC [RFC7432] Aggarwal et.al. "BGP MPLS Based Ethernet VPN", IETF RFC
7432, February 2015 7432, February 2015
9.2. Informative References 9.2. Informative References
[802.1aq] 802.1aq(2012) IEEE Standard for Local and Metropolitan [802.1aq] 802.1aq (2012), IEEE Standard for Local and
Area Networks: Bridges and Virtual Bridged Local Area Metropolitan Area Networks: Bridges and Virtual Bridged
Networks - Amendment 9: Shortest Path Bridging Local Area 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
[802.1Q] 802.1Q (2011) IEEE Standard for Local and metropolitan [802.1Q] 802.1Q (2011), IEEE Standard for Local and metropolitan
area networks--Media Access Control (MAC) Bridges and area networks--Media Access Control (MAC) Bridges and
Virtual Bridged Local Area Networks Virtual Bridged Local Area Networks
10. Authors' Addresses 10. 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 USA
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
Email: jeff.tantsura@ericsson.com Email: jeff.tantsura@ericsson.com
Don Fedyk Don Fedyk
Hewlett-Packard Hewlett-Packard
153 Tayor Street 153 Tayor Street
Littleton, MA, 01460 Littleton, MA, 01460
USA
don.fedyk@hp.com don.fedyk@hp.com
Ali Sajassi Ali Sajassi
Cisco Cisco
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134, US San Jose, CA 95134,
USA
Email: sajassi@cisco.com Email: sajassi@cisco.com
 End of changes. 29 change blocks. 
43 lines changed or deleted 49 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/