idnits 2.17.1 draft-ietf-ospf-two-part-metric-03.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 draft header indicates that this document updates RFC2328, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC5340, but the abstract doesn't seem to mention this, which it should. 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 (December 4, 2015) is 3060 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: 'RFC 3630' is mentioned on line 217, but not defined == Missing Reference: 'RFC 5329' is mentioned on line 220, but not defined == Missing Reference: 'TPM' is mentioned on line 263, but not defined == Unused Reference: 'I-D.acee-ospf-rfc4970bis' is defined on line 298, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ospf-ospfv3-lsa-extend' is defined on line 304, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 309, but no explicit reference was found in the text == Unused Reference: 'RFC2328' is defined on line 314, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 318, but no explicit reference was found in the text == Unused Reference: 'RFC4915' is defined on line 323, but no explicit reference was found in the text == Unused Reference: 'RFC5329' is defined on line 328, but no explicit reference was found in the text == Unused Reference: 'RFC5340' is defined on line 333, but no explicit reference was found in the text == Unused Reference: 'RFC5613' is defined on line 337, but no explicit reference was found in the text == Unused Reference: 'RFC6845' is defined on line 354, but no explicit reference was found in the text == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-lsa-extend-09 ** Downref: Normative reference to an Informational RFC: RFC 6987 Summary: 1 error (**), 0 flaws (~~), 15 warnings (==), 4 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: June 6, 2016 Cisco Systems 7 D. Dubois 8 General Dynamics C4S 9 V. Julka 10 T. McMillan 11 L3 Communications, Linkabit 12 December 4, 2015 14 OSPF Two-part Metric 15 draft-ietf-ospf-two-part-metric-03.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. 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 June 6, 2016. 48 Copyright Notice 50 Copyright (c) 2015 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 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Proposed Enhancement . . . . . . . . . . . . . . . . . . . . 3 67 3. Speficications . . . . . . . . . . . . . . . . . . . . . . . 4 68 3.1. Router Interface Parameters . . . . . . . . . . . . . . . 4 69 3.2. Advertising Network-to-Router Metric in OSPFv2 . . . . . 4 70 3.3. Advertising Network-to-Router Metric in OSPFv3 . . . . . 5 71 3.4. Advertising Network-to-Router TE Metric . . . . . . . . . 5 72 3.5. OSPF Stub Router Behavior . . . . . . . . . . . . . . . . 5 73 3.6. SPF Calculation . . . . . . . . . . . . . . . . . . . . . 5 74 3.7. Backward Compatibility . . . . . . . . . . . . . . . . . 6 75 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 77 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 78 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 79 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 80 7.2. Informative References . . . . . . . . . . . . . . . . . 8 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 83 1. Introduction 85 For a broadcast network, a Network-LSA is advertised to list all 86 routers on the network, and each router on the network includes a 87 link in its Router-LSA to describe its connection to the network. 88 The link in the Router-LSA includes a metric but the listed routers 89 in the Network LSA do not include a metric. This is based on the 90 assumption that from a particular router, all others on the same 91 network can be reached with the same metric. 93 With some broadcast networks, different routers can be reached with 94 different metrics. RFC 6845 extends the OSPF protocol with a hybrid 95 interface type for that kind of broadcast network, where no Network 96 LSA is advertised and Router-LSAs simply include p2p links to all 97 routers on the same network with individual metrics. Broadcast 98 capability is still utilized to optimize database synchronization and 99 adjacency maintenance. 101 That works well for broadcast networks where the metric between 102 different pair of routers are really independent. For example, VPLS 103 networks. 105 With certain types of broadcast networks, further optimization can be 106 made to reduce the size of the Router-LSAs and number of updates. 108 Consider a satellite radio network with fixed and mobile ground 109 terminals. All communication goes through the satellite. When the 110 mobile terminals move about, their communication capability may 111 change. When OSPF runs over the radio network (routers being or in 112 tandem with the terminals), RFC 6845 hybrid interface can be used, 113 but with the following drawbacks. 115 Consider that one terminal/router moves into an area where its 116 communication capability degrades significantly. Through the radio 117 control protocol, all other routers determine that the metric to this 118 particular router changed and they all need to update their Router- 119 LSAs accordingly. The router in question also determines that its 120 metric to reach all others also changed and it also needs to update 121 its Router-LSA. Consider that there could be many terminals and many 122 of them can be moving fast and frequently, the number/frequency of 123 updates of those large Router-LSAs could inhibit network scaling. 125 2. Proposed Enhancement 127 Notice that in the above scenario, when one terminal's communication 128 capability changes, its metric to all other terminals and the metric 129 from all other terminals to it will all change in a similar fashion. 130 Given this, the above problem can be easily addressed by breaking the 131 metric into two parts: the metric to the satellite and the metric 132 from the satellite. The metric from terminal R1 to R2 would be the 133 sum of the metric from R1 to the satellite and the metric from the 134 satellite to R2. 136 Now instead of using the RFC 6845 hybrid interface type, the network 137 is just treated as a regular broadcast network. A router on the 138 network no longer lists individual metrics to each neighbor in its 139 Router-LSA. Instead, each router advertises the metric from the 140 network to itself in addition to the normal metric for the network. 141 With the normal Router-to-Network and additional Network-to-Router 142 metrics advertised for each router, individual router-to-router 143 metric can be calculated. 145 With the proposed enhancement, the size of Router-LSA will be 146 significantly reduced. In addition, when a router's communication 147 capability changes, only that router needs to update its Router-LSA. 149 Note that while the example uses the satellite as the relay point at 150 the radio level (layer-2), at layer-3, the satellite does not 151 participate in packet forwarding. In fact, the satellite does not 152 need to be running any layer-3 protocol. Therefore for generality, 153 the metric is abstracted as to/from the "network" rather that 154 specifically to/from the "satellite". 156 3. Speficications 158 The following protocol specifications are added to or modified from 159 the base OSPF protocol. If an area contains one or more two-part 160 metric networks, then all routers in the area must support the 161 extensions specified herein. This is ensured by procedures described 162 in Section 3.7. 164 3.1. Router Interface Parameters 166 The "Router interface parameters" have the following additions: 168 o Two-part metric: TRUE if the interface connects to a multi-access 169 network that uses two-part metric. All routers connected to the 170 same network SHOULD have the same configuration for their 171 corresponding interfaces. 173 o Interface input cost: Link state metric from the two-part-metric 174 network to this router. Defaulted to "Interface output cost" but 175 not valid for normal networks using a single metric. May be 176 configured or dynamically adjusted to a value different from the 177 "Interface output cost". 179 3.2. Advertising Network-to-Router Metric in OSPFv2 181 For OSPFv2, the Network-to-Router metric is encoded in an OSPF 182 Extended Link TLV Sub-TLV [RFC7684], defined in this document as the 183 Network-to-Router Metric Sub-TLV. The type of the Sub-TLV is TBD. 184 The length of the Sub-TLV is 4 (for the value part only). The value 185 part of the Sub-TLV is defined as follows: 187 0 1 2 3 188 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 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | MT | 0 | MT metric | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 Multiple such Sub-TLVs can exist in a single OSPF Extended Link TLV, 194 one for each topology. The OSPF Extended Link TLV identifies the 195 transit link to the network, and is part of an OSPFv2 Extended-Link 196 Opaque LSA. The Sub-TLV MUST ONLY appear in Extended-Link TLVs for 197 Link Type 2 (link to transit network), and MUST be ignored if 198 received for other link types. 200 3.3. Advertising Network-to-Router Metric in OSPFv3 202 For OSPFv3, the same Network-to-Router Metric Sub-TLV definition is 203 used, though it is part of the Router-Link TLV of E-Router-LSA [ietf- 204 ospf-ospfv3-lsa-extend]. Currently OSPFv3 Multi-Toplogy is not 205 defined so the only valid value for the MT field is 0 and only one 206 such Sub-TLV SHOULD be included in the Router-Link TLV. Received 207 Sub-TLVs with non-zero MT field MUST be ignored. 209 Similarly, the Sub-TLV MUST ONLY appear in Router-Link TLVs for Link 210 Type 2 (connection to a transit network) and MUST be ignored if 211 received for other link types. 213 3.4. Advertising Network-to-Router TE Metric 215 A Traffic Engineering Network-to-Router Metric Sub-TLV is defined, 216 similar to the Traffic Engineering Metric Sub-TLV defined in 217 Section 2.5.5 of [RFC 3630]. The only difference is the TLV type, 218 which is TBD. The Sub-TLV MUST only appear in type 2 Link TLVs 219 (Multi-access) of Traffic Engineer LSAs (OSPF2) or Intra-Area-TE-LSAs 220 (OSPFv3) [RFC 5329], and MUST appear at most once in one such Link 221 TLV. 223 3.5. OSPF Stub Router Behavior 225 When an OSPF router with interfaces including two-part metric is 226 advertising itself as a stub router [RFC6987], only the Router-to- 227 Network metric in the stub router's OSPF Router-LSA links is set to 228 the MaxLinkMetric. This is fully backward compatible and will result 229 in the same behavior as [RFC6987]. 231 3.6. SPF Calculation 233 During the first stage of shortest-path tree calculation for an area, 234 when a vertex V corresponding to a Network-LSA is added to the 235 shortest-path tree and its adjacent vertex W (joined by a link in V's 236 corresponding Network LSA), the cost from V to W, which is W's 237 network-to-router cost, is determined as follows: 239 o For OSPFv2, if vertex W has a corresponding Extended-Link Opaque 240 LSA with an Extended Link TLV for the link from W to V, and the 241 Extended Link TLV has a Network-to-Router Metric Sub-TLV for the 242 corresponding topology, then the cost from V to W is the metric in 243 the Sub-TLV. Otherwise, the cost is 0. 245 o For OSPFv3, if vertex W has a corresponding E-Router-LSA with a 246 Router-Link TLV for the link from W to V, and the Router-Link TLV 247 has a Network-to-Router Metric Sub-TLV, then the cost from V to W 248 is the metric in the Sub-TLV. If not, the cost is 0. 250 3.7. Backward Compatibility 252 Due to the change of procedures in the SPF calculation, all routers 253 in an area that includes one or more two-part metric networks must 254 support the changes specified in this document. To ensure that, if 255 an area is provisioned to support two-part metric networks, all 256 routers supporting this capability must advertise a Router 257 Information (RI) LSA with a Router Functional Capabilities TLV [acee- 258 ospf-rfc4970bis] that includes the following Router Functional 259 Capability Bit: 261 Bit Capabilities 263 0 OSPF Two-part Metric [TPM] 265 Upon detecting the presence of a reachable Router-LSA without a 266 companion RI LSA that has the bit set, all routers MUST recalculate 267 routes w/o considering any network-to-router costs. 269 4. IANA Considerations 271 This document requests the following IANA assignments: 273 o A new bit in Registry for OSPF Router Informational Capability 274 Bits, to indicate the capability of supporting two-part metric. 276 o A new Sub-TLV type in OSPF Extended Link TLV Sub-TLV registry, for 277 the Network-to-Router Metric Sub-TLV. 279 o A new Sub-TLV type in OSPFv3 Extended-LSA Sub-TLV registry, for 280 the Network-to-Router Metric Sub-TLV. 282 o A new Sub-TLV type in Types for sub-TLVs of TE Link TLV (Value 2) 283 registry, for the Network-to-Router TE Metric Sub-TLV. 285 5. Security Considerations 287 This document does not introduce new security risks. 289 6. Acknowledgements 291 The authors would like to thank Abhay Roy, Hannes Gredler, Peter 292 Psenak and Eric Wu for their comments and suggestions. 294 7. References 296 7.1. Normative References 298 [I-D.acee-ospf-rfc4970bis] 299 Lindem, A., Shen, N., Vasseur, J., Aggarwal, R., and S. 300 Shaffer, "Extensions to OSPF for Advertising Optional 301 Router Capabilities", draft-acee-ospf-rfc4970bis-00 (work 302 in progress), July 2014. 304 [I-D.ietf-ospf-ospfv3-lsa-extend] 305 Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3 306 LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-09 307 (work in progress), November 2015. 309 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 310 Requirement Levels", BCP 14, RFC 2119, 311 DOI 10.17487/RFC2119, March 1997, 312 . 314 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 315 DOI 10.17487/RFC2328, April 1998, 316 . 318 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 319 (TE) Extensions to OSPF Version 2", RFC 3630, 320 DOI 10.17487/RFC3630, September 2003, 321 . 323 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 324 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 325 RFC 4915, DOI 10.17487/RFC4915, June 2007, 326 . 328 [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., 329 "Traffic Engineering Extensions to OSPF Version 3", 330 RFC 5329, DOI 10.17487/RFC5329, September 2008, 331 . 333 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 334 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 335 . 337 [RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. 338 Yeung, "OSPF Link-Local Signaling", RFC 5613, 339 DOI 10.17487/RFC5613, August 2009, 340 . 342 [RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D. 343 McPherson, "OSPF Stub Router Advertisement", RFC 6987, 344 DOI 10.17487/RFC6987, September 2013, 345 . 347 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 348 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 349 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 350 2015, . 352 7.2. Informative References 354 [RFC6845] Sheth, N., Wang, L., and J. Zhang, "OSPF Hybrid Broadcast 355 and Point-to-Multipoint Interface Type", RFC 6845, 356 DOI 10.17487/RFC6845, January 2013, 357 . 359 Authors' Addresses 361 Zhaohui Zhang 362 Juniper Networks, Inc. 363 10 Technology Park Drive 364 Westford, MA 01886 366 EMail: zzhang@juniper.net 368 Lili Wang 369 Juniper Networks, Inc. 370 10 Technology Park Drive 371 Westford, MA 01886 373 EMail: liliw@juniper.net 374 Acee Lindem 375 Cisco Systems 376 301 Midenhall Way 377 Cary, NC 27513 379 EMail: acee@cisco.com 381 David Dubois 382 General Dynamics C4S 383 400 John Quincy Adams Road 384 Taunton, MA 02780 386 EMail: dave.dubois@gdc4s.com 388 Vibhor Julka 389 L3 Communications, Linkabit 390 9890 Towne Centre Drive 391 San Diego, CA 92121 393 EMail: vibhor.julka@l-3Com.com 395 Tom McMillan 396 L3 Communications, Linkabit 397 9890 Towne Centre Drive 398 San Diego, CA 92121 400 EMail: tom.mcmillan@l-3com.com