< draft-ietf-ospf-rfc4970bis-02.txt		draft-ietf-ospf-rfc4970bis-03.txt >
	Network Working Group A. Lindem, Ed.		Network Working Group A. Lindem, Ed.
	Internet-Draft N. Shen		Internet-Draft N. Shen
	Obsoletes: 4970 (if approved) J. Vasseur		Obsoletes: 4970 (if approved) J. Vasseur
	Intended status: Standards Track Cisco Systems		Intended status: Standards Track Cisco Systems
	Expires: February 22, 2016 R. Aggarwal		Expires: March 26, 2016 R. Aggarwal
	Arktan		Arktan
	S. Shaffer		S. Shaffer
	Akamai		Akamai
	August 21, 2015		September 23, 2015
	Extensions to OSPF for Advertising Optional Router Capabilities		Extensions to OSPF for Advertising Optional Router Capabilities
	draft-ietf-ospf-rfc4970bis-02.txt		draft-ietf-ospf-rfc4970bis-03.txt
	Abstract		Abstract
	It is useful for routers in an OSPFv2 or OSPFv3 routing domain to		It is useful for routers in an OSPFv2 or OSPFv3 routing domain to
	know the capabilities of their neighbors and other routers in the		know the capabilities of their neighbors and other routers in the
	routing domain. This document proposes extensions to OSPFv2 and		routing domain. This document proposes extensions to OSPFv2 and
	OSPFv3 for advertising optional router capabilities. The Router		OSPFv3 for advertising optional router capabilities. The Router
	Information (RI) Link State Advertisement (LSA) is defined for this		Information (RI) Link State Advertisement (LSA) is defined for this
	purpose. In OSPFv2, the RI LSA will be implemented with an opaque		purpose. In OSPFv2, the RI LSA will be implemented with an opaque
	LSA type ID. In OSPFv3, the RI LSA will be implemented with a unique		LSA type ID. In OSPFv3, the RI LSA will be implemented with a unique
	skipping to change at page 1, line 47 ¶		skipping to change at page 1, line 47 ¶
	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 February 22, 2016.		This Internet-Draft will expire on March 26, 2016.
	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 32 ¶		skipping to change at page 2, line 32 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3		1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3
	1.2. Summary of Changes from RFC 4970 . . . . . . . . . . . . 3		1.2. Summary of Changes from RFC 4970 . . . . . . . . . . . . 3
	2. OSPF Router Information (RI) LSA . . . . . . . . . . . . . . 3		2. OSPF Router Information (RI) LSA . . . . . . . . . . . . . . 3
	2.1. OSPFv2 Router Information (RI) Opaque LSA . . . . . . . . 4		2.1. OSPFv2 Router Information (RI) Opaque LSA . . . . . . . . 4
	2.2. OSPFv3 Router Information (RI) Opaque LSA . . . . . . . . 6		2.2. OSPFv3 Router Information (RI) Opaque LSA . . . . . . . . 6
	2.3. OSPF Router Informational Capabilities TLV . . . . . . . 6		2.3. OSPF Router Informational Capabilities TLV . . . . . . . 6
	2.4. Assigned OSPF Router Informational Capability Bits . . . 7		2.4. Assigned OSPF Router Informational Capability Bits . . . 7
	2.5. OSPF Router Functional Capabilities TLV . . . . . . . . . 8		2.5. OSPF Router Functional Capabilities TLV . . . . . . . . . 8
	2.6. Flooding Scope of the Router Information LSA . . . . . . 9		2.6. Flooding Scope of the Router Information LSA . . . . . . 9
	3. Security Considerations . . . . . . . . . . . . . . . . . . . 10		3. Backward Compatibility . . . . . . . . . . . . . . . . . . . 10
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	5. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	5.1. Normative References . . . . . . . . . . . . . . . . . . 12		6. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
	5.2. Informative References . . . . . . . . . . . . . . . . . 13		6.1. Normative References . . . . . . . . . . . . . . . . . . 13
			6.2. Informative References . . . . . . . . . . . . . . . . . 13
	Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 13		Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Introduction		1. Introduction
	It is useful for routers in an OSPFv2 [OSPF] or OSPFv3 [OSPFV3]		It is useful for routers in an OSPFv2 [OSPF] or OSPFv3 [OSPFV3]
	routing domain to know the capabilities of their neighbors and other		routing domain to know the capabilities of their neighbors and other
	routers in the routing domain. This can be useful for both the		routers in the routing domain. This can be useful for both the
	advertisement and discovery of OSPFv2 and OSPFv3 capabilities.		advertisement and discovery of OSPFv2 and OSPFv3 capabilities.
	Throughout this document, OSPF will be used when the specification is		Throughout this document, OSPF will be used when the specification is
	skipping to change at page 3, line 44 ¶		skipping to change at page 3, line 45 ¶
	3. Finally, references have been updated for drafts that have become		3. Finally, references have been updated for drafts that have become
	RFCs and RFCs that have been obsoleted since the publication of		RFCs and RFCs that have been obsoleted since the publication of
	RFC 4970.		RFC 4970.
	2. OSPF Router Information (RI) LSA		2. OSPF Router Information (RI) LSA
	OSPFv2 routers will advertise a link scoped, area-scoped, or AS-		OSPFv2 routers will advertise a link scoped, area-scoped, or AS-
	scoped Opaque-LSA [OPAQUE]. The OSPFv2 Router Information (RI) LSA		scoped Opaque-LSA [OPAQUE]. The OSPFv2 Router Information (RI) LSA
	has an Opaque type of 4 and the Opaque ID is the RI LSA instance ID.		has an Opaque type of 4 and the Opaque ID is the RI LSA instance ID.
	The first Opaque ID, i.e., 0, should always contain the Router		The first Opaque ID, i.e., 0, SHOULD always contain the Router
	Informational Capabilities TLV and, if advertised, the Router		Informational Capabilities TLV and, if advertised, the Router
	Functional Capabilities TLV. RI LSAs subsequence to the first can be		Functional Capabilities TLV. RI LSAs subsequence to the first can be
	used for information that doesn't fit in the first instance.		used for information that doesn't fit in the first instance.
	2.1. OSPFv2 Router Information (RI) Opaque LSA		2.1. OSPFv2 Router Information (RI) Opaque LSA
	OSPFv2 routers will advertise a link scoped, area-scoped, or AS-		OSPFv2 routers will advertise a link scoped, area-scoped, or AS-
	scoped Opaque-LSA [OPAQUE]. The OSPFv2 Router Information LSA has an		scoped Opaque-LSA [OPAQUE]. The OSPFv2 Router Information LSA has an
	Opaque type of 4 and Opaque ID specifies the LSA instance ID with the		Opaque type of 4 and Opaque ID specifies the LSA instance ID with the
	first instance always having an Instance ID of 0.		first instance always having an Instance ID of 0.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| LS age | Options | 9, 10, or 11 |		| LS age | Options | 9, 10, or 11 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 4 | Opaque ID (Instance ID) |		| 4 | Opaque ID (Instance ID) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Advertising Router |		| Advertising Router |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| LS sequence number |		| LS sequence number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| LS checksum | length |		| LS checksum | length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+- TLVs -+		+- TLVs -+
	| ... |		| ... |
	skipping to change at page 6, line 12 ¶		skipping to change at page 6, line 12 ¶
	portion of the TLV. The padding is composed of zeros. Unrecognized		portion of the TLV. The padding is composed of zeros. Unrecognized
	types are ignored.		types are ignored.
	2.2. OSPFv3 Router Information (RI) Opaque LSA		2.2. OSPFv3 Router Information (RI) Opaque LSA
	The OSPFv3 Router Information LSA has a function code of 12 while the		The OSPFv3 Router Information LSA has a function code of 12 while the
	S1/S2 bits are dependent on the desired flooding scope for the LSA.		S1/S2 bits are dependent on the desired flooding scope for the LSA.
	The U bit will be set indicating that the OSPFv3 RI LSA should be		The U bit will be set indicating that the OSPFv3 RI LSA should be
	flooded even if it is not understood. The Link State ID (LSID) value		flooded even if it is not understood. The Link State ID (LSID) value
	for this LSA is the instance ID. The first instance ID, i.e., 0,		for this LSA is the instance ID. The first instance ID, i.e., 0,
	should always contain the Router Informational Capabilities TLV and,		SHOULD always contain the Router Informational Capabilities TLV and,
	if advertised, the Router Functional Capabilities TLV. OSPFv3 Router		if advertised, the Router Functional Capabilities TLV. OSPFv3 Router
	Information LSAs subsequence to the first can be used for information		Information LSAs subsequence to the first can be used for information
	that doesn't fit in the first instance. OSPFv3 routers MAY advertise		that doesn't fit in the first instance. OSPFv3 routers MAY advertise
	multiple RIs LSA per flooding scope.		multiple RI LSAs per flooding scope.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| LS age |1|S12| 12 |		| LS age |1|S12| 12 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Link State ID (Instance ID) |		| Link State ID (Instance ID) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Advertising Router |		| Advertising Router |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 6, line 46 ¶		skipping to change at page 6, line 46 ¶
	The format of the TLVs within the body of an RI LSA is as defined in		The format of the TLVs within the body of an RI LSA is as defined in
	Section 2.1		Section 2.1
	When a new Router Information LSA TLV is defined, the specification		When a new Router Information LSA TLV is defined, the specification
	MUST explicitly state whether the TLV is applicable to OSPFv2 only,		MUST explicitly state whether the TLV is applicable to OSPFv2 only,
	OSPFv3 only, or both OSPFv2 and OSPFv3.		OSPFv3 only, or both OSPFv2 and OSPFv3.
	2.3. OSPF Router Informational Capabilities TLV		2.3. OSPF Router Informational Capabilities TLV
	The first defined TLV in the body of an RI LSA is the Router		An OSPF router advertising an OSPF RI LSA MAY include the Router
	Informational Capabilities TLV. An OSPF router advertising an OSPF		Informational Capabilities TLV. If included, it MUST be the first
	RI LSA MAY include the Router Informational Capabilities TLV. If		TLV in the first instance, i.e., instance 0, of the OSPF RI LSA.
	included, it MUST be the first TLV in the first instance of the OSPF		Additionally, the TLV MUST accurately reflect the OSPF router's
	RI LSA. Additionally, the TLV MUST accurately reflect the OSPF		capabilities in the scope advertised. However, the informational
	router's capabilities in the scope advertised. However, the		capabilities advertised have no impact on the OSPF's operation, they
	informational capabilities advertised have no impact on the OSPF's		are advertised purely for informational purposes.
	operation -- they are advertised purely for informational purposes.
	The format of the Router Informational Capabilities TLV is as		The format of the Router Informational Capabilities TLV is as
	follows:		follows:
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Informational Capabilities |		| Informational Capabilities |
	skipping to change at page 8, line 13 ¶		skipping to change at page 8, line 13 ¶
	The following informational capability bits are assigned:		The following informational capability bits are assigned:
	Bit Capabilities		Bit Capabilities
	0 OSPF graceful restart capable [GRACE]		0 OSPF graceful restart capable [GRACE]
	1 OSPF graceful restart helper [GRACE]		1 OSPF graceful restart helper [GRACE]
	2 OSPF Stub Router support [STUB]		2 OSPF Stub Router support [STUB]
	3 OSPF Traffic Engineering support [TE]		3 OSPF Traffic Engineering support [TE]
	4 OSPF point-to-point over LAN [P2PLAN]		4 OSPF point-to-point over LAN [P2PLAN]
	5 OSPF Experimental TE [EXP-TE]		5 OSPF Experimental TE [EXP-TE]
	6-31 Unassigned (Standards Action)		6-31 Unassigned (IETF Review)
	OSPF Router Informational Capabilities Bits		OSPF Router Informational Capabilities Bits
	References for [GRACE], [STUB], [TE], [P2PLAN], and [EXP-TE] are		References for [GRACE], [STUB], [TE], [P2PLAN], and [EXP-TE] are
	included herein.		included herein.
	2.5. OSPF Router Functional Capabilities TLV		2.5. OSPF Router Functional Capabilities TLV
	This specification also defines the Router Functional Capabilities		This specification also defines the Router Functional Capabilities
	TLV for advertisement within the OSPF Router Information LSA. An		TLV for advertisement within the OSPF Router Information LSA. An
	skipping to change at page 9, line 13 ¶		skipping to change at page 9, line 13 ¶
	The format of the Router Functional Capabilities TLV is as follows:		The format of the Router Functional Capabilities TLV is as follows:
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Functional Capabilities |		| Functional Capabilities |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type A 16-bit field set to IANA TBD.		Type A 16-bit field set to IANA TBD (Suggested value 2).
	Length A 16-bit field that indicates the length of the value		Length A 16-bit field that indicates the length of the value
	portion in octets and will be a multiple of 4 octets		portion in octets and will be a multiple of 4 octets
	dependent on the number of capabilities advertised.		dependent on the number of capabilities advertised.
	Initially, the length will be 4, denoting 4 octets of		Initially, the length will be 4, denoting 4 octets of
	informational capability bits.		informational capability bits.
	Value A variable length sequence of capability bits rounded		Value A variable length sequence of capability bits rounded
	to a multiple of 4 octets padded with undefined bits.		to a multiple of 4 octets padded with undefined bits.
	Initially, there are 4 octets of capability bits. Bits		Initially, there are 4 octets of capability bits. Bits
	skipping to change at page 10, line 12 ¶		skipping to change at page 10, line 12 ¶
	scope. For example, a router may be an area border router but only		scope. For example, a router may be an area border router but only
	support traffic engineering (TE) in a subset of its attached areas.		support traffic engineering (TE) in a subset of its attached areas.
	The choice of flooding scope is made by the advertising router and is		The choice of flooding scope is made by the advertising router and is
	a matter of local policy. The originating router MAY advertise		a matter of local policy. The originating router MAY advertise
	multiple RI LSAs with the same instance ID as long as the flooding		multiple RI LSAs with the same instance ID as long as the flooding
	scopes differ. TLV flooding scope rules will be specified on a per-		scopes differ. TLV flooding scope rules will be specified on a per-
	TLV basis and MUST be specified in the accompanying specifications		TLV basis and MUST be specified in the accompanying specifications
	for future Router Information LSA TLVs.		for future Router Information LSA TLVs.
	3. Security Considerations		3. Backward Compatibility
			For backward compatibility, previously advertised Router Information
			TLVs SHOULD continue to be advertised in the first instance, i.e., 0,
			of the Router Information LSA. If a Router Information TLV is
			advertised in multiple Router Information LSA instances and the
			multiple instance processing is not explicitly specified in the RFC
			defining that Router Information TLV, the Router Instance TLV in the
			Router Information LSA with the numerically smallest Instance ID will
			be used and subsequent instances will be ignored.
			4. Security Considerations
	This document describes both a generic mechanism for advertising		This document describes both a generic mechanism for advertising
	router capabilities and a TLV for advertising informational and		router capabilities and a TLV for advertising informational and
	functional capability bits. The capability TLVs are less critical		functional capability bits. The capability TLVs are less critical
	than the topology information currently advertised by the base OSPF		than the topology information currently advertised by the base OSPF
	protocol. The security considerations for the generic mechanism are		protocol. The security considerations for the generic mechanism are
	dependent on the future application and, as such, should be described		dependent on the future application and, as such, should be described
	as additional capabilities are proposed for advertisement. Security		as additional capabilities are proposed for advertisement. Security
	considerations for the base OSPF protocol are covered in [OSPF] and		considerations for the base OSPF protocol are covered in [OSPF] and
	[OSPFV3].		[OSPFV3].
	4. IANA Considerations		5. IANA Considerations
	The following IANA assignment was made from an existing registry:		The following IANA assignment was made from an existing registry:
	The OSPFv2 opaque LSA type 4 has been reserved for the OSPFv2 RI		The OSPFv2 opaque LSA type 4 has been reserved for the OSPFv2 RI
	opaque LSA.		opaque LSA.
	The following registries have been defined for the following		The following registries have been defined for the following
	purposes:		purposes:
	1. Registry for OSPFv3 LSA Function Codes - This top-level registry		1. Registry for OSPFv3 LSA Function Codes - This top-level registry
	will be comprised of the fields Value, LSA function code name,		will be comprised of the fields Value, LSA function code name,
	and Document Reference. The OSPFv3 LSA function code is defined		and Document Reference. The OSPFv3 LSA function code is defined
	in section A.4.2.1 of [OSPFV3]. The OSPFv3 LSA function code 12		in section A.4.2.1 of [OSPFV3]. The OSPFv3 LSA function code 12
	has been reserved for the OSPFv3 Router Information (RI) LSA.		has been reserved for the OSPFv3 Router Information (RI) LSA.
	+-----------+-------------------------------------+		+-----------+-------------------------------------+
	| Range | Assignment Policy |		| Range | Assignment Policy |
	+-----------+-------------------------------------+		+-----------+-------------------------------------+
	| 0 | Reserved (not to be assigned) |		| 0 | Reserved (not to be assigned) |
	| | |		| | |
	| 1-9 | Already assigned |		| 1-11 | Already assigned |
	| | |
	| 10-11 | Unassigned (Standards Action) |
	| | |		| | |
	| 12 | OSPFv3 RI LSA (Assigned herein) |		| 12 | OSPFv3 RI LSA (Assigned herein) |
	| | |		| | |
	| 13-255 | Unassigned (Standards Action) |		| 13-15 | Already assigned |
			| | |
			| 16-255 | Unassigned (IETF Review) |
	| | |		| | |
	| 256-8175 | Reserved (No assignments) |		| 256-8175 | Reserved (No assignments) |
	| | |		| | |
	| 8176-8183 | Experimentation (No assignments) |		| 8176-8183 | Experimentation (No assignments) |
	| | |		| | |
	| 8184-8191 | Vendor Private Use (No assignments) |		| 8184-8191 | Vendor Private Use (No assignments) |
	+-----------+-------------------------------------+		+-----------+-------------------------------------+
	OSPFv3 LSA Function Codes		OSPFv3 LSA Function Codes
	* OSPFv3 LSA function codes in the range 256-8175 are not to be		* OSPFv3 LSA function codes in the range 16-255 are not be
	assigned at this time. Before any assignments can be made in		assigned subject to IETF Review. New values are assigned only
	this range, there MUST be a Standards Track RFC that specifies		through RFCs that have been shepherded through the IESG as AD-
	IANA Considerations that cover the range being assigned.		Sponsored or IETF WG Documents [IANA-GUIDE].
	* OSPFv3 LSA function codes in the range 8176-8181 are for		* OSPFv3 LSA function codes in the range 8176-8181 are for
	experimental use; these will not be registered with IANA and		experimental use; these will not be registered with IANA and
	MUST NOT be mentioned by RFCs.		MUST NOT be mentioned by RFCs.
	* OSPFv3 LSAs with an LSA Function Code in the Vendor Private		* OSPFv3 LSAs with an LSA Function Code in the Vendor Private
	Use range 8184-8191 MUST include the Vendor Enterprise Code as		Use range 8184-8191 MUST include the Vendor Enterprise Code as
	the first 4 octets following the 20 octets of LSA header.		the first 4 octets following the 20 octets of LSA header.
	* If a new LSA Function Code is documented, the documentation		* If a new LSA Function Code is documented, the documentation
	MUST include the valid combinations of the U, S2, and S1 bits		MUST include the valid combinations of the U, S2, and S1 bits
	for the LSA. It SHOULD also describe how the Link State ID is		for the LSA. It SHOULD also describe how the Link State ID is
	to be assigned.		to be assigned.
	2. Registry for OSPF RI TLVs - This top-level registry will be		2. Registry for OSPF RI TLVs - This top-level registry will be
	comprised of the fields Value, TLV Name, and Document Reference.		comprised of the fields Value, TLV Name, and Document Reference.
	The value of 1 for the informational capabilities TLV is defined		The value of 1 for the informational capabilities TLV is defined
	herein. The value IANA TBD for the functional capabilities TLV		herein. The value IANA TBD (suggested value 2) for the Router
	is also defined herein.		Functional Capabilities TLV is also defined herein.
	+-------------+-----------------------------------+		+-------------+-----------------------------------+
	| Range | Assignment Policy |		| Range | Assignment Policy |
	+-------------+-----------------------------------+		+-------------+-----------------------------------+
	| 0 | Reserved (not to be assigned) |		| 0 | Reserved (not to be assigned) |
	| | |		| | |
	| 1 | Informational Capabilities |		| 1 | Informational Capabilities |
	| | |		| | |
			| 2 | Unassigned (IETF Review) |
			| | |
	| TBD | Functional Capabilities |		| TBD | Functional Capabilities |
	| | |		| | |
	| 2-32767 | Unassigned (Standards Action) |		| 3-9 | Already Assigned |
			| | |
			| 10-32767 | Unassigned (IETF Review) |
	| | |		| | |
	| 32768-32777 | Experimentation (No assignments) |		| 32768-32777 | Experimentation (No assignments) |
	| | |		| | |
	| 32778-65535 | Reserved (Not to be assigned) |		| 32778-65535 | Reserved (Not to be assigned) |
	+-----------+-------------------------------------+		+-----------+-------------------------------------+
	OSPF RI TLVs		OSPF RI TLVs
	* Types in the range 32768-32777 are for experimental use; these		* Types in the range 2, 10-32767 are to be assigned subject to
	will not be registered with IANA and MUST NOT be mentioned by		IETF Review. New values are assigned only through RFCs that
	RFCs.		have been shepherded through the IESG as AD-Sponsored or IETF
			WG Documents [IANA-GUIDE].
	* Types in the range 32778-65535 are reserved and are not to be		* Types in the range 32778-65535 are reserved and are not to be
	assigned at this time. Before any assignments can be made in		assigned at this time. Before any assignments can be made in
	this range, there MUST be a Standards Track RFC that specifies		this range, there MUST be a Standards Track RFC that specifies
	IANA Considerations that covers the range being assigned.		IANA Considerations that covers the range being assigned.
	3. Registry for OSPF Router Informational Capability Bits - This		3. Registry for OSPF Router Informational Capability Bits - This
	sub-registry of the OSPF RI TLV registry will be comprised of the		sub-registry of the OSPF RI TLV registry will be comprised of the
	fields Bit Number, Capability Name, and Document Reference. The		fields Bit Number, Capability Name, and Document Reference. The
	values are defined in Section 2.4. All Router Informational		values are defined in Section 2.4. All Router Informational
	Capability TLV additions are to be assigned through standards		Capability TLV additions are to be assigned through IETF Review.
	action.
	4. Registry for OSPF Router Functional Capability Bits - This sub-		4. Registry for OSPF Router Functional Capability Bits - This sub-
	registry of the OSPF RI TLV registry will be comprised of the		registry of the OSPF RI TLV registry will be comprised of the
	fields Bit Number, Capability Name, and Document Reference.		fields Bit Number, Capability Name, and Document Reference.
	Initially, the sub-registry will be empty but will be available		Initially, the sub-registry will be empty but will be available
	for future capabilities. All Router Functional Capability TLV		for future capabilities. All Router Functional Capability TLV
	additions are to be assigned through standards action.		additions are to be assigned through IETF Review.
	5. References		6. References
	5.1. Normative References		6.1. Normative References
	[OPAQUE] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The		[OPAQUE] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The
	OSPF Opaque LSA Option", RFC 5250, July 2008.		OSPF Opaque LSA Option", RFC 5250, July 2008.
	[OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.		[OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
	[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.
	[RFC-KEYWORDS]		[RFC-KEYWORDS]
	Bradner, S., "Key words for use in RFC's to Indicate		Bradner, S., "Key words for use in RFC's to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC4970] Lindem, A., Shen, N., Vasseur, J., Aggarwal, R., and S.		[RFC4970] Lindem, A., Shen, N., Vasseur, J., Aggarwal, R., and S.
	Shaffer, "Extensions to OSPF for Advertising Optional		Shaffer, "Extensions to OSPF for Advertising Optional
	Router Capabilities", RFC 4970, July 2007.		Router Capabilities", RFC 4970, July 2007.
	[TE] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering		[TE] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
	Extensions to OSPF", RFC 3630, September 2003.		Extensions to OSPF", RFC 3630, September 2003.
	5.2. Informative References		6.2. Informative References
	[EXP-TE] Srisuresh, P. and P. Joseph, "OSPF-xTE: Experimental		[EXP-TE] Srisuresh, P. and P. Joseph, "OSPF-xTE: Experimental
	Extension to OSPF for Traffic Engineering", RFC 4973, July		Extension to OSPF for Traffic Engineering", RFC 4973, July
	2007.		2007.
	[GRACE] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF		[GRACE] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF
	Restart", RFC 3623, November 2003.		Restart", RFC 3623, November 2003.
			[IANA-GUIDE]
			Narten, T. and H. Alvestrand, "Guidelines for Writing an
			IANA Considerations Section in RFCs", RFC 5226, May 2008.
	[P2PLAN] Shen, N. and A. Zinin, "Point-to-point operation over LAN		[P2PLAN] Shen, N. and A. Zinin, "Point-to-point operation over LAN
	in link-state routing protocols", RFC 5309, October 2008.		in link-state routing protocols", RFC 5309, October 2008.
	[STUB] Retana, A., Nguyen, L., White, R., Zinin, A., and D.		[STUB] Retana, A., Nguyen, L., White, R., Zinin, A., and D.
	McPherson, "OSPF Stub Router Advertisement", RFC 6987,		McPherson, "OSPF Stub Router Advertisement", RFC 6987,
	September 2013.		September 2013.
	Appendix A. Acknowledgments		Appendix A. Acknowledgments
	The idea for this work grew out of a conversation with Andrew Partan		The idea for this work grew out of a conversation with Andrew Partan
	and we would like to thank him for his contribution. The authors		and we would like to thank him for his contribution. The authors
	would like to thanks Peter Psenak for his review and helpful comments		would like to thanks Peter Psenak for his review and helpful comments
	on early versions of the document.		on early versions of the document.
	Comments from Abhay Roy, Vishwas Manral, Vivek Dubey, and Adrian		Comments from Abhay Roy, Vishwas Manral, Vivek Dubey, and Adrian
	Farrel have been incorporated into later versions.		Farrel have been incorporated into later versions.
	Thanks to Chris Bowers for review of the BIS version of the draft.		Thanks to Chris Bowers, Shraddha Hegde, and Alia Atlas for review of
			the BIS version of this document.
	The RFC text was produced using Marshall Rose's xml2rfc tool.		The RFC text was produced using Marshall Rose's xml2rfc tool.
	Authors' Addresses		Authors' Addresses
	Acee Lindem (editor)		Acee Lindem (editor)
	Cisco Systems		Cisco Systems
	301 Midenhall Way		301 Midenhall Way
	Cary, NC 27513		Cary, NC 27513
	USA		USA
End of changes. 28 change blocks.
	46 lines changed or deleted		66 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/