Network Working Group                                          R. Coltun
Internet Draft                                              FORE Systems
Expiration Date: December 1998                                 V. Fuller
File name: draft-ietf-ospf-nssa-update-05.txt                 BBN Planet
                                                               P. Murphy
                                                    US Geological Survey
                                                               July 1998

                          The OSPF NSSA Option

Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

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

   To learn the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).
























Coltun, Fuller, Murphy                                          [Page i]


Internet Draft              OSPF NSSA Option                   July 1998


Table Of Contents

   1.0 Abstract .................................................  1
   2.0 Overview .................................................  2
   2.1 Motivation - transit networks ............................  2
   2.2 Motivation - corporate networks ..........................  3
   2.3 Proposed Solution ........................................  4
   3.0 Implementation Details ...................................  6
   3.1 The N-bit ................................................  6
   3.2 Type-7 Address Ranges ....................................  7
   3.3 Type-7 LSAs ..............................................  7
   3.4 Originating Type-7 LSAs ..................................  8
   3.5 Calculating Type-7 AS External Routes .................... 10
   3.6 Incremental Updates ...................................... 13
   4.0 Originating Type-5 LSAs .................................. 13
   4.1 Translating Type-7 LSAs .................................. 13
   4.2 Flushing Translated Type-7 LSAs .......................... 17
   5.0 Security Considerations .................................. 17
   6.0 Acknowledgments .......................................... 20
   7.0 References ............................................... 20
   8.0 Authors' Addresses ....................................... 21
   Appendix A: Type-7 LSA Packet Format ......................... 22
   Appendix B: The Options Field ................................ 23
   Appendix C: Router-LSAs ...................................... 24
   Appendix D: Configuration Parameters ......................... 26
   Appendix E: Differences from RFC 1587 ........................ 27

1.0  Abstract

   This memo documents of an optional type of OSPF area which is
   somewhat humorously referred to as a "not-so-stubby" area (or NSSA).
   NSSAs are similar to the existing OSPF stub area configuration option
   but have the additional capability of importing AS external routes in
   a limited fashion.

   The OSPF NSSA Option was originally defined in RFC 1587.  The
   functional differences between this memo and RFC 1587 are explained
   in Appendix E. All differences, while expanding capability, are
   backward-compatible in nature. Implementations of this memo and of
   RFC 1587 will interoperate.

   Please send comments to ospf@gated.cornell.edu.









Coltun, Fuller, Murphy                                          [Page 1]


Internet Draft              OSPF NSSA Option                   July 1998


2.0  Overview

2.1  Motivation - transit networks

   Wide-area transit networks often have connections to moderately-
   complex "leaf" sites.  A leaf site may have multiple IP network
   numbers assigned to it.  Typically, one of the leaf site's networks
   is directly connected to a router provided and administered by the
   transit network while the others are distributed throughout and
   administered by the site.  From the transit network's perspective,
   all of the network numbers associated with the site make up a single
   "stub" entity.  For example, BBN Planet has one site composed of a
   class-B network, 130.57.0.0, and a class-C network, 192.31.114.0.
   From BBN Planet's perspective, this configuration looks something
   like this:

                       192.31.114
                           |
                         (cloud)
                     -------------- 130.57.4
                           |
                           |
                        ------ 131.119.13 ------
                        |BR18|------------|BR10|
                        ------            ------
                                             |
                                             V
                                     to BBN Planet "core" OSPF system

   where the "cloud" consists of the subnets of 130.57 and network
   192.31.114, all of which are learned by RIP on router BR18.
   Topologically, this cloud looks very much like an OSPF stub area.
   The advantages of running the cloud as an OSPF stub area are:

      1. Type-5 routes (OSPF external link-state advertisements (LSAs))
         are not advertised beyond the router labeled "BR10".  This is
         advantageous because the link between BR10 and BR18 may be a
         low-speed link or the router BR18 may have limited resources.

      2. The transit network is abstracted to the "leaf" router BR18 by
         advertising only a default route across the link between BR10
         and BR18.

      3. The cloud becomes a single, manageable "leaf" with respect to
         the transit network.

      4. The cloud can become, logically, a part of the transit
         network's OSPF routing system.



Coltun, Fuller, Murphy                                          [Page 2]


Internet Draft              OSPF NSSA Option                   July 1998


      5. Translated type-5 LSAs that are sent into the backbone from the
         cloud (which is a separate stub area) may be considered "leaf"
         nodes when performing the Dijkstra calculation.

   However, the current definition of the OSPF protocol [OSPF] imposes
   topological limitations which restrict simple cloud topologies from
   becoming OSPF stub areas.  In particular, it is illegal for a stub
   area to import routes external to OSPF; it is not possible for
   routers BR18 and BR10 to both be members of the stub area and to
   import the routes learned from RIP or other IP routing protocols as
   type-5 (OSPF external LSAs) into the OSPF routing domain.  In order
   to run OSPF out to BR18, BR18 must be a member of a non-stub area or
   the OSPF backbone before it can import routes other than its
   directly-connected network(s).  Since it is not acceptable for BR18
   to maintain all of BBN Planet's external (type-5) routes, BBN Planet
   is forced by OSPF's topological limitations to only run OSPF out to
   BR10 and to run RIP between BR18 and BR10.

2.2  Motivation - corporate networks

   In a corporate network which supports a large corporate
   infrastructure it is not uncommon for OSPF area 0 to have a large
   non-zero area infrastructure which injects large routing tables into
   area 0.  Organizations within the corporate infrastructure may
   routinely multi-home their non-0 OSPF areas to strategically located
   backbone area 0 routers, either to provide backbone redundancy or to
   increase backbone connectivity or both.  Because of these large
   routing tables, OSPF aggregation via summarization is routinely used
   and recommended.  Stub areas are also recommended to keep the size of
   the non-zero routing tables small.  Organizations within the
   corporation are administratively autonomous and compete for corporate
   backbone resources. They also want isolation from each other in order
   to protect their own network resources within the organization.

   Consider a typical backbone connection, as shown on the next page,
   where routers A1, B1 and A2, B2 are connected to area 1 and area 2
   respectively, and where routers A0 and B0 are border routers which
   connect to both area 1 and area 2. Assume the 192.243.192/20 and
   192.243.208/22 clouds are subnetted with a protocol foreign to the
   corporate OSPF process.  These processes could be RIP, IGRP, or
   second and third OSPF processes separate from the corporate OSPF
   backbone process.

   As a matter of policy, the corporate network administrators want
   192.243.192/20 and 192.243.208/22 aggregated to the backbone.  This
   policy conflicts with both Area 1 and Area 2's desire to see the
   subnetted infrastructures learned from Area 1's internal routers, A1
   and B1, and Area 2's internal routers, A2 and B2, aggregated in such



