RFC 10018

Multicast and Ethernet VPN with Segment Routing Point-to-Multipoint (P2MP) and Ingress Replication

📅 published August 2026, from ietf
part 1 of 6 🎀 more parts coming, don't log off

Okay so this is RFC 10018 🎀, titled Multicast and Ethernet VPN with Segment Routing Point-to-Multipoint (P2MP) and Ingress Replication. It's a Standards Track doc, so it's a real spec people build against 💅. The editors are R. Parekh, Ed. (Arrcus) and D. Voyer, Ed., with C. Filsfils (Cisco Systems, Inc.), H. Bidgoli (Nokia), and Z. Zhang (Juniper Networks) also listed as authors. It was published in August 2026 with ISSN 2070-1721. It updates RFC 6514 and RFC 7988, and the title block doesn't list anything it obsoletes ✨.

Abstract ✨

Okay so a Point-to-Multipoint (P2MP) tree in a Segment Routing (SR) domain carries traffic from a Root to a set of Leaves 🌸. This doc specifies extensions to BGP encodings and procedures for P2MP trees and Ingress Replication, used in BGP/MPLS IP VPNs and Ethernet VPNs (EVPNs) in an SR domain. It updates RFCs 6514 and 7988 💖.

Status of This Memo 🌈

This is an Internet Standards Track document, so it's the real deal 💅.

It's a product of the Internet Engineering Task Force (IETF), and it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 7841 🧚.

For info on the current status of this doc, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc10018 🔥.

Copyright (c) 2026 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, because 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 they're provided without warranty as described in the Revised BSD License 🙈.

Table of Contents 🧚

   1.  Introduction
     1.1.  Terminology
     1.2.  Requirements Language
   2.  SR P2MP P-Tunnel
   3.  MVPN with SR
     3.1.  SRv6 Multicast Endpoint Behaviors
       3.1.1.  End.DTMC4: Decapsulation and Specific IPv4 Multicast
               Table Lookup
       3.1.2.  End.DTMC6: Decapsulation and Specific IPv6 Multicast
               Table Lookup
       3.1.3.  End.DTMC46: Decapsulation and Specific IP Multicast
               Table Lookup
     3.2.  MVPN with SR P2MP P-Tunnel
       3.2.1.  PMSI Tunnel Attribute for SR P2MP P-Tunnel
       3.2.2.  Auto-Discovery Procedures
     3.3.  MVPN with Ingress Replication over SR
       3.3.1.  SR-MPLS
       3.3.2.  SRv6
   4.  EVPN with SR
     4.1.  EVPN with SR P2MP P-Tunnel
       4.1.1.  PMSI Tunnel Attribute for SR P2MP P-Tunnel
       4.1.2.  Split-Horizon Filtering for ES Multihoming
       4.1.3.  Auto-Discovery Procedures
     4.2.  EVPN with Ingress Replication over SR
       4.2.1.  SR-MPLS
       4.2.2.  SRv6
   5.  IANA Considerations
   6.  Security Considerations
   7.  References
     7.1.  Normative References
     7.2.  Informative References
   Acknowledgements
   Contributors
   Authors' Addresses

1. Introduction 💖

"Multicast in MPLS/BGP IP VPNs" [RFC6513] and "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs" [RFC6514] are the specs that let a network operator give customers Multicast VPN (MVPN) service 🧚. Customer multicast traffic gets tunneled across the service provider network over Provider Tunnels (P-tunnels), and P-tunnels can be built with different transport mechanisms. For example, a service provider network that uses Segment Routing (SR) can use an SR Point-to-Multipoint (P2MP) tree defined by an SR P2MP Policy [RFC9960], or SR P2MP Ingress Replication (IR), to instantiate P-tunnels for MVPN. This document calls a P-tunnel realized by an SR P2MP Policy an SR P2MP P-tunnel. SR P2MP P-tunnels can be instantiated for both Segment Routing over MPLS (SR-MPLS) [RFC8660] and Segment Routing over IPv6 (SRv6) [RFC8986] [RFC8754] ✨.

An SR P2MP tree is defined by an SR P2MP Policy [RFC9960] and instantiated via a controller, such as a Path Computation Element (PCE). An SR P2MP Policy consists of a Root, a set of Leaf nodes, and a set of candidate paths (CPs) with optional set of constraints and/or optimization objectives to be satisfied by the SR P2MP tree. A CP has zero or more P2MP tree instances (PTIs) 🌸.

This document specifies extensions to the BGP auto-discovery procedures specified in [RFC6514] for P-tunnels constructed with a PTI. Use of Protocol Independent Multicast (PIM) for auto-discovery is outside the scope of this document. Support for customer Bidirectional PIM (BIDIR-PIM) is also outside the scope of this document 🙅‍♀️.

This document extends procedures in [RFC7988] for MVPN service with IR over an SR-MPLS data plane with a Service Level Agreement (SLA). New procedures are defined for MVPN service with IR over an SRv6 data plane, with or without an SLA 🦋.

This document defines new SRv6 Endpoint behaviors [RFC8986] used for MVPN with SR P2MP and IR P-tunnels 🔥.

For BGP MPLS-Based EVPN, specified in [RFC7432] and updated in [RFC9572], P-tunnels are advertised for handling multi-destination traffic. These P-tunnels can be instantiated by SR-MPLS or SRv6 P2MP trees 🌈.

The reader is expected to be familiar with [RFC6513] and [RFC6514] for MVPN procedures. For EVPN procedures, refer to [RFC7432] 📚.

Scalability, operational, and troubleshooting considerations for SR P2MP trees and Replication segments are described in [RFC9960] and [RFC9524], respectively. Operations, Administration, and Maintenance (OAM) ping and traceroute procedures for SR P2MP Policy using the SR-MPLS data plane are specified in [RFC9961] 🛠️.

1.1. Terminology

Okay, these terms are used as defined in [RFC8402] 🧠:

  • Segment Routing (SR)
  • Segment Identifier (SID)
  • SR domain
  • SR-MPLS
  • SRv6
  • SRv6 SID

