Internet DRAFT - draft-xia-nvo3-overlay-p2mp-ping

draft-xia-nvo3-overlay-p2mp-ping



NVO3 working group                                               L. Xia
Internet Draft                                               Weiguo Hao
Category: Standard Track                                         Huawei
Expires: May 24,                                            Greg Mirsky
                                                               Ericsson
                                                      November 24, 2014



       Detecting NVO3 Overlay Point-to-Multipoint Data Plane failures
                    draft-xia-nvo3-overlay-p2mp-ping-01

Abstract

   This draft refers to P2MP LSP ping, and describes NVO3 overlay P2MP
   ping mechanisms by extending the existing NVO3 overlay P2P ping
   mechanisms for applying to NVO3 overlay P2MP path in order to
   simplify implementation and network operation.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with
   the provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on May 24, 2015.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Xia, et al              Expires May 24, 2015                  [Page 1]

Internet-Draft          NVO3 OVERLAY P2MP PING           November, 2014

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document.



Table of Contents


   1. Introduction ................................................ 3
      1.1. Conventions used in this document ...................... 4
      1.2. Terminology ............................................ 4
   2. Overview .................................................... 5
      2.1. NVO3 Multicast Methods ................................. 5
      2.2. NVO3 P2MP Ping Mechanisms .............................. 5
   3. Packet Format ............................................... 6
      3.1. Identifying the P2MP NVO3 Overlay Path ................. 6
         3.1.1. No Multicast Support by NVO3 Underlay Network ..... 6
         3.1.2. Multicast Support by NVO3 Underlay Network ........ 7
            3.1.2.1. Broadcast and Unknown Unicast Packets Case ... 7
            3.1.2.2. Multicast Packets Case ....................... 7
      3.2. Limiting the Scope of Responses ........................ 8
      3.3. Other TLVs and Flags ................................... 9
   4. Theory of Operation ......................................... 9
      4.1. No Multicast Support by NVO3 Underlay Network .......... 9
      4.2. Multicast Support by NVO3 Underlay Network ............ 10
         4.2.1. Ingress NVE Operations ........................... 10
         4.2.2. Responding Node Operations ....................... 10
            4.2.2.1. Responses from Transit and Branch Nodes ..... 11
            4.2.2.2. Responses from Egress Nodes ................. 12
            4.2.2.3. Responses from Bud Nodes .................... 13
      4.3. Special Considerations for Traceroute ................. 14
   5. Hierarchical NVE Scenario .................................. 14
   6. Security Considerations .................................... 14
   7. Acknowledgements ........................................... 14
   8. IANA Considerations ........................................ 14
      8.1. TLVs .................................................. 14
   9. References ................................................. 15
      9.1. Normative References .................................. 15
      9.2. Informative References ................................ 15







Xia, et al              Expires May 24, 2014                  [Page 2]

Internet-Draft          NVO3 OVERLAY P2MP PING           November, 2014


1. Introduction

   For NVO3 network, comprehensive OAM tool set is very important. NVO3
   point-to-point (P2P) ping is a simple and efficient mechanism for
   detecting data plane failures of layer 2 (L2) or layer 3 (L3)
   virtual network overlaid on IPv4 or IPv6 underlay networks.
   [NVO3OVERLAYOAM] and [NVO3OVERLAYPING] have described P2P ping
   mechanism for various overlay technologies (i.e., VXLAN [RFC7348],
   NVGRE [NVGRE], etc) of NVO3 network.

   NVO3 P2P ping follows the basic idea of LSP ping described in
   [RFC4379]. Which is modeled after the ping/traceroute paradigm: ping
   (ICMP Echo Request [RFC792]) is used for connectivity verification,
   and traceroute is used for hop-by-hop fault localization as well as
   path tracing. In the ping mode, the NVO3 Echo Request message is
   sent by an NVE within a tested overlay path, along the same data
   path to the destination NVE as other packets. Upon reception, NVO3
   Echo Request is passed to the control plane of the destination NVE
   to verify if it is indeed an egress NVE for the tested overlay path.
   In the traceroute mode, the NVO3 Echo Request message is sent in
   band and reach the control plane of each transit node. The node
   performs various checks to verify it is indeed a transit node for
   this path. If error or ping reply timeout is found in one transit
   node, fault localization is achieved.  Also it can trace the
   underlay path that is exercised by any given overlay path. NVO3 Echo
   Reply message is used by egress NVEs or transit nodes to report the
   results to the ingress NVE. It can be sent in band or out-of-band.
   Only NVO3 Echo Request message must have the same NVO3 overlay
   encapsulation as regular data plane packets to ensure they share the
   same data path.

   NVO3 network needs to support Broadcast, Unknown unicast, Multicast
   (BUM) traffics. [NVO3MCAST] discusses four methods to handle BUM
   traffic in NVO3 network:

   1. No multicast support.

   2. Replication at the source NVE.

   3. Replication at a centralized multicast service node.

   4. IP multicast in the underlay.

   NVO3 point-to-multipoint (P2MP) ping should be supported for each
   tenant's multicast service's connectivity verification, fault