Coltun, Fuller, Murphy                                          [Page 3]


Internet Draft              OSPF NSSA Option                   July 1998


                  +---A0------Area 0 cloud------B0---+
                  |   |                          |   |
                  |   |                          |   |
                  |   |T1                   56kbs|   |
             56kbs|   |                          |   |T1
                  |   |                          |   |
                  |   |       Area 1 cloud       |   |
                  |   A1-----192.243.192/20-----B1   |
                  |                                  |
                  +---A2                        B2---+
                       |                         |
                       |       Area 2 cloud      |
                       +------192.243.208/22-----+


   a way that A0 and B0 can make efficient routing decisions.  The
   current standard OSPF stub area has no mechanism to support the
   redistribution of routes for 192.243.192/20 and 192.243.208/22
   subnets within their respective areas.  If one assumes that both the
   Area 1 and Area 2 clouds are extremely large with internally very
   large routing tables originating from a complex OSPF link state
   topology and subnetting scheme, neither Area 1 or Area 2 wants to be
   at the mercy of the other area's summary links advertisements or
   external links advertisements, which a standard OSPF area setting
   would force them to carry.

   Any solution to this dilemma must honor Area 1's path of choice
   through A0 with redundancy through B0 while at the same time honoring
   Area 2's path of choice through B0 with redundancy through A0.
   Furthermore, such a solution must support the aggregation of the
   externally learned subnetted routing subdomains.

2.3 Proposed Solution

   This document describes a new optional type of OSPF area, somewhat
   humorously referred to as a "not-so-stubby" area (or NSSA), which has
   the capability of importing external routes in a limited fashion.

   The OSPF specification defines two general classes of area
   configuration. The first allows type-5 LSAs to be flooded throughout
   the area.  In this configuration, type-5 LSAs may be originated by
   routers internal to the area or flooded into the area by area border
   routers.  These areas, referred to herein as type-5 capable areas (or
   just plain areas in the OSPF specification), are distinguished by the
   fact that they can carry transit traffic.  The backbone is always a
   type-5 capable area.  The second type of area configuration, called
   stub, allows no type-5 LSAs to be propagated into/throughout the area
   and instead depends on default routing to external destinations.



Coltun, Fuller, Murphy                                          [Page 4]


Internet Draft              OSPF NSSA Option                   July 1998


   NSSAs are defined in much the same manner as existing stub areas.  To
   support NSSAs, a new option bit (the "N" bit) and a new type of LSA
   (type-7) are defined.  The "N" bit ensures that routers belonging to
   a NSSA agree on its configuration.  Similar to the stub area's use of
   the "E" bit, both NSSA neighbors must agree on the setting of the "N"
   bit or the OSPF neighbor adjacency will not form.

   Type-7 LSAs provide for carrying external route information within a
   NSSA. Type-7 AS External LSAs have virtually the same syntax as the
   Type-5 AS External LSAs with the obvious exception of the link-state
   type (see section 3.2 for more details).  There are two major
   semantic differences between type-5 and type-7 LSAs.

      o Type-7 LSAs may be originated by and advertised throughout a
        NSSA; as with stub areas, type-5 LSAs are not flooded into NSSAs
        and do not originate there, except on NSSA border routers.

      o Type-7 LSAs are advertised only within a single NSSA; they are
        not flooded into the backbone area or any other area by border
        routers, though the information which they contain may be
        propagated into the backbone area (see section 3.6).

   In order to allow limited exchange of external information across a
   NSSA border, NSSA border routers will translate selected type-7 LSAs
   received from the NSSA into type-5 LSAs.  These type-5 LSAs will be
   flooded to all type-5 capable areas.  NSSA border routers may be
   configured with address ranges so that several type-7 LSAs may be
   represented by a single type-5 LSA. The NSSA border routers which
   perform translation are configurable thus creating efficient
   forwarding of type-5 LSAs originating from aggregated type-7 LSAs.

   In addition, a NSSA border router may originate a default type-7 LSA
   (IP address of 0.0.0.0) into the NSSA, and must if no NSSA internal
   type-7 default route exists.  Default routes are necessary because
   NSSAs do not receive full routing information and must have a default
   route in order to route to AS-external destinations.  Like stub
   areas, NSSAs may be connected to the backbone at more than one area
   border router, but may not be used as a transit area.  Note that the
   default route originated by a NSSA border router is never translated
   into a type-5 LSA, however, a default route originated by a NSSA
   internal AS boundary router (one that is not also an area border
   router) may be translated into a type-5 LSA.

   Like stub areas, the importing of OSPF summary routes (type-3 LSAs)
   into NSSAs is a configuration option.  However particular care should
   be taken to ensure that OSPF internal routes are always chosen over
   OSPF external (type-7) routes.  This may happen when other IGPs, like
   RIP and ISIS, leak routing information between an OSPF NSSA and



Coltun, Fuller, Murphy                                          [Page 5]


Internet Draft              OSPF NSSA Option                   July 1998


   another OSPF area.  In these cases, all OSPF summary routes should be
   imported into the effected NSSAs. The recommended default behavior is
   to import OSPF summary routes into NSSAs.

   As with standard OSPF stub areas, when summary routes are not
   imported, a type-3 summary LSA for the default route should originate
   from NSSA border routers. The type-3 summary default route insures
   intra-AS connectivity to the rest of the OSPF domain, as it takes
   precedence over any type-7 external default route which might
   originate on a NSSA internal router. This type-3 summary default
   route prevents the OSPF domain's internal traffic, which is normally
   forwarded by OSPF summary routes, from exiting the AS via any NSSA
   type-7 external default route originate by a NSSA internal router.
   Type-7 external defaults generated on NSSA internal routers and the
   no-summary option are mutually exclusive.  When summary routes are
   imported into the NSSA, only type-7 default routes (as opposed to
   type-3) originate into the NSSA from NSSA border routers.

   In our transit topology examples the subnets of 130.57 and network
   192.31.114 will still be learned by RIP on router BR18 but now both
   BR10 and BR18 can be in a NSSA and all of BBN Planet's external
   routes are hidden from BR18; BR10 becomes a NSSA border router and
   BR18 becomes an AS boundary router internal to the NSSA.  BR18 will
   import the subnets of 130.57 and network 192.31.114 as type-7 LSAs
   into the NSSA.  BR10 then translates these routes into type-5 LSAs
   and floods them into BBN Planet's backbone.

   In our corporate example, the subnets of 192.243.192/20 and
   192.243.208/22 are learned via their respective routing process,
   redistributed throughout NSSAreas 1 and 2, and then aggregated during
   the translation process into a single Type-5 LSA which is flooded
   into Area 0.  Area 1 may configure A0 to perform translation with B0
   standing by as a backup translator, while Area 2 configures B0 as its
   translator with A0 its backup.

