Nokia

Ottawa Canada hooman.bidgoli@nokia.com

Cisco System

San Jose USA zali@cisco.com

Juniper Networks

Boston USA zzhang@juniper.net

Cisco System

San Jose USA abudhira@cisco.com

Cisco System

Montreal Canada davoyer@cisco.com

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 via using NETCONF/YANG or 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 SR P2MP Policy with MPLS encapsulation to provide OAM (Operations, Administration, and Maintenance) 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.

explains the concept of the SR P2MP Policy and its Candidate Paths (CPs). It also explains the concept of how a CP is selected to be the active CP. To enable seamless global optimization a CP may consist of multiple P2MP Tree Instances (PTIs), allowing for Make-Before-Break (MBB) procedures between an active PTI and a newly established, optimized PTI. A PTI is the actual P2MP tunnel set up from the Root to a set of Leaves via transit routers. A PTI is identified on the Root node by the PTI's instance ID. To ensure reliable network operation, it is essential to verify end-to-end connectivity for both active and backup CPs, as well as all associated PTIs. This document specifies a mechanism for detecting data plane failures within a SR P2MP Policy CP and its associated PTIs, enabling operators to monitor and troubleshoot multicast path integrity. This specification applies exclusively to Replication Segments (Replication SIDs) that use MPLS encapsulation for forwarding and does not cover Segment Routing over IPv6 (SRv6). The mechanisms described herein build upon the concepts established in for P2MP MPLS Operations, Administration, and Maintenance (OAM). All considerations and limitations described in section 6 of apply to this document as well.

The readers of this document should familiarize themselves with the following documents and sections for terminology and details implementation of the SR P2MP Policy section 1.1 defines terms specific to SR Replication Segment and also explains the Node terminology in a Multicast domain, including the Root Node, Leaf Node and a Bud Node. section 2, defines terms and concepts specific to SR P2MP Policy including the CP and the PTI.

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 when, and only when, they appear in all capitals, as shown here.

A SR P2MP Policy and its corresponding Replication Segments are typically provisioned via a centralized controller or configured using NETCONF/YANG or CLI. The root and the leaves are discovered in accordance with and the multicast tree is computed from the root to the leaves. However, there is no underlay signaling protocol to distribute the SR P2MP Policy from the root to the leaf routers. Consequently, when a P2MP tree fails to deliver user traffic, identifying the failure can be challenging without ping and traceroute mechanisms to isolate faults along the tree. To address this challenge, SR P2MP Policy ping and traceroute can be utilized to detect and localize faults within the P2MP tree and its associated Replication Segments, as defined in . These OAM tools enable periodic ping operations to verify connectivity between the root and the leaves. In cases where a ping fails, a traceroute can be initiated to determine the point of failure along the tree. This diagnostic process can be initiated from the node responsible for establishing the SR P2MP Policy, ensuring proactive monitoring and fault detection.

Ping/Traceroute packets are forwarded based upon the SR P2MP Policy, on a specific CP and its PTI toward the designated leaf routers. These packets are replicated at the replication point based on the Replication Segment forwarding information on the corresponding router. Packets are processed based on the standard behavior when their Time-to-Live (TTL) expires or when they reach the egress (leaf) router. The appropriate response is sent back to the root node following the procedures outlined in .

