< draft-ietf-idr-bgp-ls-segment-routing-msd-10.txt		draft-ietf-idr-bgp-ls-segment-routing-msd-11.txt >
	skipping to change at page 1, line 17 ¶		skipping to change at page 1, line 17 ¶
	K. Talaulikar		K. Talaulikar
	Cisco Systems		Cisco Systems
	G. Mirsky		G. Mirsky
	ZTE Corp.		ZTE Corp.
	N. Triantafillis		N. Triantafillis
	Amazon Web Services		Amazon Web Services
	February 28, 2020		February 28, 2020
	Signaling MSD (Maximum SID Depth) using Border Gateway Protocol - Link		Signaling MSD (Maximum SID Depth) using Border Gateway Protocol - Link
	State		State
	draft-ietf-idr-bgp-ls-segment-routing-msd-10		draft-ietf-idr-bgp-ls-segment-routing-msd-11
	Abstract		Abstract
	This document defines a way for a Border Gateway Protocol - Link		This document defines a way for a Border Gateway Protocol - Link
	State (BGP-LS) speaker to advertise multiple types of supported		State (BGP-LS) speaker to advertise multiple types of supported
	Maximum SID Depths (MSDs) at node and/or link granularity.		Maximum SID Depths (MSDs) at node and/or link granularity.
	Such advertisements allow entities (e.g., centralized controllers) to		Such advertisements allow entities (e.g., centralized controllers) to
	determine whether a particular Segment Identifier (SID) stack can be		determine whether a particular Segment Identifier (SID) stack can be
	supported in a given network.		supported in a given network.
	skipping to change at page 4, line 29 ¶		skipping to change at page 4, line 29 ¶
	This document describes extensions that enable BGP-LS speakers to		This document describes extensions that enable BGP-LS speakers to
	signal the MSD capabilities (described in [RFC8491] ) of nodes and		signal the MSD capabilities (described in [RFC8491] ) of nodes and
	their links in a network to a BGP-LS consumer of network topology		their links in a network to a BGP-LS consumer of network topology
	such as a centralized controller. The centralized controller can		such as a centralized controller. The centralized controller can
	leverage this information in computation of SR paths and their		leverage this information in computation of SR paths and their
	instantiation on network nodes based on their MSD capabilities. When		instantiation on network nodes based on their MSD capabilities. When
	a BGP-LS speaker is originating the topology learnt via link-state		a BGP-LS speaker is originating the topology learnt via link-state
	routing protocols like OSPF or IS-IS, the MSD information for the		routing protocols like OSPF or IS-IS, the MSD information for the
	nodes and their links is sourced from the underlying extensions as		nodes and their links is sourced from the underlying extensions as
	defined in [RFC8476] and [RFC8491] respectively. The BGP-LS speaker		defined in [RFC8476] and [RFC8491] respectively.
	may also advertise the MSD information for the local node and its
	links when not running any link-state IGP protocol e.g. when running		The BGP-LS speaker may also advertise the MSD information for the
	BGP as the only routing protocol. The Protocol-ID field should be		local node and its links when not running any link-state IGP protocol
	set to BGP since the link and node attributes have BGP based		e.g. when running BGP as the only routing protocol. The Protocol-ID
	identifiers. Deployment model for such case would be: a limited		field should be set to BGP since the link and node attributes have
	number (meeting resiliecy requirements) of BGP-LS speakers exposing		BGP based identifiers. Deployment model for such case would be: a
	the topology to the controller, full-mesh/RouterReflectors for iBGP		limited number (meeting resiliecy requirements) of BGP-LS speakers
	or regular eBGP connectivity between every node in the topology.		exposing the topology to the controller, full-mesh/RouteReflectors
			for iBGP(Internal Border Gateway Protocol) or regular eBGP(External
			Border Gateway Protocol) connectivity between nodes in the topology.
	The extensions introduced in this document allow for advertisement of		The extensions introduced in this document allow for advertisement of
	different MSD-Types. This document does not define these MSD-Types		different MSD-Types. This document does not define these MSD-Types
	but leverages the definition, guidelines and the code-point registry		but leverages the definition, guidelines and the code-point registry
	specified in [RFC8491]. This enables sharing of MSD-Types that may		specified in [RFC8491]. This enables sharing of MSD-Types that may
	be defined in the future by the IGPs in BGP-LS.		be defined in the future by the IGPs in BGP-LS.
	3. Node MSD TLV		3. Node MSD TLV
	Node MSD is encoded in a new Node Attribute TLV [RFC7752] using the		Node MSD is encoded in a new Node Attribute TLV [RFC7752] using the
End of changes. 2 change blocks.
	10 lines changed or deleted		12 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/