This term is used as defined in [RFC8754] 🫶:

  • Segment Routing Header (SRH)

These terms are used as defined in [RFC9524] 🍓:

  • Replication segment
  • Replication-SID
  • Root node
  • Leaf node
  • Bud node
  • Intermediate Replication node

These terms are used as defined in [RFC9960] 💜:

  • SR P2MP Policy
  • Tree-ID
  • Candidate path (CP)
  • P2MP tree instance (PTI)
  • Tree-SID

For MVPN, these terms are used as defined in [RFC6513] and [RFC6514] 🎀:

  • P-Multicast Service Interface (PMSI)
  • P-tunnel
  • PMSI Tunnel Attribute (PTA)
  • Auto-Discovery (A-D) routes
  • Intra-AS I-PMSI A-D
  • Inter-AS I-PMSI A-D
  • S-PMSI A-D
  • Leaf A-D route

For EVPN, these terms are used as defined in [RFC7432], [RFC9251], and [RFC9572] 🌸:

  • EVPN Instance (EVI)
  • Ethernet Segment (ES)
  • Ethernet Segment Identifier (ESI)
  • Inclusive Multicast Ethernet Tag (IMET) route
  • Selective Multicast Ethernet Tag (SMET) route
  • Broadcast, Unknown Unicast or Multicast (BUM)
  • S-PMSI
  • Leaf A-D route

1.2. Requirements Language 🫶

Okay so about the capital-letter words. 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 🙏.

next up: Section 2, SR P2MP P-Tunnel 🧚✨

2. SR P2MP P-Tunnel ✨

okay so bestie, for MVPN or EVPN, Provider Edge (PE) routers can steer customer traffic into a P-tunnel that's realized by an SR-MPLS or SRv6 PTI 🦋. An SR PTI gets instantiated by a CP of an SR P2MP Policy [RFC9960]. A P-tunnel gets signaled in MVPN or EVPN A-D routes using the BGP PMSI Tunnel Attribute (PTA) [RFC6514], and the PTA is what identifies the P-tunnel that's used to instantiate a PMSI 💜.

   +---------------------------------+
   |            INGRESS PE           |                   +------------+
   |  +----------+     +----------+  |                   |            |
   |  |          |     |  SR P2MP |  |    PCEP/BGP/etc.  |            |
   |  | MVPN/EVPN+---->|  Policy  |  +------------------>| CONTROLLER |
   |  |  Module  |     |  Module  |  |                   |            |
   |  +----------+     +----------+  |                   |            |
   |                                 |                   +------------+
   +---------------------------------+

            Figure 1: MVPN/EVPN Interaction with SR P2MP Policy

this little diagram is giving the interaction between the conceptual MVPN or EVPN module and the SR P2MP Policy module on an ingress PE 🎀. The ingress PE participates in the MVPN or EVPN AD procedures and talks to the SR P2MP Policy module like this to create and update the SR P2MP Policy, the CP, and the Leaf set of SR P2MP policies. The SR P2MP Policy module chats with a controller over protocols like the Path Computation Element Communication Protocol (PCEP) [SR-P2MP-PCEP], BGP, the Network Configuration Protocol (NETCONF), etc. Those are outside the scope of this document 🌸.

An ingress PE creates a CP of an SR P2MP Policy in the SR P2MP Policy module when the MVPN or EVPN module gets provisioned for the SR P2MP P-tunnel. It can also happen based on events or policy, like mapping an MVPN or EVPN flow to a new SR P2MP P-tunnel 💅. This CP can have optional traffic engineering constraints and/or an optimization objective, set by provisioning or by a local policy. The SR P2MP Policy module signals the CP along with those constraints and that optimization objective to the controller, using one of the protocols above. Once the SR P2MP P-tunnel is no longer required, the ingress PE deletes the CP from the SR P2MP Policy module, and the SR P2MP Policy module signals that deletion of the CP to the controller 😭.

An ingress PE participates in the MVPN or EVPN A-D procedures defined in this document to discover Leaf nodes of an SR P2MP P-tunnel via various A-D routes. The MVPN or EVPN module on the ingress PE updates the Leaf set of the SR P2MP Policy corresponding to the P-tunnel in the SR P2MP Policy module. Then the SR P2MP Policy module signals the updated Leaf set to the controller using one of those protocols.

An egress PE associates an MVPN or EVPN A-D route with an MVPN or EVPN context, and tells the SR P2MP Policy module to join the SR P2MP P-tunnel as a Leaf or a Bud node 🙈.

Given a Leaf set of an SR P2MP Policy and a CP with constraints and an optimization objective, the controller computes and instantiates the PTI on the nodes that are part of the tree. It does this by stitching Replication segments [RFC9524] at the Root (ingress PE) node, intermediate replication nodes, and Leaf nodes (egress PEs) 🔥. A Replication segment of a PTI can be instantiated by various methods, such as BGP, PCEP, NETCONF, etc., which are outside the scope of this document. This PTI of the SR P2MP Policy is what instantiates the P-tunnel advertised by the MVPN or EVPN A-D routes.

The Tree-SID is the unique data plane identifier of the PTI. The Root node encapsulates the payload in the Tree-SID to steer it into the PTI. The Provider (P) routers replicate the encapsulated payload using Replication segments towards the Leaf nodes of the PTI. The Leaf nodes of the PTI dispose of the Tree-SID and deliver the payload. A Leaf node derives the MVPN or EVPN instance for delivering the payload from either the Tree-SID or another context encoded in the packet 👑.

Note that an ingress PE can deliver an MVPN or EVPN payload to the egress PEs using IR over SR-MPLS or SRv6. The SR P2MP Policy module and controller do not participate in IR ✨.

3. MVPN with SR 🧚

MVPN service can be provided using SR P2MP trees, or IR over either an SR-MPLS or SRv6 data plane 💖.

3.1. SRv6 Multicast Endpoint Behaviors

The following SRv6 Endpoint behaviors can be associated with the SRv6 Multicast Service SID used for MVPN with SR P2MP and IR P-tunnels.

3.1.1. End.DTMC4: Decapsulation and Specific IPv4 Multicast Table Lookup

