--- 1/draft-ietf-mpls-self-ping-00.txt 2015-06-05 07:15:05.915601765 -0700 +++ 2/draft-ietf-mpls-self-ping-01.txt 2015-06-05 07:15:05.939602342 -0700 @@ -5,21 +5,21 @@ Expires: December 7, 2015 I. Minei Google, Inc. M. Conn D. Pacella L. Tomotaki M. Wygant Verizon June 5, 2015 LSP Self-Ping - draft-ietf-mpls-self-ping-00 + draft-ietf-mpls-self-ping-01 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. @@ -118,45 +118,48 @@ that has been bound to the LSP most recently. Finally, the transit LSR sends the RESV message upstream, along the reverse path of the LSP. 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. 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 forwarding state - has been installed on all downstream nodes, traffic can be lost. + 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 + 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. 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 the process of forwarding state installation o The RESV message does not guarantee that all downstream nodes have completed the process of forwarding state installation o The ingress LSR needs to confirm that all downstream nodes have completed the process for forwarding state installation @@ -169,22 +172,26 @@ o The need to conserve control plane resources on the egress LSR outweighs the need to determine whether downstream forwarding state is correct Unlike LSP Ping [RFC4379] and S-BFD [I-D.akiya-bfd-seamless-base], LSP Self-ping is not a general purpose MPLS OAM mechanism. It cannot reliably determine whether downstream forwarding state is correct. For example, if a downstream LSR installs a forwarding state that causes an LSP to terminate at the wrong node, LSP Self-ping will not - detect an error. Furthermore, LSP Self-ping fails when either of the - following conditions are true: + detect an error. In another example, if a downstream LSR erroneously + forwards a packet without an MPLS label, LSP Self-ping will not + detect an error. + + Furthermore, LSP Self-ping fails when either of the following + conditions are true: o The LSP under test is signaled by the Label Distribution Protocol (LDP) Independent Mode [RFC5036] o Reverse Path Forwarding (RPF) [RFC3704] filters are enabled on links that connect the ingress LSR to the egress LSR While LSP Ping and S-BFD are general purpose OAM mechanisms, they are not applicable in the above described scenario because: @@ -436,20 +445,24 @@ [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. [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, 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. + Authors' Addresses Ravi Torvi Juniper Networks Email: rtorvi@juniper.net Ron Bonica Juniper Networks