One document matched: draft-xia-nvo3-overlay-p2mp-ping-00.txt
NVO3 working group L. Xia
Internet Draft Weiguo Hao
Category: Standard Track Huawei
Expires: November 21, 2014 Greg Mirsky
Ericsson
May 21, 2014
Detecting NVO3 Overlay Point-to-Multipoint Data Plane failures
draft-xia-nvo3-overlay-p2mp-ping-00
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 November 21, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
Xia, et al Expires November 21, 2014 [Page 1]
Internet-Draft NVO3 OVERLAY P2MP PING MAY, 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. Mechanism Overview .......................................... 5
2.1. NVO3 Network Multicast Methods ......................... 5
2.2. NVO3 P2MP Ping Mechanism ............................... 5
3. Packet Format ............................................... 6
3.1. Identifying the P2MP NVO3 Overlay Path ................. 7
3.1.1. No Multicast Support by NVO3 Underlay Network ..... 7
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 ....................... 11
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 November 21, 2014 [Page 2]
Internet-Draft NVO3 OVERLAY P2MP PING MAY, 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 [VXLAN],
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 to
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 use either NVO3 overlay encapsulation or
underlay encapsulation. 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 November 21, 2014 [Page 3]
Internet-Draft NVO3 OVERLAY P2MP PING MAY, 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 of 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
in order to simplify implementation and network operation.
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 [NVO3FRWK],
[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 October 21, 2014 [Page 4]
Internet-Draft NVO3 OVERLAY P2MP PING MAY, 2014
2. Mechanism Overview
2.1. NVO3 Network Multicast Methods
The MDT for BUM packets is created 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 of NVEs connected to the other part of the same L2
overlay network are all egress NVEs for that MDT. If NVO3
underlay network supports multicast, then Bidirectional PIM
(BIDIR-PIM) is appropriate for this case because of its better
scalability;
o For L3 multicast packets, maybe only a member set of NVEs in a
tenant network need to be involved. The NVE connected to the
multicast source node is the ingress NVE; other NVEs connected to
a node that receives multicast traffic are all egress NVEs for
that MDT. Even if NVO3 underlay network supports multicast, the
Bidirectional PIM (BIDIR-PIM) is not appropriate for this case
because ingress NVE and egress NVEs for specific multicast group
are fixed and do not changed. PIM-SM or PIM-SSM is more
appropriate.
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.
When the NVO3 underlay network supports multicast, the ingress NVE
directly encapsulates the packet 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.
2.2. NVO3 P2MP Ping Mechanism
Comparing to NVO3 P2P overlay services, NVO3 P2MP overlay services
are more complex. To have the abilities mentioned in Section 1, the
NVO3 P2MP ping needs some extensions to the current NVO3 ping
mechanism.
Xia, et al Expires November 21, 2014 [Page 5]
Internet-Draft NVO3 OVERLAY P2MP PING MAY, 2014
This draft refers to [RFC6425] and describes the following
extensions:
o The packet format extension to the NVO3 overlay P2MP Echo
Request/Reply messages;
o The extensive mechanisms of NVO3 overlay P2MP ping operations;
o Different operation mechanisms 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 mentioned 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 include:
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 extended format specifications, NVO3 P2MP ping
needs to define new TLVs and sub-TLVs to support the functionality
specific to its P2MP application.
Xia, et al Expires November 21, 2014 [Page 6]
Internet-Draft NVO3 OVERLAY P2MP PING MAY, 2014
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 BUM traffic at ingress NVE or multicast service
node and sends such packets by unicast. NVO3 P2MP ping requires
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 mentioned
above 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 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 Echo
message for all NVO3 IPv4/IPv6 overlay technologies (i.e. VXLAN,
NVGRE, etc) to validate the VN context of L2 network for broadcast
or unknown unicast packets.
3.1.2.2. Multicast Packets Case
For L3 multicast service, two new Target Object TLVs: VN IPv4/IPv6
multicast sub-TLVs are defined for IPv4 and IPv6 overlay network as
followed:
Xia, et al Expires November 21, 2014 [Page 7]
Internet-Draft NVO3 OVERLAY P2MP PING MAY, 2014
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 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 a receiver of the MDT corresponding to this
IPv4/IPv6 multicast address. NVE 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 mechanism 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.
Xia, et al Expires November 21, 2014 [Page 8]
Internet-Draft NVO3 OVERLAY P2MP PING MAY, 2014
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.
To use IPv4/IPv6 Egress Address P2MP Responder sub-TLVs properly,
the nodes that lie 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.
Without any extra requirement, IPv4/IPv6 Node Address P2MP Responder
sub-TLVs definition and related behavior can be remained the same
for NVO3 P2MP ping.
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 node, 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 in order to make it
applicable for NVO3 P2MP ping. The unchanged operations are
mentioned here briefly and for details we 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.
Xia, et al Expires November 21, 2014 [Page 9]
Internet-Draft NVO3 OVERLAY P2MP PING MAY, 2014
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
their choice. Because all the Echo Request messages are sent by
unicast, the operations onto them remain the same as with NVO3 P2P
ping mechanism 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 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.
Xia, et al Expires November 21, 2014 [Page 10]
Internet-Draft NVO3 OVERLAY P2MP PING MAY, 2014
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
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].
Xia, et al Expires November 21, 2014 [Page 11]
Internet-Draft NVO3 OVERLAY P2MP PING MAY, 2014
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].
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 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.
Xia, et al Expires November 21, 2014 [Page 12]
Internet-Draft NVO3 OVERLAY P2MP PING MAY, 2014
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].
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 November 21, 2014 [Page 13]
Internet-Draft NVO3 OVERLAY P2MP PING MAY, 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
This draft reuses UDP port 3503 for NVO3 Echo packets.
8.1. TLVs
The TLVs and Sub-TLVs requested by this draft for IANA consideration
are the following:
Xia, et al Expires November 21, 2014 [Page 14]
Internet-Draft NVO3 OVERLAY P2MP PING MAY, 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.
9.2. Informative References
[NVO3OVERLAYOAM] Jain, P., et al, "Generic Overlay OAM and Datapath
Failure Detection", draft-jain-nvo3-overlay-oam-01, work in progress,
February, 2014
[NVO3OVERLAYPING] Kumar, N., "Detecting NVO3 Overlay Data Plane
failures", draft-kumar-nvo3-overlay-ping-01, work in progress,
January, 2014
[NVGRE] Sridharan, M., et al, "NVGRE: Network Virtualization using
Generic Routing Encapsulation", draft-sridharan-virtualization-
nvgre-04, work in progress, February, 2014
[VXLAN] Mahalingam, M., Dutt, D., et al, "VXLAN: A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3 Networks",
Xia, et al Expires November 21, 2014 [Page 15]
Internet-Draft NVO3 OVERLAY P2MP PING MAY, 2014
draft-mahalingam-dutt-dcops-vxlan-09, work in progress, February,
2014
[NVO3MCAST] Ghanwani, A., et al, "Multicast Issues in Networks Using
NVO3", draft-ghanwani-nvo3-mcast-issues-01, work in progress,
February, 2014
[NVO3FRWK] LASSERRE, M., Motin, T., et al, "Framework for DC Network
Virtualization", draft-ietf-nvo3-framework-05, work in progress,
January, 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 November 21, 2014 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-24 06:51:47 |