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