draft-ietf-idr-bgp-ls-segment-routing-msd-15.txt		draft-ietf-idr-bgp-ls-segment-routing-msd-16.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: September 10, 2020 Futurewei Technologies		Expires: October 1, 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
	March 9, 2020		March 30, 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-15		draft-ietf-idr-bgp-ls-segment-routing-msd-16
	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 September 10, 2020.		This Internet-Draft will expire on October 1, 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 32 ¶		skipping to change at page 2, line 32 ¶
	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. 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 . . . . . . . . . . . . . . . . 6
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 7		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
	skipping to change at page 4, line 25 ¶		skipping to change at page 4, line 25 ¶
	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 ([RFC8491] ) of nodes and their links in		signal the MSD capabilities ([RFC8491] ) of nodes and their links in
	a network to a BGP-LS consumer of network topology such as a		a network to a BGP-LS consumer of network topology such as a
	centralized controller. The centralized controller can leverage this		centralized controller. The centralized controller can leverage this
	information in computation of SR paths based on their MSD		information in computation of SR paths based on their MSD
	capabilities. When a BGP-LS speaker is originating the topology		capabilities. When a BGP-LS speaker is originating the topology
	learnt via link-state routing protocols like OSPF or IS-IS, the MSD		learnt via link-state routing protocols such as OSPF or IS-IS, the
	information for the nodes and their links is sourced from the		MSD information for the nodes and their links is sourced from the
	underlying extensions as defined in [RFC8476] and [RFC8491]		underlying extensions as defined in [RFC8476] and [RFC8491]
	respectively.		respectively.
	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
	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
	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/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, which are defined elsewhere and were introduced		different MSD-Types, which are defined elsewhere and were introduced
	in [RFC8491]. This enables sharing of MSD-Types that may be defined		in [RFC8491]. This enables sharing of MSD-Types that may be defined
	in the future by the IGPs in BGP-LS.		in the future by the IGPs in BGP-LS.
	3. Node MSD TLV		3. Node MSD TLV
	The Node MSD ([RFC8476] [RFC8491]) is encoded in a new Node Attribute		The Node MSD ([RFC8476] [RFC8491]) is encoded in a new Node Attribute
	TLV [RFC7752] to carry the provisioned SID depth of the router		TLV [RFC7752] to carry the provisioned SID depth of the router
	identified by the corresponding Router-ID. Node MSD is the smallest		identified by the corresponding Router-ID. Node MSD is the smallest
	skipping to change at page 9, line 26 ¶		skipping to change at page 9, line 16 ¶
	[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-08 (work in progress), February 2020.		bgp-model-08 (work in progress), February 2020.
	[I-D.ietf-isis-mpls-elc]		[I-D.ietf-isis-mpls-elc]
	Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S.,		Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S.,
	and M. Bocci, "Signaling Entropy Label Capability and		and M. Bocci, "Signaling Entropy Label Capability and
	Entropy Readable Label Depth Using IS-IS", draft-ietf-		Entropy Readable Label Depth Using IS-IS", draft-ietf-
	isis-mpls-elc-10 (work in progress), October 2019.		isis-mpls-elc-11 (work in progress), March 2020.
	[I-D.ietf-ospf-mpls-elc]		[I-D.ietf-ospf-mpls-elc]
	Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S.,		Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S.,
	and M. Bocci, "Signaling Entropy Label Capability and		and M. Bocci, "Signaling Entropy Label Capability and
	Entropy Readable Label-stack Depth Using OSPF", draft-		Entropy Readable Label-stack Depth Using OSPF", draft-
	ietf-ospf-mpls-elc-12 (work in progress), October 2019.		ietf-ospf-mpls-elc-12 (work in progress), October 2019.
	[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,
End of changes. 8 change blocks.
	18 lines changed or deleted		8 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/