idnits 2.17.1 draft-ietf-mpls-egress-tlv-for-nil-fec-02.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 (December 3, 2021) is 846 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: June 6, 2022 Juniper Networks Inc. 6 Z. Ali 7 N. Nainar 8 Cisco Systems, Inc. 9 December 3, 2021 11 Egress TLV for Nil FEC in Label Switched Path Ping and Traceroute 12 Mechanisms 13 draft-ietf-mpls-egress-tlv-for-nil-fec-02 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 There is a possibility that all intermediate or transit nodes may not 21 have been upgraded to support these validation procedures. A simple 22 mpls ping and traceroute mechanism comprises of ability to traverse 23 any path without having to validate the control plane state. RFC 24 8029 supports this mechanism with Nil FEC. The procedures described 25 in RFC 8029 are mostly applicable when the Nil FEC is used as 26 intermediate FEC in the label stack. When all labels in label stack 27 are represented using single Nil FEC, it poses some challenges. 29 This document introduces new TLV as additional extension to exisiting 30 Nil FEC and describes mpls ping and traceroute procedures using Nil 31 FEC with this additional extensions to overcome these challenges. 33 Requirements Language 35 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 36 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 37 "OPTIONAL" in this document are to be interpreted as described in 38 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 39 capitals, as shown here. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at https://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on June 6, 2022. 58 Copyright Notice 60 Copyright (c) 2021 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (https://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 2. Problem with Nil FEC . . . . . . . . . . . . . . . . . . . . 4 77 3. Egress TLV . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 4. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 5 79 4.1. Sending Egress TLV in MPLS Echo Request . . . . . . . . . 5 80 4.2. Receiving Egress TLV in MPLS Echo Request . . . . . . . . 6 81 5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 7 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 84 7.1. New TLV . . . . . . . . . . . . . . . . . . . . . . . . . 7 85 7.2. New Return code . . . . . . . . . . . . . . . . . . . . . 8 86 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 88 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 89 9.2. Informative References . . . . . . . . . . . . . . . . . 9 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 92 1. Introduction 94 Segment routing supports the creation of explicit paths using 95 adjacency- sids, node-sids, and anycast-sids. In certain usecases, 96 the TE paths are built using mechanisms described in 97 [I.D-ietf-spring-segment-routing-policy] by stacking the labels that 98 represent the nodes and links in the explicit path. When the SR-TE 99 paths are built by the controller, the head-end routers may not have 100 the complete database of the network and may not be aware of the FEC 101 associated with labels that are used in the label stack. A very 102 useful Operations And Maintenance (OAM) requirement is to be able to 103 ping and trace these paths. A simple mpls ping and traceroute 104 mechanism comprises of ability to traverse the SR-TE path without 105 having to validate the control plane state. 107 MPLS ping and traceroute mechanism as described in [RFC8029] and 108 related extensions for SR as defined in [RFC8287] is very useful to 109 precisely validate the control plane and data plane synchronization. 110 It also provides ability to traverse multiple ECMP paths and validate 111 each of the ECMP paths. Use of Target FEC requires all nodes in the 112 network to have implemented the validation procedures. All 113 intermediate nodes may not have been upgraded to support validation 114 procedures. In such cases, it is useful to have ability to traverse 115 the paths using ping and traceroute without having to obtain the 116 Forwarding Equivalence Class (FEC) for each label.[RFC8029] supports 117 this mechanism with FECs like Nil FEC and Generic FEC. 119 Generic IPv4 and IPv6 FEC are used when the protocol that is 120 advertising the label is unknown. The information that is carried in 121 Generic FEC is the IPv4 or IPv6 prefix and prefix length. Thus 122 Generic FEC types perform an additional control plane validation. 123 But the details of generic FEC and validation procedures are not very 124 detailed in the [RFC8029]. The use-case mostly specifies inter-AS 125 VPNs as the motivation. Certain aspects of Segment Routing such as 126 anycast SIDs requires clear guidelines on how the validation 127 procedure should work. Also Generic FEC may not be widely supported 128 and if transit routers are not upgraded to support validation of 129 generic FEC, traceroute may fail. on other hand, Nil FEC consists of 130 the label and there is no other associated FEC information. NIL FEC 131 is used to traverse the path without validation for cases where the 132 FEC is not defined or routers are not upgraded to support the FECs. 133 Thus it can be used to check any combination of segments on any data 134 path. The procedures described in [RFC8029] are mostly applicable 135 when the Nil FEC is used where the Nil FEC is an intermediate FEC in 136 the label stack. When all labels in label-stack are represented 137 using single Nil FEC, it poses some challenges. 139 Section 2 discusses the problems associated with using single Nil FEC 140 in a MPLS ping/traceroute procedure and Section 3 and Section 4 141 discusses simple extensions needed to solve the problem. 143 2. Problem with Nil FEC 145 The purpose of Nil FEC as described in [RFC8029] is to ensure hiding 146 of transit tunnel information and in some cases to avoid false 147 negatives when the FEC information is unknown. 149 This draft uses single NIL FEC to represent complete label stack in 150 MPLS ping/traceroute packet irrespective of number of segments in the 151 label-stack. When router in the label-stack path receives MPLS ping/ 152 traceroute packets, there is no definite way to decide on whether it 153 is the intended egress router since Nil FEC does not carry any 154 information. So there is high possibility that the packet may be 155 mis-forwarded to incorrect destination but the ping/traceroute might 156 still return success. 158 To avoid this problem, there is a need to add additional information 159 in the MPLS ping and traceroute packet along with Nil FEC to do 160 minimal validation on egress/destination router and sends proper 161 information to ingress router on success and failure. This 162 additional information should help to report transit router 163 information to ingress/initiator router that can be used by offline 164 application to validate the traceroute path. 166 Thus addition of egress information in ping/traceroute packet will 167 help in validating Nil-FEC on each receiving router on label-stack 168 path to ensure the correct destination. It can be used to check any 169 combination of segments on any path without upgrading transit nodes. 171 3. Egress TLV 173 The Egress object is a TLV that MAY be included in an MPLS Echo 174 Request message. Its an optional TLV and should appear before FEC- 175 stack TLV in the MPLS Echo Request packet. In case multiple Nil FEC 176 is present in Target FEC Stack TLV, Egress TLV should be added 177 corresponding to the ultimate egress of the label-stack. It can be 178 use for any kind of path with Egress TLV added corresponding to the 179 end-point of the path. Explicit Path can be created using node-sid, 180 adj-sid, binding-sid etc, EGRESS TLV prefix will be derived from path 181 egress/destination and not based on labels used in the path to reach 182 the destination. The format is as specified below: 184 0 1 2 3 185 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 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Type = 28 (EGRESS TLV) | Length | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Prefix (4 or 16 octets) | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 Type : 28 (Section 7.1) 194 Length : variable based on IPV4/IPV6 prefix. Length excludes the 195 length of Type and length field. Length will be 4 octets for IPv4 196 and 16 octets for IPv6. 198 Prefix : This field carries the valid IPv4 prefix of length 4 octets 199 or valid IPv6 Prefix of length 16 octets. It can be obtained from 200 egress of Nil FEC corresponding to last label in the label-stack or 201 SR-TE policy endpoint field [I.D-ietf-idr-segment-routing-te-policy]. 203 4. Procedure 205 This section describes aspects of LSP Ping and Traceroute operations 206 that require further considerations beyond [RFC8029]. 208 4.1. Sending Egress TLV in MPLS Echo Request 210 As stated earlier, when the sender node builds a Echo Request with 211 target FEC Stack TLV, Egress TLV SHOULD appear before Target FEC- 212 stack TLV in MPLS Echo Request packet. 214 Ping 216 When the sender node builds a Echo Request with target FEC Stack TLV 217 that contains a single NiL FEC corresponding to the last segment of 218 the SR-TE path, sender node MUST add a Egress TLV with prefix 219 obtained from SR-TE policy endpoint field 220 [I.D-ietf-idr-segment-routing-te-policy] to indicate the egress for 221 this Nil FEC in the Echo Request packet. In case endpoint is not 222 specified or is equal to 0, sender MUST use the prefix corresponding 223 to last segment of the SR-TE path as prefix for Egress TLV. 225 Traceroute 227 When the sender node builds a Echo Request with target FEC Stack TLV 228 that contains a single NiL FEC corresponding to complete segment-list 229 of the SR-TE path, sender node MUST add a Egress TLV with prefix 230 obtained from SR-TE policy endpoint field 232 [I.D-ietf-idr-segment-routing-te-policy] to indicate the egress for 233 this Nil FEC in the Echo Request packet. Some implementations may 234 send multiple NilFEC but it is not really required. In case headend 235 sends multiple Nil FECs the last one should have the egress TLV. 236 When the label stack becomes zero, all Nil FEC TLVs are removed and 237 egress TLV MUST be validated from last Nil FEC In case endpoint is 238 not specified or is equal to 0 ( as in case of color-only SR-TE 239 policy), sender MUST use the prefix corresponding to the last segment 240 endpoint of the SR-TE path i.e. ultimate egress as prefix for Egress 241 TLV. 243 ----R3---- 244 / (1003) \ 245 (1001) / \(1005) (1007) 246 R1----R2(1002) R5----R6----R7(prefix X) 247 \ / (1006) 248 \ (1004) / 249 ----R4---- 251 Consider the SR-TE policy configured with label-stack as 1002, 1004 , 252 1007 and end point/destination as prefix X on ingress router R1 to 253 reach egress router R7. Segment 1007 belongs to R7 that has prefix X 254 locally configured on it. 256 In Ping Echo Request, with target FEC Stack TLV that contains a 257 single NiL FEC corresponding to 1007, should add Egress TLV for 258 endpoint/destination prefix X with type as EGRESS-TLV, length depends 259 on if X is IPv4 or IPv6 address and prefix as X. 261 In Traceroute Echo Request, with target FEC Stack TLV that contains a 262 single NiL FEC corresponding to complete label-stack (1002, 1004, 263 1007) or multiple Nil-FEC corresponding to each label in label-stack, 264 should add single Egress TLV for endpoint/destination prefix X with 265 type as EGRESS-TLV, length depends on if X is IPv4 or IPv6 address 266 and prefix as X. In case X is not present or is set to 0 ( as in 267 case of color-only SR-TE policy), sender should use endpoint of 268 segment 1007 as prefix for Egress TLV. 270 4.2. Receiving Egress TLV in MPLS Echo Request 272 No change in the processing for Nil FEC as defined in [RFC8029] in 273 Target FEC stack TLV Node that receives an MPLS echo request. 275 Additional processing done for Egress TLV on receiver node as 276 follows: 278 1. If the Label-stack-depth is greater than 0 and the Target FEC 279 Stack sub-TLV at FEC-stack-depth is Nil FEC, set Best-return-code to 280 8 ("Label switched at stack-depth") and Best-return-subcode to Label- 281 stack-depth to report transit switching in MPLS Echo Reply message. 283 2. If the Label-stack-depth is 0 and the Target FEC Stack sub-TLV at 284 FEC-stack-depth is Nil FEC then do the look up for an exact match of 285 the EGRESS TLV prefix to any of locally configured interfaces or 286 loopback addresses. 288 2a. If EGRESS TLV prefix look up succeeds, set Best-return-code to 289 36 ("Replying router is an egress for the prefix in EGRESS-TLV") 290 (Section 7.2) and Best-return-subcode to 1 to report egress ok in 291 MPLS Echo Reply message. 293 2b. If EGRESS TLV prefix look up fails, set the Best-return-code to 294 10, "Mapping for this FEC is not the given label at stack-depth" and 295 Best-return-subcode to 1. 297 5. Backward Compatibility 299 The extension proposed in this document is backward compatible with 300 procedures described in [RFC8029]. Router that does not support 301 EGRESS-TLV, will ignore it and use current NIL-FEC procedures 302 described in [RFC8029]. 304 When the egress node in the path does not support the extensions 305 proposed in this draft egress validation will not be done and Best- 306 return-code as 3 ("Replying router is an egress for the FEC at stack- 307 depth") and Best-return- subcode as 1 to report egress ok will be set 308 in MPLS Echo Reply message. 310 When the transit node in the path does not support the extensions 311 proposed in this draft Best-return-code as 8 ("Label switched at 312 stack-depth") and Best-return-subcode as Label-stack-depth to report 313 transit switching will be set in MPLS Echo Reply message. 315 6. Security Considerations 317 TBD 319 7. IANA Considerations 321 7.1. New TLV 323 IANA need to assign new value for EGRESS TLV in the "Multi-Protocol 324 Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" 325 in "TLVs" sub-registry [IANA]. 327 +-------+-------------+---------------+ 328 | Value | Description | Reference | 329 +-------+-------------+---------------+ 330 | 28 | EGRESS TLV | Section 3 | 331 | | | This document | 332 +-------+-------------+---------------+ 334 Table 1: TLVs Sub-Registry 336 7.2. New Return code 338 IANA need to assign new Return Code for "Replying router is an egress 339 for the prefix in EGRESS-TLV" in the "Multi-Protocol Label Switching 340 (MPLS) Label Switched Paths (LSPs) Ping Parameters" in "Return Codes" 341 sub-registry. [IANA]. 343 +-------+------------------------------+---------------+ 344 | Value | Description | Reference | 345 +-------+------------------------------+---------------+ 346 | 36 | Replying router is an egress | Section 4.2 | 347 | | for the prefix in EGRESS-TLV | This document | 348 +-------+------------------------------+---------------+ 350 Table 2: Return code Sub-Registry 352 8. Acknowledgements 354 TBD. 356 9. References 358 9.1. Normative References 360 [I.D-ietf-idr-segment-routing-te-policy] 361 Filsfils, C., Ed., Previdi, S., Ed., Talaulikar , K., 362 Mattes, P., Rosen, E., Jain, D., and S. Lin, "Advertising 363 Segment Routing Policies in BGP", draft-ietf-idr-segment- 364 routing-te-policy-09, work in progress, may 2020, 365 . 368 [I.D-ietf-spring-segment-routing-policy] 369 Filsfils, C., Talaulikar , K., Bogdanov, A., Mattes, P., 370 and D. Voyer, "Segment Routing Policy Architecture", 371 draft-ietf-spring-segment-routing-policy-08, work in 372 progress, July 2020, 373 . 376 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 377 Requirement Levels", BCP 14, RFC 2119, 378 DOI 10.17487/RFC2119, March 1997, 379 . 381 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 382 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 383 Switched (MPLS) Data-Plane Failures", RFC 8029, 384 DOI 10.17487/RFC8029, March 2017, 385 . 387 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 388 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 389 May 2017, . 391 [RFC8287] Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya, 392 N., Kini, S., and M. Chen, "Label Switched Path (LSP) 393 Ping/Traceroute for Segment Routing (SR) IGP-Prefix and 394 IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data 395 Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017, 396 . 398 9.2. Informative References 400 [IANA] IANA, "Multiprotocol Label Switching (MPLS) Label Switched 401 Paths (LSPs) Ping Parameters", 402 . 405 Authors' Addresses 407 Deepti N. Rathi (editor) 408 Juniper Networks Inc. 409 Exora Business Park 410 Bangalore, KA 560103 411 India 413 Email: deeptir@juniper.net 415 Kapil Arora 416 Juniper Networks Inc. 417 Exora Business Park 418 Bangalore, KA 560103 419 India 421 Email: kapilaro@juniper.net 422 Shraddha Hegde 423 Juniper Networks Inc. 424 Exora Business Park 425 Bangalore, KA 560103 426 India 428 Email: shraddha@juniper.net 430 Zafar Ali 431 Cisco Systems, Inc. 433 Email: zali@cisco.com 435 Nagendra Kumar Nainar 436 Cisco Systems, Inc. 438 Email: naikumar@cisco.com