draft-ietf-bfd-on-lags-00.txt		draft-ietf-bfd-on-lags-01.txt
	Network Working Group M. Bhatia, Ed.		Network Working Group M. Bhatia, Ed.
	Internet-Draft Alcatel-Lucent		Internet-Draft Alcatel-Lucent
	Intended status: Standards Track M. Chen, Ed.		Intended status: Standards Track M. Chen, Ed.
	Expires: November 11, 2013 Huawei Technologies		Expires: December 15, 2013 Huawei Technologies
	S. Boutros, Ed.		S. Boutros, Ed.
	M. Binderberger, Ed.		M. Binderberger, Ed.
	Cisco Systems		Cisco Systems
	J. Haas, Ed.		J. Haas, Ed.
	Juniper Networks		Juniper Networks
	May 10, 2013		June 13, 2013
	Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG)		Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG)
	Interfaces		Interfaces
	draft-ietf-bfd-on-lags-00		draft-ietf-bfd-on-lags-01
	Abstract		Abstract
	This document proposes a mechanism to run BFD on Link Aggregation		This document proposes a mechanism to run BFD on Link Aggregation
	Group (LAG) interfaces. It does so by running an independent		Group (LAG) interfaces. It does so by running an independent
	Asynchronous mode BFD session on every LAG member link.		Asynchronous mode BFD session on every LAG member link.
	This mechanism allows the verification of member link continuity,		This mechanism allows the verification of member link continuity,
	either in combination with, or in absence of, LACP. It provides a		either in combination with, or in absence of, LACP. It provides a
	shorter detection time than what LACP offers. The continuity check		shorter detection time than what LACP offers. The continuity check
	skipping to change at page 2, line 8		skipping to change at page 2, line 8
	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 November 11, 2013.		This Internet-Draft will expire on December 15, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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 3, line 12		skipping to change at page 3, line 12
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. BFD on LAG member links . . . . . . . . . . . . . . . . . . . 4		2. BFD on LAG member links . . . . . . . . . . . . . . . . . . . 4
	2.1. Micro BFD session address family . . . . . . . . . . . . . 5		2.1. Micro BFD session address family . . . . . . . . . . . . . 5
	2.2. Micro BFD session negotiation . . . . . . . . . . . . . . 5		2.2. Micro BFD session negotiation . . . . . . . . . . . . . . 5
	2.3. Micro BFD session Ethernet details . . . . . . . . . . . . 6		2.3. Micro BFD session Ethernet details . . . . . . . . . . . . 6
	3. LAG Management Module . . . . . . . . . . . . . . . . . . . . 6		3. Interaction between LAG and BFD . . . . . . . . . . . . . . . 6
	3.1. Interaction between LAG and BFD . . . . . . . . . . . . . 6		4. BFD on LAG member links and layer-3 applications . . . . . . . 7
	3.2. Handling Exceptions . . . . . . . . . . . . . . . . . . . 7		5. Detecting a member link failure . . . . . . . . . . . . . . . 7
	4. BFD on LAG members and layer-3 applications . . . . . . . . . 8		6. Security Consideration . . . . . . . . . . . . . . . . . . . . 7
	5. Detecting a member link failure . . . . . . . . . . . . . . . 8		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	6. Security Consideration . . . . . . . . . . . . . . . . . . . . 8		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		9. Contributing authors . . . . . . . . . . . . . . . . . . . . . 8
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	9. Contributing authors . . . . . . . . . . . . . . . . . . . . . 9		10.1. Normative References . . . . . . . . . . . . . . . . . . . 9
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10		10.2. Informative References . . . . . . . . . . . . . . . . . . 9
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 10		Appendix A. Considerations when using BFD on member links . . . . 9
	10.2. Informative References . . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	The Bidirectional Forwarding Detection (BFD) protocol [RFC5880]		The Bidirectional Forwarding Detection (BFD) protocol [RFC5880]
	provides a mechanism to detect faults in the bidirectional path		provides a mechanism to detect faults in the bidirectional path
	between two forwarding engines, including interfaces, data link(s),		between two forwarding engines, including interfaces, data link(s),
	and to the extent possible the forwarding engines themselves, with		and to the extent possible the forwarding engines themselves, with
	potentially very low latency. The BFD protocol also provides a fast		potentially very low latency. The BFD protocol also provides a fast
	mechanism for detecting communication failures on any data links and		mechanism for detecting communication failures on any data links and
	skipping to change at page 4, line 36		skipping to change at page 4, line 36
	verify L3 Continuity per member link.		verify L3 Continuity per member link.
	Running a single BFD session over the aggregation without internal		Running a single BFD session over the aggregation without internal
	knowledge of the member links would make it impossible for BFD to		knowledge of the member links would make it impossible for BFD to
	guarantee detection of the physical member link failures.		guarantee detection of the physical member link failures.
	The goal is to verify link Continuity for every member link. This		The goal is to verify link Continuity for every member link. This
	corresponds to [RFC5882], section 7.3.		corresponds to [RFC5882], section 7.3.
	The approach taken in this document is to run a Asynchronous mode BFD		The approach taken in this document is to run a Asynchronous mode BFD
	session over each member link and make BFD control whether the member		session over each LAG member link and make BFD control whether the
	link should be part of the L2 Loadbalance table of the LAG virtual		LAG member link should be part of the L2 Loadbalance table of the LAG
	port in the presence or the absence of LACP.		interface in the presence or the absence of LACP.
	This document describes how to establish an Asynchronous mode BFD		This document describes how to establish an Asynchronous mode BFD
	session per physical member link of the LAG virtual port.		session per physical LAG member link of the LAG interface.
	While there are native Ethernet mechanisms to detect failures		While there are native Ethernet mechanisms to detect failures
	(802.1ax, .3ah) that could be used for LAG, the solution proposed in		(802.1ax, .3ah) that could be used for LAG, the solution proposed in
	this document enables operators who have already deployed BFD over		this document enables operators who have already deployed BFD over
	different technologies (e.g. IP, MPLS) to use a common failure		different technologies (e.g. IP, MPLS) to use a common failure
	detection mechanism.		detection mechanism.
	2. BFD on LAG member links		2. BFD on LAG member links
	The mechanism proposed for a fast detection of LAG member link		The mechanism proposed for a fast detection of LAG member link
	skipping to change at page 5, line 40		skipping to change at page 5, line 40
	that micro BFD sessions belonging to the same aggregation will use		that micro BFD sessions belonging to the same aggregation will use
	the same timer values.		the same timer values.
	The demultiplexing of a received BFD packet is solely based on the		The demultiplexing of a received BFD packet is solely based on the
	Your Discriminator field, if this field is nonzero. For the initial		Your Discriminator field, if this field is nonzero. For the initial
	Down BFD packets of a BFD session this value MAY be zero. In this		Down BFD packets of a BFD session this value MAY be zero. In this
	case demultiplexing MUST be based on some combination of other fields		case demultiplexing MUST be based on some combination of other fields
	which MUST include the interface information of the member link.		which MUST include the interface information of the member link.
	The procedure for the Reception of BFD Control Packets in Section		The procedure for the Reception of BFD Control Packets in Section
	6.8.6 of [RFC5880] is amended as follows for per member link micro		6.8.6 of [RFC5880] is amended as follows for per LAG member link
	BFD over LAG sessions: "If the Your Discriminator field is non-zero		micro BFD sessions: "If the Your Discriminator field is non-zero and
	and a micro BFD over LAG session is found, the interface on which the		a micro BFD over LAG session is found, the interface on which the
	micro BFD control packet arrived on MUST correspond to the interface		micro BFD control packet arrived on MUST correspond to the interface
	associated with that session."		associated with that session."
	This document defines the BFD Control packets for each micro BFD		This document defines the BFD Control packets for each micro BFD
	session to be IP/UDP encapsulated as defined in [RFC5881], but with a		session to be IP/UDP encapsulated as defined in [RFC5881], but with a
	new UDP destination port 6784.		new UDP destination port 6784.
	Control packets use a destination IP address that is configured on		Control packets use a destination IP address that is configured on
	the peer system and can be reached via the LAG interface. The		the peer system and can be reached via the LAG interface. The
	details of how this destination IP address is learned are outside the		details of how this destination IP address is learned are outside the
	skipping to change at page 6, line 21		skipping to change at page 6, line 21
	next hop. This dedicated MAC address MUST be used for the initial		next hop. This dedicated MAC address MUST be used for the initial
	BFD packets of a micro BFD session when in the Down/AdminDown and		BFD packets of a micro BFD session when in the Down/AdminDown and
	Init state. When a micro BFD session is changing into Up state then		Init state. When a micro BFD session is changing into Up state then
	the first bfd.DetectMult packets with Up state MUST be sent with the		the first bfd.DetectMult packets with Up state MUST be sent with the
	dedicated MAC. For the following BFD packets with Up state the MAC		dedicated MAC. For the following BFD packets with Up state the MAC
	address from the received BFD packets for the session MAY be used		address from the received BFD packets for the session MAY be used
	instead of the dedicated MAC.		instead of the dedicated MAC.
	All implementations MUST be able to send and receive BFD packets in		All implementations MUST be able to send and receive BFD packets in
	Up state using the dedicated MAC address. Implementations supporting		Up state using the dedicated MAC address. Implementations supporting
	both, sending BFD Up packets with the dedicated and the received MAC		both, sending BFD Up packets with the dedicated and the received MAC,
	need to offer means to control the behaviour.		need to offer means to control the behaviour.
	On Ethernet-based LAG member links the source MAC SHOULD be the MAC		On Ethernet-based LAG member links the source MAC SHOULD be the MAC
	address of the port transmitting the packet.		address of the member link transmitting the packet.
	This mechanism helps to reduce the use of additional MAC addresses,		This mechanism helps to reduce the use of additional MAC addresses,
	which reduces the required resources on the Ethernet hardware on the		which reduces the required resources on the Ethernet hardware on the
	receiving port.		receiving member link.
	Micro BFD packets SHOULD always be sent untagged. However, when the		Micro BFD packets SHOULD always be sent untagged. However, when the
	LAG is operating in the context of IEEE 802.1q or IEEE 802.qinq, the		LAG is operating in the context of IEEE 802.1q or IEEE 802.qinq, the
	micro BFD packets may either be untagged or sent with a vlan tag of		micro BFD packets may either be untagged or sent with a vlan tag of
	Zero (802.1p priority tagged). Implementations compliant to this		Zero (802.1p priority tagged). Implementations compliant to this
	standard MUST be able to receive both untagged and 802.1p priority		standard MUST be able to receive both untagged and 802.1p priority
	tagged micro BFD packets.		tagged micro BFD packets.
	3. LAG Management Module		3. Interaction between LAG and BFD
	3.1. Interaction between LAG and BFD
	The LAG Management Module (LMM) could be envisaged as a client of
	BFD; i.e. the LMM requests the micro BFD sessions per member link.
	The LMM then uses the micro BFD session state, in addition to LACP
	state, to monitor the health of the individual members links of the
	LAG.
	The micro BFD sessions for a particular port MUST be requested when a		The micro BFD sessions for a particular LAG member link MUST be
	member port state is either Distributing or Standby. The sessions		requested when a member link state is either Distributing or Standby.
	MUST be deleted when the member port is neither in Distributing nor		The sessions MUST be deleted when the member link is neither in
	in Standby state anymore.		Distributing nor in Standby state anymore.
	BFD is used to control if the load balance algorithm is able to		BFD is used to control if the load balance algorithm is able to
	select a particular port. In other words, even when LACP is used and		select a particular LAG member link. In other words, even when LACP
	considers the member link to be ready to forward traffic, the member		is used and considers the member link to be ready to forward traffic,
	link is only used by the load balancer when all the micro BFD		the member link MUST NOT be used by the load balancer until all the
	sessions of the member link are Up.		micro BFD sessions of the particular member link are in Up state.
	In case an implementation has separate load balance tables for IPv4		In case an implementation has separate load balance tables for IPv4
	and IPv6 then if both an IPv4 and IPv6 micro session exist for a		and IPv6 and if both an IPv4 and IPv6 micro session exist for a
	member link an implementation MAY enable the member link in the		member link then an implementation MAY enable the member link in the
	distribution algorithm only when the BFD session with a matching		load balance algorithm based on the BFD session with a matching
	address family is changing into Up state.		address family alone.
	An exception are the BFD packets itself. Implementations MAY receive		An exception is the BFD packet itself. Implementations MAY receive
	and transmit BFD packets via the Aggregator's MAC service interface		and transmit BFD packets via the Aggregator's MAC service interface
	independent of the session state.		independent of the session state.
	3.2. Handling Exceptions		4. BFD on LAG member links and layer-3 applications
	If the BFD over LAG feature were provisioned on an aggregated link
	member after the link was already active within a LAG, BFD session
	state SHOULD NOT influence the load balance algorithm until the BFD
	session state transitions to Up. If the BFD session never
	transitions to Up but the LAG becomes inactive, the previously
	documented procedures would then normally apply.
	If the BFD over LAG feature were deprovisioned on an aggregate link
	member after the BFD session had transitioned to Up, BFD MAY indicate
	to the remote port that it should not take the port down or remove it
	from the aggregation by setting its BFD session state to AdminDown.
	When a micro BFD session receives AdminDown from the peer, it is
	RECOMMENDED to have a configurable timeout value. If the BFD session
	has not been removed within the timeout period the link is taken out
	of forwarding.
	When traffic is forwarded across a link before the corresponding
	micro BFD session is Up it is RECOMMENDED to have a configurable
	timeout value after which the BFD session must have reached Up state
	or otherwise the link is taken out of forwarding.
	Note that if one device is not operating a micro BFD session on a
	link, while the other device is and perceives the session to be Down,
	this will result in the two devices having a different view of the
	status of the link. This would likely lead to traffic loss across
	the LAG.
	The use of another protocol to bootstrap BFD can detect such
	mismatched config, since the side that's not configured can send a
	rejection error. Such bootstrapping mechanisms are outside the scope
	of this document.
	4. BFD on LAG members and layer-3 applications
	The mechanism described in this document is likely to be used by		The mechanism described in this document is likely to be used by
	modules like LMM or some Interface management module. Typical layer		modules like LMM or some Interface management module. Typical layer
	3 protocols like OSPF do not have an insight into the LAG and treat		3 protocols like OSPF do not have an insight into the LAG and treat
	it as one bigger interface. The signalling from micro sessions to		it as one bigger interface. The signaling from micro sessions to
	layer 3 protocols is effectively done by the impact of BFD micro		layer 3 protocols is effectively done by the impact of BFD micro
	sessions on the load balance table and the LMM's potential decision		sessions on the load balance table and the LMM's potential decision
	to shut down the LAG. An active method to test the impact of micro		to shut down the LAG. An active method to test the impact of micro
	sessions is for layer 3 protocols to request a single BFD session per		sessions is for layer 3 protocols to request a single BFD session per
	LAG.		LAG.
	5. Detecting a member link failure		5. Detecting a member link failure
	When a micro BFD session goes down then this member link MUST be		When a micro BFD session goes down then this member link MUST be
	taken out of the LAG L2 load balance table(s).		taken out of the LAG L2 load balance table(s).
	In case an implementation has separate load balance tables for IPv4		In case an implementation has separate load balance tables for IPv4
	and IPv6 then if both an IPv4 and IPv6 micro session exist for a		and IPv6 then if both an IPv4 and IPv6 micro session exist for a
	member link an implementation MAY remove the member link from the		member link an implementation MAY remove the member link from the
	load balance table only that matches the address family of the		load balance table only that matches the address family of the
	failing BFD session. If for example the IPv4 micro session fails but		failing BFD session. If for example the IPv4 micro session fails but
	the IPv6 micro session stays up then the member link MAY be removed		the IPv6 micro session stays Up then the member link MAY be removed
	from the IPv4 load balance table only but remains forwarding in the		from the IPv4 load balance table only but remains forwarding in the
	IPv6 load balance table.		IPv6 load balance table.
	6. Security Consideration		6. Security Consideration
	This document does not introduce any additional security issues and		This document does not introduce any additional security issues and
	the security mechanisms defined in [RFC5880] apply in this document.		the security mechanisms defined in [RFC5880] apply in this document.
	7. IANA Considerations		7. IANA Considerations
	skipping to change at page 10, line 36		skipping to change at page 9, line 39
	[IEEE802.1AX]		[IEEE802.1AX]
	IEEE Std. 802.1AX, "IEEE Standard for Local and		IEEE Std. 802.1AX, "IEEE Standard for Local and
	metropolitan area networks - Link Aggregation",		metropolitan area networks - Link Aggregation",
	November 2008.		November 2008.
	[RFC5342] Eastlake, D., "IANA Considerations and IETF Protocol Usage		[RFC5342] Eastlake, D., "IANA Considerations and IETF Protocol Usage
	for IEEE 802 Parameters", BCP 141, RFC 5342,		for IEEE 802 Parameters", BCP 141, RFC 5342,
	September 2008.		September 2008.
			Appendix A. Considerations when using BFD on member links
			If the BFD over LAG feature were provisioned on an aggregated link
			member after the link was already active within a LAG, BFD session
			state SHOULD NOT influence the load balance algorithm until the BFD
			session state transitions to Up. If the BFD session never
			transitions to Up but the LAG becomes inactive, the previously
			documented procedures would then normally apply.
			This procedure ensures that the sequence of events - enabling the LAG
			and enabling BFD on the LAG - has no impact on the forwarding
			service.
			If the BFD over LAG feature was deprovisioned on an aggregate link
			member while the associated micro BFD session was in Up state, BFD
			SHOULD transition its state to AdminDown and SHOULD attempt to
			communicate this state change to the peer.
			If the local or the remote state of a micro BFD session is AdminDown
			the system SHOULD NOT indicate a connectivity failure to any client
			and SHOULD NOT remove the particular LAG member link from forwarding.
			This behaviour is independent from the use of LACP for the LAG.
			When traffic is forwarded across a link while the corresponding micro
			BFD session is not in Up state an implementation MAY use a
			configurable timeout value after which the BFD session must have
			reached Up state or otherwise the link is taken out of forwarding.
			When such timeout values exist then the configuration MUST allow to
			turn off the timeout function.
			The configurable timeout value shall ensure that a LAG is not
			remaining forever in an "inconsistent" state where forwarding occurs
			on a link with no confirmation from the micro BFD session that the
			link is healthy.
			Note that if one device is not operating a micro BFD session on a
			link, while the other device is and perceives the session to be Down,
			this will result in the two devices having a different view of the
			status of the link. This would likely lead to traffic loss across
			the LAG. The use of another protocol to bootstrap BFD can detect
			such mismatched config, since the side that's not configured can send
			a rejection error. Such bootstrapping mechanisms are outside the
			scope of this document.
	Authors' Addresses		Authors' Addresses
	Manav Bhatia (editor)		Manav Bhatia (editor)
	Alcatel-Lucent		Alcatel-Lucent
	Bangalore 560045		Bangalore 560045
	India		India
	Email: manav.bhatia@alcatel-lucent.com		Email: manav.bhatia@alcatel-lucent.com
	Mach(Guoyi) Chen (editor)		Mach(Guoyi) Chen (editor)
	Huawei Technologies		Huawei Technologies
End of changes. 20 change blocks.
	86 lines changed or deleted		87 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/