idnits 2.17.1 draft-ietf-ospf-two-part-metric-08.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 : ---------------------------------------------------------------------------- No issues found here. 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 (August 12, 2016) is 2814 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) == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-lsa-extend-10 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Zhang 3 Internet-Draft L. Wang 4 Updates: 2328, 5340 (if approved) Juniper Networks, Inc. 5 Intended status: Standards Track A. Lindem 6 Expires: February 13, 2017 Cisco Systems 7 August 12, 2016 9 OSPF Two-part Metric 10 draft-ietf-ospf-two-part-metric-08.txt 12 Abstract 14 This document specifies an optional extension to the OSPF protocol, 15 to represent the metric on a multi-access network as two parts: the 16 metric from a router to the network, and the metric from the network 17 to the router. The router to router metric would be the sum of the 18 two. This document updates RFC 2328 and RFC 5340. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on February 13, 2017. 37 Copyright Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 2. Proposed Enhancement . . . . . . . . . . . . . . . . . . . . 3 57 3. Speficications . . . . . . . . . . . . . . . . . . . . . . . 4 58 3.1. Router Interface Parameters . . . . . . . . . . . . . . . 4 59 3.2. Advertising Network-to-Router Metric in OSPFv2 . . . . . 4 60 3.3. Advertising Network-to-Router Metric in OSPFv3 . . . . . 5 61 3.4. Advertising Network-to-Router TE Metric . . . . . . . . . 5 62 3.5. OSPF Stub Router Behavior . . . . . . . . . . . . . . . . 5 63 3.6. SPF Calculation . . . . . . . . . . . . . . . . . . . . . 5 64 3.7. Backward Compatibility . . . . . . . . . . . . . . . . . 6 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 67 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 69 6.2. Informative References . . . . . . . . . . . . . . . . . 8 70 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8 71 Appendix B. Contributors' Addreses . . . . . . . . . . . . . . . 9 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 With Open Shortest Path First (OSPF, [RFC2328], [RFC5340]) protocol, 77 for a broadcast network, a Network-LSA is advertised to list all 78 routers on the network, and each router on the network includes a 79 link in its Router-LSA to describe its connection to the network. 80 The link in the Router-LSA includes a metric but the listed routers 81 in the Network LSA do not include a metric. This is based on the 82 assumption that from a particular router, all others on the same 83 network can be reached with the same metric. 85 With some broadcast networks, different routers can be reached with 86 different metrics. [RFC6845] extends the OSPF protocol with a hybrid 87 interface type for that kind of broadcast network, where no Network 88 LSA is advertised and Router-LSAs simply include p2p links to all 89 routers on the same network with individual metrics. Broadcast 90 capability is still utilized to optimize database synchronization and 91 adjacency maintenance. 93 That works well for broadcast networks where the metric between 94 different pair of routers are really independent. For example, VPLS 95 networks. 97 With certain types of broadcast networks, further optimization can be 98 made to reduce the size of the Router-LSAs and number of updates. 100 Consider a satellite radio network with fixed and mobile ground 101 terminals. All communication goes through the satellite. When the 102 mobile terminals move about, their communication capability may 103 change. When OSPF runs over the radio network (routers being or in 104 tandem with the terminals), [RFC6845] hybrid interface can be used, 105 but with the following drawbacks. 107 Consider that one terminal/router moves into an area where its 108 communication capability degrades significantly. Through the radio 109 control protocol, all other routers determine that the metric to this 110 particular router changed and they all need to update their Router- 111 LSAs accordingly. The router in question also determines that its 112 metric to reach all others also changed and it also needs to update 113 its Router-LSA. Consider that there could be many terminals and many 114 of them can be moving fast and frequently, the number/frequency of 115 updates of those large Router-LSAs could inhibit network scaling. 117 1.1. Requirements Language 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 2. Proposed Enhancement 125 Notice that in the above scenario, when one terminal's communication 126 capability changes, its metric to all other terminals and the metric 127 from all other terminals to it will all change in a similar fashion. 128 Given this, the above problem can be easily addressed by breaking the 129 metric into two parts: the metric to the satellite and the metric 130 from the satellite. The metric from terminal R1 to R2 would be the 131 sum of the metric from R1 to the satellite and the metric from the 132 satellite to R2. 134 Now instead of using the [RFC6845] hybrid interface type, the network 135 is just treated as a regular broadcast network. A router on the 136 network no longer lists individual metrics to each neighbor in its 137 Router-LSA. Instead, each router advertises the metric from the 138 network to itself in addition to the normal metric for the network. 139 With the normal Router-to-Network and additional Network-to-Router 140 metrics advertised for each router, individual router-to-router 141 metric can be calculated. 143 With the proposed enhancement, the size of Router-LSA will be 144 significantly reduced. In addition, when a router's communication 145 capability changes, only that router needs to update its Router-LSA. 147 Note that while the example uses the satellite as the relay point at 148 the radio level (layer-2), at layer-3, the satellite does not 149 participate in packet forwarding. In fact, the satellite does not 150 need to be running any layer-3 protocol. Therefore for generality, 151 the metric is abstracted as to/from the "network" rather that 152 specifically to/from the "satellite". 154 3. Speficications 156 The following protocol specifications are added to or modified from 157 the base OSPF protocol. If an area contains one or more two-part 158 metric networks, then all routers in the area MUST support the 159 extensions specified herein. This is ensured by procedures described 160 in Section 3.7. 162 3.1. Router Interface Parameters 164 The "Router interface parameters" have the following additions: 166 o Two-part metric: TRUE if the interface connects to a multi-access 167 network that uses two-part metric. All routers connected to the 168 same network SHOULD have the same configuration for their 169 corresponding interfaces. 171 o Interface input cost: Link state metric from the two-part-metric 172 network to this router. Defaulted to "Interface output cost" but 173 not valid for normal networks using a single metric. May be 174 configured or dynamically adjusted to a value different from the 175 "Interface output cost". 177 3.2. Advertising Network-to-Router Metric in OSPFv2 179 For OSPFv2, the Network-to-Router metric is encoded in an OSPF 180 Extended Link TLV Sub-TLV [RFC7684], defined in this document as the 181 Network-to-Router Metric Sub-TLV. The type of the Sub-TLV is TBD2. 182 The length of the Sub-TLV is 4 (for the value part only). The value 183 part of the Sub-TLV is defined as follows: 185 0 1 2 3 186 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 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | MT | 0 | MT metric | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 Multiple such Sub-TLVs can exist in a single OSPF Extended Link TLV, 192 one for each topology [RFC4915]. The OSPF Extended Link TLV 193 identifies the transit link to the network, and is part of an OSPFv2 194 Extended-Link Opaque LSA. The Sub-TLV MUST ONLY appear in Extended- 195 Link TLVs for Link Type 2 (link to transit network), and MUST be 196 ignored if received for other link types. 198 3.3. Advertising Network-to-Router Metric in OSPFv3 200 For OSPFv3, the same Network-to-Router Metric Sub-TLV definition is 201 used, though it is part of the Router-Link TLV of E-Router-LSA 202 [I-D.ietf-ospf-ospfv3-lsa-extend] and the type is TBD3. Currently 203 OSPFv3 Multi-Toplogy is not defined so the only valid value for the 204 MT field is 0 and only one such Sub-TLV SHOULD be included in the 205 Router-Link TLV. Received Sub-TLVs with non-zero MT field MUST be 206 ignored. 208 Similarly, the Sub-TLV MUST ONLY appear in Router-Link TLVs for Link 209 Type 2 (connection to a transit network) and MUST be ignored if 210 received for other link types. 212 3.4. Advertising Network-to-Router TE Metric 214 A Traffic Engineering Network-to-Router Metric Sub-TLV is defined, 215 similar to the Traffic Engineering Metric Sub-TLV defined in 216 Section 2.5.5 of [RFC3630]. The only difference is the TLV type, 217 which is TBD4. The Sub-TLV MUST only appear in type 2 Link TLVs 218 (Multi-access) of Traffic Engineer LSAs (OSPF2) or Intra-Area-TE-LSAs 219 (OSPFv3) [RFC5329], and MUST appear at most once in one such Link 220 TLV. 222 3.5. OSPF Stub Router Behavior 224 When an OSPF router with interfaces including two-part metric is 225 advertising itself as a stub router [RFC6987], only the Router-to- 226 Network metric in the stub router's OSPF Router-LSA links is set to 227 the MaxLinkMetric. This is fully backward compatible and will result 228 in the same behavior as [RFC6987]. 230 3.6. SPF Calculation 232 The first stage of the shortest-path tree calculation is described in 233 section 16.1 of [RFC2328] and modified for OSPFv3 as described in 234 section 4.8.1 of [RFC5340]. With two-part metric, when a vertex V 235 corresponding to a Network-LSA has just been added to the Shortest 236 Path Tree (SPT) and an adjacent vertex W (joined by a link in V's 237 corresponding Network-LSA) is being added to the candidate list, the 238 cost from V to W (W's network-to-router cost) is determined as 239 follows: 241 o For OSPFv2, if vertex W has a corresponding Extended-Link Opaque 242 LSA with an Extended Link TLV for the link from W to V, and the 243 Extended Link TLV has a Network-to-Router Metric Sub-TLV for the 244 corresponding topology, then the cost from V to W is the metric in 245 the Sub-TLV. Otherwise, the cost is 0. 247 o For OSPFv3, if vertex W has a corresponding E-Router-LSA with a 248 Router-Link TLV for the link from W to V, and the Router-Link TLV 249 has a Network-to-Router Metric Sub-TLV, then the cost from V to W 250 is the metric in the Sub-TLV. If not, the cost is 0. 252 3.7. Backward Compatibility 254 Due to the change of procedures in the SPF calculation, all routers 255 in an area that includes one or more two-part metric networks must 256 support the changes specified in this document. To ensure that, if 257 an area is provisioned to support two-part metric networks, all 258 routers supporting this capability must advertise a Router 259 Information (RI) LSA with a Router Functional Capabilities TLV 260 [RFC7770] that includes the following Router Functional Capability 261 Bit: 263 Bit Capabilities 265 TBD1 OSPF Two-part Metric (TPM) 267 Upon detecting the presence of a reachable Router-LSA without a 268 companion RI LSA that has the bit set, all routers MUST recalculate 269 routes without considering any network-to-router costs. 271 4. IANA Considerations 273 This document requests the following IANA assignments: 275 o A new bit (TBD1) in Registry for OSPF Router Informational 276 Capability Bits, to indicate the capability of supporting two-part 277 metric. 279 o A new Sub-TLV type (TBD2) in OSPF Extended Link TLV Sub-TLV 280 registry, for the Network-to-Router Metric Sub-TLV. 282 o A new Sub-TLV type (TBD3) in OSPFv3 Extended-LSA Sub-TLV registry, 283 for the Network-to-Router Metric Sub-TLV. 285 o A new Sub-TLV type (TBD4) in Types for sub-TLVs of TE Link TLV 286 (Value 2) registry, for the Network-to-Router TE Metric Sub-TLV. 288 5. Security Considerations 290 This document does not introduce new security risks. Existing 291 security considerations in OSPFv2 and OSPFv3 apply. 293 6. References 295 6.1. Normative References 297 [I-D.ietf-ospf-ospfv3-lsa-extend] 298 Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3 299 LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-10 300 (work in progress), May 2016. 302 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 303 Requirement Levels", BCP 14, RFC 2119, 304 DOI 10.17487/RFC2119, March 1997, 305 . 307 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 308 DOI 10.17487/RFC2328, April 1998, 309 . 311 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 312 (TE) Extensions to OSPF Version 2", RFC 3630, 313 DOI 10.17487/RFC3630, September 2003, 314 . 316 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 317 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 318 RFC 4915, DOI 10.17487/RFC4915, June 2007, 319 . 321 [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., 322 "Traffic Engineering Extensions to OSPF Version 3", 323 RFC 5329, DOI 10.17487/RFC5329, September 2008, 324 . 326 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 327 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 328 . 330 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 331 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 332 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 333 2015, . 335 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 336 S. Shaffer, "Extensions to OSPF for Advertising Optional 337 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 338 February 2016, . 340 6.2. Informative References 342 [RFC6845] Sheth, N., Wang, L., and J. Zhang, "OSPF Hybrid Broadcast 343 and Point-to-Multipoint Interface Type", RFC 6845, 344 DOI 10.17487/RFC6845, January 2013, 345 . 347 [RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D. 348 McPherson, "OSPF Stub Router Advertisement", RFC 6987, 349 DOI 10.17487/RFC6987, September 2013, 350 . 352 Appendix A. Acknowledgements 354 The authors would like to thank Abhay Roy, Hannes Gredler, Peter 355 Psenak and Eric Wu for their comments and suggestions. 357 The RFC text was produced using Marshall Rose's xml2rfc tool. 359 Appendix B. Contributors' Addreses 361 David Dubois 362 General Dynamics C4S 363 400 John Quincy Adams Road 364 Taunton, MA 02780 366 EMail: dave.dubois@gd-ms.com 368 Vibhor Julka 369 Individual 371 EMail: vjulka1@yahoo.com 373 Tom McMillan 374 L3 Communications, Linkabit 375 9890 Towne Centre Drive 376 San Diego, CA 92121 378 EMail: tom.mcmillan@l-3com.com 380 Authors' Addresses 382 Zhaohui Zhang 383 Juniper Networks, Inc. 384 10 Technology Park Drive 385 Westford, MA 01886 387 Email: zzhang@juniper.net 389 Lili Wang 390 Juniper Networks, Inc. 391 10 Technology Park Drive 392 Westford, MA 01886 394 Email: liliw@juniper.net 396 Acee Lindem 397 Cisco Systems 398 301 Midenhall Way 399 Cary, NC 27513 401 Email: acee@cisco.com