idnits 2.17.1 draft-ietf-ospf-5to7-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 11 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2001) is 8375 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'NSSA' Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Murphy 3 Internet Draft US Geological Survey 4 Expiration Date: November 2001 May 2001 5 File name: draft-ietf-ospf-5to7-00.txt 7 OSPF Type 5 to Type 7 Translation 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Table Of Contents 30 1.0 Abstract ................................................. 1 31 2.0 Overview ................................................. 2 32 2.1 Motivation - Corporate Networks .......................... 2 33 2.2 Proposed Solution ........................................ 2 34 3.0 Type 5 Translation Implementation Details ................ 3 35 3.1 Type 5 Address Ranges .................................... 3 36 3.2 Setting the N/P-bit in the Options field of Router-LSAs... 4 37 3.3 Calculating Type 7 LSAs as External Routes ............... 4 38 3.4 Type 5 Translator Election ............................... 4 39 4.0 Originating Translated Type 5 LSAs ....................... 5 40 4.1 Translating Type 5 LSAs into Type 7 LSAs ................. 5 41 4.2 Flushing Translated Type 7 LSAs .......................... 8 42 5.0 Security Considerations .................................. 8 43 6.0 Acknowledgments .......................................... 9 44 7.0 References ............................................... 9 45 8.0 Author's Address ......................................... 9 47 1.0 Abstract 49 This memo documents an extension to OSPF which allows area border 50 routers to translate Type 5 LSAs into Type 7 LSAs with aggregation. 51 Type 7 LSAs, which are translations of Type 5 LSAs, are flooded into 52 Not-So-Stubby areas (NSSAs). All differences, while expanding 53 capability, are backward compatible in nature. NSSA Border routers 54 which run implementations of this memo will interoperate with other 55 NSSA routers which do not. This option is only applicable on a 56 border router with at least one directly attached NSSA. 58 Please send comments to ospf@discuss.microsoft.com. 60 2.0 Overview 62 2.1 Motivation - Corporate Networks 64 In a corporate network which supports a large corporate 65 infrastructure it is not uncommon for an OSPF NSSA to support its own 66 internal Internet default. Other areas may have external links to 67 outside collaborators. While Type 5 LSAs advertise the existence of 68 these collaborations throughout the OSPF transit topology, NSSAs with 69 their own internal default cannot take advantage of these 70 collaborations since Type 5 LSAs are not flooded into NSSAs. 71 Consider the following example: 73 A0------Area 0 cloud------B0 74 | | 75 | | 76 Area 2 cloud NSSA 1 cloud 77 | | 78 | | 79 A2 B1 80 | | 81 | | 82 E2 E1 83 | | 84 | | 85 ----------- Internet Default 86 10.0.13.0/24 88 where A0 and B0 are area 0 border routers attached to Area 2 and NSSA 89 1 respectively. A2 and B1 are ASBRs. A2 advertises a route to 90 10.0.13.0 through E2 while B1 advertises a preferred Type 7 NSSA 91 internal default through E1. Since NSSAs do not import Type 5 LSAs, 92 NSSA 1 has no knowledge of the path through Area 2 to 10.0.13.0/24 93 and would instead choose to forward traffic destined to 10.0.13.0/24 94 to its Internet default through E1. 96 What is needed is a means of advertising the 10.0.13.0/24 path 97 through Area 2 into NSSA 1 without converting NSSA 1 to an OSPF 98 standard area and incurring the full import of all Type 5 LSAs into 99 NSSA 1. Currently no such feature exists in OSPF. 101 2.2 Proposed Solution 103 NSSAs support external routing via Type 7 LSAs. Type 7 LSAs may be 104 flooded into the larger OSPF domain by translating them into Type 5 105 LSAs with optional aggregation. The proposed solution to the problem 106 discussed in Section 2.1 is to enable area border routers to have the 107 optional capability of translating Type 5 LSAs into Type 7 LSAs and 108 then flooding these Type 7 LSAs into their directly attached NSSAs. 109 Type 5 LSA translations are configured separately for each directly 110 attached NSSA as well as what, if any, aggregation is performed. 112 The P-bit of a Type 7 LSA translation of a Type 5 LSA is always clear 113 so that these translations are never re-translated back into type 5 114 LSAs by other NSSA border routers. As with the translation of Type 7 115 LSAs into Type 5 LSAs, when the result of translating a Type 5 LSA 116 into a Type 7 LSA is a true aggregation, the forwarding address is 117 set to 0.0.0.0. Furthermore, when the import of summary routes into 118 the NSSA is disabled, the forwarding addresses of Type 7 LSA 119 translations are also 0.0.0.0, since, in this case, the use of non- 120 zero forwarding addresses would cause the installation failure of 121 these translations (See the last paragraph of [NSSA] Section 3.5 Step 122 (3)). 124 3.0 Type 5 Translation Implementation Details 126 3.1 Type 5 Address Ranges 128 Area border routers may be configured with Type 5 address ranges for 129 each NSSA. Type 5 address ranges are area specific. Each address 130 range is defined as an [address,mask] pair. Many separate Type 5 LSA 131 networks may fall into a single Type 5 address range, just as a 132 subnetted network is composed of many separate subnets. NSSA border 133 routers may aggregate Type 5 routes by advertising into the NSSA a 134 single Type 7 LSA for each Type 5 address range. Any Type 5 LSA 135 translation resulting from a Type 5 address range match will only be 136 flooded into the NSSA for which the Type 5 address range is 137 configured. Section 4.1 gives the details of generating Type 7 LSAs 138 from Type 5 address ranges. 140 A Type 5 address range includes the following configurable items. 142 o An [address,mask] pair, 144 o a status indication of either Advertise or DoNotAdvertise, 146 o a status indication of either Aggregate or DoNotAggregate, and 148 o an external route tag. 150 Any Type 5 LSA which is not contained in a configured Type 5 address 151 range of a directly attached NSSA is not translated into a Type 7 152 LSA. This prevents the uncontrolled injection of external routing 153 information into NSSAs. 155 3.2 Setting the N/P-bit in the Options field of Router-LSAs 157 NSSA routers as described in [NSSA] expect a Type 7 LSA's non-zero 158 forwarding address to have an [NSSA] intra-area path. Type 7 LSA's 159 which are translations of Type 5 LSAs have a non-zero forwarding 160 address with an inter-area path. Section A.2 of [OSPF] implies that 161 the N/P-bit of the router-LSA's Option field of an NSSA router should 162 be set by default. This memo requires that NSSA routers implementing 163 this option should clear the N/P-bit in their router-LSA's Options 164 field. NSSA border routers should never translate Type 5 LSAs into 165 Type 7 LSAs with non-zero forwarding addresses unless all of the 166 NSSA's router-LSAs have a clear N/P-bit. 168 3.3 Calculating Type 7 LSAs as External Routes 170 The Type 7 LSA External Route calculation discussed in [NSSA] Section 171 3.5 needs only a minor change to support the translation of Type 5 172 LSAs into Type 7 LSAs. In the last paragraph of [NSSA] Section 3.5 173 Step (3) the non-zero forwarding address of a Type 7 LSA should have 174 an intra-area path with next-hop through the originating NSSA. The 175 non-zero forwarding addresses of Type 5 LSAs, as well as their Type 7 176 translations, are normally external to an NSSA. In Section 3.5 Step 177 (3), if all of the NSSA's router-LSAs have a clear N/P-bit in their 178 Options field, then non-zero forwarding addresses of Type 7 LSAs 179 which originate from one of the NSSA's border routers must be allowed 180 to have inter-area paths with next-hop through the originating NSSA. 181 Otherwise they should ignore these LSAs. 183 Even with the above change, the Type 7 AS external route calculation 184 of a Type 5 LSA translation with a non-zero forwarding address fails 185 on NSSA border routers in the last paragraph of Section 3.5 Step (3) 186 allowing the Type 5 LSA from which it was translated to be preferred. 187 However, since Type 5 LSAs must choose their preferred paths through 188 the transit topology as discussed in [NSSA] Section 3.5 Step (3), 189 their Type 7 LSA translations which have a 0.0.0.0 forwarding address 190 and Type-1 metric may offer a more preferred path through the 191 originating NSSA. 193 3.4 Type 5 Translator Election 195 It may be desirable to have only one Type 5 border router translator. 196 For the sake of simplicity this specification combines the duties of 197 translating Type 5 LSAs into Type 7 LSAs with the duties of 198 translating Type 7 LSAs into Type 5 LSAs. Any configured or elected 199 translator of Type 7 LSAs into Type 5 LSAs will also translate Type 5 200 LSAs into Type 7 LSAs. There are no other NSSA border router 201 translators. 203 4.0 Originating Translated Type 5 LSAs 205 4.1 Translating Type 5 LSAs into Type 7 LSAs 207 This step is performed as part of the NSSA's Dijkstra calculation 208 after Type 5 routes and Type 7 routes have been calculated. It is 209 performed for each attached NSSA. If the calculating router is 210 currently not an NSSA border router translator, then this translation 211 algorithm should be skipped. Only installed Type 5 LSAs and locally 212 originated Type 5 LSAs are eligible to be translated. When computing 213 the metric of a Type 7 translation of an installed type 5 LSA, its 214 link state cost is found in the Type 5 LSA's routing table entry. In 215 the case of a locally originated Type 5 LSA the link state cost of 216 its Type 7 translation is externally defined. A Type 5 range which 217 contains a Type 5 LSA best matches the LSA when the range's 218 [address,mask] pair is more specific than the [address,mask] pairs of 219 other Type 5 ranges which contain the LSA's network. 221 When a Type 5 LSA is translated without aggregation (See Step (2) 222 below), its Type 7 LSA translation uses the Type 5 LSA's non-zero 223 forwarding address and metrics provided the following two conditions 224 are met: 226 o summary routes are imported, 228 o all of the NSSA's router-LSAs have the N/P bit clear in the 229 router-LSA's Options field. 231 Otherwise the Type 7 LSA's forwarding address must be 0.0.0.0 and its 232 metrics are recomputed using the originating NSSA router as the 233 source (See below). 235 For each translation eligible Type 5 LSA perform the following for 236 each directly attached NSSA: 238 (1) If the Type 5 range which best matches the Type 5 LSA's 239 network has DoNotAdvertise status or if the LSA is not 240 contained in any explicitly configured Type 5 address range 241 then do nothing with this Type 5 LSA and consider the next one 242 in the list. Otherwise term the LSA as translatable and 243 proceed with step (2). 245 (2) If the Type 5 range which best matches the Type 5 LSA's 246 network has DoNotAggregate status and the translated Type 5 247 would have a 0.0.0.0 forwarding address or the calculating 248 router has the highest router ID amongst NSSA translators 249 which have originated a functionally equivalent Type 7 LSA 250 (i.e. same destination, cost and non-zero forwarding address) 251 and which are reachable over area 0, then a Type 7 LSA should 252 be generated with the appropriate forwarding address (See 253 above) provided there currently is no Type 7 LSA originating 254 from this router corresponding to the Type 5 LSA's network or 255 there is an existing Type 7 LSA and either it corresponds to a 256 local OSPF external source whose path type and metric is less 257 preferred (see [NSSA] Section 3.5 step (6)) or it doesn't and 258 the Type 7 LSA's path type or cost(s) have changed (See [NSSA] 259 Section 3.5 step (5)), or its non-zero forwarding address is 260 no longer reachable or its usage status of a non-zero 261 forwarding address has changed (See above). 263 The newly originated Type 7 LSA will describe the same network 264 and have the same network mask, path type and external route 265 tag as the Type 5 LSA. The advertising router field will be 266 the router ID of this NSSA border router. The P-bit will be 267 clear. If the Type 7 LSA's forwarding address will be non- 268 zero the newly originated Type 7 LSA will have the same metric 269 as the Type 5 LSA. Otherwise the metric is set as follows: 271 o when the path type is Type-2 add 1 to the Type 5 LSA's 272 metric, 274 o when the path type is Type-1 the link state cost of the 275 Type 5 LSA's network is used. 277 When the path type is Type-2, 1 is added to the Type 5 LSA's 278 metric to ensure that the translated Type 7 LSA is not more 279 preferred on the NSSA border than a translatable Type 5 LSA 280 whose network has the same [address,mask] pair and Type-2 281 metric. The link-state ID is equal to the LSA's network 282 address (in the case of multiple originations of Type 5 LSAs 283 with the same network address but different mask, the link- 284 state ID can also have one or more of the range's "host" bits 285 set). 287 (3) Else the Type 5 LSA must be aggregated by the most specific 288 Type 5 range which subsumes it. Compute the path type and 289 metric for this Type 5 range as described below. 291 The path type and metric of the Type 5 range is determined 292 from the path types and metrics of those translatable Type 5 293 LSAs which best match the range plus any locally sourced Type 294 7 LSAs whose network has the same [address,mask] pair. If any 295 of these LSAs have a path type of 2 then the range's path type 296 is 2, otherwise it is 1. If the range's path type is 1 its 297 metric is the highest link state cost amongst these LSAs; if 298 the range's path type is 2 its metric is the highest Type-2 299 metic + 1 amongst these LSAs (See [NSSA] Section 3.5 step 300 (5)). One is added to the Type-2 metric to ensure that the 301 translated Type 7 LSA is not more preferred on the NSSA border 302 than a translatable Type 5 LSA whose network has the same 303 [address,mask] pair and Type-2 metric. 305 A Type 7 LSA is generated from the Type 5 range when there 306 currently is no Type 7 LSA originated by this router whose 307 network has the same [address,mask] pair as the range or there 308 is but either its path type or metric has changed or its 309 forwarding address is non-zero. 311 The newly generated Type 7 LSA will have link-state ID equal 312 to the Type 5 range's address (in the case of multiple 313 originations of Type 7 LSAs with the same network address but 314 different mask, the link-state ID can also have one or more of 315 the range's "host" bits set). The advertising router field 316 will be the router ID of this NSSA border router. The network 317 mask and the external route tag are set to the Type 5 range's 318 configured values. The P-bit will be clear. The forwarding 319 address is set to 0.0.0.0. The path type and metric are set 320 to the Type 5 range's path type and metric as defined above. 322 (4) If a Type 5 range match has occurred, the pending processing 323 of other translation eligible Type 5 LSAs which best match 324 this Type 5 range is suppressed. Thus at most a single Type 5 325 LSA is originated for each Type 5 range. 327 For example, given a Type 5 range of [10.0.0.0, 255.0.0.0] which 328 subsumes the following Type 5 routes: 330 10.1.0.0 path type 1, link state cost 10 331 10.2.0.0 path type 1, link state cost 11 332 10.3.0.0 path type 2, metric 5, 334 a Type 7 LSA would be generated with a path type of 2 and a metric 6. 336 Given a Type 5 range of [10.0.0.0, 255.0.0.0] which subsumes the 337 following Type 5 routes: 339 10.1.0.0 path type 1, link state cost 10 340 10.2.0.0 path type 1, link state cost 11 341 10.3.0.0 path type 1, link state cost 5, 343 a Type 7 LSA will be generated with a path type of 1 and a metric 11. 345 The metric and path type rules of type 5 ranges will avoid routing 346 loops in the event that path types 1 and 2 are both used within the 347 OSPF transit topology. 349 Like Type 3 ranges, a Type 5 range performs the dual function of 350 setting propagation policy via its Advertise/DoNotAdvertise parameter 351 and optional aggregation via its network address and mask pair. 352 Unlike Type 3 summary links, Type 5 translation may result in more 353 efficient routing when the forwarding address is set, as may be done 354 during step (2) of the translation procedure. 356 Another important feature of this translation process is that it 357 allows a Type 5 range to apply different properties (aggregation, 358 forwarding address, and Advertise/DoNotAdvertise status) for the Type 359 5 routes it subsumes, versus those Type 5 routes subsumed by other 360 more specific Type 5 ranges contained by the Type 5 range. 362 4.2 Flushing Translated Type 5 LSAs 364 If an NSSA border router has either translated or aggregated an 365 installed Type 5 LSA into a Type 7 LSA and that Type 5 LSA is no 366 longer translatable, then the Type 7 LSA should either be flushed or 367 reoriginated as an aggregation of other Type 5 LSAs. 369 If an NSSA border router is translating Type 5 LSAs into Type 7 LSAs 370 with 372 NSSATranslatorState = elected 374 and the NSSA border router has determined that its translator 375 election status has been deposed by another NSSA border router, then, 376 as soon as the TranslatorStabilityInterval (See [NSSA] Section 4.1) 377 has expired without the router reelecting itself as a translator, any 378 Type 7 LSAs with a 0.0.0.0 forwarding address which were generated by 379 translating Type 5 LSAs are flushed. Conversely Type 7 LSAs with a 380 non-zero forwarding address which were generated by translating Type 381 5 LSAs are not immediately flushed, but are allowed to remain in the 382 NSSA as if the originator is still an elected translator. This 383 minimizes the impact of an NSSA border router which changes its 384 translator status frequently. 386 5.0 Security Considerations 388 This memo does not create any new security considerations for the 389 OSPF protocol. Security considerations for the base OSPF protocol 390 are covered in [OSPF]. 392 6.0 Acknowledgments 394 This document was produced by the OSPF Working Group, chaired by John 395 Moy. 397 In addition, the comments of the following individual is also 398 acknowledged: 400 Alex Zinin cisco 402 7.0 References 404 [NSSA] R. Colton, V. Fuller, P. Murphy, "The OSPF NSSA Option", RFC 405 TBD, March 2001. 407 [OSPF] Moy, J., "OSPF Version 2", RFC 2328, Cascade Communications 408 Corp., April 1998. 410 8.0 Authors' Addresses 412 Pat Murphy 413 US Geological Survey 414 345 Middlefield Road 415 Menlo Park, California 94560 417 Phone: (415) 329-4044 418 EMail: pmurphy@noc.doi.net