RFC 9339

OSPF Reverse Metric

📅 published December 2022, from ietf

RFC 9339: OSPF Reverse Metric 🎀 is an IETF (Internet Engineering Task Force) document, and it's on the Standards Track 💅. Its authors are K. Talaulikar (Ed.), P. Psenak from Cisco Systems, Inc., and H. Johnston from AT&T Labs. The ISSN is 2070-1721, and it's dated December 2022 📅. The header doesn't list any RFCs that it obsoletes or updates, so there's no drama there 🫶

Abstract 🦋

This doc extends OSPF so a router can use Link-Local Signaling (LLS) to tell its neighbor(s) which metric they should use for the link back toward the signaling router 🔥. When this reverse metric (RM) is signaled on the link to that router, it lets the router influence how much traffic comes toward itself. In some setups, it helps both sides of a link keep symmetric metrics 💜

Status of This Memo 📜

This is an Internet Standards Track document 🌸

It's a product of the IETF, it represents the consensus of the IETF community, and it has had public review. The Internet Engineering Steering Group (IESG) approved it for publication. For more on Internet Standards, check Section 2 of RFC 7841 🧚

You can find the current status, any errata, and the way to send feedback at https://www.rfc-editor.org/info/rfc9339 💖

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved ✨

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info), as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document 📖 Any Code Components pulled out of this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions. They're provided without warranty, as the Revised BSD License describes 🦋

Table of Contents 🗂️

   1.  Introduction
     1.1.  Requirements Language
   2.  Use Cases
     2.1.  Link Maintenance
     2.2.  Adaptive Metric Signaling
   3.  Solution
   4.  LLS Reverse Metric TLV
   5.  LLS Reverse TE Metric TLV
   6.  Procedures
   7.  Operational Guidelines
   8.  Backward Compatibility
   9.  IANA Considerations
   10. Security Considerations
   11. References
     11.1.  Normative References
     11.2.  Informative References
   Acknowledgements
   Authors' Addresses

1. Introduction ✨

Okay, so a router running OSPFv2 [RFC2328] or OSPFv3 [RFC5340] creates a Router-LSA (Link State Advertisement) that describes all of its links to neighbors. Each link comes with a metric that shows its "cost" to reach that neighbor 🛣️ Picture two routers, R1 and R2, connected by a link. In the R1->R2 direction, the metric is configured on R1. In the R2->R1 direction, it's configured on R2. So R1's config only affects the traffic R1 sends to R2. It has no say over the traffic R1 receives from R2 on that same link 🙈

This doc describes use cases where a router needs to signal what we call the "reverse metric" (RM) to its neighbor, so the neighbor adjusts the routing metric for inbound traffic 💅 When R1 signals its RM on its link to R2, R2 puts that value in its Router-LSA as its metric toward R1, instead of its locally configured value. Once that's part of the topology, every other router computes with it too. That can give R1 the traffic shift it wanted for traffic coming to it over the link from R2 👑

This doc also extends OSPF LLS [RFC5613] to signal OSPF RMs. Section 4 defines the LLS Reverse Metric TLV, and Section 5 defines the LLS Reverse TE Metric TLV. The procedures are in Section 6 🌈

1.1. Requirements Language 🧐

Here's the deal with the capital-letter words. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in BCP 14 [RFC2119] [RFC8174], but only when they appear in all capitals, just like shown here 🫶

2. Use Cases 🎀

This section walks through some use cases that the OSPF RM covers. The OSPF RM isn't limited to these, though. It's meant to be a generic mechanism 💖

              Core Network
          ^                ^
          |                |
          V                v
     +----------+    +----------+
     |  AGGR1   |    |  AGGR2   |
     +----------+    +----------+
       ^      ^        ^      ^
       |      |        |      |
       |      +-----------+   |
       |               |  |   |
       |      +--------+  |   |
       v      v           v   v
    +-----------+      +-----------+
    |    R1     |      |    RN     |
    |  Router   | ...  |  Router   |
    +-----------+      +-----------+

              Figure 1: Reference Dual Hub-and-Spoke Topology

Imagine a deployment like Figure 1, where routers R1 through RN are dual-homed to AGGR1 and AGGR2, which aggregate their traffic toward a core network 🌸

Before maintenance happens on individual links, operators crank the OSPF metric up to its maximum on both routers attached to the same link, all at once 🔥 The routers generate new Router LSAs, those get flooded through the network, and every router shifts traffic onto alternate paths where they exist. That keeps disruption to in-flight application and end-user traffic fairly limited, though it depends on the topology. Done right, the operator can safely do disruptive augmentation, fault diagnosis, or repairs on a link in production 🧚

