idnits 2.17.1 draft-berkowitz-ospfdeploy-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): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 649 lines 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 63 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 45: '...static routes) MUST IMPLEMENT OSPF.....' RFC 2119 keyword, line 46: '...router MAY implement additional IGPs...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 45 has weird spacing: '... static rout...' == Line 91 has weird spacing: '... static route...' == Line 241 has weird spacing: '...f areas withi...' == Line 482 has weird spacing: '...support that ...' == Line 517 has weird spacing: '...route to the ...' == (1 more instance...) -- 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 1998) is 9538 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: 'RFC1812' is defined on line 621, but no explicit reference was found in the text == Unused Reference: 'RFC2178' is defined on line 624, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2178 (Obsoleted by RFC 2328) -- No information found for draft-berkowitz-multirqmt - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Multihome' Summary: 12 errors (**), 0 flaws (~~), 10 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group H. Berkowitz 2 Internet Draft Chesapeake Computer Consultants 3 Expiration Date: September 1998 March 1998 5 Techniques in OSPF-based Network Deployment 6 draft-berkowitz-ospfdeploy-00.txt 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference 18 material or to cite them other than as ``work in progress.'' 20 To learn the current status of any Internet-Draft, please check the 21 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 22 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 23 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 24 ftp.isi.edu (US West Coast). 26 1. Abstract 28 OSPF is the preferred interior routing protocol of the Internet. It is 29 a complex protocol intended to deal with complex networks. While it is 30 a powerful mechanism, it does not handle all situations, and its 31 appropriate use may not be obvious to beginners. Standards track documents 32 deal with protocol design, but deployment of OSPF in many enterprise 33 networks has been limited by lack of information on best current practice 34 information for interior routing. Best Current Practices documents have 35 focused on general exterior connectivity. This memorandum is intended to 36 complement the protocol specification by describing the experience-based, 37 vendor-independent techniques of OSPF and complementary technologies in 38 representative networks. Better understanding of the use of OSPF features 39 to help exterior connectivity will help reduce the demand for complex user 40 BGP configuration. 42 2. Introduction 44 RFC1812, Requirements for IPv4 Routers, says "a router that implements any 45 routing protocol (other than static routes) MUST IMPLEMENT OSPF... A 46 router MAY implement additional IGPs." This is a well-crafted 47 statement, as it recognizes that static may be a useful complement to OSPF. 49 All too often, network operators work from the limiting belief that if they 50 use OSPF, it must run everywhere in their networks. They see the two-level 51 hierarchy suggested by an Area 0 and a subordinate set of nonzero areas, 52 and assume that networks using OSPF must be strictly hierarchical with only 53 two hierarchical levels. 55 3. Barriers to Understanding OSPF Deployment 57 3.1 OSPF and Autonomous Systems 59 OSPF specifications assume an enterprise's set of networks equate to an 60 autonomous system. These specifications use the term autonomous system 61 in a manner inconsistent with the current usage, which speaks of an AS 62 in terms of exterior routing. RFC1930 defines an AS as a set of 63 routers, under one or more administrations, that presents a common 64 routing policy to the global Internet. 66 It is useful to define an OSPF domain as an Area 0 and some number of 67 nonzero areas. In the broader sense, a routing domain is a set of 68 routers, with a common set of routing mechanisms and routing policies, 69 under a single administration. 71 A general observation: OSPF has a terminology problem here. "Inter- 72 zone" communication is the role of what OSPF calls a "Autonomous System 73 Border Router," but the "zones" don't need, in reality, to be distinct 74 AS. A term from the routing literature that probably is more recognized 75 than "AS" or "zone" is "routing domain." 77 OSPF has a built-in mechanism for connecting different domains, the 78 ASBR. ASBRs interconnect routing domains. Any OSPF router 79 that advertises external routes is an ASBR. Examples include: 81 1. An OSPF process that accepts routes from another separate 82 OSPF process: 84 2. An OSPF process that accepts routes from another dynamic interior 85 routing process: 87 Another option is to have static routes going to an 88 enterprise core network 89 from each OSPF Area 0, such that the Area 0's advertise the default 90 route into their subordinate areas, but the ASBR containing the 91 static route advertises the default into Area 0. 93 3. An OSPF process that accepts static routes and advertises the 94 default. 96 4. An OSPF process that accepts routes from a BGP exterior routing 97 process and advertises them into OSPF. Details of this are 98 not shown, because configurations involving redistribution to 99 and from OSPF usually involve fairly complex filtering and other 100 mechanisms to avoid loops and injections of huge numbers of 101 routes. 103 3.2 Thinking about Externals 105 The path determination workload of an OSPF area is influenced most 106 strongly by the number of network, summary, and external LSAs involved 107 in the routing computation. The various stub area schemes, stub, not- 108 so-stubby, and the vendor-specific totally stubby, all help when a large 109 number of externals would be injected into an area. 111 In medicine, there is a classic piece of advice from a physician to a 112 patient who complains that some odd movement of his arm hurts: if that 113 hurts, don't do it. If the nature of a routing environment is such that 114 large numbers of externals do not exist, then there is no benefit to 115 exploring stub area techniques to control the propagation of externals. 117 Most beginners tend to think of floods of externals into OSPF due 118 primarily to Internet connectivity. They imagine nearly 50,000 routes of 119 a current Internet default-free routing table overwhelming their 120 routers. In practice, it would be extremely unlikely to find any 121 significant benefit would come from injecting such a table into the OSPF 122 routing system. In most cases, no more than a default route needs to 123 injected to achieve connectivity. Even if preferential exits for 124 certain exterior destinations are desired, that is more likely to be an 125 Interior BGP problem than an OSPF one. 127 In practice, a major source of external routes can come from one's own 128 enterprise, as part of a migration from RIP or IGRP, or from 129 static/default routes used to connect edge routers to the main routing 130 system. Another way to think of this is that large numbers of external 131 routes can come from other routing domains in your own organization. 133 If the intra-organizational external routes are injected into OSPF 134 through ASBRs connected to Area 0, stub techniques may be effective in 135 controlling the number of externals that impose workload on nonzero 136 areas. Even in this case, do summarize the externals as much as 137 possible. 139 More challenging situations arise when the intra-organizational routes 140 come in at the edge of a nonzero area. Assume, for example, that an 141 organization has a large number of small offices, each with a single 142 frame relay PVC that carries its traffic to the next level of the 143 corporate routing hierarchy. Each of the small edge routers needs a 144 default route toward the next level. 146 The next level, however, is composed of OSPF-speaking routers. Even though 147 they are in a nonzero area, they are still ASBRs. Since these routers will 148 not speak OSPF to the edge routers, these second-level routers will need to 149 have static routes that point to these edge subnets, and then the static 150 routing information needs to be advertised as external routes into OSPF. 151 Remember that these externals can be summarized on the ASBR. 153 3.3 Hierarchy and OSPF 155 It should never be forgotten there are two ways to achieve hierarchy and 156 aggregation: address summarization, and physical topology. Many newcomers 157 to OSPF think only of the first, since OSPF summarizes on ABRs and ASBRs. 158 This leads to an incorrect assumption that OSPF has at best three levels of 159 hierarchy: 161 1. Intra-area 162 2. Inter-area 163 3. External 165 It is true that reduction in routing information and consequent reduction 166 of the routing computation workload only can come at these levels. But 167 there are other benefits of hierarchy, such as minimizing hop count, 168 simplifying debugging as opposed to complex meshes, etc. 170 Inside a nonzero area, it is perfectly reasonable to have a hierarchy of 171 internal routers, leading up to area border routers at the apex of the area 172 hierarchy. Several small OSPF speakers at "branch offices" might single- 173 or dual home to "district level" interior routers. Groups of district 174 routers might in turn single or dual home to regional routers, and groups 175 of regional routers might single or dual home to area border routers. 177 Hierarchy can begin anew inside area 0. ABRs can be concentrated 178 topologically by homing to backbone routers, and the backbone routers may 179 in turn home on ASBRs. 181 A higher-level, non-OSPF core network may usefully link the top 182 hierarchical ASBRs of multiple OSPF routing domains. Such a core network 183 could be statically routed or use BGP. 185 3.4 Virtual Links 187 A virtual link is a tunnel that has at least one end in Area 0. Virtual 188 Links (VL) are a mechanism that can be used within OSPF to handle 189 certain connectivity patterns. The standard is a bit "soft" on their 190 applications, and support engineers have seen a variety of VL 191 applications. For some of the problems being raised, it appears better 192 OSPF solutions may exist. 194 A matter of particular interest is the potential advantages of NSSAs 195 over some of the VL solutions to bringing in a new "community of 196 interest." See the discussion below of VL applicability in other than 197 backbone robustness. 199 The perception of virtual links' untility seems to be as a means of 200 accomodating specical connectivity requirements "inside" a single "OSPF 201 domain," the latter defined as a set of an Area 0 and some number of 202 nonzero areas. 204 In some of these requirements, virtual links may be completely 205 appropriate, one of several potential solutions, or definitiely not an 206 appropriate solution. 208 Some designers may use virtual links to avoid other mechanisms that they 209 do not like, such as defining the enterprise's network with multiple 210 interconnected OSPF domains. 212 Virtual links are not necessarily the appropriate solution, but cases 213 have been seen where they are used for: 215 --- Protecting against Area 0 partitioning 216 --- Making one area 0 following the merger of two enterprises, 217 both of which ran independent OSPF 218 --- Providing connectivity to a newly acquired enterprise 219 whose best connectivity is to a router in a nonzero area 220 of the acquiring enterprise 222 4. Area Sizing and Numbering Strategies 224 4.1 Communities of Interest 226 Select a set of clients and servers that primarily speak to one another. 227 Is the number of routers required, after growth projections have been 228 applied, less than the vendor-recommended limit? 230 Let's review basic OSPF, emphasizing points that can help establish 231 hierarchies of more than two levels. Let's also review some sizing 232 considerations for areas, bearing in mind 233 that this can be as much art and science. Experienced routing designers 234 know they won't always hit the correct area structure, and expect to 235 have to monitor and tune the design of a large OSPF system. Especially 236 experienced routing designers know this tuning will primarily involve 237 topology and bandwidth, rather than "knob twisting" for timers and 238 buffers. 240 The guideline about limiting the number of nonzero areas in an ABR, in 241 practice, means that large numbers of areas within a single OSPF system 242 tend to require large and expensive numbers of ABRs. This is especially 243 true attempting to avoid a single point of failure -- a single ABR -- 244 per area. 246 Many factors go into choosing the number of OSPF speakers inside an 247 area. A few conservative guidelines for these and other sizing 248 considerations: 250 1. Begin setting up area definitions based on communities of interest. 251 It is highly desirable if the majority of traffic can stay intra-area. 253 2. Do not exceed your vendor guidelines on routers per nonzero area. 254 Counts from 50 to 200 routes are often cited, although much larger numbers 255 have worked in specific environments. Use the lower numbers when media 256 tend to "bounce" up and down. As we will see below, this doesn't preclude 257 a large number of routers in what can be considered an area, because the 258 "stub" routers need not speak OSPF. 259 This is conservative, and many vendor implementations have wored 260 well with larger numbers of OSPF speakers per area. The specific limit will 261 vary with the OSPF software implementation, the processing power of the 262 router platform, and the size and stability of the topological database. 263 If areas defined on community of interest contain too many routers 264 under rule #2, consider splitting the area. Look for geographic/provider 265 natural boundaries for splitting. 267 3. Think carefully about the relationships you want between the 268 backbone and each non-backbone area. Some small OSPF environments put 269 everything into Area 0. This can be reasonable if the only reasons for 270 using OSPF are fast convergence and flexible addressing among a small set 271 of routers. The power of OSPF is only fully realized with multiple areas. 273 4. Area 0 is intended as a transit area. Capacity planning and 274 troubleshooting tend to be easiest when there are no application servers in 275 area 0. Given the connectivity of area 0, it may be reasonable to place 276 network management or DNS servers there. 277 If the application topology is hierarchical, as might be found where 278 a mainframes or server farms provides most application services, still use 279 caution in putting this server in area 0. Mainframes or server farms often 280 have local inter-server communications, such as backup, that should be kept 281 out of area 0. It may be wise to put the central servers in a small area 282 of their own. 284 5. Several techniques exist for setting up areas and controlling 285 advertisements in and out of them. You don't need to use the same 286 techniques in every nonzero area. Remember that you don't use these 287 simply to reduce the amount of routing traffic, but also for stability. 288 Stability increases as the number of routing table recomputations 289 decreases. 291 Summarization and the various kinds of stub areas reduce routing table 292 recomputation by hiding specific routes. In other words, an 293 interior router in Area 1, doesn't need to recompute the Area 1 294 routing table if a link goes up or down in Area 0. Media, especially, 295 have a habit of bouncing up and down; hiding links outside my area 296 reduces "route flapping" leading to recomputation. 298 An Area Border Router between Area 1 and Area 0 probably needs 299 to know if a link in Area 0 changes state, but it doesn't need to 300 know if a link in Area 51 changes state. The exception to this case is 301 where finding the absolutely optimal path from Area 1 to Area 0 to Area 51 302 is more important than stability. This might be the case in some 303 international networks with low-bandwidth links. 305 The reason to use the less general types of areas is they allow reducing 306 the amount of routing information advertised from the backbone into 307 nonzero areas. 309 Inside a given area, be it backbone or non-backbone, there can be a 310 hierarchy among OSPF speakers. For example, it is perfectly reasonable 311 to reduce the peering in the backbone by connecting the Area 0 side of 312 ABRs to "collapsed backbone" router(s). In large 313 networks, it can avoid problems due to excessive numbers of neighbors to 314 any given Area 0 router. 316 4.2 Numbering 318 There is a widespread misperception that areas will only work with a single 319 contiguous address range. Even a small amount of summarization, however, 320 will considerably increase the stability of OSPF systems because it hides 321 route flap. 323 A common recommendation, assuming that a single contiguous block, such as 324 an /18 prefix is given to the enterprise, is to "bit split" the prefix such 325 that the first high-order bits below the global prefix identifies the area. 326 For a routing domain with four nonzero areas, this would allocate a /20 327 prefix to each area: 329 /20 starting 00xxxx... area 1 330 starting 01xxxx... area 2 331 starting 10xxxx... area 3 332 starting 11xxxx... area 4 334 This approach seems straightforward, but suffers from several limitations. 336 First, what about area 0? No space has been left for it. In any case, it 337 is likely that a /20 assigned to area 0 would waste a great deal of space, 338 since area 0 should have a small number of router interfaces in it. 340 One technique when using the bit-split method, and assuming registered 341 addresses are used in the nonzero areas, is to use RFC1918 private address 342 space for area 0. This can be quite reasonable, because there are few 343 legitimate reasons why an arbitrary external Internet host would need to 344 access a backbone interface internal to an enterprise network. One 345 possible criticism of this approach is that traceroutes that traversed the 346 backbone might show the private address space, but it is usually apparent 347 when this is happening. Another reason why area 0 interfaces might need 348 registered addresses is that the management of the network is outsourced. 349 In outsourcing situations, the service provider commonly can assign some of 350 its allocated address space for interfaces it will manage, 352 Another and more general approach is to bit-split to a level deeper than 353 the number of areas. In the example above, there were 4 nonzero areas, and 354 4 /20 blocks. The /20 comes from it being the first power of two that can 355 contain 4 areas. 357 Consider, however, going 2 or 3 powers of two deeper. Divide the available 358 address space into 8, 16, or 32 blocks. These, respectively, would be /21, 359 /22, or /23 address prefixes. 361 One of these blocks can be assigned to Area 0. It is a reality that the 362 number of users in individual areas will vary, so area 1 might, for 363 example, need three /21 blocks, area 2 might need two such blocks, area 1 364 might need one. Several blocks can be reserved for growth as needed. 366 These blocks can still be summarized to avoid route flap. 368 5. Increasing Backbone Reliability 370 A failure in Area 0 is critical. 372 A single Area 0 has a single point of failure. Hopefully, the ASCII 373 graphic shows this. Area 0 has two interconnected Border Routers, BR1 374 and BR2. To avoid single router points of failure, there are two ABRs, 375 each with three interfaces: Area 0, Area 1, and Area 2. 377 5.1 VL Solution 379 If the BR1-BR2 link fails, a VL can be defined between the Area 1 380 interface of ABR-1 and between the Area 1 interface of ABR-2. This 381 reconstitutes backbone connectivity with a tunnel through Area 1. 383 BR1------------------------------------------BR2 384 \ / 385 \ ...to BR2 / 386 ABR-1 ABR-2--/ ABR-3 387 ========================================================= 388 | | | * | 389 | |------- * | 390 | VL? * | 391 | * | 392 v * v 393 Area 1 * Area 2 395 5.2 Alternative using Adding Circuit(s) 397 The preferred way to solve this problem is adding a parallel link 398 between BR1 and BR2. Especially if these links can be per-packet load 399 balanced, convergence would be extremely fast. 401 This solution, however, incurs additional cost for the additional 402 circuit. Balanced against this cost is the performance impact the VL 403 would have on the routers and links in the nonzero area through which 404 the VL is tunneled. Those routers and links may have been engineered for 405 the traffic estimates and performance goals under the workload of that 406 single area, not of that area with backbone traffic added to it. 408 5.3 Alternative using non-OSPF network 410 An alternative approach, especially useful if demand OSPF is not 411 available, is to split Area 0 and create two OSPF domains. Each domain 412 has a static route that points to the address range in the other domain. 413 This route is advertised into the local domain as a Type 1 external. 415 6. Backbones of Backbones 417 The method described in 5.3 above can be generalized to give more 418 effective levels of hierarchy in an overall network that uses OSPF for 419 its dynamic routing. 421 True, OSPF's area structure has two levels, Area 0 and everything else. 422 A routing architecture for an enterprise that uses OSPF, however, can be 423 more than a simple hierarchy of backbone and non-backbone areas. We can 424 extend its notion of hierarchy both above Area 0 and below the nonzero 425 areas. Even inside an area, there are some forms of hierarchy. 427 Such an architecture also lends itself to evolution to an ATM service in 428 the core. It can also be reasonable to have interior routers that 429 "concentrate" traffic, or act as collapsed backbones within an area. 431 It is also perfectly reasonable to have a broader OSPF routing 432 environment, in which some routers do not speak OSPF but cooperate with 433 those that do. At the "high" end, this involves redistribution of 434 external routes into OSPF. At the "low" end, this involves static and 435 default routes from stub routers to the lowest level of OSPF router 436 inside a nonzero area. Let's talk about the lowest level first. 438 The lowest level is a "stub" or "edge" router with a single outgoing 439 path, such as a branch office router with several LAN links, perhaps a 440 STUN serial interface for IBM support, and a single WAN link. There are 441 no routers on any of the LANs. 443 Such a router really doesn't need to run any dynamic routing protocol. 444 It should default to a higher-level router. 446 Assuming the higher-level router has multiple links going toward the 447 backbone, that router does need to run OSPF. It doesn't need to connect 448 directly to the backbone. 450 7. Transition and Network Consolidation 452 A management imperative that often occurs after the merger of two 453 enterprises is eliminating the "expense of duplicate backbones." At a 454 slighly more technical level, this means an OSPF design that has a 455 single Area 0. 457 7.1 A Solution using VLs 459 Among many OSPF users, it is a matter of faith and morals that there 460 entire enterprise appear as a single OSPF domain. As a consequence, 461 I've seen designs with a single area 0 spanning serveral continents, 462 with each continent having significantly different line quality and 463 speed, needs for demand backup circuits between parts of the area, etc. 465 Two companies, A, and B, merge. Each has an existing OSPF system, with 466 its own area 0. These Area 0s are widely separated geographically, but 467 they each have an Area 1 whose boundaries are in fairly close proximity. 468 Each ABR has a single interface to Area 0. 470 The two companies perceive they want "a single backbone". They do not 471 wish to renumber every network and router, but are willing to merge two 472 nonzero areas if that were helpful. They are also unwilling, at the 473 present time, to merge their two backbones, principally due to the 474 geographic distance between them. 476 They merge their Area 1's, renumbering appropriately adding physical 477 connectivity between the company A area 1 and the company B area 1. They 478 now have a common Area 1, and then define a VL between the two ABRs. 480 There is now a "single backbone." Potentially, a large amount of 481 inter-area traffic now flows through the combined Area 1. Neither Area 482 1 presumably was designed to support that flow, but that of the traffic 483 of the community of routers for which it originally was built. 485 7.2 An Alternate Solution using External Links between the Area 0's 487 Do not attempt to create a single Area 0. Rather than trying to merge 488 the backbones or the area 1's, define an ASBR function in each Area 0 489 that has one or more static (or even BGP) routes to the ASBR of the 490 other Area 0, and vice versa. Each ASBR advertises the default, and may 491 or may not advertise the external routes to the other Area 0. Doing 492 this requires adding one or more links between A-Area 0 and B-Area 0. 494 This requires no changes to any of the nonzero areas, which still can 495 default to their existing Area 0. If tuning or topology changes are 496 needed to handle traffic flows, most of this can be done at the core 497 tier. Such tuning would involve a smaller set of routers not directly 498 connected, in most cases, to end systems. 500 The core tier now consists of two Area 0's and a set of links between 501 them. 503 7.3 An Alternate Solution using Two Area 0's 505 Both companies have OSPF, but topological or other factors make it 506 difficult to make a direct connection between Area 0s. In this case, 507 establish a Company B ASBR that will advertise Company B routes to 508 Company A. This ASBR might be on the Company B Area 0, or in another 509 area. In either case, it advertises routes to the other ASBR, using 510 multiple static routes or BGP. 512 The company A ASBR can generate a default and advertise Company A 513 addresses to Company B, using appropriate filtering. If the Company A 514 ASBR is in a non-zero area, NSSA may be appropriate. 516 Company B has OSPF in place. Add an ASBR to its Area 0, with a static 517 route to the Area 0 of Company A. 519 8. Transition of Legacy Routing Protocol Domains to OSPF 521 8.1 Problems of Integrating a Newly Acquired Enterprise; OSPF not used 522 by new acquisition 524 Company A acquires a smaller Company B. Company B now runs RIP, or 525 possibly has a limited OSPF implementation. Company B is not 526 geographically close to the Area 0 of Company A. 528 There are several ways to deal with this situation while imposing 529 minimal impact on Company B users. 531 8.2 An OSPF and VL Solution. 533 Replace RIP with OSPF on the Company B routers, assigning the Company B 534 address space to a new nonzero area. Define a VL from one of the new 535 area's routers, tunneled through an existing Company A area, that 536 attaches to the backbone at the edge of the Company A area. 538 Eventually, provide direct connectivity to Area 0 from the Company B 539 area, and delete the VL. 541 Disadvantages here include an immediate conversion to OSPF, the cost of 542 connectivity between the new area and the existing area that carries the 543 VL, and the additional traffic load imposed on the nonzero area with the 544 Area 0 connection. 546 8.3 Run RIP in Company B area, with link to Area 0 ASBR that learns RIP 548 Leave Company B running RIP. Run a link to a Company A, Area 0 router. 549 Either redistribute the RIP routes into Area 0, or simply run RIP on the 550 ASBR and have it originate the default into Area 0. If additional 551 bandwidth or connectivity changes are needed to handle the Company B 552 trafic, this primarily can be restricted to Area 0 where it is not 553 visible to end users. 555 The disadvantage here is the cost of additional circuits from the 556 Company B area to Area 0. Also, ASBR default injection into a nonzero 557 area can create loops if conflicting defaults are being advertised 558 elsewhere, as by an ABR. 560 8.4 Run RIP in Company B area, with an ASBR in the transit nonzero area 561 of Company A. 563 Again Company B runs RIP. It connects to the nearest potential ASBR in 564 an established Company A area, and is advertised as an external route 565 into that area. This nonzero area then injects the external, possibly 566 summarizing it, into Area 0. This method is less flexible in terms of 567 advertising defaults than is 5.2, and also has the disadvantage of 568 injecting external traffic into an area not originally designed to 569 handle it. Since the area with the ASBR can no longer be stubby, it may 570 be flooded with significant numbers of Type 5 LSAs from the backbone and 571 other areas. 573 8.5 ASBR Solution with NSSAs 575 Again Company B runs RIP. It connects to the nearest potential ASBR in 576 an established Company A area, and is advertised as an external route 577 into that area. This ASBR supports NSSA, and translates the RIP routes 578 into Type 7 LSAs, which are sent to ABRs of this area and translated to 579 externals in Area 0. 581 The established nonzero area maitains its generally stubby quality, and 582 will not be flooded by unnecessary Type 5 LSAs. 584 9. Traffic Management 586 In the real world, situations may arise where a client in one area has a 587 significant traffic exchange with a server in another area. The volume of 588 this traffic is such that a special virtual circuit or dedicated line would 589 be warranted, but establishing such a link would violate the OSPF 590 hierarchy. If routers on both ends were in different areas, the hello 591 protocol handshake would fail and there would be no routing between them. 593 Again, this is a matter of if it hurts to do something, don't do it. Most 594 routers have a mechanism for preferring one source of routing information 595 over another. In this case, establish a static route between the client 596 and server prefixes. 598 In the routers along this path between client and server, give the static 599 route a preference factor that makes it more preferable than OSPF. While 600 the details will be specific to individual router implementations, it is 601 usually quite practical to establish OSPF routing, through area 0, as a 602 backup to the preferred static path. 604 10. Multiple Exit Points/Multihoming 606 Use the power of OSPF's two types of externals when defining your policy 607 for Internet connectivity. Many enterprise designers assume, incorrectly, 608 they must run BGP to deal properly with connection to multiple Points of 609 Presence (POP) of the same ISP, or to multiple ISPs when a 610 primary/secondary policy is desired. See [Multihome] for a discussion of 611 multihoming. 613 11. Security Considerations 615 Security considerations are not discussed in this memo. 617 12. Acknowledgments 619 13. References 621 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 622 1812, June 1995. 624 [RFC2178] Moy, J., "Open Shortest Path First version 2," RFC2178 626 [Multihome] Work in progress, H. Berkowitz, "To Be Multihomed: 627 Requirements & Definitions," draft-berkowitz-multirqmt-01.txt. 629 14. Author's Address 631 Howard C. Berkowitz 632 Chesapeake Computer Consultants 633 PO Box 6897 634 Arlington VA 22206 635 Phone: +1 703 998 5819 636 EMail: hcb@clark.net 638 Berkowitz Draft-berkowitz-ospfdeploy-00.txt