draft-ietf-bfd-v4v6-1hop-00.txt		draft-ietf-bfd-v4v6-1hop-01.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: January, 2005 July, 2004		Expires: August, 2005 February, 2005
	BFD for IPv4 and IPv6 (Single Hop)		BFD for IPv4 and IPv6 (Single Hop)
	draft-ietf-bfd-v4v6-1hop-00.txt		draft-ietf-bfd-v4v6-1hop-01.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		By submitting this Internet-Draft, I certify that any applicable
	all provisions of Section 10 of RFC2026.		patent or other IPR claims of which I am aware have been disclosed,
			or will be disclosed, and any of which I become aware will be
			disclosed, in accordance with RFC 3668.
	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
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt		http://www.ietf.org/1id-abstracts.html
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2005). All Rights Reserved.
	Abstract		Abstract
	This document describes the use of the Bidirectional Forwarding		This document describes the use of the Bidirectional Forwarding
	Detection protocol over IPv4 and IPv6 for single IP hops. It further		Detection protocol over IPv4 and IPv6 for single IP hops. It further
	describes the use of BFD with OSPFv2, OSPFv3, and IS-IS. Comments on		describes the use of BFD with OSPFv2, OSPFv3, and IS-IS. Comments on
	this draft should be directed to rtg-bfd@ietf.org.		this draft should be directed to rtg-bfd@ietf.org.
	Conventions used in this document		Conventions used in this document
	skipping to change at page 4, line 23		skipping to change at page 4, line 23
	BFD Echo packets MUST be transmitted in UDP packets with destination		BFD Echo packets MUST be transmitted in UDP packets with destination
	UDP port 3785 in an IPv6 packet. The setting of the UDP source port		UDP port 3785 in an IPv6 packet. The setting of the UDP source port
	is outside the scope of this specification. The source and		is outside the scope of this specification. The source and
	destination addresses MUST both be associated with the local system.		destination addresses MUST both be associated with the local system.
	The destination address MUST be chosen in such a way as to cause the		The destination address MUST be chosen in such a way as to cause the
	remote system to forward the packet back to the local system.		remote system to forward the packet back to the local system.
	5. TTL/Hop Count Issues		5. TTL/Hop Count Issues
	All BFD Control packets for sessions operating according to this		If BFD authentication is not in use, all BFD Control packets for
	specification MUST be sent with a TTL or Hop Count value of 255. All		sessions operating according to this specification MUST be sent with
	received BFD Control packets that are demultiplexed to sessions		a TTL or Hop Count value of 255. All received BFD Control packets
	operating according to this specification MUST be discarded if the		that are demultiplexed to sessions operating according to this
	received TTL or Hop Count is not equal to 255. A discussion of this		specification MUST be discarded if the received TTL or Hop Count is
	mechanism can be found in [GTSM].		not equal to 255. A discussion of this mechanism can be found in
			[GTSM].
			If BFD authentication is in use, any value of TTL/Hop Count MAY be
			used in transmitted packets, and received packets MUST NOT be
			discarded based on the received TTL/Hop Count.
	6. Addressing Issues		6. Addressing Issues
	On a subnetted network, BFD Control packets MUST be transmitted with		On a subnetted network, BFD Control packets MUST be transmitted with
	source and destination addresses that are part of the subnet		source and destination addresses that are part of the subnet
	(addressed from and to interfaces on the subnet.)		(addressed from and to interfaces on the subnet.)
	On an addressed but unsubnetted point-to-point link, BFD Control		On an addressed but unsubnetted point-to-point link, BFD Control
	packets MUST be transmitted with source and destination addresses		packets MUST be transmitted with source and destination addresses
	that match the addresses configured on that link.		that match the addresses configured on that link.
	skipping to change at page 5, line 16		skipping to change at page 5, line 21
	The two versions of OSPF, as well as IS-IS, all suffer from an		The two versions of OSPF, as well as IS-IS, all suffer from an
	architectural limitation, namely that their Hello protocols are		architectural limitation, namely that their Hello protocols are
	limited in the granularity of failure their detection times. In		limited in the granularity of failure their detection times. In
	particular, OSPF has a minimum detection time of two seconds, and IS-		particular, OSPF has a minimum detection time of two seconds, and IS-
	IS has a minimum detection time of one second.		IS has a minimum detection time of one second.
	BFD MAY be used to achieve arbitrarily small detection times for		BFD MAY be used to achieve arbitrarily small detection times for
	these protocols by supplanting the Hello protocols used in each case.		these protocols by supplanting the Hello protocols used in each case.
			It should be noted that the purpose of using BFD in this context is
			not to replace the adjacency timeout mechanism, nor is it to
			demonstrate that the network is fully functional for the use of the
			routing protocol, but is simply to advise the routing protocol that
			there are problems forwarding the data protocol for which the routing
			protocol is calculating routes.
	7.1. Session Establishment		7.1. Session Establishment
	The mechanism by which a BFD session is established in this		The mechanism by which a BFD session is established in this
	environment is outside the scope of this specification. An obvious		environment is outside the scope of this specification. An obvious
	choice would be to use the discovery mechanism inherent in the Hello		choice would be to use the discovery mechanism inherent in the Hello
	protocols in OSPF and IS-IS to bootstrap the establishment of a BFD		protocols in OSPF and IS-IS to bootstrap the establishment of a BFD
	session.		session.
	Any BFD sessions established to support OSPF and IS-IS across a		Any BFD sessions established to support OSPF and IS-IS across a
	single IP hop MUST operate in accordance with the rest of this		single IP hop MUST operate in accordance with the rest of this
	skipping to change at page 6, line 12		skipping to change at page 6, line 31
	or if multiple protocols are being advertised but the protocols must		or if multiple protocols are being advertised but the protocols must
	share a common topology, a Hello protocol timeout SHOULD be emulated		share a common topology, a Hello protocol timeout SHOULD be emulated
	for the associated OSPF neighbors and/or IS-IS adjacencies.		for the associated OSPF neighbors and/or IS-IS adjacencies.
	If multiple data protocols are advertised in the routing protocol		If multiple data protocols are advertised in the routing protocol
	Hello, and the routing protocol supports different topologies for		Hello, and the routing protocol supports different topologies for
	each data protocol, the failing data protocol SHOULD no longer be		each data protocol, the failing data protocol SHOULD no longer be
	advertised in Hello packets in order to signal a lack of connectivity		advertised in Hello packets in order to signal a lack of connectivity
	for that protocol.		for that protocol.
	If a BFD session never reaches Up state (possibly because the remote		Note that it is possible in some failure scenarios for the network to
	system does not support BFD), this MUST NOT preclude the		be in a state such that the IGP comes up, but the BFD session cannot
	establishment of an OSPF neighbor or an IS-IS adjacency.		be established, and, more particularly, data cannot be forwarded. To
			avoid this situation, it would be beneficial to not allow the IGP to
			establish a neighbor/adjacency. However, this would preclude the
			operation of the IGP in an environment in which not all systems
			support BFD.
			Therefore, if a BFD session is not in Up state (possibly because the
			remote system does not support BFD), it is OPTIONAL to preclude the
			establishment of an OSPF neighbor or an IS-IS adjacency. The choice
			of whether to do so SHOULD be controlled by means outside the scope
			of this specification, such as configuration or other mechanisms.
	7.4. Interactions with OSPF and IS-IS with Graceful Restart		7.4. Interactions with OSPF and IS-IS with Graceful Restart
	The Graceful Restart functions in OSPF [OSPF-GRACE] and IS-IS [ISIS-		The Graceful Restart functions in OSPF [OSPF-GRACE] and IS-IS [ISIS-
	GRACE] are predicated on the existence of a separate forwarding plane		GRACE] are predicated on the existence of a separate forwarding plane
	that does not necessarily share fate with the control plane in which		that does not necessarily share fate with the control plane in which
	the routing protocols operate. In particular, the assumption is that		the routing protocols operate. In particular, the assumption is that
	the forwarding plane can continue to function while the protocols		the forwarding plane can continue to function while the protocols
	restart and sort things out.		restart and sort things out.
	skipping to change at page 6, line 44		skipping to change at page 7, line 26
	BFD is independent of the control plane on the local system, and the		BFD is independent of the control plane on the local system, and the
	remote system has been transmitting BFD Control packets with the C		remote system has been transmitting BFD Control packets with the C
	bit set, the graceful restart SHOULD be aborted and the topology		bit set, the graceful restart SHOULD be aborted and the topology
	change made visible to the network as outlined in section 7.3.		change made visible to the network as outlined in section 7.3.
	If BFD shares its fate with the control plane on either system		If BFD shares its fate with the control plane on either system
	(either the local system shares fate with the control plane, or the		(either the local system shares fate with the control plane, or the
	remote system is transmitting BFD packets with the C bit set to		remote system is transmitting BFD packets with the C bit set to
	zero), it is not useful during graceful restart, as the BFD session		zero), it is not useful during graceful restart, as the BFD session
	is likely to fail regardless of the state of the forwarding plane.		is likely to fail regardless of the state of the forwarding plane.
	In this situation, if a BFD session fails while graceful restart is		The action to take in this case depends on the capabilities of the
	taking place (or if the BFD session failure triggers a graceful		IGP.
	restart event), the graceful restart SHOULD be allowed to complete
	and the topology change should not be made visible to the network as		7.4.1. OSPF Graceful Restart With Control Plane Fate Sharing
	outlined in section 7.3.
			OSPF has a "planned" restart mechanism, in which the restarting
			system notifies its neighbors that it is about to perform a restart.
			In this situation, if a BFD session fails while the neighbor is
			performing a graceful restart, the graceful restart SHOULD be allowed
			to complete and the topology change should not be made visible to the
			network as outlined in section 7.3.
			For unplanned restarts (in which the neighbor has not notified the
			local system of its intention to restart), the OSPF Graceful Restart
			specification allows a Graceful Restart to take place if the system
			restarts prior to the expiration of the OSPF neighbor relationship.
			In this case, the BFD Detection Time is likely to expire prior to the
			restart, and the neighbor relationship SHOULD be torn down. In the
			unlikely event that the system restarts quickly enough, and the
			system chooses to attempt a Graceful Restart, the graceful restart
			SHOULD be allowed to complete and the topology change should not be
			made visible to the network as outlined in section 7.3.
			7.4.2. ISIS Graceful Restart With Control Plane Fate Sharing
			ISIS Graceful Restart does not signal a "planned" restart; its
			mechanism does not begin until after the system has restarted. If
			the BFD session expires prior to the restart of the system, there is
			no way for the neighbors to know that a Graceful Restart will take
			place.
			If a planned restart is about to place, the restarting system MAY
			change the BFD timing parameters on a temporary basis in such a way
			as to make the Detection Time greater than or equal to the ISIS
			adjacency timeout. This will provide the restarting system the same
			opportunity to enter Graceful Restart as it would have without BFD.
			In this case, the restarted system SHOULD avoid sending any BFD
			Control packets until there is a high likelihood that its neighbors
			know it is performing a Graceful Restart, since the neighbors will
			tear down their BFD sessions when those sessions restart.
			In any case, if a BFD session fails while the neighbor is known to be
			performing a Graceful Restart, the Graceful Restart SHOULD be allowed
			to complete and the topology change should not be made visible to the
			network as outlined in section 7.3.
			If the BFD session fails, and it is not known whether the neighbor is
			performing a Graceful Restart, the BFD session failure SHOULD be made
			visible to the network as outlined in section 7.3.
	7.5. OSPF Virtual Links		7.5. OSPF Virtual Links
	If it is desired to use BFD for failure detction of OSPF Virtual		If it is desired to use BFD for failure detction of OSPF Virtual
	Links, the mechanism described in [BFD-MULTI] MUST be used, since		Links, the mechanism described in [BFD-MULTI] MUST be used, since
	OSPF Virtual Links may traverse an arbitrary number of hops. BFD		OSPF Virtual Links may traverse an arbitrary number of hops. BFD
	Authentication SHOULD be used and is strongly encouraged.		Authentication SHOULD be used and is strongly encouraged.
	8. BFD for use with Tunnels		8. BFD for use with Tunnels
	A number of mechanisms are available to tunnel IPv4 and IPv6 over		A number of mechanisms are available to tunnel IPv4 and IPv6 over
	arbitrary topologies. If the tunnel mechanism does not decrement the		arbitrary topologies. If the tunnel mechanism does not decrement the
	TTL or hop count of the network protocol carried within, the		TTL or hop count of the network protocol carried within, the
	mechanism described in this document may be used to provide liveness		mechanism described in this document may be used to provide liveness
	detection for the tunnel. The BFD Authentication mechanism SHOULD be		detection for the tunnel. The BFD Authentication mechanism SHOULD be
	used and is strongly encouraged.		used and is strongly encouraged.
	Normative References		Normative References
	[BFD] Katz, D., and Ward, D., "Bidirectional Forwarding Detection",		[BFD] Katz, D., and Ward, D., "Bidirectional Forwarding Detection",
	draft-ietf-bfd-base-00.txt, July, 2004.		draft-ietf-bfd-base-01.txt, February, 2005.
	[BFD-MULTI] Katz, D., and Ward, D., "BFD for Multihop Paths", draft-		[BFD-MULTI] Katz, D., and Ward, D., "BFD for Multihop Paths", draft-
	ietf-bfd-multihop-00.txt, July, 2004.		ietf-bfd-multihop-01.txt, February, 2005.
	[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 3682, February 2004.
	[ISIS] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual		[ISIS] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual
	environments", RFC 1195, December 1990.		environments", RFC 1195, December 1990.
	[ISIS-GRACE] Shand, M., and Ginsberg, L., "Restart signaling for IS-		[ISIS-GRACE] Shand, M., and Ginsberg, L., "Restart signaling for IS-
	IS", draft-ietf-isis-restart-05.txt, January 2004.		IS", RFC 3847, July 2004.
	[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.
	[OSPFv2] Moy, J., "OSPF Version 2", RFC 2328, April 1998.		[OSPFv2] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
	[OSPFv3] Coltun, R., et al, "OSPF for IPv6", RFC 2740, December 1999.		[OSPFv3] Coltun, R., et al, "OSPF for IPv6", RFC 2740, December 1999.
	[OSPF-GRACE] Moy, J., et al, "Graceful OSPF Restart", RFC 3623,		[OSPF-GRACE] Moy, J., et al, "Graceful OSPF Restart", RFC 3623,
	November 2003.		November 2003.
	skipping to change at page 8, line 34		skipping to change at page 10, line 34
	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 only significant changes to this version are the addition of		The only significant changes to this version are the option of not
	language describing tunnels and OSPF virtual links. All other		using the TTL=255 hack when authentication is in use, the option of
	changes are editorial in nature.		suppressing ISIS and OSPF neighbors while the BFD session is down,
			and further explication of the interactions with Graceful Restart.
			All other changes are editorial in nature.
	Full Copyright Notice		Full Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2005). This document is subject
			to the rights, licenses and restrictions contained in BCP 78, and
	This document and translations of it may be copied and furnished to		except as set forth therein, the authors retain all their rights.
	others, and derivative works that comment on or otherwise explain it
	or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph are
	included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing
	the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of
	developing Internet standards in which case the procedures for
	copyrights defined in the Internet Standards process must be
	followed, or as required to translate it into languages other than
	English.
	The limited permissions granted above are perpetual and will not be
	revoked by the Internet Society or its successors or assigns.
	This document and the information contained herein is provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
			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 August, 2005.
End of changes.
This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/