In hub-and-spoke designs (like Figure 1), it's super common for routers to have several hundred interfaces, and each interface can push anywhere from several hundred gigabits to terabits per second 😭 The hard part is that the operator has to find the same point-to-point (P2P) link on two different devices, then raise the OSPF metric (and lower it again afterward) correctly and in sync 🙈 For PE-CE links, where lots of Customer Edge (CE) routers hang off one Provider Edge (PE) router, there's another headache. If the provider doesn't manage the CEs, coordinating access to them can get messy 💀

The OSPF RM mechanism helps with all of this 💜 The operator can put the link on one of the routers (usually the hub, like AGGR1 or a PE) into "maintenance mode". That makes the router advertise the maximum metric for the link, and it signals the neighbor on that same link to advertise the maximum metric too, using the reverse metric signaling 👑 Once the maintenance is done and "maintenance mode" is turned off, the router goes back to its provisioned metric and stops signaling RM on that link. The neighbor then goes back to its provisioned metric for the link as well ✨

2.2. Adaptive Metric Signaling 🦋

Back in Figure 1, say at some moment (T), AGGR1 loses some of its capacity toward the core 😬 That can cause congestion toward the core on AGGR1, which it needs to fix by sending some traffic through AGGR2, which isn't having the same problem. If AGGR1 changed its link metric toward the R1-RN routers, that would only steer traffic coming from the core toward R1-RN. It wouldn't steer traffic the other way, which is what's actually needed 🙃

So in that case, AGGR1 could signal an incremental OSPF RM to some or all of the R1-RN routers. When those routers add the signaled RM offset to the provisioned metric on their links toward AGGR1, the path through AGGR2 becomes the better one. Traffic heading to the core then moves away from AGGR1 💅 The nice part is that the adaptive change happens on AGGR1, so nobody has to provision a bunch of R1-RN routers by hand 🌈

The RM mechanism can also be used in a similar way between spine and leaf nodes in a Clos network [CLOS] topology deployment 🌷

3. Solution 💡

To handle the use cases above, and to let an OSPF router signal its RM for a specific link to its neighbor(s), this doc extends OSPF link-local signaling so the Reverse Metric TLV rides in OSPF Hello packets 💌 That keeps the RM signaling scoped to one specific link ✨ A router keeps including the Reverse Metric TLV in its Hello packets on that link for as long as it wants its neighbor to use that metric value toward itself. The detailed procedures are in Section 6 🎀

The RM mechanism in this document only applies to P2P, Point-to-Multipoint (P2MP), and hybrid-broadcast-P2MP ([RFC6845]) links 🧁 It doesn't apply to broadcast or Non-Broadcast Multi-Access (NBMA) links, because the same goal is reached there with the OSPF Two-Part Metric mechanism [RFC8042] for OSPFv2. The OSPFv3 solution for broadcast or NBMA links is out of scope for this doc 🙅‍♀️

4. LLS Reverse Metric TLV 🔥

The Reverse Metric TLV is a brand-new LLS TLV, and it has the following format 🧩

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Type             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     MTID      | Flags     |O|H|        Reverse Metric         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 2: Reverse Metric TLV

Here's what each field means 👑

  • Type: 19
  • Length: 4 octets
  • MTID: The multi-topology identifier of the link ([RFC4915]).
  • Flags: 1 octet. These are the flags defined right now, and the rest MUST be set to 0 on transmission and ignored on reception 🙈
    • H (0x1): Says the neighbor should only use the value if it's higher than its provisioned metric value for the link.
    • O (0x2): Says the RM value is an offset to be added to the provisioned metric.
  • Reverse Metric: An unsigned integer of 2 octets that carries the value or offset of RM, which replaces or gets added to the provisioned link metric 💖

5. LLS Reverse TE Metric TLV ✨

okay bestie, the Reverse TE Metric TLV is a brand new LLS TLV 🦋 and it's giving neat little packet layout:

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Type             |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Flags   |O|H|                 RESERVED                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Reverse TE Metric                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 3: Reverse TE Metric TLV

