< draft-ietf-ospf-segment-routing-extensions-06.txt		draft-ietf-ospf-segment-routing-extensions-07.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: June 24, 2016 Cisco Systems, Inc.		Expires: September 22, 2016 Cisco Systems, Inc.
	H. Gredler		H. Gredler
	Individual		Individual
	R. Shakir		R. Shakir
	Jive Communications, Inc.		Jive Communications, Inc.
	W. Henderickx		W. Henderickx
	Alcatel-Lucent		Alcatel-Lucent
	J. Tantsura		J. Tantsura
	Ericsson		Ericsson
	December 22, 2015		March 21, 2016
	OSPF Extensions for Segment Routing		OSPF Extensions for Segment Routing
	draft-ietf-ospf-segment-routing-extensions-06		draft-ietf-ospf-segment-routing-extensions-07
	Abstract		Abstract
	Segment Routing (SR) allows for a flexible definition of end-to-end		Segment Routing (SR) allows for a flexible definition of end-to-end
	paths within IGP topologies by encoding paths as sequences of		paths within IGP topologies by encoding paths as sequences of
	topological sub-paths, called "segments". These segments are		topological sub-paths, called "segments". These segments are
	advertised by the link-state routing protocols (IS-IS and OSPF).		advertised by the 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 June 24, 2016.		This Internet-Draft will expire on September 22, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 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
	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 . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 5		3.2. SID/Label Range TLV . . . . . . . . . . . . . . . . . . . 6
	4. OSPF Extended Prefix Range TLV . . . . . . . . . . . . . . . 7		4. OSPF Extended Prefix Range TLV . . . . . . . . . . . . . . . 7
	5. Prefix SID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 9		5. Prefix SID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 9
	6. SID/Label Binding Sub-TLV . . . . . . . . . . . . . . . . . . 13		6. SID/Label Binding Sub-TLV . . . . . . . . . . . . . . . . . . 13
	6.1. ERO Metric Sub-TLV . . . . . . . . . . . . . . . . . . . 14		6.1. ERO Metric Sub-TLV . . . . . . . . . . . . . . . . . . . 14
	6.2. ERO Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . 15		6.2. ERO Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . 15
	6.2.1. IPv4 ERO Sub-TLV . . . . . . . . . . . . . . . . . . 15		6.2.1. IPv4 ERO Sub-TLV . . . . . . . . . . . . . . . . . . 15
	6.2.2. Unnumbered Interface ID ERO Sub-TLV . . . . . . . . . 16		6.2.2. Unnumbered Interface ID ERO Sub-TLV . . . . . . . . . 16
	6.2.3. IPv4 Backup ERO Sub-TLV . . . . . . . . . . . . . . . 17		6.2.3. IPv4 Backup ERO Sub-TLV . . . . . . . . . . . . . . . 17
	6.2.4. Unnumbered Interface ID Backup ERO Sub-TLV . . . . . 18		6.2.4. Unnumbered Interface ID Backup ERO Sub-TLV . . . . . 18
	7. Adjacency Segment Identifier (Adj-SID) . . . . . . . . . . . 19		7. Adjacency Segment Identifier (Adj-SID) . . . . . . . . . . . 19
	7.1. Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 19		7.1. Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 19
	7.2. LAN Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . 21		7.2. LAN Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . 21
	8. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 22		8. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 22
	8.1. Intra-area Segment routing in OSPFv2 . . . . . . . . . . 22		8.1. Intra-area Segment routing in OSPFv2 . . . . . . . . . . 22
	8.2. Inter-area Segment routing in OSPFv2 . . . . . . . . . . 23		8.2. Inter-area Segment routing in OSPFv2 . . . . . . . . . . 23
	8.3. SID for External Prefixes . . . . . . . . . . . . . . . . 24		8.3. SID for External Prefixes . . . . . . . . . . . . . . . . 24
	8.4. Advertisement of Adj-SID . . . . . . . . . . . . . . . . 24		8.4. Advertisement of Adj-SID . . . . . . . . . . . . . . . . 24
	8.4.1. Advertisement of Adj-SID on Point-to-Point Links . . 24		8.4.1. Advertisement of Adj-SID on Point-to-Point Links . . 25
	8.4.2. Adjacency SID on Broadcast or NBMA Interfaces . . . . 25		8.4.2. Adjacency SID on Broadcast or NBMA Interfaces . . . . 25
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
	9.1. OSPF OSPF Router Information (RI) TLVs Registry . . . . . 25		9.1. OSPF OSPF Router Information (RI) TLVs Registry . . . . . 25
	9.2. OSPF Extended Prefix LSA TLV Registry . . . . . . . . . . 25		9.2. OSPF Extended Prefix LSA TLV Registry . . . . . . . . . . 25
	9.3. OSPF Extended Prefix LSA Sub-TLV Registry . . . . . . . . 25		9.3. OSPF Extended Prefix LSA Sub-TLV Registry . . . . . . . . 25
	9.4. OSPF Extended Link LSA Sub-TLV Registry . . . . . . . . . 26		9.4. OSPF Extended Link LSA Sub-TLV Registry . . . . . . . . . 26
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 26		10. Security Considerations . . . . . . . . . . . . . . . . . . . 26
	11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26		11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26
	12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26		12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
	13.1. Normative References . . . . . . . . . . . . . . . . . . 27		13.1. Normative References . . . . . . . . . . . . . . . . . . 27
	13.2. Informative References . . . . . . . . . . . . . . . . . 27		13.2. Informative References . . . . . . . . . . . . . . . . . 27
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
	1. Introduction		1. Introduction
	Segment Routing (SR) allows for a flexible definition of end-to-end		Segment Routing (SR) allows for a flexible definition of end-to-end
	paths within IGP topologies by encoding paths as sequences of		paths within IGP topologies by encoding paths as sequences of
	topological sub-paths, called "segments". These segments are		topological sub-paths, called "segments". These segments are
	advertised by the link-state routing protocols (IS-IS and OSPF).		advertised by the link-state routing protocols (IS-IS and OSPF).
	skipping to change at page 5, line 33 ¶		skipping to change at page 5, line 33 ¶
	Length: variable		Length: variable
	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.		SPF path with a different path based on its local policy. If
			the SR-Algorithm Sub-TLV is advertised, Algorithm 0 MUST be
			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
	the support of Algorithm 1 MUST NOT alter the forwarding		the support of Algorithm 1 MUST NOT alter the forwarding
	decision computed by Algorithm 1.		decision computed by Algorithm 1.
	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
	skipping to change at page 22, line 17 ¶		skipping to change at page 22, line 17 ¶
	assigned to other adjacencies as well).		assigned to other adjacencies as well).
	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].
	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].
			Neighbor ID: The Router ID of the neighbor for which the Adj-SID
			is advertised.
	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.
	8. Elements of Procedure		8. Elements of Procedure
	skipping to change at page 23, line 45 ¶		skipping to change at page 23, line 50 ¶
	area and find the advertising router associated with the best path		area and find the advertising router associated with the best path
	to that prefix.		to that prefix.
	The ABR will then determine if such router advertised a Prefix-SID		The ABR will then determine if such router advertised a Prefix-SID
	for the prefix and use it when advertising the Prefix-SID to other		for the prefix and use it when advertising the Prefix-SID to other
	connected areas.		connected areas.
	If no Prefix-SID was advertised for the prefix in the source area		If no Prefix-SID was advertised for the prefix in the source area
	by the router that contributes to the best path to the prefix, the		by the router that contributes to the best path to the prefix, the
	originating ABR will use the Prefix-SID advertised by any other		originating ABR will use the Prefix-SID advertised by any other
	router (e.g.: a Prefix-SID coming from an SR Mapping Server as		router when propagating the Prefix-SID for the prefix to other
	defined in [I-D.filsfils-spring-segment-routing-ldp-interop]) when		areas.
	propagating the Prefix-SID for the prefix to other areas.
	When an OSPF ABR advertises Type-3 Summary LSAs from an inter-area		When an OSPF ABR advertises Type-3 Summary LSAs from an inter-area
	route to all its connected areas it will also originate an Extended		route to all its connected areas it will also originate an Extended
	Prefix Opaque LSA, as described in [I-D.ietf-ospf-prefix-link-attr].		Prefix Opaque LSA, as described in [I-D.ietf-ospf-prefix-link-attr].
	The flooding scope of the Extended Prefix Opaque LSA type will be set		The flooding scope of the Extended Prefix Opaque LSA type will be set
	to area-scope. The route-type in OSPF Extended Prefix TLV is set to		to area-scope. The route-type in OSPF Extended Prefix TLV is set to
	inter-area. The Prefix-SID Sub-TLV will be included in this LSA and		inter-area. The Prefix-SID Sub-TLV will be included in this LSA and
	the Prefix-SID will be set as follows:		the Prefix-SID will be set as follows:
	The ABR will look at its best path to the prefix in the source		The ABR will look at its best path to the prefix in the source
End of changes. 11 change blocks.
	12 lines changed or deleted		16 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/