< draft-ietf-ospf-ospfv3-lsa-extend-19.txt		draft-ietf-ospf-ospfv3-lsa-extend-20.txt >
	Network Working Group A. Lindem		Network Working Group A. Lindem
	Internet-Draft A. Roy		Internet-Draft A. Roy
	Intended status: Standards Track Cisco Systems		Updates: 5340, 5838 (if approved) Cisco Systems
	Expires: June 21, 2018 D. Goethals		Intended status: Standards Track D. Goethals
	Nokia		Expires: June 29, 2018 Nokia
	V. Reddy Vallem		V. Reddy Vallem
	F. Baker		F. Baker
			December 26, 2017
	December 18, 2017
	OSPFv3 LSA Extendibility		OSPFv3 LSA Extendibility
	draft-ietf-ospf-ospfv3-lsa-extend-19.txt		draft-ietf-ospf-ospfv3-lsa-extend-20.txt
	Abstract		Abstract
	OSPFv3 requires functional extension beyond what can readily be done		OSPFv3 requires functional extension beyond what can readily be done
	with the fixed-format Link State Advertisement (LSA) as described in		with the fixed-format Link State Advertisement (LSA) as described in
	RFC 5340. Without LSA extension, attributes associated with OSPFv3		RFC 5340. Without LSA extension, attributes associated with OSPFv3
	links and advertised IPv6 prefixes must be advertised in separate		links and advertised IPv6 prefixes must be advertised in separate
	LSAs and correlated to the fixed-format LSAs. This document extends		LSAs and correlated to the fixed-format LSAs. This document extends
	the LSA format by encoding the existing OSPFv3 LSA information in		the LSA format by encoding the existing OSPFv3 LSA information in
	Type-Length-Value (TLV) tuples and allowing advertisement of		Type-Length-Value (TLV) tuples and allowing advertisement of
	additional information with additional TLVs. Backward compatibility		additional information with additional TLVs. Backward compatibility
	mechanisms are also described.		mechanisms are also described.
			This document updates RFC 5340, "OSPF for IPv6", and RFC 5838,
			"Support of Address Families in OSPFv3".
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on June 21, 2018.		This Internet-Draft will expire on June 29, 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 25 ¶		skipping to change at page 2, line 25 ¶
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4		1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4
	1.2. OSPFv3 LSA Terminology . . . . . . . . . . . . . . . . . 4		1.2. OSPFv3 LSA Terminology . . . . . . . . . . . . . . . . . 4
	1.3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 4
	2. OSPFv3 Extended LSA Types . . . . . . . . . . . . . . . . . . 4		2. OSPFv3 Extended LSA Types . . . . . . . . . . . . . . . . . . 4
	3. OSPFv3 Extended LSA TLVs . . . . . . . . . . . . . . . . . . 5		3. OSPFv3 Extended LSA TLVs . . . . . . . . . . . . . . . . . . 5
	3.1. Prefix Options Extensions . . . . . . . . . . . . . . . . 6		3.1. Prefix Options Extensions . . . . . . . . . . . . . . . . 6
	3.1.1. N-bit Prefix Option . . . . . . . . . . . . . . . . . 7		3.1.1. N-bit Prefix Option . . . . . . . . . . . . . . . . . 6
	3.2. Router-Link TLV . . . . . . . . . . . . . . . . . . . . . 7		3.2. Router-Link TLV . . . . . . . . . . . . . . . . . . . . . 7
	3.3. Attached-Routers TLV . . . . . . . . . . . . . . . . . . 8		3.3. Attached-Routers TLV . . . . . . . . . . . . . . . . . . 8
	3.4. Inter-Area-Prefix TLV . . . . . . . . . . . . . . . . . . 10		3.4. Inter-Area-Prefix TLV . . . . . . . . . . . . . . . . . . 9
	3.5. Inter-Area-Router TLV . . . . . . . . . . . . . . . . . . 11		3.5. Inter-Area-Router TLV . . . . . . . . . . . . . . . . . . 10
	3.6. External-Prefix TLV . . . . . . . . . . . . . . . . . . . 12		3.6. External-Prefix TLV . . . . . . . . . . . . . . . . . . . 11
	3.7. Intra-Area-Prefix TLV . . . . . . . . . . . . . . . . . . 13		3.7. Intra-Area-Prefix TLV . . . . . . . . . . . . . . . . . . 12
	3.8. IPv6 Link-Local Address TLV . . . . . . . . . . . . . . . 14		3.8. IPv6 Link-Local Address TLV . . . . . . . . . . . . . . . 13
	3.9. IPv4 Link-Local Address TLV . . . . . . . . . . . . . . . 15		3.9. IPv4 Link-Local Address TLV . . . . . . . . . . . . . . . 14
	3.10. IPv6-Forwarding-Address Sub-TLV . . . . . . . . . . . . . 16		3.10. IPv6-Forwarding-Address Sub-TLV . . . . . . . . . . . . . 15
	3.11. IPv4-Forwarding-Address Sub-TLV . . . . . . . . . . . . . 16		3.11. IPv4-Forwarding-Address Sub-TLV . . . . . . . . . . . . . 15
	3.12. Route-Tag Sub-TLV . . . . . . . . . . . . . . . . . . . . 17		3.12. Route-Tag Sub-TLV . . . . . . . . . . . . . . . . . . . . 16
	4. OSPFv3 Extended LSAs . . . . . . . . . . . . . . . . . . . . 17		4. OSPFv3 Extended LSAs . . . . . . . . . . . . . . . . . . . . 16
	4.1. OSPFv3 E-Router-LSA . . . . . . . . . . . . . . . . . . . 17		4.1. OSPFv3 E-Router-LSA . . . . . . . . . . . . . . . . . . . 16
	4.2. OSPFv3 E-Network-LSA . . . . . . . . . . . . . . . . . . 19		4.2. OSPFv3 E-Network-LSA . . . . . . . . . . . . . . . . . . 18
	4.3. OSPFv3 E-Inter-Area-Prefix-LSA . . . . . . . . . . . . . 20		4.3. OSPFv3 E-Inter-Area-Prefix-LSA . . . . . . . . . . . . . 19
	4.4. OSPFv3 E-Inter-Area-Router-LSA . . . . . . . . . . . . . 21		4.4. OSPFv3 E-Inter-Area-Router-LSA . . . . . . . . . . . . . 20
	4.5. OSPFv3 E-AS-External-LSA . . . . . . . . . . . . . . . . 22		4.5. OSPFv3 E-AS-External-LSA . . . . . . . . . . . . . . . . 21
	4.6. OSPFv3 E-NSSA-LSA . . . . . . . . . . . . . . . . . . . . 23		4.6. OSPFv3 E-NSSA-LSA . . . . . . . . . . . . . . . . . . . . 22
	4.7. OSPFv3 E-Link-LSA . . . . . . . . . . . . . . . . . . . . 24		4.7. OSPFv3 E-Link-LSA . . . . . . . . . . . . . . . . . . . . 23
	4.8. OSPFv3 E-Intra-Area-Prefix-LSA . . . . . . . . . . . . . 26		4.8. OSPFv3 E-Intra-Area-Prefix-LSA . . . . . . . . . . . . . 25
	5. Malformed OSPFv3 Extended LSA Handling . . . . . . . . . . . 27		5. Malformed OSPFv3 Extended LSA Handling . . . . . . . . . . . 26
	6. LSA Extension Backward Compatibility . . . . . . . . . . . . 27		6. LSA Extension Backward Compatibility . . . . . . . . . . . . 26
	6.1. Full Extended LSA Migration . . . . . . . . . . . . . . . 27		6.1. Full Extended LSA Migration . . . . . . . . . . . . . . . 26
	6.2. Extended LSA Spare-Mode Backward Compatibility . . . . . 28		6.2. Extended LSA Spare-Mode Backward Compatibility . . . . . 27
	6.3. LSA TLV Processing Backward Compatibility . . . . . . . . 28		6.3. LSA TLV Processing Backward Compatibility . . . . . . . . 27
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 29		7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
	8.1. OSPFv3 Extended-LSA TLV Registry . . . . . . . . . . . . 29		8.1. OSPFv3 Extended-LSA TLV Registry . . . . . . . . . . . . 28
	8.2. OSPFv3 Extended-LSA sub-TLV Registry . . . . . . . . . . 30		8.2. OSPFv3 Extended-LSA sub-TLV Registry . . . . . . . . . . 29
	9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31		9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 31		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
	10.1. Normative References . . . . . . . . . . . . . . . . . . 31		10.1. Normative References . . . . . . . . . . . . . . . . . . 30
	10.2. Informative References . . . . . . . . . . . . . . . . . 31		10.2. Informative References . . . . . . . . . . . . . . . . . 30
	Appendix A. Appendix A - Global Configuration Parameters . . . . 32		Appendix A. Appendix A - Global Configuration Parameters . . . . 31
	Appendix B. Appendix B - Area Configuration Parameters . . . . . 32		Appendix B. Appendix B - Area Configuration Parameters . . . . . 31
	Appendix C. Appendix C - Deprecated LSA Extension Backward		Appendix C. Appendix C - Deprecated LSA Extension Backward
	Compatibility . . . . . . . . . . . . . . . . . . . 32		Compatibility . . . . . . . . . . . . . . . . . . . 31
	C.1. Extended LSA Mixed-Mode Backward Compatibility . . . . . 34		C.1. Extended LSA Mixed-Mode Backward Compatibility . . . . . 33
	C.1.1. Area Extended LSA Mixed-Mode Backward Compatibility . 35		C.1.1. Area Extended LSA Mixed-Mode Backward Compatibility . 34
	C.2. Global Configuration Parameters . . . . . . . . . . . . . 36		C.2. Global Configuration Parameters . . . . . . . . . . . . . 35
	C.3. Area Configuration Parameters . . . . . . . . . . . . . . 36		C.3. Area Configuration Parameters . . . . . . . . . . . . . . 35
			Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 36
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
	1. Introduction		1. Introduction
	OSPFv3 requires functional extension beyond what can readily be done		OSPFv3 requires functional extension beyond what can readily be done
	with the fixed-format Link State Advertisement (LSA) as described in		with the fixed-format Link State Advertisement (LSA) as described in
	RFC 5340 [OSPFV3]. Without LSA extension, attributes associated with		RFC 5340 [OSPFV3]. Without LSA extension, attributes associated with
	OSPFv3 links and advertised IPv6 prefixes must be advertised in		OSPFv3 links and advertised IPv6 prefixes must be advertised in
	separate LSAs and correlated to the fixed-format LSAs. This document		separate LSAs and correlated to the fixed-format LSAs. This document
	extends the LSA format by encoding the existing OSPFv3 LSA		extends the LSA format by encoding the existing OSPFv3 LSA
	information in Type-Length-Value (TLV) tuples and allowing		information in Type-Length-Value (TLV) tuples and allowing
	advertisement of additional information with additional TLVs.		advertisement of additional information with additional TLVs.
	Backward compatibility mechanisms are also described.		Backward compatibility mechanisms are also described.
			This document updates [OSPFV3] and [OSPFV3-AF].
	A similar extension was previously proposed in support of multi-		A similar extension was previously proposed in support of multi-
	topology routing. Additional requirements for OSPFv3 LSA extension		topology routing. Additional requirements for OSPFv3 LSA extension
	include source/destination routing, route tagging, and others.		include source/destination routing, route tagging, and others.
	A final requirement is to limit the changes to OSPFv3 to those		A final requirement is to limit the changes to OSPFv3 to those
	necessary for TLV-based LSAs. For the most part, the semantics of		necessary for TLV-based LSAs. For the most part, the semantics of
	existing OSPFv3 LSAs are retained for their TLV-based successor LSAs		existing OSPFv3 LSAs are retained for their TLV-based successor LSAs
	described herein. Additionally, encoding details, e.g., the		described herein. Additionally, encoding details, e.g., the
	representation of IPv6 prefixes as described in section A.4.1 in RFC		representation of IPv6 prefixes as described in section A.4.1 in RFC
	5340 [OSPFV3], have been retained. This requirement was included to		5340 [OSPFV3], have been retained. This requirement was included to
	skipping to change at page 4, line 4 ¶		skipping to change at page 4, line 6 ¶
	necessary for TLV-based LSAs. For the most part, the semantics of		necessary for TLV-based LSAs. For the most part, the semantics of
	existing OSPFv3 LSAs are retained for their TLV-based successor LSAs		existing OSPFv3 LSAs are retained for their TLV-based successor LSAs
	described herein. Additionally, encoding details, e.g., the		described herein. Additionally, encoding details, e.g., the
	representation of IPv6 prefixes as described in section A.4.1 in RFC		representation of IPv6 prefixes as described in section A.4.1 in RFC
	5340 [OSPFV3], have been retained. This requirement was included to		5340 [OSPFV3], have been retained. This requirement was included to
	increase the expedience of IETF adoption and deployment.		increase the expedience of IETF adoption and deployment.
	The following aspects of OSPFv3 LSA extension are described:		The following aspects of OSPFv3 LSA extension are described:
	1. Extended LSA Types		1. Extended LSA Types
	2. Extended LSA TLVs		2. Extended LSA TLVs
	3. Extended LSA Formats		3. Extended LSA Formats
	4. Backward Compatibility		4. Backward Compatibility
	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. OSPFv3 LSA Terminology		1.2. OSPFv3 LSA Terminology
	The TLV-based OSPFv3 LSAs described in this document will be referred		The TLV-based OSPFv3 LSAs described in this document will be referred
	to as Extended LSAs. The OSPFv3 fixed-format LSAs [OSPFV3] will be		to as Extended LSAs. The OSPFv3 fixed-format LSAs [OSPFV3] will be
	referred to as Legacy LSAs.		referred to as Legacy LSAs.
	1.3. Acknowledgments
	OSPFv3 TLV-based LSAs were first proposed in "Multi-topology routing
	in OSPFv3 (MT-OSPFv3)" [MT-OSPFV3].
	Thanks for Peter Psenak for significant contributions to the backward
	compatibility mechanisms.
	Thanks go to Michael Barnes, Mike Dubrovsky, Anton Smirnov, and Tony
	Przygienda for review of the draft versions and discussions of
	backward compatibility.
	Thanks to Alan Davey for review and comments including the suggestion
	to separate the extended LSA TLV definitions from the extended LSAs
	definitions.
	Thanks to David Lamparter for review and suggestions on backward
	compatibility.
	Thanks to Karsten Thomann, Chris Bowers, Meng Zhang, and Nagendra
	Kumar for review and editorial comments.
	The RFC text was produced using Marshall Rose's xml2rfc tool.
	2. OSPFv3 Extended LSA Types		2. OSPFv3 Extended LSA Types
	In order to provide backward compatibility, new LSA codes must be		In order to provide backward compatibility, new LSA codes must be
	allocated. There are eight fixed-format LSAs defined in RFC 5340		allocated. There are eight fixed-format LSAs defined in RFC 5340
	[OSPFV3]. For ease of implementation and debugging, the LSA function		[OSPFV3]. For ease of implementation and debugging, the LSA function
	codes are the same as the fixed-format LSAs only with 32, i.e., 0x20,		codes are the same as the fixed-format LSAs only with 32, i.e., 0x20,
	added. The alternative to this mapping was to allocate a bit in the		added. The alternative to this mapping was to allocate a bit in the
	LS Type indicating the new LSA format. However, this would have used		LS Type indicating the new LSA format. However, this would have used
	one half the LSA function code space for the migration of the eight		one half the LSA function code space for the migration of the eight
	original fixed-format LSAs. For backward compatibility, the U-bit		original fixed-format LSAs. For backward compatibility, the U-bit
	skipping to change at page 5, line 44 ¶		skipping to change at page 5, line 24 ¶
	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... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	TLV Format		TLV Format
	The Length field defines the length of the value portion in octets		The Length field defines the length of the value portion in octets
	(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
	is padded to 4-octet alignment; padding is not included in the length		TLV is padded to 4-octet alignment; padding is not included in the
	field (so a 3-octet value would have a length of 3, but the total		length field (so a 3-octet value would have a length of 3, but the
	size of the TLV would be 8 octets). Nested TLVs are also 32-bit		total size of the TLV would be 8 octets). Nested TLVs are also
	aligned. For example, a 1-byte value would have the length field set		32-bit aligned. For example, a 1-byte value would have the length
	to 1, and 3 octets of padding would be added to the end of the value		field set to 1, and 3 octets of padding would be added to the end of
	portion of the TLV.		the value portion of the TLV.
	This document defines the following top-level TLV types:		This document defines the following top-level TLV types:
	o 0 - Reserved		o 0 - Reserved
	o 1 - Router-Link TLV		o 1 - Router-Link TLV
	o 2 - Attached-Routers TLV		o 2 - Attached-Routers TLV
	o 3 - Inter-Area Prefix TLV		o 3 - Inter-Area Prefix TLV
	skipping to change at page 6, line 26 ¶		skipping to change at page 6, line 4 ¶
	o 4 - Inter-Area Router TLV		o 4 - Inter-Area Router TLV
	o 5 - External Prefix TLV		o 5 - External Prefix TLV
	o 6 - Intra-Area Prefix TLV		o 6 - Intra-Area Prefix TLV
	o 7 - IPv6 Link-Local Address TLV		o 7 - IPv6 Link-Local Address TLV
	o 8 - IPv4 Link-Local Address TLV		o 8 - IPv4 Link-Local Address TLV
	Additionally, this document defines the following sub-TLV types:		Additionally, this document defines the following sub-TLV types:
	o 0 - Reserved		o 0 - Reserved
	o 1 - IPv6 Forwarding Address sub-TLV		o 1 - IPv6 Forwarding Address sub-TLV
	o 2 - IPv4 Forwarding Address sub-TLV		o 2 - IPv4 Forwarding Address sub-TLV
	o 3 - Route Tag sub-TLV		o 3 - Route Tag sub-TLV
	In general, TLVs and sub-TLVs MAY occur in any order and the		In general, TLVs and sub-TLVs MAY occur in any order and the
	specification should define whether the TLV or sub-TLV is required		specification should define whether the TLV or sub-TLV is required
	and the behavior when there are multiple occurances of the TLV or		and the behavior when there are multiple occurrences of the TLV or
	sub-TLVs.		sub-TLV. While this document only describes the usage of TLVs and
			Sub-TLVs, Sub-TLVs may be nested to any level as long as the Sub-TLVs
			are fully specified in the specification for the subsuming Sub-TLV.
	For backward compatibility, an LSA is not considered malformed from a		For backward compatibility, an LSA is not considered malformed from a
	TLV perspective unless either a required TLV is missing or a		TLV perspective unless either a required TLV is missing or a
	specified TLV is less than the minimum required length. Refer to		specified TLV is less than the minimum required length. Refer to
	Section 6.3 for more information on TLV backward compatibility.		Section 6.3 for more information on TLV backward compatibility.
	3.1. Prefix Options Extensions		3.1. Prefix Options Extensions
	The prefix options are extended from Appendix A.4.1.1 [OSPFV3]. The		The prefix options are extended from Appendix A.4.1.1 [OSPFV3]. The
	applicability of the LA-bit is expanded and it SHOULD be set in		applicability of the LA-bit is expanded and it SHOULD be set in
	skipping to change at page 7, line 34 ¶		skipping to change at page 7, line 16 ¶
	(PrefixLength=128) that identifies the advertising router. While it		(PrefixLength=128) that identifies the advertising router. While it
	is similar to the LA-bit, there are two differences. The advertising		is similar to the LA-bit, there are two differences. The advertising
	router MAY choose NOT to set the N-bit even when the above conditions		router MAY choose NOT to set the N-bit even when the above conditions
	are met. If the N-bit is set and the PrefixLength is NOT 128, the		are met. If the N-bit is set and the PrefixLength is NOT 128, the
	N-bit MUST be ignored. Additionally, the N-bit is propagated in the		N-bit MUST be ignored. Additionally, the N-bit is propagated in the
	PrefixOptions when an OSPFv3 Area Border Router (ABR) originates an		PrefixOptions when an OSPFv3 Area Border Router (ABR) originates an
	Inter-Area-Prefix-LSA for an Intra-Area route which has the N-bit set		Inter-Area-Prefix-LSA for an Intra-Area route which has the N-bit set
	in the PrefixOptions. Similarly, the N-bit is propagated in the		in the PrefixOptions. Similarly, the N-bit is propagated in the
	PrefixOptions when an OSPFv3 NSSA ABR originates an Extended-AS-		PrefixOptions when an OSPFv3 NSSA ABR originates an Extended-AS-
	External-LSA corresponding to an NSSA route as described in section 3		External-LSA corresponding to an NSSA route as described in section 3
	of RFC 3101 ([NSSA]). The N-bit is to the Inter-Area-Prefix-TLV		of RFC 3101 ([NSSA]). The N-bit is added to the Inter-Area-Prefix-
	(Section 3.4), External-Prefix-TLV (Section 3.6), and Intra-Area-		TLV (Section 3.4), External-Prefix-TLV (Section 3.6), and Intra-Area-
	Prefix-TLV (Section 3.7) The N-bit is useful for applications such as		Prefix-TLV (Section 3.7). The N-bit is useful for applications such
	identifying the prefixes corresponding to Node Segment Identifiers		as identifying the prefixes corresponding to Node Segment Identifiers
	(SIDs) in Segment Routing [SEGMENT-ROUTING].		(SIDs) in Segment Routing [SEGMENT-ROUTING].
	3.2. Router-Link TLV		3.2. Router-Link TLV
	The Router-Link TLV defines a single router link and the field		The Router-Link TLV defines a single router link and the field
	definitions correspond directly to links in the OSPFv3 Router-LSA,		definitions correspond directly to links in the OSPFv3 Router-LSA,
	section A.4.3, [OSPFV3]. The Router-Link TLV is only applicable to		section A.4.3, [OSPFV3]. The Router-Link TLV is only applicable to
	the E-Router-LSA (Section 4.1). Inclusion in other Extended LSAs		the E-Router-LSA (Section 4.1). Inclusion in other Extended LSAs
	MUST be ignored.		MUST be ignored.
	skipping to change at page 17, line 39 ¶		skipping to change at page 16, line 39 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Route Tag |		| Route Tag |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Route Tag Sub-TLV		Route Tag Sub-TLV
	4. OSPFv3 Extended LSAs		4. OSPFv3 Extended LSAs
	This section specifies the OSPFv3 Extended LSA formats and encoding.		This section specifies the OSPFv3 Extended LSA formats and encoding.
	The Extended OSPFv3 LSAs corresponded directly to the original OSPFv3		The Extended OSPFv3 LSAs corresponded directly to the original OSPFv3
	LSAs specifed in [OSPFV3].		LSAs specified in [OSPFV3].
	4.1. OSPFv3 E-Router-LSA		4.1. OSPFv3 E-Router-LSA
	The E-Router-LSA has an LS Type of 0xA021 and has the same base		The E-Router-LSA has an LS Type of 0xA021 and has the same base
	information content as the Router-LSA defined in section A.4.3 of		information content as the Router-LSA defined in section A.4.3 of
	[OSPFV3]. However, unlike the existing Router-LSA, it is fully		[OSPFV3]. However, unlike the existing Router-LSA, it is fully
	extendable and represented as TLVs.		extendable and represented as TLVs.
	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 18, line 27 ¶		skipping to change at page 17, line 27 ¶
	+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 0 |Nt|x|V|E|B| Options |		| 0 |Nt|x|V|E|B| Options |
	+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	. .		. .
	. TLVs .		. TLVs .
	. .		. .
	+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Extended Router-LSA		Extended Router-LSA
	Other than having a differnt LS Type, all LSA Header fields are the		Other than having a different LS Type, all LSA Header fields are the
	same as defined for the Router-LSA. Initially, only the top-level		same as defined for the Router-LSA. Initially, only the top-level
	Router-Link TLV Section 3.2 is applicable and an E-Router-LSA may		Router-Link TLV Section 3.2 is applicable and an E-Router-LSA may
	include multiple Router-Link TLVs. Like the existing Router-LSA, the		include multiple Router-Link TLVs. Like the existing Router-LSA, the
	LSA length is used to determine the end of the LSA including TLVs.		LSA length is used to determine the end of the LSA including TLVs.
			Depending on the implementation, it is perfectly valid for an E-
			Router-LSA to not contain any Router-Link TLVs. However, this would
			imply that the OSPFv3 router doesn't have any active interfaces in
			the corresponding area and such E-Router-LSA would never be flooded
			to other OSPFv3 routers in the area.
	4.2. OSPFv3 E-Network-LSA		4.2. OSPFv3 E-Network-LSA
	The E-Network-LSA has an LS Type of 0xA022 and has the same base		The E-Network-LSA has an LS Type of 0xA022 and has the same base
	information content as the Network-LSA defined in section A.4.4 of		information content as the Network-LSA defined in section A.4.4 of
	[OSPFV3]. However, unlike the existing Network-LSA, it is fully		[OSPFV3]. However, unlike the existing Network-LSA, it is fully
	extendable and represented as TLVs.		extendable and represented as TLVs.
	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 19, line 34 ¶		skipping to change at page 18, line 34 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 0 | Options |		| 0 | Options |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	. .		. .
	. TLVs .		. TLVs .
	. .		. .
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	E-Network-LSA		E-Network-LSA
	Other than having a differnt LS Type, all LSA Header fields are the		Other than having a different LS Type, all LSA Header fields are the
	same as defined for the Network-LSA. Like the existing Network-LSA,		same as defined for the Network-LSA. Like the existing Network-LSA,
	the LSA length is used to determine the end of the LSA including		the LSA length is used to determine the end of the LSA including
	TLVs. Initially, only the top-level Attached-Routers TLV Section 3.3		TLVs. Initially, only the top-level Attached-Routers TLV Section 3.3
	is applicable. If the Attached-Router TLV is not included in the E-		is applicable. If the Attached-Router TLV is not included in the E-
	Network-LSA, it is treated as malformed as described in Section 5.		Network-LSA, it is treated as malformed as described in Section 5.
	Instances of the Attached-Router TLV subsequent to the first MUST be		Instances of the Attached-Router TLV subsequent to the first MUST be
	ignored.		ignored.
	4.3. OSPFv3 E-Inter-Area-Prefix-LSA		4.3. OSPFv3 E-Inter-Area-Prefix-LSA
	skipping to change at page 20, line 32 ¶		skipping to change at page 19, line 32 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| LS Checksum | Length |		| LS Checksum | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	. .		. .
	. TLVs .		. TLVs .
	. .		. .
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	E-Inter-Area-Prefix-LSA		E-Inter-Area-Prefix-LSA
	Other than having a differnt LS Type, all LSA Header fields are the		Other than having a different LS Type, all LSA Header fields are the
	same as defined for the Inter-Area-Prefix-LSA. In order to retain		same as defined for the Inter-Area-Prefix-LSA. In order to retain
	compatibility and semantics with the current OSPFv3 specification,		compatibility and semantics with the current OSPFv3 specification,
	each Inter-Area-Prefix LSA MUST contain a single Inter-Area Prefix		each Inter-Area-Prefix LSA MUST contain a single Inter-Area Prefix
	TLV. This will facilitate migration and avoid changes to functions		TLV. This will facilitate migration and avoid changes to functions
	such as incremental SPF computation.		such as incremental SPF computation.
	Like the existing Inter-Area-Prefix-LSA, the LSA length is used to		Like the existing Inter-Area-Prefix-LSA, the LSA length is used to
	determine the end of the LSA including TLV. Initially, only the top-		determine the end of the LSA including TLV. Initially, only the top-
	level Inter-Area-Prefix TLV (Section 3.4) is applicable. If the		level Inter-Area-Prefix TLV (Section 3.4) is applicable. If the
	Inter-Area-Prefix TLV is not included in the E-Inter-Area-Prefix-LSA,		Inter-Area-Prefix TLV is not included in the E-Inter-Area-Prefix-LSA,
	skipping to change at page 21, line 32 ¶		skipping to change at page 20, line 32 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| LS Checksum | Length |		| LS Checksum | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	. .		. .
	. TLVs .		. TLVs .
	. .		. .
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	E-Inter-Area-Router-LSA		E-Inter-Area-Router-LSA
	Other than having a differnt LS Type, all LSA Header fields are the		Other than having a different LS Type, all LSA Header fields are the
	same as defined for the Inter-Area-Router-LSA. In order to retain		same as defined for the Inter-Area-Router-LSA. In order to retain
	compatibility and semantics with the current OSPFv3 specification,		compatibility and semantics with the current OSPFv3 specification,
	each Inter-Area-Router LSA MUST contain a single Inter-Area Router		each Inter-Area-Router LSA MUST contain a single Inter-Area Router
	TLV. This will facilitate migration and avoid changes to functions		TLV. This will facilitate migration and avoid changes to functions
	such as incremental SPF computation.		such as incremental SPF computation.
	Like the existing Inter-Area-Router-LSA, the LSA length is used to		Like the existing Inter-Area-Router-LSA, the LSA length is used to
	determine the end of the LSA including TLV. Initially, only the top-		determine the end of the LSA including TLV. Initially, only the top-
	level Inter-Area-Router TLV (Section 3.5) is applicable. If the		level Inter-Area-Router TLV (Section 3.5) is applicable. If the
	Inter-Area-Router TLV is not included in the E-Inter-Area-Router-LSA,		Inter-Area-Router TLV is not included in the E-Inter-Area-Router-LSA,
	skipping to change at page 22, line 32 ¶		skipping to change at page 21, line 32 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| LS Checksum | Length |		| LS Checksum | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	. .		. .
	. TLVs .		. TLVs .
	. .		. .
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	E-AS-External-LSA		E-AS-External-LSA
	Other than having a differnt LS Type, all LSA Header fields are the		Other than having a different LS Type, all LSA Header fields are the
	same as defined for the AS-External-LSA. In order to retain		same as defined for the AS-External-LSA. In order to retain
	compatibility and semantics with the current OSPFv3 specification,		compatibility and semantics with the current OSPFv3 specification,
	each LSA MUST contain a single External Prefix TLV. This will		each LSA MUST contain a single External Prefix TLV. This will
	facilitate migration and avoid changes to OSPFv3 processes such as		facilitate migration and avoid changes to OSPFv3 processes such as
	incremental SPF computation.		incremental SPF computation.
	Like the existing AS-External-LSA, the LSA length is used to		Like the existing AS-External-LSA, the LSA length is used to
	determine the end of the LSA including sub-TLVs. Initially, only the		determine the end of the LSA including sub-TLVs. Initially, only the
	top-level External-Prefix TLV (Section 3.6) is applicable. If the		top-level External-Prefix TLV (Section 3.6) is applicable. If the
	External-Prefix TLV is not included in the E-External-AS-LSA, it is		External-Prefix TLV is not included in the E-External-AS-LSA, it is
	skipping to change at page 24, line 34 ¶		skipping to change at page 23, line 34 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Rtr Priority | Options |		| Rtr Priority | Options |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	. .		. .
	. TLVs .		. TLVs .
	. .		. .
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	E-Link-LSA		E-Link-LSA
	Other than having a differnt LS Type, all LSA Header fields are the		Other than having a different LS Type, all LSA Header fields are the
	same as defined for the Link-LSA.		same as defined for the Link-LSA.
	Only the Intra-Area-Prefix TLV (Section 3.7), IPv6 Link-Local Address		Only the Intra-Area-Prefix TLV (Section 3.7), IPv6 Link-Local Address
	TLV (Section 3.8), and IPv4 Link-Local Address TLV (Section 3.9) are		TLV (Section 3.8), and IPv4 Link-Local Address TLV (Section 3.9) are
	applicable to the E-Link-LSA. Like the Link-LSA, the E-Link-LSA		applicable to the E-Link-LSA. Like the Link-LSA, the E-Link-LSA
	affords advertisement of multiple intra-area prefixes. Hence,		affords advertisement of multiple intra-area prefixes. Hence,
	multiple Intra-Area Prefix TLVs (Section 3.7) may be specified and		multiple Intra-Area Prefix TLVs (Section 3.7) may be specified and
	the LSA length defines the end of the LSA including all TLVs.		the LSA length defines the end of the LSA including all TLVs.
	A single instance of the IPv6 Link-Local Address TLV (Section 3.8)		A single instance of the IPv6 Link-Local Address TLV (Section 3.8)
	SHOULD be included in the E-Link-LSA. Instances following the first		SHOULD be included in the E-Link-LSA. Instances following the first
	MUST be ignored. For IPv4 address families as defined in		MUST be ignored. For IPv4 address families as defined in
	[OSPFV3-AF], this TLV MUST be ignored.		[OSPFV3-AF], this TLV MUST be ignored.
	Similarly, only a single instance of the IPv4 Link-Local Address TLV		Similarly, only a single instance of the IPv4 Link-Local Address TLV
	(Section 3.9) SHOULD be included in the E-Link-LSA. Instances		(Section 3.9) SHOULD be included in the E-Link-LSA. Instances
	following the first MUST be ignored. For OSPFv3 IPv6 address		following the first MUST be ignored. For OSPFv3 IPv6 address
	families as defined in [OSPFV3-AF], this TLV MUST be ignored.		families as defined in [OSPFV3-AF], this TLV SHOULD be ignored.
	If the IPv4/IPv6 Link-Local Address TLV corresponding to the OSPFv3		If the IPv4/IPv6 Link-Local Address TLV corresponding to the OSPFv3
	Address Family is not included in the E-Link-LSA, it is treated as		Address Family is not included in the E-Link-LSA, it is treated as
	malformed as described in Section 5.		malformed as described in Section 5.
	Future specifications may support advertisement of routing and		Future specifications may support advertisement of routing and
	topology information for multiple address families. However, this is		topology information for multiple address families. However, this is
	beyond the scope of this document.		beyond the scope of this document.
	4.8. OSPFv3 E-Intra-Area-Prefix-LSA		4.8. OSPFv3 E-Intra-Area-Prefix-LSA
	skipping to change at page 26, line 40 ¶		skipping to change at page 25, line 40 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Referenced Advertising Router |		| Referenced Advertising Router |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	. .		. .
	. TLVs .		. TLVs .
	. .		. .
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	E-Intra-Area-Prefix-LSA		E-Intra-Area-Prefix-LSA
	Other than having a differnt LS Type, all LSA Header fields are the		Other than having a different LS Type, all LSA Header fields are the
	same as defined for the Intra-Area-Prefix-LSA.		same as defined for the Intra-Area-Prefix-LSA.
	Like the Intra-Area-Prefix-LSA, the E-Intra-Area-Link-LSA affords		Like the Intra-Area-Prefix-LSA, the E-Intra-Area-Link-LSA affords
	advertisement of multiple intra-area prefixes. Hence, multiple		advertisement of multiple intra-area prefixes. Hence, multiple
	Intra-Area Prefix TLVs may be specified and the LSA length defines		Intra-Area Prefix TLVs may be specified and the LSA length defines
	the end of the LSA including all TLVs.		the end of the LSA including all TLVs.
	5. Malformed OSPFv3 Extended LSA Handling		5. Malformed OSPFv3 Extended LSA Handling
	Extended LSAs that have inconsistent length or other encoding errors,		Extended LSAs that have inconsistent length or other encoding errors,
	as described herein, MUST NOT be installed in the Link State		as described herein, MUST NOT be installed in the Link State
	Database, acknowledged, or flooded. Reception of malformed LSAs		Database, acknowledged, or flooded. Reception of malformed LSAs
	SHOULD be counted and/or logged for examination by the administrator		SHOULD be counted and/or logged for examination by the administrator
	of the OSPFv3 Routing Domain. Note that for the purposes of length		of the OSPFv3 Routing Domain. Note that for the purposes of length
	validation, a TLV or Sub-TLV should not be considered invalid unless		validation, a TLV or Sub-TLV should not be considered invalid unless
	the length exceeds the length of the LSA or does not meet the minimum		the length exceeds the length of the LSA or does not meet the minimum
	length requirements. This allows for Sub-TLVs to be added as		length requirements. This allows for Sub-TLVs to be added as
	described in Section 6.3.		described in Section 6.3.
	Additionally, an LSA MUST be considered malformed if it does not		Additionally, an LSA MUST be considered malformed if it does not
	include any required TLV or Sub-TLVs.		include all of the required TLVs and Sub-TLVs.
	6. LSA Extension Backward Compatibility		6. LSA Extension Backward Compatibility
	In the context of this document, backward compatibility is solely		In the context of this document, backward compatibility is solely
	related to the capability of an OSPFv3 router to receive, process,		related to the capability of an OSPFv3 router to receive, process,
	and originate the TLV-based LSAs defined herein. Unrecognized TLVs		and originate the TLV-based LSAs defined herein. Unrecognized TLVs
	and sub-TLVs are ignored. Backward compatibility for future OSPFv3		and sub-TLVs are ignored. Backward compatibility for future OSPFv3
	extensions utilizing the TLV-based LSAs is out of scope and must be		extensions utilizing the TLV-based LSAs is out of scope and must be
	covered in the documents describing those extensions. Both full and,		covered in the documents describing those extensions. Both full and,
	if applicable, partial deployment SHOULD be specified for future TLV-		if applicable, partial deployment SHOULD be specified for future TLV-
	skipping to change at page 28, line 9 ¶		skipping to change at page 27, line 9 ¶
	Bases (RIB) have been verified, the OSPFv3 instances using the		Bases (RIB) have been verified, the OSPFv3 instances using the
	extended LSAs can be given preference. When this has been completed		extended LSAs can be given preference. When this has been completed
	and the routing within the OSPF routing domain or area has been		and the routing within the OSPF routing domain or area has been
	verified, the original OSPFv3 instance using Legacy LSAs can be		verified, the original OSPFv3 instance using Legacy LSAs can be
	removed.		removed.
	6.2. Extended LSA Spare-Mode Backward Compatibility		6.2. Extended LSA Spare-Mode Backward Compatibility
	In this mode, OSPFv3 will use the Legacy LSAs for the SPF computation		In this mode, OSPFv3 will use the Legacy LSAs for the SPF computation
	and will only originate extended LSAs when LSA origination is		and will only originate extended LSAs when LSA origination is
	required in support of addtional functionality. Furthermore, the		required in support of additional functionality. Furthermore, those
	extended LSAs will only include those TLVs which require further		extended LSAs will only include the top-level TLVs (e.g., Router-Link
	specification for that new functionality. Hence, this mode of		TLVs or Inter-Area TLVs) which require further specification for that
	compatibility is know as "sparse-mode". The advantage of sparse-mode		new functionality. However, if a top-level TLV is advertised, it
	is that functionality utilizing the OSPFv3 extended LSAs can be added		MUST include required Sub-TLVs or it will be considered malformed as
	to an existing OSFPv3 routing domain without the requirement for		described in Section 5. Hence, this mode of compatibility is known
	migration. In essence, this compatibility mode is very much like the		as "sparse-mode". The advantage of sparse-mode is that functionality
	approach taken for OSPFv2 [OSPF-PREFIX-LINK]. As with all the		utilizing the OSPFv3 extended LSAs can be added to an existing OSFPv3
	compatibility modes, backward compatibility for the functions		routing domain without the requirement for migration. In essence,
	utilizing the extended LSAs must be described in the IETF documents		this compatibility mode is very much like the approach taken for
	describing those functions.		OSPFv2 [OSPF-PREFIX-LINK]. As with all the compatibility modes,
			backward compatibility for the functions utilizing the extended LSAs
			must be described in the IETF documents describing those functions.
	6.3. LSA TLV Processing Backward Compatibility		6.3. LSA TLV Processing Backward Compatibility
	This section defines the general rules for processing LSA TLVs. To		This section defines the general rules for processing LSA TLVs. To
	ensure compatibility of future TLV-based LSA extensions, all		ensure compatibility of future TLV-based LSA extensions, all
	implementations MUST adhere to these rules:		implementations MUST adhere to these rules:
	1. Unrecognized TLVs and sub-TLVs are ignored when parsing or		1. Unrecognized TLVs and sub-TLVs are ignored when parsing or
	processing Extended-LSAs.		processing Extended-LSAs.
	skipping to change at page 28, line 43 ¶		skipping to change at page 27, line 45 ¶
	3. If partial deployment is not supported, mechanisms to ensure the		3. If partial deployment is not supported, mechanisms to ensure the
	corresponding feature are not deployed MUST be specified in the		corresponding feature are not deployed MUST be specified in the
	document defining the new TLV or sub-TLV.		document defining the new TLV or sub-TLV.
	4. If partial deployment is supported, backward compatibility and		4. If partial deployment is supported, backward compatibility and
	partial deployment MUST be specified in the document defining the		partial deployment MUST be specified in the document defining the
	new TLV or sub-TLV.		new TLV or sub-TLV.
	5. If a TLV or Sub-TLV is recognized but the length is less than the		5. If a TLV or Sub-TLV is recognized but the length is less than the
	minimum, then the LSA should be considered malformed and it		minimum, then the LSA should be considered malformed and it
	SHOULD NOT be acknowledged. Additionally, the occurence SHOULD		SHOULD NOT be acknowledged. Additionally, the occurrence SHOULD
	be logged with enough information to identify the LSA by type,		be logged with enough information to identify the LSA by type,
	originator, and sequence number and the TLV or Sub-TLV in error.		originator, and sequence number and the TLV or Sub-TLV in error.
	Ideally, the log entry would include the hexidecimal or binary		Ideally, the log entry would include the hexadecimal or binary
	representation of the LSA including the malformed TLS or Sub-TLV.		representation of the LSA including the malformed TLS or Sub-TLV.
	6. Documents specifying future TLVs or Sub-TLVs MUST specify the		6. Documents specifying future TLVs or Sub-TLVs MUST specify the
	requirements for usage of those TLVs or Sub-TLVs.		requirements for usage of those TLVs or Sub-TLVs.
	7. Future TLV or Sub-TLVs must be optional. However, there may be		7. Future TLV or Sub-TLVs must be optional. However, there may be
	requirements for Sub-TLVs if an optional TLV is specified.		requirements for Sub-TLVs if an optional TLV is specified.
	7. Security Considerations		7. Security Considerations
	skipping to change at page 30, line 16 ¶		skipping to change at page 29, line 16 ¶
	o 7 - IPv6 Link-Local Address TLV		o 7 - IPv6 Link-Local Address TLV
	o 8 - IPv4 Link-Local Address TLV		o 8 - IPv4 Link-Local Address TLV
	Types in the range 9-32767 are allocated via IETF Consensus or IESG		Types in the range 9-32767 are allocated via IETF Consensus or IESG
	Approval.		Approval.
	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-45055 are to be assigned on a FCFS basis
			subject to IETF expert review.
			Types in the range 45056-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.
	8.2. OSPFv3 Extended-LSA sub-TLV Registry		8.2. OSPFv3 Extended-LSA sub-TLV Registry
	The OSPFv3 Extended-LSA sub-TLV registry will define sub-TLVs at any		The OSPFv3 Extended-LSA sub-TLV registry will define sub-TLVs at any
	level of nesting for Extended-LSAs and should be placed in the		level of nesting for Extended-LSAs and should be placed in the
	existing OSPFv3 IANA registry.		existing OSPFv3 IANA registry.
	skipping to change at page 30, line 43 ¶		skipping to change at page 29, line 46 ¶
	o 2 - IPv4 Forwarding Address sub-TLV		o 2 - IPv4 Forwarding Address sub-TLV
	o 3 - Route Tag sub-TLV		o 3 - Route Tag sub-TLV
	Types in the range 4-32767 are allocated via IETF Consensus or IESG		Types in the range 4-32767 are allocated via IETF Consensus or IESG
	Approval.		Approval.
	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-45055 are to be assigned on a FCFS basis
			subject to IETF expert review.
			Types in the range 45056-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.
	9. Contributors		9. Contributors
	Contributors' Addresses		Contributors' Addresses
	Sina Mirtorabi		Sina Mirtorabi
	Cisco Systems		Cisco Systems
	skipping to change at page 31, line 32 ¶		skipping to change at page 30, line 34 ¶
	Restart", RFC 5187, June 2008.		Restart", RFC 5187, June 2008.
	[NSSA] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option",		[NSSA] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option",
	RFC 3101, January 2003.		RFC 3101, January 2003.
	[OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF		[OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
	for IPv6", RFC 5340, July 2008.		for IPv6", RFC 5340, July 2008.
	[OSPFV3-AF]		[OSPFV3-AF]
	Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R.		Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R.
	Aggarwal, "Support of Address Families in OSPFv3", RFC		Aggarwal, "Support of Address Families in OSPFv3",
	5838, April 2010.		RFC 5838, April 2010.
	[RFC-KEYWORDS]		[RFC-KEYWORDS]
	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.
	10.2. Informative References		10.2. Informative References
	skipping to change at page 36, line 32 ¶		skipping to change at page 35, line 34 ¶
	originated. OSPFv3 adjacencies will be formed with OSPFv3		originated. OSPFv3 adjacencies will be formed with OSPFv3
	routers not supporting this specification. The Legacy LSAs are		routers not supporting this specification. The Legacy LSAs are
	used for the SPF computation.		used for the SPF computation.
	* MixedModeOriginateSPF - Both Extended LSAs and Legacy LSAs will		* MixedModeOriginateSPF - Both Extended LSAs and Legacy LSAs will
	be originated. OSPFv3 adjacencies will be formed with OSPFv3		be originated. OSPFv3 adjacencies will be formed with OSPFv3
	routers not supporting this specification. The Extended LSAs		routers not supporting this specification. The Extended LSAs
	are used for the SPF computation.		are used for the SPF computation.
	* Full - Extended LSAs will be originated and adjacencies will		* Full - Extended LSAs will be originated and adjacencies will
	ndot be formed with OSPFv3 routers not supporting this		not be formed with OSPFv3 routers not supporting this
	specification. Only Extended LSAs will be originated.		specification. Only Extended LSAs will be originated.
	C.3. Area Configuration Parameters		C.3. Area Configuration Parameters
	An additional area configurable parameter will be added to the OSPFv3		An additional area configurable parameter will be added to the OSPFv3
	protocol.		protocol.
	AreaExtendedLSASupport		AreaExtendedLSASupport
	This is an enumeration type indicating the extent to which the		This is an enumeration type indicating the extent to which the
	OSPFv3 area supports the TLV format described herein for Extended		OSPFv3 area supports the TLV format described herein for Extended
	LSAs. The valid value for the enumeration are:		LSAs. The valid value for the enumeration are:
	* InheritGlobal - The AreaExtendedLSASupport will be inherited		* InheritGlobal - The AreaExtendedLSASupport will be inherited
	from ExtendedLSASupport. This is the default.		from ExtendedLSASupport. This is the default.
	* None - Extended LSAs will not be originated or used in the SPF		* None - Extended LSAs will not be originated or used in the SPF
	calculation. This is the default. When OSPFv3 functions		calculation. This is the default. When OSPFv3 functions
	requiring extended LSA are configured, and the		requiring extended LSA are configured, and the
	ExtendedLSASuppport is "None", the spare-mode compatability is		ExtendedLSASuppport is "None", the spare-mode compatibility is
	in effect Section 6.2.		in effect Section 6.2.
	* MixedModeOriginateOnly - Both extended and legacy link and area		* MixedModeOriginateOnly - Both extended and legacy link and area
	scoped LSAs will be originated. OSPFv3 adjacencies will be		scoped LSAs will be originated. OSPFv3 adjacencies will be
	formed with OSPFv3 routers not supporting this specification.		formed with OSPFv3 routers not supporting this specification.
	The Legacy LSAs are used for the area SPF computation.		The Legacy LSAs are used for the area SPF computation.
	* MixedModeOriginateSPF - Both extended and legacy link and area		* MixedModeOriginateSPF - Both extended and legacy link and area
	scoped LSAs will be originated. OSPFv3 adjacencies will be		scoped LSAs will be originated. OSPFv3 adjacencies will be
	formed with OSPFv3 routers not supporting this specification.		formed with OSPFv3 routers not supporting this specification.
	skipping to change at page 37, line 31 ¶		skipping to change at page 36, line 34 ¶
	* Full - Link and area scoped Extended LSAs will be originated		* Full - Link and area scoped Extended LSAs will be originated
	and adjacencies will not be formed with OSPFv3 routers not		and adjacencies will not be formed with OSPFv3 routers not
	supporting this specification. Only Extended LSAs will be		supporting this specification. Only Extended LSAs will be
	originated.		originated.
	For regular areas, i.e., areas where AS scoped LSAs are flooded,		For regular areas, i.e., areas where AS scoped LSAs are flooded,
	configuring None or MixedModeOriginateOnly for AreaExtendedLSASupport		configuring None or MixedModeOriginateOnly for AreaExtendedLSASupport
	when Full is specified for ExtendedLSASupport is contradictory and		when Full is specified for ExtendedLSASupport is contradictory and
	MAY be prohibited by the implementation.		MAY be prohibited by the implementation.
			Appendix D. Acknowledgments
			OSPFv3 TLV-based LSAs were first proposed in "Multi-topology routing
			in OSPFv3 (MT-OSPFv3)" [MT-OSPFV3].
			Thanks for Peter Psenak for significant contributions to the backward
			compatibility mechanisms.
			Thanks go to Michael Barnes, Mike Dubrovsky, Anton Smirnov, and Tony
			Przygienda for review of the draft versions and discussions of
			backward compatibility.
			Thanks to Alan Davey for review and comments including the suggestion
			to separate the extended LSA TLV definitions from the extended LSAs
			definitions.
			Thanks to David Lamparter for review and suggestions on backward
			compatibility.
			Thanks to Karsten Thomann, Chris Bowers, Meng Zhang, and Nagendra
			Kumar for review and editorial comments.
			Thanks to Alia Atlas for substantive Routing Area Director (AD)
			comments prior to IETF last call.
			The RFC text was produced using Marshall Rose's xml2rfc tool.
	Authors' Addresses		Authors' Addresses
	Acee Lindem		Acee Lindem
	Cisco Systems		Cisco Systems
	301 Midenhall Way		301 Midenhall Way
	Cary, NC 27513		Cary, NC 27513
	USA		USA
	Email: acee@cisco.com		Email: acee@cisco.com
End of changes. 36 change blocks.
	114 lines changed or deleted		136 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/