--- 1/draft-ietf-mpls-self-ping-02.txt 2015-09-05 14:14:59.010106705 -0700 +++ 2/draft-ietf-mpls-self-ping-03.txt 2015-09-05 14:14:59.038107384 -0700 @@ -1,25 +1,25 @@ MPLS Working Group R. Torvi Internet-Draft R. Bonica Intended status: Standards Track Juniper Networks -Expires: December 17, 2015 I. Minei +Expires: March 8, 2016 I. Minei Google, Inc. M. Conn D. Pacella L. Tomotaki M. Wygant Verizon - June 15, 2015 + September 5, 2015 LSP Self-Ping - draft-ietf-mpls-self-ping-02 + draft-ietf-mpls-self-ping-03 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 +45,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 December 17, 2015. + This Internet-Draft will expire on March 8, 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 @@ -84,21 +84,21 @@ 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 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 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 calculated a path, the ingress LSR constructs an RSVP PATH message. The PATH message includes an Explicit Route Object (ERO) that represents the path between the ingress and egress LSRs. The ingress LSR forwards the PATH message towards the egress LSR, following the path defined by the ERO. Each transit LSR that receives the PATH message executes admission control procedures. If the transit LSR admits the LSP, it sends the PATH message downstream, @@ -122,37 +122,37 @@ When the ingress LSR receives the RESV message, it installs forwarding state. Once the ingress LSR installs forwarding state it can forward traffic through the LSP. Some implementations optimize the above-described procedure by allowing LSRs to send RESV messages before installing forwarding state [RFC6383]. This optimization is desirable, because it allows LSRs to install forwarding state in parallel, thus accelerating the process of LSP signaling and setup. However, this optimization creates a race condition. When the ingress LSR receives a RESV - message, some downstream LSRs may not have installed forwarding state - yet. If the ingress LSR forwards traffic through the LSP before + message, some downstream LSRs may have not yet installed forwarding + state. If the ingress LSR forwards traffic through the LSP before forwarding state has been installed on all downstream nodes, traffic can be lost. This memo describes LSP Self-ping. When an ingress LSR receives an RESV message, it can invoke LSP Self-ping procedures to verify that forwarding state has been installed on all downstream nodes. By verifying the installation of downstream forwarding state, the ingress LSR eliminates this particular cause of traffic loss. LSP Self-ping is an extremely light-weight mechanism. It does not consume control plane resources on transit or egress LSRs. Although LSP Ping and LSP Self-ping are named similarly, each is a - unique protocol. Each protocol listens on its own UDP port and - executes is own unique procedures. + unique protocol, designed for a unique purpose. Each protocol + listens on its own UDP port and executes its own unique procedures. 2. Applicability LSP Self-ping is applicable in the following scenario: o The ingress LSR signals a point-to-point LSP o The ingress LSR receives a RESV message o The RESV message indicates that all downstream nodes have begun @@ -200,36 +200,36 @@ o An S-BFD implementation either consumes control plane resources on the egress LSR or requires special support for S-BFD on the forwarding plane. By contrast, LSP Self-ping requires nothing from the egress LSR beyond the ability to forward an IP datagram. LSP Self-ping's purpose is to determine whether forwarding state has been installed on all downstream LSRs. Its primary constraint is to minimize its impact on egress LSR performance. This functionality is - required during network convergence events that impact a large number + valuable during network convergence events that impact a large number of LSPs. Therefore, LSP Self-ping is applicable in the scenario described above, where the LSP is signaled by RSVP, RPF is not enabled, and the need to conserve control plane resources on the egress LSR outweighs the need to determine whether downstream forwarding state is correct. 3. The LSP Self-ping Message The LSP Self-ping Message is a User Datagram Protocol (UDP) [RFC0768] - packet. If the RSVP messages used to establish the LSP under test - were delivered over IPv4 [RFC0791], the UDP datagram MUST be - encapsulated in an IPv4 header. If the RSVP messages used to - establish the LSP were delivered over IPv6 [RFC2460], the UDP - datagram MUST be encapsulated in an IPv6 header. + packet that encapsulates a session ID. If the RSVP messages used to + establish the LSP under test were delivered over IPv4 [RFC0791], the + UDP datagram MUST be encapsulated in an IPv4 header. If the RSVP + messages used to establish the LSP were delivered over IPv6 + [RFC2460], the UDP datagram MUST be encapsulated in an IPv6 header. In either case: o The IP Source Address MAY be configurable. By default, it MUST be the address of the egress LSR o The IP Destination Address MUST be the address of the ingress LSR o The IP Time to Live (TTL) / Hop Count MAY be configurable. By default, it MUST be 255 @@ -271,21 +271,21 @@ initial value of this variable is determined by configuration. o Retry Timer: The number of milliseconds that the LSR waits after probing the LSP. The initial value of this variable is determined by configuration. o Status: A boolean variable indicating the completion status of the LSP Self-ping session. The initial value of this variable is FALSE. - Implementation MAY represent the above mentioned information in any + Implementations MAY represent the above mentioned information in any format that is convenient to them. The ingress LSR executes the following procedure until Status equals TRUE or Retry Counter equals zero: o Format a LSP Self-ping message. o Set the Session-ID in the LSP Self-ping message to the Session-ID mentioned above @@ -363,37 +363,36 @@ Ping well above the overhead of its data plane (MPLS/IP forwarding). These factors make LSP Ping problematic as a tool for detecting LSP readiness to carry traffic when dealing with a large number of LSPs. By contrast, LSP Self-ping does not consume any control plane resources at the egress LSR, and relies solely on the data plane of the egress LSR, making it more suitable as a tool for checking LSP readiness when dealing with a large number of LSPs. In another rejected approach, the ingress LSR does not verify LSP - readiness. Alternatively, it sets a timer when it receives an RSVP - RESV message and does not forward traffic through the LSP until the - timer expires. This approach was rejected because it is impossible - to determine the optimal setting for this timer. If the timer value - is set too low, it does not prevent black-holing. If the timer value - is set too high, it slows down the process of LSP signalling and - setup. + readiness. Instead, it sets a timer when it receives an RSVP RESV + message and does not forward traffic through the LSP until the timer + expires. This approach was rejected because it is impossible to + determine the optimal setting for this timer. If the timer value is + set too low, it does not prevent black-holing. If the timer value is + set too high, it slows down the process of LSP signalling and setup. Moreover, the above-mentioned timer is configured on a per-router basis. However, its optimum value is determined by a network-wide behavior. Therefore, changes in the network could require changes to the value of the timer, making the optimal setting of this timer a moving target. 7. IANA Considerations - IANA has assigned theUDP Port Number 8503 [IANA.PORTS] for use by LSP + IANA has assigned UDP Port Number 8503 [IANA.PORTS] for use by LSP Self-ping. 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. @@ -401,84 +400,96 @@ 9. Acknowledgements Thanks to Yakov Rekhter, Ravi Singh, Eric Rosen, Eric Osborne, Greg Mirsky and Nobo Akiya for their contributions to this document. 10. References 10.1. Normative References [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, - August 1980. + DOI 10.17487/RFC0768, August 1980, + . - [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September - 1981. + [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 - Requirement Levels", BCP 14, RFC 2119, March 1997. + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 - (IPv6) Specification", RFC 2460, December 1998. + (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, + December 1998, . [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP - Tunnels", RFC 3209, December 2001. + Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, + . [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed - Networks", BCP 84, RFC 3704, March 2004. + Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March + 2004, . [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, - February 2006. + DOI 10.17487/RFC4379, February 2006, + . - [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP - Specification", RFC 5036, October 2007. + [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., + "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, August 2011. + Transport Protocol Port Number Registry", BCP 165, + RFC 6335, DOI 10.17487/RFC6335, August 2011, + . 10.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", . [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration - Guidelines for DiffServ Service Classes", RFC 4594, August - 2006. + Guidelines for DiffServ Service Classes", RFC 4594, + DOI 10.17487/RFC4594, August 2006, + . [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, September 2011. + 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. Email: inaminei@google.com Michael Conn Verizon