idnits 2.17.1 draft-ietf-ospf-two-part-metric-10.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 (October 13, 2016) is 2751 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-12 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 (if approved) Juniper Networks, Inc. 5 Intended status: Standards Track A. Lindem 6 Expires: April 16, 2017 Cisco Systems 7 October 13, 2016 9 OSPF Two-part Metric 10 draft-ietf-ospf-two-part-metric-10.txt 12 Abstract 14 This document specifies an optional OSPF protocol extension to 15 represent router metrics in a multi-access network in two parts: the 16 metric from the router to the network and the metric from the network 17 to the router. For such networks, the router to router metric for 18 OSPF route computation is the sum of the two parts. This document 19 updates RFC 2328. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 16, 2017. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 57 2. Proposed Enhancement . . . . . . . . . . . . . . . . . . . . 3 58 3. Speficications . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. Router Interface Parameters . . . . . . . . . . . . . . . 4 60 3.2. Advertising Network-to-Router Metric in OSPFv2 . . . . . 5 61 3.3. Advertising Network-to-Router Traffic Engineering (TE) 62 Metric . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.4. Advertising Network-to-Router Metric in OSPFv3 . . . . . 5 64 3.5. OSPF Stub Router Behavior . . . . . . . . . . . . . . . . 5 65 3.6. SPF Calculation . . . . . . . . . . . . . . . . . . . . . 6 66 3.7. Backward Compatibility . . . . . . . . . . . . . . . . . 6 67 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 69 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 71 6.2. Informative References . . . . . . . . . . . . . . . . . 8 72 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8 73 Appendix B. Contributors' Addreses . . . . . . . . . . . . . . . 9 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 76 1. Introduction 78 With Open Shortest Path First (OSPF, [RFC2328], [RFC5340]) Link State 79 Advertisements (LSAs), for a broadcast network, a Network-LSA is 80 advertised to list all routers on the network, and each router on the 81 network includes a link in its Router-LSA to describe its connection 82 to the network. The link in the Router-LSA includes a metric but the 83 listed routers in the Network LSA do not include a metric. This is 84 based on the assumption that from a particular router, all others on 85 the same network can be reached with the same metric. 87 With some broadcast networks, different routers can be reached with 88 different metrics. [RFC6845] extends the OSPF protocol with a hybrid 89 interface type for that kind of broadcast network, where no Network 90 LSA is advertised and Router-LSAs simply include p2p links to all 91 routers on the same network with individual metrics. Broadcast 92 capability is still utilized to optimize database synchronization and 93 adjacency maintenance. 95 That works well for broadcast networks where the metric between 96 different pair of routers are really independent. For example, 97 Virtual Private LAN Service (VPLS) networks. 99 With certain types of broadcast networks, further optimization can be 100 made to reduce the size of the Router-LSAs and number of updates. 102 Consider a satellite radio network with fixed and mobile ground 103 terminals. All communication goes through the satellite. When the 104 mobile terminals move about, their communication capability may 105 change. When OSPF runs over the radio network (routers being or in 106 tandem with the terminals), [RFC6845] hybrid interface can be used, 107 but with the following drawbacks. 109 Consider that one terminal/router moves into an area where its 110 communication capability degrades significantly. Through the radio 111 control protocol, all other routers determine that the metric to this 112 particular router changed and they all need to update their Router- 113 LSAs accordingly. The router in question also determines that its 114 metric to reach all others also changed and it also needs to update 115 its Router-LSA. Consider that there could be many terminals and many 116 of them can be moving fast and frequently, the number/frequency of 117 updates of those large Router-LSAs could inhibit network scaling. 119 1.1. Requirements Language 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119]. 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 [RFC6845] 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 TBD2. 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-ID | 0 | MT Metric | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 Multiple such Sub-TLVs can exist in a single OSPF Extended Link TLV, 194 one for each topology [RFC4915]. Each Sub-TLV will have a unique 195 Multi-Topology Identifier (MT-ID) and will adhere to the 196 advertisement rules defined in section 3.4 of [RFC4915]. The OSPF 197 Extended Link TLV identifies the transit link to the network, and is 198 part of an OSPFv2 Extended-Link Opaque LSA. The Sub-TLV MUST ONLY 199 appear in Extended-Link TLVs for Link Type 2 (link to transit 200 network), and MUST be ignored if received for other link types. 202 3.3. Advertising Network-to-Router Traffic Engineering (TE) Metric 204 A Traffic Engineering Network-to-Router Metric Sub-TLV is defined, 205 similar to the Traffic Engineering Metric Sub-TLV defined in 206 Section 2.5.5 of [RFC3630]. The only difference is the TLV type, 207 which is TBD3. The Sub-TLV MUST only appear in type 2 Link TLVs 208 (Multi-access) of Traffic Engineer LSAs (OSPF2) or Intra-Area-TE-LSAs 209 (OSPFv3) [RFC5329], and MUST appear at most once in such Link TLV. 211 3.4. Advertising Network-to-Router Metric in OSPFv3 213 Network-to-Router metric advertisement in OSPFv3 Extended-Router-LSA 214 [I-D.ietf-ospf-ospfv3-lsa-extend] will be described in a separate 215 document. 217 3.5. OSPF Stub Router Behavior 219 When an OSPF router with interfaces including two-part metric is 220 advertising itself as a stub router [RFC6987], only the Router-to- 221 Network metric in the stub router's OSPF Router-LSA links is set to 222 the MaxLinkMetric. This is fully backward compatible and will result 223 in the same behavior as [RFC6987]. 225 3.6. SPF Calculation 227 The first stage of the shortest-path tree calculation is described in 228 section 16.1 of [RFC2328]. With two-part metric, when a vertex V 229 corresponding to a Network-LSA has just been added to the Shortest 230 Path Tree (SPT) and an adjacent vertex W (joined by a link in V's 231 corresponding Network-LSA) is being added to the candidate list, the 232 cost from V to W (W's network-to-router cost) is determined as 233 follows: 235 o For OSPFv2, if vertex W has a corresponding Extended-Link Opaque 236 LSA with an Extended Link TLV for the link from W to V, and the 237 Extended Link TLV has a Network-to-Router Metric Sub-TLV for the 238 corresponding topology, then the cost from V to W is the metric in 239 the Sub-TLV. Otherwise, the cost is 0. 241 o OSPFv3 [RFC5340] SPF changes will be described in a separate 242 document. 244 3.7. Backward Compatibility 246 Due to the change of procedures in the SPF calculation, all routers 247 in an area that includes one or more two-part metric networks must 248 support the changes specified in this document. To ensure that, if 249 an area is provisioned to support two-part metric networks, all 250 routers supporting this capability must advertise a Router 251 Information (RI) LSA with a Router Functional Capabilities TLV 252 [RFC7770] that includes the following Router Functional Capability 253 Bit: 255 Bit Capabilities 257 TBD1 OSPF Two-part Metric (TPM) 259 Upon detecting the presence of a reachable Router-LSA without a 260 companion RI LSA that has the bit set, all routers MUST recalculate 261 routes without considering any network-to-router costs. 263 4. IANA Considerations 265 This document requests the following IANA assignments: 267 o A new bit (TBD1) in Registry for OSPF Router Informational 268 Capability Bits, to indicate the capability of supporting two-part 269 metric. 271 o A new Sub-TLV type (TBD2) in OSPF Extended Link TLV Sub-TLV 272 registry, for the Network-to-Router Metric Sub-TLV. 274 o A new Sub-TLV type (TBD3) in Types for sub-TLVs of TE Link TLV 275 (Value 2) registry, for the Network-to-Router TE Metric Sub-TLV. 277 5. Security Considerations 279 This document does not introduce new security risks. Existing 280 security considerations in OSPFv2 and OSPFv3 apply. 282 6. References 284 6.1. Normative References 286 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 287 Requirement Levels", BCP 14, RFC 2119, 288 DOI 10.17487/RFC2119, March 1997, 289 . 291 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 292 DOI 10.17487/RFC2328, April 1998, 293 . 295 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 296 (TE) Extensions to OSPF Version 2", RFC 3630, 297 DOI 10.17487/RFC3630, September 2003, 298 . 300 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 301 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 302 RFC 4915, DOI 10.17487/RFC4915, June 2007, 303 . 305 [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., 306 "Traffic Engineering Extensions to OSPF Version 3", 307 RFC 5329, DOI 10.17487/RFC5329, September 2008, 308 . 310 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 311 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 312 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 313 2015, . 315 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 316 S. Shaffer, "Extensions to OSPF for Advertising Optional 317 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 318 February 2016, . 320 6.2. Informative References 322 [I-D.ietf-ospf-ospfv3-lsa-extend] 323 Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3 324 LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-12 325 (work in progress), September 2016. 327 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 328 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 329 . 331 [RFC6845] Sheth, N., Wang, L., and J. Zhang, "OSPF Hybrid Broadcast 332 and Point-to-Multipoint Interface Type", RFC 6845, 333 DOI 10.17487/RFC6845, January 2013, 334 . 336 [RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D. 337 McPherson, "OSPF Stub Router Advertisement", RFC 6987, 338 DOI 10.17487/RFC6987, September 2013, 339 . 341 Appendix A. Acknowledgements 343 The authors would like to thank Abhay Roy, Hannes Gredler, Peter 344 Psenak and Eric Wu for their comments and suggestions. 346 The RFC text was produced using Marshall Rose's xml2rfc tool. 348 Appendix B. Contributors' Addreses 350 David Dubois 351 General Dynamics C4S 352 400 John Quincy Adams Road 353 Taunton, MA 02780 355 EMail: dave.dubois@gd-ms.com 357 Vibhor Julka 358 Individual 360 EMail: vjulka1@yahoo.com 362 Tom McMillan 363 L3 Communications, Linkabit 364 9890 Towne Centre Drive 365 San Diego, CA 92121 367 EMail: tom.mcmillan@l-3com.com 369 Authors' Addresses 371 Zhaohui Zhang 372 Juniper Networks, Inc. 373 10 Technology Park Drive 374 Westford, MA 01886 376 Email: zzhang@juniper.net 378 Lili Wang 379 Juniper Networks, Inc. 380 10 Technology Park Drive 381 Westford, MA 01886 383 Email: liliw@juniper.net 385 Acee Lindem 386 Cisco Systems 387 301 Midenhall Way 388 Cary, NC 27513 390 Email: acee@cisco.com