diff options
Diffstat (limited to 'doc/rfc/rfc7623.txt')
| -rw-r--r-- | doc/rfc/rfc7623.txt | 1291 |
1 files changed, 1291 insertions, 0 deletions
diff --git a/doc/rfc/rfc7623.txt b/doc/rfc/rfc7623.txt new file mode 100644 index 0000000..7225c7b --- /dev/null +++ b/doc/rfc/rfc7623.txt @@ -0,0 +1,1291 @@ + + + + + + +Internet Engineering Task Force (IETF) A. Sajassi, Ed. +Request for Comments: 7623 S. Salam +Category: Standards Track Cisco +ISSN: 2070-1721 N. Bitar + Verizon + A. Isaac + Juniper + W. Henderickx + Alcatel-Lucent + September 2015 + + + Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN) + +Abstract + + This document discusses how Ethernet Provider Backbone Bridging (PBB) + can be combined with Ethernet VPN (EVPN) in order to reduce the + number of BGP MAC Advertisement routes by aggregating Customer/Client + MAC (C-MAC) addresses via Provider Backbone MAC (B-MAC) address, + provide client MAC address mobility using C-MAC aggregation, confine + the scope of C-MAC learning to only active flows, offer per-site + policies, and avoid C-MAC address flushing on topology changes. The + combined solution is referred to as PBB-EVPN. + +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/rfc7623. + + + + + + + + + + + + + +Sajassi, et al. Standards Track [Page 1] + +RFC 7623 PBB-EVPN September 2015 + + +Copyright Notice + + Copyright (c) 2015 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 + 2. Terminology .....................................................4 + 3. Requirements ....................................................4 + 3.1. MAC Advertisement Route Scalability ........................5 + 3.2. C-MAC Mobility Independent of B-MAC Advertisements .........5 + 3.3. C-MAC Address Learning and Confinement .....................5 + 3.4. Per-Site Policy Support ....................................6 + 3.5. No C-MAC Address Flushing for All-Active Multihoming .......6 + 4. Solution Overview ...............................................6 + 5. BGP Encoding ....................................................7 + 5.1. Ethernet Auto-Discovery Route ..............................7 + 5.2. MAC/IP Advertisement Route .................................7 + 5.3. Inclusive Multicast Ethernet Tag Route .....................8 + 5.4. Ethernet Segment Route .....................................8 + 5.5. ESI Label Extended Community ...............................8 + 5.6. ES-Import Route Target .....................................9 + 5.7. MAC Mobility Extended Community ............................9 + 5.8. Default Gateway Extended Community .........................9 + 6. Operation .......................................................9 + 6.1. MAC Address Distribution over Core .........................9 + 6.2. Device Multihoming .........................................9 + 6.2.1. Flow-Based Load-Balancing ...........................9 + 6.2.1.1. PE B-MAC Address Assignment ...............10 + 6.2.1.2. Automating B-MAC Address Assignment .......11 + 6.2.1.3. Split Horizon and Designated + Forwarder Election ........................12 + 6.2.2. Load-Balancing based on I-SID ......................12 + 6.2.2.1. PE B-MAC Address Assignment ...............12 + 6.2.2.2. Split Horizon and Designated + Forwarder Election ........................13 + 6.2.2.3. Handling Failure Scenarios ................13 + + + +Sajassi, et al. Standards Track [Page 2] + +RFC 7623 PBB-EVPN September 2015 + + + 6.3. Network Multihoming .......................................14 + 6.4. Frame Forwarding ..........................................14 + 6.4.1. Unicast ............................................15 + 6.4.2. Multicast/Broadcast ................................15 + 6.5. MPLS Encapsulation of PBB Frames ..........................16 + 7. Minimizing ARP/ND Broadcast ....................................16 + 8. Seamless Interworking with IEEE 802.1aq / 802.1Qbp .............17 + 8.1. B-MAC Address Assignment ..................................17 + 8.2. IEEE 802.1aq / 802.1Qbp B-MAC Address Advertisement .......17 + 8.3. Operation: ................................................17 + 9. Solution Advantages ............................................18 + 9.1. MAC Advertisement Route Scalability .......................18 + 9.2. C-MAC Mobility Independent of B-MAC Advertisements ........18 + 9.3. C-MAC Address Learning and Confinement ....................19 + 9.4. Seamless Interworking with 802.1aq Access Networks ........19 + 9.5. Per-Site Policy Support ...................................20 + 9.6. No C-MAC Address Flushing for All-Active Multihoming ......20 + 10. Security Considerations .......................................20 + 11. IANA Considerations ...........................................20 + 12. References ....................................................21 + 12.1. Normative References .....................................21 + 12.2. Informative References ...................................21 + Acknowledgements ..................................................22 + Contributors ......................................................22 + Authors' Addresses ................................................23 + +1. Introduction + + [RFC7432] introduces a solution for multipoint Layer 2 Virtual + Private Network (L2VPN) services, with advanced multihoming + capabilities, using BGP for distributing customer/client MAC address + reachability information over the core MPLS/IP network. [PBB] + defines an architecture for Ethernet Provider Backbone Bridging + (PBB), where MAC tunneling is employed to improve service instance + and MAC address scalability in Ethernet as well as VPLS networks + [RFC7080]. + + In this document, we discuss how PBB can be combined with EVPN in + order to: reduce the number of BGP MAC Advertisement routes by + aggregating Customer/Client MAC (C-MAC) addresses via Provider + Backbone MAC (B-MAC) address, provide client MAC address mobility + using C-MAC aggregation, confine the scope of C-MAC learning to only + active flows, offer per-site policies, and avoid C-MAC address + flushing on topology changes. The combined solution is referred to + as PBB-EVPN. + + + + + + +Sajassi, et al. Standards Track [Page 3] + +RFC 7623 PBB-EVPN September 2015 + + +2. Terminology + + ARP: Address Resolution Protocol + BEB: Backbone Edge Bridge + B-MAC: Backbone MAC + B-VID: Backbone VLAN ID + CE: Customer Edge + C-MAC: Customer/Client MAC + ES: Ethernet Segment + ESI: Ethernet Segment Identifier + EVI: EVPN Instance + EVPN: Ethernet VPN + I-SID: Service Instance Identifier (24 bits and global within a PBB + network see [RFC7080]) + LSP: Label Switched Path + MP2MP: Multipoint to Multipoint + MP2P: Multipoint to Point + NA: Neighbor Advertisement + ND: Neighbor Discovery + P2MP: Point to Multipoint + P2P: Point to Point + PBB: Provider Backbone Bridge + PE: Provider Edge + RT: Route Target + VPLS: Virtual Private LAN Service + + Single-Active Redundancy Mode: When only a single PE, among a group + of PEs attached to an Ethernet segment, is allowed to forward traffic + to/from that Ethernet segment, then the Ethernet segment is defined + to be operating in Single-Active redundancy mode. + + All-Active Redundancy Mode: When all PEs attached to an Ethernet + segment are allowed to forward traffic to/from that Ethernet segment, + then the Ethernet segment is defined to be operating in All-Active + redundancy mode. + + 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 BCP 14 [RFC2119]. + +3. Requirements + + The requirements for PBB-EVPN include all the requirements for EVPN + that were described in [RFC7209], in addition to the following: + + + + + + + +Sajassi, et al. Standards Track [Page 4] + +RFC 7623 PBB-EVPN September 2015 + + +3.1. MAC Advertisement Route Scalability + + In typical operation, an EVPN PE sends a BGP MAC Advertisement route + per C-MAC address. In certain applications, this poses scalability + challenges, as is the case in data center interconnect (DCI) + scenarios where the number of virtual machines (VMs), and hence the + number of C-MAC addresses, can be in the millions. In such + scenarios, it is required to reduce the number of BGP MAC + Advertisement routes by relying on a 'MAC summarization' scheme, as + is provided by PBB. + +3.2. C-MAC Mobility Independent of B-MAC Advertisements + + Certain applications, such as virtual machine mobility, require + support for fast C-MAC address mobility. For these applications, + when using EVPN, the virtual machine MAC address needs to be + transmitted in BGP MAC Advertisement route. Otherwise, traffic would + be forwarded to the wrong segment when a virtual machine moves from + one ES to another. This means MAC address prefixes cannot be used in + data center applications. + + In order to support C-MAC address mobility, while retaining the + scalability benefits of MAC summarization, PBB technology is used. + It defines a B-MAC address space that is independent of the C-MAC + address space, and aggregates C-MAC addresses via a single B-MAC + address. + +3.3. C-MAC Address Learning and Confinement + + In EVPN, all the PE nodes participating in the same EVPN instance are + exposed to all the C-MAC addresses learned by any one of these PE + nodes because a C-MAC learned by one of the PE nodes is advertised in + BGP to other PE nodes in that EVPN instance. This is the case even + if some of the PE nodes for that EVPN instance are not involved in + forwarding traffic to, or from, these C-MAC addresses. Even if an + implementation does not install hardware forwarding entries for C-MAC + addresses that are not part of active traffic flows on that PE, the + device memory is still consumed by keeping record of the C-MAC + addresses in the routing information base (RIB) table. In network + applications with millions of C-MAC addresses, this introduces a non- + trivial waste of PE resources. As such, it is required to confine + the scope of visibility of C-MAC addresses to only those PE nodes + that are actively involved in forwarding traffic to, or from, these + addresses. + + + + + + + +Sajassi, et al. Standards Track [Page 5] + +RFC 7623 PBB-EVPN September 2015 + + +3.4. Per-Site Policy Support + + In many applications, it is required to be able to enforce + connectivity policy rules at the granularity of a site (or segment). + This includes the ability to control which PE nodes in the network + can forward traffic to, or from, a given site. Both EVPN and PBB- + EVPN are capable of providing this granularity of policy control. In + the case where the policy needs to be at the granularity of per C-MAC + address, then the C-MAC address should be learned in the control + plane (in BGP) per [RFC7432]. + +3.5. No C-MAC Address Flushing for All-Active Multihoming + + Just as in [RFC7432], it is required to avoid C-MAC address flushing + upon link, port, or node failure for All-Active multihomed segments. + +4. Solution Overview + + The solution involves incorporating IEEE Backbone Edge Bridge (BEB) + functionality on the EVPN PE nodes similar to PBB-VPLS, where BEB + functionality is incorporated in the VPLS PE nodes. The PE devices + would then receive 802.1Q Ethernet frames from their attachment + circuits, encapsulate them in the PBB header, and forward the frames + over the IP/MPLS core. On the egress EVPN PE, the PBB header is + removed following the MPLS disposition, and the original 802.1Q + Ethernet frame is delivered to the customer equipment. + + BEB +--------------+ BEB + || | | || + \/ | | \/ + +----+ AC1 +----+ | | +----+ +----+ + | CE1|-----| | | | | |---| CE2| + +----+\ | PE1| | IP/MPLS | | PE3| +----+ + \ +----+ | Network | +----+ + \ | | + AC2\ +----+ | | + \| | | | + | PE2| | | + +----+ | | + /\ +--------------+ + || + BEB + <-802.1Q-> <------PBB over MPLS------> <-802.1Q-> + + Figure 1: PBB-EVPN Network + + + + + + +Sajassi, et al. Standards Track [Page 6] + +RFC 7623 PBB-EVPN September 2015 + + + The PE nodes perform the following functions: + + - Learn customer/client MAC addresses (C-MACs) over the attachment + circuits in the data plane, per normal bridge operation. + + - Learn remote C-MAC to B-MAC bindings in the data plane for traffic + received from the core per the bridging operation described in + [PBB]. + + - Advertise local B-MAC address reachability information in BGP to + all other PE nodes in the same set of service instances. Note + that every PE has a set of B-MAC addresses that uniquely + identifies the device. B-MAC address assignment is described in + details in Section 6.2.2. + + - Build a forwarding table from remote BGP advertisements received + associating remote B-MAC addresses with remote PE IP addresses and + the associated MPLS label(s). + +5. BGP Encoding + + PBB-EVPN leverages the same BGP routes and attributes defined in + [RFC7432], adapted as described below. + +5.1. Ethernet Auto-Discovery Route + + This route and all of its associated modes are not needed in PBB-EVPN + because PBB encapsulation provides the required level of indirection + for C-MAC addresses -- i.e., an ES can be represented by a B-MAC + address for the purpose of data-plane learning/forwarding. + + The receiving PE knows that it need not wait for the receipt of the + Ethernet A-D (auto-discovery) route for route resolution by means of + the reserved ESI encoded in the MAC Advertisement route: the ESI + values of 0 and MAX-ESI indicate that the receiving PE can resolve + the path without an Ethernet A-D route. + +5.2. MAC/IP Advertisement Route + + The EVPN MAC/IP Advertisement route is used to distribute B-MAC + addresses of the PE nodes instead of the C-MAC addresses of end- + stations/hosts. This is because the C-MAC addresses are learned in + the data plane for traffic arriving from the core. The MAC + Advertisement route is encoded as follows: + + - The MAC address field contains the B-MAC address. + + - The Ethernet Tag field is set to 0. + + + +Sajassi, et al. Standards Track [Page 7] + +RFC 7623 PBB-EVPN September 2015 + + + - The Ethernet Segment Identifier field must be set to either 0 (for + single-homed segments or multihomed segments with per-I-SID load- + balancing) or to MAX-ESI (for multihomed segments with per-flow + load-balancing). All other values are not permitted. + + - All other fields are set as defined in [RFC7432]. + + This route is tagged with the RT corresponding to its EVI. This EVI + is analogous to a B-VID. + +5.3. Inclusive Multicast Ethernet Tag Route + + This route is used for multicast pruning per I-SID. It is used for + auto-discovery of PEs participating in a given I-SID so that a + multicast tunnel (MP2P, P2P, P2MP, or MP2MP LSP) can be set up for + that I-SID. [RFC7080] uses multicast pruning per I-SID based on + [MMRP], which is a soft-state protocol. The advantages of multicast + pruning using this BGP route over [MMRP] are that a) it scales very + well for a large number of PEs and b) it works with any type of LSP + (MP2P, P2P, P2MP, or MP2MP); whereas, [MMRP] only works over P2P + pseudowires. The Inclusive Multicast Ethernet Tag route is encoded + as follows: + + - The Ethernet Tag field is set with the appropriate I-SID value. + + - All other fields are set as defined in [RFC7432]. + + This route is tagged with an RT. This RT SHOULD be set to a value + corresponding to its EVI (which is analogous to a B-VID). The RT for + this route MAY also be auto-derived from the corresponding Ethernet + Tag (I-SID) based on the procedure specified in Section 5.1.2.1 of + [OVERLAY]. + +5.4. Ethernet Segment Route + + This route is used for auto-discovery of PEs belonging to a given + redundancy group (e.g., attached to a given ES) per [RFC7432]. + +5.5. ESI Label Extended Community + + This extended community is not used in PBB-EVPN. In [RFC7432], this + extended community is used along with the Ethernet A-D route to + advertise an MPLS label for the purpose of split-horizon filtering. + Since in PBB-EVPN, the split-horizon filtering is performed natively + using B-MAC source address, there is no need for this extended + community. + + + + + +Sajassi, et al. Standards Track [Page 8] + +RFC 7623 PBB-EVPN September 2015 + + +5.6. ES-Import Route Target + + This RT is used as defined in [RFC7432]. + +5.7. MAC Mobility Extended Community + + This extended community is defined in [RFC7432] and it is used with a + MAC route (B-MAC route in case of PBB-EVPN). The B-MAC route is + tagged with the RT corresponding to its EVI (which is analogous to a + B-VID). When this extended community is used along with a B-MAC + route in PBB-EVPN, it indicates that all C-MAC addresses associated + with that B-MAC address across all corresponding I-SIDs must be + flushed. + + When a PE first advertises a B-MAC, it MAY advertise it with this + extended community where the sticky/static flag is set to 1 and the + sequence number is set to zero. In such cases where the PE wants to + signal the stickiness of a B-MAC, then when a flush indication is + needed, the PE advertises the B-MAC along with the MAC Mobility + extended community where the sticky/static flag remains set and the + sequence number is incremented. + +5.8. Default Gateway Extended Community + + This extended community is not used in PBB-EVPN. + +6. Operation + + This section discusses the operation of PBB-EVPN, specifically in + areas where it differs from [RFC7432]. + +6.1. MAC Address Distribution over Core + + In PBB-EVPN, host MAC addresses (i.e., C-MAC addresses) need not be + distributed in BGP. Rather, every PE independently learns the C-MAC + addresses in the data plane via normal bridging operation. Every PE + has a set of one or more unicast B-MAC addresses associated with it, + and those are the addresses distributed over the core in MAC + Advertisement routes. + +6.2. Device Multihoming + +6.2.1. Flow-Based Load-Balancing + + This section describes the procedures for supporting device + multihoming in an All-Active redundancy mode (i.e., flow-based load- + balancing). + + + + +Sajassi, et al. Standards Track [Page 9] + +RFC 7623 PBB-EVPN September 2015 + + +6.2.1.1. PE B-MAC Address Assignment + + In [PBB], every BEB is uniquely identified by one or more B-MAC + addresses. These addresses are usually locally administered by the + service provider. For PBB-EVPN, the choice of B-MAC address(es) for + the PE nodes must be examined carefully as it has implications on the + proper operation of multihoming. In particular, for the scenario + where a CE is multihomed to a number of PE nodes with All-Active + redundancy mode, a given C-MAC address would be reachable via + multiple PE nodes concurrently. Given that any given remote PE will + bind the C-MAC address to a single B-MAC address, then the various PE + nodes connected to the same CE must share the same B-MAC address. + Otherwise, the MAC address table of the remote PE nodes will keep + oscillating between the B-MAC addresses of the various PE devices. + For example, consider the network of Figure 1, and assume that PE1 + has B-MAC address BM1 and PE2 has B-MAC address BM2. Also, assume + that both links from CE1 to the PE nodes are part of the same + Ethernet link aggregation group. If BM1 is not equal to BM2, the + consequence is that the MAC address table on PE3 will keep + oscillating such that the C-MAC address M1 of CE1 would flip-flop + between BM1 or BM2, depending on the load-balancing decision on CE1 + for traffic destined to the core. + + Considering that there could be multiple sites (e.g., CEs) that are + multihomed to the same set of PE nodes, then it is required for all + the PE devices in a redundancy group to have a unique B-MAC address + per site. This way, it is possible to achieve fast convergence in + the case where a link or port failure impacts the attachment circuit + connecting a single site to a given PE. + + +---------+ + +-------+ PE1 | IP/MPLS | + / | | + CE1 | Network | PEr + M1 \ | | + +-------+ PE2 | | + /-------+ | | + / | | + CE2 | | + M2 \ | | + \ | | + +------+ PE3 +---------+ + + Figure 2: B-MAC Address Assignment + + In the example network shown in Figure 2 above, two sites + corresponding to CE1 and CE2 are dual-homed to PE1/PE2 and PE2/PE3, + respectively. Assume that BM1 is the B-MAC used for the site + + + +Sajassi, et al. Standards Track [Page 10] + +RFC 7623 PBB-EVPN September 2015 + + + corresponding to CE1. Similarly, BM2 is the B-MAC used for the site + corresponding to CE2. On PE1, a single B-MAC address (BM1) is + required for the site corresponding to CE1. On PE2, two B-MAC + addresses (BM1 and BM2) are required, one per site. Whereas on PE3, + a single B-MAC address (BM2) is required for the site corresponding + to CE2. All three PE nodes would advertise their respective B-MAC + addresses in BGP using the MAC Advertisement routes defined in + [RFC7432]. The remote PE, PEr, would learn via BGP that BM1 is + reachable via PE1 and PE2, whereas BM2 is reachable via both PE2 and + PE3. Furthermore, PEr establishes, via the PBB bridge learning + procedure, that C-MAC M1 is reachable via BM1, and C-MAC M2 is + reachable via BM2. As a result, PEr can load-balance traffic + destined to M1 between PE1 and PE2, as well as traffic destined to M2 + between both PE2 and PE3. In the case of a failure that causes, for + example, CE1 to be isolated from PE1, the latter can withdraw the + route it has advertised for BM1. This way, PEr would update its path + list for BM1 and will send all traffic destined to M1 over to PE2 + only. + +6.2.1.2. Automating B-MAC Address Assignment + + The PE B-MAC address used for single-homed or Single-Active sites can + be automatically derived from the hardware (using for example the + backplane's address and/or PE's reserved MAC pool ). However, the + B-MAC address used for All-Active sites must be coordinated among the + redundancy group members. To automate the assignment of this latter + address, the PE can derive this B-MAC address from the MAC address + portion of the CE's Link Aggregation Control Protocol (LACP) System + Identifier by flipping the 'Locally Administered' bit of the CE's + address. This guarantees the uniqueness of the B-MAC address within + the network, and ensures that all PE nodes connected to the same All- + Active CE use the same value for the B-MAC address. + + Note that with this automatic provisioning of the B-MAC address + associated with All-Active CEs, it is not possible to support the + uncommon scenario where a CE has multiple link bundles within the + same LACP session towards the PE nodes, and the service involves + hair-pinning traffic from one bundle to another. This is because the + split-horizon filtering relies on B-MAC addresses rather than Site-ID + Labels (as will be described in the next section). The operator must + explicitly configure the B-MAC address for this fairly uncommon + service scenario. + + Whenever a B-MAC address is provisioned on the PE, either manually or + automatically (as an outcome of CE auto-discovery), the PE MUST + transmit a MAC Advertisement route for the B-MAC address with a + downstream assigned MPLS label that uniquely identifies that address + + + + +Sajassi, et al. Standards Track [Page 11] + +RFC 7623 PBB-EVPN September 2015 + + + on the advertising PE. The route is tagged with the RTs of the + associated EVIs as described above. + +6.2.1.3. Split Horizon and Designated Forwarder Election + + [RFC7432] relies on split-horizon filtering for a multi-homed ES, + where the ES label is used for egress filtering on the attachment + circuit in order to prevent forwarding loops. In PBB-EVPN, the B-MAC + source address can be used for the same purpose, as it uniquely + identifies the originating site of a given frame. As such, ES labels + are not used in PBB-EVPN, and the egress split-horizon filtering is + done based on the B-MAC source address. It is worth noting here that + [PBB] defines this B-MAC address-based filtering function as part of + the I-Component options; hence, no new functions are required to + support split-horizon filtering beyond what is already defined in + [PBB]. + + The Designated Forwarder (DF) election procedures are defined in + [RFC7432]. + +6.2.2. Load-Balancing based on I-SID + + This section describes the procedures for supporting device + multihoming in a Single-Active redundancy mode with per-I-SID load- + balancing. + +6.2.2.1. PE B-MAC Address Assignment + + In the case where per-I-SID load-balancing is desired among the PE + nodes in a given redundancy group, multiple unicast B-MAC addresses + are allocated per multihomed ES: Each PE connected to the multihomed + segment is assigned a unique B-MAC. Every PE then advertises its + B-MAC address using the BGP MAC Advertisement route. In this mode of + operation, two B-MAC address-assignment models are possible: + + - The PE may use a shared B-MAC address for all its single-homed + segments and/or all its multi-homed Single-Active segments (e.g., + segments operating in per-I-SID load-balancing mode). + + - The PE may use a dedicated B-MAC address for each ES operating + with per-I-SID load-balancing mode. + + A PE implementation MAY choose to support either the shared B-MAC + address model or the dedicated B-MAC address model without causing + any interoperability issues. The advantage of the dedicated B-MAC + over the shared B-MAC address for multi-homed Single-Active segments, + is that when C-MAC flushing is needed, fewer C-MAC addresses are + impacted. Furthermore, it gives the disposition PE the ability to + + + +Sajassi, et al. Standards Track [Page 12] + +RFC 7623 PBB-EVPN September 2015 + + + avoid C-MAC destination address lookup even though source C-MAC + learning is still required in the data plane. Its disadvantage is + that there are additional B-MAC advertisements in BGP. + + A remote PE initially floods traffic to a destination C-MAC address, + located in a given multihomed ES, to all the PE nodes configured with + that I-SID. Then, when reply traffic arrives at the remote PE, it + learns (in the data path) the B-MAC address and associated next-hop + PE to use for said C-MAC address. + +6.2.2.2. Split Horizon and Designated Forwarder Election + + The procedures are similar to the flow-based load-balancing case, + with the only difference being that the DF filtering must be applied + to unicast as well as multicast traffic, and in both core-to-segment + as well as segment-to-core directions. + +6.2.2.3. Handling Failure Scenarios + + When a PE connected to a multihomed ES loses connectivity to the + segment, due to link or port failure, it needs to notify the remote + PEs to trigger C-MAC address flushing. This can be achieved in one + of two ways, depending on the B-MAC assignment model: + + - If the PE uses a shared B-MAC address for multiple Ethernet + segments, then the C-MAC flushing is signaled by means of having + the failed PE re-advertise the MAC Advertisement route for the + associated B-MAC, tagged with the MAC Mobility extended community + attribute. The value of the Counter field in that attribute must + be incremented prior to advertisement. This causes the remote PE + nodes to flush all C-MAC addresses associated with the B-MAC in + question. This is done across all I-SIDs that are mapped to the + EVI of the withdrawn MAC route. + + - If the PE uses a dedicated B-MAC address for each ES operating + under per-I-SID load-balancing mode, the failed PE simply + withdraws the B-MAC route previously advertised for that segment. + This causes the remote PE nodes to flush all C-MAC addresses + associated with the B-MAC in question. This is done across all + I-SIDs that are mapped to the EVI of the withdrawn MAC route. + + When a PE connected to a multihomed ES fails (i.e., node failure) or + when the PE becomes completely isolated from the EVPN network, the + remote PEs will start purging the MAC Advertisement routes that were + advertised by the failed PE. This is done either as an outcome of + the remote PEs detecting that the BGP session to the failed PE has + gone down, or by having a Route Reflector withdrawing all the routes + that were advertised by the failed PE. The remote PEs, in this case, + + + +Sajassi, et al. Standards Track [Page 13] + +RFC 7623 PBB-EVPN September 2015 + + + will perform C-MAC address flushing as an outcome of the MAC + Advertisement route withdrawals. + + For all failure scenarios (link/port failure, node failure, and PE + node isolation), when the fault condition clears, the recovered PE + re-advertises the associated ES route to other members of its + redundancy group. This triggers the backup PE(s) in the redundancy + group to block the I-SIDs for which the recovered PE is a DF. When a + backup PE blocks the I-SIDs, it triggers a C-MAC address flush + notification to the remote PEs by re-advertising the MAC + Advertisement route for the associated B-MAC, with the MAC Mobility + extended community attribute. The value of the Counter field in that + attribute must be incremented prior to advertisement. This causes + the remote PE nodes to flush all C-MAC addresses associated with the + B-MAC in question. This is done across all I-SIDs that are mapped to + the EVI of the withdrawn/re-advertised MAC route. + +6.3. Network Multihoming + + When an Ethernet network is multihomed to a set of PE nodes running + PBB-EVPN, Single-Active redundancy model can be supported with per- + service instance (i.e., I-SID) load-balancing. In this model, DF + election is performed to ensure that a single PE node in the + redundancy group is responsible for forwarding traffic associated + with a given I-SID. This guarantees that no forwarding loops are + created. Filtering based on DF state applies to both unicast and + multicast traffic, and in both access-to-core as well as core-to- + access directions just like a Single-Active multihomed device + scenario (but unlike an All-Active multihomed device scenario where + DF filtering is limited to multi-destination frames in the core-to- + access direction). Similar to a Single-Active multihomed device + scenario, with load-balancing based on I-SID, a unique B-MAC address + is assigned to each of the PE nodes connected to the multihomed + network (segment). + +6.4. Frame Forwarding + + The frame-forwarding functions are divided in between the Bridge + Module, which hosts the [PBB] BEB functionality, and the MPLS + Forwarder which handles the MPLS imposition/disposition. The details + of frame forwarding for unicast and multi-destination frames are + discussed next. + + + + + + + + + +Sajassi, et al. Standards Track [Page 14] + +RFC 7623 PBB-EVPN September 2015 + + +6.4.1. Unicast + + Known unicast traffic received from the Attachment Circuit (AC) will + be PBB-encapsulated by the PE using the B-MAC source address + corresponding to the originating site. The unicast B-MAC destination + address is determined based on a lookup of the C-MAC destination + address (the binding of the two is done via transparent learning of + reverse traffic). The resulting frame is then encapsulated with an + LSP tunnel label and an EVPN label associated with the B-MAC + destination address. If per flow load-balancing over ECMPs in the + MPLS core is required, then a flow label is added below the label + associated with the B-MAC address in the label stack. + + For unknown unicast traffic, the PE forwards these frames over the + MPLS core. When these frames are to be forwarded, then the same set + of options used for forwarding multicast/broadcast frames (as + described in next section) are used. + +6.4.2. Multicast/Broadcast + + Multi-destination frames received from the AC will be PBB- + encapsulated by the PE using the B-MAC source address corresponding + to the originating site. The multicast B-MAC destination address is + selected based on the value of the I-SID as defined in [PBB]. The + resulting frame is then forwarded over the MPLS core using one of the + following two options: + + Option 1: the MPLS Forwarder can perform ingress replication over a + set of MP2P or P2P tunnel LSPs. The frame is encapsulated with a + tunnel LSP label and the EVPN ingress replication label advertised + in the Inclusive Multicast Ethernet Tag [RFC7432]. + + Option 2: the MPLS Forwarder can use P2MP tunnel LSP per the + procedures defined in [RFC7432]. This includes either the use of + Inclusive or Aggregate Inclusive trees. Furthermore, the MPLS + Forwarder can use MP2MP tunnel LSP if Inclusive trees are used. + + Note that the same procedures for advertising and handling the + Inclusive Multicast Ethernet Tag defined in [RFC7432] apply here. + + + + + + + + + + + + +Sajassi, et al. Standards Track [Page 15] + +RFC 7623 PBB-EVPN September 2015 + + +6.5. MPLS Encapsulation of PBB Frames + + The encapsulation for the transport of PBB frames over MPLS is + similar to that of classical Ethernet, albeit with the additional PBB + header, as shown in the figure below: + + +------------------+ + | IP/MPLS Header | + +------------------+ + | PBB Header | + +------------------+ + | Ethernet Header | + +------------------+ + | Ethernet Payload | + +------------------+ + | Ethernet FCS | + +------------------+ + + Figure 3: PBB over MPLS Encapsulation + +7. Minimizing ARP/ND Broadcast + + The PE nodes MAY implement an ARP/ND-proxy function in order to + minimize the volume of ARP/ND traffic that is broadcasted over the + MPLS network. In case of ARP proxy, this is achieved by having each + PE node snoop on ARP request and response messages received over the + access interfaces or the MPLS core. The PE builds a cache of IP/MAC + address bindings from these snooped messages. The PE then uses this + cache to respond to ARP requests ingress on access ports and target + hosts that are in remote sites. If the PE finds a match for the IP + address in its ARP cache, it responds back to the requesting host and + drops the request. Otherwise, if it does not find a match, then the + request is flooded over the MPLS network using either ingress + replication or P2MP LSPs. In case of ND proxy, this is achieved + similar to the above but with ND/NA messages per [RFC4389]. + + + + + + + + + + + + + + + + +Sajassi, et al. Standards Track [Page 16] + +RFC 7623 PBB-EVPN September 2015 + + +8. Seamless Interworking with IEEE 802.1aq / 802.1Qbp + + +--------------+ + | | + +---------+ | MPLS | +---------+ + +----+ | | +----+ +----+ | | +----+ + |SW1 |--| | | PE1| | PE2| | |--| SW3| + +----+ | 802.1aq |---| | | |--| 802.1aq | +----+ + +----+ | .1Qbp | +----+ +----+ | .1Qbp | +----+ + |SW2 |--| | | Backbone | | |--| SW4| + +----+ +---------+ +--------------+ +---------+ +----+ + + |<------ IS-IS -------->|<-----BGP----->|<------ IS-IS ------>| CP + + + |<------------------------- PBB -------------------------->| DP + |<----MPLS----->| + + Legend: CP = Control-Plane View + DP = Data-Plane View + + Figure 4: Interconnecting 802.1aq / 802.1Qbp Networks with PBB-EVPN + +8.1. B-MAC Address Assignment + + The B-MAC addresses need to be globally unique across all networks + including PBB-EVPN and IEEE 802.1aq / 802.1Qbp networks. The B-MAC + addresses used for single-homed and Single-Active Ethernet segments + should be unique because they are typically auto-derived from the + PE's pools of reserved MAC addresses that are unique. The B-MAC + addresses used for All-Active Ethernet segments should also be unique + given that each network operator typically has its own assigned + Organizationally Unique Identifier (OUI) and thus can assign its own + unique MAC addresses. + +8.2. IEEE 802.1aq / 802.1Qbp B-MAC Address Advertisement + + B-MAC addresses associated with 802.1aq / 802.1Qbp switches are + advertised using the EVPN MAC/IP route advertisement already defined + in [RFC7432]. + +8.3. Operation: + + When a PE receives a PBB-encapsulated Ethernet frame from the access + side, it performs a lookup on the B-MAC destination address to + identify the next hop. If the lookup yields that the next hop is a + remote PE, the local PE would then encapsulate the PBB frame in MPLS. + The label stack comprises of the VPN label (advertised by the remote + + + +Sajassi, et al. Standards Track [Page 17] + +RFC 7623 PBB-EVPN September 2015 + + + PE), followed by an LSP/IGP label. From that point onwards, regular + MPLS forwarding is applied. + + On the disposition PE, assuming penultimate-hop-popping is employed, + the PE receives the MPLS-encapsulated PBB frame with a single label: + the VPN label. The value of the label indicates to the disposition + PE that this is a PBB frame, so the label is popped, the TTL field + (in the 802.1Qbp F-Tag) is reinitialized, and normal PBB processing + is employed from this point onwards. + +9. Solution Advantages + + In this section, we discuss the advantages of the PBB-EVPN solution + in the context of the requirements set forth in Section 3. + +9.1. MAC Advertisement Route Scalability + + In PBB-EVPN, the number of MAC Advertisement routes is a function of + the number of Ethernet segments (e.g., sites) rather than the number + of hosts/servers. This is because the B-MAC addresses of the PEs, + rather than C-MAC addresses (of hosts/servers), are being advertised + in BGP. As discussed above, there's a one-to-one mapping between + All-Active multihomed segments and their associated B-MAC addresses; + there can be either a one-to-one or many-to-one mapping between + Single-Active multihomed segments and their associated B-MAC + addresses; and finally there is a many-to-one mapping between single- + home sites and their associated B-MAC addresses on a given PE. This + means a single B-MAC is associated with one or more segments where + each segment can be associated with many C-MAC addresses. As a + result, the volume of MAC Advertisement routes in PBB-EVPN may be + multiple orders of magnitude less than EVPN. + +9.2. C-MAC Mobility Independent of B-MAC Advertisements + + As described above, in PBB-EVPN, a single B-MAC address can aggregate + many C-MAC addresses. Given that B-MAC addresses are associated with + segments attached to a PE or to the PE itself, their locations are + fixed and thus not impacted what so ever by C-MAC mobility. + Therefore, C-MAC mobility does not affect B-MAC addresses (e.g., any + re-advertisements of them). This is because the association of C-MAC + address to B-MAC address is learned in the data-plane and C-MAC + addresses are not advertised in BGP. Aggregation via B-MAC addresses + in PBB-EVPN performs much better than EVPN. + + + + + + + + +Sajassi, et al. Standards Track [Page 18] + +RFC 7623 PBB-EVPN September 2015 + + + To illustrate how this compares to EVPN, consider the following + example: + + If a PE running EVPN advertises reachability for N MAC addresses + via a particular segment, and then 50% of the MAC addresses in + that segment move to other segments (e.g., due to virtual machine + mobility), then N/2 additional MAC Advertisement routes need to be + sent for the MAC addresses that have moved. With PBB-EVPN, on the + other hand, the B-MAC addresses that are statically associated + with PE nodes are not subject to mobility. As C-MAC addresses + move from one segment to another, the binding of C-MAC to B-MAC + addresses is updated via data-plane learning in PBB-EVPN. + +9.3. C-MAC Address Learning and Confinement + + In PBB-EVPN, C-MAC address reachability information is built via + data-plane learning. As such, PE nodes not participating in active + conversations involving a particular C-MAC address will purge that + address from their forwarding tables. Furthermore, since C-MAC + addresses are not distributed in BGP, PE nodes will not maintain any + record of them in the control-plane routing table. + +9.4. Seamless Interworking with 802.1aq Access Networks + + Consider the scenario where two access networks, one running MPLS and + the other running 802.1aq, are interconnected via an MPLS backbone + network. The figure below shows such an example network. + + +--------------+ + | | + +---------+ | MPLS | +---------+ + +----+ | | +----+ +----+ | | +----+ + | CE |--| | | PE1| | PE2| | |--| CE | + +----+ | 802.1aq |---| | | |--| MPLS | +----+ + +----+ | | +----+ +----+ | | +----+ + | CE |--| | | Backbone | | |--| CE | + +----+ +---------+ +--------------+ +---------+ +----+ + + Figure 5: Interoperability with 802.1aq + + If the MPLS backbone network employs EVPN, then the 802.1aq data- + plane encapsulation must be terminated on PE1 or the edge device + connecting to PE1. Either way, all the PE nodes that are part of the + associated service instances will be exposed to all the C-MAC + addresses of all hosts/servers connected to the access networks. + However, if the MPLS backbone network employs PBB-EVPN, then the + 802.1aq encapsulation can be extended over the MPLS backbone, thereby + maintaining C-MAC address transparency on PE1. If PBB-EVPN is also + + + +Sajassi, et al. Standards Track [Page 19] + +RFC 7623 PBB-EVPN September 2015 + + + extended over the MPLS access network on the right, then C-MAC + addresses would be transparent to PE2 as well. + +9.5. Per-Site Policy Support + + In PBB-EVPN, the per-site policy can be supported via B-MAC addresses + via assigning a unique B-MAC address for every site/segment + (typically multihomed but can also be single-homed). Given that the + B-MAC addresses are sent in BGP MAC/IP route advertisement, it is + possible to define per-site (i.e., B-MAC) forwarding policies + including policies for E-TREE service. + +9.6. No C-MAC Address Flushing for All-Active Multihoming + + Just as in [RFC7432], with PBB-EVPN, it is possible to avoid C-MAC + address flushing upon topology change affecting an All-Active + multihomed segment. To illustrate this, consider the example network + of Figure 1. Both PE1 and PE2 advertise the same B-MAC address (BM1) + to PE3. PE3 then learns the C-MAC addresses of the servers/hosts + behind CE1 via data-plane learning. If AC1 fails, then PE3 does not + need to flush any of the C-MAC addresses learned and associated with + BM1. This is because PE1 will withdraw the MAC Advertisement routes + associated with BM1, thereby leading PE3 to have a single adjacency + (to PE2) for this B-MAC address. Therefore, the topology change is + communicated to PE3 and no C-MAC address flushing is required. + +10. Security Considerations + + All the security considerations in [RFC7432] apply directly to this + document because this document leverages the control plane described + in [RFC7432] and their associated procedures -- although not the + complete set but rather a subset. + + This document does not introduce any new security considerations + beyond that of [RFC7432] and [RFC4761] because advertisements and + processing of B-MAC addresses follow that of [RFC7432] and processing + of C-MAC addresses follow that of [RFC4761] -- i.e, B-MAC addresses + are learned in the control plane and C-MAC addresses are learned in + data plane. + +11. IANA Considerations + + There are no additional IANA considerations for PBB-EVPN beyond what + is already described in [RFC7432]. + + + + + + + +Sajassi, et al. Standards Track [Page 20] + +RFC 7623 PBB-EVPN September 2015 + + +12. References + +12.1. Normative References + + [PBB] IEEE, "IEEE Standard for Local and metropolitan area + networks - Media Access Control (MAC) Bridges and Virtual + Bridged Local Area Networks", Clauses 25 and 26, IEEE Std + 802.1Q, DOI 10.1109/IEEESTD.2011.6009146. + + [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>. + + [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>. + +12.2. Informative References + + [MMRP] IEEE, "IEEE Standard for Local and metropolitan area + networks - Media Access Control (MAC) Bridges and Virtual + Bridged Local Area Networks", Clause 10, IEEE Std 802.1Q, + DOI 10.1109/IEEESTD.2011.6009146. + + [OVERLAY] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Isaac, A., + Uttaro, J., Henderickx, W., Shekhar, R., Salam, S., Patel, + K., Rao, D., and S. Thoria, "A Network Virtualization + Overlay Solution using EVPN", + draft-ietf-bess-evpn-overlay-01, February 2015. + + [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery + Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April + 2006, <http://www.rfc-editor.org/info/rfc4389>. + + [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>. + + [RFC7080] Sajassi, A., Salam, S., Bitar, N., and F. Balus, "Virtual + Private LAN Service (VPLS) Interoperability with Provider + Backbone Bridges", RFC 7080, DOI 10.17487/RFC7080, + December 2013, <http://www.rfc-editor.org/info/rfc7080>. + + + + + + +Sajassi, et al. Standards Track [Page 21] + +RFC 7623 PBB-EVPN September 2015 + + + [RFC7209] Sajassi, A., Aggarwal, R., Uttaro, J., Bitar, N., + Henderickx, W., and A. Isaac, "Requirements for Ethernet + VPN (EVPN)", RFC 7209, DOI 10.17487/RFC7209, May 2014, + <http://www.rfc-editor.org/info/rfc7209>. + +Acknowledgements + + The authors would like to thank Jose Liste and Patrice Brissette for + their reviews and comments of this document. We would also like to + thank Giles Heron for several rounds of reviews and providing + valuable inputs to get this document ready for IESG submission. + +Contributors + + In addition to the authors listed, the following individuals also + contributed to this document. + + Lizhong Jin, ZTE + Sami Boutros, Cisco + Dennis Cai, Cisco + Keyur Patel, Cisco + Sam Aldrin, Huawei + Himanshu Shah, Ciena + Jorge Rabadan, ALU + + + + + + + + + + + + + + + + + + + + + + + + + + + +Sajassi, et al. Standards Track [Page 22] + +RFC 7623 PBB-EVPN September 2015 + + +Authors' Addresses + + Ali Sajassi, editor + Cisco + 170 West Tasman Drive + San Jose, CA 95134 + United States + Email: sajassi@cisco.com + + + Samer Salam + Cisco + 595 Burrard Street, Suite # 2123 + Vancouver, BC V7X 1J1 + Canada + Email: ssalam@cisco.com + + + Nabil Bitar + Verizon Communications + Email: nabil.n.bitar@verizon.com + + + Aldrin Isaac + Juniper + Email: aisaac@juniper.net + + + Wim Henderickx + Alcatel-Lucent + Email: wim.henderickx@alcatel-lucent.com + + + + + + + + + + + + + + + + + + + + +Sajassi, et al. Standards Track [Page 23] + |