RFC 8042

OSPF Two-Part Metric

📅 published December 2016, from ietf

RFC 8042: OSPF Two-Part Metric 🦋

okay bestie, this is the one about OSPF (the routing protocol that helps routers figure out the best path 🗺️) and it's a whole glow-up for multi-access networks ✨

  • Number: RFC 8042
  • Title: OSPF Two-Part Metric
  • Authors: Z. Zhang (Juniper Networks, Inc.), L. Wang (Juniper Networks, Inc.), A. Lindem (Cisco Systems)
  • Category: Standards Track
  • ISSN: 2070-1721
  • Date: December 2016
  • Updates: RFC 2328 🔥

Lowkey the most important fact is that it updates RFC 2328, so it's changing the rules of the base OSPF spec 👑

Abstract

okay so the abstract says this is an optional OSPF extension 💅 where a router's metric in a multi-access network gets split into two parts 🎀 one part is the metric from the router to the network, and the other is the metric from the network back to the router. for these networks, the router-to-router metric used in route computation is just the sum of those two parts 🧚 and this doc updates RFC 2328 💖

Status of This Memo

this is an Internet Standards Track document 🌈

it's a product of the Internet Engineering Task Force (IETF) 🫶 it represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication ✨ more info on Internet Standards is in Section 2 of RFC 7841 📚

info about the current status, errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc8042 🔗

copyright (c) 2016 IETF Trust and the persons identified as the document authors 🎀 all rights reserved 💜

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were on the day it was published 📜 please actually read those, because they explain your rights and restrictions for this doc 🙈

code components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions 🌸 and they come with no warranty, as described in the Simplified BSD License 💅

Table of Contents

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
  1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
2.  Proposed Enhancement  . . . . . . . . . . . . . . . . . . . .   3
3.  Specifications  . . . . . . . . . . . . . . . . . . . . . . .   4
  3.1.  Router Interface Parameters . . . . . . . . . . . . . . .   4
  3.2.  Advertising Network-to-Router Metric in OSPFv2  . . . . .   4
  3.3.  Advertising Network-to-Router Traffic Engineering (TE)
        Metric  . . . . . . . . . . . . . . . . . . . . . . . . .   5
  3.4.  Advertising Network-to-Router Metric in OSPFv3  . . . . .   5
  3.5.  OSPF Stub Router Behavior . . . . . . . . . . . . . . . .   5
  3.6.  SPF Calculation . . . . . . . . . . . . . . . . . . . . .   5
  3.7.  Backward Compatibility  . . . . . . . . . . . . . . . . .   6
4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
  6.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
  6.2.  Informative References  . . . . . . . . . . . . . . . . .   7
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   8
Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1. Introduction ✨

okay so with Open Shortest Path First (OSPF) [RFC2328] [RFC5340], a Network-LSA (Link State Advertisement) gets advertised to list all the routers on a broadcast network 📡 on top of that, every router on that broadcast network adds a link in its Router-LSA to describe how it's connected to the network 🔗 the link in the Router-LSA has a metric, but the routers listed in the Network-LSA don't have one 🙈 that's because the assumption is that from any given router, everyone else on the same network can be reached with the same metric 💅

but on some broadcast networks, different routers can be reached with different metrics 🌈 that's where [RFC6845] comes in. it adds a hybrid interface type for this kind of network 🎀 there's no Network-LSA in that case, and the Router-LSAs just include point-to-point links to every router on the same network, each with its own metric 🧚 broadcast capability is still used for database synchronization and adjacency maintenance 💖

this works super well for broadcast networks where the metrics between different pairs of routers are really independent, like Virtual Private LAN Service (VPLS) networks 👑

with certain types of broadcast networks, you can optimize even further to shrink the size of Router-LSAs and cut down on the number of updates ✨

picture a satellite radio network with fixed and mobile ground terminals 🛰️ all the communication goes through the satellite 🌸 when the mobile terminals move around, their communication capability can change 🏃‍♀️ if OSPF runs over that radio network, the [RFC6845] hybrid interface can be used, but it comes with some drawbacks 💀

say one terminal (router) moves into an area where its communication gets way worse 📉 through the radio control protocol, all the other routers figure out that the metric to this router changed, so they all have to update their Router-LSAs 😭 the router in question also notices that its metric to reach everyone else changed, so it has to update its own Router-LSA too 🫠 and there could be tons of terminals, with lots of them moving fast and often 🏎️ the number and frequency of updates to those big Router-LSAs could seriously hold back network scaling 🥲

1.1. Requirements Language

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 📖 these are the official BCP 14 words, so read them carefully 🔍

2. Proposed Enhancement 🦋

notice that in the scenario above, when one terminal's communication capability changes, its metric to all the other terminals and the metric to it from all the other terminals all change in a similar way 👀 so the fix is pretty clean: split the metric into two parts, the metric to the satellite and the metric from the satellite 🎀 the metric from terminal R1 to R2 is then the sum of the metric from R1 to the satellite and the metric from the satellite to R2 🧮

