--- 1/draft-ietf-mpls-self-ping-03.txt 2015-09-09 13:15:00.356867682 -0700 +++ 2/draft-ietf-mpls-self-ping-04.txt 2015-09-09 13:15:00.384868366 -0700 @@ -1,25 +1,23 @@ -MPLS Working Group R. Torvi -Internet-Draft R. Bonica -Intended status: Standards Track Juniper Networks -Expires: March 8, 2016 I. Minei - Google, Inc. +MPLS Working Group R. Bonica +Internet-Draft Juniper Networks +Intended status: Standards Track I. Minei +Expires: March 11, 2016 Google, Inc. M. Conn D. Pacella L. Tomotaki - M. Wygant Verizon - September 5, 2015 + September 8, 2015 LSP Self-Ping - draft-ietf-mpls-self-ping-03 + draft-ietf-mpls-self-ping-04 Abstract When certain RSVP-TE optimizations are implemented, ingress LSRs can receive RSVP RESV messages before forwarding state has been installed on all downstream nodes. According to the RSVP-TE specification, the ingress LSR can forward traffic through an LSP as soon as it receives a RESV message. However, if the ingress LSR forwards traffic through the LSP before forwarding state has been installed on all downstream nodes, traffic can be lost. @@ -45,21 +43,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -72,25 +70,26 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 3. The LSP Self-ping Message . . . . . . . . . . . . . . . . . . 5 4. LSP Self Ping Procedures . . . . . . . . . . . . . . . . . . 6 5. Bidirectional LSP Procedures . . . . . . . . . . . . . . . . 7 6. Rejected Approaches . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 - 10.2. Informative References . . . . . . . . . . . . . . . . . 10 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 + 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 + 11.2. Informative References . . . . . . . . . . . . . . . . . 10 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction Ingress Label Switching Routers (LSR) use RSVP-TE [RFC3209] to establish MPLS Label Switched Paths. The following paragraphs describe RSVP-TE procedures. The ingress LSR calculates a path between itself and an egress LSR. The calculated path can be either strictly or loosely routed. Having calculated a path, the ingress LSR constructs an RSVP PATH message. @@ -390,28 +389,44 @@ 8. Security Considerations LSP Self-ping messages are easily forged. Therefore, an attacker can send the ingress LSR a forged LSP Self-ping message, causing the ingress LSR to terminate the LSP Self-ping session prematurely. In order to mitigate these threats, implementations SHOULD NOT assign Session-ID's in a predictable manner. Furthermore, operators SHOULD 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 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, DOI 10.17487/RFC0768, August 1980, . [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate @@ -441,21 +456,21 @@ "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, October 2007, . [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, . -10.2. Informative References +11.2. Informative References [I-D.akiya-bfd-seamless-base] Akiya, N., Pignataro, C., Ward, D., Bhatia, M., and J. Networks, "Seamless Bidirectional Forwarding Detection (S-BFD)", draft-akiya-bfd-seamless-base-03 (work in progress), April 2014. [IANA.PORTS] IANA, "Service Name and Transport Protocol Port Number Registry", . [RFC6383] Shiomoto, K. and A. Farrel, "Advice on When It Is Safe to Start Sending Data on Label Switched Paths Established Using RSVP-TE", RFC 6383, DOI 10.17487/RFC6383, September 2011, . Authors' Addresses - Ravi Torvi - Juniper Networks - - Email: rtorvi@juniper.net Ron Bonica Juniper Networks Email: rbonica@juniper.net Ina Minei Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 U.S.A. @@ -498,15 +509,10 @@ Dante Pacella Verizon Email: dante.j.pacella@verizon.com Luis Tomotaki Verizon Email: luis.tomotaki@verizon.com - - Mark Wygant - Verizon - - Email: mark.wygant@verizon.com