< draft-ietf-ospf-segment-routing-extensions-24.txt		draft-ietf-ospf-segment-routing-extensions-25.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 17, 2018 Cisco Systems, Inc.		Expires: October 22, 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
	December 14, 2017		April 20, 2018
	OSPF Extensions for Segment Routing		OSPF Extensions for Segment Routing
	draft-ietf-ospf-segment-routing-extensions-24		draft-ietf-ospf-segment-routing-extensions-25
	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 OSPFv2 extensions required for Segment		This draft describes the OSPFv2 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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on June 17, 2018.		This Internet-Draft will expire on October 22, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2018 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	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
	skipping to change at page 7, line 32 ¶		skipping to change at page 7, line 32 ¶
	range and SID index correspondence is preserved across graceful		range and SID index correspondence is preserved across graceful
	restarts.		restarts.
	o The receiving router MUST adhere to the order in which the ranges		o The receiving router MUST adhere to the order in which the ranges
	are advertised when calculating a SID/label from a SID index.		are advertised when calculating a SID/label from a SID index.
	o The originating router MUST NOT advertise overlapping ranges.		o The originating router MUST NOT advertise overlapping ranges.
	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-segment-routing-mpls].
	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: 100		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
	skipping to change at page 10, line 21 ¶		skipping to change at page 10, line 21 ¶
	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 SRLB TLV		(link, area, or autonomous system (AS)). For the purpose of SRLB TLV
	advertisement, area-scoped flooding is REQUIRED.		advertisement, area-scoped flooding is REQUIRED.
	3.4. SRMS Preference TLV		3.4. SRMS Preference TLV
	The Segment Routing Mapping Server Preference TLV (SRMS Preference		The Segment Routing Mapping Server Preference TLV (SRMS Preference
	TLV) is used to advertise a preference associated with the node that		TLV) is used to advertise a preference associated with the node that
	acts as an SR Mapping Server. The role of an SRMS is described in		acts as an SR Mapping Server. The role of an SRMS is described in
	[I-D.ietf-spring-segment-routing-ldp-interop]. SRMS preference is		[I-D.ietf-spring-segment-routing-ldp-interop]. SRMS preference is
	defined in [I-D.ietf-spring-conflict-resolution].		defined in [I-D.ietf-spring-segment-routing-ldp-interop].
	The SRMS Preference TLV is a top-level TLV of the Router Information		The SRMS Preference TLV is a top-level TLV of the Router Information
	Opaque LSA (defined in [RFC7770]).		Opaque LSA (defined in [RFC7770]).
	The SRMS Preference TLV MAY only be advertised once in the Router		The SRMS Preference TLV MAY only be advertised once in the Router
	Information Opaque LSA and has the following format:		Information Opaque LSA and has the following format:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 26, line 35 ¶		skipping to change at page 26, line 35 ¶
	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-conflict-resolution]
	Ginsberg, L., Psenak, P., Previdi, S., and M. Pilka,
	"Segment Routing MPLS Conflict Resolution", draft-ietf-
	spring-conflict-resolution-05 (work in progress), July
	2017.
	[I-D.ietf-spring-segment-routing]		[I-D.ietf-spring-segment-routing]
	Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,		Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
	Litkowski, S., and R. Shakir, "Segment Routing		Litkowski, S., and R. Shakir, "Segment Routing
	Architecture", draft-ietf-spring-segment-routing-13 (work		Architecture", draft-ietf-spring-segment-routing-15 (work
	in progress), October 2017.		in progress), January 2018.
	[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		Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., and
	S. Litkowski, "Segment Routing interworking with LDP",		S. Litkowski, "Segment Routing interworking with LDP",
	draft-ietf-spring-segment-routing-ldp-interop-09 (work in		draft-ietf-spring-segment-routing-ldp-interop-11 (work in
	progress), September 2017.		progress), April 2018.
			[I-D.ietf-spring-segment-routing-mpls]
			Bashandy, A., Filsfils, C., Previdi, S., Decraene, B.,
			Litkowski, S., and R. Shakir, "Segment Routing with MPLS
			data plane", draft-ietf-spring-segment-routing-mpls-13
			(work in progress), April 2018.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[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,		DOI 10.17487/RFC2328, April 1998,
	<https://www.rfc-editor.org/info/rfc2328>.		<https://www.rfc-editor.org/info/rfc2328>.
	skipping to change at page 28, line 5 ¶		skipping to change at page 27, line 49 ¶
	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		[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
	Writing an IANA Considerations Section in RFCs", BCP 26,		Writing an IANA Considerations Section in RFCs", BCP 26,
	RFC 8126, DOI 10.17487/RFC8126, June 2017,		RFC 8126, DOI 10.17487/RFC8126, June 2017,
	<https://www.rfc-editor.org/info/rfc8126>.		<https://www.rfc-editor.org/info/rfc8126>.
	13.2. Informative References		13.2. Informative References
	[I-D.ietf-spring-segment-routing-mpls]
	Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
	Litkowski, S., and R. Shakir, "Segment Routing with MPLS
	data plane", draft-ietf-spring-segment-routing-mpls-11
	(work in progress), October 2017.
	[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
	2016, <https://www.rfc-editor.org/info/rfc7855>.		2016, <https://www.rfc-editor.org/info/rfc7855>.
End of changes. 12 change blocks.
	24 lines changed or deleted		18 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/