instead of using the hybrid interface type from [RFC6845], the network gets treated as a regular broadcast network 📡 a router on the network no longer lists individual metrics to each neighbor in its Router-LSA 🙌 instead, each router advertises the metric from the network to itself, on top of the normal metric for the network 💅 with the normal Router-to-Network metric plus the extra Network-to-Router metric advertised for each router, you can calculate the individual Router-to-Router metrics 🧠

with this enhancement, the Router-LSA gets way smaller 📉✨ and when one router's communication capability changes, only that router has to update its own Router-LSA 🥳

heads up that while the example uses the satellite as the relay point at the radio level (layer 2), the satellite doesn't take part in packet forwarding at layer 3 💫 in fact, the satellite doesn't need to run any layer-3 protocol at all 🛰️ so for generality, the metric is described as to/from the "network" instead of specifically to/from the "satellite" 🌈

3. Specifications 📜

the following specifications are added to or changed from the base OSPF protocol 🎀 if an area contains one or more two-part metric networks, then all routers in the area MUST support the extensions specified here 🚨 this is ensured by the procedures in Section 3.7 🫶

3.1. Router Interface Parameters

the "Router interface parameters" get these additions 💖

  • Two-part metric: TRUE if the interface connects to a multi-access network that uses a two-part metric 🧩 all routers connected to the same network SHOULD have the same configuration for their corresponding interfaces 🙌
  • Interface input cost: the link-state metric from the two-part-metric network to this router 🌸 it defaults to Interface output cost, but it's not valid for normal networks that use a single metric 🙅‍♀️ it's allowed to be configured or dynamically adjusted to a value different from Interface output cost 🔧

3.2. Advertising Network-to-Router Metric in OSPFv2

for OSPFv2, the Network-to-Router metric gets encoded in an OSPF Extended Link TLV Sub-TLV [RFC7684], which this doc defines as the Network-to-Router Metric Sub-TLV 🎀 the sub-TLV type is 4 💜 the length of the sub-TLV is 4 (for the value part only) 📏 the value part is defined like this 👇

       0                   1                   2                   3
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      MT-ID    |        0      |          MT Metric            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

you can have multiple sub-TLVs like this in one OSPF Extended Link TLV, one for each topology [RFC4915] 🗂️ each one gets its own unique Multi-Topology Identifier (MT-ID) and has to follow the advertisement rules in Section 3.4 of [RFC4915] 📋 the OSPF Extended Link TLV identifies the transit link to the network, and it's part of an OSPFv2 Extended-Link Opaque LSA 🧾 the sub-TLV MUST ONLY appear in Extended-Link TLVs for Link Type 2 (link to transit network), and it MUST be ignored if it's received for other link types 🚫

3.3. Advertising Network-to-Router Traffic Engineering (TE) Metric

there's a Traffic Engineering Network-to-Router Metric Sub-TLV that's basically a copy of the Traffic Engineering Metric Sub-TLV from Section 2.5.5 of [RFC3630] 👯‍♀️ the only difference is the TLV type, which is 35 🔢 the sub-TLV MUST only appear in Type 2 Link TLVs (Multi-access) of Traffic Engineer LSAs (OSPF2) or Intra-Area-TE-LSAs (OSPFv3) [RFC5329], and it MUST appear at most once in such a Link TLV ☝️

3.4. Advertising Network-to-Router Metric in OSPFv3

the Network-to-Router metric advertisement in the OSPFv3 Extended Router-LSA [OSPFV3-EXTENDED-LSA] is going to be described in a separate document 📚 stay tuned 👀

3.5. OSPF Stub Router Behavior

when an OSPF router with interfaces to multi-access networks using two-part metrics advertises itself as a stub router [RFC6987] 🛑 only the Router-to-Network metric in the stub router's OSPF Router-LSA links for those networks gets set to the MaxLinkMetric 🎯 this is fully backward compatible, and it results in the same behavior described in [RFC6987] 🫶 iconic, no notes 💅

3.6. SPF Calculation ✨

Okay bestie, so the first stage of the shortest-path tree calculation is already spelled out in Section 16.1 of [RFC2328] 💅. Now here's the twist 🌀: with a two-part metric, when a vertex V that matches a Network-LSA has just been added to the Shortest Path Tree (SPT), and an adjacent vertex W (linked up in V's Network-LSA) is about to be added to the candidate list, the cost from V to W (that's W's network-to-router cost) gets worked out like this:

  • For OSPFv2, if vertex W has a matching Extended-Link Opaque LSA with an Extended Link TLV for the link from W to V, AND that Extended Link TLV has a Network-to-Router Metric Sub-TLV for the matching topology, then the cost from V to W is the metric in that sub-TLV. Otherwise, the cost is 0 🫶.
  • OSPFv3 [RFC5340] Shortest Path First (SPF) changes will be described in a separate document 🧚. Stay tuned for that one!

