< draft-ietf-ospf-segment-routing-extensions-17.txt		draft-ietf-ospf-segment-routing-extensions-18.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: December 25, 2017 Cisco Systems, Inc.		Expires: January 19, 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
	June 23, 2017		July 18, 2017
	OSPF Extensions for Segment Routing		OSPF Extensions for Segment Routing
	draft-ietf-ospf-segment-routing-extensions-17		draft-ietf-ospf-segment-routing-extensions-18
	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 December 25, 2017.		This Internet-Draft will expire on January 19, 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		(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 32 ¶		skipping to change at page 2, line 32 ¶
	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 . . . . . . . . . . . . . . . . . . . . 3
	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 . . . . . . . . . . . . . . . . . . . . . 12		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
	7. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 19		7. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 19
	7.1. Intra-area Segment routing in OSPFv2 . . . . . . . . . . 19		7.1. Intra-area Segment routing in OSPFv2 . . . . . . . . . . 19
	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
	skipping to change at page 3, line 6 ¶		skipping to change at page 3, line 6 ¶
	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
	9. Implementation Status . . . . . . . . . . . . . . . . . . . . 23		9. Implementation Status . . . . . . . . . . . . . . . . . . . . 23
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 24		10. Security Considerations . . . . . . . . . . . . . . . . . . . 24
	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 . . . . . . . . . . . . . . . . . . 25
	13.2. Informative References . . . . . . . . . . . . . . . . . 25		13.2. Informative References . . . . . . . . . . . . . . . . . 26
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
	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
	skipping to change at page 5, line 48 ¶		skipping to change at page 5, line 48 ¶
	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 TLVs are received from a given router, the		When multiple SR-Algorithm TLVs are received from a given router, the
	receiver SHOULD use the first occurrence of the TLV in the Router		receiver SHOULD use the first occurrence of the TLV in the Router
	Information LSA. If the SR-Algorithm TLV appears in multiple Router		Information LSA. If the SR-Algorithm TLV appears in multiple Router
	Information LSAs that have different flooding scopes, the SR-		Information LSAs that have different flooding scopes, the SR-
	Algorithm TLV in the Router Information LSA with the narrowest		Algorithm TLV in the Router Information LSA with the narrowest
	flooding scope SHOULD be used. If the SR-Algorithm TLV appears in		flooding scope SHOULD be used. If the SR-Algorithm TLV appears in
	multiple Router Information LSAs that have the same flooding scope,		multiple Router Information LSAs that have the same flooding scope,
	the SR-Algorithm TLV in the Router Information LSA with the		the SR-Algorithm TLV in the Router Information (RI) LSA with the
	numerically smallest Instance ID SHOULD be used and subsequent		numerically smallest Instance ID SHOULD be used and subsequent
	instances of the SR-Algorithm TLV SHOULD be ignored.		instances of the SR-Algorithm 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-scoped flooding is REQUIRED.		SR-Algorithm TLV advertisement, area-scoped flooding is REQUIRED.
	3.2. SID/Label Range TLV		3.2. SID/Label Range TLV
	Prefix SIDs MAY be advertised in a form of an index as described in		Prefix SIDs MAY be advertised in a form of an index as described in
	skipping to change at page 8, line 7 ¶		skipping to change at page 8, line 7 ¶
	o When a router receives multiple overlapping ranges, it MUST		o When a router receives multiple overlapping ranges, it MUST
	conform to the procedures defined in		conform to the procedures defined in
	[I-D.ietf-spring-conflict-resolution].		[I-D.ietf-spring-conflict-resolution].
	The following example illustrates the advertisement of multiple		The following example illustrates the advertisement of multiple
	ranges:		ranges:
	The originating router advertises the following ranges:		The originating router advertises the following ranges:
	Range 1: Range Size: 100 SID/Label Sub-TLV: 199		Range 1: Range Size: 100 SID/Label Sub-TLV: 100
	Range 1: Range Size: 100 SID/Label Sub-TLV: 1000		Range 1: Range Size: 100 SID/Label Sub-TLV: 1000
	Range 1: Range Size: 100 SID/Label Sub-TLV: 500		Range 1: Range Size: 100 SID/Label Sub-TLV: 500
	The receiving routers concatenate the ranges and build the Segment		The receiving routers concatenate the ranges and build the Segment
	Routing Global Block (SRGB) as follows:		Routing Global Block (SRGB) as follows:
	SRGB = [100, 199]		SRGB = [100, 199]
	[1000, 1099]		[1000, 1099]
	[500, 599]		[500, 599]
	skipping to change at page 12, line 30 ¶		skipping to change at page 12, line 30 ¶
	where:		where:
	IA-Flag: Inter-Area flag. If set, advertisement is of inter-		IA-Flag: Inter-Area flag. If set, advertisement is of inter-
	area type. An ABR that is advertising the OSPF Extended Prefix		area type. An ABR that is advertising the OSPF Extended Prefix
	Range TLV between areas MUST set this bit.		Range TLV between areas MUST set this bit.
	This bit is used to prevent redundant flooding of Prefix Range		This bit is used to prevent redundant flooding of Prefix Range
	TLVs between areas as follows:		TLVs between areas as follows:
	An ABR always prefers intra-area Prefix Range advertisements
	over inter-area advertisements.
	An ABR does not consider inter-area Prefix Range
	advertisements coming from non-backbone areas.
	An ABR only propagates an inter-area Prefix Range		An ABR only propagates an inter-area Prefix Range
	advertisement from the backbone area to connected non-		advertisement from the backbone area to connected non-
	backbone areas if the advertisement is considered to be the		backbone areas if the advertisement is considered to be the
	best one.		best one. The following rules are used to select the best
			range from the set of advertisements for the same Prefix
			Range:
			An ABR always prefers intra-area Prefix Range
			advertisements over inter-area advertisements.
			An ABR does not consider inter-area Prefix Range
			advertisements coming from non-backbone areas.
	Address Prefix: For the address family IPv4 unicast, the prefix		Address Prefix: For the address family IPv4 unicast, the prefix
	itself is encoded as a 32-bit value. The default route is		itself is encoded as a 32-bit value. The default route is
	represented by a prefix of length 0. Prefix encoding for other		represented by a prefix of length 0. Prefix encoding for other
	address families is beyond the scope of this specification.		address families is beyond the scope of this specification.
	5. Prefix SID Sub-TLV		5. Prefix SID Sub-TLV
	The Prefix SID Sub-TLV is a Sub-TLV of the OSPF Extended Prefix TLV		The Prefix SID Sub-TLV is a Sub-TLV of the OSPF Extended Prefix TLV
	described in [RFC7684] and the OSPF Extended Prefix Range TLV		described in [RFC7684] and the OSPF Extended Prefix Range TLV
	skipping to change at page 24, line 50 ¶		skipping to change at page 24, line 50 ¶
	Existing security extensions as described in [RFC2328] and [RFC7684]		Existing security extensions as described in [RFC2328] and [RFC7684]
	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.		attackers to crash the OSPFv2 router or routing process. Reception
			of malformed TLV or Sub-TLV SHOULD be counted and/or logged for
			further analysis.
	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 26, line 8 ¶		skipping to change at page 26, line 10 ¶
	[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, <http://www.rfc-editor.org/info/rfc7770>.		February 2016, <http://www.rfc-editor.org/info/rfc7770>.
	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-04 (work in progress), May		spring-conflict-resolution-05 (work in progress), July
	2017.		2017.
	[I-D.ietf-spring-segment-routing]		[I-D.ietf-spring-segment-routing]
	Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,		Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
	and R. Shakir, "Segment Routing Architecture", draft-ietf-		and R. Shakir, "Segment Routing Architecture", draft-ietf-
	spring-segment-routing-12 (work in progress), June 2017.		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",
End of changes. 12 change blocks.
	17 lines changed or deleted		21 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/