The procedures in define fault detection and isolation mechanisms for P2MP MPLS LSPs and extend the LSP ping techniques described in such that they may be applied to P2MP MPLS LSPs, ensuring alignment with existing fault management tools. emphasizes the reuse of existing LSP ping mechanisms designed for Point-to-Point P2P LSPs, adapting them to P2MP MPLS LSPs to facilitate seamless implementation and network operation. The fault detection procedures specified in are applicable to all P2MP MPLS protocols, including P2MP RSVP-TE and Multicast LDP and now SR P2MP SR Policy. While highlights specific differences for P2MP RSVP-TE and Multicast LDP, this document introduces considerations unique to SR P2MP Policies, including: Egress Address P2MP Responder Sub-TLVs: Multicast LDP, as per section 3.2.1 of , does not allow for the inclusion of Egress Address P2MP Responder Sub-TLVs, as upstream LSRs lack visibility into downstream leaf nodes. Similarly, SR P2MP Policies often rely on a Path Computation Element (PCE) for programming transit routers. This is why in SR P2MP domain, transit routers do not have knowledge of the leaf nodes. Only the Root node, where the SR P2MP Policy is programmed, may have visibility into the leaf nodes. Consequently, these Sub-TLVs SHOULD NOT be used when an echo request carries a SR P2MP Policy MPLS Candidate Path FEC. If a node receives the Egress Address P2MP Responder Sub-TLVs in an echo request, then it will not respond since it is unaware of whether it lies on the path to the address in the sub-TLV. End of Processing for Traceroutes: In Multicast LDP LSPs, the initiating LSR may not always be aware of all egress nodes, unlike P2MP RSVP-TE. In the case of SR P2MP Policies, the Root of the tree may have full visibility into the egress nodes if the SR P2MP Policy is PCC-initiated. If the SR P2MP Policy is PCE-initiated, the Root may or may not have visibility into the egress nodes, as this depends on the specific implementation and configuration of the PCE. Based on this, a SR P2MP Policy SHOULD follow the recommendations in Section 4.3.1 of , depending on the level of visibility the Root has into the egress nodes. For example, in a PCC-initiated SR P2MP Policy, the Root can learn egress node identities through Next-Generation MVPN procedures and BGP, as described in . In contrast, for a PCE-initiated SR P2MP Policy, the PCE may not provide the egress node information to the Root, making this process optional and implementation-specific. Identification of the LSP under test: , in Section 3.1, defines distinct identifiers for P2MP RSVP-TE and Multicast LDP when identifying an LSP under test. As each protocol has its own identifier, this document introduces a new Target FEC Stack TLV specific to SR P2MP Policies to uniquely identify their Candidate Paths (CPs) and P2MP Tree Instances (PTIs). These modifications ensure that SR P2MP Policy OAM mechanisms are properly aligned with existing MPLS ping and traceroute tools while addressing the specific operational characteristics of SR P2MP Policies.

In addition to major differences outlined in the previous section, SR P2MP Policies SHOULD follow to the common procedures specified in for P2MP MPLS LSPs. Furthermore, this specification reuses the same destination UDP port as defined in for consistency with existing MPLS OAM mechanism. Implementations MUST account for the fact that a SR P2MP Policy may contain multiple CPs, and each CP may consist of multiple PTIs. As such, implementations SHOULD support the ability to individually test each CP and its corresponding PTI using ping and traceroute mechanisms. The ping and traceroute packets are forwarded along the specified CP and its PTI, traversing the associated Replication Segments. When a downstream node capable of understanding the replication SID receives a ping or traceroute packet, it MUST process the request and generate a response even if the CP and its PTI are not currently the active path.

In certain deployments, two Replication Segments may be interconnected via an unicast domain. As an example two Replication segments can be connected via a SR Policy or similar technology. Example of this deployment is ingress replication. In such scenarios SR P2MP Policy OAM tools should be used for the P2MP Tree to verify the connectivity of the Replication Segments that are building the P2MP Tree while the unicast domain OAM tools should be used to verify the connectivity of unicast domain technology connecting the two Replication segment. In these scenarios the Replication SID should not be exposed or examined in the unicast domain. Proper TTL handling to copy the Replication Segment TTL to unicast technology can be achieved via hierarchical MPLS TTL mode being used (e.g., Pipe Mode vs. Uniform Mode). For example, when a SR P2MP Policy Ping or Traceroute packet between two Replication Segment is transiting over an Unicast SR domain, the Replication SID and its TTL must be only processed on Replication Segments, and should not be exposed or processed by the unicast domain routers. The Unicast domain MUST be treated as a single hop for Replication SID's TTL value, meaning that the Replication SID TTL MUST be decremented by one before it is forwarded through the Unicast domain and the replication SID TTL should be examined on the next replication segment. The Unicast SR domain Failure detection is considered out of scope for this document. The operator can use the OAM mechanisms available for Unicast domain to farther troubleshoot the Unicast SR domain.

