P2MP Policy Ping
draft-ietf-pim-p2mp-policy-ping-09

Network Working Group                                    H. Bidgoli, Ed.
Internet-Draft                                                     Nokia
Intended status: Standards Track                                V. Voyer
Expires: 9 August 2025                                       Bell Canada
                                                               P. Parekh
                                                            Cisco System
                                                                Z. Zhang
                                                        Juniper Networks
                                                         5 February 2025

                            P2MP Policy Ping
                   draft-ietf-pim-p2mp-policy-ping-09

Abstract

   SR P2MP policies are set of policies that enable architecture for
   P2MP service delivery.  A P2MP Policy consists of a set of candidate
   paths that connects the Root of the Tree to a set of Leaves.  A
   candidate path can contain two path instances for global optimization
   purposes.  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).

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 9 August 2025.

Bidgoli, et al.           Expires 9 August 2025                 [Page 1]
Internet-Draft              P2MP Policy Ping               February 2025

Copyright Notice

   Copyright (c) 2025 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, 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

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions used in this document . . . . . . . . . . . . . .   3
   3.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  MPLS P2MP Policy Ping and Traceroute  . . . . . . . . . .   3
     3.2.  Packet format and new TLVs  . . . . . . . . . . . . . . .   5
       3.2.1.  Identifying a P2MP Policy . . . . . . . . . . . . . .   5
         3.2.1.1.  P2MP Policy CP FEC Stack Sub-TLVs . . . . . . . .   5
     3.3.  Limiting the Scope of Response  . . . . . . . . . . . . .   6
   4.  Implementation Status . . . . . . . . . . . . . . . . . . . .   6
     4.1.  Nokia Implementation  . . . . . . . . . . . . . . . . . .   7
   5.  IANA Consideration  . . . . . . . . . . . . . . . . . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   8
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

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]

Bidgoli, et al.           Expires 9 August 2025                 [Page 2]
Internet-Draft              P2MP Policy Ping               February 2025

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 or statically via yang or CLI configuration,
   the root and the leaves are discovered as per
   [draft-ietf-pim-sr-p2mp-policy-09].  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 [RFC9524].  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.

3.1.  MPLS P2MP Policy Ping and Traceroute

   Ping/Traceroute packets are forwarded on the P2MP Policy, on a
   specific CP and its PIs 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, future drafts will address
   replication segments using SRv6 encap.  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 [RFC6425]

   [RFC6425] scope is fault detection and isolation for P2MP MPLS LSPs.
   [RFC6425] extends the techniques described in [RFC8029] such that
   they may be applied to P2MP MPLS LSPs.  [RFC6425] stresses the reuse
   of existing LSP ping mechanisms used for P2P LSPs, and applies them
   to P2MP MPLS LSPs in order to simplify implementation and network
   operation.

Bidgoli, et al.           Expires 9 August 2025                 [Page 3]
Internet-Draft              P2MP Policy Ping               February 2025

   The [RFC6425] procedures for fault detection of a P2MP MPLS LSP are
   common for all P2MP MPLS protocols, including P2MP RSVP-TE and
   Multicast LDP and now P2MP SR Policy.  There are minor differences
   pointed out in [RFC6425] with regards to P2MP RSVP-TE and Multicast
   LDP which this draft will specifically address for SR P2MP Policy,
   these minor differences are as follow:

   1.  Including Egress Address P2MP Responder Sub-TLVs, which can not
       be included for Multicast LDP as per section 3.2.1 of [RFC6425].
       In Multicast LDP, there is no way for upstream LSRs to know the
       identity of the downstream leaf nodes.  This is also true for
       P2MP LSPs of P2MP SR Policy as most transit routers are
       programmed via a PCE and have no knowledge of the leaf nodes.
       The only node that might have knowledge of the leaf nodes is the
       Root where the P2MP SR Policy is programmed.  Hence these sub-
       TLVs SHOULD NOT be used with an echo request carrying a P2MP
       Policy MPLS Candidate Path FEC.

   2.  End of Processing for Traceroutes, for Multicast LDP LSPs, the
       initiating LSR might not always know about all the egress nodes
       unlike P2MP RSVP-TE.  For P2MP SR Policy the Root of the tree can
       be aware of the all the egress nodes in the case of PCC initiate
       P2MP SR Policy and optionally it MAY be aware of the all the
       egress nodes if the P2MP SR Policy is PCE initiated.  Therefore
       P2MP SR Policy SHOULD follow the recommendation of section 4.3.1
       of [RFC6425] depending on if the root is aware of the all the
       egress nodes or not.  As an example for PCC initiate P2MP SR
       Policy the root can learn the identities of egress nodes via the
       Next Generation MVPN procedures and BGP as per [RFC6514], but
       with PCE initiated P2MP SR Policy, the egress nodes may not be
       downloaded to the root by the PCE, as this is optional and
       implementation specific.

   3.  Another major difference between P2MP RSVP-TE and Multicast LDP
       in [RFC6425] is section 3.1 for identifying the LSP under test.
       Each protocol has its own identifier.  This draft defines a new
       Target FEC Stack TLV for P2MP SR Policy to identify the its CPs
       and PIs.

   Beside the major differences explained above, P2MP SR Policy should
   follow [RFC6425] common procedures for P2MP MPLS LSPs.  This draft
   also reuses the same destination UDP port as [RFC8029]

   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

