idnits 2.17.1 draft-ietf-ospf-abr-alt-02.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 == The page length should not exceed 58 lines per page, but there was 11 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages 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 2000) is 8679 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 (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Alex Zinin 3 Internet Draft Cisco Systems 4 Expiration Date: January 2001 Acee Lindem 5 File name: draft-ietf-ospf-abr-alt-02.txt Redback Networks 6 Derek Yeung 7 Procket Networks 8 July 2000 10 Alternative OSPF ABR Implementations 11 draft-ietf-ospf-abr-alt-02.txt 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its Areas, and its Working Groups. Note that other 20 groups may also distribute working documents as Internet Drafts. 22 Internet Drafts are draft documents valid for a maximum of six 23 months. Internet Drafts may be updated, replaced, or obsoleted by 24 other documents at any time. It is not appropriate to use Internet 25 Drafts as reference material or to cite them other than as a "working 26 draft" or "work in progress". 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 OSPF [Ref1] is a link-state intra-domain routing protocol used for 37 routing in IP networks. Though the definition of the ABR in the 38 current OSPF specification does not require a router with multiple 39 attached areas to have a backbone connection, it is actually 40 necessary to provide successful routing to the inter-area and 41 external destinations. If this requirement is not met, all traffic 42 destined for the areas not connected to such an ABR or out of the 43 OSPF domain, is dropped. This document describes alternative ABR 44 behaviors implemented in Cisco and IBM routers. 46 1 Overview 48 1.1 Introduction 50 An OSPF routing domain can be split into several subdomains, called 51 areas, which limit the scope of LSA flooding. According to [Ref1] a 52 router having attachments to multiple areas is called an "area border 53 router" (ABR). The primary function of an ABR is to provide its 54 attached areas with Type-3 and Type-4 LSAs (which are used for 55 describing routes and ASBRs in other areas) as well as to perform 56 actual inter-area routing. 58 1.2 Motivation 60 In OSPF domains the area topology is restricted so that there must be 61 a backbone area (area 0) and all other areas must have either 62 physical or virtual connections to the backbone. The reason for this 63 star-like topology is that OSPF inter-area routing uses the 64 distance-vector approach and a strict area hierarchy permits 65 avoidance of the "counting to infinity" problem. OSPF prevents 66 inter-area routing loops by implementing a split-horizon mechanism, 67 allowing ABRs to inject into the backbone only Summary-LSAs derived 68 from the intra-area routes, and limiting ABRs' SPF calculation to 69 consider only Summary-LSAs in the backbone area's link-state 70 database. 72 The last restriction leads to a problem when an ABR has no backbone 73 connection (in OSPF, an ABR does not need to be attached to the 74 backbone). Consider a sample OSPF domain depicted in the Figure 1. 76 . . 77 . Area 0 . 78 +--+ +--+ 79 ..|R1|.. ..|R2|.. 80 . +--+ .. +--+ . 81 . .. . 82 . +--+ . 83 . Area1 |R3| Area2 . 84 . +--+ +--+ . 85 . .. |R4| . 86 . . . +--+ . 87 ....... ....... 89 Figure 1. ABR dropping transit traffic 91 In this example R1, R2, and R3 are ABRs. R1 and R2 have backbone 92 connections, while R3 doesn't. 94 Following the section 12.4.1 of [Ref1], R3 will identify itself as an 95 ABR by setting the bit B in its router-LSA. Being an ABR, R3 can only 96 consider summary-LSAs from the backbone when building the routing 97 table (according to section 16.2 of [Ref1]), so it will not have any 98 inter-area routes in its routing table, but only intra-area routes 99 from both Area 1 and Area 2. Consequently, according to the section 100 12.4.3 of [Ref1], R3 will originate for Areas 1 and 2 only summary- 101 LSAs covering destinations in the directly attached areas, i.e., in 102 Area 2---the summary-LSAs for Area 1, and in Area 1---the summary- 103 LSAs for Area 2. 105 At the same time, router R2, as an ABR connected to the backbone, 106 will inject into Area 2 summary-LSAs describing the destinations in 107 Area 0 (the backbone), Area 1 and other areas reachable through the 108 backbone. 110 This results in a situation, where internal router R4 calculates its 111 routes to destinations in the backbone and areas other than Area 1 112 via R2. The topology of Area 2 itself can be such that the best path 113 from R4 to R2 is via the R3, so all traffic destined for the backbone 114 and backbone-attached areas goes through R3. Router R3 in turn, 115 having only intra-area routes for areas 1 and 2, will effectively 116 drop all traffic not destined for the areas directly attached to it. 117 The same problem can be seen when a backbone-connected ABR loses all 118 of its adjacencies in the backbone---even if there are other normally 119 functioning ABRs in the attached areas, all traffic going to the 120 backbone (destined for it or for other areas) will be dropped. 122 In a standard OSPF implementation this situation can be remedied by 123 use of the Virtual Links (see section 15 of [Ref1] for more details). 124 In this case, router R3 will have a virtual backbone connection, will 125 form an adjacency over it, will receive all LSAs directly from a 126 backbone-attached router (R1 or R2, or both in our example) and will 127 install intra- or inter-area routes. 129 While being an unavoidable technique for repairing a partitioned 130 backbone area, the use of virtual links in the described situation 131 adds extra configuration headaches and system traffic overhead. 133 Another situation where standard ABR behavior does not provide 134 acceptable results is when it is necessary to provide redundant 135 connectivity to an ASBR via several different OSPF areas. This would 136 allow a provider to aggregate all their customers connecting through 137 a single access point into one area while still offering a redundant 138 connection through another access point in a different area, as shown 139 in Figure 2. 141 . . 142 . Area 0 . 143 +--+ +--+ 144 ..|R1|.. ..|R2|.. 145 . +--+ .. +--+ . 146 . .. . 147 . .. . 148 . Area1 .. Area2 . 149 . .. . 150 . .. . 151 . +--+ . 152 .......|R3|....... 153 +--+ 154 ASBR 156 Customer Networks Advertised 157 as AS External or NSSA External Routes 159 Figure 2. Dual Homed Customer Router 161 This technique is already used in a number of networks including one 162 of a major provider. 164 The next section describes alternative ABR behaviors, implemented in 165 Cisco and IBM routers. The changes are in the ABR definition and 166 inter-area route calculation. Any other parts of standard OSPF are 167 not changed. 169 Described solutions are targeted to the situation when an ABR has no 170 backbone connection. It implies that a router connected to multiple 171 areas without a backbone connection is not an ABR and should function 172 as a router internal to every attached area. This solution emulates a 173 situation where separate OSPF processes are run for each area and 174 supply routes to the routing table. It remedies the situation 175 described in the examples above in the meaning of not dropping 176 transit traffic. Note that a router following it does not function 177 as a real border router---it doesn't originate summary-LSAs. 178 Nevertheless such a behavior may be desirable in certain situations. 180 Note that the proposed solutions do not obviate the need of virtual 181 link configuration in case an area has no physical backbone 182 connection at all. The methods described here improve the behavior of 183 a router connecting two or more backbone-attached areas. 185 2 Changes to ABR Behavior 187 2.1 Definitions 189 The following definitions will be used in this document to describe 190 the new ABR behaviors: 192 Configured area: 193 An area is considered configured if the router has at least one 194 interface in any state assigned to that area. 196 Actively Attached area: 197 An area is considered actively attached if the router has at 198 least one interface in that area in the state other than Down. 200 Active Backbone Connection: 201 A router is considered to have an active backbone connection if 202 the backbone area is actively attached and there is at least one 203 fully adjacent neighbor in it. 205 Area Border Router (ABR): 207 Cisco Systems Interpretation: 208 A router is considered to be an ABR if it has more than one area 209 Configured and the backbone area Actively Attached. 211 IBM Interpretation: 212 A router is considered to be an ABR if it has more than one 213 Actively Attached area and the backbone area Configured. 215 2.2 Implementation Details 217 The following changes are made to the base OSPF, described in [Ref1]: 219 1. The algorithm of Type 1 LSA (router-LSA) origination is changed 220 to prevent a multi-area connected router from identifying itself 221 as an ABR by the bit B (as described in section 12.4.1 of [Ref1]) 222 until it considers itself as an ABR according to the definitions 223 given in section 2.1. 225 2. The algorithm of the routing table calculation is changed to 226 allow the router to consider the summary-LSAs from all attached 227 areas if it is not an ABR, but has more than one attached area, 228 or it does not have an Active Backbone Connection. Definitions of 229 the terms used in this paragraph are given in section 2.1. 231 So, the paragraph 1 of section 16.2 of [Ref1] should be 232 interpreted as follows: 234 "The inter-area routes are calculated by examining summary-LSAs. 235 If the router is an ABR and has an Active Backbone Connection, 236 only backbone summary-LSAs are examined. Otherwise (either the 237 router is not an ABR or it has no Active Backbone Connection), 238 the router should consider summary-LSAs from all Actively 239 Attached areas..." 241 3. The algorithm of the summary-LSAs origination is changed to 242 prevent loops of summary-LSAs in situations where the router 243 considers itself an ABR but doesn't have an Active Backbone 244 Connection (and, consequently, examines summaries from all 245 attached areas). The algorithm is changed to allow an ABR 246 announce only intra-area routes in such a situation. 248 So, the paragraph 2 of subsection 12.4.3 of [Ref1] should be 249 interpreted as follows: 251 "Summary-LSAs are originated by area border routers. The precise 252 summary routes to advertise into an area are determined by 253 examining the routing table structure (see Section 11) in 254 accordance with the algorithm described below. Note that only 255 intra-area routes are advertised into the backbone, both intra- 256 area and inter-area routes are advertised into the other areas, 257 provided that the router has an Active Backbone Connection. 258 Otherwise the router is allowed to advertise only intra-area 259 routes into non-backbone areas." 261 For this policy to be applied we change steps 6 and 7 in the 262 summary origination algorithm to be as follows: 264 Step 6: 266 "Else, if the destination of this route is an AS boundary 267 router, a summary-LSA should be originated if and only if the 268 routing table entry describes the preferred path to the AS 269 boundary router (see Step 3 of Section 16.4). If so, a Type 4 270 summary-LSA is originated for the destination, with Link State 271 ID equal to the AS boundary router's Router ID and metric equal 272 to the routing table entry's cost. If the ABR performing this 273 algorithm does not have an Active Backbone Connection, it can 274 originate Type 4 summary-LSA only if the type of the route to 275 the ASBR is intra-area. Note: Type 4 summary-LSAs should not 276 be generated if Area A has been configured as a stub area." 278 Step 7: 280 "Else, the Destination type is network. If this is an inter- 281 area route and the ABR performing this algorithm has an Active 282 Backbone Connection, generate a Type 3 summary-LSA for the 283 destination, with Link State ID equal to the network's address 284 (if necessary, the Link State ID can also have one or more of 285 the network's host bits set; see Appendix E for details) and 286 metric equal to the routing table cost." 288 The changes in the ABR behavior described in this section allow a 289 multi-area connected router to successfully route traffic destined 290 for the backbone and other areas. Note that if the router does not 291 have a backbone area Configured it does not actively attract inter- 292 area traffic, because it does not consider itself an ABR and does not 293 originate summary-LSAs. It still can forward traffic from one 294 attached area to another along intra-area routes in case other 295 routers in corresponding areas have the best inter-area paths over 296 it, as described in section 1.2. 298 By processing all summaries when the backbone is not active, we 299 prevent the ABR, which has just lost its last backbone adjacency, 300 from dropping any packets going through the ABR in question to 301 another ABR and destined towards the backbone or other areas not 302 connected to the ABR directly. 304 3 Handling Transitions 306 The behavior described in this document requires special processing 307 when the router's ABR status or backbone connection status changes. 309 3.1 ABR status change 311 The router's ABR flag can change due to the following events: 313 For Cisco ABR definition: 315 1. A new area has been configured. The router becomes an ABR 316 if the new area is the first non-backbone area and the router 317 has the backbone area Actively Attached. 319 2. An area has been deconfigured. The router stops being an ABR 320 if only one configured area has left or the area in question 321 is the backbone. 323 3. The state machine of an OSPF-enabled interface in the backbone 324 area has transitioned to a state higher than Down. The router 325 becomes an ABR if there is at least one non-backbone area 326 Configured. 328 4. The state machine of an OSPF-enabled interface in the backbone 329 area has transitioned to the state Down. The router stops 330 being an ABR if the interface in question was the last one in 331 the backbone area. 333 For IBM ABR definition: 335 1. A new area has been configured. The router becomes an ABR 336 if the new area is the backbone and the router is Actively 337 Attached to two or more areas. 339 2. An area has been deconfigured. The router stops being an ABR 340 if only one configured area has left or the area in question 341 is the backbone. 343 3. The state machine of an OSPF-enabled interface transitions 344 into a state higher than Down, an area becomes Actively 345 Attached. If this is the second actively attached area and 346 the backbone area is Configured the router becomes an ABR. 348 4. The state machine of an OSPF-enabled interface transitions 349 into Down state. If this is the last active interface in the 350 area, it is no more considered Actively Attached. The router 351 stops being an ABR if there are no longer multiple Actively 352 Attached areas. 354 If after one of the events listed above the router's ABR flag has 355 changed to the positive state, the router should do the following: 357 a) reconstruct the router-LSAs for all area databases, setting 358 the bit B to 1. 360 b) flood the new router-LSA to all neighbors according to 361 [Ref1]. 363 c) if the router has an Active Backbone Connection---schedule 364 the routing table recalculation for all areas to get rid of the 365 inter-area routes through non-backbone areas. 367 If the router's ABR flag has changed to the negative state, the 368 router should do the following: 370 a) reconstruct the router-LSAs for all areas, setting the bit B 371 to 0. 373 b) flood the new router-LSA to all neighbors according to 374 [Ref1]. 376 c) schedule the routing table recalculation to install the 377 inter-area routes via non-backbone areas. 379 d) flush all locally originated summary-LSAs from all non- 380 backbone areas. 382 3.2 Backbone connection state change 384 A change of the backbone connection state can be a result of the 385 following events: 387 1. The state machine for a neighbor in the backbone area has 388 transitioned to the state Full. If the neighbor in question is the 389 first fully adjacent neighbor, the backbone connection becomes 390 active. 392 2. The state machine for a neighbor in the backbone area has 393 transitioned to a state other than Full or a neighbor has been 394 deleted from the neighbor list of an interface in the backbone 395 area. The backbone connection becomes inactive if the neighbor in 396 question was the last fully adjacent neighbor in the backbone. 398 If the state of the backbone connection has changed due to one of the 399 events listed above, the router should schedule the routing table 400 calculation according to [Ref1] and the changes described in section 401 2.2 (even if the router is still an ABR). This will make the router 402 flush old inter-area routes from the routing table and install new 403 ones. 405 4 Virtual Link Treatment 407 Cisco ABR approach described in this document requires an ABR to have 408 at least one active interface in the backbone area. This requirement 409 may cause problems with virtual links in those rare situations where 410 the backbone area is purely virtual, as shown in Figure 3, and the 411 state of the VL is determined as in [Ref1]. 413 ....... ........... ...... 414 . . . . 415 +--+ VL +--+ 416 |R1|***********|R2| 417 +--+ +--+ 418 Area 1 . . Area 2 . . Area 3 419 ....... ........... ...... 421 Figure 3. Purely Virtual Backbone 423 If R1 and R3 treat virtual links as in [Ref1], their virtual links 424 will never go up, because their router-LSAs do not contain the B-bit, 425 which is, in turn, because the routers do not have active interfaces 426 (virtual links) in the backbone and do not consider themselves ABRs. 427 Note that this problem does not appear if one of the routers has a 428 real interface in the backbone, as it usually is in real networks. 430 Though described situation is deemed to be rather rare, 431 implementations supporting Cisco ABR behavior may consider changing 432 VL-specific code so that a virtual link is reported up (an 433 InterfaceUp event is generated) when a router with corresponding 434 router-ID is seen via Dijkstra, no matter whether its router-LSA 435 indicates that it is an ABR or not. This means that checking of 436 configured virtual links should be done not in step 4 of the 437 algorithm in 16.1 of [Ref1] when a router routing entry is added, but 438 every time a vertex is added to the SPT in step 3 of the same 439 algorithm. 441 5 Compatibility 443 The changes of the OSPF ABR operations do not influence any aspects 444 of the router-to-router cooperation and do not create routing loops, 445 and hence are fully compatible with standard OSPF. Proof of 446 compatibility is outside the scope of this document. 448 6 Deployment Considerations 450 This section discusses the deployments details of the ABR behaviors 451 described in this document. Note that this approach is fully 452 compatible with standard ABR behavior, so ABRs acting as described in 453 [Ref1] and in this document can coexist in an OSPF domain and will 454 function without problems. 456 Deployment of ABRs using the alternative methods improves the 457 behavior of a router connected to multiple areas without a backbone 458 attachment, but can lead to unexpected routing asymmetry, as 459 described below. 461 Consider an OSPF domain depicted in Figure 4. 463 ....................... 464 . Backbone . 465 . . 466 . --------------------- . 467 . |1 1| . 468 ..+--+.............+--+.. 469 ..|R1|..... ....|R4|.. 470 . +--+ . . +--+ . 471 . 1| . . /4 . 472 . | 8 +--+ 4 / . 473 . | +-|R3|---+ . 474 . 1| / +--+\4 . 475 . +--+ / . . \ 4 +--+ . 476 . |R2|/8 . . +--|R5| . 477 . +--+ . . +--+ . 478 . | . . | . 479 . --------- . . -------- . 480 . net N . . net M . 481 . . . . 482 . Area 1 . . Area 2 . 483 ........... .......... 485 Figure 4. Inter-area routing asymmetry 487 Assume that R3 uses the approach described in this document. In this 488 case R2 will have inter-area routes to network M via ABR R1 only. R5 489 in turn will have its inter-area route to network N via R4, but as 490 far as R4 is only reachable via R3, all traffic destined to network N 491 will get into R3. R3 will have an intra-area route to network N via 492 R2 and will, of course, route it directly to it (because intra-area 493 routes are always preferred over inter-area ones). Traffic going back 494 from network N to network M will get into R2 and will be routed to 495 R1, as R2 will not have any inter-area routes via R3. So, traffic 496 from N to M will always go through the backbone while traffic from M 497 to N will cross the areas directly via R3 and, in this example, will 498 not use a more optimal path through the backbone. 500 Note that this problem is not caused by the fact that R3 uses the 501 alternative approach. The reason for attracting the attention to it 502 is that R3 is not really functioning as an ABR in case this new 503 behavior is used, i.e., it does not inject summary-LSAs into the 504 attached areas, but inter-area traffic can still go through it. 506 7 Security Considerations 508 The alternative ABR behavior specified in this document does not 509 raise any security issues that are not already covered in [Ref1]. 511 8 Acknowledgements 513 Authors would like to thank Alvaro Retana and Russ White for their 514 review of the document. 516 9 Disclaimer 518 This document describes OSPF ABR implementations of respective 519 vendors "as is", only for informational purposes, and without any 520 warranties, guarantees or support. Also, authors do not have any 521 intention to keep this document in sync with actual implementations. 523 10 References 525 [Ref1] J. Moy. OSPF version 2. Technical Report RFC 2328, Internet 526 Engineering Task Force, 1998. ftp://ftp.isi.edu/in- 527 notes/rfc2328.txt. 529 11 Authors' Addresses 531 Alex Zinin Derek M. Yeung 532 Cisco Systems Procket Networks 533 150 West Tasman Dr. 3850 N.First Street 534 San Jose,CA San Jose, CA 95134 535 95134 Phone: 408-954-7911 536 E-mail: azinin@cisco.com Fax: 408-987-6166 537 Email: myeung@procket.com 539 Acee Lindem 540 Redback Networks 541 102 Carric Bend Court 542 Apex, NC 27502 USA 543 919-387-6971