< draft-ietf-ospf-ospfv3-lsa-extend-21.txt   draft-ietf-ospf-ospfv3-lsa-extend-22.txt >
Network Working Group A. Lindem Network Working Group A. Lindem
Internet-Draft A. Roy Internet-Draft A. Roy
Updates: 5340, 5838 (if approved) Cisco Systems Updates: 5340, 5838 (if approved) Cisco Systems
Intended status: Standards Track D. Goethals Intended status: Standards Track D. Goethals
Expires: July 23, 2018 Nokia Expires: July 28, 2018 Nokia
V. Reddy Vallem V. Reddy Vallem
F. Baker F. Baker
January 19, 2018 January 24, 2018
OSPFv3 LSA Extendibility OSPFv3 LSA Extendibility
draft-ietf-ospf-ospfv3-lsa-extend-21.txt draft-ietf-ospf-ospfv3-lsa-extend-22.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, This document updates RFC 5340, "OSPF for IPv6", and RFC 5838,
"Support of Address Families in OSPFv3". "Support of Address Families in OSPFv3" by providing TLV-based
encodings for the base OSPFv3 unicast support and OSPFv3 address
family support.
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 July 23, 2018. This Internet-Draft will expire on July 28, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 52 skipping to change at page 2, line 52
4.2. OSPFv3 E-Network-LSA . . . . . . . . . . . . . . . . . . 18 4.2. OSPFv3 E-Network-LSA . . . . . . . . . . . . . . . . . . 18
4.3. OSPFv3 E-Inter-Area-Prefix-LSA . . . . . . . . . . . . . 19 4.3. OSPFv3 E-Inter-Area-Prefix-LSA . . . . . . . . . . . . . 19
4.4. OSPFv3 E-Inter-Area-Router-LSA . . . . . . . . . . . . . 20 4.4. OSPFv3 E-Inter-Area-Router-LSA . . . . . . . . . . . . . 20
4.5. OSPFv3 E-AS-External-LSA . . . . . . . . . . . . . . . . 21 4.5. OSPFv3 E-AS-External-LSA . . . . . . . . . . . . . . . . 21
4.6. OSPFv3 E-NSSA-LSA . . . . . . . . . . . . . . . . . . . . 22 4.6. OSPFv3 E-NSSA-LSA . . . . . . . . . . . . . . . . . . . . 22
4.7. OSPFv3 E-Link-LSA . . . . . . . . . . . . . . . . . . . . 23 4.7. OSPFv3 E-Link-LSA . . . . . . . . . . . . . . . . . . . . 23
4.8. OSPFv3 E-Intra-Area-Prefix-LSA . . . . . . . . . . . . . 25 4.8. OSPFv3 E-Intra-Area-Prefix-LSA . . . . . . . . . . . . . 25
5. Malformed OSPFv3 Extended LSA Handling . . . . . . . . . . . 26 5. Malformed OSPFv3 Extended LSA Handling . . . . . . . . . . . 26
6. LSA Extension Backward Compatibility . . . . . . . . . . . . 26 6. LSA Extension Backward Compatibility . . . . . . . . . . . . 26
6.1. Full Extended LSA Migration . . . . . . . . . . . . . . . 26 6.1. Full Extended LSA Migration . . . . . . . . . . . . . . . 26
6.2. Extended LSA Spare-Mode Backward Compatibility . . . . . 27 6.2. Extended LSA Sparse-Mode Backward Compatibility . . . . . 27
6.3. LSA TLV Processing Backward Compatibility . . . . . . . . 27 6.3. LSA TLV Processing Backward Compatibility . . . . . . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
8.1. OSPFv3 Extended-LSA TLV Registry . . . . . . . . . . . . 28 8.1. OSPFv3 Extended-LSA TLV Registry . . . . . . . . . . . . 28
8.2. OSPFv3 Extended-LSA sub-TLV Registry . . . . . . . . . . 29 8.2. OSPFv3 Extended-LSA sub-TLV Registry . . . . . . . . . . 29
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
10.1. Normative References . . . . . . . . . . . . . . . . . . 30 10.1. Normative References . . . . . . . . . . . . . . . . . . 30
10.2. Informative References . . . . . . . . . . . . . . . . . 30 10.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. Appendix A - Global Configuration Parameters . . . . 31 Appendix A. Appendix A - Global Configuration Parameters . . . . 31
Appendix B. Appendix B - Area Configuration Parameters . . . . . 31 Appendix B. Appendix B - Area Configuration Parameters . . . . . 31
Appendix C. Appendix C - Deprecated LSA Extension Backward Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 31
Compatibility . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
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 . . . . . . . . . . . . . 35
C.3. Area Configuration Parameters . . . . . . . . . . . . . . 35
Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 36
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]. This document updates RFC 5340, "OSPF for IPv6", and RFC 5838,
"Support of Address Families in OSPFv3" by providing TLV-based
encodings for the base OSPFv3 support [OSPFV3] and OSPFv3 address
family support [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
skipping to change at page 4, line 8 skipping to change at page 4, line 4
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", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC-KEYWORDS]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
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.
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
will be set in LS Type so that the LSAs will be flooded by OSPFv3 MUST be set in LS Type so that the LSAs will be flooded by OSPFv3
routers that do not understand them. routers that do not understand them.
LSA function code LS Type Description LSA function code LS Type Description
---------------------------------------------------- ----------------------------------------------------
33 0xA021 E-Router-LSA 33 0xA021 E-Router-LSA
34 0xA022 E-Network-LSA 34 0xA022 E-Network-LSA
35 0xA023 E-Inter-Area-Prefix-LSA 35 0xA023 E-Inter-Area-Prefix-LSA
36 0xA024 E-Inter-Area-Router-LSA 36 0xA024 E-Inter-Area-Router-LSA
37 0xC025 E-AS-External-LSA 37 0xC025 E-AS-External-LSA
38 N/A Unused (Not to be allocated) 38 N/A Unused (Not to be allocated)
skipping to change at page 7, line 14 skipping to change at page 7, line 14
The N-bit is set in PrefixOptions for a host address The N-bit is set in PrefixOptions for a host address
(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 E-AS-External-LSA
External-LSA corresponding to an NSSA route as described in section 3 corresponding to an NSSA route as described in section 3 of RFC 3101
of RFC 3101 ([NSSA]). The N-bit is added to the Inter-Area-Prefix- ([NSSA]). The N-bit is added to the Inter-Area-Prefix-TLV
TLV (Section 3.4), External-Prefix-TLV (Section 3.6), and Intra-Area- (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 Prefix-TLV (Section 3.7). The N-bit is useful for applications such
as 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
skipping to change at page 15, line 17 skipping to change at page 15, line 17
The IPv6 Forwarding Address TLV has identical semantics to the The IPv6 Forwarding Address TLV has identical semantics to the
optional forwarding address in section A.4.7 of [OSPFV3]. The IPv6 optional forwarding address in section A.4.7 of [OSPFV3]. The IPv6
Forwarding Address TLV is applicable to the External-Prefix TLV Forwarding Address TLV is applicable to the External-Prefix TLV
(Section 3.6). Specification as a sub-TLV of other TLVs is not (Section 3.6). Specification as a sub-TLV of other TLVs is not
defined herein. The sub-TLV is optional and the first specified defined herein. The sub-TLV is optional and the first specified
instance is used as the Forwarding Address as defined in [OSPFV3]. instance is used as the Forwarding Address as defined in [OSPFV3].
Instances subsequent to the first MUST be ignored. Instances subsequent to the first MUST be ignored.
The IPv6 Forwarding Address TLV is to be used with IPv6 address The IPv6 Forwarding Address TLV is to be used with IPv6 address
families as defined in [OSPFV3-AF] It MUST be ignored for other families as defined in [OSPFV3-AF] It MUST be ignored for other
address families. address families. The IPv6 Forwarding Address TLV length must meet
minimum length (16 octets) or it will be considered malformed as
described in Section 6.3.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 - Forwarding Address | sub-TLV Length | | 1 - Forwarding Address | sub-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+- -+ +- -+
| | | |
+- Forwarding Address -+ +- Forwarding Address -+
| | | |
+- -+ +- -+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Forwarding Address Tag TLV IPv6 Forwarding Address TLV
3.11. IPv4-Forwarding-Address Sub-TLV 3.11. IPv4-Forwarding-Address Sub-TLV
The IPv4 Forwarding Address TLV has identical semantics to the The IPv4 Forwarding Address TLV has identical semantics to the
optional forwarding address in section A.4.7 of [OSPFV3]. The IPv4 optional forwarding address in section A.4.7 of [OSPFV3]. The IPv4
Forwarding Address TLV is The IPv4 Forwarding Address TLV is Forwarding Address TLV is The IPv4 Forwarding Address TLV is
applicable to the External-Prefix TLV (Section 3.6). Specification applicable to the External-Prefix TLV (Section 3.6). Specification
as a sub-TLV of other TLVs is not defined herein. The sub-TLV is as a sub-TLV of other TLVs is not defined herein. The sub-TLV is
optional and the first specified instance is used as the Forwarding optional and the first specified instance is used as the Forwarding
Address as defined in [OSPFV3]. Instances subsequent to the first Address as defined in [OSPFV3]. Instances subsequent to the first
MUST be ignored. MUST be ignored.
The IPv4 Forwarding Address TLV is to be used with IPv3 address The IPv4 Forwarding Address TLV is to be used with IPv4 address
families as defined in [OSPFV3-AF] It MUST be ignored for other families as defined in [OSPFV3-AF] It MUST be ignored for other
address families. address families. The IPv4 Forwarding Address TLV length must meet
minimum length (4 octets) or it will be considered malformed as
described in Section 6.3.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 - Forwarding Address | sub-TLV Length | | 2 - Forwarding Address | sub-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Forwarding Address | | Forwarding Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Forwarding Address Tag TLV IPv4 Forwarding Address TLV
3.12. Route-Tag Sub-TLV 3.12. Route-Tag Sub-TLV
The optional Route Tag sub-TLV has identical semantics to the The optional Route Tag sub-TLV has identical semantics to the
optional External Route Tag in section A.4.7 of [OSPFV3]. The Route optional External Route Tag in section A.4.7 of [OSPFV3]. The Route
Tag sub-TLV is applicable to the External-Prefix TLV (Section 3.6). Tag sub-TLV is applicable to the External-Prefix TLV (Section 3.6).
Specification as a sub-TLV of other TLVs is not defined herein. The Specification as a sub-TLV of other TLVs is not defined herein. The
sub-TLV is optional and the first specified instance is used as the sub-TLV is optional and the first specified instance is used as the
Route Tag as defined in [OSPFV3]. Instances subsequent to the first Route Tag as defined in [OSPFV3]. Instances subsequent to the first
MUST be ignored. MUST be ignored.
The Route Tag TLV length must meet minimum length (4 octets) or it
will be considered malformed as described in Section 6.3.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 - Route Tag | sub-TLV Length | | 3 - Route Tag | sub-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Tag | | Route Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Route Tag Sub-TLV Route Tag Sub-TLV
skipping to change at page 17, line 34 skipping to change at page 17, line 34
Extended Router-LSA Extended Router-LSA
Other than having a different 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- Depending on the implementation, it is perfectly valid for an E-
Router-LSA to not contain any Router-Link TLVs. However, this would Router-LSA to not contain any Router-Link TLVs. However, this would
imply that the OSPFv3 router doesn't have any active interfaces in imply that the OSPFv3 router doesn't have any adjacencies in the
the corresponding area and such E-Router-LSA would never be flooded corresponding area and is forming an adjacency or adjacencies over
to other OSPFv3 routers in the area. unnumbered link(s). Note that no E-Router-LSA stub link is
advertised for an unnumbered link.
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 20, line 8 skipping to change at page 20, line 8
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,
it is treated as malformed as described in Section 5. Instances of it is treated as malformed as described in Section 5. Instances of
the Inter-Area-Prefix TLV subsequent to the first MUST be ignored. the Inter-Area-Prefix TLV subsequent to the first MUST be ignored.
4.4. OSPFv3 E-Inter-Area-Router-LSA 4.4. OSPFv3 E-Inter-Area-Router-LSA
The E-Inter-Area-Router-LSA has an LS Type of 0xA024 and has the same The E-Inter-Area-Router-LSA has an LS Type of 0xA024 and has the same
base information content as the Inter-Area-Router-LSAE defined in base information content as the Inter-Area-Router-LSA defined in
section A.4.6 of [OSPFV3]. However, unlike the Inter-Area-Router- section A.4.6 of [OSPFV3]. However, unlike the Inter-Area-Router-
LSA, it is fully extendable and represented as TLVs. LSA, it is fully 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Age |1|0|1| 0x24 | | LS Age |1|0|1| 0x24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID | | Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 27, line 5 skipping to change at page 27, line 5
the OSPFv3 instances with ExtendedLSASupport will have a lower the OSPFv3 instances with ExtendedLSASupport will have a lower
preference, i.e., higher administrative distance, than the OSPFv3 preference, i.e., higher administrative distance, than the OSPFv3
instances originating and using the Legacy LSAs. Once the routing instances originating and using the Legacy LSAs. Once the routing
domain or area is fully migrated and the OSPFv3 Routing Information domain or area is fully migrated and the OSPFv3 Routing Information
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 Sparse-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 additional functionality. Furthermore, those required in support of additional functionality. Furthermore, those
extended LSAs will only include the top-level TLVs (e.g., Router-Link extended LSAs will only include the top-level TLVs (e.g., Router-Link
TLVs or Inter-Area TLVs) which require further specification for that TLVs or Inter-Area TLVs) which require further specification for that
new functionality. However, if a top-level TLV is advertised, it new functionality. However, if a top-level TLV is advertised, it
MUST include required Sub-TLVs or it will be considered malformed as MUST include required Sub-TLVs or it will be considered malformed as
described in Section 5. Hence, this mode of compatibility is known described in Section 5. Hence, this mode of compatibility is known
as "sparse-mode". The advantage of sparse-mode is that functionality as "sparse-mode". The advantage of sparse-mode is that functionality
skipping to change at page 28, line 22 skipping to change at page 28, line 22
implementations must assure that malformed TLV and sub-TLV implementations must assure that malformed TLV and sub-TLV
permutations do not result in errors that cause hard OSPFv3 failures. permutations do not result in errors that cause hard OSPFv3 failures.
If there were ever a requirement to digitally sign OSPFv3 LSAs as If there were ever a requirement to digitally sign OSPFv3 LSAs as
described for OSPFv2 LSAs in RFC 2154 [OSPF-DIGITAL-SIGNATURE], the described for OSPFv2 LSAs in RFC 2154 [OSPF-DIGITAL-SIGNATURE], the
mechanisms described herein would greatly simplify the extension. mechanisms described herein would greatly simplify the extension.
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. These will be added to the existing OSPFv3 described in Section 2. These are added the existing OSPFv3 LSA
LSA Function Codes registry. Function Codes registry.
The specification will define a new code point for the N-bit in the The specification defines a new code point for the N-bit in the
OSPFv3 Prefix-Options registry. The value 0x20 is suggested. OSPFv3 Prefix-Options registry. The value 0x20 is suggested.
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.
8.1. OSPFv3 Extended-LSA TLV Registry 8.1. OSPFv3 Extended-LSA TLV Registry
The OSPFv3 Extended-LSA TLV registry will define top-level TLVs for The OSPFv3 Extended-LSA TLV registry defines 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. registry.
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
o 2 - Attached-Routers TLV o 2 - Attached-Routers TLV
skipping to change at page 29, line 26 skipping to change at page 29, line 26
Types in the range 33024-45055 are to be assigned on a First-Come- Types in the range 33024-45055 are to be assigned on a First-Come-
First-Serve (FCFS) basis. First-Serve (FCFS) basis.
Types in the range 45056-65535 are not to be assigned at this time. 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 defines 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.
Four values are allocated by this specification: Four values are allocated by this specification:
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
skipping to change at page 30, line 22 skipping to change at page 30, line 22
Cisco Systems Cisco Systems
170 Tasman Drive 170 Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: sina@cisco.com Email: sina@cisco.com
10. References 10. References
10.1. Normative References 10.1. Normative References
[GRACEFUL-RESTART]
Lindem, A. and P. Pillay-Esnault, "OSPFv3 Graceful
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", Aggarwal, "Support of Address Families in OSPFv3",
RFC 5838, April 2010. RFC 5838, April 2010.
[RFC-KEYWORDS] [RFC2119] 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.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", RFC 8174, May 2017.
[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
[MT-OSPFV3] [MT-OSPFV3]
Mirtorabi, S. and A. Roy, "Multi-topology routing in Mirtorabi, S. and A. Roy, "Multi-topology routing in
OSPFv3 (MT-OSPFV3)", draft-ietf-ospf-mt-ospfv3-04.txt OSPFv3 (MT-OSPFV3)", draft-ietf-ospf-mt-ospfv3-04.txt
(work in progress), January 2008. (work in progress), January 2008.
skipping to change at page 31, line 23 skipping to change at page 31, line 23
[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, "OSPFv3 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3
Extensions for Segment Routing", draft-ietf-ospf-ospfv3- Extensions for Segment Routing", draft-ietf-ospf-ospfv3-
segment-routing-extensions-10.txt (work in progress), July segment-routing-extensions-10.txt (work in progress), July
2016. 2016.
Appendix A. Appendix A - Global Configuration Parameters Appendix A. Appendix A - Global Configuration Parameters
The global configurable parameter ExtendedLSASupport will be added to The global configurable parameter ExtendedLSASupport is added to the
the OSPFv3 protocol. If ExtendedLSASupport is enabled, the OSPFv3 OSPFv3 protocol. If ExtendedLSASupport is enabled, the OSPFv3 Router
Router will originate OSPFv3 Extended LSAs and use the LSAs for the will originate OSPFv3 Extended LSAs and use the LSAs for the SPF
SPF computation. If ExtendedLSASupport is not enabled, a subset of computation. If ExtendedLSASupport is not enabled, a subset of
OSPFv3 Extended LSAs may still be originated and used for other OSPFv3 Extended LSAs may still be originated and used for other
functions as described in Section 6.2. functions as described in Section 6.2.
Appendix B. Appendix B - Area Configuration Parameters Appendix B. Appendix B - Area Configuration Parameters
The area configurable parameter AreaExtendedLSASupport will be added The area configurable parameter AreaExtendedLSASupport is added to
to the OSPFv3 protocol. If ExtendedLSASupport is enabled, the OSPFv3 the OSPFv3 protocol. If AreaExtendedLSASupport is enabled, the
Router will originate link and area OSPFv3 Extended LSAs and use the OSPFv3 Router will originate link and area OSPFv3 Extended LSAs and
LSAs for the SPF computation. Legacy AS-Scoped LSAs will still be use the LSAs for the SPF computation. Legacy AS-Scoped LSAs will
originated and used for the AS External LSA computation. If still be originated and used for the AS External LSA computation. If
AreaExtendedLSASupport is not enabled a subset of OSPFv3 link and AreaExtendedLSASupport is not enabled a subset of OSPFv3 link and
area Extended LSAs may still be originated and used for other area Extended LSAs may still be originated and used for other
functions as described in Section 6.2. functions as described in Section 6.2.
For regular areas, i.e., areas where AS scoped LSAs are flooded, For regular areas, i.e., areas where AS scoped LSAs are flooded,
disabling AreaExtendedLSASupport when ExtendedLSASupport is enabled disabling AreaExtendedLSASupport for a regular OSPFv3 area (not a
is contradictory and MAY be prohibited by the implementation. Stub or NSSA area) when ExtendedLSASupport is enabled is
contradictory and SHOULD 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
OSPFv3 protocol.
ExtendedLSASupport
This is an enumeration type indicating the extent to which the
OSPFv3 instance supports the TLV format described herein for
Extended LSAs. The valid values for the enumeration are:
* None - Extended LSAs will not be originated or used in the SPF
calculation. This is the default. When OSPFv3 functions
requiring extended LSA are configured, and the
ExtendedLSASuppport is "None", extended LSAs may be used as
described in Section 6.2.
* MixedModeOriginateOnly - Both extended and Legacy LSAs will be
originated. OSPFv3 adjacencies will be formed with OSPFv3
routers not supporting this specification. The Legacy LSAs are
used for the SPF computation.
* MixedModeOriginateSPF - Both Extended LSAs and Legacy LSAs will
be originated. OSPFv3 adjacencies will be formed with OSPFv3
routers not supporting this specification. The Extended LSAs
are used for the SPF computation.
* Full - Extended LSAs will be originated and adjacencies will
not be formed with OSPFv3 routers not supporting this
specification. Only Extended LSAs will be originated.
C.3. Area Configuration Parameters
An additional area configurable parameter will be added to the OSPFv3
protocol.
AreaExtendedLSASupport
This is an enumeration type indicating the extent to which the
OSPFv3 area supports the TLV format described herein for Extended
LSAs. The valid value for the enumeration are:
* InheritGlobal - The AreaExtendedLSASupport will be inherited
from ExtendedLSASupport. This is the default.
* None - Extended LSAs will not be originated or used in the SPF
calculation. This is the default. When OSPFv3 functions
requiring extended LSA are configured, and the
ExtendedLSASuppport is "None", the spare-mode compatibility is
in effect Section 6.2.
* MixedModeOriginateOnly - Both extended and legacy link and area
scoped LSAs will be originated. OSPFv3 adjacencies will be
formed with OSPFv3 routers not supporting this specification.
The Legacy LSAs are used for the area SPF computation.
* MixedModeOriginateSPF - Both extended and legacy link and area
scoped LSAs will be originated. OSPFv3 adjacencies will be
formed with OSPFv3 routers not supporting this specification.
The Extended LSAs are used for the area SPF computation.
* Full - Link and area scoped Extended LSAs will be originated
and adjacencies will not be formed with OSPFv3 routers not
supporting this specification. Only Extended LSAs will be
originated.
For regular areas, i.e., areas where AS scoped LSAs are flooded,
configuring None or MixedModeOriginateOnly for AreaExtendedLSASupport
when Full is specified for ExtendedLSASupport is contradictory and
MAY be prohibited by the implementation.
Appendix D. Acknowledgments Appendix C. 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.
skipping to change at page 37, line 11 skipping to change at page 32, line 22
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, Chris Bowers, Meng Zhang, and Nagendra Thanks to Karsten Thomann, Chris Bowers, Meng Zhang, and Nagendra
Kumar for review and editorial comments. Kumar for review and editorial comments.
Thanks to Alia Atlas for substantive Routing Area Director (AD) Thanks to Alia Atlas for substantive Routing Area Director (AD)
comments prior to IETF last call. comments prior to IETF last call.
Thanks to Alvaro Retana and Suresh Krishna for substantive comments
during IESG Review.
Thanks to Mehmet Ersue for OPS Directorate review. Thanks to Mehmet Ersue for OPS Directorate review.
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 Acee Lindem
Cisco Systems Cisco Systems
301 Midenhall Way 301 Midenhall Way
Cary, NC 27513 Cary, NC 27513
 End of changes. 33 change blocks. 
277 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/