The "Endpoint with Decapsulation and IPv4 Multicast Table Lookup" behavior (End.DTMC4 for short) is functionally identical to the End.DT4 behavior specified in [RFC8986], except that the forwarding lookup MUST be performed in the IPv4 multicast routing table rather than the IPv4 unicast routing table.

This behavior MUST only be associated with the SRv6 Multicast Service SID carried in AFI/SAFI 1/129 (MVPN-IPv4) A-D routes.

3.1.2. End.DTMC6: Decapsulation and Specific IPv6 Multicast Table Lookup

The "Endpoint with Decapsulation and IPv6 Multicast Table Lookup" behavior (End.DTMC6 for short) is functionally identical to the End.DT6 behavior specified in [RFC8986], except that the forwarding lookup MUST be performed in the IPv6 multicast routing table rather than the IPv6 unicast routing table.

This behavior MUST only be associated with the SRv6 Multicast Service SID carried in AFI/SAFI 2/129 (MVPN-IPv6) A-D routes.

3.1.3. End.DTMC46: Decapsulation and Specific IP Multicast Table Lookup

The "Endpoint with Decapsulation and IP Multicast Table Lookup" behavior (End.DTMC46 for short) is functionally identical to the End.DT4 and End.DT6 behaviors specified in [RFC8986], except that the forwarding lookup MUST be performed in the IP multicast routing table rather than in an IP unicast routing table.

This behavior MUST only be associated with the SRv6 Multicast Service SID carried in AFI/SAFI 1/129 (MVPN-IPv4) or 2/129 (MVPN-IPv6) A-D routes.

3.2. MVPN with SR P2MP P-Tunnel

[RFC6514] defines procedures for discovering PEs participating in a given MVPN and binding customer multicast flows to specific P-tunnels. This section specifies modifications to these procedures for SR P2MP P-tunnels. The Intra-AS I-PMSI, Inter-AS I-PMSI, and S-PMSI A-D routes have the PTA that specifies the SR P2MP tree P-tunnel. In this section, the term "SR P2MP" refers to both SR-MPLS and SRv6 data planes.

3.2.1. PMSI Tunnel Attribute for SR P2MP P-Tunnel

A PTA for an SR P2MP P-tunnel is constructed as specified below.

  • Tunnel Type: One of the following SR P2MP P-tunnel types (from the "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types" registry).
    • 0x0C for SR-MPLS P2MP Tree
    • 0x0D for SRv6 P2MP Tree
  • Flags: See Section 3.2.2 for use of the "Leaf Information Required" flag.
  • MPLS Label: See Section 4.1.1.1.
  • Tunnel Identifier: The SR P2MP P-tunnel identifies an SR P2MP Policy with the identifier <Root, Tree-ID> [RFC9960], encoded in the exact order below.
    • Tree-ID: A 32-bit unsigned value that uniquely identifies an SR P2MP Policy at the Root.
    • Root: An IP address identifying the Root of the SR P2MP Policy. This can be either an IPv4 or IPv6 address. The address type can be inferred from the PTA length.

A PTA with a SR P2MP P-tunnel is provisioned with the Tunnel Type for SR-MPLS or SRv6 P2MP trees. An implementation SHOULD advertise a PTA with SR P2MP P-tunnel only when the underlying SR-MPLS or SRv6 data plane is supported. The procedures for provisioning and determination of data plane support for SR-MPLS or SRv6 are outside scope of this document.

A P-tunnel can be segmented or non-segmented (see Section 8 of [RFC6513]). When a P-tunnel is non-segmented, the PTA is created by the PE router at the Root of an SR P2MP tree. For segmented P-tunnels, each segment can be instantiated by a different P-tunnel type. If a segment is instantiated using a P2MP tree, the router at the Root of an SR P2MP tree creates the PTA.

3.2.1.1. MPLS Label

When an SR P2MP P-tunnel is not shared across MVPNs, i.e., there is a one-to-one association between an MVPN instance and an SR P2MP P-tunnel, the MPLS Label field is set to zero as per [RFC6514] for both SR-MPLS and SRv6. In this case, the SR-MPLS or SRv6 Tree-SID of the PTI of the SR P2MP Policy advertised in the P-tunnel is sufficient to identify the MVPN instance for delivering the payload.

[RFC6514] allows a PE to aggregate two or more MVPNs onto one SR P2MP P-tunnel by advertising the same P-tunnel in the PTA of A-D routes of different MVPNs. In this case, the MPLS Label field of the PTA is filled to provide a context bound to a specific MVPN instance, as described in the sections below. The value in this field is used by egress PEs to identify the MVPN instance for delivering the payload encapsulated in SR-MPLS or SRv6.

3.2.1.1.1. SR-MPLS

When an SR P2MP P-tunnel is shared across two or more MVPNs in an SR-MPLS domain, the MPLS Label field of a PTA advertised in an A-D route MUST contain an upstream-assigned MPLS label [RFC5331] [RFC6513] or a label assigned from a global context, such as the Domain-wide Common Block (DCB) as specified in [RFC9573], that the advertising PE has bound to the MVPN.

When an ingress PE steers the payload into a shared SR P2MP P-tunnel PTI, this MPLS label MUST be imposed before the MPLS label representing the Tree-SID. The trade-off of sharing an SR P2MP P-tunnel across MVPNs is that two MPLS labels have to be imposed on ingress and disposed of on egress 🍓.

The egress PEs of a shared SR P2MP P-tunnel use the MPLS label to determine the MVPN instance for delivering the payload.

3.2.1.1.2. SRv6 ✨

