Network Working Group                                          P. Murphy
Internet Draft                                      US Geological Survey
Expiration Date: November 2001                                  May 2001
File name: draft-ietf-ospf-5to7-00.txt


                   OSPF Type 5 to Type 7 Translation

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

























Murphy             OSPF Type 5 to Type 7 Translation            [Page i]


Internet Draft                                                  May 2001


Table Of Contents

   1.0 Abstract .................................................  1
   2.0 Overview .................................................  2
   2.1 Motivation - Corporate Networks ..........................  2
   2.2 Proposed Solution ........................................  2
   3.0 Type 5 Translation Implementation Details ................  3
   3.1 Type 5 Address Ranges ....................................  3
   3.2 Setting the N/P-bit in the Options field of Router-LSAs...  4
   3.3 Calculating Type 7 LSAs as External Routes ...............  4
   3.4 Type 5 Translator Election ...............................  4
   4.0 Originating Translated Type 5 LSAs .......................  5
   4.1 Translating Type 5 LSAs into Type 7 LSAs .................  5
   4.2 Flushing Translated Type 7 LSAs ..........................  8
   5.0 Security Considerations ..................................  8
   6.0 Acknowledgments ..........................................  9
   7.0 References ...............................................  9
   8.0 Author's Address .........................................  9


1.0  Abstract

   This memo documents an extension to OSPF which allows area border
   routers to translate Type 5 LSAs into Type 7 LSAs with aggregation.
   Type 7 LSAs, which are translations of Type 5 LSAs, are flooded into
   Not-So-Stubby areas (NSSAs).  All differences, while expanding
   capability, are backward compatible in nature.  NSSA Border routers
   which run implementations of this memo will interoperate with other
   NSSA routers which do not.  This option is only applicable on a
   border router with at least one directly attached NSSA.

   Please send comments to ospf@discuss.microsoft.com.



















Murphy             OSPF Type 5 to Type 7 Translation            [Page 1]


Internet Draft                                                  May 2001


2.0  Overview

2.1  Motivation - Corporate Networks

   In a corporate network which supports a large corporate
   infrastructure it is not uncommon for an OSPF NSSA to support its own
   internal Internet default.  Other areas may have external links to
   outside collaborators.  While Type 5 LSAs advertise the existence of
   these collaborations throughout the OSPF transit topology, NSSAs with
   their own internal default cannot take advantage of these
   collaborations since Type 5 LSAs are not flooded into NSSAs.
   Consider the following example:

                      A0------Area 0 cloud------B0
                      |                          |
                      |                          |
                 Area 2 cloud               NSSA 1 cloud
                      |                          |
                      |                          |
                      A2                        B1
                      |                          |
                      |                          |
                      E2                        E1
                      |                          |
                      |                          |
                 -----------                Internet Default
                 10.0.13.0/24

   where A0 and B0 are area 0 border routers attached to Area 2 and NSSA
   1 respectively.  A2 and B1 are ASBRs.  A2 advertises a route to
   10.0.13.0 through E2 while B1 advertises a preferred Type 7 NSSA
   internal default through E1.  Since NSSAs do not import Type 5 LSAs,
   NSSA 1 has no knowledge of the path through Area 2 to 10.0.13.0/24
   and would instead choose to forward traffic destined to 10.0.13.0/24
   to its Internet default through E1.

   What is needed is a means of advertising the 10.0.13.0/24 path
   through Area 2 into NSSA 1 without converting NSSA 1 to an OSPF
   standard area and incurring the full import of all Type 5 LSAs into
   NSSA 1.  Currently no such feature exists in OSPF.

2.2 Proposed Solution

   NSSAs support external routing via Type 7 LSAs.  Type 7 LSAs may be
   flooded into the larger OSPF domain by translating them into Type 5
   LSAs with optional aggregation.  The proposed solution to the problem
   discussed in Section 2.1 is to enable area border routers to have the
   optional capability of translating Type 5 LSAs into Type 7 LSAs and



Murphy             OSPF Type 5 to Type 7 Translation            [Page 2]


Internet Draft                                                  May 2001


   then flooding these Type 7 LSAs into their directly attached NSSAs.
   Type 5 LSA translations are configured separately for each directly
   attached NSSA as well as what, if any, aggregation is performed.

   The P-bit of a Type 7 LSA translation of a Type 5 LSA is always clear
   so that these translations are never re-translated back into type 5
   LSAs by other NSSA border routers.  As with the translation of Type 7
   LSAs into Type 5 LSAs, when the result of translating a Type 5 LSA
   into a Type 7 LSA is a true aggregation, the forwarding address is
   set to 0.0.0.0.  Furthermore, when the import of summary routes into
   the NSSA is disabled, the forwarding addresses of Type 7 LSA
   translations are also 0.0.0.0, since, in this case, the use of non-
   zero forwarding addresses would cause the installation failure of
   these translations (See the last paragraph of [NSSA] Section 3.5 Step
   (3)).