3.0  Implementation Details

3.1  The N-bit

   The N-bit ensures that all members of a NSSA agree on the area's
   configuration.  Together, the N-bit and E-bit reflect an interface's
   (and consequently the interface's associated area) external LSA
   flooding capability.  As explained in section 10.5 of the OSPF
   specification, if type-5 LSAs are not flooded into/throughout the
   area, the E-bit must be clear in the option field of the received
   Hello packets.  Interfaces associated with a NSSA will not send or
   receive type-5 LSAs on that interface but may send and receive type-7
   LSAs.  Therefore, if the N-bit is set in the options field, the E-bit



Coltun, Fuller, Murphy                                          [Page 6]


Internet Draft              OSPF NSSA Option                   July 1998


   must be cleared.

   To support the NSSA option an additional check must be made in the
   function that handles the receiving of the Hello packet to verify
   that both the N-bit and the E-bit found in the Hello packet's option
   field match the value of the options that have been configured for
   the receiving interface.  A mismatch in the options causes processing
   of the received Hello packet to stop and the packet to be dropped.

3.2  Type-7 Address Ranges

   NSSA border routers may be configured with type-7 address ranges.
   Each address range is defined as an [address,mask] pair.  Many
   separate type-7 networks may then be represented by a single address
   range, just as a subnetted network is composed of many separate
   subnets.  NSSA border routers may then summarize type-7 routes by
   advertising a single type-5 route for each type-7 address range.  The
   type-5 route, resulting from a type-7 address range match will be
   distributed to all type-5 capable areas. Section 4.1 gives the
   details of generating type-5 routes from type-7 address ranges.

   A type-7 address range includes the following configurable items.

      o An [address,mask] pair.

      o A status indication of either Advertise or DoNotAdvertise.

      o An external route tag.

3.3  Type-7 LSAs: NSSA External Link-State Advertisements

   External routes are imported into NSSAs as type-7 LSAs by NSSA AS
   boundary routers.  A NSSA AS boundary routers (ASBR) is a router
   which has an interface associated with the NSSA and is exchanging
   routing information with routers belonging to another AS.  Like OSPF
   ASBRs, a NSSA router indicates it is a NSSA ASBR by setting the E-bit
   in its router links advertisement.  As with type-5 LSAs a separate
   type-7 LSA is originated for each destination network.  To support
   NSSAs, the link-state database must therefore be expanded to contain
   a type-7 LSA.

   Type 7-LSAs are identical to type-5 LSAs except for the following
   (see section 12.4.4 "AS external links" in the OSPF specification).

      1. The type field in the LSA header is 7.

      2. Type-7 LSAs are only flooded within the originating NSSA.  The
         flooding of type-7 LSAs follows the same rules as the flooding



Coltun, Fuller, Murphy                                          [Page 7]


Internet Draft              OSPF NSSA Option                   July 1998


         of type 1-2 LSAs.

      3. Type-7 LSAs, which are kept within the NSSA's LSDB, are area
         specific. Type-5 LSAs, which are flooded to all type-5 capable
         areas, have global scope and are kept in the router's LSDB.

      4. At the NSSA border router, selected type-7 LSAs are translated
         into type 5-LSAs and flooded into the backbone.

      5. Type 7 LSAs have a propagate (P) bit which, when set, tells a
         NSSA border router to translate the type-7 LSA into a type-5
         LSA.  Examples of how the P-bit is used for loop avoidance are
         described in section 4.1.

      6. Those type-7 LSAs that are to be translated into type-5 LSAs
         must have their forwarding address set.

   Type-5 LSAs that have been translated from type-7 LSAs normally
   contain a forwarding address.  The exception to this is if the
   translation to a type-5 LSA is the result of an address range match,
   in which case the type-5 LSA will not contain a forwarding address
   (see section 4.1 for details).  The forwarding address contained in
   type-5 LSAs will result in more efficient routing to the AS external
   networks when there are multiple NSSA border routers.  Having the
   forwarding address in the type-7 LSAs will ease the translation of
   type-7 into type-5 LSAs as the NSSA border router will not be
   required to compute the forwarding address.

   If the network between the NSSA AS boundary router and the adjacent
   AS is advertised into OSPF as an internal OSPF route, the forwarding
   address should be the next hop address as is currently done in type-5
   LSAs. Unlike type-5 LSAs if the intervening network is not advertised
   into OSPF as an internal OSPF route, the forwarding address should be
   any one of the router's active OSPF interface addresses.

   Type-5 and type-7 metrics and path types are directly comparable.

3.4 Originating Type-7 LSAs

   NSSA AS boundary routers may originate type-7 LSAs.  All NSSA border
   routers must also be AS boundary routers since they all must have the
   capability of translating type-7 LSAs into type-5 LSAs (see section
   4.1 for the translation algorithm).  NSSA border routers must set
   their E-bit (external bit) as well as their B-bit (border bit) in
   their router (type-1) LSAs (both in the backbone and in the NSSA).

   When a NSSA internal AS boundary router originates a type-7 LSA that
   it wants to be translated into a type-5 LSA by NSSA border routers



Coltun, Fuller, Murphy                                          [Page 8]


Internet Draft              OSPF NSSA Option                   July 1998


   (and subsequently flooded into the backbone), it must set the P-bit
   in the LSA header's option field and add a valid forwarding address
   in the type-7 LSA.

   If a router is attached to another AS and is also a NSSA border
   router, it may originate both a type-5 and a type-7 LSA for the same
   network.  The type-5 LSA will be flooded to the backbone (and all
   attached type-5 capable areas).  The type-7 LSA will be flooded into
   the NSSA.  If this is the case, the P-bit must be clear in the type-7
   NSSA so the type-7 LSA isn't again translated into a type-5 LSA by
   another NSSA border router.  If the border router only originates a
   type-7 LSA, it may set the P-bit, thus allowing the network to be
   aggregated/propagated during type-7 translation.

   A type-7 default route (network 0.0.0.0) may be originated into the
   NSSA by a NSSA border router or by a NSSA ASBR which is internal to
   the NSSA.  The type-7 default route originated by the NSSA border
   router must have the P-bit clear so that the default route originated
   by the NSSA border router will not find its way out of the NSSA into
   the rest of the AS via another NSSA border router. If a NSSA border
   router wishes to propagate its type-7 default route, it should simply
   originate a type-5 default route into its type-5 capable directly
   attached areas.

   The type-7 default route originated by a NSSA ASBR which is not a
   NSSA border router may have the P-bit set.  A type-7 default route
   which is originated by a NSSA border router will not get added to the
   routing tables of other NSSA border routers.  If no NSSA internal
   router originates a type-7 default route in the NSSA, then, like stub
   areas, a type-7 LSA with default destination must be originated by
   all the NSSA's border routers in order to support intra-AS routing
   and inter-AS routing.

   Note that network designors who configure a NSSA border router to
   originate a type-7 default route must also configure it to originate
   a type-5 default route before other NSSA border routers would see
   that default route (see Section 3.5, Paragraph 9). An internal type-7
   default route whose P-bit is not set may only be installed on a NSSA
   border router when it is the only non-backbone OSPF area connected to
   it.  This restriction protects the default routing of other areas
   attached to the NSSA border router as well any ISP agreements of the
   NSSArea.

   In order for backbone summary internal routes to be preferred over
   external type-7 routes, all implementations must support the optional
   import of summary LSAs from the backbone into a NSSA. If type-3
   summary LSAs are not imported into the NSSA, a type-3 summary LSA for
   the default route must be imported by NSSA border routers.  This



Coltun, Fuller, Murphy                                          [Page 9]


Internet Draft              OSPF NSSA Option                   July 1998


   protects the NSSA from routing intra-AS traffic out the AS via a
   type-7 external default route originating from an internal NSSA
   router. If summary routes are imported, NSSA border routers should
   only originate type-7 LSAs (as opposed to type-3) for the default
   destination.

   Unlike the stub area case, when summary routes are imported into the
   NSSA, a default route must not be injected into the NSSA as a summary
   (type-3). The reason for this is that the type-3 summary default
   route would be chosen over all and potentially more preferred type-7
   default routes. Note this is the exact opposite of what is
   recommended when summary routes are not imported.

3.5 Calculating Type-7 AS External Routes

   This calculation must be run when type-7 LSAs are processed during
   the AS external route calculation.  This calculation will also
   process type-5 LSAs and may replace section 16.4 when processing
   type-5 LSAs.  If section 16.4 is still used to process type-5 LSAs,
   NSSA ASBR routing table entries are not to be used for the ASBR
   address calculation of type-5 LSAs.

   A NSSA border router should examine both type-5 LSAs and type-7 LSAs
   if either type-5 or type-7 routes need to be updated or recalculated.
   This is done as part of the AS external route calculation.  A NSSA
   internal router should examine type-7 LSAs when type-7 routes need to
   be recalculated.  When OSPF Section 16.4.1 path preference is applied
   in step (6.c), NSSA and non-NSSA intra-AS paths have equal
   preference.

   What follows is only a modest modification of the OSPF Version 2
   Specification Section 16.4.  Original text is suffixed with [OSPF].
   NSSA specific text is suffixed with [NSSA].

   AS external routes are calculated by examining AS-external-LSAs, be
   they type-5 or type-7.  Each of the AS-external-LSAs is considered in
   turn. Most AS-external-LSAs describe routes to specific IP
   destinations.  An AS-external-LSA can also describe a default route
   for the Autonomous System (Destination ID = DefaultDestination,
   network/subnet mask = 0x00000000). For each AS-external-LSA [~OSPF]:

      (1) If the metric specified by the LSA is LSInfinity, or if the
          age of the LSA equals MaxAge, then examine the next LSA.
          [OSPF]

      (2) If the LSA was originated by the calculating router itself,
          examine the next LSA.  [OSPF]




Coltun, Fuller, Murphy                                         [Page 10]


Internet Draft              OSPF NSSA Option                   July 1998


      (3) Call the destination described by the LSA N.  N's address is
          obtained by masking the LSA's Link State ID with the
          network/subnet mask contained in the body of the LSA.  Look up
          the routing table entries (potentially one per attached area)
          for the AS boundary router (ASBR) that originated the LSA. If
          no entries exist for router ASBR (i.e., ASBR is unreachable),
          do nothing with this LSA and consider the next in the list.
          [OSPF]

          Else if the destination is a type-7 default route (destination
          = DefaultDestination) and one of the following is true, then
          do nothing with this LSA and consider the next in the list:

             o  The originator of the type-7 LSA and the calculating
                router are both NSSA border routers.

             o  The calculating router is a border router, the LSA has
                its P-bit clear, and at least two non-backbone OSPF
                areas connect to the calculating router. [NSSA]

          Else, this LSA describes an AS external path to destination N.
          Examine the forwarding address specified in the AS-external-
          LSA.  This indicates the IP address to which packets for the
          destination should be forwarded.  [OSPF]

          If the forwarding address is set to 0.0.0.0, packets should be
          sent to the ASBR itself.  [OSPF]

          If the current LSA is type-5, among the multiple non-NSSA ASBR
          routing table entries for the ASBR (both NSSA and non-NSSA
          ASBR entries might exists on an NSSA border router), select
          the preferred entry as follows [NSSA]:

             If RFC1583Compatibility is set to "disabled", prune the set
             of routing table entries for the ASBR as described in OSPF
             Section 16.4.1.  In any case, among the remaining routing
             table entries, select the routing table entry with the
             least cost; when there are multiple least cost routing
             table entries the entry whose associated area has the
             largest OSPF Area ID (when considered as an unsigned 32-bit
             integer) is chosen.  [OSPF]

          If the forwarding address is non-zero, look up the forwarding
          address in the routing table.  The matching routing table
          entry must specify an intra-area or inter-area path; if no
          such path exists, do nothing with the LSA and consider the
          next in the list.  [OSPF]




Coltun, Fuller, Murphy                                         [Page 11]


Internet Draft              OSPF NSSA Option                   July 1998


      (4) Let X be the cost specified by the preferred routing table
          entry for the ASBR/forwarding address, and Y the cost
          specified in the LSA.  X is in terms of the link state metric,
          and Y is a type 1 or 2 external metric.  [OSPF]

      (5) Now, look up the routing table entry for the destination N.
          If no entry exists for N, install the AS external path to N,
          with the next hop equal to the list of next hops to the
          ASBR/forwarding address, and advertising router equal to ASBR.
          If the external metric type is 1, then the path-type is set to
          Type-1 external and the cost is equal to X + Y.  If the
          external metric type is 2, the path-type is set to Type-2
          external, the link-state component of the route's cost is X,
          and the type 2 cost is Y.  [OSPF]

      (6) Otherwise compare the AS external path described by the LSA
          with the existing paths in N's routing table entry, as
          follows.  If the new path is preferred, it replaces the
          present paths in N's routing table entry.  If the new path is
          of equal preference, it is added to N's routing table entry's
          list of paths.  [OSPF]

          Preference is defined as follows:

          (a) Intra-area and inter-area paths are always preferred over
              AS external paths.  [OSPF]

          (b) Type 1 external paths are always preferred over type 2
              external paths. When all paths are type 2 external paths,
              the paths with the smallest advertised type 2 metric are
              always preferred.  [OSPF]

          (c) If the new AS external path is still indistinguishable
              from the current paths in N's routing table entry, and
              RFC1583Compatibility is set to "disabled", select the
              preferred paths based on the intra-AS paths to the
              ASBR/forwarding addresses, as specified in Section 16.4.1.
              [OSPF]

          (d) If the new AS external path is still indistinguishable
              from the current paths in N's routing table entry, select
              the preferred path based on a least cost comparison.  Type
              1 external paths are compared by looking at the sum of the
              distance to the forwarding address and the advertised type
              1 metric (X+Y).  Type 2 external paths advertising equal
              type 2 metrics are compared by looking at the distance to
              the forwarding addresses.  [OSPF]




Coltun, Fuller, Murphy                                         [Page 12]


Internet Draft              OSPF NSSA Option                   July 1998


          (e) If the new paths are still indistinguishable the following
              priorities apply (listed from highest to lowest) for
              breaking the tie.

              a. Any type-5 LSA.

              b. A type-7 LSA with the P-bit set and the forwarding
                 address non-zero.

              c. Any other type-7 LSA.  [NSSA]

3.6 Incremental Updates

   Incremental updates for type-7 LSAs should be treated the same as
   incremental updates for type-5 LSAs (see section 16.6 of the OSPF
   specification).  That is, if a new instance of a type-7 LSA is
   received it is not necessary to recalculate the entire routing table.
   If there is already an OSPF internal route to the destination
   represented by the type-7 LSA, no recalculation is necessary.

   Otherwise, the procedure in the proceeding section will have to be
   performed but only for the external routes (type-5 and type-7) whose
   networks describe the same networks as the newly received LSA.

4.0 Originating Type-5 LSAs

4.1 Translating Type-7 LSAs Into Type-5 LSAs

   This step is performed as part of the NSSA's Dijkstra calculation
   after type-5 and type-7 routes have been calculated.  If the
   calculating router is not a NSSA border router this translation
   algorithm should be skipped. It is not recommended that multiple NSSA
   border routers perform the translation unless the efficient routing
   of packets through area 0 to a NSSA partitioned by aggregation
   requires it.  It is normally sufficient to have only one NSSA border
   router perform the translation.  Excessive numbers of type-7
   translators unnecessarily increase the size of the OSPF link state
   data base.

   A new bit called bit Nt is added to the router links advertisement.
   All NSSA area border routers which are performing the translation set
   bit Nt in their router links advertisement into the NSSA.

   A new parameter called the NSSATranslateState is added to the OSPF
   area data structure.  If a NSSA border router has

                NSSATranslateState = enabled




Coltun, Fuller, Murphy                                         [Page 13]


Internet Draft              OSPF NSSA Option                   July 1998


   then this router always translates Type-7 LSAs into Type-5 LSAs for
   the NSSA.

   If a NSSA border router has

                NSSATranslateState = disabled

   and no NSSA border router for the NSSA has bit Nt set in its router
   links advertisement and this router has the highest router ID amongst
   the NSSA border router set, then this router performs the translation
   of type-7 LSAs into type-5 LSAs for the NSSA and its
   NSSATranslateState should be set to elected.

   Otherwise the translation algorithm should not be performed and
   NSSATranslateState should remain set to disabled.

   Note that during the translation of type-7 LSAs into aggregated
   type-5 LSAs, the highest router ID is not necessarily the best choice
   for an advertising router, as all packets which are forwarded by a
   type-5 LSA routing table entry originating from an aggregated type-7
   LSA translation are sent to the translator (Note, as described below,
   the forwarding address is not set in type-5 LSAs which originate from
   aggregated type-7 LSAs).  The NSSATranslateState allows the network
   designer to configure the most cost effective route to the NSSA's
   type-5 LSAs which originate from the aggregation during the
   translation of type-7 LSAs.  In cases of aggregate partitioning of
   the NSSA, multiple translators may be required to effect efficient
   routing. Indeed, all NSSA border routers could be set to perform
   translation, if required.

   All installed type-7 LSA's should be examined including those type-7s
   originated by the router itself (a set which may differ between NSSA
   border routers of the same NSSArea).  This allows NSSA border routers
   to propagate and/or aggregate locally originated type-7s during the
   translation.  Locally originated type-7s are skipped during the
   external route calculation.  Their installation status is external to
   OSPF.

   If the type-7 LSA (associated with the route being examined) has the
   P-bit set and a non-zero forwarding address, then the translation
   procedure is performed. It first checks for a configured type-7
   address range.  Recall that a type-7 address range consists of an
   [address,mask] pair and a status indication of either Advertise or
   DoNotAdvertise.  At most a single type-5 LSA is made for each range.
   If the route being examined falls within the type-7 address range,
   (i.e., the [address,mask] pair of the route is equal to or a more
   specific instance of the [address,mask] pair of the type-7 address
   range), one of following three actions may take place.



Coltun, Fuller, Murphy                                         [Page 14]


Internet Draft              OSPF NSSA Option                   July 1998


      1. When the range's status indicates Advertise and the route's
         address and mask are equal to the address and mask of the
         type-7 range, a type-5 LSA should be originated if

            o there currently is no type-5 LSA originated from this
              router corresponding to the type-7 LSA, or there is and

            o the path type or the metric in the corresponding type-5
              LSA is different from the type-7 LSA or

            o the forwarding address in the corresponding type-5 LSA is
              different from the type-7 LSA.

         The newly originated type-5 LSA will describe the same network
         and have the same network mask, metrics, forwarding address,
         external route tag and path type as the type-7 LSA, however,
         the advertising router field will be the router ID of this area
         border router.

      2. When the range's status indicates Advertise and the route's
         address or mask indicates a more specific route (i.e., the
         route's address is subsumed by the range or the route has a
         longer mask), a type-5 LSA is generated with link-state ID
         equal to the range's address (if necessary, the link-state ID
         can also have one or more of the range's "host" bits set; see
         Appendix F of the OSPF specification for details), the network
         mask, external route tag and path type will be set to the
         configured type-7 range values.  The advertising router field
         will be the router ID of this area border router. The
         forwarding address will not be set.  The path type should
         always be set to the highest path type that is subsumed by the
         net range.  The metric for the type-5 LSA will be set as
         follows:

            o if the path type is external type 2, the type-5
              metric should be set to the largest type-7 metric
              subsumed by this net range + 1.

            o if the path type is external type 1, the type-5
              metric should be set to the largest metric.

         For example, given a net range of [10.0.0.0, 255.0.0.0]
         for an area that has type-7 routes of:

                 10.1.0.0 path type 1, metric 10
                 10.2.0.0 path type 1, metric 11
                 10.3.0.0 path type 2, metric 5




