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]
