< draft-ietf-ospf-segment-routing-extensions-19.txt		draft-ietf-ospf-segment-routing-extensions-20.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: February 26, 2018 Cisco Systems, Inc.		Expires: April 23, 2018 Cisco Systems, Inc.
	H. Gredler		H. Gredler
	RtBrick Inc.		RtBrick Inc.
	R. Shakir		R. Shakir
	Google, Inc.		Google, Inc.
	W. Henderickx		W. Henderickx
	Nokia		Nokia
	J. Tantsura		J. Tantsura
	Individual		Individual
	August 25, 2017		October 20, 2017
	OSPF Extensions for Segment Routing		OSPF Extensions for Segment Routing
	draft-ietf-ospf-segment-routing-extensions-19		draft-ietf-ospf-segment-routing-extensions-20
	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 1, line 44 ¶		skipping to change at page 1, line 44 ¶
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 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 26, 2018.		This Internet-Draft will expire on April 23, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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		(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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	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 . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Segment Routing Identifiers . . . . . . . . . . . . . . . . . 3		2. Segment Routing Identifiers . . . . . . . . . . . . . . . . . 3
	2.1. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . . . 3		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
	3.3. SR Local Block TLV . . . . . . . . . . . . . . . . . . . 8		3.3. SR Local Block TLV . . . . . . . . . . . . . . . . . . . 8
	3.4. SRMS Preference TLV . . . . . . . . . . . . . . . . . . . 10		3.4. SRMS Preference TLV . . . . . . . . . . . . . . . . . . . 10
	4. OSPF Extended Prefix Range TLV . . . . . . . . . . . . . . . 11		4. OSPF Extended Prefix Range TLV . . . . . . . . . . . . . . . 11
	5. Prefix SID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 13		5. Prefix SID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 13
	6. Adjacency Segment Identifier (Adj-SID) . . . . . . . . . . . 16		6. Adjacency Segment Identifier (Adj-SID) . . . . . . . . . . . 16
	6.1. Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 16		6.1. Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 16
	6.2. LAN Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . 18		6.2. LAN Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . 18
	skipping to change at page 2, line 48 ¶		skipping to change at page 2, line 48 ¶
	7.2. Inter-area Segment routing in OSPFv2 . . . . . . . . . . 20		7.2. Inter-area Segment routing in OSPFv2 . . . . . . . . . . 20
	7.3. Segment Routing for External Prefixes . . . . . . . . . . 21		7.3. Segment Routing for External Prefixes . . . . . . . . . . 21
	7.4. Advertisement of Adj-SID . . . . . . . . . . . . . . . . 21		7.4. Advertisement of Adj-SID . . . . . . . . . . . . . . . . 21
	7.4.1. Advertisement of Adj-SID on Point-to-Point Links . . 21		7.4.1. Advertisement of Adj-SID on Point-to-Point Links . . 21
	7.4.2. Adjacency SID on Broadcast or NBMA Interfaces . . . . 21		7.4.2. Adjacency SID on Broadcast or NBMA Interfaces . . . . 21
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
	8.1. OSPF OSPF Router Information (RI) TLVs Registry . . . . . 22		8.1. OSPF OSPF Router Information (RI) TLVs Registry . . . . . 22
	8.2. OSPF Extended Prefix LSA TLV Registry . . . . . . . . . . 22		8.2. OSPF Extended Prefix LSA TLV Registry . . . . . . . . . . 22
	8.3. OSPF Extended Prefix LSA Sub-TLV Registry . . . . . . . . 22		8.3. OSPF Extended Prefix LSA Sub-TLV Registry . . . . . . . . 22
	8.4. OSPF Extended Link LSA Sub-TLV Registry . . . . . . . . . 22		8.4. OSPF Extended Link LSA Sub-TLV Registry . . . . . . . . . 22
			8.5. SR-Algorithm Registry . . . . . . . . . . . . . . . . . . 23
	9. Implementation Status . . . . . . . . . . . . . . . . . . . . 23		9. Implementation Status . . . . . . . . . . . . . . . . . . . . 23
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 24		10. Security Considerations . . . . . . . . . . . . . . . . . . . 25
	11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25		11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25
	12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25		12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 25		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
	13.1. Normative References . . . . . . . . . . . . . . . . . . 25		13.1. Normative References . . . . . . . . . . . . . . . . . . 26
	13.2. Informative References . . . . . . . . . . . . . . . . . 26		13.2. Informative References . . . . . . . . . . . . . . . . . 26
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
	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 4, line 17 ¶		skipping to change at page 4, line 22 ¶
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| SID/Label (variable) |		| SID/Label (variable) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	where:		where:
	Type: TBD, suggested value 1		Type: 1
	Length: Variable, 3 or 4 octet		Length: Variable, 3 or 4 octet
	SID/Label: If length is set to 3, then the 20 rightmost bits		SID/Label: If length is set to 3, then the 20 rightmost bits
	represent a label. If length is set to 4, then the value		represent a label. If length is set to 4, then the value
	represents a 32-bit SID.		represents a 32-bit SID.
	The receiving router MUST ignore the SID/Label Sub-TLV if the		The receiving router MUST ignore the SID/Label Sub-TLV if the
	length is other then 3 or 4.		length is other then 3 or 4.
	skipping to change at page 5, line 19 ¶		skipping to change at page 5, line 22 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Algorithm 1 | Algorithm... | Algorithm n | |		| Algorithm 1 | Algorithm... | Algorithm n | |
	+- -+		+- -+
	| |		| |
	+ +		+ +
	where:		where:
	Type: TBD, suggested value 8		Type: 8
	Length: Variable, dependent on number of algorithms advertised.		Variable, in octets, dependent on number of algorithms advertised.
	Algorithm: Single octet identifying the algorithm. The following		Algorithm: Single octet identifying the algorithm. The following
	values are defined by this document:		values are defined by this document:
	0: Shortest Path First (SPF) algorithm based on link metric.		0: Shortest Path First (SPF) algorithm based on link metric.
	This is the standard shortest path algorithm as computed by the		This is the standard shortest path algorithm as computed by the
	OSPF protocol. Consistent with the deployed practice for link-		OSPF protocol. Consistent with the deployed practice for link-
	state protocols, Algorithm 0 permits any node to overwrite the		state protocols, Algorithm 0 permits any node to overwrite the
	SPF path with a different path based on its local policy. If		SPF path with a different path based on its local policy. If
	the SR-Algorithm TLV is advertised, Algorithm 0 MUST be		the SR-Algorithm TLV is advertised, Algorithm 0 MUST be
	skipping to change at page 6, line 36 ¶		skipping to change at page 6, line 38 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Range Size | Reserved |		| Range Size | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sub-TLVs (variable) |		| Sub-TLVs (variable) |
	+- -+		+- -+
	| |		| |
	+ +		+ +
	where:		where:
	Type: TBD, suggested value 9		Type: 9
	Length: Variable, dependent on Sub-TLVs.		Length: Variable, in octets, dependent on Sub-TLVs.
	Range Size: 3-octet SID/label range size (i.e., the number of SIDs		Range Size: 3-octet SID/label range size (i.e., the number of SIDs
	or labels in the range including the first SID/label). It MUST be		or labels in the range including the first SID/label). It MUST be
	greater than 0.		greater than 0.
	Initially, the only supported Sub-TLV is the SID/Label Sub-TLV as		Initially, the only supported Sub-TLV is the SID/Label Sub-TLV as
	defined in Section 2.1. The SID/Label Sub-TLV MUST be included in		defined in Section 2.1. The SID/Label Sub-TLV MUST be included in
	the SID/Label Range TLV. The SID/Label advertised in the SID/Label		the SID/Label Range TLV. The SID/Label advertised in the SID/Label
	Sub-TLV represents the first SID/Label in the advertised range.		Sub-TLV represents the first SID/Label in the advertised range.
	skipping to change at page 9, line 19 ¶		skipping to change at page 9, line 19 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Range Size | Reserved |		| Range Size | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sub-TLVs (variable) |		| Sub-TLVs (variable) |
	+- -+		+- -+
	| |		| |
	+ +		+ +
	where:		where:
	Type: TBD, suggested value 12		Type: 14
	Length: Variable, dependent on Sub-TLVs.		Length: Variable, in octets, dependent on Sub-TLVs.
	Range Size: 3-octet SID/label range size (i.e., the number of SIDs		Range Size: 3-octet SID/label range size (i.e., the number of SIDs
	or labels in the range including the first SID/label). It MUST be		or labels in the range including the first SID/label). It MUST be
	greater than 0.		greater than 0.
	Initially, the only supported Sub-TLV is the SID/Label Sub-TLV as		Initially, the only supported Sub-TLV is the SID/Label Sub-TLV as
	defined in Section 2.1. The SID/Label Sub-TLV MUST be included in		defined in Section 2.1. The SID/Label Sub-TLV MUST be included in
	the SRLB TLV. The SID/Label advertised in the SID/Label Sub-TLV		the SRLB TLV. The SID/Label advertised in the SID/Label Sub-TLV
	represents the first SID/Label in the advertised range.		represents the first SID/Label in the advertised range.
	skipping to change at page 10, line 35 ¶		skipping to change at page 10, line 35 ¶
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Preference | Reserved |		| Preference | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	where:		where:
	Type: TBD, suggested value 13		Type: 13
	Length: 4 octets		Length: 4 octets
	Preference: 1 octet. SRMS preference value from 0 to 255.		Preference: 1 octet. SRMS preference value from 0 to 255.
	When multiple SRMS Preference TLVs are received from a given router,		When multiple SRMS Preference TLVs are received from a given router,
	the receiver SHOULD use the first occurrence of the TLV in the Router		the receiver SHOULD use the first occurrence of the TLV in the Router
	Information LSA. If the SRMS Preference TLV appears in multiple		Information LSA. If the SRMS Preference TLV appears in multiple
	Router Information LSAs that have different flooding scopes, the SRMS		Router Information LSAs that have different flooding scopes, the SRMS
	Preference TLV in the Router Information LSA with the narrowest		Preference TLV in the Router Information LSA with the narrowest
	skipping to change at page 11, line 47 ¶		skipping to change at page 11, line 47 ¶
	| Flags | Reserved |		| Flags | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Address Prefix (variable) |		| Address Prefix (variable) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sub-TLVs (variable) |		| Sub-TLVs (variable) |
	+- -+		+- -+
	| |		| |
	where:		where:
	Type: TBD, suggested value 2.		Type: 2
	Length: Variable, dependent on Sub-TLVs.		Length: Variable, in octets, dependent on Sub-TLVs.
	Prefix length: Length of prefix in bits.		Prefix length: Length of prefix in bits.
	AF: Address family for the prefix. Currently, the only supported		AF: Address family for the prefix. Currently, the only supported
	value is 0 for IPv4 unicast. The inclusion of address family in		value is 0 for IPv4 unicast. The inclusion of address family in
	this TLV allows for future extension.		this TLV allows for future extension.
	Range size: Represents the number of prefixes that are covered by		Range size: Represents the number of prefixes that are covered by
	the advertisement. The Range Size MUST NOT exceed the number of		the advertisement. The Range Size MUST NOT exceed the number of
	prefixes that could be satisfied by the prefix length without		prefixes that could be satisfied by the prefix length without
	skipping to change at page 13, line 24 ¶		skipping to change at page 13, line 24 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Flags | Reserved | MT-ID | Algorithm |		| Flags | Reserved | MT-ID | Algorithm |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| SID/Index/Label (variable) |		| SID/Index/Label (variable) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	where:		where:
	Type: TBD, suggested value 2.		Type: 2
	Length: 7 or 8 octets, dependent on the V-flag		Length: 7 or 8 octets, dependent on the V-flag
	Flags: Single octet field. The following flags are defined:		Flags: Single octet field. The following flags are defined:
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	+--+--+--+--+--+--+--+--+		+--+--+--+--+--+--+--+--+
	| |NP|M |E |V |L | | |		| |NP|M |E |V |L | | |
	+--+--+--+--+--+--+--+--+		+--+--+--+--+--+--+--+--+
	skipping to change at page 17, line 5 ¶		skipping to change at page 17, line 5 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Flags | Reserved | MT-ID | Weight |		| Flags | Reserved | MT-ID | Weight |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| SID/Label/Index (variable) |		| SID/Label/Index (variable) |
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	where:		where:
	Type: TBD, suggested value 2.		Type: 2
	Length: 7 or 8 octets, dependent on the V flag.		Length: 7 or 8 octets, dependent on the V flag.
	Flags: Single octet field containing the following flags:		Flags: Single octet field containing the following flags:
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	|B|V|L|G|P| |		|B|V|L|G|P| |
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	skipping to change at page 18, line 43 ¶		skipping to change at page 18, line 43 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Flags | Reserved | MT-ID | Weight |		| Flags | Reserved | MT-ID | Weight |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Neighbor ID |		| Neighbor ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| SID/Label/Index (variable) |		| SID/Label/Index (variable) |
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	where:		where:
	Type: TBD, suggested value 3.		Type: 3
	Length: 11 or 12 octets, dependent on V-flag.		Length: 11 or 12 octets, dependent on V-flag.
	Flags: same as in Section 6.1		Flags: same as in Section 6.1
	MT-ID: Multi-Topology ID (as defined in [RFC4915].		MT-ID: Multi-Topology ID (as defined in [RFC4915].
	Weight: Weight used for load-balancing purposes. The use of the		Weight: Weight used for load-balancing purposes. The use of the
	weight is defined in [I-D.ietf-spring-segment-routing].		weight is defined in [I-D.ietf-spring-segment-routing].
	skipping to change at page 22, line 25 ¶		skipping to change at page 22, line 25 ¶
	8. IANA Considerations		8. IANA Considerations
	This specification updates several existing OSPF registries.		This specification updates several existing OSPF registries.
	8.1. OSPF OSPF Router Information (RI) TLVs Registry		8.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 TLV
	o 13 - SRMS Preference TLV		o 13 - SRMS Preference TLV
			o 14 - SR Local Block TLV
	8.2. OSPF Extended Prefix LSA TLV Registry		8.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
	8.3. OSPF Extended Prefix LSA Sub-TLV Registry		8.3. OSPF Extended Prefix LSA Sub-TLV Registry
	Following values are allocated:		Following values are allocated:
	skipping to change at page 23, line 5 ¶		skipping to change at page 23, line 5 ¶
	8.4. OSPF Extended Link LSA Sub-TLV Registry		8.4. OSPF Extended Link LSA Sub-TLV Registry
	Following initial values are allocated:		Following initial values are allocated:
	o 1 - SID/Label Sub-TLV		o 1 - SID/Label Sub-TLV
	o 2 - Adj-SID Sub-TLV		o 2 - Adj-SID Sub-TLV
	o 3 - LAN Adj-SID/Label Sub-TLV		o 3 - LAN Adj-SID/Label Sub-TLV
			8.5. SR-Algorithm Registry
			IANA is requested to set up a registry called "SR-Algorithm Type".
			The registration policy for this registry is "Standards Action"
			([RFC8126] and [RFC7120]).
			Values in this registry must come from the range 0-255.
			The initial values in the SR-Algorithm Type registry are:
			0: Shortest Path First (SPF) algorithm based on link metric. This
			is the standard shortest path algorithm as computed by the IGP
			protocol. Consistent with the deployed practice for link-state
			protocols, Algorithm 0 permits any node to overwrite the SPF path
			with a different path based on its local policy.
			1: Strict Shortest Path First (SPF) algorithm based on link
			metric. The algorithm is identical to Algorithm 0 but Algorithm 1
			requires that all nodes along the path will honor the SPF routing
			decision. Local policy at the node claiming support for Algorithm
			1 MUST NOT alter the SPF paths computed by Algorithm 1.
	9. Implementation Status		9. Implementation Status
	An implementation survey with seven questions related to the		An implementation survey with seven questions related to the
	implementer's support of OSPFv2 Segment Routing was sent to the OSPF		implementer's support of OSPFv2 Segment Routing was sent to the OSPF
	WG list and several known implementers. This section contains		WG list and several known implementers. This section contains
	responses from three implementers who completed the survey. No		responses from three implementers who completed the survey. No
	external means were used to verify the accuracy of the information		external means were used to verify the accuracy of the information
	submitted by the respondents. The respondents are considered experts		submitted by the respondents. The respondents are considered experts
	on the products they reported on. Additionally, responses were		on the products they reported on. Additionally, responses were
	omitted from implementers who indicated that they have not		omitted from implementers who indicated that they have not
	skipping to change at page 25, line 5 ¶		skipping to change at page 25, line 29 ¶
	apply to these segment routing extensions. While OSPF is under a		apply to these segment routing extensions. While OSPF is under a
	single administrative domain, there may be deployments where		single administrative domain, there may be deployments where
	potential attackers have access to one or more networks in the OSPF		potential attackers have access to one or more networks in the OSPF
	routing domain. In these deployments, stronger authentication		routing domain. In these deployments, stronger authentication
	mechanisms such as those specified in [RFC7474] SHOULD be used.		mechanisms such as those specified in [RFC7474] SHOULD be used.
	Implementations must assure that malformed TLV and Sub-TLV defined in		Implementations must assure that malformed TLV and Sub-TLV defined in
	this document are detected and do not provide a vulnerability for		this document are detected and do not provide a vulnerability for
	attackers to crash the OSPFv2 router or routing process. Reception		attackers to crash the OSPFv2 router or routing process. Reception
	of malformed TLV or Sub-TLV SHOULD be counted and/or logged for		of malformed TLV or Sub-TLV SHOULD be counted and/or logged for
	further analysis.		further analysis. Logging of malformed TLVs and Sub-TLVs should be
			rate-limited to prevent a Denial of Service (DoS) attack (distributed
			or otherwise) from overloading the OSPF control plane.
	11. Contributors		11. Contributors
	The following people gave a substantial contribution to the content		The following people gave a substantial contribution to the content
	of this document: Acee Lindem, Ahmed Bashandy, Martin Horneffer,		of this document: Acee Lindem, Ahmed Bashandy, Martin Horneffer,
	Bruno Decraene, Stephane Litkowski, Igor Milojevic, Rob Shakir and		Bruno Decraene, Stephane Litkowski, Igor Milojevic, Rob Shakir and
	Saku Ytti.		Saku Ytti.
	12. Acknowledgements		12. Acknowledgements
	skipping to change at page 25, line 22 ¶		skipping to change at page 26, line 4 ¶
	Saku Ytti.		Saku Ytti.
	12. Acknowledgements		12. Acknowledgements
	We would like to thank Anton Smirnov for his contribution.		We would like to thank Anton Smirnov for his contribution.
	Thanks to Acee Lindem for the detail review of the draft,		Thanks to Acee Lindem for the detail review of the draft,
	corrections, as well as discussion about details of the encoding.		corrections, as well as discussion about details of the encoding.
	13. References		13. References
	13.1. Normative References		13.1. Normative References
			[I-D.ietf-spring-segment-routing]
			Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
			and R. Shakir, "Segment Routing Architecture", draft-ietf-
			spring-segment-routing-12 (work in progress), June 2017.
	[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, <https://www.rfc-		DOI 10.17487/RFC2119, March 1997,
	editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.		[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
	Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",		Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
	RFC 4915, DOI 10.17487/RFC4915, June 2007,		RFC 4915, DOI 10.17487/RFC4915, June 2007,
	<https://www.rfc-editor.org/info/rfc4915>.		<https://www.rfc-editor.org/info/rfc4915>.
	[RFC6845] Sheth, N., Wang, L., and J. Zhang, "OSPF Hybrid Broadcast		[RFC6845] Sheth, N., Wang, L., and J. Zhang, "OSPF Hybrid Broadcast
	and Point-to-Multipoint Interface Type", RFC 6845,		and Point-to-Multipoint Interface Type", RFC 6845,
	DOI 10.17487/RFC6845, January 2013, <https://www.rfc-		DOI 10.17487/RFC6845, January 2013,
	editor.org/info/rfc6845>.		<https://www.rfc-editor.org/info/rfc6845>.
			[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code
			Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January
			2014, <https://www.rfc-editor.org/info/rfc7120>.
	[RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W.,		[RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W.,
	Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute		Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute
	Advertisement", RFC 7684, DOI 10.17487/RFC7684, November		Advertisement", RFC 7684, DOI 10.17487/RFC7684, November
	2015, <https://www.rfc-editor.org/info/rfc7684>.		2015, <https://www.rfc-editor.org/info/rfc7684>.
	[RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and		[RFC7770] 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 7770, DOI 10.17487/RFC7770,		Router Capabilities", RFC 7770, DOI 10.17487/RFC7770,
	February 2016, <https://www.rfc-editor.org/info/rfc7770>.		February 2016, <https://www.rfc-editor.org/info/rfc7770>.
			[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
			Writing an IANA Considerations Section in RFCs", BCP 26,
			RFC 8126, DOI 10.17487/RFC8126, June 2017,
			<https://www.rfc-editor.org/info/rfc8126>.
	13.2. Informative References		13.2. Informative References
	[I-D.ietf-spring-conflict-resolution]		[I-D.ietf-spring-conflict-resolution]
	Ginsberg, L., Psenak, P., Previdi, S., and M. Pilka,		Ginsberg, L., Psenak, P., Previdi, S., and M. Pilka,
	"Segment Routing MPLS Conflict Resolution", draft-ietf-		"Segment Routing MPLS Conflict Resolution", draft-ietf-
	spring-conflict-resolution-05 (work in progress), July		spring-conflict-resolution-05 (work in progress), July
	2017.		2017.
	[I-D.ietf-spring-segment-routing]
	Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
	and R. Shakir, "Segment Routing Architecture", draft-ietf-
	spring-segment-routing-12 (work in progress), June 2017.
	[I-D.ietf-spring-segment-routing-ldp-interop]		[I-D.ietf-spring-segment-routing-ldp-interop]
	Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., and		Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., and
	S. Litkowski, "Segment Routing interworking with LDP",		S. Litkowski, "Segment Routing interworking with LDP",
	draft-ietf-spring-segment-routing-ldp-interop-08 (work in		draft-ietf-spring-segment-routing-ldp-interop-09 (work in
	progress), June 2017.		progress), September 2017.
	[I-D.ietf-spring-segment-routing-mpls]		[I-D.ietf-spring-segment-routing-mpls]
	Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,		Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
	Litkowski, S., and R. Shakir, "Segment Routing with MPLS		Litkowski, S., and R. Shakir, "Segment Routing with MPLS
	data plane", draft-ietf-spring-segment-routing-mpls-10		data plane", draft-ietf-spring-segment-routing-mpls-10
	(work in progress), June 2017.		(work in progress), June 2017.
	[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,		[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
	DOI 10.17487/RFC2328, April 1998, <https://www.rfc-		DOI 10.17487/RFC2328, April 1998,
	editor.org/info/rfc2328>.		<https://www.rfc-editor.org/info/rfc2328>.
	[RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed.,		[RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed.,
	"Security Extension for OSPFv2 When Using Manual Key		"Security Extension for OSPFv2 When Using Manual Key
	Management", RFC 7474, DOI 10.17487/RFC7474, April 2015,		Management", RFC 7474, DOI 10.17487/RFC7474, April 2015,
	<https://www.rfc-editor.org/info/rfc7474>.		<https://www.rfc-editor.org/info/rfc7474>.
	[RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B.,		[RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B.,
	Litkowski, S., Horneffer, M., and R. Shakir, "Source		Litkowski, S., Horneffer, M., and R. Shakir, "Source
	Packet Routing in Networking (SPRING) Problem Statement		Packet Routing in Networking (SPRING) Problem Statement
	and Requirements", RFC 7855, DOI 10.17487/RFC7855, May		and Requirements", RFC 7855, DOI 10.17487/RFC7855, May
End of changes. 36 change blocks.
	40 lines changed or deleted		73 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/