Network Working Group                                          A. Lindem
Internet-Draft                                              S. Mirtorabi
Intended status: Standards Track                                  A. Roy
Expires: April 10, 2016                                         F. Baker
                                                           Cisco Systems
                                                         October 8, 2015


                        OSPFv3 LSA Extendibility
                draft-ietf-ospf-ospfv3-lsa-extend-08.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 LSAs.  This document extends
   the LSA format by encoding the existing OSPFv3 LSA information in
   Type-Length-Value (TLV) tuples and allowing advertisement of
   additional information with additional TLVs.  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 April 10, 2016.

Copyright Notice

   Copyright (c) 2015 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 April 10, 2016                 [Page 1]


Internet-Draft          OSPFv3 LSA Extendibility            October 2015


   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Requirements notation . . . . . . . . . . . . . . . . . .   3
     1.2.  Acknowledgments . . . . . . . . . . . . . . . . . . . . .   3
   2.  OSPFv3 Extended LSA Types . . . . . . . . . . . . . . . . . .   4
   3.  OSPFv3 Extended LSA TLVs  . . . . . . . . . . . . . . . . . .   5
     3.1.  Prefix Options Extensions . . . . . . . . . . . . . . . .   6
       3.1.1.  N-bit Prefix Option . . . . . . . . . . . . . . . . .   6
     3.2.  Router-Link TLV . . . . . . . . . . . . . . . . . . . . .   7
     3.3.  Attached-Routers TLV  . . . . . . . . . . . . . . . . . .   7
     3.4.  Inter-Area-Prefix TLV . . . . . . . . . . . . . . . . . .   9
     3.5.  Inter-Area-Router TLV . . . . . . . . . . . . . . . . . .  10
     3.6.  External-Prefix TLV . . . . . . . . . . . . . . . . . . .  11
     3.7.  Intra-Area-Prefix TLV . . . . . . . . . . . . . . . . . .  12
     3.8.  IPv6 Link-Local Address TLV . . . . . . . . . . . . . . .  13
     3.9.  IPv4 Link-Local Address TLV . . . . . . . . . . . . . . .  14
     3.10. IPv6-Forwarding-Address Sub-TLV . . . . . . . . . . . . .  15
     3.11. IPv4-Forwarding-Address Sub-TLV . . . . . . . . . . . . .  15
     3.12. Route-Tag Sub-TLV . . . . . . . . . . . . . . . . . . . .  16
   4.  OSPFv3 Extended LSAs  . . . . . . . . . . . . . . . . . . . .  16
     4.1.  OSPFv3 E-Router-LSA . . . . . . . . . . . . . . . . . . .  16
     4.2.  OSPFv3 E-Network-LSA  . . . . . . . . . . . . . . . . . .  18
     4.3.  OSPFv3 E-Inter-Area-Prefix-LSA  . . . . . . . . . . . . .  19
     4.4.  OSPFv3 E-Inter-Area-Router-LSA  . . . . . . . . . . . . .  20
     4.5.  OSPFv3 E-AS-External-LSA  . . . . . . . . . . . . . . . .  21
     4.6.  OSPFv3 E-NSSA-LSA . . . . . . . . . . . . . . . . . . . .  22
     4.7.  OSPFv3 E-Link-LSA . . . . . . . . . . . . . . . . . . . .  23
     4.8.  OSPFv3 E-Intra-Area-Prefix-LSA  . . . . . . . . . . . . .  25
   5.  Malformed OSPFv3 Extended LSA Handling  . . . . . . . . . . .  25
   6.  LSA Extension Backward Compatibility  . . . . . . . . . . . .  26
     6.1.  Extended LSA Mixed-Mode Backward Compatibility  . . . . .  28
       6.1.1.  Area Extended LSA Mixed-Mode Backward Compatibility .  28
     6.2.  Extended LSA Spare-Mode Backward Compatibility  . . . . .  29
     6.3.  LSA TLV Processing Backward Compatibility . . . . . . . .  29
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  30
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  30
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  31
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  31
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  32
   Appendix A.  Global Configuration Parameters  . . . . . . . . . .  32



Lindem, et al.           Expires April 10, 2016                 [Page 2]


