idnits 2.17.00 (12 Aug 2021) /tmp/idnits10798/draft-ietf-ospf-two-part-metric-05.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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, 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 (May 5, 2016) is 2207 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) == Missing Reference: 'TPM' is mentioned on line 277, but not defined == Outdated reference: draft-ietf-ospf-ospfv3-lsa-extend has been published as RFC 8362 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Open Shortest Path First 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: November 6, 2016 Cisco Systems 7 D. Dubois 8 General Dynamics C4S 9 V. Julka 10 T. McMillan 11 L3 Communications, Linkabit 12 May 5, 2016 14 OSPF Two-part Metric 15 draft-ietf-ospf-two-part-metric-05.txt 17 Abstract 19 This document specifies an optional extension to the OSPF protocol, 20 to represent the metric on a multi-access network as two parts: the 21 metric from a router to the network, and the metric from the network 22 to the router. The router to router metric would be the sum of the 23 two. This document updates RFC 2328 and RFC 5340. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on November 6, 2016. 48 Copyright Notice 50 Copyright (c) 2016 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 This document may contain material from IETF Documents or IETF 64 Contributions published or made publicly available before November 65 10, 2008. The person(s) controlling the copyright in some of this 66 material may not have granted the IETF Trust the right to allow 67 modifications of such material outside the IETF Standards Process. 68 Without obtaining an adequate license from the person(s) controlling 69 the copyright in such materials, this document may not be modified 70 outside the IETF Standards Process, and derivative works of it may 71 not be created outside the IETF Standards Process, except to format 72 it for publication as an RFC or to translate it into languages other 73 than English. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 78 2. Proposed Enhancement . . . . . . . . . . . . . . . . . . . . 3 79 3. Speficications . . . . . . . . . . . . . . . . . . . . . . . 4 80 3.1. Router Interface Parameters . . . . . . . . . . . . . . . 4 81 3.2. Advertising Network-to-Router Metric in OSPFv2 . . . . . 5 82 3.3. Advertising Network-to-Router Metric in OSPFv3 . . . . . 5 83 3.4. Advertising Network-to-Router TE Metric . . . . . . . . . 5 84 3.5. OSPF Stub Router Behavior . . . . . . . . . . . . . . . . 6 85 3.6. SPF Calculation . . . . . . . . . . . . . . . . . . . . . 6 86 3.7. Backward Compatibility . . . . . . . . . . . . . . . . . 6 87 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 88 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 89 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 90 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 91 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 92 7.2. Informative References . . . . . . . . . . . . . . . . . 8 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 95 1. Introduction 97 With Open Shortest Path First (OSPF, [RFC2328], [RFC5340]) protocol, 98 for a broadcast network, a Network-LSA is advertised to list all 99 routers on the network, and each router on the network includes a 100 link in its Router-LSA to describe its connection to the network. 101 The link in the Router-LSA includes a metric but the listed routers 102 in the Network LSA do not include a metric. This is based on the 103 assumption that from a particular router, all others on the same 104 network can be reached with the same metric. 106 With some broadcast networks, different routers can be reached with 107 different metrics. [RFC6845] extends the OSPF protocol with a hybrid 108 interface type for that kind of broadcast network, where no Network 109 LSA is advertised and Router-LSAs simply include p2p links to all 110 routers on the same network with individual metrics. Broadcast 111 capability is still utilized to optimize database synchronization and 112 adjacency maintenance. 114 That works well for broadcast networks where the metric between 115 different pair of routers are really independent. For example, VPLS 116 networks. 118 With certain types of broadcast networks, further optimization can be 119 made to reduce the size of the Router-LSAs and number of updates. 121 Consider a satellite radio network with fixed and mobile ground 122 terminals. All communication goes through the satellite. When the 123 mobile terminals move about, their communication capability may 124 change. When OSPF runs over the radio network (routers being or in 125 tandem with the terminals), [RFC6845] hybrid interface can be used, 126 but with the following drawbacks. 128 Consider that one terminal/router moves into an area where its 129 communication capability degrades significantly. Through the radio 130 control protocol, all other routers determine that the metric to this 131 particular router changed and they all need to update their Router- 132 LSAs accordingly. The router in question also determines that its 133 metric to reach all others also changed and it also needs to update 134 its Router-LSA. Consider that there could be many terminals and many 135 of them can be moving fast and frequently, the number/frequency of 136 updates of those large Router-LSAs could inhibit network scaling. 138 2. Proposed Enhancement 140 Notice that in the above scenario, when one terminal's communication 141 capability changes, its metric to all other terminals and the metric 142 from all other terminals to it will all change in a similar fashion. 144 Given this, the above problem can be easily addressed by breaking the 145 metric into two parts: the metric to the satellite and the metric 146 from the satellite. The metric from terminal R1 to R2 would be the 147 sum of the metric from R1 to the satellite and the metric from the 148 satellite to R2. 150 Now instead of using the [RFC6845] hybrid interface type, the network 151 is just treated as a regular broadcast network. A router on the 152 network no longer lists individual metrics to each neighbor in its 153 Router-LSA. Instead, each router advertises the metric from the 154 network to itself in addition to the normal metric for the network. 155 With the normal Router-to-Network and additional Network-to-Router 156 metrics advertised for each router, individual router-to-router 157 metric can be calculated. 159 With the proposed enhancement, the size of Router-LSA will be 160 significantly reduced. In addition, when a router's communication 161 capability changes, only that router needs to update its Router-LSA. 163 Note that while the example uses the satellite as the relay point at 164 the radio level (layer-2), at layer-3, the satellite does not 165 participate in packet forwarding. In fact, the satellite does not 166 need to be running any layer-3 protocol. Therefore for generality, 167 the metric is abstracted as to/from the "network" rather that 168 specifically to/from the "satellite". 170 3. Speficications 172 The following protocol specifications are added to or modified from 173 the base OSPF protocol. If an area contains one or more two-part 174 metric networks, then all routers in the area must support the 175 extensions specified herein. This is ensured by procedures described 176 in Section 3.7. 178 3.1. Router Interface Parameters 180 The "Router interface parameters" have the following additions: 182 o Two-part metric: TRUE if the interface connects to a multi-access 183 network that uses two-part metric. All routers connected to the 184 same network SHOULD have the same configuration for their 185 corresponding interfaces. 187 o Interface input cost: Link state metric from the two-part-metric 188 network to this router. Defaulted to "Interface output cost" but 189 not valid for normal networks using a single metric. May be 190 configured or dynamically adjusted to a value different from the 191 "Interface output cost". 193 3.2. Advertising Network-to-Router Metric in OSPFv2 195 For OSPFv2, the Network-to-Router metric is encoded in an OSPF 196 Extended Link TLV Sub-TLV [RFC7684], defined in this document as the 197 Network-to-Router Metric Sub-TLV. The type of the Sub-TLV is TBD. 198 The length of the Sub-TLV is 4 (for the value part only). The value 199 part of the Sub-TLV is defined as follows: 201 0 1 2 3 202 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 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | MT | 0 | MT metric | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 Multiple such Sub-TLVs can exist in a single OSPF Extended Link TLV, 208 one for each topology [RFC4915]. The OSPF Extended Link TLV 209 identifies the transit link to the network, and is part of an OSPFv2 210 Extended-Link Opaque LSA. The Sub-TLV MUST ONLY appear in Extended- 211 Link TLVs for Link Type 2 (link to transit network), and MUST be 212 ignored if received for other link types. 214 3.3. Advertising Network-to-Router Metric in OSPFv3 216 For OSPFv3, the same Network-to-Router Metric Sub-TLV definition is 217 used, though it is part of the Router-Link TLV of E-Router-LSA 218 [I-D.ietf-ospf-ospfv3-lsa-extend]. Currently OSPFv3 Multi-Toplogy is 219 not defined so the only valid value for the MT field is 0 and only 220 one such Sub-TLV SHOULD be included in the Router-Link TLV. Received 221 Sub-TLVs with non-zero MT field MUST be ignored. 223 Similarly, the Sub-TLV MUST ONLY appear in Router-Link TLVs for Link 224 Type 2 (connection to a transit network) and MUST be ignored if 225 received for other link types. 227 3.4. Advertising Network-to-Router TE Metric 229 A Traffic Engineering Network-to-Router Metric Sub-TLV is defined, 230 similar to the Traffic Engineering Metric Sub-TLV defined in 231 Section 2.5.5 of [RFC3630]. The only difference is the TLV type, 232 which is TBD. The Sub-TLV MUST only appear in type 2 Link TLVs 233 (Multi-access) of Traffic Engineer LSAs (OSPF2) or Intra-Area-TE-LSAs 234 (OSPFv3) [RFC5329], and MUST appear at most once in one such Link 235 TLV. 237 3.5. OSPF Stub Router Behavior 239 When an OSPF router with interfaces including two-part metric is 240 advertising itself as a stub router [RFC6987], only the Router-to- 241 Network metric in the stub router's OSPF Router-LSA links is set to 242 the MaxLinkMetric. This is fully backward compatible and will result 243 in the same behavior as [RFC6987]. 245 3.6. SPF Calculation 247 During the first stage of shortest-path tree calculation for an area, 248 when a vertex V corresponding to a Network-LSA is added to the 249 shortest-path tree and its adjacent vertex W (joined by a link in V's 250 corresponding Network LSA), the cost from V to W, which is W's 251 network-to-router cost, is determined as follows: 253 o For OSPFv2, if vertex W has a corresponding Extended-Link Opaque 254 LSA with an Extended Link TLV for the link from W to V, and the 255 Extended Link TLV has a Network-to-Router Metric Sub-TLV for the 256 corresponding topology, then the cost from V to W is the metric in 257 the Sub-TLV. Otherwise, the cost is 0. 259 o For OSPFv3, if vertex W has a corresponding E-Router-LSA with a 260 Router-Link TLV for the link from W to V, and the Router-Link TLV 261 has a Network-to-Router Metric Sub-TLV, then the cost from V to W 262 is the metric in the Sub-TLV. If not, the cost is 0. 264 3.7. Backward Compatibility 266 Due to the change of procedures in the SPF calculation, all routers 267 in an area that includes one or more two-part metric networks must 268 support the changes specified in this document. To ensure that, if 269 an area is provisioned to support two-part metric networks, all 270 routers supporting this capability must advertise a Router 271 Information (RI) LSA with a Router Functional Capabilities TLV 272 [RFC7770] that includes the following Router Functional Capability 273 Bit: 275 Bit Capabilities 277 0 OSPF Two-part Metric [TPM] 279 Upon detecting the presence of a reachable Router-LSA without a 280 companion RI LSA that has the bit set, all routers MUST recalculate 281 routes w/o considering any network-to-router costs. 283 4. IANA Considerations 285 This document requests the following IANA assignments: 287 o A new bit in Registry for OSPF Router Informational Capability 288 Bits, to indicate the capability of supporting two-part metric. 290 o A new Sub-TLV type in OSPF Extended Link TLV Sub-TLV registry, for 291 the Network-to-Router Metric Sub-TLV. 293 o A new Sub-TLV type in OSPFv3 Extended-LSA Sub-TLV registry, for 294 the Network-to-Router Metric Sub-TLV. 296 o A new Sub-TLV type in Types for sub-TLVs of TE Link TLV (Value 2) 297 registry, for the Network-to-Router TE Metric Sub-TLV. 299 5. Security Considerations 301 This document does not introduce new security risks. 303 6. Acknowledgements 305 The authors would like to thank Abhay Roy, Hannes Gredler, Peter 306 Psenak and Eric Wu for their comments and suggestions. 308 7. References 310 7.1. Normative References 312 [I-D.ietf-ospf-ospfv3-lsa-extend] 313 Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3 314 LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-09 315 (work in progress), November 2015. 317 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 318 Requirement Levels", BCP 14, RFC 2119, 319 DOI 10.17487/RFC2119, March 1997, 320 . 322 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 323 DOI 10.17487/RFC2328, April 1998, 324 . 326 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 327 (TE) Extensions to OSPF Version 2", RFC 3630, 328 DOI 10.17487/RFC3630, September 2003, 329 . 331 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 332 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 333 RFC 4915, DOI 10.17487/RFC4915, June 2007, 334 . 336 [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., 337 "Traffic Engineering Extensions to OSPF Version 3", 338 RFC 5329, DOI 10.17487/RFC5329, September 2008, 339 . 341 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 342 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 343 . 345 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 346 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 347 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 348 2015, . 350 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 351 S. Shaffer, "Extensions to OSPF for Advertising Optional 352 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 353 February 2016, . 355 7.2. Informative References 357 [RFC6845] Sheth, N., Wang, L., and J. Zhang, "OSPF Hybrid Broadcast 358 and Point-to-Multipoint Interface Type", RFC 6845, 359 DOI 10.17487/RFC6845, January 2013, 360 . 362 [RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D. 363 McPherson, "OSPF Stub Router Advertisement", RFC 6987, 364 DOI 10.17487/RFC6987, September 2013, 365 . 367 Authors' Addresses 369 Zhaohui Zhang 370 Juniper Networks, Inc. 371 10 Technology Park Drive 372 Westford, MA 01886 374 EMail: zzhang@juniper.net 375 Lili Wang 376 Juniper Networks, Inc. 377 10 Technology Park Drive 378 Westford, MA 01886 380 EMail: liliw@juniper.net 382 Acee Lindem 383 Cisco Systems 384 301 Midenhall Way 385 Cary, NC 27513 387 EMail: acee@cisco.com 389 David Dubois 390 General Dynamics C4S 391 400 John Quincy Adams Road 392 Taunton, MA 02780 394 EMail: dave.dubois@gdc4s.com 396 Vibhor Julka 397 L3 Communications, Linkabit 398 9890 Towne Centre Drive 399 San Diego, CA 92121 401 EMail: vibhor.julka@l-3Com.com 403 Tom McMillan 404 L3 Communications, Linkabit 405 9890 Towne Centre Drive 406 San Diego, CA 92121 408 EMail: tom.mcmillan@l-3com.com