< draft-ietf-ospf-ospfv3-lsa-extend-13.txt   draft-ietf-ospf-ospfv3-lsa-extend-14.txt >
Network Working Group A. Lindem Network Working Group A. Lindem
Internet-Draft S. Mirtorabi Internet-Draft A. Roy
Intended status: Standards Track A. Roy Intended status: Standards Track Cisco Systems
Expires: April 24, 2017 Cisco Systems Expires: October 15, 2017 D. Goethals
Nokia
V. Reddy Vallem
Huawei, Inc
F. Baker F. Baker
October 21, 2016 April 13, 2017
OSPFv3 LSA Extendibility OSPFv3 LSA Extendibility
draft-ietf-ospf-ospfv3-lsa-extend-13.txt draft-ietf-ospf-ospfv3-lsa-extend-14.txt
Abstract Abstract
OSPFv3 requires functional extension beyond what can readily be done OSPFv3 requires functional extension beyond what can readily be done
with the fixed-format Link State Advertisement (LSA) as described in with the fixed-format Link State Advertisement (LSA) as described in
RFC 5340. Without LSA extension, attributes associated with OSPFv3 RFC 5340. Without LSA extension, attributes associated with OSPFv3
links and advertised IPv6 prefixes must be advertised in separate links and advertised IPv6 prefixes must be advertised in separate
LSAs and correlated to the fixed-format LSAs. This document extends LSAs and correlated to the fixed-format LSAs. This document extends
the LSA format by encoding the existing OSPFv3 LSA information in the LSA format by encoding the existing OSPFv3 LSA information in
Type-Length-Value (TLV) tuples and allowing advertisement of Type-Length-Value (TLV) tuples and allowing advertisement of
skipping to change at page 1, line 41 skipping to change at page 1, line 44
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 24, 2017. This Internet-Draft will expire on October 15, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
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
skipping to change at page 2, line 21 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4
1.2. OSPFv3 LSA Terminology . . . . . . . . . . . . . . . . . 4 1.2. OSPFv3 LSA Terminology . . . . . . . . . . . . . . . . . 4
1.3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . 7
3.2. Router-Link TLV . . . . . . . . . . . . . . . . . . . . . 7 3.2. Router-Link TLV . . . . . . . . . . . . . . . . . . . . . 7
3.3. Attached-Routers TLV . . . . . . . . . . . . . . . . . . 8 3.3. Attached-Routers TLV . . . . . . . . . . . . . . . . . . 8
3.4. Inter-Area-Prefix TLV . . . . . . . . . . . . . . . . . . 10 3.4. Inter-Area-Prefix TLV . . . . . . . . . . . . . . . . . . 10
3.5. Inter-Area-Router TLV . . . . . . . . . . . . . . . . . . 11 3.5. Inter-Area-Router TLV . . . . . . . . . . . . . . . . . . 11
3.6. External-Prefix TLV . . . . . . . . . . . . . . . . . . . 12 3.6. External-Prefix TLV . . . . . . . . . . . . . . . . . . . 12
3.7. Intra-Area-Prefix TLV . . . . . . . . . . . . . . . . . . 13 3.7. Intra-Area-Prefix TLV . . . . . . . . . . . . . . . . . . 13
3.8. IPv6 Link-Local Address TLV . . . . . . . . . . . . . . . 14 3.8. IPv6 Link-Local Address TLV . . . . . . . . . . . . . . . 14
3.9. IPv4 Link-Local Address TLV . . . . . . . . . . . . . . . 15 3.9. IPv4 Link-Local Address TLV . . . . . . . . . . . . . . . 15
3.10. IPv6-Forwarding-Address Sub-TLV . . . . . . . . . . . . . 16 3.10. IPv6-Forwarding-Address Sub-TLV . . . . . . . . . . . . . 16
3.11. IPv4-Forwarding-Address Sub-TLV . . . . . . . . . . . . . 16 3.11. IPv4-Forwarding-Address Sub-TLV . . . . . . . . . . . . . 16
3.12. Route-Tag Sub-TLV . . . . . . . . . . . . . . . . . . . . 17 3.12. Route-Tag Sub-TLV . . . . . . . . . . . . . . . . . . . . 17
4. OSPFv3 Extended LSAs . . . . . . . . . . . . . . . . . . . . 17 4. OSPFv3 Extended LSAs . . . . . . . . . . . . . . . . . . . . 17
4.1. OSPFv3 E-Router-LSA . . . . . . . . . . . . . . . . . . . 17 4.1. OSPFv3 E-Router-LSA . . . . . . . . . . . . . . . . . . . 17
4.2. OSPFv3 E-Network-LSA . . . . . . . . . . . . . . . . . . 19 4.2. OSPFv3 E-Network-LSA . . . . . . . . . . . . . . . . . . 19
4.3. OSPFv3 E-Inter-Area-Prefix-LSA . . . . . . . . . . . . . 20 4.3. OSPFv3 E-Inter-Area-Prefix-LSA . . . . . . . . . . . . . 20
4.4. OSPFv3 E-Inter-Area-Router-LSA . . . . . . . . . . . . . 21 4.4. OSPFv3 E-Inter-Area-Router-LSA . . . . . . . . . . . . . 21
4.5. OSPFv3 E-AS-External-LSA . . . . . . . . . . . . . . . . 22 4.5. OSPFv3 E-AS-External-LSA . . . . . . . . . . . . . . . . 22
4.6. OSPFv3 E-NSSA-LSA . . . . . . . . . . . . . . . . . . . . 23 4.6. OSPFv3 E-NSSA-LSA . . . . . . . . . . . . . . . . . . . . 23
4.7. OSPFv3 E-Link-LSA . . . . . . . . . . . . . . . . . . . . 24 4.7. OSPFv3 E-Link-LSA . . . . . . . . . . . . . . . . . . . . 24
4.8. OSPFv3 E-Intra-Area-Prefix-LSA . . . . . . . . . . . . . 26 4.8. OSPFv3 E-Intra-Area-Prefix-LSA . . . . . . . . . . . . . 26
5. Malformed OSPFv3 Extended LSA Handling . . . . . . . . . . . 26 5. Malformed OSPFv3 Extended LSA Handling . . . . . . . . . . . 27
6. LSA Extension Backward Compatibility . . . . . . . . . . . . 27 6. LSA Extension Backward Compatibility . . . . . . . . . . . . 27
6.1. Full Extended LSA Migration . . . . . . . . . . . . . . . 27 6.1. Full Extended LSA Migration . . . . . . . . . . . . . . . 27
6.2. Extended LSA Spare-Mode Backward Compatibility . . . . . 27 6.2. Extended LSA Spare-Mode Backward Compatibility . . . . . 28
6.3. LSA TLV Processing Backward Compatibility . . . . . . . . 28 6.3. LSA TLV Processing Backward Compatibility . . . . . . . . 28
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30
9.1. Normative References . . . . . . . . . . . . . . . . . . 29 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
9.2. Informative References . . . . . . . . . . . . . . . . . 30 10.1. Normative References . . . . . . . . . . . . . . . . . . 30
10.2. Informative References . . . . . . . . . . . . . . . . . 31
Appendix A. Appendix A - Global Configuration Parameters . . . . 30 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. Appendix C - Deprecated LSA Extension Backward
Compatibility . . . . . . . . . . . . . . . . . . . 31 Compatibility . . . . . . . . . . . . . . . . . . . 32
C.1. Extended LSA Mixed-Mode Backward Compatibility . . . . . 33 C.1. Extended LSA Mixed-Mode Backward Compatibility . . . . . 34
C.1.1. Area Extended LSA Mixed-Mode Backward Compatibility . 34 C.1.1. Area Extended LSA Mixed-Mode Backward Compatibility . 34
C.2. Global Configuration Parameters . . . . . . . . . . . . . 34 C.2. Global Configuration Parameters . . . . . . . . . . . . . 35
C.3. Area Configuration Parameters . . . . . . . . . . . . . . 35 C.3. Area Configuration Parameters . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 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
skipping to change at page 6, line 33 skipping to change at page 6, line 40
o 2 - IPv4 Forwarding Address sub-TLV o 2 - IPv4 Forwarding Address sub-TLV
o 3 - Route Tag sub-TLV o 3 - Route Tag sub-TLV
In general, TLVs and sub-TLVs MAY occur in any order and the In general, TLVs and sub-TLVs MAY occur in any order and the
specification should define whether the TLV or sub-TLV is required specification should define whether the TLV or sub-TLV is required
and the behavior when there are multiple occurances of the TLV or and the behavior when there are multiple occurances of the TLV or
sub-TLVs. sub-TLVs.
For backward compatibility, an LSA is not considered malformed from a
TLV perspective unless either a required TLV is missing or a
specified TLV is less than the minimum required length. Refer to
Section 6.3 for more information on TLV backward compatibility.
3.1. Prefix Options Extensions 3.1. Prefix Options Extensions
The prefix options are extended from Appendix A.4.1.1 [OSPFV3]. The The prefix options are extended from Appendix A.4.1.1 [OSPFV3]. The
applicability of the LA-bit is expanded and it SHOULD be set in applicability of the LA-bit is expanded and it SHOULD be set in
Inter-Area-Prefix-TLVs and MAY be set in External-Prefix-TLVs when Inter-Area-Prefix-TLVs and MAY be set in External-Prefix-TLVs when
the advertised host IPv6 address, i.e., PrefixLength = 128, is an the advertised host IPv6 address, i.e., PrefixLength = 128, is an
interface address. In RFC 5340, the LA-bit is only set in Intra- interface address. In RFC 5340, the LA-bit is only set in Intra-
Area-Prefix-LSAs (Section 4.4.3.9 in [OSPFV3]). This will allow a Area-Prefix-LSAs (Section 4.4.3.9 in [OSPFV3]). This will allow a
stable address to be advertised without having to configure a stable address to be advertised without having to configure a
separate loopback address in every OSPFv3 area. separate loopback address in every OSPFv3 area.
skipping to change at page 18, line 27 skipping to change at page 18, line 27
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |Nt|x|V|E|B| Options | | 0 |Nt|x|V|E|B| Options |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. TLVs . . TLVs .
. . . .
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Extended Router-LSA Extended Router-LSA
All LSA Header fields are the same as defined for the Router-LSA. Other than having a differnt LS Type, all LSA Header fields are the
Initially, only the top-level Router-Link TLV Section 3.2 is same as defined for the Router-LSA. Initially, only the top-level
applicable and an E-Router-LSA may include multiple Router-Link TLVs. Router-Link TLV Section 3.2 is applicable and an E-Router-LSA may
Like the existing Router-LSA, the LSA length is used to determine the include multiple Router-Link TLVs. Like the existing Router-LSA, the
end of the LSA including TLVs. LSA length is used to determine the end of the LSA including TLVs.
4.2. OSPFv3 E-Network-LSA 4.2. OSPFv3 E-Network-LSA
The E-Network-LSA has an LS Type of 0xA022 and has the same base The E-Network-LSA has an LS Type of 0xA022 and has the same base
information content as the Network-LSA defined in section A.4.4 of information content as the Network-LSA defined in section A.4.4 of
[OSPFV3]. However, unlike the existing Network-LSA, it is fully [OSPFV3]. However, unlike the existing Network-LSA, it is fully
extendable and represented as TLVs. extendable and represented as TLVs.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 19, line 34 skipping to change at page 19, line 34
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Options | | 0 | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. TLVs . . TLVs .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E-Network-LSA E-Network-LSA
All LSA Header fields are the same as defined for the Network-LSA. Other than having a differnt LS Type, all LSA Header fields are the
Like the existing Network-LSA, the LSA length is used to determine same as defined for the Network-LSA. Like the existing Network-LSA,
the end of the LSA including TLVs. Initially, only the top-level the LSA length is used to determine the end of the LSA including
Attached-Routers TLV Section 3.3 is applicable. If the Attached- TLVs. Initially, only the top-level Attached-Routers TLV Section 3.3
Router TLV is not included in the E-Network-LSA, it is treated as is applicable. If the Attached-Router TLV is not included in the E-
malformed as described in Section 5. Instances of the Attached- Network-LSA, it is treated as malformed as described in Section 5.
Router TLV subsequent to the first MUST be ignored. Instances of the Attached-Router TLV subsequent to the first MUST be
ignored.
4.3. OSPFv3 E-Inter-Area-Prefix-LSA 4.3. OSPFv3 E-Inter-Area-Prefix-LSA
The E-Inter-Area-Prefix-LSA has an LS Type of 0xA023 and has the same The E-Inter-Area-Prefix-LSA has an LS Type of 0xA023 and has the same
base information content as the Inter-Area-Prefix-LSA defined in base information content as the Inter-Area-Prefix-LSA defined in
section A.4.5 of [OSPFV3]. However, unlike the existing Inter-Area- section A.4.5 of [OSPFV3]. However, unlike the existing Inter-Area-
Prefix-LSA, it is fully extendable and represented as TLVs. Prefix-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
skipping to change at page 20, line 32 skipping to change at page 20, line 32
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length | | LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. TLVs . . TLVs .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E-Inter-Area-Prefix-LSA E-Inter-Area-Prefix-LSA
All LSA Header fields are the same as defined for the Inter-Area- Other than having a differnt LS Type, all LSA Header fields are the
Prefix-LSA. In order to retain compatibility and semantics with the same as defined for the Inter-Area-Prefix-LSA. In order to retain
current OSPFv3 specification, each Inter-Area-Prefix LSA MUST contain compatibility and semantics with the current OSPFv3 specification,
a single Inter-Area Prefix TLV. This will facilitate migration and each Inter-Area-Prefix LSA MUST contain a single Inter-Area Prefix
avoid changes to functions such as incremental SPF computation. TLV. This will facilitate migration and avoid changes to functions
such as incremental SPF computation.
Like the existing Inter-Area-Prefix-LSA, the LSA length is used to Like the existing Inter-Area-Prefix-LSA, the LSA length is used to
determine the end of the LSA including TLV. Initially, only the top- determine the end of the LSA including TLV. Initially, only the top-
level Inter-Area-Prefix TLV (Section 3.4) is applicable. If the level Inter-Area-Prefix TLV (Section 3.4) is applicable. If the
Inter-Area-Prefix TLV is not included in the E-Inter-Area-Prefix-LSA, Inter-Area-Prefix TLV is not included in the E-Inter-Area-Prefix-LSA,
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
skipping to change at page 21, line 32 skipping to change at page 21, line 32
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length | | LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. TLVs . . TLVs .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E-Inter-Area-Router-LSA E-Inter-Area-Router-LSA
All LSA Header fields are the same as defined for the Inter-Area- Other than having a differnt LS Type, all LSA Header fields are the
Router-LSA. In order to retain compatibility and semantics with the same as defined for the Inter-Area-Router-LSA. In order to retain
current OSPFv3 specification, each Inter-Area-Router LSA MUST contain compatibility and semantics with the current OSPFv3 specification,
a single Inter-Area Router TLV. This will facilitate migration and each Inter-Area-Router LSA MUST contain a single Inter-Area Router
avoid changes to functions such as incremental SPF computation. TLV. This will facilitate migration and avoid changes to functions
such as incremental SPF computation.
Like the existing Inter-Area-Router-LSA, the LSA length is used to Like the existing Inter-Area-Router-LSA, the LSA length is used to
determine the end of the LSA including TLV. Initially, only the top- determine the end of the LSA including TLV. Initially, only the top-
level Inter-Area-Router TLV (Section 3.5) is applicable. If the level Inter-Area-Router TLV (Section 3.5) is applicable. If the
Inter-Area-Router TLV is not included in the E-Inter-Area-Router-LSA, Inter-Area-Router TLV is not included in the E-Inter-Area-Router-LSA,
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-Router TLV subsequent to the first MUST be ignored. the Inter-Area-Router TLV subsequent to the first MUST be ignored.
4.5. OSPFv3 E-AS-External-LSA 4.5. OSPFv3 E-AS-External-LSA
skipping to change at page 22, line 32 skipping to change at page 22, line 32
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length | | LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. TLVs . . TLVs .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E-AS-External-LSA E-AS-External-LSA
All LSA Header fields are the same as defined for the AS-External- Other than having a differnt LS Type, all LSA Header fields are the
LSA. In order to retain compatibility and semantics with the current same as defined for the AS-External-LSA. In order to retain
OSPFv3 specification, each LSA MUST contain a single External Prefix compatibility and semantics with the current OSPFv3 specification,
TLV. This will facilitate migration and avoid changes to OSPFv3 each LSA MUST contain a single External Prefix TLV. This will
processes such as incremental SPF computation. facilitate migration and avoid changes to OSPFv3 processes such as
incremental SPF computation.
Like the existing AS-External-LSA, the LSA length is used to Like the existing AS-External-LSA, the LSA length is used to
determine the end of the LSA including sub-TLVs. Initially, only the determine the end of the LSA including sub-TLVs. Initially, only the
top-level External-Prefix TLV (Section 3.6) is applicable. If the top-level External-Prefix TLV (Section 3.6) is applicable. If the
External-Prefix TLV is not included in the E-External-AS-LSA, it is External-Prefix TLV is not included in the E-External-AS-LSA, it is
treated as malformed as described in Section 5. Instances of the treated as malformed as described in Section 5. Instances of the
External-Prefix TLV subsequent to the first MUST be ignored. External-Prefix TLV subsequent to the first MUST be ignored.
4.6. OSPFv3 E-NSSA-LSA 4.6. OSPFv3 E-NSSA-LSA
skipping to change at page 24, line 34 skipping to change at page 24, line 34
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rtr Priority | Options | | Rtr Priority | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. TLVs . . TLVs .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E-Link-LSA E-Link-LSA
All LSA Header fields are the same as defined for the Link-LSA. Other than having a differnt LS Type, all LSA Header fields are the
same as defined for the Link-LSA.
Only the Intra-Area-Prefix TLV (Section 3.7), IPv6 Link-Local Address Only the Intra-Area-Prefix TLV (Section 3.7), IPv6 Link-Local Address
TLV (Section 3.8), and IPv4 Link-Local Address TLV (Section 3.9) are TLV (Section 3.8), and IPv4 Link-Local Address TLV (Section 3.9) are
applicable to the E-Link-LSA. Like the Link-LSA, the E-Link-LSA applicable to the E-Link-LSA. Like the Link-LSA, the E-Link-LSA
affords advertisement of multiple intra-area prefixes. Hence, affords advertisement of multiple intra-area prefixes. Hence,
multiple Intra-Area Prefix TLVs (Section 3.7) may be specified and multiple Intra-Area Prefix TLVs (Section 3.7) may be specified and
the LSA length defines the end of the LSA including all TLVs. the LSA length defines the end of the LSA including all TLVs.
A single instance of the IPv6 Link-Local Address TLV (Section 3.8) A single instance of the IPv6 Link-Local Address TLV (Section 3.8)
SHOULD be included in the E-Link-LSA. Instances following the first SHOULD be included in the E-Link-LSA. Instances following the first
skipping to change at page 26, line 9 skipping to change at page 26, line 9
malformed as described in Section 5. malformed as described in Section 5.
Future specifications may support advertisement of routing and Future specifications may support advertisement of routing and
topology information for multiple address families. However, this is topology information for multiple address families. However, this is
beyond the scope of this document. beyond the scope of this document.
4.8. OSPFv3 E-Intra-Area-Prefix-LSA 4.8. OSPFv3 E-Intra-Area-Prefix-LSA
The E-Intra-Area-Prefix-LSA has an LS Type of 0xA029 and has the same The E-Intra-Area-Prefix-LSA has an LS Type of 0xA029 and has the same
base information content as the Intra-Area-Prefix-LSA defined in base information content as the Intra-Area-Prefix-LSA defined in
section A.4.10 of [OSPFV3]. However, unlike the Intra-Area-Prefix- section A.4.10 of [OSPFV3] except for the Referenced LS Type.
LSA, it is fully extendable and represented as TLVs. However, unlike the Intra-Area-Prefix-LSA, it is fully extendable and
represented as TLVs. The Referenced LS Type MUST be either an E-
Router-LSA (0xA021) or an E-Network-LSA (0xA022).
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| 0x29 | | LS Age |1|0|1| 0x29 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID | | Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router | | Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 26, line 38 skipping to change at page 26, line 40
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Referenced Advertising Router | | Referenced Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. TLVs . . TLVs .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E-Intra-Area-Prefix-LSA E-Intra-Area-Prefix-LSA
All LSA Header fields are the same as defined for the Intra-Area- Other than having a differnt LS Type, all LSA Header fields are the
Prefix-LSA. same as defined for the Intra-Area-Prefix-LSA.
Like the Intra-Area-Prefix-LSA, the E-Intra-Area-Link-LSA affords Like the Intra-Area-Prefix-LSA, the E-Intra-Area-Link-LSA affords
advertisement of multiple intra-area prefixes. Hence, multiple advertisement of multiple intra-area prefixes. Hence, multiple
Intra-Area Prefix TLVs may be specified and the LSA length defines Intra-Area Prefix TLVs may be specified and the LSA length defines
the end of the LSA including all TLVs. the end of the LSA including all TLVs.
5. Malformed OSPFv3 Extended LSA Handling 5. Malformed OSPFv3 Extended LSA Handling
Extended LSAs that have inconsistent length or other encoding errors, Extended LSAs that have inconsistent length or other encoding errors,
as described herein, MUST NOT be installed in the Link State as described herein, MUST NOT be installed in the Link State
Database, acknowledged, or flooded. Reception of malformed LSAs Database, acknowledged, or flooded. Reception of malformed LSAs
SHOULD be counted and/or logged for examination by the administrator SHOULD be counted and/or logged for examination by the administrator
of the OSPFv3 Routing Domain. of the OSPFv3 Routing Domain. Note that for the purposes of length
validation, a TLV or Sub-TLV should not be considered invalid unless
the length exceeds the length of the LSA or does not meet the minimum
length requirements. This allows for Sub-TLVs to be added as
described in Section 6.3.
Additionally, an LSA MUST be considered malformed if it does not
include any required TLV or Sub-TLVs.
6. LSA Extension Backward Compatibility 6. LSA Extension Backward Compatibility
In the context of this document, backward compatibility is solely In the context of this document, backward compatibility is solely
related to the capability of an OSPFv3 router to receive, process, related to the capability of an OSPFv3 router to receive, process,
and originate the TLV-based LSAs defined herein. Unrecognized TLVs and originate the TLV-based LSAs defined herein. Unrecognized TLVs
and sub-TLVs are ignored. Backward compatibility for future OSPFv3 and sub-TLVs are ignored. Backward compatibility for future OSPFv3
extensions utilizing the TLV-based LSAs is out of scope and must be extensions utilizing the TLV-based LSAs is out of scope and must be
covered in the documents describing those extensions. Both full and, covered in the documents describing those extensions. Both full and,
if applicable, partial deployment SHOULD be specified for future TLV- if applicable, partial deployment SHOULD be specified for future TLV-
skipping to change at page 28, line 27 skipping to change at page 28, line 41
MUST be specified. MUST be specified.
3. If partial deployment is not supported, mechanisms to ensure the 3. If partial deployment is not supported, mechanisms to ensure the
corresponding feature are not deployed MUST be specified in the corresponding feature are not deployed MUST be specified in the
document defining the new TLV or sub-TLV. document defining the new TLV or sub-TLV.
4. If partial deployment is supported, backward compatibility and 4. If partial deployment is supported, backward compatibility and
partial deployment MUST be specified in the document defining the partial deployment MUST be specified in the document defining the
new TLV or sub-TLV. new TLV or sub-TLV.
5. If a TLV or Sub-TLV is recognized but the length is less than the
minimum, then the LSA should be considered malformed and it
SHOULD NOT be acknowledged. Additionally, the occurence SHOULD
be logged with enough information to identify the LSA by type,
originator, and sequence number and the TLV or Sub-TLV in error.
Ideally, the log entry would include the hexidecimal or binary
representation of the LSA including the malformed TLS or Sub-TLV.
6. Documents specifying future TLVs or Sub-TLVs MUST specify the
requirements for usage of those TLVs or Sub-TLVs.
7. Future TLV or Sub-TLVs must be optional. However, there may be
requirements for Sub-TLVs if an optional TLV is specified.
7. Security Considerations 7. Security Considerations
In general, extendible OSPFv3 LSAs are subject to the same security In general, extendible OSPFv3 LSAs are subject to the same security
concerns as those described in RFC 5340 [OSPFV3]. Additionally, concerns as those described in RFC 5340 [OSPFV3]. Additionally,
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.
skipping to change at page 29, line 24 skipping to change at page 30, line 4
o 4 - Inter-Area Router TLV o 4 - Inter-Area Router TLV
o 5 - External Prefix TLV o 5 - External Prefix TLV
o 6 - Intra-Area Prefix TLV o 6 - Intra-Area Prefix TLV
o 7 - IPv6 Link-Local Address TLV o 7 - IPv6 Link-Local Address TLV
o 8 - IPv4 Link-Local Address TLV o 8 - IPv4 Link-Local Address TLV
The OSPFv3 Extended-LSA sub-TLV registry will define sub-TLVs at any The OSPFv3 Extended-LSA sub-TLV registry will define sub-TLVs at any
level of nesting for Extended-LSAs and should be placed in the level of nesting for Extended-LSAs and should be placed in the
existing OSPFv3 IANA registry. 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
o 2 - Route Tag o 2 - Route Tag
The OSPFv3 Prefix Options registry will define a new code point for The OSPFv3 Prefix Options registry will define a new code point for
the N-bit. The value 0x20 is suggested. the N-bit. The value 0x20 is suggested.
9. References 9. Contributors
9.1. Normative References Contributors' Addresses
Sina Mirtorabi
Cisco Systems
170 Tasman Drive
San Jose, CA 95134
USA
Email: sina@cisco.com
10. References
10.1. Normative References
[GRACEFUL-RESTART] [GRACEFUL-RESTART]
Lindem, A. and P. Pillay-Esnault, "OSPFv3 Graceful Lindem, A. and P. Pillay-Esnault, "OSPFv3 Graceful
Restart", RFC 5187, June 2008. Restart", RFC 5187, June 2008.
[NSSA] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", [NSSA] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option",
RFC 3101, January 2003. RFC 3101, January 2003.
[OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF [OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008. for IPv6", RFC 5340, July 2008.
skipping to change at page 30, line 20 skipping to change at page 31, line 12
Aggarwal, "Support of Address Families in OSPFv3", RFC Aggarwal, "Support of Address Families in OSPFv3", RFC
5838, April 2010. 5838, April 2010.
[RFC-KEYWORDS] [RFC-KEYWORDS]
Bradner, S., "Key words for use in RFCs to Indicate Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering [TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering
Extensions to OSPF", RFC 3630, September 2003. Extensions to OSPF", RFC 3630, September 2003.
9.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-03.txt OSPFv3 (MT-OSPFV3)", draft-ietf-ospf-mt-ospfv3-03.txt
(work in progress), January 2008. (work in progress), January 2008.
[OSPF-DIGITAL-SIGNATURE] [OSPF-DIGITAL-SIGNATURE]
Murphy, S., Badger, M., and B. Wellington, "OSPF with Murphy, S., Badger, M., and B. Wellington, "OSPF with
Digital Signatures", RFC 2154, June 1997. Digital Signatures", RFC 2154, June 1997.
skipping to change at page 36, line 23 skipping to change at page 37, line 4
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
Acee Lindem Acee Lindem
Cisco Systems Cisco Systems
301 Midenhall Way 301 Midenhall Way
Cary, NC 27513 Cary, NC 27513
USA USA
Email: acee@cisco.com Email: acee@cisco.com
Sina Mirtorabi
Cisco Systems
170 Tasman Drive
San Jose, CA 95134
USA
Email: sina@cisco.com
Abhay Roy Abhay Roy
Cisco Systems Cisco Systems
170 Tasman Drive 170 Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: akr@cisco.com Email: akr@cisco.com
Dirk Goethals
Nokia
Copernicuslaan 50
Antwerp 2018
Belgium
Email: dirk.goethals@nokia.com
Veerendranatha Reddy Vallem
Huawei, Inc
Email: veerendranatharv@huawei.com
Fred Baker Fred Baker
Santa Barbara, California 93117 Santa Barbara, California 93117
USA USA
Email: FredBaker.IETF@gmail.com Email: FredBaker.IETF@gmail.com
 End of changes. 29 change blocks. 
67 lines changed or deleted 118 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/