idnits 2.17.1 draft-hb-pim-p2mp-policy-ping-00.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 27, 2020) is 1368 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 167, but not defined -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 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: January 28, 2021 Bell Canada 6 P. Parekh 7 Cisco System 8 Z. Zhang 9 Juniper Networks 10 July 27, 2020 12 P2MP Policy Ping 13 draft-hb-pim-p2mp-policy-ping-00 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 January 28, 2021. 45 Copyright Notice 47 Copyright (c) 2020 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 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Conventions used in this document . . . . . . . . . . . . . . 3 64 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3.1. P2MP Policy Ping and Traceroute . . . . . . . . . . . . . 3 66 3.2. Packet format and new TLVs . . . . . . . . . . . . . . . 3 67 3.2.1. Identifying a P2MP Policy . . . . . . . . . . . . . . 4 68 3.2.1.1. P2MP Policy Sub-TLVs . . . . . . . . . . . . . . 4 69 3.3. Limiting the Scope of Response . . . . . . . . . . . . . 5 70 4. Operation of P2MP Policy Ping . . . . . . . . . . . . . . . . 5 71 4.1. Replication Segments Connected via a Unicast SR domain . 5 72 5. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 6 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 74 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 77 8.2. Informative References . . . . . . . . . . . . . . . . . 6 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 80 1. Introduction 82 Each P2MP Policy can have multiple CPs. The CP with highest 83 preference is the active CP while all other CPs are the backup CPs. 84 A CP can have multiple PI to allow global optimization of the CP via 85 Make Before Break procedures between the active PI and the newly 86 setup and optimized PI. 88 This document describes a mechanism that can be used to detect data 89 plane failures in P2MP Policy Candidate Paths (CP) and its associate 90 Path Instances (PI) from the root to a set of leaves. 92 This draft defines two new sub-TLVs to identifier a P2MP Policy and 93 reuses concepts from [RFC6425] 95 2. Conventions used in this document 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC 2119 [RFC2119]. 101 3. Motivation 103 A P2MP Policy and its corresponding Replication Segments are usually 104 setup via a PCE, after PCE has calculated the tree from the root to a 105 set of leaves. There is no underlay protocol to signal the P2MP 106 Policy from the root to the Leaf routers, as such when a P2MP tree 107 fails to deliver user traffic, the failure can be difficult to pin 108 point without a ping/traceroute mechanism to isolate the fault in the 109 P2MP tree. The P2MP Policy ping/traceroute can be utilize to detect 110 faults on the path of the tree and its associated replication 111 segments. These tools can be used to periodically ping the leaves to 112 ensure connectivity. If the ping fails, trace route can be initiated 113 to determine where the failure lies. 115 3.1. P2MP Policy Ping and Traceroute 117 The P2MP Policy Ping and Traceroute detect failure on the path of 118 P2MP Tree and its corresponding replication segments. Ping/ 119 Traceroute packets are forwarded on the P2MP Policy, on a specific CP 120 or the CP's PI toward the leaf routers. They are replicated at the 121 replication point based on the replication segment information on the 122 corresponding transit node. The packet are processed accordingly 123 when their TTL expires or when the egress router (leaf) is reached. 124 The appropriate respond is send back to the root as per [RFC6425] 126 The implementation should take into account that there can be many CP 127 under the P2MP Policy, one active CP and many inactive CPs. The 128 implementation should allow each CP and its corresponding PIs to be 129 tested via Ping and Trace route. The Ping and Traceroute packet is 130 forwarded via that specific CP and its corresponding replication 131 segments. 133 3.2. Packet format and new TLVs 135 The packet format used is as per [RFC4379] section 3. 137 3.2.1. Identifying a P2MP Policy 139 The new sub-TLV identifiers are assigned, as follow: 141 artwork 142 Sub-Type Length Value Field 143 -------- ------ ----------- 144 38 20 P2MP Policy IPv4 CP 145 39 32 P2MP Policy IPv6 CP 147 3.2.1.1. P2MP Policy Sub-TLVs 149 artwork 150 0 1 2 3 151 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 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Address Family | Address Length | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | | 156 ~ Root Address (Cont.) ~ 157 | | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | TreeId length | Tree-ID ... | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 161 | | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Path-Instance length | Path-instance | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 o Address Family: Two-octet quantity containing a value from ADDRESS 167 FAMILY NUMBERS in [IANA-AF] that encodes the address family for 168 the Root LSR Address. 170 o Address Length: Length of the Root LSR Address in octets. 172 o Root Addrt: The address of Root node of P2MP tree instantiated by 173 the SR P2MP Policy 175 o TreeId Length: Length of the TreeID in octets. This should be set 176 to 4 octets 178 o Tree-ID: A identifier that is unique in context of the Root. This 179 is an unsigned 32-bit number. 181 o Path-instance Length: Length of the path instance ID in octet. 182 This should be set to 2. 184 o path-instance: path instance ID to be tested 186 3.3. Limiting the Scope of Response 188 As per [RFC6425] section 3.2 Four sub-TLVs are used for the inclusion 189 in the P2MP Responder Identifier TLV carried on the echo request 190 message. 192 The Sub-TLVs for IPv4 and IPv6 egress address P2MP responder is in 193 par with [RFC6425] section 3.2.1 195 The Sub-TLVs for IPv4 and IPv6 node address P2MP responder is in par 196 with [RFC6425] section 3.2.2 198 4. Operation of P2MP Policy Ping 200 The P2MP Policy Ping should be able to test the path for all the CPs 201 (active or inactive) or the CPs corresponding PIs for a P2MP policy 202 on the root router. In addition it should test all the Out going 203 interface for the replication segment connecting the root to the set 204 of leaves for this CP or PI. To do so the concepts in [RFC4379] and 205 [RFC6425] are extended to this draft. 207 The following sections will explain any new concepts for P2MP policy 208 Ping 210 4.1. Replication Segments Connected via a Unicast SR domain 212 Two replication segment can be connected via a unicast SR domain. 213 This means the traffic will be steered out of the upstream 214 replication segment based on the unicast SR SID List (as an example 215 node or adjacency SIDs). In this case the replication SID TTL is 216 subtracted by one on the current node. If the TTL hasn't expired, 217 the SR SID List will be placed on top of the replication segment, 218 with replication segment being at the bottom of the stack. The SR 219 SID List TTL should be set to 255, as an example pipe mode. When in 220 SR domain the TTL of SR SIDs will be decremented accordingly. The 221 TTL of the replication SID will be untouched in the SR domain. The 222 replication SID TTL will be examined again on the next replication 223 segment after the unicast SR SID List is removed from the label 224 stack. The appropriate actions will be taken on this replication 225 segment for P2MP Policy PING and Traceroute packet. To detect 226 failures in SR domain is beyond the scope of this draft. 228 5. IANA Consideration 230 Two new sub-TLV types are defined for inclusion within the LSP ping 231 [RFC4379] Target FEC Stack TLV (TLV type 1). 233 6. Security Considerations 235 TBD 237 7. Acknowledgments 239 8. References 241 8.1. Normative References 243 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 244 Requirement Levels", BCP 14, RFC 2119, 245 DOI 10.17487/RFC2119, March 1997, 246 . 248 8.2. Informative References 250 [draft-voyer-pim-sr-p2mp-policy] 251 "D. Yoyer, C. Filsfils, R.Prekh, H.bidgoli, Z. Zhang, 252 "draft-voyer-pim-sr-p2mp-policy"", October 2019. 254 [draft-voyer-spring-sr-replication-segment-04] 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 267 Hooman Bidgoli (editor) 268 Nokia 269 Ottawa 270 Canada 272 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 USA 285 Email: riparekh@cisco.com 287 Zhaohui Zhang 288 Juniper Networks 289 Boston 290 USA 292 Email: zzhang@juniper.com