idnits 2.17.1 draft-mirtorabi-ospf-tunnel-adjacency-01.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 12 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** There are 14 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 386 has weird spacing: '...R1 will not u...' -- 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 (December 2003) is 7438 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 460 looks like a reference -- Missing reference section? '1' on line 458 looks like a reference -- Missing reference section? '3' on line 463 looks like a reference -- Missing reference section? '4' on line 466 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 6 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-01.txt Cisco Systems, Inc 5 Expiration Date: June 2004 6 Acee Lindem 7 Redback Networks 9 December 2003 11 OSPF Tunnel Adjacency 12 draft-mirtorabi-ospf-tunnel-adjacency-01.txt 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its Areas, and its Working Groups. Note that other 21 groups may also distribute working documents as Internet Drafts. 23 Internet Drafts are draft documents valid for a maximum of six 24 months. Internet Drafts may be updated, replaced, or obsoleted by 25 other documents at any time. It is not appropriate to use Internet 26 Drafts as reference material or to cite them other than as a "working 27 draft" or "work in progress". 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 The OSPF specification requires that intra-area paths are always 38 preferred over inter-area paths, regardless of the path's cost. 39 In some situations this can lead to an inefficient usage of 40 network resources. This document describes a solution that helps 41 to address this problem by creating adjacencies through backbone 42 area that belong to non-backbone areas. 44 1. Motivation 46 There could be a requirement to prefer an inter-area path over an 47 intra-area path. For example, in order to utilize a high bandwidth 48 backbone path to transit the intra-area traffic from a non-backbone 49 area. The current OSPF specification does not provide any generic 50 mechanism to achieve this. In some situations, Virtual 51 Links (VLs) can help. However, there are some restrictions associated 52 with VLs: 54 a) Transit area must be a non-backbone regular area 56 b) VLs prevent summarization of backbone prefixes into their 57 associated transit area 59 c) VLs cannot be configured through Stub or NSSA [2] areas 61 2. Proposed Solution 63 The Tunnel Adjacency (TA) proposal uses a concept similar to 64 virtual links by forming an adjacency (possibly multihop) between 65 two ABRs through a transit area. However, TAs can be configured for 66 any non-backbone area with the backbone as the transit area. 68 Tunnel Adjacencies operate similar to VLs in adjacency establishment, 69 sending unicast OSPF packets, and datbase synchronization. Data packet 70 forwarding between the endpoint ABRs is different from VLs in that 71 the packets are tunneled if the TA's path spans multiple hops. This 72 removes the requirement for routers internal to the transit area to 73 have the TA area's unsummarised intra-area routes. The rest of this 74 document describes the TA specification. 76 3. Bringing up the tunnel adjacency 78 TAs are configured between two ABRs attached to the backbone. 79 Similiar to virtual links, TAs are identified by the Router ID of the 80 endpoint. Once a tunnel adjacency for a given area is configured and 81 an intra-area path exists between the two ABRs through the backbone 82 an adjacency can be formed as specified in OSPF [1]. 84 The interface MTU should be set to 0 in Database Description 85 packets sent over TAs as is done with virtual links. TAs can 86 be configured as a Demand Circuits (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 over the backbone is via 96 this direct network connection, no additional encapsulation is 97 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 103 to have interoperability between vendors all implementations 104 should support GRE encapsulation [3]. 106 5. Advertising tunnel adjacency 108 TAs are announced as unnumbered point-to-point links. Once a 109 router's TA reaches the FULL state a type 1 link will be added to 110 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 via the backbone area 115 or the configured cost 117 The IP address specified in the link data is computed during the 118 routing table build process for the backbone. 120 6. Tunnel adjacency interface data structure 122 The TA interface data structure is the same as specified 123 in section 9 of OSPF [1]. An OSPF interface data structure is 124 created for each configured tunnel adjacency. The cost of the TA 125 is configurable allowing a traffic path to be selected independent 126 of the intra-area path cost. The default cost is equal to the 127 intra-area cost to reach the TA endpoint through the backbone. 129 Topologically, a TA is identical to an unnumbered point-to-point 130 interface. 132 7. Tunnel adjacency interface FSM 134 The TA Interface FSM is the same as specified in section 9.3 135 of OSPF [1]. The InterfaceUp event for TA interfaces is generated 136 once the remote end of the TA becomes reachable through the backbone 137 via an intra-area path. 139 Similiarly, the InterfaceDown event is generated for TA interfaces 140 when the remote end of the TA is no longer reachable through the 141 backbone via an intra-area path. 143 8. Tunnel adjacency neighbor data structure 145 The TA neighbor data structure is identical to the neighbor data 146 structure for standard OSPF adjacencies as specified in section 10 147 of OSPF [1]. 149 9. Tunnel adjacency neighbor FSM 151 The TA neighbor FSM is identical to the neighbor FSM for a standard 152 OSPF point-to-point adjacency as specified in section 10.3 153 of OSPF [1]. 155 10. Tunnel adjacency OSPF control packet processing 157 OSPF control packet processing is specified in OSPF [1] section 8. 158 This section is modified as follow: 160 [...] 162 The IP source address should be set to the IP address of the 163 sending interface. Interfaces to unnumbered point-to-point networks 164 have no associated IP address. On these interfaces, the IP source 165 should be set to any of the other IP addresses belonging to the 166 router. For this reason, there must be at least one IP address 167 assigned to the router. Note that, for most purposes, virtual links 168 and tunnel adjacency act precisely the same as unnumbered 169 point-to-point networks. 171 However, each virtual link or tunnel adjacency does have an IP 172 interface address belonging to a transit area or backbone (discovered 173 during the routing table build process) which is used as the IP 174 source when sending packets over the virtual link or tunnel 175 adjacency. If there is not at least one IP address belonging to 176 Transit area or the backbone and a virtual link or TA is configured, 177 a router could advertise any of its attached IP address as a stub link 178 (Link ID set to the router's own IP interface address, Link Data set 179 to the mask 0xffffffff) to the transit area. 181 [...] 183 Receiving protocol packets as described in 8.2 is changed as follow: 185 Next, the OSPF packet header is verified. The fields specified in 186 the header must match those configured for the receiving interface. 187 If they do not, the packet should be discarded: 189 o The version number field must specify protocol version 2. 191 o The Area ID found in the OSPF header must be verified. If all of 192 the following cases fail, the packet should be discarded. 193 The Area ID specified in the header must either: 195 (1) Match the Area ID of the receiving interface. In this case, 196 the packet has been sent over a single hop. Therefore, the 197 packet's IP source address is required to be on the same 198 network as the receiving interface. This can be verified by 199 comparing the packet's IP source address to the interface's 200 IP address, after masking both addresses with the interface 201 mask. This comparison should not be performed on point-to-point 202 networks. On point-to-point networks, the interface addresses 203 of each end of the link are assigned independently, if they 204 are assigned at all. 206 (2) Indicate a non-backbone area. In this case, the packet has 207 been sent over a tunnel adjacency. The receiving router must 208 be an area border router, and the Router ID specified in the 209 packet (the source router) must be the other end of a 210 configured tunnel adjacency. The receiving interface must 211 also attach to the backbone. If all of these checks succeed, 212 the packet is accepted and is from now on associated with 213 the tunnel adjacency for that area. 215 (3) Indicate the backbone. In this case, the packet has been 216 sent over a virtual link. The receiving router must be an 217 area border router, and the Router ID specified in the 218 packet (the source router) must be the other end of a 219 configured virtual link. The receiving interface must 220 also attach to the virtual link's configured Transit area. 221 If all of these checks succeed, the packet is accepted 222 and is from now on associated with the virtual link 223 (and the backbone area). 225 o Packets whose IP destination is AllDRouters should only be 226 accepted if the state of the receiving interface is DR or 227 Backup (see Section 9.1). 229 [...] 231 11. Tunnel adjacency next hop calculation 233 The next-hop to reach the TA endpoint is equal to the next-hop 234 associated with the TA endpoint via the backbone area. 236 Data packet forwarding between the two ABRs is different from a 237 VL in that the packets are tunneled if the TA path spans multiple 238 hops. This removes the requirement for routers internal to the 239 backbone area to have the TA area's unsummarised intra-area routes. 241 12. Virtual link - tunnel adjacency comparison 243 Virtual links are part of area 0 and must transit through a regular 244 non-backbone area and are configured to avoid backbone partitioning. 245 Conversely, tunnel adjacencies can be part of any type non-backbone 246 area and use the backbone as a transit area. Hence, TAs complement 247 virtual links and address the following requirements (refer to the 248 applications section for more information): 250 a) Preference of a high speed backbone area link for non-backbone 251 traffic. 253 b) On-demand (automatic) partition repair for non-backbone areas. 255 c) Multiple TAs could be configured over a backbone path, each (TA) 256 belonging to a different area in order to provide an intra-area 257 path for each area and saving the cost of an additional link. 259 An additional advantage is the cost of TA is configurable allowing 260 a traffic path to be selected independent of the intra-area path 261 cost. This allows an alternate traffic path to be forced. 263 13. Applications 265 In this section we give a few examples of how TAs can be used. 267 13.1 Prefer Inter-area Path over intra-area Path 269 It is a common requirement that users would like to prefer the high 270 bandwidth part of the backbone for traffic that can be strictly 271 routed inside the non-backbone area. 273 Consider the following topology: 275 R1-------backbone------R2 276 | | 277 area 1 area 1 278 | | 279 R3--------area 1--------R4 281 Fig.1 283 The backbone link between R1 and R2 is a high speed link and could 284 be used to forward part of the area 1's traffic between R1 and R2. 285 In the current OSPF specification, intra-area paths are preferred 286 over inter-area paths. As a result, R1 will always route traffic 287 to R4 through area 1 over the lower speed links. Even to reach 288 networks connected to R2 that belong to area 1, R1 will use the 289 intra-area path over area 1. 291 By configuring a TA between R1 and R2, a P2P link will be advertised 292 into area 1 making the TA a topological part of area 1 with a lower 293 cost than than the low speed links. 295 Note that the above scenario can not be solved using a VL since the 296 link between R1 and R2 belongs to the backbone area and it is not 297 desirable to move this backbone link in a non-backbone area. 299 It should also be noted that the connection between R1 and R2 in 300 the backbone area could be multiple hops away. In other words, 301 TAs are not limited to directly connected topologies. 303 13.2 On-demand partition avoidance for summarized non-backbone area 305 In general when a non-backbone area is partitioned there is no 306 need for partition repair as intra-area routes will be replaced 307 by inter-area routes for the partiationed area. However, this is 308 not true if the area is summarized into the backbone. Consider 309 the following topology: 311 R1-------backbone------R2 312 | | 313 area 1 area 1 314 | | 315 R3--------area 1--------R4 317 Fig.3 319 R1 and R2 are summarizing area 1 into the backbone area. When area 320 1 becomes partitioned due the R3-R4 going down, R1 and R2 continue 321 to summarize area 1 into the backbone area. This can lead to 322 blackholing of the traffic. The reason is that after the area 323 partitioning, R1 or R2 will only have knowledge of their attached 324 area partitions. When R1 or R2 receives a packet that does not 325 belong to its attached partitioned area (as a result of advertising 326 a summary) the packet will be discarded. 328 Note that R1 and R2 will install a discard route for the configured 329 summary range. If the destination doesn't match an intra-area 330 route in R1 or R2 area partition, the destination will match on 331 the less specific discard route. 333 By configuring an on-demand TA for area 1 through the backbone, 334 R1 and R2 will establish an adjacency if area 1 becomes 335 partitioned. 337 When a TA is configured between the two ABRs, a configuration option 338 (automatic) will be used to not start sending Hellos unless the other 339 ABR is not reachable via area 1. 341 The cost of on-demand TA should automatically be set to maximum 342 cost LSInfinity (16-bit value 0xFFFF). The reason to set the cost of 343 TA to 0xFFFF is to make it easier to detect that the area is no longer 344 partitioned. During the SPF, only the shortest path to the remote end 345 of the TA is discovered and making the TA cost the maximum reachable 346 cost will allow partition repair to be detected as a natural side 347 effect of the intra-area SPF calculation. 349 13.3 Saving additional link between ABRs in a Hub and Spoke environment 351 Consider the typical hub and spoke topology in figure 4. 353 R1---BB--R2 354 | \ / | 355 | \ / | 356 | \/ | 357 | /\ | 358 | / \ | 359 Spoke1 Spoke2 361 Fig.4 363 Only two spokes are represented in figure 4, but in general we may 364 have N spokes similar to Spoke1. 366 R1 and R2 are ABRs and can be multiple hops away over the backbone 367 area (BB). Further, the ABRs are summarizing IP prefixes from all 368 the attached areas into the backbone. 370 Case 1: Spoke1 and Spoke2 are in different area 371 ----------------------------------------------- 373 Since both R1 and R2 are summarizing, there is a need for a link 374 between R1 and R2 in each connected area. This is to guarantee an 375 alternative path when the link between a spoke and hub becomes 376 unavailable. 378 For example, imagine a network X advertised by Spoke1 and summarized 379 by both R1 and R2. Later the link between R1 and Spoke1 goes down. 380 When a packet arrives at R1 to be forwarded to Spoke1, R1 cannot send 381 the packet to Spoke1 since the link is not available. 382 Since R1 is summarizing this route it may have installed a discard 383 route for summarized range (here we assume the range is still 'active', 384 as there may be other spokes in the same area as Spoke1 that are still 385 attached to R1 and advertising prefixes that fall in the same range as X). 386 Hence, R1 will not use an inter-area path over R2. A link between R1 387 and R2 inside the same area as the link between R1 and Spoke1 would 388 prevent this problem. 390 Case 2: Spoke1 and Spoke2 are in the same area 391 ---------------------------------------------- 393 Link between R1 and Spoke1 is broken. The path from R1 to Spoke1 is 394 R1-Spoke2-R2-Spoke1 instead of R1-R2-Spoke1. 396 In general, for N areas being attached to the hub routers, there is 397 a need for N links between hub routers. Multiple TAs could be used 398 through the backbone between the hub routers to avoid using multiple 399 physical links between ABRs (each belonging to a different 400 non-backbone area) 402 14. Tunnel adjacency parameters 404 Tunnel adjacencies can be configured in a non-backbone areas between 405 area border routers having at least one backbone conection. 406 A tunnel adjacency is defined by the following configurable 407 parameters: 409 o The Router ID of the Tunnel adjacency's endpoint. 411 o The area where the tunnel adjacency resides. 413 Optionally, the following parameters are configurable: 415 o The cost of the tunnel adjacency which will override 416 intra-area cost between the two TA endpoints. 418 o The encapsulation type to be used when the two TA endpoints 419 are not directly connected. The default is GRE. 421 o The 'automatic' option used for on on-demand partition repair. 423 15. Tunnel adjacency in OSPFv3 425 All mechanisms described in this document for OSPFv2 applies also to 426 OSPFv3 [4] with the following exceptions: 428 o The IPv6 interface address of a tunnel adjacency must be an IPv6 429 address having a global scope, instead of the link-local addresses 430 used by other interface types. This address is used as the IPv6 431 source for OSPF protocol packets sent over the tunnel adjacency. 433 o Likewise, the tunnel adjacency neighbor's IPv6 address is an IPv6 434 address with global scope. 436 o Like all other IPv6 OSPF interfaces, tunnel adjacency are assigned 437 unique (within the router) Interface IDs. These are advertised in 438 Hellos sent over the tunnel adjacency and specified for links in 439 the router's router-LSAs. 441 16. Compatibility issues 443 All mechanisms described in this document are backward-compatible 444 with standard OSPF implementations. 446 17. Security 448 Tunnel adjacencies as specified in this document do not raise any 449 security issues that are not already covered in [1]. 451 18. Acknowledgments 453 Authors would like to thank Abhay Roy, Liem Nguyen, Pat Murphy, 454 and Alex Zinin for their comments on the document. 456 19. Reference 458 [1] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 460 [2] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", 461 RFC 3101, January 2003. 463 [3] D. Farinacci, T. Li, S. Hanks, D. Meyer and P. Traina, 464 "Generic Routing Encapsulation (GRE), RFC 2784, March 2000. 466 [4] R. Coltun, D. Ferguson and J. Moy, "OSPF for IPv6", 467 RFC 2740, December 1999. 469 20. Authors' address 471 Sina Mirtorabi 472 Cisco Systems 473 225 West Tasman drive 474 San Jose, CA 95134 475 E-mail: sina@cisco.com 477 Peter Psenak 478 Cisco Systems 479 Parc Pegasus, 480 De Kleetlaan 6A 481 1831 Diegem 482 Belgium 483 E-mail: ppsenak@cisco.com 485 Acee Lindem 486 Redback Networks 487 102 Carric Bend Court 488 Cary, NC 27519 489 Email: acee@redback.com