okay bestie, so when a shared SR P2MP P-tunnel is hanging out across two or more MVPNs in an SRv6 domain [RFC8986] 🌸, the MPLS Label field of the PTA that the advertising PE sends MUST contain an upstream-assigned SRv6 Multicast Service SID (Section 3.1) that the PE bound to the MVPN 💖, or an SRv6 Multicast Service SID assigned from a global context. It's the same concept as the DCB label from [RFC9573], iykyk 🧚. The high-order 20 bits of the MPLS Label field carry the whole or a portion of the Function part of the SRv6 Multicast Service SID when the Transposition Scheme of encoding from [RFC9252] is used. When you're using the Transposition Scheme, the Transposition Length of the SRv6 SID Structure Sub-Sub-TLV of the SRv6 Prefix-SID attribute (see below) MUST be less than or equal to 20 and less than or equal to the Function Length. When the Transposition Scheme is not used, the MPLS Label field MUST be set to zero as per [RFC6514], and Transposition Length MUST be zero 🙈.

The advertising ingress PE MUST attach a BGP Prefix-SID attribute [RFC8669] to Intra-AS I-PMSI, Inter-AS I-PMSI, or S-PMSI A-D routes with the SRv6 L3 Service TLV [RFC9252] to signal the SRv6 Multicast Service SID. The SRv6 SID Information Sub-TLV carries the SRv6 Multicast Service SID in the SRv6 SID Value field. The SRv6 Endpoint behavior of the SRv6 SID Information Sub-TLV encodes one of End.DTMC4, End.DTMC6, or End.DTMC46 code point values. The SRv6 SID Structure Sub-Sub-TLV encodes the structure of the SRv6 Multicast Service SID. If the Transposition Scheme is used, the offset and length of SRv6 Multicast Endpoint function of the SRv6 Multicast Service SID is set in the Transposition Length and Transposition Offset fields of this sub-sub-TLV. Otherwise, the Transposition Length and Offset fields MUST be set to zero. The locator (LOC) of an SRv6 Multicast Service SID, which is assigned from a global context such as DCB, is outside the scope of this document 📦.

The advertising ingress PE, which is the Root node of the shared SR P2MP P-tunnel, MUST encapsulate a payload in an outer IPv6 header with an SRH in which the SRv6 Multicast Service SID MUST be the last segment in the segment list (note the SRv6 Multicast Service SID may be the only segment in the SRH) 🔥. If the Transposition Scheme is used, the ingress PE MUST merge the Function part of the MPLS Label field of the PTA with the SRv6 SID in the SRv6 SID Information Sub-TLV using the Transposition Offset and Length fields from the SRv6 SID Structure Sub-Sub-TLV to create the SRv6 Multicast Service SID.

An egress PE of the shared SR P2MP P-tunnel uses the SRv6 Multicast Service SID in the SRH to determine the MVPN instance in which the customer payload is to be delivered. The egress PE, in the role of Leaf or Bud node of the Replication segment associated with the shared SR P2MP P-tunnel tree, uses the "look at next SID in SRH" behavior from [RFC9524] to process the SRv6 Multicast Service SID. An egress PE MUST NOT install the SRv6 Multicast Service SID in its Forwarding Information Base (FIB), i.e., it MUST NOT forward packets based on the Locator portion of the SRv6 Multicast Service SID because the SID is not significant on the ingress PE. no forwarding off the locator, periodt 💅

3.2.2. Auto-Discovery Procedures 🦋

MVPN A-D procedures specified in [RFC6514] are used to advertise an SR P2MP P-tunnel and discover the Leaf nodes of the SR P2MP Policy associated with the P-tunnel. This section describes the processing of MVPN A-D routes to create, update, and tear down an SR P2MP Policy of an SR P2MP P-tunnel as described in Section 2 🌈.

3.2.2.1. Creation of CP of SR P2MP Policy ⭐

A PE interacts with an SR P2MP Policy module to create a CP, with optional traffic engineering constraints and an optional optimization objective, of an SR P2MP Policy when it originates an Intra-AS I-PMSI A-D route [RFC6514], an Inter-AS I-PMSI A-D route for an intra-AS segment [RFC6514], an S-PMSI A-D route [RFC6514], or a "wildcard" S-PMSI A-D route [RFC6625] with a PTA that has an SR P2MP P-tunnel type.

The CP of the SR P2MP Policy associated with an SR P2MP P-tunnel is deleted from the SR P2MP Policy module when a PE withdraws the Intra-AS I-PMSI, Inter-AS I-PMSI, or S-PMSI A-D route advertising that P-tunnel 🥀.

When a PE originates an Inter-AS I-PMSI or an S-PMSI A-D route with a PTA that has an SR P2MP P-tunnel type, it MUST set the "Leaf Information Required" flag in the PTA 🚩.

3.2.2.2. Discovery of Leaf Nodes 🧚‍♀️

An ingress PE that advertises an MVPN A-D route with a PTA that has an SR P2MP P-tunnel type discovers a Leaf node of the SR P2MP Policy associated with the SR P2MP P-tunnel when it imports an Intra-AS I-PMSI A-D route [RFC6514] or Leaf A-D route [RFC6514] from an egress PE. The ingress PE adds the egress PE as a Leaf node in the SR P2MP Policy module.

An ingress PE removes an egress PE from the Leaf set of the SR P2MP Policy when the egress PE withdraws the Intra-AS I-PMSI or the Leaf A-D route 👋.

An egress PE informs the SR P2MP Policy module to join the SR P2MP Policy as a Leaf or Bud node when it imports an Intra-AS I-PMSI A-D route, an Inter-AS I-PMSI A-D route, or an S-PMSI A-D route from an ingress PE that has a PTA with an SR P2MP P-tunnel type. The egress PE MUST originate a Leaf A-D route if the "Leaf Information Required" flag is set in the PTA 🎀.

An egress PE withdraws itself as a Leaf or Bud node of the SR P2MP Policy when the ingress PE withdraws an Intra-AS I-PMSI, Inter-AS I-PMSI, or S-PMSI A-D route. The egress PE MUST withdraw the Leaf A-D it had originated earlier in response to the "Leaf Information Required" flag in the PTA 🫶.

3.3. MVPN with Ingress Replication over SR 💜

A PE can provide MVPN service using IR over SR. The payload is encapsulated in SR-MPLS or SRv6 at an ingress PE and replicated with each copy sent to an egress PE via unicast 🍓.