3.7. Backward Compatibility 🦋

Okay this part is SO important 😭. Since the SPF calculation procedures changed, every router in an area that has one or more two-part metric networks must support the changes in this document. To make sure that happens, if an area is set up to support two-part metric networks, every router that supports this capability must advertise a Router Information (RI) LSA with a Router Functional Capabilities TLV [RFC7770]. That TLV includes the following Router Functional Capability Bit:

          Bit       Capabilities

          6         Two-Part Metric support

And here's the big catch 🙈: when a router spots a reachable Router-LSA that doesn't have a companion RI LSA with that bit set, ALL routers MUST recalculate routes without considering any network-to-router costs. Nobody gets to skip this one, periodt 💀.

4. IANA Considerations ✨

IANA made the following assignments per this document 📝:

  • Two-Part Metric support (6) was added to the "OSPF Router Informational Capability Bits" registry.
  • Network-to-Router Metric Sub-TLV (4) has been added to the "OSPFv2 Extended Link TLV Sub-TLVs" registry.
  • Network-to-Router TE Metric Sub-TLV (35) has been added to the "Types for sub-TLVs of TE Link TLV (Value 2)" registry.

5. Security Considerations 🔥

Okay, I need you to pay attention to this bit 🚨. This document does not introduce new security risks, so you're not getting any surprise dangers here. ✨ That said, the existing security considerations in OSPFv2 and OSPFv3 still apply, so don't forget about them 🛡️💖.

6. References ✨

6.1. Normative References 📚

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <http://www.rfc-editor.org/info/rfc2119>.

[RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328,
           DOI 10.17487/RFC2328, April 1998,
           <http://www.rfc-editor.org/info/rfc2328>.

[RFC3630]  Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
           (TE) Extensions to OSPF Version 2", RFC 3630,
           DOI 10.17487/RFC3630, September 2003,
           <http://www.rfc-editor.org/info/rfc3630>.

[RFC4915]  Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
           Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
           RFC 4915, DOI 10.17487/RFC4915, June 2007,
           <http://www.rfc-editor.org/info/rfc4915>.

[RFC5329]  Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed.,
           "Traffic Engineering Extensions to OSPF Version 3",
           RFC 5329, DOI 10.17487/RFC5329, September 2008,
           <http://www.rfc-editor.org/info/rfc5329>.

[RFC7684]  Psenak, P., Gredler, H., Shakir, R., Henderickx, W.,
           Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute
           Advertisement", RFC 7684, DOI 10.17487/RFC7684, November
           2015, <http://www.rfc-editor.org/info/rfc7684>.

[RFC7770]  Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and
           S. Shaffer, "Extensions to OSPF for Advertising Optional
           Router Capabilities", RFC 7770, DOI 10.17487/RFC7770,
           February 2016, <http://www.rfc-editor.org/info/rfc7770>.

6.2. Informative References 🧠

[OSPFV3-EXTENDED-LSA]
           Lindem, A., Mirtorabi, S., and A. Roy, "OSPFv3 LSA
           Extendibility", Work in Progress, draft-ietf-ospf-ospfv3-
           lsa-extend-13.txt, October 2016.

[RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
           for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
           <http://www.rfc-editor.org/info/rfc5340>.

[RFC6845]  Sheth, N., Wang, L., and J. Zhang, "OSPF Hybrid Broadcast
           and Point-to-Multipoint Interface Type", RFC 6845,
           DOI 10.17487/RFC6845, January 2013,
           <http://www.rfc-editor.org/info/rfc6845>.

[RFC6987]  Retana, A., Nguyen, L., Zinin, A., White, R., and D.
           McPherson, "OSPF Stub Router Advertisement", RFC 6987,
           DOI 10.17487/RFC6987, September 2013,
           <http://www.rfc-editor.org/info/rfc6987>.

Acknowledgements 🫶

The authors would like to thank Abhay Roy, Hannes Gredler, Peter Psenak, and Eric Wu for their comments and suggestions. Thank you, queens 👑💜!

Contributors 🌸

David Dubois
General Dynamics C4S
400 John Quincy Adams Road
Taunton, MA 02780
United States of America
Email: dave.dubois@gd-ms.com

Vibhor Julka
Individual Contributor

Email: vjulka1@yahoo.com


Tom McMillan
L3 Communications, Linkabit
9890 Towne Centre Drive
San Diego, CA 92121
United States of America
Email: tom.mcmillan@l-3com.com

Authors' Addresses 🎀

Zhaohui Zhang
Juniper Networks, Inc.
10 Technology Park Drive
Westford, MA 01886
United States of America

Email: zzhang@juniper.net


Lili Wang
Juniper Networks, Inc.
10 Technology Park Drive
Westford, MA 01886
United States of America

Email: liliw@juniper.net


Acee Lindem
Cisco Systems
301 Midenhall Way
Cary, NC 27513
United States of America

Email: acee@cisco.com
📦 where this page comes from