Internet-Draft          OSPFv3 LSA Extendibility            October 2015


   Appendix B.  Area Configuration Parameters  . . . . . . . . . . .  33
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  34

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 LSAs.  This document
   extends the LSA format by encoding the existing OSPFv3 LSA
   information in Type-Length-Value (TLV) tuples and allowing
   advertisement of additional information with additional TLVs.
   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 LSAs 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 TLVs

   3.  Extended LSA Formats

   4.  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].




Lindem, et al.           Expires April 10, 2016                 [Page 3]


Internet-Draft          OSPFv3 LSA Extendibility            October 2015


   Thanks for Peter Psenak for significant contributions to the backward
   compatibility mechanisms.

   Thanks go to Michael Barnes, Mike Dubrovsky, Anton Smirnov, and Tony
   Przygienda for review of the draft versions and discussions of
   backward compatibility.

   Thanks to Alan Davey for review and comments including the suggestion
   to separate the extended LSA TLV definitions from the extended LSAs
   definitions.

   Thanks to David Lamparter for review and suggestions on backward
   compatibility.

   Thanks to Karsten Thomann for review and editorial comments.

   The RFC text was produced using Marshall Rose's xml2rfc tool.

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 to this mapping was to allocate a bit in the
   LS Type indicating the new LSA format.  However, this would have used
   one half the LSA function code space for the migration of the eight
   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 April 10, 2016                 [Page 4]


Internet-Draft          OSPFv3 LSA Extendibility            October 2015


3.  OSPFv3 Extended LSA TLVs

   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.  Nested TLVs are also referred to as
   sub-TLVs.  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.

   This document defines the following top-level TLV types:

   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




Lindem, et al.           Expires April 10, 2016                 [Page 5]


Internet-Draft          OSPFv3 LSA Extendibility            October 2015


   Additionally, this document defines the following sub-TLV types:

   o  0 - Reserved

   o  1 - IPv6 Forwarding Address 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
   specification should define whether the TLV or sub-TLV is required
   and the behavior when there are multiple occurances of the TLV or
   sub-TLVs.

3.1.  Prefix Options Extensions

   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
   Inter-Area-Prefix-TLVs and MAY be set in External-Prefix-TLVs when
   the advertised host IPv6 address, i.e., PrefixLength = 128, is an
   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
   stable address to be advertised without having to configure a
   separate loopback address in every OSPFv3 area.

3.1.1.  N-bit Prefix Option

   Additionally, the N-bit prefix option is defined.  The figure below
   shows the position of the N-bit in the prefix options (pending IANA
   allocation).  This corresponds to the value 0x20.

                      0  1  2  3  4  5  6  7
                    +--+--+--+--+--+--+--+--+
                    |  |  | N|DN| P| x|LA|NU|
                    +--+--+--+--+--+--+--+--+



                         The Prefix Options field

   The N-bit is set in PrefixOptions for a host address
   (PrefixLength=128) that identifies the advertising router.  While it
   is similar to the LA-bit, there are two differences.  The advertising
   router MAY choose NOT to set the N-bit even when the above conditions
   are met.  If the N-bit is set and the PrefixLength is NOT 128, the
   N-bit MUST be ignored.  Additionally, the N-bit is propagated in the
   PrefixOptions when an OSPFv3 Area Border Router (ABR) originates an



Lindem, et al.           Expires April 10, 2016                 [Page 6]


Internet-Draft          OSPFv3 LSA Extendibility            October 2015


   Inter-Area-Prefix-LSA for an Intra-Area route which has the N-bit set
   in the PrefixOptions.  Similarly, the N-bit is propagated in the
   PrefixOptions when an OSPFv3 NSSA ABR originates an Extended-AS-
   External-LSA corresponding to an NSSA route as described in section 3
   of RFC 3101 ([NSSA]).  The N-bit is to the Inter-Area-Prefix-TLV
   (Section 3.4), External-Prefix-TLV (Section 3.6), and Intra-Area-
   Prefix-TLV (Section 3.7) The N-bit is useful for applications such as
   identifying the prefixes corresponding to Node Segment Identifiers
   (SIDs) in Segment Routing [SEGMENT-ROUTING].

