< draft-ietf-ospf-ospfv3-lsa-extend-08.txt   draft-ietf-ospf-ospfv3-lsa-extend-09.txt >
Network Working Group A. Lindem Network Working Group A. Lindem
Internet-Draft S. Mirtorabi Internet-Draft S. Mirtorabi
Intended status: Standards Track A. Roy Intended status: Standards Track A. Roy
Expires: April 10, 2016 F. Baker Expires: May 22, 2016 F. Baker
Cisco Systems Cisco Systems
October 8, 2015 November 19, 2015
OSPFv3 LSA Extendibility OSPFv3 LSA Extendibility
draft-ietf-ospf-ospfv3-lsa-extend-08.txt draft-ietf-ospf-ospfv3-lsa-extend-09.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 40 skipping to change at page 1, line 40
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 April 10, 2016. This Internet-Draft will expire on May 22, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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 . . . . . . . . . . . . . . . . . . 3 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3
1.2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . 7 3.3. Attached-Routers TLV . . . . . . . . . . . . . . . . . . 8
3.4. Inter-Area-Prefix TLV . . . . . . . . . . . . . . . . . . 9 3.4. Inter-Area-Prefix TLV . . . . . . . . . . . . . . . . . . 10
3.5. Inter-Area-Router TLV . . . . . . . . . . . . . . . . . . 10 3.5. Inter-Area-Router TLV . . . . . . . . . . . . . . . . . . 11
3.6. External-Prefix TLV . . . . . . . . . . . . . . . . . . . 11 3.6. External-Prefix TLV . . . . . . . . . . . . . . . . . . . 12
3.7. Intra-Area-Prefix TLV . . . . . . . . . . . . . . . . . . 12 3.7. Intra-Area-Prefix TLV . . . . . . . . . . . . . . . . . . 13
3.8. IPv6 Link-Local Address TLV . . . . . . . . . . . . . . . 13 3.8. IPv6 Link-Local Address TLV . . . . . . . . . . . . . . . 14
3.9. IPv4 Link-Local Address TLV . . . . . . . . . . . . . . . 14 3.9. IPv4 Link-Local Address TLV . . . . . . . . . . . . . . . 15
3.10. IPv6-Forwarding-Address Sub-TLV . . . . . . . . . . . . . 15 3.10. IPv6-Forwarding-Address Sub-TLV . . . . . . . . . . . . . 16
3.11. IPv4-Forwarding-Address Sub-TLV . . . . . . . . . . . . . 15 3.11. IPv4-Forwarding-Address Sub-TLV . . . . . . . . . . . . . 16
3.12. Route-Tag Sub-TLV . . . . . . . . . . . . . . . . . . . . 16 3.12. Route-Tag Sub-TLV . . . . . . . . . . . . . . . . . . . . 17
4. OSPFv3 Extended LSAs . . . . . . . . . . . . . . . . . . . . 16 4. OSPFv3 Extended LSAs . . . . . . . . . . . . . . . . . . . . 17
4.1. OSPFv3 E-Router-LSA . . . . . . . . . . . . . . . . . . . 16 4.1. OSPFv3 E-Router-LSA . . . . . . . . . . . . . . . . . . . 17
4.2. OSPFv3 E-Network-LSA . . . . . . . . . . . . . . . . . . 18 4.2. OSPFv3 E-Network-LSA . . . . . . . . . . . . . . . . . . 19
4.3. OSPFv3 E-Inter-Area-Prefix-LSA . . . . . . . . . . . . . 19 4.3. OSPFv3 E-Inter-Area-Prefix-LSA . . . . . . . . . . . . . 20
4.4. OSPFv3 E-Inter-Area-Router-LSA . . . . . . . . . . . . . 20 4.4. OSPFv3 E-Inter-Area-Router-LSA . . . . . . . . . . . . . 21
4.5. OSPFv3 E-AS-External-LSA . . . . . . . . . . . . . . . . 21 4.5. OSPFv3 E-AS-External-LSA . . . . . . . . . . . . . . . . 22
4.6. OSPFv3 E-NSSA-LSA . . . . . . . . . . . . . . . . . . . . 22 4.6. OSPFv3 E-NSSA-LSA . . . . . . . . . . . . . . . . . . . . 23
4.7. OSPFv3 E-Link-LSA . . . . . . . . . . . . . . . . . . . . 23 4.7. OSPFv3 E-Link-LSA . . . . . . . . . . . . . . . . . . . . 24
4.8. OSPFv3 E-Intra-Area-Prefix-LSA . . . . . . . . . . . . . 25 4.8. OSPFv3 E-Intra-Area-Prefix-LSA . . . . . . . . . . . . . 26
5. Malformed OSPFv3 Extended LSA Handling . . . . . . . . . . . 25 5. Malformed OSPFv3 Extended LSA Handling . . . . . . . . . . . 26
6. LSA Extension Backward Compatibility . . . . . . . . . . . . 26 6. LSA Extension Backward Compatibility . . . . . . . . . . . . 27
6.1. Extended LSA Mixed-Mode Backward Compatibility . . . . . 28 6.1. Full Extended LSA Migration . . . . . . . . . . . . . . . 27
6.1.1. Area Extended LSA Mixed-Mode Backward Compatibility . 28 6.2. Extended LSA Spare-Mode Backward Compatibility . . . . . 27
6.2. Extended LSA Spare-Mode Backward Compatibility . . . . . 29 6.3. LSA TLV Processing Backward Compatibility . . . . . . . . 28
6.3. LSA TLV Processing Backward Compatibility . . . . . . . . 29 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 9.1. Normative References . . . . . . . . . . . . . . . . . . 29
9.1. Normative References . . . . . . . . . . . . . . . . . . 31 9.2. Informative References . . . . . . . . . . . . . . . . . 30
9.2. Informative References . . . . . . . . . . . . . . . . . 32 Appendix A. Appendix A - Global Configuration Parameters . . . . 30
Appendix A. Global Configuration Parameters . . . . . . . . . . 32 Appendix B. Appendix B - Area Configuration Parameters . . . . . 31
Appendix B. Area Configuration Parameters . . . . . . . . . . . 33 Appendix C. Appendix C - Deprecated LSA Extension Backward
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 Compatibility . . . . . . . . . . . . . . . . . . . 31
C.1. Extended LSA Mixed-Mode Backward Compatibility . . . . . 33
C.1.1. Area Extended LSA Mixed-Mode Backward Compatibility . 34
C.2. Global Configuration Parameters . . . . . . . . . . . . . 34
C.3. Area Configuration Parameters . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
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
skipping to change at page 3, line 47 skipping to change at page 4, line 5
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. Acknowledgments 1.2. OSPFv3 LSA Terminology
The TLV-based OSPFv3 LSAs described in this document will be referred
to as Extended LSAs. The OSPFv3 fixed-format LSAs [OSPFV3] will be
referred to as Legacy LSAs.
1.3. 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, Anton Smirnov, and Tony Thanks go to Michael Barnes, Mike Dubrovsky, Anton Smirnov, and Tony
Przygienda for review of the draft versions and discussions of Przygienda for review of the draft versions and discussions of
backward 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.
Thanks to Karsten Thomann for review and editorial comments. Thanks to Karsten Thomann and Chris Bowers for review and editorial
comments.
The RFC text was produced using Marshall Rose's xml2rfc tool. 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
skipping to change at page 26, line 18 skipping to change at page 27, line 18
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.
Three distinct backward compatibility modes are supported dependent 6.1. Full Extended LSA Migration
on the OSPFv3 routing domain migration requirements. For simplicity
and to avoid the scaling impact of maintaining both TLV and non-TLV
based versions of the same LSA within a routing domain, the basic
backward compatibility mode will not allow mixing of LSA formats.
Different LSA formats could still be supported with multiple OSPFv3
instances and separate OSPFv3 routing domains. Additionally, a more
flexible mode is provided in Section 6.1, where both formats of LSA
coexist. In order to facilitate backward compatibility, the OSPFv3
options field (as described in Appendix A.2 of RFC 5340 [OSPFV3]),
will contain two additional options bits. The EL-bits will be used
to indicate that the OSPFv3 router's level of Extended LSA support.
An 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'
None - Extended LSAs are not originated nor used in the SPF
calculation (except for future functionalities as described in
Section 6.2) .
B'01'
MixedModeOriginateOnly - Both extended and non-extended LSAs are
originated. Non-extended LSAs are used in the SPF computation.
B'10'
MixedModeOriginateSPF - Both extended and non-extended LSAs are
originated. Extended LSAs are used in the SPF computation.
B'11'
Full - Only extended LSAs are originated and used in the SPF
computation.
If Full is specified for ExtendedLSASupport, the OSPFv3 router MUST
NOT form adjacencies with OSPFv3 Routers sending OSPFv3 Hello and
Database Description packets with the options field EL-bits set to
MixedModeOriginateOnly or None. Similarly, if MixModeOriginateSPF is
specified for ExtendedLSASupport, the OSPFv3 router MUST NOT form
adjacencies with OSPFv3 Routers sending OSPFv3 Hello and Database
Description packets with the options field EL-bits set to None
(B'00'). In this manner, OSPFv3 routers using new encodings can be
completely isolated from those OSPFv3 routers depending on the RFC
5340 encoding and not setting their options field EL-bits since the
default setting indicates no support for extended LSAs.
Finally, a mode supporting existing OSPFv3 routing domains is
provided. This mode, subsequently referred to as "sparse-mode", will
use the TLV-based LSAs solely in support of new functionality
Section 6.2. In this compatibility mode, the EL-bits will be
advertised as B'00' since the backward compatibility with the non-
extended LSAs is not supported or required.
1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+-+-+--+
| | | | | | | | | | | | EL|AT|L|AF|*|*|DC|R|N|x|E|V6|
+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+-+-+--+
The Options field
EL-bits
These bits indicate the level of Extended LSA support.
B'00' - Extended LSAs are not originate nor used in the
SPF calculation (except for new functionalities
for future functions as described in Section 6.2).
B'01' - Both extended and non-extended LSAs are originated.
Non-extended LSAs are used in the SPF computation.
B'10' - Both extended and non-extended LSAs are originated.
Extended LSAs are used in the SPF computation.
B'11' - Only extended LSA are originated and used in the
SPF computation.
Options Field EL-bits
The EL-bits will also be set in the LSA options field in Extended and
Non-Extended LSAs. While the value of the EL-bits has no functional
significance in the LSA options field, visibility of every OSPFv3
Router's extended LSA support is expected to be very useful for
management and troubleshooting during the migration period.
6.1. Extended LSA Mixed-Mode Backward Compatibility
An implementation MAY support configuration allowing a graceful
transition from the non-extended (non-TLV-based) LSAs to the extended
(TLV-based) LSAs in an OSPFv3 routing domain. In these routing
domains, the OSPFv3 routers configured with a value of
MixedModeOriginateOnly or MixedModeOriginateSPF for
ExtendedLSASupport, (Appendix A), MUST originate both the extended
and non-extended versions of the OSPFv3 LSAs described herein. For
the purposes of Shortest Path First (SPF) computation, the non-
extended OSPFv3 LSAs are used for SPF computation when
MixedModeOriginateOnly is configured and the extended LSAs are used
when MixedModeOriginateSPF is specified. The extended LSAs MAY be
used for functions other than routing computation as long as backward
compatibility is specified in the documents specifying those
functions.
In this manner, OSPFv3 routing domains utilizing the new encodings
can be gradually migrated with a worst-case overhead cost of
approximately doubling the number of LSAs in the routing domain. The
transition within an OSPFv3 routing domain would progress as follows:
1. Configure OSPFv3 Router ExtendedLSASupport to
MixedModeOriginateOnly so that routers originate the extended
LSAs.
2. When all the OSPFv3 Routers have been reconfigured to
MixedModeOriginateOnly, gradually reconfigure OSPFv3 Routers to
use the extended LSAs by configuring ExtendedLSASupport to
MixedModeOriginateSPF. This can be done on a small subset of
OSPFv3 Routers and the route tables can be verified.
3. When all the OSPFv3 Routers have been reconfigured to
MixedModeOriginateSPF and the routing has been verified,
reconfigure OSPFv3 Routers to purge or simply not refresh the
non-extended OSPFv3 LSA by configuring ExtendedLSASupport to
Full.
In order to prevent OSPFv3 routing domain routing loops, the
advertised metrics in the extended and non-extended OSPFv3 LSAs MUST
be identical.
6.1.1. Area Extended LSA Mixed-Mode Backward Compatibility
An implementation MAY also support configuration allowing graceful If ExtendedLSASupport is enabled Appendix A, OSPFv3 Extended LSAs
transition from the non-extended LSAs to the extended LSAs within a will be originated and used for the SPF computation. Individual OSPF
single area. In these areas, the parameter AreaExtendedLSASupport Areas can be migrated separately with the Legacy AS-External LSAs
(Appendix B) may be configured to take precedence over the global being originated and used for the SPF computation. This is
parameter ExtendedLSASupport. However, the AreaExtendedLSASupport accomplished by enabled AreaExtendedLSASupport Appendix B.
will only apply to link and area scoped LSAs within the area and area
based SPF calculations. The default is for the
AreaExtendedLSASupport to be inherited from the ExtendedLSASupport.
The configuration of ExtendedLSASupport will apply to AS-External
LSAs even when AreaExtendedLSASupport takes precedence.
When preforming a graceful restart [GRACEFUL-RESTART], an OSPFv3 An OSPFv3 routing domain or area may be non-disruptively migrated
router configured with MixedModeOriginate will use the non-extended using separate OSPFv3 instances for the extended LSAs. Initially,
OSPFv3 LSAs to determine whether or not the graceful restart has the OSPFv3 instances with ExtendedLSASupport will have a lower
completed successfully. Similarly, an OSPFv3 router configured with preference, i.e., higher administrative distance, than the OSPFv3
MixedModeOriginateSPF will use the extended LSAs. In other words, instances originating and using the Legacy LSAs. Once the routing
successful OSPFv3 graceful restart determination will follow the SPF domain or area is fully migrated and the OSPFv3 Routing Information
calculation. Bases (RIB) have been verified, the OSPFv3 instances using the
extended LSAs can be given preference. When this has been completed
and the routing within the OSPF routing domain or area has been
verified, the original OSPFv3 instance using Legacy LSAs can be
removed.
6.2. Extended LSA Spare-Mode Backward Compatibility 6.2. Extended LSA Spare-Mode Backward Compatibility
In this mode, OSPFv3 will use the non-extended LSAs for the SPF In this mode, OSPFv3 will use the Legacy LSAs for the SPF computation
computation and will only originate extended LSAs when LSA and will only originate extended LSAs when LSA origination is
origination is required in support of addtional functionality. required in support of addtional functionality. Furthermore, the
Furthermore, the extended LSAs will only include those TLVs which extended LSAs will only include those TLVs which require further
require further specification for that new functionality. Hence, specification for that new functionality. Hence, this mode of
this mode of compatibility is know as "sparse-mode". The advantage compatibility is know as "sparse-mode". The advantage of sparse-mode
of sparse-mode is that functionality utilizing the OSPFv3 extended is that functionality utilizing the OSPFv3 extended LSAs can be added
LSAs can be added to an existing OSFPv3 routing domain without the to an existing OSFPv3 routing domain without the requirement for
requirement for migration. In essence, this compatibility mode is migration. In essence, this compatibility mode is very much like the
very much like the approach taken for OSPFv2 [OSPF-PREFIX-LINK]. As approach taken for OSPFv2 [OSPF-PREFIX-LINK]. As with all the
with all the compatibility modes, backward compatibility for the compatibility modes, backward compatibility for the functions
functions utilizing the extended LSAs must be described in the IETF utilizing the extended LSAs must be described in the IETF documents
documents describing those functions. 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 30, line 30 skipping to change at page 28, line 48
8. IANA Considerations 8. IANA Considerations
This specification defines nine OSPFv3 Extended LSA types as This specification defines nine OSPFv3 Extended LSA types as
described in Section 2. described in Section 2.
This specification also creates two registries OSPFv3 Extended-LSAs This specification also creates two registries OSPFv3 Extended-LSAs
TLVs and sub-TLVs. The TLV and sub-TLV code-points in these TLVs and sub-TLVs. The TLV and sub-TLV code-points in these
registries are common to all Extended-LSAs and their respective registries are common to all Extended-LSAs and their respective
definitions must define where they are applicable. definitions must define where they are applicable.
The OSPFv3 Extend-LSA TLV registry will define top-level TLVs for The OSPFv3 Extended-LSA TLV registry will define top-level TLVs for
Extended-LSAs and should be placed in the existing OSPFv3 IANA Extended-LSAs and should be placed in the existing OSPFv3 IANA
registry. New values can be allocated via IETF Consensus or IESG registry. New values can be allocated via IETF Consensus or IESG
Approval. Approval.
Nine values are allocated by this specification: Nine values are allocated by this specification:
o 0 - Reserved o 0 - Reserved
o 1 - Router-Link TLV o 1 - Router-Link TLV
skipping to change at page 31, line 4 skipping to change at page 29, line 22
o 3 - Inter-Area Prefix TLV o 3 - Inter-Area Prefix TLV
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
The OSPFv3 Extend-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. New values can be allocated via IETF existing OSPFv3 IANA registry. New values can be allocated via IETF
Review. Review.
Three values are allocated by this specification: Three values are allocated by this specification:
o 0 - Reserved o 0 - Reserved
o 1 - Forwarding Address o 1 - Forwarding Address
skipping to change at page 32, line 29 skipping to change at page 30, line 44
Attributes", draft-ietf-ospf-prefix-link-attr-13.txt (work Attributes", draft-ietf-ospf-prefix-link-attr-13.txt (work
in progress), August 2015. in progress), August 2015.
[SEGMENT-ROUTING] [SEGMENT-ROUTING]
Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
Extensions for Segment Routing", draft-ietf-ospf-segment- Extensions for Segment Routing", draft-ietf-ospf-segment-
routing-extensions-05.txt (work in progress), February routing-extensions-05.txt (work in progress), February
2015. 2015.
Appendix A. Global Configuration Parameters Appendix A. Appendix A - Global Configuration Parameters
The global configurable parameter ExtendedLSASupport will be added to
the OSPFv3 protocol. If ExtendedLSASupport is enabled, the OSPFv3
Router will originate OSPFv3 Extended LSAs and use the LSAs for the
SPF computation. If ExtendedLSASupport is not enabled, a subset of
OSPFv3 Extended LSAs may still be originated and used for other
functions as described in Section 6.2.
Appendix B. Appendix B - Area Configuration Parameters
The area configurable parameter AreaExtendedLSASupport will be added
to the OSPFv3 protocol. If ExtendedLSASupport is enabled, the OSPFv3
Router will originate link and area OSPFv3 Extended LSAs and use the
LSAs for the SPF computation. Legacy AS-Scoped LSAs will still be
originated and used for the AS External LSA computation. If
AreaExtendedLSASupport is not enabled a subset of OSPFv3 link and
area Extended LSAs may still be originated and used for other
functions as described in Section 6.2.
For regular areas, i.e., areas where AS scoped LSAs are flooded,
disabling AreaExtendedLSASupport when ExtendedLSASupport is enabled
is contradictory and MAY be prohibited by the implementation.
Appendix C. Appendix C - Deprecated LSA Extension Backward
Compatibility
In the context of this document, backward compatibility is solely
related to the capability of an OSPFv3 router to receive, process,
and originate the TLV-based LSAs defined herein. Unrecognized TLVs
and sub-TLVs are ignored. Backward compatibility for future OSPFv3
extensions utilizing the TLV-based LSAs is out of scope and must be
covered in the documents describing those extensions. Both full and,
if applicable, partial deployment SHOULD be specified for future TLV-
based OSPFv3 LSA extensions.
Three distinct backward compatibility modes are supported dependent
on the OSPFv3 routing domain migration requirements. For simplicity
and to avoid the scaling impact of maintaining both TLV and non-TLV
based versions of the same LSA within a routing domain, the basic
backward compatibility mode will not allow mixing of LSA formats.
Different LSA formats could still be supported with multiple OSPFv3
instances and separate OSPFv3 routing domains. Additionally, a more
flexible mode is provided in Appendix C.1, where both formats of LSA
coexist. In order to facilitate backward compatibility, the OSPFv3
options field (as described in Appendix A.2 of RFC 5340 [OSPFV3]),
will contain two additional options bits. The EL-bits will be used
to indicate that the OSPFv3 router's level of Extended LSA support.
An 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'
None - Extended LSAs are not originated nor used in the SPF
calculation (except for future functionalities as described in
Section 6.2) .
B'01'
MixedModeOriginateOnly - Both Extended and Legacy LSAs are
originated. Legacy LSAs are used in the SPF computation.
B'10'
MixedModeOriginateSPF - Both extended and Legacy LSAs are
originated. Extended LSAs are used in the SPF computation.
B'11'
Full - Only extended LSAs are originated and used in the SPF
computation.
If Full is specified for ExtendedLSASupport, the OSPFv3 router MUST
NOT form adjacencies with OSPFv3 Routers sending OSPFv3 Hello and
Database Description packets with the options field EL-bits set to
MixedModeOriginateOnly or None. Similarly, if MixModeOriginateSPF is
specified for ExtendedLSASupport, the OSPFv3 router MUST NOT form
adjacencies with OSPFv3 Routers sending OSPFv3 Hello and Database
Description packets with the options field EL-bits set to None
(B'00'). In this manner, OSPFv3 routers using new encodings can be
completely isolated from those OSPFv3 routers depending on the RFC
5340 encoding and not setting their options field EL-bits since the
default setting indicates no support for extended LSAs.
Finally, a mode supporting existing OSPFv3 routing domains is
provided. This mode, subsequently referred to as "sparse-mode", will
use the TLV-based LSAs solely in support of new functionality
Section 6.2. In this compatibility mode, the EL-bits will be
advertised as B'00' since the backward compatibility with the Legacy
LSAs is not supported or required.
1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+-+-+--+
| | | | | | | | | | | | EL|AT|L|AF|*|*|DC|R|N|x|E|V6|
+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+-+-+--+
The Options field
EL-bits
These bits indicate the level of Extended LSA support.
B'00' - Extended LSAs are not originate nor used in the
SPF calculation (except for new functionalities
for future functions as described in Section 6.2).
B'01' - Both extended and Legacy LSAs are originated.
Non-extended LSAs are used in the SPF computation.
B'10' - Both extended and Legacy LSAs are originated.
Extended LSAs are used in the SPF computation.
B'11' - Only extended LSA are originated and used in the
SPF computation.
Options Field EL-bits
The EL-bits will also be set in the LSA options field in Extended and
Legacy LSAs. While the value of the EL-bits has no functional
significance in the LSA options field, visibility of every OSPFv3
Router's extended LSA support is expected to be very useful for
management and troubleshooting during the migration period.
C.1. Extended LSA Mixed-Mode Backward Compatibility
An implementation MAY support configuration allowing a graceful
transition from the Legacy (non-TLV-based) LSAs to the extended (TLV-
based) LSAs in an OSPFv3 routing domain. In these routing domains,
the OSPFv3 routers configured with a value of MixedModeOriginateOnly
or MixedModeOriginateSPF for ExtendedLSASupport, (Appendix C.2), MUST
originate both the extended and legacy versions of the OSPFv3 LSAs
described herein. For the purposes of Shortest Path First (SPF)
computation, the Legacy LSAs are used for SPF computation when
MixedModeOriginateOnly is configured and the extended LSAs are used
when MixedModeOriginateSPF is specified. The Extended LSAs MAY be
used for functions other than routing computation as long as backward
compatibility is specified in the documents specifying those
functions.
In this manner, OSPFv3 routing domains utilizing the new encodings
can be gradually migrated with a worst-case overhead cost of
approximately doubling the number of LSAs in the routing domain. The
transition within an OSPFv3 routing domain would progress as follows:
1. Configure OSPFv3 Router ExtendedLSASupport to
MixedModeOriginateOnly so that routers originate the extended
LSAs.
2. When all the OSPFv3 Routers have been reconfigured to
MixedModeOriginateOnly, gradually reconfigure OSPFv3 Routers to
use the extended LSAs by configuring ExtendedLSASupport to
MixedModeOriginateSPF. This can be done on a small subset of
OSPFv3 Routers and the route tables can be verified.
3. When all the OSPFv3 Routers have been reconfigured to
MixedModeOriginateSPF and the routing has been verified,
reconfigure OSPFv3 Routers to purge or simply not refresh the
Legacy LSA by configuring ExtendedLSASupport to Full.
In order to prevent OSPFv3 routing domain routing loops, the
advertised metrics in the Extended LSAs and Legacy LSAs MUST be
identical.
C.1.1. Area Extended LSA Mixed-Mode Backward Compatibility
An implementation MAY also support configuration allowing graceful
transition from the Legacy LSAs to the extended LSAs within a single
area. In these areas, the parameter AreaExtendedLSASupport
(Appendix C.3) may be configured to take precedence over the global
parameter ExtendedLSASupport. However, the AreaExtendedLSASupport
will only apply to link and area scoped LSAs within the area and area
based SPF calculations. The default is for the
AreaExtendedLSASupport to be inherited from the ExtendedLSASupport.
The configuration of ExtendedLSASupport will apply to AS-External
LSAs even when AreaExtendedLSASupport takes precedence.
When preforming a graceful restart [GRACEFUL-RESTART], an OSPFv3
router configured with MixedModeOriginate will use the Legacy LSAs to
determine whether or not the graceful restart has completed
successfully. Similarly, an OSPFv3 router configured with
MixedModeOriginateSPF will use the extended LSAs. In other words,
successful OSPFv3 graceful restart determination will follow the SPF
calculation.
C.2. Global Configuration Parameters
An additional global configurable parameter will be added to the An additional global configurable parameter will be added to the
OSPFv3 protocol. OSPFv3 protocol.
ExtendedLSASupport ExtendedLSASupport
This is an enumeration type indicating the extent to which the This is an enumeration type indicating the extent to which the
OSPFv3 instance supports the TLV format described herein for OSPFv3 instance supports the TLV format described herein for
Extended LSAs. The valid values for the enumeration are: Extended LSAs. The valid values for the enumeration are:
* 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", extended LSAs may be used as ExtendedLSASuppport is "None", extended LSAs may be used as
described in Section 6.2. described in Section 6.2.
* MixedModeOriginateOnly - Both extended and non-extended LSAs * MixedModeOriginateOnly - Both extended and Legacy LSAs will be
will be originated. OSPFv3 adjacencies will be formed with originated. OSPFv3 adjacencies will be formed with OSPFv3
OSPFv3 routers not supporting this specification. The non- routers not supporting this specification. The Legacy LSAs are
extended LSAs are used for the SPF computation. used for the SPF computation.
* MixedModeOriginateSPF - Both extended and non-extended LSAs * MixedModeOriginateSPF - Both Extended LSAs and Legacy LSAs will
will be originated. OSPFv3 adjacencies will be formed with be originated. OSPFv3 adjacencies will be formed with OSPFv3
OSPFv3 routers not supporting this specification. The extended routers not supporting this specification. The Extended LSAs
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 ndot be formed with OSPFv3 routers not supporting this
specification. Only Extended LSAs will be originated. specification. Only Extended LSAs will be originated.
Appendix B. 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 compatability is
in effect Section 6.2. in effect Section 6.2.
* MixedModeOriginateOnly - Both extended and non-extended link * MixedModeOriginateOnly - Both extended and legacy link and area
and area scoped LSAs will be originated. OSPFv3 adjacencies scoped LSAs will be originated. OSPFv3 adjacencies will be
will be formed with OSPFv3 routers not supporting this formed with OSPFv3 routers not supporting this specification.
specification. The non-extended LSAs are used for the SPF The Legacy LSAs are used for the area SPF computation.
computation.
* MixedModeOriginateSPF - Both extended and non-extended link and * MixedModeOriginateSPF - Both extended and legacy link and area
area scoped LSAs will be originated. OSPFv3 adjacencies will scoped LSAs will be originated. OSPFv3 adjacencies will be
be formed with OSPFv3 routers not supporting this formed with OSPFv3 routers not supporting this specification.
specification. The extended LSAs are used for the area SPF The Extended LSAs are used for the area SPF computation.
computation.
* 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.
Authors' Addresses Authors' Addresses
 End of changes. 22 change blocks. 
215 lines changed or deleted 281 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/