Coltun, Fuller, Murphy                                         [Page 15]


Internet Draft              OSPF NSSA Option                   July 1998


         a type-5 LSA will be generated with a path type of 2 and a
         metric of 6.

         Given a net range of [10.0.0.0, 255.0.0.0] for an area
         that has type-7 routes of:

                 10.1.0.0 path type 1, metric 10
                 10.2.0.0 path type 1, metric 11
                 10.3.0.0 path type 1, metric 5

         a type-5 LSA will be generated with a path type of 1 and a
         metric of 11.

         These metric and path type rules will avoid routing loops
         in the event that path type 1 and 2 are both used within
         the area.

      3. When the range's status indicates DoNotAdvertise, the
         type-5 LSA is suppressed and the component networks remain
         hidden from the rest of the AS.

   By default (given that the P-bit is set and the LSA has a non-
   zero forwarding address) if a network is not contained in any
   explicitly configured address range, a type-7 to type-5 LSA
   translation will occur.

   A new instance of a type-5 LSA should be originated and flooded
   to all attached type-5 capable areas if

      o there currently is no type-5 LSA originated from this
        router corresponding to the type-7 LSA, or there is and

      o the path type or the metric in the corresponding type-5 LSA
        is different from the type-7 LSA or

      o the forwarding address in the corresponding type-5 LSA is
        different from the type-7 LSA.

   The newly originated type-5 LSAs will describe the same network
   and have the same network mask, metrics, forwarding address,
   external route tag and path type as the type-7 LSA.  The
   advertising router field will be the router ID of this area
   border router.

   As with all newly originated type-5 LSAs, a type-5 LSA that is
   the result of a type-7 to type-5 translation (type-7 range or
   default case) is flooded to all attached type-5 capable areas.