Here's what each piece means:

  • Type: 20 🌸
  • Length: 4 octets
  • Flags: 1 octet. These are the flags defined right now, and the rest MUST be set to 0 on transmission and ignored on reception:
    • H (0x1): tells the neighbor to only use the value if it's higher than its provisioned TE metric value for the link.
    • O (0x2): tells the neighbor that the reverse TE metric value is an offset to be added to the provisioned TE metric.
  • RESERVED: a 24-bit field. It MUST be set to 0 on transmission and MUST be ignored on receipt.
  • Reverse TE Metric: an unsigned integer of 4 octets carrying the value or offset of the reverse traffic engineering metric that replaces, or gets added to, the provisioned TE metric of the link. 💜

6. Procedures 🎀

okay so when a router needs to signal an RM value that its neighbor(s) should use for a link towards the router, it includes the Reverse Metric TLV in the LLS block of its Hello packets sent on that link. It keeps including this TLV for as long as it needs its neighbor to use that value. How the RM value gets figured out is up to the implementation and the use case, and it's outside the scope of this document. For example, the RM value could be derived from the router's link bandwidth compared to a reference bandwidth. 🧚

Now, a router that gets a Hello packet from its neighbor containing the Reverse Metric TLV on a link MUST use the RM value to derive the metric for the link to the advertising router in its Router-LSA, as long as the RM feature is enabled (see Section 7 for how RM gets enabled). When the O flag is set, the advertised metric is the TLV value added to the provisioned metric for the link. If that sum goes over the maximum interface cost, the metric value 0xffff (maximum interface cost) gets advertised instead. When the O flag is clear, the advertised metric is copied straight from the TLV value. When the H flag is set and the O flag is clear, the advertised metric is copied straight from the TLV value only when the RM value signaled is higher than the provisioned metric for the link. The H and O flags are mutually exclusive, so the H flag gets ignored whenever the O flag is set. 🔥

A router stops including the Reverse Metric TLV in its Hello packets when it wants its neighbors to go back to using their own provisioned metric values. When that happens, a router that changed its metric because it received a Reverse Metric TLV from a neighbor MUST revert to using its provisioned metric value.

Sometimes two or more routers might start RM signaling on the same link, and that can create collision scenarios. The following guidelines are RECOMMENDED for adoption so the network doesn't get unstable from metric churn caused by RM signaling:

  • The RM value that a router signals to its neighbor should not be derived from the RM being signaled by any of its neighbors on any of its links.
  • The RM value that a router signals to its neighbor should not be derived from the RM being signaled by any of its neighbors on any of its links. RM signaling from other routers can affect the router's metric advertised in its Router-LSA. When deriving the RM values that a router signals to its neighbors, it should use its provisioned local metric values, not ones influenced by any RM signaling.

So basically, a router wouldn't start, stop, or change its RM signaling because of RM signaling from some other routers. Based on local configuration policy, each router ends up accepting the RM value its neighbor signals, and there's no metric churn on the link or in the network because of RM signaling. Iconic behavior 👑

In some use cases where symmetrical metrics are wanted (for example, when metrics are derived from link bandwidth), RM signaling can be enabled on routers at either end of a link. In other use cases (described in Section 2.1), RM signaling may only need to be enabled on the router at one end of a link. 💅

When using multi-topology routing with OSPF [RFC4915], a router MAY include multiple instances of the Reverse Metric TLV in the LLS block of its Hello packet, one for each of the topologies where it wants to signal the RM. A router MUST NOT include more than one instance of this TLV per MTID. If more than one instance of this TLV per MTID is present, the receiving router MUST only use the value from the first instance and ignore the others. 🦋

In certain scenarios, the OSPF router may also need to change the TE metric its neighbor router advertises towards it in the inbound direction. Using procedures similar to the ones above, the Reverse TE Metric TLV MAY be used to signal the reverse TE metric for router links. The neighbor MUST use the reverse TE metric value to derive the TE metric advertised in the TE Metric sub-TLV of the Link TLV in its TE Opaque LSA [RFC3630] when the reverse metric feature is enabled (see Section 7 for how RM gets enabled). The rules for doing this are analogous to the ones given above for the Router-LSA. 🌈

7. Operational Guidelines 🍓

The signaled RM doesn't change the OSPF metric parameters stored in a receiving router's persistent provisioning database. Your saved config stays exactly as it is, bestie 🫶

Routers that receive an RM advertisement SHOULD log an event to notify system administration. This helps admins quickly find the node in the network that's advertising an OSPF metric or TE metric different from what's configured locally on the device. 🔍

When the link TE metric gets raised to the maximum value, whether because of the RM mechanism or by explicit user configuration, this SHOULD immediately trigger a CSPF (Constrained Shortest Path First) recalculation to move TE traffic away from that link. Moving the traffic off that link ASAP is the move 💀