"Ingress Replication Tunnels in Multicast VPN" [RFC7988] specifies procedures that can be reused to provide MVPN service with IR in an SR domain. A PE advertises Intra-AS I-PMSI A-D, Inter-AS I-PMSI A-D, or Selective PMSI A-D and Leaf A-D routes with the PTA for IR. Egress PEs join as Leaf nodes using Intra-AS I-PMSI A-D or Leaf A-D routes. The procedures of [RFC7988] provide an MVPN IR service with best-effort unicast connectivity 🌸.

This document adds procedures for providing an MVPN IR service with an SLA from an ingress PE to an egress PE both for SR-MPLS and SRv6 ✨. This document extends the BGP Update message of AFI/SAFI 1/129 (MVPN-IPv4) and 2/129 (MVPN-IPv6) to carry the Color Extended Community as specified in [RFC9012] and the Color-Only Type extension specified in Section 3 of [RFC9830]. An egress PE colors the Leaf or Intra-AS I-PMSI A-D route with a Color Extended Community. The ingress PE replicates MVPN customer payload to the egress PE by steering it into an SR-TE policy according to Section 8 of [RFC9256]. The ingress PE encapsulates the payload packet into a segment list of the matching SR-TE policy to the egress PE along with the IR MPLS label or SRv6 Multicast Service SID received from the egress PE 🦋.

Note that the Color Extended Community is not used with an MVPN SR P2MP P-tunnel. For MVPN with an SR P2MP P-tunnel, the ingress PE dictates the traffic engineering treatment by specifying the constraints and the metric optimization in the CP of the SR P2MP Policy corresponding to the P-tunnel on the ingress PE. This is necessary because packets are replicated in the PTI; therefore, it is not possible to have differing traffic engineering treatment towards each egress PE (Leaf node) of the PTI 🙈.

3.3.1. SR-MPLS 🧃

The PTA carried in Intra-AS I-PMSI A-D, Inter-AS I-PMSI A-D, S-PMSI A-D, and Leaf A-D routes is constructed as specified in [RFC7988] 💅.

MVPN IR service with SLA over SR-MPLS data plane can be provided by using the Color Extended Community as described above 🌈. Suppose an egress PE, say PE2, sends Leaf A-D route with Extended Color Community C1 with Color-Only Type 0 and IR label L10 to the ingress PE1. Assume the segment list of SR-TE policy (C1, PE2) at ingress PE1 is <L1, L2, L3>. PE1 will encapsulate the MVPN payload into the MPLS label stack <L1, L2, L3, L10> with L10 as the Bottom-of-Stack (BoS) label 👑.

3.3.2. SRv6 🌸

Okay bestie, MVPN IR over SRv6 is basically [RFC7988] with a glow-up 💅 The procedures from [RFC7988] are used here, with the modifications defined in this section, to provide MVPN IR service over SRv6.

The PTA riding along in Intra-AS I-PMSI A-D, Inter-AS I-PMSI A-D, Selective PMSI A-D, and Leaf A-D routes gets built the [RFC7988] way, with these tweaks ✨

  • Tunnel Type: "Ingress Replication" as per [RFC6514] 🦋
  • MPLS Label: the high-order 20 bits of this field carry the whole or a portion of the Function part of the SRv6 Multicast Service SID when the Transposition Scheme is used for encoding, as defined in [RFC9252]. When using the Transposition Scheme, the Transposition Length of the SRv6 SID Structure Sub-Sub-TLV of the SRv6 Prefix-SID attribute (see below) MUST be less than or equal to 20 and less than or equal to the Function Length. When the Transposition Scheme is not used, the MPLS Label field MUST be set to zero, and Transposition Length MUST be zero 🍓

Sections 6 and 7 of [RFC7988] describe considerations and procedures for allocating MPLS labels for IR P-tunnels. Those same considerations also apply to allocating an SRv6 Multicast Service SID for SRv6 IR 🧚

Now, how does an egress PE join an SRv6 IR P-tunnel? It's giving signaling energy 💖 The P-tunnel gets advertised in the PTA of Intra-AS I-PMSI A-D, Inter-AS I-PMSI A-D, or Selective S-PMSI A-D routes. The egress PE then builds a Leaf A-D or Intra-AS I-PMSI A-D route as described in [RFC7988], using the modified PTA from above. The egress PE MUST attach a BGP Prefix-SID attribute [RFC8669] with a Leaf A-D or Intra-AS I-PMSI A-D route, along with the SRv6 L3 Service TLV [RFC9252], to signal the SRv6 Multicast Service SID (Section 3.1). The SRv6 SID Information Sub-TLV carries the SRv6 Multicast Service SID in its SRv6 SID Value field. The SRv6 Endpoint behavior of the SRv6 SID Information Sub-TLV MUST encode one of the End.DTMC4, End.DTMC6, or End.DTMC46 code point values. The SRv6 SID Structure Sub-Sub-TLV encodes the structure of the SRv6 Multicast Service SID. If the Transposition Scheme is used, the offset and length of the SRv6 Multicast Endpoint function of the SRv6 Multicast Service SID get set in the Transposition Length and Transposition Offset fields of this sub-sub-TLV. Otherwise, the Transposition Length and Offset fields MUST be set to zero. The BGP Prefix SID attribute with the SRv6 L3 Service TLV in an Intra-AS I-PMSI or Leaf A-D route tells the ingress PE that the egress PE supports SRv6 ✨

The SRv6 Multicast Service SID MUST be routable within the AS of the egress PE. As per [RFC7988], the ingress PE uses the Tunnel Identifier of the PTA to figure out which unicast tunnel to use when sending data to the egress PE. For SRv6 IR, the ingress PE MUST use the SRv6 Multicast Service SID to determine the unicast tunnel to be used. For best-effort MVPN IR service, or SLA-based MVPN IR service using the IGP Flexible Algorithm, the ingress PE MUST encapsulate the payload in an outer IPv6 header, with the SRv6 Multicast Service SID provided by the egress PE used as the destination address. If the Transposition Scheme is used, the ingress PE MUST merge the Function part of the MPLS Label field of the PTA with the SRv6 SID in the SRv6 SID Information Sub-TLV, using the Transposition Offset and Length fields from the SRv6 SID Structure Sub-Sub-TLV, to create the SRv6 Multicast Service SID 🔥

