draft-ietf-mpls-self-ping-02.txt		draft-ietf-mpls-self-ping-03.txt
	MPLS Working Group R. Torvi		MPLS Working Group R. Torvi
	Internet-Draft R. Bonica		Internet-Draft R. Bonica
	Intended status: Standards Track Juniper Networks		Intended status: Standards Track Juniper Networks
	Expires: December 17, 2015 I. Minei		Expires: March 8, 2016 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 15, 2015		September 5, 2015
	LSP Self-Ping		LSP Self-Ping
	draft-ietf-mpls-self-ping-02		draft-ietf-mpls-self-ping-03
	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 December 17, 2015.		This Internet-Draft will expire on March 8, 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 49		skipping to change at page 2, line 49
	10.1. Normative References . . . . . . . . . . . . . . . . . . 9		10.1. Normative References . . . . . . . . . . . . . . . . . . 9
	10.2. Informative References . . . . . . . . . . . . . . . . . 10		10.2. Informative References . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	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 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.
	The PATH message includes an Explicit Route Object (ERO) that		The PATH message includes an Explicit Route Object (ERO) that
	represents the path between the ingress and egress LSRs.		represents the path between the ingress and egress LSRs.
	The ingress LSR forwards the PATH message towards the egress LSR,		The ingress LSR forwards the PATH message towards the egress LSR,
	following the path defined by the ERO. Each transit LSR that		following the path defined by the ERO. Each transit LSR that
	receives the PATH message executes admission control procedures. If		receives the PATH message executes admission control procedures. If
	the transit LSR admits the LSP, it sends the PATH message downstream,		the transit LSR admits the LSP, it sends the PATH message downstream,
	skipping to change at page 3, line 39		skipping to change at page 3, line 39
	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 [RFC6383]. This optimization is desirable, because it allows		state [RFC6383]. This optimization is desirable, because it allows
	LSRs to install forwarding state in parallel, thus accelerating the		LSRs to install forwarding state in parallel, thus accelerating the
	process of LSP signaling and setup. However, this optimization		process of LSP signaling and setup. However, this optimization
	creates a race condition. When the ingress LSR receives a RESV		creates a race condition. When the ingress LSR receives a RESV
	message, some downstream LSRs may not have installed forwarding state		message, some downstream LSRs may have not yet installed forwarding
	yet. If the ingress LSR forwards traffic through the LSP before		state. If the ingress LSR forwards traffic through the LSP before
	forwarding state has been installed on all downstream nodes, traffic		forwarding state has been installed on all downstream nodes, traffic
	can be lost.		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, designed for a unique purpose. Each protocol
	executes is own unique procedures.		listens on its own UDP port and executes its 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 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
	skipping to change at page 5, line 20		skipping to change at page 5, line 20
	o An S-BFD implementation either consumes control plane resources on		o An S-BFD implementation either consumes control plane resources on
	the egress LSR or requires special support for S-BFD on the		the egress LSR or requires special support for S-BFD on the
	forwarding plane.		forwarding plane.
	By contrast, LSP Self-ping requires nothing from the egress LSR		By contrast, LSP Self-ping requires nothing from the egress LSR
	beyond the ability to forward an IP datagram.		beyond the ability to forward an IP datagram.
	LSP Self-ping's purpose is to determine whether forwarding state has		LSP Self-ping's purpose is to determine whether forwarding state has
	been installed on all downstream LSRs. Its primary constraint is to		been installed on all downstream LSRs. Its primary constraint is to
	minimize its impact on egress LSR performance. This functionality is		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.		of LSPs.
	Therefore, LSP Self-ping is applicable in the scenario described		Therefore, LSP Self-ping is applicable in the scenario described
	above, where the LSP is signaled by RSVP, RPF is not enabled, and the		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		need to conserve control plane resources on the egress LSR outweighs
	the need to determine whether downstream forwarding state is correct.		the need to determine whether downstream forwarding state is correct.
	3. The LSP Self-ping Message		3. The LSP Self-ping Message
	The LSP Self-ping Message is a User Datagram Protocol (UDP) [RFC0768]		The LSP Self-ping Message is a User Datagram Protocol (UDP) [RFC0768]
	packet. If the RSVP messages used to establish the LSP under test		packet that encapsulates a session ID. If the RSVP messages used to
	were delivered over IPv4 [RFC0791], the UDP datagram MUST be		establish the LSP under test were delivered over IPv4 [RFC0791], the
	encapsulated in an IPv4 header. If the RSVP messages used to		UDP datagram MUST be encapsulated in an IPv4 header. If the RSVP
	establish the LSP were delivered over IPv6 [RFC2460], the UDP		messages used to establish the LSP were delivered over IPv6
	datagram MUST be encapsulated in an IPv6 header.		[RFC2460], the UDP datagram MUST be encapsulated in an IPv6 header.
	In either case:		In either case:
	o The IP Source Address MAY be configurable. By default, it MUST be		o The IP Source Address MAY be configurable. By default, it MUST be
	the address of the egress LSR		the address of the egress LSR
	o The IP Destination Address MUST be the address of the ingress 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		o The IP Time to Live (TTL) / Hop Count MAY be configurable. By
	default, it MUST be 255		default, it MUST be 255
	skipping to change at page 6, line 43		skipping to change at page 6, line 43
	initial value of this variable is determined by configuration.		initial value of this variable is determined by configuration.
	o Retry Timer: The number of milliseconds that the LSR waits after		o Retry Timer: The number of milliseconds that the LSR waits after
	probing the LSP. The initial value of this variable is determined		probing the LSP. The initial value of this variable is determined
	by configuration.		by configuration.
	o Status: A boolean variable indicating the completion status of the		o Status: A boolean variable indicating the completion status of the
	LSP Self-ping session. The initial value of this variable is		LSP Self-ping session. The initial value of this variable is
	FALSE.		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.		format that is convenient to them.
	The ingress LSR executes the following procedure until Status equals		The ingress LSR executes the following procedure until Status equals
	TRUE or Retry Counter equals zero:		TRUE or Retry Counter equals zero:
	o Format a LSP Self-ping message.		o Format a LSP Self-ping message.
	o Set the Session-ID in the LSP Self-ping message to the Session-ID		o Set the Session-ID in the LSP Self-ping message to the Session-ID
	mentioned above		mentioned above
	skipping to change at page 8, line 41		skipping to change at page 8, line 41
	Ping well above the overhead of its data plane (MPLS/IP forwarding).		Ping well above the overhead of its data plane (MPLS/IP forwarding).
	These factors make LSP Ping problematic as a tool for detecting LSP		These factors make LSP Ping problematic as a tool for detecting LSP
	readiness to carry traffic when dealing with a large number of LSPs.		readiness to carry traffic when dealing with a large number of LSPs.
	By contrast, LSP Self-ping does not consume any control plane		By contrast, LSP Self-ping does not consume any control plane
	resources at the egress LSR, and relies solely on the data plane of		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		the egress LSR, making it more suitable as a tool for checking LSP
	readiness when dealing with a large number of LSPs.		readiness when dealing with a large number of LSPs.
	In another rejected approach, the ingress LSR does not verify LSP		In another rejected approach, the ingress LSR does not verify LSP
	readiness. Alternatively, it sets a timer when it receives an RSVP		readiness. Instead, it sets a timer when it receives an RSVP RESV
	RESV message and does not forward traffic through the LSP until the		message and does not forward traffic through the LSP until the timer
	timer expires. This approach was rejected because it is impossible		expires. This approach was rejected because it is impossible to
	to determine the optimal setting for this timer. If the timer value		determine the optimal setting for this timer. If the timer value is
	is set too low, it does not prevent black-holing. If the timer value		set too low, it does not prevent black-holing. If the timer value is
	is set too high, it slows down the process of LSP signalling and		set too high, it slows down the process of LSP signalling and setup.
	setup.
	Moreover, the above-mentioned timer is configured on a per-router		Moreover, the above-mentioned timer is configured on a per-router
	basis. However, its optimum value is determined by a network-wide		basis. However, its optimum value is determined by a network-wide
	behavior. Therefore, changes in the network could require changes to		behavior. Therefore, changes in the network could require changes to
	the value of the timer, making the optimal setting of this timer a		the value of the timer, making the optimal setting of this timer a
	moving target.		moving target.
	7. IANA Considerations		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.		Self-ping.
	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.
	skipping to change at page 9, line 31		skipping to change at page 9, line 29
	9. Acknowledgements		9. 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		10. References
	10.1. Normative References		10.1. Normative References
	[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,		[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
	August 1980.		DOI 10.17487/RFC0768, August 1980,
			<http://www.rfc-editor.org/info/rfc768>.
	[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September		[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
	1981.		DOI 10.17487/RFC0791, September 1981,
			<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
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119,
			DOI 10.17487/RFC2119, March 1997,
			<http://www.rfc-editor.org/info/rfc2119>.
	[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6		[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, <http://www.rfc-editor.org/info/rfc2460>.
	[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,		[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
	and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP		and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
	Tunnels", RFC 3209, December 2001.		Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
			<http://www.rfc-editor.org/info/rfc3209>.
	[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed		[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, <http://www.rfc-editor.org/info/rfc3704>.
	[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol		[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
	Label Switched (MPLS) Data Plane Failures", RFC 4379,		Label Switched (MPLS) Data Plane Failures", RFC 4379,
	February 2006.		DOI 10.17487/RFC4379, February 2006,
			<http://www.rfc-editor.org/info/rfc4379>.
	[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP		[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
	Specification", RFC 5036, October 2007.		"LDP Specification", RFC 5036, DOI 10.17487/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, RFC		Transport Protocol Port Number Registry", BCP 165,
	6335, August 2011.		RFC 6335, DOI 10.17487/RFC6335, August 2011,
			<http://www.rfc-editor.org/info/rfc6335>.
	10.2. Informative References		10.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/
	service-names-port-numbers/		service-names-port-numbers/
	service-names-port-numbers.txt>.		service-names-port-numbers.txt>.
	[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,
	2006.		DOI 10.17487/RFC4594, August 2006,
			<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, September 2011.		Using RSVP-TE", RFC 6383, DOI 10.17487/RFC6383, September
			2011, <http://www.rfc-editor.org/info/rfc6383>.
	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
	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.
	Email: inaminei@google.com		Email: inaminei@google.com
	Michael Conn		Michael Conn
	Verizon		Verizon
End of changes. 25 change blocks.
	40 lines changed or deleted		51 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/