Internet DRAFT - draft-acee-ospfv3-lsa-extend
draft-acee-ospfv3-lsa-extend
Network Working Group A. Lindem
Internet-Draft Ericsson
Intended status: Standards Track S. Mirtorabi
Expires: March 14, 2014 A. Roy
F. Baker
Cisco Systems
September 10, 2013
OSPFv3 LSA Extendibility
draft-acee-ospfv3-lsa-extend-02.txt
Abstract
OSPFv3 requires functional extension beyond what can readily be done
with the fixed-format Link State Advertisement (LSA) as described in
RFC 5340. Without LSA extension, attributes associated with OSPFv3
links and advertised IPv6 prefixes must be advertised in separate
LSAs and correlated to the fixed-format LSA. This document extends
the LSA format by allowing the optional inclusion of Type-Length-
Value (TLV) tuples in the LSAs. Backward compatibility mechanisms
are also described.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 14, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
Lindem, et al. Expires March 14, 2014 [Page 1]
Internet-Draft OSPFv3 LSA Extendibility September 2013
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
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.
Lindem, et al. Expires March 14, 2014 [Page 2]
Internet-Draft OSPFv3 LSA Extendibility September 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4
1.2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 4
2. OSPFv3 Extended LSA Types . . . . . . . . . . . . . . . . . . 6
3. OSPFv3 Extended LSA TLV . . . . . . . . . . . . . . . . . . . 7
4. OSPFv3 E-Router-LSA . . . . . . . . . . . . . . . . . . . . . 8
5. OSPFv3 E-Network-LSA . . . . . . . . . . . . . . . . . . . . . 10
6. OSPFv3 E-Inter-Area-Prefix-LSA . . . . . . . . . . . . . . . . 12
7. OSPFv3 E-Inter-Area-Router-LSA . . . . . . . . . . . . . . . . 14
8. OSPFv3 E-AS-External-LSA . . . . . . . . . . . . . . . . . . . 16
9. OSPFv3 E-NSSA-LSA . . . . . . . . . . . . . . . . . . . . . . 18
10. OSPFv3 E-Link-LSA . . . . . . . . . . . . . . . . . . . . . . 19
11. OSPFv3 E-Intra-Area-Prefix-LSA . . . . . . . . . . . . . . . . 22
12. LSA Extension Backward Compatibility . . . . . . . . . . . . . 23
12.1. Extended LSA Mixed-Mode Backward Compatibility . . . . . . 24
12.2. LSA TLV Processing Backward Compatibility . . . . . . . . 24
13. Security Considerations . . . . . . . . . . . . . . . . . . . 25
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
15.1. Normative References . . . . . . . . . . . . . . . . . . . 27
15.2. Informative References . . . . . . . . . . . . . . . . . . 27
Appendix A. Configurable Constants . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Lindem, et al. Expires March 14, 2014 [Page 3]
Internet-Draft OSPFv3 LSA Extendibility September 2013
1. Introduction
OSPFv3 requires functional extension beyond what can readily be done
with the fixed-format Link State Advertisement (LSA) as described in
RFC 5340 [OSPFV3]. Without LSA extension, attributes associated with
OSPFv3 links and advertised IPv6 prefixes must be advertised in
separate LSAs and correlated to the fixed-format LSA. This document
extends the LSA format by allowing the optional inclusion of Type-
Length-Value (TLV) tuples in the LSAs. Backward compatibility
mechanisms are also described.
A similar extension was previously proposed in support of multi-
topology routing. Additional requirements for OSPFv3 LSA extension
include source/destination routing, route tagging, and others.
A final requirement is to limit the changes to OSPFv3 to those
necessary for TLV-based LSAs. For the most part, the semantics of
existing OSPFv3 LSA are retained for their TLV-based successor LSAs
described herein. Additionally, encoding details, e.g., the
representation of IPv6 prefixes as described in section A.4.1 in RFC
5340 [OSPFV3], have been retained. This requirement was included to
increase the expedience of IETF adoption and deployment.
The following aspects of OSPFv3 LSA extension are described:
1. Extended LSA Types
2. Extended LSA Formats
3. Backward Compatibility
1.1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC-KEYWORDS].
1.2. Acknowledgments
OSPFv3 TLV-based LSAs were first proposed in "Multi-topology routing
in OSPFv3 (MT-OSPFv3)" [MT-OSPFV3].
Thanks for Peter Psenak for significant contributions to the backward
compatibility mechanisms.
Thanks go to Michael Barnes, Mike Dubrovsky, and Anton Smirnov for
review of the draft versions and discussions of backward
compatibility.
Lindem, et al. Expires March 14, 2014 [Page 4]
Internet-Draft OSPFv3 LSA Extendibility September 2013
The RFC text was produced using Marshall Rose's xml2rfc tool.
Lindem, et al. Expires March 14, 2014 [Page 5]
Internet-Draft OSPFv3 LSA Extendibility September 2013
2. OSPFv3 Extended LSA Types
In order to provide backward compatibility, new LSA codes must be
allocated. There are eight fixed-format LSAs defined in RFC 5340
[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,
added. The alternative was to allocate a bit in the LSA Type
indicating the new LSA format. However, this would have used one
half the LSA function code space for the migration of the eight
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
routers that do not understand them.
LSA function code LS Type Description
----------------------------------------------------
33 0xA021 E-Router-LSA
34 0xA022 E-Network-LSA
35 0xA023 E-Inter-Area-Prefix-LSA
36 0xA024 E-Inter-Area-Router-LSA
37 0xC025 E-AS-External-LSA
38 N/A Unused (Not to be allocated)
39 0xA027 E-Type-7-LSA
40 0x8028 E-Link-LSA
41 0xA029 E-Intra-Area-Prefix-LSA
OSPFv3 Extended LSA Types
Lindem, et al. Expires March 14, 2014 [Page 6]
Internet-Draft OSPFv3 LSA Extendibility September 2013
3. OSPFv3 Extended LSA TLV
The format of the TLVs within the body of the extended LSAs is the
same as the format used by the Traffic Engineering Extensions to OSPF
[TE]. The variable TLV section consists of one or more nested Type/
Length/Value (TLV) tuples. The format of each TLV is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Format
The Length field defines the length of the value portion in octets
(thus a TLV with no value portion would have a length of 0). The TLV
is padded to 4-octet alignment; padding is not included in the length
field (so a 3-octet value would have a length of 3, but the total
size of the TLV would be 8 octets). Nested TLVs are also 32-bit
aligned. For example, a 1-byte value would have the length field set
to 1, and 3 octets of padding would be added to the end of the value
portion of the TLV. Unrecognized types are ignored.
Lindem, et al. Expires March 14, 2014 [Page 7]
Internet-Draft OSPFv3 LSA Extendibility September 2013
4. OSPFv3 E-Router-LSA
The E-Router-LSA has an LS Type of 0xA021 and has the same base
information content as the Router-LSA, section 4.4.3.2 in [OSPFV3].
However, unlike the existing Router-LSA, it is fully extendable and
represented as TLVs.
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
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Age |1|0|1| 0x21 |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |Nt|x|V|E|B| Options |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. TLVs .
. .
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Extended Router-LSA
All LSA Header fields are the same as defined for the Router-LSA.
The following top-level TLVs are defined:
o 0 - Reserved
o 1 - Router-Link TLV
Lindem, et al. Expires March 14, 2014 [Page 8]
Internet-Draft OSPFv3 LSA Extendibility September 2013
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 (Router-Link) | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | 0 | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. sub-TLVs .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Router-Link TLV
Like the existing Router-LSA, the LSA length is used to determine the
end of the LSA including TLVs. The Router-Link TLV is only
applicable to the E-Router-LSA. Inclusion in other Extended LSAs
MUST be ignored.
Lindem, et al. Expires March 14, 2014 [Page 9]
Internet-Draft OSPFv3 LSA Extendibility September 2013
5. OSPFv3 E-Network-LSA
The E-Network-LSA has an LS Type of 0xA022 and has the same base
information content as the Network-LSA, section 4.4.3.3 in [OSPFV3].
However, unlike the existing Network-LSA, it is fully extendable and
represented as TLVs.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Age |1|0|1| 0x22 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. TLVs .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E-Network-LSA
All LSA Header fields are the same as defined for the Network-LSA.
The following top-level TLVs are defined:
o 2 - Attached-Routers TLV
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 (Attached-Routers) | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adjacent Neighbor Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Additional Adjacent Neighbors .
. .
Lindem, et al. Expires March 14, 2014 [Page 10]
Internet-Draft OSPFv3 LSA Extendibility September 2013
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attached-Routers TLV
There are two reasons for not having a separate TLV or sub-TLV for
each adjacent neighbor. The first is to discourage using the
E-Network-LSA for more than its current role of solely advertising
the routers attached to a multi-access network. The router's metric
as well as her attributes of individual attached routers should be
advertised in their respective E-Router-LSAs. The second reason is
that there is only a single E-Network-LSA per multi-access link with
the Link State ID set to the Designated Router's Interface ID and,
consequently, compact encoding has been chosen to decrease the
likelihood of the size of the E-Network-LSA requiring IPv6
fragmentation when advertised in an OSPFv3 Link State Update packet.
Like the existing Network-LSA, the LSA length is used to determine
the end of the LSA including TLVs. The Attached-Routers TLV is only
applicable to the E-Network-LSA. Inclusion in other Extended LSAs
MUST be ignored.
Lindem, et al. Expires March 14, 2014 [Page 11]
Internet-Draft OSPFv3 LSA Extendibility September 2013
6. OSPFv3 E-Inter-Area-Prefix-LSA
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, section
4.4.3.4 in [OSPFV3]. However, unlike the existing Inter-Area-Prefix-
LSA, it is fully extendable and represented as TLVs.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Age |1|0|1| 0x23 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. TLVs .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E-Inter-Area-Prefix-LSA
All LSA Header fields are the same as defined for the Network-LSA.
The following top-level TLVs are defined:
o 3 - Inter-Area Prefix TLV
Lindem, et al. Expires March 14, 2014 [Page 12]
Internet-Draft OSPFv3 LSA Extendibility September 2013
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 (Inter-Area Prefix) | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. sub-TLVs .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Inter-Area Prefix TLV
In order to retain compatibility and semantics with the current
OSPFv3 specification, each LSA MUST contain a single Inter-Area
Prefix 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
determine the end of the LSA including TLV. The Inter-Area-Prefix
TLV is only applicable to the E-Inter-Area-Prefix-LSA. Inclusion in
other Extended LSAs MUST be ignored.
Lindem, et al. Expires March 14, 2014 [Page 13]
Internet-Draft OSPFv3 LSA Extendibility September 2013
7. OSPFv3 E-Inter-Area-Router-LSA
The E-Inter-Area-Router-LSA has an LS Type of 0xA024 and has the same
base information content as the Inter-Area-Router-LSA, section
4.4.3.5 in [OSPFV3]. However, unlike the Inter-Area-Router-LSA, it
is fully extendable and represented as TLVs.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Age |1|0|1| 0x24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. TLVs .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E-Inter-Area-Router-LSA
All LSA Header fields are the same as defined for the Inter-Area-
Router-LSA. The following top-level TLVs are defined:
o 4 - Inter-Area Router TLV
Lindem, et al. Expires March 14, 2014 [Page 14]
Internet-Draft OSPFv3 LSA Extendibility September 2013
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 (Inter-Area Router) | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. sub-TLVs .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Inter-Area Router TLV
In order to retain compatibility and semantics with the current
OSPFv3 specification, each LSA MUST contain a single Inter-Area
Router 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
determine the end of the LSA including sub-TLVs. The Inter-Area-
Router TLV is only applicable to the E-Inter-Area-Router-LSA.
Inclusion in other Extended LSAs MUST be ignored.
Lindem, et al. Expires March 14, 2014 [Page 15]
Internet-Draft OSPFv3 LSA Extendibility September 2013
8. OSPFv3 E-AS-External-LSA
The E-AS-External-LSA has an LS Type of 0xC025 and has the same base
information content as the AS-External-LSA, section 4.4.3.6 in
[OSPFV3]. However, unlike the existing AS-External-LSA, it is fully
extendable and represented as TLVs.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Age |1|1|0| 0x25 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. TLVs .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E-AS-External-LSA
All LSA Header fields are the same as defined for the AS-External-
LSA. The following top-level TLVs are defined:
o 5 - External Prefix TLV
Lindem, et al. Expires March 14, 2014 [Page 16]
Internet-Draft OSPFv3 LSA Extendibility September 2013
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 (External Prefix) | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |E|F|T| Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- Forwarding Address (Optional) -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| External Route Tag (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. sub-TLVs .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
External Prefix TLV
In order to retain compatibility and semantics with the current
OSPFv3 specification, each LSA MUST contain a single External Prefix
TLV. This will facilitate migration and avoid changes to functions
such as incremental SPF computation. Given the Referenced LS type
and Referenced Link State ID from the AS-External-LSA have never been
used or even specified, they have been omitted from the External
Prefix TLV. If there were ever a requirement for a referenced LSA,
it could be satisfied with a sub-TLV.
Like the existing AS-External-LSA, the LSA length is used to
determine the end of the LSA including sub-TLVs. The External-Prefix
TLV is only applicable to the E-AS-External-LSA and the E-NSSA-LSA.
Inclusion in other Extended LSAs MUST be ignored.
Lindem, et al. Expires March 14, 2014 [Page 17]
Internet-Draft OSPFv3 LSA Extendibility September 2013
9. OSPFv3 E-NSSA-LSA
The E-NSSA-LSA will have the same format and TLVs as the Extended AS-
External-LSA Section 8. This is the same relationship as exists
between the NSSA-LSA, section 4.4.3.7 in [OSPFV3], and the AS-
External-LSA. The NSSA-LSA will have type 0xA027 which implies area
flooding scope. Future requirements may dictate that supported TLVs
differ between the E-AS-External-LSA and the E-NSSA-LSA. However,
future requirements are beyond the scope of this document.
Lindem, et al. Expires March 14, 2014 [Page 18]
Internet-Draft OSPFv3 LSA Extendibility September 2013
10. OSPFv3 E-Link-LSA
The E-Link-LSA has an LS Type of 0x8028 and will have the same base
information content as the Link-LSA, section 4.4.3.8 in [OSPFV3].
However, unlike the existing Link-LFA, it is extendable and
represented as TLVs.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Age |1|0|0| 0x28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rtr Priority | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. TLVs .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E-Link-LSA
The following top-level TLVs are defined:
o 6 - Intra-Area Prefix TLV
o 7 - IPv6 Link-Local Address TLV
o 8 - IPv4 Link-Local Address TLV
Lindem, et al. Expires March 14, 2014 [Page 19]
Internet-Draft OSPFv3 LSA Extendibility September 2013
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6 (Intra-Area Prefix) | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. sub-TLVs .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Intra-Area Prefix TLV
Like the Link-LSA, the E-Link-LSA affords advertisement of multiple
intra-area prefixes. Hence, multiple Intra-Area Prefix TLVs may be
specified and the LSA length defines the end of the LSA including all
TLVs. The Intra-Area-Prefix TLV is only applicable to the E-Link-LSA
and the E-Intra-Area-Prefix-LSA. Inclusion in other Extended LSAs
MUST be ignored.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7 (IPv6 Local-Local Address) | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- IPv6 Link-Local Interface Address -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. sub-TLVs .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 Link-Local Address TLV
The IPv6 Link-Local Address TLV is to be used with IPv6 address
Lindem, et al. Expires March 14, 2014 [Page 20]
Internet-Draft OSPFv3 LSA Extendibility September 2013
families as defined in [OSPFV3-AF]. The IPv6 Link-Local Address TLV
is only applicable to the E-Link-LSA. Inclusion in other Extended
LSAs MUST be ignored. Only a single instance of the IPv6 Link-Local
Address family SHOULD be included in the E-Link-LSA. Instances
preceding the first MUST be ignored. For IPv4 address families as
defined in [OSPFV3-AF], this TLV SHOULD be ignored. Future
specifications may support advertisement of routing and topology
information for multiple address families. However, this is beyond
the scope of this document.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8 (IPv4 Local-Local Address) | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Link-Local Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. sub-TLVs .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 Link-Local Address TLV
The IPv4 Link-Local Address TLV is to be used with IPv4 address
families as defined in [OSPFV3-AF]. The IPv4 Link-Local Address TLV
is only applicable to the E-Link-LSA. Inclusion in other Extended
LSAs MUST be ignored. Only a single instance of the IPv4 Link-Local
Address family SHOULD be included in the E-Link-LSA. Instances
preceding the first MUST be ignored. For IPv6 address families as
defined in [OSPFV3-AF]. Future specifications may support
advertisement of routing and topology information for multiple
address families. However, this is beyond the scope of this
document.
Lindem, et al. Expires March 14, 2014 [Page 21]
Internet-Draft OSPFv3 LSA Extendibility September 2013
11. OSPFv3 E-Intra-Area-Prefix-LSA
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, section
4.4.3.9 in [OSPFV3]. However, unlike the Intra-Area-Prefix-LSA, it
is fully extendable and represented as TLVs.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Age |1|0|1| 0x29 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Referenced LS Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Referenced Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Referenced Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. TLVs .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E-Intra-Area-Prefix-LSA
All LSA Header fields are the same as defined for the Intra-Area-
Prefix-LSA. The following top-level TLVs are defined:
o 6 - Intra-Area-Prefix TLV (defined in Section 10)
Like the Intra-Area-Prefix-LSA, the E-Intra-Area-Link-LSA affords
advertisement of multiple intra-area prefixes. Hence, multiple
Intra-Area Prefix TLVs may be specified and the LSA length defines
the end of the LSA including all TLVs.
Lindem, et al. Expires March 14, 2014 [Page 22]
Internet-Draft OSPFv3 LSA Extendibility September 2013
12. 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. 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 covered for future OSPFv3 LSA extensions.
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 formats could still be supported with
multiple OSPFv3 instances and separate OSPFv3 routing domains.
Additionally, a more complex mode is provided in Section 12.1, where
both formats of LSA coexist. An OSPFv3 instance will be configured
to use either the Non-TLV-based LSAs, TLV-based LSAs, or support both
(Appendix A). In order to facilitate backward compatibility, the
OSPFv3 options field (as described in Appendix A.2 of RFC 5340
[OSPFV3]), will contain an additional options bits. The EL-bit will
be used to indicate that the advertising OSPFv3 Router can receive,
process, and originate TLV-based LSAs. An OSPFv3 router configured
to support TLV-based LSAs WILL set its option field EL-bit in OSPFv3
Hello and Database Description packets. If "Normal" 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-bit clear. In this manner, OSPFv3 routing
domains utilizing the new encoding will be completely isolated from
those using the RFC 5340 encodings.
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-bit
This bit is indicates whether or not the OSPFv3 router
supports the Extended LSA format with the bit set condition
indicating support.
Options Field EL-bit
Lindem, et al. Expires March 14, 2014 [Page 23]
Internet-Draft OSPFv3 LSA Extendibility September 2013
12.1. Extended LSA Mixed-Mode Backward Compatibility
An implementation MAY support configuration allowing a mixture of
OSPFv3 routers supporting and not supporting TLV-based LSAs in the
same OSPFv3 routing domain. In these deployments, the OSPFv3 routers
configured with a value of MixedMode or MixedModeDegraded for
ExtendedLSASupport, (Appendix A), MUST originate both the TLV-based
and non-TLV-based versions of the OSPFv3 LSAs described herein. For
the purposes of Shortest Path First (SPF) computation, if the
configured value is MixedMode, the TLV-based LSAs MUST be used by
OSPFv3 routers supporting this specification. If MixedModeDegraded
is configured, the non-TLV-based versions of the OSPFv3 LSAs are used
for SPF computation. OSPFv3 routers configured for mixed mode
operation also MUST form adjacencies with OSPFv3 Routers sending
OSPFv3 Hello and Database Description packets with the options field
EL-bit clear. In this manner, OSPFv3 routing domains utilizing the
new encodings can be gradually migrated with a worst-case cost of
approximately doubling the number of LSAs in the routing domain.
12.2. LSA TLV Processing Backward Compatibility
This section defines the general rules for processing LSA TLVs. To
ensure compatibility of future TLV-based LSA extensions, all
implementations MUST adhere to these rules:
1. Unrecognized TLVs and sub-TLVs are ignored when parsing or
processing Extended-LSAs.
2. Whether or not partial deployment of a given TLV is supported
MUST be specified.
3. If partial deployment is not supported, mechanisms to ensure the
corresponding feature are not deployed MUST be specified in the
document defining the new TLV or sub-TLV.
4. If partial deployment is supported, backward compatibility and
partial deployment MUST be specified in the document defining the
new TLV or sub-TLV.
Lindem, et al. Expires March 14, 2014 [Page 24]
Internet-Draft OSPFv3 LSA Extendibility September 2013
13. Security Considerations
In general, extendible OSPFv3 LSAs are subject to the same security
concerns as those described in RFC 5340 [OSPFV3]. Additionally,
implementations must assure that malformed TLV and Sub-TLV
permutations do not result in errors which cause hard OSPFv3
failures.
If there were ever a requirement to digitally sign OSPFv3 LSAs as
described for OSPFv2 LSAs in RFC 2154 [OSPF-DIGITAL-SIGNATURE], the
mechanisms described herein would greatly simplify the extension.
Lindem, et al. Expires March 14, 2014 [Page 25]
Internet-Draft OSPFv3 LSA Extendibility September 2013
14. IANA Considerations
This specification defines nine OSPFv3 Extended LSA types as
described in Section 2.
This specification also creates two registries OSPFv3 Extended-LSAs
TLVs and sub-TLVs. The TLV and Sub-TLV code-points in these
registries are common to all Extended-LSAs and their respective
definitions must define where they are applicable.
The OSPFv3 Extend-LSA TLV registry will define top-level TLVs for
Extended-LSAs and should be placed in the existing OSPFv3 IANA
registry. New values can be allocated via IETF Consensus or IESG
Approval.
Nine initial values are allocated:
o 0 - Reserved
o 1 - Router-Link TLV
o 2 - Attached-Routers TLV
o 3 - Inter-Area Prefix TLV
o 4 - Inter-Area Router TLV
o 5 - External Prefix TLV
o 6 - Intra-Area Prefix TLV
o 7 - IPv6 Link-Local Address TLV
o 8 - IPv4 Link-Local Address TLV
The OSPFv3 Extend-LSA sub-TLV registry will define sub-TLVs at any
level of nesting for Extended-LSAs and should be placed in the
existing OSPFv3 IANA registry. New values can be allocated via IETF
Consensus or IESG Approval.
One initial value is allocated:
o 0 - Reserved
Lindem, et al. Expires March 14, 2014 [Page 26]
Internet-Draft OSPFv3 LSA Extendibility September 2013
15. References
15.1. Normative References
[OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008.
[OSPFV3-AF]
Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R.
Aggarwal, "Support of Address Families in OSPFv3",
RFC 5838, April 2010.
[RFC-KEYWORDS]
Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering
Extensions to OSPF", RFC 3630, September 2003.
15.2. Informative References
[MT-OSPFV3]
Mirtorabi, S. and A. Roy, "Multi-topology routing in
OSPFv3 (MT-OSPFV3)", draft-ietf-ospf-mt-ospfv3-04.txt
(work in progress).
[OSPF-DIGITAL-SIGNATURE]
Murphy, S., Badger, M., and B. Wellington, "OSPF with
Digital Signatures", RFC 2154, June 1997.
Lindem, et al. Expires March 14, 2014 [Page 27]
Internet-Draft OSPFv3 LSA Extendibility September 2013
Appendix A. Configurable Constants
An additional global configurable constant 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 value for the enumeration are:
* None - Non-extended LSAs will not be originated or used in the
SPF calculation.
* Normal - Extended LSAs will be originated and adjacencies will
not be formed with OSPFv3 routers not supporting this
specification.
* MixedMode - Both extended and non-extended 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.
* MixedModeDegraded - Both extended and non-extended LSAs will be
originated. OSPFv3 adjacencies will be formed with OSPFv3
routers not supporting this specification. The non-extended
LSAs are used for the SPF computation.
Lindem, et al. Expires March 14, 2014 [Page 28]
Internet-Draft OSPFv3 LSA Extendibility September 2013
Authors' Addresses
Acee Lindem
Ericsson
301 Midenhall Way
Cary, NC 27513
USA
Email: acee.lindem@ericsson.com
Sina Mirtorabi
Cisco Systems
170 Tasman Drive
San Jose, CA 95134
USA
Email: sina@cisco.com
Abhay Roy
Cisco Systems
170 Tasman Drive
San Jose, CA 95134
USA
Email: akr@cisco.com
Fred Baker
Cisco Systems
Santa Barbara, CA 93117
USA
Email: fred@cisco.com
Lindem, et al. Expires March 14, 2014 [Page 29]
