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]