idnits 2.17.1 draft-kumar-nvo3-overlay-ping-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 (January 15, 2014) is 3754 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: 'RFC3031' is defined on line 599, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-nvo3-framework-04 ** Downref: Normative reference to an Informational draft: draft-ietf-nvo3-framework (ref. 'I-D.ietf-nvo3-framework') ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) ** Obsolete normative reference: RFC 6424 (Obsoleted by RFC 8029) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 nvo3 N. Kumar 3 Internet-Draft C. Pignataro 4 Intended status: Standards Track D. Rao 5 Expires: July 19, 2014 Cisco Systems, Inc. 6 S. Aldrin 7 Huawei Technologies, Inc. 8 January 15, 2014 10 Detecting NVO3 Overlay Data Plane failures 11 draft-kumar-nvo3-overlay-ping-01 13 Abstract 15 This document describes a simple and efficient mechanism to perform 16 L2 or L3 VN Context validation and to detect any data plane failures 17 in IPv4 or IPv6 based overlay network providing L2 or L3 virtualized 18 network. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on July 19, 2014. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 56 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4.1. Return Code and Return Subcode . . . . . . . . . . . . . 4 59 4.2. TLV Format . . . . . . . . . . . . . . . . . . . . . . . 5 60 4.2.1. Target Object TLV . . . . . . . . . . . . . . . . . . 5 61 4.2.2. Downstream Detailed Mapping Extension . . . . . . . . 5 62 4.2.3. Multipath Information Encoding . . . . . . . . . . . 6 63 5. NVO3 Echo Packet Indicator . . . . . . . . . . . . . . . . . 7 64 5.1. When the core is IPv6 network . . . . . . . . . . . . . . 7 65 5.2. When the core is IPv4 network . . . . . . . . . . . . . . 8 66 6. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 8 67 6.1. Sending NVO3 Echo Request . . . . . . . . . . . . . . . . 8 68 6.2. Receiving NVO3 Echo Request . . . . . . . . . . . . . . . 8 69 6.2.1. Transit Node procedure . . . . . . . . . . . . . . . 9 70 6.2.2. Edge Node procedure . . . . . . . . . . . . . . . . . 10 71 6.3. Sending NVO3 Echo Reply . . . . . . . . . . . . . . . . . 10 72 6.4. Receiving NVO3 Echo Reply . . . . . . . . . . . . . . . . 11 73 6.5. Dealing with Equal-Cost-Multi-Path (ECMP) . . . . . . . . 11 74 7. Connectivity verification between Tenant system . . . . . . . 12 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 76 8.1. Message Types, Reply Modes, Return Codes . . . . . . . . 12 77 8.2. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 79 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13 80 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 82 11.2. Informative References . . . . . . . . . . . . . . . . . 13 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 85 1. Introduction 87 I.D-ietf-nvo3-framework [I-D.ietf-nvo3-framework] specifies a 88 framework that defines mechanism to support large scale network 89 virtualization by connecting L2 or L3 virtualized network over L3 90 tunnels. Various tunneling options like IPv4, IPv6 or MPLS can be 91 used in underlying network. 93 Section 3.8 of [I.D-ietf-nvo3-dataplane-requirement] specifies the 94 requirement of OAM tool that performs connectivity verification and 95 fault isolation along with revealing ECMP paths between NVE nodes. 96 While the mechanism described in RFC4379 [RFC4379] helps with 97 satisfying this OAM requirement when MPLS tunnel is used, there is no 98 native way to achieve the same when IPv4 or IPv6 is used as tunneling 99 option. 101 This document describes a simple and efficient mechanism to perform 102 L2 or L3 VN Context validation and to detect any data plane failures 103 in IPv4 or IPv6 overlay network by re-purposing and extending MPLS 104 Ping mechanism defined in RFC4379 [RFC4379]. This document also 105 describes the mechanism to reveal all available paths (multi path) 106 between any ingress and egress NVE nodes. 108 2. Requirements notation 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [RFC2119]. 114 3. Terminology 116 L2 VN: Layer 2 Virtual Network 118 L3 VN: Layer 3 Virtual Network 120 NVE: Network Virtualization Edge 122 ECMP: Equal Cost multiple path 124 4. Packet Format 126 NVO3 PATH Ping packet is a IPv4 or IPv6 UDP packet and the basic 127 structure of the packet remains the same as mentioned in Section 3 of 128 RFC4379 [RFC4379]. 130 This document introduces a new flag in Global Flags field defined in 131 RFC4379 [RFC4379]. The new format of the Global Flags field is: 133 0 1 134 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | MBZ |N|T|V| 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 The V flag is described in RFC4379 [RFC4379] and T flag is described 140 in RFC6425 [RFC6425]. 142 The N flag (NVO3 PATH Ping) MUST be set in echo request and reply 143 packet only when it is used to validate NVO3 Path. 145 The Message Type is one of the following: 147 Value Meaning 148 ----- ------- 149 11 NVO3 Echo Request 150 12 NVO3 Echo Reply 152 The Reply Mode can be one of the following: 154 Value Meaning 155 ----- ------- 156 11 Do not Reply 157 12 Reply via IPv4/IPv6 UDP packet 159 Return codes and Subcodes are described in section 4.1. 161 The Sender's Handle, Sequence Number, TimeStamp sent and TimeStamp 162 Received field are as mentioned in Section 3 of RFC4379 [RFC4379]. 164 The TLV format is same as mentioned in [RFC4379] and this document 165 introduce a new TLV described later. 167 4.1. Return Code and Return Subcode 169 Responder uses Return code field to reply with validity check or any 170 error message to Initiator. It doesnt carry any meaning in Echo 171 Request and should be set as zero. 173 The Return Code can be one of the following: 175 Value Meaning 176 ----- ------- 177 100 No Return Code 178 101 Malformed Echo Request Received 179 102 One or more TLVs not understood 180 103 Egress for the Target 181 104 No control plane mapping for the Target Object 182 105 Downstream Detailed Mapping mismatch 183 108 Packet-Forward-OK 185 The Return Subcode contains the pointer in Target Object TLV for 186 which the Replying node doesnt have a control plane mapping. For 187 example, when NVE receives Target Object TLV with multiple Sub-TLVs 188 and if NVE doesnt have an entry for second Sub-TLV should include 2 189 as RSC value. 191 4.2. TLV Format 193 The document introduces the below list of TLVs used in NVO3 Echo 194 packets: 196 Type Value Field 197 ------ ----------- 198 101 Target Object 200 4.2.1. Target Object TLV 202 Target Object TLV is a list of Sub-TLVs that carries the element 203 against which the path or control plane validation is done. 205 This document defines the below Target Object Sub-TLVs: 207 Sub-Type Length Value Field 208 -------- ------ ----------- 209 1 5 IPv4 prefix 210 2 17 IPv6 Prefix 211 3 variable L2 VN ID 212 4 variable L3 VN ID 214 NVO3 ECHO Request MUST have a Target Object TLV with atleast one Sub- 215 TLV which describe the egress node about the element to be validated. 217 For example, if NVE X wanted to verify that MAC M1 is associated with 218 VN ID VN1, it carries relevant information like VN ID and the MAC 219 address in Sub-TLV type 3 and send to egress NVE. Egress NVE on 220 receiving NVO3 Echo Request will validate the Target Object and will 221 reply back with respective Return Code. 223 New Sub-TLVs can be proposed as and when required in future. 225 4.2.2. Downstream Detailed Mapping Extension 227 This document extends the Downstream Detailed Mapping TLV defined in 228 Section 3.3 of RFC6424 [RFC6424] to be used in NVO3 scenarios with 229 IPv4 or IPv6 based core network. This document introduces a new DS 230 flag and the format is as below: 232 0 1 2 3 4 5 6 7 233 +-+-+-+-+-+-+-+-+ 234 |Rsvd(MBZ)|P|I|N| 235 +-+-+-+-+-+-+-+-+ 237 Flag Name and Meaning 238 ---- ---------------- 239 P Set when used in NVO3 Ping 241 The P flag (NVO3 Path ping) MUST be set in Downstream Detailed 242 Mapping TLV only when it is used in NVO3 scenarios. When P flag is 243 set, I flag MUST NOT be set. 245 For simplicity, The DDMAP with N flag set in DS flag will be referred 246 as NVO3 DDMAP in this document. 248 This document also defines the below new multipath types to be used 249 in NVO3 Path ping. 251 Type Meaning Multipath information 252 -------- -------------- ----------------------- 253 11 UDP Port Mask UDP Port and bit mask 254 12 Flow Label Mask IPv6 Flow label and bit mask 256 Multipath Information 258 UDP port or IPv6 Flow label range encoded according to the 259 Multipath type. The next section explains the encoding details. 261 4.2.3. Multipath Information Encoding 263 Based on the Multipath type, the Multipath Information encodes Flow 264 label range or UDP port range that will excercise each path. The 265 Multipath encoding follows the same procedure specifies in 266 Section 3.3.1 of RFC4379 [RFC4379]. For completeness, it is 267 explained in this document with UDP port range and IPv6 FLow label 268 range. 270 Multipath type 1 encodes UDP port range. The UDP prefix is formatted 271 as a base UDP port value with non-prefix low-order bits set to zero. 272 Since the UDp port is 16 bits, the leading 16 bits are set as zeros. 273 The maximum prefix (including leading zeros) length can be 27. 274 Following the prefix is a mask of length 2^(32-prefix-length) bits. 275 Each bit set to one represents a valid UDP port. UDP port values of 276 all the odd numbers between 32704 and 3267 would be encoded as below: 278 0 1 2 3 279 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 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0| 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 |0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1| 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 |0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1| 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 Multipath type 2 encoded IPv6 Fow label range. The formatting is as 289 mentioned above for UDP port range except that the leading zeros are 290 set for leading 8 bits. 292 If the received Multipath Information is non-null, the UDP ports or 293 IPv6 Flow labels MUST be picked from the set provided. if the range 294 in received set cannot be mapped to a particular downstream 295 interface, the type MUST be set to 0 for that interface while 296 replying. If the received Multipath type is null, the type MUST be 297 set to 0 while replying. 299 5. NVO3 Echo Packet Indicator 301 Unlike MPLS LSP Echo, the IP destination address in NVO3 Echo packet 302 will be the actual destination of egress node and this raises a need 303 to have an OAM indicator that can be used by transit nodes to 304 differentiate between NVO3 Echo packet and data packet. This 305 document explains the same as below: 307 5.1. When the core is IPv6 network 309 This document proposes the below IPv6 Extension header and the format 310 is as below: 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Next Header | Hdr Ext Len |R|R|R|R|R|R|R|R|R|R|R|R|R|R|R|N| 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | | 316 . Sub-TLVs . 317 | | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 N flag 322 NVO3 OAM Indicator 324 Any node on initiating NVO3 Echo Request MUST include IPv6 OAM 325 Extension Header with NVO3 OAM flag set. Any node on replying back 326 with NVO3 Echo Reply MUST include IPv6 OAM Extension Header with NVO3 327 OAM flag set. Any transit node on receiving IPv6 destinated packet 328 with TTL=1 SHOULD interpret the payload as NVO3 ECHO packet if IPv6 329 OAM Extension header is present. 331 5.2. When the core is IPv4 network 333 Any transit node on receiving IPv4 destinated packet with TTL=1 334 SHOULD interpret the payload as NVO3 ECHO packet if UDP port is 3503. 336 6. Theory of Operation 338 NVO3 Echo Request and Reply packet are UDP packet with destination 339 port as 3503. This section describes the procedure in Initiating and 340 responding nodes. 342 6.1. Sending NVO3 Echo Request 344 Initiator MUST include the respective Sub-TLV for the target(s) to be 345 validated (L2 or L3 VNI or NVE address) in Target Object TLV. It 346 also MUST set the N flag in Global Flags (Section 4) and set the 347 message type as 11. The Reply mode is set to the desired mode ( type 348 11 or 12); Return code and Return Subcode are set to zero. The 349 Sender's Handle and Sequence number are set by Initiator. 351 The source UDP port can be choosen by the Initiator and the 352 destination UDP port is set to 3503. The IP header is set as 353 follows: the source IP address is a routable address of the sender; 354 the destination IP address is the target egress NVE address. When 355 the core is IPv6 network, Initiator MUST include IPv6 OAM Extension 356 header. 358 In ping mode (Connectivity check), the IP TTL is set to 255. In 359 traceroute mode (Fault isolation), the IP TTL is set successively 360 from 1 and MUST stop sending the Request if it receives a reply with 361 Return code 103 or 104. 363 6.2. Receiving NVO3 Echo Request 365 Sending an NVO3 Echo Request to control plane for payload processsing 366 is done by IP TTL expiration in case of IPv4 and a combination of IP 367 TTL expiration and IPv6 OAM Extension header incase of IPv6. The 368 control plane further identifies it as NVO3 Echo packet by a 369 combination of UDP destion port 3503 and N flag in Global flag field 370 (Section 4). 372 Any node on receiving NVO3 Echo Request MUST send Echo Reply with 373 Return code "Malformed Echo Request received" to Initiator if the 374 packet fails sanity check. If the sanity check for NVO3 Echo Request 375 is fine, Any node should store the below temporary variables: 377 o Interface-I: Interface over which Echo Request is received. 379 o Address-A: Local address on Interface-I. 381 o Index-I: Interface Index for upstream node interface connected to 382 Interface-I. 384 o Destination-D: Destination address of the NVO3 Echo Request. 386 6.2.1. Transit Node procedure 388 Any transit node on receiving NVO3 Echo Request should perform the 389 below: 391 1. Transit node MUST only check the first (or top) Sub-TLV and MUST 392 NOT iterate to other Sub-TLVs beneath. Ideally the first Sub-TLV 393 will be IPv4 prefix or IPv6 prefix Sub-TLV on which the transit 394 node is required to act upon. It MUST set the Return code as 395 "One or more TLVs not understood" if the first (or top) Sub-TLV 396 in Target Object TLV is not understood. 398 2. If the TLV is understood, Tranit node MUST perform longest match 399 lookup in its local forwarding table and set the Return code as 400 "Replying node has no control plane mapping for the Target 401 Object" and Return Subcode as 1, if there is no matching entry 402 for the prefix in Sub-TLV in its local forwarding table. 404 3. If the received NVO3 Echo Request has NVO3 Downstream Detailed 405 Mapping TLV MUST set the Return code as "Downstream Detailed 406 Mapping mismatch" if any of the below fails: 408 * When Address Type is 1, Address-A SHOULD match Downstream 409 Interface Index and Router ID or Address-A SHOULD match 410 Downstream Address. 412 * When Address Type is 2 or 4, Index-I SHOULD match Downstream 413 Interface Index and Router ID SHOULD match Downstream Address. 415 * When Address Type is 3, Address-A SHOULD match Downstream 416 Interface Index and Router ID SHOULD match Downstream Address. 418 4. If the IP prefix in Sub-TLV matches any entry in local forwarding 419 table and if step 4 satisfies the received NVO3 DDMAP or if there 420 is no NVO3 DDMAP received in Echo Request, Transit node MUST set 421 the Return code as "Packet-Forward-OK" and set DDMAP field for 422 each available multipath egress interface in forwarding table. 424 5. If the received NVO3 Echo Request has Multipath information sub- 425 TLV in NVO3 DDMAP, Transit node MUST reply as mentioned section 426 5.5. 428 6.2.2. Edge Node procedure 430 Any Edge node (NVE) on receiving NVO3 Echo Request should perform the 431 below: 433 1. If the sanity check is fine, NVE MUST check all the Sub-TLVs and 434 MUST set the Return code as "One or more TLVs not understood" if 435 any of the TLV is not understood. 437 2. If the TLVs are understood, NVE node MUST send Echo Reply with 438 Return code "Replying node has no control plane mapping for the 439 Target Object" and Return Subcode as 1, if there is no matching 440 entry in local forwarding table to take a forwarding decision. 442 3. NVE node MUST set the Return code as "Replying node is the egress 443 for the Target" if the IP address in first (or top) Sub-TLV in 444 Target Object TLV is locally configured to this node and there is 445 no further sub-TLV in Target Object TLV 447 4. If the Target Object TLV have more than one Sub-TLV, NVE MUST 448 validate all the Sub-TLVs and set the Return code as "Replying 449 node has no control plane mapping for the Target Object" and 450 Return Subcode as pointer of the Sub-TLV which fails the 451 validation. 453 5. If the received Echo Request has NVO3 Downstream Detailed Mapping 454 TLV MUST check as mentioned in step 4 of section 6.2.1. 456 6. If the validation for all Sub-TLVs in Target Object TLV is fine, 457 NVE MUST set Return code as "Replying node is the egress for the 458 Target" and SHOULD NOT include NVO3 DDMAP. 460 6.3. Sending NVO3 Echo Reply 462 NVO3 Echo Reply is a UDP packet and MUST be sent only in response to 463 received NVO3 Echo Request. The format of NVO3 Echo Reply is same as 464 Echo request. 466 Responder MUST fill the DDMAP field, Return Code and Return Subcode 467 from previous section. It MUST also set the N flag in Global Flags 468 and set the message type as 12. The Sender's Handle, Sequence Number 469 field MUST be copied from the received Echo Request. 471 The source UDP port is set to 3503 and the source UDP port of 472 received Echo Request is copied to destination UDP port of Echo 473 Reply. The IP header is set as follows: the source IP address is a 474 routable address of the responder; the destination IP address is 475 coped from source address of Echo Request and IP TTL is set to 255. 476 When the core is IPv6 network, Responder MUST include IPv6 OAM 477 Extension Header. 479 6.4. Receiving NVO3 Echo Reply 481 Any node should receive NVO3 Echo Reply only in response to an NVO3 482 Echo Request that it sent. Initiator MUST drop the packet if it 483 fails sanity check. If the sanity check is fine, the Echo Reply 484 should be mapped with the respective Echo Request using the 485 destination port and Sender's Handle. if there is no match, the Echo 486 Reply MUST be ignored. Else, it checks the Sequence Number to match 487 the iteration. 489 In traceroute mode, If the Echo Reply contains NVO3 DDMAP, it SHOULD 490 copy the same to subsequent Echo Request(s). 492 6.5. Dealing with Equal-Cost-Multi-Path (ECMP) 494 For redundancy and load balancing purpose, It is common to see 495 multiple equal cost paths between ingress and egress NVE and it is a 496 local matter to transit node to decide the egress interface based on 497 local hashing algorithm. It is common to see deployment with routers 498 that support load-balancing based on UDP ports or based on IPv6 Flow 499 label. So it is useful to have the OAM tool to exercise all possible 500 paths between ingress and egress NVEs. 502 This can be achieved using Multipath Information Sub-TLV in NVO3 503 DDMAP. This can be used as follows: 505 o When the core is IPv6 network, the Initiator will send Echo 506 Request in traceroute mode (start with TTL as 1 and increment for 507 subsequent message) with Multipath type set to 2. Any transit 508 node will include multipath encoding for each downstream interface 509 in a way that the local hashing decision based on IPv6 flow label 510 will use the respective downstream path. Initiator will then send 511 NVO3 Echo Request with respective Flow label to excercise these 512 paths. 514 o When the core is Ipv4 network, the Initiator will send Echo 515 Request in traceroute mode with Multipath type set to 1. Any 516 transit node will include multipath encoding for each downstream 517 interface in a way that local hashing decision based on UDP port 518 will use the respective downstream path. initiator will then send 519 NVO3 Echo Request with respective UDP port as source port to 520 excercise these paths. 522 7. Connectivity verification between Tenant system 524 As like other overlay ping mechanism, the approach discussed in this 525 document will help with connectivity verification between NVE nodes 526 and control plane validation on NVE nodes. 528 Any dataplane programming corruption for VN context details in NVE 529 nodes will be in different layer and may need end-to-end connectivity 530 verification procedures. 532 8. IANA Considerations 534 This document reuse UDP port 3503 for NVO3 Echo packets. 536 8.1. Message Types, Reply Modes, Return Codes 538 This document request to assign the Message Types and Reply mode 539 mentioned in Section 4 and Return code mentioned in Section 4.1 541 8.2. TLVs 543 The TLVs and Sub-TLVs requested by this document for IANA 544 consideration are the following: 546 Type Sub-Type Value Field 547 ------- -------- ----------- 548 101 Target Object 549 1 IPv4 Prefix 550 2 IPv6 Prefix 551 3 L2 VN ID 552 4 L3 VN ID 554 9. Security Considerations 556 The security consideration for NVO3 Ping is similar to ICMP or LSP 557 Ping. AS like ICMP or LSP ping, NVO3 may be exposed to Denial-of- 558 service attacks and it is RECOMMENDED to regulate the NVO3 Ping 559 packet flow to control plane. A rate limiter SHOULD be applied to 560 avoid any attack 562 As like ICMP or LSP Ping, a traceroute can be used to obtain network 563 information. It is RECOMMENDED that the implementation check the 564 source address of the Echo messages against any local secured list 565 like access list before processing the message further 567 10. Acknowledgement 569 The authors would like to thank Lizhong Jin for his review and 570 comments. 572 11. References 574 11.1. Normative References 576 [I-D.ietf-nvo3-framework] 577 Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. 578 Rekhter, "Framework for DC Network Virtualization", draft- 579 ietf-nvo3-framework-04 (work in progress), November 2013. 581 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 582 Requirement Levels", BCP 14, RFC 2119, March 1997. 584 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 585 Label Switched (MPLS) Data Plane Failures", RFC 4379, 586 February 2006. 588 [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for 589 Performing Label Switched Path Ping (LSP Ping) over MPLS 590 Tunnels", RFC 6424, November 2011. 592 [RFC6425] Saxena, S., Swallow, G., Ali, Z., Farrel, A., Yasukawa, 593 S., and T. Nadeau, "Detecting Data-Plane Failures in 594 Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC 595 6425, November 2011. 597 11.2. Informative References 599 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 600 Label Switching Architecture", RFC 3031, January 2001. 602 Authors' Addresses 604 Nagendra Kumar 605 Cisco Systems, Inc. 606 7200 Kit Creek Road 607 Research Triangle Park, NC 27709 608 US 610 Email: naikumar@cisco.com 611 Carlos Pignataro 612 Cisco Systems, Inc. 613 7200 Kit Creek Road 614 Research Triangle Park, NC 27709-4987 615 US 617 Email: cpignata@cisco.com 619 Dhananjaya Rao 620 Cisco Systems, Inc. 621 170 W Tasman Drive 622 San Jose, CA 95138 623 US 625 Email: dhrao@cisco.com 627 Sam Aldrin 628 Huawei Technologies, Inc. 629 1188 Central Express Way 630 Santa Clara, CA 95051 631 US 633 Email: aldrin.ietf@gmail.com