Xia, et al              Expires May 24, 2014                  [Page 3]

Internet-Draft          NVO3 OVERLAY P2MP PING           November, 2014

   localization and path tracing. The NVO3 P2MP ping must have the
   ability to:

   o Support the connectivity verification from an arbitrary NVE to
      either a specific set of NVEs or all NVEs overlaid on the
      underlay Multicast Distribution Tree (MDT);

   o Support the fault localization in the underlay MDT;

   o Support the path tracing of the underlay MDT exercised by any
      given overlay path.

   This draft draws on P2MP LSP ping [RFC6425] solution, and describes
   NVO3 overlay P2MP ping mechanisms by extending the existing NVO3
   overlay P2P ping mechanisms for applying to NVO3 overlay P2MP path.

1.1. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [RFC2119].

1.2. Terminology

   This document uses the terms defined in NVO3 framework [RFC7365],
   [RFC6425] and [NVO3OVERLAYPING].

   BUM - Broadcast, Unknown unicast, Multicast

   IGMP - Internet Group Management Protocol

   MDT - Multicast Distribution Tree

   MLD - Multicast Listener Discover

   NVE - Network Virtualization Edge

   PIM-DM - Protocol Independent Multicast-Dense Mode

   PIM-SM - Protocol Independent Multicast-Sparse Mode

   PIM-SSM - Protocol Independent Multicast-Source-Specific Multicast








Xia, et al              Expires May 24, 2014                  [Page 4]

Internet-Draft          NVO3 OVERLAY P2MP PING           November, 2014

2. Overview

2.1. NVO3 Multicast Methods

   This section gives a simple summary of current existed NVO3
   multicast methods.

   When the NVO3 underlay network supports multicast, the underlay MDT
   is established according to the topology of tenant network and BUM
   packets type:

   o For broadcast or unknown unicast packets, all NVEs in a L2
      overlay network are involved. Each NVE within a L2 overlay
      network of a tenant network can be the ingress NVE for the MDT,
      the rest NVEs connected to other parts of the same L2 overlay
      network are all egress NVEs for that MDT;

   o For L3 multicast packets, possibly only part of NVEs in a tenant
      network are involved. The NVE connected to the multicast source
      node is the ingress NVE; other NVEs connected to the nodes that
      need to receive multicast traffic are all egress NVEs.

   In this method, the ingress NVE directly encapsulates the BUM
   packets with the appropriate IP multicast address in the tunnel
   encapsulation header for delivery to the desired set of egress NVEs.
   All egress NVEs that belong to the same multicast group MUST send
   IGMP/MLD packets to underlay network edge devices to trigger
   underlay network MDT establishment.

   When the NVO3 underlay network does not support multicast, the
   mechanism of head-end replication at the ingress NVE or centralized
   replication at the multicast service node can be used. These two
   mechanisms use unicast NVO3 encapsulation to send BUM traffic to all
   destination NVEs and don't rely on multicast forwarding capability
   of underlay network.

2.2. NVO3 P2MP Ping Mechanisms

   Comparing to NVO3 P2P overlay services, NVO3 P2MP overlay services
   are more complex. To meet the requirements mentioned in Section 1,
   the NVO3 P2MP ping mechanisms need some extensions to the current
   NVO3 ping mechanisms.

   This draft refers to [RFC6425] and describes the following
   extensions:





