< draft-ietf-isis-segment-routing-msd-11.txt		draft-ietf-isis-segment-routing-msd-12.txt >
	IS-IS Working Group J. Tantsura		IS-IS Working Group J. Tantsura
	Internet-Draft Nuage Networks		Internet-Draft Nuage Networks
	Intended status: Standards Track U. Chunduri		Intended status: Standards Track U. Chunduri
	Expires: November 11, 2018 Huawei Technologies		Expires: November 17, 2018 Huawei Technologies
	S. Aldrin		S. Aldrin
	Google, Inc		Google, Inc
	L. Ginsberg		L. Ginsberg
	Cisco Systems		Cisco Systems
	May 10, 2018		May 16, 2018
	Signaling MSD (Maximum SID Depth) using IS-IS		Signaling MSD (Maximum SID Depth) using IS-IS
	draft-ietf-isis-segment-routing-msd-11		draft-ietf-isis-segment-routing-msd-12
	Abstract		Abstract
	This document defines a way for an IS-IS Router to advertise multiple		This document defines a way for an IS-IS Router to advertise multiple
	types of supported Maximum SID Depths (MSDs) at node and/or link		types of supported Maximum SID Depths (MSDs) at node and/or link
	granularity. Such advertisements allow entities (e.g., centralized		granularity. Such advertisements allow entities (e.g., centralized
	controllers) to determine whether a particular SID stack can be		controllers) to determine whether a particular SID stack can be
	supported in a given network. This document only defines one type of		supported in a given network. This document only defines one type of
	MSD maximum label imposition, but defines an encoding that can		MSD maximum label imposition, but defines an encoding that can
	support other MSD types.		support other MSD types.
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	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 November 11, 2018.		This Internet-Draft will expire on November 17, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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 19 ¶		skipping to change at page 2, line 19 ¶
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	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.2. Requirements Language . . . . . . . . . . . . . . . . . . 3		1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3
	2. Node MSD Advertisement . . . . . . . . . . . . . . . . . . . 4		2. Node MSD Advertisement . . . . . . . . . . . . . . . . . . . 4
	3. Link MSD Advertisement . . . . . . . . . . . . . . . . . . . 4		3. Link MSD Advertisement . . . . . . . . . . . . . . . . . . . 5
	4. Using Node and Link MSD Advertisements . . . . . . . . . . . 5		4. Using Node and Link MSD Advertisements . . . . . . . . . . . 6
	5. Base MPLS Imposition MSD . . . . . . . . . . . . . . . . . . 6		5. Base MPLS Imposition MSD . . . . . . . . . . . . . . . . . . 6
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 7		7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7		8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	10.1. Normative References . . . . . . . . . . . . . . . . . . 8		10.1. Normative References . . . . . . . . . . . . . . . . . . 8
	10.2. Informative References . . . . . . . . . . . . . . . . . 8		10.2. Informative References . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	When Segment Routing(SR) paths are computed by a centralized		When Segment Routing(SR) paths are computed by a centralized
	controller, it is critical that the controller learns the Maximum SID		controller, it is critical that the controller learns the Maximum SID
	skipping to change at page 4, line 34 ¶		skipping to change at page 4, line 34 ¶
	| MSD-Type | MSD Value |		| MSD-Type | MSD Value |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: Node MSD Sub-TLV		Figure 1: Node MSD Sub-TLV
	Type: 23 (allocated by IANA via the early assignment process)		Type: 23 (allocated by IANA via the early assignment process)
	Length: variable (minimum of 2, multiple of 2 octets) and represents		Length: variable (minimum of 2, multiple of 2 octets) and represents
	the total length of value field.		the total length of value field.
	Value: field consists of one or more pairs of a 1 octet MSD-Type		Value: field consists of one or more pairs of a 1 octet MSD-Type and
	(IANA Registry) and 1 octet Value.		1 octet MSD-Value.
	Node MSD value is a number in the range of 0-255. 0 represents lack		MSD-Type is one of the values defined in the MSD Types registry
	of the ability to support SID stack of any depth; any other value		created by the IANA Section of this document.
	represents that of the node. This value MUST represent the lowest
	value supported by any link configured for use by the advertising IS-		MSD-Value is a number in the range of 0-255. For all MSD-Types, 0
	IS instance.		represents lack of the ability to support SID stack of any depth; any
			other value represents that of the node. This value MUST represent
			the lowest value supported by any link configured for use by the
			advertising IS-IS instance.
	This sub-TLV is optional. The scope of the advertisement is specific		This sub-TLV is optional. The scope of the advertisement is specific
	to the deployment.		to the deployment.
			If there exist multiple Node MSD advertisements for the same MSD-Type
			originated by the same router, the procedures defined in [RFC7981]
			apply.
	3. Link MSD Advertisement		3. Link MSD Advertisement
	The link MSD sub-TLV is defined for TLVs 22, 23, 25, 141, 222, and		The link MSD sub-TLV is defined for TLVs 22, 23, 25, 141, 222, and
	223 to carry the MSD of the interface associated with the link. MSD		223 to carry the MSD of the interface associated with the link. MSD
	values may be learned via a hardware API or may be provisioned.		values may be learned via a hardware API or may be provisioned.
	0 1		0 1
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 5, line 25 ¶		skipping to change at page 5, line 31 ¶
	| MSD-Type | MSD Value |		| MSD-Type | MSD Value |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2: Link MSD Sub-TLV		Figure 2: Link MSD Sub-TLV
	Type: 15 (allocated by IANA via the early assignment process)		Type: 15 (allocated by IANA via the early assignment process)
	Length: variable (minimum of 2, multiple of 2 octets) and represents		Length: variable (minimum of 2, multiple of 2 octets) and represents
	the total length of value field.		the total length of value field.
	Value: consists of one or more pairs of a 1 octet MSD-Type (IANA		Value: consists of one or more pairs of a 1 octet MSD-Type and 1
	Registry) and 1 octet Value.		octet Value.
	Link MSD value is a number in the range of 0-255. 0 represents lack		MSD-Type is one of the values defined in the MSD Types registry
	of the ability to support SID stack of any depth; any other value		created by the IANA Section of this document.
	represents that of the link when used as an outgoing link.
			MSD-Value is a number in the range of 0-255. For all MSD-Types, 0
			represents lack of the ability to support SID stack of any depth; any
			other value represents that of the link when used as an outgoing
			link.
	This sub-TLV is optional. The scope of the advertisement is specific		This sub-TLV is optional. The scope of the advertisement is specific
	to the deployment.		to the deployment.
			If multiple Link MSD advertisements for the same MSD Type and the
			same link are received, the procedure used to select which copy is
			used is undefined.
	4. Using Node and Link MSD Advertisements		4. 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 preference over the Node MSD. When a Link MSD type is		MSD MUST take preference over the Node MSD. When a Link MSD type is
	not signalled but the Node MSD type is, then the Node MSD type value		not signalled but the Node MSD type is, then the Node MSD type value
	MUST be considered as the MSD value for that link.		MUST be considered as the MSD value for that link.
	In order to increase flooding efficiency, it is RECOMMENDED that		In order to increase flooding efficiency, it is RECOMMENDED that
	routers with homogenous link MSD values advertise just the Node MSD		routers with homogenous link MSD values advertise just the Node MSD
	value.		value.
End of changes. 12 change blocks.
	19 lines changed or deleted		34 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/