idnits 2.17.1 draft-rathi-mpls-egress-tlv-for-nil-fec-04.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 (February 21, 2021) is 1159 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Routing area D. Rathi, Ed. 3 Internet-Draft K. Arora 4 Intended status: Standards Track S. Hegde 5 Expires: August 25, 2021 Juniper Networks Inc. 6 Z. Ali 7 N. Nainar 8 Cisco Systems, Inc. 9 February 21, 2021 11 Egress TLV for Nil FEC in Label Switched Path Ping and Traceroute 12 Mechanisms 13 draft-rathi-mpls-egress-tlv-for-nil-fec-04 15 Abstract 17 MPLS ping and traceroute mechanism as described in RFC 8029 and 18 related extensions for SR as defined in RFC 8287 is very useful to 19 precisely validate the control plane and data plane synchronization. 20 All intermediate nodes may not have been upgraded to support 21 validation procedures. A simple mpls ping and traceroute mechanism 22 comprises of ability to traverse any path without having to validate 23 the control plane state. RFC 8029 supports this mechanism with Nil 24 FEC. The procedures described in RFC 8029 are mostly applicable when 25 the Nil FEC is used as intermediate FEC in the label stack. When all 26 labels are represented using Nil FEC, it poses some challenges. 28 This document introduces new TLV as additional extension to exisiting 29 Nil FEC and describes mpls ping and traceroute procedures using Nil 30 FEC with this additional extensions to overcome these challenges. 32 Requirements Language 34 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 35 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 36 "OPTIONAL" in this document are to be interpreted as described in 37 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 38 capitals, as shown here. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at https://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on August 25, 2021. 57 Copyright Notice 59 Copyright (c) 2021 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (https://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 75 2. Problem with Nil FEC . . . . . . . . . . . . . . . . . . . . 3 76 3. Egress TLV . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 4. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 4.1. Sending Egress TLV in MPLS Echo Request . . . . . . . . . 4 79 4.2. Receiving Egress TLV in MPLS Echo Request . . . . . . . . 6 80 5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 6 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 83 7.1. New TLV . . . . . . . . . . . . . . . . . . . . . . . . . 6 84 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 86 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 87 9.2. Informative References . . . . . . . . . . . . . . . . . 8 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 90 1. Introduction 92 Segment routing supports the creation of explicit paths using 93 adjacency- sids, node-sids, and anycast-sids. In certain usecases, 94 the TE paths are built using mechanisms described in 95 [I.D-ietf-spring-segment-routing-policy] by stacking the labels that 96 represent the nodes and links in the explicit path. When the SR-TE 97 paths are built by the controller, the head-end routers may not have 98 the complete database of the network and may not be aware of the FEC 99 associated with labels that are used in the label stack. A very 100 useful Operations And Maintenance (OAM) requirement is to be able to 101 ping and trace these paths. A simple mpls ping and traceroute 102 mechanism comprises of ability to traverse the SR-TE path without 103 having to validate the control plane state. 105 MPLS ping and traceroute mechanism as described in [RFC8029] and 106 related extensions for SR as defined in [RFC8287] is very useful to 107 precisely validate the control plane and data plane synchronization. 108 It also provides ability to traverse multiple ECMP paths and validate 109 each of the ECMP paths. Use of Target FEC requires all nodes in the 110 network to have implemented the validation procedures. All 111 intermediate nodes may not have been upgraded to support validation 112 procedures. In such cases, it is useful to have ability to traverse 113 the paths using ping and traceroute without having to obtain the 114 Forwarding Equivalence Class (FEC) for each label. 116 [RFC8029] supports this mechanism with Nil FEC. Nil FEC consists of 117 the label and there is no other associated FEC information. The 118 procedures described in [RFC8029] are mostly applicable when the Nil 119 FEC is used where the Nil FEC is an intermediate FEC in the label 120 stack. When all labels are represented using Nil FEC, it poses some 121 challenges. 123 Section 2 discusses the problems associated with using all Nil FECs 124 in a MPLS ping/traceroute procedure and Section 3 and Section 4 125 discusses simple extensions needed to solve the problem. 127 2. Problem with Nil FEC 129 The purpose of Nil FEC as described in [RFC8029] is to ensure hiding 130 of transit tunnel information and in some cases to avoid false 131 negatives when the FEC information is not known. 133 The MPLS ping/traceroute packet consists of only single Nil FEC 134 corresponding to the complete label stack irrespective of number of 135 segments in the label-stack. When router in the label-stack path 136 receives MPLS ping/traceroute packets, there is no definite way to 137 decide on whether its egress or transit since Nil FEC does not carry 138 any information. So there is high possibility that the packet may be 139 mis-forwarded to incorrect destination but the ping/traceroute might 140 still show success. 142 To avoid this problem, there is a need to add additional information 143 in the MPLS ping/traceroute packet along with Nil FEC that will help 144 to do needed validation on each router of the label-stack path and 145 sends proper information to ingress router on success and failure. 147 Thus it will be useful to add egress information in ping/traceroute 148 packet that will help in validating Nil-FEC on each receiving router 149 on label-stack path to ensure the correct destination. 151 3. Egress TLV 153 The Egress object is a TLV that MAY be included in an MPLS Echo 154 Request message. Its an optional TLV and should appear before FEC- 155 stack TLV in the MPLS Echo Request packet. In case multiple Nil FEC 156 is present in Target FEC Stack TLV, Egress TLV should be added 157 corresponding to the ultimate egress of the label-stack. It can be 158 use for any kind of path with Egress TLV added corresponding to the 159 end-point of the path. The format is as specified below: 161 0 1 2 3 162 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 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Type = TBD (EGRESS TLV) | Length | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Prefix (4 or 16 octets) | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 Type : TBD 171 Length : variable based on IPV4/IPV6 prefix. Length excludes the 172 length of Type and length field. Length will be 4 octets for IPv4 173 and 16 octets for IPv6. 175 Prefix : This field carries the valid IPv4 prefix of length 4 octets 176 or valid IPv6 Prefix of length 16 octets. It can be obtained from 177 egress of Nil FEC corresponding to last label in the label-stack or 178 SR-TE policy endpoint field [I.D-ietf-idr-segment-routing-te-policy]. 180 4. Procedure 182 This section describes aspects of LSP Ping and Traceroute operations 183 that require further considerations beyond [RFC8029]. 185 4.1. Sending Egress TLV in MPLS Echo Request 187 As stated earlier, when the sender node builds a Echo Request with 188 target FEC Stack TLV, Egress TLV SHOULD appear before Target FEC- 189 stack TLV in MPLS Echo Request packet. 191 Ping 192 When the sender node builds a Echo Request with target FEC Stack TLV 193 that contains a single NiL FEC corresponding to the last segment of 194 the SR-TE path, sender node MUST add a Egress TLV with prefix 195 obtained from SR-TE policy endpoint field 196 [I.D-ietf-idr-segment-routing-te-policy] to indicate the egress for 197 this Nil FEC in the Echo Request packet. In case endpoint is not 198 specified or is equal to 0, sender MUST use the prefix corresponding 199 to last segment of the SR-TE path as prefix for Egress TLV. 201 Traceroute 203 When the sender node builds a Echo Request with target FEC Stack TLV 204 that contains a single NiL FEC corresponding to complete segment-list 205 of the SR-TE path, sender node MUST add a Egress TLV with prefix 206 obtained from SR-TE policy endpoint field 207 [I.D-ietf-idr-segment-routing-te-policy] to indicate the egress for 208 this Nil FEC in the Echo Request packet. In case of multiple Nil 209 FEC, Egress TLV SHOULD be added with prefix that indicate endpoint 210 for last Nil-FEC corresponding to respective segment in label-stack. 211 In case endpoint is not specified or is equal to 0, sender MUST use 212 the prefix corresponding to the last segment endpoint of the SR-TE 213 path i.e. ultimate egress as prefix for Egress TLV. 215 ----R3---- 216 / (1003) \ 217 (1001) / \(1005) (1007) 218 R1----R2(1002) R5----R6----R7 219 \ / (1006) 220 \ (1004) / 221 ----R4---- 223 Consider the SR-TE policy configured with label-stack as 1002, 1004 , 224 1007 and end point as X on ingress router R1 to reach egress router 225 R3. Segment 1007 belongs to R3 that has prefix X configured on it 226 locally. 228 In Ping Echo Request, with target FEC Stack TLV that contains a 229 single NiL FEC corresponding to 1007, should add Egress TLV for 230 endpoint X with type as EGRESS-TLV, length depends on if X is IPv4 or 231 IPv6 address and prefix as X. 233 In Traceroute Echo Request, with target FEC Stack TLV that contains a 234 single NiL FEC corresponding to complete label-stack (1002, 1004, 235 1007) or multiple Nil-FEC corresponding to each label in label-stack, 236 should add single Egress TLV for endpoint X with type as EGRESS-TLV, 237 length depends on if X is IPv4 or IPv6 address and prefix as X or 238 endpoint of segment 1007. In case X is not present or is set to 0, 239 sender should use endpoint of segment 1007 as prefix for Egress TLV. 241 4.2. Receiving Egress TLV in MPLS Echo Request 243 No change in the processing for Nil FEC as defined in [RFC8029] in 244 Target FEC stack TLV Node that receives an MPLS echo request. 246 Additional processing done for Egress TLV on receiver node as 247 follows: 249 1. If the Label-stack-depth is greater than 0 and the Target FEC 250 Stack sub-TLV at FEC-stack-depth is Nil FEC, set Best-return-code to 251 8 ("Label switched at stack-depth") and Best-return-subcode to Label- 252 stack-depth to report transit switching in MPLS Echo Reply message. 254 2. If the Label-stack-depth is 0 and the Target FEC Stack sub-TLV at 255 FEC-stack-depth is Nil FEC then do the look up for an exact match of 256 the EGRESS TLV prefix to any of locally configured interfaces or 257 loopback addresses. 259 2a. If EGRESS TLV prefix look up succeeds, set Best-return-code to 3 260 ("Replying router is an egress for the FEC at stack-depth") and Best- 261 return-subcode to 1 to report egress ok in MPLS Echo Reply message. 263 2b. If EGRESS TLV prefix look up fails, set the Best-return-code to 264 10, "Mapping for this FEC is not the given label at stack-depth" and 265 Best-return-subcode to 1. 267 5. Backward Compatibility 269 The extension proposed in this document is backward compatible with 270 procedures described in [RFC8029]. 272 6. Security Considerations 274 TBD 276 7. IANA Considerations 278 7.1. New TLV 280 IANA need to assign new value for EGRESS TLV in the "Multi-Protocol 281 Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" 282 TLV registry [IANA]. 284 EGRESS TLV : (TBD) 286 8. Acknowledgements 288 TBD. 290 9. References 292 9.1. Normative References 294 [I.D-ietf-idr-segment-routing-te-policy] 295 Filsfils, C., Ed., Previdi, S., Ed., Talaulikar , K., 296 Mattes, P., Rosen, E., Jain, D., and S. Lin, "Advertising 297 Segment Routing Policies in BGP", draft-ietf-idr-segment- 298 routing-te-policy-09, work in progress, may 2020, 299 . 302 [I.D-ietf-spring-segment-routing-policy] 303 Filsfils, C., Talaulikar , K., Bogdanov, A., Mattes, P., 304 and D. Voyer, "Segment Routing Policy Architecture", 305 draft-ietf-spring-segment-routing-policy-08, work in 306 progress, July 2020, 307 . 310 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 311 Requirement Levels", BCP 14, RFC 2119, 312 DOI 10.17487/RFC2119, March 1997, 313 . 315 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 316 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 317 Switched (MPLS) Data-Plane Failures", RFC 8029, 318 DOI 10.17487/RFC8029, March 2017, 319 . 321 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 322 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 323 May 2017, . 325 [RFC8287] Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya, 326 N., Kini, S., and M. Chen, "Label Switched Path (LSP) 327 Ping/Traceroute for Segment Routing (SR) IGP-Prefix and 328 IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data 329 Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017, 330 . 332 9.2. Informative References 334 [IANA] IANA, "Multiprotocol Label Switching (MPLS) Label Switched 335 Paths (LSPs) Ping Parameters", 336 . 339 Authors' Addresses 341 Deepti N. Rathi (editor) 342 Juniper Networks Inc. 343 Exora Business Park 344 Bangalore, KA 560103 345 India 347 Email: deeptir@juniper.net 349 Kapil Arora 350 Juniper Networks Inc. 351 Exora Business Park 352 Bangalore, KA 560103 353 India 355 Email: kapilaro@juniper.net 357 Shraddha Hegde 358 Juniper Networks Inc. 359 Exora Business Park 360 Bangalore, KA 560103 361 India 363 Email: shraddha@juniper.net 365 Zafar Ali 366 Cisco Systems, Inc. 368 Email: zali@cisco.com 370 Nagendra Kumar Nainar 371 Cisco Systems, Inc. 373 Email: naikumar@cisco.com