3.2.  Router-Link TLV

   The Router-Link TLV defines a single router link and the field
   definitions correspond directly to links in the OSPFv3 Router-LSA,
   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
   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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          1 (Router-Link)      |       TLV Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |       0       |           Metric              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Interface ID                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Neighbor Interface ID                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Neighbor Router ID                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                                                               .
      .                            sub-TLVs                           .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                              Router-Link TLV

3.3.  Attached-Routers TLV

   The Attached-Routers TLV defines all the routers attached to an
   OSPFv3 multi-access network.  The field definitions correspond
   directly to content of the OSPFv3 Network-LSA, section A.4.4,
   [OSPFV3].  The Attached-Routers TLV is only applicable to the E-
   Network-LSA (Section 4.2).  Inclusion in other Extended LSAs MUST be
   ignored.





Lindem, et al.           Expires April 10, 2016                 [Page 7]


Internet-Draft          OSPFv3 LSA Extendibility            October 2015


       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                    .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           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 the 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 that the size of the E-Network-LSA will require IPv6
   fragmentation when advertised in an OSPFv3 Link State Update packet.


























Lindem, et al.           Expires April 10, 2016                 [Page 8]


Internet-Draft          OSPFv3 LSA Extendibility            October 2015


3.4.  Inter-Area-Prefix TLV

   The Inter-Area-Prefix TLV defines a single OSPFV3 inter-area prefix.
   The field definitions correspond directly to the content of an OSPFv3
   IPv6 Prefix as defined in Section A.4.1, [OSPFV3] and an OSPFv3
   Inter-Area-Prefix-LSA, as defined in section A.4.5, [OSPFV3].
   Additionally, the PrefixOptions are extended as described in
   Section 3.1.  The Inter-Area-Prefix TLV is only applicable to the E-
   Inter-Area-Prefix-LSA (Section 4.3).  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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       3 (Inter-Area Prefix)   |       TLV Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      0        |                  Metric                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | PrefixLength  | PrefixOptions |              0                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Address Prefix                         |
      |                             ...                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                                                               .
      .                            sub-TLVs                           .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           Inter-Area Prefix TLV






















Lindem, et al.           Expires April 10, 2016                 [Page 9]


Internet-Draft          OSPFv3 LSA Extendibility            October 2015


3.5.  Inter-Area-Router TLV

   The Inter-Area-Router TLV defines a single OSPFv3 Autonomous System
   Boundary Router (ASBR) reachable in another area.  The field
   definitions correspond directly to the content of an OSPFv3 Inter-
   Area-Router-LSA, as defined in section A.4.6, [OSPFV3].  The Inter-
   Area-Router TLV is only applicable to the E-Inter-Area-Router-LSA
   (Section 4.4).  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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       4 (Inter-Area Router)   |       TLV Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      0        |                Options                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      0        |                Metric                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Destination Router ID                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                                                               .
      .                            sub-TLVs                           .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           Inter-Area Router TLV

























Lindem, et al.           Expires April 10, 2016                [Page 10]


Internet-Draft          OSPFv3 LSA Extendibility            October 2015


3.6.  External-Prefix TLV

   The External-Prefix TLV defines a single OSPFv3 external prefix.  The
   field definitions correspond directly to the content of an OSPFv3
   IPv6 Prefix as defined in Section A.4.1, [OSPFV3] and an OSPFv3 AS-
   External-LSA, as defined in section A.4.7, [OSPFV3].  The External-
   Prefix TLV is only applicable to the E-AS-External-LSA (Section 4.5)
   and the E-NSSA-LSA (Section 4.6).  Additionally, the PrefixOptions
   are extended as described in Section 3.1.  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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       5 (External Prefix)     |       TLV Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         |E| | |                Metric                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | PrefixLength  | PrefixOptions |              0                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Address Prefix                         |
      |                             ...                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                                                               .
      .                            sub-TLVs                           .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                            External Prefix TLV

   In the External-Prefix TLV, the optional IPv6/IPv4 Forwarding Address
   and External Route Tag are now sub-TLVs.  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.

   The following sub-TLVs are defined for optional inclusion in the
   External Prefix TLV:

   o  1 - IPv6 Forwarding Address sub-TLV (Section 3.10)

   o  2 - IPv4 Forwarding Address sub-TLV (Section 3.11)

   o  3 - Route Tag sub-TLV (Section 3.12)