An implementation MUST NOT signal RM to neighbors by default, and it MUST provide a configuration option to enable RM signaling on specific links. An implementation MUST NOT accept RM from its neighbors by default. An implementation MAY provide configuration to accept RM globally on the device or per area, but an implementation MUST support configuration to enable or disable acceptance of RM from neighbors on specific links. This is all to guard against inadvertent use of RM. 🙈

For the use case in Section 2.1, it is RECOMMENDED that the network operator limit the period during which the reverse metric mechanism is enabled to only the duration of a network maintenance window. ⭐

[RFC9129] specifies the base OSPF YANG data model. The required configuration and operational elements for this feature are expected to be introduced as an augmentation to this base OSPF YANG data model. 🌸

8. Backward Compatibility 🧁

The signaling in this document happens at a link-local level between the routers on that link. A router that doesn't support this specification would ignore the Reverse Metric and Reverse TE Metric LLS TLVs and wouldn't update its metric(s) in the other LSAs. So the behavior is the same as it was before this specification. Because of that, there are no backward compatibility issues or considerations you need to handle when implementing this specification. Zero drama ✨

9. IANA Considerations 📋

IANA has registered code points from the "Link Local Signalling TLV Identifiers (LLS Types)" registry in the "Open Shortest Path First (OSPF) Link Local Signalling (LLS) - Type/Length/Value Identifiers (TLV)" registry group for the TLVs introduced in this document, like this:

  • 19 - Reverse Metric TLV
  • 20 - Reverse TE Metric TLV

10. Security Considerations 🚨

⚠️ Please read this section carefully, it's serious business!

The security considerations for "OSPF Link-Local Signaling" [RFC5613] also apply to the extension described in this document. The whole point of the reverse metric TLVs is to change the metrics routers on the link use, and to influence how traffic flows and gets routed across the network. So modifying the Reverse Metric and Reverse TE Metric TLVs may result in traffic being misrouted. If authentication is being used in the OSPFv2 routing domain [RFC5709][RFC7474], then the Cryptographic Authentication TLV [RFC5613] MUST also be used to protect the contents of the LLS block. 🔐

A router that's misbehaving or misconfigured might end up signaling varying RM values or toggling the state of RM. This can make a neighbor router have to update its Router LSA over and over, causing network churn and instability even with existing OSPF protocol mechanisms (for example, MinLSInterval, and [RFC8405]) in place. It is RECOMMENDED that implementations support detecting frequent changes in RM signaling and ignore the RM (in other words, revert to using their provisioned metric value) during such conditions. 💜

Receiving malformed LLS TLVs or sub-TLVs SHOULD be logged, but that logging MUST be rate-limited to prevent Denial of Service (DoS) attacks. 🛡️

11. References 📚

11.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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328,
              DOI 10.17487/RFC2328, April 1998,
              <https://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,
              <https://www.rfc-editor.org/info/rfc3630>.

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

   [RFC5613]  Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D.
              Yeung, "OSPF Link-Local Signaling", RFC 5613,
              DOI 10.17487/RFC5613, August 2009,
              <https://www.rfc-editor.org/info/rfc5613>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

11.2. Informative References

okay these are the extra-credit reads, bestie 📚🎀 not required but they're giving context and I'm obsessed with all of them:

Acknowledgements

The authors wanted to give a massive shoutout to the people who helped make this happen 🫶💖

  • Jay Karthik for his contributions to the use cases and the review of the solution. ✨
  • Les Ginsberg, Aijun Wang, Gyan Mishra, Matthew Bocci, Thomas Fossati, and Steve Hanna for their review and feedback. 🙌
  • Acee Lindem for a detailed shepherd's review and comments. 🔍
  • John Scudder for his detailed AD review and suggestions for improvement. 👑

The document leverages the concept of RM for IS-IS, its related use cases, and applicability aspects from [RFC8500]. It's giving "built on the shoulders of giants" energy 🦋

Authors' Addresses

These are the squad members who wrote it, bestie. Slide into their inboxes if you have questions 💌

Ketan Talaulikar (editor)
Cisco Systems, Inc.
India
Email: ketant.ietf@gmail.com
Peter Psenak
Cisco Systems, Inc.
Apollo Business Center
Mlynske nivy 43
821 09 Bratislava
Slovakia
Email: ppsenak@cisco.com
Hugh Johnston
AT&T Labs
United States of America
Email: hugh.johnston@att.com
📦 where this page comes from