[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network Working Group                                          P. Murphy
Internet Draft                                      US Geological Survey
Expiration Date: September 2002                               March 2002
File name: draft-ietf-ospf-5to7-01.txt

                      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                                                          [Page i]


Internet Draft        Type 5 to Type 7 Translation            March 2002


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 ...............................  5
   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 ..................................  9
   6.0 Acknowledgments ..........................................  9
   7.0 References ...............................................  9
   8.0 Author's Address .........................................  9
   Appendix A:  Configuration Parameters ........................ 10


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                                                          [Page 1]


Internet Draft        Type 5 to Type 7 Translation            March 2002


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 route cannot reach take these
   collaborations through Area 0 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. It would also be
   nice if such a feature supported the aggregation of these external
   advertisements to minimize the impact on the size the NSSA's link
   state data base.

2.2 Proposed Solution

   NSSAs support external routing via Type 7 LSAs.  Destinations
   described in Type 7 LSAs may be announced to the rest of the larger



Murphy                                                          [Page 2]


Internet Draft        Type 5 to Type 7 Translation            March 2002


   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 with the optional
   capability of translating Type 5 LSAs into Type 7 LSAs and then
   flooding these Type 7 LSAs into specific directly attached NSSAs.
   What Type 5 LSAs are translated is 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 not resolve during the external route
   calculation 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 NSSA specific.  Each address
   range is defined as an [address,mask] pair.  Many prefixes announced
   in separate Type 5 LSAs may fall into a single Type 5 address range,
   just as a subnetted network is composed of many separate subnets.
   E.g. 10.2.2.0/24 and 10.2.3.0/24 fall into the 10.1.0.0/16 range.
   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 4 address range
   is configured.  Section 4.1 details how Type 7 LSAs are generated
   from Type 5 LSAs and configured 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.




Murphy                                                          [Page 3]


Internet Draft        Type 5 to Type 7 Translation            March 2002


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

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 be resolvable through an NSSA intra-area path.
   The forwarding addresses of Type 5 LSAs belong to networks which are
   part of an OSPF standard area. Thus the non-zero forwarding address
   of a Type 7 LSA translation of any Type 5 LSA has an inter-area path
   from within its NSSA. Implementations of [OSPF] are expected to set
   the N/P-bit of the router-LSA's Option field of an NSSA router. 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. If an NSSA's UseForwardingAddresses configuration
   parameter (See Appendix A) is set to yes then the N/P-bit of the
   NSSA's router LSA is clear. Otherwise the N/P-bit of the NSSA's
   router LSA is set.

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, on NSSA border routers the Type 7 AS
   external route calculation of a Type 5 LSA translation with a non-
   zero forwarding address fails 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.





Murphy                                                          [Page 4]


Internet Draft        Type 5 to Type 7 Translation            March 2002


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.

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, including the local router, 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 border 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



Murphy                                                          [Page 5]


Internet Draft        Type 5 to Type 7 Translation            March 2002


          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 forwarding
          address is non-zero and the calculating router has the highest
          router ID amongst NSSA translators which have originated a
          functionally equivalent installed Type 7 LSA (i.e. same
          destination, cost and non-zero forwarding address) 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 the use of non-zero forwarding
          addresses 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 routing table 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



Murphy                                                          [Page 6]


Internet Draft        Type 5 to Type 7 Translation            March 2002


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

   Note that when a Type 5 range match does occur, the subsequent
   processing of other translation eligible Type 5 LSAs which best match
   the 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.




Murphy                                                          [Page 7]


Internet Draft        Type 5 to Type 7 Translation            March 2002


   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
   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 a translation or 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



Murphy                                                          [Page 8]


Internet Draft        Type 5 to Type 7 Translation            March 2002


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

6.0 Acknowledgments

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

   Most notably, Alex Zinin of Nexsi is acknowledge for suggesting that
   translating Type 5 LSAs into Type 7 LSAs would be a useful feature
   and has provided substantial technical review in the preparation of
   the document.

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.usgs.net
















Murphy                                                          [Page 9]


Internet Draft        Type 5 to Type 7 Translation            March 2002


Appendix A:  Configuration Parameters

      Section 3.1 of this document lists the configuration parameters
      for Type-5 address ranges.  The following area configuration
      parameter has been added and should be configurable for each
      directly connected NSSA.

      UseForwardingAddrresses

         If set to yes an NSSA router will originate a router-LSA with a
         clear N/P-bit. Otherwise it will originate a router-LSA with
         the N/P bit set. On NSSA internal routers the default setting
         is yes. On NSSA border routers the default setting is yes when
         the NSSA parameter ImportSummaries is enabled.  The default
         setting is no when ImportSummaries is disabled.




































Murphy                                                         [Page 10]


Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/