< draft-ietf-rtgwg-vrrp-p2mp-bfd-00.txt		draft-ietf-rtgwg-vrrp-p2mp-bfd-01.txt >
	BFD Working Group G. Mirsky		BFD Working Group G. Mirsky
	Internet-Draft Ericsson		Internet-Draft Ericsson
	Updates: 5798 (if approved) J. Tantsura		Updates: 5798 (if approved) J. Tantsura
	Intended status: Standards Track Microsoft		Intended status: Standards Track Microsoft
	Expires: 2 July 2022 G. Mishra		Expires: 22 September 2022 G. Mishra
	Verizon Inc.		Verizon Inc.
	29 December 2021		21 March 2022
	Applicability of Bidirectional Forwarding Detection (BFD) for Multi-		Applicability of Bidirectional Forwarding Detection (BFD) for Multi-
	point Networks in Virtual Router Redundancy Protocol (VRRP)		point Networks in Virtual Router Redundancy Protocol (VRRP)
	draft-ietf-rtgwg-vrrp-p2mp-bfd-00		draft-ietf-rtgwg-vrrp-p2mp-bfd-01
	Abstract		Abstract
	This document discusses the applicability of Bidirectional Forwarding		This document discusses the applicability of Bidirectional Forwarding
	Detection (BFD) for multipoint networks to provide Virtual Router		Detection (BFD) for multipoint networks to provide Virtual Router
	Redundancy Protocol (VRRP) with sub-second Master convergence and		Redundancy Protocol (VRRP) with sub-second Active convergence and
	defines the extension to bootstrap point-to-multipoint BFD session.		defines the extension to bootstrap point-to-multipoint BFD session.
	This draft updates RFC 5798.		This draft updates RFC 5798.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 2 July 2022.		This Internet-Draft will expire on 22 September 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2022 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Revised BSD License text as		extracted from this document must include Revised BSD License text as
	described in Section 4.e of the Trust Legal Provisions and are		described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Revised BSD License.		provided without warranty as described in the Revised BSD License.
	skipping to change at page 2, line 31 ¶		skipping to change at page 2, line 31 ¶
	7. Normative References . . . . . . . . . . . . . . . . . . . . 5		7. Normative References . . . . . . . . . . . . . . . . . . . . 5
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
	1. Introduction		1. Introduction
	The [RFC5798] is the current specification of the Virtual Router		The [RFC5798] is the current specification of the Virtual Router
	Redundancy Protocol (VRRP) for IPv4 and IPv6 networks. VRRPv3 allows		Redundancy Protocol (VRRP) for IPv4 and IPv6 networks. VRRPv3 allows
	for a faster switchover to a Backup router. Using such capability		for a faster switchover to a Backup router. Using such capability
	with the software-based implementation of VRRP may prove challenging.		with the software-based implementation of VRRP may prove challenging.
	But it still may be possible to deploy VRRP and provide sub-second		But it still may be possible to deploy VRRP and provide sub-second
	detection of Master router failure by Backup routers.		detection of Active router failure by Backup routers.
	Bidirectional Forwarding Detection (BFD) [RFC5880] had been		Bidirectional Forwarding Detection (BFD) [RFC5880] had been
	originally defined detect failure of point-to-point (p2p) paths:		originally defined detect failure of point-to-point (p2p) paths:
	single-hop [RFC5881], multihop [RFC5883]. Single-hop BFD may be used		single-hop [RFC5881], multihop [RFC5883]. Single-hop BFD may be used
	to enable Backup routers to detect a failure of the Master router		to enable Backup routers to detect a failure of the Active router
	within 100 msec or faster.		within 100 msec or faster.
	[RFC8562] extends [RFC5880] for multipoint and multicast networks,		[RFC8562] extends [RFC5880] for multipoint and multicast networks,
	which matches the deployment scenarios for VRRP over the LAN segment.		which matches the deployment scenarios for VRRP over the LAN segment.
	This document demonstrates how point-to-multipoint (p2mp) BFD can		This document demonstrates how point-to-multipoint (p2mp) BFD can
	enable faster detection of Master failure and thus minimize service		enable faster detection of Active failure and thus minimize service
	disruption in a VRRP domain. The document also defines the extension		disruption in a VRRP domain. The document also defines the extension
	to VRRP [RFC5798] to bootstrap a VRRP Backup router to join in p2mp		to VRRP [RFC5798] to bootstrap a VRRP Backup router to join in p2mp
	BFD session.		BFD session.
	1.1. Conventions used in this document		1.1. Conventions used in this document
	1.1.1. Terminology		1.1.1. Terminology
	BFD: Bidirectional Forwarding Detection		BFD: Bidirectional Forwarding Detection
	skipping to change at page 3, line 26 ¶		skipping to change at page 3, line 26 ¶
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	2. Problem Statement		2. Problem Statement
	A router may be part of several Virtual Router Redundancy groups, as		A router may be part of several Virtual Router Redundancy groups, as
	Master in some and as Backup in others. Supporting sub-second mode		Active in some and as Backup in others. Supporting sub-second mode
	for VRRPv3 [RFC5798] for all these roles without specialized support		for VRRPv3 [RFC5798] for all these roles without specialized support
	in the data plane may prove challenging. BFD already has many		in the data plane may prove challenging. BFD already has many
	implementations based on HW that are capable of supporting multiple		implementations based on HW that are capable of supporting multiple
	sub-second sessions concurrently.		sub-second sessions concurrently.
	3. Applicability of p2mp BFD		3. Applicability of p2mp BFD
	[RFC8562] may provide an efficient and scalable solution for fast-		[RFC8562] may provide an efficient and scalable solution for fast-
	converging environment that uses the default route rather than		converging environment that uses the default route rather than
	dynamic routing. Each redundancy group presents itself as a p2mp BFD		dynamic routing. Each redundancy group presents itself as a p2mp BFD
	session, with its Master being the root and Backup routers being the		session, with its Active being the root and Backup routers being the
	tails of the p2mp BFD session. Figure 1 displays the extension of		tails of the p2mp BFD session. Figure 1 displays the extension of
	VRRP [RFC5798] to bootstrap a tail of the p2mp BFD session.		VRRP [RFC5798] to bootstrap a tail of the p2mp BFD session.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|Version| Type | Virtual Rtr ID| Priority |Count IPvX Addr|		|Version| Type | Virtual Rtr ID| Priority |Count IPvX Addr|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|Rsvd |B| Max Adver Int | Checksum |		|Rsvd |B| Max Adver Int | Checksum |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 4, line 23 ¶		skipping to change at page 4, line 23 ¶
	+ +		+ +
	| IPvX Address(es) |		| IPvX Address(es) |
	+ +		+ +
	+ +		+ +
	+ +		+ +
	+ +		+ +
	| |		| |
	+ +		+ +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Master Discriminator |		| Active Router Discriminator |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: VRRP Extension to Bootstrap P2MP BFD session		Figure 1: VRRP Extension to Bootstrap P2MP BFD session
	The new fields are interpreted as follows:		The new fields are interpreted as follows:
	B(FD) - a one-bit flag that indicates that the Master		B(FD) - a one-bit flag that indicates that the Active Router
	Discriminator field is appended to VRRP packet defined in		Discriminator field is appended to VRRP packet defined in
	[RFC5798];		[RFC5798];
	Master Discriminator - the four-octet field. The value MUST NOT		Active Router Discriminator - the four-octet field. The value
	be zero, and it equals the My Discriminator value allocated by the		MUST NOT be zero, and it equals the My Discriminator value
	root of the p2mp BFD session.		allocated by the root of the p2mp BFD session.
	The Master router, configured to use p2mp BFD to support faster		The Active router, configured to use p2mp BFD to support faster
	convergence of VRRP, starts transmitting BFD control packets with		convergence of VRRP, starts transmitting BFD control packets with
	VRID as a source IP address and the locally allocated value as the		VRID as a source IP address and the locally allocated value as the
	value of the My Discriminator field ([RFC5880]). The same non-zero		value of the My Discriminator field ([RFC5880]). The same non-zero
	value of My Discriminator MUST be set as the value of the Master		value of My Discriminator MUST be set as the value of the Active
	Discriminator field. The BFD flag MUST be set in the VRRP packet. A		Router Discriminator field. The BFD flag MUST be set in the VRRP
	Backup router demultiplexes p2mp BFD test sessions based on VRID that		packet. A Backup router demultiplexes p2mp BFD test sessions based
	it has been configured with and the non-zero My Discriminator value		on VRID that it has been configured with and the non-zero My
	it learns from the received VRRP packet. When a Backup router		Discriminator value it learns from the received VRRP packet. When a
	detects the failure of the Master router, it re-evaluates its role in		Backup router detects the failure of the Active router, it re-
	the VRID. As a result, the Backup router may become the Master		evaluates its role in the VRID. As a result, the Backup router may
	router of the given VRID or continue as a Backup router. If the		become the Active router of the given VRID or continue as a Backup
	former is the case, then the new Master router MUST select My		router. If the former is the case, then the new Active router MUST
	Discriminator and start transmitting p2mp BFD control packets using		select My Discriminator and start transmitting p2mp BFD control
	Master IP address as the source IP address for p2mp BFD control		packets using Active IP address as the source IP address for p2mp BFD
	packets. If the latter is the case, then the Backup router MUST wait		control packets. If the latter is the case, then the Backup router
	for the VRRP packet from the new VRRP Master router that will		MUST wait for the VRRP packet from the new VRRP Active router that
	bootstrap the new p2mp BFD session.		will bootstrap the new p2mp BFD session.
	3.1. Multipoint BFD Encapsulation		3.1. Multipoint BFD Encapsulation
	The MultipointHead of p2mp BFD session when transmitting BFD control		The MultipointHead of p2mp BFD session when transmitting BFD control
	packet:		packet:
	MUST set TTL or Hop Limit value to 255 (Section 5 [RFC5881]).		MUST set TTL or Hop Limit value to 255 (Section 5 [RFC5881]).
	Similarly, all received BFD Control packets that are demultiplexed		Similarly, all received BFD Control packets that are demultiplexed
	to the session MUST be discarded if the received TTL or Hop Limit		to the session MUST be discarded if the received TTL or Hop Limit
	is not equal to 255;		is not equal to 255;
	SHOULD use group address VRRP ('224.0.0.18' for IPv4 and		SHOULD use group address VRRP ('224.0.0.18' for IPv4 and
	'FF02:0:0:0:0:0:0:12' for IPv6) as destination IP address		'FF02:0:0:0:0:0:0:12' for IPv6) as destination IP address
	MAY use network broadcast address for IPv4 or link-local all nodes		MAY use network broadcast address for IPv4 or link-local all nodes
	multicast group for IPv6 as destination IP address;		multicast group for IPv6 as destination IP address;
	MUST set destination UDP port value to 3784 when transmitting BFD		MUST set destination UDP port value to 3784 when transmitting BFD
	control packets, as defined in [RFC8562];		control packets, as defined in [RFC8562];
	MUST use the Master IP address as the source IP address.		MUST use the Active IP address as the source IP address.
	4. IANA Considerations		4. IANA Considerations
	This document makes no requests for IANA allocations. This section		This document makes no requests for IANA allocations. This section
	may be deleted by RFC Editor.		may be deleted by RFC Editor.
	5. Security Considerations		5. Security Considerations
	This document defines an alternative way, to the one defined in		This document defines an alternative way, to the one defined in
	[RFC5798], to accelerate detecting a failure that affects VRRP		[RFC5798], to accelerate detecting a failure that affects VRRP
End of changes. 17 change blocks.
	32 lines changed or deleted		32 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/