Xia, et al              Expires May 24, 2014                  [Page 5]

Internet-Draft          NVO3 OVERLAY P2MP PING           November, 2014

   o The packet format extension to the NVO3 overlay P2MP Echo
      Request/Reply messages;

   o The extended mechanisms of NVO3 overlay P2MP ping operations;

   o Different operation mechanism for two scenarios - with or without
      underlay multicast support;

   o Special considerations for traceroute function;

   o Support for the hierarchical NVE scenario.

   NVO3 overlay P2MP ping packet is an IPv4 or IPv6 UDP packet
   identified by well known UDP Port 3503, and the basic structure of
   the packet remains the same as defined in Section 3 of [RFC4379].

3. Packet Format

   This document also references Section 4 of [NVO3OVERLAYPING] as the
   extended specification to the payload of inner UDP of NVO3 Echo
   Request/Reply packet format, which includes:

   o a new "N" flag (NVO3 PATH Ping) in Global Flags field for
      identifying a NVO3 ping Echo message;

   o The extended specification of Message Type, Reply Mode, Return
      Code and Return Subcode in the contents of the Echo UDP message
      part;

   o Target Object TLV: A list of newly defined sub-TLVs (i.e.,
      IPv4/IPv6 prefix sub-TLVs for egress NVE address, L2/L3 VN ID
      sub-TLVs for L2/L3 VNI) for validating the target objects of NVO3
      P2P path;

   o Downstream Detailed Mapping Extension and related Multipath
      information encoding algorithm.

   Besides the above extensions, NVO3 P2MP ping mechanisms need to
   define new TLVs and sub-TLVs to support the functionalities specific
   to its P2MP application.

3.1. Identifying the P2MP NVO3 Overlay Path

    3.1.1. No Multicast Support by NVO3 Underlay Network

   If NVO3 underlay network does not support multicast, NVO3 overlay
   network replicates and sends BUM traffic at ingress NVE or multicast



Xia, et al              Expires May 24, 2014                  [Page 6]

Internet-Draft          NVO3 OVERLAY P2MP PING           November, 2014

   service node by unicast. NVO3 P2MP ping mechanisms require ingress
   NVE or multicast service node to use NVO3 P2P ping sessions to all
   or desired subset of egress NVEs. The ingress NVE (or multicast
   service node) MUST use the Target Object TLVs for P2P ping sessions
   with target egress NVEs. It's noted that, for the multicast service
   node case, the E2E P2MP ping session also includes a P2P ping sub-
   session between the ingress NVE and the multicast service node.

    3.1.2. Multicast Support by NVO3 Underlay Network

   3.1.2.1. Broadcast and Unknown Unicast Packets Case

   If NVO3 underlay network supports multicast, a new Target Object
   TLV--L2 VN ID sub-TLV is defined to validate the VN context of L2
   network for broadcast or unknown unicast packets. The example TLV
   format for VXLAN is as followed:

   0                   1                   2                   3
   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type = X (P2MP ping for BU)  |          Length                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               VN ID (VXLAN VNI)                |  Reserved    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   Figure 1: L2 VN ID sub-TLV for VXLAN

   Note: BU - Broadcast, Unknown unicast.

   The above TLV format can be a general format used in P2MP ping Echo
   message for all NVO3 overlay technologies (i.e. VXLAN, NVGRE, etc)
   to validate the VN context of L2 network for the case of broadcast
   or unknown unicast packets.

   3.1.2.2. Multicast Packets Case

   For L3 multicast case, two new Target Object TLVs: VN IPv4/IPv6
   multicast sub-TLVs are defined for IPv4 and IPv6 overlay network as
   followed:

   0                   1                   2                   3
   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type= Y(P2MP ping for IPv4 M)|          Length                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Xia, et al              Expires May 24, 2014                  [Page 7]

