< draft-ietf-ospf-ospfv3-lsa-extend-03.txt   draft-ietf-ospf-ospfv3-lsa-extend-04.txt >
Network Working Group A. Lindem Network Working Group A. Lindem
Internet-Draft Ericsson Internet-Draft S. Mirtorabi
Intended status: Standards Track S. Mirtorabi Intended status: Standards Track A. Roy
Expires: November 30, 2014 A. Roy Expires: March 22, 2015 F. Baker
F. Baker
Cisco Systems Cisco Systems
May 29, 2014 September 18, 2014
OSPFv3 LSA Extendibility OSPFv3 LSA Extendibility
draft-ietf-ospf-ospfv3-lsa-extend-03.txt draft-ietf-ospf-ospfv3-lsa-extend-04.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 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 November 30, 2014. This Internet-Draft will expire on March 22, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3
1.2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 4 1.2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 3
2. OSPFv3 Extended LSA Types . . . . . . . . . . . . . . . . . . 6 2. OSPFv3 Extended LSA Types . . . . . . . . . . . . . . . . . . 5
3. OSPFv3 Extended LSA TLVs . . . . . . . . . . . . . . . . . . . 7 3. OSPFv3 Extended LSA TLVs . . . . . . . . . . . . . . . . . . . 6
3.1. Router-Link TLVs . . . . . . . . . . . . . . . . . . . . . 8 3.1. Router-Link TLV . . . . . . . . . . . . . . . . . . . . . 7
3.2. Attached-Routers TLV . . . . . . . . . . . . . . . . . . . 9 3.2. Attached-Routers TLV . . . . . . . . . . . . . . . . . . . 8
3.3. Inter-Area-Prefix TLV . . . . . . . . . . . . . . . . . . 10 3.3. Inter-Area-Prefix TLV . . . . . . . . . . . . . . . . . . 9
3.4. Inter-Area-Router TLV . . . . . . . . . . . . . . . . . . 11 3.4. Inter-Area-Router TLV . . . . . . . . . . . . . . . . . . 10
3.5. External-Prefix TLV . . . . . . . . . . . . . . . . . . . 12 3.5. External-Prefix TLV . . . . . . . . . . . . . . . . . . . 11
3.6. Intra-Area-Prefix TLV . . . . . . . . . . . . . . . . . . 13 3.6. Intra-Area-Prefix TLV . . . . . . . . . . . . . . . . . . 12
3.7. IPv6 Link-Local Address TLV . . . . . . . . . . . . . . . 14 3.7. IPv6 Link-Local Address TLV . . . . . . . . . . . . . . . 13
3.8. IPv4 Link-Local Address TLV . . . . . . . . . . . . . . . 15 3.8. IPv4 Link-Local Address TLV . . . . . . . . . . . . . . . 14
3.9. Forwarding-Address Sub-TLV . . . . . . . . . . . . . . . . 16 3.9. IPv6-Forwarding-Address Sub-TLV . . . . . . . . . . . . . 15
3.10. Route-Tag Sub-TLV . . . . . . . . . . . . . . . . . . . . 16 3.10. IPv4-Forwarding-Address Sub-TLV . . . . . . . . . . . . . 15
3.11. Route-Tag Sub-TLV . . . . . . . . . . . . . . . . . . . . 16
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 . . . . . . . . . . . . . . . . . . . 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. LSA Extension Backward Compatibility . . . . . . . . . . . . . 26 5. Malformed OSPFv3 Extended LSA Handling . . . . . . . . . . . . 26
5.1. Extended LSA Mixed-Mode Backward Compatibility . . . . . . 27 6. LSA Extension Backward Compatibility . . . . . . . . . . . . . 27
5.1.1. Area Extended LSA Mixed-Mode Backward Compatibility . 28 6.1. Extended LSA Mixed-Mode Backward Compatibility . . . . . . 28
5.2. LSA TLV Processing Backward Compatibility . . . . . . . . 28 6.1.1. Area Extended LSA Mixed-Mode Backward Compatibility . 29
6. Security Considerations . . . . . . . . . . . . . . . . . . . 30 6.2. LSA TLV Processing Backward Compatibility . . . . . . . . 30
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
8.1. Normative References . . . . . . . . . . . . . . . . . . . 32 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
8.2. Informative References . . . . . . . . . . . . . . . . . . 32 9.1. Normative References . . . . . . . . . . . . . . . . . . . 33
Appendix A. Global Configuration Parameters . . . . . . . . . . . 33 9.2. Informative References . . . . . . . . . . . . . . . . . . 33
Appendix B. Area Configuration Parameters . . . . . . . . . . . . 34 Appendix A. Global Configuration Parameters . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 Appendix B. 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 8, line 10 skipping to change at page 7, line 10
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
Additionally, this document defines the following sub-TLV types: Additionally, this document defines the following sub-TLV types:
o 0 - Reserved o 0 - Reserved
o 1 - Forwarding Address sub-TLV o 1 - IPv6 Forwarding Address sub-TLV
o 2 - Route Tag sub-TLV o 2 - IPv4 Forwarding Address 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.
3.1. Router-Link TLVs 3.1. 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
MUST be ignored. MUST be ignored.
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 12, line 34 skipping to change at page 11, line 34
| Address Prefix | | Address Prefix |
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. sub-TLVs . . sub-TLVs .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
External Prefix TLV External Prefix TLV
In the External-Prefix TLV, the optional Forwarding Address and In the External-Prefix TLV, the optional IPv6/IPv4 Forwarding Address
External Route Tag are now sub-TLVs. Given the Referenced LS type and External Route Tag are now sub-TLVs. Given the Referenced LS
and Referenced Link State ID from the AS-External-LSA have never been type and Referenced Link State ID from the AS-External-LSA have never
used or even specified, they have been omitted from the External been used or even specified, they have been omitted from the External
Prefix TLV. If there were ever a requirement for a referenced LSA, Prefix TLV. If there were ever a requirement for a referenced LSA,
it could be satisfied with a sub-TLV. it could be satisfied with a sub-TLV.
The following sub-TLVs are defined for optional inclusion in the The following sub-TLVs are defined for optional inclusion in the
External Prefix TLV: External Prefix TLV:
o 1 - Forwarding Address sub-TLV (Section 3.9) o 1 - IPv6 Forwarding Address sub-TLV (Section 3.9)
o 2 - Route Tag sub-TLV (Section 3.10) o 2 - IPv4 Forwarding Address sub-TLV (Section 3.10)
o 3 - Route Tag sub-TLV (Section 3.11)
3.6. Intra-Area-Prefix TLV 3.6. Intra-Area-Prefix TLV
The Intra-Area-Prefix TLV defines a single OSPFv3 intra-area prefix. The Intra-Area-Prefix TLV defines a single OSPFv3 intra-area prefix.
The field definitions correspond directly to the content of an OSPFv3 The field definitions correspond directly to the content of an OSPFv3
IPv6 Prefix as defined in Section A.4.1, [OSPFV3] and an OSPFv3 Link- IPv6 Prefix as defined in Section A.4.1, [OSPFV3] and an OSPFv3 Link-
LSA, as defined in section A.4.9, [OSPFV3]. The Intra-Area-Prefix LSA, as defined in section A.4.9, [OSPFV3]. The Intra-Area-Prefix
TLV is only applicable to the E-Link-LSA (Section 4.7) and the TLV is only applicable to the E-Link-LSA (Section 4.7) and the
E-Intra-Area-Prefix-LSA (Section 4.8). Inclusion in other Extended E-Intra-Area-Prefix-LSA (Section 4.8). Inclusion in other Extended
LSAs MUST be ignored. LSAs MUST be ignored.
skipping to change at page 16, line 5 skipping to change at page 15, line 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Link-Local Interface Address | | IPv4 Link-Local Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. sub-TLVs . . sub-TLVs .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 Link-Local Address TLV IPv4 Link-Local Address TLV
3.9. Forwarding-Address Sub-TLV 3.9. IPv6-Forwarding-Address Sub-TLV
The Forwarding Address TLV has identical semantics to the optional The IPv6 Forwarding Address TLV has identical semantics to the
forwarding address in section A.4.7 of [OSPFV3]. The Forwarding optional forwarding address in section A.4.7 of [OSPFV3]. The IPv6
Address TLV is applicable to the External-Prefix TLV (Section 3.5). Forwarding Address TLV is applicable to the External-Prefix TLV
Specification as a sub-TLV of other TLVs is not defined herein. The (Section 3.5). Specification as a sub-TLV of other TLVs is not
sub-TLV is optional and the first specified instance is used as the defined herein. The sub-TLV is optional and the first specified
Forwarding Address as defined in [OSPFV3]. Instances subsequent to instance is used as the Forwarding Address as defined in [OSPFV3].
the first are ignored. Instances subsequent to the first MUST be ignored.
The IPv6 Forwarding Address TLV is to be used with IPv6 address
families as defined in [OSPFV3-AF] It will be ignored for other
address families.
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 Forwarding Address Tag TLV
3.10. Route-Tag Sub-TLV 3.10. IPv4-Forwarding-Address Sub-TLV
The IPv4 Forwarding Address TLV has identical semantics to the
optional forwarding address in section A.4.7 of [OSPFV3]. The IPv4
Forwarding Address TLV is The IPv4 Forwarding Address TLV is
applicable to the External-Prefix TLV (Section 3.5). 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 Forwarding
Address as defined in [OSPFV3]. Instances subsequent to the first
MUST be ignored.
The IPv4 Forwarding Address TLV is to be used with IPv3 address
families as defined in [OSPFV3-AF] It will be ignored for other
address families.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 - Forwarding Address | sub-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Forwarding Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Forwarding Address Tag TLV
3.11. 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.5). Tag sub-TLV is applicable to the External-Prefix TLV (Section 3.5).
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
are ignored. MUST be ignored.
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 - Route Tag | sub-TLV Length | | 3 - Route Tag | sub-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Tag | | Route Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Route Tag Sub-TLV Route Tag Sub-TLV
4. OSPFv3 Extended LSAs 4. OSPFv3 Extended LSAs
This section specifies the OSPFv3 Extended LSA formats and encoding. This section specifies the OSPFv3 Extended LSA formats and encoding.
The Extended OSPFv3 LSAs corresponded directly to the original OSPFv3 The Extended OSPFv3 LSAs corresponded directly to the original OSPFv3
skipping to change at page 18, line 37 skipping to change at page 18, line 37
. . . .
. TLVs . . TLVs .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E-Network-LSA E-Network-LSA
All LSA Header fields are the same as defined for the Network-LSA. All LSA Header fields are the same as defined for the Network-LSA.
Like the existing Network-LSA, the LSA length is used to determine Like the existing Network-LSA, the LSA length is used to determine
the end of the LSA including TLVs. Initially, only the top-level the end of the LSA including TLVs. Initially, only the top-level
Attached-Routers TLV Section 3.2 is applicable. Attached-Routers TLV Section 3.2 is applicable. If the Attached-
Router TLV is not included in the E-Network-LSA, it is treated as
malformed as described in Section 5. 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 19, line 40 skipping to change at page 19, line 40
E-Inter-Area-Prefix-LSA E-Inter-Area-Prefix-LSA
All LSA Header fields are the same as defined for the Inter-Area- All LSA Header fields are the same as defined for the Inter-Area-
Prefix-LSA. In order to retain compatibility and semantics with the Prefix-LSA. In order to retain compatibility and semantics with the
current OSPFv3 specification, each Inter-Area-Prefix LSA MUST contain current OSPFv3 specification, each Inter-Area-Prefix LSA MUST contain
a single Inter-Area Prefix TLV. This will facilitate migration and a single Inter-Area Prefix TLV. This will facilitate migration and
avoid changes to functions such as incremental SPF computation. 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.3) is applicable. level Inter-Area-Prefix TLV (Section 3.3) is applicable. If the
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
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-LSAE 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
skipping to change at page 20, line 40 skipping to change at page 20, line 40
E-Inter-Area-Router-LSA E-Inter-Area-Router-LSA
All LSA Header fields are the same as defined for the Inter-Area- All LSA Header fields are the same as defined for the Inter-Area-
Router-LSA. In order to retain compatibility and semantics with the Router-LSA. In order to retain compatibility and semantics with the
current OSPFv3 specification, each Inter-Area-Router LSA MUST contain current OSPFv3 specification, each Inter-Area-Router LSA MUST contain
a single Inter-Area Router TLV. This will facilitate migration and a single Inter-Area Router TLV. This will facilitate migration and
avoid changes to functions such as incremental SPF computation. 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.4) is applicable. level Inter-Area-Router TLV (Section 3.4) is applicable. If the
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
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
The E-AS-External-LSA has an LS Type of 0xC025 and has the same base The E-AS-External-LSA has an LS Type of 0xC025 and has the same base
information content as the AS-External-LSA defined in section A.4.7 information content as the AS-External-LSA defined in section A.4.7
of [OSPFV3]. However, unlike the existing AS-External-LSA, it is of [OSPFV3]. However, unlike the existing AS-External-LSA, it is
fully extendable and represented as TLVs. 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 21, line 40 skipping to change at page 21, line 40
E-AS-External-LSA E-AS-External-LSA
All LSA Header fields are the same as defined for the AS-External- All LSA Header fields are the same as defined for the AS-External-
LSA. In order to retain compatibility and semantics with the current LSA. In order to retain compatibility and semantics with the current
OSPFv3 specification, each LSA MUST contain a single External Prefix OSPFv3 specification, each LSA MUST contain a single External Prefix
TLV. This will facilitate migration and avoid changes to OSPFv3 TLV. This will facilitate migration and avoid changes to OSPFv3
processes such as incremental SPF computation. 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.5) is applicable. top-level External-Prefix TLV (Section 3.5) is applicable. If the
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
External-Prefix TLV subsequent to the first MUST be ignored.
4.6. OSPFv3 E-NSSA-LSA 4.6. OSPFv3 E-NSSA-LSA
The E-NSSA-LSA will have the same format and TLVs as the Extended AS- The E-NSSA-LSA will have the same format and TLVs as the Extended AS-
External-LSA Section 4.5. This is the same relationship as exists External-LSA Section 4.5. This is the same relationship as exists
between the NSSA-LSA defined in section A.4.8 of [OSPFV3], and the between the NSSA-LSA defined in section A.4.8 of [OSPFV3], and the
AS-External-LSA. The NSSA-LSA will have type 0xA027 which implies AS-External-LSA. The NSSA-LSA will have type 0xA027 which implies
area flooding scope. Future requirements may dictate that supported area flooding scope. Future requirements may dictate that supported
TLVs differ between the E-AS-External-LSA and the E-NSSA-LSA. TLVs differ between the E-AS-External-LSA and the E-NSSA-LSA.
However, future requirements are beyond the scope of this document. However, future requirements are beyond the scope of this document.
skipping to change at page 23, line 43 skipping to change at page 23, line 43
All LSA Header fields are the same as defined for the Link-LSA. All LSA Header fields are the same as defined for the Link-LSA.
Only the Intra-Area-Prefix TLV (Section 3.6), IPv6 Link-Local Address Only the Intra-Area-Prefix TLV (Section 3.6), IPv6 Link-Local Address
TLV (Section 3.7), and IPv4 Link-Local Address TLV (Section 3.8) are TLV (Section 3.7), and IPv4 Link-Local Address TLV (Section 3.8) 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.6) may be specified and multiple Intra-Area Prefix TLVs (Section 3.6) 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.
Only a single instance of the IPv6 Link-Local Address TLV A single instance of the IPv6 Link-Local Address TLV (Section 3.7)
(Section 3.7) SHOULD be included in the E-Link-LSA. Instances SHOULD be included in the E-Link-LSA. Instances following the first
following the first MUST be ignored. For IPv4 address families as MUST be ignored. For IPv4 address families as defined in
defined in [OSPFV3-AF], this TLV MUST be ignored. [OSPFV3-AF], this TLV MUST be ignored.
Similarly, only a single instance of the IPv4 Link-Local Address TLV Similarly, only a single instance of the IPv4 Link-Local Address TLV
(Section 3.8) SHOULD be included in the E-Link-LSA. Instances (Section 3.8) SHOULD be included in the E-Link-LSA. Instances
following the first MUST be ignored. For OSPFv3 IPv6 address following the first MUST be ignored. For OSPFv3 IPv6 address
families as defined in [OSPFV3-AF], this TLV MUST be ignored. families as defined in [OSPFV3-AF], this TLV MUST be ignored.
If the IPv4/IPv6 Link-Local Address TLV corresponding to the OSPFv3
Address Family is not included in the E-Link-LSA, it is treated as
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]. However, unlike the Intra-Area-Prefix-
LSA, it is fully extendable and represented as TLVs. LSA, it is fully extendable and represented as TLVs.
skipping to change at page 26, line 5 skipping to change at page 26, line 5
E-Intra-Area-Prefix-LSA E-Intra-Area-Prefix-LSA
All LSA Header fields are the same as defined for the Intra-Area- All LSA Header fields are the same as defined for the Intra-Area-
Prefix-LSA. 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. LSA Extension Backward Compatibility 5. Malformed OSPFv3 Extended LSA Handling
Extended LSAs that have inconsistent length or other encoding errors,
as described herein, MUST NOT be installed in the Link State
Database, acknowledged, or flooded. Reception of malformed LSAs
SHOULD be counted and/or logged for examination by the administrator
of the OSPFv3 Routing Domain.
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-
based OSPFv3 LSA extensions. based OSPFv3 LSA extensions.
Two distinct backward compatibility modes are supported dependent on Two distinct backward compatibility modes are supported dependent on
the OSPFv3 routing domain migration requirements. For simplicity and the OSPFv3 routing domain migration requirements. For simplicity and
to avoid the scaling impact of maintaining both TLV and non-TLV based 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 versions of the same LSA within a routing domain, the basic backward
compatibility mode will not allow mixing of LSA formats. Different compatibility mode will not allow mixing of LSA formats. Different
LSA formats could still be supported with multiple OSPFv3 instances LSA formats could still be supported with multiple OSPFv3 instances
and separate OSPFv3 routing domains. Additionally, a more flexible and separate OSPFv3 routing domains. Additionally, a more flexible
mode is provided in Section 5.1, where both formats of LSA coexist. mode is provided in Section 6.1, where both formats of LSA coexist.
In order to facilitate backward compatibility, the OSPFv3 options In order to facilitate backward compatibility, the OSPFv3 options
field (as described in Appendix A.2 of RFC 5340 [OSPFV3]), will field (as described in Appendix A.2 of RFC 5340 [OSPFV3]), will
contain two additional options bits. The EL-bits will be used to contain two additional options bits. The EL-bits will be used to
indicate that the OSPFv3 router's level of Extended LSA support. An indicate that the OSPFv3 router's level of Extended LSA support. An
OSPFv3 router configured to support extended LSAs MUST set its OSPFv3 router configured to support extended LSAs MUST set its
options field EL-bits in OSPFv3 Hello and Database Description options field EL-bits in OSPFv3 Hello and Database Description
packets as follows: packets as follows:
B'00' B'00'
None - Extended LSAs are not originate nor used in the SPF None - Extended LSAs are not originate nor used in the SPF
skipping to change at page 27, line 38 skipping to change at page 28, line 38
SPF computation. SPF computation.
Options Field EL-bits Options Field EL-bits
The EL-bits will also be set in the LSA options field in Extended and 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 Non-Extended LSAs. While the value of the EL-bits has no functional
significance in the LSA options field, visibility of every OSPFv3 significance in the LSA options field, visibility of every OSPFv3
Router's extended LSA support is expected to be very useful for Router's extended LSA support is expected to be very useful for
management and troubleshooting during the migration period. management and troubleshooting during the migration period.
5.1. Extended LSA Mixed-Mode Backward Compatibility 6.1. Extended LSA Mixed-Mode Backward Compatibility
An implementation MAY support configuration allowing a graceful An implementation MAY support configuration allowing a graceful
transition from the non-extended (non-TLV-based) LSAs to the extended transition from the non-extended (non-TLV-based) LSAs to the extended
(TLV-based) LSAs in an OSPFv3 routing domain. In these routing (TLV-based) LSAs in an OSPFv3 routing domain. In these routing
domains, the OSPFv3 routers configured with a value of domains, the OSPFv3 routers configured with a value of
MixedModeOriginateOnly or MixedModeOriginateSPF for MixedModeOriginateOnly or MixedModeOriginateSPF for
ExtendedLSASupport, (Appendix A), MUST originate both the extended ExtendedLSASupport, (Appendix A), MUST originate both the extended
and non-extended versions of the OSPFv3 LSAs described herein. For and non-extended versions of the OSPFv3 LSAs described herein. For
the purposes of Shortest Path First (SPF) computation, the non- the purposes of Shortest Path First (SPF) computation, the non-
extended OSPFv3 LSAs are used for SPF computation when extended OSPFv3 LSAs are used for SPF computation when
skipping to change at page 28, line 33 skipping to change at page 29, line 33
3. When all the OSPFv3 Routers have been reconfigured to 3. When all the OSPFv3 Routers have been reconfigured to
MixedModeOriginateSPF and the routing has been verified, MixedModeOriginateSPF and the routing has been verified,
reconfigure OSPFv3 Routers to purge or simply not refresh the reconfigure OSPFv3 Routers to purge or simply not refresh the
non-extended OSPFv3 LSA by configuring ExtendedLSASupport to non-extended OSPFv3 LSA by configuring ExtendedLSASupport to
Full. Full.
In order to prevent OSPFv3 routing domain routing loops, the In order to prevent OSPFv3 routing domain routing loops, the
advertised metrics in the extended and non-extended OSPFv3 LSAs MUST advertised metrics in the extended and non-extended OSPFv3 LSAs MUST
be identical. be identical.
5.1.1. Area Extended LSA Mixed-Mode Backward Compatibility 6.1.1. Area Extended LSA Mixed-Mode Backward Compatibility
An implementation MAY also support configuration allowing graceful An implementation MAY also support configuration allowing graceful
transition from the non-extended LSAs to the extended LSAs within a transition from the non-extended LSAs to the extended LSAs within a
single area. In these areas, the parameter AreaExtendedLSASupport single area. In these areas, the parameter AreaExtendedLSASupport
(Appendix B) may be configured to take precedence over the global (Appendix B) may be configured to take precedence over the global
parameter ExtendedLSASupport. However, the AreaExtendedLSASupport parameter ExtendedLSASupport. However, the AreaExtendedLSASupport
will only apply to link and area scoped LSAs within the area and area will only apply to link and area scoped LSAs within the area and area
based SPF calculations. The default is for the based SPF calculations. The default is for the
AreaExtendedLSASupport to be inherited from the ExtendedLSASupport. AreaExtendedLSASupport to be inherited from the ExtendedLSASupport.
The configuration of ExtendedLSASupport will apply to AS-External The configuration of ExtendedLSASupport will apply to AS-External
LSAs even when AreaExtendedLSASupport takes precedence. LSAs even when AreaExtendedLSASupport takes precedence.
5.2. LSA TLV Processing Backward Compatibility When preforming a graceful restart [GRACEFUL-RESTART], an OSPFv3
router configured with MixedModeOriginate will use the non-extended
OSPFv3 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.
6.2. 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.
2. Whether or not partial deployment of a given TLV is supported 2. Whether or not partial deployment of a given TLV is supported
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.
6. 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.
7. 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 Extend-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:
skipping to change at page 32, line 5 skipping to change at page 33, line 5
Consensus or IESG Approval. Consensus or IESG Approval.
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
8. References 9. References
8.1. Normative References 9.1. Normative References
[GRACEFUL-RESTART]
Lindem, A. and P. Pillay-Esnault, "OSPFv3 Graceful
Restart", RFC 5178, June 2008.
[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] [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.
8.2. Informative References 9.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). (work in progress).
[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 35, line 8 skipping to change at page 36, line 8
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
Ericsson Cisco Systems
301 Midenhall Way 301 Midenhall Way
Cary, NC 27513 Cary, NC 27513
USA USA
Email: acee.lindem@ericsson.com Email: acee@cisco.com
Sina Mirtorabi Sina Mirtorabi
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
Abhay Roy Abhay Roy
 End of changes. 38 change blocks. 
88 lines changed or deleted 146 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/