< draft-ietf-idr-bgp-ls-segment-routing-msd-09.txt		draft-ietf-idr-bgp-ls-segment-routing-msd-10.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: April 17, 2020 Futurewei Technologies		Expires: August 31, 2020 Futurewei Technologies
	K. Talaulikar		K. Talaulikar
	Cisco Systems		Cisco Systems
	G. Mirsky		G. Mirsky
	ZTE Corp.		ZTE Corp.
	N. Triantafillis		N. Triantafillis
	Apstra, Inc.		Amazon Web Services
	October 15, 2019		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-09		draft-ietf-idr-bgp-ls-segment-routing-msd-10
	Abstract		Abstract
	This document defines a way for a Border Gateway Protocol Link-State		This document defines a way for a Border Gateway Protocol - Link
	(BGP-LS) speaker to advertise multiple types of supported Maximum SID		State (BGP-LS) speaker to advertise multiple types of supported
	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.
	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 April 17, 2020.		This Internet-Draft will expire on August 31, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 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
	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 29 ¶		skipping to change at page 2, line 29 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		5. Procedures for Defining and Using Node and Link MSD
	6. Manageability Considerations . . . . . . . . . . . . . . . . 6		Advertisements . . . . . . . . . . . . . . . . . . . . . . . 6
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 7		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8		7. Manageability Considerations . . . . . . . . . . . . . . . . 7
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8		8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8
	10.1. Normative References . . . . . . . . . . . . . . . . . . 8		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
	10.2. Informative References . . . . . . . . . . . . . . . . . 8		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
			11.1. Normative References . . . . . . . . . . . . . . . . . . 8
			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
	centralized controller, it is critical that the controller learns the		centralized controller, it is critical that the controller learn the
	Maximum SID Depth (MSD) that can be imposed at each node/link on a		Maximum SID Depth (MSD) that can be imposed at each node/link on a
	given SR path. This ensures that the Segment Identifier (SID) stack		given SR path. This ensures that the Segment Identifier (SID) stack
	depth of a computed path doesn't exceed the number of SIDs the node		depth of a computed path doesn't exceed the number of SIDs the node
	is capable of imposing.		is capable of imposing.
	[I-D.ietf-pce-segment-routing] defines how to signal MSD in the Path		[RFC8664] defines how to signal MSD in the Path Computation Element
	Computation Element Protocol (PCEP). The OSPF and IS-IS extensions		Protocol (PCEP). The OSPF and IS-IS extensions for signaling of MSD
	for signaling of MSD are defined in [RFC8476] and [RFC8491]		are defined in [RFC8476] and [RFC8491] respectively.
	respectively.
	However, if PCEP is not supported/configured on the head-end of a SR		However, if PCEP is not supported/configured on the head-end of a SR
	tunnel or a Binding-SID anchor node, and controller does not		tunnel or a Binding-SID anchor node, and controller does not
	participate in IGP routing, it has no way of learning the MSD of		participate in IGP routing, it has no way of learning the MSD of
	nodes and links. BGP-LS [RFC7752] defines a way to advertise		nodes and links. BGP-LS [RFC7752] defines a way to expose topology
	topology and associated attributes and capabilities of the nodes in		and associated attributes and capabilities of the nodes in that
	that topology to a centralized controller. This document defines		topology to a centralized controller.
	extensions to BGP-LS to advertise one or more types of MSDs at node
	and/or link granularity.
	Other types of MSD are known to be useful. For example,		This document defines extensions to BGP-LS to advertise one or more
	[I-D.ietf-ospf-mpls-elc] and [I-D.ietf-isis-mpls-elc] define Readable		types of MSDs at node and/or link granularity. Other types of MSD
	Label Depth Capability (RLDC) that is used by a head-end to insert an		are known to be useful. For example, [I-D.ietf-ospf-mpls-elc] and
	Entropy Label (EL) at a depth that can be read by transit nodes.		[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
			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
	skipping to change at page 4, line 32 ¶		skipping to change at page 4, line 32 ¶
	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. The BGP-LS speaker
	may also advertise the MSD information for the local node and its		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		links when not running any link-state IGP protocol e.g. when running
	BGP as the only routing protocol.		BGP as the only routing protocol. The Protocol-ID field should be
			set to BGP since the link and node attributes have BGP based
			identifiers. Deployment model for such case would be: a limited
			number (meeting resiliecy requirements) of BGP-LS speakers exposing
			the topology to the controller, full-mesh/RouterReflectors for iBGP
			or regular eBGP connectivity between every node 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
	skipping to change at page 6, line 19 ¶		skipping to change at page 6, line 19 ¶
	* MSD-Type : one of the values defined in the IANA registry		* MSD-Type : one of the values defined in the IANA registry
	titled "IGP MSD-Types" under the "Interior Gateway Protocol		titled "IGP MSD-Types" under the "Interior Gateway Protocol
	(IGP) Parameters" registry created by [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. IANA Considerations		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
			MSD MUST take precedence over the Node MSD. When a Link MSD-type is
			not signaled but the Node MSD-type is, then the Node MSD-type value
			MUST be considered as the MSD value for that link.
			In order to increase flooding efficiency, it is RECOMMENDED that
			routers with homogenous link MSD values advertise just the Node MSD
			value.
			The meaning of the absence of both Node and Link MSD advertisements
			for a given MSD-type is specific to the MSD-type. Generally it can
			only be inferred that the advertising node does not support
			advertisement of that MSD-type. However, in some cases the lack of
			advertisement might imply that the functionality associated with the
			MSD-type is not supported. The correct interpretation MUST be
			specified when an MSD-type is defined in [RFC8491].
			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 |
	+------------+-----------------+---------------------------+		+------------+-----------------+---------------------------+
	| 266 | Node MSD | 242/23 |		| 266 | Node MSD | 242/23 |
	| 267 | Link MSD | (22,23,25,141,222,223)/15 |		| 267 | Link MSD | (22,23,25,141,222,223)/15 |
	+------------+-----------------+---------------------------+		+------------+-----------------+---------------------------+
	6. 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
	skipping to change at page 7, line 32 ¶		skipping to change at page 8, line 5 ¶
	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 BGP and BGP-LS models is an ongoing work
	based on the [I-D.ietf-idr-bgp-model]. The management of the MSD		based on the [I-D.ietf-idr-bgp-model]. The management of the MSD
	features within an ietf segment-routing stack is also an ongoing work		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		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] ,		routing in IGPs is ongoing work for ISIS [I-D.ietf-isis-sr-yang] ,
	and OSPF [I-D.ietf-ospf-sr-yang].		and OSPF [I-D.ietf-ospf-sr-yang].
	7. 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 document does not introduce additional security issues beyond
	discussed in [RFC7752], [RFC8476] and [RFC8491]. However, [RFC7752]		discussed in [RFC7752], [RFC8476] and [RFC8491]. However, [RFC7752]
	is being revised in [I-D.ietf-idr-rfc7752bis] to provide additional		is being revised in [I-D.ietf-idr-rfc7752bis] to provide additional
	clarification in several portions of the specification after		clarification in several portions of the specification after
	receiving feedback from implementers. One of the places that is		receiving feedback from implementers. One of the places that is
	being clarified is the error handling and security. It is expected		being clarified is the error handling and security. It is expected
	that after [I-D.ietf-idr-rfc7752bis] is released that implementers		that after [I-D.ietf-idr-rfc7752bis] is released that implementers
	will update all BGP-LS base implementations improving the error		will update all BGP-LS base implementations improving the error
	handling for protocol work (including this document) that depend on		handling for protocol work (including this document) that depend on
	this function.		this function.
	8. Contributors		9. Contributors
	Siva Sivabalan		Siva Sivabalan
	Cisco Systems Inc.		Cisco Systems Inc.
	Canada		Canada
	Email: msiva@cisco.com		Email: msiva@cisco.com
	9. Acknowledgements		10. Acknowledgements
	We like to thank Acee Lindem, Stephane Litkowski and Bruno Decraene		We like to thank Acee Lindem, Stephane Litkowski and Bruno Decraene
	for their reviews and valuable comments.		for their reviews and valuable comments.
	10. References		11. References
	10.1. Normative References		11.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and		[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
	S. Ray, "North-Bound Distribution of Link-State and		S. Ray, "North-Bound Distribution of Link-State and
	Traffic Engineering (TE) Information Using BGP", RFC 7752,		Traffic Engineering (TE) Information Using BGP", RFC 7752,
	DOI 10.17487/RFC7752, March 2016,		DOI 10.17487/RFC7752, March 2016,
	skipping to change at page 8, line 47 ¶		skipping to change at page 9, line 19 ¶
	[RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak,		[RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak,
	"Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476,		"Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476,
	DOI 10.17487/RFC8476, December 2018,		DOI 10.17487/RFC8476, December 2018,
	<https://www.rfc-editor.org/info/rfc8476>.		<https://www.rfc-editor.org/info/rfc8476>.
	[RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg,		[RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg,
	"Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491,		"Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491,
	DOI 10.17487/RFC8491, November 2018,		DOI 10.17487/RFC8491, November 2018,
	<https://www.rfc-editor.org/info/rfc8491>.		<https://www.rfc-editor.org/info/rfc8491>.
	10.2. Informative References		11.2. Informative References
	[I-D.ietf-idr-bgp-model]		[I-D.ietf-idr-bgp-model]
	Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP		Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP
	YANG Model for Service Provider Networks", draft-ietf-idr-		YANG Model for Service Provider Networks", draft-ietf-idr-
	bgp-model-07 (work in progress), October 2019.		bgp-model-07 (work in progress), October 2019.
	[I-D.ietf-idr-rfc7752bis]		[I-D.ietf-idr-rfc7752bis]
	Talaulikar, K., "Distribution of Link-State and Traffic		Talaulikar, K., "Distribution of Link-State and Traffic
	Engineering Information Using BGP", draft-ietf-idr-		Engineering Information Using BGP", draft-ietf-idr-
	rfc7752bis-01 (work in progress), September 2019.		rfc7752bis-02 (work in progress), November 2019.
	[I-D.ietf-isis-mpls-elc]		[I-D.ietf-isis-mpls-elc]
	Xu, X., Kini, S., Psenak, P., Filsfils, C., and S.		Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S.,
	Litkowski, "Signaling Entropy Label Capability and Entropy		and M. Bocci, "Signaling Entropy Label Capability and
	Readable Label Depth Using IS-IS", draft-ietf-isis-mpls-		Entropy Readable Label Depth Using IS-IS", draft-ietf-
	elc-09 (work in progress), October 2019.		isis-mpls-elc-10 (work in progress), October 2019.
	[I-D.ietf-isis-sr-yang]		[I-D.ietf-isis-sr-yang]
	Litkowski, S., Qu, Y., Sarkar, P., Chen, I., and J.		Litkowski, S., Qu, Y., Sarkar, P., Chen, I., and J.
	Tantsura, "YANG Data Model for IS-IS Segment Routing",		Tantsura, "YANG Data Model for IS-IS Segment Routing",
	draft-ietf-isis-sr-yang-06 (work in progress), July 2019.		draft-ietf-isis-sr-yang-07 (work in progress), January
			2020.
	[I-D.ietf-ospf-mpls-elc]		[I-D.ietf-ospf-mpls-elc]
	Xu, X., Kini, S., Psenak, P., Filsfils, C., and S.		Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S.,
	Litkowski, "Signaling Entropy Label Capability and Entropy		and M. Bocci, "Signaling Entropy Label Capability and
	Readable Label-stack Depth Using OSPF", draft-ietf-ospf-		Entropy Readable Label-stack Depth Using OSPF", draft-
	mpls-elc-10 (work in progress), October 2019.		ietf-ospf-mpls-elc-12 (work in progress), October 2019.
	[I-D.ietf-ospf-sr-yang]		[I-D.ietf-ospf-sr-yang]
	Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem,		Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem,
	"YANG Data Model for OSPF SR (Segment Routing) Protocol",		"YANG Data Model for OSPF SR (Segment Routing) Protocol",
	draft-ietf-ospf-sr-yang-10 (work in progress), August		draft-ietf-ospf-sr-yang-11 (work in progress), February
	2019.		2020.
	[I-D.ietf-pce-segment-routing]
	Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
	and J. Hardwick, "PCEP Extensions for Segment Routing",
	draft-ietf-pce-segment-routing-16 (work in progress),
	March 2019.
	[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-13 (work in progress), July 2019.		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>.
	[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.,
			and J. Hardwick, "Path Computation Element Communication
			Protocol (PCEP) Extensions for Segment Routing", RFC 8664,
			DOI 10.17487/RFC8664, December 2019,
			<https://www.rfc-editor.org/info/rfc8664>.
	Authors' Addresses		Authors' Addresses
	Jeff Tantsura		Jeff Tantsura
	Apstra, Inc.		Apstra, Inc.
	Email: jefftant.ietf@gmail.com		Email: jefftant.ietf@gmail.com
	Uma Chunduri		Uma Chunduri
	Futurewei Technologies		Futurewei Technologies
	skipping to change at page 10, line 21 ¶		skipping to change at page 11, line 4 ¶
	Uma Chunduri		Uma Chunduri
	Futurewei Technologies		Futurewei Technologies
	Email: umac.ietf@gmail.com		Email: umac.ietf@gmail.com
	Ketan Talaulikar		Ketan Talaulikar
	Cisco Systems		Cisco Systems
	Email: ketant@cisco.com		Email: ketant@cisco.com
	Greg Mirsky		Greg Mirsky
	ZTE Corp.		ZTE Corp.
	Email: gregimirsky@gmail.com		Email: gregimirsky@gmail.com
	Nikos Triantafillis		Nikos Triantafillis
	Apstra, Inc.		Amazon Web Services
	Email: nikos@apstra.com		Email: nikost@amazon.com
End of changes. 31 change blocks.
	62 lines changed or deleted		87 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/