idnits 2.17.1 draft-ietf-ospf-transport-instance-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 25, 2014) is 3585 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: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Lindem 3 Internet-Draft Ericsson 4 Intended status: Standards Track A. Roy 5 Expires: December 27, 2014 S. Mirtorabi 6 Cisco Systems 7 June 25, 2014 9 OSPF Transport Instance Extensions 10 draft-ietf-ospf-transport-instance-11.txt 12 Abstract 14 OSPFv2 and OSPFv3 include a reliable flooding mechanism to 15 disseminate routing topology and Traffic Engineering (TE) information 16 within a routing domain. Given the effectiveness of these 17 mechanisms, it is convenient to envision using the same mechanism for 18 dissemination of other types of information within the domain. 19 However, burdening OSPF with this additional information will impact 20 intra-domain routing convergence and possibly jeopardize the 21 stability of the OSPF routing domain. This document presents 22 mechanism to relegate this ancillary information to a separate OSPF 23 instance and minimize the impact. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on December 27, 2014. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 59 10, 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material outside the IETF Standards Process. 62 Without obtaining an adequate license from the person(s) controlling 63 the copyright in such materials, this document may not be modified 64 outside the IETF Standards Process, and derivative works of it may 65 not be created outside the IETF Standards Process, except to format 66 it for publication as an RFC or to translate it into languages other 67 than English. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4 73 2. OSPF Transport Instance . . . . . . . . . . . . . . . . . . . 5 74 2.1. OSPFv2 Transport Instance Packets Differentiation . . . . 5 75 2.2. OSPFv3 Transport Instance Packets Differentiation . . . . 5 76 2.3. Instance Relationship to Normal OSPF Instances . . . . . . 5 77 2.3.1. Ships in the Night Relationship to Normal OSPF 78 Instances . . . . . . . . . . . . . . . . . . . . . . 6 79 2.3.2. Tighter Coupling with Normal OSPF Instances . . . . . 6 80 2.4. Network Prioritization . . . . . . . . . . . . . . . . . . 6 81 2.5. OSPF Transport Instance Omission of Routing Calculation . 6 82 2.6. Non-routing Instance Separation . . . . . . . . . . . . . 7 83 2.7. Non-Routing Sparse Topologies . . . . . . . . . . . . . . 7 84 2.7.1. Remote OSPF Neighbor . . . . . . . . . . . . . . . . . 8 85 3. OSPF Transport Instance Information Encoding . . . . . . . . . 9 86 3.1. OSPFv2 Transport Instance Information Encoding . . . . . . 9 87 3.2. OSPFv3 Transport Instance Information Encoding . . . . . . 9 88 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 89 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 90 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 91 6.1. Normative References . . . . . . . . . . . . . . . . . . . 12 92 6.2. Informative References . . . . . . . . . . . . . . . . . . 12 93 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 13 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 96 1. Introduction 98 OSPFv2 [OSPFV2] and OSPFv3 [OSPFV3] include a reliable flooding 99 mechanism to disseminate routing topology and Traffic Engineering 100 (TE) information within a routing domain. Given the effectiveness of 101 these mechanisms, it is convenient to envision using the same 102 mechanism for dissemination of other types of information within the 103 domain. However, burdening OSPF with this additional information 104 will impact intra-domain routing convergence and possibly jeopardize 105 the stability of the OSPF routing domain. This document presents 106 mechanism to relegate this ancillary information to a separate OSPF 107 instance and minimize the impact. 109 1.1. Requirements notation 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC-KEYWORDS]. 115 2. OSPF Transport Instance 117 In order to isolate the effects of flooding and processing of non- 118 routing information, it will be relegated to a separate protocol 119 instance. This instance should be given lower priority when 120 contending for router resources including processing, backplane 121 bandwidth, and line card bandwidth. How that is realized is an 122 implementation issue and is outside the scope of this document. 124 Throughout the document, non-routing refers to routing information 125 that is not used for IP or IPv6 routing calculations. The OSPF 126 transport instance is ideally suited for dissemination of routing 127 information for other protocols and layers. 129 2.1. OSPFv2 Transport Instance Packets Differentiation 131 OSPFv2 currently doesn't offer a mechanism to differentiate Transport 132 instance packets from normal instance packets sent and received on 133 the same interface. However, the [MULTI-INST] provides the necessary 134 packet encoding to support multiple OSPF protocol instances. 136 2.2. OSPFv3 Transport Instance Packets Differentiation 138 Fortunately, OSPFv3 already supports separate instances within the 139 packet encodings. The existing OSPFv3 packet header instance ID 140 field will be used to differentiate packets received on the same link 141 (refer to section 2.4 in [OSPFV3]). 143 2.3. Instance Relationship to Normal OSPF Instances 145 There are basically two alternatives for the relationship between a 146 normal OSPF instance and an OSPF transport instance. In both cases, 147 we must guarantee that any information we've received is treated as 148 valid if and only if the router sending it is reachable. We'll refer 149 to this as the "condition of reachability" in this document. 151 1. Ships in the Night - The OSPF transport instance has no 152 relationship or dependency on any other OSPF instance. 154 2. Child Instance - The OSPF transport instance has a child-parent 155 relationship with a normal OSPF instance and is dependent on this 156 for topology information and assuring the "condition of 157 reachability". 159 2.3.1. Ships in the Night Relationship to Normal OSPF Instances 161 In this mode, the OSPF transport instance is not dependent on any 162 other OSPF instance. It does, however, have much of the same as 163 topology information must be advertised to satisfy the "condition of 164 reachability". 166 Prefix information does not need to be advertised. This implies that 167 for OSPFv2, only router-LSAs, network-LSAs, and type 4 summary-LSAs 168 need to be advertised. In the router-LSAs, the stub (type 3) links 169 may be suppressed. For OSPFv3, this implies that router-LSAs, 170 network-LSAs, and inter-area-router-LSAs must be advertised. 172 2.3.2. Tighter Coupling with Normal OSPF Instances 174 Further optimizations and coupling between an OSPF transport instance 175 and a normal OSPF instance are beyond the scope of this document. 176 This is an area for future study. 178 2.4. Network Prioritization 180 While OSPFv2 (section 4.3 in [OSPFV2]) are normally sent with IP 181 precedence Internetwork Control, any packets sent by an OSPF 182 transport instance will be sent with IP precedence Flash (B'011'). 183 This is only appropriate given that this is a pretty flashy 184 mechanism. 186 Similarly, OSPFv3 transport instance packets will be sent with the 187 traffic class mapped to flash (B'011') as specified in ([OSPFV3]. 189 By setting the IP/IPv6 precedence differently for OSPF transport 190 instance packets, normal OSPF routing instances can be given priority 191 during both packet transmission and reception. In fact, some router 192 implementations map the IP precedence directly to their internal 193 packet priority. However, internal router implementation decisions 194 are beyond the scope of this document. 196 2.5. OSPF Transport Instance Omission of Routing Calculation 198 Since the whole point of the transport instance is to separate the 199 routing and non-routing processing and fate sharing, a transport 200 instance SHOULD NOT install any IP or IPv6 routes. OSPF routers 201 SHOULD NOT advertise any transport instance LSAs containing IP or 202 IPv6 prefixes and OSPF routers receiving LSAs advertising IP or IPv6 203 prefixes SHOULD ignore them. This implies that an OSPFv2 transport 204 instance Link State Database should not include any summary-LSAs 205 (type 3) , AS-external-LSAs (type 5), or NSSA-LSAs (type 7) and the 206 router-LSAs should not include any stub (type 3) links. An OSPFv3 207 transport instance Link State database should not include any inter- 208 area-prefix-LSAs (type 0x2003), AS-external-LSAs (0x4005), NSSA-LSAs 209 (type 0x2007), or intra-area-prefix-LSAs (type 0x2009). If they are 210 erroneously advertised, they will be flooded as per standard OSPF but 211 MUST be ignored by OSPF routers supporting this specification. 213 2.6. Non-routing Instance Separation 215 It has been suggested that an implementation could obtain the same 216 level of separation between IP routing information and non-routing 217 information in a single instance with slight modifications to the 218 OSPF protocol. The authors refute this contention for the following 219 reasons: 221 o Adding internal and external mechanisms to prioritize routing 222 information over non-routing information are much more complex 223 than simply relegating the non-routing information to a separate 224 instance as proposed in this specification. 226 o The instance boundary offers much better separation for allocation 227 of finite resources such as buffers, memory, processor cores, 228 sockets, and bandwidth. 230 o The instance boundary decreases the level of fate sharing for 231 failures. Each instance may be implemented as a separate process 232 or task. 234 o With non-routing information, many times not every router in the 235 OSPF routing domain requires knowledge of every piece of non- 236 routing information. In these cases, groups of routers which need 237 to share information can be segregated into sparse topologies 238 greatly reducing the amount of non-routing information any single 239 router needs to maintain. 241 2.7. Non-Routing Sparse Topologies 243 With non-routing information, many times not every router in the OSPF 244 routing domain requires knowledge of every piece of non-routing 245 information. In these cases, groups of routers which need to share 246 information can be segregated into sparse topologies. This will 247 greatly reduce the amount of information any single router needs to 248 maintain with the core routers possibly not requiring any non-routing 249 information at all. 251 With normal OSPF, every router in an OSPF area must have every piece 252 of topological information and every intra-area IP or IPv6 prefix. 253 With non-routing information, only the routers needing to share a set 254 of information need be part of the corresponding sparse topology. 256 For directly attached routers, one only needs to configure the 257 desired topologies on the interfaces with routers requiring the non- 258 routing information. When the routers making up the sparse topology 259 are not part of a uniconnected graph, two alternatives exist. The 260 first alternative is configure tunnels to form a fully connected 261 graph including only those routers in the sparse topology. The 262 second alternative is use remote neighbors as described in 263 Section 2.7.1. 265 2.7.1. Remote OSPF Neighbor 267 With sparse topologies, OSPF routers sharing non-routing information 268 may not be directly connected. OSPF adjacencies with remote 269 neighbors are formed exactly as they are with regular OSPF neighbors. 270 The main difference is that a remote OSPF neighbor's address is 271 configured and IP routing is used to deliver OSPF protocol packets to 272 the remote neighbor. Other salient feature of the remote neighbor 273 include: 275 o All OSPF packets have the remote neighbor's configured IP address 276 as the IP destination address. 278 o The adjacency is represented in the router Router-LSA as a router 279 (type-1) link with the link data set to the remote neighbor's 280 configured IP address. 282 o Similar to NBMA networks, a poll-interval is configured to 283 determine if the remote neighbor is reachable. This value is 284 normally much higher than the hello interval with 40 seconds 285 RECOMMENDED as the default. 287 3. OSPF Transport Instance Information Encoding 289 The format of the TLVs within the body of an LSA containing non- 290 routing information is the same as the format used by the Traffic 291 Engineering Extensions to OSPF [TE]. The LSA payload consists of one 292 or more nested Type/Length/Value (TLV) triplets. The format of each 293 TLV is: 295 0 1 2 3 296 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Type | Length | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Value... | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 TLV Format 305 However, each unique application using the mechanisms defined in this 306 document will have it's own unique ID. Whether to encode this ID as 307 the top-level TLV or make it part of the OSPF LSA ID is open for 308 debate. 310 The specific TLVs and sub-TLVs relating to a given application and 311 the corresponding IANA considerations MUST for standard applications 312 MUST be specified in the document corresponding to that application. 314 3.1. OSPFv2 Transport Instance Information Encoding 316 Application specific information will be flooded in opaque LSAs as 317 specified in [OPAQUE]. 319 3.2. OSPFv3 Transport Instance Information Encoding 321 Application specific information will be flooded in separate LSAs 322 with separate function codes. Refer to section A.4.2.1 of [OSPFV3] 323 for information on the LS Type encoding in OSPFv3. 325 4. Security Considerations 327 The security considerations for the Transport Instance will not be 328 different for those for OSPFv2 [OSPFV2] and OSPFv3 [OSPFV3]. 330 5. IANA Considerations 332 No IANA actions are required. 334 6. References 336 6.1. Normative References 338 [MULTI-INST] 339 Lindem, A., Mirtorabi, S., and A. Roy, "OSPF Multi- 340 Instance Extensions", RFC 6549, March 2012. 342 [OPAQUE] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 343 OSPF Opaque LSA Option", RFC 5250, July 2008. 345 [OSPFV2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 347 [OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 348 for IPv6", RFC 5340, July 2008. 350 [RFC-KEYWORDS] 351 Bradner, S., "Key words for use in RFCs to Indicate 352 Requirement Levels", RFC 2119, March 1997. 354 [TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering 355 Extensions to OSPF", RFC 3630, September 2003. 357 6.2. Informative References 359 [ISIS-GEN-APP] 360 Ginsberg, L., Previdi, S., and M. Shand, "Advertising 361 Generic Information in IS-IS", RFC 6823, December 2012. 363 Appendix A. Acknowledgments 365 The RFC text was produced using Marshall Rose's xml2rfc tool. 367 Although very different mechanisms are utilized, the concept of using 368 a separate instance to advertise non-routing information in an IGP 369 was first introduced in "Advertising Generic Information in IS-IS" 370 [ISIS-GEN-APP]. 372 Thanks to Jonathan Sadler for comments on the document. 374 Authors' Addresses 376 Acee Lindem 377 Ericsson 378 301 Midenhall Way 379 Cary, NC 27513 380 USA 382 Email: acee.lindem@ericsson.com 384 Abhay Roy 385 Cisco Systems 386 225 West Tasman Drive 387 San Jose, CA 95134 388 USA 390 Email: akr@cisco.com 392 Sina Mirtorabi 393 Cisco Systems 394 3 West Plumeria Drive 395 San Jose, CA 95134 396 USA 398 Email: sina@cisco.com