RFC 8388
Usage and Applicability of BGP MPLS-Based Ethernet VPN
Pages: 31
Informational
Informational
Part 2 of 2 – Pages 20 to 31
7. MPLS-Based Forwarding Model Use Case
EVPN supports an alternative forwarding model, usually referred to as the MPLS-based forwarding or disposition model, as opposed to the MAC-based forwarding or disposition model described in Section 6. Using the MPLS-based forwarding model instead of the MAC-based model might have an impact on the following: o the number of forwarding states required; and o the FIB where the forwarding states are handled (MAC FIB or MPLS Label FIB (LFIB)). The MPLS-based forwarding model avoids the destination MAC lookup at the egress PE MAC FIB at the expense of increasing the number of next-hop forwarding states at the egress MPLS LFIB. This also has an impact on the control plane and the label allocation model, since an MPLS-based disposition PE must send as many routes and labels as required next-hops in the egress MAC-VRF. This concept is equivalent to the forwarding models supported in IP-VPNs at the egress PE, where an IP lookup in the IP-VPN FIB may or may not be necessary depending on the available next-hop forwarding states in the LFIB. The following subsections highlight the impact on the control- and data-plane procedures described in Section 6 when an MPLS-based forwarding model is used. Note that both forwarding models are compatible and interoperable in the same network. The implementation of either model in each PE is a local decision to the PE node.
7.1. Impact of MPLS-Based Forwarding on the EVPN Network Startup
The MPLS-based forwarding model has no impact on the procedures explained in Section 6.1.7.2. Impact of MPLS-Based Forwarding on the VLAN-Based Service Procedures
Compared to the MAC-based forwarding model, the MPLS-based forwarding model has no impact in terms of the number of routes when all the service interfaces are based on VLAN. The differences for the use case described in this document are summarized in the following list: o Flooding tree setup per EVI (4k routes per PE): There is no impact when compared to the MAC-based model. o Ethernet A-D routes per ESI (one set of routes for ESI12 per PE): There is no impact compared to the MAC-based model. o Ethernet A-D routes per EVI (4k routes per PE/ESI): There is no impact compared to the MAC-based model. o MAC Advertisement routes: Instead of allocating and advertising the same MPLS Label for all the new MACs locally learned on the same MAC-VRF, a different label must be advertised per CE next-hop or MAC so that no MAC FIB lookup is needed at the egress PE. In general, this means that a different label (at least per CE) must be advertised, although the PE can decide to implement a label per MAC if more granularity (hence, less scalability) is required in terms of forwarding states. For example, if CE2 sends traffic from two different MACs to PE1, CE2-MAC1, and CE2-MAC2, the same MPLS Label=x can be re-used for both MAC advertisements, since they both share the same source ESI12. It is up to the PE1 implementation to use a different label per individual MAC within the same ES (even if only one label per ESI is enough). o PE1, PE2, and PE3 will not add forwarding states to the MAC FIB upon learning new local CE MAC addresses on the data plane but will rather add forwarding states to the MPLS LFIB.
7.3. Impact of MPLS-Based Forwarding on the VLAN Bundle Service Procedures
Compared to the MAC-based forwarding model, the MPLS-based forwarding model has no impact in terms of number of routes when all the service interfaces are VLAN bundle type. The differences for the use case described in this document are summarized in the following list: o Flooding tree setup per EVI (one route): There is no impact compared to the MAC-based model. o Ethernet A-D routes per ESI (one route for ESI12 per PE): There is no impact compared to the MAC-based model. o Ethernet A-D routes per EVI (one route per PE/ESI): There is no impact compared to the MAC-based model since no VLAN translation is required. o MAC Advertisement routes: Instead of allocating and advertising the same MPLS Label for all the new MACs locally learned on the same MAC-VRF, a different label must be advertised per CE next-hop or MAC so that no MAC FIB lookup is needed at the egress PE. In general, this means that a different label (at least per CE) must be advertised, although the PE can decide to implement a label per MAC if more granularity (hence, less scalability) is required in terms of forwarding states. It is up to the PE1 implementation to use a different label per individual MAC within the same ES (even if only one label per ESI is enough). o PE1, PE2, and PE3 will not add forwarding states to the MAC FIB upon learning new local CE MAC addresses on the data plane, but will rather add forwarding states to the MPLS LFIB.7.4. Impact of MPLS-Based Forwarding on the VLAN-Aware Service Procedures
Compared to the MAC-based forwarding model, the MPLS-based forwarding model has no impact in terms of the number of A-D routes when all the service interfaces are of the VLAN-aware bundle type. The differences for the use case described in this document are summarized in the following list: o Flooding tree setup per EVI (4k routes per PE): There is no impact compared to the MAC-based model. o Ethernet A-D routes per ESI (one route for ESI12 per PE): There is no impact compared to the MAC-based model.
o Ethernet A-D routes per EVI (1 route per ESI or 4k routes per PE/
ESI): PE1 and PE2 may send one route per ESI if no CE-VID
translation is needed. However, 4k routes are normally sent for
EVI300, one per <ESI, Ethernet Tag ID> tuple. This allows the
egress PE to find out all the forwarding information in the MPLS
LFIB and even support Ethernet Tag to CE-VID translation at the
egress.
o MAC Advertisement routes: Instead of allocating and advertising
the same MPLS Label for all the new MACs locally learned on the
same MAC-VRF, a different label must be advertised per CE next-hop
or MAC so that no MAC FIB lookup is needed at the egress PE. In
general, this means that a different label (at least per CE) must
be advertised, although the PE can decide to implement a label per
MAC if more granularity (hence, less scalability) is required in
terms of forwarding states. It is up to the PE1 implementation to
use a different label per individual MAC within the same ES. Note
that the Ethernet Tag will be set to a non-zero value for the MAC
Advertisement routes. The same MAC address can be announced with
a different Ethernet Tag value. This will make the advertising PE
install two different forwarding states in the MPLS LFIB.
o PE1, PE2, and PE3 will not add forwarding states to the MAC FIB
upon learning new local CE MAC addresses on the data plane but
will rather add forwarding states to the MPLS LFIB.
8. Comparison between MAC-Based and MPLS-Based Egress Forwarding Models
Both forwarding models are possible in a network deployment, and each
one has its own trade-offs.
Both forwarding models can save A-D routes per EVI when VLAN-aware
bundling services are deployed and no CE-VID translation is required.
While this saves a significant amount of routes, customers normally
require CE-VID translation; hence, we assume an A-D per EVI route per
<ESI, Ethernet Tag> is needed.
The MAC-based model saves a significant amount of MPLS Labels
compared to the MPLS-based forwarding model. All the MACs and A-D
routes for the same EVI can signal the same MPLS Label, saving labels
from the local PE space. A MAC FIB lookup at the egress PE is
required in order to do so.
The MPLS-based forwarding model can save forwarding states at the
egress PEs if labels per next-hop CE (as opposed to per MAC) are
implemented. No egress MAC lookup is required. Also, a different
label per next-hop CE per MAC-VRF is consumed, as opposed to a single
label per MAC-VRF.
Table 2 summarizes the resource implementation details of both models. +-----------------------------+-----------------+------------------+ | Resources | MAC-Based Model | MPLS-Based Model | +-----------------------------+-----------------+------------------+ | MPLS Labels Consumed | 1 per MAC-VRF | 1 per CE/EVI | | Egress PE Forwarding States | 1 per MAC | 1 per Next-Hop | | Egress PE Lookups | 2 (MPLS+MAC) | 1 (MPLS) | +-----------------------------+-----------------+------------------+ Table 2: Resource Comparison between MAC-Based and MPLS-Based Models The egress forwarding model is an implementation local to the egress PE and is independent of the model supported on the rest of the PEs; i.e., in our use case, PE1, PE2, and PE3 could have either egress forwarding model without any dependencies.9. Traffic Flow Optimization
In addition to the procedures described across Sections 3 through 8, EVPN [RFC7432] procedures allow for optimized traffic handling in order to minimize unnecessary flooding across the entire infrastructure. Optimization is provided through specific ARP termination and the ability to block unknown unicast flooding. Additionally, EVPN procedures allow for intelligent, close to the source, inter-subnet forwarding and solves the commonly known suboptimal routing problem. Besides the traffic efficiency, ingress- based inter-subnet forwarding also optimizes packet forwarding rules and implementation at the egress nodes as well. Details of these procedures are outlined in Sections 9.1 and 9.2.9.1. Control-Plane Procedures
9.1.1. MAC Learning Options
The fundamental premise of [RFC7432] is the notion of a different approach to MAC address learning compared to traditional IEEE 802.1 bridge learning methods; specifically, EVPN differentiates between data and control-plane-driven learning mechanisms. Data-driven learning implies that there is no separate communication channel used to advertise and propagate MAC addresses. Rather, MAC addresses are learned through IEEE-defined bridge learning procedures as well as by snooping on DHCP and ARP requests. As different MAC addresses show up on different ports, the Layer 2 (L2) FIB is populated with the appropriate MAC addresses.
Control-plane-driven learning implies a communication channel that
could be either a control-plane protocol or a management-plane
mechanism. In the context of EVPN, two different learning procedures
are defined: local and remote procedures.
o Local learning defines the procedures used for learning the MAC
addresses of network elements locally connected to a MAC-VRF.
Local learning could be implemented through all three learning
procedures: control plane, management plane, and data plane.
However, the expectation is that for most of the use cases, local
learning through the data plane should be sufficient.
o Remote learning defines the procedures used for learning MAC
addresses of network elements remotely connected to a MAC-VRF,
i.e., far-end PEs. Remote learning procedures defined in
[RFC7432] advocate using only control-plane learning, BGP
specifically. Through the use of BGP EVPN NLRIs, the remote PE
has the capability of advertising all the MAC addresses present in
its local FIB.
9.1.2. Proxy ARP/ND
In EVPN, MAC addresses are advertised via the MAC/IP Advertisement
route, as discussed in [RFC7432]. Optionally, an IP address can be
advertised along with the MAC address advertisement. However, there
are certain rules put in place in terms of IP address usage: if the
MAC/IP Route contains an IP address, this particular IP address
correlates directly with the advertised MAC address. Such
advertisement allows us to build a proxy ARP / Neighbor Discovery
(ND) table populated with the IP<->MAC bindings received from all the
remote nodes.
Furthermore, based on these bindings, a local MAC-VRF can now provide
proxy ARP/ND functionality for all ARP requests and ND solicitations
directed to the IP address pool learned through BGP. Therefore, the
amount of unnecessary L2 flooding (ARP/ND requests/solicitations in
this case) can be further reduced by the introduction of proxy ARP/ND
functionality across all EVI MAC-VRFs.
9.1.3. Unknown Unicast Flooding Suppression
Given that all locally learned MAC addresses are advertised through
BGP to all remote PEs, suppressing flooding of any unknown unicast
traffic towards the remote PEs is a feasible network optimization.
The assumption in the use case is made that any network device that
appears on a remote MAC-VRF will somehow signal its presence to the
network. This signaling can be done through, for example, gratuitous
ARPs. Once the remote PE acknowledges the presence of the node in the MAC-VRF, it will do two things: install its MAC address in its local FIB and advertise this MAC address to all other BGP speakers via EVPN NLRI. Therefore, we can assume that any active MAC address is propagated and learned through the entire EVI. Given that MAC addresses become prepopulated -- once nodes are alive on the network -- there is no need to flood any unknown unicast towards the remote PEs. If the owner of a given destination MAC is active, the BGP route will be present in the local RIB and FIB, assuming that the BGP import policies are successfully applied; otherwise, the owner of such destination MAC is not present on the network. It is worth noting that unknown unicast flooding must not be suppressed unless (at least) one of the following two statements is given: a) control- or management-plane learning is performed throughout the entire EVI for all the MACs or b) all the EVI-attached devices signal their presence when they come up (Gratuitous ARP (GARP) packets or similar).9.1.4. Optimization of Inter-Subnet Forwarding
In a scenario in which both L2 and L3 services are needed over the same physical topology, some interaction between EVPN and IP-VPN is required. A common way of stitching the two service planes is through the use of an Integrated Routing and Bridging (IRB) interface, which allows for traffic to be either routed or bridged depending on its destination MAC address. If the destination MAC address is the one from the IRB interface, traffic needs to be passed through a routing module and potentially be either routed to a remote PE or forwarded to a local subnet. If the destination MAC address is not the one from the IRB interface, the MAC-VRF follows standard bridging procedures. A typical example of EVPN inter-subnet forwarding would be a scenario in which multiple IP subnets are part of a single or multiple EVIs, and they all belong to a single IP-VPN. In such topologies, it is desired that inter-subnet traffic can be efficiently routed without any tromboning effects in the network. Due to the overlapping physical and service topology in such scenarios, all inter-subnet connectivity will be locally routed through the IRB interface. In addition to optimizing the traffic patterns in the network, local inter-subnet forwarding also greatly optimizes the amount of processing needed to cross the subnets. Through EVPN MAC advertisements, the local PE learns the real destination MAC address associated with the remote IP address and the inter-subnet forwarding
can happen locally. When the packet is received at the egress PE, it is directly mapped to an egress MAC-VRF and bypasses any egress IP-VPN processing. Please refer to [EVPN-INTERSUBNET] for more information about the IP inter-subnet forwarding procedures in EVPN.9.2. Packet Walk-Through Examples
Assuming that the services are set up according to Figure 1 in Section 3, the following flow optimization processes will take place in terms of creating, receiving, and forwarding packets across the network.9.2.1. Proxy ARP Example for CE2-to-CE3 Traffic
Using Figure 1 in Section 3, consider EVI400 residing on PE1, PE2, and PE3 connecting CE2 and CE3 networks. Also, consider that PE1 and PE2 are part of the all-active multihoming ES for CE2, and that PE2 is elected designated forwarder for EVI400. We assume that all the PEs implement the proxy ARP functionality in the MAC-VRF-400 context. In this scenario, PE3 will not only advertise the MAC addresses through the EVPN MAC Advertisement route but also IP addresses of individual hosts (i.e., /32 prefixes) behind CE3. Upon receiving the EVPN routes, PE1 and PE2 will install the MAC addresses in the MAC- VRF-400 FIB and, based on the associated received IP addresses, PE1 and PE2 can now build a proxy ARP table within the context of MAC- VRF-400. From the forwarding perspective, when a node behind CE2 sends a frame destined to a node behind CE3, it will first send an ARP request to, for example, PE2 (based on the result of the CE2 hashing). Assuming that PE2 has populated its proxy ARP table for all active nodes behind the CE3, and that the IP address in the ARP message matches the entry in the table, PE2 will respond to the ARP request with the actual MAC address on behalf of the node behind CE3. Once the nodes behind CE2 learn the actual MAC address of the nodes behind CE3, all the MAC-to-MAC communications between the two networks will be unicast.9.2.2. Flood Suppression Example for CE1-to-CE3 Traffic
Using Figure 1 in Section 3, consider EVI500 residing on PE1 and PE3 connecting CE1 and CE3 networks. Consider that both PE1 and PE3 have disabled unknown unicast flooding for this specific EVI context. Once the network devices behind CE3 come online, they will learn
their MAC addresses and create local FIB entries for these devices. Note that local FIB entries could also be created through either a control or management plane between PE and CE as well. Consequently, PE3 will automatically create EVPN Type 2 MAC Advertisement routes and advertise all locally learned MAC addresses. The routes will also include the corresponding MPLS Label. Given that PE1 automatically learns and installs all MAC addresses behind CE3, its MAC-VRF FIB will already be prepopulated with the respective next-hops and label assignments associated with the MAC addresses behind CE3. As such, as soon as the traffic sent by CE1 to nodes behind CE3 is received into the context of EVI500, PE1 will push the MPLS Label(s) onto the original Ethernet frame and send the packet to the MPLS network. As usual, once PE3 receives this packet, and depending on the forwarding model, PE3 will either do a next-hop lookup in the EVI500 context or just forward the traffic directly to the CE3. In the case that PE1 MAC-VRF-500 does not have a MAC entry for a specific destination that CE1 is trying to reach, PE1 will drop the frame since unknown unicast flooding is disabled. Based on the assumption that all the MAC entries behind the CEs are prepopulated through gratuitous ARP and/or DHCP requests, if one specific MAC entry is not present in the MAC-VRF-500 FIB on PE1, the owner of that MAC is not alive on the network behind the CE3; hence, the traffic can be dropped at PE1 instead of flooding and consuming network bandwidth.9.2.3. Optimization of Inter-subnet Forwarding Example for CE3-to-CE2 Traffic
Using Figure 1 in Section 3, consider that there is an IP-VPN 666 context residing on PE1, PE2, and PE3, which connects CE1, CE2, and CE3 into a single IP-VPN domain. Also consider that there are two EVIs present on the PEs, EVI600 and EVI60. Each IP subnet is associated with a different MAC-VRF context. Thus, there is a single subnet (subnet 600) between CE1 and CE3 that is established through EVI600. Similarly, there is another subnet (subnet 60) between CE2 and CE3 that is established through EVI60. Since both subnets are part of the same IP-VPN, there is a mapping of each EVI (or individual subnet) to a local IRB interface on the three PEs. If a node behind CE2 wants to communicate with a node on the same subnet seating behind CE3, the communication flow will follow the standard EVPN procedures, i.e., FIB lookup within the PE1 (or PE2) after adding the corresponding EVPN label to the MPLS Label stack (downstream label allocation from PE3 for EVI60).
When it comes to crossing the subnet boundaries, the ingress PE implements local inter-subnet forwarding. For example, when a node behind CE2 (EVI60) sends a packet to a node behind CE1 (EVI600), the destination IP address will be in the subnet 600, but the destination MAC address will be the address of the source node's default gateway, which in this case will be an IRB interface on PE1 (connecting EVI60 to IP-VPN 666). Once PE1 sees the traffic destined to its own MAC address, it will route the packet to EVI600, i.e., it will change the source MAC address to the one of the IRB interface in EVI600 and change the destination MAC address to the address belonging to the node behind CE1, which is already populated in the MAC-VRF-600 FIB, either through data- or control-plane learning. An important optimization to be noted is the local inter-subnet forwarding in lieu of IP-VPN routing. If the node from subnet 60 (behind CE2) is sending a packet to the remote end-node on subnet 600 (behind CE3), the mechanism in place still honors the local inter- subnet (inter-EVI) forwarding. In our use case, therefore, when the node from subnet 60 behind CE2 sends traffic to the node on subnet 600 behind CE3, the destination MAC address is the PE1 MAC-VRF-60 IRB MAC address. However, once the traffic locally crosses EVIs to EVI600 (via the IRB interface on PE1), the source MAC address is changed to that of the IRB interface and the destination MAC address is changed to the one advertised by PE3 via EVPN and already installed in MAC-VRF-600. The rest of the forwarding through PE1 is using the MAC-VRF-600 forwarding context and label space. Another very relevant optimization is due to the fact that traffic between PEs is forwarded through EVPN rather than through IP-VPN. In the example described above for traffic from EVI60 on CE2 to EVI600 on CE3, there is no need for IP-VPN processing on the egress PE3. Traffic is forwarded either to the EVI600 context in PE3 for further MAC lookup and next-hop processing or directly to the node behind CE3, depending on the egress forwarding model being used.10. Security Considerations
Please refer to the "Security Considerations" section in [RFC7432]. The standards produced by the SIDR Working Group address secure route origin authentication (e.g., RFCs 6480 through 6493) and route advertisement security (e.g., RFCs 8205 through 8211). They protect the integrity and authenticity of IP address advertisements and ASN/ IP prefix bindings. This document and [RFC7432] use BGP to convey other info (e.g., MAC addresses); thus, the protections offered by the SIDR WG RFCs are not applicable in this context.
11. IANA Considerations
This document has no IANA actions.12. References
12.1. Normative References
[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, <https://www.rfc-editor.org/info/rfc7209>. [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, <https://www.rfc-editor.org/info/rfc7432>.12.2. Informative References
[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, <https://www.rfc-editor.org/info/rfc4761>. [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, <https://www.rfc-editor.org/info/rfc4762>. [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, DOI 10.17487/RFC6074, January 2011, <https://www.rfc-editor.org/info/rfc6074>. [EVPN-INTERSUBNET] Sajassi, A., Salam, S., Thoria, S., Drake, J., Rabadan, J., and L. Yong, "Integrated Routing and Bridging in EVPN", Work in Progress, draft-ietf-bess-evpn-inter- subnet-forwarding-03, February 2017.Acknowledgments
The authors want to thank Giles Heron for his detailed review of the document. We also thank Stefan Plug and Eric Wunan for their comments.
Contributors
The following people contributed substantially to the content of this document and should be considered coauthors: Florin Balus Keyur Patel Aldrin Isaac Truman BoyesAuthors' Addresses
Jorge Rabadan (editor) Nokia 777 E. Middlefield Road Mountain View, CA 94043 United States America Email: jorge.rabadan@nokia.com Senad Palislamovic Nokia Email: senad.palislamovic@nokia.com Wim Henderickx Nokia Copernicuslaan 50 2018 Antwerp Belgium Email: wim.henderickx@nokia.com Ali Sajassi Cisco Email: sajassi@cisco.com James Uttaro AT&T Email: uttaro@att.com