< draft-ietf-idr-bgp-ls-sbfd-extensions-04.txt		draft-ietf-idr-bgp-ls-sbfd-extensions-05.txt >
	Inter-Domain Routing Z. Li		Inter-Domain Routing Z. Li
	Internet-Draft S. Zhuang		Internet-Draft S. Zhuang
	Intended status: Standards Track Huawei		Intended status: Standards Track Huawei
	Expires: May 17, 2021 K. Talaulikar		Expires: September 9, 2021 K. Talaulikar, Ed.
	Cisco Systems		Cisco Systems, Inc.
	S. Aldrin		S. Aldrin
	Google, Inc		Google, Inc
	J. Tantsura		J. Tantsura
	Apstra		Apstra
	G. Mirsky		G. Mirsky
	ZTE Corp.		ZTE Corp.
	November 13, 2020		March 8, 2021
	BGP Link-State Extensions for Seamless BFD		BGP Link-State Extensions for Seamless BFD
	draft-ietf-idr-bgp-ls-sbfd-extensions-04		draft-ietf-idr-bgp-ls-sbfd-extensions-05
	Abstract		Abstract
	Seamless Bidirectional Forwarding Detection (S-BFD) defines a		Seamless Bidirectional Forwarding Detection (S-BFD) defines a
	simplified mechanism to use Bidirectional Forwarding Detection (BFD)		simplified mechanism to use Bidirectional Forwarding Detection (BFD)
	with large portions of negotiation aspects eliminated, thus providing		with large portions of negotiation aspects eliminated, thus providing
	benefits such as quick provisioning as well as improved control and		benefits such as quick provisioning as well as improved control and
	flexibility to network nodes initiating the path monitoring. The		flexibility to network nodes initiating the path monitoring. The
	link-state routing protocols (IS-IS and OSPF) have been extended to		link-state routing protocols (IS-IS and OSPF) have been extended to
	advertise the Seamless BFD (S-BFD) Discriminators.		advertise the Seamless BFD (S-BFD) Discriminators.
	skipping to change at page 1, line 47 ¶		skipping to change at page 1, line 47 ¶
	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 May 17, 2021.		This Internet-Draft will expire on September 9, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2021 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 47 ¶		skipping to change at page 2, line 47 ¶
	1. Introduction		1. Introduction
	Seamless Bidirectional Forwarding Detection (S-BFD) [RFC7880] defines		Seamless Bidirectional Forwarding Detection (S-BFD) [RFC7880] defines
	a simplified mechanism to use Bidirectional Forwarding Detection		a simplified mechanism to use Bidirectional Forwarding Detection
	(BFD) [RFC5880] with large portions of negotiation aspects		(BFD) [RFC5880] with large portions of negotiation aspects
	eliminated, thus providing benefits such as quick provisioning as		eliminated, thus providing benefits such as quick provisioning as
	well as improved control and flexibility to network nodes initiating		well as improved control and flexibility to network nodes initiating
	the path monitoring.		the path monitoring.
	For monitoring of a service path end-to-end via S-BFD, the headend/		For monitoring of a service path end-to-end via S-BFD, the headend
	initiator node needs to know the S-BFD Discriminator of the		node (i.e. Initiator) needs to know the S-BFD Discriminator of the
	destination/tail-end node of that service. The link-state routing		destination/tail-end node (i.e. Responder) of that service. The
	protocols (IS-IS, OSPF and OSPFv3) have been extended to advertise		link-state routing protocols (IS-IS, OSPF and OSPFv3) have been
	the S-BFD Discriminators. With this a initiator node can learn the		extended to advertise the S-BFD Discriminators. With this a
	S-BFD discriminator for all nodes within its IGP area/level or		Initiator can learn the S-BFD discriminator for all Responders within
	optionally within the domain. With networks being divided into		its IGP area/level, or optionally within the domain. With networks
	multiple IGP domains for scaling and operational considerations, the		being divided into multiple IGP domains for scaling and operational
	service endpoints that require end to end S-BFD monitoring often span		considerations, the service endpoints that require end to end S-BFD
	across IGP domains.		monitoring often span across IGP domains.
	BGP Link-State (BGP-LS) [RFC7752] enables the collection and		BGP Link-State (BGP-LS) [RFC7752] enables the collection and
	distribution of IGP link-state topology information via BGP sessions		distribution of IGP link-state topology information via BGP sessions
	across IGP areas/levels and domains. The S-BFD discriminator(s) of a		across IGP areas/levels and domains. The S-BFD discriminator(s) of a
	node can thus be distributed along with the topology information via		node can thus be distributed along with the topology information via
	BGP-LS across IGP domains and even across multiple Autonomous Systems		BGP-LS across IGP domains and even across multiple Autonomous Systems
	(AS) within an administrative domain.		(AS) within an administrative domain.
	This draft defines extensions to BGP-LS for carrying the S-BFD		This draft defines extensions to BGP-LS for carrying the S-BFD
	Discriminators information.		Discriminators information.
	skipping to change at page 3, line 46 ¶		skipping to change at page 3, line 46 ¶
	organized as different ASes. Although the core and aggregation		organized as different ASes. Although the core and aggregation
	networks are segmented into different ASes, an end-to-end label		networks are segmented into different ASes, an end-to-end label
	switched path (LSP) can be created using hierarchical BGP signaled		switched path (LSP) can be created using hierarchical BGP signaled
	LSPs based on internal-BGP (IBGP) labeled unicast within each AS, and		LSPs based on internal-BGP (IBGP) labeled unicast within each AS, and
	external-BGP (EBGP) labeled unicast to extend the LSP across AS		external-BGP (EBGP) labeled unicast to extend the LSP across AS
	boundaries. This provides a seamless MPLS transport connectivity for		boundaries. This provides a seamless MPLS transport connectivity for
	any two service end-points across the entire domain. In order to		any two service end-points across the entire domain. In order to
	detect failures for such end to end services and trigger faster		detect failures for such end to end services and trigger faster
	protection and/or re-routing, S-BFD MAY be used for the Service Layer		protection and/or re-routing, S-BFD MAY be used for the Service Layer
	(e.g. for MPLS VPNs, pseudowires, etc. ) or the Transport Layer		(e.g. for MPLS VPNs, pseudowires, etc. ) or the Transport Layer
	monitoring. This brings up the need for setting up S-BFD session		monitoring. This creates the need for setting up S-BFD session
	spanning across AS domains.		spanning across AS domains.
	In a similar Segment Routing (SR) [RFC8402] multi-domain network, an		In a similar Segment Routing (SR) [RFC8402] multi-domain network, an
	end to end SR Policy [I-D.ietf-spring-segment-routing-policy] path		end to end SR Policy [I-D.ietf-spring-segment-routing-policy] path
	may be provisioned between service end-points across domains either		may be provisioned between service end-points across domains either
	via local provisioning or by a controller or signalled from a Path		via local provisioning, or by a controller or signalled from a Path
	Computation Engine (PCE). Monitoring using S-BFD can similarly be		Computation Engine (PCE) [RFC4655] . Monitoring using S-BFD can
	setup for such a SR Policy.		similarly be setup for such a SR Policy.
	Extending the automatic discovery of S-BFD discriminators of nodes		Extending the automatic discovery of S-BFD discriminators of nodes
	from within the IGP domain to across the administrative domain using		from within the IGP domain to cross an administrative domain using
	BGP-LS enables setting up of S-BFD sessions on demand across IGP		BGP-LS enables creating S-BFD sessions on demand across IGP domains.
	domains. The S-BFD discriminators for service end point nodes MAY be		The S-BFD discriminators for service end point nodes MAY be learnt by
	learnt by the PCE or a controller via the BGP-LS feed that it gets		the PCE or a controller via the BGP-LS feed that it gets from across
	from across IGP domains and it can signal or provision the remote		IGP domains, and it can signal or provision the remote S-BFD
	S-BFD discriminator on the initiator node on demand when S-BFD		discriminator on the Initiator on demand when S-BFD monitoring is
	monitoring is required. The mechanisms for the signaling of the		required. The mechanisms for the signaling of the S-BFD
	S-BFD discriminator from the PCE/controller to the initiator node and		discriminator from the PCE/controller to the Initiator and setup of
	setup of the S-BFD session is outside the scope of this document.		the S-BFD session are outside the scope of this document.
	Additionally, the service end-points themselves MAY also learn the		Additionally, the service end-points themselves MAY also learn the
	S-BFD discriminator of the remote nodes themselves by receiving the		S-BFD discriminator of the remote nodes themselves by receiving the
	BGP-LS feed via a route reflector (RR) or a centralized BGP Speaker		BGP-LS feed via a route reflector (RR) [RFC4456] or a centralized BGP
	that is consolidating the topology information across the domains.		Speaker that is consolidating the topology information across the
	The initiator node can then itself setup the S-BFD session to the		domains. The Initiator can then itself setup the S-BFD session to
	remote node without a controller/PCE assistance.		the remote node without a controller/PCE assistance.
	While this document takes examples of MPLS and SR paths, the S-BFD		While this document takes examples of MPLS and SR paths, the S-BFD
	discriminator advertisement mechanism is applicable for any S-BFD		discriminator advertisement mechanism is applicable for any S-BFD
	use-case in general.		use-case in general.
	4. BGP-LS Extensions for S-BFD Discriminator		4. BGP-LS Extensions for S-BFD Discriminator
	The BGP-LS [RFC7752] specifies the Node NLRI for advertisement of		The BGP-LS [RFC7752] specifies the Node NLRI for advertisement of
	nodes and their attributes using the BGP-LS Attribute. The S-BFD		nodes and their attributes using the BGP-LS Attribute. The S-BFD
	discriminators of a node are considered as its node level attribute		discriminators of a node are considered as its node level attribute
	and advertised as such.		and advertised as such.
	This document defines a new BGP-LS Attribute TLV called the S-BFD		This document defines a new BGP-LS Attribute TLV called the S-BFD
	Discriminators TLV and its format is as follows:		Discriminators TLV, and its format is as follows:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Discriminator 1 |		| Discriminator 1 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Discriminator 2 (Optional) |		| Discriminator 2 (Optional) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 8, line 11 ¶		skipping to change at page 8, line 11 ¶
	Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz,		Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz,
	M., and D. Steinberg, "Seamless MPLS Architecture", draft-		M., and D. Steinberg, "Seamless MPLS Architecture", draft-
	ietf-mpls-seamless-mpls-07 (work in progress), June 2014.		ietf-mpls-seamless-mpls-07 (work in progress), June 2014.
	[I-D.ietf-spring-segment-routing-policy]		[I-D.ietf-spring-segment-routing-policy]
	Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and		Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and
	P. Mattes, "Segment Routing Policy Architecture", draft-		P. Mattes, "Segment Routing Policy Architecture", draft-
	ietf-spring-segment-routing-policy-09 (work in progress),		ietf-spring-segment-routing-policy-09 (work in progress),
	November 2020.		November 2020.
			[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
			Reflection: An Alternative to Full Mesh Internal BGP
			(IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,
			<https://www.rfc-editor.org/info/rfc4456>.
			[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
			Element (PCE)-Based Architecture", RFC 4655,
			DOI 10.17487/RFC4655, August 2006,
			<https://www.rfc-editor.org/info/rfc4655>.
	[RFC5706] Harrington, D., "Guidelines for Considering Operations and		[RFC5706] Harrington, D., "Guidelines for Considering Operations and
	Management of New Protocols and Protocol Extensions",		Management of New Protocols and Protocol Extensions",
	RFC 5706, DOI 10.17487/RFC5706, November 2009,		RFC 5706, DOI 10.17487/RFC5706, November 2009,
	<https://www.rfc-editor.org/info/rfc5706>.		<https://www.rfc-editor.org/info/rfc5706>.
	[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection		[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
	(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,		(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
	<https://www.rfc-editor.org/info/rfc5880>.		<https://www.rfc-editor.org/info/rfc5880>.
	[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,		[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
	skipping to change at page 8, line 42 ¶		skipping to change at page 9, line 4 ¶
	Email: lizhenbin@huawei.com		Email: lizhenbin@huawei.com
	Shunwan Zhuang		Shunwan Zhuang
	Huawei		Huawei
	Huawei Bld., No.156 Beiqing Rd.		Huawei Bld., No.156 Beiqing Rd.
	Beijing 100095		Beijing 100095
	China		China
	Email: zhuangshunwan@huawei.com		Email: zhuangshunwan@huawei.com
			Ketan Talaulikar (editor)
	Ketan Talaulikar		Cisco Systems, Inc.
	Cisco Systems
	India		India
	Email: ketant@cisco.com		Email: ketant@cisco.com
	Sam Aldrin		Sam Aldrin
	Google, Inc		Google, Inc
	Email: aldrin.ietf@gmail.com		Email: aldrin.ietf@gmail.com
	Jeff Tantsura		Jeff Tantsura
	Apstra		Apstra
	Email: jefftant.ietf@gmail.com		Email: jefftant.ietf@gmail.com
End of changes. 14 change blocks.
	37 lines changed or deleted		47 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/