3.0  Type 5 Translation Implementation Details

3.1  Type 5 Address Ranges

   Area border routers may be configured with Type 5 address ranges for
   each NSSA.  Type 5 address ranges are area specific.  Each address
   range is defined as an [address,mask] pair.  Many separate Type 5 LSA
   networks may fall into a single Type 5 address range, just as a
   subnetted network is composed of many separate subnets.  NSSA border
   routers may aggregate Type 5 routes by advertising into the NSSA a
   single Type 7 LSA for each Type 5 address range. Any Type 5 LSA
   translation resulting from a Type 5 address range match will only be
   flooded into the NSSA for which the Type 5 address range is
   configured.  Section 4.1 gives the details of generating Type 7 LSAs
   from Type 5 address ranges.

   A Type 5 address range includes the following configurable items.

      o An [address,mask] pair,

      o a status indication of either Advertise or DoNotAdvertise,

      o a status indication of either Aggregate or DoNotAggregate, and

      o an external route tag.

   Any Type 5 LSA which is not contained in a configured Type 5 address
   range of a directly attached NSSA is not translated into a Type 7
   LSA. This prevents the uncontrolled injection of external routing
   information into NSSAs.





Murphy             OSPF Type 5 to Type 7 Translation            [Page 3]


Internet Draft                                                  May 2001


3.2 Setting the N/P-bit in the Options field of Router-LSAs

   NSSA routers as described in [NSSA] expect a Type 7 LSA's non-zero
   forwarding address to have an [NSSA] intra-area path.  Type 7 LSA's
   which are translations of Type 5 LSAs have a non-zero forwarding
   address with an inter-area path.  Section A.2 of [OSPF] implies that
   the N/P-bit of the router-LSA's Option field of an NSSA router should
   be set by default.  This memo requires that NSSA routers implementing
   this option should clear the N/P-bit in their router-LSA's Options
   field.  NSSA border routers should never translate Type 5 LSAs into
   Type 7 LSAs with non-zero forwarding addresses unless all of the
   NSSA's router-LSAs have a clear N/P-bit.

3.3 Calculating Type 7 LSAs as External Routes

   The Type 7 LSA External Route calculation discussed in [NSSA] Section
   3.5 needs only a minor change to support the translation of Type 5
   LSAs into Type 7 LSAs.  In the last paragraph of [NSSA] Section 3.5
   Step (3) the non-zero forwarding address of a Type 7 LSA should have
   an intra-area path with next-hop through the originating NSSA.  The
   non-zero forwarding addresses of Type 5 LSAs, as well as their Type 7
   translations, are normally external to an NSSA.  In Section 3.5 Step
   (3), if all of the NSSA's router-LSAs have a clear N/P-bit in their
   Options field, then non-zero forwarding addresses of Type 7 LSAs
   which originate from one of the NSSA's border routers must be allowed
   to have inter-area paths with next-hop through the originating NSSA.
   Otherwise they should ignore these LSAs.

   Even with the above change, the Type 7 AS external route calculation
   of a Type 5 LSA translation with a non-zero forwarding address fails
   on NSSA border routers in the last paragraph of Section 3.5 Step (3)
   allowing the Type 5 LSA from which it was translated to be preferred.
   However, since Type 5 LSAs must choose their preferred paths through
   the transit topology as discussed in [NSSA] Section 3.5 Step (3),
   their Type 7 LSA translations which have a 0.0.0.0 forwarding address
   and Type-1 metric may offer a more preferred path through the
   originating NSSA.

3.4 Type 5 Translator Election

   It may be desirable to have only one Type 5 border router translator.
   For the sake of simplicity this specification combines the duties of
   translating Type 5 LSAs into Type 7 LSAs with the duties of
   translating Type 7 LSAs into Type 5 LSAs.  Any configured or elected
   translator of Type 7 LSAs into Type 5 LSAs will also translate Type 5
   LSAs into Type 7 LSAs.  There are no other NSSA border router
   translators.




Murphy             OSPF Type 5 to Type 7 Translation            [Page 4]


Internet Draft                                                  May 2001


4.0 Originating Translated Type 5 LSAs