MVPN IR service with SLA over SRv6 can be provided by using the Extended Color community, as described above. Picture this: an egress PE, say PE2, sends a Leaf A-D route with Extended Color community C1 with Color-Only Type 0 and SRv6 Multicast Service SID S10 to ingress PE1. Say the segment list of the SR-TE policy (C1, PE2) at ingress PE1 is <S1, S2, S3>. Then PE1 will encapsulate a payload into an IPv6 header with SRH (PE1, S1) (S10, S3, S2; SL=3) (payload) 👑

4. EVPN with SR 💜

BGP MPLS-Based EVPN, specified in [RFC7432], defines the IMET route to support BUM traffic. This IMET route is the equivalent of the MVPN Intra-AS I-PMSI route, and it is advertised with a PTA as specified in [RFC6514] to advertise the inclusive P-tunnels. [RFC9252] specifies procedures for IMET routes with IR over SRv6 🦋

[RFC9572] updates the EVPN BUM procedures to support selective P-tunnels. It defines new BGP route types that are advertised with a PTA, including the S-PMSI A-D and Leaf A-D routes. The S-PMSI and Leaf A-D routes of [RFC9572] are analogous to the MVPN S-PMSI and Leaf A-D routes in [RFC6514]. Note that support for Inter-AS and Inter-Region segmentation procedures in [RFC9572] with SR P2MP P-tunnels is out of scope for this document 🙈

Inclusive and selective P-tunnels can be instantiated using SR P2MP trees or IR over SR 🌈

4.1. EVPN with SR P2MP P-Tunnel

This section specifies modifications to the procedures of [RFC7432] and [RFC9572] for SR P2MP P-tunnels. The IMET, S-PMSI, and Leaf A-D routes carry a PTA that specifies the SR P2MP tree P-tunnel. In this section, the term "SR P2MP" refers to both the SR-MPLS and SRv6 data planes 🎀

4.1.1. PMSI Tunnel Attribute for SR P2MP P-Tunnel

A PTA for an SR P2MP P-tunnel is constructed as specified in Section 3.2.1, except that the MPLS Label and Flags fields are filled as specified in Sections 4.1.1.1 and 4.1.3, respectively 💅

4.1.1.1. MPLS Label

4.1.1.1.1. SR-MPLS

When an SR P2MP P-tunnel is not shared across MVPNs, i.e., there is a one-to-one association between an EVI and an SR P2MP P-tunnel, the MPLS Label field is set to zero as per [RFC6514]. In this case, the SR-MPLS Tree-SID of the PTI of the SR P2MP Policy advertised in the P-tunnel is enough to identify the MVPN instance for delivering the payload 🌸

[RFC7432] and [RFC9572] let a PE aggregate two or more EVIs onto one SR P2MP P-tunnel, by advertising the same P-tunnel in the PTA of A-D routes for different EVIs. When an SR P2MP P-tunnel is shared across two or more EVIs in an SR-MPLS domain, the MPLS Label field of a PTA advertised in an EVPN A-D route MUST contain an upstream-assigned MPLS label [RFC5331] [RFC6513], or a label assigned from a global context, such as DCB as specified in [RFC9573], that the advertising PE has bound to the EVI. The egress PE uses this label as context to identify the specific EVI for delivering the EVPN payload encapsulated in SR-MPLS. When an ingress PE steers the payload into a shared SR P2MP P-tunnel PTI, this MPLS label MUST be imposed before the MPLS label representing the Tree-SID 🧚

4.1.1.1.2. SRv6

For SRv6 P2MP, an EVI is identified by an SRv6 SID encoded in the SRH of an IPv6-encapsulated packet from the ingress PE, as described later in this section. This is required even if the SR P2MP P-tunnel is not shared across EVIs 🦋

The advertising ingress PE MUST attach a BGP Prefix-SID attribute [RFC8669] to IMET [RFC9252] or S-PMSI [RFC9572] A-D routes, with the SRv6 L2 Service TLV [RFC9252]. The SRv6 SID Information Sub-TLV carries the SID in its SRv6 SID Value field. The SRv6 Endpoint behavior of the SRv6 SID Information Sub-TLV SHOULD be END.DT2M [RFC8986], as per Section 6.3 of [RFC9252]. The SRv6 SID Structure Sub-Sub-TLV encodes the structure of the SID. If the Transposition Scheme is used, the offset and length of the SID are set in the Transposition Length and Transposition Offset fields of this sub-sub-TLV. Otherwise, the Transposition Length and Offset fields MUST be set to zero. The LOC of a SID, which is assigned from a global context such as DCB, is outside the scope of this document 🌈

The MPLS Label field of a PTA advertised in an A-D route MUST contain an upstream-assigned SRv6 SID that the advertising PE has bound to the EVI, or an SRv6 SID assigned from a global context. This follows the same concept as the DCB label specified in [RFC9573]. The high-order 20 bits of the MPLS Label field carry the whole or a portion of the Function part of the SRv6 SID when the Transposition Scheme of encoding, as defined in [RFC9252], is used. When using the Transposition Scheme, the Transposition Length of the SRv6 SID Structure Sub-Sub-TLV of the SRv6 Prefix-SID attribute MUST be less than or equal to 20 and less than or equal to the Function Length. When the Transposition Scheme is not used, the MPLS Label field MUST be set to zero as per [RFC6514], and Transposition Length MUST be zero 🍓

The advertising ingress PE, which is the Root node of the SR P2MP P-tunnel, MUST encapsulate a payload in an outer IPv6 header with an SRH in which the SRv6 SID (advertised in the BGP Prefix-SID attribute) MUST be the last segment in the segment list. Note that the SRv6 SID may be the only segment in the SRH. If the Transposition Scheme is used, the ingress PE MUST merge the Function part of the MPLS Label field of the PTA with the SRv6 SID in the SRv6 SID Information Sub-TLV, using the Transposition Offset and Length fields from the SRv6 SID Structure Sub-Sub-TLV, to create the SRv6 SID. When ESI-based split-horizon filtering is used, the Arg.FE2 (see Section 4.1.2.2) SHOULD be merged with the SRv6 SID by doing a bitwise logical OR operation, to create the complete SRv6 SID encoded in the SRH on the ingress PE 👑

