Multicast and Ethernet VPN with Segment Routing Point-to-Multipoint (P2MP) and Ingress ReplicationArrcusUnited States of Americarishabh@arrcus.comCisco Systems, Inc.MontrealCanadadavoyer@cisco.comCisco Systems, Inc.BrusselsBelgiumcfilsfil@cisco.comNokiaOttawaCanadahooman.bidgoli@nokia.comJuniper Networkszzhang@juniper.net
RTG
bessA Point-to-Multipoint (P2MP) tree in a Segment Routing (SR) domain carries
traffic from a Root to a set of Leaves. This document 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. This document updates RFCs 6514 and 7988.Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
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
() 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
. Introduction
. Terminology
. Requirements Language
. SR P2MP P-Tunnel
. MVPN with SR
. SRv6 Multicast Endpoint Behaviors
. End.DTMC4: Decapsulation and Specific IPv4 Multicast Table Lookup
. End.DTMC6: Decapsulation and Specific IPv6 Multicast Table Lookup
. End.DTMC46: Decapsulation and Specific IP Multicast Table Lookup
. MVPN with SR P2MP P-Tunnel
. PMSI Tunnel Attribute for SR P2MP P-Tunnel
. Auto-Discovery Procedures
. MVPN with Ingress Replication over SR
. SR-MPLS
. SRv6
. EVPN with SR
. EVPN with SR P2MP P-Tunnel
. PMSI Tunnel Attribute for SR P2MP P-Tunnel
. Split-Horizon Filtering for ES Multihoming
. Auto-Discovery Procedures
. EVPN with Ingress Replication over SR
. SR-MPLS
. SRv6
. IANA Considerations
. Security Considerations
. References
. Normative References
. Informative References
Acknowledgements
Contributors
Authors' Addresses
Introduction"Multicast in MPLS/BGP IP VPNs" and "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs" specify procedures that allow a network operator to
provide Multicast VPN (MVPN) service to its customers. Multicast traffic
from a customer is tunneled across the service provider network over
Provider Tunnels (P-tunnels). P-tunnels can be instantiated using
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 or SR P2MP Ingress Replication
(IR) to instantiate P-tunnels for MVPN. This document refers to a
P-tunnel realized by an SR P2MP Policy as an SR P2MP P-tunnel. SR P2MP
P-tunnels can be instantiated for both Segment Routing over MPLS (SR-MPLS)
and Segment Routing over IPv6 (SRv6) .An SR P2MP tree is defined by an SR P2MP Policy 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 BGP auto-discovery procedures
specified in 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 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 used for MVPN with SR P2MP and IR P-tunnels.For BGP MPLS-Based EVPN specified in and updated in , 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 and for MVPN procedures. For EVPN procedures, refer to .Scalability, operational, and troubleshooting considerations for SR
P2MP trees and Replication segments are described in and ,
respectively. Operations, Administration, and Maintenance (OAM) ping and
traceroute procedures for SR P2MP Policy using the SR-MPLS data plane are
specified in .TerminologyThe following terms are used as defined in :
Segment Routing (SR)
Segment Identifier (SID)
SR domain
SR-MPLS
SRv6
SRv6 SID
The following term is used as defined in :
Segment Routing Header (SRH)
The following terms are used as defined in :
Replication segment
Replication-SID
Root node
Leaf node
Bud node
Intermediate Replication node
The following terms are used as defined in :
SR P2MP Policy
Tree-ID
Candidate path (CP)
P2MP tree instance (PTI)
Tree-SID
For MVPN, the following terms are used as defined in and :
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, the following terms are used as defined in , , and :
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
Requirements LanguageThe 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 when, and only when, they
appear in all capitals, as shown here.
SR P2MP P-TunnelFor MVPN or EVPN, Provider Edge (PE) routers can steer customer traffic into a P-tunnel realized by an SR-MPLS or SRv6 PTI. An SR PTI is instantiated by a CP of an SR P2MP Policy . A P-tunnel is
signaled in MVPN or EVPN A-D routes using the BGP PMSI Tunnel Attribute
(PTA) . The PTA identifies the P-tunnel that is
used to instantiate a PMSI.MVPN/EVPN Interaction with SR P2MP Policy
+---------------------------------+
| INGRESS PE | +------------+
| +----------+ +----------+ | | |
| | | | SR P2MP | | PCEP/BGP/etc. | |
| | MVPN/EVPN+---->| Policy | +------------------>| CONTROLLER |
| | Module | | Module | | | |
| +----------+ +----------+ | | |
| | +------------+
+---------------------------------+The figure above shows the interaction between the conceptual MVPN or
EVPN module and SR P2MP Policy module on an ingress PE. The ingress PE
participates in MVPN or EVPN AD procedures and interacts with the SR
P2MP Policy module as shown above to create and update the SR P2MP
Policy, CP, and the Leaf set of SR P2MP policies. The SR P2MP
Policy module interacts with a controller using protocols such as the Path Computation Element Communication Protocol (PCEP)
, BGP, the Network Configuration Protocol (NETCONF), etc., which
are outside the scope of this document.An ingress PE creates a CP of an SR P2MP Policy in the SR P2MP Policy
module upon provisioning of the MVPN or EVPN module for the SR P2MP
P-tunnel or based on events or policy, such as mapping MVPN or EVPN
flow to a new SR P2MP P-tunnel. This CP can have optional traffic
engineering constraints and/or an optimization objective by provisioning or
by a local policy. The SR P2MP Policy module signals the CP along with
the constraints and optimization objective to the controller using one of the
protocols mentioned above. The ingress PE deletes the CP of the SR P2MP
Policy from the SR P2MP Policy module when the SR P2MP P-tunnel is not
longer required. The SR P2MP Policy module signals deletion of the CP of
the SR P2MP Policy 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. The SR P2MP Policy module signals the
updated Leaf set to the controller using one of the protocols mentioned
above.An egress PE associates an MVPN or EVPN A-D route with an MVPN or EVPN
context and informs 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 by stitching Replication segments
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 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 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.MVPN with SRMVPN service can be provided using SR P2MP trees or IR over either an SR-MPLS
or SRv6 data plane.SRv6 Multicast Endpoint BehaviorsThe following SRv6 Endpoint behaviors can be associated with the
SRv6 Multicast Service SID used for MVPN with SR P2MP and IR
P-tunnels.End.DTMC4: Decapsulation and Specific IPv4 Multicast Table LookupThe "Endpoint with Decapsulation and IPv4 Multicast Table Lookup" behavior (End.DTMC4 for short)
is functionally identical to the
End.DT4 behavior specified in , 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.End.DTMC6: Decapsulation and Specific IPv6 Multicast Table LookupThe "Endpoint with Decapsulation and IPv6 Multicast Table Lookup"
behavior (End.DTMC6 for short) is functionally identical to
the End.DT6 behavior specified in , 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.End.DTMC46: Decapsulation and Specific IP Multicast Table LookupThe "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 , 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.MVPN with SR P2MP P-Tunnel 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.PMSI Tunnel Attribute for SR P2MP P-TunnelA 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 for use
of the "Leaf Information Required" flag.
MPLS Label: See .
Tunnel Identifier: The SR P2MP P-tunnel identifies an SR
P2MP Policy with the identifier <Root, Tree-ID> 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
). When a P-tunnel is non-segmented, the PTA
is created by 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.MPLS LabelWhen an SR P2MP P-tunnel is not shared across MVPNs, i.e., there
is one-to-one association between an MVPN instance and an SR P2MP
P-tunnel, the MPLS Label field is set to zero as per 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. allows a PE to aggregate two or more
MVPNs onto one SR P2MP P-tunnel by advertising the same P-tunnel
in 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 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.SR-MPLSWhen 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
or a label
assigned from a global context, such as the Domain-wide Common
Block (DCB) as specified in , 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 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.SRv6When an SR P2MP P-tunnel is shared across two or more MVPNs
in an SRv6 domain , the MPLS Label
field of a PTA advertised in an A-D route MUST contain an
upstream-assigned SRv6 Multicast Service SID () that the advertising PE has bound to
the MVPN or an SRv6 Multicast Service SID assigned from a global
context; this follows same concept of the DCB label as specified in . 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 as defined in is used. 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 as per , and Transposition Length
MUST be zero.The advertising ingress PE MUST attach a BGP Prefix-SID
attribute to Intra-AS I-PMSI, Inter-AS
I-PMSI, or S-PMSI A-D routes with the SRv6 L3 Service TLV 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 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.Auto-Discovery ProceduresMVPN A-D procedures specified in 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 .Creation of CP of SR P2MP PolicyA 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 , an Inter-AS I-PMSI
A-D route for an intra-AS segment , an
S-PMSI A-D route , or a "wildcard" S-PMSI
A-D route 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.Discovery of Leaf NodesAn 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 or Leaf A-D route 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.MVPN with Ingress Replication over SRA 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" 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
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 and the Color-Only Type extension
specified in . 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
. 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.SR-MPLSThe 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 .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.SRv6The procedures specified in , with the
modifications defined in this section, are used to provide MVPN IR
service over SRv6.The PTA carried in Intra-AS I-PMSI A-D, Inter-AS I-PMSI A-D,
Selective PMSI A-D, and Leaf A-D routes is constructed as specified
in with the following modifications:
Tunnel Type: "Ingress Replication" as per .
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 .
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 and of describe
considerations and procedures for allocating MPLS labels for IR
P-tunnels. These considerations also apply to allocation of a SRv6
Multicast Service SID for SRv6 IR.To join an SRv6 IR P-tunnel advertised in the PTA of Intra-AS I-PMSI
A-D, Inter-AS I-PMSI A-D, or Selective S-PMSI A-D routes, an egress
PE constructs a Leaf A-D or Intra-AS I-PMSI A-D route as described
in with the modified PTA above. The egress PE
MUST attach a BGP Prefix-SID attribute with
a Leaf A-D or Intra-AS I-PMSI A-D route with the SRv6 L3 Service TLV
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 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 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 BGP Prefix SID attribute with the SRv6 L3
Service TLV in an Intra-AS I-PMSI or Leaf A-D route indicates to 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 , the ingress PE uses
the Tunnel Identifier of PTA to determine the unicast tunnel to use
in order to send 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 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
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 SRv6 Multicast Service 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).EVPN with SRBGP MPLS-Based EVPN, specified in , specifies
the IMET route to support BUM traffic. This IMET route is the equivalent of the
MVPN Intra-AS I-PMSI route and is advertised with a PTA as specified in to advertise
the inclusive P-tunnels. specifies procedures
for IMET routes with IR over SRv6. 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 are analogous to MVPN S-PMSI
and Leaf A-D routes . Note that support of Inter-AS
and Inter-Region segmentation procedures in
with SR P2MP P-tunnels are out of scope of this document.Inclusive and selective P-tunnels can be instantiated using SR P2MP
trees or IR over SR.EVPN with SR P2MP P-TunnelThis section specifies modifications to procedures of and for SR P2MP P-tunnels.
The IMET, S-PMSI, and Leaf 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.PMSI Tunnel Attribute for SR P2MP P-TunnelA PTA for an SR P2MP P-tunnel is constructed as specified in
, except the MPLS Label and Flags fields are
filled as specified in Sections and , respectively.MPLS LabelSR-MPLSWhen an SR P2MP P-tunnel is not shared across MVPNs, i.e., there
is one-to-one association between an EVI and an SR P2MP P-tunnel,
the MPLS Label field is set to zero as per . In this case, the SR-MPLS 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. and allow
a PE to aggregate two or more EVIs onto one SR P2MP P-tunnel by
advertising the same P-tunnel in the PTA of A-D routes of 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 or a
label assigned from a global context, such as DCB as specified in , 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.SRv6For 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 to IMET or S-PMSI A-D routes
with the SRv6 L2 Service TLV . The SRv6 SID
Information Sub-TLV carries the SID in the SRv6 SID Value field. The
SRv6 Endpoint behavior of the SRv6 SID Information Sub-TLV
SHOULD be END.DT2M as per
. The SRv6 SID Structure Sub-Sub-TLV
encodes the structure of SID. If the Transposition Scheme is used,
the offset and length of the 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 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 same concept of the DCB label as specified in . 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 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 , 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 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 ) 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 role of Leaf or Bud node of the
Replication segment associated with the SR P2MP P-tunnel tree, uses
"look at next SID in SRH" 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 .Split-Horizon Filtering for ES MultihomingEVPN requires split-horizon filtering with ES multihoming in
order to prevent duplicate BUM traffic as described in
. This section describes split-horizon
filtering procedures with SR P2MP P-tunnels.SR-MPLS FilteringThe split-horizon procedures specified for P2MP MPLS Label Switched Paths (LSPs) in
are sufficient for SR
P2MP P-tunnels. Note 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 P-tunnel
at the top in SR-MPLS encapsulation.SRv6 FilteringFor SRv6, the Arg.FE2 argument of End.DT2M SRv6 Endpoint behavior
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 and identifies
an ES of origin. This SID Argument is analogous to the
upstream-assigned ESI MPLS label specified in . The Arg.FE2 is signaled in the ESI Label field of
the ESI Label extended community and a
BGP Prefix-SID attribute with an Ethernet A-D per ES route as
specified in and
expanded further in .The advertised Arg.FE2 is encoded with the SRv6 SID in the SRH by the
ingress PE as described in . 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 .Auto-Discovery ProceduresEVPN A-D procedures specified in and 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 EVPN A-D routes to create, update, and tear down an SR
P2MP Policy of an SR P2MP P-tunnel as described in .Creation of CP of SR P2MP PolicyA 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 IMET A-D
route or an S-PMSI A-D route , 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
IMET or S-PMSI A-D route advertising 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.Discovery of Leaf NodesAn ingress PE that advertises an EVPN 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 IMET A-D
route or Leaf A-D route 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 IMET A-D 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 IMET 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 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.EVPN with Ingress Replication over SRA PE can provide EVPN service using IR over SR. The EVPN payload is
encapsulated in SR-MPLS or SRv6 at an ingress PE and replicated with
each copy sent to an egress PE via unicast. IR procedures for MPLS are
specified for the IMET A-D route in and the SMET A-D
route in . Procedures for EVPN IR over SRv6
for the IMET A-D route are specified in . These
procedures provide an EVPN IR service with best-effort unicast
connectivity.This document adds procedures for providing an EVPN 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 25/70
(L2VPN-EVPN) to carry the Color Extended Community as specified in
and the Color-Only Type extension specified in
. An egress PE colors the IMET
with a Color Extended Community. The ingress PE replicates EVPN
customer payload to the egress PE by steering it into an SR-TE policy
according to . The ingress PE
encapsulates the payload packet into a segment list of the matching
SR-TE policy to the egress PE along with IR MPLS label or SRv6
End.DT2M SID received from the egress PE.Note that 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 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.SR-MPLSEVPN IR procedures for MPLS specified in
and can be extended for EVPN IR over
SR-MPLS.EVPN IR service with an 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 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.SRv6EVPN IR procedures for SRv6 are specified in for the IMET A-D route.A PE can provide EVPN IR service with SLA over SRv6 using the
Color Extended Community as described above. Suppose an egress PE,
say 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.IANA ConsiderationsIANA has assigned the following values in the "P-Multicast Service
Interface Tunnel (PMSI Tunnel) Tunnel Types" registry within the "Border Gateway Protocol
(BGP) Parameters" registry group .
PMSI Tunnel Types
Value
Meaning
Reference
0x0C
SR-MPLS P2MP Tree
RFC 10018
0x0D
SRv6 P2MP Tree
RFC 10018
IANA has allocated the following code points in the "SRv6 Endpoint
Behaviors" registry within the
"Segment Routing" registry group .
SRv6 Endpoint Behaviors
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
Security ConsiderationsThe procedures in this document do not introduce any additional
security considerations beyond those mentioned in , , ,
and . For general security considerations
applicable to SR P2MP Policy and Replication segments, please refer to
and , respectively.ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Multicast in MPLS/BGP IP VPNsIn order for IP multicast traffic within a BGP/MPLS IP VPN (Virtual Private Network) to travel from one VPN site to another, special protocols and procedures must be implemented by the VPN Service Provider. These protocols and procedures are specified in this document. [STANDARDS-TRACK]BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNsThis document describes the BGP encodings and procedures for exchanging the information elements required by Multicast in MPLS/BGP IP VPNs, as specified in RFC 6513. [STANDARDS-TRACK]Wildcards in Multicast VPN Auto-Discovery RoutesIn Multicast Virtual Private Networks (MVPNs), customer multicast flows are carried in "tunnels" through a service provider's network. The base specifications for MVPN define BGP multicast VPN "auto-discovery routes" and specify how to use an auto-discovery route to advertise the fact that an individual customer multicast flow is being carried in a particular tunnel. However, those specifications do not provide a way to specify, in a single such route, that multiple customer flows are being carried in a single tunnel. Those specifications also do not provide a way to advertise that a particular tunnel is to be used by default to carry all customer flows, except in the case where that tunnel is joined by all the provider edge routers of the MVPN. This document eliminates these restrictions by specifying the use of "wildcard" elements in the customer flow identifiers. With wildcard elements, a single auto-discovery route can refer to multiple customer flows or even to all customer flows. [STANDARDS-TRACK]IANA Registry for P-Multicast Service Interface (PMSI) Tunnel Type Code PointsRFC 6514 created a space of Tunnel Type code points for a new BGP attribute called the "P-Multicast Service Interface Tunnel (PMSI Tunnel) attribute". However, the RFC did not create a corresponding IANA registry.There now is need to make further code point allocations from this name space. This document serves to update RFC 6514 in that it creates an IANA registry for that purpose.BGP MPLS-Based Ethernet VPNThis document describes procedures for BGP MPLS-based Ethernet VPNs (EVPN). The procedures described here meet the requirements specified in RFC 7209 -- "Requirements for Ethernet VPN (EVPN)".Ingress Replication Tunnels in Multicast VPNRFCs 6513, 6514, and other RFCs describe procedures by which a Service Provider may offer Multicast VPN (MVPN) service to its customers. These procedures create point-to-multipoint (P2MP) or multipoint-to-multipoint (MP2MP) trees across the Service Provider's backbone. One type of P2MP tree that may be used is known as an "Ingress Replication (IR) tunnel". In an IR tunnel, a parent node need not be directly connected to its child nodes. When a parent node has to send a multicast data packet to its n child nodes, it does not use Layer 2 multicast, IP multicast, or MPLS multicast to do so. Rather, it makes n individual copies, and then unicasts each copy, through an IP or MPLS unicast tunnel, to exactly one child node. While the prior MVPN specifications allow the use of IR tunnels, those specifications are not always very clear or explicit about how the MVPN protocol elements and procedures are applied to IR tunnels. This document updates RFCs 6513 and 6514 by adding additional details that are specific to the use of IR tunnels.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Segment Routing ArchitectureSegment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain.SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack.SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header.Segment Routing with the MPLS Data PlaneSegment Routing (SR) leverages the source-routing paradigm. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. In the MPLS data plane, the SR header is instantiated through a label stack. This document specifies the forwarding behavior to allow instantiating SR over the MPLS data plane (SR-MPLS).Segment Routing Prefix Segment Identifier Extensions for BGPSegment Routing (SR) leverages the source-routing paradigm. A node steers a packet through an ordered list of instructions called "segments". A segment can represent any instruction, topological or service based. The ingress node prepends an SR header to a packet containing a set of segment identifiers (SIDs). Each SID represents a topological or service-based instruction. Per-flow state is maintained only on the ingress node of the SR domain. An "SR domain" is defined as a single administrative domain for global SID assignment.This document defines an optional, transitive BGP attribute for announcing information about BGP Prefix Segment Identifiers (BGP Prefix-SIDs) and the specification for SR-MPLS SIDs.IPv6 Segment Routing Header (SRH)Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH). This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable.Segment Routing over IPv6 (SRv6) Network ProgrammingThe Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header.Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet.This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization.The BGP Tunnel Encapsulation AttributeThis document defines a BGP path attribute known as the "Tunnel Encapsulation attribute", which can be used with BGP UPDATEs of various Subsequent Address Family Identifiers (SAFIs) to provide information needed to create tunnels and their corresponding encapsulation headers. It provides encodings for a number of tunnel types, along with procedures for choosing between alternate tunnels and routing packets into tunnels.This document obsoletes RFC 5512, which provided an earlier definition of the Tunnel Encapsulation attribute. RFC 5512 was never deployed in production. Since RFC 5566 relies on RFC 5512, it is likewise obsoleted. This document updates RFC 5640 by indicating that the Load-Balancing Block sub-TLV may be included in any Tunnel Encapsulation attribute where load balancing is desired.BGP Overlay Services Based on Segment Routing over IPv6 (SRv6)This document defines procedures and messages for SRv6-based BGP services, including Layer 3 Virtual Private Network (L3VPN), Ethernet VPN (EVPN), and Internet services. It builds on "BGP/MPLS IP Virtual Private Networks (VPNs)" (RFC 4364) and "BGP MPLS-Based Ethernet VPN" (RFC 7432).Segment Routing Replication for Multipoint Service DeliveryThis document describes the Segment Routing Replication segment for multipoint service delivery. A Replication segment allows a packet to be replicated from a replication node to downstream nodes.Updates to EVPN Broadcast, Unknown Unicast, or Multicast (BUM) ProceduresThis document specifies updated procedures for handling Broadcast, Unknown Unicast, or Multicast (BUM) traffic in Ethernet VPNs (EVPNs), including selective multicast and segmentation of provider tunnels. This document updates RFC 7432.Argument Signaling for BGP Services in Segment Routing over IPv6 (SRv6)RFC 9252 defines procedures and messages for BGP overlay services for Segment Routing over IPv6 (SRv6), including Layer 3 Virtual Private Network (L3VPN), Ethernet VPN (EVPN), and global Internet routing. This document updates RFC 9252 and provides more detailed specifications for the signaling and processing of SRv6 Segment Identifier advertisements for BGP overlay service routes associated with SRv6 Endpoint Behaviors that support arguments.Segment Routing Point-to-Multipoint PolicyThe Point-to-Multipoint (P2MP) Policy enables creation of P2MP trees for efficient multipoint packet delivery in a Segment Routing (SR) domain. This document specifies the architecture, signaling, and procedures for SR P2MP Policies with Segment Routing over MPLS (SR-MPLS) and Segment Routing over IPv6 (SRv6). It defines the SR P2MP Policy construct, candidate paths (CPs) of an SR P2MP Policy, and the instantiation of the P2MP tree instances (PTIs) of a CP using Replication segments. Additionally, it describes the required extensions for a controller to support P2MP path computation and provisioning. This document updates RFC 9524.Informative ReferencesMPLS Upstream Label Assignment and Context-Specific Label SpaceRFC 3031 limits the MPLS architecture to downstream-assigned MPLS labels. This document introduces the notion of upstream-assigned MPLS labels. It describes the procedures for upstream MPLS label assignment and introduces the concept of a "Context-Specific Label Space". [STANDARDS-TRACK]Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Proxies for Ethernet VPN (EVPN)This document describes how to support endpoints running the Internet Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD) efficiently for the multicast services over an Ethernet VPN (EVPN) network by incorporating IGMP/MLD Proxy procedures on EVPN Provider Edges (PEs).Segment Routing Policy ArchitectureSegment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy.This document updates RFC 8402 as it details the concepts of SR Policy and steering into an SR Policy.MVPN/EVPN Tunnel Aggregation with Common LabelsThe Multicast VPN (MVPN) specifications allow a single Point-to-Multipoint (P2MP) tunnel to carry traffic of multiple IP VPNs (referred to as VPNs in this document). The EVPN specifications allow a single P2MP tunnel to carry traffic of multiple Broadcast Domains (BDs). These features require the ingress router of the P2MP tunnel to allocate an upstream-assigned MPLS label for each VPN or for each BD. A packet sent on a P2MP tunnel then carries the label that is mapped to its VPN or BD (in some cases, a distinct upstream-assigned label is needed for each flow.) Since each ingress router allocates labels independently, with no coordination among the ingress routers, the egress routers may need to keep track of a large number of labels. The number of labels may need to be as large as, or larger than, the product of the number of ingress routers times the number of VPNs or BDs. However, the number of labels can be greatly reduced if the association between a label and a VPN or BD is made by provisioning, so that all ingress routers assign the same label to a particular VPN or BD. New procedures are needed in order to take advantage of such provisioned labels. These new procedures also apply to Multipoint-to-Multipoint (MP2MP) tunnels. This document updates RFCs 6514, 7432, and 7582 by specifying the necessary procedures.Advertising Segment Routing Policies in BGPA Segment Routing (SR) Policy is an ordered list of segments (also referred to as "instructions") that define a source-routed policy. An SR Policy consists of one or more Candidate Paths (CPs), each comprising one or more segment lists. A headend can be provisioned with these CPs using various mechanisms such as Command-Line Interface (CLI), Network Configuration Protocol (NETCONF), Path Computation Element Communication Protocol (PCEP), or BGP.This document specifies how BGP can be used to distribute SR Policy CPs. It introduces a BGP SAFI for advertising a CP of an SR Policy and defines sub-TLVs for the Tunnel Encapsulation Attribute to signal information related to these CPs.Furthermore, this document updates RFC 9012 by extending the Color Extended Community to support additional steering modes over SR Policy.MPLS Segment Routing Point-to-Multipoint (P2MP) Policy PingSegment Routing (SR) Point-to-Multipoint (P2MP) Policies are used to define and manage explicit P2MP paths within a network. These policies are typically calculated via a controller-based mechanism and installed via, e.g., a Path Computation Element (PCE). In other cases, these policies can be installed using the Network Configuration Protocol (NETCONF) / YANG or a Command Line Interface (CLI). They are used to steer Multicast traffic along optimized paths from a Root to a set of Leaf routers.This document defines extensions to ping and traceroute mechanisms for an SR P2MP Policy with MPLS encapsulation to provide Operations, Administration, and Maintenance (OAM) capabilities. The extensions enable operators to verify connectivity, diagnose failures, and troubleshoot forwarding issues within SR P2MP Policy Multicast trees.By introducing new mechanisms for detecting failures and validating path integrity, this document enhances the operational robustness of P2MP Multicast deployments. Additionally, it ensures that existing MPLS and SR-based OAM tools can be effectively applied to networks utilizing SR P2MP Policies.PCEP extensions for SR P2MP PolicyNokiaCisco SystemsCisco SystemArrcusCienaSegment Routing (SR) Point-to-Multipoint (P2MP) Policies are a set of policies that enable architecture for P2MP service delivery. This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate P2MP paths for SR-MPLS from a Root to a set of Leaf nodes.Work in ProgressAcknowledgementsThe authors would like to acknowledge reviewing the
document.ContributorsCisco Systems, Inc.United States of Americazali@cisco.comCisco Systems, Inc.United States of Americaarvvenka@cisco.comNokiaMountain ViewCAUnited States of Americajayant.kotalwar@nokia.comNokiaMountain ViewCAUnited States of Americatanmoy.kundu@nokia.comBellVancouverCanadaclayton.hassen@bell.caCisco Systems, Inc.United States of Americamankamis@cisco.comAuthors' AddressesArrcusUnited States of Americarishabh@arrcus.comCisco Systems, Inc.MontrealCanadadavoyer@cisco.comCisco Systems, Inc.BrusselsBelgiumcfilsfil@cisco.comNokiaOttawaCanadahooman.bidgoli@nokia.comJuniper Networkszzhang@juniper.net