Coltun, Fuller, Murphy                                         [Page 16]


Internet Draft              OSPF NSSA Option                   July 1998


4.2 Flushing Translated Type-7 LSAs

   If a NSSA border router has translated a type-7 LSA to a type-5
   LSA that should no longer be translated, the type-5 LSA should
   be flushed (set to MaxAge and flooded).  The translated type-5
   LSA should be flushed whenever the routing table entry that
   caused the translation changes so that either the routing table
   entry is unreachable or the entry's associated LSA is not a
   type-7 with the P-bit set and a non-zero forwarding address.

   If a NSSA border router is translating type-7 LSA's into type-5
   LSA's and

                NSSATranslateState = elected

   and a new router links advertisement arrives in the NSSA with
   bit Nt set, then it should flush any of its type-5 LSAs
   originating from translated type-7 LSAs and readvertise its
   router links advertisement into the NSSA with bit Nt clear.

   This flushing keeps the number of type-7 translators at the
   minimum number configured, either explicitly or by default.
   Since the default translator election process only occurs in the
   absence of a translator, should a router with a higher router ID
   join the NSSA border router set it will not necessarily assume
   translator duties.  Indeed, a previously default elected
   translator should continue to perform translation duties until
   supplanted by a NSSA border router whose Nt bit is set to true.
   Such an event might be triggered by the manual setting of the
   NSSATranslateState to enabled or a topological rejoining of a
   partitioned NSSA.  This behavior reduces the flushing of
   translated type-7 LSA's in the AS.

   Any change in the membership of the NSSA border router set or
   the setting of their Nt bits resulting from updated router links
   advertisements should force a NSSA border router whose
   NSSATranslateState is not set to recheck and possibly elect or
   disable its type-7 translation status.

