idnits 2.17.1 draft-hb-pim-p2mp-policy-ping-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (13 November 2021) is 894 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'IANA-AF' is mentioned on line 201, but not defined -- Duplicate reference: RFC2119, mentioned in 'RFC8174', was also mentioned in 'RFC2119'. -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Bidgoli, Ed. 3 Internet-Draft Nokia 4 Intended status: Standards Track V. Voyer 5 Expires: 17 May 2022 Bell Canada 6 P. Parekh 7 Cisco System 8 Z. Zhang 9 Juniper Networks 10 13 November 2021 12 P2MP Policy Ping 13 draft-hb-pim-p2mp-policy-ping-03 15 Abstract 17 SR P2MP policies are set of policies that enable architecture for 18 P2MP service delivery. A P2MP Policy consists of candidate paths 19 that connects the Root of the Tree to a set of Leaves. The P2MP 20 policy is composed of replication segments. A replication segment is 21 a forwarding instruction for a candidate path which is downloaded to 22 the Root, transit nodes and the leaves. 24 This document describes a simple and efficient mechanism that can be 25 used to detect data plane failures in P2MP Policy Candidate Paths 26 (CPs) and Path Instances (PIs). 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 17 May 2022. 45 Copyright Notice 47 Copyright (c) 2021 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Simplified BSD License text 56 as described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Conventions used in this document . . . . . . . . . . . . . . 3 63 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3.1. MPLS P2MP Policy Ping and Traceroute . . . . . . . . . . 3 65 3.2. Packet format and new TLVs . . . . . . . . . . . . . . . 4 66 3.2.1. Identifying a P2MP Policy . . . . . . . . . . . . . . 4 67 3.2.1.1. P2MP Policy CP FEC Stack Sub-TLVs . . . . . . . . 4 68 3.3. Limiting the Scope of Response . . . . . . . . . . . . . 5 69 4. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 6 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 71 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 74 7.2. Informative References . . . . . . . . . . . . . . . . . 6 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 77 1. Introduction 79 Each P2MP Policy can have multiple CPs. The CP with highest 80 preference is the active CP while all other CPs are the backup CPs. 81 A CP can have multiple PIs to allow global optimization of the CP via 82 Make Before Break procedures between the active PI and the newly 83 setup and optimized PI. 85 It is desirable to test the end to end connectivity of a CP, whether 86 it is the active CP or a backup CP and all the CP's PIs. This 87 document describes a mechanism that can be used to detect data plane 88 failures in P2MP Policy Candidate Paths (CP) and its associate Path 89 Instances (PI). 91 This draft is only for replication SIDs that use MPLS encap for their 92 forwarding and not SRv6. It reuses most of the concepts in [RFC6425] 94 2. Conventions used in this document 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 98 "OPTIONAL" in this document are to be interpreted as described in BCP 99 14 [RFC2119] [RFC8174] when, and only when, they appear in all 100 capitals, as shown here. 102 3. Motivation 104 A P2MP Policy and its corresponding Replication Segments are usually 105 setup via a controller, the root and the leaves are discovered as per 106 [draft-ietf-pim-sr-p2mp-policy-02]. The tree is calculated from the 107 root to the leaves. There is no underlay protocol to signal the P2MP 108 Policy from the root to the Leaf routers, as such when a P2MP tree 109 fails to deliver user traffic, the failure can be difficult to pin 110 point without a ping/traceroute mechanism to isolate the fault in the 111 P2MP tree. The P2MP Policy ping/traceroute can be utilize to detect 112 faults on the path of the tree and its associated replication 113 segments [draft-ietf-spring-segment-routing-policy-13]. These tools 114 can be used to periodically ping the leaves to ensure connectivity. 115 If the ping fails, trace route can be initiated to determine where 116 the failure lies. The ping/traceroute can be initiated from the node 117 that initiates the P2MP policy. 119 3.1. MPLS P2MP Policy Ping and Traceroute 121 Ping/Traceroute packets are forwarded on the P2MP Policy, on a 122 specific CP or its active PI toward the leaf routers. They are 123 replicated at the replication point based on the replication segment 124 forwarding information on the corresponding node. This draft only 125 addresses the replication segments that use MPLS encap only, future 126 drafts will address the SRv6 forwarding. The packet are processed 127 accordingly when their TTL expires or when the egress router (leaf) 128 is reached. The appropriate respond is send back to the root as per 129 procedures in [RFC6425] 131 This draft reuses most procedures for mLDP in RFC [RFC6425] 133 This draft also reuses the same destination UDP port as [RFC4379] 135 The implementation should take into account that there can be many 136 CPs under the P2MP Policy and the implementation should allow each CP 137 and its corresponding PI to be tested via Ping and Trace route. The 138 Ping and Traceroute packet is forwarded via that specific CP and its 139 corresponding replication segments. On the egress node the 140 corresponding CP and its PI should respond irrespective if it is the 141 active CP or a backup CP. 143 Two replication segments can be connected via a unicast SR domain. 144 In this scenario the SR tunnel labels need to be programmed with the 145 right TTL depending on the which type of hierarchical MPLS TTL mode 146 is used. As an example pipe vs uniform mode. When in SR domain the 147 P2MP Tree PING and Traceroute will be processed on the two connecting 148 replication segments based on the replication SID and its TTL. As 149 such the SR domain will act as a single hop on the replication SID 150 and the replication SID TTL is subtracted by one before the unicast 151 SR SIDs are pushed on the replication SID. To detect failure in SR 152 domain is beyond the scope of this draft. 154 3.2. Packet format and new TLVs 156 The packet format used is as per [RFC4379] section 3. Some new TLVs 157 and sub-TLVs are required to support the new functionality. They are 158 described in the following sections. 160 3.2.1. Identifying a P2MP Policy 162 [RFC4379] defines how an MPLS TE LSP under test may be identified in 163 an echo request.In order to identify the correct replication segment 164 for the CP and its PI, the echo request message MUST carry a Target 165 FEC Stack TLV, and this MUST carry exactly one of one new sub-TLV: a 166 P2MP policy MPLS CP FEC Stack sub-TLV. The new sub-TLV is assigned 167 Sub-Type identifiers as follows, and are described in the following 168 sections. 170 artwork 171 Sub-Type Length Value Field 172 -------- ------ ----------- 173 42 xx P2MP Policy MPLS CP 175 3.2.1.1. P2MP Policy CP FEC Stack Sub-TLVs 177 The format of the P2MP Policy Session sub-TLV value field is 178 specified in the following figure. The value fields are taken from 179 the definitions of the P2MP Policy section 3 of 180 [draft-ietf-pim-sr-p2mp-policy-02] 181 artwork 182 0 1 2 3 183 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 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Address Family | Address Length| Root Addr | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | | 188 ~ Root Address (Cont.) ~ 189 | | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | TreeId length | Tree-ID ... | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 193 | | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Path-Instance length | Path-instance | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 197 | | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 * Address Family: Two-octet quantity, containing a value from 201 ADDRESS FAMILY NUMBERS in [IANA-AF] that encodes the address 202 family for the Root Address. 204 * Address Length: Length of the Root Address in octets. 206 * Root Address: The address of Root node of P2MP tree instantiated 207 by the SR P2MP Policy 209 * TreeId Length: Length of the TreeID in octets. This should be set 210 to 4 octets 212 * Tree-ID: A identifier that is unique in context of the Root. This 213 is an unsigned 32-bit number. 215 * Path-instance Length: Length of the path instance ID in octet. 217 * path-instance: path instance ID to be tested 218 [draft-ietf-spring-segment-routing-policy-13] 220 3.3. Limiting the Scope of Response 222 As per [RFC6425] section 3.2 Four sub-TLVs are used for the inclusion 223 in the P2MP Responder Identifier TLV carried on the echo request 224 message. 226 The Sub-TLVs for IPv4 and IPv6 egress address P2MP responder is in 227 par with [RFC6425] section 3.2.1 228 The Sub-TLVs for IPv4 and IPv6 node address P2MP responder is in par 229 with [RFC6425] section 3.2.2 231 4. IANA Consideration 233 Two new sub-TLV types are defined for inclusion within the LSP ping 234 [RFC4379] Target FEC Stack TLV (TLV type 1). 236 5. Security Considerations 238 TBD 240 6. Acknowledgments 242 7. References 244 7.1. Normative References 246 [RFC2119] "S. Brandner, "Key words for use in RFCs to Indicate 247 Requirement Levels"", March 1997. 249 [RFC8174] "B. Leiba, "ambiguity of Uppercase vs Lowercase in RFC 250 2119 Key Words"", May 2017. 252 7.2. Informative References 254 [draft-ietf-pim-sr-p2mp-policy-02] 255 "D. Yoyer, C. Filsfils, R.Prekh, H.bidgoli, Z. Zhang, 256 "draft-voyer-pim-sr-p2mp-policy"", October 2019. 258 [draft-ietf-spring-segment-routing-policy-13] 259 "D. Yoyer, C. Filsfils, R.Prekh, H.bidgoli, Z. Zhang, 260 "draft-voyer-pim-sr-p2mp-policy "draft-voyer-spring-sr- 261 replication-segment"", July 2020. 263 [RFC4379] "K. Kompella, G. Swallow", February 2006. 265 [RFC6425] "S. Saxena, G. Swallow, Z. Ali, A. Farrel, S. Yasukawa, 266 T.Nadeau "Detecting Data-Plane Failures in Point-to- 267 Multipoint MPLS"", November 2011. 269 Authors' Addresses 270 Hooman Bidgoli (editor) 271 Nokia 272 Ottawa 273 Canada 275 Email: hooman.bidgoli@nokia.com 277 Daniel Voyer 278 Bell Canada 279 Montreal 280 Canada 282 Email: daniel.yover@bell.ca 284 Rishabh Parekh 285 Cisco System 286 San Jose, 287 United States of America 289 Email: riparekh@cisco.com 291 Zhaohui Zhang 292 Juniper Networks 293 Boston, 294 United States of America 296 Email: zzhang@juniper.com