draft-ietf-ospf-segment-routing-msd-16.txt		draft-ietf-ospf-segment-routing-msd-17.txt
	OSPF Working Group J. Tantsura		OSPF 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: February 20, 2019 Huawei Technologies		Expires: February 22, 2019 Huawei Technologies
	S. Aldrin		S. Aldrin
	Google, Inc		Google, Inc
	P. Psenak		P. Psenak
	Cisco Systems		Cisco Systems
	August 19, 2018		August 21, 2018
	Signaling MSD (Maximum SID Depth) using OSPF		Signaling MSD (Maximum SID Depth) using OSPF
	draft-ietf-ospf-segment-routing-msd-16		draft-ietf-ospf-segment-routing-msd-17
	Abstract		Abstract
	This document defines a way for an Open Shortest Path First (OSPF)		This document defines a way for an Open Shortest Path First (OSPF)
	Router to advertise multiple types of supported Maximum SID Depths		Router to advertise multiple types of supported Maximum SID Depths
	(MSDs) at node and/or link granularity. Such advertisements allow		(MSDs) at node and/or link granularity. Such advertisements allow
	entities (e.g., centralized controllers) to determine whether a		entities (e.g., centralized controllers) to determine whether a
	particular SID stack can be supported in a given network. This		particular SID stack can be supported in a given network. This
	document defines only one type of MSD, but defines an encoding that		document defines only one type of MSD, but defines an encoding that
	can support other MSD types. Here the term OSPF means both OSPFv2		can support other MSD types. Here the term OSPF means both OSPFv2
	skipping to change at page 1, line 42 ¶		skipping to change at page 1, line 42 ¶
	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 February 20, 2019.		This Internet-Draft will expire on February 22, 2019.
	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 26 ¶		skipping to change at page 2, line 26 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4		1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
	2. Node MSD Advertisement . . . . . . . . . . . . . . . . . . . 4		2. Node MSD Advertisement . . . . . . . . . . . . . . . . . . . 4
	3. Link MSD sub-TLV . . . . . . . . . . . . . . . . . . . . . . 5		3. Link MSD sub-TLV . . . . . . . . . . . . . . . . . . . . . . 5
	4. Using Node and Link MSD Advertisements . . . . . . . . . . . 6		4. Using Node and Link MSD Advertisements . . . . . . . . . . . 6
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 7		6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7		7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	9.1. Normative References . . . . . . . . . . . . . . . . . . 7		9.1. Normative References . . . . . . . . . . . . . . . . . . 7
	9.2. Informative References . . . . . . . . . . . . . . . . . 8		9.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
	Depth (MSD) that can be imposed at each node/link on a given SR path		Depth (MSD) that can be imposed at each node/link on a given SR path
	skipping to change at page 4, line 20 ¶		skipping to change at page 4, line 20 ¶
	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. Node MSD Advertisement		2. Node MSD Advertisement
	The node MSD TLV within the body of the OSPF RI Opaque LSA [RFC7770]		The node MSD TLV within the body of the OSPF RI Opaque LSA [RFC7770]
	is defined to carry the provisioned SID depth of the router		is defined to carry the provisioned SID depth of the router
	originating the RI LSA. Node MSD is the smallest MSD supported by		originating the RI LSA. Node MSD is the smallest MSD supported by
	the node on the set of interfaces configured for use by the		the node on the set of interfaces configured for use by the
	advertising IGP instance. MSD values may be learned via a hardware		advertising IGP instance. MSD values may be learned via a hardware
	API or may be provisioned..		API or may be provisioned.
	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... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: Node MSD TLV		Figure 1: Node MSD TLV
	The Type: TBD1		The Type: TBD1
	Length: variable (multiple of 2 octets) and represents the total		Length: variable (multiple of 2 octets) and represents the total
	length of value field in octets.		length of value field in octets.
	Value: consists of one or more pairs of a 1 octet MSD-type and 1		Value: consists of one or more pairs of a 1 octet MSD-type and 1
	skipping to change at page 5, line 29 ¶		skipping to change at page 5, line 29 ¶
	3. Link MSD sub-TLV		3. Link MSD sub-TLV
	The link sub-TLV is defined to carry the MSD of the interface		The link sub-TLV is defined to carry the MSD of the interface
	associated with the link. MSD values may be learned via a hardware		associated with the link. MSD values may be learned via a hardware
	API or may be provisioned.		API or may be provisioned.
	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... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2: Link MSD Sub-TLV		Figure 2: Link MSD Sub-TLV
	Type:		Type:
	For OSPFv2, the Link level MSD value is advertised as an optional		For OSPFv2, the Link level MSD value is advertised as an optional
	Sub-TLV of the OSPFv2 Extended Link TLV as defined in [RFC7684], and		Sub-TLV of the OSPFv2 Extended Link TLV as defined in [RFC7684], and
	has a type of TBD2.		has a type of TBD2.
	skipping to change at page 6, line 50 ¶		skipping to change at page 7, line 4 ¶
	advertisement of that MSD type. However, in some cases the lack of		advertisement of that MSD type. However, in some cases the lack of
	advertisement might imply that the functionality associated with the		advertisement might imply that the functionality associated with the
	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.		specified when an MSD type is defined.
	5. IANA Considerations		5. IANA Considerations
	This document requests IANA to allocate TLV type (TBD1) from the OSPF		This document requests IANA to allocate TLV type (TBD1) from the OSPF
	Router Information (RI) TLVs Registry as defined by [RFC7770]. IANA		Router Information (RI) TLVs Registry as defined by [RFC7770]. IANA
	has allocated the value 12 through the early assignment process.		has allocated the value 12 through the early assignment process.
	Also, this document requests IANA to allocate a sub-TLV type (TBD2)		Also, this document requests IANA to allocate a sub-TLV type (TBD2)
	from the OSPFv2 Extended Link TLV Sub-TLVs registry. IANA has		from the OSPFv2 Extended Link TLV Sub-TLVs registry. IANA has
	allocated the the value 6 through the early assignment process.		allocated the value 6 through the early assignment process. Finally,
			this document requests IANA to allocate a sub-TLV type (TBD3) from
	Finally, this document requests IANA to allocate a sub-TLV type		the OSPFv3 Extended-LSA Sub-TLV registry.
	(TBD3) from the OSPFv3 Extended-LSA Sub-TLV registry.
	6. Security Considerations		6. Security Considerations
	Security concerns for OSPF are addressed in [RFC7474]. Further		Security concerns for OSPF are addressed in [RFC7474]. Further
	security analysis for OSPF protocol is done in [RFC6863] Security		security analysis for OSPF protocol is done in [RFC6863] Security
	considerations, as specified by [RFC7770], [RFC7684] and [RFC8362]		considerations, as specified by [RFC7770], [RFC7684] and [RFC8362]
	are applicable to this document.		are applicable to this document.
	Advertisement of an incorrect MSD value may result: in a path		Advertisement of an incorrect MSD value may result: in a path
	computation failing and the service unavailable or instantiation of a		computation failing and the service unavailable or instantiation of a
	skipping to change at page 7, line 28 ¶		skipping to change at page 7, line 31 ¶
	imposition).		imposition).
	7. Contributors		7. Contributors
	The following people contributed to this document:		The following people contributed to this document:
	Les Ginsberg		Les Ginsberg
	Email: ginsberg@cisco.com		Email: ginsberg@cisco.com
	8. Acknowledgements		8. Acknowledgments
	The authors would like to thank Acee Lindem, Ketan Talaulikar, Tal		The authors would like to thank Acee Lindem, Ketan Talaulikar, Tal
	Mizrahi, Stephane Litkowski and Bruno Decraene for their reviews and		Mizrahi, Stephane Litkowski and Bruno Decraene for their reviews and
	valuable comments.		valuable comments.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[I-D.ietf-isis-segment-routing-msd]		[I-D.ietf-isis-segment-routing-msd]
End of changes. 13 change blocks.
	15 lines changed or deleted		15 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/