idnits 2.17.1 draft-hb-pim-p2mp-policy-ping-01.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 (25 July 2021) is 999 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 197, 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: 26 January 2022 Bell Canada 6 P. Parekh 7 Cisco System 8 Z. Zhang 9 Juniper Networks 10 25 July 2021 12 P2MP Policy Ping 13 draft-hb-pim-p2mp-policy-ping-01 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 26 January 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. 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 reuses most of the concepts in [RFC6425] 93 2. Conventions used in this document 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 97 "OPTIONAL" in this document are to be interpreted as described in BCP 98 14 [RFC2119] [RFC8174] when, and only when, they appear in all 99 capitals, as shown here. 101 3. Motivation 103 A P2MP Policy and its corresponding Replication Segments are usually 104 setup via a controller, the root and the leaves are discovered as per 105 [draft-ietf-pim-sr-p2mp-policy-02]. The tree is calculated from the 106 root to the leaves. There is no underlay protocol to signal the P2MP 107 Policy from the root to the Leaf routers, as such when a P2MP tree 108 fails to deliver user traffic, the failure can be difficult to pin 109 point without a ping/traceroute mechanism to isolate the fault in the 110 P2MP tree. The P2MP Policy ping/traceroute can be utilize to detect 111 faults on the path of the tree and its associated replication 112 segments [draft-ietf-spring-segment-routing-policy-13]. These tools 113 can be used to periodically ping the leaves to ensure connectivity. 114 If the ping fails, trace route can be initiated to determine where 115 the failure lies. The ping/traceroute can be initiated from the node 116 that initiates the P2MP policy. 118 3.1. P2MP Policy Ping and Traceroute 120 Ping/Traceroute packets are forwarded on the P2MP Policy, on a 121 specific CP or its active PI toward the leaf routers. They are 122 replicated at the replication point based on the replication segment 123 forwarding information on the corresponding node. The packet are 124 processed accordingly when their TTL expires or when the egress 125 router (leaf) is reached. The appropriate respond is send back to 126 the root as per procedures in [RFC6425] 128 This draft reuses most procedures for mLDP in RFC [RFC6425] 130 The implementation should take into account that there can be many 131 CPs under the P2MP Policy and the implementation should allow each CP 132 and its corresponding PI to be tested via Ping and Trace route. The 133 Ping and Traceroute packet is forwarded via that specific CP and its 134 corresponding replication segments. On the egress node the 135 corresponding CP and its PI should respond irrespective if it is the 136 active CP or a backup CP. 138 Two replication segments can be connected via a unicast SR domain. 139 In this scenario the SR tunnel labels need to be programmed with the 140 right TTL depending on the which type of hierarchical MPLS TTL mode 141 is used. As an example pipe vs uniform mode. When in SR domain the 142 P2MP Tree PING and Traceroute will be processed on the two connecting 143 replication segments based on the replication SID and its TTL. As 144 such the SR domain will act as a single hop on the replication SID 145 and the replication SID TTL is subtracted by one before the unicast 146 SR SIDs are pushed on the replication SID. To detect failure in SR 147 domain is beyond the scope of this draft. 149 3.2. Packet format and new TLVs 151 The packet format used is as per [RFC4379] section 3. Some new TLVs 152 and sub-TLVs are required to support the new functionality. They are 153 described in the following sections. 155 3.2.1. Identifying a P2MP Policy 157 [RFC4379] defines how an MPLS TE LSP under test may be identified in 158 an echo request.In order to identify the correct replication segment 159 for the CP and its PI, the echo request message MUST carry a Target 160 FEC Stack TLV, and this MUST carry exactly one of two new sub-TLVs: 161 either a P2MP policy IPv4 CP or P2MP Policy IPv6 CP FEC Stack sub- 162 TLV. The new sub-TLVs are assigned Sub-Type identifiers as follows, 163 and are described in the following sections. 165 artwork 166 Sub-Type Length Value Field 167 -------- ------ ----------- 168 42 xx P2MP Policy IPv4 CP 169 43 xx P2MP Policy IPv6 CP 171 3.2.1.1. P2MP Policy CP FEC Stack Sub-TLVs 173 The format of the P2MP Policy Session sub-TLV value field is 174 specified in the following figure. The value fields are taken from 175 the definitions of the P2MP Policy section 3 of 176 [draft-ietf-pim-sr-p2mp-policy-02] 177 artwork 178 0 1 2 3 179 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 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Address Family | Address Length| Root Addr | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | | 184 ~ Root Address (Cont.) ~ 185 | | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | TreeId length | Tree-ID ... | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 189 | | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Path-Instance length | Path-instance | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 193 | | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 * Address Family: Two-octet quantity, containing a value from 197 ADDRESS FAMILY NUMBERS in [IANA-AF] that encodes the address 198 family for the Root Address. 200 * Address Length: Length of the Root Address in octets. 202 * Root Address: The address of Root node of P2MP tree instantiated 203 by the SR P2MP Policy 205 * TreeId Length: Length of the TreeID in octets. This should be set 206 to 4 octets 208 * Tree-ID: A identifier that is unique in context of the Root. This 209 is an unsigned 32-bit number. 211 * Path-instance Length: Length of the path instance ID in octet. 213 * path-instance: path instance ID to be tested 214 [draft-ietf-spring-segment-routing-policy-13] 216 3.3. Limiting the Scope of Response 218 As per [RFC6425] section 3.2 Four sub-TLVs are used for the inclusion 219 in the P2MP Responder Identifier TLV carried on the echo request 220 message. 222 The Sub-TLVs for IPv4 and IPv6 egress address P2MP responder is in 223 par with [RFC6425] section 3.2.1 224 The Sub-TLVs for IPv4 and IPv6 node address P2MP responder is in par 225 with [RFC6425] section 3.2.2 227 4. IANA Consideration 229 Two new sub-TLV types are defined for inclusion within the LSP ping 230 [RFC4379] Target FEC Stack TLV (TLV type 1). 232 5. Security Considerations 234 TBD 236 6. Acknowledgments 238 7. References 240 7.1. Normative References 242 [RFC2119] "S. Brandner, "Key words for use in RFCs to Indicate 243 Requirement Levels"", March 1997. 245 [RFC8174] "B. Leiba, "ambiguity of Uppercase vs Lowercase in RFC 246 2119 Key Words"", May 2017. 248 7.2. Informative References 250 [draft-ietf-pim-sr-p2mp-policy-02] 251 "D. Yoyer, C. Filsfils, R.Prekh, H.bidgoli, Z. Zhang, 252 "draft-voyer-pim-sr-p2mp-policy"", October 2019. 254 [draft-ietf-spring-segment-routing-policy-13] 255 "D. Yoyer, C. Filsfils, R.Prekh, H.bidgoli, Z. Zhang, 256 "draft-voyer-pim-sr-p2mp-policy "draft-voyer-spring-sr- 257 replication-segment"", July 2020. 259 [RFC4379] "K. Kompella, G. Swallow", February 2006. 261 [RFC6425] "S. Saxena, G. Swallow, Z. Ali, A. Farrel, S. Yasukawa, 262 T.Nadeau "Detecting Data-Plane Failures in Point-to- 263 Multipoint MPLS"", November 2011. 265 Authors' Addresses 266 Hooman Bidgoli (editor) 267 Nokia 268 Ottawa 269 Canada 271 Email: hooman.bidgoli@nokia.com 273 Daniel Voyer 274 Bell Canada 275 Montreal 276 Canada 278 Email: daniel.yover@bell.ca 280 Rishabh Parekh 281 Cisco System 282 San Jose, 283 United States of America 285 Email: riparekh@cisco.com 287 Zhaohui Zhang 288 Juniper Networks 289 Boston, 290 United States of America 292 Email: zzhang@juniper.com