List of EVPN and DC-related IETF drafts (as of 1H 2018)
Ethernet Virtual Private Network (EVPN) solution is becoming pervasive for Network Virtualization Overlay (NVO) services in data center (DC) networks and as the next generation VPN services in service provider (SP) networks. As a result of this popularity a lot of work is going on in IETF in this area. In this post I collect links to some of the interesting IETF drafts in this area.
All this information is relevant for 1H 2018 timeframe. Keep in mind to pay attention to which version of draft you’re reading – this drafts are frequently updated.
Service Chaining using Virtual Networks with BGP VPNs
This document describes how service function chains (SFC) can be applied to traffic flows using routing in a virtual (overlay) network to steer traffic between service nodes. Chains can include services running in routers, on physical appliances or in virtual machines. Two techniques are described: in one the service chain is implemented as a sequence of distinct VPNs between sets of service nodes that apply each service function; in the other, the routes within a VPN are modified through the use of special route targets and modified next-hop resolution to achieve the desired result.
Applicability of EVPN to NVO3 Networks
In NVO3 networks, Network Virtualization Edge (NVE) devices sit at the edge of the underlay network and provide Layer-2 and Layer-3 connectivity among Tenant Systems (TSes) of the same tenant. This document describes the applicability of EVPN to NVO3 networks and how EVPN solves the challenges in those networks.
Some Service Providers want to extend the concept of the physical links in an ES to Ethernet Virtual Circuits (EVCs) where many of such EVCs can be aggregated on a single physical External Network-to-Network Interface (ENNI). An ES that consists of a set of EVCs instead of physical links is referred to as a virtual ES (vES). This draft describes the requirements and the extensions needed to support vES in EVPN and PBB-EVPN.
EVPN Seamless Integration with VPLS
This draft specifies procedures for backward compatibility of the EVPN solution with VPLS and provides mechanisms for seamless integration of the two technologies in the same MPLS/IP network on a per-VPN-instance basis. Implementation of this draft enables service providers to introduce EVPN PEs in their brown-field deployments of VPLS networks.
EVPN Integration with VPLS in All-Active Mode
This draft discusses the backward compatibility of the EVPN solution with VPLS in all-active redundancy mode.
EVPN VPWS Flexible Cross-Connect Service
This document describes a new EVPN VPWS service type specifically for multiplexing multiple attachment circuits across different Ethernet Segments and physical interfaces into a single EVPN VPWS service tunnel and still providing Single-Active and All-Active multi-homing. This new service is referred to as flexible cross-connect service. It also describes the rational for this new service type as well as a solution to deliver such service.
EVPN Vendor-Specific Route Type
RFC7432 defines Ethernet VPN as a BGP address family that makes use of Typed NLRIs. IANA has a registry called “EVPN Route Types” that allocates values to Route Types. The purpose of this document is to solicit IANA the registration of a route type value for a vendor specific usage, as well as the definition of the EVPN NLRI for that route.
Extended Mobility Procedures for EVPN-IRB
Intent of this draft is to enumerate a set of design considerations applicable to mobility across EVPN IRB use cases and define generic sequence number assignment procedures to address these IRB use cases.
Loop Protection in EVPN networks
This document describes a mechanism to provide global loop protection in EVPN networks.
EVPN Multi-Homing Mechanism for Layer-2 Gateway Protocols
Existing EVPN multi-homing load-balancing modes are limited to Single-Active and All-Active. Neither of these multi-homing mechanisms are sufficient to support access networks with Layer-2 Gateway protocols such as MST-AG, REP-AG, and G.8032. These Layer-2 Gateway protocols require a new multi-homing mechanism defined in this draft.
EVPN multi-homing port-active load-balancing
EVPN standard defines EVPN based MC-LAG with single-active and all-active multi-homing load-balancing mode. The current draft expands on existing redundancy mechanisms supported by EVPN and introduces support of port-active load-balancing mode. In the current draft, port-active load-balancing mode is also referred to as per interface active/standby.
Weighted Multi-Path Procedures for EVPN All-Active Multi-Homing
In an EVPN-IRB based network overlay, EVPN LAG enables all-active multi-homing for a host or CE device connected to two or more PEs via a LAG bundle, such that bridged and routed traffic from remote PEs can be equally load balanced (ECMPed) across the multi-homing PEs. This document defines extensions to EVPN procedures to optimally handle unequal access bandwidth distribution across a set of multi-homing PEs.
EVPN All Active Usage Enhancement
A principal feature of EVPN is the ability to support multihoming from a customer equipment (CE) to multiple provider edge equipment (PE) active with all-active links. This draft specifies an improvement to load balancing such links.
Updates on EVPN BUM Procedures
This document specifies procedure updates for broadcast, unknown unicast, and multicast (BUM) traffic in Ethernet VPNs (EVPN), including selective multicast, and provider tunnel segmentation.
Operational Aspects of Proxy-ARP/ND in EVPN Networks
This document describes how the [RFC7432] EVPN proxy-ARP/ND function may be implemented to help IXPs and other operators deal with the issues derived from Address Resolution in large broadcast domains.
Propagation of IPv6 Neighbor Advertisement Flags in EVPN
This document proposes an OPTIONAL advertisement of the Flags defined in [RFC4861] along with the EVPN MAC/IP Advertisement routes, so that an EVPN PE implementing a proxy-ND function can reply to Neighbor Solicitations with the correct Flag information in Neighbor Advertisements.
BGP EVPN Flood Traffic Optimization
In EVPN, the Broadcast, Unknown Unicast and Multicast (BUM) traffic is sent to all the routers participating in the EVPN instance. In a multi-homing scenario, when more than one PEs share the same Ethernet Segment, i.e. there are more than one PEs in a redundancy group, only the PE that is the Designated-Forwarder (DF) for the ES will forward that packet on the access interface whereas all non-DF PEs will drop the packet. From the perspective of the network, this is quite wasteful. This is especially true if there are significantly more PEs on the Ethernet Segment. This draft explores this problem and provides a solution for the same.
Framework for EVPN Designated Forwarder Election Extensibility
This default DF Election algorithm has some inefficiencies that this document addresses by defining a new DF Election algorithm and a capability to influence the DF Election result for a VLAN, depending on the state of the associated Attachment Circuit (AC). In addition, this document creates a registry with IANA, for future DF Election Algorithms and Capabilities. It also presents a formal definition and clarification of the DF Election Finite State Machine.
Preference-based EVPN DF Election
This document proposes an extension to the current RFC7432 DF election ‘service-carving’ algorithm for a more ‘deterministic’ and user-controlled method.
Fast Recovery for EVPN DF Election
This draft makes further improvement to DF election procedures in [DF-FRAMEWORK] by providing two options for fast DF election upon recovery of the failed link or node associated with the multi-homing Ethernet Segment. This fast DF election is achieved independent of number of EVIs associated with that Ethernet Segment and it is performed via a simple signaling between the recovered PE and each PE in the multi-homing group.
This document proposes a centralized DF Designated Forwarder election mechanism to be used between an SDN (Software Defined Network) controller and each PE (Provider Edge) device in an EVPN network. Such a mechanism overcomes the issues of current standalone DF election defined in RFC 7432. A new BGP capability and an additional DF Election Result Route Type are specified to support this centralized DF mechanism.
Per multicast flow Designated Forwarder Election for EVPN
[RFC7432] describes mechanism to elect designated forwarder (DF) at the granularity of (ESI, EVI) which is per VLAN (or per group of VLANs in case of VLAN bundle or VLAN-aware bundle service). However, the current level of granularity of per-VLAN is not adequate for some applications.[I-D.ietf-bess-evpn-df-election-framework] improves base line DF election by introducing HRW DF election. [I-D.ietf-bess-evpn-igmp-mld-proxy] introduces applicability of EVPN to Multicast flows, routes to sync them and a default DF election. This document is an extension to HRW base draft [I-D.ietf-bess-evpn-df-election-framework] and further enhances HRW algorithm for the Multicast flows to do DF election at the granularity of (ESI, VLAN, Mcast flow).
Optimized Ingress Replication solution for EVPN
This document describes a solution to optimize the efficiency of IR in NVO networks.
This draft describes how to support efficiently endpoints running IGMP over an EVPN network by incorporating IGMP proxy procedures on EVPN PEs.
EVPN Optimized Inter-Subnet Multicast (OISM) Forwarding
This document specifies new procedures that allow inter- subnet IP multicast traffic to be routed among the LANs of a given tenant, while still making intra-subnet IP multicast traffic appear to be bridged. These procedures can provide optimal routing of the inter-subnet multicast traffic, and do not require any such traffic to leave a given router and then reenter that same router. These procedures also accommodate IP multicast traffic that needs to travel to or from systems that are outside the EVPN domain.
Seamless Multicast Interoperability between EVPN and MVPN PEs
This document describes a unified solution based on RFCs 6513 & 6514 for seamless interoperability of multicast VPN between EVPN and MVPN PEs. Furthermore, it describes how the proposed solution can be used as a routed multicast solution in data centers with only EVPN PEs.
MVPN/EVPN Tunnel Aggregation with Common Labels
The MVPN specifications allow a single Point-to-Multipoint (P2MP) tunnel to carry traffic of multiple VPNs. The EVPN specifications allow a single P2MP tunnel to carry traffic of multiple Broadcast Domains (BDs). These features require the ingress router of the P2MP tunnel to allocate an upstream-assigned MPLS label for each VPN or for each BD. A packet sent on a P2MP tunnel then carries the label that is mapped to its VPN or BD. (In some cases, a distinct upstream-assigned is needed for each flow.) Since each ingress router allocates labels independently, with no coordination among the ingress routers, the egress routers may need to keep track of a large number of labels. The number of labels may need to be as large (or larger) than the product of the number of ingress routers times the number of VPNs or BDs. However, the number of labels can be greatly reduced if the association between a label and a VPN or BD is made by provisioning, so that all ingress routers assign the same label to a particular VPN or BD. New procedures are needed in order to take advantage of such provisioned labels. These new procedures also apply to Multipoint-to-Multipoint (MP2MP) tunnels. This document updates RFCs 6514, 7432 and 7582 by specifying the necessary procedures.
EVPN Multicast Synchronization Enhancement
In the scenario of multi-homing from a CE to multiple PEs with links used in a single-active or all-active redundancy mode, IGMP & MLD Join/Leave and PIM Join/RPT-Prune synchronization procedures have been provided. This document specifies an enhancement for IGMP/PIM signaling synchronization when using different Ethernet tag encapsulation mode.
EVPN Operations, Administration and Maintenance Requirements and Framework
This document specifies the requirements and reference framework for Ethernet VPN (EVPN) Operations, Administration and Maintenance (OAM). The requirements cover the OAM aspects of EVPN and PBB-EVPN. The framework defines the layered OAM model encompassing the EVPN service layer, network layer and underlying Packet Switched Network (PSN) transport layer.
Benchmarking Methodology for EVPN and PBB-EVPN
This document defines methodologies for benchmarking EVPN and PBB-EVPN performance. Specifically this document defines the methodologies for benchmarking EVPN/PBB-EVPN convergence, data plane performance, and control plane performance.
Fault Management for EVPN networks
This document specifies a proactive, in-band network OAM mechanism to detect loss of continuity and miss-connection faults that affect unicast and multi-destination paths, used by Broadcast, unknown Unicast and Multicast traffic, in an EVPN network. The mechanisms proposed in the draft use the widely adopted Bidirectional Forwarding Detection (BFD) protocol.
LSP-Ping Mechanisms for EVPN and PBB-EVPN
LSP-Ping is a widely deployed Operation, Administration, and Maintenance (OAM) mechanism in MPLS networks. This document describes mechanisms for detecting data-plane failures using LSP Ping in MPLS based EVPN and PBB-EVPN networks.
EVPN Ping Mechanism for Virtual eXtensible Local Area Network (VXLAN)
Ping is a widely deployed Operation, Administration, and Maintenance (OAM) mechanism in networks. This document describes a mechanism for detecting data-plane failures using Ping in RFC7348 VXLAN based EVPN networks.
This document describes use of Bidirectional Forwarding Detection (BFD) protocol in Virtual eXtensible Local Area Network (VXLAN) overlay network.