idnits 2.17.1 draft-saum-evpn-lsp-ping-extension-00.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 : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 21 characters in excess of 72. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 281 has weird spacing: '...ined in draft...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (19 May 2022) is 706 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) == Unused Reference: 'I-D.draft-tissa-nvo3-oam-fm' is defined on line 494, but no explicit reference was found in the text == Unused Reference: 'RFC7348' is defined on line 504, but no explicit reference was found in the text == Unused Reference: 'RFC9014' is defined on line 521, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-bess-evpn-lsp-ping-07 -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS WG S. Dikshit 3 Internet-Draft S. Rao 4 Intended status: Standards Track S. Easale 5 Expires: 20 November 2022 A. Dahiya 6 Aruba, HPE 7 19 May 2022 9 EVPN Mpls Ping Extension 10 draft-saum-evpn-lsp-ping-extension-00 12 Abstract 14 In an EVPN or any other VPN deployment, there is an urgent need to 15 tailor the reachability checks of the client nodes via off-box tools 16 which can be triggered from a remote Overlay end-point or a 17 centralized controller and also customize check if the knowledge 18 known is partial or incomplete. This document aims to address the 19 limitation in current standards for doing so and provides solution 20 which can be made standards in future. As an additional requirement, 21 in network border routers, there are liaison/dummy VRFs created to 22 leak routes from one network/fabric to another. There are scenarios 23 wherein an explicit reachability check for these type of VRFs is not 24 possible with existing mpls-ping mechanisms. This draft intends to 25 address this as well. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 20 November 2022. 44 Copyright Notice 46 Copyright (c) 2022 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Revised BSD License text as 55 described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Revised BSD License. 58 Table of Contents 60 1. Important Terms . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 63 4. Problem Description . . . . . . . . . . . . . . . . . . . . . 3 64 4.1. EVPN NLRI is a Complex String . . . . . . . . . . . . . . 3 65 4.2. Partial Validation Support . . . . . . . . . . . . . . . 4 66 4.3. Reachability to Liaison VRFs . . . . . . . . . . . . . . 4 67 5. Solution(s) . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 5.1. Wild Card Tlv . . . . . . . . . . . . . . . . . . . . . . 6 69 5.1.1. Description . . . . . . . . . . . . . . . . . . . . . 6 70 5.1.2. Processing . . . . . . . . . . . . . . . . . . . . . 7 71 5.2. Validation Scope Tlv . . . . . . . . . . . . . . . . . . 7 72 5.2.1. Description . . . . . . . . . . . . . . . . . . . . . 8 73 5.2.2. Processing . . . . . . . . . . . . . . . . . . . . . 8 74 5.3. EVI Sub Tlv . . . . . . . . . . . . . . . . . . . . . . . 9 75 5.3.1. Description . . . . . . . . . . . . . . . . . . . . . 10 76 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 10 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 79 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 82 10.2. Informative References . . . . . . . . . . . . . . . . . 11 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 85 1. Important Terms 87 VTEP: Virtual Tunnel End Point or Vxlan Tunnel End Point 89 RD: Route Distinguisher 91 RT: Route Target 93 LSP: Label Switched Path 95 LER: Label Edge Router 96 LSR: Label Switch Router 98 NLRI: Network Layer Reachability Information 100 EVPN: Etherenet Virtual Private Network 102 2. Introduction 104 In an EVPN or any other VPN deployment, there is an urgent need to 105 tailor the reachability checks of the client nodes via off-box tools 106 which can be triggered from a remote Overlay end-point or a 107 centralized controller and also customize check if the knowledge 108 known is partial or incomplete. This document aims to address the 109 limitation in current standards for doing so and provides solution 110 which can be made standards in future. As an additional requirement, 111 in network border routers, there are liaison/dummy VRFs created to 112 leak routes from one network/fabric to another. There are scenarios 113 wherein an explicit reachability check for these type of VRFs is not 114 possible with existing mpls-ping mechanisms. This draft intends to 115 address this as well. 117 3. Requirements Language 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 When used in lowercase, these words convey their typical use in 124 common language, and they are not to be interpreted as described in 125 [RFC2119]. 127 4. Problem Description 129 This document intends to solve multiple problems, all related to ease 130 of serviceability, troubleshooting and provisioning. In a nut shell, 131 the solution eases out the network management of overlay network with 132 MPLS fabric for network operators and end-users. the following 133 subsections detail out the problems at hand. 135 4.1. EVPN NLRI is a Complex String 137 For overlays like EVPN, where the NLRI key is complex to remember; 138 the OAM ping (access) to a NLRI, may be difficult to achieve by 139 providing the exact prefix key. For example, an EVPN NLRI index 140 consists of list of following parameters, which typically are 141 combined to be treated as long string index, comprising of, Route 142 Type, RD, Ethernet Segment Index (ESI), Ethernet-Tag, IP-prefix, MAC- 143 IP. Instead it will be easier, if the administrator remembers few or 144 significant of the above information and remaining can be sent as 145 wild-card or dont care values. For example, the OAM trigger for LSP- 146 ping for a host 10.10.10.1 to a remote tunnel endpoint referred by IP 147 address 1.1.1.1, can be initiated a combination of Route- 148 Distinguisher, Ethernet Segment Index and Ethernet tag as wild card 149 values, thus simplifying the OAM procedures. 151 4.2. Partial Validation Support 153 The current set of OAM standards are built around validating the co- 154 relation of control plane and dataplane information. For example, 155 set of same-prefixes which are published by more than two external 156 border routers, only one of them may make it to the Routing table of 157 other routers (receiving these routes). 159 * The remote OAM check may want to check all the routes published 160 into the routing table or may want to check all the routes in the 161 protocol fib. 163 * This selective mechanism to fetch information is not supported for 164 Overlays via standard OAM methods. 166 As mentioned above, the choice of validating control plane and 167 dataplane for an NLRI ping is not in place in the EVPN( or any 168 Overlay) OAM specifications [I-D.draft-ietf-bess-evpn-lsp-ping]. 169 When the routing data is huge, and the control plane protocol are in 170 the middle of churn, it is difficult to ascertain if the remote 171 network in remote site is in steady state or not. An overlay ping is 172 should help validate only the data plane and forgo any control plane 173 validation, so that the control plane churn is not adding to the CPU 174 cycles for the routing or OAM entities like processes and daemons 175 running on the remote vteps. 177 To extend this problem state further, when admin access to vtep (in a 178 non-local operator domain) is not possible, control plane information 179 can be obtained by leveraging the control plane options only. Thus 180 providing a side-view of the protocol rib on the remote device. 182 4.3. Reachability to Liaison VRFs 184 In a typical VPN deployments between branch offices, or a Datacenter 185 deployment in an enterprise, be it MPLS or Vxlan fabric, the border 186 routers of the fabric cater to terminating or relaying of multi- 187 tenancy across fabric. That is, border routers are provisioned with 188 routing and/or bridging-domains for clients while also extending it 189 beyond the geography or site. The border routers are provisioned 190 with stitching of inter-site tunnels/Overlays. 192 To simplify configuration and provisioning of overlays, a dedicated 193 VRF is created to ensure all routes learnt from external network 194 (from various client VRFs) over, lets say, BGP-MPLS L3VPN peering, 195 can be de-multiplexed or leaked into a single VRF which is leveraged 196 as a dedicated VRF for learnings from external network. This VRF is 197 used by the intra fabric constructs as a client VRF. For example, in 198 a Vxlan fabric, this is vrf is one of the tenant VRFs which a 199 rightful mapping to EVPN constructs like EVI( for example VNI). This 200 client VRF does not require any interface configuration, as the 201 purpose of this VRF is to act as a liaison for the external routes. 203 Since there is no ip address( layer 3 interface) configured on this 204 VRF, its not possible to check the state of the VRF on the border 205 router via OAM methods. The state of VRF can be defined as following 207 * Working Configuration that is, VRF is operationally and 208 administratively UP and WORKING 210 * Network Reachability, that is, VRF is reachable via remote fabric 211 routers like Vteps or LSR or LER routers 213 * Existing OAM tools DO NOT provide enough ammunition to address 214 this use case. 216 If there is no route leaked into the VRF, the BR will not form a 217 tunnel with any other Vtep in the site. Hence an OAM check to reach 218 out to the VRF will not work even though the VRF is up and working. 220 5. Solution(s) 222 The EVPN extension for MPLS OAM is being driven by 223 [I-D.draft-ietf-bess-evpn-lsp-ping], and does not resolves the 224 problem mentioned above. 226 This document proposes a three new TLVs which an Overlay OAM PDU like 227 mpls ping, that can carry to fill up the gap with the rightful or 228 optimal information to the remote tunnel end points 230 * dont care option 232 * mode of validation 234 * liaison vrf information. 236 These PDUs are described for an MPLS EVPN fabric, but can be 237 generalized for any EVPN fabric per se 239 * Wild Card List TLV 240 * Validation TLV 242 * EVI Sub Tlv 244 5.1. Wild Card Tlv 246 The Wild Card Tlv addresses the problem described in section 247 Section 4.1. 249 (1) It Carries the information regarding the fields (TLVs or sub 250 TLVs), which need to be ignored on processing in mpls lsp ping 251 PDU. 253 (2) For example, if an OAM ping to a prefix does not requires any RD 254 (Route-Distinguisher) validation, then RD value, to be carried 255 in IP prefix TLV; can be indicated as wild-card (dont care). 257 * The control-plane validation of the lsp-ping then should 258 ignore the RD value in the TLV, and respond back as success 259 even if there is atleast one NLRI which complies with other 260 attributes (not set as wild card). 262 5.1.1. Description 264 The following diagram shows the wild-card list TLV and the following 265 table, describe the fields, followed by the receive side processing 267 0 1 2 3 4 268 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 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Type | Length | Sub-TLV Type | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Bits corresponding to fields in Sub-TLV | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 Field | Description 276 ============================================================ 277 Type | Type field can be newly defined as a proprietary one. 278 | 279 Length | length of the TLV 280 | 281 Sub-TLV Type | Sub-TLV type value as defined in draft-ietf-bess-evpn-lsp-ping 282 | 283 Bitmap | Maps to field(s) inside Sub-TLV. The bit-map indicates which field(s) 284 | in the Sub-TLV type is carried as wild card. 286 Figure 1: Figure 1: WILD CARD TLV 288 NOTE: The bitmap for fields is very specific to the sub-tlv. The 289 assumption is that there are no more than 32 unique fields carried in 290 mpls ping packet across all sub tlvs. For example, in 291 [I-D.draft-ietf-bess-evpn-lsp-ping], if for a EVPN MAC Sub-TLV, the 292 RD is to set as wild card, then the Sub-TLV-Type carries a value 2 as 293 defined in [RFC7432] and bitmap has 1st bit set indicating the 1st 294 field of the TLV is RD. 296 5.1.2. Processing 298 (1) If the receiving BGP peer does not supports the wild-card list 299 TLV, 301 * it ignores the TLV while processing other information carried 302 in sub-TLVs 304 (2) If the receiving BGP peer support wild-card-list TLV but does 305 not supports the wild-card ignorance of the field for validating 306 the OAM request 308 (a) It responds back the error defined in [RFC4379] 310 (b) The error code which is to be leveraged is '2' which 311 represent the error: 'One or more of the TLVs was not 312 understood'. 314 (3) if the receiving BPG peer supports wild-card list TLV, then, 316 (a) it extracts the information and maps it to the 317 corresponding fields in other sub-TLVs as carried in the 318 OAM message (MPLS LSP ping or any other fabric OAM). 320 (b) It Ignores the value carried in those fields for performing 321 Control-plane or Dataplane Validation. 323 (c) Then, responds back with appropriate messages with errors 324 or otherwise as described in 325 [I-D.draft-ietf-bess-evpn-lsp-ping]. 327 5.2. Validation Scope Tlv 329 The validation Scope TLV addresses the problem mentioned in section 330 Section 4.2. 332 (1) It defines the type validation to be done for the OAM mpls ping 333 PDU at the receiving end before a response can be corroborated 334 and sent back to the sender 336 (2) The validation types are defined as follows 338 (a) Dataplane Validation: Validating the parameters which 339 matter to the FIB (forwarding information base) or 340 routing/switching/bridging table 342 (b) Control Plane Validation: Validating parameters which are 343 matter to the protocol(s) producing those routes. For 344 example, validating the carried parameters against the 345 protocol(s) RIB (routing information base). This operation 346 can be CPU intensive and can impact the control plane 347 processing 349 (c) Both Control plane and Dataplane Validation: Typically 350 performed to sanitize the network in a new-installation or 351 post/pre upgrades when the network is in steady state and 352 routers/switches in contention are not experiencing 353 protocol churns. 355 5.2.1. Description 357 The following diagram shows the wild-card list TLV and the following 358 table, describe the fields 360 0 1 2 3 4 361 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 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Type | Length | Validation Type | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 Field | Description 367 ====================================================================== 368 Type | Type field can be newly defined as a proprietary one. 369 | 370 Length | Length of the TLV 371 | 372 Validation type | Three values for the validation as of now: 373 | 0 Both Control plane and Dataplane Validation (DEFAULT) 374 | 1 Only Control plane Validation 375 | 2 Only Data plane Validation 377 Figure 2: Figure 2: Validation Scope TLV 379 5.2.2. Processing 381 (1) If the receiving BGP peer does not supports the Validation TLV, 382 * it ignores the TLV while processing other information carried 383 in sub-TLVs 385 * Alternatively, It responds back with the error defined in 386 [RFC4379], 388 (2) If the receiving BGP peer does supports the Validation TLV but 389 does not supports the non-default mode (1 and 2), it does the 390 validation as described in the standard document, that is the 391 default mode (both control plane and dataplane validation) in 392 [I-D.draft-ietf-bess-evpn-lsp-ping]. 394 (3) If receiving side supports Validation TLV and all its modes, it 395 performs the validation only in the requested mode: 397 * Both Control plane and dataplane 399 * Only Control Plane 401 * Only Dataplane 403 5.3. EVI Sub Tlv 405 The EVI Sub Tlv addresses the issues mentioned in the section 406 Section 4.3. 408 This solution proposes a new Object/TLV which carries the EVI 409 (Virtual Network Identifier) information, thus ensuring that 410 following tools and/or action-sets can be supported: 412 (1) Ping or path tracing to check the configuration of an EVI on a 413 remote Vtep 415 (2) Ping to check VRF configuration (mapped to an EVI) on remote 416 Vtep, 418 * even though no layer-3 configuration is enable against that 419 VRF 421 (3) Ping to check VRF configuration (mapped to an EVI) on remote 422 Vtep, 424 * For which EVPN tunnel not been provisioned yet 426 The EVI values carried in the EVI Sub TLV can be user-defined or 427 derived from underlaying fabric idenfier for the EVI. 429 * For mpls fabric the EVI values can be MPLS labels (mapped to the 430 VRFs), whereas, 432 * For other encapsulations like Vxlan (GUE, Geneve, GPE), the EVI 433 value should be the VNI (mapped to the VRFs). 435 5.3.1. Description 437 0 1 2 3 4 438 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 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | Type | Length | EVI Identifier | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | EVI Identifier (continued) | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 Type: 1 Octet: Type field can be newly defined as a proprietary one. 446 Length: 1 Octet: Defines the length of the Value field. 447 Value: 6 Octets: EVI identifier. 449 Figure 3: Figure 2: Validation Scope TLV 451 This TLV aligns generically with any Overlay OAM-ping, agnostic to a 452 fabric used in the deployment (Vxlan, MPLS, GUE, Geneve, GPE). This 453 TLV can be integrated into OAM tools of any underlying fabric. For 454 example, the EVI identifier for MPLS will be 4-octets. Hence length 455 field will carry '4' as the length. 457 NOTE: Nil FEC described in [RFC8029], can also be leveraged for the 458 ping when the underneath fabric is MPLS. 460 6. Backward Compatibility 462 Backward Compatibility for non-support nodes is as per the following 463 standards already defined in [RFC7606], that, BGP speaker should 464 discard the unsupported TLV types 466 7. Security Considerations 468 This document inherits all the security considerations discussed in 469 [I-D.draft-ietf-bess-evpn-lsp-ping]. 471 8. IANA Considerations 473 This document inherits all the IANA considerations discussed in 474 [I-D.draft-ietf-bess-evpn-lsp-ping]. 476 9. Acknowledgements 478 10. References 480 10.1. Normative References 482 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 483 Requirement Levels", BCP 14, RFC 2119, March 1997, 484 . 486 10.2. Informative References 488 [I-D.draft-ietf-bess-evpn-lsp-ping] 489 Jain, P., "LSP-Ping Mechanisms for EVPN and PBB-EVPN", 490 Work in Progress, Internet-Draft, 8029, February 2022, 491 . 494 [I-D.draft-tissa-nvo3-oam-fm] 495 Senevirathne, T., "NVO3 Fault Managemen", Work in 496 Progress, Internet-Draft, draft-tissa-nvo3-oam-fm-04, May 497 2017, . 500 [RFC4379] Kompella, K., "Detecting Multi-Protocol Label Switched 501 (MPLS) Data Plane Failures", RFC 4379, February 2006, 502 . 504 [RFC7348] Mahalingam, M., "Virtual eXtensible Local Area Network 505 (VXLAN): A Framework for Overlaying Virtualized Layer 2 506 Networks over Layer 3 Networks", RFC 7348, August 2014, 507 . 509 [RFC7432] Sajassi, A., "BGP MPLS-Based Ethernet VPN", RFC 7432, 510 February 2015, 511 . 513 [RFC7606] Chen, E., "Revised Error Handling for BGP UPDATE 514 Messages", RFC 7606, August 2015, 515 . 517 [RFC8029] Kompella, K., "Detecting Multi-Protocol Label Switched 518 (MPLS) Data Plane Failures", RFC 8029, February 2006, 519 . 521 [RFC9014] Rabadan, J., "Interconnect Solution for Ethernet VPN 522 (EVPN) Overlay Networks", RFC 9014, May 2021, 523 . 525 Authors' Addresses 527 Saumya Dikshit 528 Aruba Networks, HPE 529 Mahadevpura 530 Bangalore 560 048 531 Karnataka 532 India 533 Email: saumya.dikshit@hpe.com 535 Srinath Rao 536 Aruba Networks, HPE 537 Email: srinath.krishnarao@hpe.com 539 Santosh Easale 540 Aruba Networks, HPE 541 Email: santosh.easale@hpe.com 543 Ashwini Dahiya 544 Aruba Networks, HPE 545 Email: ashwini.dahiya@hpe.com