idnits 2.17.1 draft-ietf-ospf-transport-instance-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 date (October 5, 2009) is 5311 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) == Outdated reference: A later version (-02) exists of draft-acee-ospf-multi-instance-01 == Outdated reference: A later version (-04) exists of draft-ietf-isis-genapp-01 Summary: 1 error (**), 0 flaws (~~), 3 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: April 8, 2010 S. Mirtorabi 6 Cisco Systems 7 October 5, 2009 9 OSPF Transport Instance Extensions 10 draft-ietf-ospf-transport-instance-03.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 8, 2010. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 OSPFv2 and OSPFv3 include a reliable flooding mechanism to 49 disseminate routing topology and Traffic Engineering (TE) information 50 within a routing domain. Given the effectiveness of these 51 mechanisms, it is convenient to envision using the same mechanism for 52 dissemination of other types of information within the domain. 53 However, burdening OSPF with this additional information will impact 54 intra-domain routing convergence and possibly jeopardize the 55 stability of the OSPF routing domain. This document presents 56 mechanism to relegate this ancillary information to a separate OSPF 57 instance and minimize the impact. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 63 2. OSPF Transport Instance . . . . . . . . . . . . . . . . . . . 4 64 2.1. OSPFv2 Transport Instance Packets Differentiation . . . . 4 65 2.2. OSPFv3 Transport Instance Packets Differentiation . . . . 4 66 2.3. Instance Relationship to Normal OSPF Instances . . . . . . 4 67 2.3.1. Ships in the Night Relationship to Normal OSPF 68 Instances . . . . . . . . . . . . . . . . . . . . . . 5 69 2.3.2. Tighter Coupling with Normal OSPF Instances . . . . . 5 70 2.4. Network Prioritization . . . . . . . . . . . . . . . . . . 5 71 2.5. OSPF Transport Instance Omission of Routing Calculation . 5 72 2.6. Non-routing Instance Separation . . . . . . . . . . . . . 6 73 2.7. Non-Routing Sparse Topologies . . . . . . . . . . . . . . 6 74 2.7.1. Remote OSPF Neighbor . . . . . . . . . . . . . . . . . 7 75 3. OSPF Transport Instance Information Encoding . . . . . . . . . 8 76 3.1. OSPFv2 Transport Instance Information Encoding . . . . . . 8 77 3.2. OSPFv3 Transport Instance Information Encoding . . . . . . 8 78 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 80 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 6.1. Normative References . . . . . . . . . . . . . . . . . . . 11 82 6.2. Informative References . . . . . . . . . . . . . . . . . . 11 83 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 12 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 86 1. Introduction 88 OSPFv2 [OSPFV2] and OSPFv3 [OSPFV3] include a reliable flooding 89 mechanism to disseminate routing topology and Traffic Engineering 90 (TE) information within a routing domain. Given the effectiveness of 91 these mechanisms, it is convenient to envision using the same 92 mechanism for dissemination of other types of information within the 93 domain. However, burdening OSPF with this additional information 94 will impact intra-domain routing convergence and possibly jeopardize 95 the stability of the OSPF routing domain. This document presents 96 mechanism to relegate this ancillary information to a separate OSPF 97 instance and minimize the impact. 99 1.1. Requirements notation 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [RFC-KEYWORDS]. 105 2. OSPF Transport Instance 107 In order to isolate the overhead of flooding non-routing information, 108 its flooding will be relegated to a separate protocol instance. This 109 instance should be given lower priority when contending for router 110 resources including processing, backplane bandwidth, and line card 111 bandwidth. How that is realized is an implementation issue and is 112 beyond the scope of this document. 114 Throughout the document, non-routing refers to routing information 115 that is not used for IP or IPv6 routing calculations. The OSPF 116 transport instance is ideally suited for dissemination of routing 117 information for other protocols and layers. 119 2.1. OSPFv2 Transport Instance Packets Differentiation 121 OSPFv2 currently doesn't offer a mechanism to differentiate Transport 122 instance packets from normal instance packets sent and received on 123 the same interface. However, the [MULTI-INST] provides the necessary 124 packet encoding to support multiple OSPF protocol instances. 126 2.2. OSPFv3 Transport Instance Packets Differentiation 128 Fortunately, OSPFv3 already supports separate instances within the 129 packet encodings. The existing OSPFv3 packet header instance ID 130 field will be used to differentiate packets received on the same link 131 (refer to section 2.4 in [OSPFV3]). 133 2.3. Instance Relationship to Normal OSPF Instances 135 There are basically two alternatives for the relationship between a 136 normal OSPF instance and a Transport Instance. In both cases, we 137 must guarantee that any information we've received is treated as 138 valid if and only if the router sending it is reachable. We'll refer 139 to this as the "condition of reachability" in this document. 141 1. Ships in the Night - The Transport Instance has no relationship 142 or dependency on any other OSPF instance. 144 2. Child Instance - The Transport Instance has a child-parent 145 relationship with a normal OSPF instance and is dependent on this 146 for topology information and assuring the "condition of 147 reachability". 149 2.3.1. Ships in the Night Relationship to Normal OSPF Instances 151 In this mode, the Transport Instance is not dependent on any other 152 OSPF instance. It does, however, have much of the overhead as 153 topology information must be advertised to satisfy the condition of 154 reachability. 156 Prefix information does this need to be advertised. This implies 157 that for OSPFv2, only router-LSAs, network-LSAs, and type 4 summary- 158 LSAs need to be advertised. In the router-LSAs, the stub (type 3) 159 links may be suppressed. For OSPFv3, this implies that router-LSAs, 160 Network-LSAs, and inter-area-router-LSAs must be advertised. 162 2.3.2. Tighter Coupling with Normal OSPF Instances 164 Further optimization and coupling between the transport instance and 165 a normal OSPF instance are beyond the scope of this document. This 166 is an area for future study. 168 2.4. Network Prioritization 170 While OSPFv2 (section 4.3 in [OSPFV2]) are normally sent with IP 171 precedence Internetwork Control, any packets sent by a transport 172 instance will be sent with IP precedence Flash (B'011'). This is 173 only appropriate given that this is a pretty flashy mechanism. 175 Similarly, OSPFv3 transport instance packets will be sent with the 176 traffic class mapped to flash (B'011') as specified in ([OSPFV3]. 178 By setting the IP/IPv6 precedence differently for OSPF transport 179 instance packets, normal OSPF routing instances can be given priority 180 during both packet transmission and reception. In fact, some router 181 implementations map the IP precedence directly to their internal 182 packet priority. However, implementation issues are beyond the scope 183 of this document. 185 2.5. OSPF Transport Instance Omission of Routing Calculation 187 Since the whole point of the transport instance is to separate the 188 routing and non-routing processing and fate sharing, a transport 189 instance SHOULD NOT install any routes. OSPF routers SHOULD NOT 190 advertise any transport instance LSAs containing IP or IPv6 prefixes 191 and OSPF routers receiving LSAs advertising prefixes SHOULD ignore 192 them. This implies that an OSPFv2 transport instance Link State 193 Database should not include any Summary-LSAs (type 3) , AS-External- 194 LSAs (type 5), or NSSA-LSAs (type 7) and the Router-LSAs should not 195 include any stub (type 3) links. An OSPFv3 transport instance Link 196 State database should not include any Inter-Area-Prefix-LSAs (type 197 0x2003), AS-External-LSAs (0x4005), NSSA-LSAs (type 0x2007), or 198 Intra-Area-Prefix-LSAs (type 0x2009). If they are erroneously 199 advertised, they MUST be ignored by OSPF routers supporting this 200 specification. 202 2.6. Non-routing Instance Separation 204 It has been suggested that an implementation could obtain the same 205 level of separation between IP routing information and non-routing 206 information in a single instance with slight modifications to the 207 OSPF protocol. The authors refute this contention for the following 208 reasons: 210 o Adding internal and external mechanisms to prioritize routing 211 information over non-routing information are much more complex 212 than simply relegating the non-routing information to a separate 213 instance as proposed in this specification. 215 o The instance boundary offers much better separation for allocation 216 of finite resources such as buffers, memory, processor cores, 217 sockets, and bandwidth. 219 o The instance boundary decreases the level of fate sharing for 220 failures. Each instance may be implemented as a separate process 221 or task. 223 o With non-routing information, many times not every router in the 224 OSPF routing domain requires knowledge of every piece of routing 225 information. In these cases, groups of routers which need to 226 share information can be segregated into sparse topologies greatly 227 reducing the amount of non-routing information any single router 228 needs to maintain. 230 2.7. Non-Routing Sparse Topologies 232 With non-routing information, many times not every router in the OSPF 233 routing domain requires knowledge of every piece of routing 234 information. In these cases, groups of routers which need to share 235 information can be segregated into sparse topologies. This will 236 greatly reduce the amount of information any single router needs to 237 maintain with the core routers possibly not requiring any non-routing 238 information at all. 240 With normal OSPF, every router in an OSPF area must have every piece 241 of topological and IP or IPv6 prefix routing information. With non- 242 routing information, only the routers needing to share a set of 243 information need be part of the corresponding sparse topology. For 244 directly attached routers, one only needs to configure the desired 245 topologies on the interfaces with routers requiring the non-routing 246 information. When the routers making up the sparse topology are not 247 part of a uniconnected graph, two alternatives exist. The first 248 alternative is configure tunnels to form a fully connected graph 249 including only those routers in the sparse topology. The second 250 alternative is use remote neighbors as described in Section 2.7.1. 252 2.7.1. Remote OSPF Neighbor 254 With sparse topologies, OSPF routers sharing non-routing information 255 may not be directly connected. OSPF adjacencies with remote 256 neighbors are formed exactly as they are with regular OSPF neighbors. 257 The main difference is that a remote OSPF neighbor's address is 258 configured and IP routing is used to deliver packet to the remote 259 neighbor. Other salient feature of remote neighbor include: 261 o All OSPF packets are addressed to the remote neighbor's configured 262 IP address. 264 o The adjacency is represented in the router Router-LSA as a router 265 (type-1) link with the link data set to the remote neighbor 266 address. 268 o Similar to NBMA networks, a poll-interval is configured to 269 determine if the remote neighbor is reachable. This value is 270 normally much higher than the hello interval. 272 3. OSPF Transport Instance Information Encoding 274 The format of the TLVs within the body of an LSA containing non- 275 routing information is the same as the format used by the Traffic 276 Engineering Extensions to OSPF [TE]. The LSA payload consists of one 277 or more nested Type/Length/Value (TLV) triplets. The format of each 278 TLV is: 280 0 1 2 3 281 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 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Type | Length | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Value... | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 TLV Format 290 However, each unique application using the mechanisms defined in this 291 document will have it's own unique ID. Whether to encode this ID as 292 the top-level TLV or make it part of the OSPF LSA ID is open for 293 debate. 295 The specific TLVs and sub-TLVs relating to a given application and 296 the corresponding IANA considerations MUST for standard applications 297 MUST be specified in the document corresponding to that application. 299 3.1. OSPFv2 Transport Instance Information Encoding 301 Application specific information will be flooded in opaque LSAs as 302 specified in [OPAQUE]. 304 3.2. OSPFv3 Transport Instance Information Encoding 306 Application specific information will be flooded in separate LSAs 307 with separate function codes. Refer to section A.4.2.1 of [OSPFV3] 308 for information on the LS Type encoding in OSPFv3. 310 4. Security Considerations 312 The security considerations for the Transport Instance will not be 313 different for those for OSPFv2 [OSPFV2] and OSPFv3 [OSPFV3]. 315 5. IANA Considerations 317 No new IANA assignments are required for this draft. 319 6. References 321 6.1. Normative References 323 [MULTI-INST] 324 Lindem, A., Mirtorabi, S., and A. Roy, "OSPF Multi- 325 Instance Extensions", 326 draft-acee-ospf-multi-instance-01.txt (work in progress). 328 [OPAQUE] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 329 OSPF Opaque LSA Option", RFC 5250, July 2008. 331 [OSPFV2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 333 [OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 334 for IPv6", RFC 5340, July 2008. 336 [RFC-KEYWORDS] 337 Bradner, S., "Key words for use in RFC's to Indicate 338 Requirement Levels", RFC 2119, March 1997. 340 [TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering 341 Extensions to OSPF", RFC 3630, September 2003. 343 6.2. Informative References 345 [ISIS-GEN-APP] 346 Ginsberg, L., Previdi, S., and M. Shand, "Advertising 347 Generic Information in IS-IS", 348 draft-ietf-isis-genapp-01.txt (work in progress). 350 Appendix A. Acknowledgments 352 The RFC text was produced using Marshall Rose's xml2rfc tool. 354 Although very different mechanisms are utilized, the concept of using 355 a separate instance to advertise non-routing information in an IGP 356 was first introduced in "Advertising Generic Information in IS-IS" 357 [ISIS-GEN-APP]. 359 Thanks to Jonathan Sadler for comments on the document. 361 Authors' Addresses 363 Acee Lindem 364 Ericsson 365 102 Carric Bend Court 366 Cary, NC 27519 367 USA 369 Email: acee.lindem@ericsson.com 371 Abhay Roy 372 Cisco Systems 373 225 West Tasman Drive 374 San Jose, CA 95134 375 USA 377 Email: akr@cisco.com 379 Sina Mirtorabi 380 Cisco Systems 381 3 West Plumeria Drive 382 San Jose, CA 95134 383 USA 385 Email: sina@cisco.com