Lindem, et al.           Expires April 10, 2016                [Page 11]


Internet-Draft          OSPFv3 LSA Extendibility            October 2015


3.7.  Intra-Area-Prefix TLV

   The Intra-Area-Prefix TLV defines a single OSPFv3 intra-area prefix.
   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-
   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
   Additionally, the PrefixOptions are extended as described in
   Section 3.1.  E-Intra-Area-Prefix-LSA (Section 4.8).  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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       6 (Intra-Area Prefix)   |       TLV Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      0        |                  Metric                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | PrefixLength  | PrefixOptions |              0                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Address Prefix                         |
      |                             ...                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                                                               .
      .                            sub-TLVs                           .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           Intra-Area Prefix TLV






















Lindem, et al.           Expires April 10, 2016                [Page 12]


Internet-Draft          OSPFv3 LSA Extendibility            October 2015


3.8.  IPv6 Link-Local Address TLV

   The IPv6 Link-Local Address TLV is to be used with IPv6 address
   families as defined in [OSPFV3-AF].  The IPv6 Link-Local Address TLV
   is only applicable to the E-Link-LSA (Section 4.7).  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

























Lindem, et al.           Expires April 10, 2016                [Page 13]


Internet-Draft          OSPFv3 LSA Extendibility            October 2015


3.9.  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 (Section 4.7).  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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  8 (IPv4 Local-Local Address) |       TLV Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             IPv4 Link-Local Interface Address                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                                                               .
      .                            sub-TLVs                           .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        IPv4 Link-Local Address TLV































Lindem, et al.           Expires April 10, 2016                [Page 14]


Internet-Draft          OSPFv3 LSA Extendibility            October 2015


3.10.  IPv6-Forwarding-Address Sub-TLV

   The IPv6 Forwarding Address TLV has identical semantics to the
   optional forwarding address in section A.4.7 of [OSPFV3].  The IPv6
   Forwarding Address TLV is applicable to the External-Prefix TLV
   (Section 3.6).  Specification as a sub-TLV of other TLVs is not
   defined herein.  The sub-TLV is 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 IPv6 Forwarding Address TLV is to be used with IPv6 address
   families as defined in [OSPFV3-AF] It MUST 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       1 - Forwarding Address  |          sub-TLV Length       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +-                                                             -+
      |                                                               |
      +-                Forwarding Address                           -+
      |                                                               |
      +-                                                             -+
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Forwarding Address Tag TLV

3.11.  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.6).  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 MUST be ignored for other
   address families.







Lindem, et al.           Expires April 10, 2016                [Page 15]


Internet-Draft          OSPFv3 LSA Extendibility            October 2015


       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.12.  Route-Tag Sub-TLV

   The optional Route Tag sub-TLV has identical semantics to the
   optional External Route Tag in section A.4.7 of [OSPFV3].  The Route
   Tag sub-TLV is applicable to the External-Prefix TLV (Section 3.6).
   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
   Route Tag as defined in [OSPFV3].  Instances subsequent to the first
   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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       3 - Route Tag           |          sub-TLV Length       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Route Tag                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                             Route Tag Sub-TLV

4.  OSPFv3 Extended LSAs

   This section specifies the OSPFv3 Extended LSA formats and encoding.
   The Extended OSPFv3 LSAs corresponded directly to the original OSPFv3
   LSAs specifed in [OSPFV3].

4.1.  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 defined in section A.4.3 of
   [OSPFV3].  However, unlike the existing Router-LSA, it is fully
   extendable and represented as TLVs.









Lindem, et al.           Expires April 10, 2016                [Page 16]


Internet-Draft          OSPFv3 LSA Extendibility            October 2015


       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.
   Initially, only the top-level Router-Link TLV Section 3.2 is
   applicable and an E-Router-LSA may include multiple Router-Link TLVs.
   Like the existing Router-LSA, the LSA length is used to determine the
   end of the LSA including TLVs.























Lindem, et al.           Expires April 10, 2016                [Page 17]


Internet-Draft          OSPFv3 LSA Extendibility            October 2015


