Diff: draft-ietf-ospf-segment-routing-extensions-09.txt - draft-ietf-ospf-segment-routing-extensions-10.txt

	< draft-ietf-ospf-segment-routing-extensions-09.txt	draft-ietf-ospf-segment-routing-extensions-10.txt >

	Open Shortest Path First IGP P. Psenak, Ed.	Open Shortest Path First IGP P. Psenak, Ed.
	Internet-Draft S. Previdi, Ed.	Internet-Draft S. Previdi, Ed.
	Intended status: Standards Track C. Filsfils	Intended status: Standards Track C. Filsfils

	Expires: January 7, 2017 Cisco Systems, Inc.	Expires: May 1, 2017 Cisco Systems, Inc.
	H. Gredler	H. Gredler

	Individual	RtBrick Inc.
	R. Shakir	R. Shakir

	Jive Communications, Inc.	Google, Inc.
	W. Henderickx	W. Henderickx
	Nokia	Nokia
	J. Tantsura	J. Tantsura
	Individual	Individual

	July 6, 2016	October 28, 2016

	OSPF Extensions for Segment Routing	OSPF Extensions for Segment Routing

	draft-ietf-ospf-segment-routing-extensions-09	draft-ietf-ospf-segment-routing-extensions-10

	Abstract	Abstract

	Segment Routing (SR) allows a flexible definition of end-to-end paths	Segment Routing (SR) allows a flexible definition of end-to-end paths
	within IGP topologies by encoding paths as sequences of topological	within IGP topologies by encoding paths as sequences of topological
	sub-paths, called "segments". These segments are advertised by the	sub-paths, called "segments". These segments are advertised by the
	link-state routing protocols (IS-IS and OSPF).	link-state routing protocols (IS-IS and OSPF).

	This draft describes the OSPF extensions required for Segment	This draft describes the OSPF extensions required for Segment
	Routing.	Routing.

	skipping to change at page 2, line 4 ¶	skipping to change at page 2, line 4 ¶

	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 http://datatracker.ietf.org/drafts/current/.	Drafts is at http://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 January 7, 2017.	This Internet-Draft will expire on May 1, 2017.

	Copyright Notice	Copyright Notice

	Copyright (c) 2016 IETF Trust and the persons identified as the	Copyright (c) 2016 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
	(http://trustee.ietf.org/license-info) in effect on the date of	(http://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 29 ¶	skipping to change at page 2, line 29 ¶
	described in the Simplified BSD License.	described in the Simplified BSD License.

	Table of Contents	Table of Contents

	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Segment Routing Identifiers . . . . . . . . . . . . . . . . . 3	2. Segment Routing Identifiers . . . . . . . . . . . . . . . . . 3
	2.1. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . . . 4	2.1. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . . . 4
	3. Segment Routing Capabilities . . . . . . . . . . . . . . . . 4	3. Segment Routing Capabilities . . . . . . . . . . . . . . . . 4
	3.1. SR-Algorithm TLV . . . . . . . . . . . . . . . . . . . . 4	3.1. SR-Algorithm TLV . . . . . . . . . . . . . . . . . . . . 4
	3.2. SID/Label Range TLV . . . . . . . . . . . . . . . . . . . 6	3.2. SID/Label Range TLV . . . . . . . . . . . . . . . . . . . 6

	4. OSPF Extended Prefix Range TLV . . . . . . . . . . . . . . . 7	3.3. SR Local Block Sub-TLV . . . . . . . . . . . . . . . . . 8
	5. Prefix SID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 9	3.4. SRMS Preference Sub-TLV . . . . . . . . . . . . . . . . . 9
	6. SID/Label Binding Sub-TLV . . . . . . . . . . . . . . . . . . 13	4. OSPF Extended Prefix Range TLV . . . . . . . . . . . . . . . 10
	6.1. ERO Metric Sub-TLV . . . . . . . . . . . . . . . . . . . 14	5. Prefix SID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 12
	6.2. ERO Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . 15	6. SID/Label Binding Sub-TLV . . . . . . . . . . . . . . . . . . 16
	6.2.1. IPv4 ERO Sub-TLV . . . . . . . . . . . . . . . . . . 15	6.1. ERO Metric Sub-TLV . . . . . . . . . . . . . . . . . . . 18
	6.2.2. Unnumbered Interface ID ERO Sub-TLV . . . . . . . . . 16	6.2. ERO Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . 18
	6.2.3. IPv4 Backup ERO Sub-TLV . . . . . . . . . . . . . . . 17	6.2.1. IPv4 ERO Sub-TLV . . . . . . . . . . . . . . . . . . 19
	6.2.4. Unnumbered Interface ID Backup ERO Sub-TLV . . . . . 18	6.2.2. Unnumbered Interface ID ERO Sub-TLV . . . . . . . . . 19
	7. Adjacency Segment Identifier (Adj-SID) . . . . . . . . . . . 19	6.2.3. IPv4 Backup ERO Sub-TLV . . . . . . . . . . . . . . . 21
	7.1. Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 20	6.2.4. Unnumbered Interface ID Backup ERO Sub-TLV . . . . . 21
	7.2. LAN Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . 21	7. Adjacency Segment Identifier (Adj-SID) . . . . . . . . . . . 23
	8. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 23	7.1. Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 23
	8.1. Intra-area Segment routing in OSPFv2 . . . . . . . . . . 23	7.2. LAN Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . 24
	8.2. Inter-area Segment routing in OSPFv2 . . . . . . . . . . 23	8. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 26
	8.3. SID for External Prefixes . . . . . . . . . . . . . . . . 25	8.1. Intra-area Segment routing in OSPFv2 . . . . . . . . . . 26
	8.4. Advertisement of Adj-SID . . . . . . . . . . . . . . . . 25	8.2. Inter-area Segment routing in OSPFv2 . . . . . . . . . . 27
	8.4.1. Advertisement of Adj-SID on Point-to-Point Links . . 25	8.3. SID for External Prefixes . . . . . . . . . . . . . . . . 28
	8.4.2. Adjacency SID on Broadcast or NBMA Interfaces . . . . 25	8.4. Advertisement of Adj-SID . . . . . . . . . . . . . . . . 28
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26	8.4.1. Advertisement of Adj-SID on Point-to-Point Links . . 28
	9.1. OSPF OSPF Router Information (RI) TLVs Registry . . . . . 26	8.4.2. Adjacency SID on Broadcast or NBMA Interfaces . . . . 28
	9.2. OSPF Extended Prefix LSA TLV Registry . . . . . . . . . . 26	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
	9.3. OSPF Extended Prefix LSA Sub-TLV Registry . . . . . . . . 26	9.1. OSPF OSPF Router Information (RI) TLVs Registry . . . . . 29
	9.4. OSPF Extended Link LSA Sub-TLV Registry . . . . . . . . . 26	9.2. OSPF Extended Prefix LSA TLV Registry . . . . . . . . . . 29
	10. Implementation Status . . . . . . . . . . . . . . . . . . . . 27	9.3. OSPF Extended Prefix LSA Sub-TLV Registry . . . . . . . . 29
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 28	9.4. OSPF Extended Link LSA Sub-TLV Registry . . . . . . . . . 30
	12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28	10. Implementation Status . . . . . . . . . . . . . . . . . . . . 30
	13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28	11. Security Considerations . . . . . . . . . . . . . . . . . . . 31
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . 29	12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31
	14.1. Normative References . . . . . . . . . . . . . . . . . . 29	13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
	14.2. Informative References . . . . . . . . . . . . . . . . . 30	14. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30	14.1. Normative References . . . . . . . . . . . . . . . . . . 32
		14.2. Informative References . . . . . . . . . . . . . . . . . 33
		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34

	1. Introduction	1. Introduction

	Segment Routing (SR) allows a flexible definition of end-to-end paths	Segment Routing (SR) allows a flexible definition of end-to-end paths
	within IGP topologies by encoding paths as sequences of topological	within IGP topologies by encoding paths as sequences of topological
	sub-paths, called "segments". These segments are advertised by the	sub-paths, called "segments". These segments are advertised by the
	link-state routing protocols (IS-IS and OSPF). Prefix segments	link-state routing protocols (IS-IS and OSPF). Prefix segments
	represent an ECMP-aware shortest-path to a prefix (or a node), as per	represent an ECMP-aware shortest-path to a prefix (or a node), as per
	the state of the IGP topology. Adjacency segments represent a hop	the state of the IGP topology. Adjacency segments represent a hop
	over a specific adjacency between two nodes in the IGP. A prefix	over a specific adjacency between two nodes in the IGP. A prefix

	skipping to change at page 5, line 49 ¶	skipping to change at page 5, line 49 ¶
	the SR-Algorithm Sub-TLV is advertised, Algorithm 0 MUST be	the SR-Algorithm Sub-TLV is advertised, Algorithm 0 MUST be
	included.	included.

	1: Strict Shortest Path First (SPF) algorithm based on link	1: Strict Shortest Path First (SPF) algorithm based on link
	metric. The algorithm is identical to Algorithm 0 but	metric. The algorithm is identical to Algorithm 0 but
	Algorithm 1 requires that all nodes along the path will honor	Algorithm 1 requires that all nodes along the path will honor
	the SPF routing decision. Local policy at the node claiming	the SPF routing decision. Local policy at the node claiming
	support for Algorithm 1 MUST NOT alter the SPF paths computed	support for Algorithm 1 MUST NOT alter the SPF paths computed
	by Algorithm 1.	by Algorithm 1.


		When multiple SR-Algorithm sub-TLVs are received from a given router
		the receiver SHOULD use the first occurrence of the sub-TLV in the
		Router Information LSA. If the SR-Algorithm sub-TLV appears in
		multiple Router Information LSAs that have different flooding scopes,
		the SR-Algorithm sub-TLV in the Router Information LSA with the
		lowest flooding scope SHOULD be used. If the SR-Algorithm sub-TLV
		appears in multiple Router Information LSAs that have the same
		flooding scope, the SR-Algorithm sub-TLV in the Router Information
		LSA with the numerically smallest Instance ID SHOULD be used and
		subsequent instances of the SR-Algorithm sub-TLV SHOULD be ignored.

	The RI LSA can be advertised at any of the defined opaque flooding	The RI LSA can be advertised at any of the defined opaque flooding
	scopes (link, area, or Autonomous System (AS)). For the purpose of	scopes (link, area, or Autonomous System (AS)). For the purpose of
	SR-Algorithm TLV advertisement, area scope flooding is required.	SR-Algorithm TLV advertisement, area scope flooding is required.

	3.2. SID/Label Range TLV	3.2. SID/Label Range TLV

	The SID/Label Range TLV is a top-level TLV of the Router Information	The SID/Label Range TLV is a top-level TLV of the Router Information
	Opaque LSA (defined in [RFC7770]).	Opaque LSA (defined in [RFC7770]).

	The SID/Label Range TLV MAY appear multiple times and has the	The SID/Label Range TLV MAY appear multiple times and has the

	skipping to change at page 7, line 35 ¶	skipping to change at page 8, line 5 ¶
	index 100 means label 1000	index 100 means label 1000
	index 199 means label 1099	index 199 means label 1099
	...	...
	index 200 means label 500	index 200 means label 500
	...	...

	The RI LSA can be advertised at any of the defined flooding scopes	The RI LSA can be advertised at any of the defined flooding scopes
	(link, area, or autonomous system (AS)). For the purpose of SID/	(link, area, or autonomous system (AS)). For the purpose of SID/
	Label Range TLV advertisement, area scope flooding is required.	Label Range TLV advertisement, area scope flooding is required.


		3.3. SR Local Block Sub-TLV

		The SR Local Block (SRLB) Sub-TLV contains the range of labels the
		node has reserved for local SIDs. Local SIDs are used, e.g., for
		Adjacency-SIDs, and may also be allocated by other components than
		OSPF protocol. As an example, an application or a controller may
		instruct the router to allocate a specific local SID. Therefore, in
		order for such applications or controllers to know what are the local
		SIDs available in the router, it is required that the router
		advertises its SRLB. The SRLB Sub-TLV is used for that purpose.

		The SR Local Block (SRLB) Sub-TLV is a top-level TLV of the Router
		Information Opaque LSA (defined in [RFC7770]).

		The SR Local Block Sub-TLV MAY only be advertised once in the Router
		Information Opaque LSA and has the following format:

		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
		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		\| Type \| Length \|
		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		\| Range Size \| Reserved \|
		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		\| Sub-TLVs (variable) \|
		+- -+
		\| \|
		+ +

		where:

		Type: TBD, suggested value 12

		Length: variable

		Range Size: 3 octets of the SID/label range. MUST be higher then
		0.

		Initially, the only supported Sub-TLV is the SID/Label TLV as defined
		in Section 2.1. The SID/Label advertised in the SID/Label TLV
		represents the first SID/Label in the advertised range.

		When multiple SRLB sub-TLVs are received from a given router the
		receiver SHOULD use the first occurrence of the sub-TLV in the Router
		Information LSA. If the SRLB sub-TLV appears in multiple Router
		Information LSAs that have different flooding scopes, the SRLB sub-
		TLV in the Router Information LSA with the lowest flooding scope
		SHOULD be used. If the SRLB sub-TLV appears in multiple Router
		Information LSAs that have the same flooding scope, the SRLB sub-TLV
		in the Router Information LSA with the numerically smallest Instance
		ID SHOULD be used and subsequent instances of the SRLB sub-TLV SHOULD
		be ignored.

		Each time a SID from the SRLB is allocated, it SHOULD also be
		reported to all components (e.g.: controller or applications) in
		order for these components to have an up-to-date view of the current
		SRLB allocation. This is required to avoid collision between
		allocation instructions.

		Within the context of OSPF, the reporting of local SIDs is done
		through OSPF Sub-TLVs such as the Adjacency-SID (Section 7).
		However, the reporting of allocated local SIDs may also be done
		through other means and protocols which mechanisms are outside the
		scope of this document.

		A router advertising the SRLB TLV may also have other label ranges,
		outside of the SRLB, used for its local allocation purposes which are
		NOT advertised in the SRLB. For example, it is possible that an
		Adjacency-SID is allocated using a local label that is not part of
		the SRLB.

		The RI LSA can be advertised at any of the defined flooding scopes
		(link, area, or autonomous system (AS)). For the purpose of SR Local
		Block Sub-TLV TLV advertisement, area scope flooding is required.

		3.4. SRMS Preference Sub-TLV

		The Segment Routing Mapping Server (SRMS) Preference sub-TLV is used
		to advertise a preference associated with the node that acts as a SR
		Mapping Server. SRMS preference is defined in
		[I-D.ietf-spring-conflict-resolution].

		The SRMS Preference Sub-TLV is a top-level TLV of the Router
		Information Opaque LSA (defined in [RFC7770]).

		The SRMS Preference Sub-TLV MAY only be advertised once in the Router
		Information Opaque LSA and has the following format:

		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
		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		\| Type \| Length \|
		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		\| Preference \| Reserved \|
		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

		where:

		Type: TBD, suggested value 13

		Length: 4 octets

		Preference: 1 octet. SRMS preference value from 0 to 255.

		When multiple SRMS Preference sub-TLVs are received from a given
		router the receiver SHOULD use the first occurrence of the sub-TLV in
		the Router Information LSA. If the SRMS Preference sub-TLV appears
		in multiple Router Information LSAs that have different flooding
		scopes, the SRLB sub-TLV in the Router Information LSA with the
		lowest flooding scope SHOULD be used. If the SRMS Preference sub-TLV
		appears in multiple Router Information LSAs that have the same
		flooding scope, the SRMS Preference sub-TLV in the Router Information
		LSA with the numerically smallest Instance ID SHOULD be used and
		subsequent instances of the SRMS Preference sub-TLV SHOULD be
		ignored.

		The RI LSA can be advertised at any of the defined flooding scopes
		(link, area, or autonomous system (AS)). For the purpose of the SRMS
		Preference Sub-TLV advertisement, AS scope flooding is required. If
		the SRMS advertisements from the SRMS server are only used inside the
		area to which the SRMS server is attached, area scope flooding may be
		used.

	4. OSPF Extended Prefix Range TLV	4. OSPF Extended Prefix Range TLV

	In some cases it is useful to advertise attributes for a range of	In some cases it is useful to advertise attributes for a range of
	prefixes. The Segment Routing Mapping Server, which is described in	prefixes. The Segment Routing Mapping Server, which is described in
	[I-D.filsfils-spring-segment-routing-ldp-interop], is an example	[I-D.filsfils-spring-segment-routing-ldp-interop], is an example
	where we need a single advertisement to advertise SIDs for multiple	where we need a single advertisement to advertise SIDs for multiple
	prefixes from a contiguous address range.	prefixes from a contiguous address range.

	The OSPF Extended Prefix Range TLV, which is a new top level TLV of	The OSPF Extended Prefix Range TLV, which is a new top level TLV of
	the Extended Prefix LSA described in [RFC7684] is defined for this	the Extended Prefix LSA described in [RFC7684] is defined for this

	skipping to change at page 10, line 34 ¶	skipping to change at page 13, line 41 ¶
	significance.	significance.

	Other bits: Reserved. These MUST be zero when sent and are	Other bits: Reserved. These MUST be zero when sent and are
	ignored when received.	ignored when received.

	MT-ID: Multi-Topology ID (as defined in [RFC4915]).	MT-ID: Multi-Topology ID (as defined in [RFC4915]).

	Algorithm: Single octet identifying the algorithm the Prefix-SID	Algorithm: Single octet identifying the algorithm the Prefix-SID
	is associated with as defined in Section 3.1.	is associated with as defined in Section 3.1.


		A router receiving a Prefix-SID from a remote node and with an
		algorithm value that such remote node has not advertised in the
		SR-Algorithm sub-TLV (Section 3.1) MUST ignore the Prefix-SID sub-
		TLV.

	SID/Index/Label: According to the V and L flags, it contains	SID/Index/Label: According to the V and L flags, it contains
	either:	either:

	A 32-bit index defining the offset in the SID/Label space	A 32-bit index defining the offset in the SID/Label space
	advertised by this router.	advertised by this router.

	A 24-bit label where the 20 rightmost bits are used for	A 24-bit label where the 20 rightmost bits are used for
	encoding the label value.	encoding the label value.

	If multiple Prefix-SIDs are advertised for the same prefix, the	If multiple Prefix-SIDs are advertised for the same prefix, the

	skipping to change at page 23, line 44 ¶	skipping to change at page 27, line 12 ¶
	areas. Similar to propagation of prefixes between areas, an ABR only	areas. Similar to propagation of prefixes between areas, an ABR only
	propagates the OSPF Extended Prefix Range TLV that it considers to be	propagates the OSPF Extended Prefix Range TLV that it considers to be
	the best from the set it received. The rules used to pick the best	the best from the set it received. The rules used to pick the best
	OSPF Extended Prefix Range TLV are described in Section 4.	OSPF Extended Prefix Range TLV are described in Section 4.

	When propagating an OSPF Extended Prefix Range TLV between areas,	When propagating an OSPF Extended Prefix Range TLV between areas,
	ABRs MUST set the IA-Flag, that is used to prevent redundant flooding	ABRs MUST set the IA-Flag, that is used to prevent redundant flooding
	of the OSPF Extended Prefix Range TLV between areas as described in	of the OSPF Extended Prefix Range TLV between areas as described in
	Section 4.	Section 4.


	If the Prefix-SID that is advertised in a Prefix SID Sub-TLV is also
	covered by the OSPF Extended Prefix Range TLV, the Prefix-SID
	advertised in Prefix SID Sub-TLV MUST be preferred.

	8.2. Inter-area Segment routing in OSPFv2	8.2. Inter-area Segment routing in OSPFv2

	In order to support SR in a multi-area environment, OSPFv2 must	In order to support SR in a multi-area environment, OSPFv2 must
	propagate Prefix-SID information between areas. The following	propagate Prefix-SID information between areas. The following
	procedure is used to propagate Prefix SIDs between areas.	procedure is used to propagate Prefix SIDs between areas.

	When an OSPF ABR advertises a Type-3 Summary LSA from an intra-area	When an OSPF ABR advertises a Type-3 Summary LSA from an intra-area
	prefix to all its connected areas, it will also originate an Extended	prefix to all its connected areas, it will also originate an Extended
	Prefix Opaque LSA, as described in [RFC7684]. The flooding scope of	Prefix Opaque LSA, as described in [RFC7684]. The flooding scope of
	the Extended Prefix Opaque LSA type will be set to area-scope. The	the Extended Prefix Opaque LSA type will be set to area-scope. The

	skipping to change at page 26, line 19 ¶	skipping to change at page 29, line 28 ¶
	9. IANA Considerations	9. IANA Considerations

	This specification updates several existing OSPF registries.	This specification updates several existing OSPF registries.

	9.1. OSPF OSPF Router Information (RI) TLVs Registry	9.1. OSPF OSPF Router Information (RI) TLVs Registry

	o 8 (IANA Preallocated) - SR-Algorithm TLV	o 8 (IANA Preallocated) - SR-Algorithm TLV

	o 9 (IANA Preallocated) - SID/Label Range TLV	o 9 (IANA Preallocated) - SID/Label Range TLV


		o 12 - SR Local Block Sub-TLV

		o 13 - SRMS Preference Sub-TLV

	9.2. OSPF Extended Prefix LSA TLV Registry	9.2. OSPF Extended Prefix LSA TLV Registry

	Following values are allocated:	Following values are allocated:

	o 2 - OSPF Extended Prefix Range TLV	o 2 - OSPF Extended Prefix Range TLV

	9.3. OSPF Extended Prefix LSA Sub-TLV Registry	9.3. OSPF Extended Prefix LSA Sub-TLV Registry

	Following values are allocated:	Following values are allocated:


	skipping to change at page 30, line 33 ¶	skipping to change at page 33, line 43 ¶
	Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E.	Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E.
	Crabbe, "Segment Routing Use Cases", draft-filsfils-	Crabbe, "Segment Routing Use Cases", draft-filsfils-
	spring-segment-routing-use-cases-01 (work in progress),	spring-segment-routing-use-cases-01 (work in progress),
	October 2014.	October 2014.

	[I-D.gredler-ospf-label-advertisement]	[I-D.gredler-ospf-label-advertisement]
	Gredler, H., Amante, S., Scholl, T., and L. Jalil,	Gredler, H., Amante, S., Scholl, T., and L. Jalil,
	"Advertising MPLS labels in OSPF", draft-gredler-ospf-	"Advertising MPLS labels in OSPF", draft-gredler-ospf-
	label-advertisement-03 (work in progress), May 2013.	label-advertisement-03 (work in progress), May 2013.


		[I-D.ietf-spring-conflict-resolution]
		Ginsberg, L., Psenak, P., Previdi, S., and M. Pilka,
		"Segment Routing Conflict Resolution", draft-ietf-spring-
		conflict-resolution-01 (work in progress), June 2016.

	[I-D.ietf-spring-segment-routing]	[I-D.ietf-spring-segment-routing]
	Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,	Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
	Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J.,	Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J.,
	and E. Crabbe, "Segment Routing Architecture", draft-ietf-	and E. Crabbe, "Segment Routing Architecture", draft-ietf-
	spring-segment-routing-00 (work in progress), December	spring-segment-routing-00 (work in progress), December
	2014.	2014.

	[I-D.minto-rsvp-lsp-egress-fast-protection]	[I-D.minto-rsvp-lsp-egress-fast-protection]
	Jeganathan, J., Gredler, H., and Y. Shen, "RSVP-TE LSP	Jeganathan, J., Gredler, H., and Y. Shen, "RSVP-TE LSP
	egress fast-protection", draft-minto-rsvp-lsp-egress-fast-	egress fast-protection", draft-minto-rsvp-lsp-egress-fast-

	skipping to change at page 31, line 29 ¶	skipping to change at page 34, line 44 ¶
	Email: sprevidi@cisco.com	Email: sprevidi@cisco.com

	Clarence Filsfils	Clarence Filsfils
	Cisco Systems, Inc.	Cisco Systems, Inc.
	Brussels	Brussels
	Belgium	Belgium

	Email: cfilsfil@cisco.com	Email: cfilsfil@cisco.com

	Hannes Gredler	Hannes Gredler

	Individual	RtBrick Inc.
	Austria

	Email: hannes@gredler.at


		Email: hannes@rtbrick.com
	Rob Shakir	Rob Shakir

	Jive Communications, Inc.	Google, Inc.
	1275 West 1600 North, Suite 100	1600 Amphitheatre Parkway
	Orem, UT 84057	Mountain View, CA 94043
	US	US


	Email: rrjs@rob.sh	Email: robjs@google.com

	Wim Henderickx	Wim Henderickx
	Nokia	Nokia
	Copernicuslaan 50	Copernicuslaan 50
	Antwerp 2018	Antwerp 2018
	BE	BE

	Email: wim.henderickx@nokia.com	Email: wim.henderickx@nokia.com

	Jeff Tantsura	Jeff Tantsura
	Individual	Individual

End of changes. 17 change blocks.
	50 lines changed or deleted	195 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/