idnits 2.17.1 draft-ietf-ospf-multi-area-adj-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 399. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 410. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 417. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 423. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (April 23, 2008) is 5818 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) ** Obsolete normative reference: RFC 2740 (ref. 'OSPFV3') (Obsoleted by RFC 5340) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Mirtorabi 3 Internet-Draft Nuova Systems 4 Intended status: Standards Track P. Psenak 5 Expires: October 25, 2008 Cisco Systems 6 A. Lindem (Editor) 7 A. Oswal 8 Redback Networks 9 April 23, 2008 11 OSPF Multi-Area Adjacency 12 draft-ietf-ospf-multi-area-adj-09.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on October 25, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2008). 43 Abstract 45 This document describes an extension to the Open Shortest Path First 46 (OSPF) protocol to allow a single physical link to be shared by 47 multiple areas. This is necessary to allow the link to be considered 48 an intra-area link in multiple areas. This would create an intra- 49 area path in each of the corresponding areas sharing the same link. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 55 1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.3. Possible Solutions . . . . . . . . . . . . . . . . . . . . 4 57 1.4. Proposed Solution . . . . . . . . . . . . . . . . . . . . 4 58 2. Functional Specifications . . . . . . . . . . . . . . . . . . 5 59 2.1. Multi-Area Adjacency Configuration and Neighbor 60 Discovery . . . . . . . . . . . . . . . . . . . . . . . . 5 61 2.2. Multi-Area Adjacency Packet Transmission . . . . . . . . . 5 62 2.3. Multi-Area Adjacency Control Packet Reception Changes . . 5 63 2.4. Interface Data Structure . . . . . . . . . . . . . . . . . 6 64 2.5. Interface FSM . . . . . . . . . . . . . . . . . . . . . . 6 65 2.6. Neighbor Data Structure and Neighbor FSM . . . . . . . . . 6 66 2.7. Advertising Multi-Area Adjacencies . . . . . . . . . . . . 6 67 3. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 8 68 3.1. Adjacency Endpoint Compatibility . . . . . . . . . . . . . 8 69 4. OSPFv3 Applicability . . . . . . . . . . . . . . . . . . . . . 9 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 74 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 75 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 13 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 77 Intellectual Property and Copyright Statements . . . . . . . . . . 15 79 1. Introduction 81 1.1. Requirements notation 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in RFC2119 86 [RFC-KEYWORDS]. 88 1.2. Motivation 90 It is often a requirement to have an Open Shortest Path First (OSPF) 91 [OSPF] link in multiple areas. This will allow the link to be 92 considered as an intra-area path in each area and be preferred over 93 higher cost links. A simple example is to use a high-speed backbone 94 link between two Area Border Routers (ABRs) to create multi-area 95 adjacencies belonging to different areas. 97 Consider the following topology: 99 R1-------Backbone------R2 100 | | 101 Area 1 Area 1 102 | | 103 R3--------Area 1--------R4 105 Multi-Link Topology 107 The backbone link between R1 and R2 is a high-speed link and it is 108 desirable to forward Area 1's traffic between R1 and R2 over that 109 link. In the current OSPF specification, intra-area paths are 110 preferred over inter-area paths. As a result, R1 will always route 111 traffic to R4 through Area 1 over the lower speed links. R1 will 112 even use the intra-area Area 1 path though R3 to get to area 1 113 networks connected to R2. An OSPF virtual link cannot be used to 114 solve this problem without moving the link between R1 and R2 to area 115 1. This is not desirable if the physical link is, in fact, part of 116 the network's backbone topology. 118 The protocol extension described herein will rectify this problem by 119 allowing the link between R1 and R2 to be part of both the backbone 120 and Area 1. 122 1.3. Possible Solutions 124 For numbered interfaces, the OSPF (Open Shortest Path First) 125 specification [OSPF] allows a separate OSPF interface to be 126 configured in each area using a secondary address. The disadvantages 127 of this approach are that it requires additional IP address 128 configuration, doesn't apply to unnumbered interfaces, and 129 advertising secondary addresses will result in a larger overall 130 routing table. 132 Allowing a link with a single address to simply be configured in 133 multiple areas would also solve the problem. However, this would 134 result in the subnet corresponding to the interface residing in 135 multiple areas that is contrary to the definition of an OSPF area as 136 a collection of subnets. 138 Another approach is to simply allow unnumbered links to be configured 139 in multiple areas. Section 8.2. of the OSPF specification already 140 specifies that the OSPF area ID should be used to de-multiplex 141 received OSPF packets. One limitation of this approach is that 142 multi-access networks are not supported. Although this limitation 143 may be overcome for LAN media with support of "Point-to-Point 144 operation over LAN in link-state routing protocols" [P2PLAN], it may 145 not be acceptable to configure the link as unnumbered due to network 146 management policies. Many popular network management applications 147 individually test the path to each interface and an IP address 148 facilitates this task. 150 1.4. Proposed Solution 152 ABRs will simply establish multiple adjacencies belonging to 153 different areas. Each multi-area adjacency is announced as a point- 154 to-point link in the configured area. However, unlike numbered 155 point-to-point links, no type 3 link is advertised for multi-area 156 adjacencies. This point-to-point link will provide a topological 157 path for that area. The first or primary adjacency using the link 158 will operate and advertise the link in a manner consistent with RFC 159 2328 [OSPF]. 161 2. Functional Specifications 163 2.1. Multi-Area Adjacency Configuration and Neighbor Discovery 165 Multi-area adjacencies are configured between two routers having a 166 common interface. On point-to-point interfaces, there is no need to 167 configure the neighbor's address since there can be only one 168 neighbor. For all other network types, the neighbor address of each 169 multi-area adjacency must be configured or automatically discovered 170 via a mechanism external to OSPF. 172 2.2. Multi-Area Adjacency Packet Transmission 174 On point-to-point interfaces, OSPF control packets are sent to the 175 AllSPFRouters address. For all other network types, OSPF control 176 packets are unicast to the remote neighbor's IP address. 178 2.3. Multi-Area Adjacency Control Packet Reception Changes 180 Receiving protocol packets is described in section 8.2 of [OSPF]. 181 The text starting with the second paragraph and continuing through 182 the third bullet beneath that paragraph is changed as follows: 184 Next, the OSPF packet header is verified. The fields specified in 185 the header must match those configured for the receiving interface. 186 If they do not, the packet should be discarded: 188 o The version number field must specify protocol version 2. 190 o The Area ID found in the OSPF header must be verified. If all of 191 the following cases fail, the packet should be discarded. The 192 Area ID specified in the header must either: 194 1. Match the Area ID of the receiving interface. In this case, 195 the packet has been sent over a single hop. Therefore, the 196 packet's IP source address is required to be on the same 197 network as the receiving interface. This can be verified by 198 comparing the packet's IP source address to the interface's IP 199 address, after masking both addresses with the interface mask. 200 This comparison should not be performed on point-to-point 201 networks. On point-to-point networks, the interface addresses 202 of each end of the link are assigned independently, if they 203 are assigned at all. 205 2. Indicate a non-backbone area. In this case, the packet has 206 been sent over a multi-area adjacency. If the area-id matches 207 the configured area for multi-area adjacency, the packet is 208 accepted and is from now on associated with the multi-area 209 adjacency for that area. 211 3. Indicate the backbone. In this case, the packet has been sent 212 over a virtual link or a multi-area adjacency. 214 o For virtual links, the receiving router must be an area border 215 router, and the Router ID specified in the packet (the source 216 router) must be the other end of a configured virtual link. The 217 receiving interface must also attach to the virtual link's 218 configured transit area. If all of these checks succeed, the 219 packet is accepted and is from now on associated with the virtual 220 link. 222 o For multi-area adjacencies, if the area-id matches the configured 223 area for the multi-area adjacency, the packet is accepted and is 224 from now on associated with the multi-area adjacency for that 225 area. 227 o Note that if there is a match for both a virtual link and a multi- 228 area adjacency then this is a configuration error that should be 229 handled at the configuration level. 231 o Packets whose IP destination is AllDRouters should only be 232 accepted if the state of the receiving interface is DR or Backup 233 (see Section 9.1 [OSPF]). 235 o [...] The remainder of section 8.2 [OSPF] is unchanged. 237 2.4. Interface Data Structure 239 An OSPF interface data structure is built for each configured multi- 240 area adjacency as specified in section 9 of [OSPF]. The interface 241 type will always be point-to-point. 243 2.5. Interface FSM 245 The interface FSM will be the same as a point-to-point link 246 irrespective of the underlying physical link. 248 2.6. Neighbor Data Structure and Neighbor FSM 250 Both the neighbor data structure and neighbor FSM are the same as for 251 standard OSPF, specified in section 10 of [OSPF]. 253 2.7. Advertising Multi-Area Adjacencies 255 Multi-area adjacencies are announced as point-to-point links. Once 256 the router's multi-area adjacency reaches the FULL state it will be 257 added as a link type 1 to the Router Link State Advertisement (LSA) 258 with: 260 Link ID = Remote's Router ID 262 Link Data = Neighbor's IP Address or IfIndex (if the underlying 263 interface is unnumbered). 265 Unlike numbered point-to-point links, no type 3 link is advertised 266 for multi-area adjacencies. 268 3. Compatibility 270 All mechanisms described in this document are backward compatible 271 with standard OSPF implementations [OSPF]. 273 3.1. Adjacency Endpoint Compatibility 275 Since multi-area adjacencies are modeled as unnumbered point-to-point 276 links, it is only necessary for the router at the other end of the 277 adjacency to model the adjacency as a point-to-point link. However, 278 the network topology will be easier to represent and troubleshoot if 279 both neighbors are symmetrically configured as multi-area 280 adjacencies. 282 4. OSPFv3 Applicability 284 The mechanisms defined in this document also apply to OSPFv3 285 [OSPFV3]. As in OSPF, a multi-area adjacency is advertised as an 286 unnumbered point-to-point link in the advertising router's router- 287 LSA. Since OSPFv3 router-LSA links are independent of addressing 288 semantics and unambiguously identify OSPFv3 neighbors (refer section 289 3.4.3.1 [OSPFV3]), the change to router-LSA links described in 290 Section 2.7 is not applicable to OSPFv3. Furthermore, no prefixes 291 corresponding to the multi-area adjacency are advertised in the 292 router's intra-area-prefix-LSA. 294 A link-LSA SHOULD NOT be advertised for a multi-area adjacency. The 295 neighbor's IPv6 link local address can be learned in other ways, 296 e.g., it can be extracted from the IPv6 header of Hello packets 297 received over the multi-area adjacency. The neighbor IPv6 link local 298 address is required for the OSPFv3 route next-hop calculation on 299 multi-access networks (refer section 3.8.1.1 [OSPFV3]). 301 5. Security Considerations 303 This document does not raise any security issues that are not already 304 covered in [OSPF] or [OSPFV3]. 306 6. IANA Considerations 308 This document does not require any IANA assignments or action. 310 7. References 312 7.1. Normative References 314 [OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 316 [OSPFV3] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", 317 RFC 2740, December 1999. 319 [RFC-KEYWORDS] 320 Bradner, S., "Key words for use in RFC's to Indicate 321 Requirement Levels", RFC 2119, March 1997. 323 7.2. Informative References 325 [P2PLAN] Shen, N. and A. Zinin, "Point-to-point operation over LAN 326 in link-state routing protocols", 327 draft-ietf-isis-igp-p2p-over-lan-06.txt (work in 328 progress). 330 Appendix A. Acknowledgments 332 The authors wish to acknowledge Pat Murphy for bringing focus to the 333 requirement. 335 Thanks to Mitchell Erblich's for his last call review and comments. 337 Thanks to Padma Pillay-Esnault for her last call review and comments. 338 Also thanks to Padma for comments on the OSPFv3 applicability section 339 that was last called separately. 341 Thanks to Nischal Seth for pointing out that the document 342 inadvertently precluded point-to-point over LAN interfaces. 344 Thanks to Ben Campbell for performing the General Area Review. 346 Thanks to Jari Arkko for comments during the IESG review. 348 The RFC text was produced using Marshall Rose's xml2rfc tool. 350 Authors' Addresses 352 Sina Mirtorabi 353 Nuova Systems 354 3 West Plumeria Drive 355 San Jose, CA 95134 356 USA 358 Email: sina@nuovasystems.com 360 Peter Psenak 361 Cisco Systems 362 Apollo Business Center 363 Mlynaki nivy 43 364 821 09 Bratislava, Sovakia 365 Slovakia 367 Email: ppsenak@cisco.com 369 Acee Lindem 370 Redback Networks 371 102 Carric Bend Court 372 Cary, NC 27519 373 USA 375 Email: acee@redback.com 377 Anand Oswal 378 Redback Networks 379 300 Holger Way 380 San Jose, CA 95134 381 USA 383 Email: aoswal@redback.com 385 Full Copyright Statement 387 Copyright (C) The IETF Trust (2008). 389 This document is subject to the rights, licenses and restrictions 390 contained in BCP 78, and except as set forth therein, the authors 391 retain all their rights. 393 This document and the information contained herein are provided on an 394 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 395 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 396 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 397 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 398 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 399 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 401 Intellectual Property 403 The IETF takes no position regarding the validity or scope of any 404 Intellectual Property Rights or other rights that might be claimed to 405 pertain to the implementation or use of the technology described in 406 this document or the extent to which any license under such rights 407 might or might not be available; nor does it represent that it has 408 made any independent effort to identify any such rights. Information 409 on the procedures with respect to rights in RFC documents can be 410 found in BCP 78 and BCP 79. 412 Copies of IPR disclosures made to the IETF Secretariat and any 413 assurances of licenses to be made available, or the result of an 414 attempt made to obtain a general license or permission for the use of 415 such proprietary rights by implementers or users of this 416 specification can be obtained from the IETF on-line IPR repository at 417 http://www.ietf.org/ipr. 419 The IETF invites any interested party to bring to its attention any 420 copyrights, patents or patent applications, or other proprietary 421 rights that may cover technology that may be required to implement 422 this standard. Please address the information to the IETF at 423 ietf-ipr@ietf.org. 425 Acknowledgment 427 Funding for the RFC Editor function is provided by the IETF 428 Administrative Support Activity (IASA).