5.0 Security Considerations

   There are two types of issues that need be addressed when
   looking at protecting routing protocols from misconfigurations
   and malicious attacks. The first is authentication and
   certification of routing protocol information.  The second is
   denial of service attacks resulting from repetitive origination
   of the same router advertisement or origination of a large
   number of distinct advertisements resulting in database



Coltun, Fuller, Murphy                                         [Page 17]


Internet Draft              OSPF NSSA Option                   July 1998


   overflow. Note that both of these concerns exist independently
   of a router's support for the NSSA option.

   The OSPF protocol addresses authentication concerns by
   authenticating OSPF protocol exchanges.  OSPF supports multiple
   types of authentication; the type of authentication in use can
   be configured on a per network segment basis.  One of OSPF's
   authentication types, namely the Cryptographic authentication
   option, is believed to be secure against passive attacks and
   provides significant protection against active attacks.  When
   using the Cryptographic authentication option, each router
   appends a "message digest" to its transmitted OSPF packets.
   Receivers then use the shared secret key and the received digest
   to verify that each received OSPF packet is authentic.

   The quality of the security provided by the Cryptographic
   authentication option depends completely on the strength of the
   message digest algorithm (MD5 is currently the only message
   digest algorithm specified), the strength of the key being used,
   and the correct implementation of the security mechanism in all
   communicating OSPF implementations.  It also requires that all
   parties maintain the secrecy of the shared secret key.  None of
   the standard OSPF authentication types provide confidentiality.
   Nor do they protect against traffic analysis.  For more
   information on the standard OSPF security mechanisms, see
   Sections 8.1, 8.2, and Appendix D of [OSPF].

   [DIGI] describes the extensions to OSPF required to add digital
   signature authentication to Link State data and to provide a
   certification mechanism for router data.  [DIGI] also describes
   the added LSA processing and key management as well as a method
   for migration from or co-existence with standard OSPF V2.

   Repetitive origination of advertisements are addressed by OSPF
   by mandating a limit on the frequency that new instances of any
   particular LSA can be originated and accepted during the
   flooding procedure.  The frequency at which new LSA instances
   may be originated is set equal to once every MinLSInterval
   seconds, whose value is 5 seconds (see Section 12.4 of [OSPF]).
   The frequency at which new LSA instances are accepted during
   flooding is once every MinLSArrival seconds, whose value is set
   to 1 (see Section 13, Appendix B and G.5 of [OSPF]).

   Proper operation of the OSPF protocol requires that all OSPF
   routers maintain an identical copy of the OSPF link state
   database.  However, when the size of the link state database
   becomes very large, some routers may be unable to keep the
   entire database due to resource shortages; this is termed



