idnits 2.17.1 draft-ietf-ospf-hybrid-bcast-and-p2mp-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5340], [RFC2328]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC2328, but the abstract doesn't seem to directly say this. It does mention RFC2328 though, so this could be OK. -- The draft header indicates that this document updates RFC5340, but the abstract doesn't seem to directly say this. It does mention RFC5340 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2328, updated by this document, for RFC5378 checks: 1997-11-05) -- 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 (October 17, 2012) is 4208 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) ** Obsolete normative reference: RFC 6506 (Obsoleted by RFC 7166) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Sheth 3 Internet-Draft Contrail Systems 4 Updates: 2328, 5340 (if approved) L. Wang 5 Intended status: Standards Track J. Zhang 6 Expires: April 20, 2013 Juniper Networks 7 October 17, 2012 9 OSPF Hybrid Broadcast and P2MP Interface Type 10 draft-ietf-ospf-hybrid-bcast-and-p2mp-06.txt 12 Abstract 14 This document describes a mechanism to model a broadcast network as a 15 hybrid of broadcast and point-to-multipoint networks for purposes of 16 OSPF operation. Neighbor discovery and maintenance as well as Link 17 State Advertisement (LSA) database synchronization are performed 18 using the broadcast model, but the network is represented using the 19 point-to-multipoint model in the router LSAs of the routers connected 20 to it. This allows an accurate representation of the cost of 21 communication between different routers on the network, while 22 maintaining the network efficiency of broadcast operation. This 23 approach is relatively simple and requires minimal changes to OSPF. 25 This document updates both OSPFv2 [RFC2328] and OSPFv3 [RFC5340]. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 20, 2013. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 63 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 4.1. Interface Parameters . . . . . . . . . . . . . . . . . . . 6 66 4.2. Neighbor Data Structure . . . . . . . . . . . . . . . . . 6 67 4.3. Neighbor Discovery and Maintenance . . . . . . . . . . . . 6 68 4.4. Database Synchronization . . . . . . . . . . . . . . . . . 6 69 4.5. Generating Network LSAs . . . . . . . . . . . . . . . . . 6 70 4.6. Generating Router and Intra-Area-Prefix-LSAs . . . . . . . 7 71 4.6.1. Stub Links in OSPFv2 Router LSA . . . . . . . . . . . 7 72 4.6.2. OSPFv3 Intra-Area-Prefix-LSA . . . . . . . . . . . . . 7 73 4.7. Next-Hop Calculation . . . . . . . . . . . . . . . . . . . 7 74 4.8. Graceful Restart . . . . . . . . . . . . . . . . . . . . . 8 75 5. Compatibility Considerations . . . . . . . . . . . . . . . . . 9 76 6. Scalability and Deployment Considerations . . . . . . . . . . 10 77 7. Management Considerations . . . . . . . . . . . . . . . . . . 11 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 79 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 80 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 81 11. Normative References . . . . . . . . . . . . . . . . . . . . . 15 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 84 1. Introduction 86 OSPF [RFC2328] operation on broadcast interfaces takes advantage of 87 the broadcast capabilities of the underlying medium for doing 88 neighbor discovery and maintenance. Further, it uses a Designated 89 Router (DR) and Backup Designated Router (BDR) to keep the LSA 90 databases of the routers on the network synchronized in an efficient 91 manner. However, it has the limitation that a router cannot 92 advertise different costs to each of the neighboring routers on the 93 network in its router LSA. 95 Consider a radio network that supports true broadcast, yet the 96 metrics between different pairs of terminals could be different for 97 various reasons (e.g. different signal strength due to placement). 98 When running OSPF over the radio network, for a router to advertise 99 different costs to different neighbors, the interface must be treated 100 as point-to-multipoint, even though the network has true broadcast 101 capability. 103 Operation on point-to-multipoint interfaces could require explicit 104 configuration of the identity of neighboring routers. It also 105 requires the router to send separate hellos to each neighbor on the 106 network. Further, it mandates establishment of adjacencies to all 107 configured or discovered neighbors on the network. However, it gives 108 the routers the flexibility to advertise different costs to each of 109 the neighboring routers in their router LSAs. 111 This document proposes a new interface type that can be used on 112 networks that have broadcast capability. In this mode, neighbor 113 discovery and maintenance, as well as database synchronization are 114 performed using existing procedures for broadcast mode. The network 115 is modeled as a collection of point-to-point links in the router LSA, 116 just as it would be in point-to-multipoint mode. This new interface 117 type is referred to as hybrid-broadcast-and-p2mp in the rest of this 118 document. 120 2. Requirements Language 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in [RFC2119]. 126 3. Motivation 128 There are some networks that are broadcast capable but have a 129 potentially different cost associated with communication between any 130 given pair of nodes. The cost could be based on the underlying 131 topology as well as various link quality metrics such as bandwidth, 132 delay and jitter, among others. 134 It is not accurate to treat such networks as OSPF broadcast networks 135 since that does not allow a router to advertise a different cost to 136 each of the other routers. Using OSPF point-to-multipoint mode would 137 satisfy the requirement to correctly describe the cost to reach each 138 router. However, it would be inefficient in the sense that it would 139 require forming O(N^2) adjacencies when there are N routers on the 140 network. 142 It is advantageous to use the hybrid-broadcast-and-p2mp type for such 143 networks. This combines the flexibility of point-to-multipoint type 144 with the advantages and efficiencies of broadcast interface type. 146 4. Operation 148 OSPF routers supporting the capabilities described herein should have 149 support for an additional hybrid-broadcast-and-p2mp type for the Type 150 data item described in section 9 of [RFC2328]. 152 The following sub-sections describe salient aspects of OSPF operation 153 on routers configured with a hybrid-broadcast-and-p2mp interface. 155 4.1. Interface Parameters 157 The "Router Priority" interface parameter as specified in OSPFv2 158 [RFC2328] and OSPFv3 [RFC5340] applies to a hybrid-broadcast-and-p2mp 159 interface. 161 The "LinkLSASuppression" interface parameter as specified in OSPFv3 162 [RFC5340] applies to a hybrid-broadcast-and-p2mp interface. The 163 default value is "disabled". It may be set to "enabled" via 164 configuration. 166 4.2. Neighbor Data Structure 168 An additional field called the Neighbor Output is added to the 169 neighbor data structure. This is the cost of sending a data packet 170 to the neighbor, expressed in the link state metric. The default 171 value of this field is the Interface output cost. It may be set to a 172 different value using mechanisms which are outside the scope of this 173 document, like static per-neighbor configuration, or any dynamic 174 discovery mechanism that is supported by the underlying network. 176 4.3. Neighbor Discovery and Maintenance 178 Routers send and receive Hellos so as to perform neighbor discovery 179 and maintenance on the interface using the procedures specified for 180 broadcast interfaces in [RFC2328] and [RFC5340]. 182 4.4. Database Synchronization 184 Routers elect a DR and BDR for the interface and use them for initial 185 and ongoing database synchronization using the procedures specified 186 for broadcast interfaces in [RFC2328] and [RFC5340]. 188 4.5. Generating Network LSAs 190 Since a hybrid-broadcast-and-p2mp interface is described in router 191 LSAs using a collection of point-to-point links, the DR MUST NOT 192 generate a network LSA for the interface. 194 4.6. Generating Router and Intra-Area-Prefix-LSAs 196 Routers describe the interface in their router LSA as specified for a 197 point-to-multipoint interface in section 12.4.1.4 of [RFC2328] and 198 section 4.4.3.2 of [RFC5340], with the following modifications for 199 Type 1 links: 201 o If a router is not the DR, it MUST NOT add any Type 1 links if it 202 does not have a full adjacency to the DR. 204 o If a router is not the DR and has a full adjacency to the DR, and 205 both the DR and this router agree on the DR role, it MUST add a 206 Type 1 link corresponding to each neighbor that is in state 2-Way 207 or higher and to which the DR's router LSA includes a link. 209 o The cost for a Type 1 link corresponding to a neighbor SHOULD be 210 set to the value of the Neighbor Output Cost field as defined in 211 Section 4.2 213 4.6.1. Stub Links in OSPFv2 Router LSA 215 Routers MUST add a Type 3 link for their own IP address to the router 216 LSA as described in section 12.4.1.4 of [RFC2328]. Further, they 217 MUST also add a Type 3 link with the Link ID set to the IP subnet 218 address, Link Data set to the IP subnet mask, and cost equal to the 219 configured output cost of the interface. 221 4.6.2. OSPFv3 Intra-Area-Prefix-LSA 223 Routers MUST add global scoped IPv6 addresses on the interface to the 224 intra-area-prefix-LSA as described for point-to-multipoint interfaces 225 in section 4.4.3.9 of [RFC5340]. In addition, they MUST also add all 226 global scoped IPv6 prefixes on the interface to the LSA by specifying 227 the PrefixLength, PrefixOptions, and Address Prefix fields. The 228 Metric field for each of these prefixes is set to the configured 229 output cost of the interface. 231 The DR MUST NOT generate an intra-area-prefix-LSA for the transit 232 network for this interface since it does not generate a network LSA 233 for the interface. Note that the global prefixes associated with the 234 interface are advertised in the intra-area-prefix-LSA for the router 235 as described above. 237 4.7. Next-Hop Calculation 239 Next-Hops to destinations that are directly connected to a router via 240 the interface are calculated as specified for a point-to-multipoint 241 interface in section 16.1.1 of [RFC2328]. 243 4.8. Graceful Restart 245 The following modifications to the procedures defined in section 2.2, 246 item 1 of [RFC3623] are required in order to ensure that the router 247 correctly exits graceful restart. 249 o If a router is the DR on the interface, the pre-restart network 250 LSA for the interface MUST NOT be used to determine the previous 251 set of adjacencies. 253 o If a router is in state DROther on the interface, an adjacency to 254 a non-DR or non-BDR neighbor is considered as reestablished when 255 the neighbor state reaches 2-Way. 257 5. Compatibility Considerations 259 All routers on the network must support the hybrid-broadcast-and-p2mp 260 interface type for successful operation. Otherwise, the interface 261 should be configured as a standard broadcast interface. 263 If some routers on the network treat the interface as broadcast and 264 others as hybrid-broadcast-and-p2mp, neighbors and adjacencies will 265 still get formed as for a broadcast interface. However, due to the 266 differences in how router and network LSAs are built for these two 267 interface types, there will be no traffic traversing certain pairs of 268 routers. Note that this will not cause any persistent loops or black 269 holing of traffic. 271 To detect and flag possible mismatched configurations, an 272 implementation of this specification SHOULD log a message if a 273 Network LSA is received for a locally configured hybrid interface. 275 6. Scalability and Deployment Considerations 277 Treating a broadcast interface as hybrid-broadcast-and-p2mp results 278 in O(N^2) links to represent the network instead of O(N), when there 279 are N routers on the network. This will increase memory usage and 280 have a negative impact on route calculation performance on all the 281 routers in the area. Network designers should carefully weigh the 282 benefits of using the new interface type against the disadvantages 283 mentioned here. 285 7. Management Considerations 287 The following MIB variable/value should be added to the appropriate 288 OSPFv2 and OSPFv3 MIBs ([RFC4750], [RFC5643]). 290 o For ospfIfType/ospfv3IfType, a new value broadcast-p2mp-hybrid (X) 291 for the hybrid interface type (X to be defined when the revised 292 MIB documents are approved). 294 o For ospfNbrEntry/ospfv3NbrEntry, an ospfNbrMetricValue/ 295 ospfv3NbrMetricValue attribute for per-neigbhor metrics. In case 296 of non-hybrid interfaces, the value is the same as the interface 297 metric. 299 This section is not normative. 301 8. Security Considerations 303 This document raises no new security issues for OSPF. Security 304 considerations for the base OSPF protocol are covered in [RFC2328], 305 [RFC5340], and [RFC6506]. 307 9. IANA Considerations 309 This document has no IANA considerations. 311 This section should be removed by the RFC Editor to final 312 publication. 314 10. Acknowledgements 316 The authors would like to thank Acee Lindem and Richard Ogier for 317 their comments and suggestions. 319 11. Normative References 321 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 322 Requirement Levels", BCP 14, RFC 2119, March 1997. 324 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 326 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 327 for IPv6", RFC 5340, July 2008. 329 [RFC3623] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF 330 Restart", RFC 3623, November 2003. 332 [RFC4750] Joyal, D., Galecki, P., Giacalone, S., Coltun, R., and F. 333 Baker, "OSPF Version 2 Management Information Base", 334 RFC 4750, December 2006. 336 [RFC5643] Joyal, D. and V. Manral, "Management Information Base for 337 OSPFv3", RFC 5643, August 2009. 339 [RFC6506] Bhatia, M., Manral, V., and A. Lindem, "Supporting 340 Authentication Trailer for OSPFv3", RFC 6506, 341 February 2012. 343 Authors' Addresses 345 Nischal Sheth 346 Contrail Systems 347 2350 Mission College Blvd, #1140 348 Santa Clara, CA 95054 349 US 351 Email: nsheth@contrailsystems.com 353 Lili Wang 354 Juniper Networks 355 10 Technology Park Dr. 356 Westford, MA 01886 357 US 359 Email: liliw@juniper.net 361 Jeffrey Zhang 362 Juniper Networks 363 10 Technology Park Dr. 364 Westford, MA 01886 365 US 367 Email: zzhang@juniper.net