draft-ietf-bfd-base-06.txt		draft-ietf-bfd-base-07.txt
	Network Working Group D. Katz		Network Working Group D. Katz
	Internet Draft Juniper Networks		Internet Draft Juniper Networks
	D. Ward		D. Ward
	Cisco Systems		Cisco Systems
	Expires: September, 2007 March, 2007		Expires: July, 2008 January, 2008
	Bidirectional Forwarding Detection		Bidirectional Forwarding Detection
	draft-ietf-bfd-base-06.txt		draft-ietf-bfd-base-07.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 3, line 7		skipping to change at page 3, line 7
	6.8.7 Transmitting BFD Control Packets . . . . . . . . . 36		6.8.7 Transmitting BFD Control Packets . . . . . . . . . 36
	6.8.8 Reception of BFD Echo Packets . . . . . . . . . . 39		6.8.8 Reception of BFD Echo Packets . . . . . . . . . . 39
	6.8.9 Transmission of BFD Echo Packets . . . . . . . . . 39		6.8.9 Transmission of BFD Echo Packets . . . . . . . . . 39
	6.8.10 Min Rx Interval Change . . . . . . . . . . . . . 40		6.8.10 Min Rx Interval Change . . . . . . . . . . . . . 40
	6.8.11 Min Tx Interval Change . . . . . . . . . . . . . 40		6.8.11 Min Tx Interval Change . . . . . . . . . . . . . 40
	6.8.12 Detect Multiplier Change . . . . . . . . . . . . 40		6.8.12 Detect Multiplier Change . . . . . . . . . . . . 40
	6.8.13 Enabling or Disabling the Echo Function . . . . . 40		6.8.13 Enabling or Disabling the Echo Function . . . . . 40
	6.8.14 Enabling or Disabling Demand Mode . . . . . . . . 41		6.8.14 Enabling or Disabling Demand Mode . . . . . . . . 41
	6.8.15 Forwarding Plane Reset . . . . . . . . . . . . . 41		6.8.15 Forwarding Plane Reset . . . . . . . . . . . . . 41
	6.8.16 Administrative Control . . . . . . . . . . . . . 41		6.8.16 Administrative Control . . . . . . . . . . . . . 41
	6.8.17 Concatenated Paths . . . . . . . . . . . . . . . 41		6.8.17 Concatenated Paths . . . . . . . . . . . . . . . 42
	6.8.18 Holding Down Sessions . . . . . . . . . . . . . . 42		6.8.18 Holding Down Sessions . . . . . . . . . . . . . . 42
	Backward Compatibility (Non-Normative) . . . . . . . . . . . . 43		Backward Compatibility (Non-Normative) . . . . . . . . . . . . 43
	Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 43		Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 44
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44		Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44
	Security Considerations . . . . . . . . . . . . . . . . . . . . 44		Security Considerations . . . . . . . . . . . . . . . . . . . . 44
	IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 45		IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 45
	Normative References . . . . . . . . . . . . . . . . . . . . . 45		Normative References . . . . . . . . . . . . . . . . . . . . . 45
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 46		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 46
	Changes from the previous draft . . . . . . . . . . . . . . . . 46		Changes from the previous draft . . . . . . . . . . . . . . . . 46
	IPR Notice . . . . . . . . . . . . . . . . . . . . . . . . . . 47		IPR Notice . . . . . . . . . . . . . . . . . . . . . . . . . . 46
	1. Introduction		1. Introduction
	An increasingly important feature of networking equipment is the		An increasingly important feature of networking equipment is the
	rapid detection of communication failures between adjacent systems,		rapid detection of communication failures between adjacent systems,
	in order to more quickly establish alternative paths. Detection can		in order to more quickly establish alternative paths. Detection can
	come fairly quickly in certain circumstances when data link hardware		come fairly quickly in certain circumstances when data link hardware
	comes into play (such as SONET alarms.) However, there are media		comes into play (such as SONET alarms.) However, there are media
	that do not provide this kind of signaling (such as Ethernet), and		that do not provide this kind of signaling (such as Ethernet), and
	some media may not detect certain kinds of failures in the path, for		some media may not detect certain kinds of failures in the path, for
	example, failing interfaces or forwarding engine components.		example, failing interfaces or forwarding engine components.
	Networks use relatively slow "Hello" mechanisms, usually in routing		Networks use relatively slow "Hello" mechanisms, usually in routing
	protocols, to detect failures when there is no hardware signaling to		protocols, to detect failures when there is no hardware signaling to
	help out. The time to detect failures ("detection times") available		help out. The time to detect failures ("Detection Times") available
	in the existing protocols are no better than a second, which is far		in the existing protocols are no better than a second, which is far
	too long for some applications and represents a great deal of lost		too long for some applications and represents a great deal of lost
	data at gigabit rates. Furthermore, routing protocol Hellos are of		data at gigabit rates. Furthermore, routing protocol Hellos are of
	no help when those routing protocols are not in use, and the		no help when those routing protocols are not in use, and the
	semantics of detection are subtly different--they detect a failure in		semantics of detection are subtly different--they detect a failure in
	the path between the two routing protocol engines.		the path between the two routing protocol engines.
	The goal of BFD is to provide low-overhead, short-duration detection		The goal of BFD is to provide low-overhead, short-duration detection
	of failures in the path between adjacent forwarding engines,		of failures in the path between adjacent forwarding engines,
	including the interfaces, data link(s), and to the extent possible		including the interfaces, data link(s), and to the extent possible
	the forwarding engines themselves.		the forwarding engines themselves.
	An additional goal is to provide a single mechanism that can be used		An additional goal is to provide a single mechanism that can be used
	for liveness detection over any media, at any protocol layer, with a		for liveness detection over any media, at any protocol layer, with a
	wide range of detection times and overhead, to avoid a proliferation		wide range of Detection Times and overhead, to avoid a proliferation
	of different methods.		of different methods.
	This document specifies the details of the base protocol. The use of		This document specifies the details of the base protocol. The use of
	some mechanisms are application dependent and are specified in a		some mechanisms are application dependent and are specified in a
	separate series of application documents. These issues are so noted.		separate series of application documents. These issues are so noted.
	Note that many of the exact mechanisms are implementation dependent		Note that many of the exact mechanisms are implementation dependent
	and will not affect interoperability, and are thus outside the scope		and will not affect interoperability, and are thus outside the scope
	of this specification. Those issues are so noted.		of this specification. Those issues are so noted.
	skipping to change at page 6, line 26		skipping to change at page 6, line 26
	such a way as to have the other system loop them back through its		such a way as to have the other system loop them back through its
	forwarding path. If a number of packets of the echoed data stream		forwarding path. If a number of packets of the echoed data stream
	are not received, the session is declared to be down. The Echo		are not received, the session is declared to be down. The Echo
	function may be used with either Asynchronous or Demand modes. Since		function may be used with either Asynchronous or Demand modes. Since
	the Echo function is handling the task of detection, the rate of		the Echo function is handling the task of detection, the rate of
	periodic transmission of Control packets may be reduced (in the case		periodic transmission of Control packets may be reduced (in the case
	of Asynchronous mode) or eliminated completely (in the case of Demand		of Asynchronous mode) or eliminated completely (in the case of Demand
	mode.)		mode.)
	Pure asynchronous mode is advantageous in that it requires half as		Pure asynchronous mode is advantageous in that it requires half as
	many packets to achieve a particular detection time as does the Echo		many packets to achieve a particular Detection Time as does the Echo
	function. It is also used when the Echo function cannot be supported		function. It is also used when the Echo function cannot be supported
	for some reason.		for some reason.
	The Echo function has the advantage of truly testing only the		The Echo function has the advantage of truly testing only the
	forwarding path on the remote system. This may reduce round-trip		forwarding path on the remote system. This may reduce round-trip
	jitter and thus allow more aggressive detection times, as well as		jitter and thus allow more aggressive Detection Times, as well as
	potentially detecting some classes of failure that might not		potentially detecting some classes of failure that might not
	otherwise be detected.		otherwise be detected.
	The Echo function may be enabled individually in each direction. It		The Echo function may be enabled individually in each direction. It
	is enabled in a particular direction only when the system that loops		is enabled in a particular direction only when the system that loops
	the Echo packets back signals that it will allow it, and when the		the Echo packets back signals that it will allow it, and when the
	system that sends the Echo packets decides it wishes to.		system that sends the Echo packets decides it wishes to.
	Demand mode is useful in situations where the overhead of a periodic		Demand mode is useful in situations where the overhead of a periodic
	protocol might prove onerous, such as a system with a very large		protocol might prove onerous, such as a system with a very large
	number of BFD sessions. It is also useful when the Echo function is		number of BFD sessions. It is also useful when the Echo function is
	being used symmetrically. Demand mode has the disadvantage that		being used symmetrically. Demand mode has the disadvantage that
	detection times are essentially driven by the heuristics of the		Detection Times are essentially driven by the heuristics of the
	system implementation and are not known to the BFD protocol. Demand		system implementation and are not known to the BFD protocol. Demand
	mode may not be used when the path round trip time is greater than		mode may not be used when the path round trip time is greater than
	the desired detection time. See section 6.6 for more details.		the desired Detection Time. See section 6.6 for more details.
	4. BFD Control Packet Format		4. BFD Control Packet Format
	4.1. Generic BFD Control Packet Format		4.1. Generic BFD Control Packet Format
	BFD Control packets are sent in an encapsulation appropriate to the		BFD Control packets are sent in an encapsulation appropriate to the
	environment. The specific encapsulation is outside of the scope of		environment. The specific encapsulation is outside of the scope of
	this specification. See the appropriate application document for		this specification. See the appropriate application document for
	encapsulation details.		encapsulation details.
	skipping to change at page 9, line 39		skipping to change at page 9, line 39
	Demand mode is not active in the transmitting system.		Demand mode is not active in the transmitting system.
	Multipoint (M)		Multipoint (M)
	This bit is reserved for future point-to-multipoint extensions to		This bit is reserved for future point-to-multipoint extensions to
	BFD. It must be zero on both transmit and receipt.		BFD. It must be zero on both transmit and receipt.
	Detect Mult		Detect Mult
	Detection time multiplier. The negotiated transmit interval,		Detection time multiplier. The negotiated transmit interval,
	multiplied by this value, provides the detection time for the		multiplied by this value, provides the Detection Time for the
	transmitting system in Asynchronous mode.		transmitting system in Asynchronous mode.
	Length		Length
	Length of the BFD Control packet, in bytes.		Length of the BFD Control packet, in bytes.
	My Discriminator		My Discriminator
	A unique, nonzero discriminator value generated by the		A unique, nonzero discriminator value generated by the
	transmitting system, used to demultiplex multiple BFD sessions		transmitting system, used to demultiplex multiple BFD sessions
	skipping to change at page 15, line 42		skipping to change at page 15, line 42
	packets. When bidirectional communication is achieved, the BFD		packets. When bidirectional communication is achieved, the BFD
	session comes Up.		session comes Up.
	Once the BFD session is Up, a system can choose to start the Echo		Once the BFD session is Up, a system can choose to start the Echo
	function if it desires to and the other system signals that it will		function if it desires to and the other system signals that it will
	allow it. The rate of transmission of Control packets is typically		allow it. The rate of transmission of Control packets is typically
	kept low when the Echo function is active.		kept low when the Echo function is active.
	If the Echo function is not active, the transmission rate of Control		If the Echo function is not active, the transmission rate of Control
	packets may be increased to a level necessary to achieve the		packets may be increased to a level necessary to achieve the
	detection time requirements for the session.		Detection Time requirements for the session.
	Once the session is up, a system may signal that it has entered		Once the session is up, a system may signal that it has entered
	Demand mode, and the transmission of BFD Control packets by the		Demand mode, and the transmission of BFD Control packets by the
	remote system ceases. Other means of implying connectivity are used		remote system ceases. Other means of implying connectivity are used
	to keep the session alive. If either system wishes to verify		to keep the session alive. If either system wishes to verify
	bidirectional connectivity, it can initiate a short exchange of BFD		bidirectional connectivity, it can initiate a short exchange of BFD
	Control packets (a "Poll Sequence"; see section 6.5) to do so.		Control packets (a "Poll Sequence"; see section 6.5) to do so.
	If Demand mode is not active, and no Control packets are received in		If Demand mode is not active, and no Control packets are received in
	the calculated detection time (see section 6.8.4), the session is		the calculated Detection Time (see section 6.8.4), the session is
	declared Down. This is signaled to the remote end via the State		declared Down. This is signaled to the remote end via the State
	(Sta) field in outgoing packets.		(Sta) field in outgoing packets.
	If sufficient Echo packets are lost, the session is declared down in		If sufficient Echo packets are lost, the session is declared down in
	the same manner. See section 6.8.5.		the same manner. See section 6.8.5.
	If Demand mode is active and no appropriate Control packets are		If Demand mode is active and no appropriate Control packets are
	received in response to a Poll Sequence, the session is declared down		received in response to a Poll Sequence, the session is declared down
	in the same manner. See section 6.6.		in the same manner. See section 6.6.
	skipping to change at page 17, line 6		skipping to change at page 17, line 6
	A session remains in Down state until the remote system indicates		A session remains in Down state until the remote system indicates
	that it agrees that the session is down by sending a BFD Control		that it agrees that the session is down by sending a BFD Control
	packet with the State field set to anything other than Up. If that		packet with the State field set to anything other than Up. If that
	packet signals Down state, the session advances to Init state; if		packet signals Down state, the session advances to Init state; if
	that packet signals Init state, the session advances to Up state.		that packet signals Init state, the session advances to Up state.
	Semantically, Down state indicates that the forwarding path is		Semantically, Down state indicates that the forwarding path is
	unavailable, and that appropriate actions should be taken by the		unavailable, and that appropriate actions should be taken by the
	applications monitoring the state of the BFD session. A system MAY		applications monitoring the state of the BFD session. A system MAY
	hold a session in Down state indefinitely (by simply refusing to		hold a session in Down state indefinitely (by simply refusing to
	advance the session state.) This may be done for operational or		advance the session state.) This may be done for operational or
	adminstrative reasons, among others.		administrative reasons, among others.
	Init state means that the remote system is communicating, and the		Init state means that the remote system is communicating, and the
	local system desires to bring the session up, but the remote system		local system desires to bring the session up, but the remote system
	does not yet realize it. A session will remain in Init state until		does not yet realize it. A session will remain in Init state until
	either a BFD Control Packet is received that is signaling Init or Up		either a BFD Control Packet is received that is signaling Init or Up
	state (in which case the session advances to Up state) or until the		state (in which case the session advances to Up state) or until the
	detection time expires, meaning that communication with the remote		Detection Time expires, meaning that communication with the remote
	system has been lost (in which case the session advances to Down		system has been lost (in which case the session advances to Down
	state.)		state.)
	Up state means that the BFD session has successfully been		Up state means that the BFD session has successfully been
	established, and implies that connectivity between the systems is		established, and implies that connectivity between the systems is
	working. The session will remain in the Up state until either		working. The session will remain in the Up state until either
	connectivity fails, or the session is taken down administratively.		connectivity fails, or the session is taken down administratively.
	If either the remote system signals Down state, or the detection time		If either the remote system signals Down state, or the Detection Time
	expires, the session advances to Down state.		expires, the session advances to Down state.
	AdminDown state means that the session is being held administratively		AdminDown state means that the session is being held administratively
	down. This causes the remote system to enter Down state, and remain		down. This causes the remote system to enter Down state, and remain
	there until the local system exits AdminDown state. AdminDown state		there until the local system exits AdminDown state. AdminDown state
	has no semantic implications for the availability of the forwarding		has no semantic implications for the availability of the forwarding
	path.		path.
	The following diagram provides an overview of the state machine.		The following diagram provides an overview of the state machine.
	Transitions involving AdminDown state are deleted for clarity (but		Transitions involving AdminDown state are deleted for clarity (but
	are fully specified in section 6.8.6.) The notation on each arc		are fully specified in sections 6.8.6 and 6.8.16.) The notation on
	represents the state of the remote system (as received in the State		each arc represents the state of the remote system (as received in
	field in the BFD Control packet) or indicates the expiration of the		the State field in the BFD Control packet) or indicates the
	Detection Timer.		expiration of the Detection Timer.
	+--+		+--+
	| | UP, ADMIN DOWN, TIMER		| | UP, ADMIN DOWN, TIMER
	| V		| V
	DOWN +------+ INIT		DOWN +------+ INIT
	+------------| |------------+		+------------| |------------+
	| | DOWN | |		| | DOWN | |
	| +-------->| |<--------+ |		| +-------->| |<--------+ |
	| | +------+ | |		| | +------+ | |
	| | | |		| | | |
	skipping to change at page 19, line 21		skipping to change at page 19, line 21
	packets is not directly signaled to the system looping them back.		packets is not directly signaled to the system looping them back.
	When a system is using the Echo function, it is advantageous to		When a system is using the Echo function, it is advantageous to
	choose a sedate reception rate for Control packets, since liveness		choose a sedate reception rate for Control packets, since liveness
	detection is being handled by the Echo packets. This can be		detection is being handled by the Echo packets. This can be
	controlled by manipulating the Required Min RX Interval field (see		controlled by manipulating the Required Min RX Interval field (see
	section 6.8.3.)		section 6.8.3.)
	If the Echo function is only being run in one direction, the system		If the Echo function is only being run in one direction, the system
	not running the Echo function will more likely wish to receive fairly		not running the Echo function will more likely wish to receive fairly
	rapid Control packets in order to achieve its desired detection time.		rapid Control packets in order to achieve its desired Detection Time.
	Since BFD allows independent transmission rates in each direction,		Since BFD allows independent transmission rates in each direction,
	this is easily accomplished.		this is easily accomplished.
	A system SHOULD otherwise advertise the lowest value of Required Min		A system SHOULD otherwise advertise the lowest value of Required Min
	RX Interval and Required Min Echo RX Interval that it can under the		RX Interval and Required Min Echo RX Interval that it can under the
	circumstances, to give the other system more freedom in choosing its		circumstances, to give the other system more freedom in choosing its
	transmission rate. Note that a system is committing to be able to		transmission rate. Note that a system is committing to be able to
	receive both streams of packets at the rate it advertises, so this		receive both streams of packets at the rate it advertises, so this
	should be taken into account when choosing the values to advertise.		should be taken into account when choosing the values to advertise.
	skipping to change at page 20, line 36		skipping to change at page 20, line 36
	Demand mode requires that some other mechanism is used to imply		Demand mode requires that some other mechanism is used to imply
	continuing connectivity between the two systems. The mechanism used		continuing connectivity between the two systems. The mechanism used
	does not have to be the same in both directions, and is outside of		does not have to be the same in both directions, and is outside of
	the scope of this specification. One possible mechanism is the		the scope of this specification. One possible mechanism is the
	receipt of traffic from the remote system; another is the use of the		receipt of traffic from the remote system; another is the use of the
	Echo function.		Echo function.
	When a system in Demand mode wishes to verify bidirectional		When a system in Demand mode wishes to verify bidirectional
	connectivity, it initiates a Poll Sequence (see section 6.5). If no		connectivity, it initiates a Poll Sequence (see section 6.5). If no
	response is received to a Poll, the Poll is repeated until the		response is received to a Poll, the Poll is repeated until the
	detection time expires, at which point the session is declared to be		Detection Time expires, at which point the session is declared to be
	down. Note that if Demand mode is operating only on the remote		down. Note that if Demand mode is operating only on the local
	system, the Poll Sequence is performed on the local system by simply		system, the Poll Sequence is performed by simply setting the Poll (P)
	setting the Poll (P) bit in regular periodic BFD Control packets.		bit in regular periodic BFD Control packets, as required by section
			6.6.
	The detection time in Demand mode is calculated differently than in		The Detection Time in Demand mode is calculated differently than in
	Asynchronous mode; it is based on the transmit rate of the local		Asynchronous mode; it is based on the transmit rate of the local
	system, rather than the transmit rate of the remote system. This		system, rather than the transmit rate of the remote system. This
	ensures that the Poll Sequence mechanism works properly. See section		ensures that the Poll Sequence mechanism works properly. See section
	6.8.4 for more details.		6.8.4 for more details.
	Note that this mechanism requires that the detection time negotiated		Note that this mechanism requires that the Detection Time negotiated
	is greater than the round trip time between the two systems, or the		is greater than the round trip time between the two systems, or the
	Poll mechanism will always fail. Enforcement of this requirement is		Poll mechanism will always fail. Enforcement of this requirement is
	outside the scope of this specification.		outside the scope of this specification.
	Demand mode MAY be enabled or disabled at any time, independently in		Demand mode MAY be enabled or disabled at any time, independently in
	each direction, by setting or clearing the Demand (D) bit in the BFD		each direction, by setting or clearing the Demand (D) bit in the BFD
	Control packet, without affecting the BFD session state. Note that		Control packet, without affecting the BFD session state. Note that
	the Demand bit MUST NOT be set unless both systems perceive the		the Demand bit MUST NOT be set unless both systems perceive the
	session to be Up (the local system thinks the session is Up, and the		session to be Up (the local system thinks the session is Up, and the
	remote system last reported Up state in the State (Sta) field of the		remote system last reported Up state in the State (Sta) field of the
	skipping to change at page 21, line 26		skipping to change at page 21, line 27
	of the change.		of the change.
	If Demand mode is active on either or both systems, a Poll Sequence		If Demand mode is active on either or both systems, a Poll Sequence
	MUST be initiated whenever the contents of the next BFD Control		MUST be initiated whenever the contents of the next BFD Control
	packet to be sent would be different than the contents of the		packet to be sent would be different than the contents of the
	previous packet, with the exception of the Poll (P) and Final (F)		previous packet, with the exception of the Poll (P) and Final (F)
	bits. This ensures that parameter changes are transmitted to the		bits. This ensures that parameter changes are transmitted to the
	remote system and that the remote system acknowledges these changes.		remote system and that the remote system acknowledges these changes.
	Because the underlying detection mechanism is unspecified, and may		Because the underlying detection mechanism is unspecified, and may
	differ between the two systems, the overall detection time		differ between the two systems, the overall Detection Time
	characteristics of the path will not be fully known to either system.		characteristics of the path will not be fully known to either system.
	The total detection time for a particular system is the sum of the		The total Detection Time for a particular system is the sum of the
	time prior to the initiation of the Poll Sequence, plus the		time prior to the initiation of the Poll Sequence, plus the
	calculated detection time.		calculated Detection Time.
	Note that if Demand mode is enabled in only one direction, continuous		Note that if Demand mode is enabled in only one direction, continuous
	bidirectional connectivity verification is lost (only connectivity in		bidirectional connectivity verification is lost (only connectivity in
	the direction from the system in Demand mode to the other system will		the direction from the system in Demand mode to the other system will
	be verified.) Resolving the issue of one system requesting Demand		be verified.) Resolving the issue of one system requesting Demand
	mode while the other requires continuous bidirectional connectivity		mode while the other requires continuous bidirectional connectivity
	verification is outside the scope of this specification.		verification is outside the scope of this specification.
	6.7. Authentication		6.7. Authentication
	skipping to change at page 22, line 23		skipping to change at page 22, line 24
	6.7.1. Enabling and Disabling Authentication		6.7.1. Enabling and Disabling Authentication
	It may be desirable to enable or disable authentication on a session		It may be desirable to enable or disable authentication on a session
	without disturbing the session state. The exact mechanism for doing		without disturbing the session state. The exact mechanism for doing
	so is outside the scope of this specification. However, it is useful		so is outside the scope of this specification. However, it is useful
	to point out some issues in supporting this mechanism.		to point out some issues in supporting this mechanism.
	In a simple implementation, a BFD session will fail when		In a simple implementation, a BFD session will fail when
	authentication is either turned on or turned off, because the packet		authentication is either turned on or turned off, because the packet
	acceptance rules essentially require the local and remote machines to		acceptance rules essentially require the local and remote machines to
	do so in a more or less synchronized fashion (within the detection		do so in a more or less synchronized fashion (within the Detection
	time)--a packet with authentication will only be accepted if		Time)--a packet with authentication will only be accepted if
	authentication is "in use" (and likewise packets without		authentication is "in use" (and likewise packets without
	authentication.		authentication.
	One possible approach is to build an implementation such that		One possible approach is to build an implementation such that
	authentication is configured, but not considered "in use" until the		authentication is configured, but not considered "in use" until the
	first packet containing a matching authentication section is received		first packet containing a matching authentication section is received
	(providing the necessary synchronization.) Likewise, authentication		(providing the necessary synchronization.) Likewise, authentication
	could be configured off, but still considered "in use" until the		could be configured off, but still considered "in use" until the
	receipt of the first packet without the authentication section.		receipt of the first packet without the authentication section.
	skipping to change at page 28, line 35		skipping to change at page 28, line 35
	identify it. It MUST be unique across all BFD sessions on this		identify it. It MUST be unique across all BFD sessions on this
	system, and nonzero. It SHOULD be set to a random (but still		system, and nonzero. It SHOULD be set to a random (but still
	unique) value to improve security. The value is otherwise		unique) value to improve security. The value is otherwise
	outside the scope of this specification.		outside the scope of this specification.
	bfd.RemoteDiscr		bfd.RemoteDiscr
	The remote discriminator for this BFD session. This is the		The remote discriminator for this BFD session. This is the
	discriminator chosen by the remote system, and is totally		discriminator chosen by the remote system, and is totally
	opaque to the local system. This MUST be initialized to zero.		opaque to the local system. This MUST be initialized to zero.
			If a period of a Detection Time passes without the receipt of a
			valid, authenticated BFD packet from the remote system, this
			variable MUST be set to zero.
	bfd.LocalDiag		bfd.LocalDiag
	The diagnostic code specifying the reason for the most recent		The diagnostic code specifying the reason for the most recent
	local session state change to states Down or AdminDown. This		local session state change to states Down or AdminDown. This
	MUST be initialized to zero (No Diagnostic.)		MUST be initialized to zero (No Diagnostic.)
	bfd.DesiredMinTxInterval		bfd.DesiredMinTxInterval
	The minimum interval, in microseconds, between transmitted BFD		The minimum interval, in microseconds, between transmitted BFD
	Control packets that this system would like to use at the		Control packets that this system would like to use at the
	current time. The actual interval is negotiated between the		current time. The actual interval is negotiated between the
	two systems. This MUST be initialized to a value of at least		two systems. This MUST be initialized to a value of at least
	one second (1,000,000 microseconds) according to the rules		one second (1,000,000 microseconds) according to the rules
	described in section 6.8.3. The setting of this variable is		described in section 6.8.3. The setting of this variable is
	otherwise outside the scope of this specification.		otherwise outside the scope of this specification.
	skipping to change at page 29, line 38		skipping to change at page 29, line 42
	bfd.RemoteDemandMode		bfd.RemoteDemandMode
	Set to 1 if the remote system wishes to use Demand mode, or 0		Set to 1 if the remote system wishes to use Demand mode, or 0
	if not. This is the value of the Demand (D) bit in the last		if not. This is the value of the Demand (D) bit in the last
	received BFD Control packet. This variable MUST be initialized		received BFD Control packet. This variable MUST be initialized
	to zero.		to zero.
	bfd.DetectMult		bfd.DetectMult
	The desired detection time multiplier for BFD Control packets.		The desired Detection Time multiplier for BFD Control packets.
	The negotiated Control packet transmission interval, multiplied		The negotiated Control packet transmission interval, multiplied
	by this variable, will be the detection time for this session		by this variable, will be the Detection Time for this session
	(as seen by the remote system.) This variable MUST be a		(as seen by the remote system.) This variable MUST be a
	nonzero integer, and is otherwise outside the scope of this		nonzero integer, and is otherwise outside the scope of this
	specification. See section 6.8.4 for further information.		specification. See section 6.8.4 for further information.
	bfd.AuthType		bfd.AuthType
	The authentication type in use for this session, as defined in		The authentication type in use for this session, as defined in
	section 4.1, or zero if no authentication is in use.		section 4.1, or zero if no authentication is in use.
	bfd.RcvAuthSeq		bfd.RcvAuthSeq
	skipping to change at page 30, line 36		skipping to change at page 30, line 38
	not known. This variable MUST be initialized to zero.		not known. This variable MUST be initialized to zero.
	This variable MUST be set to zero after no packets have been		This variable MUST be set to zero after no packets have been
	received on this session for at least twice the Detection Time.		received on this session for at least twice the Detection Time.
	This ensures that the sequence number can be resynchronized if		This ensures that the sequence number can be resynchronized if
	the remote system restarts.		the remote system restarts.
	6.8.2. Timer Negotiation		6.8.2. Timer Negotiation
	The time values used to determine BFD packet transmission intervals		The time values used to determine BFD packet transmission intervals
	and the session detection time are continuously negotiated, and thus		and the session Detection Time are continuously negotiated, and thus
	may be changed at any time. The negotiation and time values are		may be changed at any time. The negotiation and time values are
	independent in each direction for each session.		independent in each direction for each session.
	Each system reports in the BFD Control packet how rapidly it would		Each system reports in the BFD Control packet how rapidly it would
	like to transmit BFD packets, as well as how rapidly it is prepared		like to transmit BFD packets, as well as how rapidly it is prepared
	to receive them. With the exceptions listed in the remainder of this		to receive them. With the exceptions listed in the remainder of this
	section, a system MUST NOT transmit BFD Control packets at an		section, a system MUST NOT transmit BFD Control packets at an
	interval less than the larger of bfd.DesiredMinTxInterval and		interval less than the larger of bfd.DesiredMinTxInterval and
	bfd.RemoteMinRxInterval. In other words, the system reporting the		bfd.RemoteMinRxInterval. In other words, the system reporting the
	slower rate determines the transmission rate.		slower rate determines the transmission rate.
	skipping to change at page 31, line 19		skipping to change at page 31, line 23
	If bfd.DetectMult is equal to 1, the interval between transmitted BFD		If bfd.DetectMult is equal to 1, the interval between transmitted BFD
	Control packets MUST be no more than 90% of the negotiated		Control packets MUST be no more than 90% of the negotiated
	transmission interval, and MUST be no less than 75% of the negotiated		transmission interval, and MUST be no less than 75% of the negotiated
	transmission interval. This is to ensure that, on the remote system,		transmission interval. This is to ensure that, on the remote system,
	the calculated DetectTime does not pass prior to the receipt of the		the calculated DetectTime does not pass prior to the receipt of the
	next BFD Control packet.		next BFD Control packet.
	6.8.3. Timer Manipulation		6.8.3. Timer Manipulation
	The time values used to determine BFD packet transmission intervals		The time values used to determine BFD packet transmission intervals
	and the session detection time may be modified at any time without		and the session Detection Time may be modified at any time without
	affecting the state of the session. When the timer parameters are		affecting the state of the session. When the timer parameters are
	changed for any reason, the requirements of this section apply.		changed for any reason, the requirements of this section apply.
	If either bfd.DesiredMinTxInterval is changed or		If either bfd.DesiredMinTxInterval is changed or
	bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST be		bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST be
	initiated (see section 6.5). If the timing is such that a system		initiated (see section 6.5). If the timing is such that a system
	receiving a Poll Sequence wishes to change the parameters described		receiving a Poll Sequence wishes to change the parameters described
	in this paragraph, the new parameter values may be carried in packets		in this paragraph, the new parameter values may be carried in packets
	with the Final (F) bit set, even if the Poll Sequence has not yet		with the Final (F) bit set, even if the Poll Sequence has not yet
	been sent.		been sent.
	If bfd.DesiredMinTxInterval is increased and bfd.SessionState is Up,		If bfd.DesiredMinTxInterval is increased and bfd.SessionState is Up,
	the actual transmission interval used MUST NOT change until the Poll		the actual transmission interval used MUST NOT change until the Poll
	Sequence described above has terminated. This is to ensure that the		Sequence described above has terminated. This is to ensure that the
	remote system updates its Detection Time before the transmission		remote system updates its Detection Time before the transmission
	interval increases.		interval increases.
	If bfd.RequiredMinRxInterval is reduced and bfd.SessionState is Up,		If bfd.RequiredMinRxInterval is reduced and bfd.SessionState is Up,
	the previous value of bfd.RequiredMinRxInterval MUST be used when		the previous value of bfd.RequiredMinRxInterval MUST be used when
	calculating the detection time for the remote system until the Poll		calculating the Detection Time for the remote system until the Poll
	Sequence described above has terminated. This is to ensure that the		Sequence described above has terminated. This is to ensure that the
	remote system is transmitting packets at the higher rate (and those		remote system is transmitting packets at the higher rate (and those
	packets are being received) prior to the detection time being		packets are being received) prior to the Detection Time being
	reduced.		reduced.
	When bfd.SessionState is not Up, the system MUST set		When bfd.SessionState is not Up, the system MUST set
	bfd.DesiredMinTxInterval to a value of not less than one second		bfd.DesiredMinTxInterval to a value of not less than one second
	(1,000,000 microseconds.) This is intended to ensure that the		(1,000,000 microseconds.) This is intended to ensure that the
	bandwidth consumed by BFD sessions that are not Up is negligible,		bandwidth consumed by BFD sessions that are not Up is negligible,
	particularly in the case where a neighbor may not be running BFD.		particularly in the case where a neighbor may not be running BFD.
	If the local system reduces its transmit interval due to		If the local system reduces its transmit interval due to
	bfd.RemoteMinRxInterval being reduced (the remote system has		bfd.RemoteMinRxInterval being reduced (the remote system has
	skipping to change at page 32, line 24		skipping to change at page 32, line 27
	BFD Control packet as soon as practicable.		BFD Control packet as soon as practicable.
	When the Echo function is active, a system SHOULD set		When the Echo function is active, a system SHOULD set
	bfd.RequiredMinRxInterval to a value of not less than one second		bfd.RequiredMinRxInterval to a value of not less than one second
	(1,000,000 microseconds.) This is intended to keep received BFD		(1,000,000 microseconds.) This is intended to keep received BFD
	Control traffic at a negligible level, since the actual detection		Control traffic at a negligible level, since the actual detection
	function is being performed using BFD Echo packets.		function is being performed using BFD Echo packets.
	In any case other than those explicitly called out above, timing		In any case other than those explicitly called out above, timing
	parameter changes MUST be effected immediately (changing the		parameter changes MUST be effected immediately (changing the
	transmission rate and/or the Detection Time), and a Poll Sequence		transmission rate and/or the Detection Time).
	SHOULD NOT be sent.
	Note that the Poll Sequence mechanism is ambiguous if more than one		Note that the Poll Sequence mechanism is ambiguous if more than one
	parameter change is made that would require its use, and those		parameter change is made that would require its use, and those
	multiple changes are spread across multiple packets (since the		multiple changes are spread across multiple packets (since the
	semantics of the returning Final are unclear.) Therefore, if		semantics of the returning Final are unclear.) Therefore, if
	multiple changes are made that require the use of a Poll Sequence,		multiple changes are made that require the use of a Poll Sequence,
	there are three choices: 1) they MUST be communicated in a single		there are three choices: 1) they MUST be communicated in a single
	BFD Control packet (so the semantics of the Final reply are clear),		BFD Control packet (so the semantics of the Final reply are clear),
	or 2) sufficient time must have transpired since the Poll Sequence		or 2) sufficient time must have transpired since the Poll Sequence
	was completed to disambiguate the situation (at least a round trip		was completed to disambiguate the situation (at least a round trip
	skipping to change at page 32, line 49		skipping to change at page 32, line 51
	has completed prior to the initiation of another Poll Sequence (this		has completed prior to the initiation of another Poll Sequence (this
	option is not available when Demand mode is active.)		option is not available when Demand mode is active.)
	6.8.4. Calculating the Detection Time		6.8.4. Calculating the Detection Time
	The Detection Time (the period of time without receiving BFD packets		The Detection Time (the period of time without receiving BFD packets
	after which the session is determined to have failed) is not carried		after which the session is determined to have failed) is not carried
	explicitly in the protocol. Rather, it is calculated independently		explicitly in the protocol. Rather, it is calculated independently
	in each direction by the receiving system based on the negotiated		in each direction by the receiving system based on the negotiated
	transmit interval and the detection multiplier. Note that there may		transmit interval and the detection multiplier. Note that there may
	be different detection times in each direction.		be different Detection Times in each direction.
	The calculation of the Detection Time is slightly different when in		The calculation of the Detection Time is slightly different when in
	Demand mode versus Asynchronous mode.		Demand mode versus Asynchronous mode.
	In Asynchronous mode, the Detection Time calculated in the local		In Asynchronous mode, the Detection Time calculated in the local
	system is equal to the value of Detect Mult received from the remote		system is equal to the value of Detect Mult received from the remote
	system, multiplied by the agreed transmit interval of the remote		system, multiplied by the agreed transmit interval of the remote
	system (the greater of bfd.RequiredMinRxInterval and the last		system (the greater of bfd.RequiredMinRxInterval and the last
	received Desired Min TX Interval.) The Detect Mult value is (roughly		received Desired Min TX Interval.) The Detect Mult value is (roughly
	speaking, due to jitter) the number of packets that have to be missed		speaking, due to jitter) the number of packets that have to be missed
	skipping to change at page 36, line 4		skipping to change at page 36, line 4
	Set bfd.SessionState to Up		Set bfd.SessionState to Up
	Else if bfd.SessionState is Init		Else if bfd.SessionState is Init
	If received State is Init or Up		If received State is Init or Up
	Set bfd.SessionState to Up		Set bfd.SessionState to Up
	Else (bfd.SessionState is Up)		Else (bfd.SessionState is Up)
	If received State is Down		If received State is Down
	Set bfd.LocalDiag to 3 (Neighbor signaled session down)		Set bfd.LocalDiag to 3 (Neighbor signaled session down)
	Set bfd.SessionState to Down		Set bfd.SessionState to Down
	Check to see if Demand mode should become active or not		Check to see if Demand mode should become active or not (see
	(see section 6.6).		section 6.6).
	If bfd.RemoteDemandMode is 1, bfd.SessionState is Up, and		If bfd.RemoteDemandMode is 1, bfd.SessionState is Up, and
	bfd.RemoteSessionState is Up, Demand mode is active on the		bfd.RemoteSessionState is Up, Demand mode is active on the remote
	remote system and the local system MUST cease the periodic		system and the local system MUST cease the periodic transmission
	transmission of BFD Control packets (see section 6.8.7.)		of BFD Control packets (see section 6.8.7.)
	If bfd.RemoteDemandMode is 0, or bfd.SessionState is not Up, or		If bfd.RemoteDemandMode is 0, or bfd.SessionState is not Up, or
	bfd.RemoteSessionState is not Up, Demand mode is not active on the		bfd.RemoteSessionState is not Up, Demand mode is not active on the
	remote system and the local system MUST send periodic BFD Control		remote system and the local system MUST send periodic BFD Control
	packets (see section 6.8.7.)		packets (see section 6.8.7.)
	If the Poll (P) bit is set, send a BFD Control packet to the		If the Poll (P) bit is set, send a BFD Control packet to the
	remote system with the Poll (P) bit clear, and the Final (F) bit		remote system with the Poll (P) bit clear, and the Final (F) bit
	set (see section 6.8.7.)		set (see section 6.8.7.)
	skipping to change at page 41, line 37		skipping to change at page 41, line 37
	procedure MUST be followed:		procedure MUST be followed:
	If enabling session		If enabling session
	Set bfd.SessionState to Down		Set bfd.SessionState to Down
	Else		Else
	Set bfd.SessionState to AdminDown		Set bfd.SessionState to AdminDown
	Set bfd.LocalDiag to an appropriate value		Set bfd.LocalDiag to an appropriate value
	Cease the transmission of BFD Echo packets		Cease the transmission of BFD Echo packets
	If signaling is received from outside BFD that the underlying		If signaling is received from outside BFD that the underlying path
	path has failed, an implementation MAY administratively disable		has failed, an implementation MAY administratively disable the
	the session with the diagnostic Path Down.		session with the diagnostic Path Down.
	Other scenarios MAY use the diagnostic Administratively Down.		Other scenarios MAY use the diagnostic Administratively Down.
			BFD Control packets SHOULD be transmitted for at least a Detection
			Time after transitioning to AdminDown state in order to ensure that
			the remote system is aware of the state change. BFD Control packets
			MAY be transmitted indefinitely after transitioning to AdminDown
			state in order to maintain session state in each system (see section
			6.8.18 below.)
	6.8.17. Concatenated Paths		6.8.17. Concatenated Paths
	If the path being monitored by BFD is concatenated with other paths,		If the path being monitored by BFD is concatenated with other paths,
	it may be desirable to propagate the indication of a failure of one		it may be desirable to propagate the indication of a failure of one
	of those paths across the BFD session (providing an interworking		of those paths across the BFD session (providing an interworking
	function for liveness monitoring between BFD and other technologies.)		function for liveness monitoring between BFD and other technologies.)
	Two diagnostic codes are defined for this purpose: Concatenated Path		Two diagnostic codes are defined for this purpose: Concatenated Path
	Down and Reverse Concatenated Path Down. The first propagates		Down and Reverse Concatenated Path Down. The first propagates
	forward path failures (in which the concatenated path fails in the		forward path failures (in which the concatenated path fails in the
	direction toward the interworking system), and the second propagates		direction toward the interworking system), and the second propagates
	reverse path failures (in which the concatenated path fails in the		reverse path failures (in which the concatenated path fails in the
	direction away from the interworking system, assuming a bidirectional		direction away from the interworking system, assuming a bidirectional
	link.)		link.)
	A system MAY signal one of these failure states by simply setting		A system MAY signal one of these failure states by simply setting
	bfd.LocalDiag to the appropriate diagnostic code. Note that the BFD		bfd.LocalDiag to the appropriate diagnostic code. Note that the BFD
	skipping to change at page 43, line 15		skipping to change at page 43, line 22
	Backward Compatibility (Non-Normative)		Backward Compatibility (Non-Normative)
	Although Version 0 of this document is unlikely to have been deployed		Although Version 0 of this document is unlikely to have been deployed
	widely, some implementors may wish to have a backward compatibility		widely, some implementors may wish to have a backward compatibility
	mechanism. Note that any mechanism may be potentially used that does		mechanism. Note that any mechanism may be potentially used that does
	not alter the protocol definition, so interoperability should not be		not alter the protocol definition, so interoperability should not be
	an issue.		an issue.
	The suggested mechanism described here has the property that it will		The suggested mechanism described here has the property that it will
	converge on version 1 if both systems implement it, even if one		converge on version 1 if both systems implement it, even if one
	system is upgraded from version 0 within a detection time. It will		system is upgraded from version 0 within a Detection Time. It will
	interoperate with a system that implements only one version (or is		interoperate with a system that implements only one version (or is
	configured to support only one version.) A system should obviously		configured to support only one version.) A system should obviously
	not perform this function if it is configured to or is only capable		not perform this function if it is configured to or is only capable
	of using a single version.		of using a single version.
	A BFD session will enter a "negotiation holddown" if it is configured		A BFD session will enter a "negotiation holddown" if it is configured
	for automatic versioning and either has just started up, or the		for automatic versioning and either has just started up, or the
	session has been manually cleared. The session is set to AdminDown		session has been manually cleared. The session is set to AdminDown
	state and Version 1. During the holddown period, which lasts for one		state and Version 1. During the holddown period, which lasts for one
	detection time, the system sends BFD Control packets as usual, but		Detection Time, the system sends BFD Control packets as usual, but
	ignores received packets. After the holddown time is complete, the		ignores received packets. After the holddown time is complete, the
	state transitions to Down and normal operation resumes.		state transitions to Down and normal operation resumes.
	When a system is not in holddown, if it doing automatic versioning		When a system is not in holddown, if it doing automatic versioning
	and is currently using Version 1, if any Version 0 packet is received		and is currently using Version 1, if any Version 0 packet is received
	for the session, it switches immediately to Version 0. If it is		for the session, it switches immediately to Version 0. If it is
	currently using Version 0 and a Version 1 packet is received that		currently using Version 0 and a Version 1 packet is received that
	indicates that the neighbor is in state AdminDown, it switches to		indicates that the neighbor is in state AdminDown, it switches to
	Version 1. If using Version 0 and a Version 1 packet is received		Version 1. If using Version 0 and a Version 1 packet is received
	indicating a state other than AdminDown, the packet is ignored (per		indicating a state other than AdminDown, the packet is ignored (per
	skipping to change at page 44, line 17		skipping to change at page 44, line 22
	This document was inspired by (and is intended to replace) the		This document was inspired by (and is intended to replace) the
	Protocol Liveness Protocol draft, written by Kireeti Kompella.		Protocol Liveness Protocol draft, written by Kireeti Kompella.
	Demand mode was inspired by draft-ietf-ipsec-dpd-03.txt, by G. Huang		Demand mode was inspired by draft-ietf-ipsec-dpd-03.txt, by G. Huang
	et al.		et al.
	The authors would also like to thank Mike Shand, John Scudder,		The authors would also like to thank Mike Shand, John Scudder,
	Stewart Bryant, Pekka Savola, and Richard Spencer for their		Stewart Bryant, Pekka Savola, and Richard Spencer for their
	substantive input.		substantive input.
			The authors would also like to thank Owen Wheeler for hosting
			teleconferences between the authors of this specification and
			multiple vendors in order address implementation and clarity issues.
	Security Considerations		Security Considerations
	As BFD may be tied into the stability of the network infrastructure		As BFD may be tied into the stability of the network infrastructure
	(such as routing protocols), the effects of an attack on a BFD		(such as routing protocols), the effects of an attack on a BFD
	session may be very serious. This ultimately has denial-of-service		session may be very serious. This ultimately has denial-of-service
	effects, as links may be declared to be down (or falsely declared to		effects, as links may be declared to be down (or falsely declared to
	be up.)		be up.)
	When BFD is run over network layer protocols, a significant denial-		When BFD is run over network layer protocols, a significant denial-
	of-service risk is created, as BFD packets may be trivial to spoof.		of-service risk is created, as BFD packets may be trivial to spoof.
	skipping to change at page 45, line 30		skipping to change at page 45, line 41
	Discriminator may be changed at any time during a session, this		Discriminator may be changed at any time during a session, this
	mechanism may also help mitigate attacks.		mechanism may also help mitigate attacks.
	IANA Considerations		IANA Considerations
	This document has no actions for IANA.		This document has no actions for IANA.
	Normative References		Normative References
	[GTSM] Gill, V., et al, "The Generalized TTL Security Mechanism		[GTSM] Gill, V., et al, "The Generalized TTL Security Mechanism
	(GTSM)", RFC 3682, February 2004.		(GTSM)", RFC 5082, October 2007.
	[KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate		[KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", RFC 2119, March 1997.		Requirement Levels", RFC 2119, March 1997.
	[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April		[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
	1992.		1992.
	[OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998.		[OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
	[SHA1] "Secure Hash Standard", United States of America, National		[SHA1] "Secure Hash Standard", United States of America, National
	skipping to change at page 46, line 23		skipping to change at page 46, line 29
	Dave Ward		Dave Ward
	Cisco Systems		Cisco Systems
	170 W. Tasman Dr.		170 W. Tasman Dr.
	San Jose, CA 95134 USA		San Jose, CA 95134 USA
	Phone: +1-408-526-4000		Phone: +1-408-526-4000
	Email: dward@cisco.com		Email: dward@cisco.com
	Changes from the Previous Draft		Changes from the Previous Draft
	The most significant technical change in this draft is a rework of		A correction was made to the description of Demand mode in section
	Demand Mode, based on bugs turned up by implementation experience.		6.6. Another correction was made to the interaction between timing
	Additionally, Demand Mode can now be enabled independently in each		changes and the transmission of a Poll Sequence in section 6.8.3.
	direction.		The requirement to clear bfd.RemoteDiscr when the remote system falls
			silent was added to section 6.8.1. The continuing transmission of
	Text was added requiring that an implementation maintain session		Control packets in AdminDown state was added to section 6.8.16. All
	state for a detection time after the session goes down, to ensure		other changes are purely editorial in nature.
	that the remote end can still control the transmit rate of the local
	system even when the session isn't up. In conjunction with this, the
	semantics of Required Min RX Interval so that a value of zero informs
	the remote system that it cannot send any periodic BFD Control
	packets.
	Additional state variables were added to support Demand mode, and to
	simplify the text elsewhere.
	Text describing how to disambiguate multiple Poll Sequences in the
	face of multiple parameter changes was added.
	The pseudocode describing packet reception was reordered slightly.
	Text regarding the semantics of Down and AdminDown state was added.
	Many editorial changes were made. The most significant is to unify
	the concept of a Poll Sequence (so that it is independent of Demand
	Mode.) Explanatory text was added in a number of places based on
	feedback from implementors.
	IPR Notice		IPR Notice
	The IETF has been notified of intellectual property rights claimed in		The IETF has been notified of intellectual property rights claimed in
	regard to some or all of the specification contained in this		regard to some or all of the specification contained in this
	document. For more information consult the online list of claimed		document. For more information consult the online list of claimed
	rights.		rights.
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	skipping to change at page 47, line 36		skipping to change at page 47, line 26
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at ietf-		this standard. Please address the information to the IETF at ietf-
	ipr@ietf.org.		ipr@ietf.org.
	Full Copyright Notice		Full Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF		OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Acknowledgement		Acknowledgement
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
	This document expires in September, 2007.		This document expires in July, 2008.
End of changes. 48 change blocks.
	82 lines changed or deleted		76 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/