idnits 2.17.1 draft-nsheth-ospf-hybrid-bcast-and-p2mp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == 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 (October 25, 2010) is 4925 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 288, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Sheth 3 Internet-Draft L. Wang 4 Intended status: Informational J. Zhang 5 Expires: April 25, 2011 Juniper Networks 6 October 25, 2010 8 OSPF Hybrid Broadcast and P2MP Interface Type 9 draft-nsheth-ospf-hybrid-bcast-and-p2mp-01.txt 11 Abstract 13 This document describes a mechanism to model a broadcast network as a 14 hybrid of broadcast and point-to-multipoint networks for purposes of 15 OSPF operation. Neighbor discovery and maintenance as well as LSA 16 database synchronization are performed using the broadcast model, but 17 the network is represented using the point-to-multipoint model in the 18 router LSAs of the routers connected to it. This allows an accurate 19 representation of the cost of communication between different routers 20 on the network, while maintaining the network efficiency of broadcast 21 operation. This approach is relatively simple and requires minimal 22 changes to OSPF. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on April 25, 2011. 47 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 76 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 78 3.1. Interface Parameters . . . . . . . . . . . . . . . . . . . 5 79 3.2. Neighbor Data Structure . . . . . . . . . . . . . . . . . 5 80 3.3. Neighbor Discovery and Maintenance . . . . . . . . . . . . 5 81 3.4. Database Synchronization . . . . . . . . . . . . . . . . . 5 82 3.5. Generating Network LSAs . . . . . . . . . . . . . . . . . 5 83 3.6. Generating Router and Intra-Area-Prefix-LSAs . . . . . . . 5 84 3.6.1. Stub Links in OSPFv2 Router LSA . . . . . . . . . . . 6 85 3.6.2. OSPFv3 Intra-Area-Prefix-LSA . . . . . . . . . . . . . 6 86 3.7. Next-Hop Calculation . . . . . . . . . . . . . . . . . . . 6 87 3.8. Graceful Restart . . . . . . . . . . . . . . . . . . . . . 6 88 4. Compatibility Considerations . . . . . . . . . . . . . . . . . 8 89 5. Scalability and Deployment Considerations . . . . . . . . . . 9 90 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 91 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 92 8. Normative References . . . . . . . . . . . . . . . . . . . . . 12 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 95 1. Introduction 97 OSPF [RFC2328] operation on broadcast interfaces takes advantage of 98 the broadcast capabilities of the underlying medium for doing 99 neighbor discovery and maintenance. Further, it uses a Designated 100 Router and Backup Designated Router to keep the LSA databases of the 101 routers on the network synchronized in an efficient manner. However, 102 it has the limitation that a router cannot advertise different costs 103 to each of the neighboring routers on the network in it's router LSA. 105 Operation on point-to-multipoint interfaces could require explicit 106 configuration of the identity of it's neighboring routers. It also 107 requires the router to send separate hellos to each neighbor on the 108 network. Further, it mandates establishment of adjacencies to all 109 all configured or discovered neighbors on the network. However, it 110 gives the routers the flexibility to advertise different costs to 111 each of the neighboring routers in their router LSAs. 113 This document proposes a new interface type that can be used on layer 114 2 networks that have broadcast capability. In this mode, neighbor 115 discovery and maintenance, as well as database synchronization are 116 performed using existing procedures for broadcast mode. The network 117 is modeled as a collection of point-to-point links in the router LSA, 118 just as it would be in point-to-multipoint mode. This new interface 119 type is referred to as hybrid-broadcast-and-p2mp in the rest of this 120 document. 122 2. Motivation 124 There are some layer 2 networks that are broadcast capable but have a 125 potentially different cost associated with communication between any 126 given pair of nodes. The cost could be based on the underlying layer 127 2 topology as well as various link quality metrics such as bandwidth, 128 delay and jitter among others. 130 It is not accurate to treat such networks as OSPF broadcast networks 131 since that does not allow a router to advertise a different cost to 132 each of the other routers. Using OSPF point-to-multipoint mode would 133 satisfy the requirement to correctly describe the cost to reach each 134 router. However, it would be inefficient in the sense that it would 135 require forming O(N^2) adjacencies when there are N routers on the 136 network. 138 It is advantageous to use the hybrid-broadcast-and-p2mp type for such 139 networks. This combines the flexibility of point-to-multipoint type 140 with the advantages and efficiencies of broadcast interface type. 142 3. Operation 144 OSPF routers supporting the capabilities described herein should have 145 support for an additional hybrid-broadcast-and-p2mp type for the Type 146 data item described in section 9 of [RFC2328]. 148 The following sub-sections describe salient aspects of OSPF operation 149 on routers configured with a hybrid-broadcast-and-p2mp interface. 151 3.1. Interface Parameters 153 Routers MUST support configuration of the Router Priority for the 154 interface. 156 The default value of the LinkLSASuppression is "disabled". It MAY be 157 set to "enabled" via configuration. 159 3.2. Neighbor Data Structure 161 Routers MUST support an additional field called the Neighbor Output 162 Cost. This is the cost of sending a data packet to the neighbor, 163 expressed in the link state metric. The default value of this field 164 is the Interface output cost. It MAY be set to a different value 165 using mechanisms which are outside the scope of this document, 166 like static per-neighbor configuration, or any dynamic discovery 167 mechanism that is supported by the underlying network. 169 3.3. Neighbor Discovery and Maintenance 171 Routers send and receive Hellos so as to perform neighbor discovery 172 and maintenance on the interface using the procedures specified for 173 broadcast interfaces in [RFC2328] and [RFC5340]. 175 3.4. Database Synchronization 177 Routers elect a DR and BDR for the interface and use them for initial 178 and ongoing database synchronization using the procedures specified 179 for broadcast interfaces in [RFC2328] and [RFC5340]. 181 3.5. Generating Network LSAs 183 Since a hybrid-broadcast-and-p2mp interface is described in router 184 LSAs using a collection of point-to-point links, the DR SHOULD NOT 185 generate a network LSA for the interface. 187 3.6. Generating Router and Intra-Area-Prefix-LSAs 189 Routers describe the interface in their router LSA as specified for a 190 point-to-multipoint interface in section 12.4.1.4 of [RFC2328] and 191 section 4.4.3.2 of [RFC5340], with the following modifications for 192 Type 1 links: 194 o If a router is not the DR, it MUST NOT add any Type 1 links if it 195 does not have a full adjacency to the DR. 197 o If a router is not the DR and has a full adjacency to the DR, it 198 MUST add a Type 1 link corresponding to each neighbor that is in 199 state 2-Way or higher. 201 o The cost for a Type 1 link corresponding to a neighbor SHOULD be 202 set to the value of the Neighbor Output Cost field as defined in 203 Section 3.2 205 3.6.1. Stub Links in OSPFv2 Router LSA 207 Routers MUST add a Type 3 link for their own IP address to the router 208 LSA as described in section 12.4.1.4 of [RFC2328]. Further, they 209 MUST also add a Type 3 link with the Link ID set to the IP subnet 210 address, Link Data set to the IP subnet mask, and cost equal to the 211 configured output cost of the interface. 213 3.6.2. OSPFv3 Intra-Area-Prefix-LSA 215 Routers MUST add global scoped IPv6 addresses on the interface to the 216 intra-area-prefix-LSA as described for point-to-multipoint interfaces 217 in section 4.4.3.9 of [RFC5340]. In addition, they MUST also add all 218 global scoped IPv6 prefixes on the interface to the LSA by specifying 219 the PrefixLength, PrefixOptions, and Address Prefix fields. The 220 Metric field for each of these prefixes is set to the configured 221 output cost of the interface. 223 The DR SHOULD NOT generate an intra-area-prefix-LSA for the transit 224 network for this interface since it does not generate a network LSA 225 for the interface. Note that the global prefixes associated with the 226 interface are advertised in the intra-area-prefix-LSA for the router 227 as described above. 229 3.7. Next-Hop Calculation 231 Next-Hops to destinations that are directly connected to a router via 232 the interface are calculated as specified for a point-to-multipoint 233 interface in section 16.1.1 of [RFC2328]. 235 3.8. Graceful Restart 237 The following modifications to the procedures defined in section 2.2, 238 item 1 of [RFC3623] are required in order to ensure that the router 239 correctly exits graceful restart. 241 o If a router is the DR on the interface, it MUST NOT examine the 242 pre-restart network LSA for the interface in order to determine 243 the previous set of adjacencies. 245 o If a router is in state DROther on the interface, it MUST consider 246 an adjacency to non-DR and non-BDR neighbors as reestablished when 247 the neighbor state reaches 2-Way. 249 4. Compatibility Considerations 251 All routers on the network must support the hybrid-broadcast-and-p2mp 252 interface type for successful operation. Otherwise, the interface 253 should be configured as a standard broadcast interface. 255 If some routers on the network treat the interface as broadcast and 256 others as hybrid-broadcast-and-p2mp, neighbors and adjacencies will 257 still get formed as for a broadcast interface. However, due to the 258 differences in how router and network LSAs are built for these two 259 interface types, there will be no traffic traversing certain pairs of 260 routers. Note that this will not cause any persistent loops or black 261 holing of traffic. 263 5. Scalability and Deployment Considerations 265 Treating a broadcast interface as hybrid-broadcast-and-p2mp results 266 in O(N^2) links to represent the network instead of O(N), when there 267 are N routers on the network. This will increase memory usage and 268 have a negative impact on route calculation performance on all the 269 routers in the area. Network designers should carefully weigh the 270 benefits of using the new interface type against the disadvantages 271 mentioned here. 273 6. Security Considerations 275 This document raises no new security issues for OSPF. Security 276 considerations for the base OSPF protocol are covered in [RFC2328] 277 and [RFC5340]. 279 7. IANA Considerations 281 This document has no IANA considerations. 283 This section should be removed by the RFC Editor to final 284 publication. 286 8. Normative References 288 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 289 Requirement Levels", BCP 14, RFC 2119, March 1997. 291 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 293 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 294 for IPv6", RFC 5340, July 2008. 296 [RFC3623] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF 297 Restart", RFC 3623, November 2003. 299 Authors' Addresses 301 Nischal Sheth 302 Juniper Networks 303 1194 N. Mathilda Ave. 304 Sunnyvale, CA 94089 305 US 307 Email: nsheth@juniper.net 309 Lili Wang 310 Juniper Networks 311 10 Technology Park Dr. 312 Westford, MA 01886 313 US 315 Email: liliw@juniper.net 317 Jeffrey Zhang 318 Juniper Networks 319 10 Technology Park Dr. 320 Westford, MA 01886 321 US 323 Email: zzhang@juniper.net