idnits 2.17.00 (12 Aug 2021) /tmp/idnits15768/draft-xia-nvo3-overlay-p2mp-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 : ---------------------------------------------------------------------------- == There are 5 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 -- The document date (November 24, 2014) is 2728 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) ** Downref: Normative reference to an Informational RFC: RFC 4378 (ref. 'RFC4379') ** Obsolete normative reference: RFC 6424 (Obsoleted by RFC 8029) ** Downref: Normative reference to an Informational RFC: RFC 7348 ** Downref: Normative reference to an Informational RFC: RFC 7365 == Outdated reference: A later version (-03) exists of draft-jain-nvo3-overlay-oam-02 == Outdated reference: draft-sridharan-virtualization-nvgre has been published as RFC 7637 == Outdated reference: A later version (-02) exists of draft-ghanwani-nvo3-app-mcast-framework-00 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NVO3 working group L. Xia 2 Internet Draft Weiguo Hao 3 Category: Standard Track Huawei 4 Expires: May 24, Greg Mirsky 5 Ericsson 6 November 24, 2014 8 Detecting NVO3 Overlay Point-to-Multipoint Data Plane failures 9 draft-xia-nvo3-overlay-p2mp-ping-01 11 Abstract 13 This draft refers to P2MP LSP ping, and describes NVO3 overlay P2MP 14 ping mechanisms by extending the existing NVO3 overlay P2P ping 15 mechanisms for applying to NVO3 overlay P2MP path in order to 16 simplify implementation and network operation. 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with 21 the provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other documents 30 at any time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on May 24, 2015. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with 51 respect to this document. 53 Table of Contents 55 1. Introduction ................................................ 3 56 1.1. Conventions used in this document ...................... 4 57 1.2. Terminology ............................................ 4 58 2. Overview .................................................... 5 59 2.1. NVO3 Multicast Methods ................................. 5 60 2.2. NVO3 P2MP Ping Mechanisms .............................. 5 61 3. Packet Format ............................................... 6 62 3.1. Identifying the P2MP NVO3 Overlay Path ................. 6 63 3.1.1. No Multicast Support by NVO3 Underlay Network ..... 6 64 3.1.2. Multicast Support by NVO3 Underlay Network ........ 7 65 3.1.2.1. Broadcast and Unknown Unicast Packets Case ... 7 66 3.1.2.2. Multicast Packets Case ....................... 7 67 3.2. Limiting the Scope of Responses ........................ 8 68 3.3. Other TLVs and Flags ................................... 9 69 4. Theory of Operation ......................................... 9 70 4.1. No Multicast Support by NVO3 Underlay Network .......... 9 71 4.2. Multicast Support by NVO3 Underlay Network ............ 10 72 4.2.1. Ingress NVE Operations ........................... 10 73 4.2.2. Responding Node Operations ....................... 10 74 4.2.2.1. Responses from Transit and Branch Nodes ..... 11 75 4.2.2.2. Responses from Egress Nodes ................. 12 76 4.2.2.3. Responses from Bud Nodes .................... 13 77 4.3. Special Considerations for Traceroute ................. 14 78 5. Hierarchical NVE Scenario .................................. 14 79 6. Security Considerations .................................... 14 80 7. Acknowledgements ........................................... 14 81 8. IANA Considerations ........................................ 14 82 8.1. TLVs .................................................. 14 83 9. References ................................................. 15 84 9.1. Normative References .................................. 15 85 9.2. Informative References ................................ 15 87 1. Introduction 89 For NVO3 network, comprehensive OAM tool set is very important. NVO3 90 point-to-point (P2P) ping is a simple and efficient mechanism for 91 detecting data plane failures of layer 2 (L2) or layer 3 (L3) 92 virtual network overlaid on IPv4 or IPv6 underlay networks. 93 [NVO3OVERLAYOAM] and [NVO3OVERLAYPING] have described P2P ping 94 mechanism for various overlay technologies (i.e., VXLAN [RFC7348], 95 NVGRE [NVGRE], etc) of NVO3 network. 97 NVO3 P2P ping follows the basic idea of LSP ping described in 98 [RFC4379]. Which is modeled after the ping/traceroute paradigm: ping 99 (ICMP Echo Request [RFC792]) is used for connectivity verification, 100 and traceroute is used for hop-by-hop fault localization as well as 101 path tracing. In the ping mode, the NVO3 Echo Request message is 102 sent by an NVE within a tested overlay path, along the same data 103 path to the destination NVE as other packets. Upon reception, NVO3 104 Echo Request is passed to the control plane of the destination NVE 105 to verify if it is indeed an egress NVE for the tested overlay path. 106 In the traceroute mode, the NVO3 Echo Request message is sent in 107 band and reach the control plane of each transit node. The node 108 performs various checks to verify it is indeed a transit node for 109 this path. If error or ping reply timeout is found in one transit 110 node, fault localization is achieved. Also it can trace the 111 underlay path that is exercised by any given overlay path. NVO3 Echo 112 Reply message is used by egress NVEs or transit nodes to report the 113 results to the ingress NVE. It can be sent in band or out-of-band. 114 Only NVO3 Echo Request message must have the same NVO3 overlay 115 encapsulation as regular data plane packets to ensure they share the 116 same data path. 118 NVO3 network needs to support Broadcast, Unknown unicast, Multicast 119 (BUM) traffics. [NVO3MCAST] discusses four methods to handle BUM 120 traffic in NVO3 network: 122 1. No multicast support. 124 2. Replication at the source NVE. 126 3. Replication at a centralized multicast service node. 128 4. IP multicast in the underlay. 130 NVO3 point-to-multipoint (P2MP) ping should be supported for each 131 tenant's multicast service's connectivity verification, fault 132 localization and path tracing. The NVO3 P2MP ping must have the 133 ability to: 135 o Support the connectivity verification from an arbitrary NVE to 136 either a specific set of NVEs or all NVEs overlaid on the 137 underlay Multicast Distribution Tree (MDT); 139 o Support the fault localization in the underlay MDT; 141 o Support the path tracing of the underlay MDT exercised by any 142 given overlay path. 144 This draft draws on P2MP LSP ping [RFC6425] solution, and describes 145 NVO3 overlay P2MP ping mechanisms by extending the existing NVO3 146 overlay P2P ping mechanisms for applying to NVO3 overlay P2MP path. 148 1.1. Conventions used in this document 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in RFC-2119 [RFC2119]. 154 1.2. Terminology 156 This document uses the terms defined in NVO3 framework [RFC7365], 157 [RFC6425] and [NVO3OVERLAYPING]. 159 BUM - Broadcast, Unknown unicast, Multicast 161 IGMP - Internet Group Management Protocol 163 MDT - Multicast Distribution Tree 165 MLD - Multicast Listener Discover 167 NVE - Network Virtualization Edge 169 PIM-DM - Protocol Independent Multicast-Dense Mode 171 PIM-SM - Protocol Independent Multicast-Sparse Mode 173 PIM-SSM - Protocol Independent Multicast-Source-Specific Multicast 175 2. Overview 177 2.1. NVO3 Multicast Methods 179 This section gives a simple summary of current existed NVO3 180 multicast methods. 182 When the NVO3 underlay network supports multicast, the underlay MDT 183 is established according to the topology of tenant network and BUM 184 packets type: 186 o For broadcast or unknown unicast packets, all NVEs in a L2 187 overlay network are involved. Each NVE within a L2 overlay 188 network of a tenant network can be the ingress NVE for the MDT, 189 the rest NVEs connected to other parts of the same L2 overlay 190 network are all egress NVEs for that MDT; 192 o For L3 multicast packets, possibly only part of NVEs in a tenant 193 network are involved. The NVE connected to the multicast source 194 node is the ingress NVE; other NVEs connected to the nodes that 195 need to receive multicast traffic are all egress NVEs. 197 In this method, the ingress NVE directly encapsulates the BUM 198 packets with the appropriate IP multicast address in the tunnel 199 encapsulation header for delivery to the desired set of egress NVEs. 200 All egress NVEs that belong to the same multicast group MUST send 201 IGMP/MLD packets to underlay network edge devices to trigger 202 underlay network MDT establishment. 204 When the NVO3 underlay network does not support multicast, the 205 mechanism of head-end replication at the ingress NVE or centralized 206 replication at the multicast service node can be used. These two 207 mechanisms use unicast NVO3 encapsulation to send BUM traffic to all 208 destination NVEs and don't rely on multicast forwarding capability 209 of underlay network. 211 2.2. NVO3 P2MP Ping Mechanisms 213 Comparing to NVO3 P2P overlay services, NVO3 P2MP overlay services 214 are more complex. To meet the requirements mentioned in Section 1, 215 the NVO3 P2MP ping mechanisms need some extensions to the current 216 NVO3 ping mechanisms. 218 This draft refers to [RFC6425] and describes the following 219 extensions: 221 o The packet format extension to the NVO3 overlay P2MP Echo 222 Request/Reply messages; 224 o The extended mechanisms of NVO3 overlay P2MP ping operations; 226 o Different operation mechanism for two scenarios - with or without 227 underlay multicast support; 229 o Special considerations for traceroute function; 231 o Support for the hierarchical NVE scenario. 233 NVO3 overlay P2MP ping packet is an IPv4 or IPv6 UDP packet 234 identified by well known UDP Port 3503, and the basic structure of 235 the packet remains the same as defined in Section 3 of [RFC4379]. 237 3. Packet Format 239 This document also references Section 4 of [NVO3OVERLAYPING] as the 240 extended specification to the payload of inner UDP of NVO3 Echo 241 Request/Reply packet format, which includes: 243 o a new "N" flag (NVO3 PATH Ping) in Global Flags field for 244 identifying a NVO3 ping Echo message; 246 o The extended specification of Message Type, Reply Mode, Return 247 Code and Return Subcode in the contents of the Echo UDP message 248 part; 250 o Target Object TLV: A list of newly defined sub-TLVs (i.e., 251 IPv4/IPv6 prefix sub-TLVs for egress NVE address, L2/L3 VN ID 252 sub-TLVs for L2/L3 VNI) for validating the target objects of NVO3 253 P2P path; 255 o Downstream Detailed Mapping Extension and related Multipath 256 information encoding algorithm. 258 Besides the above extensions, NVO3 P2MP ping mechanisms need to 259 define new TLVs and sub-TLVs to support the functionalities specific 260 to its P2MP application. 262 3.1. Identifying the P2MP NVO3 Overlay Path 264 3.1.1. No Multicast Support by NVO3 Underlay Network 266 If NVO3 underlay network does not support multicast, NVO3 overlay 267 network replicates and sends BUM traffic at ingress NVE or multicast 268 service node by unicast. NVO3 P2MP ping mechanisms require ingress 269 NVE or multicast service node to use NVO3 P2P ping sessions to all 270 or desired subset of egress NVEs. The ingress NVE (or multicast 271 service node) MUST use the Target Object TLVs for P2P ping sessions 272 with target egress NVEs. It's noted that, for the multicast service 273 node case, the E2E P2MP ping session also includes a P2P ping sub- 274 session between the ingress NVE and the multicast service node. 276 3.1.2. Multicast Support by NVO3 Underlay Network 278 3.1.2.1. Broadcast and Unknown Unicast Packets Case 280 If NVO3 underlay network supports multicast, a new Target Object 281 TLV--L2 VN ID sub-TLV is defined to validate the VN context of L2 282 network for broadcast or unknown unicast packets. The example TLV 283 format for VXLAN is as followed: 285 0 1 2 3 286 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 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Type = X (P2MP ping for BU) | Length | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | VN ID (VXLAN VNI) | Reserved | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 Figure 1: L2 VN ID sub-TLV for VXLAN 294 Note: BU - Broadcast, Unknown unicast. 296 The above TLV format can be a general format used in P2MP ping Echo 297 message for all NVO3 overlay technologies (i.e. VXLAN, NVGRE, etc) 298 to validate the VN context of L2 network for the case of broadcast 299 or unknown unicast packets. 301 3.1.2.2. Multicast Packets Case 303 For L3 multicast case, two new Target Object TLVs: VN IPv4/IPv6 304 multicast sub-TLVs are defined for IPv4 and IPv6 overlay network as 305 followed: 307 0 1 2 3 308 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 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Type= Y(P2MP ping for IPv4 M)| Length | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | VN ID | Reserved | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | IPv4 Multicast Address | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 Figure 2: VN multicast sub-TLV for IPv4 overlay network 318 0 1 2 3 319 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 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Type= Z(P2MP ping for IPv6 M)| Length | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | VN ID | Reserved | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | IPv6 Multicast Address | 326 | | 327 | | 328 | | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 Figure 3: VN multicast sub-TLV for IPv6 overlay network 332 Note: M - Multicast. 334 In this case, in addition to the VN ID used for the validation of 335 L2/L3 VN context, IPv4/IPv6 multicast address is needed to check if 336 the target NVEs are on the path to the receiver of the corresponding 337 MDT. NVEs MUST be able to snoop IGMP/MLD messages in order to 338 remember it has multicast receiver attached. 340 3.2. Limiting the Scope of Responses 342 To limit the scope of responses, NVO3 P2MP ping mechanisms MUST 343 include specific TLV in Echo Request message to make the appointed 344 target NVEs to respond Echo Request message, and other NVEs do not 345 respond it. 347 Section 3.2 of [RFC6425] defines the P2MP Responder Identifier TLV 348 and four sub-TLVs (IPv4/IPv6 Egress Address P2MP Responder sub-TLVs, 349 IPv4/IPv6 Node Address P2MP Responder sub-TLVs). The responding node 350 upon receiving any of these sub-TLVs would respond or not respond to 351 the Echo Request message thus achieving goal of limiting the scope 352 of responses. 354 To use IPv4/IPv6 Egress Address P2MP Responder sub-TLVs properly, 355 the nodes that locate upstream in the MDT must know all the egress 356 NVE IP addresses. Current multicast protocols (i.e., PIM-SM, PIM-DM, 357 IGMP, MLD, etc) cannot meet this requirement. So, these two sub-TLVs 358 cannot be used for the NVO3 P2MP ping mechanisms. 360 Without any extra requirement, IPv4/IPv6 Node Address P2MP Responder 361 sub-TLVs definition and related operations remain the same for NVO3 362 P2MP ping mechanisms. 364 3.3. Other TLVs and Flags 366 The Echo Jitter TLV and the intended behavior of the responding node 367 upon receiving it, defined in Section 3.3 of [RFC6425], remain the 368 same to help to limit congestion of Echo replies. 370 The Respond Only If TTL Expired Flag in the Global Flags field 371 defined in Section 3.4 of [RFC6425] is inherited here with one 372 change: TTL to be checked is in the outer IP header. 374 4. Theory of Operation 376 This section refers to Section 4 of [RFC6425] to describe how the 377 NVO3 P2MP Echo messages are processed at various nodes, e.g. ingress 378 NVE, transit nodes, etc. This section also discusses the different 379 mechanisms for ping mode and traceroute mode. 381 Note that the main goal of this section is to describe the changes 382 that existing P2MP MPLS ping operations need to make in order to 383 make it applicable for NVO3 network. The unchanged operations are 384 listed here briefly. The details can refer to Section 4 of [RFC6425]. 386 4.1. No Multicast Support by NVO3 Underlay Network 388 For ping mode, NVO3 P2MP Echo Request messages are replicated at 389 ingress NVE or multicast service node and sent each copy of the 390 message to destination NVEs through unicast NVO3 encapsulation. This 391 mode is more often used by Connectivity Verification function. 393 For traceroute mode, NVO3 P2MP Echo Request messages are replicated 394 at ingress NVE or multicast service node, and then each copy of the 395 message will be sent to desired transit nodes through unicast 396 encapsulation with specific TTL value in outer IP header. This mode 397 can be used for Fault Localization or Path Tracing functions. 399 Ingress NVE or multicast service node can send Echo Request messages 400 to one or a set of members of egress NVEs, or their transit nodes by 401 their choice. Because all the Echo Request messages are sent by 402 unicast, the operations onto them remain the same as with NVO3 P2P 403 ping mechanisms defined in [NVO3OVERLAYPING]. 405 In addition, ingress NVE is still possible to send multiple Echo 406 Request messages to multiple target nodes and gets many Echo Reply 407 messages in a short period, which will cause congestion on the 408 ingress NVE. So, the Echo Jitter TLV and according random delay 409 reply mechanism defined in [RFC6425] should be supported for this 410 case. 412 4.2. Multicast Support by NVO3 Underlay Network 414 Because NVO3 underlay network supports multicast protocol, NVO3 415 overlay network can use the underlay MDT to transfer BUM traffics 416 and the NVO3 P2MP Echo Request messages. The elements in the MDT 417 include ingress node, transit node, branch node, bud node, egress 418 node. They have different operations on the P2MP Echo Request 419 messages which are described in the following sections. 421 4.2.1. Ingress NVE Operations 423 Ingress NVE should follow the procedure defined in [RFC4379] to 424 construct the P2MP Echo Request message. The packet format MUST be 425 the extended format described in Section 3 of this document and it 426 MUST be IP encapsulated. 428 Echo Request message will contain a Target Object TLV to identify 429 NVE membership. L2 VN ID sub-TLV is for broadcast or unknown unicast 430 case, VN IPv4/IPv6 multicast sub-TLVs is for L3 multicast case. 432 Echo Request message can contain IPv4/IPv6 Node Address P2MP 433 Responder sub-TLVs to limit responses from only those targeted nodes 434 under the ping mode. 436 The Echo Jitter TLV can also be contained to limit the congestion in 437 the ingress NVE. 439 4.2.2. Responding Node Operations 441 Except for the ingress NVE, other nodes potentially are to act as a 442 responding node. 444 Usually the Echo Request message will be addressed to the egress 445 and/or bud nodes. In case of TTL Expiry, i.e. in the traceroute mode, 446 the Echo Request message may stop at branch or transit nodes. In 447 both scenarios, the Echo Request message will be passed on to the 448 control plane to generate the Echo Reply message. 450 After the rate-limit control and sanity check, the responding node 451 MUST determine how to reply based on the Reply Mode field. Then, the 452 responding node MUST determine if it is on the underlay MDT in 453 question which the overlay P2MP path is tunneled on by checking the 454 destination multicast address against the control plane: 456 o If the responding node is not on the underlay MDT in question, it 457 MUST send Echo Reply with Return Code "Replying node has no 458 control plane mapping for the Target Object" and Return Subcode 459 as 1 which implies the MDT address check failure, as defined in 460 [NVO3OVERLAYPING]; 462 o If the node is on the underlay MDT in question, the node MUST 463 check whether or not the Echo Request is directed to it: 465 o If a P2MP Responder Identifier TLV is present, then the node 466 MUST follow the procedures defined in Section 3.2 to 467 determine whether or not it should respond to the request; 469 o If the P2MP Responder Identifier TLV is not present (or, in 470 the error case, is present, but does not contain any sub- 471 TLVs), then the node MUST respond according to 472 [NVO3OVERLAYPING] processing rules. 474 The following sections describe the expected values of Return Codes 475 for various nodes on the underlay MDT which the overlay P2MP path is 476 tunneled on. Note that the Return Code might change based on the 477 presence of a Responder Identifier TLV or Downstream Detailed 478 Mapping TLV. 480 4.2.2.1. Responses from Transit and Branch Nodes 482 The presence of a Responder Identifier TLV does not influence the 483 choice of the Return Code. To report success, the Return Code MAY be 484 set to "Packet-Forward-OK". For error conditions, use appropriate 485 values defined in [NVO3OVERLAYPING]. 487 The presence of a Downstream Detailed Mapping TLV will influence the 488 choice of Return Code. As per [RFC6424], the Return Code may be set 489 to "See DDM TLV for Return Code and Return Subcode". The Return Code 490 for each Downstream Detailed Mapping TLV will depend on the 491 downstream path as described in [RFC6424]. 493 There will be a Downstream Detailed Mapping TLV for each downstream 494 path being reported in the Echo Reply. Hence, for transit nodes, 495 there will be only one such TLV, and for branch nodes, there will be 496 more than one. 498 4.2.2.2. Responses from Egress Nodes 500 The presence of a Responder Identifier TLV does not influence the 501 choice of the Return Code. To report success, the Return Code MAY be 502 set to "Egress for the Target", as defined in [NVO3OVERLAYPING]. For 503 error conditions, use appropriate values defined in 504 [NVO3OVERLAYPING]. 506 To check whether a NVE is an egress NVE for an overlay P2MP path, 507 two cases need to be differentiated according to previous analysis: 509 o Broadcast or unknown unicast overlay path case: L2 VN ID sub-TLV 510 should be contained in the Echo Request message, which includes 511 the L2 VN ID need to be validated. An NVE determines if it is the 512 egress NVE for this VN by checking if there is an entry of this 513 VN ID existed in the NVE. If it is the egress NVE, MUST return 514 the success response; 516 o L3 multicast overlay path case: VN IPv4/IPv6 multicast sub-TLV 517 should be contained in the Echo Request message. Except for the 518 same VN ID validation procedure as above, NVE also needs to check 519 if it is on the path to a receiver of this IPv4/IPv6 multicast 520 address, which is included in VN IPv4/IPv6 multicast sub-TLV. 521 Only if all the validations are OK, the NVE thinks itself an 522 egress NVE and MUST return the success response. 524 To save the MDT number in the NVO3 underlay network, multiple 525 overlay P2MP paths may share the same underlay MDT. The egress NVEs 526 of one overlay P2MP path of them may be a subset of the egress nodes 527 of MDT. When the NVO3 P2MP Echo Request messages for this overlay 528 P2MP path are sent to all the egress nodes of MDT and get response 529 from them, some egress NVEs that do not belong to this overlay P2MP 530 path SHOULD reply with Return Code "Replying node has no control 531 plane mapping for the Target Object" and Return Subcode as 1 to the 532 ingress NVE. Note that this does not mean the error condition for 533 the egress NVE. 535 The presence of the Downstream Detailed Mapping TLV does not 536 influence the choice of Return Code. Egress NVEs do not put in any 537 Downstream Detailed Mapping TLV in the Echo Reply as per [RFC6424]. 539 4.2.2.3. Responses from Bud Nodes 541 The processing at bud nodes is more complex than other types of MDT 542 nodes. The bud node behaves as either an egress node or a transit 543 node, or a combination of an egress and branch node. This behavior 544 is determined by the presence of any Responder Identifier TLV. 545 Similarly, the Downstream Detailed Mapping TLV can influence the 546 Return Code values. 548 To determine the behavior of the bud node, use the following rules: 550 o If the Responder Identifier TLV is not present, then the node 551 MUST behave as a combination of egress and branch node; 553 o If the Responder Identifier TLV containing a Node Address sub- 554 TLV is present, and: 556 o If the address specified in the sub-TLV matches to an address 557 in the node, then the node MUST behave like a combination of 558 egress and branch node; 560 o If the address specified in the sub-TLV does not match any 561 address in the node, then no reply SHOULD be sent. 563 Once the node behavior has been determined, the possible values for 564 Return Codes are as follows: 566 o If the node is behaving as a combination of egress and branch 567 node, and: 569 o If a Downstream Detailed Mapping TLV is not present, then for 570 a success response, the Return Code SHOULD be set to "Egress 571 for the Target". For error conditions, use appropriate 572 values defined in [NVO3OVERLAYPING]; 574 o If a Downstream Detailed Mapping TLV is present, then for a 575 success response, the Return Code SHOULD be set to "Egress 576 for the Target". For error conditions, use appropriate 577 values defined in [NVO3OVERLAYPING]. The Return Code for the 578 each Downstream Detailed Mapping TLV will depend on the 579 downstream path as described in [RFC6424]. There will be a 580 Downstream Detailed Mapping TLV for each downstream path from 581 the node. 583 4.3. Special Considerations for Traceroute 585 Comparing to P2P ping, P2MP ping has a new problem of how to figure 586 out the end of the traceroute processing. The relevant background 587 can refer to Section 4.3.1 of [RFC6425]. For the two cases of NVO3 588 P2MP ping: 590 o Replication at ingress NVE or multicast service node: Because the 591 initiating node has a priori knowledge about the number of egress 592 nodes and their addresses, it is possible to continue processing 593 until a valid reply has been received from each end point, 594 provided that the replies can be matched correctly to the egress 595 NVEs; 597 o Underlay network multicast supporting: the ingress NVE might not 598 always know about all of the egress NVEs. Hence, there might not 599 be a definitive way to estimate the end of processing for 600 traceroute. Therefore, a configurable upper limit on TTL values 601 is a good solution for this case. By this way, the user can 602 choose the depth to which the tree will be probed. 604 The other problems of traceroute mode for MPLS P2MP ping also exist 605 for NVO3 P2MP ping. The specific mechanisms defined in Sections 606 4.3.2, 4.3.3, 4.3.4, 4.3.5 of [RFC6425] are all applicable to NVO3 607 P2MP ping. 609 5. Hierarchical NVE Scenario 611 TBD 613 6. Security Considerations 615 TBD. 617 7. Acknowledgements 619 8. IANA Considerations 621 8.1. TLVs 623 The TLVs and Sub-TLVs requested by this draft for IANA consideration 624 are the following: 626 Type Sub-Type Value Field 628 ------- -------- ----------- 630 XXX Target Object 632 X L2 VN ID 634 X VN IPv4/IPv6 multicast 636 9. References 638 9.1. Normative References 640 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 641 Requirement Levels", BCP 14, RFC2119, March 1997 643 [RFC4379] Allan, D. and T. Nadeau, "A Framework for Multi-Protocol 644 Label Switching (MPLS) Operations and Management (OAM)", RFC 4378, 645 February 2006 647 [RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 648 792, September 1981 650 [RFC6425] Saxena, S., et al, "Detecting Data Plane Failures in 651 Point-to-Multipoint Multiprotocol Label Switching (MPLS) - 652 Extensions to LSP", RFC 6425, November 2011 654 [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism 655 for Performing LSP-Ping over MPLS Tunnels", RFC 6424, November 2011 657 [RFC7348] Mahalingam, M., Dutt, D., et al, "Virtual eXtensible 658 Local Area Network (VXLAN): A Framework for Overlaying Virtualized 659 Layer 2 Networks over Layer 3 Networks", RFC7348, August, 2014 661 [RFC7365] LASSERRE, M., Motin, T., et al, "Framework for DC Network 662 Virtualization", RFC7365, October, 2014 664 9.2. Informative References 666 [NVO3OVERLAYOAM] Jain, P., et al, "Generic Overlay OAM and Datapath 667 Failure Detection", draft-jain-nvo3-overlay-oam-02, work in progress, 668 October, 2014 670 [NVO3OVERLAYPING] Kumar, N., "Detecting NVO3 Overlay Data Plane 671 failures", draft-kumar-nvo3-overlay-ping-01, work in progress, 672 January, 2014 674 [NVGRE] Sridharan, M., et al, "NVGRE: Network Virtualization using 675 Generic Routing Encapsulation", draft-sridharan-virtualization- 676 nvgre-06, work in progress, October, 2014 678 [NVO3MCAST] Ghanwani, A., et al, "Framework of Supporting 679 Applications Specific Multicast in NVO3", draft-ghanwani-nvo3-app- 680 mcast-framework-00, work in progress, June, 2014 682 Authors' Addresses 684 Liang Xia 685 Huawei Technologies 687 Email: frank.xialiang@huawei.com 689 Weiguo Hao 690 Huawei Technologies 691 101 Software Avenue, 692 Nanjing 210012 693 China 694 Phone: +86-25-56623144 695 Email: haoweiguo@huawei.com 697 Greg Mirsky 698 Ericsson 700 EMail: gregory.mirsky@ericsson.com