4.1 Translating Type 5 LSAs into Type 7 LSAs

   This step is performed as part of the NSSA's Dijkstra calculation
   after Type 5 routes and Type 7 routes have been calculated.  It is
   performed for each attached NSSA.  If the calculating router is
   currently not an NSSA border router translator, then this translation
   algorithm should be skipped.  Only installed Type 5 LSAs and locally
   originated Type 5 LSAs are eligible to be translated.  When computing
   the metric of a Type 7 translation of an installed type 5 LSA, its
   link state cost is found in the Type 5 LSA's routing table entry. In
   the case of a locally originated Type 5 LSA the link state cost of
   its Type 7 translation is externally defined.  A Type 5 range which
   contains a Type 5 LSA best matches the LSA when the range's
   [address,mask] pair is more specific than the [address,mask] pairs of
   other Type 5 ranges which contain the LSA's network.

   When a Type 5 LSA is translated without aggregation (See Step (2)
   below), its Type 7 LSA translation uses the Type 5 LSA's non-zero
   forwarding address and metrics provided the following two conditions
   are met:

      o summary routes are imported,

      o all of the NSSA's router-LSAs have the N/P bit clear in the
        router-LSA's Options field.

   Otherwise the Type 7 LSA's forwarding address must be 0.0.0.0 and its
   metrics are recomputed using the originating NSSA router as the
   source (See below).

   For each translation eligible Type 5 LSA perform the following for
   each directly attached NSSA:

      (1) If the Type 5 range which best matches the Type 5 LSA's
          network has DoNotAdvertise status or if the LSA is not
          contained in any explicitly configured Type 5 address range
          then do nothing with this Type 5 LSA and consider the next one
          in the list.  Otherwise term the LSA as translatable and
          proceed with step (2).

      (2) If the Type 5 range which best matches the Type 5 LSA's
          network has DoNotAggregate status and the translated Type 5
          would have a 0.0.0.0 forwarding address or the calculating
          router has the highest router ID amongst NSSA translators
          which have originated a functionally equivalent Type 7 LSA
          (i.e. same destination, cost and non-zero forwarding address)



Murphy             OSPF Type 5 to Type 7 Translation            [Page 5]


Internet Draft                                                  May 2001


          and which are reachable over area 0, then a Type 7 LSA should
          be generated with the appropriate forwarding address (See
          above) provided there currently is no Type 7 LSA originating
          from this router corresponding to the Type 5 LSA's network or
          there is an existing Type 7 LSA and either it corresponds to a
          local OSPF external source whose path type and metric is less
          preferred (see [NSSA] Section 3.5 step (6)) or it doesn't and
          the Type 7 LSA's path type or cost(s) have changed (See [NSSA]
          Section 3.5 step (5)), or its non-zero forwarding address is
          no longer reachable or its usage status of a non-zero
          forwarding address has changed (See above).

          The newly originated Type 7 LSA will describe the same network
          and have the same network mask, path type and external route
          tag as the Type 5 LSA.  The advertising router field will be
          the router ID of this NSSA border router.  The P-bit will be
          clear.  If the Type 7 LSA's forwarding address will be non-
          zero the newly originated Type 7 LSA will have the same metric
          as the Type 5 LSA. Otherwise the metric is set as follows:

             o when the path type is Type-2 add 1 to the Type 5 LSA's
               metric,

             o when the path type is Type-1 the link state cost of the
               Type 5 LSA's network is used.

          When the path type is Type-2, 1 is added to the Type 5 LSA's
          metric to ensure that the translated Type 7 LSA is not more
          preferred on the NSSA border than a translatable Type 5 LSA
          whose network has the same [address,mask] pair and Type-2
          metric.  The link-state ID is equal to the LSA's network
          address (in the case of multiple originations of Type 5 LSAs
          with the same network address but different mask, the link-
          state ID can also have one or more of the range's "host" bits
          set).

      (3) Else the Type 5 LSA must be aggregated by the most specific
          Type 5 range which subsumes it.  Compute the path type and
          metric for this Type 5 range as described below.

          The path type and metric of the Type 5 range is determined
          from the path types and metrics of those translatable Type 5
          LSAs which best match the range plus any locally sourced Type
          7 LSAs whose network has the same [address,mask] pair.  If any
          of these LSAs have a path type of 2 then the range's path type
          is 2, otherwise it is 1.  If the range's path type is 1 its
          metric is the highest link state cost amongst these LSAs; if
          the range's path type is 2 its metric is the highest Type-2



Murphy             OSPF Type 5 to Type 7 Translation            [Page 6]


