idnits 2.17.1 draft-ietf-ospf-ppp-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 129 instances of lines with control characters in the document. == 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 "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 (November 2000) is 8562 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: May 2001 November 2000 5 File name: draft-ietf-ospf-ppp-flood-00.txt 7 Flooding over parallel point-to-point links 8 draft-ietf-ospf-ppp-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 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 Next hop calculation ................................... 4 47 2.4 MTU check .............................................. 4 48 3 Backward compatibility ................................. 5 49 4 Example ................................................ 5 50 5 Notes .................................................. 5 51 References ............................................. 6 52 Security Considerations ................................ 7 53 Authors' Addresses ..................................... 7 55 1. Overview 57 When multiple "equivalent" links connect a pair of OSPF routers, 58 database synchronization (both initial via the Database Exchange 59 process and ongoing via flooding, also called adjacency formation 60 and maintenance) need only be performed over one of the links. The 61 key reason for this is that remote routers only care that at least 62 one link is advertised in the two routers' router-LSAs; 63 advertisement of additional links is redundant. 65 The definition of "equivalent" links is as follows. A set of links 66 are equivalent if they (a) are all point-to-point links, (b) all 67 connect the same pair of OSPF routers, and (c) all belong to the 68 same OSPF area. 70 The organization of this memo is as follows. Section 2 describes the 71 implementation in detail. In a nutshell, the changes required to 72 implement the reduction in adjacencies are: (Section 2.1) The router 73 with the higher OSPF router ID chooses which of the equivalent links 74 to form adjacencies over; the remaining equivalent links stay in 75 state 2-Way. (Section 2.2) When an existing adjacency is lost, the 76 router with the higher Router ID froms an adjacency over one of the 77 other equivalent links. (Section 2.3) The routing calculation in the 78 routers at either end of t he equivalent links is modified to 79 include the 2-Way links as next hops. (Section 2.4) The MTU check is 80 performed as part of Hello processing, since it is now required on 81 2-Way links as well as adjacencies. 83 Section 3 addresses backward compatibility with implementations of 84 the OSPF specification [Ref1]. A simple example of the adjacency 85 reduction is given in Section 4. Additional information concerning 86 the adjacency reduction, including anomalies and possible 87 enhancements, are provided in Section 5. 89 2. Implementation 91 This section discusses the implementation of the adjacency reduction 92 in detail, identifying the sections of the base OSPF protocol [Ref1] 93 which must be modified. 95 2.1. Whether to become adjacent 97 The decision as to whether to become adjacent with a neighbor is 98 covered by Section 10.4, "Whether to become adjacent", of the 99 OSPF specification [Ref1]. That section must be modified to 100 implement the following idea: "When there are multiple 101 equivalent links attaching a pair of OSPF Routers, the Router 102 with the higher OSPF Router ID decides which links will form 103 adjacencies". 105 In particular, if Section 10.4 of [Ref1] indicates that the 106 router should form an adjacency with a neighbor (transitioning 107 the neighbor from 2-Way to ExStart state), the router should 108 execute additional steps as follows: 110 (1) If the interface type is other than point-to-point, start 111 forming the adjacency. 113 (2) If the neighbor is asking to form an adjacency (that is, 114 we're running the logic in Section 10.4 of [Ref1] because we 115 have received a Database Description packet from the 116 neighbor), start forming the adjacency. This is necessary 117 for backward compatibility. 119 (3) Otherwise, we're running Section 10.4 of [Ref1] because 120 either (i) we've just received a bidirectional Hello from 121 the neighbor, (ii) there was an error in the previous 122 Database Exchange over this link or (iii) an adjacency over 123 an equivalent link has been lost (see Section 2.2). In this 124 case: 126 (a) If the router has a smaller Router ID than the neighbor, 127 leave the neighbor in state 2-Way. The neighbor will 128 decide over which of the equivalent links adjacencies 129 should form. 131 (b) If the router's Router ID is larger, examine all the 132 equivalent links to the neighbor. If one or more of them 133 are adjacent (neighbor state Full) or are in the process 134 of becoming adjacent (neighbor state greater than or 135 equal to ExStart) leave the neighbor state on the 136 current link in state 2-Way. Otherwise, start forming 137 the adjacency by transitioning the neighbor state to 138 ExStart. 140 2.2. Lost adjacencies 142 If the router with the higher OSPF Router ID notices that the 143 single adjacency in a collection of equivalent links has gone 144 down, it must replace it by forming an adjacency one another of 145 the equivalent links. 147 To be more precise, Section 10.3 of [Ref1] must be modified as 148 follows. If a neighbor in state ExStart or greater transitions 149 to a state of 2-Way or lower, and (a) the router has a larger 150 OSPF Router ID than the neighbor, (b) the link associated with 151 the failed adjacency is one of a collection of equivalent links, 152 and (c) none of the other equivalent links are in state ExStart 153 or greater, then the router must start forming an adjacency on 154 one of the equivalent 2-Way links (if any) by transitioning that 155 link's neighbor's state to ExStart, which starts the Database 156 Exchange process on that link. 158 2.3. Next hop calculation 160 We must change routing calculation in the routers at the end of 161 the equivalent links, allowing 2-Way interfaces to be installed 162 as next hops as long as at least one equivalent link is fully 163 adjacent (neighbor state Full). 165 To this effect, Section 16.1.1 of [Ref1] is changed as follows. 166 When installing a next hop to a directly connected router, 167 through a point-to-point interface, all equivalent links with 168 neighbors in state 2-Way should be added as equal-cost next 169 hops. 171 2.4. MTU check 173 Since you are now adding certain 2-way, but non-adjacent, links 174 as next hops in the routing table entries (Section 2.3), the MTU 175 mismatch detection must be implemented in OSPF Hello packets 176 sent over point-to-point links. To this end, Hello packets sent 177 over point-to-point links (Section 9.5 of [Ref1]) have their 178 Designated Router field set to the MTU of the point-to-point 179 interface. Upon receiving an Hello on a point-to-point 180 interface (Section 10.5 of [Ref1]), the new MTU field is 181 examined. If it is greater than the interface's MTU, the Hello 182 is discarded, preventing the neighbor relationship from forming 183 and the interface from being installed as a next hop in the 184 routing table (see Section G.9 of [Ref3] for more details on MTU 185 mismatches). 187 3. Backward compatibility 189 This memo is backward compatible with implementations of the OSPF 190 specification in [Ref1]. No negotiation between neighbors is 191 required. If the neighbor runs [Ref1] but not the enhancements in 192 this memo, adjacencies will form over all links, because of Step 2 193 in Section 2.1. 195 4. Example 197 Suppose there are six point-to-point links connecting Routers A and 198 B. Router A has the higher OSPF Router ID. The first two links 199 (IfIndex 1 and 2 on the Router A end) belong to Area 0.0.0.0. The 200 last four (IfIndexes 3-6 in Router A) belong to Area 0.0.0.1. There 201 are then two sets of equivalent links, one for each area. 203 In all cases, OSPF Hellos will always be sent over all links. 204 Assuming the links are all operational, they will all attain a 205 neighbor state of 2-Way. 207 There are then three cases of interest. 209 Case 1: 210 A and B running enhancements defined in this memo. In this case, 211 B will let A choose one link in each area over which to form an 212 adjacency. Suppose these are the links corresponding to 213 IfIndexes 1 and 3. If the link corresponding to IfIndex 3 later 214 fails, A will choose a different link (say IfIndex 4) over which 215 to form an adjacency. 217 Case 2: 218 Only A runs the enhancements in this memo. A will receive 219 requests to form adjacencies on all links (that is, Database 220 Description packets from B) and will cooperate by establishing 221 adjacencies over all links. 223 Case 3: 224 Only B runs the enhancements in this memo. The mirror image of 225 Case 2; adjacencies again form over all links. 227 5. Notes 229 Here is additional information on the enhancements provided by this 230 memo. 232 (1) The biggest code change required by this memo is to base the 233 decision to form an adjacency on whether a Database 234 Description packet has just been seen from the neighbor (Step 235 2 of Section 2.1). However, this distinction is useful for 236 other reasons; for example, in rate-limiting the number of 237 concurrent Database Exchange sessions (see Section 8.3 of 238 [Ref2]). 240 (2) This memo didn't change the logic of router-LSA origination. 241 So as a side benefit, you also get compression of the router- 242 LSA as it only includes one of each set of equivalent links. 244 (3) If you assign different costs within a set of equivalent 245 links, this memo breaks that functionality, as it simply 246 advertises the cost associated with the link that becomes 247 adjacent. However, if assigning differing costs within a set 248 of equivalent links is important, then an implementation can 249 either a) advertise the smallest cost of any 2-Way link 250 within the set of equivalent links or b) select the link to 251 become adjacent based on smallest cost (only works if costs 252 are configured symmetricly). 254 (4) Why not include Point-to-MultiPoint links in the equivalent 255 links definition? Because they can't be excluded from the 256 router-LSA, as they are necessary for the next hop 257 calculation. 259 (5) When the single adjacency goes down, packets will not be 260 forwarded between the neighbors until a new adjacency is 261 formed. To get around this problem, you can introduce a new 262 parameter, NumFloodingLinks, and require that that many 263 adjacencies be formed within each set of equivalent links. 264 This is equivalent to OSPF's Backup Designated Router on 265 broadcast subnets. 267 (6) Whenever you are limiting the number of adjacencies, you 268 should timeout adjacencies that are not progressing towards 269 Full state. See Section 8.3 of [Ref2] for details. 271 References 273 [Ref1] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 275 [Ref2] Moy, J., "OSPF Complete Implementation", Addison-Wesley, 276 October 2000. 278 [Ref3] Moy, J., "OSPF Version 2", RFC 2178, July 1997. 280 Security Considerations 282 This memo does not create any new security issues for the OSPF 283 protocol. Security considerations for the base OSPF protocol are 284 covered in [Ref1]. 286 Authors Addresses 288 J. Moy 289 Sycamore Networks, Inc. 290 150 Apollo Drive 291 Chelmsford, MA 01824 292 Phone: (978) 367-2505 293 Fax: (978) 256-4203 294 email: jmoy@sycamorenet.com