Coltun, Fuller, Murphy                                         [Page 18]


Internet Draft              OSPF NSSA Option                   July 1998


   "database overflow".  When database overflow is anticipated, the
   routers with limited resources can be accommodated by
   configuring OSPF stub areas and NSSAs.  [OVERFLOW] details a way
   of gracefully handling unanticipated database overflows.















































Coltun, Fuller, Murphy                                         [Page 19]


Internet Draft              OSPF NSSA Option                   July 1998


6.0 Acknowledgments

   This document was produced by the OSPF Working Group, chaired by
   John Moy.

   In addition, the comments of the following individuals are also
   acknowledged:

                  Phani Jajjarvarpu  cisco
                  Dino Farinacci     cisco
                  Jeff Honig         Cornell University
                  John Moy           Proteon, Inc.
                  Doug Williams      IBM

7.0 References

   [DIGI] S. Murphy, M. Badger, B. Wellington, "OSPF with Digital
      Signatures", RFC 2154, Trusted Information Systems, June
      1997.

   [MUEX] Moy, J., "Multicast Extensions to OSPF", RFC 1584,
      Proteon, Inc., Proteon, Inc., March 1994.

   [OSPF] Moy, J., "OSPF Version 2", RFC 2328, Cascade
      Communications Corp., April 1998.

   [OVERFLOW] Moy, J., "OSPF Database Overflow", RFC 1765, Cascade,
      March 1995.























Coltun, Fuller, Murphy                                         [Page 20]


Internet Draft              OSPF NSSA Option                   July 1998


8.0 Authors' Addresses

      This update uses much of the original text from RFC 1587 authored by

      Rob Coltun
      Fore Systems
      1595 Sprint Hill Road,
      5th Floor
      Vienna, VA 22182

      Phone: (703) 245-4543
      EMail: rcoltun@fore.com


      Vince Fuller
      GTE Internetworking
      3801 East Bayshore Road
      Palo Alto, California 94303

      Phone: (415) 528-7227
      EMail: vaf@BBNPlanet.com


      New sections, edits and revisions have been added by

      Pat Murphy
      US Geological Survey
      345 Middlefield Road
      Menlo Park, California 94560

      Phone: (415) 329-4044
      EMail: pmurphy@noc.doi.net



















Coltun, Fuller, Murphy                                         [Page 21]


Internet Draft              OSPF NSSA Option                   July 1998


Appendix A: Type-7 Packet Format

          0                                32
          -----------------------------------
          |                | OPTS   |   7   |
          |                ------------------
          |        Link-State Header        |
          |                                 |
          -----------------------------------
          | Network Mask                    |
          -----------------------------------  ______
          |E| Tos  |        metric          |  .
          -----------------------------------  .  repeated for each TOS
          | Forwarding Address              |  .
          -----------------------------------  .
          | External Route Tag              |  ______
          -----------------------------------

   The definitions of the link-state ID, network mask, metrics and
   external route tag are the same as the definitions for the
   type-5 LSAs (see A.4.5 in the OSPF specification) except for the
   forwarding address. If the network between the NSSA AS boundary
   router and the adjacent AS is advertised into OSPF as an
   internal OSPF route, the forwarding address should be the next
   hop address but if the intervening network is not advertised
   into OSPF as an internal OSPF route, the forwarding address
   should be any one of the router's active OSPF interface
   addresses.























Coltun, Fuller, Murphy                                         [Page 22]


Internet Draft              OSPF NSSA Option                   July 1998


Appendix B: The Options Field

   The OSPF options field is present in OSPF Hello packets,
   Database Description packets and all link-state advertisements.
   See appendix A.2 in the OSPF specification for a description of
   the options field.  Six bits are assigned but only two (the E-
   bit and the N/P bit) are described completely in this section.

                   --------------------------------------
                   | * | * | DC | EA | N/P | MC | E | T |
                   --------------------------------------

                       The Type-7 LSA options field

      E-bit:  Type-5 AS external link advertisements are not
              flooded into/through OSPF stub areas and NSSAs. The
              E-bit ensures that all members of a stub area agree
              on that area configuration.  The E-bit is meaningful
              only in OSPF Hello packets.  When the E-bit is clear
              in the Hello packet sent out a particular interface,
              it means that the router will neither send nor
              receive type-5 AS external link state advertisements
              on that interface (in other words, the interface
              connects to a stub area or NSSArea).  Two routers
              will not become neighbors unless they agree on the
              state of the E-bit.

      N-bit:  The N-bit describes the router's NSSArea capability.
              The N-bit is used only in Hello packets and ensures
              that all members of a NSSArea agree on that area's
              configuration.  When the N-bit is set in the Hello
              packet and sent out a particular interface, it means
              that the router will send and receive type-7 LSAs on
              that interface.  Two routers will not form an
              adjacency unless they agree on the state of the N-
              bit.  If the N-bit is set in the options field, the
              E-bit must be clear.

      P-bit:  The P-bit is used only in the type-7 LSA header. It
              flags the NSSA border router to translate the type-7
              LSA into a type-5 LSA. The default setting for the
              P-bit is off.









