< draft-ietf-ospf-segment-routing-msd-12.txt		draft-ietf-ospf-segment-routing-msd-13.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: November 10, 2018 Huawei Technologies		Expires: November 18, 2018 Huawei Technologies
	S. Aldrin		S. Aldrin
	Google, Inc		Google, Inc
	P. Psenak		P. Psenak
	Cisco Systems		Cisco Systems
	May 09, 2018		May 17, 2018
	Signaling MSD (Maximum SID Depth) using OSPF		Signaling MSD (Maximum SID Depth) using OSPF
	draft-ietf-ospf-segment-routing-msd-12		draft-ietf-ospf-segment-routing-msd-13
	Abstract		Abstract
	This document defines a way for an OSPF Router to advertise multiple		This document defines a way for an OSPF 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 defines only one type of		supported in a given network. This document defines only one type of
	MSD, but defines an encoding that can support other MSD types. Here		MSD, but defines an encoding that can support other MSD types. Here
	the term OSPF means both OSPFv2 and OSPFv3.		the term OSPF means both OSPFv2 and OSPFv3.
	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 10, 2018.		This Internet-Draft will expire on November 18, 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 25 ¶		skipping to change at page 2, line 25 ¶
	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 . . . . . . . . . . . . . . . . . . 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. Base MPLS Imposition MSD . . . . . . . . . . . . . . . . . . 6		5. Base MPLS Imposition MSD . . . . . . . . . . . . . . . . . . 6
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 7		7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7		8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	10.1. Normative References . . . . . . . . . . . . . . . . . . 8		10.1. Normative References . . . . . . . . . . . . . . . . . . 8
	10.2. Informative References . . . . . . . . . . . . . . . . . 9		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
	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
	to insure that the SID stack depth of a computed path doesn't exceed		to insure that the SID stack depth of a computed path doesn't exceed
	the number of SIDs the node is capable of imposing.		the number of SIDs the node is capable of imposing.
	The PCEP SR extensions draft [I-D.ietf-pce-segment-routing] signals		The PCEP SR extensions draft [I-D.ietf-pce-segment-routing] signals
	MSD in SR PCE Capability TLV and METRIC Object. However, if PCEP is		MSD in SR PCE Capability TLV and METRIC Object. However, if PCEP is
	not supported/configured on the head-end of an SR tunnel or a		not supported/configured on the head-end of an SR tunnel or a
	Binding-SID anchor node and controller does not participate in IGP		Binding-SID anchor node and controller do not participate in IGP
	routing, it has no way to learn the MSD of nodes and links. BGP-LS		routing, it has no way to learn the MSD of nodes and links. BGP-LS
	[RFC7752] defines a way to expose topology and associated attributes		[RFC7752] defines a way to expose topology and associated attributes
	and capabilities of the nodes in that topology to a centralized		and capabilities of the nodes in that topology to a centralized
	controller. MSD signaling by BGP-LS has been defined in		controller. MSD signaling by BGP-LS has been defined in
	[I-D.ietf-idr-bgp-ls-segment-routing-msd]. Typically, BGP-LS is		[I-D.ietf-idr-bgp-ls-segment-routing-msd]. Typically, BGP-LS is
	configured on a small number of nodes that do not necessarily act as		configured on a small number of nodes that do not necessarily act as
	head-ends. In order for BGP-LS to signal MSD for all the nodes and		head-ends. In order for BGP-LS to signal MSD for all the nodes and
	links in the network MSD is relevant, MSD capabilites should be		links in the network MSD is relevant, MSD capabilites should be
	advertised by every OSPF router in the network.		advertised by every OSPF router in the network.
	Other types of MSD are known to be useful. For example,		Other types of MSD are known to be useful. For example,
	[I-D.ietf-ospf-mpls-elc] defines Readable Label Depth Capability		[I-D.ietf-ospf-mpls-elc] defines 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.
	This document defines an extension to OSPF used to advertise one or		This document defines an extension to OSPF used to advertise one or
	more types of MSD at node and/or link granularity. It also creates		more types of MSD at node and/or link granularity. It also defines
	an IANA registry for assigning MSD type identifiers. It also defines
	the Base MPLS Imposition MSD type. In the future it is expected,		the Base MPLS Imposition MSD type. In the future it is expected,
	that new MSD types will be defined to signal additional capabilities		that new MSD types will be defined to signal additional capabilities
	e.g., entropy labels, SIDs that can be imposed through recirculation,		e.g., entropy labels, SIDs that can be imposed through recirculation,
	or SIDs associated with another dataplane e.g., IPv6. Although MSD		or SIDs associated with another dataplane e.g., IPv6. Although MSD
	advertisements are associated with Segment Routing, the		advertisements are associated with Segment Routing, the
	advertisements MAY be present even if Segment Routing itself is not		advertisements MAY be present even if Segment Routing itself is not
	enabled.		enabled.
	1.1. Conventions used in this document		1.1. Conventions used in this document
	skipping to change at page 3, line 50 ¶		skipping to change at page 3, line 49 ¶
	PCE: Path Computation Element		PCE: Path Computation Element
	PCEP: Path Computation Element Protocol		PCEP: Path Computation Element Protocol
	SR: Segment Routing		SR: Segment Routing
	SID: Segment Identifier		SID: Segment Identifier
	LSA: Link state advertisement		LSA: Link state advertisement
	RI: Router Information LSA		RI: OSPF Router Information LSA
	1.2. Requirements Language		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		"OPTIONAL" in this document are to be interpreted as described in
	BCP14 [RFC2119], [RFC8174] when, and only when they appear in all		BCP14 [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
	skipping to change at page 4, line 37 ¶		skipping to change at page 4, line 37 ¶
	| MSD Type and Value ...		| MSD Type and Value ...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
	Figure 1: Node MSD TLV		Figure 1: Node MSD TLV
	The Type: TBD1		The Type: TBD1
	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 type (IANA		Value: consists of one or more pairs of a 1 octet MSD-type and 1
	Registry) and 1 octet value.		octet MSD-Value.
	MSD Type 1 (IANA Section), MSD and the Value field contains the MSD		MSD-Type: one of the values defined in the MSD Types registry defined
	of the originating router. Node MSD is a number in the range of		in [I-D.ietf-isis-segment-routing-msd].
	0-255. 0 represents lack of the ability to impose MSD stack of any
	depth; any other value represents that of the node. This value
	SHOULD represent the minimum value supported by a node.
	Other MSD Types are reserved for future extensions.		MSD-Value: a number in the range of 0-255. For all MSD-Types, 0
			represents lack of the ability to impose MSD 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 OSPF instance.
	This TLV is applicable to OSPFv2 and to OSPFv3 [RFC5838] and is		This TLV is applicable to OSPFv2 and to OSPFv3 [RFC5838] and is
	optional. The scope of the advertisement is specific to the		optional. The scope of the advertisement is specific to the
	deployment.		deployment.
	When multiple Node MSD TLVs are received from a given router, the		When multiple Node MSD TLVs are received from a given router, the
	receiver MUST use the first occurrence of the TLV in the Router		receiver MUST use the first occurrence of the TLV in the Router
	Information LSA. If the Node MSD TLV appears in multiple Router		Information LSA. If the Node MSD TLV appears in multiple Router
	Information LSAs that have different flooding scopes, the Node MSD		Information LSAs that have different flooding scopes, the Node MSD
	TLV in the Router Information LSA with the area-scoped flooding scope		TLV in the Router Information LSA with the area-scoped flooding scope
	skipping to change at page 5, line 48 ¶		skipping to change at page 5, line 48 ¶
	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 value of TBD2.		has value of TBD2.
	For OSPFv3, the Link level MSD value is advertised as an optional		For OSPFv3, the Link level MSD value is advertised as an optional
	Sub-TLV of the E-Router-LSA TLV as defined in [RFC8362], and has		Sub-TLV of the E-Router-LSA TLV as defined in [RFC8362], and has
	value of TBD3.		value of TBD3.
	Length: variable and similar to that, defined in Section 2.		Length: variable and similar to that, defined in Section 2.
	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 MSD-Value.
	MSD Type 1 (IANA Section), MSD and the Value field contains Link MSD		MSD-Type: one of the values defined in the MSD Types registry defined
	of the router originating the corresponding LSA as specified for		in [I-D.ietf-isis-segment-routing-msd].
	OSPFv2 and OSPFv3. Link MSD is a number in the range of 0-255. 0
	represents lack of the ability to impose MSD stack of any depth; any		MSD-Value field contains Link MSD of the router originating the
	other value represents that of the particular link MSD value.		corresponding LSA as specified for OSPFv2 and OSPFv3. Link MSD is a
			number in the range of 0-255. For all MSD-Types, 0 represents lack
			of the ability to impose MSD stack of any depth; any other value
			represents that of the particular link when used as an outgoing
			interface.
	Other MSD Types are reserved for future extensions.		Other MSD Types are reserved for future extensions.
	If this TLV is advertised multiple times in the same OSPFv2 Extended		If this TLV is advertised multiple times in the same OSPFv2 Extended
	Link Opaque LSA, only the first instance of the TLV is used by		Link Opaque LSA, only the first instance of the TLV is used by
	receiving OSPFv2 routers. This situation SHOULD be logged as an		receiving OSPFv2 routers. This situation SHOULD be logged as an
	error.		error.
	If this TLV is advertised multiple times for the same link in		If this TLV is advertised multiple times for the same link in
	different OSPFv2 Extended Link Opaque LSAs originated by the same		different OSPFv2 Extended Link Opaque LSAs originated by the same
	skipping to change at page 7, line 4 ¶		skipping to change at page 7, line 7 ¶
	specified when an MSD type is defined.		specified when an MSD type is defined.
	5. Base MPLS Imposition MSD		5. Base MPLS Imposition MSD
	The Base MPLS Imposition MSD (BMI-MSD) signals the total number of		The Base MPLS Imposition MSD (BMI-MSD) signals the total number of
	MPLS labels a node is capable of imposing, including all		MPLS labels a node is capable of imposing, including all
	service/transport/special labels.		service/transport/special labels.
	Absence of BMI-MSD advertisements indicates solely that the		Absence of BMI-MSD advertisements indicates solely that the
	advertising node does not support advertisement of this capability.		advertising node does not support advertisement of this capability.
			Assignment of MSD-Type for BMI-MSD is defined in
			[I-D.ietf-isis-segment-routing-msd].
	6. IANA Considerations		6. 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 [RFC4970]. IANA		Router Information (RI) TLVs Registry as defined by [RFC4970]. 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 the value 6 through the early assignment process.
	Finally, this document requests IANA to allocate a sub-TLV type		Finally, this document requests IANA to allocate a sub-TLV type
	(TBD3) from the OSPFv3 Extended-LSA Sub-TLV registry.		(TBD3) from the OSPFv3 Extended-LSA Sub-TLV registry.
	This document requests creation of an IANA managed registry under a
	new category of "Interior Gateway Protocol (IGP) Parameters" IANA
	registries to identify MSD types as proposed in Section 2, Section 3.
	The registration procedure is "Expert Review" as defined in
	[RFC8126]. The suggested registry name is "MSD types". Types are an
	unsigned 8 bit number. The following values are defined by this
	document.
	Value Name Reference
	----- --------------------- -------------
	0 Reserved This document
	1 Base MPLS Imposition MSD This document
	2-250 Unassigned This document
	251-254 Experimental This document
	255 Reserved This document
	Figure 3: MSD Types Codepoints Registry
	7. Security Considerations		7. 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] including		security analysis for OSPF protocol is done in [RFC6863] including
	analysis of both the above documents. Security considerations, as		analysis of both the above documents. Security considerations, as
	specified by [RFC7770], [RFC7684] and [RFC8362] are applicable to		specified by [RFC7770], [RFC7684] and [RFC8362] are applicable to
	this document.		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 8, line 4 ¶		skipping to change at page 7, line 39 ¶
	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
	path that can't be supported by the head-end (the node performing the		path that can't be supported by the head-end (the node performing the
	imposition).		imposition).
	8. Contributors		8. 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
	9. Acknowledgements		9. Acknowledgements
	The authors would like to thank Acee Lindem, Ketan Talaulikar,		The authors would like to thank Acee Lindem, Ketan Talaulikar, Tal
	Stephane Litkowski and Bruno Decraene for their reviews and valuable		Mizrahi, Stephane Litkowski and Bruno Decraene for their reviews and
	comments.		valuable comments.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
			[I-D.ietf-isis-segment-routing-msd]
			Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg,
			"Signaling MSD (Maximum SID Depth) using IS-IS", draft-
			ietf-isis-segment-routing-msd-12 (work in progress), May
			2018.
	[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>.
	[RFC4970] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and		[RFC4970] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and
	S. Shaffer, "Extensions to OSPF for Advertising Optional		S. Shaffer, "Extensions to OSPF for Advertising Optional
	Router Capabilities", RFC 4970, DOI 10.17487/RFC4970, July		Router Capabilities", RFC 4970, DOI 10.17487/RFC4970, July
	2007, <https://www.rfc-editor.org/info/rfc4970>.		2007, <https://www.rfc-editor.org/info/rfc4970>.
End of changes. 20 change blocks.
	48 lines changed or deleted		42 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/