idnits 2.17.1 draft-zzhang-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 : ---------------------------------------------------------------------------- -- 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 (October 14, 2014) is 3480 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 241, but not defined == Unused Reference: 'I-D.acee-ospf-rfc4970bis' is defined on line 273, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ospf-lsa-extend' is defined on line 281, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ospf-ospfv3-lsa-extend' is defined on line 289, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 295, but no explicit reference was found in the text == Unused Reference: 'RFC2328' is defined on line 300, but no explicit reference was found in the text == Unused Reference: 'RFC4915' is defined on line 303, but no explicit reference was found in the text == Unused Reference: 'RFC5340' is defined on line 309, but no explicit reference was found in the text == Unused Reference: 'RFC5613' is defined on line 313, but no explicit reference was found in the text == Unused Reference: 'RFC6845' is defined on line 320, but no explicit reference was found in the text == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-lsa-extend-04 Summary: 0 errors (**), 0 flaws (~~), 12 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: April 17, 2015 Cisco Systems 7 D. Dubois 8 General Dynamics C4S 9 V. Julka 10 T. McMillan 11 L3 Communications, Linkabit 12 October 14, 2014 14 OSPF Two-part Metric 15 draft-zzhang-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. 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 April 17, 2015. 48 Copyright Notice 49 Copyright (c) 2014 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Proposed Enhancement . . . . . . . . . . . . . . . . . . . . . 3 66 3. Speficications . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3.1. Router Interface Parameters . . . . . . . . . . . . . . . . 4 68 3.2. Advertising Network-to-Router metric in OSPFv2 . . . . . . 5 69 3.3. Advertising Network-to-Router metric in OSPFv3 . . . . . . 5 70 3.4. SPF Calculation . . . . . . . . . . . . . . . . . . . . . . 5 71 3.5. Backward Compatibility . . . . . . . . . . . . . . . . . . 6 72 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 74 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 77 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 79 1. Introduction 81 For a broadcast network, a Network-LSA is advertised to list all 82 routers on the network, and each router on the network includes a 83 link in its Router-LSA to describe its connection to the network. 84 The link in the Router-LSA includes a metric but the listed routers 85 in the Network LSA do not include a metric. This is based on the 86 assumption that from a particular router, all others on the same 87 network can be reached with the same metric. 89 With some broadcast networks, different routers can be reached with 90 different metrics. RFC 6845 extends the OSPF protocol with a hybrid 91 interface type for that kind of broadcast network, where no Network 92 LSA is advertised and Router-LSAs simply include p2p links to all 93 routers on the same network with individual metrics. Broadcast 94 capability is still utilized to optimize database synchronization and 95 adjacency maintenance. 97 That works well for broadcast networks where the metric between 98 different pair of routers are really independent. For example, VPLS 99 networks. 101 With certain types of broadcast networks, further optimization can be 102 made to reduce the size of the Router-LSAs and number of updates. 104 Consider a satellite radio network with fixed and mobile ground 105 terminals. All communication goes through the satellite. When the 106 mobile terminals move about, their communication capability may 107 change. When OSPF runs over the radio network (routers being or in 108 tandem with the terminals), RFC 6845 hybrid interface can be used, 109 but with the following drawbacks. 111 Consider that one terminal/router moves into an area where its 112 communication capability degrades significantly. Through the radio 113 control protocol, all other routers determine that the metric to this 114 particular router changed and they all need to update their Router- 115 LSAs accordingly. The router in question also determines that its 116 metric to reach all others also changed and it also needs to update 117 its Router-LSA. Consider that there could be many terminals and many 118 of them can be moving fast and frequently, the number/frequency of 119 updates of those large Router-LSAs could inhibit network scaling. 121 2. Proposed Enhancement 123 Notice that in the above scenario, when one terminal's communication 124 capability changes, its metric to all other terminals and the metric 125 from all other terminals to it will all change in a similar fashion. 126 Given this, the above problem can be easily addressed by breaking the 127 metric into two parts: the metric to the satellite and the metric 128 from the satellite. The metric from terminal R1 to R2 would be the 129 sum of the metric from R1 to the satellite and the metric from the 130 satellite to R2. 132 Now instead of using the RFC 6845 hybrid interface type, the network 133 is just treated as a regular broadcast network. A router on the 134 network no longer lists individual metrics to each neighbor in its 135 Router-LSA. Instead, each router advertises the metric from the 136 network to itself in addition to the normal metric for the network. 137 With the normal Router-to-Network and additional Network-to-Router 138 metrics advertised for each router, individual router-to-router 139 metric can be calculated. 141 With the proposed enhancement, the size of Router-LSA will be 142 significantly reduced. In addition, when a router's communication 143 capability changes, only that router needs to update its Router-LSA. 145 Note that while the example uses the satellite as the relay point at 146 the radio level (layer-2), at layer-3, the satellite does not 147 participate in packet forwarding. In fact, the satellite does not 148 need to be running any layer-3 protocol. Therefore for generality, 149 the metric is abstracted as to/from the "network" rather that 150 specifically to/from the "satellite". 152 3. Speficications 154 The following protocol specifications are added to or modified from 155 the base OSPF protocol. If an area contains one or more two-part 156 metric networks, then all routers in the area must support the 157 extensions specified herein. This is ensured by procedures described 158 in Section 3.5. 160 3.1. Router Interface Parameters 162 The "Router interface parameters" have the following additions: 164 o Two-part metric: TRUE if the interface connects to a multi-access 165 network that uses two-part metric. All routers connected to the 166 same network SHOULD have the same configuration for their 167 corresponding interfaces. 169 o Interface input cost: Link state metric from the two-part-metric 170 network to this router. Defaulted to "Interface output cost" but 171 not valid for normal networks using a single metric. May be 172 configured or dynamically adjusted to a value different from the 173 "Interface output cost". 175 3.2. Advertising Network-to-Router metric in OSPFv2 177 For OSPFv2, the Network-to-Router metric is encoded in an OSPF 178 Extended Link TLV Sub-TLV [ietf-ospf-lsa-extend], defined in this 179 document as the Network-to-Router Metric Sub-TLV. The type of the 180 Sub-TLV is TBD. The length of the Sub-TLV is 4 (for the value part 181 only). The value part of the Sub-TLV is defined as follows: 183 0 1 2 3 184 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 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | MT | 0 | MT metric | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 Multiple such Sub-TLVs can exist in a single OSPF Extended Link TLV, 190 one for each topology. The OSPF Extended Link TLV identifies the 191 transit link to the network, and is part of an OSPFv2 Extended-Link 192 Opaque LSA. The Sub-TLV MUST ONLY appear in Extended-Link TLVs for 193 Link Type 2 (link to transit network), and MUST be ignored if 194 received for other link types. 196 3.3. Advertising Network-to-Router metric in OSPFv3 198 For OSPFv3, the same Network-to-Router Metric Sub-TLV definition is 199 used, though it is part of the Router-Link TLV of E-Router-LSA [ietf- 200 ospf-ospfv3-lsa-extend]. Currently OSPFv3 Multi-Toplogy is not 201 defined so the only valid value for the MT field is 0 and only one 202 such Sub-TLV SHOULD be included in the Router-Link TLV. Received 203 Sub-TLVs with non-zero MT field MUST be ignored. 205 Similarly, the Sub-TLV MUST ONLY appear in Router-Link TLVs for Link 206 Type 2 (connection to a transit network) and MUST be ignored if 207 received for other link types. 209 3.4. SPF Calculation 211 During the first stage of shortest-path tree calculation for an area, 212 when a vertex V corresponding to a Network-LSA is added to the 213 shortest-path tree and its adjacent vertex W (joined by a link in V's 214 corresponding Network LSA), the cost from V to W, which is W's 215 network-to-router cost, is determined as follows: 217 o For OSPFv2, if vertex W has a corresponding Extended-Link Opaque 218 LSA with an Extended Link TLV for the link from W to V, and the 219 Extended Link TLV has a Network-to-Router Metric Sub-TLV for the 220 corresponding topology, then the cost from V to W is the metric in 221 the Sub-TLV. Otherwise, the cost is 0. 223 o For OSPFv3, if vertex W has a corresponding E-Router-LSA with a 224 Router-Link TLV for the link from W to V, and the Router-Link TLV 225 has a Network-to-Router Metric Sub-TLV, then the cost from V to W 226 is the metric in the Sub-TLV. If not, the cost is 0. 228 3.5. Backward Compatibility 230 Due to the change of procedures in the SPF calculation, all routers 231 in an area that includes one or more two-part metric networks must 232 support the changes specified in this document. To ensure that, if 233 an area is provisioned to support two-part metric networks, all 234 routers supporting this capability must advertise a Router 235 Information (RI) LSA with a Router Functional Capabilities TLV [acee- 236 ospf-rfc4970bis] that includes the following Router Functional 237 Capability Bit: 239 Bit Capabilities 241 0 OSPF Two-part Metric [TPM] 243 Upon detecting the presence of a reachable Router-LSA without a 244 companion RI LSA that has the bit set, all routers MUST disable the 245 two-part metric functionalities and take the following actions: 247 o If this router currently advertises network-to-router costs, 248 remove the Network-to-Router Metric Sub-TLVs. This may lead to 249 removal of parent TLVs and even withdrawal of the parent LSAs. 251 o Recalculate routes w/o considering any network-to-router costs. 253 4. IANA Considerations 255 This document requests IANA to assigna a new bit in the Router 256 Functional Capabilities TLV to indicate the capability of supporting 257 two-part metric, a new Sub-TLV in the OSPF Extended-Link TLV Sub-TLV 258 Registry, and a new Sub-TLV in the The OSPFv3 Extend-LSA Sub-TLV 259 registry. 261 5. Security Considerations 263 This document does not introduce new security risks. 265 6. Acknowledgements 267 The authors would like to thank Abhay Roy, Hannes Gredler, Peter 268 Psenak and Eric Wu for their comments and suggestions. 270 7. References 271 7.1. Normative References 273 [I-D.acee-ospf-rfc4970bis] Lindem, A., Shen, N., Vasseur, J., 274 Aggarwal, R., and S. Shaffer, 275 "Extensions to OSPF for 276 Advertising Optional Router 277 Capabilities", 278 draft-acee-ospf-rfc4970bis-00 279 (work in progress), July 2014. 281 [I-D.ietf-ospf-lsa-extend] Psenak, P., Previdi, S., Filsfils, 282 C., Gredler, H., Shakir, R., 283 Henderickx, W., Tantsura, J., and 284 A. Lindem, "OSPFv2 LSA 285 Extendibility", 286 draft-ietf-ospf-lsa-extend-00 287 (work in progress), August 2014. 289 [I-D.ietf-ospf-ospfv3-lsa-extend] Lindem, A., Mirtorabi, S., Roy, 290 A., and F. Baker, "OSPFv3 LSA 291 Extendibility", draft-ietf-ospf- 292 ospfv3-lsa-extend-04 (work in 293 progress), September 2014. 295 [RFC2119] Bradner, S., "Key words for use in 296 RFCs to Indicate Requirement 297 Levels", BCP 14, RFC 2119, 298 March 1997. 300 [RFC2328] Moy, J., "OSPF Version 2", STD 54, 301 RFC 2328, April 1998. 303 [RFC4915] Psenak, P., Mirtorabi, S., Roy, 304 A., Nguyen, L., and P. Pillay- 305 Esnault, "Multi-Topology (MT) 306 Routing in OSPF", RFC 4915, 307 June 2007. 309 [RFC5340] Coltun, R., Ferguson, D., Moy, J., 310 and A. Lindem, "OSPF for IPv6", 311 RFC 5340, July 2008. 313 [RFC5613] Zinin, A., Roy, A., Nguyen, L., 314 Friedman, B., and D. Yeung, "OSPF 315 Link-Local Signaling", RFC 5613, 316 August 2009. 318 7.2. Informative References 320 [RFC6845] Sheth, N., Wang, L., and J. Zhang, 321 "OSPF Hybrid Broadcast and Point- 322 to-Multipoint Interface Type", 323 RFC 6845, January 2013. 325 Authors' Addresses 327 Jeffrey Zhang 328 Juniper Networks, Inc. 329 10 Technology Park Drive 330 Westford, MA 01886 332 EMail: zzhang@juniper.net 334 Lili Wang 335 Juniper Networks, Inc. 336 10 Technology Park Drive 337 Westford, MA 01886 339 EMail: liliw@juniper.net 341 Acee Lindem 342 Cisco Systems 343 301 Midenhall Way 344 Cary, NC 27513 346 EMail: acee@cisco.com 348 David Dubois 349 General Dynamics C4S 350 400 John Quincy Adams Road 351 Taunton, MA 02780 353 EMail: dave.dubois@gdc4s.com 355 Vibhor Julka 356 L3 Communications, Linkabit 357 9890 Towne Centre Drive 358 San Diego, CA 92121 360 EMail: vibhor.julka@l-3Com.com 361 Tom McMillan 362 L3 Communications, Linkabit 363 9890 Towne Centre Drive 364 San Diego, CA 92121 366 EMail: tom.mcmillan@l-3com.com