P2MP Policy Ping

Abstract

SR P2MP policies are set of policies that enable architecture for P2MP service delivery. A P2MP Policy consists of candidate paths that connects the Root of the Tree to a set of Leaves. The P2MP policy is composed of replication segments. A replication segment is a forwarding instruction for a candidate path which is downloaded to the Root, transit nodes and the leaves.¶

This document describes a simple and efficient mechanism that can be used to detect data plane failures in P2MP Policy Candidate Paths (CPs) and Path Instances (PIs).¶

1. Introduction

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 [RFC6425]¶

2. Conventions used in this document

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.¶

3. Motivation

A P2MP Policy and its corresponding Replication Segments are usually setup via a controller, the root and the leaves are discovered as per [draft-ietf-pim-sr-p2mp-policy]. 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 [draft-ietf-spring-segment-routing-policy-13]. 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.¶

artwork
Sub-Type       Length            Value Field
--------       ------            -----------
    TBD          xx            P2MP Policy MPLS Candidate Path

artwork
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Address Family         | Address Length|   Reserved    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                     Root Address                          ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Tree-ID                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Instance-ID                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4. Implementation Status

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 RFC [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 RFC 7942 [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".¶

5. IANA Consideration

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¶

6. Security Considerations

Overall, the security needs for P2MP policy ping is same as [RFC8029]. 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 RFC8029 section 5 should be taken and implemented to mitigate these attack vectors for P2MP policy Ping as well.¶

7. Acknowledgments

8. References