Internet-Draft          NVO3 OVERLAY P2MP PING           November, 2014

   |                          VN ID                 |  Reserved    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          IPv4 Multicast Address               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          Figure 2: VN multicast sub-TLV for IPv4 overlay network


   0                   1                   2                   3
   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type= Z(P2MP ping for IPv6 M)|          Length                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          VN ID                 |  Reserved    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          IPv6 Multicast Address               |
   |                                                               |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          Figure 3: VN multicast sub-TLV for IPv6 overlay network

   Note: M - Multicast.

   In this case, in addition to the VN ID used for the validation of
   L2/L3 VN context, IPv4/IPv6 multicast address is needed to check if
   the target NVEs are on the path to the receiver of the corresponding
   MDT. NVEs MUST be able to snoop IGMP/MLD messages in order to
   remember it has multicast receiver attached.

3.2. Limiting the Scope of Responses

   To limit the scope of responses, NVO3 P2MP ping mechanisms MUST
   include specific TLV in Echo Request message to make the appointed
   target NVEs to respond Echo Request message, and other NVEs do not
   respond it.

   Section 3.2 of [RFC6425] defines the P2MP Responder Identifier TLV
   and four sub-TLVs (IPv4/IPv6 Egress Address P2MP Responder sub-TLVs,
   IPv4/IPv6 Node Address P2MP Responder sub-TLVs). The responding node
   upon receiving any of these sub-TLVs would respond or not respond to
   the Echo Request message thus achieving goal of limiting the scope
   of responses.




Xia, et al              Expires May 24, 2014                  [Page 8]

Internet-Draft          NVO3 OVERLAY P2MP PING           November, 2014

   To use IPv4/IPv6 Egress Address P2MP Responder sub-TLVs properly,
   the nodes that locate upstream in the MDT must know all the egress
   NVE IP addresses. Current multicast protocols (i.e., PIM-SM, PIM-DM,
   IGMP, MLD, etc) cannot meet this requirement. So, these two sub-TLVs
   cannot be used for the NVO3 P2MP ping mechanisms.

   Without any extra requirement, IPv4/IPv6 Node Address P2MP Responder
   sub-TLVs definition and related operations remain the same for NVO3
   P2MP ping mechanisms.

3.3. Other TLVs and Flags

   The Echo Jitter TLV and the intended behavior of the responding node
   upon receiving it, defined in Section 3.3 of [RFC6425], remain the
   same to help to limit congestion of Echo replies.

   The Respond Only If TTL Expired Flag in the Global Flags field
   defined in Section 3.4 of [RFC6425] is inherited here with one
   change: TTL to be checked is in the outer IP header.

4. Theory of Operation

   This section refers to Section 4 of [RFC6425] to describe how the
   NVO3 P2MP Echo messages are processed at various nodes, e.g. ingress
   NVE, transit nodes, etc. This section also discusses the different
   mechanisms for ping mode and traceroute mode.

   Note that the main goal of this section is to describe the changes
   that existing P2MP MPLS ping operations need to make in order to
   make it applicable for NVO3 network. The unchanged operations are
   listed here briefly. The details can refer to Section 4 of [RFC6425].

4.1. No Multicast Support by NVO3 Underlay Network

   For ping mode, NVO3 P2MP Echo Request messages are replicated at
   ingress NVE or multicast service node and sent each copy of the
   message to destination NVEs through unicast NVO3 encapsulation. This
   mode is more often used by Connectivity Verification function.

   For traceroute mode, NVO3 P2MP Echo Request messages are replicated
   at ingress NVE or multicast service node, and then each copy of the
   message will be sent to desired transit nodes through unicast
   encapsulation with specific TTL value in outer IP header. This mode
   can be used for Fault Localization or Path Tracing functions.

   Ingress NVE or multicast service node can send Echo Request messages
   to one or a set of members of egress NVEs, or their transit nodes by



Xia, et al              Expires May 24, 2014                  [Page 9]

Internet-Draft          NVO3 OVERLAY P2MP PING           November, 2014

   their choice. Because all the Echo Request messages are sent by
   unicast, the operations onto them remain the same as with NVO3 P2P
   ping mechanisms defined in [NVO3OVERLAYPING].

   In addition, ingress NVE is still possible to send multiple Echo
   Request messages to multiple target nodes and gets many Echo Reply
   messages in a short period, which will cause congestion on the
   ingress NVE. So, the Echo Jitter TLV and according random delay
   reply mechanism defined in [RFC6425] should be supported for this
   case.

