EVPN Interworking with IPVPN
draft-ietf-bess-evpn-ipvpn-interworking-15
| Document | Type | Active Internet-Draft (bess WG) | |
|---|---|---|---|
| Authors | Jorge Rabadan , Ali Sajassi , Eric C. Rosen , John Drake , W. Lin , Jim Uttaro , Adam Simpson | ||
| Last updated | 2025-12-04 (Latest revision 2025-11-21) | ||
| Replaces | draft-rabadan-sajassi-bess-evpn-ipvpn-interworking | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | Proposed Standard | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | Submitted to IESG for Publication | |
| Document shepherd | Stephane Litkowski | ||
| Shepherd write-up | Show Last changed 2025-06-18 | ||
| IESG | IESG state | In Last Call (ends 2025-12-18) | |
| Action Holder | |||
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | Gunter Van de Velde | ||
| Send notices to | slitkows.ietf@gmail.com | ||
| IANA | IANA review state | IANA - Review Needed |
draft-ietf-bess-evpn-ipvpn-interworking-15
BESS Workgroup J. Rabadan, Ed.
Internet-Draft Nokia
Intended status: Standards Track A. Sajassi, Ed.
Expires: 25 May 2026 Cisco
E. Rosen
Individual
J. Drake
Independent
W. Lin
HPE
J. Uttaro
Independent
A. Simpson
Nokia
21 November 2025
EVPN Interworking with IPVPN
draft-ietf-bess-evpn-ipvpn-interworking-15
Abstract
Ethernet Virtual Private Network (EVPN) provides a unified BGP
control plane for both intra- and inter-subnet forwarding within
tenant networks. When a tenant network spans multiple domains —
including EVPN domains as well as domains that use BGP VPN-IP or IP
address families for inter-subnet forwarding — it becomes necessary
to define the interworking mechanisms among these BGP domains (EVPN,
VPN-IP, and IP) to ensure seamless end-to-end tenant connectivity.
In addition, this document defines a new BGP Path Attribute, referred
to as D-PATH (Domain PATH), which provides loop prevention for
gateway nodes by protecting against control plane loops. The
introduction of D-PATH modifies the BGP best path selection process
for Multiprotocol BGP routes of SAFI 128 (IPVPN) and EVPN IP Prefix
routes. As a result, this specification updates the BGP best path
selection procedure, but only in the context of IPVPN and EVPN route
families.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Rabadan, et al. Expires 25 May 2026 [Page 1]
Internet-Draft EVPN and IPVPN Interworking November 2025
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 25 May 2026.
Copyright Notice
Copyright (c) 2025 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 (https://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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction and Problem Statement . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 4
3. Terminology and Interworking PE Components . . . . . . . . . 4
4. Domain Path Attribute (D-PATH) . . . . . . . . . . . . . . . 11
5. BGP Path Attribute Propagation across Domains . . . . . . . . 18
5.1. No-Propagation Mode . . . . . . . . . . . . . . . . . . . 18
5.2. Uniform Propagation Mode . . . . . . . . . . . . . . . . 19
5.3. Aggregation of Routes and Path Attribute Propagation . . 20
6. Route Selection Process for ISF Routes . . . . . . . . . . . 21
6.1. Tie-Breaking and Selection Rules . . . . . . . . . . . . 22
6.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 23
7. Composite PE Procedures . . . . . . . . . . . . . . . . . . . 23
8. Gateway PE Procedures . . . . . . . . . . . . . . . . . . . . 26
8.1. Export Conditions . . . . . . . . . . . . . . . . . . . . 27
8.2. Advertisement Behavior . . . . . . . . . . . . . . . . . 28
9. Interworking Use-Cases . . . . . . . . . . . . . . . . . . . 30
10. BGP Error Handling on Interworking PEs . . . . . . . . . . . 31
11. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 32
12. Security Considerations . . . . . . . . . . . . . . . . . . . 33
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34
15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 34
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
16.1. Normative References . . . . . . . . . . . . . . . . . . 35
16.2. Informative References . . . . . . . . . . . . . . . . . 36
Rabadan, et al. Expires 25 May 2026 [Page 2]
Internet-Draft EVPN and IPVPN Interworking November 2025
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction and Problem Statement
EVPN is used as a unified BGP control plane to support both intra-
subnet and inter-subnet forwarding for tenant networks. In
deployments where a tenant network spans multiple domains, some of
which use EVPN, and others which rely on BGP VPN-IPv4/VPN-IPv6 or
IPv4/IPv6 address families for inter-subnet forwarding, it becomes
necessary to define interworking procedures to enable seamless end-
to-end tenant connectivity across these heterogeneous domains.
This document specifies procedures for interworking between EVPN and
other BGP address families, including VPN-IPv4, VPN-IPv6, IPv4, and
IPv6, specifically for the purpose of inter-subnet forwarding. It
also addresses the interconnection of one EVPN domain with another,
focusing on the propagation and handling of EVPN inter-subnet
forwarding routes across such domains.
To support loop prevention in scenarios where redundant gateway
Provider Edges (PEs) interconnect distinct domains, this
specification introduces a new BGP Path Attribute called the Domain
Path (D-PATH). In topologies where multiple gateways connect
domains, control plane loops may occur if routes are redistributed
between domains without proper safeguards. For example, if gateway
PE1 imports a VPN-IP route for a given prefix and redistributes it as
an EVPN IP Prefix route into the EVPN domain, and a second gateway PE
(PE2) receives this EVPN route and re-advertises it back into the
IPVPN domain, a loop may form. The D-PATH attribute is designed to
prevent such scenarios by providing domain-level loop detection and
avoidance.
The D-PATH attribute alters the BGP best path selection logic for
Multiprotocol BGP routes of SAFI 128 (VPN-IPv4/IPv6) and for EVPN IP
Prefix routes. Accordingly, this document updates the BGP best path
selection procedures specified in [RFC4271], but only in the context
of IPVPN and EVPN families.
EVPN supports the advertisement of IPv4 or IPv6 prefixes through two
route types:
* Route Type 2 - EVPN MAC/IP Advertisement route, as defined in
[RFC9135], supporting host routes (i.e., /32 or /128).
* Route Type 5 - EVPN IP Prefix route, as defined in [RFC9136].
Rabadan, et al. Expires 25 May 2026 [Page 3]
Internet-Draft EVPN and IPVPN Interworking November 2025
When interworking with other BGP address families for inter-subnet
forwarding, the IP prefixes conveyed in these EVPN route types must
be propagated into corresponding address families (e.g., VPN-IP), and
vice versa. Several aspects of this propagation require clarified
procedures, including route selection, loop prevention, and BGP Path
Attribute handling across AFI/SAFI boundaries.
This document defines the concept of an Interworking PE Section 3,
which is responsible for interconnecting different domains. An
Interworking PE implements the following behavior: it imports routes
from one domain (along with the domain-specific encapsulation
parameters), installs them in an IP-VRF, and reoriginates the routes
with the encapsulation attributes suitable for the adjacent domain
before advertisement. This reorigination process enables the
solution to operate independently of the transport encapsulation
mechanisms used within each domain and serves as a service
interworking function.
The procedures defined herein ensure that tenant inter-subnet
connectivity can be maintained across a mix of EVPN and non-EVPN
domains, while preventing routing loops and maintaining protocol
consistency across BGP address families.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Terminology and Interworking PE Components
This section summarizes the terminology related to the "Interworking
PE" concept that will be used throughout the rest of the document.
Rabadan, et al. Expires 25 May 2026 [Page 4]
Internet-Draft EVPN and IPVPN Interworking November 2025
+-------------------------------------------------------------+
| |
| +------------------+ Interworking PE |
| Attachment | +------------------+ |
| Circuit(AC1) | | +----------+ | MPLS/NVO tnl
----------------------*Bridge | | +------
| | | |Table(BT1)| | +-----------+ / \ \
MPLS/NVO tnl +-------->| *---------* |<--> | Eth |
-------+ | | | |Eth-Tag x + |IRB1| | \ / /
/ Eth / \<-+ | | +----------+ | | | +------
| | | | | ... | | IP-VRF1 | |
\ \ /<-+ | | +----------+ | | RD2/RT2 |MPLS/NVO tnl
-------+ | | | |Bridge | | | | +------
| +-------->|Table(BT2)| |IRB2| | / \ \
| | | | *---------* |<--> | IP |
----------------------*Eth-Tag y | | +-----*-----+ \ / /
| AC2 | | +----------+ | AC3| +------
| | | MAC-VRF1 | | |
| +-+ RD1/RT1 | | |
| +------------------+ | SAFIs |
| | 1 +---+ |
-------------------------------------------------+ 128 |BGP| |
| EVPN +---+ |
| |
+-------------------------------------------------------------+
Figure 1: EVPN-IPVPN Interworking PE
* ISF SAFI: the Inter-Subnet Forwarding (ISF) Subsequent Address
Family Identifier (SAFI) defines an MP-BGP Sub-Address Family used
to advertise IP prefix reachability for inter-subnet forwarding
within a tenant network. The SAFIs used for ISF include 1
(applicable only to IPv4 and IPv6 AFIs), 128 (applicable only to
IPv4 and IPv6 AFIs), and 70 (EVPN, applicable only to AFI 25).
This document uses the following terms interchangeably: ISF SAFI 1
or BGP IP, ISF SAFI 128 or IPVPN, ISF SAFI 70 or EVPN.
* ISF route: a route for a given prefix, whose ISF SAFI may change
as it transits different domains. BGP IP routes as in [RFC4760]
[RFC8950], IPVPN routes as in [RFC4364], [RFC4659], EVPN IP Prefix
routes as in [RFC9136] or EVPN MAC/IP Advertisement routes when
they are programmed within an IP-VRF [RFC9135], are considered ISF
routes in this document.
* IP-VRF: an IP Virtual Routing and Forwarding table, as defined in
[RFC4364]. Route Distinguisher and Route Target(s) are required
properties of an IP-VRF. An IP-VRF is programmed with ISF routes.
Rabadan, et al. Expires 25 May 2026 [Page 5]
Internet-Draft EVPN and IPVPN Interworking November 2025
* MAC-VRF: a MAC Virtual Routing and Forwarding table, as defined in
[RFC7432]. A MAC-VRF represents the instantiation of an EVPN
Instance (EVI) on a PE device. Each MAC-VRF is associated with a
unique Route Distinguisher (RD) and one or more Route Targets
(RTs), which are required attributes for its operation. These RD
and RT values are typically distinct from those used by any
associated IP-VRF, when such an IP-VRF is linked to the MAC-VRF
through a Bridge Table via an Integrated Routing and Bridging
(IRB) interface.
* BT: a Bridge Table, as defined in [RFC7432], represents the
instantiation of a Broadcast Domain on a PE device. When an EVI
contains a single Broadcast Domain, the associated MAC-VRF on each
PE includes a single BT. In cases where multiple Broadcast
Domains exist within the same MAC-VRF, each BT is associated with
a distinct Ethernet Tag. EVPN routes specific to a given BT
include the corresponding Ethernet Tag to indicate the Broadcast
Domain to which the route pertains.
Example: In Figure 1, MAC-VRF1 has two BTs: BT1 and BT2. Ethernet
Tag x is defined in BT1 and Ethernet Tag y in BT2.
* CE: Customer Edge device.
* Ethernet Tag: used to represent a Broadcast Domain.
* EVI: an EVPN instance spanning the Provider Edge devices
participating in that EVPN.
* AC: Attachment Circuit or logical interface associated to a given
BT or IP-VRF. To determine the AC on which a packet arrived, the
PE will examine the combination of a physical port and VLAN tags
(where the VLAN tags can be individual VLAN tags, Q-in-Q tags or
ranges of both).
Example: In Figure 1, AC1 is associated to BT1, AC2 to BT2 and AC3
to IP-VRF1.
* IRB: Integrated Routing and Bridging interface. It refers to the
logical interface that connects a BT to an IP-VRF and allows to
forward packets with destination in a different subnet.
* MPLS/NVO tunnel: A tunnel that may be based on either MPLS or a
Network Virtualization Overlay (NVO) technology. Such tunnels are
utilized by both MAC-VRFs and IP-VRFs. Regardless of the
underlying tunneling technology, the tunnel may carry either
Ethernet or IP payloads. MAC-VRFs are restricted to using tunnels
that carry Ethernet payloads - Ethernet NVO Tunnels [RFC9136] -
Rabadan, et al. Expires 25 May 2026 [Page 6]
Internet-Draft EVPN and IPVPN Interworking November 2025
which are typically established via EVPN signaling. In contrast,
IP-VRFs may utilize tunnels carrying Ethernet payloads - Ethernet
NVO Tunnels [RFC9136], signaled via EVPN - or IP payloads - IP NVO
Tunnels [RFC9136], signaled via EVPN or IPVPN mechanisms. IPVPN-
only PE devices support IP-VRFs but do not support sending or
receiving traffic over tunnels carrying Ethernet payloads.
Example: Figure 1 illustrates the use of an MPLS or NVO-based
tunnel to transport Ethernet frames associated with MAC-VRF1. The
PE device identifies the corresponding MAC-VRF and BT based on the
EVPN label, either an MPLS label or a Virtual Network Identifier
(VNI), depending on the encapsulation type. Additionally,
Figure 1 shows two distinct MPLS/NVO tunnels used by IP-VRF1: one
tunnel transports Ethernet frames, while the other carries IP
packets. This demonstrates that IP-VRFs may concurrently utilize
multiple tunnel types, depending on the payload and the signaling
mechanism (EVPN or IPVPN).
* PE: Provider Edge device.
* RT-2: Route Type 2 or MAC/IP route, as per [RFC7432].
* RT-5: Route Type 5 or IP Prefix route, as per [RFC9136].
* NVE: Network Virtualization Edge router.
* Domain: Two PEs belong to the same domain if they are attached to
the same tenant and the packets exchanged between them do not
require a data-path IP lookup (in the tenant space) at any transit
router. A gateway PE is always configured with multiple DOMAIN-
IDs. Domain boundaries are not restricted to an Autonomous System
or an IGP instance. The PEs in a domain may reside within the
same or in different Autonomous Systems, and a single Autonomous
System may also encompass multiple domains.
Example 1: Figure 2 depicts an example where Tenant Systems TS1
and TS2 belong to the same tenant, and they are located in
different Data Centers that are connected by gateway PEs (see the
gateway PE definition later). These gateway PEs use IPVPN in the
WAN. When TS1 sends traffic to TS2, the intermediate routers
between PE1 and PE2 require a tenant IP lookup in their IP-VRFs so
that the packets can be forwarded. In this example there are
three different domains. The gateway PEs connect the EVPN domains
to the IPVPN domain.
Rabadan, et al. Expires 25 May 2026 [Page 7]
Internet-Draft EVPN and IPVPN Interworking November 2025
GW1------------GW3
+------+ +------+
+-------------|IP-VRF| |IP-VRF|-------------+
PE1 +------+ +------+ PE2
+------+ DC1 | WAN | DC2 +------+
TS1-|IP-VRF| EVPN | IPVPN | EVPN |IP-VRF|-TS2
+------+ GW2 GW4 +---+--+
| +------+ +------+ |
+-------------|IP-VRF| |IP-VRF|-------------+
+------+ +------+
+--------------+
DOMAIN 1 DOMAIN 2 DOMAIN 3
<---------------> <------------> <---------------->
Figure 2: Multiple domain DCI example
Example 2: Figure 3 illustrates a similar example, but PE1 and PE2
are now connected by a BGP-LU (BGP Labeled Unicast) tunnel, and
they have a BGP peer relationship for EVPN. Contrary to Example
1, there is no need for tenant IP lookups on the intermediate
routers in order to forward packets between PE1 and PE2.
Therefore, there is only one domain in the network and PE1/PE2
belong to it.
EVPN
<------------------------------------------------->
BGP-LU
<------------------------------------------------->
ASBR------------ASBR
+------+ +------+
+-------------| | | |-------------+
PE1 +------+ +--+---+ PE2
+------+ DC1 | WAN | DC2 +------+
TS1-|IP-VRF| EVPN | | EVPN |IP-VRF|-TS2
+------+ ASBR ASBR +---+--+
| +------+ +------+ |
+-------------| | | |-------------+
+------+ +------+
+--------------+
<--------------------DOMAIN-1--------------------->
Figure 3: Single domain DCI example
Rabadan, et al. Expires 25 May 2026 [Page 8]
Internet-Draft EVPN and IPVPN Interworking November 2025
* Regular Domain: a domain in which a single control plane ISF SAFI,
i.e., BGP IP, IPVPN or EVPN, is used. A Regular Domain is
composed of regular PEs, see below. In Figure 2 and Figure 3,
above, all domains are regular domains.
* Composite Domain: a domain in which multiple control plane ISF
SAFIs, i.e., BGP IP, IPVPN and/or EVPN, are used and which is
composed of regular PEs and composite PEs, see below.
* Regular PE: A PE that is attached to a domain, either regular or
composite, and which uses one of the control plane protocols (BGP
IP, IPVPN or EVPN) operating in the domain.
* Interworking PE: A PE device that is capable of advertising a
given IP prefix using one or more of the following route types: an
EVPN Inter-Subnet Forwarding (ISF) route, either an EVPN MAC/IP
Advertisement route or an EVPN IP Prefix route-an IPVPN ISF route,
or a BGP IP ISF route. An Interworking PE maintains a single IP-
VRF per tenant and zero, one, or more MAC-VRFs per tenant. Each
MAC-VRF may include one or more Bridge Tables (BTs), and each BT
may be associated with the tenant's IP-VRF via an Integrated
Routing and Bridging (IRB) interface. There are two types of
Interworking PEs:
- Composite PE
- Gateway PE
These two functions may be implemented independently on a per-
tenant basis and may also coexist for the same tenant on a single
PE.
Example: Figure 1 shows an interworking PE of type gateway, where
ISF SAFIs 1, 128 and 70 are enabled. IP-VRF1 and MAC-VRF1 are
instantiated on the PE, and together provide inter-subnet
forwarding for the tenant.
* Composite PE: An Interworking PE device that is connected to a
composite domain and is capable of advertising a given prefix to
multiple types of peers using appropriate route types.
Specifically, a Composite PE advertises the prefix to an IPVPN
peer using an IPVPN ISF route, to an EVPN peer using an EVPN ISF
route, and to a route reflector using both IPVPN and EVPN ISF
routes. A Composite PE implements the procedures defined in
Section 7.
Rabadan, et al. Expires 25 May 2026 [Page 9]
Internet-Draft EVPN and IPVPN Interworking November 2025
Example: Figure 4 shows an example where PE1 is a composite PE
since PE1 has EVPN and another ISF SAFI enabled to the same route-
reflector, and PE1 advertises a given IP prefix IPn/x twice, one
using EVPN and another one using ISF SAFI 128. PE2 and PE3 are
not composite PEs.
+---+
|PE2|
+---+
^
Interworking |EVPN
PE EVPN v
+---+ IPVPN +--+ +---+
|PE1| <----> |RR| <---> |PE3|
+---+ +--+ IPVPN +---+
Composite
Figure 4: Interworking composite PE example
* Gateway PE: An Interworking PE device that connects two or more
distinct domains, where each domain may be either a regular domain
or a composite domain. A Gateway PE may establish either IBGP or
EBGP sessions with peers in the connected domains. Depending on
its configuration, the Gateway PE performs one of the following
functions:
- Propagates ISF routes using the same ISF SAFI, such as BGP IP,
IPVPN, or EVPN, between the connected domains.
- Translates and propagates an ISF route received with one ISF
SAFI to a domain that uses a different ISF SAFI. For example,
a received EVPN ISF route may be propagated as an IPVPN ISF
route, and vice versa.
A Gateway PE follows the procedures defined in Section 8. A
gateway PE is always configured with multiple DOMAIN-IDs. These
DOMAIN-IDs are encoded in the D-PATH and are included in ISF SAFI
route advertisements. The structure and behavior of the D-PATH
attribute are described in Section 4.
Example: Figure 5 illustrates an example where PE1 is a gateway PE
since the EVPN and IPVPN SAFIs are enabled on different BGP peers,
and a given local IP prefix IPn/x is sent to both BGP peers for
the same tenant. PE2 and PE1 are in one domain and PE3 and PE1
are in another domain.
Rabadan, et al. Expires 25 May 2026 [Page 10]
Internet-Draft EVPN and IPVPN Interworking November 2025
Interworking PE
+---+ EVPN +---+ IPVPN +---+
|PE2| <----> |PE1| <----> |PE3|
+---+ +---+ +---+
Gateway
Figure 5: Interworking gateway PE example
* Composite/Gateway PE: An Interworking PE device that
simultaneously performs the functions of both a Composite PE and a
Gateway PE. This type of PE is connected to two domains: one
regular domain and one composite domain. It operates as follows:
- Propagates an ISF route received from the regular domain into
the composite domain. Within the composite domain, it performs
the behavior of a Composite PE.
- Propagates an ISF route received from the composite domain into
the regular domain. In the regular domain, the route is
advertised using the ISF SAFI applicable to that domain.
This functionality is particularly useful in scenarios where a
tenant network spans multiple domains using different ISF SAFIs
(e.g., BGP IP, IPVPN, and EVPN), and where any-to-any tenant
connectivity is required. In such deployments, maintaining
consistent end-to-end control plane behavior across domains is
desirable when feasible.
4. Domain Path Attribute (D-PATH)
The BGP D-PATH attribute is an optional and transitive BGP path
attribute.
Similar to AS_PATH, D-PATH is composed of a sequence of Domain
segments. Each Domain segment is comprised of <domain segment
length, domain segment value>, where the domain segment value is a
sequence of one or more Domains, as illustrated in Figure 6. Each
domain is represented by <DOMAIN-ID:ISF_SAFI_TYPE>.
Rabadan, et al. Expires 25 May 2026 [Page 11]
Internet-Draft EVPN and IPVPN Interworking November 2025
Octets
0 1 8 n
+---------------+----------------//--+----//-------------------+
|Domain Segment | Last Domain | Domain of Origin |
| Length | | |
+---------------+----------------//--+----//-------------------+
\__________________/
|
Octets v
0 6 7
+------------------//-----+----------------+
| DOMAIN-ID | ISF_SAFI_TYPE |
+------------------//-----+----------------+
\________________________/
|
Octets v
0 1 2 3 4 5 6
+-----------------------+-----------+
| Global | Local |
| Admin | Admin |
+-----------------------+-----------+
Figure 6: D-PATH Domain Segment
* Domain Segment Length (length: 1-octet): containing the number of
domains in the segment.
* “Last Domain” refers to the most recently added Domain, while
“Domain of Origin” refers to the first Domain added by the gateway
PE that initialized the D-PATH for the ISF route. Multiple
Domains may exist between those Domains.
* DOMAIN-ID is a 6-octet field that represents a domain. It is
composed of a 4-octet Global Administrator sub-field and a 2-octet
Local Administrator sub-field. The Global Administrator sub-field
MAY be filled with an Autonomous System Number (ASN, Public or
Private), an IPv4 address, or any value that guarantees the
uniqueness of the DOMAIN-ID (when the tenant network is connected
to multiple Operators) and helps troubleshooting and debugging of
D-PATH in ISF routes. The Local Administrator sub-field is any
local 2-octet value, and its allocation or configuration is a
local implementation matter. Expressing the Global Administrator
and Local Administrator values as opaque unsigned integers is
RECOMMENDED.
* ISF_SAFI_TYPE is a 1-octet field that indicates the Inter-Subnet
Forwarding SAFI type in which a route was received by the gateway
PE, before the route is re-exported by the gateway PE into a
Rabadan, et al. Expires 25 May 2026 [Page 12]
Internet-Draft EVPN and IPVPN Interworking November 2025
different domain. The ISF_SAFI_TYPE field is informational and
does not have any impact on the loop detection or BGP Path
selection procedures. The following types are assigned by this
document:
+=======+============================+
| Value | ISF_SAFI_TYPE |
+=======+============================+
| 0 | Gateway PE local ISF route |
+-------+----------------------------+
| 70 | EVPN |
+-------+----------------------------+
| 128 | SAFI 128 |
+-------+----------------------------+
Table 1
The BGP D-PATH attribute is supported on ISF routes of type IPVPN and
EVPN and MUST NOT be advertised along with routes different from
IPVPN and EVPN routes. By default, the BGP D-PATH attribute is not
advertised and MUST be explicitly enabled by configuration on the
Gateway PEs. In addition, D-PATH:
a. Identifies the sequence of domains, each identified by a <DOMAIN-
ID:ISF_SAFI_TYPE> through which a given ISF route of type IPVPN
or EVPN has passed.
* This attribute list MAY contain one or more segments. Each
segment's Domain Segment Length MUST be equal or greater than
one.
* The first entry in the list (leftmost) is the <DOMAIN-
ID:ISF_SAFI_TYPE> from which a gateway PE is propagating an
ISF IPVPN or EVPN route. The last entry in the list
(rightmost) is the <DOMAIN-ID:ISF_SAFI_TYPE> from which a
gateway PE received an ISF IPVPN or EVPN route without a
D-PATH attribute (the Domain of Origin). Intermediate entries
in the list are domains that the ISF IPVPN or EVPN route has
transited.
* As an example, an ISF IPVPN or EVPN route received with a
D-PATH attribute containing a domain segment of {length=2,
<6500:2:IPVPN>,<6500:1:EVPN>} indicates that the route was
originated in EVPN domain 6500:1, and propagated into IPVPN
domain 6500:2.
Rabadan, et al. Expires 25 May 2026 [Page 13]
Internet-Draft EVPN and IPVPN Interworking November 2025
* In order to minimize the number of segments in the D-PATH
attribute, the local gateway PE prepends its own domain as the
last element of the domain segment. If the act of prepending
a new domain causes an overflow in the domain segment (i.e.,
more than 255 domains), the local gateway PE MUST prepend a
new segment and prepend its own domain to this new segment.
b. Is added/modified by a gateway PE when propagating an update to a
different domain (which runs the same or different ISF SAFI):
* A gateway PE's IP-VRF, that connects two domains, belongs to
two DOMAIN-IDs, e.g. 6500:1 for EVPN and 6500:2 for IPVPN.
* Whenever a prefix arrives at a gateway PE in a particular ISF
SAFI route, if the gateway PE needs to export that prefix to a
BGP peer, the gateway PE MUST prepend a <DOMAIN-
ID:ISF_SAFI_TYPE> to the list of domains in the D-PATH of the
received route, as long as the gateway PE works in Uniform-
Propagation-Mode, as explained in Section 5.2.
* For instance, consider an IP-VRF configured with DOMAIN-IDs
6500:1 for EVPN and 6500:2 for IPVPN. If an EVPN route for
prefix P is received and P is installed in the IP-VRF, then
the corresponding IPVPN route for P, when exported to an IPVPN
peer, will include the domain identifier <6500:1:EVPN>
prepended to the existing D-PATH attribute. Similarly,
prefixes received in the IP-VRF from an IPVPN peer will be
exported to EVPN peers with the domain identifier
<6500:2:IPVPN> appended to the D-PATH attribute.
* In the above example, if the EVPN route is received without
D-PATH, the gateway PE will add the D-PATH attribute with one
segment {length=1, <6500:1:EVPN>} when re-advertising to
domain 6500:2.
* Within the Domain of Origin, the update does not contain a
D-PATH attribute because the update has not passed through a
gateway PE yet.
c. For a local ISF route, i.e., a configured route or a route
learned from a local attachment circuit, a gateway PE following
this specification has three choices:
1. The gateway PE MAY advertise that ISF route without a D-PATH
attribute into one or more of its configured domains, in
which case the D-PATH attribute will be added by the other
gateway PEs in each of those domains.
Rabadan, et al. Expires 25 May 2026 [Page 14]
Internet-Draft EVPN and IPVPN Interworking November 2025
2. The gateway PE MAY advertise that ISF route with a D-PATH
attribute into one or more of its configured domains, in
which case the D-PATH attribute in each copy of the ISF route
is initialized with an ISF_SAFI_TYPE of 0 and the DOMAIN-ID
of the domain with which the ISF route is associated.
3. The gateway PE MAY advertise the ISF route with a D-PATH
attribute containing a locally configured domain identifier
associated with its local ISF routes into one or more of its
configured domains. In this case, the D-PATH attribute in
each copy of the ISF route is initialized with an
ISF_SAFI_TYPE value of 0 and the DOMAIN-ID representing the
local ISF domain. The DOMAIN-ID MUST be globally unique and
MAY be shared across multiple gateway PEs.
Although all three options provide mechanisms for detecting
control plane loops, this third option is RECOMMENDED, as it
conveys additional information about the origin of the route.
Specifically, it allows the receiving PE to identify the
route as having originated from a local gateway, based on the
combination of the DOMAIN-ID and the ISF_SAFI_TYPE value.
d. An ISF route of type IPVPN or EVPN received by a Gateway PE that
includes a D-PATH attribute containing one or more DOMAIN-ID
values locally associated with the corresponding IP-VRF MUST be
considered a looped ISF route for the purposes of re-
advertisement into adjacent domains. In such cases:
* The ISF route MUST be flagged as "looped".
* The route MUST NOT be re-exported to any other domain.
* The route MAY be installed in the IP-VRF only if it is
selected as the best path according to the procedures defined
in Section 6.
For the purpose of loop detection, the ISF_SAFI_TYPE value
associated with a DOMAIN-ID in the D-PATH attribute is
irrelevant. That is, a route is considered looped if it contains
at least one DOMAIN-ID that matches any local DOMAIN-ID
configured on the Gateway PE, regardless of the ISF_SAFI_TYPE
value.
Example: In the scenario illustrated in Figure 2, gateway GW1
receives two ISF routes for the same prefix associated with TS1:
* An EVPN IP Prefix route with a next-hop of PE1, and no D-PATH
attribute.
Rabadan, et al. Expires 25 May 2026 [Page 15]
Internet-Draft EVPN and IPVPN Interworking November 2025
* A SAFI 128 (IPVPN) route with a next-hop of GW2, and a D-PATH
attribute containing a single segment: {length=1,
<6500:1:EVPN>}, where 6500:1 is assumed to be the DOMAIN-ID
for domain 1, which is local to GW1.
Upon receiving the SAFI 128 route, GW1 identifies 6500:1 as a
locally configured DOMAIN-ID, and therefore flags the route as
"looped". As a result, GW1 does not install this route in the
tenant IP-VRF, because the route selection process prefers the
EVPN IP Prefix route (due to its shorter D-PATH attribute, as
specified in Section 6). Loop detection is applied even if the
ISF_SAFI_TYPE value in the D-PATH attribute is unknown to GW1 or
does not match any SAFI defined in this specification.
e. A DOMAIN-ID configured on a gateway PE MAY be assigned at either
the peering domain level or scoped individually per tenant IP-
VRF.
* When the DOMAIN-ID is allocated at the peering domain level,
it SHALL apply to all tenant IP-VRFs associated with that
domain.
* When the DOMAIN-ID is allocated for a specific tenant IP-VRF,
the processing of received D-PATH attributes and their
subsequent propagation SHALL be performed in the context of
that IP-VRF's DOMAIN-ID.
A per tenant IP-VRF DOMAIN-ID assignment is particularly useful
in scenarios involving route leaking. For example, consider two
gateway PEs, PE1 and PE2, both associated with different tenant
IP-VRFs, denoted as IP-VRF-1 and IP-VRF-2. If PE1 advertises ISF
SAFI routes for IP-VRF-1 with a DOMAIN-ID of 6500:1, and these
routes are received on PE2 and subsequently leaked from IP-VRF-1
into IP-VRF-2, the re-advertisement of the routes from PE2 back
to PE1 in the context of IP-VRF-2 will not be considered looped
by PE1. This is because PE1 processes the route in the context
of IP-VRF-2, for which DOMAIN-ID 6500:1 is not locally
configured.
f. The number of domains encoded in the D-PATH attribute reflects
the number of Gateway PEs that the corresponding ISF route update
has traversed. If a transit Gateway PE performs route leaking
between two local tenant IP-VRFs, it MAY prepend a domain segment
to the D-PATH attribute with an ISF_SAFI_TYPE value of 0 when
exporting the leaked route into an ISF SAFI. In such cases, the
total number of domain entries in the D-PATH attribute represents
the number of tenant IP-VRFs through which the ISF route update
has propagated.
Rabadan, et al. Expires 25 May 2026 [Page 16]
Internet-Draft EVPN and IPVPN Interworking November 2025
g. The following error-handling procedures apply to the D-PATH Path
Attribute:
1. A received D-PATH attribute MUST be considered malformed if
it contains a malformed Domain Segment.
2. A Domain Segment MUST be considered malformed under any of
the following conditions:
* The length of the Domain Segment is zero.
* The length of the Domain Segment exceeds the remaining
length of the enclosing D-PATH attribute.
* Fewer than eight octets remain after the last successfully
parsed Domain Segment.
* The total length of the D-PATH attribute is less than
eight octets.
* Each Domain Segment consists of a one-octet length field
indicating the number of Domains in the segment, with each
Domain encoded in seven octets. If the total length of
the Domain Segment (i.e., 1 + 7 × number of Domains)
exceeds the remaining length of the D-PATH attribute, the
Domain Segment is considered malformed.
3. A BGP speaker receiving an UPDATE message containing a
malformed D-PATH attribute SHALL apply the "treat-as-
withdraw" procedure, as specified in [RFC7606].
4. Domains within the D-PATH attribute that contain unrecognized
ISF_SAFI_TYPE values MAY be accepted and MUST NOT be
considered an error.
5. The D-PATH Path Attribute MUST NOT appear more than once in
the Path Attributes of a given BGP UPDATE message. If
multiple instances of the D-PATH attribute are present, all
instances other than the first MUST be discarded, and the
UPDATE message MUST continue to be processed, as per
[RFC7606].
Rabadan, et al. Expires 25 May 2026 [Page 17]
Internet-Draft EVPN and IPVPN Interworking November 2025
6. The D-PATH Path Attribute MAY be included only in UPDATE
messages that carry routes of SAFI 128 (IPVPN) or EVPN. It
MUST NOT be included with any other AFI/SAFI combinations.
If a D-PATH attribute is received in an UPDATE message
associated with an unsupported AFI/SAFI, the "treat-as-
withdraw" procedure MUST be applied, in accordance with
[RFC7606].
h. The use of the D-PATH attribute is restricted to "walled garden"
Virtual Private Network (VPN) deployments. An operator MUST NOT
enable the generation of D-PATH attributes in conjunction with
IPVPN and/or EVPN routes if any CE devices connected to a PE
device, belonging to any domain within the VPN, is also connected
to the public Internet.
Furthermore, a gateway PE MUST support the ability to remove the
D-PATH attribute upon route import and export, as determined by
local configuration.
5. BGP Path Attribute Propagation across Domains
A Gateway PE device, depending on its local configuration, is
required to propagate an ISF route between two domains that utilize
either the same or different ISF SAFIs. This requires defining how a
Gateway PE handles the BGP Path Attributes associated with the ISF
route during such propagation.
This section specifies the BGP Path Attribute propagation behaviors
that a Gateway PE MAY apply when it receives an ISF route with ISF
SAFI x, installs the route into the relevant IP-VRF, and subsequently
re-advertises the route as an ISF route using ISF SAFI y. The values
of ISF SAFI x and SAFI y MAY be the same or different.
5.1. No-Propagation Mode
The No-Propagation Mode is the default operational mode for Gateway
PEs when re-exporting ISF routes from one domain into another. In
this mode, the Gateway PE re-initializes the BGP Path Attributes
during the propagation of an ISF route, treating it in the same
manner as a directly connected or locally originated IP prefix.
This mode is suitable for deployment scenarios where the source
domain-for example, an EVPN domain is "abstracted" and treated as a
virtual CE, and where remote IPVPN or IP-based PEs do not require the
original EVPN-specific BGP Path Attributes for path selection or
policy evaluation.
Rabadan, et al. Expires 25 May 2026 [Page 18]
Internet-Draft EVPN and IPVPN Interworking November 2025
It is important to note that, in No-Propagation Mode, the D-PATH
attribute is not propagated. As a result, redundant Gateway PEs may
be susceptible to routing loops. While such loops may be mitigated
using routing policies or additional attributes, such as the Route
Origin extended community [RFC4360], this approach does not guarantee
detection or prevention of all potential loop scenarios.
5.2. Uniform Propagation Mode
In Uniform Propagation Mode, the Gateway PE retains and propagates a
consistent set of commonly used BGP Path Attributes when re-
advertising an ISF route between domains. This mode is typically
employed in deployments where IP prefixes are seamlessly distributed
using both EVPN and IPVPN SAFIs.
The following normative behavior MUST be followed by a Gateway PE
operating in Uniform Propagation Mode:
1. Upon receiving an ISF route, the gateway PE imports the route
into the associated IP-VRF and stores the original BGP Path
Attributes. When advertising the route into a different domain,
the gateway PE SHOULD propagate only the following set of
attributes. All other Path Attributes SHOULD NOT be propagated:
* AS_PATH
* D-PATH (only when advertising IPVPN [SAFI 128] or EVPN routes)
* IBGP-only attributes (when advertising to IBGP peers):
LOCAL_PREF, ORIGINATOR_ID, CLUSTER_ID
* MULTI_EXIT_DISC (MED)
* AIGP
* COMMUNITY, EXTENDED_COMMUNITY, LARGE_COMMUNITY, and
WIDE_COMMUNITY (as defined in
[I-D.ietf-idr-wide-bgp-communities]), except where explicitly
excluded in Item 4 below.
2. When re-advertising an ISF route to an IBGP peer, the gateway PE
SHOULD preserve the AS_PATH of the original ISF route without
modification. When re-advertising to an EBGP peer, the Gateway
PE SHOULD prepend the IP-VRF's ASN to the preserved AS_PATH.
Rabadan, et al. Expires 25 May 2026 [Page 19]
Internet-Draft EVPN and IPVPN Interworking November 2025
3. When propagating an ISF route to IBGP peers, the gateway PE
SHOULD retain IBGP-only attributes (e.g., LOCAL_PREF,
ORIGINATOR_ID, CLUSTER_ID) from the original ISF route. As the
route is re-originated, the gateway PE is not required to perform
the route reflector function described in [RFC4456].
4. As stated in Item 1, the gateway PE SHOULD preserve the
COMMUNITY, EXTENDED_COMMUNITY, LARGE_COMMUNITY, and
WIDE_COMMUNITY attributes from the original ISF route. However,
the following Extended Community types SHOULD NOT be propagated::
a. BGP Encapsulation Extended Communities, as defined in
[RFC9012].
b. Route Target Extended Communities. Route Targets MUST NOT be
propagated and MUST be re-initialized when re-advertising the
ISF route into a different domain. The re-initialized Route
Target value MAY or MAY NOT match the value used in the
original route.
c. All EVPN-specific Extended Communities.
The Gateway PE SHOULD NOT copy the above Extended Community types
from the original ISF route into the re-advertised ISF route.
5. For a given ISF route, only the BGP Path Attributes associated
with the best path MAY be propagated when re-advertising the
route into a different domain. If multiple paths are received
for the same prefix within the same ISF SAFI, the standard BGP
best path selection procedure MUST be applied to determine the
active path and its associated attributes. Even when Equal-Cost
Multi-Path (ECMP) is enabled for the IP-VRF, only the Path
Attributes of the selected best path SHALL be propagated.
5.3. Aggregation of Routes and Path Attribute Propagation
Instead of propagating a high number of (host) ISF routes between
domains, a gateway PE that receives multiple ISF routes from a domain
MAY choose to propagate a single ISF aggregate route into a different
domain. In this document, aggregation is used to combine the
characteristics of multiple ISF routes in such way that a single
aggregate ISF route can be propagated to the destination domain.
Aggregation of multiple ISF routes of one ISF SAFI into an aggregate
ISF route is only done by a gateway PE.
Aggregation on gateway PEs may use either the No-Propagation-Mode or
the Uniform-Propagation-Mode explained in Section 5.1 and
Section 5.2, respectively.
Rabadan, et al. Expires 25 May 2026 [Page 20]
Internet-Draft EVPN and IPVPN Interworking November 2025
When using Uniform-Propagation-Mode, Path Attributes of the same type
code MAY be aggregated according to the following rules:
* AS_PATH is aggregated based on the rules in [RFC4271]. The
gateway PEs are not expected to receive AS_PATH attributes with
path segments of type AS_SET [RFC9774]. Routes received with
AS_PATH attributes including AS_SET path segments MUST NOT be
aggregated.
* An ISF aggregate route SHOULD NOT be advertised unless all the
contributing ISF routes have the same D-PATH DOMAIN-ID members,
regardless of their order. If there is at least one contributing
ISF route that has a different D-PATH DOMAIN-ID, the gateway PE
SHOULD advertise each contributing ISF route with its own D-PATH
(prepended with the gateway's domain). An implementation MAY
override this behavior, via policy, to advertise an ISF aggregate
route without D-PATH in case the contributing routes did not have
the same D-PATH DOMAIN-ID members.
* The Community, Extended Community, Large Community and Wide
Community attributes of an aggregated ISF route SHOULD include the
union of the corresponding attributes from all constituent ISF
routes that were aggregated, with the exception of those Extended
Community types explicitly excluded from propagation as specified
in Section 5.2.
* For other attributes, rules in [RFC4271] are followed.
If the conditions for route aggregation, as specified above, are
satisfied, operators SHOULD consider enabling aggregation in
environments with large-scale tenant networks where a significant
number of host routes are present. This practice is particularly
applicable to deployments such as large-scale data centers.
6. Route Selection Process for ISF Routes
A PE router may receive the same IP prefix via ISF routes with
different ISF SAFIs, and from either the same or different BGP peers.
Additionally, the same IP prefix (e.g., a host route) may be received
in both an EVPN MAC/IP Advertisement route and an EVPN IP Prefix
route. To ensure consistent and deterministic forwarding behavior, a
route selection procedure across all ISF SAFIs is required.
The objectives of this route selection process are as follows:
* To ensure that all composite and gateway PEs have a consistent and
deterministic view of the preferred path to reach a given IP
prefix.
Rabadan, et al. Expires 25 May 2026 [Page 21]
Internet-Draft EVPN and IPVPN Interworking November 2025
* To enable meaningful comparison of routes advertised in EVPN and
non-EVPN ISF SAFIs based on commonly used path attributes.
* To support Equal-Cost Multi-Path (ECMP) forwarding across EVPN and
non-EVPN ISF SAFI routes, where applicable.
For a given prefix received via one or more non-EVPN ISF routes, the
standard BGP best path selection procedure, as defined in [RFC4271],
is applied to determine the "non-EVPN best paths." Similarly, for a
given prefix received via one or more EVPN ISF routes, the same
procedure is applied to determine the "EVPN best paths."
When both EVPN and non-EVPN ISF routes are present for the same
prefix within a single IP-VRF, the PE MUST perform a tie-breaking
selection procedure on the union of these best-path sets. The
process treats all candidate ISF routes as equally preferable
initially, then iteratively removes routes until a single best path
(or a valid ECMP set) remains.
6.1. Tie-Breaking and Selection Rules
The selection procedure MUST follow the standard route selection
rules defined in [RFC4271], with the following additional rules and
exceptions applied in the specified order:
1. Immediately after applying the Local Preference comparison step
from [RFC4271], the PE MUST remove from consideration any routes
that do not have the shortest D-PATH attribute. Routes with no
D-PATH attribute are considered to have a D-PATH length of zero.
This rule MUST NOT be applied to ISF routes that are not imported
into an IP-VRF.
2. After applying Rule 1, the standard [RFC4271] selection steps
MUST continue in order.
3. If, after the previous steps, one or more candidate routes remain
and at least one of them is an EVPN MAC/IP Advertisement route
(EVPN Route Type 2), then all EVPN IP Prefix routes (EVPN Route
Type 5) MUST be removed from consideration.
4. If ECMP is enabled by policy and the remaining candidate routes
after Steps 1 through 3 include both EVPN and non-EVPN paths,
then both paths MUST be retained. If ECMP is not enabled, and
such a case arises, the EVPN path MUST be selected and the non-
EVPN path MUST be removed from consideration.
Rabadan, et al. Expires 25 May 2026 [Page 22]
Internet-Draft EVPN and IPVPN Interworking November 2025
This procedure extends the standard BGP best path selection behavior
as specified in [RFC4271] for SAFI 128 and EVPN IP Prefix routes by
incorporating D-PATH based tie-breaking to prefer routes that
traverse the fewest Gateway PEs or domains. These rules MUST NOT be
applied to routes received under AFI/SAFI combinations other than
SAFI 128 or EVPN; such routes get a treat-as-withdraw procedures as
described in Section 4.
6.2. Examples
Example 1:
PE1 receives three candidate routes for prefix IP1/32, all eligible
for import into IP-VRF-1:
{SAFI=EVPN, RT-2, Local-Pref=100, AS-Path=(100,200)}
{SAFI=EVPN, RT-5, Local-Pref=100, AS-Path=(100,200)}
{SAFI=128, Local-Pref=100, AS-Path=(100,200)}
Selected route:
{SAFI=EVPN, RT-2, Local-Pref=100, AS_PATH=(100,200)}
This outcome is due to Step 3, which gives preference to Route Type 2
when both Type 2 and Type 5 EVPN routes exist.
Example 2:
PE1 receives two candidate routes for prefix IP2/24, both eligible
for import into IP-VRF-1:
{SAFI=EVPN, RT-5, D-PATH=(6500:3:IPVPN), AS-Path=(100,200), MED=10}
{SAFI=128, D-PATH=(6500:1:EVPN,6500:2:IPVPN), AS-Path=(200), MED=200}
Selected route: {SAFI=EVPN, RT-5, D-PATH=(6500:3:IPVPN),
AS_PATH=(100,200), MED=10}
This result is due to Step 1, which prefers the route with the
shortest D-PATH.
7. Composite PE Procedures
As described in Section 3, composite PEs are typically used in tenant
networks where EVPN and IPVPN are both used to provide inter-subnet
forwarding within the same composite domain.
Rabadan, et al. Expires 25 May 2026 [Page 23]
Internet-Draft EVPN and IPVPN Interworking November 2025
Figure 7 depicts an example of a composite domain, where PE1/PE2/PE4
are composite PEs (they support EVPN and IPVPN ISF SAFIs on their
peering to the Route Reflector), and PE3 is a regular IPVPN PE.
+-----------------------------------+
| |
| MPLS IPVPN PE3
| Network +----------+ IP3/24
| IPVPN |+------+ | +---+
| +----->||IP-VRF|------|CE3|
Composite PE1 | |+------+ | +---+
+---------------+ | +----------+
| +------+ | EVPN v |
| |IP-VRF| | IPVPN +--+ |
| +----| | | <------> |RR| |
+---+ | | +------+ | +--+ Composite PE4
|CE2|----|MAC-VRF| | ^ ^ +---------+ IP4/24
+---+ | +-------+ | EVPN | | EVPN |+------+ | +---+
+---|-----------+ IPVPN | | IPVPN ||IP-VRF|-----|CE4|
| | +----+ +-------->|+------+ | +---+
IP1/24 | | v +---------+
+---+ | | +---------------+ |
|CE1|--+ +----| +------+ +--------------+
+---+ | |IP-VRF| |
| | +----| | |
| | | +------+ |
+--------------|MAC-VRF| |
| +-------+ |
+---------------+
Composite PE2
Figure 7: Composite PE example
In a composite domain comprising both composite and regular PE
devices, the following behaviors apply:
1. Prefix Advertisement Consistency
Composite PEs MUST advertise the same IP prefixes using each ISF
SAFI to the Route Reflector (RR). For example, as shown in
Figure 7, the prefix IP1/24 is advertised by PE1 and PE2 to the
Route Reflector in two separate NLRI entries: one for AFI/SAFI
1/128 (IPVPN) and another for EVPN. If both routes are
advertised with the same set of BGP Path Attributes, the
receiving composite PE will select the EVPN route over the IPVPN
route, following the route selection procedures defined in
Section 6. While not required, prioritizing the advertisement of
the EVPN route before the IPVPN route is an OPTIONAL
Rabadan, et al. Expires 25 May 2026 [Page 24]
Internet-Draft EVPN and IPVPN Interworking November 2025
optimization. This ensures that the EVPN route is more likely to
be selected first, avoiding unnecessary replacement if the IPVPN
route arrives later.
2. Route Reflector SAFI-Specific Forwarding Behavior
The Route Reflector does not forward EVPN routes to peers for
which the EVPN SAFI is not enabled, and likewise does not forward
IPVPN routes to peers lacking IPVPN SAFI support. For instance,
in Figure 7, the Route Reflector does not forward EVPN routes to
PE3 if the EVPN SAFI is not enabled on its BGP session with PE3.
However, the IPVPN routes are forwarded to all PEs since they all
have IPVPN SAFI enabled.
3. IPVPN PE Route Processing
Regular IPVPN PEs process and import IPVPN routes as specified in
[RFC4364]. For example, PE3 receives only the IPVPN route for
prefix IP1/24 and resolves the BGP next-hop to an MPLS tunnel
(with IP payload) toward PE1 and/or PE2.
4. Composite PE Route Selection
Composite PEs MUST perform route selection for prefixes received
via multiple ISF SAFIs, applying the procedures described in
Section 6:
* For example, PE4 receives prefix IP1/24 via both an EVPN route
and a non-EVPN ISF route (e.g., an IPVPN route). Route
selection is performed as specified in Section 6.
* If the EVPN route is selected, PE4 resolves the BGP next-hop
to an MPLS tunnel (which may carry either Ethernet or IP
payloads) to PE1 and/or PE2. As described in Section 3, the
tunnel type used between EVPN PEs depends on the [RFC9136]
model supported.
* Other composite PEs (e.g., PE1 and PE2) receiving the same
prefix via both EVPN and IPVPN SAFIs must also apply the route
selection process defined in Section 6.
5. Forwarding Behavior Based on Selected Route
Once a route has been selected for a given IP prefix, packet
forwarding MUST follow the forwarding rules associated with the
AFI/SAFI of the selected route.
6. Applicability of EVPN Forwarding Enhancements
Rabadan, et al. Expires 25 May 2026 [Page 25]
Internet-Draft EVPN and IPVPN Interworking November 2025
In composite domains such as the one depicted in Figure 7, the
advanced forwarding features provided by EVPN are available only
to composite and EVPN-capable PEs that select an EVPN IP Prefix
route as the best path. These enhancements are not available to
IPVPN-only PEs. For example, if PE1 advertises IP1/24 using both
EVPN and IPVPN routes, and the EVPN route is selected as the best
path, only composite PEs such as PE2 and PE4 can leverage EVPN-
specific recursive resolution and forwarding mechanisms. IPVPN
PEs, such as PE3, cannot utilize these capabilities.
Consequently, the benefits of EVPN-based indirection and route
resolution in large-scale deployments may not be available
uniformly across all PEs in the network.
8. Gateway PE Procedures
As defined in Section 3, a gateway PE is an Interworking PE that
connects two or more domains and facilitates the propagation of ISF
routes between those domains. Typical examples include data center
gateway devices that interconnect domains utilizing different ISF
SAFIs, such as EVPN and IPVPN, for the same tenant network.
The gateway PE procedures specified in this document define the
mechanisms required to support ISF route interconnection across such
domains. These procedures extend the concept of a gateway PE beyond
the scope of Section 3, which focuses on Layer 2 interconnection, by
providing an analogous interconnection model for ISF route exchange
at Layer 3.
The procedures described in this section apply to both of the
following scenarios:
* Interconnection between domains utilizing different ISF SAFIs
(e.g., EVPN to IPVPN).
* Interconnection between domains utilizing the same ISF SAFI (e.g.,
EVPN to EVPN)
Figure 8 provides an illustrative example of this model, wherein PE1
and PE2 (as well as PE3 and PE4) operate as gateway PEs
interconnecting different domains associated with the same tenant.
Rabadan, et al. Expires 25 May 2026 [Page 26]
Internet-Draft EVPN and IPVPN Interworking November 2025
<----EVPN----> <----------IPVPN---------> <----EVPN---->
6500:1:EVPN 6500:2:IPVPN 6500:3:EVPN
<DOMAIN-ID:ISF_SAFI_TYPE>
+-----------------------+
Gateway PE1 Gateway PE3
+----------+ +----------+
+-----------|+------+ | MPLS tnls |+------+ |------------+
| ||IP-VRF| | ||IP-VRF| | |
PE5 |+------+ | |+------+ | PE6
+------+ +----------+ +----------+ +------+
|IP-VRF| NVO tnls | | | | NVO tnls |IP-VRF|
| | | | | | | |
+------+ +----------+ +----------+ +------+
IP1/24--> |+------+ | |+------+ | |
| ||IP-VRF| | ||IP-VRF| | |
+-----------|+------+ | |+------+ |------------+
+----------+ +----------+
Gateway PE2 +------+ Gateway PE4
+-------|IP-VRF|---------+
| |
+------+
PE7
Figure 8: Gateway PE example
A gateway PE that is enabled for two ISF SAFIs, referred to here as
SAFI x and SAFI y, on the same IP-VRF, MUST follow the procedures
described below for propagating routes between domains.
8.1. Export Conditions
1. A Gateway PE that imports an ISF SAFI x route for prefix P into
an IP-VRF MUST export P using ISF SAFI y if all of the following
conditions are met:
a. The route for P is installed in the IP-VRF, indicating that
the SAFI x route is well-formed, valid, and selected as the
best route.
b. The PE has an active BGP session with a peer supporting SAFI
y, enabled for the same IP-VRF.
c. Export policy permits the advertisement of the route.
d. SAFI x and SAFI y are valid ISF SAFIs as defined in
Section 3. SAFI x and SAFI y MAY be the same.
Rabadan, et al. Expires 25 May 2026 [Page 27]
Internet-Draft EVPN and IPVPN Interworking November 2025
Example: In Figure 8, Gateway PEs PE1 and PE2 receive an EVPN IP
Prefix route for prefix IP1/24, install the route in their
respective IP-VRFs, and re-advertise it using SAFI 128 (IPVPN).
2. A Gateway PE that receives an ISF SAFI x route for prefix P into
an IP-VRF MUST NOT export P using SAFI y under any of the
following conditions:
a. The SAFI x route is not well-formed or valid. Criteria for
route validity are defined in the corresponding ISF SAFI
specification. For example, an EVPN IP Prefix route that
contains both a non-zero EESI and a Gateway IP address is
invalid, as specified in [RFC9136], Section 3.2.
b. The D-PATH attribute of the SAFI x route includes one or more
DOMAIN-ID values locally configured on the Gateway PE for the
associated IP-VRF. In this case, the route is considered a
looped ISF route, as described in Section 4, and MUST NOT be
exported using SAFI y.
8.2. Advertisement Behavior
If the export conditions are satisfied, the gateway PE MUST advertise
prefix P using ISF SAFI y in accordance with the following
procedures:
a. If Uniform Propagation Mode (see Section 5.2) is enabled, the
gateway PE MUST include the D-PATH attribute when SAFI y is
either SAFI 128 (IPVPN) or EVPN. This enables loop detection at
downstream gateway PEs.
When propagating an ISF route, the gateway PE MUST prepend a
<DOMAIN-ID:ISF_SAFI_TYPE> element to the received D-PATH
attribute. The DOMAIN-ID reflects the domain from which the
route was received, and the ISF_SAFI_TYPE reflects the SAFI of
the received route.
If the received route does not include a D-PATH attribute, the
gateway PE MUST create and attach a new D-PATH attribute
containing a single segment: the <DOMAIN-ID:ISF_SAFI_TYPE>
corresponding to the received route.
Rabadan, et al. Expires 25 May 2026 [Page 28]
Internet-Draft EVPN and IPVPN Interworking November 2025
Example: In Figure 8, gateway PEs PE1 and PE2 receive an EVPN IP
Prefix route from PE5 that does not include a D-PATH attribute.
PE1 and PE2 add Domain <6500:1:EVPN> to form the new D-PATH.
Gateway PEs PE3 and PE4, upon re-advertising the route, prepend
<6500:2:IPVPN>, resulting in PE6 receiving the route with D-PATH
{<6500:2:IPVPN>, <6500:1:EVPN>}. This information is then used
by PE6 in BGP path selection.
b. The gateway PE MAY use the Route Distinguisher (RD) of the IP-VRF
when re-advertising prefix P via ISF SAFI y.
c. Label allocation for route advertisement is an implementation-
specific matter. The gateway PE MAY use per-VRF, per-prefix, or
other label allocation models.
d. The gateway PE MUST support the use of distinct Route Target (RT)
sets per domain on the same IP-VRF. If multiple domains
associated with a tenant use different RT sets, the gateway PE
MUST be capable of importing and exporting routes according to
each domain's RT configuration.
e. Although Figure 8 illustrates a scenario with only two domains
per gateway PE, gateway PEs MAY interconnect more than two
domains.
f. There is no restriction on the number of gateway PEs that a given
prefix P may traverse before reaching its destination.
g. If Uniform Propagation Mode is used for BGP Path Attribute
propagation, the gateway PE MUST follow the procedures defined in
Section 5.2 in addition to the D-PATH specific behavior described
in item (a).
h. Informative Note: If prefix P is originated in an EVPN domain and
subsequently traverses one or more non-EVPN ISF SAFI domains, it
will lose EVPN-specific attributes used for advanced EVPN
procedures. For example, if PE1 advertises prefix IP1/24 along
with a non-zero ESI (for recursive resolution to that ESI), the
ESI value will be reset to zero by the time the route reaches
PE6, as it passed through an ISF SAFI domain that is not EVPN-
capable. Consequently, certain EVPN-specific functionalities may
not be preserved end-to-end.
Rabadan, et al. Expires 25 May 2026 [Page 29]
Internet-Draft EVPN and IPVPN Interworking November 2025
9. Interworking Use-Cases
While network deployments involving Interworking PEs may align with
the scenarios described in Section 7 and Section 8, there are cases
where a combination of both gateway PE and composite PE functionality
is required. Figure 9 illustrates an example in which gateway PEs
also operate as composite PEs. In such scenarios, the devices must
not only propagate ISF routes between domains, such as between EVPN
and IPVPN SAFIs or across multiple EVPN domains, but also
interoperate with IPVPN-only PEs within domains that include a mix of
composite and IPVPN-only PEs.
+-----------------------------------+
| |
| MPLS IPVPN PE3
| Network +---------+
| IPVPN |+------+ |
| +----->||IP-VRF|---TS3
(GW+composite) PE1 | |+------+ |
+---------------+ | +---------+
| +------+ | EVPN v |
| |IP+VRF| | IPVPN +--+ |
| +----| | | <------>|RR| |
+--------| | +------+ | +--+ Composite PE4
| | |MAC+VRF| | ^ ^ +---------+
| | +-------+ | EVPN | | EVPN |+------+ |
+----+ +---------------+ IPVPN | | IPVPN ||IP-VRF|---TS4
TS1-|NVE1| | +----+ +------->|+------+ |
+----+ | v +---------+
| EVPN DC | +---------------+ |
| NVO tnls +----| +------+ |-------------+
| | |IP+VRF| |
| | +----| | |
| | | +------+ |
| +----+ | |MAC+VRF| |
+-----|NVE2|---------| +-------+ |
+----+ +---------------+
| (GW+composite) PE2
TS2
Figure 9: Gateway and composite combined functions - example
In the example illustrated, PE1 and PE2 MUST follow the procedures
defined in Section 7 and Section 8. Unlike the scenario described in
Section 8, PE1 and PE2 are additionally required to propagate ISF
routes between EVPN domains (i.e., EVPN-to-EVPN), in addition to
EVPN-to-IPVPN propagation. It is important to note that PE1 and PE2
will receive the IP prefix associated with TS4 via both IPVPN and
Rabadan, et al. Expires 25 May 2026 [Page 30]
Internet-Draft EVPN and IPVPN Interworking November 2025
EVPN IP Prefix routes. When re-advertising the selected route to
NVE1 and NVE2, PE1 and PE2 MUST apply the D-PATH handling rules and
related attribute processing as described in Section 6 (Route
Selection Process).
10. BGP Error Handling on Interworking PEs
An Interworking PE, whether operating in a Gateway PE or Composite PE
role, MUST adhere to the following error-handling procedures when
processing Inter-Subnet Forwarding (ISF) routes:
* Any BGP UPDATE message for an ISF route that includes a D-PATH
Path Attribute MUST be handled in accordance with the error-
handling rules defined in Section 4 of this document.
* All received BGP UPDATE messages for ISF routes MUST conform to
the general error-handling procedures specified in [RFC7606].
* This specification introduces no new error-handling behaviors for
BGP UPDATE messages that contain NLRI and BGP Path Attributes
defined in other specifications. Implementations SHOULD apply the
relevant error-handling rules specified for each supported route
type. Applicable references include::
BGP IP routes: [RFC4760], [RFC8950].
IPVPN routes: [RFC4364], [RFC4659].
EVPN MAC/IP Advertisement routes (Route Type 2): [RFC7432],
[RFC8365].
EVPN IP Prefix routes (Route Type 5): [RFC9136].
ISF routes installed in IP-VRFs with SRv6 forwarding:
[RFC9252].
If a Gateway PE is configured to propagate BGP Path Attributes for
ISF routes between domains, the procedures specified in Section 5.2
are intended to ensure that receiving BGP speakers do not encounter
UPDATE messages containing well-formed but semantically inappropriate
BGP Path Attributes. However, if a gateway PE incorrectly propagates
such attributes in violation of the procedures in Section 5.2,
receiving PEs MUST apply the error-handling rules defined in the
applicable specifications for the relevant route type and attribute.
The following are examples of such scenarios and their handling:
Rabadan, et al. Expires 25 May 2026 [Page 31]
Internet-Draft EVPN and IPVPN Interworking November 2025
* If a Gateway PE erroneously propagates the BGP Encapsulation
Extended Community or the equivalent Encapsulation TLV in the
Tunnel Encapsulation Attribute [RFC9012] from one EVPN domain to
another, the receiving PE MAY receive two encapsulation
indications with different values. In such a case, the PE MUST
follow the procedures in [RFC8365], which permit signaling
multiple encapsulation types. As specified in [RFC9012],
encapsulations carried via the Tunnel Encapsulation Attribute MUST
be treated as equivalent to those conveyed via the Encapsulation
Extended Community.
* If a gateway PE propagates an EVPN Extended Community from an EVPN
domain into an IPVPN domain, the receiving IPVPN PE MUST ignore
such communities, as their semantics are not applicable to the
IPVPN SAFI.
* If a gateway PE erroneously propagates a BGP Prefix-SID attribute
containing SRv6 Service TLVs [RFC9252] for an ISF route between
domains, and the receiving PE receives multiple SRv6 TLV
instances, it MUST apply the procedures specified in [RFC9252] for
resolving multiple TLVs.
11. Conclusion
This document defines procedures applicable to PE routers that
process and advertise ISF routes for a given tenant. In particular,
the following key procedures are specified:
* A route selection algorithm that enables a PE to deterministically
select a best path among candidates learned via EVPN and other ISF
SAFIs.
* A new BGP Path Attribute, referred to as the Domain Path (D-PATH)
attribute, which provides loop prevention capabilities and conveys
domain traversal information for a given route.
* The rules governing BGP Path Attribute propagation across domains
to maintain semantic consistency and enable cross-domain route
processing.
* The operational procedures required on Interworking PEs that
function as composite PEs, gateway PEs, or devices supporting both
roles.
Rabadan, et al. Expires 25 May 2026 [Page 32]
Internet-Draft EVPN and IPVPN Interworking November 2025
Collectively, these procedures equip operators with the necessary
mechanisms to deploy scalable tenant networks spanning multiple
administrative or routing domains, employing different ISF SAFIs for
IP prefix dissemination while maintaining deterministic forwarding
behavior and routing loop protection.
12. Security Considerations
The security considerations outlined in [RFC9136] and [RFC4364] are
applicable to this specification.
This document introduces the D-PATH Path Attribute (Section 4), which
provides a mechanism for control-plane loop prevention when ISF IPVPN
and EVPN routes are propagated across multiple domains via Gateway
PEs. When configured and supported correctly, the use of the D-PATH
attribute helps prevent both control-plane and data-plane loops.
However, incorrect configuration of DOMAIN-ID values or inconsistent
support for D-PATH among Gateway PEs may result in false-positive
loop detection, traffic discarding, or suboptimal and inconsistent
routing behavior. Furthermore, as D-PATH is a transitive BGP
attribute, a malicious actor may attempt to inject incorrect domain
information that propagates across multiple administrative
boundaries.
To mitigate such risks, the use of D-PATH is explicitly restricted to
IPVPN and EVPN routes within "walled garden" Virtual Private
Networks, as specified in Section 4. A PE that conforms to this
specification MUST remove the D-PATH attribute prior to advertising a
prefix to a CE router in a SAFI 1 (NLRI used for unicast forwarding)
route. If a non-upgraded PE that does not support D-PATH receives
such a route and is connected to a CE with Internet access, it may
erroneously propagate the D-PATH attribute in a SAFI 1 UPDATE to the
CE. If the CE further propagates the route, the D-PATH attribute
could inadvertently escape into the public Internet.
However, the presence of the D-PATH attribute in SAFI 1 routes MUST
NOT impact BGP best-path selection for those routes and, as such,
cannot introduce routing loops or instability in the Internet.
Additionally, BGP speakers beyond the "walled garden" that support
D-PATH and receive the attribute in SAFI 1 routes MUST apply the
"treat-as-withdraw" behavior, as described in Section 4 and
consistent with [RFC7606].
As a further safeguard, implementations SHOULD enforce local policy
on upgraded PEs to discard any ISF EVPN or IPVPN routes received from
non-upgraded peers if such routes include a D-PATH attribute, to
prevent unintended propagation.
Rabadan, et al. Expires 25 May 2026 [Page 33]
Internet-Draft EVPN and IPVPN Interworking November 2025
Section 5.2 of this document introduces Uniform Propagation Mode,
which enables gateway PEs to propagate a consistent set of BGP Path
Attributes across domain boundaries. This mode enhances operational
visibility by preserving attributes end-to-end along the route path.
However, it also introduces the possibility that an attacker could
inject malformed or semantically inappropriate, but syntactically
correct, attributes that influence BGP path selection in remote
domains.
To mitigate this risk, an operator MAY choose to deploy No-
Propagation Mode (Section 5.1), wherein BGP Path Attributes are re-
initialized upon domain transition. While this limits attribute-
based attack vectors, it also eliminates the ability of downstream
PEs to inspect the original set of BGP Path Attributes as intended by
the route originator.
Operators SHOULD carefully weigh the trade-offs between visibility
and control when selecting the appropriate propagation mode and
ensure that policies are in place to validate attribute contents at
domain boundaries.
13. IANA Considerations
This document defines a new BGP path attribute known as the BGP
Domain Path (D-PATH) attribute.
IANA has assigned a new attribute code type from the "BGP Path
Attributes" subregistry under the "Border Gateway Protocol (BGP)
Parameters" registry:
Path Attribute Value Code Reference
-------------------- ------------------------ ---------------
36 BGP Domain Path (D-PATH) [This document]
14. Acknowledgments
The authors want to thank Russell Kelly, Dhananjaya Rao, Suresh
Basavarajappa, Mallika Gautam, Senthil Sathappan, Arul Mohan Jovel,
Naveen Tubugere, Mathanraj Petchimuthu, Eduard Vasilenko, Amit Kumar,
Mohit Kumar, Lukas Krattiger, Gyan Mishra and Stephane Litkowski for
their review and suggestions. Thanks to Sue Hares and Jeff Haas as
well, for their detailed review to clarify the procedures of the
D-PATH attribute. The authors want to also thank especially Gunter
van de Velde for his thorough review that helped raise the quality of
the document significantly.
15. Contributors
Rabadan, et al. Expires 25 May 2026 [Page 34]
Internet-Draft EVPN and IPVPN Interworking November 2025
16. References
16.1. Normative References
[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>.
[RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R.,
Uttaro, J., and W. Henderickx, "A Network Virtualization
Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365,
DOI 10.17487/RFC8365, March 2018,
<https://www.rfc-editor.org/info/rfc8365>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
Patel, "Revised Error Handling for BGP UPDATE Messages",
RFC 7606, DOI 10.17487/RFC7606, August 2015,
<https://www.rfc-editor.org/info/rfc7606>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007,
<https://www.rfc-editor.org/info/rfc4760>.
[RFC9136] Rabadan, J., Ed., Henderickx, W., Drake, J., Lin, W., and
A. Sajassi, "IP Prefix Advertisement in Ethernet VPN
(EVPN)", RFC 9136, DOI 10.17487/RFC9136, October 2021,
<https://www.rfc-editor.org/info/rfc9136>.
Rabadan, et al. Expires 25 May 2026 [Page 35]
Internet-Draft EVPN and IPVPN Interworking November 2025
[RFC9135] Sajassi, A., Salam, S., Thoria, S., Drake, J., and J.
Rabadan, "Integrated Routing and Bridging in Ethernet VPN
(EVPN)", RFC 9135, DOI 10.17487/RFC9135, October 2021,
<https://www.rfc-editor.org/info/rfc9135>.
[RFC9252] Dawra, G., Ed., Talaulikar, K., Ed., Raszuk, R., Decraene,
B., Zhuang, S., and J. Rabadan, "BGP Overlay Services
Based on Segment Routing over IPv6 (SRv6)", RFC 9252,
DOI 10.17487/RFC9252, July 2022,
<https://www.rfc-editor.org/info/rfc9252>.
16.2. Informative References
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
February 2006, <https://www.rfc-editor.org/info/rfc4360>.
[RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder,
"The BGP Tunnel Encapsulation Attribute", RFC 9012,
DOI 10.17487/RFC9012, April 2021,
<https://www.rfc-editor.org/info/rfc9012>.
[RFC9774] Kumari, W., Sriram, K., Hannachi, L., and J. Haas,
"Deprecation of AS_SET and AS_CONFED_SET in BGP",
RFC 9774, DOI 10.17487/RFC9774, May 2025,
<https://www.rfc-editor.org/info/rfc9774>.
[RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur,
"BGP-MPLS IP Virtual Private Network (VPN) Extension for
IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006,
<https://www.rfc-editor.org/info/rfc4659>.
[RFC8950] Litkowski, S., Agrawal, S., Ananthamurthy, K., and K.
Patel, "Advertising IPv4 Network Layer Reachability
Information (NLRI) with an IPv6 Next Hop", RFC 8950,
DOI 10.17487/RFC8950, November 2020,
<https://www.rfc-editor.org/info/rfc8950>.
[RFC9014] Rabadan, J., Ed., Sathappan, S., Henderickx, W., Sajassi,
A., and J. Drake, "Interconnect Solution for Ethernet VPN
(EVPN) Overlay Networks", RFC 9014, DOI 10.17487/RFC9014,
May 2021, <https://www.rfc-editor.org/info/rfc9014>.
Rabadan, et al. Expires 25 May 2026 [Page 36]
Internet-Draft EVPN and IPVPN Interworking November 2025
[I-D.ietf-idr-wide-bgp-communities]
Raszuk, R., Haas, J., Lange, A., Decraene, B., Amante, S.,
and P. Jakma, "BGP Community Container Attribute", Work in
Progress, Internet-Draft, draft-ietf-idr-wide-bgp-
communities-12, 17 March 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-
wide-bgp-communities-12>.
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
Reflection: An Alternative to Full Mesh Internal BGP
(IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,
<https://www.rfc-editor.org/info/rfc4456>.
Authors' Addresses
J. Rabadan (editor)
Nokia
520 Almanor Avenue
Sunnyvale, CA 94085
United States of America
Email: jorge.rabadan@nokia.com
A. Sajassi (editor)
Cisco
225 West Tasman Drive
San Jose, CA 95134
United States of America
Email: sajassi@cisco.com
E. Rosen
Individual
Email: erosen52@gmail.com
J. Drake
Independent
Email: je_drake@yahoo.com
W. Lin
HPE
Email: wen.lin@hpe.com
J. Uttaro
Independent
Rabadan, et al. Expires 25 May 2026 [Page 37]
Internet-Draft EVPN and IPVPN Interworking November 2025
Email: juttaro@ieee.org
A. Simpson
Nokia
Email: adam.1.simpson@nokia.com
Rabadan, et al. Expires 25 May 2026 [Page 38]