draft-ietf-mpls-p2mp-lsp-ping-16.txt   draft-ietf-mpls-p2mp-lsp-ping-17.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: September 14, 2011 A. Farrel Expires: December 20, 2011 A. Farrel
Old Dog Consulting Old Dog Consulting
S. Yasukawa S. Yasukawa
NTT Corporation NTT Corporation
T. Nadeau T. Nadeau
LucidVision CA Technologies
March 14, 2011 June 20, 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-16.txt draft-ietf-mpls-p2mp-lsp-ping-17.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 2, line 41 skipping to change at page 2, line 41
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............ 12
3.3. Preventing Congestion of Echo Responses...................... 12 3.3. Preventing Congestion of Echo Replies........................ 12
3.4. Respond Only If TTL Expired Flag............................. 13 3.4. Respond Only If TTL Expired Flag............................. 13
3.5. Downstream Detailed Mapping TLV.............................. 14 3.5. Downstream Detailed Mapping TLV.............................. 14
4. Operation of LSP Ping for a P2MP LSP........................... 14 4. Operation of LSP Ping for a P2MP LSP........................... 14
4.1. Initiating LSR Operations.................................... 15 4.1. Initiating LSR Operations.................................... 15
4.1.1. Limiting Responses to Echo Requests........................ 15 4.1.1. Limiting Responses to Echo Requests........................ 15
4.1.2. Jittered Responses to Echo Requests........................ 15 4.1.2. Jittered Responses to Echo Requests........................ 15
4.2. Responding LSR Operations.................................... 16 4.2. Responding LSR Operations.................................... 16
4.2.1. Echo Response Reporting.................................... 17 4.2.1. Echo Reply Reporting....................................... 17
4.2.1.1. Responses from Transit and Branch Nodes.................. 18 4.2.1.1. Responses from Transit and Branch Nodes.................. 17
4.2.1.2. Responses from Egress Nodes.............................. 18 4.2.1.2. Responses from Egress Nodes.............................. 18
4.2.1.3. Responses from Bud Nodes................................. 18 4.2.1.3. Responses from Bud Nodes................................. 18
4.3. Special Considerations for Traceroute........................ 20 4.3. Special Considerations for Traceroute........................ 20
4.3.1. End of Processing for Traceroutes.......................... 20 4.3.1. End of Processing for Traceroute........................... 20
4.3.2. Multiple responses from Bud and Egress Nodes............... 21 4.3.2. Multiple responses from Bud and Egress Nodes............... 21
4.3.3. Non-Response to Traceroute Echo Requests................... 21 4.3.3. Non-Response to Traceroute Echo Requests................... 21
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..... 21
4.3.5 Cross-Over Node Processing.................................. 22 4.3.5 Cross-Over Node Processing.................................. 22
5. Non-compliant Routers.......................................... 22 5. Non-compliant Routers.......................................... 22
6. OAM and Management Considerations.............................. 23 6. OAM and Management Considerations.............................. 23
7. IANA Considerations............................................ 23 7. IANA Considerations............................................ 23
7.1. New Sub-TLV Types............................................ 24 7.1. New Sub-TLV Types............................................ 23
7.2. New TLVs..................................................... 24 7.2. New TLVs..................................................... 24
8. Security Considerations........................................ 24 8. Security Considerations........................................ 24
9. Acknowledgements............................................... 25 9. Acknowledgements............................................... 24
10. References.................................................... 25 10. References.................................................... 25
10.1. Normative References........................................ 25 10.1. Normative References........................................ 25
10.2. Informative References...................................... 25 10.2. Informative References...................................... 25
11. Authors' Addresses............................................ 26 11. Authors' Addresses............................................ 26
12. Full Copyright Statement...................................... 27 12. Full Copyright Statement...................................... 27
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)
skipping to change at page 4, line 30 skipping to change at page 4, line 30
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 OAM
procedures such as [RFC5884]. As pointed out in [RFC4379], procedures such as [RFC5884]. As pointed out in [RFC4379],
mechanisms to check the liveness, function, and consistency of the mechanisms to check the liveness, function, and consistency of the
control plane are valuable, but such mechanisms are not a feature of control plane are valuable, but such mechanisms are not a feature of
LSP Ping and are not covered in this document. 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 the control plane. A rate limiter should be applied to the incoming
well-known UDP port defined for use by 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
skipping to change at page 6, line 15 skipping to change at page 6, line 15
hops indicated by the routing protocols. Each LSP is identified by hops indicated by the routing protocols. Each LSP is identified by
an MPLS multicast FEC. an MPLS multicast FEC.
P2MP MPLS TE LSPs [RFC4875] may be viewed as MPLS tunnels with a P2MP MPLS TE LSPs [RFC4875] may be viewed as MPLS tunnels with a
single ingress and multiple egresses. The tunnels, built on P2MP single ingress and multiple egresses. The tunnels, built on P2MP
LSPs, are explicitly routed through the network. There is no concept LSPs, are explicitly routed through the network. There is no concept
or applicability of a FEC in the context of a P2MP MPLS TE LSP. or applicability of a FEC in the context of a P2MP MPLS TE LSP.
MPLS packets inserted at the ingress of a P2MP LSP are delivered MPLS packets inserted at the ingress of a P2MP LSP are delivered
equally (barring faults) to all egresses. In consequence, the basic equally (barring faults) to all egresses. In consequence, the basic
idea of LSP Ping for P2MP MPLS TE LSPs may be expressed as an idea of LSP Ping for P2MP MPLS LSPs may be expressed as an
intention to test that packets that enter (at the ingress) a intention to test that packets that enter (at the ingress) a
particular P2MP LSP actually end their MPLS path on the LSRs that are particular P2MP LSP actually end their MPLS path on the LSRs that are
the (intended) egresses for that LSP. The idea may be extended to the (intended) egresses for that LSP. The idea may be extended to
check selectively that such packets reach specific egresses. check selectively that such packets reach specific egresses.
The technique in this document makes this test by sending an LSP Ping The technique in this document makes this test by sending an LSP Ping
echo request message along the same data path as the MPLS packets. echo request message along the same data path as the MPLS packets.
An echo request also carries the identification of the P2MP MPLS LSP An echo request also carries the identification of the P2MP MPLS LSP
(multicast LSP or P2MP TE LSP) that it is testing. The echo request (multicast LSP or P2MP TE LSP) that it is testing. The echo request
is forwarded just as any other packet using that LSP, and so is is forwarded just as any other packet using that LSP, and so is
replicated at branch points of the LSP and should be delivered to all replicated at branch points of the LSP and should be delivered to all
egresses. egresses.
In "ping" mode (basic connectivity check), the echo request should In "ping" mode (basic connectivity check), the echo request should
reach the end of the path, at which point it is sent to the control reach the end of the path, at which point it is sent to the control
plane of the egress LSRs, which verify that they are indeed an egress plane of the egress LSRs, which verify that they are indeed an egress
(leaf) of the P2MP LSP. An echo response message is sent by an (leaf) of the P2MP LSP. An echo reply message is sent by an
egress to the ingress to confirm the successful receipt (or announce egress to the ingress to confirm the successful receipt (or announce
the erroneous arrival) of the echo request. the erroneous arrival) of the echo request.
In "traceroute" mode (fault isolation), the echo request is sent to In "traceroute" mode (fault isolation), the echo request is sent to
the control plane at each transit LSR, and the control plane checks the control plane at each transit LSR, and the control plane checks
that it is indeed a transit LSR for this P2MP MPLS LSP. The transit that it is indeed a transit LSR for this P2MP MPLS LSP. The transit
LSR returns information about the outgoing paths. This information LSR returns information about the outgoing paths. This information
can be used by ingress LSR to build topology or by downstream LSRs to can be used by ingress LSR to build topology or by downstream LSRs to
do extra label verification. do extra label verification.
P2MP MPLS LSPs may have many egresses, and it is not necessarily the P2MP MPLS LSPs may have many egresses, and it is not necessarily the
intention of the initiator of the ping or traceroute operation to intention of the initiator of the ping or traceroute operation to
collect information about the connectivity or path to all egresses. collect information about the connectivity or path to all egresses.
Indeed, in the event of pinging all egresses of a large P2MP MPLS Indeed, in the event of pinging all egresses of a large P2MP MPLS
LSP, it might be expected that a large number of echo responses would LSP, it might be expected that a large number of echo replies would
arrive at the ingress independently but at approximately the same arrive at the ingress independently but at approximately the same
time. Under some circumstances this might cause congestion at or time. Under some circumstances this might cause congestion at or
around the ingress LSR. The procedures described in this document around the ingress LSR. The procedures described in this document
provide two mechanisms to control echo responses. provide two mechanisms to control echo replies.
The first procedure allows the responders to randomly delay (or The first procedure allows the responders to randomly delay (or
jitter) their responses so that the chances of swamping the ingress jitter) their replies so that the chances of swamping the ingress
are reduced. The second procedures allows the initiator to limit the are reduced. The second procedure allows the initiator to limit the
scope of an LSP Ping echo request (ping or traceroute mode) to one scope of an LSP Ping echo request (ping or traceroute mode) to one
specific intended egress. specific intended egress.
LSP Ping can be used to periodically ping a P2MP MPLS LSP to ensure LSP Ping can be used to periodically ping a P2MP MPLS LSP to ensure
connectivity to any or all of the egresses. If the ping fails, the connectivity to any or all of the egresses. If the ping fails, the
operator or an automated process can then initiate a traceroute to operator or an automated process can then initiate a traceroute to
determine where the fault is located within the network. A determine where the fault is located within the network. A
traceroute may also be used periodically to verify that data plane traceroute may also be used periodically to verify that data plane
forwarding matches the control plane state; however, this places an forwarding matches the control plane state; however, this places an
increased burden on transit LSRs and should be used infrequently and increased burden on transit LSRs and should be used infrequently and
skipping to change at page 9, line 39 skipping to change at page 9, line 39
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
message MUST carry a Target FEC Stack TLV, and this MUST carry message MUST carry a Target FEC Stack TLV, and this MUST carry
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 a 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 TBD Variable Multicast P2MP LDP FEC Stack
TBD Variable Multicast MP2MP LDP FEC Stack TBD 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
skipping to change at page 11, line 39 skipping to change at page 11, line 39
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.
The P2MP Responder Identifier TLV only has meaning on an echo request The P2MP Responder Identifier TLV only has meaning in an echo request
message. If present on an echo response message, it SHOULD be message. If present in an echo reply message, it SHOULD 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
skipping to change at page 12, line 47 skipping to change at page 12, line 47
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 only if the address in the Sub-TLV corresponds to any address
that is local to the node. This address in the Sub-TLV may be of any that is local to the node. This address in the Sub-TLV may be of any
physical interface or may be the router id of the node itself. 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.
3.3. Preventing Congestion of Echo Responses 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 TBD and is encoded
as follows. 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 = TBD (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 response. A responding node SHOULD wait before sending an echo reply. A responding node SHOULD
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 response message, it SHOULD be ignored. present on an echo reply message, it SHOULD 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|
skipping to change at page 14, line 4 skipping to change at page 14, line 4
The T (Respond Only If TTL Expired) flag SHOULD be set only in the The T (Respond Only If TTL Expired) flag SHOULD 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 SHOULD 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 receiver SHOULD reply as per
regular processing. regular processing.
If the T flag is set to 1, then the receiver SHOULD reply only if the If the T flag is set to 1, then the receiver SHOULD reply only if the
TTL of the incoming MPLS label is equal to 1; if the TTL is more than TTL of the incoming MPLS label is equal to 1; if the TTL is more than
1, then no response should be sent back. 1, then reply SHOULD NOT be sent back.
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 there are no incoming MPLS labels on
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 SHOULD
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
skipping to change at page 15, line 28 skipping to change at page 15, line 28
the control plane, there is no facility to limit the propagation of the control plane, there is no facility to limit the propagation of
echo requests, and they will automatically be forwarded to all echo requests, and they will automatically be forwarded to all
reachable egresses. reachable egresses.
However, a single egress may be identified by the inclusion of a P2MP However, a single egress may be identified by the inclusion of a P2MP
Responder Identifier TLV. The details of this TLV and its Sub-TLVs Responder Identifier TLV. The details of this TLV and its Sub-TLVs
are in section 3.2. There are two main types of sub-TLV in the P2MP are in section 3.2. There are two main types of sub-TLV in the P2MP
Responder Identifier TLV: Node Address sub-TLV and Egress Address Responder Identifier TLV: Node Address sub-TLV and Egress Address
sub-TLV. sub-TLV.
These sub-TLVs limit the responses either to the specified LSR only These sub-TLVs limit the replies either to the specified LSR only
or to any LSR on the path to the specified LSR. The former or to any LSR on the path to the specified LSR. The former
capability is generally useful for ping mode, while the latter is capability is generally useful for ping mode, while the latter is
more suited to traceroute mode. An initiating LSR may indicate that more suited to traceroute mode. An initiating LSR may indicate that
it wishes all egresses to respond to an echo request by omitting the it wishes all egresses to respond to an echo request by omitting the
P2MP Responder Identifier TLV. P2MP Responder Identifier TLV.
4.1.2. Jittered Responses to Echo Requests 4.1.2. Jittered Responses to Echo Requests
The initiating LSR MAY request the responding LSRs to introduce a The initiating LSR MAY request the responding LSRs to introduce a
random delay (or jitter) before sending the response. The randomness random delay (or jitter) before sending the reply. The randomness
of the delay allows the responses from multiple egresses to be spread of the delay allows the replies from multiple egresses to be spread
over a time period. Thus this technique is particularly relevant over a time period. Thus this technique is particularly relevant
when the entire P2MP LSP is being pinged or traced since it helps when the entire P2MP LSP is being pinged or traced since it helps
prevent the initiating (or nearby) LSRs from being swamped by prevent the initiating (or nearby) LSRs from being swamped by
responses, or from discarding responses 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 section 3.3. If this TLV is present, the Echo Jitter TLV as defined in section 3.3. If this TLV is present, the
responding LSR MUST delay sending a response for a random amount of responding LSR SHOULD 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.
LSP ping SHOULD NOT be used to attempt to measure the round-trip time LSP ping SHOULD 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 response is often sent back through the control plane. and the echo reply is often sent back through the control plane.
The timestamp fields in the echo request and echo response packets The timestamp fields in the echo request and echo reply packets
MAY be used to deduce some information about delivery times and MAY be used to deduce some information about delivery times and
particularly the variance in delivery times. particularly 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 response jittering SHOULD be used for P2MP LSPs. If the Echo Echo reply jittering SHOULD be used for P2MP LSPs. If the Echo
Jitter TLV is present in an echo request for any other type of LSPs, Jitter TLV is present in an echo request for any other type of LSPs,
the responding egress MAY apply the jitter behavior as described the responding egress MAY apply the jitter behavior as described
here. 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]. A responding LSR is
RECOMMENDED to rate limit its receipt of echo request messages. RECOMMENDED to rate limit its receipt of echo request messages.
After rate limiting, the responding LSR must verify general sanity of After rate limiting, the responding LSR must verify general sanity of
the packet. If the packet is malformed, or certain TLVs are not the packet. If the packet is malformed, or certain TLVs are not
understood, the [RFC4379] procedures must be followed for echo reply. understood, the [RFC4379] procedures must be followed for echo reply.
Similarly the Reply Mode field determines if the response is required Similarly the Reply Mode field determines if the reply is required
or not (and the mechanism to send it back). 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.
skipping to change at page 17, line 20 skipping to change at page 17, line 20
determine whether it should respond to the reqeust or not. determine whether it should respond to the reqeust or not.
The presence of a P2MP Responder Identifier TLV or a The presence of a P2MP Responder Identifier TLV or a
Downstream Detailed Mapping TLV might affect the Return Code. Downstream Detailed Mapping TLV might affect the Return Code.
This is discussed in more detail later. This is discussed in more detail later.
- If the P2MP Responder Identifier TLV is not present (or, in - If the P2MP Responder Identifier TLV is not present (or, in
the error case, is present, but does not contain any the error case, is present, but does not contain any
sub-TLVs), then the node MUST respond according to [RFC4379] sub-TLVs), then the node MUST respond according to [RFC4379]
processing rules. processing rules.
4.2.1. Echo Response Reporting 4.2.1. Echo Reply Reporting
Echo response messages carry return codes and subcodes to indicate Echo reply messages carry return codes and subcodes to indicate
the result of the LSP Ping (when the ping mode is being used) as the result of the LSP Ping (when the ping mode is being used) as
described in [RFC4379]. described in [RFC4379].
When the responding node reports that it is an egress, it is clear When the responding node reports that it is an egress, it is clear
that the echo response applies only to the reporting node. that the echo reply applies only to that reporting
Similarly, when a node reports that it does not form part of the LSP node. Similarly, when a node reports that it does not form part of
described by the FEC (i.e. there is a misconnection) then the echo the LSP described by the FEC then it is clear that the echo reply
response applies to the reporting node. applies only to that reporting node. However, an echo reply
message that reports an error from a transit node may apply to
However, it should be noted that an echo response message that multiple egress nodes (i.e. leaves) downstream of the reporting node.
reports an error from a transit node may apply to multiple egress In the case of the ping mode of operation, it is not possible to
nodes (i.e. leaves) downstream of the reporting node. In the case of correlate the reporting node to the affected egresses unless the
the ping mode of operation, it is not possible to correlate the topology of the P2MP tree is already known, and it may be necessary
reporting node to the affected egresses unless the topology of the to use the traceroute mode of operation to further diagnose the LSP.
P2MP tree is already known, and it may be necessary to use the
traceroute mode of operation to further diagnose the LSP.
Note also 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 response. this case, the node SHOULD NOT generate an echo reply.
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 response 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 previously, the Return Code might change based on
the presence of Responder Identifier TLV or Downstream Detailed the presence of Responder Identifier TLV or Downstream Detailed
Mapping TLV. 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, which MAY be set to value 8 ('Label
switched at stack-depth <RSC>') or any other error value as needed. switched at stack-depth <RSC>') or any other error value as needed.
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
response header MAY be set to value TBD ('See DDM TLV for Return Code reply header MAY be set to value TBD ('See DDM TLV for Return Code
and Return SubCode') as defined in [DDMT]. The Return Code for each and Return SubCode') as defined in [DDMT]. The Return Code for each
Downstream Detailed Mapping TLV will depend on the downstream path as Downstream Detailed Mapping TLV will depend on the downstream path as
described in [DDMT]. described 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 response. 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, which MAY be set to value 3 ('Replying
router is an egress for the FEC at stack-depth <RSC>') or any other router is an egress for the FEC at stack-depth <RSC>') or any other
error value as needed. error value as needed.
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 response. Downstream Detailed Mapping TLV in the echo reply.
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
guidelines. The intent of these guidelines is to figure out if the guidelines. The intent of these guidelines is to figure out if the
echo request is meant for all nodes, or just this node, or for echo request is meant for all nodes, or just this node, or for
another node reachable through this node or for a different section another node reachable through this node or for a different section
of the tree. In the first case, the node will behave like a of the tree. In the first case, the node will behave like a
combination of egress and branch node; in the second case, the node combination of egress and branch node; in the second case, the node
will behave like pure egress node; in the third case, the node will will behave like pure egress node; in the third case, the node will
behave like a transit node; and in the last case, no response will be behave like a transit node; and in the last case, no reply will be
sent back. sent back.
Node behavior guidelines: Node behavior guidelines:
- 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 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 an combination in the node, then the node will behave like a combination of
egress and branch node. egress and branch node.
- If the address specified in the sub-TLV does not match any - If the address specified in the sub-TLV does not match any
address in the node, then no response will be sent. address in the node, then no reply will be sent.
- If the Responder Identifier TLV containing an Egress Address - If the Responder Identifier TLV containing an Egress 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 an egress node in the node, then the node will behave like an egress node
only. only.
- 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 response 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 the Return
Code MAY be set to value 3 ('Replying router is an egress for Code MAY be set to value 3 ('Replying router is an egress for
the FEC at stack-depth <RSC>') or any other error value as the FEC at stack-depth <RSC>') or any other error value as
needed. The echo response MUST NOT contain any Downstream needed. 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 the Return Code MAY be set to value 8 ('Label switched at
stack-depth <RSC>') or any other error value as needed. stack-depth <RSC>') or any other error value as needed.
- 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 value TBD ('See DDM TLV for
Return Code and Return SubCode') as defined in [DDMT]. The Return Code and Return SubCode') as defined in [DDMT]. The
Return Code for the Downstream Detailed Mapping TLV will Return Code for the Downstream Detailed Mapping TLV will
depend on the downstream path as described in [DDMT]. depend on the downstream path as described in [DDMT].
There will be only one Downstream Detailed Mapping There will be only one Downstream Detailed Mapping
corresponding to the downstream path to the address corresponding to the downstream path to the address
specified in the Egress Address Sub-TLV. specified in the Egress Address Sub-TLV.
- If the node is behaving as a combination egress and branch node, - If the node is behaving as a combination of egress and branch node,
and: 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 the Return Code MAY be set to value 3 ('Replying router is
an egress for the FEC at stack-depth <RSC>') or any other an egress for the FEC at stack-depth <RSC>') or any other
error value as needed. error value as needed.
- 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 3 ('Replying router is an Return Code MAY be set to value 3 ('Replying router is an
egress for the FEC at stack-depth <RSC>') or any other egress for the FEC at stack-depth <RSC>') or any other
error value as needed. Return Code for the each Downstream error value as needed. 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 Traceroutes 4.3.1. End of Processing for Traceroute
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 response 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 response from an egress will not signal the end of Receiving a valid reply from an egress will not signal the end of
processing. processing.
For P2MP TE LSP, the initiating LSR has a priori knowledge about For P2MP TE LSP, the initiating LSR has a priori knowledge about
number of egress nodes and their addresses. Hence it possible to number of egress nodes and their addresses. Hence it is possible to
continue processing till a valid response has been received from each continue processing till a valid reply has been received from each
end-point, provided the responses can be matched correctly to the end-point, provided the replies can be matched correctly to the
egress nodes. egress nodes.
However for Multicast LDP LSP, the initiating LSR might not always However for Multicast LDP LSP, the initiating LSR might not always
know about all the egress nodes. Hence there might not be a know about all the egress nodes. Hence there might not be a
definitive way to estimate the end of processing for traceroute. definitive way to estimate the end of processing for traceroute.
Therefore it is RECOMMENDED that traceroute operations provide for a Therefore it is RECOMMENDED that traceroute operations provide for a
configurable upper limit on TTL values. Hence the user can choose configurable upper limit on TTL values. Hence the user can choose
the depth to which the tree will be probed. the depth to which the tree will be probed.
4.3.2. Multiple responses from Bud and Egress Nodes 4.3.2. Multiple responses from Bud and Egress Nodes
The P2MP traceroute may continue even after it has received a valid The P2MP traceroute may continue even after it has received a valid
response from a bud or egress node, as there may be more nodes at reply from a bud or egress node, as there may be more nodes at
deeper levels. Hence for subsequent TTL values, a bud or egress node deeper levels. Hence for subsequent TTL values, a bud or egress node
that has previously replied would continue to get new echo requests. that has previously replied would continue to get new echo requests.
Since each echo request is handled independently from previous Since each echo request is handled independently from previous
requests, these bud and egress nodes will keep on responding to the requests, these bud and egress nodes will keep on responding to the
traceroute echo requests. This can cause extra processing burden for traceroute echo requests. This can cause extra processing burden for
the initiating LSR and these bud or egress LSRs. the initiating LSR and these bud or egress LSRs.
To prevent a bud or egress node from sending multiple responses in To prevent a bud or egress node from sending multiple replies in
the same traceroute operation, a new "Respond Only If TTL Expired" the same traceroute operation, a new "Respond Only If TTL Expired"
flag is being introduced. This flag is described in Section 3.4. flag is being introduced. This flag is described in Section 3.4.
It is RECOMMENDED that this flag be used for P2MP traceroute mode It is RECOMMENDED that this flag be used for P2MP traceroute mode
only. By using this flag, extraneous responses from bud and egress only. By using this flag, extraneous replies from bud and egress
nodes can be reduced. If PHP is being used in the P2MP tree, then nodes can be reduced. If PHP is being used in the P2MP tree, then
bud and egress nodes will not get any labels with the echo request bud and egress nodes will not get any labels with the echo request
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 response 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 response 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.
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. In
the echo request packet, the "Downstream IP Address" field, of the the echo request packet, the "Downstream IP Address" field, of the
Downstream Detailed Mapping TLV, SHOULD be set to the ALLROUTERS Downstream Detailed Mapping TLV, SHOULD be set to the ALLROUTERS
multicast address. multicast address.
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 path to one egress. Therefore
this traceroute is effectively behaving like a P2P traceroute. In this traceroute is effectively behaving like a P2P traceroute. In
this scenario, as per section 4.2, the echo responses from this scenario, as per section 4.2, the echo replies from
intermediate nodes will contain only one Downstream Detailed Mapping intermediate nodes will contain only one Downstream Detailed Mapping
TLV corresponding to the downstream path required to reach the TLV corresponding to the downstream path required to reach the
address specified in the Egress Address sub-TLV. For this case, the address specified in the Egress Address sub-TLV. For this case, the
echo request packet MAY reuse a received Downstream Detailed Mapping echo request packet MAY reuse a received Downstream Detailed Mapping
TLV. TLV.
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
skipping to change at page 22, line 34 skipping to change at page 22, line 31
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 response SHOULD carry information only about Mapping TLV in the echo reply SHOULD carry information only about
the outgoing interface corresponding to the input interface. the outgoing interface corresponding to the input interface.
Due to this restriction, the cross-over node will not duplicate the Due to this restriction, the cross-over node will not duplicate the
outgoing interface information in each of the echo request it outgoing interface information in each of the echo request it
receives via the different input interfaces. This will reflect the receives via the different input interfaces. This will reflect the
actual packet replication in the data plane. 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
skipping to change at page 23, line 23 skipping to change at page 23, line 19
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 must be made.
- 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 responses 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, it SHOULD provide the
ability to limit the scope of an LSP Ping echo request for a ability to limit the scope of an LSP Ping echo request for a
P2MP MPLS LSP to a single egress. P2MP MPLS LSP to a single egress.
Such an interface SHOULD also provide the ability to disable all Such an interface 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 this section have already been assigned using the IANA
early allocation process [RFC4020]. 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).
skipping to change at page 26, line 18 skipping to change at page 26, line 9
[P2MP-LDP] Minei, I., and Wijnands, I., "Label Distribution Protocol [P2MP-LDP] Minei, I., and Wijnands, I., "Label Distribution Protocol
Extensions for Point-to-Multipoint and Extensions for Point-to-Multipoint and
Multipoint-to-Multipoint Label Switched Paths", Multipoint-to-Multipoint Label Switched Paths",
draft-ietf-mpls-ldp-p2mp, work in progress. draft-ietf-mpls-ldp-p2mp, work in progress.
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and Swallow, G., [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and Swallow, G.,
"Bidirectional Forwarding Detection (BFD) for MPLS Label "Bidirectional Forwarding Detection (BFD) for MPLS Label
Switched Paths (LSPs)", RFC 5884, June 2010 Switched Paths (LSPs)", RFC 5884, June 2010
[IANA-PORT] IANA Assigned Port Numbers, http://www.iana.org [IANA-PORT] IANA Assigned Port Numbers,
http://www.iana.org/assignments/mpls-lsp-parameters/
[RFC4461] S. Yasukawa, et al., "Signaling Requirements for [RFC4461] S. Yasukawa, et al., "Signaling Requirements for
Point-to-Multipoint Traffic-Engineered MPLS Label Point-to-Multipoint Traffic-Engineered MPLS Label
Switched Paths (LSPs)", RFC 4461, April 2006 Switched Paths (LSPs)", RFC 4461, April 2006
[RFC4020] Kompella, K., Zinin, A., "Early Allocation of Standard [RFC4020] Kompella, K., Zinin, A., "Early Allocation of Standard
Code Points", RFC 4020, February 2005. Code Points", RFC 4020, February 2005.
11. Authors' Addresses 11. Authors' Addresses
skipping to change at page 27, line 4 skipping to change at page 26, line 44
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
Email: tnadeau@lucidvision.com
Thomas D. Nadeau
CA Technologies
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. 60 change blocks. 
87 lines changed or deleted 81 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/