4.2. Multicast Support by NVO3 Underlay Network

   Because NVO3 underlay network supports multicast protocol, NVO3
   overlay network can use the underlay MDT to transfer BUM traffics
   and the NVO3 P2MP Echo Request messages. The elements in the MDT
   include ingress node, transit node, branch node, bud node, egress
   node. They have different operations on the P2MP Echo Request
   messages which are described in the following sections.

    4.2.1. Ingress NVE Operations

   Ingress NVE should follow the procedure defined in [RFC4379] to
   construct the P2MP Echo Request message. The packet format MUST be
   the extended format described in Section 3 of this document and it
   MUST be IP encapsulated.

   Echo Request message will contain a Target Object TLV to identify
   NVE membership. L2 VN ID sub-TLV is for broadcast or unknown unicast
   case, VN IPv4/IPv6 multicast sub-TLVs is for L3 multicast case.

   Echo Request message can contain IPv4/IPv6 Node Address P2MP
   Responder sub-TLVs to limit responses from only those targeted nodes
   under the ping mode.

   The Echo Jitter TLV can also be contained to limit the congestion in
   the ingress NVE.

    4.2.2. Responding Node Operations

   Except for the ingress NVE, other nodes potentially are to act as a
   responding node.

   Usually the Echo Request message will be addressed to the egress
   and/or bud nodes. In case of TTL Expiry, i.e. in the traceroute mode,
   the Echo Request message may stop at branch or transit nodes. In




Xia, et al              Expires May 24, 2014                 [Page 10]

Internet-Draft          NVO3 OVERLAY P2MP PING           November, 2014

   both scenarios, the Echo Request message will be passed on to the
   control plane to generate the Echo Reply message.

   After the rate-limit control and sanity check, the responding node
   MUST determine how to reply based on the Reply Mode field. Then, the
   responding node MUST determine if it is on the underlay MDT in
   question which the overlay P2MP path is tunneled on by checking the
   destination multicast address against the control plane:

   o If the responding node is not on the underlay MDT in question, it
      MUST send Echo Reply with Return Code "Replying node has no
      control plane mapping for the Target Object" and Return Subcode
      as 1 which implies the MDT address check failure, as defined in
      [NVO3OVERLAYPING];

   o If the node is on the underlay MDT in question, the node MUST
      check whether or not the Echo Request is directed to it:

        o  If a P2MP Responder Identifier TLV is present, then the node
          MUST follow the procedures defined in Section 3.2 to
          determine whether or not it should respond to the request;

        o  If the P2MP Responder Identifier TLV is not present (or, in
          the error case, is present, but does not contain any sub-
          TLVs), then the node MUST respond according to
          [NVO3OVERLAYPING] processing rules.

   The following sections describe the expected values of Return Codes
   for various nodes on the underlay MDT which the overlay P2MP path is
   tunneled on. Note that the Return Code might change based on the
   presence of a Responder Identifier TLV or Downstream Detailed
   Mapping TLV.

   4.2.2.1. Responses from Transit and Branch Nodes

   The presence of a Responder Identifier TLV does not influence the
   choice of the Return Code. To report success, the Return Code MAY be
   set to "Packet-Forward-OK". For error conditions, use appropriate
   values defined in [NVO3OVERLAYPING].

   The presence of a Downstream Detailed Mapping TLV will influence the
   choice of Return Code. As per [RFC6424], the Return Code may be set
   to "See DDM TLV for Return Code and Return Subcode". The Return Code
   for each Downstream Detailed Mapping TLV will depend on the
   downstream path as described in [RFC6424].





Xia, et al              Expires May 24, 2014                 [Page 11]

