draft-ietf-mpls-self-ping-00.txt		draft-ietf-mpls-self-ping-01.txt
	skipping to change at page 1, line 16		skipping to change at page 1, line 16
	Expires: December 7, 2015 I. Minei		Expires: December 7, 2015 I. Minei
	Google, Inc.		Google, Inc.
	M. Conn		M. Conn
	D. Pacella		D. Pacella
	L. Tomotaki		L. Tomotaki
	M. Wygant		M. Wygant
	Verizon		Verizon
	June 5, 2015		June 5, 2015
	LSP Self-Ping		LSP Self-Ping
	draft-ietf-mpls-self-ping-00		draft-ietf-mpls-self-ping-01
	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 3, line 35		skipping to change at page 3, line 35
	that has been bound to the LSP most recently. Finally, the transit		that has been bound to the LSP most recently. Finally, the transit
	LSR sends the RESV message upstream, along the reverse path of the		LSR sends the RESV message upstream, along the reverse path of the
	LSP.		LSP.
	When the ingress LSR receives the RESV message, it installs		When the ingress LSR receives the RESV message, it installs
	forwarding state. Once the ingress LSR installs forwarding state it		forwarding state. Once the ingress LSR installs forwarding state it
	can forward traffic through the LSP.		can forward traffic through the LSP.
	Some implementations optimize the above-described procedure by		Some implementations optimize the above-described procedure by
	allowing LSRs to send RESV messages before installing forwarding		allowing LSRs to send RESV messages before installing forwarding
	state. This optimization is desirable, because it allows LSRs to		state [RFC6383]. This optimization is desirable, because it allows
	install forwarding state in parallel, thus accelerating the process		LSRs to install forwarding state in parallel, thus accelerating the
	of LSP signaling and setup. However, this optimization creates a		process of LSP signaling and setup. However, this optimization
	race condition. When the ingress LSR receives a RESV message, some		creates a race condition. When the ingress LSR receives a RESV
	downstream LSRs may not have installed forwarding state yet. If the		message, some downstream LSRs may not have installed forwarding state
	ingress LSR forwards traffic through the LSP before forwarding state		yet. If the ingress LSR forwards traffic through the LSP before
	has been installed on all downstream nodes, traffic can be lost.		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		This memo describes LSP Self-ping. When an ingress LSR receives an
	RESV message, it can invoke LSP Self-ping procedures to verify that		RESV message, it can invoke LSP Self-ping procedures to verify that
	forwarding state has been installed on all downstream nodes. By		forwarding state has been installed on all downstream nodes. By
	verifying the installation of downstream forwarding state, the		verifying the installation of downstream forwarding state, the
	ingress LSR eliminates this particular cause of traffic loss.		ingress LSR eliminates this particular cause of traffic loss.
	LSP Self-ping is an extremely light-weight mechanism. It does not		LSP Self-ping is an extremely light-weight mechanism. It does not
	consume control plane resources on transit or egress LSRs.		consume control plane resources on transit or egress LSRs.
	Although LSP Ping and LSP Self-ping are named similarly, each is a		Although LSP Ping and LSP Self-ping are named similarly, each is a
	unique protocol. Each protocol listens on its own UDP port and		unique protocol. Each protocol listens on its own UDP port and
	executes is own unique procedures.		executes is own unique procedures.
	2. Applicability		2. Applicability
	LSP Self-ping is applicable in the following scenario:		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 ingress LSR receives a RESV message
	o The RESV message indicates that all downstream nodes have begun		o The RESV message indicates that all downstream nodes have begun
	the process of forwarding state installation		the process of forwarding state installation
	o The RESV message does not guarantee that all downstream nodes have		o The RESV message does not guarantee that all downstream nodes have
	completed the process of forwarding state installation		completed the process of forwarding state installation
	o The ingress LSR needs to confirm that all downstream nodes have		o The ingress LSR needs to confirm that all downstream nodes have
	completed the process for forwarding state installation		completed the process for forwarding state installation
	skipping to change at page 4, line 39		skipping to change at page 4, line 41
	o The need to conserve control plane resources on the egress LSR		o The need to conserve control plane resources on the egress LSR
	outweighs the need to determine whether downstream forwarding		outweighs the need to determine whether downstream forwarding
	state is correct		state is correct
	Unlike LSP Ping [RFC4379] and S-BFD [I-D.akiya-bfd-seamless-base],		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		LSP Self-ping is not a general purpose MPLS OAM mechanism. It cannot
	reliably determine whether downstream forwarding state is correct.		reliably determine whether downstream forwarding state is correct.
	For example, if a downstream LSR installs a forwarding state that		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		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		detect an error. In another example, if a downstream LSR erroneously
	following conditions are true:		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		o The LSP under test is signaled by the Label Distribution Protocol
	(LDP) Independent Mode [RFC5036]		(LDP) Independent Mode [RFC5036]
	o Reverse Path Forwarding (RPF) [RFC3704] filters are enabled on		o Reverse Path Forwarding (RPF) [RFC3704] filters are enabled on
	links that connect the ingress LSR to the egress LSR		links that connect the ingress LSR to the egress LSR
	While LSP Ping and S-BFD are general purpose OAM mechanisms, they are		While LSP Ping and S-BFD are general purpose OAM mechanisms, they are
	not applicable in the above described scenario because:		not applicable in the above described scenario because:
	skipping to change at page 10, line 23		skipping to change at page 10, line 26
	[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.
	[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration		[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
	Guidelines for DiffServ Service Classes", RFC 4594, August		Guidelines for DiffServ Service Classes", RFC 4594, August
	2006.		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		Authors' Addresses
	Ravi Torvi		Ravi Torvi
	Juniper Networks		Juniper Networks
	Email: rtorvi@juniper.net		Email: rtorvi@juniper.net
	Ron Bonica		Ron Bonica
	Juniper Networks		Juniper Networks
End of changes. 5 change blocks.
	10 lines changed or deleted		21 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/