An egress PE of the SR P2MP P-tunnel uses the SRv6 SID in the SRH to determine the EVI in which the customer payload is to be delivered. The egress PE, in the role of Leaf or Bud node of the Replication segment associated with the SR P2MP P-tunnel tree, uses the "look at next SID in SRH" [RFC9524] behavior to process the SRv6 SID. An egress PE MUST NOT install the SRv6 SID in its FIB, i.e., it MUST NOT forward packets based on the Locator portion of the SRv6 SID. The Arg.FE2 of the SID, if present, is used for ESI-based split-horizon filtering as specified in Section 4.1.2.2 🫶

4.1.2. Split-Horizon Filtering for ES Multihoming

EVPN requires split-horizon filtering with ES multihoming in order to prevent duplicate BUM traffic, as described in Section 8.3 of [RFC7432]. This section describes split-horizon filtering procedures with SR P2MP P-tunnels 💖

4.1.2.1. SR-MPLS Filtering

The split-horizon procedures specified for P2MP MPLS Label Switched Paths (LSPs) in Section 8.3.1.2 of [RFC7432] are sufficient for SR P2MP P-tunnels. Note that for shared SR P2MP P-tunnels, the ESI label is at the bottom of the label stack, followed by an EVI context label, and finally the Tree-SID label of the PTI associated with the P-tunnel at the top in SR-MPLS encapsulation ✨

4.1.2.2. SRv6 Filtering

For SRv6, the Arg.FE2 argument of the END.DT2M SRv6 Endpoint behavior [RFC8986] is used for ESI-based split-horizon filtering. For an SR P2MP P-tunnel, the Arg.FE2 SID argument is an upstream-assigned value, assigned by an ingress PE, that identifies an ES of origin. This SID Argument is analogous to the upstream-assigned ESI MPLS label specified in Section 8.3 of [RFC7432]. The Arg.FE2 is signaled in the ESI Label field of the ESI Label extended community [RFC7432], and in a BGP Prefix-SID attribute with an Ethernet A-D per ES route, as specified in Section 6.1.1 of [RFC9252] and expanded further in [RFC9819] 🎀

The advertised Arg.FE2 is encoded with the SRv6 SID in the SRH by the ingress PE, as described in Section 4.1.1.1.2. The egress PE uses the Arg.FE2 of the SRv6 SID, if present, to perform ESI-based split-horizon filtering, as specified for the END.DT2M forwarding behavior in Section 4.12 of [RFC8986] 🦋

4.1.3. Auto-Discovery Procedures ✨

okay so the EVPN A-D procedures from [RFC7432] and [RFC9572] are how we advertise an SR P2MP P-tunnel and figure out who the Leaf nodes of the SR P2MP Policy tied to it are 💖. This section explains how A-D routes get used to create, update, and tear down an SR P2MP Policy of an SR P2MP P-tunnel, as described in Section 2 🦋.

4.1.3.1. Creation of CP of SR P2MP Policy 🎀

A PE talks to the SR P2MP Policy module to create a CP for an SR P2MP Policy whenever it originates an IMET A-D route [RFC7432] or an S-PMSI A-D route [RFC9572] carrying a PTA with an SR P2MP P-tunnel type ✨. The CP can come with optional traffic engineering constraints and an optional optimization objective, so it's totally customizable 💅.

The CP of the SR P2MP Policy tied to an SR P2MP P-tunnel gets deleted from the SR P2MP Policy module when a PE withdraws the IMET or S-PMSI A-D route that advertised that P-tunnel 🌸.

When a PE originates an S-PMSI A-D route with a PTA that has an SR P2MP P-tunnel type, it MUST set the "Leaf Information Required" flag in the PTA 🚩. That flag is non-negotiable, bestie 😭.

4.1.3.2. Discovery of Leaf Nodes 🌸

An ingress PE that advertises an EVPN A-D route with a PTA of SR P2MP P-tunnel type discovers a Leaf node of the SR P2MP Policy tied to that P-tunnel when it imports an IMET A-D route [RFC7432] or a Leaf A-D route [RFC9572] from an egress PE 🧚. The ingress PE then adds that egress PE as a Leaf node in the SR P2MP Policy module.

An ingress PE removes an egress PE from the Leaf set of the SR P2MP Policy when that egress PE withdraws its IMET A-D or Leaf A-D route 👋.

An egress PE tells the SR P2MP Policy module to join the SR P2MP Policy as a Leaf or Bud node when it imports an IMET A-D route or an S-PMSI A-D route from an ingress PE whose PTA has an SR P2MP P-tunnel type 📣. The egress PE MUST originate a Leaf A-D route if the "Leaf Information Required" flag is set in the PTA 🔥.

An egress PE withdraws itself as a Leaf or Bud node of the SR P2MP Policy when the ingress PE withdraws an IMET or an S-PMSI A-D route 💔. The egress PE MUST withdraw the Leaf A-D it had originated earlier in response to the "Leaf Information Required" flag in the PTA 💅.

4.2. EVPN with Ingress Replication over SR 🧚

A PE can give you EVPN service using IR over SR 🌈. The EVPN payload gets encapsulated in SR-MPLS or SRv6 at an ingress PE, and each copy is replicated and sent to an egress PE via unicast. IR procedures for MPLS are specified for the IMET A-D route in [RFC7432] and the SMET A-D route in [RFC9251]. Procedures for EVPN IR over SRv6 for the IMET A-D route are specified in [RFC9252]. These procedures give you an EVPN IR service with best-effort unicast connectivity 🫶.