Internet-Draft          NVO3 OVERLAY P2MP PING           November, 2014

   There will be a Downstream Detailed Mapping TLV for each downstream
   path being reported in the Echo Reply.  Hence, for transit nodes,
   there will be only one such TLV, and for branch nodes, there will be
   more than one.

   4.2.2.2. Responses from Egress Nodes

   The presence of a Responder Identifier TLV does not influence the
   choice of the Return Code. To report success, the Return Code MAY be
   set to "Egress for the Target", as defined in [NVO3OVERLAYPING]. For
   error conditions, use appropriate values defined in
   [NVO3OVERLAYPING].

   To check whether a NVE is an egress NVE for an overlay P2MP path,
   two cases need to be differentiated according to previous analysis:

   o Broadcast or unknown unicast overlay path case: L2 VN ID sub-TLV
      should be contained in the Echo Request message, which includes
      the L2 VN ID need to be validated. An NVE determines if it is the
      egress NVE for this VN by checking if there is an entry of this
      VN ID existed in the NVE. If it is the egress NVE, MUST return
      the success response;

   o L3 multicast overlay path case: VN IPv4/IPv6 multicast sub-TLV
      should be contained in the Echo Request message. Except for the
      same VN ID validation procedure as above, NVE also needs to check
      if it is on the path to a receiver of this IPv4/IPv6 multicast
      address, which is included in VN IPv4/IPv6 multicast sub-TLV.
      Only if all the validations are OK, the NVE thinks itself an
      egress NVE and MUST return the success response.

   To save the MDT number in the NVO3 underlay network, multiple
   overlay P2MP paths may share the same underlay MDT. The egress NVEs
   of one overlay P2MP path of them may be a subset of the egress nodes
   of MDT. When the NVO3 P2MP Echo Request messages for this overlay
   P2MP path are sent to all the egress nodes of MDT and get response
   from them, some egress NVEs that do not belong to this overlay P2MP
   path SHOULD reply with Return Code "Replying node has no control
   plane mapping for the Target Object" and Return Subcode as 1 to the
   ingress NVE. Note that this does not mean the error condition for
   the egress NVE.

   The presence of the Downstream Detailed Mapping TLV does not
   influence the choice of Return Code. Egress NVEs do not put in any
   Downstream Detailed Mapping TLV in the Echo Reply as per [RFC6424].





Xia, et al              Expires May 24, 2014                 [Page 12]

Internet-Draft          NVO3 OVERLAY P2MP PING           November, 2014

   4.2.2.3. Responses from Bud Nodes

   The processing at bud nodes is more complex than other types of MDT
   nodes.  The bud node behaves as either an egress node or a transit
   node, or a combination of an egress and branch node. This behavior
   is determined by the presence of any Responder Identifier TLV.
   Similarly, the Downstream Detailed Mapping TLV can influence the
   Return Code values.

   To determine the behavior of the bud node, use the following rules:

   o If the Responder Identifier TLV is not present, then the node
      MUST behave as a combination of egress and branch node;

   o If the Responder Identifier TLV containing a Node Address sub-
      TLV is present, and:

        o  If the address specified in the sub-TLV matches to an address
          in the node, then the node MUST behave like a combination of
          egress and branch node;

        o  If the address specified in the sub-TLV does not match any
          address in the node, then no reply SHOULD be sent.

   Once the node behavior has been determined, the possible values for
   Return Codes are as follows:

   o If the node is behaving as a combination of egress and branch
      node, and:

        o  If a Downstream Detailed Mapping TLV is not present, then for
          a success response, the Return Code SHOULD be set to "Egress
          for the Target".  For error conditions, use appropriate
          values defined in [NVO3OVERLAYPING];

        o  If a Downstream Detailed Mapping TLV is present, then for a
          success response, the Return Code SHOULD be set to "Egress
          for the Target".  For error conditions, use appropriate
          values defined in [NVO3OVERLAYPING]. The Return Code for the
          each Downstream Detailed Mapping TLV will depend on the
          downstream path as described in [RFC6424].  There will be a
          Downstream Detailed Mapping TLV for each downstream path from
          the node.







Xia, et al              Expires May 24, 2014                 [Page 13]

Internet-Draft          NVO3 OVERLAY P2MP PING           November, 2014

