Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8388

Usage and Applicability of BGP MPLS-Based Ethernet VPN

Pages: 31
Informational
Part 2 of 2 – Pages 20 to 31
First   Prev   None

Top   ToC   RFC8388 - Page 20   prevText

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.
Top   ToC   RFC8388 - Page 21

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.
Top   ToC   RFC8388 - Page 22

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.
Top   ToC   RFC8388 - Page 23
   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.
Top   ToC   RFC8388 - Page 24
   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.
Top   ToC   RFC8388 - Page 25
   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
Top   ToC   RFC8388 - Page 26
   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
Top   ToC   RFC8388 - Page 27
   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
Top   ToC   RFC8388 - Page 28
   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).
Top   ToC   RFC8388 - Page 29
   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.
Top   ToC   RFC8388 - Page 30

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.
Top   ToC   RFC8388 - Page 31

Contributors

The following people contributed substantially to the content of this document and should be considered coauthors: Florin Balus Keyur Patel Aldrin Isaac Truman Boyes

Authors' 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