idnits 2.17.1 draft-ietf-ospf-abr-alt-00.txt: 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. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == 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. ** The abstract seems to contain references ([Ref1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (July 1999) is 9050 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) No issues found here. Summary: 6 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Alex Zinin 2 Internet Draft AMT Group 3 Expiration Date: January 2000 Acee Lindem 4 File name: draft-ietf-ospf-abr-alt-00.txt IBM 5 Derek Yeung 6 Cisco Systems 7 July 1999 9 Alternative OSPF ABR Implementations 10 draft-ietf-ospf-abr-alt-00.txt 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its Areas, and its Working Groups. Note that other 19 groups may also distribute working documents as Internet Drafts. 21 Internet Drafts are draft documents valid for a maximum of six 22 months. Internet Drafts may be updated, replaced, or obsoleted by 23 other documents at any time. It is not appropriate to use Internet 24 Drafts as reference material or to cite them other than as a "working 25 draft" or "work in progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 OSPF [Ref1] is a link-state intra-domain routing protocol used for 36 routing in IP networks. Though the definition of the ABR in the 37 current OSPF specification does not require a router with multiple 38 attached areas to have a backbone connection, it is actually 39 necessary to provide successful routing to the inter-area and 40 external destinations. If this requirement is not met all traffic, 41 destined for the areas not connected to such an ABR or out of the 42 OSPF domain, is dropped. This document describes alternative ABR 43 behaviors implemented in Cisco and IBM routers. 45 1 Overview 47 1.1 Introduction 49 An OSPF routing domain can be split into several subdomains, called 50 areas, which limit the scope of LSA flooding. According to [Ref1] a 51 router having attachments to multiple areas is called an "area border 52 router" (ABR). The primary function of an ABR is to provide its 53 attached areas with Type-3 and Type-4 LSAs (which are used for 54 describing routes and ASBRs in other areas) as well as to perform 55 actual inter-area routing. 57 1.2 Motivation 59 In OSPF domains the area topology is restricted so that there must be 60 a backbone area (area 0) and all other areas must have either 61 physical or virtual connections to the backbone. The reason for this 62 star-like topology is that OSPF inter-area routing uses the 63 distance-vector approach and a strict area hierarchy permits 64 avoidance of the "counting to infinity" technique. OSPF prevents 65 inter-area routing loops by implementing a split-horizon mechanism, 66 permitting ABRs to inject into the backbone only Summary-LSAs derived 67 from the intra-area routes, and limiting ABRs' SPF calculation to 68 consider only Summary-LSAs in the backbone area's link-state 69 database. 71 The last restriction leads to a problem when an ABR has no backbone 72 connection (in OSPF an ABR does not need to be attached to the 73 backbone). Consider a sample OSPF domain depicted in the Figure 1. 75 . . 76 . Area 0 . 77 +--+ +--+ 78 ..|R1|.. ..|R2|.. 79 . +--+ .. +--+ . 80 . .. . 81 . +--+ . 82 . Area1 |R3| Area2 . 83 . +--+ +--+ . 84 . .. |R4| . 85 . . . +--+ . 86 ....... ....... 88 Figure 1. ABR dropping transit traffic 90 In this example R1, R2, and R3 are ABRs. R1 and R2 have backbone 91 connections, while R3 doesn't. 93 Following the section 12.4.1 of [Ref1], R3 will identify itself as an 94 ABR by setting the bit B in its router-LSA. Being an ABR, R3 can only 95 consider summary-LSAs from the backbone when building the routing 96 table (according to section 16.2 of [Ref1]), so it will not have any 97 inter-area routes in its routing table, but only intra-area routes 98 from both Area 1 and Area 2. Consequently, according to the section 99 12.4.3 of [Ref1], R3 will originate for Areas 1 and 2 only summary- 100 LSAs covering destinations in the directly attached areas, i.e., in 101 Area 2---the summary-LSAs for Area 1, and in Area 1---the summary- 102 LSAs for Area 2. 104 At the same time, router R2, as an ABR connected to the backbone, 105 will inject into Area 2 summary-LSAs describing the destinations in 106 Area 0 (the backbone), Area 1 and other areas reachable through the 107 backbone. 109 This results in a situation, where internal router R4 calculates its 110 routes to destinations in the backbone and areas other than Area 1 111 via R2. The topology of Area 2 itself can be such that the best path 112 from R4 to R2 is via the R3, so all traffic destined for the backbone 113 and backbone-attached areas goes through R3. Router R3 in turn, 114 having only intra-area routes for areas 1 and 2, will effectively 115 drop all traffic not destined for the areas directly attached to it. 116 The same problem can be seen when a backbone-connected ABR loses all 117 of its adjacencies in the backbone---even if there are other normally 118 functioning ABRs in the attached areas, all traffic going to the 119 backbone (destined for it or for other areas) will be dropped. 121 In a standard OSPF implementation this situation can be remedied by 122 use of the Virtual Links (see section 15 of [Ref1] for more details). 123 In this case, router R3 will have a virtual backbone connection, will 124 form an adjacency over it, will receive all summary-LSAs directly 125 from a backbone-attached router (R1 or R2, or both in our example) 126 and will install inter-area routes. 128 While being an unavoidable technique for repairing a partitioned 129 backbone area, the use of virtual links in the described situation 130 adds extra configuration headaches and system traffic overhead. 132 Another situation where standard ABR behavior is not applicable is 133 when it is necessary to provide redundant connectivity to an ASBR via 134 several different OSPF areas. This would allow a provider to 135 aggregate all their customers connecting through a single access 136 point into one area while still offering a redundant connection 137 through another access point in a different area, as shown in Figure 138 2. 140 . . 141 . Area 0 . 142 +--+ +--+ 143 ..|R1|.. ..|R2|.. 144 . +--+ .. +--+ . 145 . .. . 146 . .. . 147 . Area1 .. Area2 . 148 . .. . 149 . .. . 150 . +--+ . 151 .......|R3|....... 152 +--+ 153 ASBR 155 Customer Networks Advertised 156 as AS External or NSSA External Routes 158 Figure 2. Dual Homed Customer Router 160 This technique is already used in a number of networks including one 161 of a major provider. 163 The next section describes alternative ABR behaviors, implemented in 164 Cisco and IBM routers. The changes are in the ABR definition and 165 inter-area route calculation. Any other parts of standard OSPF are 166 not changed. 168 Described solutions are targeted to the situation when an ABR has no 169 backbone connection. It implies that a router connected to multiple 170 areas without a backbone connection is not an ABR and must function 171 as a router internal to every attached area. This solution emulates a 172 situation where separate OSPF processes are run for each area and 173 supply routes to the routing table. It remedies the situation 174 described in the examples above in the meaning of not dropping 175 transit traffic. Note that a router following it does not function 176 as a real border router---it doesn't originates summary-LSAs. 177 Nevertheless such a behavior may be desirable in certain situations. 179 Note that the proposed solutions do not obviate the need of virtual 180 link configuration in case an area has no physical backbone 181 connection at all. The methods described here improve the behavior of 182 a router connecting two or more backbone-attached areas. 184 Though this document is initially oriented to processing Type-3 LSAs 185 and, consequently, is targeted to improving OSPF inter-area routing, 186 it's acceptable to apply described methods to Type-4 LSAs, which will 187 lead to improvement of external routing in an OSPF domain. 189 2 Changes to ABR Behavior 191 2.1 Definitions 193 The following definitions will be used in this document to describe 194 the new ABR behaviors: 196 Configured area: 197 An area is considered configured if the router has at least one 198 interface in any state assigned to that area. 200 Actively attached area: 201 An area is considered actively attached if the router has at 202 least one interface in that area in the state other than Down. 204 Active backbone connection: 205 A router is considered to have an active backbone connection if 206 the backbone area is actively attached and there is at least one 207 fully adjacent neighbor in it. 209 Area Border Router (ABR): 211 Cisco Systems Interpretation: 212 A router is considered to be an ABR if it has more than one area 213 configured and the backbone area actively attached. 215 IBM Interpretation: 216 A router is considered to be an ABR if it has more than one 217 actively attached area and the backbone area configured. 219 2.2 Implementation Details 221 The following changes are made to the base OSPF, described in [Ref1]: 223 1. The algorithm of Type 1 LSA (router-LSA) origination is changed 224 to prevent a multi-area connected router from identifying itself 225 as an ABR by the bit B (as described in section 12.4.1 of [Ref1]) 226 until it considers itself as an ABR according to the definitions 227 given in section 2.1. 229 2. The algorithm of the routing table calculation is changed to 230 allow the router to consider the summary-LSAs from all attached 231 areas if it is not an ABR, but has more than one attached area, 232 or the backbone area connection is not available. Definitions of 233 the terms used in this paragraph are given in section 2.1. 235 So, the paragraph 1 of section 16.2 of [Ref1] should be read as 236 follows: 238 "The inter-area routes are calculated by examining summary-LSAs. 239 If the router is an ABR and has an active backbone connection, 240 only backbone summary-LSAs are examined. Otherwise (either the 241 router is not an ABR or it has no active backbone connection), 242 the router must consider summary-LSAs from all actively attached 243 areas..." 245 3. The algorithm of the summary-LSAs origination is changed to 246 prevent loops of summary-LSAs in situations where the router 247 considers itself an ABR but doesn't have an active backbone 248 connection (and, consequently, examines summaries from all 249 attached areas). The algorithm is changed to allow an ABR 250 announce only intra-area routes in such a situation. 252 So, the paragraph 2 of subsection 12.4.3 of [Ref1] should be read 253 as follows: 255 "Summary-LSAs are originated by area border routers. The precise 256 summary routes to advertise into an area are determined by 257 examining the routing table structure (see Section 11) in 258 accordance with the algorithm described below. Note that only 259 intra-area routes are advertised into the backbone, both intra- 260 area and inter-area routes are advertised into the other areas, 261 provided that the router has an active backbone connection. 262 Otherwise the router is allowed to advertise only intra-area 263 routes into non-backbone areas." 265 For this policy to be applied we change steps 6 and 7 in the 266 summary origination algorithm to be as follows: 268 Step 6: 270 "Else, if the destination of this route is an AS boundary 271 router, a summary-LSA should be originated if and only if the 272 routing table entry describes the preferred path to the AS 273 boundary router (see Step 3 of Section 16.4). If so, a Type 4 274 summary-LSA is originated for the destination, with Link State 275 ID equal to the AS boundary router's Router ID and metric equal 276 to the routing table entry's cost. If the ABR performing this 277 algorithm does not have an active backbone connection, it can 278 originate Type 4 summary-LSA only if the type of the route to 279 the ASBR is intra-area. Note: Type 4 summary-LSAs should not 280 be generated if Area A has been configured as a stub area." 282 Step 7: 284 "Else, the Destination type is network. If this is an inter- 285 area route and the ABR performing this algorithm has an active 286 backbone connection, generate a Type 3 summary-LSA for the 287 destination, with Link State ID equal to the network's address 288 (if necessary, the Link State ID can also have one or more of 289 the network's host bits set; see Appendix E for details) and 290 metric equal to the routing table cost." 292 The changes in the ABR behavior described in this section allow a 293 multi-area connected router to successfully route traffic destined 294 for the backbone and other areas. Note that if the router does not 295 have a backbone area configured it does not actively attract inter- 296 area traffic, because it does not consider itself an ABR and does not 297 originate summary-LSAs. It still can forward traffic from one 298 attached area to another along intra-area routes in case other 299 routers in corresponding areas have the best inter-area paths over 300 it, as described in section 1.2. 302 By processing all summaries when the backbone is not active, we 303 prevent the ABR, which has just lost its last backbone adjacency, 304 from dropping any packets going through the ABR in question to 305 another ABR and destined towards the backbone or other areas not 306 connected to the ABR directly. 308 3 Handling Transitions 310 The behavior described in this document requires special processing 311 when the router's ABR status or backbone connection status changes. 313 3.1 ABR status change 315 The router's ABR flag can change due to the following events: 317 For Cisco ABR definition: 319 1. A new area has been configured. The router becomes an ABR 320 if the new area is the first non-backbone area and the router 321 has the backbone area actively attached. 323 2. An area has been deconfigured. The router stops being an ABR 324 if only one configured area has left or the area in question 325 is the backbone. 327 3. The state machine of an OSPF-enabled interface in the backbone 328 area has transitioned to a state higher than Down. The router 329 becomes an ABR if there is at least one non-backbone area 330 configured. 332 4. The state machine of an OSPF-enabled interface in the backbone 333 area has transitioned to the state Down. The router stops 334 being an ABR if the interface in question was the last one in 335 the backbone area. 337 For IBM ABR definition: 339 1. A new area has been configured. The router becomes an ABR 340 if the new area is the backbone and the router is actively 341 attached to two or more areas. 343 2. An area has been deconfigured. The router stops being an ABR 344 if only one configured area has left or the area in question 345 is the backbone. 347 3. The state machine of an OSPF-enabled interface transitions 348 into a state higher than Down, an area becomes actively 349 attached. If this is the second actively attached area and 350 the backbone area is configured the router becomes an ABR. 352 4. The state machine of an OSPF-enabled interface transitions 353 into Down state. If this is the last active interface in the 354 area, it is no more considered actively attached. The router 355 stops being an ABR if there are no longer multiple actively 356 attached areas. 358 If after one of the events listed above the router's ABR flag has 359 changed to the positive state, the router must do the following: 361 a) reconstruct the router-LSAs for all area databases, setting 362 the bit B to 1. 364 b) flood the new router-LSA to all neighbors according to 365 [Ref1]. 367 c) if the router has an active backbone connection---schedule 368 the routing table recalculation for all areas to get rid of the 369 inter-area routes through non-backbone areas. 371 If the router's ABR flag has changed to the negative state, the 372 router must do the following: 374 a) reconstruct the router-LSAs for all areas, setting the bit B 375 to 0. 377 b) flood the new router-LSA to all neighbors according to 378 [Ref1]. 380 c) schedule the routing table recalculation to install the 381 inter-area routes via non-backbone areas. 383 d) flush all locally originated summary-LSAs from all non- 384 backbone areas. 386 3.2 Backbone connection state change 388 A change of the backbone connection state can be a result of the 389 following events: 391 1. The state machine for a neighbor in the backbone area has 392 transitioned to the state Full. If the neighbor in question is the 393 first fully adjacent neighbor, the backbone connection becomes 394 active. 396 2. The state machine for a neighbor in the backbone area has 397 transitioned to a state other than Full or a neighbor has been 398 deleted from the neighbor list of an interface in the backbone 399 area. The backbone connection becomes inactive if the neighbor in 400 question was the last fully adjacent neighbor in the backbone. 402 If the state of the backbone connection has changed due to one of the 403 events listed above, the router must schedule the routing table 404 calculation according to [Ref1] and the changes described in section 405 2.2 (even if the router is still an ABR). This will make the router 406 flush old inter-area routes from the routing table and install new 407 ones. 409 4 Compatibility 411 The changes of the OSPF ABR operations do not influence any aspects 412 of the router-to-router cooperation and do not create routing loops, 413 and hence are fully compatible with standard OSPF. Proof of 414 compatibility is outside the scope of this document. 416 5 Deployment Considerations 418 This section discusses the deployments details of the ABR behaviors 419 described in this document. Note that this approach is fully 420 compatible with standard ABR behavior, so ABRs acting as described in 421 [Ref1] and in this document can coexist in an OSPF domain and will 422 function without problems. 424 Deployment of ABRs using the alternative methods improves the 425 behavior of a router connected to multiple areas without a backbone 426 attachment, but can lead to unexpected routing asymmetry, as 427 described below. 429 Consider an OSPF domain depicted in Figure 2. 431 ....................... 432 . Backbone . 433 . . 434 . --------------------- . 435 . |1 1| . 436 ..+--+.............+--+.. 437 ..|R1|..... ....|R4|.. 438 . +--+ . . +--+ . 439 . 1| . . /4 . 440 . | 8 +--+ 4 / . 441 . | +-|R3|---+ . 442 . 1| / +--+\4 . 443 . +--+ / . . \ 4 +--+ . 444 . |R2|/8 . . +--|R5| . 445 . +--+ . . +--+ . 446 . | . . | . 447 . --------- . . -------- . 448 . net N . . net M . 449 . . . . 450 . Area 1 . . Area 2 . 451 ........... .......... 453 Figure 2. Inter-area routing asymmetry 455 Assume that R3 uses the approach described in this document. In this 456 case R2 will have inter-area routes to network M via ABR R1 only. R5 457 in turn will have its inter-area route to network N via R4, but as 458 far as R4 is only reachable via R3, all traffic destined to network N 459 will get into R3. R3 will have an intra-area route to network N via 460 R2 and will, of course, route it directly to it (because intra-area 461 routes are always preferred over inter-area ones). Traffic going back 462 from network N to network M will get into R2 and will be routed to 463 R1, as R2 will not have any inter-area routes via R3. So, traffic 464 from N to M will always go through the backbone while traffic from M 465 to N will cross the areas directly via R3 and, in this example, will 466 not use a more optimal path through the backbone. 468 Note that this problem is not caused by the fact that R3 uses the 469 alternative approach. The reason for attracting the attention to it 470 is that R3 is not really functioning as an ABR in case this new 471 behavior is used, i.e., it does not inject summary-LSAs into the 472 attached areas, but inter-area traffic can still go through it. 474 6 Security Considerations 476 The alternative ABR behavior specified in this document does not 477 raise any security issues that are not already covered in [Ref1]. 479 7 References 481 [Ref1] J. Moy. OSPF version 2. Technical Report RFC 2328, Internet 482 Engineering Task Force, 1998. ftp://ftp.isi.edu/in- 483 notes/rfc2328.txt. 485 8 Authors' Address 487 Alex D. Zinin 488 AMT Group 489 8 Maly Znamensky per., bld. 1 490 Office 3b 491 121019 Moscow, Russia 492 E-mail: zinin@amt.ru 494 Acee Lindem 495 IBM Corporation 496 Research Triangle Park, NC USA 497 E-mail: acee@raleigh.ibm.com 499 Derek M. Yeung 500 Cisco Systems Inc. 501 San Jose, CA, USA 502 E-mail: myeung@cisco.com