Internet Draft                                                  May 2001


          metic + 1 amongst these LSAs (See [NSSA] Section 3.5 step
          (5)).  One is added to the Type-2 metric to ensure that the
          translated Type 7 LSA is not more preferred on the NSSA border
          than a translatable Type 5 LSA whose network has the same
          [address,mask] pair and Type-2 metric.

          A Type 7 LSA is generated from the Type 5 range when there
          currently is no Type 7 LSA originated by this router whose
          network has the same [address,mask] pair as the range or there
          is but either its path type or metric has changed or its
          forwarding address is non-zero.

          The newly generated Type 7 LSA will have link-state ID equal
          to the Type 5 range's address (in the case of multiple
          originations of Type 7 LSAs with the same network address but
          different mask, the link-state ID can also have one or more of
          the range's "host" bits set).  The advertising router field
          will be the router ID of this NSSA border router.  The network
          mask and the external route tag are set to the Type 5 range's
          configured values.  The P-bit will be clear.  The forwarding
          address is set to 0.0.0.0.  The path type and metric are set
          to the Type 5 range's path type and metric as defined above.

      (4) If a Type 5 range match has occurred, the pending processing
          of other translation eligible Type 5 LSAs which best match
          this Type 5 range is suppressed.  Thus at most a single Type 5
          LSA is originated for each Type 5 range.

   For example, given a Type 5 range of [10.0.0.0, 255.0.0.0] which
   subsumes the following Type 5 routes:

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

   a Type 7 LSA would be generated with a path type of 2 and a metric 6.

   Given a Type 5 range of [10.0.0.0, 255.0.0.0] which subsumes the
   following Type 5 routes:

                 10.1.0.0 path type 1, link state cost 10
                 10.2.0.0 path type 1, link state cost 11
                 10.3.0.0 path type 1, link state cost 5,

   a Type 7 LSA will be generated with a path type of 1 and a metric 11.

   The metric and path type rules of type 5 ranges will avoid routing
   loops in the event that path types 1 and 2 are both used within the



Murphy             OSPF Type 5 to Type 7 Translation            [Page 7]


Internet Draft                                                  May 2001


   OSPF transit topology.

   Like Type 3 ranges, a Type 5 range performs the dual function of
   setting propagation policy via its Advertise/DoNotAdvertise parameter
   and optional aggregation via its network address and mask pair.
   Unlike Type 3 summary links, Type 5 translation may result in more
   efficient routing when the forwarding address is set, as may be done
   during step (2) of the translation procedure.

   Another important feature of this translation process is that it
   allows a Type 5 range to apply different properties (aggregation,
   forwarding address, and Advertise/DoNotAdvertise status) for the Type
   5 routes it subsumes, versus those Type 5 routes subsumed by other
   more specific Type 5 ranges contained by the Type 5 range.

4.2 Flushing Translated Type 5 LSAs

   If an NSSA border router has either translated or aggregated an
   installed Type 5 LSA into a Type 7 LSA and that Type 5 LSA is no
   longer translatable, then the Type 7 LSA should either be flushed or
   reoriginated as an aggregation of other Type 5 LSAs.

   If an NSSA border router is translating Type 5 LSAs into Type 7 LSAs
   with

                NSSATranslatorState = elected

   and the NSSA border router has determined that its translator
   election status has been deposed by another NSSA border router, then,
   as soon as the TranslatorStabilityInterval (See [NSSA] Section 4.1)
   has expired without the router reelecting itself as a translator, any
   Type 7 LSAs with a 0.0.0.0 forwarding address which were generated by
   translating Type 5 LSAs are flushed.  Conversely Type 7 LSAs with a
   non-zero forwarding address which were generated by translating Type
   5 LSAs are not immediately flushed, but are allowed to remain in the
   NSSA as if the originator is still an elected translator.  This
   minimizes the impact of an NSSA border router which changes its
   translator status frequently.

5.0 Security Considerations

   This memo does not create any new security considerations for the
   OSPF protocol.  Security considerations for the base OSPF protocol
   are covered in [OSPF].







Murphy             OSPF Type 5 to Type 7 Translation            [Page 8]


Internet Draft                                                  May 2001


6.0 Acknowledgments

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

   In addition, the comments of the following individual is also
   acknowledged:

                  Alex Zinin         cisco

7.0 References

   [NSSA] R. Colton, V. Fuller, P. Murphy, "The OSPF NSSA Option", RFC
      TBD, March 2001.

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

8.0 Authors' Addresses

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

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
























Murphy             OSPF Type 5 to Type 7 Translation            [Page 9]