This article is a technical explanation and implementation example generated using AI. Although the included code and procedures are based on primary sources, the author has not verified their operation on actual hardware. Behavior may vary depending on the environment and version.

Organizing the Communication Sequences and Message Structures of RFC 10039: Interconnecting EVPN and IPVPN Domains

When a multi-tenant network spans multiple domains, we organize the interconnection procedures to ensure seamless connectivity between Ethernet Virtual Private Network (EVPN) and IPVPN (BGP VPN-IPv4 / VPN-IPv6), as well as specifications regarding control plane loop prevention, based on primary sources. This article explains the roles of components in multi-domain interconnection and extensions related to BGP path selection.

Objectives, Prerequisites, and Notes

Objectives

The objective is to understand the relay mechanisms when interconnecting different BGP domains (EVPN and IPVPN), the mechanisms to prevent control plane loops, and the specifications regarding the propagation of path attributes.

Prerequisites and Notes

• Primary sources are based on RFC 10039 (Interconnecting EVPN and IPVPN Domains).

• This article organizes the concepts of structures and messages and does not guarantee operation on specific devices or actual hardware.

• Since no physical verification environment has been built, concrete experimental results or successful packet capture examples will not be shown.

Overview of Interconnection between EVPN and IPVPN Domains

When a tenant network spans multiple domains (a combination of EVPN and IPVPN domains), a mechanism to re-originate routes between domains is required to maintain end-to-end tenant connectivity.

According to primary sources, a node called an Interworking PE assumes this relay role. The Interworking PE imports routes (including encapsulation parameters) from one domain, installs them into the IP Virtual Routing and Forwarding (IP-VRF) table, and then re-advertises them with encapsulation attributes suitable for the adjacent domain. This enables service interconnection independent of the transport mechanisms internal to each domain.

Loop Prevention in the Control Plane and the D-PATH Attribute

In a redundant configuration where multiple gateway nodes interconnect different domains, routing loops may occur in the control plane without appropriate protection mechanisms. For example, if Gateway PE1 imports an IPVPN route and retransmits it to the EVPN domain as an EVPN IP Prefix route, and another Gateway PE2 then advertises it back to the IPVPN domain, a loop is formed.

To address this issue, RFC 10039 introduces a new BGP path attribute called Domain Path (D-PATH). The D-PATH attribute provides domain-level loop detection and avoidance, and modifies the BGP best-path selection logic in Multiprotocol BGP SAFI 128 (VPN-IPv4 / VPN-IPv6) and EVPN IP Prefix routes.

Component Architecture of the Interworking PE

The primary source defines the following terminology and components related to interworking PEs:

• AC (Attachment Circuit): A combination of a logical interface or physical port and a VLAN tag associated with a Bridge Table (BT) or IP-VRF.

• BT (Bridge Table): [RFC7432] An instance of a broadcast domain as defined in. When multiple broadcast domains exist within a MAC-VRF, each BT is associated with a different Ethernet tag.

• Composite Domain: A domain where multiple control plane ISF SAFIs (IPVPN and/or EVPN) are used.

• Composite PE: An interworking PE connected to at least one composite domain that can advertise prefixes to multiple types of peers using appropriate route types.

• Gateway PE / Composite/Gateway PE: A node that interconnects multiple domains and simultaneously performs the functions of both a composite PE and a gateway PE.

The following Mermaid diagram illustrates the architectural concept of the EVPN-IPVPN interworking PE described in the primary source.

flowchart TD
    AC1["Attachment Circuit (AC1)"] --> BT1["Bridge Table (BT1)"]
    AC2["Attachment Circuit (AC2)"] --> BT2["Bridge Table (BT2)"]
    BT1 --> IRB1["IRB1"]
    BT2 --> IRB2["IRB2"]
    IRB1 --> IPVRF["IP-VRF1 (RD2/RT2)"]
    IRB2 --> IPVRF
    AC3["Attachment Circuit (AC3)"] --> IPVRF
    IPVRF --> BGP["BGP SAFIs (IPVPN / EVPN IP)"]

Points of BGP Route Re-origination and Attribute Propagation

In EVPN, IPv4 or IPv6 prefixes are primarily advertised using the following route types:

• Route Type 2: EVPN MAC / IP Advertisement route ([RFC9135]). Supports host routes (/32 and /128).

• Route Type 5: EVPN IP Prefix route ([RFC9136])。

When interworking with BGP address families listed elsewhere, IP prefixes contained in these EVPN route types are re-originated into the corresponding address family (e.g., IPVPN) and vice versa. During this process, route selection, loop prevention, and the handling of BGP path attributes across AFI/SAFI boundaries are managed to ensure consistency.

Limitations and Precautions Before Verification on Actual Equipment

• The procedures and the operation of the D-PATH attribute explained in this article are theoretical descriptions based on the specification (RFC 10039).

• Since packet transmission and reception, BGP session establishment, and actual behavior verification of the D-PATH attribute have not been performed using actual routers or emulator environments, it is necessary to check each vendor's implementation status and version when applying them in a production environment.

Conclusion

We have outlined the interconnection mechanism between EVPN and IPVPN domains based on RFC 10039.

The points to check and constraints before execution are as follows.

• Verify whether the equipment and BGP implementations used support RFC 10039 and the D-PATH attribute.

• In network designs spanning multiple domains, thoroughly verify policies and attribute propagation rules to prevent control plane loops.

• The content of this article is based on the investigation of specifications, and operational verification on actual equipment must be conducted separately for each environment.

References

• Source Title: RFC 10039: Interconnecting EVPN and IPVPN Domains

• Source URL: https://www.rfc-editor.org/info/rfc10039/