Coltun, Fuller, Murphy                                         [Page 23]


Internet Draft              OSPF NSSA Option                   July 1998


Appendix C: Router-LSAs

   Router-LSAs are the Type 1 LSAs.  Each router in an area
   originates a router-LSA. The LSA describes the state and cost of
   the router's links (i.e., interfaces) to the area. All of the
   router's links to the area must be described in a single
   router-LSA. For details concerning the construction of router-
   LSAs, see the OSPF Specification, Section 12.4.1.

        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             |     Options   |       1       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Link State ID                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Advertising Router                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     LS sequence number                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         LS checksum           |             length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  0  Nt|W|V|E|B|        0      |            # links            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Link ID                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Link Data                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Type      |     # TOS     |        TOS 0 metric           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      TOS      |        0      |            metric             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              ...                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      TOS      |        0      |            metric             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Link ID                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Link Data                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              ...                              |

   In router-LSAs, the Link State ID field is set to the router's
   OSPF Router ID.  The T-bit is set in the LSA's Option field if
   and only if the router is able to calculate a separate set of
   routes for each IP TOS.  Router-LSAs are flooded throughout a
   single area only.




Coltun, Fuller, Murphy                                         [Page 24]


Internet Draft              OSPF NSSA Option                   July 1998


      bit V
          When set, the router is an endpoint of one or more fully
          adjacent virtual links having the described area as
          Transit area (V is for virtual link endpoint).

      bit E
          When set, the router is an AS boundary router (E is for
          external).

      bit B
          When set, the router is an area border router (B is for
          border).

      bit W
          When set, the router is a wild-card multicast receiver (W
          is for for wild).

      bit Nt
          When set, the router is a NSSA border router which
          translates type-7 LSAs into type-5 LSAs (Nt is for NSSA
          translation).

   The remainder of the router links specification is as defined in
   the OSPF Specification, Section A.4.2.



























Coltun, Fuller, Murphy                                         [Page 25]


Internet Draft              OSPF NSSA Option                   July 1998


Appendix D:  Configuration Parameters

   Appendix C.2 in the OSPF specification lists the area
   parameters.  The area ID, list of address ranges for type-3
   summary routes and authentication type remain unchanged.
   Section 3.2 of this document lists the configuration parameters
   for type-7 address ranges.  The following parameter is added to
   the NSSArea data structure:

       NSSATranslateState

       This parameter indicates whether or not an NSSA Border
       router is performing NSSA translation of type-7 LSAs into
       type-5 LSAs and flooding the translated type-5 LSAs into the
       AS.  If the parameter is set to "enabled", translation is
       always performed.  If the parameter is set to "elected", it
       means translation is being performed because the router was
       chosen during the default election process. If the parameter
       is set to "disabled" the NSSA border router is not currently
       performing type-7 translation.  "disabled" is the default
       setting.  (See Section 4.1.)

   For NSSAs the external capabilities of the area must be set to
   accept type-7 external routes.  Additionally there must be a way
   of configuring a NSSA border router to send a default route into
   the NSSArea using a designer specified metric type (type 1 or
   type 2) and the actual cost.
























Coltun, Fuller, Murphy                                         [Page 26]


Internet Draft              OSPF NSSA Option                   July 1998


Appendix E: Differences from RFC 1587

   This section documents the differences between this memo and RFC
   1587.  All differences are backward-compatible.  Implementations
   of this memo and of RFC 1587 will interoperate.

   E.1 Enhancements to OSPF summary LSAs.                      .

       The flooding of backbone summary LSAs (type-3 LSAs) into the
       NSSA is now optional.  In RFC 1587 the flooding of backbone
       summary LSAs was mandated in order to guarantee inter-area
       routes are preferred over external routes. The current
       recommended default behavior is to flood summary LSAs. When
       summary routes are not imported a type-3 summary default
       route (as opposed to type-7) should be originated into the
       NSSA.

       See sections 2.2 and 3.4 for details.

   E.2 Changes to the type-7 AS external routing calculation.

       The type-7 external route calculation has been revised.
       Most notably:

          o The path preference defined in OSPF Section 16.4.1 has
            been included.

          o A type-7 default route with the P-bit clear will not be
            installed on a NSSA border router which connects
            multiple non-backbone areas.  This protects the default
            routing of other OSPF Areas as well as any ISP
            agreements of the originating NSSArea.

          o The type-7 AS external route calculation may now
            compute type-5 external paths.

       See Section 3.5 for details.

   E.3 Changes to translating type-7 LSAs into type-5 LSAs

       NSSA border routers which perform the translation are now
       optionally configurable, with more than one allowed.  This
       allows the network designer to choose the most cost
       effective intra-AS route for NSSA type-7 aggregates
       propagated into the AS.  Furthermore, since different NSSA
       border routers may install different sets of type-7 LSA
       routes, the cost effectiveness of non-aggregated type-7
       propagation may also be maximized.



Coltun, Fuller, Murphy                                         [Page 27]


Internet Draft              OSPF NSSA Option                   July 1998


       All installed type-7 LSA's plus those originated by the NSSA
       border router are processed for translation.  This allows
       the NSSA border router to propagate and/or aggregate locally
       originated type-7s utilizing the type-5 translation process.
       NSSA RFC 1587 required locally originated type-7 LSAs be
       paired with locally originated type-5 LSAs for the external
       path to be seen by the AS (Note that locally originated
       type-7s are skipped during the external route calculation).

       The default translator election process occurs only in the
       absence of a translator amongst the NSSA border router set.

       See Section 4.1 for details.

   E.4 Changes to flushing translated type-7 LSAs

       A NSSA border router which was elected by the default
       selection process of RFC 1587, terminates its translation
       duties and flushes its translated type-7 LSAs from the AS
       when a configured translator presents itself in the NSSA.
       This keeps the number of translators at a minimum.

       See Section 4.2 for details.




























Coltun, Fuller, Murphy                                         [Page 28]