draft-ietf-mpls-self-ping-03.txt   draft-ietf-mpls-self-ping-04.txt 
MPLS Working Group R. Torvi MPLS Working Group R. Bonica
Internet-Draft R. Bonica Internet-Draft Juniper Networks
Intended status: Standards Track Juniper Networks Intended status: Standards Track I. Minei
Expires: March 8, 2016 I. Minei Expires: March 11, 2016 Google, Inc.
Google, Inc.
M. Conn M. Conn
D. Pacella D. Pacella
L. Tomotaki L. Tomotaki
M. Wygant
Verizon Verizon
September 5, 2015 September 8, 2015
LSP Self-Ping LSP Self-Ping
draft-ietf-mpls-self-ping-03 draft-ietf-mpls-self-ping-04
Abstract Abstract
When certain RSVP-TE optimizations are implemented, ingress LSRs can When certain RSVP-TE optimizations are implemented, ingress LSRs can
receive RSVP RESV messages before forwarding state has been installed receive RSVP RESV messages before forwarding state has been installed
on all downstream nodes. According to the RSVP-TE specification, the on all downstream nodes. According to the RSVP-TE specification, the
ingress LSR can forward traffic through an LSP as soon as it receives ingress LSR can forward traffic through an LSP as soon as it receives
a RESV message. However, if the ingress LSR forwards traffic through a RESV message. However, if the ingress LSR forwards traffic through
the LSP before forwarding state has been installed on all downstream the LSP before forwarding state has been installed on all downstream
nodes, traffic can be lost. nodes, traffic can be lost.
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 8, 2016. This Internet-Draft will expire on March 11, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 37 skipping to change at page 2, line 37
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The LSP Self-ping Message . . . . . . . . . . . . . . . . . . 5 3. The LSP Self-ping Message . . . . . . . . . . . . . . . . . . 5
4. LSP Self Ping Procedures . . . . . . . . . . . . . . . . . . 6 4. LSP Self Ping Procedures . . . . . . . . . . . . . . . . . . 6
5. Bidirectional LSP Procedures . . . . . . . . . . . . . . . . 7 5. Bidirectional LSP Procedures . . . . . . . . . . . . . . . . 7
6. Rejected Approaches . . . . . . . . . . . . . . . . . . . . . 8 6. Rejected Approaches . . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . 10 11.1. Normative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 11.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
Ingress Label Switching Routers (LSR) use RSVP-TE [RFC3209] to Ingress Label Switching Routers (LSR) use RSVP-TE [RFC3209] to
establish MPLS Label Switched Paths. The following paragraphs establish MPLS Label Switched Paths. The following paragraphs
describe RSVP-TE procedures. describe RSVP-TE procedures.
The ingress LSR calculates a path between itself and an egress LSR. The ingress LSR calculates a path between itself and an egress LSR.
The calculated path can be either strictly or loosely routed. Having The calculated path can be either strictly or loosely routed. Having
calculated a path, the ingress LSR constructs an RSVP PATH message. calculated a path, the ingress LSR constructs an RSVP PATH message.
skipping to change at page 9, line 19 skipping to change at page 9, line 19
8. Security Considerations 8. Security Considerations
LSP Self-ping messages are easily forged. Therefore, an attacker can LSP Self-ping messages are easily forged. Therefore, an attacker can
send the ingress LSR a forged LSP Self-ping message, causing the send the ingress LSR a forged LSP Self-ping message, causing the
ingress LSR to terminate the LSP Self-ping session prematurely. In ingress LSR to terminate the LSP Self-ping session prematurely. In
order to mitigate these threats, implementations SHOULD NOT assign order to mitigate these threats, implementations SHOULD NOT assign
Session-ID's in a predictable manner. Furthermore, operators SHOULD Session-ID's in a predictable manner. Furthermore, operators SHOULD
filter LSP Self-ping packets at network ingress points. filter LSP Self-ping packets at network ingress points.
9. Acknowledgements 9. Contributors
The following individuals contributed significantly to this document:
Mark Wygant
Verizon
mark.wygant@verizon.com
Ravi Torvi
Juniper Networks
rtorvi@juniper.net
10. Acknowledgements
Thanks to Yakov Rekhter, Ravi Singh, Eric Rosen, Eric Osborne, Greg Thanks to Yakov Rekhter, Ravi Singh, Eric Rosen, Eric Osborne, Greg
Mirsky and Nobo Akiya for their contributions to this document. Mirsky and Nobo Akiya for their contributions to this document.
10. References 11. References
10.1. Normative References 11.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980, DOI 10.17487/RFC0768, August 1980,
<http://www.rfc-editor.org/info/rfc768>. <http://www.rfc-editor.org/info/rfc768>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981,
<http://www.rfc-editor.org/info/rfc791>. <http://www.rfc-editor.org/info/rfc791>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 10, line 21 skipping to change at page 10, line 39
"LDP Specification", RFC 5036, DOI 10.17487/RFC5036, "LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
October 2007, <http://www.rfc-editor.org/info/rfc5036>. October 2007, <http://www.rfc-editor.org/info/rfc5036>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA) Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165, Transport Protocol Port Number Registry", BCP 165,
RFC 6335, DOI 10.17487/RFC6335, August 2011, RFC 6335, DOI 10.17487/RFC6335, August 2011,
<http://www.rfc-editor.org/info/rfc6335>. <http://www.rfc-editor.org/info/rfc6335>.
10.2. Informative References 11.2. Informative References
[I-D.akiya-bfd-seamless-base] [I-D.akiya-bfd-seamless-base]
Akiya, N., Pignataro, C., Ward, D., Bhatia, M., and J. Akiya, N., Pignataro, C., Ward, D., Bhatia, M., and J.
Networks, "Seamless Bidirectional Forwarding Detection Networks, "Seamless Bidirectional Forwarding Detection
(S-BFD)", draft-akiya-bfd-seamless-base-03 (work in (S-BFD)", draft-akiya-bfd-seamless-base-03 (work in
progress), April 2014. progress), April 2014.
[IANA.PORTS] [IANA.PORTS]
IANA, "Service Name and Transport Protocol Port Number IANA, "Service Name and Transport Protocol Port Number
Registry", <http://www.iana.org/assignments/ Registry", <http://www.iana.org/assignments/
skipping to change at page 10, line 47 skipping to change at page 11, line 17
DOI 10.17487/RFC4594, August 2006, DOI 10.17487/RFC4594, August 2006,
<http://www.rfc-editor.org/info/rfc4594>. <http://www.rfc-editor.org/info/rfc4594>.
[RFC6383] Shiomoto, K. and A. Farrel, "Advice on When It Is Safe to [RFC6383] Shiomoto, K. and A. Farrel, "Advice on When It Is Safe to
Start Sending Data on Label Switched Paths Established Start Sending Data on Label Switched Paths Established
Using RSVP-TE", RFC 6383, DOI 10.17487/RFC6383, September Using RSVP-TE", RFC 6383, DOI 10.17487/RFC6383, September
2011, <http://www.rfc-editor.org/info/rfc6383>. 2011, <http://www.rfc-editor.org/info/rfc6383>.
Authors' Addresses Authors' Addresses
Ravi Torvi
Juniper Networks
Email: rtorvi@juniper.net
Ron Bonica Ron Bonica
Juniper Networks Juniper Networks
Email: rbonica@juniper.net Email: rbonica@juniper.net
Ina Minei Ina Minei
Google, Inc. Google, Inc.
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA 94043 Mountain View, CA 94043
U.S.A. U.S.A.
skipping to change at page 11, line 31 skipping to change at line 519
Dante Pacella Dante Pacella
Verizon Verizon
Email: dante.j.pacella@verizon.com Email: dante.j.pacella@verizon.com
Luis Tomotaki Luis Tomotaki
Verizon Verizon
Email: luis.tomotaki@verizon.com Email: luis.tomotaki@verizon.com
Mark Wygant
Verizon
Email: mark.wygant@verizon.com
 End of changes. 12 change blocks. 
22 lines changed or deleted 33 lines changed or added

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