idnits 2.17.1 draft-ietf-ospf-ppp-flood-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 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 161 instances of lines with control characters in the document. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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 8471 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'Ref2' ** Obsolete normative reference: RFC 2178 (ref. 'Ref3') (Obsoleted by RFC 2328) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 3 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: August 2001 February 2001 5 File name: draft-ietf-ospf-ppp-flood-01.txt 7 Flooding over parallel point-to-point links 8 draft-ietf-ospf-ppp-flood-01.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 The OSPF routing protocol synchronizes its link-state database over 34 all links. However, when multiple point-to-point links connect a 35 pair of OSPF routers, it is only necessary to flood over one of the 36 parallel links. This can be done in a backward-compatible fashion, 37 without requiring negotiation between neighboring routers, as 38 described in this memo. 40 Table of Contents 42 1 Overview ............................................... 2 43 2 Implementation ......................................... 3 44 2.1 Whether to become adjacent ............................. 3 45 2.2 Lost adjacencies ....................................... 4 46 2.3 Originating router-LSAs ................................ 4 47 2.4 Next hop calculation ................................... 5 48 2.5 MTU check .............................................. 5 49 3 Backward compatibility ................................. 5 50 4 Example ................................................ 6 51 5 Notes .................................................. 6 52 References ............................................. 7 53 Security Considerations ................................ 7 54 Authors' Addresses ..................................... 8 56 1. Overview 58 When multiple "equivalent" links connect a pair of OSPF routers, 59 database synchronization (both initial via the Database Exchange 60 process and ongoing via flooding, also called adjacency formation 61 and maintenance) need only be performed over one of the links. The 62 key reason for this is that remote routers only care that at least 63 one link is advertised in the two routers' router-LSAs; 64 advertisement of additional links is redundant. 66 The definition of "equivalent" links is as follows. A set of links 67 are equivalent if they (a) are all point-to-point links, (b) all 68 connect the same pair of OSPF routers, and (c) all belong to the 69 same OSPF area. 71 The organization of this memo is as follows. Section 2 describes the 72 implementation in detail. In a nutshell, the changes required to 73 implement the reduction in adjacencies are: (Section 2.1) The router 74 with the higher OSPF router ID chooses which of the equivalent links 75 to form adjacencies over; the remaining equivalent links stay in 76 state 2-Way. (Section 2.2) When an existing adjacency is lost, the 77 router with the higher Router ID forms an adjacency over one of the 78 other equivalent links. (Section 2.3) Router-LSAs advertise at most 79 one Type 1 router link (point-to-point connection to another router) 80 for the entire collection of equivalent links, with the advertised 81 cost equal to the smallest cost of any of the 2-Way links. (Section 82 2.4) The routing calculation in the routers at either end of the 83 equivalent links is modified to include the least cost 2-Way links 84 as next hops. (Section 2.5) The MTU check is performed as part of 85 Hello processing, since it is now required on 2-Way links as well as 86 adjacencies. 88 Section 3 addresses backward compatibility with implementations of 89 the OSPF specification [Ref1]. A simple example of the adjacency 90 reduction is given in Section 4. Additional information concerning 91 the adjacency reduction, including anomalies and possible 92 enhancements, are provided in Section 5. 94 2. Implementation 96 This section discusses the implementation of the adjacency reduction 97 in detail, identifying the sections of the base OSPF protocol [Ref1] 98 which must be modified. 100 2.1. Whether to become adjacent 102 The decision as to whether to become adjacent with a neighbor is 103 covered by Section 10.4, "Whether to become adjacent", of the 104 OSPF specification [Ref1]. That section must be modified to 105 implement the following idea: "When there are multiple 106 equivalent links attaching a pair of OSPF Routers, the Router 107 with the higher OSPF Router ID decides which links will form 108 adjacencies". 110 In particular, if Section 10.4 of [Ref1] indicates that the 111 router should form an adjacency with a neighbor (transitioning 112 the neighbor from 2-Way to ExStart state), the router should 113 execute additional steps as follows: 115 (1) If the interface type is other than point-to-point, start 116 forming the adjacency. 118 (2) If the neighbor is asking to form an adjacency (that is, 119 we're running the logic in Section 10.4 of [Ref1] because we 120 have received a Database Description packet from the 121 neighbor), start forming the adjacency. This is necessary 122 for backward compatibility. 124 (3) Otherwise, we're running Section 10.4 of [Ref1] because 125 either (i) we've just received a bidirectional Hello from 126 the neighbor, (ii) there was an error in the previous 127 Database Exchange over this link or (iii) an adjacency over 128 an equivalent link has been lost (see Section 2.2). In this 129 case: 131 (a) If the router has a smaller Router ID than the neighbor, 132 leave the neighbor in state 2-Way. The neighbor will 133 decide over which of the equivalent links adjacencies 134 should form. 136 (b) If the router's Router ID is larger, examine all the 137 equivalent links to the neighbor. If one or more of them 138 are adjacent (neighbor state Full) or are in the process 139 of becoming adjacent (neighbor state greater than or 140 equal to ExStart) leave the neighbor state on the 141 current link in state 2-Way. Otherwise, start forming 142 the adjacency by transitioning the neighbor state to 143 ExStart. 145 2.2. Lost adjacencies 147 If the router with the higher OSPF Router ID notices that the 148 single adjacency in a collection of equivalent links has gone 149 down, it must replace it by forming an adjacency one another of 150 the equivalent links. 152 To be more precise, Section 10.3 of [Ref1] must be modified as 153 follows. If a neighbor in state ExStart or greater transitions 154 to a state of 2-Way or lower, and (a) the router has a larger 155 OSPF Router ID than the neighbor, (b) the link associated with 156 the failed adjacency is one of a collection of equivalent links, 157 and (c) none of the other equivalent links are in state ExStart 158 or greater, then the router must start forming an adjacency on 159 one of the equivalent 2-Way links (if any) by transitioning that 160 link's neighbor's state to ExStart, which starts the Database 161 Exchange process on that link. 163 2.3. Originating router-LSAs 165 Section 12.4.1.1 of [Ref1], "Describing point-to-point 166 interfaces in the router-LSA", is changed as follows. If one or 167 more of the equivalent links is fully adjacent (neighbor state 168 Full), a single Type 1 link (point-to-point connection to 169 another router) is added to the router-LSA. The advertised 170 metric is set equal to the smallest cost of any of the 171 equivalent links which are in state 2-Way or greater. In this 172 way, in addition to the main benefit of reducing flooding 173 traffic, this memo also reduces the size of the router-LSA by 174 suppressing redundant link advertisements. 176 Type 3 links (connection to stub networks) continue to be added 177 to the router-LSA as specified in Section 12.4.1.1 of [Ref1]. Up 178 to one of these links will be added for each of the equivalent 179 links. 181 Now, in addition to the events listed in Section 12.4 of [Ref1], 182 the transition of a point-to-point link to/from neighbor state 183 2-Way can cause a router-LSA to be reoriginated. Such a state 184 transition may change the cost that is advertised for the 185 equivalent links' Type 1 link. 187 2.4. Next hop calculation 189 We must change routing calculation in the routers at the end of 190 the equivalent links, allowing 2-Way interfaces to be installed 191 as next hops as long as at least one equivalent link is fully 192 adjacent (neighbor state Full). 194 To this effect, Section 16.1.1 of [Ref1] is changed as follows. 195 When installing a next hop to a directly connected router, 196 through a point-to-point interface, all least cost equivalent 197 links to the neighbor in state 2-Way or greater should be added 198 as equal-cost next hops. 200 Even if it doesn't cause the contents of the link-state database 201 to change, the transition of a point-to-point link to/from 202 neighbor state 2-Way may change the next hops of routing table 203 entries, forcing rerunning of the routing calculation. 205 2.5. MTU check 207 Since you are now adding certain 2-way, but non-adjacent, links 208 as next hops in the routing table entries (Section 2.4), the MTU 209 mismatch detection must be implemented in OSPF Hello packets 210 sent over point-to-point links. To this end, Hello packets sent 211 over point-to-point links (Section 9.5 of [Ref1]) have their 212 Designated Router field set to the MTU of the point-to-point 213 interface. Upon receiving an Hello on a point-to-point 214 interface (Section 10.5 of [Ref1]), the new MTU field is 215 examined. If it is greater than the interface's MTU, the Hello 216 is discarded, preventing the neighbor relationship from forming 217 and the interface from being installed as a next hop in the 218 routing table (see Section G.9 of [Ref3] for more details on MTU 219 mismatches). 221 3. Backward compatibility 223 This memo is backward compatible with implementations of the OSPF 224 specification in [Ref1]. No negotiation between neighbors is 225 required. If the neighbor runs [Ref1] but not the enhancements in 226 this memo, adjacencies will form over all links, because of Step 2 227 in Section 2.1. 229 4. Example 231 Suppose there are six point-to-point links connecting Routers A and 232 B. Router A has the higher OSPF Router ID. The first two links 233 (IfIndex 1 and 2 on the Router A end) belong to Area 0.0.0.0. The 234 last four (IfIndexes 3-6 in Router A) belong to Area 0.0.0.1. There 235 are then two sets of equivalent links, one for each area. 237 In all cases, OSPF Hellos will always be sent over all links. 238 Assuming the links are all operational, they will all attain a 239 neighbor state of 2-Way. 241 There are then three cases of interest. 243 Case 1: 244 A and B running enhancements defined in this memo. In this case, 245 B will let A choose one link in each area over which to form an 246 adjacency. Suppose these are the links corresponding to 247 IfIndexes 1 and 3. If the link corresponding to IfIndex 3 later 248 fails, A will choose a different link (say IfIndex 4) over which 249 to form an adjacency. Suppose that IfIndexes 5 and 6 have been 250 assigned the smallest costs, each with cost 10. As long as 251 IfIndexes 5 and 6 are bidirectional (in neighbor state 2-Way or 252 greater), A's router-LSA for area 0.0.0.1 will include a single 253 Type 1 link to B with cost 10, and the outgoing interfaces for 254 routing table entries through B will be the combination of 255 IfIndexes 5 and 6. This will be true both before and after the 256 failure of IfIndex 3. 258 Case 2: 259 Only A runs the enhancements in this memo. A will receive 260 requests to form adjacencies on all links (that is, Database 261 Description packets from B) and will cooperate by establishing 262 adjacencies over all links. 264 Case 3: 265 Only B runs the enhancements in this memo. The mirror image of 266 Case 2; adjacencies again form over all links. 268 5. Notes 270 Here is additional information on the enhancements provided by this 271 memo. 273 (1) The biggest code change required by this memo is to base the 274 decision to form an adjacency on whether a Database 275 Description packet has just been seen from the neighbor (Step 276 2 of Section 2.1). However, this distinction is useful for 277 other reasons; for example, in rate-limiting the number of 278 concurrent Database Exchange sessions (see Section 8.3 of 279 [Ref2]). 281 (2) Why not include Point-to-MultiPoint links in the equivalent 282 links definition? Because they can't be excluded from the 283 router-LSA, as they are necessary for the next hop 284 calculation. 286 (3) When the single adjacency goes down, packets will not be 287 forwarded between the neighbors until a new adjacency is 288 formed. To get around this problem, you can introduce a new 289 parameter, NumFloodingLinks, and require that that many 290 adjacencies be formed within each set of equivalent links. 291 This is equivalent to OSPF's Backup Designated Router on 292 broadcast subnets. 294 (4) Whenever you are limiting the number of adjacencies, you 295 should timeout adjacencies that are not progressing towards 296 Full state. See Section 8.3 of [Ref2] for details. 298 (5) If a router running the enhancements in this memo restarts, 299 and chooses not to form an adjacency over a given point-to- 300 point link, its neighbor may mistakenly believe that an 301 adjacency still exists: there may have been an adjacency 302 before the restart, and either the router did not send an 303 empty Hello Packet out the interface after restart, or the 304 Hello was dropped for some reason. The router will eventually 305 notice its neighbor's confusion when the neighbor sends a 306 Link State Update packet over the former adjacency. At this 307 time the router should tell the neighbor that the adjacency 308 no longer exists by responding with an empty Hello Packet. 310 References 312 [Ref1] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 314 [Ref2] Moy, J., "OSPF Complete Implementation", Addison-Wesley, 315 October 2000. 317 [Ref3] Moy, J., "OSPF Version 2", RFC 2178, July 1997. 319 Security Considerations 321 This memo does not create any new security issues for the OSPF 322 protocol. Security considerations for the base OSPF protocol are 323 covered in [Ref1]. 325 Authors Addresses 327 J. Moy 328 Sycamore Networks, Inc. 329 150 Apollo Drive 330 Chelmsford, MA 01824 331 Phone: (978) 367-2505 332 Fax: (978) 256-4203 333 email: jmoy@sycamorenet.com