draft-ietf-mpls-p2mp-lsp-ping-11.txt   draft-ietf-mpls-p2mp-lsp-ping-12.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
Created: October 08, 2010 S. Yasukawa Expires: April 17, 2011 S. Yasukawa
Expires: April 08, 2010 NTT Corporation NTT Corporation
October 18, 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-11.txt draft-ietf-mpls-p2mp-lsp-ping-12.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 18 skipping to change at page 2, line 18
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].
Contents Contents
1. Introduction.................................................... 5 1. Introduction.................................................... 3
1.1. Design Considerations......................................... 6 1.1. Design Considerations......................................... 4
2. Notes on Motivation............................................. 6 2. Notes on Motivation............................................. 4
2.1. Basic Motivations for LSP Ping................................ 7 2.1. Basic Motivations for LSP Ping................................ 4
2.2. Motivations for LSP Ping for P2MP LSPs........................ 7 2.2. Motivations for LSP Ping for P2MP LSPs........................ 5
3. Packet Format................................................... 9 3. Packet Format................................................... 7
3.1. Identifying the LSP Under Test................................ 9 3.1. Identifying the LSP Under Test................................ 7
3.1.1. Identifying a P2MP MPLS TE LSP.............................. 9 3.1.1. Identifying a P2MP MPLS TE LSP.............................. 7
3.1.1.1. RSVP P2MP IPv4 Session Sub-TLV........................... 10 3.1.1.1. RSVP P2MP IPv4 Session Sub-TLV............................ 8
3.1.1.2. RSVP P2MP IPv6 Session Sub-TLV........................... 10 3.1.1.2. RSVP P2MP IPv6 Session Sub-TLV............................ 8
3.1.2. Identifying a Multicast LDP LSP............................ 11 3.1.2. Identifying a Multicast LDP LSP............................. 9
3.1.2.1. Multicast LDP FEC Stack Sub-TLVs......................... 11 3.1.2.1. Multicast LDP FEC Stack Sub-TLVs.......................... 9
3.1.2.2. Applicability to Multipoint-to-Multipoint LSPs........... 13 3.1.2.2. Applicability to Multipoint-to-Multipoint LSPs........... 11
3.2. Limiting the Scope of Responses.............................. 13 3.2. Limiting the Scope of Responses.............................. 11
3.2.1. Egress Address P2MP Responder Identifier Sub-TLVs.......... 14 3.2.1. Egress Address P2MP Responder Identifier Sub-TLVs.......... 12
3.2.2. Node Address P2MP Responder Identifier Sub-TLVs............ 14 3.2.2. Node Address P2MP Responder Identifier Sub-TLVs............ 12
3.3. Preventing Congestion of Echo Responses...................... 14 3.3. Preventing Congestion of Echo Responses...................... 12
3.4. Respond Only If TTL Expired Flag............................. 15 3.4. Respond Only If TTL Expired Flag............................. 13
3.5. Downstream Detailed Mapping TLV.............................. 16 3.5. Downstream Detailed Mapping TLV.............................. 14
4. Operation of LSP Ping for a P2MP LSP........................... 16 4. Operation of LSP Ping for a P2MP LSP........................... 14
4.1. Initiating Router Operations................................. 16 4.1. Initiating Router Operations................................. 14
4.1.1. Limiting Responses to Echo Requests........................ 17 4.1.1. Limiting Responses to Echo Requests........................ 15
4.1.2. Jittered Responses to Echo Requests........................ 17 4.1.2. Jittered Responses to Echo Requests........................ 15
4.2. Responding Router Operations................................. 18 4.2. Responding Router Operations................................. 16
4.2.1. Echo Response Reporting.................................... 19 4.2.1. Echo Response Reporting.................................... 17
4.2.1.1. Responses from Transit and Branch nodes.................. 19 4.2.1.1. Responses from Transit and Branch nodes.................. 17
4.2.1.2. Responses from Egress Nodes.............................. 20 4.2.1.2. Responses from Egress Nodes.............................. 18
4.2.1.3. Responses from Bud Nodes................................. 20 4.2.1.3. Responses from Bud Nodes................................. 18
4.3. Special Considerations for Traceroute........................ 22 4.3. Special Considerations for Traceroute........................ 20
4.3.1. End of Processing for Traceroutes.......................... 22 4.3.1. End of Processing for Traceroutes.......................... 20
4.3.2. Multiple responses from Bud and Egress Nodes............... 23 4.3.2. Multiple responses from Bud and Egress Nodes............... 21
4.3.3. Non-Response to Traceroute Echo Requests................... 23 4.3.3. Non-Response to Traceroute Echo Requests................... 21
4.3.4. Use of Downstream Detailed Mapping TLV in Echo Request..... 23 4.3.4. Use of Downstream Detailed Mapping TLV in Echo Request..... 21
4.3.5 Cross Over Node Processing.................................. 24 4.3.5 Cross Over Node Processing.................................. 22
5. Non-compliant Routers.......................................... 24 5. Non-compliant Routers.......................................... 22
6. OAM Considerations............................................. 25 6. OAM Considerations............................................. 23
7. IANA Considerations............................................ 25 7. IANA Considerations............................................ 23
7.1. New Sub-TLV Types............................................ 25 7.1. New Sub-TLV Types............................................ 23
7.2. New TLVs..................................................... 26 7.2. New TLVs..................................................... 24
8. Security Considerations........................................ 26 8. Security Considerations........................................ 24
9. Acknowledgements............................................... 26 9. Acknowledgements............................................... 24
10. References.................................................... 26 10. References.................................................... 24
10.1. Normative References........................................ 27 10.1. Normative References........................................ 25
10.2. Informative References...................................... 27 10.2. Informative References...................................... 25
11. Authors' Addresses............................................ 28 11. Authors' Addresses............................................ 26
12. Full Copyright Statement...................................... 28 12. Full Copyright Statement...................................... 26
0. Change Log
This section to be removed before publication as an RFC.
0.1 Changes from 00 to 01
- Update references.
- Fix boilerplate.
0.2 Changes from 01 to 02
- Update entire document so that it is not specific to MPLS-TE, but
also includes multicast LDP LSPs.
- Move the egress identifier sub-TLVs from the FEC Stack TLV to a new
egress identifier TLV.
- Include Multicast LDP FEC Stack sub-TLV definition from [MCAST-CV].
- Add brief section on use of LSP Ping for bootstrapping.
- Add new references to References section.
- Add details of two new authors.
0.3 Changes from 02 to 03
- Update references.
- Update boilerplate.
- Fix typos.
- Clarify in 3.2.2 that a recipient of an echo request must reply
only once it has applied incoming rate limiting.
- Tidy references to bootstrapping for [MCAST-CV] in 1.1.
- Allow multiple sub-TLVs in the P2MP Egress Identifier TLV in
sections 3.2.1, 3.2.2, 3.2.4, 3.3.1, and 3.3.4.
- Clarify how to handle a P2MP Egress Identifier TLV with no sub-TLVs
in sections 3.2.1 and 3.2.2.
0.4 Changes from 03 to 04
- Revert to previous text in sections 3.2.1, 3.2.2, 3.2.4, 3.3.1, and
3.3.4 with respect to multiple sub-TLVs in the P2MP Egress
Identifier TLV.
0.5 Changes from 04 to 05
- Change coordinates for Tom Nadeau. Section 13.
- Fix typos.
- Update references.
- Resolve all acronym expansions.
0.6 Changes from 05 to 06
- New section, 3.2.6, to explain echo response reporting in the Ping
case.
- New section, 3.3.7, to explain echo response reporting in the
Traceroute case.
- Sections 3.3.2, 3.3.5, and 5. Retire the E-flag for identification
of bud nodes. Use the B-flag in a Downstream Mapping TLV with a
zero address to provide the necessary indication.
- Section 3.3.4. Note the use of ALLROUTERS address as per RFC 4379
- Section 7. Suggest values for IANA assignment.
- Rename "P2MP Responder Identifier TLV" to "P2MP Responder
Identifier TLV", "Egress Identifier sub-TLV" to "Responder
Identifier sub-TLV", and "P2MP egresses" multipath type to "P2MP
responder". This allows any LSR on the P2MP LSP to be the target
of, or responder to, an echo request.
0.7 Changes from 06 to 07
- Sections 3.3.2 and 3.3.3. Delete section 3.3.5. New sections
3.3.2.1 through 3.3.2.3: Retire B-flag from Downstream Mapping TLV.
Introduce new Node Properties TLV with Branching Properties and
Egress Address sub-TLVs.
- Section 3.3.2.4: Clarify rules on presence of Multipath Information
in Downstream Mapping TLVs.
- Section 3.3.5: Clarify padding rules.
- Section 3.3.6: Updated to use Downstream Detailed Mapping TLVs for
multiple return conditions reported by a single echo response.
- Section 7: Update IANA values and add new sub-sections.
- Section 11: Add reference draft-ietf-mpls-lsp-ping-enhanced-dsmap.
- Section 13: Update Bill Fenner's coordinates.
0.8 Changes from 07 to 08
- Removed the Node Properties TLV (Section 3.3.2.1 of version 07).
- Removed the New Multipath Type from Multipath Sub-TLV (Section
3.3.5 of version 07).
- Removed the Return Code Sub-TLV from Downstream Detailed TLV
(Section 3.3.6.1 of version 07), as it is already included in
draft-ietf-mpls-lsp-ping-enhanced-dsmap-02.
- Clarified the behavior of Responder Identifier TLV (Section
3.2.4 of version 07). Two new Sub-TLVs are introduced.
- Downstream Detailed Mapping TLV is now mandatory for implementing
P2MP OAM functionality.
- Split Multicast LDP TLV into two TLVs, one for P2MP and other for
MP2MP. Also added description to allow MP2MP ping by using this
draft.
- Removed Section 4. as it was a duplicate of Section 2.3.
0.9 Changes from 08 to 09
- Reformatted the document to follow the RFC4379 style. After the
Motivations section is the Packet Format section, followed by the
Operations section. The sections on Ping and Traceroute have been
merged.
- Added a Respond if TTL Expired Flag.
- Removed reference to [MCAST-CV].
0.10 Changes from 09 to 10
- Removed references to bootstrapping other OAM protocols. This draft
does not provide any details of such methods. Hence it is cleaner
to remove such references.
- Minor edits based on comments.
0.11 Changes from 10 to 11
- Updated behavior of T bit when no label is present.
- Clarified that Egress Address TLV is not applicable to tracing in
Multicast LDP trees.
- Changed expected processing at bud nodes upon receipt of Node
Address Responder Identifier TLV from egress node only to
combination of egress and branch node.
- Added details on how Downstream Detailed Mapping TLV should be
filled for cross-over node scenario.
- Various edits based on comments.
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 6, line 39 skipping to change at page 4, line 20
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 OAM
procedures such as [MPLS-BFD]. 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
well-known UDP port defined for use by LSP Ping traffic. well-known UDP port defined for use by LSP Ping traffic.
2. Notes on Motivation 2. Notes on Motivation
skipping to change at page 26, line 44 skipping to change at page 24, line 44
9. Acknowledgements 9. Acknowledgements
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,
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,
February 2006. February 2006.
skipping to change at page 27, line 45 skipping to change at page 25, line 45
[P2MP-LDP-REQ] J.-L. Le Roux, et al., "Requirements for [P2MP-LDP-REQ] J.-L. Le Roux, et al., "Requirements for
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.
[MPLS-BFD] Aggarwal, R., Kompella, K., Nadeau, T., and Swallow, G., [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and Swallow, G.,
"BFD For MPLS LSPs", draft-ietf-bfd-mpls, work in "Bidirectional Forwarding Detection (BFD) for MPLS Label
progress. 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. 6 change blocks. 
175 lines changed or deleted 56 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/