4.3. Special Considerations for Traceroute

   Comparing to P2P ping, P2MP ping has a new problem of how to figure
   out the end of the traceroute processing. The relevant background
   can refer to Section 4.3.1 of [RFC6425]. For the two cases of NVO3
   P2MP ping:

   o Replication at ingress NVE or multicast service node: Because the
      initiating node has a priori knowledge about the number of egress
      nodes and their addresses, it is possible to continue processing
      until a valid reply has been received from each end point,
      provided that the replies can be matched correctly to the egress
      NVEs;

   o Underlay network multicast supporting: the ingress NVE might not
      always know about all of the egress NVEs. Hence, there might not
      be a definitive way to estimate the end of processing for
      traceroute. Therefore, a configurable upper limit on TTL values
      is a good solution for this case.  By this way, the user can
      choose the depth to which the tree will be probed.

   The other problems of traceroute mode for MPLS P2MP ping also exist
   for NVO3 P2MP ping. The specific mechanisms defined in Sections
   4.3.2, 4.3.3, 4.3.4, 4.3.5 of [RFC6425] are all applicable to NVO3
   P2MP ping.

5. Hierarchical NVE Scenario

   TBD

6. Security Considerations

   TBD.

7. Acknowledgements



8. IANA Considerations



8.1. TLVs

   The TLVs and Sub-TLVs requested by this draft for IANA consideration
   are the following:




Xia, et al              Expires May 24, 2014                 [Page 14]

Internet-Draft          NVO3 OVERLAY P2MP PING           November, 2014

                 Type        Sub-Type            Value Field

                -------      --------            -----------

                 XXX                             Target Object

                                 X               L2 VN ID

                                 X               VN IPv4/IPv6 multicast

9. References

9.1. Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", BCP 14, RFC2119, March 1997

   [RFC4379]  Allan, D. and T. Nadeau, "A Framework for Multi-Protocol
   Label Switching (MPLS) Operations and Management (OAM)", RFC 4378,
   February 2006

   [RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC
   792, September 1981

   [RFC6425] Saxena, S., et al, "Detecting Data Plane Failures in
   Point-to-Multipoint Multiprotocol Label Switching (MPLS) -
   Extensions to LSP", RFC 6425, November 2011

   [RFC6424]   Bahadur, N., Kompella, K., and G. Swallow, "Mechanism
   for Performing LSP-Ping over MPLS Tunnels", RFC 6424, November 2011

   [RFC7348]  Mahalingam, M., Dutt, D., et al, "Virtual eXtensible
   Local Area Network (VXLAN): A Framework for Overlaying Virtualized
   Layer 2 Networks over Layer 3 Networks", RFC7348, August, 2014

   [RFC7365] LASSERRE, M., Motin, T., et al, "Framework for DC Network
   Virtualization", RFC7365, October, 2014

9.2. Informative References

   [NVO3OVERLAYOAM]  Jain, P., et al, "Generic Overlay OAM and Datapath
   Failure Detection", draft-jain-nvo3-overlay-oam-02, work in progress,
   October, 2014

   [NVO3OVERLAYPING] Kumar, N., "Detecting NVO3 Overlay Data Plane
   failures", draft-kumar-nvo3-overlay-ping-01, work in progress,
   January, 2014



Xia, et al              Expires May 24, 2014                 [Page 15]

Internet-Draft          NVO3 OVERLAY P2MP PING           November, 2014

   [NVGRE]  Sridharan, M., et al, "NVGRE: Network Virtualization using
   Generic Routing Encapsulation", draft-sridharan-virtualization-
   nvgre-06, work in progress, October, 2014

   [NVO3MCAST] Ghanwani, A., et al, "Framework of Supporting
   Applications Specific Multicast in NVO3", draft-ghanwani-nvo3-app-
   mcast-framework-00, work in progress, June, 2014





   Authors' Addresses


   Liang Xia
   Huawei Technologies

   Email: frank.xialiang@huawei.com

   Weiguo Hao
   Huawei Technologies
   101 Software Avenue,
   Nanjing 210012
   China
   Phone: +86-25-56623144
   Email: haoweiguo@huawei.com

   Greg Mirsky
   Ericsson

   EMail: gregory.mirsky@ericsson.com

















Xia, et al              Expires May 24, 2014                 [Page 16]