Bidgoli, et al.           Expires 9 August 2025                 [Page 4]
Internet-Draft              P2MP Policy Ping               February 2025

   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.

3.2.  Packet format and new TLVs

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

3.2.1.  Identifying a P2MP Policy

   [RFC8029] 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.

   Sub-Type       Length            Value Field
   --------       ------            -----------
       41        Variable          P2MP Policy MPLS Candidate Path

3.2.1.1.  P2MP Policy CP FEC Stack Sub-TLVs

   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
   [draft-ietf-pim-sr-p2mp-policy-09]

Bidgoli, et al.           Expires 9 August 2025                 [Page 5]
Internet-Draft              P2MP Policy Ping               February 2025

       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                               ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Tree-ID                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Instance-ID                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   *  Address Family: Two-octet quantity, containing a value from
      ADDRESS FAMILY NUMBERS in [IANA-AF] 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 [draft-ietf-pim-sr-p2mp-policy-09]

   *  Tree-ID: as defined in [draft-ietf-pim-sr-p2mp-policy-09]

   *  Instance-ID: 16 bit value to identify the Path-Instance
      [draft-ietf-pim-sr-p2mp-policy-09]

3.3.  Limiting the Scope of Response

   As per [RFC6425] 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 [RFC6425] section 3.2.1

   The Sub-TLVs for IPv4 and IPv6 node address P2MP responder is in par
   with [RFC6425] section 3.2.2

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 RFC7942 .  The description of implementations in this
   section is intended to assist the IETF in its decision processes in

Bidgoli, et al.           Expires 9 August 2025                 [Page 6]
Internet-Draft              P2MP Policy Ping               February 2025

   progressing drafts to RFCs.  Please note that the listing of any
   individual implementation here does not imply endorsement by the
   IETF.  Fu, thermore, 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".

4.1.  Nokia Implementation

   Nokia has implemented [draft-ietf-pim-sr-p2mp-policy-09] and
   [RFC9524].  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.

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.

Bidgoli, et al.           Expires 9 August 2025                 [Page 7]
Internet-Draft              P2MP Policy Ping               February 2025

7.  Acknowledgments

8.  Normative References

   [draft-ietf-pim-sr-p2mp-policy-09]
              "D. Yoyer, C. Filsfils, R.Prekh, H.bidgoli, Z. Zhang,
              "draft-ietf-pim-sr-p2mp-policy"", October 2019.

   [IANA-AF]  "IANA Assigned Port Numbers,
              "http://www.iana.org/assignments/address-family-numbers"".

   [RFC2119]  "S. Brandner, "Key words for use in RFCs to Indicate
              Requirement Levels"", March 1997.

   [RFC6425]  "S. Saxena, G. Swallow, Z. Ali, A. Farrel, S. Yasukawa,
              T.Nadeau "Detecting Data-Plane Failures in Point-to-
              Multipoint MPLS"", November 2011.

   [RFC6514]  "R.Aggarwal, E. Rosen, T. Morin, Y. Rekhter "BGP Encodings
              and Procedures for Multicast in MPLS/BGP IP VPNs"",
              February 2012.

   [RFC8029]  "K. Kompella, G. Swallow, C. Pgnataro, N. kumar, S. Aldrin
              M.  Chen, "Detecting Multiprotocol Label Switched (MPLS)
              Data-Plane Failures.", February 2006.

   [RFC8174]  "B. Leiba, "ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words"", May 2017.

   [RFC9524]  "D. Voyer, C. Filsfils, R. Parekh, H. Bidgoli, Z. Zhang,
              "Segment Routing Replication for Multipoint Service
              Delivery"", February 2024.

Authors' Addresses

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

   Daniel Voyer
   Bell Canada
   Montreal
   Canada
   Email: daniel.voyer@bell.ca

Bidgoli, et al.           Expires 9 August 2025                 [Page 8]
Internet-Draft              P2MP Policy Ping               February 2025

   Rishabh Parekh
   Cisco System
   San Jose,
   United States of America
   Email: riparekh@cisco.com

   Zhaohui Zhang
   Juniper Networks
   Boston,
   United States of America
   Email: zzhang@juniper.net

Bidgoli, et al.           Expires 9 August 2025                 [Page 9]