< draft-ietf-ospf-prefix-link-attr-03.txt		draft-ietf-ospf-prefix-link-attr-04.txt >
	Network Working Group P. Psenak		Network Working Group P. Psenak
	Internet-Draft Cisco Systems		Internet-Draft Cisco Systems
	Intended status: Standards Track H. Gredler		Intended status: Standards Track H. Gredler
	Expires: August 5, 2015 Juniper Networks, Inc.		Expires: October 16, 2015 Juniper Networks, Inc.
	R. Shakir		R. Shakir
	British Telcom		British Telcom
	W. Henderickx		W. Henderickx
	Alcatel-Lucent		Alcatel-Lucent
	J. Tantsura		J. Tantsura
	Ericsson		Ericsson
	A. Lindem		A. Lindem
	Cisco Systems		Cisco Systems
	February 1, 2015		April 14, 2015
	OSPFv2 Prefix/Link Attribute Advertisement		OSPFv2 Prefix/Link Attribute Advertisement
	draft-ietf-ospf-prefix-link-attr-03.txt		draft-ietf-ospf-prefix-link-attr-04.txt
	Abstract		Abstract
	OSPFv2 requires functional extension beyond what can readily be done		OSPFv2 requires functional extension beyond what can readily be done
	with the fixed-format Link State Advertisements (LSAs) as described		with the fixed-format Link State Advertisements (LSAs) as described
	in RFC 2328. This document defines OSPF opaque LSAs based on Type-		in RFC 2328. This document defines OSPF opaque LSAs based on Type-
	Length-Value (TLV) tuples that can be used to associate additional		Length-Value (TLV) tuples that can be used to associate additional
	attributes with prefixes or links. Dependent on the application,		attributes with prefixes or links. Dependent on the application,
	these prefixes and links may or not be advertised in the fixed-format		these prefixes and links may or not be advertised in the fixed-format
	LSAs. The OSPF opaque LSAs are optional and fully backward		LSAs. The OSPF opaque LSAs are optional and fully backward
	skipping to change at page 1, line 46 ¶		skipping to change at page 1, line 46 ¶
	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 August 5, 2015.		This Internet-Draft will expire on October 16, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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 41 ¶		skipping to change at page 2, line 41 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3		1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3
	1.2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 3		1.2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 3
	2. OSPFv2 Extended Prefix Opaque LSA . . . . . . . . . . . . . . 4		2. OSPFv2 Extended Prefix Opaque LSA . . . . . . . . . . . . . . 4
	2.1. OSPFv2 Extended Prefix TLV . . . . . . . . . . . . . . . 5		2.1. OSPFv2 Extended Prefix TLV . . . . . . . . . . . . . . . 5
	3. OSPFv2 Extended Link Opaque LSA . . . . . . . . . . . . . . . 7		3. OSPFv2 Extended Link Opaque LSA . . . . . . . . . . . . . . . 7
	3.1. OSPFv2 Extended Link TLV . . . . . . . . . . . . . . . . 8		3.1. OSPFv2 Extended Link TLV . . . . . . . . . . . . . . . . 8
	4. Backward Compatibility . . . . . . . . . . . . . . . . . . . 9		4. Backward Compatibility . . . . . . . . . . . . . . . . . . . 10
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 10		5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	6.1. OSPF Extended Prefix LSA TLV Registry . . . . . . . . . . 10		6.1. OSPF Extended Prefix Opaque LSA TLV Registry . . . . . . 10
	6.2. OSPF Extended Prefix TLV Sub-TLV Registry . . . . . . . . 11		6.2. OSPF Extended Prefix TLV Sub-TLV Registry . . . . . . . . 11
	6.3. OSPF Extended Link LSA TLV Registry . . . . . . . . . . . 11		6.3. OSPF Extended Link Opaque LSA TLV Registry . . . . . . . 11
	6.4. OSPF Extended Link TLV Sub-TLV Registry . . . . . . . . . 11		6.4. OSPF Extended Link TLV Sub-TLV Registry . . . . . . . . . 12
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	7.1. Normative References . . . . . . . . . . . . . . . . . . 12		7.1. Normative References . . . . . . . . . . . . . . . . . . 12
	7.2. Informative References . . . . . . . . . . . . . . . . . 12		7.2. Informative References . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	OSPFv2 requires functional extension beyond what can readily be done		OSPFv2 requires functional extension beyond what can readily be done
	with the fixed-format Link State Advertisements (LSAs) as described		with the fixed-format Link State Advertisements (LSAs) as described
	in RFC 2328 [OSPFV2]. This document defines OSPF opaque LSAs based		in RFC 2328 [OSPFV2]. This document defines OSPF opaque LSAs based
	on Type-Length-Value (TLV) tuples that can be used to associate		on Type-Length-Value (TLV) tuples that can be used to associate
	additional attributes with prefixes or links. Dependent on the		additional attributes with prefixes or links. Dependent on the
	application, these prefixes and links may or not be advertised in the		application, these prefixes and links may or not be advertised in the
	fixed-format LSAs. The OSPF opaque LSAs are optional and fully		fixed-format LSAs. The OSPF opaque LSAs are optional and fully
	backward compatible. This is in contrast to the approach taken in		backward compatible. This is in contrast to the approach taken in
	OSPFv3 [I-D.ietf-ospf-ospfv3-lsa-extend] where the existing LSAs will		OSPFv3 [I-D.ietf-ospf-ospfv3-lsa-extend] where the existing LSAs will
	be replaced by TLV-based extended LSAs.		be replaced by TLV-based extended LSAs.
	New requirements such as source/destination routing, route tagging,		New requirements such as source/destination routing, route tagging,
	and segment routing necessitate this extension.		and segment routing necessitate this extension.
	This specification defines the following OSPFv2 opaque LSAs:		This specification defines the following OSPFv2 opaque LSAs:
	1. OSPFv2 Extended Prefix LSA - Allows advertisement of additional		1. OSPFv2 Extended Prefix Opaque LSA - Allows advertisement of
	attributes for prefixes advertised in Router-LSAs, Network-LSAs,		additional attributes for prefixes advertised in Router-LSAs,
	Network-Summary-LSAs, NSSA-LSAs, and AS-External-LSAs [OSPFV2]		Network-LSAs, Network-Summary-LSAs, NSSA-LSAs, and AS-External-
			LSAs [OSPFV2]
	2. OSPFv2 Extended links LSA - Allows advertisement of additional		2. OSPFv2 Extended Link Opaque LSA - Allows advertisement of
	attributes for links advertised in Router-LSAs.		additional attributes for links advertised in Router-LSAs.
	Additionally, the following TLVs are defined:		Additionally, the following TLVs are defined:
	1. OSPFv2 Extended Prefix TLV - Top-level TLV advertising attributes		1. OSPFv2 Extended Prefix TLV - Top-level TLV advertising attributes
	for a prefix in the OSPFv2 Extended Prefix LSA.		for a prefix in the OSPFv2 Extended Prefix Opaque LSA.
	2. OSPFv2 Extended Link TLV - Top-level TLV advertising attributes		2. OSPFv2 Extended Link TLV - Top-level TLV advertising attributes
	for a link in the OSPFv2 Extended link LSA.		for a link in the OSPFv2 Extended Link Opaque LSA.
	1.1. Requirements notation		1.1. Requirements notation
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC-KEYWORDS].		document are to be interpreted as described in [RFC-KEYWORDS].
	1.2. Acknowledgments		1.2. Acknowledgments
	We would like to thank Anton Smirnov for his contribution.		We would like to thank Anton Smirnov for his contribution.
	skipping to change at page 4, line 36 ¶		skipping to change at page 4, line 36 ¶
	| Advertising Router |		| Advertising Router |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| LS sequence number |		| LS sequence number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| LS checksum | length |		| LS checksum | length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+- TLVs -+		+- TLVs -+
	| ... |		| ... |
	OSPFv2 Extended Prefix LSA		OSPFv2 Extended Prefix Opaque LSA
	The opaque type used by OSPFv2 Extended Prefix Opaque LSA is 7.		The opaque type used by OSPFv2 Extended Prefix Opaque LSA is 7.
			The Instance field is an arbitrary value used to maintain multiple
			Extended Prefix Opaque LSAs. A maximum of 16777216 Extended Prefix
			Opaque LSAs may be sourced by a single OSPF instance.
	The format of the TLVs within the body of the OSPFv2 Extended Prefix		The format of the TLVs within the body of the OSPFv2 Extended Prefix
	LSA is the same as the format used by the Traffic Engineering		Opaque LSA is the same as the format used by the Traffic Engineering
	Extensions to OSPF [TE]. The variable TLV section consists of one or		Extensions to OSPF [TE]. The variable TLV section consists of one or
	more nested Type/Length/Value (TLV) tuples. Nested TLVs are also		more nested Type/Length/Value (TLV) tuples. Nested TLVs are also
	referred to as sub-TLVs. The format of each TLV is:		referred to as sub-TLVs. The format of each TLV is:
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Value... |		| Value... |
	skipping to change at page 5, line 26 ¶		skipping to change at page 5, line 26 ¶
	(thus a TLV with no value portion would have a length of 0). The TLV		(thus a TLV with no value portion would have a length of 0). The TLV
	is padded to 4-octet alignment; padding is not included in the length		is padded to 4-octet alignment; padding is not included in the length
	field (so a 3-octet value would have a length of 3, but the total		field (so a 3-octet value would have a length of 3, but the total
	size of the TLV would be 8 octets). Nested TLVs are also 32-bit		size of the TLV would be 8 octets). Nested TLVs are also 32-bit
	aligned. For example, a 1-byte value would have the length field set		aligned. For example, a 1-byte value would have the length field set
	to 1, and 3 octets of padding would be added to the end of the value		to 1, and 3 octets of padding would be added to the end of the value
	portion of the TLV.		portion of the TLV.
	2.1. OSPFv2 Extended Prefix TLV		2.1. OSPFv2 Extended Prefix TLV
	The OSPF Extended Prefix TLV is used in order to advertise additional		The OSPF Extended Prefix TLV is used to advertise additional
	attributes associated with the prefix. Multiple OSPF Extended Prefix		attributes associated with the prefix. Multiple OSPF Extended Prefix
	TLVs MAY be advertised in each OSPFv2 Extended Prefix Opaque LSA.		TLVs MAY be advertised in each OSPFv2 Extended Prefix Opaque LSA.
	However, since the opaque LSA type defines the flooding scope, the		However, since the opaque LSA type defines the flooding scope, the
	LSA flooding scope MUST satisfy the application specific requirements		LSA flooding scope MUST satisfy the application specific requirements
	for all the prefixes included in a single OSPFv2 Extended Prefix		for all the prefixes included in a single OSPFv2 Extended Prefix
	Opaque LSA. The OSPF Extended Prefix TLV has the following format:		Opaque LSA. The OSPF Extended Prefix TLV 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 7, line 31 ¶		skipping to change at page 7, line 31 ¶
	If this TLV is advertised multiple times for the same prefix in		If this TLV is advertised multiple times for the same prefix in
	different OSPFv2 Extended Prefix Opaque LSAs originated by the same		different OSPFv2 Extended Prefix Opaque LSAs originated by the same
	OSPF router, the OSPF advertising router is re-originating Extended		OSPF router, the OSPF advertising router is re-originating Extended
	Prefix Opaque LSAs for multiple prefixes and is most likely repacking		Prefix Opaque LSAs for multiple prefixes and is most likely repacking
	Extended-Prefix-TLVs in Extended Prefix Opaque LSAs. In this case,		Extended-Prefix-TLVs in Extended Prefix Opaque LSAs. In this case,
	the Extended-Prefix-TLV in the Extended Prefix Opaque LSA with the		the Extended-Prefix-TLV in the Extended Prefix Opaque LSA with the
	smallest Instance is used by receiving OSPFv2 Routers. This		smallest Instance is used by receiving OSPFv2 Routers. This
	situation MAY be logged as a warning.		situation MAY be logged as a warning.
	It is RECOMMENDED that OSPF routers advertising Extended-Prefix-TLVs		It is RECOMMENDED that OSPF routers advertising Extended Prefix TLVs
	in different Extended Prefix Opaque LSAs re-originate these LSAs in		in different Extended Prefix Opaque LSAs re-originate these LSAs in
	ascending order of Instance to minimize the disruption.		ascending order of Instance to minimize the disruption.
	If this TLV is advertised multiple times for the same prefix in		If this TLV is advertised multiple times for the same prefix in
	different OSPFv2 Extended Prefix Opaque LSAs originated by the		different OSPFv2 Extended Prefix Opaque LSAs originated by the
	different OSPF routers, the application using the information is		different OSPF routers, the application using the information is
	required to determine which OSPFv2 Extended Prefix Opaque LSA is		required to determine which OSPFv2 Extended Prefix Opaque LSA is
	used. For example, the application could prefer the LSA providing		used. For example, the application could prefer the LSA providing
	the best path to the prefix.		the best path to the prefix.
	skipping to change at page 8, line 24 ¶		skipping to change at page 8, line 24 ¶
	| Advertising Router |		| Advertising Router |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| LS sequence number |		| LS sequence number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| LS checksum | length |		| LS checksum | length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+- TLVs -+		+- TLVs -+
	| ... |		| ... |
	OSPFv2 Extended Link LSA		OSPFv2 Extended Link Opaque LSA
	The Opaque type used by OSPFv2 Extended Link Opaque LSA is 8.		The Opaque type used by OSPFv2 Extended Link Opaque LSA is 8.
	The format of the TLVs within the body of the OSPFv2 Extended Prefix		The Instance field is an arbitrary value used to maintain multiple
	LSA is the same as Section 2.		Extended Link Opaque LSAs. A maximum of 16777216 Extended Link
			Opaque LSAs may be sourced by a single OSPF instance.
			The format of the TLVs within the body of the OSPFv2 Extended Link
			Opaque LSA is the same as described in Section 2.
	3.1. OSPFv2 Extended Link TLV		3.1. OSPFv2 Extended Link TLV
	OSPFv2 Extended Link TLV is used in order to advertise various		The OSPFv2 Extended Link TLV is used to advertise various attributes
	attributes of the link. It describes a single link and is		of the link. It describes a single link and is constructed of a set
	constructed of a set of Sub-TLVs. There are no ordering requirements		of Sub-TLVs. There are no ordering requirements for the Sub-TLVs.
	for the Sub-TLVs. Only one Extended Link TLV SHALL be advertised in		Only one Extended Link TLV SHALL be advertised in each Extended Link
	each Extended Link Opaque LSA, allowing for fine granularity changes		Opaque LSA, allowing for fine granularity changes in the topology.
	in the topology.
	The Extended Link TLV has following format:		The Extended Link TLV has 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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Link-Type | Reserved |		| Link-Type | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 9, line 37 ¶		skipping to change at page 9, line 37 ¶
	Link-Type		Link-Type
	Link-Type is defined in section A.4.2 of [OSPFV2].		Link-Type is defined in section A.4.2 of [OSPFV2].
	Link-ID		Link-ID
	Link-ID is defined in section A.4.2 of [OSPFV2].		Link-ID is defined in section A.4.2 of [OSPFV2].
	Link Data		Link Data
	Link-Data is defined in section A.4.2 of [OSPFV2].		Link-Data is defined in section A.4.2 of [OSPFV2].
			If this TLV is advertised multiple times in the same OSPFv2 Extended
			Link Opaque LSA, only the first instance is used by receiving OSPFv2
			Routers. This situation SHOULD be logged as an error.
			If this TLV is advertised multiple times for the same link in
			different OSPFv2 Extended Link Opaque LSAs originated by the same
			OSPF router, the Extended Link TLV in the Extended Link Opaque LSA
			with the smallest Instance is used by receiving OSPFv2 Routers. This
			situation MAY be logged as a warning.
			It is RECOMMENDED that OSPF routers advertising Extended Link TLVs in
			different Extended Link Opaque LSAs re-originate these LSAs in
			ascending order of Instance to minimize the disruption.
	This document creates a registry for OSPF Extended Link sub-TLVs in		This document creates a registry for OSPF Extended Link sub-TLVs in
	Section 6.		Section 6.
	4. Backward Compatibility		4. Backward Compatibility
	Since opaque OSPFv2 LSAs are optional and backward compatible		Since opaque OSPFv2 LSAs are optional and backward compatible
	[OPAQUE], the extensions described herein is fully backward		[OPAQUE], the extensions described herein is fully backward
	compatible. However, future OSPFv2 extensions utilizing these		compatible. However, future OSPFv2 extensions utilizing these
	extensions must address backward compatibility of the corresponding		extensions must address backward compatibility of the corresponding
	functionality.		functionality.
	skipping to change at page 10, line 25 ¶		skipping to change at page 10, line 36 ¶
	Option Types with the following values:		Option Types with the following values:
	o 7 (IANA Early Allocation [RFC7120]) - OSPFv2 Extended Prefix		o 7 (IANA Early Allocation [RFC7120]) - OSPFv2 Extended Prefix
	Opaque LSA		Opaque LSA
	o 8 (IANA Early Allocation [RFC7120]) - OSPFv2 Extended Link Opaque		o 8 (IANA Early Allocation [RFC7120]) - OSPFv2 Extended Link Opaque
	LSA		LSA
	This specification also creates four new registries:		This specification also creates four new registries:
	o OSPF Extended Prefix LSA TLVs		o OSPF Extended Prefix Opaque LSA TLVs
	o OSPF Extended Prefix TLV Sub-TLVs		o OSPF Extended Prefix TLV Sub-TLVs
	o OSPF Extended Link LSA TLVs		o OSPF Extended Link Opaque LSA TLVs
	o OSPF Extended Link TLV Sub-TLVs		o OSPF Extended Link TLV Sub-TLVs
	6.1. OSPF Extended Prefix LSA TLV Registry		6.1. OSPF Extended Prefix Opaque LSA TLV Registry
	The OSPF Extend Prefix LSA TLV registry will define top-level TLVs		The OSPF Extend Prefix Opaque LSA TLV registry will define top-level
	for Extended Prefix LSAs and should be placed in the existing OSPF		TLVs for Extended Prefix Opaque LSA and should be placed in the
	IANA registry. New values can be allocated via IETF Consensus or		existing OSPF IANA registry. New values can be allocated via IETF
	IESG Approval.		Consensus or IESG Approval.
	The following initial values are allocated:		The following initial values are allocated:
	o 0 - Reserved		o 0 - Reserved
	o 1 - OSPF Extended Prefix TLV		o 1 - OSPF Extended Prefix TLV
	Types in the range 32768-33023 are for experimental use; these will		Types in the range 32768-33023 are for experimental use; these will
	not be registered with IANA, and MUST NOT be mentioned by RFCs.		not be registered with IANA, and MUST NOT be mentioned by RFCs.
	Types in the range 33024-65535 are not to be assigned at this time.		Types in the range 33024-65535 are not to be assigned at this time.
	Before any assignments can be made in the 33024-65535 range, there		Before any assignments can be made in the 33024-65535 range, there
	MUST be an IETF specification that specifies IANA Considerations that		MUST be an IETF specification that specifies IANA Considerations that
	covers the range being assigned.		covers the range being assigned.
	6.2. OSPF Extended Prefix TLV Sub-TLV Registry		6.2. OSPF Extended Prefix TLV Sub-TLV Registry
	The OSPF Extended Link LSA sub-TLV registry will define sub-TLVs at		The OSPF Extended Prefix TLV sub-TLV registry will define sub-TLVs at
	any level of nesting for Extended Link LSAs and should be placed in		any level of nesting for Extended Prefix TLV and should be placed in
	the existing OSPF IANA registry. New values can be allocated via		the existing OSPF IANA registry. New values can be allocated via
	IETF Consensus or IESG Approval.		IETF Consensus or IESG Approval.
	The following initial values are allocated:		The following initial values are allocated:
	o 0 - Reserved		o 0 - Reserved
	Types in the range 32768-33023 are for experimental use; these will		Types in the range 32768-33023 are for experimental use; these will
	not be registered with IANA, and MUST NOT be mentioned by RFCs.		not be registered with IANA, and MUST NOT be mentioned by RFCs.
	Types in the range 33024-65535 are not to be assigned at this time.		Types in the range 33024-65535 are not to be assigned at this time.
	Before any assignments can be made in the 33024-65535 range, there		Before any assignments can be made in the 33024-65535 range, there
	MUST be an IETF specification that specifies IANA Considerations that		MUST be an IETF specification that specifies IANA Considerations that
	covers the range being assigned.		covers the range being assigned.
	6.3. OSPF Extended Link LSA TLV Registry		6.3. OSPF Extended Link Opaque LSA TLV Registry
	The OSPF Extend Link LSA TLV registry will define top-level TLVs for		The OSPF Extended Link Opaque LSA TLV registry will define top-level
	Extended Link LSAs and should be placed in the existing OSPF IANA		TLVs for Extended Link Opaque LSAs and should be placed in the
	registry. New values can be allocated via IETF Consensus or IESG		existing OSPF IANA registry. New values can be allocated via IETF
	Approval.		Consensus or IESG Approval.
	Following initial values are allocated:		Following initial values are allocated:
	o 0 - Reserved		o 0 - Reserved
	o 1 - OSPFv2 Extended Link TLV		o 1 - OSPFv2 Extended Link TLV
	Types in the range 32768-33023 are for experimental use; these will		Types in the range 32768-33023 are for experimental use; these will
	not be registered with IANA, and MUST NOT be mentioned by RFCs.		not be registered with IANA, and MUST NOT be mentioned by RFCs.
	Types in the range 33024-65535 are not to be assigned at this time.		Types in the range 33024-65535 are not to be assigned at this time.
	Before any assignments can be made in the 33024-65535 range, there		Before any assignments can be made in the 33024-65535 range, there
	MUST be am IETF specification that specifies IANA Considerations that		MUST be am IETF specification that specifies IANA Considerations that
	covers the range being assigned.		covers the range being assigned.
	6.4. OSPF Extended Link TLV Sub-TLV Registry		6.4. OSPF Extended Link TLV Sub-TLV Registry
	The OSPF Extended Link sub-TLV registry will define will define sub-		The OSPF Extended Link TLV sub-TLV registry will define sub-TLVs at
	TLVs at any level of nesting for Extended Link LSAs and should be		any level of nesting for Extended Link TLV and should be placed in
	placed in the existing OSPF IANA registry. New values can be		the existing OSPF IANA registry. New values can be allocated via
	allocated via IETF Consensus or IESG Approval.		IETF Consensus or IESG Approval.
	The following initial values are allocated:		The following initial values are allocated:
	o 0 - Reserved		o 0 - Reserved
	Types in the range 32768-33023 are for experimental use; these will		Types in the range 32768-33023 are for experimental use; these will
	not be registered with IANA, and MUST NOT be mentioned by RFCs.		not be registered with IANA, and MUST NOT be mentioned by RFCs.
	Types in the range 33024-65535 are not to be assigned at this time.		Types in the range 33024-65535 are not to be assigned at this time.
	Before any assignments can be made in the 33024-65535 range, there		Before any assignments can be made in the 33024-65535 range, there
	MUST be an IETF specification that specifies IANA Considerations that		MUST be an IETF specification that specifies IANA Considerations that
	skipping to change at page 12, line 34 ¶		skipping to change at page 12, line 48 ¶
	Bradner, S., "Key words for use in RFCs to Indicate		Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", RFC 2119, March 1997.		Requirement Levels", RFC 2119, March 1997.
	[TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering		[TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering
	Extensions to OSPF", RFC 3630, September 2003.		Extensions to OSPF", RFC 3630, September 2003.
	7.2. Informative References		7.2. Informative References
	[I-D.ietf-ospf-ospfv3-lsa-extend]		[I-D.ietf-ospf-ospfv3-lsa-extend]
	Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3		Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3
	LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-05		LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-06
	(work in progress), November 2014.		(work in progress), February 2015.
	[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code		[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code
	Points", BCP 100, RFC 7120, January 2014.		Points", BCP 100, RFC 7120, January 2014.
	Authors' Addresses		Authors' Addresses
	Peter Psenak		Peter Psenak
	Cisco Systems		Cisco Systems
	Apollo Business Center		Apollo Business Center
	Mlynske nivy 43		Mlynske nivy 43
End of changes. 30 change blocks.
	49 lines changed or deleted		71 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/