The packet format used in this specification follow section 3 of . However, additional TLVs and sub-TLVs are required to support the new functionality introduced for SR P2MP Policies. These extensions are described in the following sections.

defines a standardized mechanism for detecting data-plane failures in Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs). To correctly identify the Replication Segment associated with a given Candidate Path (CP) and P2MP Tree Instance (PTI), the Echo Request message MUST include a Target FEC Stack TLV that explicitly specifies the Candidate Path and P2MP Tree Instance under test. This document introduces a new sub-TLV, referred to as the SR MPLS P2MP Policy Tree Instance sub-TLV, which is defined as follows:

Further details regarding the structure and processing of this sub-TLV are provided in subsequent sections.

The SR MPLS P2MP Policy Tree Instance sub-TLV value field follows the format specified in Section 2.3 of . The structure of this sub-TLV is illustrated in the figure below. It should be noted that this sub-TLV is testing a specific PTI within a specific CP and it is not testing the CP.

Address Family: (2 octets) IPv4/IPv6 ADDRESS FAMILY NUMBERS as specified in , indicating the address family of the Root. Any other Address Family but IPv4/IPv6 is not supported by this draft. Address Length: (1 octet) specifying the length of the Root Address in octets (4 octets for IPv4, 16 octets for IPv6). Reserved: MUST be set to zero by sender and it should be ignored by the reciver Root: (variable length depending on the address family field) The root node of the SR P2MP Policy, as defined in Tree-ID: (4 octets) A unique identifier for the P2MP tree, as defined in Instance-ID: (2 octets) identifies the specific Path-Instance as defined in

As specified in section 3.2 of , four sub-TLVs are used within the P2MP Responder Identifier TLV included in the echo request message. The Sub-TLVs for IPv4 and IPv6 egress addresses of P2MP responder are aligned with section 3.2.1 of . The sub-TLVs for IPv4 and IPv6 node addresses of the P2MP responder are aligned with Section 3.2.2 of These mechanisms ensure that responses are appropriately scoped to limit unnecessary processing and improve the efficiency of P2MP OAM procedures.

Note to the RFC Editor: please remove this section before publication. This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in RFC7942 . The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to RFC7942, "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".

Nokia has implemented and . In addition, Nokia has implemented P2MP policy ping as defined in this draft to verify the end to end connectivity of a P2MP tree in segment routing domain. The implementation supports SR-MPLS encapsulation and has all the MUST and SHOULD clause in this draft. The implementation is at general availability maturity and is compliant with the latest version of the draft. The documentation for implementation can be found at Nokia help and the point of contact is hooman.bidgoli@nokia.com.

IANA has assigned a TEMPORARY code point for the "SR MPLS P2MP Policy Tree Instance" Sub-TLV Name. This Sub-TLV is assigned from TLV type 1 (Target FEC Stack) from the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry group. The Sub-TLVs for TLV type 1 are listed under "Sub-TLVs for TLV Types 1, 16, and 21" sub-registry. This sub-type value is assigned from the standards Action range of 0-16383 from the "Sub-TLVs for TLV Types 1, 16, and 21" sub-registry. Sub-Type Sub-TLV Name 41 SR MPLS P2MP Policy Tree Instance

Overall, the security needs for P2MP policy ping are the same as and . The P2MP policy ping is susceptible to the same three attack vectors as explained in RFC8029 section 5. The same procedures and recommendations explained in section 5 should be taken and implemented to mitigate these attack vectors for P2MP policy Ping as well.