P2MP Policy Ping

Each P2MP Policy can have multiple Candidate Paths (CP)s. The CP with highest preference is the active CP while all other CPs are the backup CPs. A CP can have multiple PIs to allow global optimization of the CP via Make Before Break procedures between the active PI and the newly setup and optimized PI. It is desirable to test the end to end connectivity of a CP, whether it is the active CP or a backup CP and all the CP's PIs. This document describes a mechanism that can be used to detect data plane failures in P2MP Policy CP and its associate Path Instances (PI). This draft is only for replication SIDs that use MPLS encap for their forwarding and not SRv6. It reuses most of the concepts in

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 P2MP Policy and its corresponding Replication Segments are usually setup via a controller, the root and the leaves are discovered as per . The tree is calculated from the root to the leaves. There is no underlay protocol to signal the P2MP Policy from the root to the Leaf routers, as such when a P2MP tree fails to deliver user traffic, the failure can be difficult to pin point without a ping/traceroute mechanism to isolate the fault in the P2MP tree. The P2MP Policy ping/traceroute can be utilize to detect faults on the path of the tree and its associated replication segments . These tools can be used to periodically ping the leaves to ensure connectivity. If the ping fails, trace route can be initiated to determine where the failure lies. The ping/traceroute can be initiated from the node that initiates the P2MP policy.

Ping/Traceroute packets are forwarded on the P2MP Policy, on a specific CP or its active PI toward the leaf routers. They are replicated at the replication point based on the replication segment forwarding information on the corresponding node. This draft only addresses the replication segments that use MPLS encap only, future drafts will address the SRv6 forwarding. The packets are processed accordingly when their TTL expires or when the egress router (leaf) is reached. The appropriate respond is sent back to the root as per procedures in This draft reuses procedures for mLDP in RFC . More precisely, a P2MP policy and its corresponding Candidate Paths and Path Instances do not have a signaling layer and are setup manually via CLI or automatically via a controller. As an example, as per section 3.2.1, just like Multicast LDP, for each replication segment acting as LSR, there is no way to know the identity of the downstream leaf nodes. This draft will follow the Multicast LDP procedures in section 3, 4, 5 and 6 with exception of section 3.1 which explains the procedures and TLVs needed to identify the LSP under test. The procedures to identify the LSP is explained in this draft. “ This draft also reuses the same destination UDP port as The implementation should take into account that there can be many CPs under the P2MP Policy and the implementation should allow each CP and its corresponding PI to be tested via Ping and Traceroute. The Ping and Traceroute packet is forwarded via that specific CP and its PI and its corresponding replication segments. On downstream nodes when the ping and trace route is received, the node should process the packet and generate a response even if the CP and its PI is not the active path. Two replication segments can be connected via a unicast SR domain. In this scenario the SR tunnel labels need to be programmed with the right TTL depending on the which type of hierarchical MPLS TTL mode is used. As an example pipe vs uniform mode. When in SR domain the P2MP Tree PING and Traceroute will be processed on the two connecting replication segments based on the replication SID and its TTL. As such the SR domain will act as a single hop on the replication SID and the replication SID TTL is subtracted by one before the unicast SR SIDs are pushed on the replication SID. To detect failure in SR domain is beyond the scope of this draft.

The packet format used is as per section 3. Some new TLVs and sub-TLVs are required to support the new functionality. They are described in the following sections.

defines a simple and efficient mechanism to detect data-plane failures in Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs). In order to identify the correct replication segment for the CP and its PI, the echo request message MUST carry a Target FEC Stack TLV for the Candidate path and the Path instance that is under test. This draft defines a new sub-TLV: P2MP policy MPLS Candidate Path sub-TLV. The new sub-TLV is described in the following sections.

The format of the P2MP Policy MPLS Candidate Path sub-TLV value field is specified in the following figure. The value fields are taken from the definitions of the P2MP Policy section 2 of

Address Family: Two-octet quantity, containing a value from ADDRESS FAMILY NUMBERS in that encodes the address family for the Root Address. Address Length: Length of the Root Address in octets, 4 octets for IPv4 or 16 octets for IPv6. Root: as defined in Tree-ID: as defined in Instance-ID: 16 bit value to identify the Path-Instance

As per section 3.2 Four sub-TLVs are used for the inclusion in the P2MP Responder Identifier TLV carried on the echo request message. The Sub-TLVs for IPv4 and IPv6 egress address P2MP responder is in par with section 3.2.1 The Sub-TLVs for IPv4 and IPv6 node address P2MP responder is in par with section 3.2.2

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 the following code points for sub-type values to the following sub-TLVs under TLV type 1 (Target FEC Stack) from the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry, "TLVs and sub-TLVs" sub-registry. This sub-type value is assigned from the standards Action of range 0-16383 for TLV type 1 (Target FEC Stack) 41: P2MP Policy MPLS Candidate Path

Overall, the security needs for P2MP policy ping is same as . 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.