| |
|
| |
| | Optimized Ingress Replication Solution for Ethernet VPN (EVPN) |
| |
|
Network Virtualization Overlay networks using Ethernet VPN (EVPN) as their control plane may use Ingress Replication or PIM (Protocol Independent Multicast)-based trees to convey the overlay Broadcast, Unknown unicast and Multicast (BUM) traffic. PIM provides an efficient solution to avoid sending multiple copies of the same packet over the same physical link, however it may not always be deployed in the Network Virtualization Overlay core network. Ingress Replication avoids the dependency on PIM in the Network Virtualization Overlay network core. While Ingress Replication provides a simple multicast transport, some Network Virtualization Overlay networks with demanding multicast applications require a more efficient solution without PIM in the core. This document describes a solution to optimize the efficiency of Ingress Replication trees. |
| | Updates on EVPN BUM Procedures |
| |
|
This document specifies updated procedures for handling broadcast, unknown unicast, and multicast (BUM) traffic in Ethernet VPNs (EVPN), including selective multicast, and provider tunnel segmentation. This document updates RFC 7432. |
| | Preference-based EVPN DF Election |
| |
|
The Designated Forwarder (DF) in Ethernet Virtual Private Networks (EVPN) is defined as the Provider Edge (PE) router responsible for sending Broadcast, Unknown unicast and Multicast traffic (BUM) to a multi-homed device/network in the case of an all-active multi-homing Ethernet Segment (ES), or BUM and unicast in the case of single- active multi-homing. The Designated Forwarder is selected out of a candidate list of PEs that advertise the same Ethernet Segment Identifier (ESI) to the EVPN network, according to the Default Designated Forwarder Election algorithm. While the Default Algorithm provides an efficient and automated way of selecting the Designated Forwarder across different Ethernet Tags in the Ethernet Segment, there are some use cases where a more 'deterministic' and user- controlled method is required. At the same time, Network Operators require an easy way to force an on-demand Designated Forwarder switchover in order to carry out some maintenance tasks on the existing Designated Forwarder or control whether a new active PE can preempt the existing Designated Forwarder PE. This document proposes a Designated Forwarder Election algorithm that meets the requirements of determinism and operation control. This document updates RFC8584 by modifying the definition of the DF Election Extended Community. |
| | EVPN Optimized Inter-Subnet Multicast (OISM) Forwarding |
| |
|
Ethernet VPN (EVPN) provides a service that allows a single Local Area Network (LAN), comprising a single IP subnet, to be divided into multiple "segments". Each segment may be located at a different site, and the segments are interconnected by an IP or MPLS backbone. Intra-subnet traffic (either unicast or multicast) always appears to the end users to be bridged, even when it is actually carried over the IP or MPLS backbone. When a single "tenant" owns multiple such LANs, EVPN also allows IP unicast traffic to be routed between those LANs. 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 egress a given router and then ingress that same router. These procedures also accommodate IP multicast traffic that originates or is destined external to the EVPN domain. |
| | EVPN VPWS Flexible Cross-Connect Service |
| |
| | draft-ietf-bess-evpn-vpws-fxc-08.txt |
| | Date: |
24/10/2022 |
| | Authors: |
Ali Sajassi, Patrice Brissette, Jim Uttaro, John Drake, Sami Boutros, Jorge Rabadan |
| | Working Group: |
BGP Enabled ServiceS (bess) |
|
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. After a description of the rationale for this new service type, the solution to deliver such service is detailed. |
| | Fast Recovery for EVPN Designated Forwarder Election |
| |
|
The Ethernet Virtual Private Network (EVPN) solution provides Designated Forwarder (DF) election procedures for multihomed Ethernet Segments. These procedures have been enhanced further by applying Highest Random Weight (HRW) algorithm for Designated Forwarder election in order to avoid unnecessary DF status changes upon a failure. This document improves these procedures by providing a fast Designated Forwarder election upon recovery of the failed link or node associated with the multihomed Ethernet Segment. This document updates Section 2.1 of [RFC8584] by optionally introducing delays between some of the events therein. The solution is independent of the number of EVPN Instances (EVIs) associated with that Ethernet Segment and it is performed via a simple signaling between the recovered node and each of the other nodes in the multihoming group. |
| | EVPN Virtual Ethernet Segment |
| |
|
Etheret VPN (EVPN) and Provider Backbone EVPN (PBB-EVPN) introduce a family of solutions for Ethernet services over MPLS/IP network with many advanced features including multi-homing capabilities. These solutions introduce Single-Active and All-Active redundancy modes for an Ethernet Segment (ES), itself defined as a set of physical links between the multi-homed device/network and a set of PE devices that they are connected to. This document extends the Ethernet Segment concept so that an ES can be associated to a set of Ethernet Virtual Circuits (EVCs e.g., VLANs) or other objects such as MPLS Label Switch Paths (LSPs) or Pseudowires (PWs). Such an ES is referred to as Virtual Ethernet Segments (vES). This draft describes the requirements and the extensions needed to support vES in EVPN and PBB-EVPN. |
| | Weighted Multi-Path Procedures for EVPN Multi-Homing |
| |
| | draft-ietf-bess-evpn-unequal-lb-21.txt |
| | Date: |
07/12/2023 |
| | Authors: |
Neeraj Malhotra, Ali Sajassi, Jorge Rabadan, John Drake, Avinash Lingala, Samir Thoria |
| | Working Group: |
BGP Enabled ServiceS (bess) |
|
EVPN enables all-active multi-homing for a CE (Customer Equipment) device connected to two or more PE (Provider Equipment) devices via a LAG (Link Aggregation), such that bridged and routed traffic from remote PEs to hosts attached to the Ethernet Segment can be equally load balanced (it uses Equal Cost Multi Path) across the multi-homing PEs. EVPN also enables multi-homing for IP subnets advertised in IP Prefix routes, so that routed traffic from remote PEs to those IP subnets can be load balanced. This document defines extensions to EVPN procedures to optimally handle unequal access bandwidth distribution across a set of multi-homing PEs in order to: * provide greater flexibility, with respect to adding or removing individual multi-homed PE-CE links. * handle multi-homed PE-CE link failures that can result in unequal PE-CE access bandwidth across a set of multi-homing PEs. In order to achieve the above, it specifies signaling extensions and procedures to: * Loadbalance bridged and routed traffic across egress PEs in proportion to PE-CE link bandwidth or a generalized weight distribution. * Achieve BUM (Broadcast, UnknownUnicast, Multicast) DF (Designated Forwarder) election distribution for a given ES (Ethernet Segment) across the multi-homing PE set in proportion to PE-CE link bandwidth. Section 6 of this document further updates RFC 8584, draft-ietf-bess-evpn-per-mcast-flow-df-election and draft-ietf- bess-evpn-pref-df in order for the DF election extension defined in this document to work across different DF election algorithms. |
| | MVPN/EVPN Tunnel Aggregation with Common Labels |
| |
|
The MVPN specifications allow a single Point-to-Multipoint (P2MP) tunnel to carry traffic of multiple IP VPNs (abbreviated as 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 label 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 Interworking with IPVPN |
| |
|
Ethernet Virtual Private Network (EVPN) is used as a unified control plane for tenant network intra and inter-subnet forwarding. When a tenant network spans not only EVPN domains but also domains where BGP VPN-IP or IP families provide inter-subnet forwarding, there is a need to specify the interworking aspects between BGP domains of type EVPN, VPN-IP and IP, so that the end to end tenant connectivity can be accomplished. This document specifies how EVPN interworks with VPN-IPv4/VPN-IPv6 and IPv4/IPv6 BGP families for inter-subnet forwarding. The document also addresses the interconnect of EVPN domains for Inter-Subnet Forwarding routes. In addition, this specification defines a new BGP Path Attribute called D-PATH (Domain PATH) that protects gateways against control plane loops. D-PATH modifies the BGP best path selection for multiprotocol BGP routes of SAFI 128 and EVPN IP Prefix routes, and therefore this document updates the BGP best path selection in [RFC4271], but only for IPVPN and EVPN families. |
| | Extended Mobility Procedures for EVPN-IRB |
| |
|
The procedure to handle host mobility in a layer 2 Network with EVPN control plane is defined as part of RFC7432. EVPN has since evolved to find wider applicability across various IRB use cases that include distributing both MAC and IP reachability via a common EVPN control plane. MAC Mobility procedures defined in RFC7432 are extensible to IRB use cases if a fixed 1:1 mapping between host IP and MAC is assumed across host moves. Generic mobility support for IP and MAC addresses that allows these bindings to change across moves IS REQUIRED to support a broader set of EVPN IRB use cases. EVPN all- active multi-homing further introduces scenarios that require additional consideration from mobility perspective. This document enumerates a set of design considerations applicable to mobility across these EVPN IRB use cases and updates sequence number assignment procedures defined in RFC7432 to address these IRB use cases. NOTE TO IESG (TO BE DELETED BEFORE PUBLISHING): This draft lists six authors which is above the required limit of five. Given significant and active contributions to the draft from all six authors over the course of six years, we would like to request IESG to allow publication with six authors. Specifically, the three Cisco authors are the original inventors of these procedures and contributed heavily to rev 0 draft, most of which is still intact. AT&T is also a key contributor towards defining the use cases that this document addresses as well as the proposed solution. Authors from Nokia and Juniper have further contributed to revisions and discussions steadily over last six years to enable respective implementations and a wider adoption. |
| | Seamless Multicast Interoperability between EVPN and MVPN PEs |
| |
|
Ethernet Virtual Private Network (EVPN) solution is becoming pervasive for Network Virtualization Overlay (NVO) services in data center (DC) and Enterprise networks as well as the next generation VPN services in service provider (SP) networks. As service providers transform their networks in their Central Offices (COs) towards the next generation data center with Software Defined Networking (SDN) based fabric and Network Function Virtualization (NFV), they want to be able to maintain their offered services including Multicast VPN (MVPN) service between their existing network and their new Service Provider Data Center (SPDC) network seamlessly without the use of gateway devices. They want to have such seamless interoperability between their new SPDCs and their existing networks for a) reducing cost, b) having optimum forwarding, and c) reducing provisioning. 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. |
| | Controller Based BGP Multicast Signaling |
| |
|
This document specifies a way that one or more centralized controllers can use BGP to set up multicast distribution trees (identified by either IP source/destination address pair, or mLDP FEC) in a network. Since the controllers calculate the trees, they can use sophisticated algorithms and constraints to achieve traffic engineering. The controllers directly signal dynamic replication state to tree nodes, leading to very simple multicast control plane on the tree nodes, as if they were using static routes. This can be used for both underlay and overlay multicast trees, including replacing BGP-MVPN signaling. |
| | BGP Based Multicast |
| |
| | draft-ietf-bess-bgp-multicast-07.txt |
| | Date: |
02/12/2023 |
| | Authors: |
Zhaohui Zhang, Lenny Giuliano, Keyur Patel, IJsbrand Wijnands, Mankamana Mishra, Arkadiy Gulko |
| | Working Group: |
BGP Enabled ServiceS (bess) |
|
This document specifies a BGP address family and related procedures that allow BGP to be used for setting up multicast distribution trees. This document also specifies procedures that enable BGP to be used for multicast source discovery, and for showing interest in receiving particular multicast flows. Taken together, these procedures allow BGP to be used as a replacement for other multicast routing protocols, such as PIM or mLDP. The BGP procedures specified here are based on the BGP multicast procedures that were originally designed for use by providers of Multicast Virtual Private Network service. This document also describes how various signaling mechanisms can be used to set up end-to-end inter-region multicast trees. |
| | EVPN Port-Active Redundancy Mode |
| |
| | draft-ietf-bess-evpn-mh-pa-10.txt |
| | Date: |
04/03/2024 |
| | Authors: |
Patrice Brissette, Luc Burdet, Bin Wen, Eddie Leyton, Jorge Rabadan |
| | Working Group: |
BGP Enabled ServiceS (bess) |
|
The Multi-Chassis Link Aggregation Group (MC-LAG) technology enables establishing a logical link-aggregation connection with a redundant group of independent nodes. The purpose of multi-chassis LAG is to provide a solution to achieve higher network availability while providing different modes of sharing/balancing of traffic. RFC7432 defines EVPN-based MC-LAG with Single-active and All-active multi-homing redundancy modes. This document expands on existing redundancy mechanisms supported by EVPN and introduces a new Port- Active redundancy mode. |
| | Extended Procedures for EVPN Optimized Ingress Replication |
| |
|
In the Virtualization Overlay (NVO) network with Ethernet VPN (EVPN), optimized ingress replication uses Assisted-Replication (AR) to achieve more efficient delivery of Broadcast and Multicast (BM) traffic. An AR-LEAF, which is a Network Virtualization Edge (NVE) device, forwards received BM traffic from its tenant system to an AR- REPLICATOR. The AR-REPLICATOR then replicates it to the remaining AR-LEAFs in the network. However, when replicating the packet on behalf of its multihomed AR-LEAF, an AR-REPLICATOR may face challenges in retaining the source IP address or including the expected Ethernet Segment Identifier (ESI) label that is required for EVPN split-horizon filtering. This document extends the optimized ingress replication procedures to address such limitations. The extended procedures specified in this document allow the support of EVPN multihoming on the AR-LEAFs as well as optimized ingress replication for the rest of the EVPN NVO network. |
| | EVPN Network Layer Fault Management |
| |
| | draft-ietf-bess-evpn-bfd-06.txt |
| | Date: |
01/03/2024 |
| | Authors: |
Vengada Govindan, Mallik Mudigonda, Ali Sajassi, Greg Mirsky, Donald Eastlake |
| | Working Group: |
BGP Enabled ServiceS (bess) |
|
This document specifies proactive, in-band network layer OAM mechanisms to detect loss of continuity faults that affect unicast and multi-destination paths (used by Broadcast, Unknown Unicast, and Multicast traffic) in an Ethernet VPN (RFC 7432bis) network. The mechanisms specified in the draft use the widely adopted Bidirectional Forwarding Detection (RFC 5880) protocol and other protocols as necessary. |
| | BGP Usage for SD-WAN Overlay Networks |
| |
|
This document explores the complexities involved in managing large scale Software Defined WAN (SD-WAN) overlay networks, along with various SD-WAN scenarios. Its objective is to illustrate how the BGP-based control plane can effectively manage large-scale SD-WAN overlay networks with minimal manual intervention. |
| | EVPN Multi-Homing Extensions for Split Horizon Filtering |
| |
|
Ethernet Virtual Private Network (EVPN) is commonly used along with Network Virtualization Overlay (NVO) tunnels, as well as MPLS and Segment Routing tunnels. The EVPN multi-homing procedures may be different depending on the tunnel type used in the EVPN Broadcast Domain. In particular, there are two multi-homing Split Horizon procedures to avoid looped frames on the multi-homed CE: ESI Label based and Local Bias. ESI Label based Split Horizon is used for MPLSoX tunnels, E.g., MPLSoUDP, whereas Local Bias is used for other tunnels, E.g., VXLAN tunnels. The existing specifications do not allow the operator to decide which Split Horizon procedure to use for tunnel encapsulations that could support both. Examples of tunnels that may support both procedures are MPLSoGRE, MPLSoUDP, GENEVE or SRv6. This document updates the EVPN Multihoming procedures in RFC8365 and RFC7432 so that an operator can decide the Split Horizon procedure for a given tunnel depending on their own requirements. |
| | Multicast and Ethernet VPN with Segment Routing P2MP and Ingress Replication |
| |
| | draft-ietf-bess-mvpn-evpn-sr-p2mp-08.txt |
| | Date: |
06/11/2023 |
| | Authors: |
Rishabh Parekh, Clarence Filsfils, Arvind Venkateswaran, Hooman Bidgoli, Dan Voyer, Zhaohui Zhang |
| | Working Group: |
BGP Enabled ServiceS (bess) |
|
A Point-to-Multipoint (P2MP) Tree in a Segment Routing domain carries traffic from a Root to a set of Leaves. This document describes extensions to BGP encodings and procedures for P2MP trees and Ingress Replication used in BGP/MPLS IP VPNs and Ethernet VPNs in a Segment Routing domain. |
| | BGP MPLS-Based Ethernet VPN |
| |
|
This document describes procedures for Ethernet VPN (EVPN), a BGP MPLS-based solution which addresses the requirements specified in the corresponding RFC - "Requirements for Ethernet VPN (EVPN)". |
| | Multicast Source Redundancy in EVPN Networks |
| |
|
Ethernet Virtual Private Network (EVPN) supports intra and inter- subnet IP multicast forwarding. However, EVPN (or conventional IP multicast techniques for that matter) do not have a solution for the case where the following two statements are true at the same time: a) a given multicast group carries more than one flow (i.e., more than one source), and b) it is desired that each receiver gets only one of the several flows. Existing multicast techniques assume there are no redundant sources sending the same flow to the same IP multicast group, and, in case there were redundant sources, the receiver's application would deal with the received duplicated packets. This document extends the existing EVPN specifications and assumes that IP Multicast source redundancy may exist. It also assumes that, in case two or more sources send the same IP Multicast flows into the tenant domain, the EVPN PEs need to avoid that the receivers get packet duplication by following the described procedures. |
| | Cumulative DMZ Link Bandwidth and load-balancing |
| |
| | draft-ietf-bess-ebgp-dmz-04.txt |
| | Date: |
28/12/2023 |
| | Authors: |
MOHANTY Satya, Arie Vayner, Akshay Gattani, Ajay Kini, Jeff Tantsura |
| | Working Group: |
BGP Enabled ServiceS (bess) |
|
The DMZ Link Bandwidth draft provides a way to load-balance traffic to a destination which is reachable via more than one path according to the weight attahced. Typically, the link bandwidth (either configured on the link of the EBGP egress interface or set via a policy) is encoded in an extended community and then sent to the IBGP peer that employs multi-path. The link-bandwidth value is then extracted from the extended community and is used as a weight in the RIB/FIB, which does the load-balancing. This draft extends the usage of the DMZ link bandwidth to another setting where the ingress BGP speaker requires knowledge of the cumulative bandwidth while doing the load-balancing. The draft also proposes neighbor-level knobs to enable the link bandwidth extended community to be regenerated and then advertised to EBGP peers to override the default behavior of not advertising optional non-transitive attributes to EBGP peers. |
| | AC-Aware Bundling Service Interface in EVPN |
| |
|
An EVPN (Ethernet VPNs) provides an extensible and flexible multihoming VPN solution over an MPLS/IP network for intra-subnet connectivity among Tenant Systems and End Devices that can be physical or virtual. EVPN multihoming with Integrated Routing and Bridging (IRB) is one of the common deployment scenarios. Some deployments requires the capability to have multiple subnets designated with multiple VLAN IDs in the single broadcast domain. EVPN technology defines three different types of service interface which serve different requirements but none of them address the requirement of supporting multiple subnets within a single broadcast domain. In this document, we define a new service interface type to support multiple subnets in the single broadcast domain. Service interface proposed in this document will be applicable to multihoming cases only. |
| | SRv6 Argument Signaling for BGP Services |
| |
|
RFC9252 defines procedures and messages for SRv6-based BGP services including L3VPN, EVPN, and Internet services. This document updates RFC9252 and provides more detailed specifications for the signaling and processing of SRv6 SID advertisements for BGP Service routes associated with SRv6 Endpoint Behaviors that support arguments. |
| | IPv4-Only and IPv6-Only PE Design DESIGN ALL SAFI |
| |
| | draft-ietf-bess-v4-v6-pe-all-safi-00.txt |
| | Date: |
06/11/2023 |
| | Authors: |
Gyan Mishra, Mankamana Mishra, Jeff Tantsura, Sudha Madhavi, Qing Yang, Adam Simpson, Shuanglong Chen |
| | Working Group: |
BGP Enabled ServiceS (bess) |
|
As Enterprises and Service Providers upgrade their brown field or green field MPLS/SR core to an IPv6 transport, Multiprotocol BGP (MP- BGP)now plays an important role in the transition of their Provider (P) core network as well as Provider Edge (PE) Inter-AS peering network from IPv4 to IPv6. Operators must have flexiblity to continue to support IPv4 customers when both the Core and Edge networks migrate to IPv6. As well as must be able to support IPv6 networks in cases where operators decide to remain on an IPv4 network or during transition. This document details the External BGP (eBGP) PE-PE Inter-AS and PE- CE Edge peering IPv4-Only PE design where both IPv4 and IPv6 all supported SAFI NLRI can be advertised over a single IPv4 peer and IPv6-Only PE Design where all supported SAFI NLRI can be advertised over a single IPv6 peer. This document also defines a new IPv4 BGP next hop encoding standard that uses an IPv4 address as the next hop and not an IPv4 mapped IPv6 address. This document also provides vendor specific test cases for the IPv4-Only peering design and IPv6-Only PE design as well as test results for the five major vendors stakeholders in the routing and switching indusrty, Cisco, Juniper, Arista, Nokia and Huawei. With the test results provided for the IPv6-Only Edge peering design, the goal is that all other vendors around the world that have not been tested will begin to adopt and implement the design. |
| | EVPN Support for L3 Fast Convergence and Aliasing/Backup Path |
| |
|
This document proposes an EVPN extension to allow several of its multi-homing functions, fast convergence, and aliasing/backup path, to be used in conjunction with inter-subnet forwarding. The extension is limited to All-Active and Single-Active redundancy modes. |
| | Domain Path (D-PATH) for Ethernet VPN (EVPN) Interconnect Networks |
| |
| | draft-ietf-bess-evpn-dpath-00.txt |
| | Date: |
02/04/2024 |
| | Authors: |
Jorge Rabadan, Senthil Sathappan, Mallika Gautam, Patrice Brissette, Wen Lin |
| | Working Group: |
BGP Enabled ServiceS (bess) |
|
The BGP Domain PATH (D-PATH) attribute is defined for Inter-Subnet Forwarding (ISF) BGP Sub-Address Families that advertise IP prefixes. When used along with EVPN IP Prefix routes or IP-VPN routes, it identifies the domain(s) through which the routes have passed and that information can be used by the receiver BGP speakers to detect routing loops or influence the BGP best path selection. This document extends the use of D-PATH so that it can also be used along with other EVPN route types. |