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