draft-ietf-mpls-p2mp-lsp-ping-12.txt   draft-ietf-mpls-p2mp-lsp-ping-13.txt 
Network Working Group S. Saxena, Ed. Network Working Group S. Saxena, Ed.
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended Status: Standards Track A. Farrel Intended Status: Standards Track A. Farrel
Updates: 4379 (if approved) Old Dog Consulting Updates: 4379 (if approved) Old Dog Consulting
Expires: April 17, 2011 S. Yasukawa Expires: May 7, 2011 S. Yasukawa
NTT Corporation NTT Corporation
October 18, 2010 November 08, 2010
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-12.txt draft-ietf-mpls-p2mp-lsp-ping-13.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 38 skipping to change at page 2, line 38
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 Responses...................... 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 Router Operations................................. 14 4.1. Initiating Router 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 Router Operations................................. 16 4.2. Responding Router Operations................................. 16
4.2.1. Echo Response Reporting.................................... 17 4.2.1. Echo Response Reporting.................................... 17
4.2.1.1. Responses from Transit and Branch nodes.................. 17 4.2.1.1. Responses from Transit and Branch nodes.................. 18
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 Traceroutes.......................... 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 Considerations............................................. 23 6. OAM Considerations............................................. 23
7. IANA Considerations............................................ 23 7. IANA Considerations............................................ 23
7.1. New Sub-TLV Types............................................ 23 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............................................... 24 9. Acknowledgements............................................... 24
10. References.................................................... 24 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...................................... 26 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)
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 13, line 47 skipping to change at page 13, line 47
| 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 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 1, then the reciever SHOULD reply only if the
TTL of the incoming MPLS label is equal to 1; if the TTL is more than
1, then no response should be sent back. If there is no incoming
MPLS label on the echo request packet, then this bit SHOULD 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
TTL of the incoming MPLS label is equal to 1; if the TTL is more than
1, then no response should be sent back.
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
choose to not respond to this echo request. All other nodes SHOULD
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 4.3 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
skipping to change at page 23, line 45 skipping to change at page 24, line 6
extension of the LSP Ping MIB module used for P2P LSPs. extension of the LSP Ping MIB module used for P2P LSPs.
7. IANA Considerations 7. IANA Considerations
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
from the "Multiprotocol Label Switching Architecture (MPLS) Label under TLV type 1 (Target FEC Stack) from the "Multiprotocol Label
Switched Paths (LSPs) Parameters - TLVs" registry, "TLVs and Switching Architecture (MPLS) Label Switched Paths (LSPs) Parameters
sub-TLVs" sub-registry. - TLVs" registry, "TLVs and sub-TLVs" sub-registry.
RSVP P2MP IPv4 Session (Section 3.1.1). Suggested value 17. RSVP P2MP IPv4 Session (Section 3.1.1). Suggested value 17.
RSVP P2MP IPv6 Session (Section 3.1.1). Suggested value 18. RSVP P2MP IPv6 Session (Section 3.1.1). Suggested value 18.
Multicast P2MP LDP FEC Stack (Section 3.1.2). Suggested value 19. Multicast P2MP LDP FEC Stack (Section 3.1.2). Suggested value 19.
Multicast MP2MP LDP FEC Stack (Section 3.1.2). Suggested value 20. 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 P2MP Responder Identifier TLV (see Section 3.2) is a mandatory
TLV. Suggested value 11. 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 Echo Jitter TLV (see Section 3.3) is a mandatory TLV. Suggested
value 12. value 12.
8. Security Considerations 8. Security Considerations
skipping to change at page 25, line 47 skipping to change at page 26, line 12
point-to-multipoint extensions to the Label Distribution point-to-multipoint extensions to the Label Distribution
Protocol", draft-ietf-mpls-mp-ldp-reqs, work in progress. Protocol", draft-ietf-mpls-mp-ldp-reqs, work in progress.
[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
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
 End of changes. 12 change blocks. 
18 lines changed or deleted 22 lines changed or added

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