idnits 2.17.1 draft-ietf-ospf-5to7-01.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 12 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 (March 2002) is 8072 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: September 2002 March 2002 5 File name: draft-ietf-ospf-5to7-01.txt 7 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 ............................... 5 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 .................................. 9 43 6.0 Acknowledgments .......................................... 9 44 7.0 References ............................................... 9 45 8.0 Author's Address ......................................... 9 46 Appendix A: Configuration Parameters ........................ 10 48 1.0 Abstract 50 This memo documents an extension to OSPF which allows area border 51 routers to translate Type 5 LSAs into Type 7 LSAs with aggregation. 52 Type 7 LSAs, which are translations of Type 5 LSAs, are flooded into 53 Not-So-Stubby areas (NSSAs). All differences, while expanding 54 capability, are backward compatible in nature. NSSA Border routers 55 which run implementations of this memo will interoperate with other 56 NSSA routers which do not. This option is only applicable on a 57 border router with at least one directly attached NSSA. 59 Please send comments to ospf@discuss.microsoft.com. 61 2.0 Overview 63 2.1 Motivation - Corporate Networks 65 In a corporate network which supports a large corporate 66 infrastructure it is not uncommon for an OSPF NSSA to support its own 67 internal Internet default. Other areas may have external links to 68 outside collaborators. While Type 5 LSAs advertise the existence of 69 these collaborations throughout the OSPF transit topology, NSSAs with 70 their own internal default route cannot reach take these 71 collaborations through Area 0 since Type 5 LSAs are not flooded into 72 NSSAs. Consider the following example: 74 A0------Area 0 cloud------B0 75 | | 76 | | 77 Area 2 cloud NSSA 1 cloud 78 | | 79 | | 80 A2 B1 81 | | 82 | | 83 E2 E1 84 | | 85 | | 86 ----------- Internet Default 87 10.0.13.0/24 89 where A0 and B0 are area 0 border routers attached to Area 2 and NSSA 90 1 respectively. A2 and B1 are ASBRs. A2 advertises a route to 91 10.0.13.0 through E2 while B1 advertises a preferred Type 7 NSSA 92 internal default through E1. Since NSSAs do not import Type 5 LSAs, 93 NSSA 1 has no knowledge of the path through Area 2 to 10.0.13.0/24 94 and would instead choose to forward traffic destined to 10.0.13.0/24 95 to its Internet default through E1. 97 What is needed is a means of advertising the 10.0.13.0/24 path 98 through Area 2 into NSSA 1 without converting NSSA 1 to an OSPF 99 standard area and incurring the full import of all Type 5 LSAs into 100 NSSA 1. Currently no such feature exists in OSPF. It would also be 101 nice if such a feature supported the aggregation of these external 102 advertisements to minimize the impact on the size the NSSA's link 103 state data base. 105 2.2 Proposed Solution 107 NSSAs support external routing via Type 7 LSAs. Destinations 108 described in Type 7 LSAs may be announced to the rest of the larger 109 OSPF domain by translating them into Type 5 LSAs with optional 110 aggregation. The proposed solution to the problem discussed in 111 Section 2.1 is to enable area border routers with the optional 112 capability of translating Type 5 LSAs into Type 7 LSAs and then 113 flooding these Type 7 LSAs into specific directly attached NSSAs. 114 What Type 5 LSAs are translated is configured separately for each 115 directly attached NSSA as well as what, if any, aggregation is 116 performed. 118 The P-bit of a Type 7 LSA translation of a Type 5 LSA is always clear 119 so that these translations are never re-translated back into Type 5 120 LSAs by other NSSA border routers. As with the translation of Type 7 121 LSAs into Type 5 LSAs, when the result of translating a Type 5 LSA 122 into a Type 7 LSA is a true aggregation, the forwarding address is 123 set to 0.0.0.0. Furthermore, when the import of summary routes into 124 the NSSA is disabled, the forwarding addresses of Type 7 LSA 125 translations are also 0.0.0.0, since, in this case, the use of non- 126 zero forwarding addresses would not resolve during the external route 127 calculation of these translations (See the last paragraph of [NSSA] 128 Section 3.5 Step (3)). 130 3.0 Type 5 Translation Implementation Details 132 3.1 Type 5 Address Ranges 134 Area border routers may be configured with Type 5 address ranges for 135 each NSSA. Type 5 address ranges are NSSA specific. Each address 136 range is defined as an [address,mask] pair. Many prefixes announced 137 in separate Type 5 LSAs may fall into a single Type 5 address range, 138 just as a subnetted network is composed of many separate subnets. 139 E.g. 10.2.2.0/24 and 10.2.3.0/24 fall into the 10.1.0.0/16 range. 140 NSSA border routers may aggregate Type 5 routes by advertising into 141 the NSSA a single Type 7 LSA for each Type 5 address range. Any 142 Type 5 LSA translation resulting from a Type 5 address range match 143 will only be flooded into the NSSA for which the Type 4 address range 144 is configured. Section 4.1 details how Type 7 LSAs are generated 145 from Type 5 LSAs and configured Type 5 address ranges. 147 A Type 5 address range includes the following configurable items. 149 o An [address,mask] pair, 151 o a status indication of either Advertise or DoNotAdvertise, 153 o a status indication of either Aggregate or DoNotAggregate, and 155 o an external route tag. 157 Any Type 5 LSA which is not contained in a configured Type 5 address 158 range is not translated into a Type 7 LSA. This prevents the 159 uncontrolled injection of external routing information into NSSAs. 161 3.2 Setting the N/P-bit in the Options field of Router-LSAs 163 NSSA routers as described in [NSSA] expect a Type 7 LSA's non-zero 164 forwarding address to be resolvable through an NSSA intra-area path. 165 The forwarding addresses of Type 5 LSAs belong to networks which are 166 part of an OSPF standard area. Thus the non-zero forwarding address 167 of a Type 7 LSA translation of any Type 5 LSA has an inter-area path 168 from within its NSSA. Implementations of [OSPF] are expected to set 169 the N/P-bit of the router-LSA's Option field of an NSSA router. This 170 memo requires that NSSA routers implementing this option should clear 171 the N/P-bit in their router-LSA's Options field. NSSA border routers 172 should never translate Type 5 LSAs into Type 7 LSAs with non-zero 173 forwarding addresses unless all of the NSSA's router-LSAs have a 174 clear N/P-bit. If an NSSA's UseForwardingAddresses configuration 175 parameter (See Appendix A) is set to yes then the N/P-bit of the 176 NSSA's router LSA is clear. Otherwise the N/P-bit of the NSSA's 177 router LSA is set. 179 3.3 Calculating Type 7 LSAs as External Routes 181 The Type 7 LSA External Route calculation discussed in [NSSA] Section 182 3.5 needs only a minor change to support the translation of Type 5 183 LSAs into Type 7 LSAs. In the last paragraph of [NSSA] Section 3.5 184 Step (3) the non-zero forwarding address of a Type 7 LSA should have 185 an intra-area path with next-hop through the originating NSSA. The 186 non-zero forwarding addresses of Type 5 LSAs, as well as their Type 7 187 translations, are normally external to an NSSA. In Section 3.5 Step 188 (3), if all of the NSSA's router-LSAs have a clear N/P-bit in their 189 Options field, then non-zero forwarding addresses of Type 7 LSAs 190 which originate from one of the NSSA's border routers must be allowed 191 to have inter-area paths with next-hop through the originating NSSA. 192 Otherwise they should ignore these LSAs. 194 Even with the above change, on NSSA border routers the Type 7 AS 195 external route calculation of a Type 5 LSA translation with a non- 196 zero forwarding address fails in the last paragraph of Section 3.5 197 Step (3) allowing the Type 5 LSA from which it was translated to be 198 preferred. However, since Type 5 LSAs must choose their preferred 199 paths through the transit topology as discussed in [NSSA] Section 3.5 200 Step (3), their Type 7 LSA translations which have a 0.0.0.0 201 forwarding address and Type-1 metric may offer a more preferred path 202 through the originating NSSA. 204 3.4 Type 5 Translator Election 206 It may be desirable to have only one Type 5 border router translator. 207 For the sake of simplicity this specification combines the duties of 208 translating Type 5 LSAs into Type 7 LSAs with the duties of 209 translating Type 7 LSAs into Type 5 LSAs. Any configured or elected 210 translator of Type 7 LSAs into Type 5 LSAs will also translate Type 5 211 LSAs into Type 7 LSAs. There are no other NSSA border router 212 translators. 214 4.0 Originating Translated Type 5 LSAs 216 4.1 Translating Type 5 LSAs into Type 7 LSAs 218 This step is performed as part of the NSSA's Dijkstra calculation 219 after Type 5 routes and Type 7 routes have been calculated. It is 220 performed for each attached NSSA. If the calculating router is 221 currently not an NSSA border router translator, then this translation 222 algorithm should be skipped. Only installed Type 5 LSAs and locally 223 originated Type 5 LSAs are eligible to be translated. When computing 224 the metric of a Type 7 translation of an installed type 5 LSA, its 225 link state cost is found in the Type 5 LSA's routing table entry. In 226 the case of a locally originated Type 5 LSA the link state cost of 227 its Type 7 translation is externally defined. A Type 5 range which 228 contains a Type 5 LSA best matches the LSA when the range's 229 [address,mask] pair is more specific than the [address,mask] pairs of 230 other Type 5 ranges which contain the LSA's network. 232 When a Type 5 LSA is translated without aggregation (See Step (2) 233 below), its Type 7 LSA translation uses the Type 5 LSA's non-zero 234 forwarding address and metrics provided the following two conditions 235 are met: 237 o summary routes are imported, 239 o all of the NSSA's router-LSAs, including the local router, have 240 the N/P bit clear in the router-LSA's Options field. 242 Otherwise the Type 7 LSA's forwarding address must be 0.0.0.0 and its 243 metrics are recomputed using the originating NSSA border router as 244 the source (See below). 246 For each translation eligible Type 5 LSA perform the following for 247 each directly attached NSSA: 249 (1) If the Type 5 range which best matches the Type 5 LSA's 250 network has DoNotAdvertise status or if the LSA is not 251 contained in any explicitly configured Type 5 address range 252 then do nothing with this Type 5 LSA and consider the next one 253 in the list. Otherwise term the LSA as translatable and 254 proceed with step (2). 256 (2) If the Type 5 range which best matches the Type 5 LSA's 257 network has DoNotAggregate status and the translated Type 5 258 would have a 0.0.0.0 forwarding address or the forwarding 259 address is non-zero and the calculating router has the highest 260 router ID amongst NSSA translators which have originated a 261 functionally equivalent installed Type 7 LSA (i.e. same 262 destination, cost and non-zero forwarding address) and which 263 are reachable over area 0, then a Type 7 LSA should be 264 generated with the appropriate forwarding address (See above) 265 provided there currently is no Type 7 LSA originating from 266 this router corresponding to the Type 5 LSA's network or there 267 is an existing Type 7 LSA and either it corresponds to a local 268 OSPF external source whose path type and metric is less 269 preferred (see [NSSA] Section 3.5 step (6)) or it doesn't and 270 the Type 7 LSA's path type or cost(s) have changed (See [NSSA] 271 Section 3.5 step (5)), or its non-zero forwarding address is 272 no longer reachable or the use of non-zero forwarding 273 addresses has changed (See above). 275 The newly originated Type 7 LSA will describe the same network 276 and have the same network mask, path type and external route 277 tag as the Type 5 LSA. The advertising router field will be 278 the router ID of this NSSA border router. The P-bit will be 279 clear. If the Type 7 LSA's forwarding address will be non- 280 zero the newly originated Type 7 LSA will have the same metric 281 as the Type 5 LSA. Otherwise the metric is set as follows: 283 o when the path type is Type-2 add 1 to the Type 5 LSA's 284 metric, 286 o when the path type is Type-1 the routing table cost of 287 the Type 5 LSA's network is used. 289 When the path type is Type-2, 1 is added to the Type 5 LSA's 290 metric to ensure that the translated Type 7 LSA is not more 291 preferred on the NSSA border than a translatable Type 5 LSA 292 whose network has the same [address,mask] pair and Type-2 293 metric. The link-state ID is equal to the LSA's network 294 address (in the case of multiple originations of Type 5 LSAs 295 with the same network address but different mask, the link- 296 state ID can also have one or more of the range's "host" bits 297 set). 299 (3) Else the Type 5 LSA must be aggregated by the most specific 300 Type 5 range which subsumes it. Compute the path type and 301 metric for this Type 5 range as described below. 303 The path type and metric of the Type 5 range is determined 304 from the path types and metrics of those translatable Type 5 305 LSAs which best match the range plus any locally sourced Type 306 7 LSAs whose network has the same [address,mask] pair. If any 307 of these LSAs have a path type of 2 then the range's path type 308 is 2, otherwise it is 1. If the range's path type is 1 its 309 metric is the highest link state cost amongst these LSAs; if 310 the range's path type is 2 its metric is the highest Type-2 311 metric + 1 amongst these LSAs (See [NSSA] Section 3.5 step 312 (5)). One is added to the Type-2 metric to ensure that the 313 translated Type 7 LSA is not more preferred on the NSSA border 314 than a translatable Type 5 LSA whose network has the same 315 [address,mask] pair and Type-2 metric. 317 A Type 7 LSA is generated from the Type 5 range when there 318 currently is no Type 7 LSA originated by this router whose 319 network has the same [address,mask] pair as the range or there 320 is but either its path type or metric has changed or its 321 forwarding address is non-zero. 323 The newly generated Type 7 LSA will have link-state ID equal 324 to the Type 5 range's address (in the case of multiple 325 originations of Type 7 LSAs with the same network address but 326 different mask, the link-state ID can also have one or more of 327 the range's "host" bits set). The advertising router field 328 will be the router ID of this NSSA border router. The network 329 mask and the external route tag are set to the Type 5 range's 330 configured values. The P-bit will be clear. The forwarding 331 address is set to 0.0.0.0. The path type and metric are set 332 to the Type 5 range's path type and metric as defined above. 334 Note that when a Type 5 range match does occur, the subsequent 335 processing of other translation eligible Type 5 LSAs which best match 336 the Type 5 range is suppressed. Thus at most a single Type 5 LSA is 337 originated for each Type 5 range. 339 For example, given a Type 5 range of [10.0.0.0, 255.0.0.0] which 340 subsumes the following Type 5 routes: 342 10.1.0.0 path type 1, link state cost 10 343 10.2.0.0 path type 1, link state cost 11 344 10.3.0.0 path type 2, metric 5, 346 a Type 7 LSA would be generated with a path type of 2 and a metric 6. 348 Given a Type 5 range of [10.0.0.0, 255.0.0.0] which subsumes the 349 following Type 5 routes: 351 10.1.0.0 path type 1, link state cost 10 352 10.2.0.0 path type 1, link state cost 11 353 10.3.0.0 path type 1, link state cost 5, 355 a Type 7 LSA will be generated with a path type of 1 and a metric 11. 357 The metric and path type rules of type 5 ranges will avoid routing 358 loops in the event that path types 1 and 2 are both used within the 359 OSPF transit topology. 361 Like Type 3 ranges, a Type 5 range performs the dual function of 362 setting propagation policy via its Advertise/DoNotAdvertise parameter 363 and optional aggregation via its network address and mask pair. 364 Unlike Type 3 summary links, Type 5 translation may result in more 365 efficient routing when the forwarding address is set, as may be done 366 during step (2) of the translation procedure. 368 Another important feature of this translation process is that it 369 allows a Type 5 range to apply different properties (aggregation, 370 forwarding address, and Advertise/DoNotAdvertise status) for the Type 371 5 routes it subsumes, versus those Type 5 routes subsumed by other 372 more specific Type 5 ranges contained by the Type 5 range. 374 4.2 Flushing Translated Type 5 LSAs 376 If an NSSA border router has either translated or aggregated an 377 installed Type 5 LSA into a Type 7 LSA and that Type 5 LSA is no 378 longer translatable, then the Type 7 LSA should either be flushed or 379 reoriginated as a translation or aggregation of other Type 5 LSAs. 381 If an NSSA border router is translating Type 5 LSAs into Type 7 LSAs 382 with 384 NSSATranslatorState = elected 386 and the NSSA border router has determined that its translator 387 election status has been deposed by another NSSA border router, then, 388 as soon as the TranslatorStabilityInterval (See [NSSA] Section 4.1) 389 has expired without the router reelecting itself as a translator, any 390 Type 7 LSAs with a 0.0.0.0 forwarding address which were generated by 391 translating Type 5 LSAs are flushed. Conversely Type 7 LSAs with a 392 non-zero forwarding address which were generated by translating Type 393 5 LSAs are not immediately flushed, but are allowed to remain in the 394 NSSA as if the originator is still an elected translator. This 395 minimizes the impact of an NSSA border router which changes its 396 translator status frequently. 398 5.0 Security Considerations 400 This memo does not create any new security considerations for the 401 OSPF protocol. Security considerations for the base OSPF protocol 402 are covered in [OSPF]. 404 6.0 Acknowledgments 406 This document was produced by the OSPF Working Group, chaired by John 407 Moy. 409 Most notably, Alex Zinin of Nexsi is acknowledge for suggesting that 410 translating Type 5 LSAs into Type 7 LSAs would be a useful feature 411 and has provided substantial technical review in the preparation of 412 the document. 414 7.0 References 416 [NSSA] R. Colton, V. Fuller, P. Murphy, "The OSPF NSSA Option", RFC 417 TBD, March 2001. 419 [OSPF] Moy, J., "OSPF Version 2", RFC 2328, Cascade Communications 420 Corp., April 1998. 422 8.0 Authors' Addresses 424 Pat Murphy 425 US Geological Survey 426 345 Middlefield Road 427 Menlo Park, California 94560 429 Phone: (415) 329-4044 430 EMail: pmurphy@noc.usgs.net 432 Appendix A: Configuration Parameters 434 Section 3.1 of this document lists the configuration parameters 435 for Type-5 address ranges. The following area configuration 436 parameter has been added and should be configurable for each 437 directly connected NSSA. 439 UseForwardingAddrresses 441 If set to yes an NSSA router will originate a router-LSA with a 442 clear N/P-bit. Otherwise it will originate a router-LSA with 443 the N/P bit set. On NSSA internal routers the default setting 444 is yes. On NSSA border routers the default setting is yes when 445 the NSSA parameter ImportSummaries is enabled. The default 446 setting is no when ImportSummaries is disabled.