Diff: draft-ietf-ospf-ospfv3-lsa-extend-02.txt - draft-ietf-ospf-ospfv3-lsa-extend-03.txt

	< draft-ietf-ospf-ospfv3-lsa-extend-02.txt	draft-ietf-ospf-ospfv3-lsa-extend-03.txt >

	Network Working Group A. Lindem	Network Working Group A. Lindem
	Internet-Draft Ericsson	Internet-Draft Ericsson
	Intended status: Standards Track S. Mirtorabi	Intended status: Standards Track S. Mirtorabi

	Expires: October 20, 2014 A. Roy	Expires: November 30, 2014 A. Roy
	F. Baker	F. Baker
	Cisco Systems	Cisco Systems

	April 18, 2014	May 29, 2014

	OSPFv3 LSA Extendibility	OSPFv3 LSA Extendibility

	draft-ietf-ospf-ospfv3-lsa-extend-02.txt	draft-ietf-ospf-ospfv3-lsa-extend-03.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

	skipping to change at page 1, line 41 ¶	skipping to change at page 1, line 41 ¶
	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 October 20, 2014.	This Internet-Draft will expire on November 30, 2014.

	Copyright Notice	Copyright Notice

	Copyright (c) 2014 IETF Trust and the persons identified as the	Copyright (c) 2014 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 5, line 5 ¶	skipping to change at page 5, line 5 ¶
	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

	OSPFv3 TLV-based LSAs were first proposed in "Multi-topology routing	OSPFv3 TLV-based LSAs were first proposed in "Multi-topology routing
	in OSPFv3 (MT-OSPFv3)" [MT-OSPFV3].	in OSPFv3 (MT-OSPFv3)" [MT-OSPFV3].

	Thanks for Peter Psenak for significant contributions to the backward	Thanks for Peter Psenak for significant contributions to the backward
	compatibility mechanisms.	compatibility mechanisms.


	Thanks go to Michael Barnes, Mike Dubrovsky, and Anton Smirnov for	Thanks go to Michael Barnes, Mike Dubrovsky, Anton Smirnov, and Tony
	review of the draft versions and discussions of backward	Przygienda for review of the draft versions and discussions of
	compatibility.	backward compatibility.

	Thanks to Alan Davey for review and comments including the suggestion	Thanks to Alan Davey for review and comments including the suggestion
	to separate the extended LSA TLV definitions from the extended LSAs	to separate the extended LSA TLV definitions from the extended LSAs
	definitions.	definitions.

	Thanks to David Lamparter for review and suggestions on backward	Thanks to David Lamparter for review and suggestions on backward
	compatibility.	compatibility.

	The RFC text was produced using Marshall Rose's xml2rfc tool.	The RFC text was produced using Marshall Rose's xml2rfc tool.


	skipping to change at page 26, line 16 ¶	skipping to change at page 26, line 16 ¶

	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-
	based OSPFv3 LSA extensions.	based OSPFv3 LSA extensions.


	For simplicity and to avoid the scaling impact of maintaining both	Two distinct backward compatibility modes are supported dependent on
	TLV and non-TLV based versions of the same LSA within a routing	the OSPFv3 routing domain migration requirements. For simplicity and
	domain, the base backward compatibility mode will not allow mixing of	to avoid the scaling impact of maintaining both TLV and non-TLV based
	LSA formats. Different formats could still be supported with	versions of the same LSA within a routing domain, the basic backward
	multiple OSPFv3 instances and separate OSPFv3 routing domains.	compatibility mode will not allow mixing of LSA formats. Different
	Additionally, a more complex mode is provided in Section 5.1, where	LSA formats could still be supported with multiple OSPFv3 instances
	both formats of LSA coexist. In order to facilitate backward	and separate OSPFv3 routing domains. Additionally, a more flexible
	compatibility, the OSPFv3 options field (as described in Appendix A.2	mode is provided in Section 5.1, where both formats of LSA coexist.
	of RFC 5340 [OSPFV3]), will contain two additional options bits. The	In order to facilitate backward compatibility, the OSPFv3 options
	EL-bits will be used to indicate that the OSPFv3 router's level of	field (as described in Appendix A.2 of RFC 5340 [OSPFV3]), will
	Extended LSA support. An OSPFv3 router configured to support	contain two additional options bits. The EL-bits will be used to
	extended LSAs WILL set its options field EL-bits in OSPFv3 Hello and	indicate that the OSPFv3 router's level of Extended LSA support. An
	Database Description packets as follows:	OSPFv3 router configured to support extended LSAs MUST set its
		options field EL-bits in OSPFv3 Hello and Database Description
		packets as follows:

	B'00'	B'00'
	None - Extended LSAs are not originate nor used in the SPF	None - Extended LSAs are not originate nor used in the SPF
	calculation.	calculation.

	B'01'	B'01'
	MixedModeOriginateOnly - Both extended and non-extended LSAs are	MixedModeOriginateOnly - Both extended and non-extended LSAs are
	originated. Non-extended LSAs are used in the SPF computation.	originated. Non-extended LSAs are used in the SPF computation.

	B'10'	B'10'

	skipping to change at page 28, line 27 ¶	skipping to change at page 28, line 29 ¶
	use the extended LSAs by configuring ExtendedLSASupport to	use the extended LSAs by configuring ExtendedLSASupport to
	MixedModeOriginateSPF. This can be done on a small subset of	MixedModeOriginateSPF. This can be done on a small subset of
	OSPFv3 Routers and the route tables can be verified.	OSPFv3 Routers and the route tables can be verified.

	3. When all the OSPFv3 Routers have been reconfigured to	3. When all the OSPFv3 Routers have been reconfigured to
	MixedModeOriginateSPF and the routing has been verified,	MixedModeOriginateSPF and the routing has been verified,
	reconfigure OSPFv3 Routers to purge or simply not refresh the	reconfigure OSPFv3 Routers to purge or simply not refresh the
	non-extended OSPFv3 LSA by configuring ExtendedLSASupport to	non-extended OSPFv3 LSA by configuring ExtendedLSASupport to
	Full.	Full.


		In order to prevent OSPFv3 routing domain routing loops, the
		advertised metrics in the extended and non-extended OSPFv3 LSAs MUST
		be identical.

	5.1.1. Area Extended LSA Mixed-Mode Backward Compatibility	5.1.1. Area Extended LSA Mixed-Mode Backward Compatibility

	An implementation MAY also support configuration allowing graceful	An implementation MAY also support configuration allowing graceful
	transition from the non-extended LSAs to the extended LSAs within a	transition from the non-extended LSAs to the extended LSAs within a
	single area. In these areas, the parameter AreaExtendedLSASupport	single area. In these areas, the parameter AreaExtendedLSASupport
	(Appendix B) may be configured to take precedence over the global	(Appendix B) may be configured to take precedence over the global
	parameter ExtendedLSASupport. However, the AreaExtendedLSASupport	parameter ExtendedLSASupport. However, the AreaExtendedLSASupport
	will only apply to link and area scoped LSAs within the area and area	will only apply to link and area scoped LSAs within the area and area
	based SPF calculations. The default is for the	based SPF calculations. The default is for the
	AreaExtendedLSASupport to be inherited from the ExtendedLSASupport.	AreaExtendedLSASupport to be inherited from the ExtendedLSASupport.

End of changes. 7 change blocks.
	20 lines changed or deleted	26 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/