draft-ietf-mpls-p2mp-lsp-ping-17.txt   draft-ietf-mpls-p2mp-lsp-ping-18.txt 
Network Working Group S. Saxena, Ed. Network Working Group S. Saxena, Ed.
Internet-Draft G. Swallow Internet-Draft G. Swallow
Intended Status: Standards Track Z. Ali Intended Status: Standards Track Z. Ali
Updates: 4379 (if approved) Cisco Systems, Inc. Updates: 4379 (if approved) Cisco Systems, Inc.
Expires: December 20, 2011 A. Farrel Expires: March 2, 2012 A. Farrel
Old Dog Consulting Juniper Networks
S. Yasukawa S. Yasukawa
NTT Corporation NTT Corporation
T. Nadeau T. Nadeau
CA Technologies LucidVision
June 20, 2011 September 2, 2011
Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol
Label Switching (MPLS) - Extensions to LSP Ping Label Switching (MPLS) - Extensions to LSP Ping
draft-ietf-mpls-p2mp-lsp-ping-17.txt draft-ietf-mpls-p2mp-lsp-ping-18.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.txt. http://www.ietf.org/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document updates RFC 4379.
Recent proposals have extended the scope of Multiprotocol Label Recent proposals have extended the scope of Multiprotocol Label
Switching (MPLS) Label Switched Paths (LSPs) to encompass Switching (MPLS) Label Switched Paths (LSPs) to encompass
point-to-multipoint (P2MP) LSPs. point-to-multipoint (P2MP) LSPs.
The requirement for a simple and efficient mechanism that can be used The requirement for a simple and efficient mechanism that can be used
to detect data plane failures in point-to-point (P2P) MPLS LSPs has to detect data plane failures in point-to-point (P2P) MPLS LSPs has
been recognized and has led to the development of techniques for been recognized and has led to the development of techniques for
fault detection and isolation commonly referred to as "LSP Ping". fault detection and isolation commonly referred to as "LSP Ping".
The scope of this document is fault detection and isolation for P2MP The scope of this document is fault detection and isolation for P2MP
MPLS LSPs. This documents does not replace any of the mechanisms of MPLS LSPs. This documents does not replace any of the mechanisms of
LSP Ping, but clarifies their applicability to MPLS P2MP LSPs, and LSP Ping, but clarifies their applicability to MPLS P2MP LSPs, and
extends the techniques and mechanisms of LSP Ping to the MPLS P2MP extends the techniques and mechanisms of LSP Ping to the MPLS P2MP
environment. environment.
This document updates RFC 4379.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
skipping to change at page 2, line 40 skipping to change at page 2, line 42
3. Packet Format................................................... 7 3. Packet Format................................................... 7
3.1. Identifying the LSP Under Test................................ 7 3.1. Identifying the LSP Under Test................................ 7
3.1.1. Identifying a P2MP MPLS TE LSP.............................. 7 3.1.1. Identifying a P2MP MPLS TE LSP.............................. 7
3.1.1.1. RSVP P2MP IPv4 Session Sub-TLV............................ 8 3.1.1.1. RSVP P2MP IPv4 Session Sub-TLV............................ 8
3.1.1.2. RSVP P2MP IPv6 Session Sub-TLV............................ 8 3.1.1.2. RSVP P2MP IPv6 Session Sub-TLV............................ 8
3.1.2. Identifying a Multicast LDP LSP............................. 9 3.1.2. Identifying a Multicast LDP LSP............................. 9
3.1.2.1. Multicast LDP FEC Stack Sub-TLVs.......................... 9 3.1.2.1. Multicast LDP FEC Stack Sub-TLVs.......................... 9
3.1.2.2. Applicability to Multipoint-to-Multipoint LSPs........... 11 3.1.2.2. Applicability to Multipoint-to-Multipoint LSPs........... 11
3.2. Limiting the Scope of Responses.............................. 11 3.2. Limiting the Scope of Responses.............................. 11
3.2.1. Egress Address P2MP Responder Identifier Sub-TLVs.......... 12 3.2.1. Egress Address P2MP Responder Identifier Sub-TLVs.......... 12
3.2.2. Node Address P2MP Responder Identifier Sub-TLVs............ 12 3.2.2. Node Address P2MP Responder Identifier Sub-TLVs............ 13
3.3. Preventing Congestion of Echo Replies........................ 12 3.3. Preventing Congestion of Echo Replies........................ 14
3.4. Respond Only If TTL Expired Flag............................. 13 3.4. Respond Only If TTL Expired Flag............................. 14
3.5. Downstream Detailed Mapping TLV.............................. 14 3.5. Downstream Detailed Mapping TLV.............................. 15
4. Operation of LSP Ping for a P2MP LSP........................... 14 4. Operation of LSP Ping for a P2MP LSP........................... 15
4.1. Initiating LSR Operations.................................... 15 4.1. Initiating LSR Operations.................................... 16
4.1.1. Limiting Responses to Echo Requests........................ 15 4.1.1. Limiting Responses to Echo Requests........................ 16
4.1.2. Jittered Responses to Echo Requests........................ 15 4.1.2. Jittered Responses to Echo Requests........................ 16
4.2. Responding LSR Operations.................................... 16 4.2. Responding LSR Operations.................................... 17
4.2.1. Echo Reply Reporting....................................... 17 4.2.1. Echo Reply Reporting....................................... 18
4.2.1.1. Responses from Transit and Branch Nodes.................. 17 4.2.1.1. Responses from Transit and Branch Nodes.................. 19
4.2.1.2. Responses from Egress Nodes.............................. 18 4.2.1.2. Responses from Egress Nodes.............................. 19
4.2.1.3. Responses from Bud Nodes................................. 18 4.2.1.3. Responses from Bud Nodes................................. 20
4.3. Special Considerations for Traceroute........................ 20 4.3. Special Considerations for Traceroute........................ 21
4.3.1. End of Processing for Traceroute........................... 20 4.3.1. End of Processing for Traceroutes.......................... 21
4.3.2. Multiple responses from Bud and Egress Nodes............... 21 4.3.2. Multiple responses from Bud and Egress Nodes............... 22
4.3.3. Non-Response to Traceroute Echo Requests................... 21 4.3.3. Non-Response to Traceroute Echo Requests................... 23
4.3.4. Use of Downstream Detailed Mapping TLV in Echo Request..... 21 4.3.4. Use of Downstream Detailed Mapping TLV in Echo Request..... 23
4.3.5 Cross-Over Node Processing.................................. 22 4.3.5 Cross-Over Node Processing.................................. 23
5. Non-compliant Routers.......................................... 22 5. Non-compliant Routers.......................................... 24
6. OAM and Management Considerations.............................. 23 6. OAM and Management Considerations.............................. 24
7. IANA Considerations............................................ 23 7. IANA Considerations............................................ 25
7.1. New Sub-TLV Types............................................ 23 7.1. New Sub-TLV Types............................................ 25
7.2. New TLVs..................................................... 24 7.2. New TLVs..................................................... 26
8. Security Considerations........................................ 24 7.3. New Global Flags Registry.................................... 26
9. Acknowledgements............................................... 24 8. Security Considerations........................................ 26
10. References.................................................... 25 9. Acknowledgements............................................... 27
10.1. Normative References........................................ 25 10. References.................................................... 27
10.2. Informative References...................................... 25 10.1. Normative References........................................ 27
11. Authors' Addresses............................................ 26 10.2. Informative References...................................... 27
12. Full Copyright Statement...................................... 27 11. Authors' Addresses............................................ 28
12. Full Copyright Statement...................................... 29
1. Introduction 1. Introduction
Simple and efficient mechanisms that can be used to detect data plane Simple and efficient mechanisms that can be used to detect data plane
failures in point-to-point (P2P) Multiprotocol Label Switching (MPLS) failures in point-to-point (P2P) Multiprotocol Label Switching (MPLS)
Label Switched Paths (LSP) are described in [RFC4379]. The Label Switched Paths (LSP) are described in [RFC4379]. The
techniques involve information carried in MPLS "Echo Request" and techniques involve information carried in MPLS "Echo Request" and
"Echo Reply" messages, and mechanisms for transporting them. The "Echo Reply" messages, and mechanisms for transporting them. The
echo request and reply messages provide sufficient information to echo request and reply messages provide sufficient information to
check correct operation of the data plane, as well as a mechanism to check correct operation of the data plane, as well as a mechanism to
skipping to change at page 4, line 22 skipping to change at page 4, line 25
rather than invent new mechanisms. rather than invent new mechanisms.
As for P2P LSPs, a critical requirement is that the echo request As for P2P LSPs, a critical requirement is that the echo request
messages follow the same data path that normal MPLS packets traverse. messages follow the same data path that normal MPLS packets traverse.
However, it can be seen this notion needs to be extended for P2MP However, it can be seen this notion needs to be extended for P2MP
MPLS LSPs, as in this case an MPLS packet is replicated so that it MPLS LSPs, as in this case an MPLS packet is replicated so that it
arrives at each egress (or leaf) of the P2MP tree. arrives at each egress (or leaf) of the P2MP tree.
MPLS echo requests are meant primarily to validate the data plane, MPLS echo requests are meant primarily to validate the data plane,
and they can then be used to validate data plane state against the and they can then be used to validate data plane state against the
control plane. They may also be used to bootstrap other OAM control plane. They may also be used to bootstrap other Operations,
procedures such as [RFC5884]. As pointed out in [RFC4379], Administration, and Maintenance (OAM) procedures such as [RFC5884].
mechanisms to check the liveness, function, and consistency of the As pointed out in [RFC4379], mechanisms to check the liveness,
control plane are valuable, but such mechanisms are not a feature of function, and consistency of the control plane are valuable, but such
LSP Ping and are not covered in this document. mechanisms are not a feature of LSP Ping and are not covered in this
document.
As is described in [RFC4379], to avoid potential Denial of Service As is described in [RFC4379], to avoid potential Denial of Service
attacks, it is RECOMMENDED to regulate the LSP Ping traffic passed to attacks, it is RECOMMENDED to regulate the LSP Ping traffic passed to
the control plane. A rate limiter should be applied to the incoming the control plane. A rate limiter should be applied to the incoming
LSP Ping traffic. LSP Ping traffic.
1.2 Terminology 1.2 Terminology
The terminology used in this document for P2MP MPLS can be found in The terminology used in this document for P2MP MPLS can be found in
[RFC4461]. The terminology for MPLS OAM can be found in [RFC4379]. [RFC4461]. The terminology for MPLS OAM can be found in [RFC4379].
In particular, the notation <RSC> refers to the Return Subcode as In particular, the notation <RSC> refers to the Return Subcode as
defined in section 3.1. of [RFC4379]. defined in section 3.1. of [RFC4379].
2. Notes on Motivation 2. Notes on Motivation
2.1. Basic Motivations for LSP Ping 2.1. Basic Motivations for LSP Ping
The motivations listed in [RFC4379] are reproduced here for The motivations listed in [RFC4379] are reproduced here for
completeness. completeness.
When an LSP fails to deliver user traffic, the failure cannot always When an LSP fails to deliver user traffic, the failure cannot
be detected by the MPLS control plane. There is a need to provide a always be detected by the MPLS control plane. There is a need to
tool that enables users to detect such traffic "black holes" or provide a tool that enables users to detect such traffic "black
misrouting within a reasonable period of time. A mechanism to holes" or misrouting within a reasonable period of time. A
isolate faults is also required. mechanism to isolate faults is also required.
[RFC4379] describes a mechanism that accomplishes these goals. This [RFC4379] describes a mechanism that accomplishes these goals.
mechanism is modeled after the ping/traceroute paradigm: ping (ICMP This mechanism is modeled after the ping/traceroute paradigm:
echo request [RFC792]) is used for connectivity checks, and ping (ICMP echo request [RFC792]) is used for connectivity
traceroute is used for hop-by-hop fault localization as well as path checks, and traceroute is used for hop-by-hop fault localization
tracing. [RFC4379] specifies a "ping mode" and a "traceroute" mode as well as path tracing. [RFC4379] specifies a "ping mode" and a
for testing MPLS LSPs. "traceroute" mode for testing MPLS LSPs.
The basic idea as expressed in [RFC4379] is to test that the packets The basic idea as expressed in [RFC4379] is to test that the
that belong to a particular Forwarding Equivalence Class (FEC) packets that belong to a particular Forwarding Equivalence Class
actually end their MPLS path on an LSR that is an egress for that (FEC) actually end their MPLS path on an LSR that is an egress
FEC. [RFC4379] achieves this test by sending a packet (called an for that FEC. [RFC4379] achieves this test by sending a packet
"MPLS echo request") along the same data path as other packets (called an "MPLS echo request") along the same data path as other
belonging to this FEC. An MPLS echo request also carries information packets belonging to this FEC. An MPLS echo request also carries
about the FEC whose MPLS path is being verified. This echo request information about the FEC whose MPLS path is being verified.
is forwarded just like any other packet belonging to that FEC. In This echo request is forwarded just like any other packet
"ping" mode (basic connectivity check), the packet should reach the belonging to that FEC. In "ping" mode (basic connectivity
end of the path, at which point it is sent to the control plane of check), the packet should reach the end of the path, at which
the egress LSR, which then verifies that it is indeed an egress for point it is sent to the control plane of the egress LSR, which
the FEC. In "traceroute" mode (fault isolation), the packet is sent then verifies that it is indeed an egress for the FEC. In
to the control plane of each transit LSR, which performs various "traceroute" mode (fault isolation), the packet is sent to the
checks that it is indeed a transit LSR for this path; this LSR also control plane of each transit LSR, which performs various checks
returns further information that helps to check the control plane that it is indeed a transit LSR for this path; this LSR also
against the data plane, i.e., that forwarding matches what the returns further information that helps to check the control plane
routing protocols determined as the path. against the data plane, i.e., that forwarding matches what the
routing protocols determined as the path.
One way these tools can be used is to periodically ping a FEC to One way these tools can be used is to periodically ping a FEC to
ensure connectivity. If the ping fails, one can then initiate a ensure connectivity. If the ping fails, one can then initiate a
traceroute to determine where the fault lies. One can also traceroute to determine where the fault lies. One can also
periodically traceroute FECs to verify that forwarding matches the periodically traceroute FECs to verify that forwarding matches
control plane; however, this places a greater burden on transit LSRs the control plane; however, this places a greater burden on
and should be used with caution. transit LSRs and should be used with caution.
2.2. Motivations for LSP Ping for P2MP LSPs 2.2. Motivations for LSP Ping for P2MP LSPs
As stated in [RFC4687], MPLS has been extended to encompass P2MP As stated in [RFC4687], MPLS has been extended to encompass P2MP
LSPs. As with P2P MPLS LSPs, the requirement to detect, handle, and LSPs. As with P2P MPLS LSPs, the requirement to detect, handle, and
diagnose control and data plane defects is critical. For operators diagnose control and data plane defects is critical. For operators
deploying services based on P2MP MPLS LSPs, the detection and deploying services based on P2MP MPLS LSPs, the detection and
specification of how to handle those defects is important because specification of how to handle those defects is important because
such defects may affect the fundamentals of an MPLS network, but also such defects may affect the fundamentals of an MPLS network, but also
because they may impact service level specification commitments for because they may impact service level specification commitments for
skipping to change at page 7, line 48 skipping to change at page 8, line 7
Session sub-TLV or an RSVP P2MP IPv6 Session sub-TLV. These sub-TLVs Session sub-TLV or an RSVP P2MP IPv6 Session sub-TLV. These sub-TLVs
carry fields from the RSVP-TE P2MP Session and Sender-Template carry fields from the RSVP-TE P2MP Session and Sender-Template
objects [RFC4875] and so provide sufficient information to uniquely objects [RFC4875] and so provide sufficient information to uniquely
identify the LSP. identify the LSP.
The new sub-TLVs are assigned sub-type identifiers as follows, and The new sub-TLVs are assigned sub-type identifiers as follows, and
are described in the following sections. are described in the following sections.
Sub-Type # Length Value Field Sub-Type # Length Value Field
---------- ------ ----------- ---------- ------ -----------
TBD 20 RSVP P2MP IPv4 Session TBD1 20 RSVP P2MP IPv4 Session
TBD 56 RSVP P2MP IPv6 Session TBD2 56 RSVP P2MP IPv6 Session
3.1.1.1. RSVP P2MP IPv4 Session Sub-TLV 3.1.1.1. RSVP P2MP IPv4 Session Sub-TLV
The format of the RSVP P2MP IPv4 Session sub-TLV value field is The format of the RSVP P2MP IPv4 Session sub-TLV value field is
specified in the following figure. The value fields are taken from specified in the following figure. The value fields are taken from
the definitions of the P2MP IPv4 LSP Session Object and the P2MP IPv4 the definitions of the P2MP IPv4 LSP Session Object and the P2MP IPv4
Sender-Template Object in Sections 19.1.1 and 19.2.1 of [RFC4875]. Sender-Template Object in Sections 19.1.1 and 19.2.1 of [RFC4875].
Note that the Sub-Group ID of the Sender-Template is not required. Note that the Sub-Group ID of the Sender-Template is not required.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP ID | | P2MP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | Tunnel ID | | MUST Be Zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID | | Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel sender address | | IPv4 tunnel sender address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | LSP ID | | MUST Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.1.1.2. RSVP P2MP IPv6 Session Sub-TLV 3.1.1.2. RSVP P2MP IPv6 Session Sub-TLV
The format of the RSVP P2MP IPv6 Session sub-TLV value field is The format of the RSVP P2MP IPv6 Session sub-TLV value field is
specified in the following figure. The value fields are taken from specified in the following figure. The value fields are taken from
the definitions of the P2MP IPv6 LSP Session Object, and the P2MP the definitions of the P2MP IPv6 LSP Session Object, and the P2MP
IPv6 Sender-Template Object in Sections 19.1.2 and 19.2.2 of IPv6 Sender-Template Object in Sections 19.1.2 and 19.2.2 of
[RFC4875]. Note that the Sub-Group ID of the Sender-Template is not [RFC4875]. Note that the Sub-Group ID of the Sender-Template is not
required. required.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| P2MP ID | | P2MP ID |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | Tunnel ID | | MUST Be Zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Extended Tunnel ID | | Extended Tunnel ID |
| | | |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IPv6 tunnel sender address | | IPv6 tunnel sender address |
| | | |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | LSP ID | | MUST Be Zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.1.2. Identifying a Multicast LDP LSP 3.1.2. Identifying a Multicast LDP LSP
[RFC4379] defines how a P2P LDP LSP under test may be identified in [RFC4379] defines how a P2P LDP LSP under test may be identified in
an echo request. A Target FEC Stack TLV is used to carry one or more an echo request. A Target FEC Stack TLV is used to carry one or more
sub-TLVs (for example, an IPv4 Prefix FEC sub-TLV) that identify the sub-TLVs (for example, an IPv4 Prefix FEC sub-TLV) that identify the
LSP. LSP.
In order to identify a multicast LDP LSP under test, the echo request In order to identify a multicast LDP LSP under test, the echo request
skipping to change at page 9, line 44 skipping to change at page 9, line 44
exactly one of two new sub-TLVs: either a Multicast P2MP LDP FEC exactly one of two new sub-TLVs: either a Multicast P2MP LDP FEC
Stack sub-TLV or a Multicast MP2MP LDP FEC Stack sub-TLV. These Stack sub-TLV or a Multicast MP2MP LDP FEC Stack sub-TLV. These
sub-TLVs use fields from the multicast LDP messages [P2MP-LDP] and so sub-TLVs use fields from the multicast LDP messages [P2MP-LDP] and so
provides sufficient information to uniquely identify the LSP. provides sufficient information to uniquely identify the LSP.
The new sub-TLVs are assigned sub-type identifiers as follows, and The new sub-TLVs are assigned sub-type identifiers as follows, and
are described in the following section. are described in the following section.
Sub-Type # Length Value Field Sub-Type # Length Value Field
---------- ------ ----------- ---------- ------ -----------
TBD Variable Multicast P2MP LDP FEC Stack TBD3 Variable Multicast P2MP LDP FEC Stack
TBD Variable Multicast MP2MP LDP FEC Stack TBD4 Variable Multicast MP2MP LDP FEC Stack
3.1.2.1. Multicast LDP FEC Stack Sub-TLVs 3.1.2.1. Multicast LDP FEC Stack Sub-TLVs
Both Multicast P2MP and MP2MP LDP FEC Stack have the same format, as Both Multicast P2MP and MP2MP LDP FEC Stack have the same format, as
specified in the following figure. specified in the following figure.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | Address Length| Root LSR Addr | | Address Family | Address Length| Root LSR Addr |
skipping to change at page 11, line 19 skipping to change at page 11, line 19
tree, any leaf node can be treated like a head node of a P2MP tree. tree, any leaf node can be treated like a head node of a P2MP tree.
In other words, for MPLS OAM purposes, the MP2MP tree can be treated In other words, for MPLS OAM purposes, the MP2MP tree can be treated
like a collection of P2MP trees, with each MP2MP leaf node acting like a collection of P2MP trees, with each MP2MP leaf node acting
like a P2MP head-end node. When a leaf node is acting like a P2MP like a P2MP head-end node. When a leaf node is acting like a P2MP
head-end node, the remaining leaf nodes act like egress or bud nodes. head-end node, the remaining leaf nodes act like egress or bud nodes.
3.2. Limiting the Scope of Responses 3.2. Limiting the Scope of Responses
A new TLV is defined for inclusion in the Echo request message. A new TLV is defined for inclusion in the Echo request message.
The P2MP Responder Identifier TLV is assigned the TLV type value TBD The P2MP Responder Identifier TLV is assigned the TLV type value TBD5
and is encoded as follows. and is encoded as follows.
0 1 2 3 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 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=TBD(P2MP Responder ID TLV)| Length = Variable | |Type = TBD5 (P2MP Responder ID)| Length = Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Sub-TLVs ~ ~ Sub-TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sub-TLVs: Sub-TLVs:
Zero, one or more sub-TLVs as defined below. Zero, one or more sub-TLVs as defined below.
If no sub-TLVs are present, the TLV MUST be processed as if it If no sub-TLVs are present, the TLV MUST be processed as if it
were absent. If more than one sub-TLV is present the first MUST were absent. If more than one sub-TLV is present the first MUST
be processed as described in this document, and subsequent be processed as described in this document, and subsequent
sub-TLVs SHOULD be ignored. sub-TLVs SHOULD be ignored. Interpretation of additional sub-
TLVs may be defined in future documents.
The P2MP Responder Identifier TLV only has meaning in an echo request The P2MP Responder Identifier TLV only has meaning on an echo request
message. If present in an echo reply message, it SHOULD be message. If present on an echo reply message, it MUST be
ignored. ignored.
Four sub-TLVs are defined for inclusion in the P2MP Responder Four sub-TLVs are defined for inclusion in the P2MP Responder
Identifier TLV carried on the echo request message. These are: Identifier TLV carried on the echo request message. These are:
Sub-Type # Length Value Field Sub-Type # Length Value Field
---------- ------ ----------- ---------- ------ -----------
1 4 IPv4 Egress Address P2MP Responder Identifier 1 4 IPv4 Egress Address P2MP Responder Identifier
2 16 IPv6 Egress Address P2MP Responder Identifier 2 16 IPv6 Egress Address P2MP Responder Identifier
3 4 IPv4 Node Address P2MP Responder Identifier 3 4 IPv4 Node Address P2MP Responder Identifier
4 16 IPv6 Node Address P2MP Responder Identifier 4 16 IPv6 Node Address P2MP Responder Identifier
The content of these Sub-TLVs are defined in the following sections. The content of these Sub-TLVs are defined in the following sections.
Also defined is the intended behavior of the responding node upon Also defined is the intended behavior of the responding node upon
receiving any of these Sub-TLVs. receiving any of these Sub-TLVs.
3.2.1. Egress Address P2MP Responder Identifier Sub-TLVs 3.2.1. Egress Address P2MP Responder Identifier Sub-TLVs
The IPv4 or IPv6 Egress Address P2MP Responder Identifier Sub-TLVs The encoding of the IPv4 Egress Address P2MP Responder Identifier
MAY be used in an echo request carrying RSVP P2MP Session Sub-TLV. sub-TLV is as follows:
They SHOULD NOT be used with an echo request carrying Multicast LDP
FEC Stack Sub-TLV. If a node receives these TLVs in an echo request 0 1 2 3
carrying Multicast LDP then it SHOULD ignore these sub-TLVs and 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
respond as if they are not present. Hence these TLVs cannot be used +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
to traceroute to a single node when Multicast LDP FEC is used. | Sub-Type = 1 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The encoding of the IPv6 Egress Address P2MP Responder Identifier
sub-TLV is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Type = 2 | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| 128-bit IPv6 Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A node that receives an echo request with this Sub-TLV present MUST A node that receives an echo request with this Sub-TLV present MUST
respond only if the node lies on the path to the address in the respond if the node lies on the path to the address in the Sub-TLV
Sub-TLV. and MUST NOT respond if it does not lie on the path to the address in
the Sub-TLV. For this to be possible, the address in the Sub-TLV must
be known to the nodes that lie upstream in the LSP. This can be the
case if RSVP-TE is used to signal the P2MP LSP, in which case this
address will be the address used in destination address field of
the S2L_SUB_LSP object, when corresponding egress or bud node is
signaled. Thus, the IPv4 or IPv6 Egress Address P2MP Responder
Identifier Sub-TLV MAY be used in an echo request carrying RSVP P2MP
Session Sub-TLV.
The address in this Sub-TLV SHOULD be of an egress or bud node and However, in Multicast LDP there is no way for upstream LSRs to know
SHOULD NOT be of a transit or branch node. A transit or branch node, the idendity of the downstream leaf nodes. Hence these TLVs cannot be
should be able to determine if the address in this Sub-TLV is for an used to perform traceroute to a single node when Multicast LDP FEC is
egress or bud node which is reachable through it. Hence, this used, and the IPv4 or IPv6 Egress Address P2MP Responder Identifier
address SHOULD be known to the nodes upstream of the target node, for Sub-TLV SHOULD NOT be used with an echo request carrying Multicast
instance via control plane signaling. As a case in point, if RSVP-TE LDP FEC Stack Sub-TLV. If a node receives these TLVs in an echo
is used to signal the P2MP LSP, this address SHOULD be the address request carrying Multicast LDP then it will not respond since it is
used in destination address field of the S2L_SUB_LSP object, when unaware of whether it lies on the path to the address in the Sub-TLV.
corresponding egress or bud node is signaled.
3.2.2. Node Address P2MP Responder Identifier Sub-TLVs 3.2.2. Node Address P2MP Responder Identifier Sub-TLVs
The encoding of the IPv4 Node Address P2MP Responder Identifier
sub-TLV is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Type = 3 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The encoding of the IPv6 Node Address P2MP Responder Identifier
sub-TLV is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Type = 4 | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| 128-bit IPv6 Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The IPv4 or IPv6 Node Address P2MP Responder Identifier Sub-TLVs MAY The IPv4 or IPv6 Node Address P2MP Responder Identifier Sub-TLVs MAY
be used in an echo request carrying either RSVP P2MP Session or be used in an echo request carrying either RSVP P2MP Session or
Multicast LDP FEC Stack Sub-TLV. Multicast LDP FEC Stack Sub-TLV.
A node that receives an echo request with this Sub-TLV present MUST A node that receives an echo request with this Sub-TLV present MUST
respond only if the address in the Sub-TLV corresponds to any address respond if the address in the Sub-TLV matches any address that is
that is local to the node. This address in the Sub-TLV may be of any local to the node and MUST NOT respond if the address in the Sub-TLV
physical interface or may be the router id of the node itself. does not match any address that is local to the node. The address
in the Sub-TLV may be of any physical interface or may be the router
id of the node itself.
The address in this Sub-TLV SHOULD be of any transit, branch, bud or The address in this Sub-TLV SHOULD be of any transit, branch, bud or
egress node for that P2MP LSP. egress node for that P2MP LSP. The address of a node that is not on
the P2MP LSP MAY be used as a check that no reply is received.
3.3. Preventing Congestion of Echo Replies 3.3. Preventing Congestion of Echo Replies
A new TLV is defined for inclusion in the Echo request message. A new TLV is defined for inclusion in the Echo request message.
The Echo Jitter TLV is assigned the TLV type value TBD and is encoded The Echo Jitter TLV is assigned the TLV type value TBD6 and is
as follows. encoded as follows.
0 1 2 3 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 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 = TBD (Jitter TLV) | Length = 4 | | Type = TBD6 (Jitter TLV) | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Jitter time | | Jitter time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Jitter time: Jitter time:
This field specifies the upper bound of the jitter period that This field specifies the upper bound of the jitter period that
should be applied by a responding node to determine how long to should be applied by a responding node to determine how long to
wait before sending an echo reply. A responding node SHOULD wait before sending an echo reply. A responding node MUST
wait a random amount of time between zero milliseconds and the wait a random amount of time between zero milliseconds and the
value specified in this field. value specified in this field.
Jitter time is specified in milliseconds. Jitter time is specified in milliseconds.
The Echo Jitter TLV only has meaning on an echo request message. If The Echo Jitter TLV only has meaning on an echo request message. If
present on an echo reply message, it SHOULD be ignored. present on an echo reply message, it MUST be ignored.
3.4. Respond Only If TTL Expired Flag 3.4. Respond Only If TTL Expired Flag
A new flag is being introduced in the Global Flags field defined in A new flag is being introduced in the Global Flags field defined in
[RFC4379]. The new format of the Global Flags field is: [RFC4379]. The new format of the Global Flags field is:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ |T|V| | MBZ |T|V|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The V flag is described in [RFC4379]. The V flag is described in [RFC4379].
The T (Respond Only If TTL Expired) flag SHOULD be set only in the The T (Respond Only If TTL Expired) flag MUST be set only in the
echo request packet by the sender. This flag SHOULD NOT be set in echo request packet by the sender. This flag MUST NOT be set in
the echo reply packet. If this flag is set in an echo reply packet, the echo reply packet. If this flag is set in an echo reply packet,
then it MUST be ignored. then it MUST be ignored.
If the T flag is set to 0, then the receiver SHOULD reply as per If the T flag is set to 0, then the receiving node MUST process the
regular processing. incoming echo request.
If the T flag is set to 1, then the receiver SHOULD reply only if the If the T flag is set to 1, and the TTL of the incoming MPLS label is
TTL of the incoming MPLS label is equal to 1; if the TTL is more than equal to 1 then the receiving node MUST process the incoming echo
1, then reply SHOULD NOT be sent back. request.
If the T flag is set to 1 and there are no incoming MPLS labels on If the T flag is set to 1, and the TTL of the incoming MPLS label is
more than 1 then the receiving node MUST drop the incoming echo
request and MUST NOT send any echo reply to the sender.
If the T flag is set to 1 and there are no incoming MPLS labels in
the echo request packet, then a bud node with PHP configured MAY the echo request packet, then a bud node with PHP configured MAY
choose to not respond to this echo request. All other nodes SHOULD choose to not respond to this echo request. All other nodes MUST
ignore this bit and respond as per regular processing. ignore this bit and respond as per regular processing.
3.5. Downstream Detailed Mapping TLV 3.5. Downstream Detailed Mapping TLV
Downstream Detailed Mapping TLV is described in [DDMT]. A transit, Downstream Detailed Mapping TLV is described in [DDMT]. A transit,
branch or bud node can use the Downstream Detailed Mapping TLV to branch or bud node can use the Downstream Detailed Mapping TLV to
return multiple Return Codes for different downstream paths. This return multiple Return Codes for different downstream paths. This
functionality can not be achieved via the Downstream Mapping TLV. As functionality can not be achieved via the Downstream Mapping TLV. As
per Section 4.3 of [DDMT], the Downstream Mapping TLV as described in per Section 3.4 of [DDMT], the Downstream Mapping TLV as described in
[RFC4379] is being deprecated. [RFC4379] is being deprecated.
Therefore for P2MP, a node MUST support Downstream Detailed Mapping Therefore for P2MP, a node MUST support Downstream Detailed Mapping
TLV. The Downstream Mapping TLV [RFC4379] is not appropriate for P2MP TLV. The Downstream Mapping TLV [RFC4379] is not appropriate for P2MP
traceroute functionality and SHOULD NOT be included in an Echo Request traceroute functionality and MUST NOT be included in an Echo Request
message. When responding to an RSVP IPv4/IPv6 P2MP Session FEC Type message. When responding to an RSVP IPv4/IPv6 P2MP Session FEC Type
or a Multicast P2MP/MP2MP LDP FEC Type, a node MUST ignore any or a Multicast P2MP/MP2MP LDP FEC Type, a node MUST ignore any
Downstream Mapping TLV it receives in the echo request and MUST Downstream Mapping TLV it receives in the echo request and MUST
continue processing as if the Downstream Mapping TLV is not present. continue processing as if the Downstream Mapping TLV is not present.
The details of the Return Codes to be used in the Downstream Detailed The details of the Return Codes to be used in the Downstream Detailed
Mapping TLV are provided in section 4. Mapping TLV are provided in section 4.
4. Operation of LSP Ping for a P2MP LSP 4. Operation of LSP Ping for a P2MP LSP
skipping to change at page 16, line 6 skipping to change at page 17, line 15
prevent the initiating (or nearby) LSRs from being swamped by prevent the initiating (or nearby) LSRs from being swamped by
replies, or from discarding replies due to rate limits that have replies, or from discarding replies due to rate limits that have
been applied. been applied.
It is desirable for the initiating LSR to be able to control the It is desirable for the initiating LSR to be able to control the
bounds of the jitter. If the tree size is small, only a small amount bounds of the jitter. If the tree size is small, only a small amount
of jitter is required, but if the tree is large, greater jitter is of jitter is required, but if the tree is large, greater jitter is
needed. needed.
The initiating LSR can supply the desired value of the jitter in the The initiating LSR can supply the desired value of the jitter in the
Echo Jitter TLV as defined in section 3.3. If this TLV is present, the Echo Jitter TLV as defined in section 3.3. If this TLV is present,
responding LSR SHOULD delay sending a reply for a random amount of the responding LSR MUST delay sending a reply for a random amount of
time between zero milliseconds and the value indicated in the TLV. time between zero milliseconds and the value indicated in the TLV.
If the TLV is absent, the responding egress SHOULD NOT introduce any If the TLV is absent, the responding egress SHOULD NOT introduce any
additional delay in responding to the echo request. additional delay in responding to the echo request, but MAY delay
according to local policy.
LSP ping SHOULD NOT be used to attempt to measure the round-trip time LSP ping MUST NOT be used to attempt to measure the round-trip time
for data delivery. This is because the P2MP LSPs are unidirectional, for data delivery. This is because the P2MP LSPs are unidirectional,
and the echo reply is often sent back through the control plane. and the echo reply is often sent back through the control plane. The
The timestamp fields in the echo request and echo reply packets timestamp fields in the echo request and echo reply packets MAY be
MAY be used to deduce some information about delivery times and used to deduce some information about delivery times, for example
particularly the variance in delivery times. the variance in delivery times.
The use of echo jittering does not change the processes for gaining The use of echo jittering does not change the processes for gaining
information, but note that the responding node MUST set the value in information, but note that the responding node MUST set the value in
the Timestamp Received fields before applying any delay. the Timestamp Received fields before applying any delay.
Echo reply jittering SHOULD be used for P2MP LSPs. If the Echo Echo reply jittering SHOULD be used for P2MP LSPs although MAY be
Jitter TLV is present in an echo request for any other type of LSPs, omitted for simple P2MP LSPs or when the Node Address P2MP Responder
the responding egress MAY apply the jitter behavior as described Identifier Sub-TLVs are used. If the Echo Jitter TLV is present in
here. an echo request for any other type of LSPs, the responding egress MAY
apply the jitter behavior as described here.
4.2. Responding LSR Operations 4.2. Responding LSR Operations
Usually the echo request packet will reach the egress and bud nodes. Usually the echo request packet will reach the egress and bud nodes.
In case of TTL Expiry, i.e. traceroute mode, the echo request packet In case of TTL Expiry, i.e. traceroute mode, the echo request packet
may stop at branch or transit nodes. In both scenarios, the echo may stop at branch or transit nodes. In both scenarios, the echo
request will be passed on to control plane for reply processing. request will be passed on to control plane for reply processing.
The operations at the receiving node are an extension to the existing The operations at the receiving node are an extension to the existing
processing as specified in [RFC4379]. A responding LSR is processing as specified in [RFC4379]. As described in that document,
RECOMMENDED to rate limit its receipt of echo request messages. a responding LSR SHOULD rate limit the receipt of echo request
After rate limiting, the responding LSR must verify general sanity of messages. After rate limiting, the responding LSR must verify
the packet. If the packet is malformed, or certain TLVs are not general sanity of the packet. If the packet is malformed, or certain
understood, the [RFC4379] procedures must be followed for echo reply. TLVs are not understood, the [RFC4379] procedures must be followed
Similarly the Reply Mode field determines if the reply is required for echo reply. Similarly the Reply Mode field determines if the
or not (and the mechanism to send it back). reply is required or not (and the mechanism to send it back).
For P2MP LSP ping and traceroute, i.e. if the echo request is For P2MP LSP ping and traceroute, i.e. if the echo request is
carrying an RSVP P2MP FEC or a Multicast LDP FEC, the responding LSR carrying an RSVP P2MP FEC or a Multicast LDP FEC, the responding LSR
MUST determine whether it is part of the P2MP LSP in question by MUST determine whether it is part of the P2MP LSP in question by
checking with the control plane. checking with the control plane.
- If the node is not part of the P2MP LSP, it MUST respond - If the node is not part of the P2MP LSP, it MUST respond
according to [RFC4379] processing rules. according to [RFC4379] processing rules.
- If the node is part of the P2MP LSP, the node must check whether - If the node is part of the P2MP LSP, the node must check whether
skipping to change at page 17, line 41 skipping to change at page 18, line 51
message that reports an error from a transit node may apply to message that reports an error from a transit node may apply to
multiple egress nodes (i.e. leaves) downstream of the reporting node. multiple egress nodes (i.e. leaves) downstream of the reporting node.
In the case of the ping mode of operation, it is not possible to In the case of the ping mode of operation, it is not possible to
correlate the reporting node to the affected egresses unless the correlate the reporting node to the affected egresses unless the
topology of the P2MP tree is already known, and it may be necessary topology of the P2MP tree is already known, and it may be necessary
to use the traceroute mode of operation to further diagnose the LSP. to use the traceroute mode of operation to further diagnose the LSP.
Note that a transit node may discover an error but also Note that a transit node may discover an error but also
determine that while it does lie on the path of the LSP under test, determine that while it does lie on the path of the LSP under test,
it does not lie on the path to the specific egress being tested. In it does not lie on the path to the specific egress being tested. In
this case, the node SHOULD NOT generate an echo reply. this case, the node SHOULD NOT generate an echo reply unless there is
a specific error condition that needs to be communicated.
The following sections describe the expected values of Return Codes The following sections describe the expected values of Return Codes
for various nodes in a P2MP LSP. It is assumed that the sanity and for various nodes in a P2MP LSP. It is assumed that the sanity and
other checks have been performed and an echo reply is being sent other checks have been performed and an echo reply is being sent
back. As mentioned previously, the Return Code might change based on back. As mentioned in Section 4.2, the Return Code might change
the presence of Responder Identifier TLV or Downstream Detailed based on the presence of Responder Identifier TLV or Downstream
Mapping TLV. Detailed Mapping TLV.
4.2.1.1. Responses from Transit and Branch Nodes 4.2.1.1. Responses from Transit and Branch Nodes
The presence of a Responder Identifier TLV does not influence the The presence of a Responder Identifier TLV does not influence the
choice of the Return Code, which MAY be set to value 8 ('Label choice of the Return Code. For a success response, the Return Code
switched at stack-depth <RSC>') or any other error value as needed. MAY be set to value 8 ('Label switched at stack-depth <RSC>'). The
notation <RSC> refers to the Return Subcode as defined in section
3.1. of [RFC4379]. For error conditions, use appropriate values
defined in [RFC4379].
The presence of a Downstream Detailed Mapping TLV will influence the The presence of a Downstream Detailed Mapping TLV will influence the
choice of Return Code. As per [DDMT], the Return Code in the echo choice of Return Code. As per [DDMT], the Return Code in the echo
reply header MAY be set to value TBD ('See DDM TLV for Return Code reply header MAY be set to 'See DDM TLV for Return Code and Return
and Return SubCode') as defined in [DDMT]. The Return Code for each SubCode' as defined in [DDMT]. The Return Code for each Downstream
Downstream Detailed Mapping TLV will depend on the downstream path as Detailed Mapping TLV will depend on the downstream path as described
described in [DDMT]. in [DDMT].
There will be a Downstream Detailed Mapping TLV for each downstream There will be a Downstream Detailed Mapping TLV for each downstream
path being reported in the echo reply. Hence for transit nodes, 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 there will be only one such TLV and for branch nodes, there will be
more than one. If there is an Egress Address Responder Identifier more than one. If there is an Egress Address Responder Identifier
Sub-TLV, then the branch node will include only one Downstream Sub-TLV, then the branch node will include only one Downstream
Detailed Mapping TLV corresponding to the downstream path required to Detailed Mapping TLV corresponding to the downstream path required to
reach the address specified in the Egress Address Sub-TLV. reach the address specified in the Egress Address Sub-TLV.
4.2.1.2. Responses from Egress Nodes 4.2.1.2. Responses from Egress Nodes
The presence of a Responder Identifier TLV does not influence the The presence of a Responder Identifier TLV does not influence the
choice of the Return Code, which MAY be set to value 3 ('Replying choice of the Return Code. For a success response, the Return Code
router is an egress for the FEC at stack-depth <RSC>') or any other MAY be set to value 3 ('Replying router is an egress for the FEC at
error value as needed. stack-depth <RSC>'). For error conditions, use appropriate values
defined in [RFC4379].
The presence of the Downstream Detailed Mapping TLV does not The presence of the Downstream Detailed Mapping TLV does not
influence the choice of Return Code. Egress nodes do not put in any influence the choice of Return Code. Egress nodes do not put in any
Downstream Detailed Mapping TLV in the echo reply. Downstream Detailed Mapping TLV in the echo reply [DDMT].
4.2.1.3. Responses from Bud Nodes 4.2.1.3. Responses from Bud Nodes
The case of bud nodes is more complex than other types of nodes. The The case of bud nodes is more complex than other types of nodes. The
node might behave as either an egress node or a transit node or a node might behave as either an egress node or a transit node or a
combination of an egress and branch node. This behavior is combination of an egress and branch node. This behavior is
determined by the presence of any Responder Identifier TLV and the determined by the presence of any Responder Identifier TLV and the
type of sub-TLV in it. Similarly Downstream Detailed Mapping TLV can type of sub-TLV in it. Similarly Downstream Detailed Mapping TLV can
influence the Return Code values. influence the Return Code values.
To determine the behavior of the bud node, use the following To determine the behavior of the bud node, use the following rules.
guidelines. The intent of these guidelines is to figure out if the The intent of these rules is to figure out if the echo request is
echo request is meant for all nodes, or just this node, or for meant for all nodes, or just this node, or for another node reachable
another node reachable through this node or for a different section through this node or for a different section of the tree. In the
of the tree. In the first case, the node will behave like a first case, the node will behave like a combination of egress and
combination of egress and branch node; in the second case, the node branch node; in the second case, the node will behave like pure
will behave like pure egress node; in the third case, the node will egress node; in the third case, the node will behave like a transit
behave like a transit node; and in the last case, no reply will be node; and in the last case, no reply will be sent back.
sent back.
Node behavior guidelines: Node behavior rules:
- If the Responder Identifier TLV is not present, then the node - If the Responder Identifier TLV is not present, then the node
will behave as a combination of egress and branch node. will behave as a combination of egress and branch node.
- If the Responder Identifier TLV containing a Node Address - If the Responder Identifier TLV containing a Node Address
sub-TLV is present, and: sub-TLV is present, and:
- If the address specified in the sub-TLV matches to an address - If the address specified in the sub-TLV matches to an address
in the node, then the node will behave like a combination of in the node, then the node will behave like a combination of
egress and branch node. egress and branch node.
skipping to change at page 19, line 37 skipping to change at page 21, line 5
- If the node lies on the path to the address specified in the - If the node lies on the path to the address specified in the
sub-TLV, then the node will behave like a transit node. sub-TLV, then the node will behave like a transit node.
- If the node does not lie on the path to the address specified - If the node does not lie on the path to the address specified
in the sub-TLV, then no reply will be sent. in the sub-TLV, then no reply will be sent.
Once the node behavior has been determined, the possible values for Once the node behavior has been determined, the possible values for
Return Codes are as follows: Return Codes are as follows:
- If the node is behaving as an egress node only, then the Return - If the node is behaving as an egress node only, then for a
Code MAY be set to value 3 ('Replying router is an egress for success response, the Return Code MAY be set to value 3
the FEC at stack-depth <RSC>') or any other error value as ('Replying router is an egress for the FEC at stack-depth
needed. The echo reply MUST NOT contain any Downstream <RSC>'). For error conditions, use appropriate values defined
in [RFC4379]. The echo reply MUST NOT contain any Downstream
Detailed Mapping TLV, even if one is present in the echo Detailed Mapping TLV, even if one is present in the echo
request. request.
- If the node is behaving as a transit node, and: - If the node is behaving as a transit node, and:
- If a Downstream Detailed Mapping TLV is not present, then - If a Downstream Detailed Mapping TLV is not present, then
the Return Code MAY be set to value 8 ('Label switched at for a success response, the Return Code MAY be set to value
stack-depth <RSC>') or any other error value as needed. 8 ('Label switched at stack-depth <RSC>'). For error
conditions, use appropriate values defined in [RFC4379].
- If a Downstream Detailed Mapping TLV is present, then the - If a Downstream Detailed Mapping TLV is present, then the
Return Code MAY be set to value TBD ('See DDM TLV for Return Code MAY be set to 'See DDM TLV for Return Code and
Return Code and Return SubCode') as defined in [DDMT]. The Return SubCode' as defined in [DDMT]. The Return Code for
Return Code for the Downstream Detailed Mapping TLV will the Downstream Detailed Mapping TLV will depend on the
depend on the downstream path as described in [DDMT]. downstream path as described in [DDMT]. There will be only
There will be only one Downstream Detailed Mapping one Downstream Detailed Mapping corresponding to the
corresponding to the downstream path to the address downstream path to the address specified in the Egress
specified in the Egress Address Sub-TLV. Address Sub-TLV.
- If the node is behaving as a combination of egress and branch node, - If the node is behaving as a combination of egress and branch
and: node, and:
- If a Downstream Detailed Mapping TLV is not present, then - If a Downstream Detailed Mapping TLV is not present, then
the Return Code MAY be set to value 3 ('Replying router is for a success response, the Return Code MAY be set to value
an egress for the FEC at stack-depth <RSC>') or any other 3 ('Replying router is an egress for the FEC at stack-depth
error value as needed. <RSC>'). For error conditions, use appropriate values
defined in [RFC4379].
- If a Downstream Detailed Mapping TLV is present, then the - If a Downstream Detailed Mapping TLV is present, then for a
Return Code MAY be set to value 3 ('Replying router is an success response, the Return Code MAY be set to value 3
egress for the FEC at stack-depth <RSC>') or any other ('Replying router is an egress for the FEC at stack-depth
error value as needed. Return Code for the each Downstream <RSC>'). For error conditions, use appropriate values
defined in [RFC4379]. Return Code for the each Downstream
Detailed Mapping TLV will depend on the downstream path as Detailed Mapping TLV will depend on the downstream path as
described in [DDMT]. There will be a Downstream Detailed described in [DDMT]. There will be a Downstream Detailed
Mapping for each downstream path from the node. Mapping for each downstream path from the node.
4.3. Special Considerations for Traceroute 4.3. Special Considerations for Traceroute
4.3.1. End of Processing for Traceroute 4.3.1. End of Processing for Traceroutes
As specified in [RFC4379], the traceroute mode operates by sending a As specified in [RFC4379], the traceroute mode operates by sending a
series of echo requests with sequentially increasing TTL values. For series of echo requests with sequentially increasing TTL values. For
regular P2P targets, this processing stops when a valid reply is regular P2P targets, this processing stops when a valid reply is
received from the intended egress or when some errored return code is received from the intended egress or when some errored return code is
received. received.
For P2MP targets, there may not be an easy way to figure out the end For P2MP targets, there may not be an easy way to figure out the end
of the traceroute processing, as there are multiple egress nodes. of the traceroute processing, as there are multiple egress nodes.
Receiving a valid reply from an egress will not signal the end of Receiving a valid reply from an egress will not signal the end of
skipping to change at page 21, line 38 skipping to change at page 23, line 14
packet. Hence this mechanism will not be effective for PHP scenario. packet. Hence this mechanism will not be effective for PHP scenario.
4.3.3. Non-Response to Traceroute Echo Requests 4.3.3. Non-Response to Traceroute Echo Requests
There are multiple reasons for which an ingress node may not receive There are multiple reasons for which an ingress node may not receive
a reply to its echo request. For example, the transit node has a reply to its echo request. For example, the transit node has
failed, or the transit node does not support LSP Ping. failed, or the transit node does not support LSP Ping.
When no reply to an echo request is received by the ingress, then When no reply to an echo request is received by the ingress, then
as per [RFC4379] the subsequent echo request with a larger TTL SHOULD as per [RFC4379] the subsequent echo request with a larger TTL SHOULD
be sent. be sent in order to trace further toward the egress, although the
ingress MAY halt the procedure at this point. The time that an
ingress waits before sending the subsequent echo request is an
implementation choice.
4.3.4. Use of Downstream Detailed Mapping TLV in Echo Request 4.3.4. Use of Downstream Detailed Mapping TLV in Echo Request
As described in section 4.6 of [RFC4379], an initiating LSR, during As described in section 4.6 of [RFC4379], an initiating LSR, during
traceroute, SHOULD copy the Downstream Mapping(s) into its next echo traceroute, SHOULD copy the Downstream Mapping(s) into its next echo
request(s). However for P2MP LSPs, the intiating LSR will receive request(s). However for P2MP LSPs, the intiating LSR will receive
multiple sets of Downstream Detailed Mapping TLV from different multiple sets of Downstream Detailed Mapping TLV from different
nodes. It is not practical to copy all of them into the next echo nodes. It is not practical to copy all of them into the next echo
request. Hence this behavior is being modified for P2MP LSPs. In request. Hence this behavior is being modified for P2MP LSPs. If
the echo request packet, the "Downstream IP Address" field, of the the echo request is destined for more than one node, then the
Downstream Detailed Mapping TLV, SHOULD be set to the ALLROUTERS "Downstream IP Address" field of the Downstream Detailed Mapping TLV
multicast address. MUST be set to the ALLROUTERS multicast address, and the Address Type
field MUST be set to either IPv4 Unnumbered or IPv6 Unnumbered
depending on the Target FEC Stack TLV.
If an Egress Address Responder Identifier sub-TLV is being used, then If an Egress Address Responder Identifier sub-TLV is being used, then
the traceroute is limited to only one path to one egress. Therefore the traceroute is limited to only one egress. Therefore this
this traceroute is effectively behaving like a P2P traceroute. In traceroute is effectively behaving like a P2P traceroute. In this
this scenario, as per section 4.2, the echo replies from scenario, as per section 4.2, the echo replies from intermediate
intermediate nodes will contain only one Downstream Detailed Mapping nodes will contain only one Downstream Detailed Mapping TLV
TLV corresponding to the downstream path required to reach the corresponding to the downstream path required to reach the address
address specified in the Egress Address sub-TLV. For this case, the specified in the Egress Address sub-TLV. For this case, the echo
echo request packet MAY reuse a received Downstream Detailed Mapping request packet MAY reuse a received Downstream Detailed Mapping
TLV. TLV. This will allow interface validation to be performed as per
[RFC4379].
4.3.5 Cross-Over Node Processing 4.3.5 Cross-Over Node Processing
A cross-over node will require slightly different processing for A cross-over node will require slightly different processing for
traceroute mode. The following definition of cross-over is taken from traceroute mode. The following definition of cross-over is taken from
[RFC4875]. [RFC4875].
The term "cross-over" refers to the case of an ingress or transit The term "cross-over" refers to the case of an ingress or transit
node that creates a branch of a P2MP LSP, a cross-over branch, that node that creates a branch of a P2MP LSP, a cross-over branch, that
intersects the P2MP LSP at another node farther down the tree. It intersects the P2MP LSP at another node farther down the tree. It
is unlike re-merge in that, at the intersecting node, the is unlike re-merge in that, at the intersecting node, the
cross-over branch has a different outgoing interface as well as a cross-over branch has a different outgoing interface as well as a
different incoming interface. different incoming interface.
During traceroute, a cross-over node will receive the echo requests During traceroute, a cross-over node will receive the echo requests
via each of its input interfaces. Therefore the Downstream Detailed via each of its input interfaces. Therefore the Downstream Detailed
Mapping TLV in the echo reply SHOULD carry information only about Mapping TLV in the echo reply MUST carry information only about the
the outgoing interface corresponding to the input interface. outgoing interface corresponding to the input interface.
Due to this restriction, the cross-over node will not duplicate the If this restriction is applied, the cross-over node will not
outgoing interface information in each of the echo request it duplicate the outgoing interface information in each of the echo
receives via the different input interfaces. This will reflect the request it receives via the different input interfaces. This will
actual packet replication in the data plane. reflect the actual packet replication in the data plane.
5. Non-compliant Routers 5. Non-compliant Routers
If a node for a P2MP LSP does not support MPLS LSP ping, then no If a node for a P2MP LSP does not support MPLS LSP ping, then no
reply will be sent, causing an incorrect result on the initiating reply will be sent, causing an incorrect result on the initiating
LSR. There is no protection for this situation, and operators may LSR. There is no protection for this situation, and operators may
wish to ensure that all nodes for P2MP LSPs are all equally capable wish to ensure that all nodes for P2MP LSPs are all equally capable
of supporting this function. of supporting this function.
If the non-compliant node is an egress, then the traceroute mode can If the non-compliant node is an egress, then the traceroute mode can
skipping to change at page 23, line 14 skipping to change at page 24, line 43
If the non-compliant node is a branch or transit node, then it should If the non-compliant node is a branch or transit node, then it should
not impact ping mode. However the node will not respond during not impact ping mode. However the node will not respond during
traceroute mode. traceroute mode.
6. OAM and Management Considerations 6. OAM and Management Considerations
The procedures in this document provide OAM functions for P2MP MPLS The procedures in this document provide OAM functions for P2MP MPLS
LSPs and may be used to enable bootstrapping of other OAM procedures. LSPs and may be used to enable bootstrapping of other OAM procedures.
In order to be fully operational several considerations must be made. In order to be fully operational several considerations apply.
- Scaling concerns dictate that only cautious use of LSP Ping - Scaling concerns dictate that only cautious use of LSP Ping
should be made. In particular, sending an LSP Ping to all should be made. In particular, sending an LSP Ping to all
egresses of a P2MP MPLS LSP could result in congestion at or egresses of a P2MP MPLS LSP could result in congestion at or
near the ingress when the replies arrive. near the ingress when the replies arrive.
Further, incautious use of timers to generate LSP Ping echo Further, incautious use of timers to generate LSP Ping echo
requests either in ping mode or especially in traceroute may requests either in ping mode or especially in traceroute may
lead to significant degradation of network performance. lead to significant degradation of network performance.
- Management interfaces should allow an operator full control over - Management interfaces should allow an operator full control over
the operation of LSP Ping. In particular, it SHOULD provide the the operation of LSP Ping. In particular, such interfaces
ability to limit the scope of an LSP Ping echo request for a should provide the ability to limit the scope of an LSP Ping
P2MP MPLS LSP to a single egress. echo request for a P2MP MPLS LSP to a single egress.
Such an interface SHOULD also provide the ability to disable all Such interfaces should also provide the ability to disable all
active LSP Ping operations to provide a quick escape if the active LSP Ping operations to provide a quick escape if the
network becomes congested. network becomes congested.
- A MIB module is required for the control and management of LSP
Ping operations, and to enable the reported information to be
inspected.
There is no reason to believe this should not be a simple
extension of the LSP Ping MIB module used for P2P LSPs.
7. IANA Considerations 7. IANA Considerations
[Note - this paragraph to be removed before publication.] The values [Note - this paragraph to be removed before publication.] The values
suggested in this section have already been assigned using the IANA suggested in sections 7.1 and 7.2 have already been assigned using
early allocation process [RFC4020]. the IANA early allocation process [RFC4020].
7.1. New Sub-TLV Types 7.1. New Sub-TLV Types
Four new sub-TLV types are defined for inclusion within the LSP Ping Four new sub-TLV types are defined for inclusion within the LSP Ping
[RFC4379] Target FEC Stack TLV (TLV type 1). [RFC4379] Target FEC Stack TLV (TLV type 1).
IANA is requested to assign sub-type values to the following sub-TLVs IANA is requested to assign sub-type values to the following sub-TLVs
under TLV type 1 (Target FEC Stack) from the "Multiprotocol Label under TLV type 1 (Target FEC Stack) from the "Multiprotocol Label
Switching Architecture (MPLS) Label Switched Paths (LSPs) Parameters Switching Architecture (MPLS) Label Switched Paths (LSPs) Parameters
- TLVs" registry, "TLVs and sub-TLVs" sub-registry. - TLVs" registry, "TLVs and sub-TLVs" sub-registry.
RSVP P2MP IPv4 Session (Section 3.1.1). Suggested value 17. TBD1
RSVP P2MP IPv6 Session (Section 3.1.1). Suggested value 18. RSVP P2MP IPv4 Session (Section 3.1.1).
Multicast P2MP LDP FEC Stack (Section 3.1.2). Suggested value 19. Suggested value 17.
Multicast MP2MP LDP FEC Stack (Section 3.1.2). Suggested value 20. TBD2
RSVP P2MP IPv6 Session (Section 3.1.1).
Suggested value 18.
TBD3
Multicast P2MP LDP FEC Stack (Section 3.1.2).
Suggested value 19.
TBD4
Multicast MP2MP LDP FEC Stack (Section 3.1.2).
Suggested value 20.
7.2. New TLVs 7.2. New TLVs
Two new LSP Ping TLV types are defined for inclusion in LSP Ping Two new LSP Ping TLV types are defined for inclusion in LSP Ping
messages. messages.
IANA is requested to assign a new value from the "Multi-Protocol IANA is requested to assign a new value from the "Multi-Protocol
Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Label Switching Architecture (MPLS) Label Switched Paths (LSPs)
Parameters - TLVs" registry, "TLVs and sub-TLVs" sub-registry as Parameters - TLVs" registry, "TLVs and sub-TLVs" sub-registry as
follows using a Standards Action value. follows using a Standards Action value.
P2MP Responder Identifier TLV (see Section 3.2) is a mandatory TBD5
TLV. Suggested value 11. P2MP Responder Identifier TLV (see Section 3.2) is a mandatory
Four sub-TLVs are defined. TLV.
Suggested value 11.
Four sub-TLVs are defined.
- Type 1: IPv4 Egress Address P2MP Responder Identifier - Type 1: IPv4 Egress Address P2MP Responder Identifier
- Type 2: IPv6 Egress Address P2MP Responder Identifier - Type 2: IPv6 Egress Address P2MP Responder Identifier
- Type 3: IPv4 Node Address P2MP Responder Identifier - Type 3: IPv4 Node Address P2MP Responder Identifier
- Type 4: IPv6 Node Address P2MP Responder Identifier - Type 4: IPv6 Node Address P2MP Responder Identifier
Echo Jitter TLV (see Section 3.3) is a mandatory TLV. Suggested TBD6
value 12. Echo Jitter TLV (see Section 3.3) is a mandatory TLV.
Suggested value 12.
7.3. New Global Flags Registry
IANA is requested to create a new sub-registry of the "Multi-Protocol
Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters"
registry. The sub-registry should be called "Global Flags" registry.
This registry tracks the assignment of 16 flags in the Global Flags
field of the MPLS LSP Ping echo request message. The flags are
numbered from 0 (most significant bit, transmitted first) to 15.
New entries are assigned by Standards Action
Initial entries in the registry should read:
Bit number | Name | Reference
------------+----------------------------+--------------
15 | V Flag | [RFC4379]
14 | T Flag | [This I-D]
13-0 | Unassigned |
8. Security Considerations 8. Security Considerations
This document does not introduce security concerns over and above This document does not introduce security concerns over and above
those described in [RFC4379]. Note that because of the scalability those described in [RFC4379]. Note that because of the scalability
implications of many egresses to P2MP MPLS LSPs, there is a stronger implications of many egresses to P2MP MPLS LSPs, there is a stronger
concern to regulate the LSP Ping traffic passed to the control plane concern to regulate the LSP Ping traffic passed to the control plane
by the use of a rate limiter applied to the LSP Ping well-known UDP by the use of a rate limiter applied to the LSP Ping well-known UDP
port. This rate limiting might lead to false indications of LSP port. This rate limiting might lead to false indications of LSP
failure. failure.
skipping to change at page 25, line 8 skipping to change at page 27, line 26
The authors would like to acknowledge the authors of [RFC4379] for The authors would like to acknowledge the authors of [RFC4379] for
their work which is substantially re-used in this document. Also their work which is substantially re-used in this document. Also
thanks to the members of the MBONED working group for their review of thanks to the members of the MBONED working group for their review of
this material, to Daniel King and Mustapha Aissaoui for their review, this material, to Daniel King and Mustapha Aissaoui for their review,
and to Yakov Rekhter for useful discussions. and to Yakov Rekhter for useful discussions.
The authors would like to thank Bill Fenner, Vanson Lim, Danny The authors would like to thank Bill Fenner, Vanson Lim, Danny
Prairie, Reshad Rahman, Ben Niven-Jenkins, Hannes Gredler, Nitin Prairie, Reshad Rahman, Ben Niven-Jenkins, Hannes Gredler, Nitin
Bahadur, Tetsuya Murakami, Michael Hua, Michael Wildt, Dipa Thakkar, Bahadur, Tetsuya Murakami, Michael Hua, Michael Wildt, Dipa Thakkar,
Sam Aldrin and IJsbrand Wijnands for their comments and suggestions. Sam Aldrin, and IJsbrand Wijnands for their comments and suggestions.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4379] Kompella, K., and Swallow, G., "Detecting Multi-Protocol [RFC4379] Kompella, K., and Swallow, G., "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379, Label Switched (MPLS) Data Plane Failures", RFC 4379,
skipping to change at page 26, line 29 skipping to change at page 28, line 48
11. Authors' Addresses 11. Authors' Addresses
Seisho Yasukawa Seisho Yasukawa
NTT Corporation NTT Corporation
(R&D Strategy Department) (R&D Strategy Department)
3-1, Otemachi 2-Chome Chiyodaku, Tokyo 100-8116 Japan 3-1, Otemachi 2-Chome Chiyodaku, Tokyo 100-8116 Japan
Phone: +81 3 5205 5341 Phone: +81 3 5205 5341
Email: yasukawa.seisho@lab.ntt.co.jp Email: yasukawa.seisho@lab.ntt.co.jp
Adrian Farrel Adrian Farrel
Old Dog Consulting Juniper Networks
EMail: adrian@olddog.co.uk Email: adrian@olddog.co.uk
Zafar Ali Zafar Ali
Cisco Systems Inc. Cisco Systems Inc.
2000 Innovation Drive 2000 Innovation Drive
Kanata, ON, K2K 3E8, Canada. Kanata, ON, K2K 3E8, Canada.
Phone: 613-889-6158 Phone: 613-889-6158
Email: zali@cisco.com Email: zali@cisco.com
George Swallow George Swallow
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Ave 1414 Massachusetts Ave
Boxborough, MA 01719 Boxborough, MA 01719
Email: swallow@cisco.com Email: swallow@cisco.com
Thomas D. Nadeau Thomas D. Nadeau
CA Technologies Email: tnadeau@lucidvision.com
273 Corporate Drive
Portsmouth, NH, USA
Email: thomas.nadeau@ca.com
Shaleen Saxena Shaleen Saxena
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Ave 1414 Massachusetts Ave
Boxborough, MA 01719 Boxborough, MA 01719
Email: ssaxena@cisco.com Email: ssaxena@cisco.com
12. Full Copyright Statement 12. Full Copyright Statement
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
 End of changes. 80 change blocks. 
239 lines changed or deleted 352 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/