This document adds procedures for an EVPN IR service with an SLA from an ingress PE to an egress PE, for both SR-MPLS and SRv6 ✨. It extends the BGP Update message of AFI/SAFI 25/70 (L2VPN-EVPN) to carry the Color Extended Community as specified in [RFC9012] and the Color-Only Type extension specified in Section 3 of [RFC9830] 🎀. An egress PE colors the IMET with a Color Extended Community. The ingress PE replicates the EVPN customer payload to the egress PE by steering it into an SR-TE policy according to Section 8 of [RFC9256]. The ingress PE then encapsulates the payload packet into a segment list of the matching SR-TE policy to the egress PE, along with the IR MPLS label or the End.DT2M SID received from the egress PE 💜.

Heads up, bestie: the Color Extended Community is not used with an EVPN SR P2MP P-tunnel 🙈. For EVPN with an SR P2MP P-tunnel, the ingress PE decides the traffic engineering treatment by setting the constraints and the metric optimization in the CP of the SR P2MP Policy that goes with the P-tunnel on the ingress PE. This is needed because packets get replicated in the PTI, so it isn't possible to have differing traffic engineering treatment toward each egress PE (Leaf node) of the PTI 💀.

4.2.1. SR-MPLS 💜

EVPN IR procedures for MPLS specified in [RFC7432] and [RFC9251] can be extended for EVPN IR over SR-MPLS 🌸.

An EVPN IR service with an SLA over the SR-MPLS data plane can be provided by using the Color Extended Community described above ✨. Let's say an egress PE, PE2, sends an IMET A-D route with Extended Color Community C1 with Color-Only Type 0 and EVPN BUM label L10 to ingress PE1 💖. Assume the segment list of SR-TE policy (C1, PE2) at ingress PE1 is <L1, L2, L3>. PE1 will encapsulate the MVPN payload into the MPLS label stack <L1, L2, L3, L10>, with L10 as the BoS label 🦋. Note that the MPLS label stack may have the ESI label at the bottom of the label stack if ESI-based split-horizon filtering is used 🎀.

4.2.2. SRv6 🌊

EVPN IR procedures for SRv6 are specified in Section 6.3 of [RFC9252] for the IMET A-D route 🧜.

A PE can provide EVPN IR service with an SLA over SRv6 using the Color Extended Community described above 💅. Say an egress PE, PE2, sends an IMET A-D route with Extended Color community C1 with Color-Only Type 0 and SRv6 End.DT2M SID S10 to ingress PE1 🫶. Assume the segment list of the SR-TE policy (C1, PE2) at ingress PE1 is <S1, S2, S3>. PE1 will encapsulate a payload into an IPv6 header with SRH (PE1, S1) (S10, S3, S2; SL=3) (payload). Note that the End.DT2M SID S10 may also have an Arg.FE2 Argument if ESI-based split-horizon filtering is used 🔥.

5. IANA Considerations 🌷

IANA has assigned the following values in the "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types" registry [RFC7385] within the "Border Gateway Protocol (BGP) Parameters" registry group <https://www.iana.org/assignments/bgp-parameters> 🍓.

                 +=======+===================+===========+
                 | Value | Meaning           | Reference |
                 +=======+===================+===========+
                 | 0x0C  | SR-MPLS P2MP Tree | RFC 10018 |
                 +-------+-------------------+-----------+
                 | 0x0D  | SRv6 P2MP Tree    | RFC 10018 |
                 +-------+-------------------+-----------+

                         Table 1: PMSI Tunnel Types

IANA has allocated the following code points in the "SRv6 Endpoint Behaviors" registry [RFC8986] within the "Segment Routing" registry group <https://www.iana.org/assignments/segment-routing> ✨.

      +=======+========+===================+===========+============+
      | Value |  Hex   | Endpoint Behavior | Reference |   Change   |
      |       |        |                   |           | Controller |
      +=======+========+===================+===========+============+
      | 76    | 0x004C |     End.DTMC4     | RFC 10018 |    IETF    |
      +-------+--------+-------------------+-----------+------------+
      | 77    | 0x004D |     End.DTMC6     | RFC 10018 |    IETF    |
      +-------+--------+-------------------+-----------+------------+
      | 78    | 0x004E |     End.DTMC46    | RFC 10018 |    IETF    |
      +-------+--------+-------------------+-----------+------------+

                      Table 2: SRv6 Endpoint Behaviors

6. Security Considerations 🛡️

okay, security time, and I'm not playing 😭. The procedures in this document do not introduce any additional security considerations beyond those mentioned in [RFC6513], [RFC6514], [RFC7432], and [RFC9572]. For general security considerations for SR P2MP Policy and Replication segments, go check out [RFC9960] and [RFC9524], respectively 🔐.

7. References 📚

7.1. Normative References ✨

okay bestie, these are the big foundational docs the whole spec leans on 🧚

7.2. Informative References ✨

these ones are more background reading vibes, still super useful 📚

Acknowledgements 🌸

big thank you to Luc André Burdet 🫶 the authors would like to acknowledge them for reviewing the document 💖

Contributors 🎀

these lovely people helped build this one, and they're all iconic 👑

Zafar Ali Cisco Systems, Inc. United States of America Email: zali@cisco.com

Arvind Venkateswaran Cisco Systems, Inc. United States of America Email: arvvenka@cisco.com

Jayant Kotalwar Nokia Mountain View, CA United States of America Email: jayant.kotalwar@nokia.com

Tanmoy Kundu Nokia Mountain View, CA United States of America Email: tanmoy.kundu@nokia.com

Clayton Hassen Bell Vancouver Canada Email: clayton.hassen@bell.ca

Mankamana Mishra Cisco Systems, Inc. United States of America Email: mankamis@cisco.com

Authors' Addresses 💜

and here are the authors, the real main characters 🦋

Rishabh Parekh (editor) Arrcus United States of America Email: rishabh@arrcus.com

Daniel Voyer (editor) Cisco Systems, Inc. Montreal Canada Email: davoyer@cisco.com

Clarence Filsfils Cisco Systems, Inc. Brussels Belgium Email: cfilsfil@cisco.com

Hooman Bidgoli Nokia Ottawa Canada Email: hooman.bidgoli@nokia.com

Zhaohui Zhang Juniper Networks Email: zzhang@juniper.net

📦 where this page comes from