idnits 2.17.1 draft-ietf-ospf-nssa-update-02.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): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == Mismatching filename: the document gives the document name as 'draft-ietf-ospf-nssa-02', but the file name used is 'draft-ietf-ospf-nssa-update-02' == 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 155 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** There are 39 instances of lines with control characters in the document. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 6 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: ---------------------------------------------------------------------------- == Line 819 has weird spacing: '...arvarpu cisco...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (April 1997) is 9870 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) == Unused Reference: '2' is defined on line 829, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1583 (ref. '1') (Obsoleted by RFC 2178) ** Downref: Normative reference to an Historic RFC: RFC 1584 (ref. '2') Summary: 12 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Coltun 3 Internet Draft FORE Systems 4 Expiration Date: July 1997 V. Fuller 5 File name: draft-ietf-ospf-nssa-02.txt BBN Planet 6 P. Murphy 7 US Geological Survey 8 April 1997 10 The OSPF NSSA Option 12 Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress". 24 To learn the current status of any Internet-Draft, please check the 25 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 26 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 27 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 28 ftp.isi.edu (US West Coast). 30 Table Of Contents 32 1.0 Abstract ................................................. 1 33 2.0 Overview ................................................. 2 34 2.1 Motivation - transit networks ............................ 2 35 2.2 Motivation - corporate networks .......................... 3 36 2.3 Proposed Solution ........................................ 4 37 3.0 Implementation Details ................................... 6 38 3.1 The N-bit ................................................ 6 39 3.2 Type-7 Address Ranges .................................... 7 40 3.3 Type-7 LSAs .............................................. 7 41 3.4 Originating Type-7 LSAs .................................. 8 42 3.5 Calculating Type-7 AS External Routes .................... 9 43 3.6 Incremental Updates ...................................... 12 44 4.0 Originating Type-5 LSAs .................................. 13 45 4.1 Translating Type-7 LSAs .................................. 13 46 4.2 Flushing Translated Type-7 LSAs .......................... 16 47 5.0 Acknowledgments .......................................... 17 48 6.0 References ............................................... 17 49 7.0 Security Considerations .................................. 17 50 8.0 Authors' Addresses ....................................... 18 51 Appendix A: Type-7 LSA Packet Format ......................... 19 52 Appendix B: The Options Field ................................ 20 53 Appendix C: Router-LSAs ...................................... 21 54 Appendix D: Configuration Parameters ......................... 23 55 Appendix E: Differences from RFC 1587 ........................ 24 57 1.0 Abstract 59 This memo documents of an optional type of OSPF area which is 60 somewhat humorously referred to as a "not-so-stubby" area (or NSSA). 61 NSSAs are similar to the existing OSPF stub area configuration option 62 but have the additional capability of importing AS external routes in 63 a limited fashion. 65 The OSPF NSSA Option was originally defined in RFC 1587. The functional 66 differences between this memo and RFC 1587 are explained in Appendix D. 67 All differences, while expanding capability, are backward-compatible in 68 nature. Implementations of this memo and of RFC 1587 will interoperate. 70 Please send comments to ospf@gated.cornell.edu. 72 2.0 Overview 74 2.1 Motivation - transit networks 76 Wide-area transit networks (such as the NSFNET regionals) often have 77 connections to moderately-complex "leaf" sites. A leaf site may have 78 multiple IP network numbers assigned to it. 80 Typically, one of the leaf site's networks is directly connected to a 81 router provided and administered by the transit network while the 82 others are distributed throughout and administered by the site. From 83 the transit network's perspective, all of the network numbers 84 associated with the site make up a single "stub" entity. For example, 85 BBN Planet has one site composed of a class-B network, 130.57.0.0, 86 and a class-C network, 192.31.114.0. From BBN Planet's perspective, 87 this configuration looks something like this: 89 192.31.114 90 | 91 (cloud) 92 -------------- 130.57.4 93 | 94 | 95 ------ 131.119.13 ------ 96 |BR18|------------|BR10| 97 ------ ------ 98 | 99 V 100 to BBN Planet "core" OSPF system 102 where the "cloud" consists of the subnets of 130.57 and network 103 192.31.114, all of which are learned by RIP on router BR18. 104 Topologically, this cloud looks very much like an OSPF stub area. The 105 advantages of running the cloud as an OSPF stub area are: 107 1. Type-5 routes (OSPF external link-state advertisements 108 (LSAs)) are not advertised beyond the router labeled 109 "BR10". This is advantageous because the link between 110 BR10 and BR18 may be a low-speed link or the router BR18 111 may have limited resources. 113 2. The transit network is abstracted to the "leaf" router 114 BR18 by advertising only a default route across the link 115 between BR10 and BR18. 117 3. The cloud becomes a single, manageable "leaf" with 118 respect to the transit network. 120 4. The cloud can become, logically, a part of the transit 121 network's OSPF routing system. 123 5. Translated type-5 LSAs that are sent into the backbone 124 from the cloud (which is a separate stub area) may be 125 considered "leaf" nodes when performing the Dijkstra 126 calculation. 128 However, the current definition of the OSPF protocol [1] imposes 129 topological limitations which restrict simple cloud topologies from 130 becoming OSPF stub areas. In particular, it is illegal for a stub 131 area to import routes external to OSPF; it is not possible for 132 routers BR18 and BR10 to both be members of the stub area and to 133 import the routes learned from RIP or other IP routing protocols as 134 type-5 (OSPF external LSAs) into the OSPF system. In order to run 135 OSPF out to BR18, BR18 must be a member of a non-stub area or the 136 OSPF backbone before it can import routes other than its 137 directly-connected network(s). Since it is not acceptable for BR18 to 138 maintain all of BBN Planet's external (type-5) routes, BBN Planet 139 is forced by OSPF's topological limitations to only run OSPF out to 140 BR10 and to run RIP between BR18 and BR10. 142 2.2 Motivation - corporate networks 144 In a corporate network which supports a large corporate infrastructure it 145 is not uncommon for OSPF area 0 to have a large area infrastructure 146 injecting large routing tables into area 0. Organizations within the 147 corporate infrastructure may routinely multi-home their non-0 OSPF areas 148 to strategically located backbone area 0 routers, either to provide 149 backbone redundancy or increase backbone connectivity or both. Because 150 of these large routing tables, OSPF aggregation via summarization is 151 routinely used and recommended. Stub areas are also recommended to keep 152 the size of the non-zero routing tables small. Organizations within the 153 corporation are administratively autonomous and compete for corporate 154 backbone resources. They also want isolation from each other in order 155 protect their own network resources within the organization. 157 Consider a typical backbone connection, as shown on the next page, where 158 routers An, Bn are connected to their respective area n's and routers A0 159 and B0 are border routers to both area 1 and area 2. Serial lines are 160 displayed, but several ethernets, not displayed, may also connect from 161 the connected areas at each router depicted internal to Areas 1 and 2. 162 Assume the 192.243.192/20 and 192.243.208/22 clouds are subnetted with a 163 protocol foreign to the corporate OSPF process. These processes could be 164 RIP, IGRP, or second and third OSPF processes separate from the corporate 165 OSPF backbone process. 167 /---A0-----Area 0(cloud)------B0---\ 168 | | | | 169 56kbs| |T1 19.2 dialup| |T1 170 | | | | 171 | A1-----Area 1(cloud)------B1 | 172 | | T1 T1 | | 173 | T1| |T1 | 174 | \---192.243.192/20 cloud---/ | 175 | | 176 \---A2-----Area 2(cloud)------B2---/ 177 | T1 T1 | 178 | | 179 \---192.243.208/22 cloud---/ 181 As a matter of policy, the corporate network administrators want 182 192.243.192/20 and 192.243.208/22 aggregated to the backbone. This 183 policy conflicts with both Area 1 and Area 2's desire to see the 184 aggregate's subnetted infrastructures learned from Area 1's internal 185 routers A1 and B1 and Area 2's internal routers A2 and B2 from which it 186 can make efficient routing decisions. The current standard OSPF stub 187 area has no mechanism to support the redistribution of routes for 188 192.243.192/20 and 192.243.208/22 subnets within their respective areas. 189 If one assumes that both the Area 1 and Area 2 clouds are extremely large 190 with internally very large routing tables originating from a complex OSPF 191 link state topology and subnetting scheme, neither Area 1 or Area 2 wants 192 to be at the mercy of either the other area's summary links 193 advertisements or external links advertisements. Thus standard OSPF 194 areas are not an option either. 196 Any solution to this dilemma must honor Area 1's path of choice through 197 A0 with redundancy through B0 while at the same time honoring Area 2's 198 path of choice through B0 with redundancy through A0. Furthermore, such 199 a solution must support the aggregation of the externally learned 200 subnetted routing subdomain. 202 2.3 Proposed Solution 204 This document describes a new optional type of OSPF area, somewhat 205 humorously referred to as a "not-so-stubby" area (or NSSA), which has the 206 capability of importing external routes in a limited fashion. 208 The OSPF specification defines two general classes of area configuration. 209 The first allows type-5 LSAs to be flooded throughout the area. In this 210 configuration, type-5 LSAs may be originated by routers internal to the 211 area or flooded into the area by area border routers. These areas, 212 referred to herein as type-5 capable areas (or just plain areas in the 213 OSPF specification), are distinguished by the fact that they can carry 214 transit traffic. The backbone is always a type-5 capable area. The 215 second type of area configuration, called stub, allows no type-5 LSAs to 216 be propagated into/throughout the area and instead depends on default 217 routing to external destinations. 219 NSSAs are defined in much the same manner as existing stub areas. To 220 support NSSAs, a new option bit (the "N" bit) and a new type of LSA 221 (type-7) are defined. The "N" bit ensures that routers belonging to a 222 NSSA agree on its configuration. Similar to the stub area's use of the 223 "E" bit, both NSSA neighbors must agree on the setting of the "N" bit or 224 the OSPF neighbor adjacency will not form. 226 Type-7 LSAs provide for carrying external route information within a 227 NSSA. Type-7 AS External LSAs have virtually the same syntax as the 228 Type-5 AS External LSAs with the obvious exception of the link-state type 229 (see section 3.2 for more details). There are two major semantic 230 differences between type-5 and type-7 LSAs. 232 o Type-7 LSAs may be originated by and advertised throughout 233 a NSSA; as with stub areas, type-5 LSAs are not flooded 234 into NSSAs and do not originate there, except on NSSA border 235 routers. 237 o Type-7 LSAs are advertised only within a single NSSA; they 238 are not flooded into the backbone area or any other area by 239 border routers, though the information which they contain 240 can be propagated into the backbone area (see section 3.6). 242 In order to allow limited exchange of external information across a NSSA 243 border, NSSA border routers will translate selected type-7 LSAs received 244 from the NSSA into type-5 LSAs. These type-5 LSAs will be flooded to all 245 type-5 capable areas. NSSA border routers may be configured with address 246 ranges so that several type-7 LSAs may be represented by a single type-5 247 LSA. The NSSA border routers which perform translation are configurable 248 thus creating efficient forwarding to type-5 LSA originating from 249 aggregated type-7s. 251 In addition, a NSSA border router may originate a default type-7 LSA (IP 252 address of 0.0.0.0) into the NSSA, and must if no NSSA internal type-7 253 default route exists. Default routes are necessary because NSSAs do not 254 receive full routing information and must have a default route to route 255 to AS-external destinations. Like stub areas, NSSAs may be connected to 256 the backbone at more than one area border router, but may not be used as 257 a transit area. Note that the default route originated by a NSSA border 258 router is never translated into a type-5 LSA, however, a default route 259 originated by a NSSA internal AS boundary router (one that is not also an 260 area border router) may be translated into a type-5 LSA. 262 Like stub areas, the importing of OSPF summary routes (type-3 LSAs) into 263 NSSAs is a configuration option. However particular care should be taken 264 to ensure that OSPF internal routes are always chosen over OSPF external 265 (type-7) routes. This may happen when other IGPs, like RIP and ISIS, 266 leak routing information between an OSPF NSSA and another OSPF area. In 267 these cases, all OSPF summary routes should be imported into the effected 268 NSSAs. The recommended default behavior is to import OSPF summary routes 269 into NSSAs. Note that if a type-7 default originates from an internal 270 NSSA router, all summary routes must automatically be imported into the 271 NSSA. This insures that OSPF internal routes are preferred over an 272 internal type-7 LSA default path which may cause inter-AS traffic to exit 273 the AS. 275 In our transit example topologies the subnets of 130.57 and network 276 192.31.114 will still be learned by RIP on router BR18 but now both 277 BR10 and BR18 can be in a NSSA and all of BBN Planet's external routes 278 are hidden from BR18; BR10 becomes a NSSA border router and BR18 becomes 279 an AS boundary router internal to the NSSA. BR18 will import the subnets 280 of 130.57 and network 192.31.114 as type-7 LSAs into the NSSA. BR10 then 281 translates these routes into type-5 LSAs and floods them into BBN 282 Planet's backbone. 284 In our corporate example, the subnets of 192.243.192/20 and 285 192.243.208/22 are learned via their respective routing process, 286 redistributed throughout NSSAreas 1 and 2, and then aggregated during the 287 translation process into a single Type-5 LSA which is flooded into Area 288 0. Area 1 may configure A0 to perform translation with B0 standing by as 289 a backup translator, while Area 2 configures B0 as its translator with A0 290 its backup. 292 3.0 Implementation Details 294 3.1 The N-bit 296 The N-bit ensures that all members of a NSSA agree on the area's 297 configuration. Together, the N-bit and E-bit reflect an interface's 298 (and consequently the interface's associated area) external LSA 299 flooding capability. As explained in section 10.5 of the OSPF 300 specification, if type-5 LSAs are not flooded into/throughout the 301 area, the E-bit must be clear in the option field of the received 302 Hello packets. Interfaces associated with a NSSA will not send or 303 receive type-5 LSAs on that interface but may send and receive type-7 304 LSAs. Therefore, if the N-bit is set in the options field, the E-bit 305 must be cleared. 307 To support the NSSA option an additional check must be made in the 308 function that handles the receiving of the Hello packet to verify that 309 both the N-bit and the E-bit found in the Hello packet's option field 310 match the value of the options that have been configured in the receiving 311 interface. A mismatch in the options causes processing of the received 312 Hello packet to stop and the packet to be dropped. 314 3.2 Type-7 Address Ranges 316 NSSA border routers may be configured with type-7 address ranges. 318 Each address range is defined as an [address,mask] pair. Many 319 separate type-7 networks may then be represented by a single address 320 range, just as a subnetted network is composed of many separate 321 subnets. NSSA border routers may then summarize type-7 routes by 322 advertising a single type-5 route for each type-7 address range. The 323 type-5 route, resulting from a type-7 address range match will be 324 distributed to all type-5 capable areas. Section 4.1 gives the 325 details of generating type-5 routes from type-7 address ranges. 327 A type-7 address range includes the following configurable items. 329 o An [address,mask] pair. 331 o A status indication of either Advertise or 332 DoNotAdvertise. 334 o An external route tag. 336 3.3 Type-7 LSAs: NSSA External Link-State Advertisements 338 External routes are imported into NSSAs as type-7 LSAs by NSSA AS 339 boundary routers. A NSSA AS boundary routers (ASBR) is a router 340 which has an interface associated with the NSSA and is exchanging 341 routing information with routers belonging to another AS. Like ASBRs, 342 a NSSA router indicates it is a NSSA ASBR by setting the E-bit in its 343 router links advertisement. As with type-5 LSAs a separate type-7 LSA 344 is originated for each destination network. To support NSSAs, the 345 link-state database must therefore be expanded to contain a type-7 346 LSA. 348 Type 7-LSAs are identical to type-5 LSAs except for the following 349 (see section 12.4.4 "AS external links" in the OSPF specification). 351 1. The type field in the LSA header is 7. 353 2. Type-7 LSAs are only flooded within the originating NSSA. The 354 flooding of type-7 LSAs follows the same rules as the flooding 355 of type 1-2 LSAs. 357 3. Type-7 LSAs, which are kept within the NSSA's LSDB, are area 358 specific. Type-5 LSAs, which are flooded to all type-5 capable 359 areas, have global scope and are kept in the router's LSDB. 361 4. At the NSSA border router, selected type-7 LSAs are translated 362 into type 5-LSAs and flooded into the backbone. 364 5. Type 7 LSAs have a propagate (P) bit which is used to flag the 365 NSSA border router to translate the type-7 LSA into a type-5 366 LSA. Examples of how the P-bit is used for loop avoidance are 367 in the following sections. 369 6. Those type-7 LSAs that are to be translated into type-5 LSAs 370 must have their forwarding address set. Type-5 LSAs that have 371 been translated from type-7 LSAs for the most part must contain 372 a forwarding address. The exception to this is if the 373 translation to a type-5 LSA is the result of an address range 374 match, in which case the type-5 LSA will not contain a 375 forwarding address (see section 4.1 for details). The 376 forwarding address contained in type-5 LSAs will result in more 377 efficient routing to the AS external networks when there are 378 multiple NSSA border routers. Having the forwarding address in 379 the type-7 LSAs will ease the translation of type-7 into type-5 380 LSAs as the NSSA border router will not be required to compute 381 the forwarding address. 383 If the network between the NSSA AS boundary router and the 384 adjacent AS is advertised into OSPF as an internal OSPF route, 385 the forwarding address should be the next hop address as is 386 currently done in type-5 LSAs, but unlike type-5 LSAs if the 387 intervening network is not advertised into OSPF as an internal 388 OSPF route, the forwarding address should be any one of the 389 router's active OSPF interface addresses. 391 Type-5 and type-7 metrics and path types are directly comparable. 393 3.4 Originating Type-7 LSAs 395 NSSA AS boundary routers may originate type-7 LSAs. All NSSA border 396 routers must also be AS boundary routers since they all must have the 397 capability of translating type-7 LSAs into type-5 LSAs (see section 398 4.1 for the translation algorithm). NSSA border routers must 399 set the E-bit (external bit) as well as the B-bit (border bit) in 400 their router (type-1) LSAs (both in the backbone and in the NSSA). 402 When a NSSA internal AS boundary router originates a type-7 LSA that 403 it wants to be translated into a type-5 LSA by NSSA border routers 404 (and subsequently flooded into the backbone), it must set the P-bit 405 in the LSA header's option field and add a valid forwarding address in 406 the type-7 LSA. 408 If a router is attached to another AS and is also a NSSA border 409 router, it may originate both a type-5 and a type-7 LSA for the same 410 network. The type-5 LSA will be flooded to the backbone (and all 411 attached type-5 capable areas). The type-7 LSA will be flooded into 412 the NSSA. If this is the case, the P-bit must be reset in the type-7 413 NSSA so the type-7 LSA isn't again translated into a type-5 LSA by 414 another NSSA border router. If the border router only originates a 415 type-7 LSA, it may set the P-bit, thus allowing the network to be 416 aggregated/propagated during the type-7 translation. 418 A type-7 default route (network 0.0.0.0) may be originated into the NSSA 419 by a NSSA border router or by a NSSA ASBR which is internal to the NSSA. 420 The type-7 default route originated by the NSSA border router must have 421 the P-bit reset so that the default route originated by the NSSA border 422 router will not find its way out of the NSSA into the rest of the AS 423 system via another NSSA border router. 425 The type-7 default route originated by a NSSA ASBR which is not a NSSA 426 border router may have the P-bit set. Type-7 routes which are originated 427 by a NSSA border router will not get added to the routing tables of other 428 NSSA border routers. If no NSSA internal router originates a type-7 429 default route in the NSSA, then, like stub areas, a type-7 LSA with 430 default destination must be originated by all the NSSA's border routers 431 in order to support inter-area AS routing and inter-AS routing. 433 Note that a NSSA area border router which originates a type-7 434 default route would have to originate a type-5 default route before 435 other NSSA area border routers would see that default route. An 436 internal type-7 default route whose P-bit is not set may only be 437 installed on a NSSA border router when it is the only non-backbone 438 OSPF area connected to it. This restriction protects the default 439 routing of other areas attached to the NSSA border router as well any 440 ISP agreements of the NSSArea. 442 In order for backbone summary internal routes to be preferred over 443 external Type 7 routes, all implementations must support the optional 444 import of summary LSAs from the backbone into a NSSA, with the 445 exception of a (type-3) summary LSA for the default route. The 446 import of summary LSAs is automatically activated when an type-7 447 default route is detected as originating from an internal NSSA ASBR, 448 regardless of the no-summary setting. This protects the NSSA from 449 routing intra-AS traffic out the AS via a type-7 default route. 451 Unlike the stub area case, a default route must not be injected into 452 the NSSA as a summary (type-3) LSA. The reason for this is that the 453 summary default route would be chosen over all more preferred type-7 454 default routes. 456 3.5 Calculating Type-7 AS External Routes 458 This calculation must be run when type-7 LSAs are processed during the AS 459 external route calculation. This calculation will also process type-5 460 LSAs and may replace section 16.4 when processing type-5 LSAs. If 461 section 16.4 is still used to process type-5 LSAs, NSSA ASBR routing 462 table entries are not to be used for the ASBR address calculation of 463 type-5 LSAs. 465 A NSSA border router should examine both type-5 LSAs and type-7 LSAs 466 if either type-5 or type-7 routes need to be updated or recalculated. 467 This is done as part of the AS external route calculation. A NSSA 468 internal router should examine type-7 LSAs when type-7 routes need to 469 be recalculated. When OSPF Section 16.4.1 path preference is applied 470 in step (6.c), NSSA and non-NSSA intra-AS paths have equal 471 preference. 473 What follows is only a modest modification of the OSPF Version 2 474 Specification Section 16.4. Original text is suffixed with . NSSA 475 specific text is suffixed with . 477 AS external routes are calculated by examining AS-external-LSAs, be they 478 type-5 or type-7. Each of the AS-external-LSAs is considered in turn. 479 Most AS-external-LSAs describe routes to specific IP destinations. An 480 AS-external-LSA can also describe a default route for the Autonomous 481 System (Destination ID = DefaultDestination, network/subnet mask = 482 0x00000000). For each AS-external-LSA : 484 (1) If the metric specified by the LSA is LSInfinity, or if the age 485 of the LSA equals MaxAge, then examine the next LSA. 487 (2) If the LSA was originated by the calculating router itself, 488 examine the next LSA. 490 (3) Call the destination described by the LSA N. N's address is 491 obtained by masking the LSA's Link State ID with the 492 network/subnet mask contained in the body of the LSA. Look up 493 the routing table entries (potentially one per attached area) 494 for the AS boundary router (ASBR) that originated the LSA. If 495 no entries exist for router ASBR (i.e., ASBR is unreachable), do 496 nothing with this LSA and consider the next in the list. 498 Else if the destination is a type-7 default route (destination = 499 DefaultDestination) and one of the following is true, then do 500 nothing with this LSA and consider the next in the list: 502 o The originator of the type-7 LSA and the calculating 503 router are both NSSA border routers. 505 o The calculating router is a border router, the LSA has its 506 P-bit clear, and at least two non-backbone OSPF areas 507 connect to the calculating router. 509 Else, this LSA describes an AS external path to destination N. 510 Examine the forwarding address specified in the AS-external-LSA. 512 This indicates the IP address to which packets for the 513 destination should be forwarded. 514 If the forwarding address is set to 0.0.0.0, packets should be 515 sent to the ASBR itself. 517 If the current LSA is type-5, among the multiple non-NSSA ASBR 518 routing table entries for the ASBR (both NSSA and non-NSSA ASBR 519 entries might exists on an NSSA border router), select the 520 preferred entry as follows : 522 If RFC1583Compatibility is set to "disabled", prune the set 523 of routing table entries for the ASBR as described in OSPF 524 Section 16.4.1. In any case, among the remaining routing 525 table entries, select the routing table entry with the least 526 cost; when there are multiple least cost routing table 527 entries the entry whose associated area has the largest OSPF 528 Area ID (when considered as an unsigned 32-bit integer) is 529 chosen. 531 If the forwarding address is non-zero, look up the forwarding 532 address in the routing table. The matching routing table entry 533 must specify an intra-area or inter-area path; if no such path 534 exists, do nothing with the LSA and consider the next in the 535 list. 537 (4) Let X be the cost specified by the preferred routing table entry 538 for the ASBR/forwarding address, and Y the cost specified in the 539 LSA. X is in terms of the link state metric, and Y is a type 1 540 or 2 external metric. 542 (5) Now, look up the routing table entry for the destination N. If 543 no entry exists for N, install the AS external path to N, with 544 the next hop equal to the list of next hops to the 545 ASBR/forwarding address, and advertising router equal to ASBR. 546 If the external metric type is 1, then the path-type is set to 547 Type-1 external and the cost is equal to X + Y. If the external 548 metric type is 2, the path-type is set to Type-2 external, the 549 link-state component of the route's cost is X, and the Type-2 550 cost is Y. 552 (6) Otherwise compare the AS external path described by the LSA with 553 the existing paths in N's routing table entry, as follows. If 554 the new path is preferred, it replaces the present paths in N's 555 routing table entry. If the new path is of equal preference, it 556 is added to N's routing table entry's list of paths. 558 Preference is defined as follows: 560 (a) Intra-area and inter-area paths are always preferred over AS 561 external paths. 563 (b) Type 1 external paths are always preferred over type 2 564 external paths. When all paths are type 2 external paths, 565 the paths with the smallest advertised type 2 metric are 566 always preferred. 568 (c) If the new AS external path is still indistinguishable from 569 the current paths in N's routing table entry, and 570 RFC1583Compatibility is set to "disabled", select the 571 preferred paths based on the intra-AS paths to the 572 ASBR/forwarding addresses, as specified in Section 573 16.4.1. 575 (d) If the new AS external path is still indistinguishable from 576 the current paths in N's routing table entry, select the 577 preferred path based on a least cost comparison. Type 1 578 external paths are compared by looking at the sum of the 579 distance to the forwarding address and the advertised type 1 580 metric (X+Y). Type 2 external paths advertising equal type 581 2 metrics are compared by looking at the distance to the 582 forwarding addresses. 584 (e) If the new paths are still indistinguishable the following 585 priorities apply (listed from highest to lowest) for 586 breaking the tie. 588 a. Any type-5 LSA. 590 b. A type-7 LSA with the P-bit set and the forwarding 591 address non-zero. 593 c. Any other type-7 LSA. 595 3.6 Incremental Updates 597 Incremental updates for type-7 LSAs should be treated the same as 598 incremental updates for type-5 LSAs (see section 16.6 of the OSPF 599 specification). That is, if a new instance of a type-7 LSA is 600 received it is not necessary to recalculate the entire routing table. 601 If there is already an OSPF internal route to the destination 602 represented by the type-7 LSA, no recalculation is necessary. 603 Otherwise, the procedure in the proceeding section will have to be 604 performed but only for the external routes (type-5 and type-7) whose 605 networks describe the same networks as the newly received LSA. 607 4.0 Originating Type-5 LSAs 609 4.1 Translating Type-7 LSAs Into Type-5 LSAs 611 This step is performed as part of the NSSA's Dijkstra calculation after 612 type-5 and type-7 routes have been calculated. If the calculating router 613 is not a NSSA border router this translation algorithm should be skipped. 614 It is not recommended that multiple NSSA border routers perform the 615 translation unless the efficient routing of packets through area 0 to a 616 NSSA partitioned by aggregation requires it. It is normally sufficient 617 to have only one NSSA border router perform the translation. Excessive 618 numbers of type-7 translators unnecessarily increase the size of the OSPF 619 link state data base. 621 A new bit called bit Nt is added to the router links advertisement. All 622 NSSA area border routers which are performing the translation set bit Nt in 623 their router links advertisement into the NSSA. 625 A new parameter called the NSSATranslateState is added to the OSPF area 626 data structure. If a NSSA border router has 628 NSSATranslateState = enabled 630 then this router always translates Type-7 LSAs into Type-5 LSAs for the 631 NSSA. 633 If a NSSA border router has 635 NSSATranslateState = disabled 637 and no NSSA border router for the NSSA has bit Nt set in its router links 638 advertisement and this router has the highest router ID among the NSSA 639 border router set, then this router performs the translation of type-7 640 LSAs into type-5 LSAs for the NSSA and NSSATranslateState should be set 641 to elected. 643 Otherwise the translation algorithm should not be performed and 644 NSSATranslateState should remain set to disabled. 646 Note that during the translation of type-7 LSAs into aggregated type-5 647 LSAs, the highest router ID is not necessarily the best choice for an 648 advertising router as all packets which are forwarded by a type-5 LSA 649 routing table entry originating from an aggregated type-7 LSA translation 650 are sent to the translator (As described below, the forwarding address is 651 not set in type-5 LSAs which originate from aggregated type-7 LSAs). The 652 NSSATranslateState allows the network designer to configure the most cost 653 effective route to the NSSA's type-5 LSAs which originate from the 654 aggregation of type-7 LSAs. Is cases of aggregate partitioning of the 655 NSSA, multiple translators may be required to effect efficient routing. 657 Indeed, all NSSA border routers could be set to perform translation, if 658 required. 660 All installed type-7 LSA's should be examined including those type-7s 661 originated by the router itself (a set which may differ between NSSA 662 border routers of the same NSSArea). This allows NSSA border routers to 663 propagate and/or aggregate locally originated type-7s during the 664 translation. Locally originated type-7s are skipped during the external 665 route calculation. Their installation status is external to OSPF. 667 If the type-7 LSA (associated with the route being examined) has the 668 P-bit set and a non-zero forwarding address, the following steps 669 should be taken. 671 The translation procedure must first check for a configured type-7 672 address range. Recall that a type-7 address range consists of an 673 [address,mask] pair and a status indication of either Advertise or 674 DoNotAdvertise. At most a single type-5 LSA is made for each 675 range. If the route being examined falls within the type-7 676 address range, (i.e., the [address,mask] pair of the route is 677 equal to or a more specific instance of the [address,mask] pair of 678 the type-7 address range), one of following three actions may take 679 place. 681 1. When the range's status indicates Advertise and the route's 682 address and mask are equal to the address and mask of the 683 type-7 range, a type-5 LSA should be originated if 685 o there currently is no type-5 LSA originated from this 686 router corresponding to the type-7 LSA, or there is and 688 o the path type or the metric in the corresponding type-5 689 LSA is different from the type-7 LSA or 691 o the forwarding address in the corresponding type-5 LSA is 692 different from the type-7 LSA. 694 The newly originated type-5 LSA will describe the same 695 network and have the same network mask, metrics, forwarding 696 address, external route tag and path type as the type-7 LSA, 697 however, the advertising router field will be the router ID 698 of this area border router. 700 2. When the range's status indicates Advertise and the route's 701 address or mask indicates a more specific route (i.e., the 702 route's address is subsumed by the range or the route has a 703 longer mask), a type-5 LSA is generated with link-state ID 704 equal to the range's address (if necessary, the link-state 705 ID can also have one or more of the range's "host" bits set; 706 see Appendix F of the OSPF specification for details), the 707 network mask, external route tag and path type will be set 708 to the configured type-7 range values. The advertising 709 router field will be the router ID of this area border 710 router. The forwarding address will not be set. The path 711 type should always be set to the highest path type that is 712 subsumed by the net range. The metric for the type-5 LSA 713 will be set as follows: 715 o if the path type is external type 2, the type-5 metric 716 should be set to the largest type-7 metric subsumed by 717 this net range + 1. 719 o if the path type is external type 1, the type-5 metric 720 should be set to the largest metric. 722 For example, given a net range of [10.0.0.0, 255.0.0.0] for 723 an area that has type-7 routes of: 725 10.1.0.0 path type 1, metric 10 726 10.2.0.0 path type 1, metric 11 727 10.3.0.0 path type 2, metric 5 729 a type-5 LSA will be generated with a path type of 2 and a 730 metric of 6. 732 As another example, given a net range of [10.0.0.0, 733 255.0.0.0] for an area that has type-7 routes of: 735 10.1.0.0 path type 1, metric 10 736 10.2.0.0 path type 1, metric 11 737 10.3.0.0 path type 1, metric 5 739 a type-5 LSA will be generated with a path type of 1 and a 740 metric of 11. 742 These metric and path type rules will avoid routing loops in 743 the event that path type 1 and 2 are both used within the 744 area. 746 3. When the range's status indicates DoNotAdvertise, the type-5 747 LSA is suppressed and the component networks remain hidden 748 from the rest of the AS. 750 By default (given that the P-bit is set and the LSA has a non-zero 751 forwarding address) if a network is not contained in any 752 explicitly configured address range, a type-7 to type-5 LSA 753 translation will occur. 755 A new instance of a type-5 LSA should be originated and flooded to 756 all attached type-5 capable areas if 758 o there currently is no type-5 LSA originated from this 759 router corresponding to the type-7 LSA, or there is and 761 o the path type or the metric in the corresponding type-5 762 LSA is different from the type-7 LSA or 764 o the forwarding address in the corresponding type-5 LSA is 765 different from the type-7 LSA. 766 The newly originated type-5 LSAs will describe the same network 767 and have the same network mask, metrics, forwarding address, 768 external route tag and path type as the type-7 LSA. The 769 advertising router field will be the router ID of this area border 770 router. 772 As with all newly originated type-5 LSAs, a type-5 LSA that is the 773 result of a type-7 to type-5 translation (type-7 range or default 774 case) is flooded to all attached type-5 capable areas. 776 4.2 Flushing Translated Type-7 LSAs 778 If a NSSA border router has translated a type-7 LSA to a type-5 LSA that 779 should no longer be translated, the type-5 LSA should be flushed (set to 780 MaxAge and flooded). The translated type-5 LSA should be flushed 781 whenever the routing table entry that caused the translation changes so 782 that either the routing table entry is unreachable or the entry's 783 associated LSA is not a type-7 with the P-bit set and a non-zero 784 forwarding address. 786 If a NSSA border router is translating type-7 LSA's into type-5 LSA's and 788 NSSATranslateState = elected 790 and a new router links advertisement arrives in the NSSA with bit Nt set, 791 then it should flush any of its type-5 LSAs originating from translated 792 type-7 LSAs and readvertise its router links advertisement into the NSSA 793 with bit Nt clear. 795 This flushing keeps the number of type-7 translators at the minimum 796 number configured, either explicitly or by default. Since the default 797 translator election process only occurs in the absence of a translator, 798 should a router with a higher router ID join the NSSA border router set 799 it will not necessarily assume translator duties. Indeed, a previously 800 default elected translator should continue to perform translation duties 801 until supplanted by an NSSA border router whose Nt bit is set to true. 802 Such an event might happen due to by setting the NSSATranslateState to 803 enabled or a topological rejoining of a partitioned NSSA. This behavior 804 reduces the flushing of translated type-7 LSA's in the AS. 806 Any change in the membership of the NSSA border router set or the setting 807 of their Nt bits resulting from updated router links advertisements 808 should force a NSSA border router whose NSSATranslateState is not set to 809 recheck and possibly elect or disable its type-7 translation status. 811 5.0 Acknowledgments 813 This document was produced by the OSPF Working Group, chaired by John 814 Moy. 816 In addition, the comments of the following individuals are also 817 acknowledged: 819 Phani Jajjarvarpu cisco 820 Dino Farinacci cisco 821 Jeff Honig Cornell University 822 John Moy Proteon, Inc. 823 Doug Williams IBM 825 6.0 References 827 [1] Moy, J., "OSPF Version 2", RFC 1583, Proteon, Inc., March 1994. 829 [2] Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon, Inc., 830 Proteon, Inc., March 1994. 832 7.0 Security Considerations 834 Security issues are not discussed in this memo. 836 8.0 Authors' Addresses 838 This update uses much of the original text from RFC 1587 authored by 840 Rob Coltun 841 Fore Systems 842 6905 Rockledge Drive 843 Suite 800 844 Bethesada, Maryland 20817 846 Phone: (301) 571-2521 847 EMail: rcoltun@fore.com 849 Vince Fuller 850 BBN Planet 851 3801 East Bayshore Road 852 Palo Alto, California 94303 854 Phone: (415) 528-7227 855 EMail: vaf@wr.BBNPlanet.com 857 New Sections, edits and revisions are authored by 859 Pat Murphy 860 US Geological Survey 861 345 Middlefield Road 862 Menlo Park, California 94560 864 Phone: (415) 329-4044 865 EMail: pmurphy@usgs.gov 867 in support of the new features suggested by Pat Murphy. 869 Appendix A: Type-7 Packet Format 871 0 32 872 ----------------------------------- 873 | | OPTS | 7 | 874 | ------------------ 875 | Link-State Header | 876 | | 877 ----------------------------------- 878 | Network Mask | 879 ----------------------------------- ______ 880 |E| Tos | metric | . 881 ----------------------------------- . repeated for each TOS 882 | Forwarding Address | . 883 ----------------------------------- . 884 | External Route Tag | ______ 885 ----------------------------------- 887 The definitions of the link-state ID, network mask, metrics and 888 external route tag are the same as the definitions for the type-5 889 LSAs (see A.4.5 in the OSPF specification) except for: 891 The Forwarding Address 893 If the network between the NSSA AS boundary router and the adjacent 894 AS is advertised into OSPF as an internal OSPF route, the forwarding 895 address should be the next hop address but if the intervening network 896 is not advertised into OSPF as an internal OSPF route, the forwarding 897 address should be any one of the router's active OSPF interface 898 addresses. 900 Appendix B: The Options Field 902 The OSPF options field is present in OSPF Hello packets, Database 903 Description packets and all link-state advertisements. See appendix 904 A.2 in the OSPF specification for a description of option field. Six 905 bits are assigned but only two (the E-bit and the N/P bit) are 906 described completely in this section. 908 -------------------------------------- 909 | * | * | DC | EA | N/P | MC | E | T | 910 -------------------------------------- 912 The Type-7 LSA options field 914 E-bit: Type-5 AS external link advertisements are not 915 flooded into/through OSPF stub areas and NSSAs. 916 The E-bit ensures that all members of a stub area 917 agree on that area configuration. The E-bit is 918 meaningful only in OSPF Hello packets. When the 919 E-bit is reset in the Hello packet sent out a 920 particular interface, it means that the router 921 will neither send nor receive type-5 AS external 922 link state advertisements on that interface (in 923 other words, the interface connects to a stub 924 area or NSSArea). Two routers will not become 925 neighbors unless they agree on the state of the 926 E-bit. 928 N-bit: The N-bit describes the router's NSSArea 929 capability. The N-bit is used only in Hello 930 packets and ensures that all members of a NSSArea 931 agree on that area's configuration. When the 932 N-bit is set in the Hello packet and sent out a 933 particular interface, it means that the router 934 will send and receive type-7 LSAs on that 935 interface. Two routers will not form an adjacency 936 unless they agree on the state of the N-bit. If 937 the N-bit is set in the options field, the E-bit 938 must be reset. 940 P-bit: The P-bit is used only in the type-7 LSA header. 941 It flags the NSSA border router to translate 942 the type-7 LSA into a type-5 LSA. 944 Appendix C: Router-LSAs 946 Router-LSAs are the Type 1 LSAs. Each router in an area originates a 947 router-LSA. The LSA describes the state and cost of the router's links 948 (i.e., interfaces) to the area. All of the router's links to the area 949 must be described in a single router-LSA. For details concerning the 950 construction of router-LSAs, see the OSPF Specification, Section 12.4.1. 952 0 1 2 3 953 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 955 | LS age | Options | 1 | 956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 957 | Link State ID | 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 | Advertising Router | 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 | LS sequence number | 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 | LS checksum | length | 964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 | 0 Nt|W|V|E|B| 0 | # links | 966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 | Link ID | 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 | Link Data | 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 971 | Type | # TOS | TOS 0 metric | 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 | TOS | 0 | metric | 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 | ... | 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 | TOS | 0 | metric | 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 | Link ID | 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 | Link Data | 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 | ... | 985 In router-LSAs, the Link State ID field is set to the router's OSPF 986 Router ID. The T-bit is set in the LSA's Option field if and only 987 if the router is able to calculate a separate set of routes for each 988 IP TOS. Router-LSAs are flooded throughout a single area only. 990 bit V 991 When set, the router is an endpoint of one or more fully 992 adjacent virtual links having the described area as Transit area 993 (V is for virtual link endpoint). 995 bit E 996 When set, the router is an AS boundary router (E is for 997 external). 999 bit B 1000 When set, the router is an area border router (B is for border). 1002 bit W 1003 When set, the router is a wild-card multicast receiver (W is for 1004 for wild). 1006 bit Nt 1007 When set, the router is a NSSA border router which translates type-7 1008 LSAs into type-5 LSAs (Nt is for NSSA translation). 1010 The remainder of the router links specification is as defined in the OSPF 1011 Specification, Section A.4.2 1013 Appendix D: Configuration Parameters 1015 Appendix C.2 in the OSPF specification lists the area parameters. The 1016 area ID, list of address ranges for type-3 summary routes and 1017 authentication type remain unchanged. Section 3.2 of this document lists 1018 the configuration parameters for type-7 address ranges. The following 1019 parameter is added to the NSSArea data structure: 1021 NSSATranslateState 1022 This parameter indicates whether or not an NSSA Border router is 1023 performing NSSA translation of type-7 LSAs into type-5 LSAs and 1024 flooding the translated type-5 LSAs into the AS. If the parameter is 1025 set to "enabled", translation is always performed. If the parameter 1026 is set to "elected", it means translation is being performed because 1027 the router was chosen during the default election process. If the 1028 parameter is set to "disabled" the NSSA border router is not 1029 currently performing type-7 translation. "disabled" is the default 1030 setting. (See Section 4.1.) 1032 For NSSAs the external capabilities of the area must be set to accept 1033 type-7 external routes. Additionally there must be a way of 1034 configuring the NSSA border router to send a default route into the 1035 NSSArea using a specific metric (type 1 or type 2 and the actual cost). 1037 Appendix E: Differences from RFC 1587 1039 This section documents the differences between this memo and RFC 1040 1587. All differences are backward-compatible. Implementations of 1041 this memo and of RFC 1587 will interoperate. 1043 E.1 Enhancements to OSPF summary LSAs. . 1045 The flooding of backbone summary LSAs (type-3 LSAs) into the NSSA 1046 is now optional. In RFC 1587 the flooding of backbone summary 1047 LSAs was mandated in order to guarantee inter-area routes are 1048 preferred over external routes. The current recommended default 1049 behavior is to flood summary LSAs. 1051 See sections 2.2 and 3.4 for details. 1053 E.2 Changes to the type-7 AS external routing calculation. 1055 The type-7 external route calculation has been revised. Most 1056 notably: 1058 o The path preference defined in OSPF Section 16.4.1 has been 1059 included. 1061 o A type-7 default route with the P-bit clear will not be installed 1062 on a NSSA border router which connects multiple non-backbone 1063 areas. This protects the default routing of other OSPF Areas as 1064 well as any ISP agreements of the originating NSSArea. 1066 o The type-7 AS external route calculation may now compute 1067 type-5 external paths. 1069 See Section 3.5 for details. 1071 E.3 Changes to translating type-7 LSAs into type-5 LSAs 1073 NSSA border routers which perform the translation are now optionally 1074 configurable, with more than one allowed. This allows the network 1075 designer to choose the most cost effective intra-AS route for NSSA 1076 type-7 aggregates propagated into the AS. Furthermore, since 1077 different NSSA border routers may install different sets of type-7 1078 LSA routes, the cost effectiveness of non-aggregated type-7 1079 propagation may also be maximized. 1081 All installed type-7 LSA's including those originated by the NSSA 1082 border router are processed for translation. This allows the 1083 NSSA border router to propagate and/or aggregate locally 1084 originated type-7s utilizing the type-5 translation process. 1085 NSSA RFC 1587 required locally originated type-7 LSAs be paired 1086 with locally originated type-5 LSAs for the external path to be 1087 seen by the AS (Note that locally originated type-7s are skipped 1088 during the external route calculation). 1090 The default translator election process occurs only in the absence of 1091 a translator amongst the NSSA border router set. 1093 See Section 4.1 for details. 1095 E.4 Changes to flushing translated type-7 LSAs 1097 A NSSA border router which was elected by the default selection 1098 process of RFC 1587, terminates its translation duties and flushes 1099 its translated type-7 LSAs from the AS when another translator 1100 presents itself in the NSSA. This keeps the number of translators at 1101 a minimum. 1103 See Section 4.2 for details.