draft-ietf-idr-bgp-ls-segment-routing-msd-11.txt		draft-ietf-idr-bgp-ls-segment-routing-msd-12.txt
	IDR Working Group J. Tantsura		IDR Working Group J. Tantsura
	Internet-Draft Apstra, Inc.		Internet-Draft Apstra, Inc.
	Intended status: Standards Track U. Chunduri		Intended status: Standards Track U. Chunduri
	Expires: August 31, 2020 Futurewei Technologies		Expires: September 2, 2020 Futurewei Technologies
	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		March 1, 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-11		draft-ietf-idr-bgp-ls-segment-routing-msd-12
	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 1, line 44 ¶		skipping to change at page 1, line 44 ¶
	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 August 31, 2020.		This Internet-Draft will expire on September 2, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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
	skipping to change at page 2, line 33 ¶		skipping to change at page 2, line 33 ¶
	1.1. Conventions used in this document . . . . . . . . . . . . 3		1.1. Conventions used in this document . . . . . . . . . . . . 3
	1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3		1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3
	1.1.2. Requirements Language . . . . . . . . . . . . . . . . 4		1.1.2. Requirements Language . . . . . . . . . . . . . . . . 4
	2. Advertisement of MSD via BGP-LS . . . . . . . . . . . . . . . 4		2. Advertisement of MSD via BGP-LS . . . . . . . . . . . . . . . 4
	3. Node MSD TLV . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Node MSD TLV . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Link MSD TLV . . . . . . . . . . . . . . . . . . . . . . . . 5		4. Link MSD TLV . . . . . . . . . . . . . . . . . . . . . . . . 5
	5. Procedures for Defining and Using Node and Link MSD		5. Procedures for Defining and Using Node and Link MSD
	Advertisements . . . . . . . . . . . . . . . . . . . . . . . 6		Advertisements . . . . . . . . . . . . . . . . . . . . . . . 6
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	7. Manageability Considerations . . . . . . . . . . . . . . . . 7		7. Manageability Considerations . . . . . . . . . . . . . . . . 7
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 8		8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8		9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	11.1. Normative References . . . . . . . . . . . . . . . . . . 8		11.1. Normative References . . . . . . . . . . . . . . . . . . 8
	11.2. Informative References . . . . . . . . . . . . . . . . . 9		11.2. Informative References . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	When Segment Routing (SR) [RFC8402] paths are computed by a		When Segment Routing (SR) [RFC8402] paths are computed by a
	skipping to change at page 3, line 22 ¶		skipping to change at page 3, line 22 ¶
	This document defines extensions to BGP-LS to advertise one or more		This document defines extensions to BGP-LS to advertise one or more
	types of MSDs at node and/or link granularity. Other types of MSD		types of MSDs at node and/or link granularity. Other types of MSD
	are known to be useful. For example, [I-D.ietf-ospf-mpls-elc] and		are known to be useful. For example, [I-D.ietf-ospf-mpls-elc] and
	[I-D.ietf-isis-mpls-elc] define Readable Label Depth Capability		[I-D.ietf-isis-mpls-elc] define Readable Label Depth Capability
	(RLDC) that is used by a head-end to insert an Entropy Label (EL) at		(RLDC) that is used by a head-end to insert an Entropy Label (EL) at
	a depth that can be read by transit nodes.		a depth that can be read by transit nodes.
	In the future, it is expected that new MSD-Types will be defined to		In the future, it is expected that new MSD-Types will be defined to
	signal additional capabilities, e.g., ELs, SIDs that can be imposed		signal additional capabilities, e.g., ELs, SIDs that can be imposed
	through recirculation, or SIDs associated with another data plane		through recirculation, or SIDs associated with another data plane
	such as IPv6. MSD advertisements MAY be useful even if SR itself is		such as IPv6. MSD advertisements may be useful even if SR itself is
	not enabled. For example, in a non-SR MPLS network, MSD defines the		not enabled. For example, in a non-SR MPLS network, MSD defines the
	maximum label depth.		maximum label depth.
	1.1. Conventions used in this document		1.1. Conventions used in this document
	1.1.1. Terminology		1.1.1. Terminology
	BGP-LS: Distribution of Link-State and TE Information using Border		MSD: Maximum SID Depth - the number of SIDs supported by a node or a
	Gateway Protocol		link on a node
	MSD: Maximum SID Depth
	PCC: Path Computation Client		PCC: Path Computation Client
	PCE: Path Computation Element		PCE: Path Computation Element
	PCEP: Path Computation Element Protocol		PCEP: Path Computation Element Protocol
	SID: Segment Identifier		SID: Segment Identifier as defined in [RFC8402]
	SR: Segment routing		SR: Segment routing
	Label Imposition: Imposition is the act of modifying and/or adding		Label Imposition: Imposition is the act of modifying and/or adding
	labels to the outgoing label stack associated with a packet. This		labels to the outgoing label stack associated with a packet. This
	includes:		includes:
	o replacing the label at the top of the label stack with a new		o replacing the label at the top of the label stack with a new
	label.		label.
	o pushing one or more new labels onto the label stack. The number		o pushing one or more new labels onto the label stack.
	of labels imposed is then the sum of the number of labels that are
	replaced and the number of labels that are pushed. See [RFC3031]		o The number of labels imposed is then the sum of the number of
	for further details.		labels that are replaced and the number of labels that are pushed.
			See [RFC3031] for further details.
	1.1.2. Requirements Language		1.1.2. Requirements Language
	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. Advertisement of MSD via BGP-LS		2. Advertisement of MSD via BGP-LS
	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 ([RFC8491] ) of nodes and their links in
	their links in a network to a BGP-LS consumer of network topology		a network to a BGP-LS consumer of network topology such as a
	such as a centralized controller. The centralized controller can		centralized controller. The centralized controller can leverage this
	leverage this information in computation of SR paths and their		information in computation of SR paths and their instantiation on
	instantiation on network nodes based on their MSD capabilities. When		network nodes based on their MSD capabilities. When a BGP-LS speaker
	a BGP-LS speaker is originating the topology learnt via link-state		is originating the topology learnt via link-state routing protocols
	routing protocols like OSPF or IS-IS, the MSD information for the		like OSPF or IS-IS, the MSD information for the nodes and their links
	nodes and their links is sourced from the underlying extensions as		is sourced from the underlying extensions as defined in [RFC8476] and
	defined in [RFC8476] and [RFC8491] respectively.		[RFC8491] respectively.
	The BGP-LS speaker may also advertise the MSD information for the		The BGP-LS speaker may also advertise the MSD information for the
	local node and its links when not running any link-state IGP protocol		local node and its links when not running any link-state IGP protocol
	e.g. when running BGP as the only routing protocol. The Protocol-ID		e.g. when running BGP as the only routing protocol. The Protocol-ID
	field should be set to BGP since the link and node attributes have		field should be set to BGP since the link and node attributes have
	BGP based identifiers. Deployment model for such case would be: a		BGP based identifiers. Deployment model for such case would be: a
	limited number (meeting resiliecy requirements) of BGP-LS speakers		limited number (meeting resiliecy requirements) of BGP-LS speakers
	exposing the topology to the controller, full-mesh/RouteReflectors		exposing the topology to the controller, full-mesh/RouteReflectors
	for iBGP(Internal Border Gateway Protocol) or regular eBGP(External		for iBGP(Internal Border Gateway Protocol) or regular eBGP(External
	Border Gateway Protocol) connectivity between nodes in the topology.		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, which are defined elsewhere and were introduced
	but leverages the definition, guidelines and the code-point registry		in [RFC8491]. This enables sharing of MSD-Types that may be defined
	specified in [RFC8491]. This enables sharing of MSD-Types that may		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		The Node MSD ([RFC8476] [RFC8491]) is encoded in a new Node Attribute
	following format:		TLV [RFC7752] to carry the provisioned SID depth of the router
			identified by the corresponding Router-ID. Node MSD is the smallest
			MSD supported by the node on the set of interfaces configured for
			use. MSD values may be learned via a hardware API or may be
			provisioned. The following format is used:
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MSD-Type | MSD-Value | MSD-Type... | MSD-Value... |		| MSD-Type | MSD-Value | MSD-Type... | MSD-Value... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: Node MSD TLV Format		Figure 1: Node MSD TLV Format
	skipping to change at page 5, line 25 ¶		skipping to change at page 5, line 25 ¶
	Where:		Where:
	o Type: 266		o Type: 266
	o Length: variable (multiple of 2); represents the total length of		o Length: variable (multiple of 2); represents the total length of
	the value field in octets.		the value field in octets.
	o Value : consists of one or more pairs of a 1-octet MSD-Type and		o Value : consists of one or more pairs of a 1-octet MSD-Type and
	1-octet MSD-Value.		1-octet MSD-Value.
	* MSD-Type : one of the values defined in the IANA registry		* MSD-Type : one of the values defined in the "IGP MSD-Types"
	titled "IGP MSD-Types" under the "Interior Gateway Protocol		registry defined in [RFC8491].
	(IGP) Parameters" registry created by [RFC8491].
	* MSD-Value : a number in the range of 0-255. For all MSD-Types,		* MSD-Value : a number in the range of 0-255. For all MSD-Types,
	0 represents the lack of ability to impose an MSD stack of any		0 represents the lack of ability to impose an MSD stack of any
	depth; any other value represents that of the node. This value		depth; any other value represents that of the node. This value
	MUST represent the lowest value supported by any link		MUST represent the lowest value supported by any link
	configured for use by the advertising protocol instance.		configured for use by the advertising protocol instance.
	4. Link MSD TLV		4. Link MSD TLV
	Link MSD is encoded in a new Link Attribute TLV [RFC7752] using the		The Link MSD ([RFC8476] [RFC8491]) is defined to carry the MSD of the
	following format:		interface associated with the link. It is encoded in a new Link
			Attribute TLV [RFC7752] using the following format:
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MSD-Type | MSD-Value | MSD-Type... | MSD-Value... |		| MSD-Type | MSD-Value | MSD-Type... | MSD-Value... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2: Link MSD TLV Format		Figure 2: Link MSD TLV Format
	Where:		Where:
	o Type: 267		o Type: 267
	o Length: variable (multiple of 2); represents the total length of		o Length: variable (multiple of 2); represents the total length of
	the value field in octets.		the value field in octets.
	o Value : consists of one or more pairs of a 1-octet MSD-Type and		o Value : consists of one or more pairs of a 1-octet MSD-Type and
	1-octet MSD-Value.		1-octet MSD-Value.
	* MSD-Type : one of the values defined in the IANA registry		* MSD-Type : MSD-Type : one of the values defined in the "IGP
	titled "IGP MSD-Types" under the "Interior Gateway Protocol		MSD-Types" registry defined in [RFC8491].
	(IGP) Parameters" registry created by [RFC8491].
	* MSD-Value : a number in the range of 0-255. For all MSD-Types,		* MSD-Value : a number in the range of 0-255. For all MSD-Types,
	0 represents the lack of ability to impose an MSD stack of any		0 represents the lack of ability to impose an MSD stack of any
	depth; any other value represents that of the link when used as		depth; any other value represents that of the link when used as
	an outgoing interface.		an outgoing interface.
	5. Procedures for Defining and Using Node and Link MSD Advertisements		5. Procedures for Defining and Using Node and Link MSD Advertisements
	When Link MSD is present for a given MSD-type, the value of the Link		When Link MSD is present for a given MSD-type, the value of the Link
	MSD MUST take precedence over the Node MSD. When a Link MSD-type is		MSD MUST take precedence over the Node MSD. When a Link MSD-type is
	skipping to change at page 6, line 45 ¶		skipping to change at page 6, line 44 ¶
	MSD-type is not supported. The correct interpretation MUST be		MSD-type is not supported. The correct interpretation MUST be
	specified when an MSD-type is defined in [RFC8491].		specified when an MSD-type is defined in [RFC8491].
	6. IANA Considerations		6. IANA Considerations
	This document requests assigning code-points from the registry "BGP-		This document requests assigning code-points from the registry "BGP-
	LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute		LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute
	TLVs" based on table below. Early allocation for these code-points		TLVs" based on table below. Early allocation for these code-points
	have been done by IANA.		have been done by IANA.
	+------------+-----------------+---------------------------+		+------------+-----------------+---------------------------+-------------------+
	| Code Point | Description | IS-IS TLV/Sub-TLV |		| Code Point | Description | IS-IS TLV/Sub-TLV | Reference |
	+------------+-----------------+---------------------------+		+------------+-----------------+---------------------------+-------------------+
	| 266 | Node MSD | 242/23 |		| 266 | Node MSD | 242/23 | This document |
	| 267 | Link MSD | (22,23,25,141,222,223)/15 |		| 267 | Link MSD | (22,23,25,141,222,223)/15 | This document |
	+------------+-----------------+---------------------------+		+------------+-----------------+---------------------------+-------------------+
	7. Manageability Considerations		7. Manageability Considerations
	The new protocol extensions introduced in this document augment the		The new protocol extensions introduced in this document augment the
	existing IGP topology information that is distributed via [RFC7752].		existing IGP topology information that is distributed via [RFC7752].
	Procedures and protocol extensions defined in this document do not		Procedures and protocol extensions defined in this document do not
	affect the BGP protocol operations and management other than as		affect the BGP protocol operations and management other than as
	discussed in the Manageability Considerations section of [RFC7752].		discussed in the Manageability Considerations section of [RFC7752].
	Specifically, the malformed attribute tests for syntactic checks in		Specifically, the malformed attribute tests for syntactic checks in
	the Fault Management section of [RFC7752] now encompass the new BGP-		the Fault Management section of [RFC7752] now encompass the new BGP-
	LS Attribute TLVs defined in this document. The semantic or content		LS Attribute TLVs defined in this document. The semantic or content
	checking for the TLVs specified in this document and their		checking for the TLVs specified in this document and their
	association with the BGP-LS NLRI types or their BGP-LS Attribute is		association with the BGP-LS NLRI types or their BGP-LS Attribute is
	left to the consumer of the BGP-LS information (e.g. an application		left to the consumer of the BGP-LS information (e.g. an application
	or a controller) and not the BGP protocol.		or a controller) and not the BGP protocol.
	A consumer of the BGP-LS information retrieves this information over		A consumer of the BGP-LS information retrieves this information over
	a BGP-LS session (refer Section 1 and 2 of [RFC7752]). The handling		a BGP-LS session (refer Section 1 and 2 of [RFC7752]).
	of semantic or content errors by the consumer would be dictated by
	the nature of its application usage and hence is beyond the scope of
	this document.
	This document only introduces new Attribute TLVs and any syntactic		This document only introduces new Attribute TLVs and any syntactic
	error in them would result in the BGP-LS Attribute being discarded		error in them would result in the BGP-LS Attribute being discarded
	with an error log. The MSD information introduced in BGP-LS by this		[RFC7752]. The MSD information introduced in BGP-LS by this
	specification, may be used by BGP-LS consumer applications like a SR		specification, may be used by BGP-LS consumer applications like a SR
	path computation engine (PCE) to learn the SR SID-stack handling		path computation engine (PCE) to learn the SR SID-stack handling
	capabilities of the nodes in the topology. This can enable the SR		capabilities of the nodes in the topology. This can enable the SR
	PCE to perform path computations taking into consideration the size		PCE to perform path computations taking into consideration the size
	of SID Stack that the specific headend node may be able to impose.		of SID Stack that the specific headend node may be able to impose.
	Errors in the encoding or decoding of the MSD information may result		Errors in the encoding or decoding of the MSD information may result
	in the unavailability of such information to the SR PCE or incorrect		in the unavailability of such information to the SR PCE or incorrect
	information being made available to it. This may result in the		information being made available to it. This may result in the
	headend node not being able to instantiate the desired SR path in its		headend node not being able to instantiate the desired SR path in its
	forwarding and provide the SR based optimization functionality. The		forwarding and provide the SR based optimization functionality. The
	handling of such errors by applications like SR PCE may be		handling of such errors by applications like SR PCE may be
	implementation specific and out of scope of this document.		implementation specific and out of scope of this document.
	The extensions specified in this document, do not specify any new		The extensions specified in this document, do not specify any new
	configuration or monitoring aspects in BGP or BGP-LS. The		configuration or monitoring aspects in BGP or BGP-LS. The
	specification of BGP models BGP and BGP-LS models is an ongoing work		specification of BGP models is an ongoing work based on the
	based on the [I-D.ietf-idr-bgp-model]. The management of the MSD		[I-D.ietf-idr-bgp-model].
	features within an ietf segment-routing stack is also an ongoing work
	based on the [I-D.ietf-spring-sr-yang]. Management of the segment
	routing in IGPs is ongoing work for ISIS [I-D.ietf-isis-sr-yang] ,
	and OSPF [I-D.ietf-ospf-sr-yang].
	8. Security Considerations		8. Security Considerations
	The advertisement of an incorrect MSD value may have negative		The advertisement of an incorrect MSD value may have negative
	consequences. If the value is smaller than supported, path		consequences. If the value is smaller than supported, path
	computation may fail to compute a viable path. If the value is		computation may fail to compute a viable path. If the value is
	larger than supported, an attempt to instantiate a path that can't be		larger than supported, an attempt to instantiate a path that can't be
	supported by the head-end (the node performing the SID imposition)		supported by the head-end (the node performing the SID imposition)
	may occur. The presence of this information may also inform an		may occur. The presence of this information may also inform an
	attacker of how to induce any of the aforementioned conditions.		attacker of how to induce any of the aforementioned conditions.
	The document does not introduce additional security issues beyond		The procedures and protocol extensions defined in this document do
	discussed in [RFC7752], [RFC8476] and [RFC8491]. However, [RFC7752]		not affect the BGP security model. See the "Security Considerations"
	is being revised in [I-D.ietf-idr-rfc7752bis] to provide additional		section of [RFC4271] for a discussion of BGP security. Also, refer
	clarification in several portions of the specification after		to [RFC4272] and [RFC6952] for analyses of security issues for BGP.
	receiving feedback from implementers. One of the places that is		Security considerations for acquiring and distributing BGP-LS
	being clarified is the error handling and security. It is expected		information are discussed in [RFC7752]. The TLVs introduced in this
	that after [I-D.ietf-idr-rfc7752bis] is released that implementers		document are used to propagate the MSD IGP extensions defined in
	will update all BGP-LS base implementations improving the error		[RFC8476] [RFC8491]. It is assumed that the IGP instances
	handling for protocol work (including this document) that depend on		originating these TLVs will support all the required security (as
	this function.		described in [RFC8476] [RFC8491]) in order to prevent any security
			issues when propagating the TLVs into BGP-LS. The advertisement of
			the node and link attribute information defined in this document
			presents no additional risk beyond that associated with the existing
			node and link attribute information already supported in [RFC7752].
	9. Contributors		9. Contributors
	Siva Sivabalan		Siva Sivabalan
	Cisco Systems Inc.		Cisco Systems Inc.
	Canada		Canada
	Email: msiva@cisco.com		Email: msiva@cisco.com
	10. Acknowledgements		10. Acknowledgements
	skipping to change at page 10, line 21 ¶		skipping to change at page 10, line 15 ¶
	[I-D.ietf-spring-sr-yang]		[I-D.ietf-spring-sr-yang]
	Litkowski, S., Qu, Y., Lindem, A., Sarkar, P., and J.		Litkowski, S., Qu, Y., Lindem, A., Sarkar, P., and J.
	Tantsura, "YANG Data Model for Segment Routing", draft-		Tantsura, "YANG Data Model for Segment Routing", draft-
	ietf-spring-sr-yang-15 (work in progress), January 2020.		ietf-spring-sr-yang-15 (work in progress), January 2020.
	[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol		[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
	Label Switching Architecture", RFC 3031,		Label Switching Architecture", RFC 3031,
	DOI 10.17487/RFC3031, January 2001,		DOI 10.17487/RFC3031, January 2001,
	<https://www.rfc-editor.org/info/rfc3031>.		<https://www.rfc-editor.org/info/rfc3031>.
			[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
			Border Gateway Protocol 4 (BGP-4)", RFC 4271,
			DOI 10.17487/RFC4271, January 2006,
			<https://www.rfc-editor.org/info/rfc4271>.
			[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
			RFC 4272, DOI 10.17487/RFC4272, January 2006,
			<https://www.rfc-editor.org/info/rfc4272>.
			[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
			BGP, LDP, PCEP, and MSDP Issues According to the Keying
			and Authentication for Routing Protocols (KARP) Design
			Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013,
			<https://www.rfc-editor.org/info/rfc6952>.
	[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,		[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
	Decraene, B., Litkowski, S., and R. Shakir, "Segment		Decraene, B., Litkowski, S., and R. Shakir, "Segment
	Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,		Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
	July 2018, <https://www.rfc-editor.org/info/rfc8402>.		July 2018, <https://www.rfc-editor.org/info/rfc8402>.
	[RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,		[RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
	and J. Hardwick, "Path Computation Element Communication		and J. Hardwick, "Path Computation Element Communication
	Protocol (PCEP) Extensions for Segment Routing", RFC 8664,		Protocol (PCEP) Extensions for Segment Routing", RFC 8664,
	DOI 10.17487/RFC8664, December 2019,		DOI 10.17487/RFC8664, December 2019,
	<https://www.rfc-editor.org/info/rfc8664>.		<https://www.rfc-editor.org/info/rfc8664>.
End of changes. 21 change blocks.
	66 lines changed or deleted		78 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/