idnits 2.17.1 draft-ietf-ospf-subset-flood-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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 12 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 181 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 (February 2001) is 8443 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'Ref4' is defined on line 258, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2370 (ref. 'Ref2') (Obsoleted by RFC 5250) == Outdated reference: A later version (-01) exists of draft-ietf-ospf-ppp-flood-00 -- Possible downref: Normative reference to a draft: ref. 'Ref3' ** Obsolete normative reference: RFC 2178 (ref. 'Ref4') (Obsoleted by RFC 2328) ** Obsolete normative reference: RFC 2740 (ref. 'Ref5') (Obsoleted by RFC 5340) Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Moy 3 Internet Draft Sycamore Networks, Inc. 4 Expiration Date: July 2001 February 2001 5 File name: draft-ietf-ospf-subset-flood-00.txt 7 Flooding Over a Subset Topology 8 draft-ietf-ospf-subset-flood-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 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet- Drafts as 23 reference material or to cite them other than as "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 This memo defines a method for limiting the flooding of OSPF LSAs to 34 a configurable subset of the network topology. The following OSPF 35 properties are maintained: (1) routers are omitted from the routing 36 calculation until their link-state databases are synchronized and 37 (2) links must be bidirectional before they can be used in the 38 calculation. Backward-compatibility with unmodified OSPF routers is 39 also provided. 41 Table of Contents 43 1 Overview ............................................... 2 44 2 Mechanisms ............................................. 3 45 2.1 Deciding to become adjacent ............................ 3 46 2.2 LSA origination ........................................ 3 47 2.2.1 Advertising forwarding adjacencies ..................... 4 48 2.3 Modified routing calculation ........................... 4 49 2.4 MTU check .............................................. 5 50 4 Backward compatibility ................................. 5 51 5 Notes .................................................. 5 52 References ............................................. 6 53 A New LSA formats ........................................ 7 54 A.1 Router-LSA: rtype field ................................ 8 55 A.2 Router-additions-LSA .................................. 10 56 A.3 Network-additions-LSA ................................. 12 57 Security Considerations ............................... 13 58 Authors' Addresses .................................... 13 60 1. Overview 62 Standard OSPF floods its LSAs over all links. This flooding logic is 63 simple, robust, and auto-configuring. However, in highly meshed 64 environments when many routers have a large number of neighbors, 65 this flooding can be a burden on the router's processing power. 67 For that reason, this memo suggests restricting flooding to a 68 configured set of links. For backward-compatibility, and to enable 69 the network operator to restore control connectivity from any 70 location, a link is used for flooding if configured as such in 71 *either* end. To prevent a link to be used for flooding, we use the 72 technique from [Ref3], preventing its neighbor relationships from 73 advancing past 2-way state. 75 These neighbor relationships that were artificially stopped at 2-way 76 state, but would have advanced to Full state if Section 10.4 of 77 [Ref1] were followed, are termed "forwarding adjacencies". We do not 78 change the building of router-LSAs and network-LSAs, and instead 79 report these forwarding adjacencies in a new set of LSAs, called 80 router-addition-LSAs and network-addition-LSAs. 82 The standard OSPF routing calculation is then extended on an area- 83 by-area basis to include the forwarding adjacencies, but only if 84 both (a) all routers in the area support this memo and (b) both ends 85 of the forwarding adjacency are reachable via the standard OSPF 86 routing calculation. 88 2. Mechanisms 90 The descriptions of the required enhancements is split into the 91 following sections. Section 2.1 describes how we prevent flooding on 92 certain links by preventing their neighbor relationships from 93 advancing past state 2-Way. These non-flooding relationships, called 94 "forwarding adjacencies", are advertised in new LSAs as described in 95 Section 2.2. Section 2.3 describes how these new LSAs are used in 96 the routing calculation. The use of forwarding adjacencies requires 97 that we perform the MTU check in the OSPF Hello protocol, as Section 98 2.4 explains. 100 2.1. Deciding to become adjacent 102 OSPF floods only to neighbors is state Exchange or greater. So 103 we prevent flooding on a link by preventing the neighbor 104 relationships on the link from advancing past 2-way, exactly as 105 was done in [Ref3]. 107 In particular, if Section 10.4 of [Ref1] indicates that the 108 router should form an adjacency with a neighbor (transitioning 109 the neighbor from 2-Way to ExStart state), the router should 110 execute additional steps as follows: 112 (1) If the interface type is Virtual Link, start forming the 113 adjacency (we don't allow you to disable flooding over 114 virtual links). 116 (2) If the neighbor is asking to form an adjacency (that is, 117 we're running the logic in Section 10.4 of [Ref1] because we 118 have received a Database Description packet from the 119 neighbor), start forming the adjacency. This is necessary 120 for backward compatibility. 122 (3) Otherwise, we're running Section 10.4 of [Ref1] because 123 either (i) we've just received a bidirectional Hello from 124 the neighbor, (ii) there was an error in the previous 125 Database Exchange over this link or (iii) an adjacency over 126 an equivalent link has been lost (see Section 2.2). In this 127 case, start forming the adjacency by transitioning the 128 neighbor state to ExStart *only* if you have been configured 129 to do so. 131 2.2. LSA origination 133 A router implementing the enhancements in this memo sets the FA 134 bit it its router-LSA's type field (Section A.1), and advertises 135 its forwarding adjacencies in router-addition-LSAs and network- 136 addition-LSAs. 138 2.2.1. Advertising forwarding adjacencies 140 Forwarding adjacencies, those bidirectional neighbors 141 (neighbor state 2-Way) that would have been advertised in 142 router-LSAs and network-LSAs had the router been configured 143 to flood over them, are advertised instead in router- 144 addition-LSAs and network-addition-LSAs. 146 The way a forwarding adjacency is advertised depends upon 147 its associated interface type and the role that the router 148 is playing on the associated segment. 150 o Neighbors that have been stopped at 2-Way state on 151 point-to-point and point-to-multipoint interfaces are 152 added to router-addition-LSAs as Type 1 links (point-to- 153 point connection to another router), formatted according 154 to Sections 12.4.1.1 and 12.4.1.4 of [Ref1]. 156 o If the router is attached to a broadcast or NBMA 157 segment, is not the DR, and its conversation with the DR 158 has been limited to state 2Way, a Type 2 link 159 (connection to a transit network) is added to a router- 160 addition-LSA. 162 o If the router is the DR on an attached broadcast or NBMA 163 segment, neighbor conversations that have been limited 164 to state 2Way are added to network-addition-LSAs. 166 2.3. Modified routing calculation 168 If all the router-LSAs in Area A's link-state database have the 169 FA bit (Section A.1) set in their rtype field, then the OSPF 170 routing calculation for Area A is modified as follows. 172 (1) The intra-area calculation for Area A, Section 16.1 of 173 [Ref1], is run to determine which routers are reachable 174 in Area A. 176 (2) The intra-area calculation is then rerun. However, this 177 time when Section 16.1 of [Ref1] examines the router-LSA 178 for router X, you must examine both the router-LSA 179 originated by X *and* all the router-addition-LSAs that 180 it has originated. Likewise, when 16.1 of [Ref1] examines 181 network-LSAs for network N (defined by its Designated 182 Router's address), you must examine the network-LSA and 183 also all matching network-addition-LSAs. For the 184 forwarding adjacencies listed in router-addition-LSAs and 185 network-addition-LSAs, we substitute a different check 186 for the bidirectional check in Step 2b of Section 16.1 of 187 [Ref1]. In order to use a forwarding adjacency in the 188 routing calculation, both router endpoints must have been 189 found to be reachable. 191 2.4. MTU check 193 Links that are not used by the OSPF Database Exchange process 194 are now included in the routing calculation. However, we still 195 want links with MTU mismatches to be excluded from the routing 196 calculation. For this reason we implement the MTU mismatch 197 detection in OSPF's Hello Protocol, exactly as was specified in 198 Section 2.4 of [Ref3]. This logic prevents links with MTU 199 mismatches from being declared bidirectional. See Section G.9 200 of [Ref3] for more details on MTU mismatches. 202 3. Backward compatibility 204 If the router's neighbor requests to form a full adjacency, by 205 sending a Database Description packet, the router must comply as 206 long as a full adjacency is warranted according to Section 10.4 of 207 [Ref1}, and is the same backward-compatibility mechanism used by 208 [Ref3]. 210 Also, all routers within an OSPF area need to be capable of 211 including forwarding adjacencies (advertised in router-additions- 212 LSAs and network-additions-LSAs) in their routing calculations 213 before any router in the area is allowed to. This is determined by 214 checking to see that all router-LSAs in the area's link-state 215 database have the FA-bit set. 217 4. Notes 219 Note the following concerning the enhancements proposed by this 220 memo. 222 o We do not recommend any particular configuration syntax. A 223 vendor may decide to let you configure over which links to 224 flood, or configure over which links not to flood. Or the vendor 225 could combine with the functionality of [Ref3], and configure 226 the Router IDs of the neighbors with which to flood (or not to 227 flood). 229 o In the future, the routers may themselves choose which links to 230 use in flooding, For example, if a distributed, stable algorithm 231 were developed which produced a 2-connected spanning graph, that 232 might be used to autoconfigure the flooding links. 234 o If insufficient links are configured from flooding, some routers 235 may become isolated from the flooding algorithm, and hence from 236 the routing calculation. However, since a link's flooding 237 participation need only be configured in one endpoint, and 238 operator would be able to reconfigure flooding and fix the 239 problem remotely. 241 o Two Dijkstra calculations are employed by the enhanced routing 242 calculation of this memo, the first to determine router 243 reachability, and the second to include the forwarding 244 adjacencies. However, since the first only deals with 245 reachability, one does not need to perform its sorting phase. 247 References 249 [Ref1] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 251 [Ref2] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 252 1998. 254 [Ref3] Moy, J., "Flooding over parallel point-to-point links", 255 Internet Draft, draft-ietf-ospf-ppp-flood-00.txt, November 256 2000. RFC 2154, June 1997. 258 [Ref4] Moy, J., "OSPF Version 2", RFC 2178, July 1997. 260 [Ref5] Coltun, R., D. Ferguson and J. Moy, "OSPF for IPv6", RFC 261 2740, December 1999. 263 A. New LSA formats 265 This memo requires that the router set an additional bit in it's 266 router-LSA's rtype field (Section A.1) and that the router be 267 capable of originating and processing two new LSAs, the router- 268 additions-LSA (Section A.2) and the network-additions-LSA (Section 269 A.2). 271 A.1 Router-LSA: rtype field 273 The format and building of the OSPF router-LSA remains unchanged, 274 reflecting the router's full adjacencies (neighbor state Full) as 275 specified in Section 12.4.1 of [Ref1]. However, a new flag, called 276 bit FA, is added to the rtype field of the router-LSA. A router sets 277 this bit if and only if it is capable of using the new router- 278 additions-LSAs and network-additions-LSAs in its routing 279 calculations. Equivalently, bit FA is set when the router is capable 280 of using forwarding adjacencies in the routing calculation. Setting 281 bit FA also implies that the router is capable of handling Opaque- 282 LSAs, as specified in [Ref2]. 284 0 1 2 3 285 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 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | LS age | Options | 1 | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Link State ID | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Advertising Router | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | LS sequence number | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | LS checksum | length | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | rtype | 0 | # links | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 299 | Link ID | P 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E 301 | Link Data | R 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Type | # TOS | TOS 0 metric | # 304 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L 305 # | TOS | 0 | metric | I 306 T +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N 307 O | ... | K 308 S +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S 309 | | TOS | 0 | metric | | 310 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 311 | ... | 313 The router-LSA 314 +---+---+---+---+---+---+---+---+ 315 | * | FA| S | Nt| W | V | E | B | 316 +---+---+---+---+---+---+---+-+-+ 318 The rtype field 319 A.2 Router-additions-LSA 321 The router-additions-LSA is an area-scoped Opaque-LSA, having Opaque 322 Type equal to TBD1. It is used to advertise forwarding adjacencies, 323 and uses the same format as the router-LSA. The router's collection 324 of forwarding adjacencies can be listed in one or more router- 325 additions-LSAs, with the Opaque ID field used to distinguish the 326 LSAs. Rules for building the router-additions-LSA are described in 327 Section 2.2.1 above. 328 0 1 2 3 329 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 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | LS age | Options | 10 | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Opaque Type | Opaque ID | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Advertising Router | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | LS sequence number | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | LS checksum | length | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | 0 | # links | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 343 | Link ID | P 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E 345 | Link Data | R 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Type | # TOS | TOS 0 metric | # 348 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L 349 # | TOS | 0 | metric | I 350 T +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N 351 O | ... | K 352 S +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S 353 | | TOS | 0 | metric | | 354 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 355 | ... | 357 The router-additions-LSA 359 The format of the router-additions-LSA is identical to the router- 360 LSA, except for the following differences: 362 o Multiple router-addition-LSAs can be originated, distinguished 363 by Opaque ID. The value of Opaque ID can be arbitrary. Note the 364 similarity to the OSPF for IPv6 router-LSA [Ref5]. 366 o The router-additions-LSA has no rtype field. 368 A.3 Network-additions-LSA 370 The network-additions-LSA is an area-scoped Opaque-LSA, having 371 Opaque Type equal to TBD2. It is used by the Designated Router on a 372 broadcast or NBMA segment to advertise its forwarding adjacencies on 373 the segment, and uses a similar format to the network-LSA. The 374 router's collection of forwarding adjacencies can be listed in one 375 or more network-additions-LSAs, with the Opaque ID field used to 376 distinguish the LSAs. Rules for building the network-additions-LSA 377 are described in Section 2.2.1 above. 379 0 1 2 3 380 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 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | LS age | Options | 10 | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Opaque Type | Opaque ID | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Advertising Router | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | LS sequence number | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | LS checksum | length | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Network Address | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Network Mask | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Attached Router | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | ... | 400 The format of the network-additions-LSA is identical to the network- 401 LSA, except for the following differences: 403 o The IP address of the network segment is included in the body of 404 the network-additions-LSA, in the "Network Address" field. As in 405 standard OSPF, this is the IP address of the segment's 406 Designated Router. 408 o Multiple network-addition-LSAs can be originated, distinguished 409 by Opaque ID. The value of Opaque ID can be arbitrary. 411 Security Considerations 413 This memo does not create any new security issues for the OSPF 414 protocol. Security considerations for the base OSPF protocol are 415 covered in [Ref1]. 417 Authors' Addresses 419 J. Moy 420 Sycamore Networks, Inc. 421 150 Apollo Drive 422 Chelmsford, MA 01824 423 Phone: (978) 367-2505 424 Fax: (978) 256-4203 425 email: jmoy@sycamorenet.com