< draft-ietf-ospf-ospfv3-segment-routing-extensions-12.txt		draft-ietf-ospf-ospfv3-segment-routing-extensions-13.txt >
	Open Shortest Path First IGP P. Psenak, Ed.		Open Shortest Path First IGP P. Psenak, Ed.
	Internet-Draft C. Filsfils		Internet-Draft C. Filsfils
	Intended status: Standards Track Cisco Systems, Inc.		Intended status: Standards Track Cisco Systems, Inc.
	Expires: October 22, 2018 S. Previdi, Ed.		Expires: November 24, 2018 S. Previdi, Ed.
	Individual		Individual
	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
	Nuage Networks		Nuage Networks
	April 20, 2018		May 23, 2018
	OSPFv3 Extensions for Segment Routing		OSPFv3 Extensions for Segment Routing
	draft-ietf-ospf-ospfv3-segment-routing-extensions-12		draft-ietf-ospf-ospfv3-segment-routing-extensions-13
	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 OSPFv3 extensions required for Segment		This draft describes the OSPFv3 extensions required for Segment
	Routing.		Routing.
	skipping to change at page 2, line 7 ¶		skipping to change at page 2, line 7 ¶
	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 October 22, 2018.		This Internet-Draft will expire on November 24, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 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
	skipping to change at page 2, line 47 ¶		skipping to change at page 2, line 47 ¶
	6.1. Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 17		6.1. Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 17
	6.2. LAN Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . 19		6.2. LAN Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . 19
	7. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 20		7. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 20
	7.1. Intra-area Segment routing in OSPFv3 . . . . . . . . . . 20		7.1. Intra-area Segment routing in OSPFv3 . . . . . . . . . . 20
	7.2. Inter-area Segment routing in OSPFv3 . . . . . . . . . . 22		7.2. Inter-area Segment routing in OSPFv3 . . . . . . . . . . 22
	7.3. Segment Routing for External Prefixes . . . . . . . . . . 23		7.3. Segment Routing for External Prefixes . . . . . . . . . . 23
	7.4. Advertisement of Adj-SID . . . . . . . . . . . . . . . . 23		7.4. Advertisement of Adj-SID . . . . . . . . . . . . . . . . 23
	7.4.1. Advertisement of Adj-SID on Point-to-Point Links . . 23		7.4.1. Advertisement of Adj-SID on Point-to-Point Links . . 23
	7.4.2. Adjacency SID on Broadcast or NBMA Interfaces . . . . 23		7.4.2. Adjacency SID on Broadcast or NBMA Interfaces . . . . 23
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
	8.1. OSPFv3 Extend-LSA TLV Registry . . . . . . . . . . . . . 24		8.1. OSPFv3 Extended-LSA TLV Registry . . . . . . . . . . . . 24
	8.2. OSPFv3 Extend-LSA Sub-TLV registry . . . . . . . . . . . 24		8.2. OSPFv3 Extended-LSA Sub-TLV registry . . . . . . . . . . 24
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 24		9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
	10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25		10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25		11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
	12.1. Normative References . . . . . . . . . . . . . . . . . . 25		12.1. Normative References . . . . . . . . . . . . . . . . . . 25
	12.2. Informative References . . . . . . . . . . . . . . . . . 26		12.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 46 ¶		skipping to change at page 4, line 46 ¶
	The SR-Algorithm TLV is a top-level TLV of the OSPFv3 Router		The SR-Algorithm TLV is a top-level TLV of the OSPFv3 Router
	Information Opaque LSA (defined in [RFC7770]).		Information Opaque LSA (defined in [RFC7770]).
	The SR-Algorithm TLV is optional. It SHOULD only be advertised once		The SR-Algorithm TLV is optional. It SHOULD only be advertised once
	in the OSPFv3 Router Information Opaque LSA. If the SR-Algorithm TLV		in the OSPFv3 Router Information Opaque LSA. If the SR-Algorithm TLV
	is not advertised by the node, such node is considered as not being		is not advertised by the node, such node is considered as not being
	segment routing capable.		segment routing capable.
	An SR router can use various algorithms when calculating reachability		An SR router can use various algorithms when calculating reachability
	to OSPFv3 routers or prefixes in an OSPFv3 area. Examples of these		to OSPFv3 routers or prefixes in an OSPFv3 area. Examples of these
	algorithms are metric based Shortest Path First (SPF), various		algorithms are metric-based Shortest Path First (SPF), various
	flavors of Constrained SPF, etc. The SR-Algorithm TLV allows a		flavors of Constrained SPF, etc. The SR-Algorithm TLV allows a
	router to advertise the algorithms currently used by the router to		router to advertise the algorithms currently used by the router to
	other routers in an OSPFv3 area. The SR-Algorithm TLV has following		other routers in an OSPFv3 area. The SR-Algorithm TLV has following
	format:		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Algorithm 1 | Algorithm... | Algorithm n | |		| Algorithm 1 | Algorithm... | Algorithm n | |
	+- -+		+- -+
	| |		| |
	+ +		+ +
	where:		where:
	Type: 8		Type: 8
	Length: Variable, in octets, dependent on number of algorithms		Length: Variable, in octets, dependent on number of algorithms
	advertised.		advertised.
	skipping to change at page 5, line 41 ¶		skipping to change at page 5, line 41 ¶
	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 TLVs are received from a given router, the		When multiple SR-Algorithm TLVs are received from a given router, the
	receiver MUST use the first occurrence of the TLV in the OSPFV3		receiver MUST use the first occurrence of the TLV in the OSPFv3
	Router Information Opaque LSA. If the SR-Algorithm TLV appears in		Router Information Opaque LSA. If the SR-Algorithm TLV appears in
	multiple OSPFv3 Router Information Opaque LSAs that have different		multiple OSPFv3 Router Information Opaque LSAs that have different
	flooding scopes, the SR-Algorithm TLV in the OSPFv3 Router		flooding scopes, the SR-Algorithm TLV in the OSPFv3 Router
	Information Opaque LSA with the area-scoped flooding scope MUST be		Information Opaque LSA with the area-scoped flooding scope MUST be
	used. If the SR-Algorithm TLV appears in multiple OSPFv3 Router		used. If the SR-Algorithm TLV appears in multiple OSPFv3 Router
	Information Opaque LSAs that have the same flooding scope, the SR-		Information Opaque LSAs that have the same flooding scope, the SR-
	Algorithm TLV in the OSPFv3 Router Information Opaque LSA with the		Algorithm TLV in the OSPFv3 Router Information Opaque LSA with the
	numerically smallest Instance ID MUST be used and subsequent		numerically smallest Instance ID MUST be used and subsequent
	instances of the SR-Algorithm TLV MUST be ignored.		instances of the SR-Algorithm TLV MUST be ignored.
	skipping to change at page 6, line 26 ¶		skipping to change at page 6, line 26 ¶
	The SID/Label Range TLV is a top-level TLV of the OSPFv3 Router		The SID/Label Range TLV is a top-level TLV of the OSPFv3 Router
	Information Opaque LSA (defined in [RFC7770]).		Information 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
	following format:		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Range Size | Reserved |		| Range Size | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sub-TLVs (variable) |		| Sub-TLVs (variable) |
	+- -+		+- -+
	| |		| |
	+ +		+ +
	where:		where:
	skipping to change at page 10, line 19 ¶		skipping to change at page 10, line 19 ¶
	the SRLB.		the SRLB.
	The OSPFv3 Router Information Opaque LSA can be advertised at any of		The OSPFv3 Router Information Opaque LSA can be advertised at any of
	the defined flooding scopes (link, area, or autonomous system (AS)).		the defined flooding scopes (link, area, or autonomous system (AS)).
	For the purpose of SRLB TLV advertisement, area-scoped flooding is		For the purpose of SRLB TLV advertisement, area-scoped flooding is
	REQUIRED.		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 a 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-segment-routing-ldp-interop].		defined in [I-D.ietf-spring-segment-routing-ldp-interop].
	The SRMS Preference TLV is a top-level TLV of the OSPFv3 Router		The SRMS Preference TLV is a top-level TLV of the OSPFv3 Router
	Information Opaque LSA (defined in [RFC7770]).		Information Opaque LSA (defined in [RFC7770]).
	The SRMS Preference TLV MAY only be advertised once in the OSPFv3		The SRMS Preference TLV MAY only be advertised once in the OSPFv3
	Router Information Opaque LSA and has the following format:		Router 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Preference | Reserved |		| Preference | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	where:		where:
	Type: 15		Type: 15
	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.
	skipping to change at page 11, line 28 ¶		skipping to change at page 11, line 28 ¶
	SRMS server's area, area-scoped flooding MAY be used.		SRMS server's area, area-scoped flooding MAY be used.
	4. OSPFv3 Extended Prefix Range TLV		4. OSPFv3 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.ietf-spring-segment-routing-ldp-interop], is an example where we		[I-D.ietf-spring-segment-routing-ldp-interop], is an example where we
	need a single advertisement to advertise SIDs for multiple prefixes		need a single advertisement to advertise SIDs for multiple prefixes
	from a contiguous address range.		from a contiguous address range.
	The OSPFv3 Extended Prefix Range TLV, is defined for this purpose.		The OSPFv3 Extended Prefix Range TLV is defined for this purpose.
	The OSPFv3 Extended Prefix Range TLV is a top level TLV of the		The OSPFv3 Extended Prefix Range TLV is a top-level TLV of the
	following LSAs defined in [I-D.ietf-ospf-ospfv3-lsa-extend]:		following LSAs defined in [I-D.ietf-ospf-ospfv3-lsa-extend]:
	E-Intra-Area-Prefix-LSA		E-Intra-Area-Prefix-LSA
	E-Inter-Area-Prefix-LSA		E-Inter-Area-Prefix-LSA
	E-AS-External-LSA		E-AS-External-LSA
	E-Type-7-LSA		E-Type-7-LSA
	skipping to change at page 12, line 43 ¶		skipping to change at page 12, line 43 ¶
	AF: 1 - IPv6 unicast		AF: 1 - IPv6 unicast
	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
	including:		including:
	IPv4 multicast address range (224.0.0.0/3), if the AF is IPv4		IPv4 multicast address range (224.0.0.0/3), if the AF is IPv4
	unicast		unicast
	addresses from other than the IPv6 unicast address class, if		Addresses from other than the IPv6 unicast address class, if
	the AF is IPv6 unicast		the AF is IPv6 unicast
	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
	+--+--+--+--+--+--+--+--+		+--+--+--+--+--+--+--+--+
	|IA| | | | | | | |		|IA| | | | | | | |
	+--+--+--+--+--+--+--+--+		+--+--+--+--+--+--+--+--+
	where:		where:
	skipping to change at page 14, line 26 ¶		skipping to change at page 14, line 26 ¶
	OSPFv3 Extended Prefix Range TLV		OSPFv3 Extended Prefix Range TLV
	It MAY appear more than once in the parent TLV and has the following		It MAY appear more than once in the parent TLV and has the following
	format:		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Flags | Algorithm | Reserved |		| Flags | Algorithm | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| SID/Index/Label (variable) |		| SID/Index/Label (variable) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	where:		where:
	Type: 4		Type: 4
	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:
	skipping to change at page 15, line 46 ¶		skipping to change at page 15, line 46 ¶
	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 an OSPFv3 router advertises multiple Prefix-SIDs for the same		If an OSPFv3 router advertises multiple Prefix-SIDs for the same
	prefix, topology and algorithm, all of them MUST be ignored.		prefix, topology and algorithm, all of them MUST be ignored.
	When calculating the outgoing label for the prefix, the router MUST		When calculating the outgoing label for the prefix, the router MUST
	take into account, as described below, the E, NP and M flags		take into account, as described below, the E, NP, and M flags
	advertised by the next-hop router if that router advertised the SID		advertised by the next-hop router if that router advertised the SID
	for the prefix. This MUST be done regardless of whether the next-hop		for the prefix. This MUST be done regardless of whether the next-hop
	router contributes to the best path to the prefix.		router contributes to the best path to the prefix.
	The NP-Flag (No-PHP) MUST be set and the E-flag MUST be clear for		The NP-Flag (No-PHP) MUST be set and the E-flag MUST be clear for
	Prefix-SIDs allocated to inter-area prefixes that are originated by		Prefix-SIDs allocated to prefixes that are propagated between areas
	the ABR based on intra-area or inter-area reachability between areas,		by an ABR based on intra-area or inter-area reachability, unless the
	unless the advertised prefix is directly attached to the ABR.		advertised prefix is directly attached to such ABR.
	The NP-Flag (No-PHP) MUST be set and the E-flag MUST be clear for		The NP-Flag (No-PHP) MUST be set and the E-flag MUST be clear for
	Prefix-SIDs allocated to redistributed prefixes, unless the		Prefix-SIDs allocated to redistributed prefixes, unless the
	redistributed prefix is directly attached to the ASBR.		redistributed prefix is directly attached to the advertising ASBR.
	If the NP-Flag is not set, then any upstream neighbor of the Prefix-		If the NP-Flag is not set, then any upstream neighbor of the Prefix-
	SID originator MUST pop the Prefix-SID. This is equivalent to the		SID originator MUST pop the Prefix-SID. This is equivalent to the
	penultimate hop popping mechanism used in the MPLS dataplane. If the		penultimate hop popping mechanism used in the MPLS dataplane. If the
	NP-flag is not set, then the received E-flag is ignored.		NP-flag is not set, then the received E-flag is ignored.
	If the NP-flag is set then:		If the NP-flag is set then:
	If the E-flag is not set, then any upstream neighbor of the		If the E-flag is not set, then any upstream neighbor of the
	Prefix-SID originator MUST keep the Prefix-SID on top of the		Prefix-SID originator MUST keep the Prefix-SID on top of the
	stack. This is useful when the originator of the Prefix-SID need		stack. This is useful when the originator of the Prefix-SID needs
	to stitch the incoming packet into a continuing MPLS LSP to the		to stitch the incoming packet into a continuing MPLS LSP to the
	final destination. This could occur at an Area Border Router		final destination. This could occur at an Area Border Router
	(prefix propagation from one area to another) or at an AS Boundary		(prefix propagation from one area to another) or at an AS Boundary
	Router (prefix propagation from one domain to another).		Router (prefix propagation from one domain to another).
	If the E-flag is set, then any upstream neighbor of the Prefix-SID		If the E-flag is set, then any upstream neighbor of the Prefix-SID
	originator MUST replace the Prefix-SID with an Explicit-NULL		originator MUST replace the Prefix-SID with an Explicit-NULL
	label. This is useful, e.g., when the originator of the Prefix-		label. This is useful, e.g., when the originator of the Prefix-
	SID is the final destination for the related prefix and the		SID is the final destination for the related prefix and the
	originator wishes to receive the packet with the original EXP		originator wishes to receive the packet with the original EXP
	skipping to change at page 16, line 44 ¶		skipping to change at page 16, line 44 ¶
	reception.		reception.
	As the Mapping Server does not specify the originator of a prefix		As the Mapping Server does not specify the originator of a prefix
	advertisement, it is not possible to determine PHP behavior solely		advertisement, it is not possible to determine PHP behavior solely
	based on the Mapping Server advertisement. However, PHP behavior		based on the Mapping Server advertisement. However, PHP behavior
	SHOULD be done in following cases:		SHOULD be done in following cases:
	The Prefix is intra-area type and the downstream neighbor is the		The Prefix is intra-area type and the downstream neighbor is the
	originator of the prefix.		originator of the prefix.
	The Prefix is inter-area type and downstream neighbor is an ABR,		The Prefix is inter-area type and the downstream neighbor is an
	which is advertising prefix reachability and is setting LA-bit in		ABR, which is advertising prefix reachability and is setting the
	the Prefix Options as described in		LA-bit in the Prefix Options as described in
	[I-D.ietf-ospf-ospfv3-lsa-extend].		[I-D.ietf-ospf-ospfv3-lsa-extend].
	The Prefix is external type and downstream neighbor is an ASBR,		The Prefix is external type and the downstream neighbor is an
	which is advertising prefix reachability and is setting LA-bit in		ASBR, which is advertising prefix reachability and is setting the
	the Prefix Options as described in		LA-bit in the Prefix Options as described in
	[I-D.ietf-ospf-ospfv3-lsa-extend].		[I-D.ietf-ospf-ospfv3-lsa-extend].
	When a Prefix-SID is advertised in the OSPFv3 Extended Prefix Range		When a Prefix-SID is advertised in the OSPFv3 Extended Prefix Range
	TLV, then the value advertised in the Prefix SID Sub-TLV is		TLV, then the value advertised in the Prefix SID Sub-TLV is
	interpreted as a starting SID/Label value.		interpreted as a starting SID/Label value.
	Example 1: If the following router addresses (loopback addresses)		Example 1: If the following router addresses (loopback addresses)
	need to be mapped into the corresponding Prefix SID indexes:		need to be mapped into the corresponding Prefix SID indexes:
	Router-A: 2001:DB8::1/128, Prefix-SID: Index 1		Router-A: 2001:DB8::1/128, Prefix-SID: Index 1
	Router-B: 2001:DB8::2/128, Prefix-SID: Index 2		Router-B: 2001:DB8::2/128, Prefix-SID: Index 2
	Router-C: 2001:DB8::3/128, Prefix-SID: Index 3		Router-C: 2001:DB8::3/128, Prefix-SID: Index 3
	Router-D: 2001:DB8::4/128, Prefix-SID: Index 4		Router-D: 2001:DB8::4/128, Prefix-SID: Index 4
	then the Address Prefix field in the OSPFv3 Extended Prefix Range TLV		then the Address Prefix field in the OSPFv3 Extended Prefix Range TLV
	would be set to 2001:DB8::1, Prefix Length would be set to 128, Range		would be set to 2001:DB8::1, the Prefix Length would be set to 128,
	Size would be set to 4, and the Index value in the Prefix-SID Sub-TLV		the Range Size would be set to 4, and the Index value in the Prefix-
	would be set to 1.		SID Sub-TLV would be set to 1.
	Example 2: If the following prefixes need to be mapped into the		Example 2: If the following prefixes need to be mapped into the
	corresponding Prefix-SID indexes:		corresponding Prefix-SID indexes:
	2001:DB8:1::0/120, Prefix-SID: Index 51		2001:DB8:1::0/120, Prefix-SID: Index 51
	2001:DB8:1::100/120, Prefix-SID: Index 52		2001:DB8:1::100/120, Prefix-SID: Index 52
	2001:DB8:1::200/120, Prefix-SID: Index 53		2001:DB8:1::200/120, Prefix-SID: Index 53
	2001:DB8:1::300/120, Prefix-SID: Index 54		2001:DB8:1::300/120, Prefix-SID: Index 54
	2001:DB8:1::400/120, Prefix-SID: Index 55		2001:DB8:1::400/120, Prefix-SID: Index 55
	2001:DB8:1::500/120, Prefix-SID: Index 56		2001:DB8:1::500/120, Prefix-SID: Index 56
	2001:DB8:1::600/120, Prefix-SID: Index 57		2001:DB8:1::600/120, Prefix-SID: Index 57
	then the Prefix field in the OSPFv3 Extended Prefix Range TLV would		then the Prefix field in the OSPFv3 Extended Prefix Range TLV would
	be set to 2001:DB8:1::0, Prefix Length would be set to 120, Range		be set to 2001:DB8:1::0, the Prefix Length would be set to 120, the
	Size would be set to 7, and the Index value in the Prefix-SID Sub-TLV		Range Size would be set to 7, and the Index value in the Prefix-SID
	would be set to 51.		Sub-TLV would be set to 51.
	6. Adjacency Segment Identifier (Adj-SID)		6. Adjacency Segment Identifier (Adj-SID)
	An Adjacency Segment Identifier (Adj-SID) represents a router		An Adjacency Segment Identifier (Adj-SID) represents a router
	adjacency in Segment Routing.		adjacency in Segment Routing.
	6.1. Adj-SID Sub-TLV		6.1. Adj-SID Sub-TLV
	Adj-SID is an optional Sub-TLV of the Router-Link TLV as defined in		Adj-SID is an optional Sub-TLV of the Router-Link TLV as defined in
	[I-D.ietf-ospf-ospfv3-lsa-extend]. It MAY appear multiple times in		[I-D.ietf-ospf-ospfv3-lsa-extend]. It MAY appear multiple times in
	skipping to change at page 19, line 23 ¶		skipping to change at page 19, line 23 ¶
	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.
	An SR capable router MAY allocate an Adj-SID for each of its		An SR-capable router MAY allocate an Adj-SID for each of its
	adjacencies and set the B-Flag when the adjacency is eligible for		adjacencies and set the B-Flag when the adjacency is eligible for
	protection by an FRR mechanism (IP or MPLS) as described in		protection by an FRR mechanism (IP or MPLS) as described in
	[I-D.ietf-spring-segment-routing].		[I-D.ietf-spring-segment-routing].
	An SR capable router MAY allocate more than one Adj-SID to an		An SR-capable router MAY allocate more than one Adj-SID to an
	adjacency		adjacency
	An SR capable router MAY allocate the same Adj-SID to different		An SR-capable router MAY allocate the same Adj-SID to different
	adjacencies		adjacencies
	When the P-flag is not set, the Adj-SID MAY be persistent. When the		When the P-flag is not set, the Adj-SID MAY be persistent. When the
	P-flag is set, the Adj-SID MUST be persistent.		P-flag is set, the Adj-SID MUST be persistent.
	6.2. LAN Adj-SID Sub-TLV		6.2. LAN Adj-SID Sub-TLV
	LAN Adj-SID is an optional Sub-TLV of the Router-Link TLV. It MAY		LAN Adj-SID is an optional Sub-TLV of the Router-Link TLV. It MAY
	appear multiple times in the Router-Link TLV. It is used to		appear multiple times in the Router-Link TLV. It is used to
	advertise a SID/Label for an adjacency to a non-DR router on a		advertise a SID/Label for an adjacency to a non-DR router on a
	skipping to change at page 21, line 5 ¶		skipping to change at page 21, line 5 ¶
	the P-flag is set, the Adj-SID MUST be persistent.		the P-flag is set, the Adj-SID MUST be persistent.
	7. Elements of Procedure		7. Elements of Procedure
	7.1. Intra-area Segment routing in OSPFv3		7.1. Intra-area Segment routing in OSPFv3
	An OSPFv3 router that supports segment routing MAY advertise Prefix-		An OSPFv3 router that supports segment routing MAY advertise Prefix-
	SIDs for any prefix to which it is advertising reachability (e.g., a		SIDs for any prefix to which it is advertising reachability (e.g., a
	loopback IP address as described in Section 5).		loopback IP address as described in Section 5).
	A Prefix-SID can also be advertised by the SR Mapping Servers (as		A Prefix-SID can also be advertised by SR Mapping Servers (as
	described in [I-D.ietf-spring-segment-routing-ldp-interop]). A		described in [I-D.ietf-spring-segment-routing-ldp-interop]). A
	Mapping Server advertises Prefix-SIDs for remote prefixes that exist		Mapping Server advertises Prefix-SIDs for remote prefixes that exist
	in the OSPFv3 routing domain. Multiple Mapping Servers can advertise		in the OSPFv3 routing domain. Multiple Mapping Servers can advertise
	Prefix-SIDs for the same prefix, in which case the same Prefix-SID		Prefix-SIDs for the same prefix, in which case the same Prefix-SID
	MUST be advertised by all of them. The SR Mapping Server could use		MUST be advertised by all of them. The SR Mapping Server could use
	either area scope or autonomous system flooding scope when		either area flooding scope or autonomous system flooding scope when
	advertising Prefix SID for prefixes, based on the configuration of		advertising Prefix SID for prefixes, based on the configuration of
	the SR Mapping Server. Depending on the flooding scope used, the SR		the SR Mapping Server. Depending on the flooding scope used, the SR
	Mapping Server chooses the OSPFv3 LSA type that will be used. If the		Mapping Server chooses the OSPFv3 LSA type that will be used. If the
	area flooding scope is needed, E-Intra-Area-Prefix-LSA		area flooding scope is needed, an E-Intra-Area-Prefix-LSA
	([I-D.ietf-ospf-ospfv3-lsa-extend]) is used. If autonomous system		([I-D.ietf-ospf-ospfv3-lsa-extend]) is used. If autonomous system
	flooding scope is needed, E-AS-External-LSA		flooding scope is needed, an E-AS-External-LSA
	([I-D.ietf-ospf-ospfv3-lsa-extend]) is used.		([I-D.ietf-ospf-ospfv3-lsa-extend]) is used.
	When a Prefix-SID is advertised by the Mapping Server, which is		When a Prefix-SID is advertised by the Mapping Server, which is
	indicated by the M-flag in the Prefix-SID Sub-TLV (Section 5), the		indicated by the M-flag in the Prefix-SID Sub-TLV (Section 5), the
	route type as implied by the LSA type is ignored and the Prefix-SID		route type as implied by the LSA type is ignored and the Prefix-SID
	is bound to the corresponding prefix independent of the route type.		is bound to the corresponding prefix independent of the route type.
	Advertisement of the Prefix-SID by the Mapping Server using Inter-		Advertisement of the Prefix-SID by the Mapping Server using an Inter-
	Area Prefix TLV, External-Prefix TLV or Intra-Area-Prefix TLV		Area Prefix TLV, External-Prefix TLV, or Intra-Area-Prefix TLV
	([I-D.ietf-ospf-ospfv3-lsa-extend]) does not itself contribute to the		([I-D.ietf-ospf-ospfv3-lsa-extend]) does not itself contribute to the
	prefix reachability. The NU-bit MUST be set in the PrefixOptions		prefix reachability. The NU-bit MUST be set in the PrefixOptions
	field of the LSA which is used by the Mapping Server to advertise SID		field of the LSA which is used by the Mapping Server to advertise SID
	or SID Range, which prevents the advertisement to contribute to the		or SID Range, which prevents the advertisement from contributing to
	prefix reachability.		prefix reachability.
	An SR Mapping Server MUST use the OSPFv3 Extended Prefix Range TLVs		An SR Mapping Server MUST use the OSPFv3 Extended Prefix Range TLVs
	when advertising SIDs for prefixes. Prefixes of different route-		when advertising SIDs for prefixes. Prefixes of different route-
	types can be combined in a single OSPFv3 Extended Prefix Range TLV		types can be combined in a single OSPFv3 Extended Prefix Range TLV
	advertised by an SR Mapping Server.		advertised by an SR Mapping Server.
	Area-scoped OSPFv3 Extended Prefix Range TLVs are propagated between		Area-scoped OSPFv3 Extended Prefix Range TLVs are propagated between
	areas. Similar to propagation of prefixes between areas, an ABR only		areas. Similar to propagation of prefixes between areas, an ABR only
	propagates the OSPFv3 Extended Prefix Range TLV that it considers to		propagates the OSPFv3 Extended Prefix Range TLV that it considers to
	skipping to change at page 22, line 11 ¶		skipping to change at page 22, line 11 ¶
	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 OSPFv3 Extended Prefix Range TLV between areas as described in		of the OSPFv3 Extended Prefix Range TLV between areas as described in
	Section 4.		Section 4.
	7.2. Inter-area Segment routing in OSPFv3		7.2. Inter-area Segment routing in OSPFv3
	In order to support SR in a multi-area environment, OSPFv3 MUST		In order to support SR in a multi-area environment, OSPFv3 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 OSPFv3 ABR advertises a Inter-Area-Prefix-LSA from an intra-		When an OSPFv3 ABR advertises an Inter-Area-Prefix-LSA from an intra-
	area prefix to all its connected areas, it will also include Prefix-		area prefix to all its connected areas, it will also include Prefix-
	SID Sub-TLV, as described in Section 5. The Prefix-SID value will be		SID Sub-TLV, as described in Section 5. The Prefix-SID value will be
	set as follows:		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
	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
	skipping to change at page 23, line 8 ¶		skipping to change at page 23, line 8 ¶
	If no Prefix-SID was advertised for the prefix in the backbone		If no Prefix-SID was advertised for the prefix in the backbone
	area by the ABR that contributes to the best path to the prefix,		area by the ABR that contributes to the best path to the prefix,
	the originating ABR will use the Prefix-SID advertised by any		the originating ABR will use the Prefix-SID advertised by any
	other router when propagating the Prefix-SID for the prefix to		other router when propagating the Prefix-SID for the prefix to
	other areas.		other areas.
	7.3. Segment Routing for External Prefixes		7.3. Segment Routing for External Prefixes
	AS-External-LSAs are flooded domain wide. When an ASBR, which		AS-External-LSAs are flooded domain wide. When an ASBR, which
	supports SR, generates E-AS-External-LSA, it SHOULD also include		supports SR, originates an E-AS-External-LSA, it SHOULD also include
	Prefix-SID Sub-TLV, as described in Section 5. The Prefix-SID value		a Prefix-SID Sub-TLV, as described in Section 5. The Prefix-SID
	will be set to the SID that has been reserved for that prefix.		value will be set to the SID that has been reserved for that prefix.
	When an NSSA [RFC3101] ABR translates an E-NSSA-LSA into an E-AS-		When an NSSA [RFC3101] ABR translates an E-NSSA-LSA into an E-AS-
	External-LSA, it SHOULD also advertise the Prefix-SID for the prefix.		External-LSA, it SHOULD also advertise the Prefix-SID for the prefix.
	The NSSA ABR determines its best path to the prefix advertised in the		The NSSA ABR determines its best path to the prefix advertised in the
	translated E-NSSA-LSA and finds the advertising router associated		translated E-NSSA-LSA and finds the advertising router associated
	with that path. If the advertising router has advertised a Prefix-		with that path. If the advertising router has advertised a Prefix-
	SID for the prefix, then the NSSA ABR uses it when advertising the		SID for the prefix, then the NSSA ABR uses it when advertising the
	Prefix-SID for the E-AS-External-LSA. Otherwise, the Prefix-SID		Prefix-SID for the E-AS-External-LSA. Otherwise, the Prefix-SID
	advertised by any other router will be used.		advertised by any other router will be used.
	skipping to change at page 23, line 50 ¶		skipping to change at page 23, line 50 ¶
	or hybrid network connect. As a result, routers on the broadcast,		or hybrid network connect. As a result, routers on the broadcast,
	NBMA, or hybrid network advertise only their adjacency to the DR.		NBMA, or hybrid network advertise only their adjacency to the DR.
	Routers that do not act as DR do not form or advertise adjacencies		Routers that do not act as DR do not form or advertise adjacencies
	with each other. They do, however, maintain 2-Way adjacency state		with each other. They do, however, maintain 2-Way adjacency state
	with each other and are directly reachable.		with each other and are directly reachable.
	When Segment Routing is used, each router on the broadcast, NBMA, or		When Segment Routing is used, each router on the broadcast, NBMA, or
	hybrid network MAY advertise the Adj-SID for its adjacency to the DR		hybrid network MAY advertise the Adj-SID for its adjacency to the DR
	using the Adj-SID Sub-TLV as described in Section 6.1.		using the Adj-SID Sub-TLV as described in Section 6.1.
	SR capable routers MAY also advertise a LAN-Adj-SID for other		SR-capable routers MAY also advertise a LAN-Adj-SID for other
	neighbors (e.g., BDR, DR-OTHER) on the broadcast, NBMA, or hybrid		neighbors (e.g., BDR, DR-OTHER) on the broadcast, NBMA, or hybrid
	network using the LAN-Adj-SID Sub-TLV as described in Section 6.2.		network using the LAN-Adj-SID Sub-TLV as described in Section 6.2.
	8. IANA Considerations		8. IANA Considerations
	This specification updates several existing OSPFv3 registries.		This specification updates several existing OSPFv3 registries.
	8.1. OSPFv3 Extend-LSA TLV Registry		8.1. OSPFv3 Extended-LSA TLV Registry
	Following values are allocated:		Following values are allocated:
	o suggested value 9 - OSPFv3 Extended Prefix Range TLV		o suggested value 9 - OSPFv3 Extended Prefix Range TLV
	8.2. OSPFv3 Extend-LSA Sub-TLV registry		8.2. OSPFv3 Extended-LSA Sub-TLV registry
	o 4 - Prefix SID Sub-TLV		o 4 - Prefix SID Sub-TLV
	o 5 - Adj-SID Sub-TLV		o 5 - Adj-SID Sub-TLV
	o 6 - LAN Adj-SID Sub-TLV		o 6 - LAN Adj-SID Sub-TLV
	o 7 - SID/Label Sub-TLV		o 7 - SID/Label Sub-TLV
	9. Security Considerations		9. Security Considerations
	skipping to change at page 24, line 44 ¶		skipping to change at page 24, line 44 ¶
	IP control plane can be carried out on the MPLS control plane		IP control plane can be carried out on the MPLS control plane
	resulting in traffic being misrouted in the respective data planes.		resulting in traffic being misrouted in the respective data planes.
	However, the latter can be more difficult to detect and isolate.		However, the latter can be more difficult to detect and isolate.
	Existing security extensions as described in [RFC5340] and		Existing security extensions as described in [RFC5340] and
	[I-D.ietf-ospf-ospfv3-lsa-extend] apply to these segment routing		[I-D.ietf-ospf-ospfv3-lsa-extend] apply to these segment routing
	extensions. While OSPFv3 is under a single administrative domain,		extensions. While OSPFv3 is under a single administrative domain,
	there can be deployments where potential attackers have access to one		there can be deployments where potential attackers have access to one
	or more networks in the OSPFv3 routing domain. In these deployments,		or more networks in the OSPFv3 routing domain. In these deployments,
	stronger authentication mechanisms such as those specified in		stronger authentication mechanisms such as those specified in
	[RFC4552] SHOULD be used.		[RFC4552] or [RFC7166] 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 OSPFv3 router or routing process. Reception		attackers to crash the OSPFv3 router or routing process. Reception
	of malformed TLV or Sub-TLV SHOULD be counted and/or logged for		of a malformed TLV or Sub-TLV SHOULD be counted and/or logged for
	further analysis. Logging of malformed TLVs and Sub-TLVs SHOULD be		further analysis. Logging of malformed TLVs and Sub-TLVs SHOULD be
	rate-limited to prevent a Denial of Service (DoS) attack (distributed		rate-limited to prevent a Denial of Service (DoS) attack (distributed
	or otherwise) from overloading the OSPFv3 control plane.		or otherwise) from overloading the OSPFv3 control plane.
	10. Contributors		10. Contributors
	Acee Lindem gave a substantial contribution to the content of this		Acee Lindem gave a substantial contribution to the content of this
	document.		document.
	11. Acknowledgements		11. Acknowledgements
	skipping to change at page 26, line 38 ¶		skipping to change at page 26, line 38 ¶
	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>.
	12.2. Informative References		12.2. Informative References
	[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality		[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality
	for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006,		for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006,
	<https://www.rfc-editor.org/info/rfc4552>.		<https://www.rfc-editor.org/info/rfc4552>.
			[RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting
			Authentication Trailer for OSPFv3", RFC 7166,
			DOI 10.17487/RFC7166, March 2014,
			<https://www.rfc-editor.org/info/rfc7166>.
	[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>.
	Authors' Addresses		Authors' Addresses
	Peter Psenak (editor)		Peter Psenak (editor)
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Eurovea Centre, Central 3		Eurovea Centre, Central 3
	Pribinova Street 10		Pribinova Street 10
	Bratislava 81109		Bratislava 81109
	Slovakia		Slovakia
	Email: ppsenak@cisco.com		Email: ppsenak@cisco.com
	Clarence Filsfils		Clarence Filsfils
End of changes. 42 change blocks.
	54 lines changed or deleted		60 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/