idnits 2.17.00 (12 Aug 2021) /tmp/idnits36643/draft-mirtorabi-ospf-tunnel-adjacency-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 Introduction section. ** 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.) ** There are 24 instances of lines with control characters in the document. 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 (May 2003) is 6946 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) -- Missing reference section? '2' on line 484 looks like a reference -- Missing reference section? '1' on line 483 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Sina Mirtorabi 3 Internet Draft Peter Psenak 4 Document: draft-mirtorabi-ospf-tunnel-adjacency-00.txt Cisco Systems 5 Expiration Date: November 2003 May 2003 7 OSPF Tunnel Adjacency 8 draft-mirtorabi-ospf-tunnel-adjacency-00.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its Areas, and its Working Groups. Note that other 17 groups may also distribute working documents as Internet Drafts. 19 Internet Drafts are draft documents valid for a maximum of six 20 months. Internet Drafts may be updated, replaced, or obsoleted by 21 other documents at any time. It is not appropriate to use Internet 22 Drafts as reference material or to cite them other than as a "working 23 draft" or "work in progress". 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 OSPF specification requires that intra-area paths are always 34 preferred over Inter-area paths regardless of the path's cost. This 35 document describes a solution that will remedy this limitation 36 without introducing any significant change to the current 37 specification. Further, this solution provides some other benefits 38 such as automatic partition repair described in application section. 40 1. Motivation 42 There could be a requirement to prefer an Inter-area path over an 43 intra-area path, for example in order to utilize the high bandwidth 44 backbone path to transit the intra-area traffic from a non-backbone 45 area. The current OSPF specification does not provide any generic 46 mechanism to be able to achieve this. In some situations Virtual 47 Link (VL) can help, however there are some restrictions applied to 48 VL: 50 a) Transit area needs to be a non-backbone regular area 52 b) VL prevents summarization of backbone prefixes into transit 53 area 55 c) VL cannot be configured through Stub or NSSA [2] areas 57 2. Proposed Solution 59 The Tunnel Adjacency (TA) proposal uses a similar concept as 60 virtual link, e.g. forming an (possibly multihop) adjacency between 61 two ABRs through the transit area, however TA can be configured for 62 any area and the transit area can also be any area. 64 Tunnel adjacency's concept is close to VL in the way of 65 establishing an adjacency, sending unicast OSPF packets and 66 synchronizing the database over it. Data packet forwarding between 67 the two ABRs is different from a VL in that the packets are tunneled 68 if the TA path spans multiple hops. This removes the requirement 69 for routers internal to the transit area to have the TA area's 70 unsummarised intra-area routes. The rest of this document describes 71 TA specification. 73 3. Bringing up the tunnel adjacency 75 TA is configured between two ABRs attached to the same OSPF area. 76 This area is called Tunnel-adjacency Transit Area (TTA). Similar to 77 Virtual Link, TA is identified by the Router ID of the other 78 endpoint. Once a tunnel adjacency for a given area is configured and 79 an intra-area path exists between the two ABRs through the TTA, the 80 router can start forming adjacency with the remote neighbor by 81 sending unicast Hellos and synchronizing the database over TA as 82 specified in OSPF [1]. 84 The interface MTU should be set to 0 in Database Description 85 Packets sent over the TA as it is done with virtual links. TA could 86 be configured as a Demand Circuit (DC) in order to reduce Hello 87 exchange and periodic LSA flooding. 89 4. Tunnel adjacency encapsulation 91 User traffic routed based on the presence of the TA will be 92 encapsulated on the TA endpoints in the following way: 94 a) If both ends of the TA are directly connected to the same 95 network and the best intra-area path to the TA endpoint in the 96 TTA is over this direct network connection, NO special 97 encapsulation is needed. 99 b) Otherwise the traffic is further encapsulated (tunneled) and 100 sent directly to the TA endpoint. The encapsulation type is 101 left to the implementation and different encapsulation types 102 could be specified through configuration. However, in order to 103 have interoperability between vendors all implementation should 104 support GRE encapsulation. 106 5. Advertising tunnel adjacency 108 TA is announced as an unnumbered point-to-point link. Once the 109 router's TA reaches the FULL state it will be added as a link type 1 110 to the Router LSA with: 112 Link ID = remote's Router ID 113 Link Data = router's own IP address associated with TA 114 Cost = intra area cost to the TA endpoint in the TTA or the 115 configured cost 117 The IP address specified in the link data is computed during the 118 routing table build process for the TTA. 120 6. Tunnel adjacency interface data structure 122 An OSPF interface data structure is created for each configured 123 tunnel adjacency. The cost of the TA is configurable allowing a 124 traffic path to be selected independent of the intra-area path 125 cost. The default cost is equal to the intra-area cost to reach the 126 remote TA's neighbor in the TTA. 128 TA is considered as unnumbered point-to-point interface. 130 7. Tunnel adjacency interface FSM 132 TA Interface FSM is the same as specified in OSPF [1]. 133 The InterfaceUp event for TA interfaces is generated once the 134 intra-area path to the remote end of the TA becomes reachable 135 through the TTA. 137 InterfaceDown event is generated for TA when the intra-area 138 path to the remote end of the TA is lost in TTA. 140 8. Tunnel adjacency neighbor data structure 142 TA neighbor data structure is identical to the neighbor data 143 structure for standard OSPF adjacencies as specified in OSPF [1]. 145 9. Tunnel adjacency neighbor FSM 146 TA neighbor FSM is identical to the neighbor FSM for standard 147 OSPF point-to-point adjacencies. 149 10. Tunnel adjacency OSPF control packet processing 151 OSPF control packet processing is specified in OSPF [1] section 8. 152 This section is modified as follow : 154 [...] 156 The IP source address should be set to the IP address of the 157 sending interface. Interfaces to unnumbered point-to-point networks 158 have no associated IP address. On these interfaces, the IP source 159 should be set to any of the other IP addresses belonging to the 160 router. For this reason, there must be at least one IP address 161 assigned to the router. Note that, for most purposes, virtual links 162 and tunnel adjacency act precisely the same as unnumbered 163 point-to-point networks. 165 However, each virtual link or tunnel adjacency does have an IP 166 interface address belonging to transit area or TTA (discovered 167 during the routing table build process) which is used as the IP 168 source when sending packets over the virtual link or tunnel 169 adjacency. If there is not at least one IP address belonging to 170 Transit area or TTA and the virtual link or TA is configured, a 171 router could advertise any of its attached IP address as a stub link 172 (Link ID set to the router's own IP interface address, Link Data set 173 to the mask 0xffffffff) to the transit area. 175 [...] 177 Receiving protocol packets as described in 8.2 is changed as follow: 179 Next, the OSPF packet header is verified. The fields specified in 180 the header must match those configured for the receiving interface. 181 If they do not, the packet should be discarded: 183 o The version number field must specify protocol version 2. 185 o The Area ID found in the OSPF header must be verified. If all of 186 the following cases fail, the packet should be discarded. 187 The Area ID specified in the header must either: 189 (1) Match the Area ID of the receiving interface. In this case, 190 the packet has been sent over a single hop. Therefore, 191 the packet's IP source address is required to be on the 192 same network as the receiving interface. This can be verified 193 by comparing the packet's IP source address to the interface's 194 IP address, after masking both addresses with the interface 195 mask. This comparison should not be performed on 196 point-to-point networks. On point-to-point networks, the 197 interface addresses of each end of the link are assigned 198 independently, if they are assigned at all. 200 (2) Indicate a non-backbone area. In this case, the packet has 201 been sent over a tunnel adjacency. The receiving router must 202 be an area border router, and the Router ID specified in the 203 packet (the source router) must be the other end of a 204 configured tunnel adjacency. The receiving interface must 205 also attach to the TTA. If all of these checks succeed, the 206 packet is accepted and is from now on associated with the 207 tunnel adjacency for that area. 209 (3) Indicate the backbone. In this case, the packet has been sent 210 over a virtual link or tunnel adjacency. The receiving router 211 must be an area border router, and the Router ID specified in 212 the packet (the source router) must be the other end of a 213 configured virtual link or tunnel adjacency. The receiving 214 interface must also attach to the virtual link's configured 215 transit area or tunnel adjacency's configured TTA. If all 216 of these checks succeed, the packet is accepted and is from 217 now on associated with the virtual link or tunnel adjacency. 219 [Note if there is a match for both a VL and TA then this is a 220 configuration error that should be handled at the configuration 221 level.] 223 o Packets whose IP destination is AllDRouters should only be 224 accepted if the state of the receiving interface is DR or 225 Backup (see Section 9.1). 227 [...] 229 11. Tunnel adjacency next hop calculation 231 The next-hop to reach the TA endpoint is equal to the next-hop 232 associated with the TA endpoint inside the TTA. 234 Data packet forwarding between the two ABRs is different from a 235 VL in that the packets are tunneled if the TA path spans multiple 236 hops. This removes the requirement for routers internal to the 237 transit area to have the TA area's unsummarised intra-area routes. 239 12. Virtual link - tunnel adjacency comparison 241 Virtual link has the following limitations: 243 1) The link should belong to a non-backbone area 245 2) Backbone area route cannot be summarized into the Transit area 247 3) VL can not be configured through Stub or NSSA area 249 Tunnel adjacency remedies all the above limitations. Further it 250 will allow: 252 a) The cost of TA is configurable allowing a traffic path to be 253 selected independent of the intra-area path cost, making it 254 ideal to force a traffic path. 256 b) It can be used as an on demand partition repair. In this 257 application, the TA will be established only if the two end of 258 TA are not reachable over a given area (see application 259 section). 261 c) Multiple TAs could be configured over a TTA, each (TA) 262 belonging to a different area in order to provide an intra area 263 path for each area therefore saving cost of adding additional 264 links (see application section). 266 Tunnel Adjacency can be considered as a generalization of Virtual 267 Link. 269 13. Applications 271 In this section we give a few examples in which TA can be used. 273 13.1 Prefer Inter-area Path over intra-area Path 275 It is a common example that users would like to prefer the high 276 bandwidth part of the backbone for traffic that can be strictly 277 routed inside the non-backbone area. 279 Consider the following topology: 281 R1-------backbone------R2 282 | | 283 area 1 area 1 284 | | 285 R3--------area 1--------R4 287 Fig.1 289 The backbone link between R1 and R2 is a high speed link and could be 290 used to forward part of the traffic of area 1 between R1 and R2. 291 In the current OSPF specification, intra-area path are preferred over 292 inter-area path. As a result R1 will always route traffic to R4 293 through area 1 involving lower speed links. Even to reach networks 294 connected to R2 that belong to area 1, R1 will use the intra-area 295 path over area 1. 297 By configuring a TA between R1 and R2 a p2p link will be advertised 298 into area 1 making the TA visible as a topological part of area 1 and 299 by associating a low cost with TA, R1 will now compare two intra-area 300 path and choose the one with lower cost. 302 Note that the above scenario can not be solved by VL since the link 303 between R1 and R2 belongs to the backbone area and it is not 304 desirable to move this backbone link into a non-backbone area. 306 It should also be noted that the connection between R1 and R2 in the 307 backbone area could be multi-hop away, therefore there is no one hop 308 limitation for TA. 310 13.2 On demand partition avoidance for the backbone 312 It can be desirable to not have a virtual link unless the backbone 313 is partitioned, because the backbone's configured ranges are ignored 314 when originating summary-LSA into a transit area. On demand partition 315 repair requires checking to see if the two ends of TA are reachable 316 through the backbone area before starting to form the adjacency. 318 When a TA is configured between the two ABRs a configuration option 319 (automatic) will be used to not start sending Hello unless the other 320 ABR is not reachable over the backbone area. Further, once the on 321 demand adjacency is configured the check for ABR status is ignored 322 during formation of the TA adjacency, because ABR may lose its 323 backbone link and lose its ABR status, but the TA still needs to be 324 established. 326 The cost of on-demand TA should automatically be set to maximum 327 cost LSInfinity (16-bit value 0xFFFF). The reason to set the cost of 328 TA to 0xFFFF in this case is to make it easier to detect that the 329 partitioned area healed. During the SPF only the shortest path to 330 the remote end of the TA is discovered and if the shortest path is 331 via the TA itself, there is no simple way to find out that an 332 alternative intra-area path to the remote end of the TA, other than 333 over TA itself, exist. Setting the metric of TA to 0xFFFF makes 334 this task easier. 336 R1-------area 1--------R2 337 | | 338 backbone backbone 339 | | 340 R3--------backbone-----R4 342 Fig.2 344 In the above topology in order to have an on demand VL for the 345 backbone, an on demand TA can be configured between R1 and R2 for 346 backbone through area 1. Should the backbone be partitioned, R1/R2 347 are not reachable over the backbone and they start forming adjacency 348 through area 1 for the backbone. 350 13.3 On demand partition avoidance for summarized non-backbone area 352 In general when a non-backbone area is partitioned there is no 353 need for partition repair as an intra-area route will be replaced by 354 an Inter-area route for a segmented area. However this is not true 355 any more if the area is summarized into the backbone. Consider the 356 following topology: 358 R1-------backbone------R2 359 | | 360 area 1 area 1 361 | | 362 R3--------area 1--------R4 364 Fig.3 366 R1 and R2 are summarizing area 1 into the backbone area. when 367 area becomes partitioned, for example when R3-R4 link is broken, R1 368 and R2 still continue to summarize area 1 into the backbone area. 369 This can lead to blackholing of the traffic. The reason is that 370 after the area partitioning, R1 or R2 will only have knowledge of 371 their attached partitioned area. When R1 or R2 receives a packet 372 that does not belong to it's attached partitioned area (as a result 373 of advertising a summary) the packet will be discarded. 375 Note that R1 and R2 will install a discard route for the 376 configured summary range. If the destination is not found in the 377 attached area the packet is discarded following the discard route 378 entry in the routing table. 380 By configuring an on demand TA for area 1 through the backbone, 381 R1/R2 will establish an adjacency should area 1 becomes partitioned, 382 that is when R1/R2 is not reachable over area 1. 384 Note that the cost of on-demand TA should be set to maximum cost 385 LSInfinity (16-bit value 0xFFFF). 387 13.4 Saving additional link between ABRs in a Hub and Spoke environment 389 Consider the typical Hub and Spoke topology in figure 4. 391 R1---BB--R2 392 | \ / | 393 | \ / | 394 | \/ | 395 | /\ | 396 | / \ | 397 Spoke1 Spoke2 399 Fig.4 401 Only two Spokes are represented in figure 4, but in general we may 402 have N spokes similar to Spoke1. 404 R1 and R2 are ABRs and can be multiple hops away over the backbone 405 area (BB).Further, the ABRs are summarizing IP prefixes from all the 406 attached areas into the backbone. 408 Case 1: Spoke1 and Spoke2 are in different area 409 ----------------------------------------------- 411 Since both R1 and R2 are summarizing, there is a need for a link 412 between R1 and R2 in each connected area. This is to guarantee an 413 alternative path when the link between a spoke and Hub becomes 414 unavailable. 416 For example imagine a network X advertised by Spoke1 and 417 summarized by both R1 and R2. Later the link between R1 and Spoke1 418 goes down. When a packet arrives at R1 to be forwarded to Spoke1, R1 419 cannot send the packet to Spoke1 since the link is not available and 420 R1 by summarizing may have installed a discard route for summarized 421 range (here we assume the range is still 'active', as there may be 422 other spokes in the same area as Spoke1, single attached to R1 and 423 advertising prefixes that falls in the same range as X), so R1 will 424 not use an inter-area path over R2. A link between R1 and R2, 425 inside the same area as the link between R1 and Spoke1 is, would 426 prevent this problem. 428 Case 2: Spoke1 and Spoke2 are in the same area 429 ---------------------------------------------- 431 Link between R1 and Spoke1 is broken. The path from R1 to Spoke1 is 432 R1-Spoke2-R2-Spoke1 instead of R1-R2-Spoke1. 434 In general, for N areas being attached to the Hub routers, there 435 is a need for N links between Hub routers. Multiple TA could be used 436 through the backbone between the Hub routers to avoid using multiple 437 physical links (each belonging to a different non-backbone area) 438 between ABRs. 440 14. Tunnel adjacency parameters 442 Tunnel adjacency can be configured between area border routers 443 having interfaces to a common area and it can belong to any area. 444 The tunnel adjacency appears as an unnumbered point-to-point link in 445 the graph for the configured area. Tunnel adjacency must be 446 configured on both ends. 448 A tunnel adjacency is defined by the following configurable 449 parameters: 451 o The Router ID of the Tunnel adjacency's other endpoint. 453 o The TTA area through which the tunnel adjacency runs. 455 o The area to which the tunnel adjacency belong. 457 Optionally the following configurable parameters can be set: 459 o cost of the tunnel adjacency which will overwrite the 460 intra-area cost between the two endpoint of the TA. 462 o Encapsulation type used between the two endpoint of the TA. 464 o 'Automatic' option used for on demand partition repair. 466 15. Compatibility issues 468 All mechanisms described in this document are backward-compatible 469 with standard OSPF implementations. 471 16. Security 473 Tunnel adjacency specified in this document does not raise any 474 security issues that are not already covered in [1]. 476 17. Acknowledgments 478 Authors would like to thank Abhay Roy, Liem Nguyen, Acee Lindem 479 and Pat Murphy for their comments on the document. 481 18. Reference 483 [1] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 484 [2] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", 485 RFC 3101, January 2003. 487 19. Authors' address 489 Sina Mirtorabi 490 Cisco Systems 491 225 West Tasman drive 492 San Jose, CA 95134 493 E-mail: sina@cisco.com 495 Peter Psenak 496 Cisco Systems 497 Parc Pegasus, 498 De Kleetlaan 6A 499 1831 Diegem 500 Belgium 501 E-mail: ppsenak@cisco.com