idnits 2.17.1 draft-rathi-mpls-egress-tlv-for-nil-fec-05.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 (July 4, 2021) is 1021 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: January 5, 2022 Juniper Networks Inc. 6 Z. Ali 7 N. Nainar 8 Cisco Systems, Inc. 9 July 4, 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-05 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 January 5, 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 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 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 87 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 88 9.2. Informative References . . . . . . . . . . . . . . . . . 9 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 91 1. Introduction 93 Segment routing supports the creation of explicit paths using 94 adjacency- sids, node-sids, and anycast-sids. In certain usecases, 95 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 its 153 egress or transit since Nil FEC does not carry any information. So 154 there is high possibility that the packet may be mis-forwarded to 155 incorrect destination but the ping/traceroute might still return 156 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 = TBD (EGRESS TLV) | Length | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Prefix (4 or 16 octets) | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 Type : TBD 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 3 289 ("Replying router is an egress for the FEC at stack-depth") and Best- 290 return-subcode to 1 to report egress ok in MPLS Echo Reply message. 292 2b. If EGRESS TLV prefix look up fails, set the Best-return-code to 293 10, "Mapping for this FEC is not the given label at stack-depth" and 294 Best-return-subcode to 1. 296 5. Backward Compatibility 298 The extension proposed in this document is backward compatible with 299 procedures described in [RFC8029]. Router that does not support 300 EGRESS-TLV, will ignore it and use current NIL-FEC procedures 301 described in [RFC8029]. 303 When the egress node in the path does not support the extensions 304 proposed in this draft egress validation will not be done and Best- 305 return-code as 3 ("Replying router is an egress for the FEC at stack- 306 depth") and Best-return- subcode as 1 to report egress ok will be set 307 in MPLS Echo Reply message. 309 When the transit node in the path does not support the extensions 310 proposed in this draft Best-return-code as 8 ("Label switched at 311 stack-depth") and Best-return-subcode as Label-stack-depth to report 312 transit switching will be set in MPLS Echo Reply message. 314 6. Security Considerations 316 TBD 318 7. IANA Considerations 320 7.1. New TLV 322 IANA need to assign new value for EGRESS TLV in the "Multi-Protocol 323 Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" 324 TLV registry [IANA]. 326 EGRESS TLV : (TBD) 328 8. Acknowledgements 330 TBD. 332 9. References 334 9.1. Normative References 336 [I.D-ietf-idr-segment-routing-te-policy] 337 Filsfils, C., Ed., Previdi, S., Ed., Talaulikar , K., 338 Mattes, P., Rosen, E., Jain, D., and S. Lin, "Advertising 339 Segment Routing Policies in BGP", draft-ietf-idr-segment- 340 routing-te-policy-09, work in progress, may 2020, 341 . 344 [I.D-ietf-spring-segment-routing-policy] 345 Filsfils, C., Talaulikar , K., Bogdanov, A., Mattes, P., 346 and D. Voyer, "Segment Routing Policy Architecture", 347 draft-ietf-spring-segment-routing-policy-08, work in 348 progress, July 2020, 349 . 352 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 353 Requirement Levels", BCP 14, RFC 2119, 354 DOI 10.17487/RFC2119, March 1997, 355 . 357 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 358 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 359 Switched (MPLS) Data-Plane Failures", RFC 8029, 360 DOI 10.17487/RFC8029, March 2017, 361 . 363 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 364 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 365 May 2017, . 367 [RFC8287] Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya, 368 N., Kini, S., and M. Chen, "Label Switched Path (LSP) 369 Ping/Traceroute for Segment Routing (SR) IGP-Prefix and 370 IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data 371 Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017, 372 . 374 9.2. Informative References 376 [IANA] IANA, "Multiprotocol Label Switching (MPLS) Label Switched 377 Paths (LSPs) Ping Parameters", 378 . 381 Authors' Addresses 383 Deepti N. Rathi (editor) 384 Juniper Networks Inc. 385 Exora Business Park 386 Bangalore, KA 560103 387 India 389 Email: deeptir@juniper.net 391 Kapil Arora 392 Juniper Networks Inc. 393 Exora Business Park 394 Bangalore, KA 560103 395 India 397 Email: kapilaro@juniper.net 399 Shraddha Hegde 400 Juniper Networks Inc. 401 Exora Business Park 402 Bangalore, KA 560103 403 India 405 Email: shraddha@juniper.net 407 Zafar Ali 408 Cisco Systems, Inc. 410 Email: zali@cisco.com 412 Nagendra Kumar Nainar 413 Cisco Systems, Inc. 415 Email: naikumar@cisco.com