4.2.  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 defined in section A.4.4 of
   [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.
   Like the existing Network-LSA, the LSA length is used to determine
   the end of the LSA including TLVs.  Initially, only the top-level
   Attached-Routers TLV Section 3.3 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.













Lindem, et al.           Expires April 10, 2016                [Page 18]


Internet-Draft          OSPFv3 LSA Extendibility            October 2015


4.3.  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 defined in
   section A.4.5 of [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 Inter-Area-
   Prefix-LSA.  In order to retain compatibility and semantics with the
   current OSPFv3 specification, each Inter-Area-Prefix 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.  Initially, only the top-
   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,
   it is treated as malformed as described in Section 5.  Instances of
   the Inter-Area-Prefix TLV subsequent to the first MUST be ignored.










Lindem, et al.           Expires April 10, 2016                [Page 19]


Internet-Draft          OSPFv3 LSA Extendibility            October 2015


4.4.  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-LSAE defined in
   section A.4.6 of [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.  In order to retain compatibility and semantics with the
   current OSPFv3 specification, each Inter-Area-Router 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 TLV.  Initially, only the top-
   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,
   it is treated as malformed as described in Section 5.  Instances of
   the Inter-Area-Router TLV subsequent to the first MUST be ignored.










Lindem, et al.           Expires April 10, 2016                [Page 20]


Internet-Draft          OSPFv3 LSA Extendibility            October 2015


4.5.  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 defined in section A.4.7
   of [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.  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 OSPFv3
   processes such as incremental SPF computation.

   Like the existing AS-External-LSA, the LSA length is used to
   determine the end of the LSA including sub-TLVs.  Initially, only 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
   treated as malformed as described in Section 5.  Instances of the
   External-Prefix TLV subsequent to the first MUST be ignored.










Lindem, et al.           Expires April 10, 2016                [Page 21]


Internet-Draft          OSPFv3 LSA Extendibility            October 2015


4.6.  OSPFv3 E-NSSA-LSA

   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
   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
   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 April 10, 2016                [Page 22]


Internet-Draft          OSPFv3 LSA Extendibility            October 2015


4.7.  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 defined in section A.4.9 of
   [OSPFV3].  However, unlike the existing Link-LSA, 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

   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
   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
   affords advertisement of multiple intra-area prefixes.  Hence,
   multiple Intra-Area Prefix TLVs (Section 3.7) may be specified and
   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)
   SHOULD be included in the E-Link-LSA.  Instances following the first
   MUST be ignored.  For IPv4 address families as defined in
   [OSPFV3-AF], this TLV MUST be ignored.

   Similarly, only a single instance of the IPv4 Link-Local Address TLV
   (Section 3.9) SHOULD be included in the E-Link-LSA.  Instances
   following the first MUST be ignored.  For OSPFv3 IPv6 address
   families as defined in [OSPFV3-AF], this TLV MUST be ignored.



Lindem, et al.           Expires April 10, 2016                [Page 23]


Internet-Draft          OSPFv3 LSA Extendibility            October 2015


   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
   topology information for multiple address families.  However, this is
   beyond the scope of this document.












































Lindem, et al.           Expires April 10, 2016                [Page 24]


Internet-Draft          OSPFv3 LSA Extendibility            October 2015


4.8.  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 defined in
   section A.4.10 of [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.

   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.

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



Lindem, et al.           Expires April 10, 2016                [Page 25]


Internet-Draft          OSPFv3 LSA Extendibility            October 2015


   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
   related to the capability of an OSPFv3 router to receive, process,
   and originate the TLV-based LSAs defined herein.  Unrecognized TLVs
   and sub-TLVs are ignored.  Backward compatibility for future OSPFv3
   extensions utilizing the TLV-based LSAs is out of scope and must be
   covered in the documents describing those extensions.  Both full and,
   if applicable, partial deployment SHOULD be specified for future TLV-
   based OSPFv3 LSA extensions.

   Three distinct backward compatibility modes are supported dependent
   on the OSPFv3 routing domain migration requirements.  For simplicity
   and to avoid the scaling impact of maintaining both TLV and non-TLV
   based versions of the same LSA within a routing domain, the basic
   backward compatibility mode will not allow mixing of LSA formats.
   Different LSA formats could still be supported with multiple OSPFv3
   instances and separate OSPFv3 routing domains.  Additionally, a more
   flexible mode is provided in Section 6.1, where both formats of LSA
   coexist.  In order to facilitate backward compatibility, the OSPFv3
   options field (as described in Appendix A.2 of RFC 5340 [OSPFV3]),
   will contain two additional options bits.  The EL-bits will be used
   to indicate that the OSPFv3 router's level of Extended LSA support.
   An OSPFv3 router configured to support extended LSAs MUST set its
   options field EL-bits in OSPFv3 Hello and Database Description
   packets as follows:


   B'00'
      None - Extended LSAs are not originated nor used in the SPF
      calculation (except for future functionalities as described in
      Section 6.2) .

   B'01'
      MixedModeOriginateOnly - Both extended and non-extended LSAs are
      originated.  Non-extended LSAs are used in the SPF computation.

   B'10'
      MixedModeOriginateSPF - Both extended and non-extended LSAs are
      originated.  Extended LSAs are used in the SPF computation.

   B'11'
      Full - Only extended LSAs are originated and used in the SPF
      computation.




Lindem, et al.           Expires April 10, 2016                [Page 26]


Internet-Draft          OSPFv3 LSA Extendibility            October 2015


   If Full is specified for ExtendedLSASupport, the OSPFv3 router MUST
   NOT form adjacencies with OSPFv3 Routers sending OSPFv3 Hello and
   Database Description packets with the options field EL-bits set to
   MixedModeOriginateOnly or None.  Similarly, if MixModeOriginateSPF is
   specified for ExtendedLSASupport, the OSPFv3 router MUST NOT form
   adjacencies with OSPFv3 Routers sending OSPFv3 Hello and Database
   Description packets with the options field EL-bits set to None
   (B'00').  In this manner, OSPFv3 routers using new encodings can be
   completely isolated from those OSPFv3 routers depending on the RFC
   5340 encoding and not setting their options field EL-bits since the
   default setting indicates no support for extended LSAs.

   Finally, a mode supporting existing OSPFv3 routing domains is
   provided.  This mode, subsequently referred to as "sparse-mode", will
   use the TLV-based LSAs solely in support of new functionality
   Section 6.2.  In this compatibility mode, the EL-bits will be
   advertised as B'00' since the backward compatibility with the non-
   extended LSAs is not supported or required.

                         1                      2
     0 1 2 3 4 5 6 7 8 9 0 1 2  3 4  5 6 7  8 9 0 1 2  3
    +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+-+-+--+
    | | | | | | | | | | | | EL|AT|L|AF|*|*|DC|R|N|x|E|V6|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+-+-+--+
                        The Options field

      EL-bits
        These bits indicate the level of Extended LSA support.
           B'00' - Extended LSAs are not originate nor used in the
                   SPF calculation (except for new functionalities
                   for future functions as described in Section 6.2).
           B'01' - Both extended and non-extended LSAs are originated.
                   Non-extended LSAs are used in the SPF computation.
           B'10' - Both extended and non-extended LSAs are originated.
                   Extended LSAs are used in the SPF computation.
           B'11' - Only extended LSA are originated and used in the
                   SPF computation.

                           Options Field EL-bits

   The EL-bits will also be set in the LSA options field in Extended and
   Non-Extended LSAs.  While the value of the EL-bits has no functional
   significance in the LSA options field, visibility of every OSPFv3
   Router's extended LSA support is expected to be very useful for
   management and troubleshooting during the migration period.






Lindem, et al.           Expires April 10, 2016                [Page 27]


Internet-Draft          OSPFv3 LSA Extendibility            October 2015


6.1.  Extended LSA Mixed-Mode Backward Compatibility

   An implementation MAY support configuration allowing a graceful
   transition from the non-extended (non-TLV-based) LSAs to the extended
   (TLV-based) LSAs in an OSPFv3 routing domain.  In these routing
   domains, the OSPFv3 routers configured with a value of
   MixedModeOriginateOnly or MixedModeOriginateSPF for
   ExtendedLSASupport, (Appendix A), MUST originate both the extended
   and non-extended versions of the OSPFv3 LSAs described herein.  For
   the purposes of Shortest Path First (SPF) computation, the non-
   extended OSPFv3 LSAs are used for SPF computation when
   MixedModeOriginateOnly is configured and the extended LSAs are used
   when MixedModeOriginateSPF is specified.  The extended LSAs MAY be
   used for functions other than routing computation as long as backward
   compatibility is specified in the documents specifying those
   functions.

   In this manner, OSPFv3 routing domains utilizing the new encodings
   can be gradually migrated with a worst-case overhead cost of
   approximately doubling the number of LSAs in the routing domain.  The
   transition within an OSPFv3 routing domain would progress as follows:

   1.  Configure OSPFv3 Router ExtendedLSASupport to
       MixedModeOriginateOnly so that routers originate the extended
       LSAs.

   2.  When all the OSPFv3 Routers have been reconfigured to
       MixedModeOriginateOnly, gradually reconfigure OSPFv3 Routers to
       use the extended LSAs by configuring ExtendedLSASupport to
       MixedModeOriginateSPF.  This can be done on a small subset of
       OSPFv3 Routers and the route tables can be verified.

   3.  When all the OSPFv3 Routers have been reconfigured to
       MixedModeOriginateSPF and the routing has been verified,
       reconfigure OSPFv3 Routers to purge or simply not refresh the
       non-extended OSPFv3 LSA by configuring ExtendedLSASupport to
       Full.

   In order to prevent OSPFv3 routing domain routing loops, the
   advertised metrics in the extended and non-extended OSPFv3 LSAs MUST
   be identical.

6.1.1.  Area Extended LSA Mixed-Mode Backward Compatibility

   An implementation MAY also support configuration allowing graceful
   transition from the non-extended LSAs to the extended LSAs within a
   single area.  In these areas, the parameter AreaExtendedLSASupport
   (Appendix B) may be configured to take precedence over the global



Lindem, et al.           Expires April 10, 2016                [Page 28]


Internet-Draft          OSPFv3 LSA Extendibility            October 2015


   parameter ExtendedLSASupport.  However, the AreaExtendedLSASupport
   will only apply to link and area scoped LSAs within the area and area
   based SPF calculations.  The default is for the
   AreaExtendedLSASupport to be inherited from the ExtendedLSASupport.
   The configuration of ExtendedLSASupport will apply to AS-External
   LSAs even when AreaExtendedLSASupport takes precedence.

   When preforming a graceful restart [GRACEFUL-RESTART], an OSPFv3
   router configured with MixedModeOriginate will use the 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.  Extended LSA Spare-Mode Backward Compatibility

   In this mode, OSPFv3 will use the non-extended LSAs for the SPF
   computation and will only originate extended LSAs when LSA
   origination is required in support of addtional functionality.
   Furthermore, the extended LSAs will only include those TLVs which
   require further specification for that new functionality.  Hence,
   this mode of compatibility is know as "sparse-mode".  The advantage
   of sparse-mode is that functionality utilizing the OSPFv3 extended
   LSAs can be added to an existing OSFPv3 routing domain without the
   requirement for migration.  In essence, this compatibility mode is
   very much like the approach taken for OSPFv2 [OSPF-PREFIX-LINK].  As
   with all the compatibility modes, backward compatibility for the
   functions utilizing the extended LSAs must be described in the IETF
   documents describing those functions.

6.3.  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.





Lindem, et al.           Expires April 10, 2016                [Page 29]


Internet-Draft          OSPFv3 LSA Extendibility            October 2015


   4.  If partial deployment is supported, backward compatibility and
       partial deployment MUST be specified in the document defining the
       new TLV or sub-TLV.

7.  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 that 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.

8.  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 values are allocated by this specification:

   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




Lindem, et al.           Expires April 10, 2016                [Page 30]


Internet-Draft          OSPFv3 LSA Extendibility            October 2015


   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
   Review.

   Three values are allocated by this specification:

   o  0 - Reserved

   o  1 - Forwarding Address

   o  2 - Route Tag

   The OSPFv3 Prefix Options registry will define a new code point for
   the N-bit.  The value 0x20 is suggested.

9.  References

9.1.  Normative References

   [GRACEFUL-RESTART]
              Lindem, A. and P. Pillay-Esnault, "OSPFv3 Graceful
              Restart", RFC 5187, June 2008.

   [NSSA]     Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option",
              RFC 3101, January 2003.

   [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.








Lindem, et al.           Expires April 10, 2016                [Page 31]


Internet-Draft          OSPFv3 LSA Extendibility            October 2015


9.2.  Informative References

   [MT-OSPFV3]
              Mirtorabi, S. and A. Roy, "Multi-topology routing in
              OSPFv3 (MT-OSPFV3)", draft-ietf-ospf-mt-ospfv3-03.txt
              (work in progress), January 2008.

   [OSPF-DIGITAL-SIGNATURE]
              Murphy, S., Badger, M., and B. Wellington, "OSPF with
              Digital Signatures", RFC 2154, June 1997.

   [OSPF-PREFIX-LINK]
              Psenak, P., Gredler, H., Shakir, R., Henderickx, W.,
              Tantsura, J., and A. Lindem, "OSPF Prefix/Link
              Attributes", draft-ietf-ospf-prefix-link-attr-13.txt (work
              in progress), August 2015.

   [SEGMENT-ROUTING]
              Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
              Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
              Extensions for Segment Routing", draft-ietf-ospf-segment-
              routing-extensions-05.txt (work in progress), February
              2015.

Appendix A.  Global Configuration Parameters

   An additional global configurable parameter will be added to the
   OSPFv3 protocol.


   ExtendedLSASupport
      This is an enumeration type indicating the extent to which the
      OSPFv3 instance supports the TLV format described herein for
      Extended LSAs.  The valid values for the enumeration are:


      *  None - Extended LSAs will not be originated or used in the SPF
         calculation.  This is the default.  When OSPFv3 functions
         requiring extended LSA are configured, and the
         ExtendedLSASuppport is "None", extended LSAs may be used as
         described in Section 6.2.

      *  MixedModeOriginateOnly - Both extended and 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 April 10, 2016                [Page 32]


Internet-Draft          OSPFv3 LSA Extendibility            October 2015


      *  MixedModeOriginateSPF - 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.

      *  Full - Extended LSAs will be originated and adjacencies will
         ndot be formed with OSPFv3 routers not supporting this
         specification.  Only Extended LSAs will be originated.

Appendix B.  Area Configuration Parameters

   An additional area configurable parameter will be added to the OSPFv3
   protocol.


   AreaExtendedLSASupport
      This is an enumeration type indicating the extent to which the
      OSPFv3 area supports the TLV format described herein for Extended
      LSAs.  The valid value for the enumeration are:


      *  InheritGlobal - The AreaExtendedLSASupport will be inherited
         from ExtendedLSASupport.  This is the default.

      *  None - Extended LSAs will not be originated or used in the SPF
         calculation.  This is the default.  When OSPFv3 functions
         requiring extended LSA are configured, and the
         ExtendedLSASuppport is "None", the spare-mode compatability is
         in effect Section 6.2.

      *  MixedModeOriginateOnly - Both extended and non-extended link
         and area scoped 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.

      *  MixedModeOriginateSPF - Both extended and non-extended link and
         area scoped LSAs will be originated.  OSPFv3 adjacencies will
         be formed with OSPFv3 routers not supporting this
         specification.  The extended LSAs are used for the area SPF
         computation.

      *  Full - Link and area scoped extended LSAs will be originated
         and adjacencies will not be formed with OSPFv3 routers not
         supporting this specification.  Only Extended LSAs will be
         originated.





Lindem, et al.           Expires April 10, 2016                [Page 33]


Internet-Draft          OSPFv3 LSA Extendibility            October 2015


   For regular areas, i.e., areas where AS scoped LSAs are flooded,
   configuring None or MixedModeOriginateOnly for AreaExtendedLSASupport
   when Full is specified for ExtendedLSASupport is contradictory and
   MAY be prohibited by the implementation.

Authors' Addresses

   Acee Lindem
   Cisco Systems
   301 Midenhall Way
   Cary, NC  27513
   USA

   Email: acee@cisco.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 April 10, 2016                [Page 34]