RFC 3137

OSPF Stub Router Advertisement

📅 published June 2001, from ietf

OSPF Stub Router Advertisement 🦋

okay bestie, this is RFC 3137 💖 and it's an Informational doc, so it's sharing ideas, not setting a standard 🎀

  • Title: OSPF Stub Router Advertisement ✨
  • Date: June 2001 🍓
  • Category: Informational
  • Authors: Alvaro Retana, Liem Nguyen, and Russ White (Cisco Systems), Alex Zinin (Nexsi Systems), and Danny McPherson (Amber Networks) 👑
  • Obsoletes / Updates: the header doesn't list anything it obsoletes or updates 🫶

Status of this Memo 📜

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. 🌸

Copyright (C) The Internet Society (2001). All Rights Reserved.

Abstract 🧚

okay so this memo describes a backward-compatible technique that OSPF (Open Shortest Path First) implementations can use to announce that they're not available to forward transit traffic, or to lower the preference level for paths through that router 🦋 sometimes you just don't want traffic routed through a specific OSPF router, and ngl, OSPF doesn't have a standard way to do that yet 😭

1. Motivation 💅

so there are situations where it's advantageous to tell the other routers in a network not to use a specific router as a transit point, but still let them route to it ✨ possible reasons include:

  • the router is in a critical condition (like super high CPU load, or not enough memory to store all the LSAs or build the routing table) 💀
  • graceful introduction and removal of the router to and from the network 🌈
  • other administrative or traffic engineering reasons 🎀

the vibe here is that the proposed solution doesn't remove the router from the topology view of the network (which you could do by just flushing that router's router-LSA) 🙈 instead it stops other routers from using it for transit routing, while still routing packets to the router's own IP addresses. so the router gets announced as a stub 🧚

and bestie, this part is important: the solution gives real benefits only in networks with at least some redundancy, so traffic can be routed around the stub router 🔥 otherwise, traffic headed for networks reachable through that stub router is still going to get routed through it 😭

2. Proposed Solution 👑

this solution solves two challenges that come with the problem above ✨ in the description below, router X is the router announcing itself as a stub 🦋

  1. making other routers prefer routes around router X while they do the Dijkstra calculation 💖
  2. letting other routers reach IP prefixes directly connected to router X 🫶

okay so here's the tea: it would be easy to handle issue 1) alone by flushing router X's router-LSA from the domain. but that doesn't solve problem 2), because other routers can't use links to router X in Dijkstra (there's no back link), and router X won't have links to its neighbors either 💀

so to fix both problems, router X announces its router-LSA to its neighbors like this 💅

  • the costs of all non-stub links (links of the types other than 3) are set to LSInfinity (the 16-bit value 0xFFFF, instead of the 24-bit value 0xFFFFFF used in summary and AS-external LSAs) 🌸
  • the costs of stub links (type 3) are set to the interface output cost 🍓

and that handles issues 1) and 2) 🎀 slay 💜

3. Compatibility issues ⚠️

heads up, this part is a little messy 😭

some inconsistency can show up when a network is built from routers doing the intra-area Dijkstra calculation as specified in [RFC1247] (which discards link records in router-LSAs that have an LSInfinity cost value), mixed with routers doing it as specified in [RFC1583] and higher (which don't treat links with LSInfinity cost as unreachable) 🦋 but ngl, it won't lead to routing loops. if there are alternate paths in the network, both types of routers agree to use them instead of the path through the stub router 🫶

the only real edge case is when the path through the stub router is the only one. then the first type of router won't use the stub router for transit (which is what we want!), but the second type will still use that path 🙈

4. Acknowledgements 🫶

the authors don't make any claims on the originality of the ideas here 🌈 big thanks to Henk Smit, who was part of one of the initial discussions around this topic 💖

5. Security Considerations 💀🔐

the technique described in this document does not introduce any new security issues into the OSPF protocol. Not one. Zero. Periodt 💅🔥

6. References 📚

7. Authors' Addresses 💌

Alvaro Retana
7025 Kit Creek Rd.
Research Triangle Park, NC 27709
USA

EMail: aretana@cisco.com


Liem Nguyen
7025 Kit Creek Rd.
Research Triangle Park, NC 27709
USA

EMail: lhnguyen@cisco.com


Russ White
Cisco Systems, Inc.
7025 Kit Creek Rd.
Research Triangle Park, NC 27709

EMail: riw@cisco.com


Alex Zinin
Nexsi Systems
1959 Concourse Drive
San Jose,CA 95131

EMail: azinin@nexsi.com


Danny McPherson
Amber Networks
48664 Milmont Drive
Fremont, CA 94538

EMail: danny@ambernetworks.com
Copyright (C) The Internet Society (2001).  All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works.  However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 🌷

funding for the RFC Editor function is currently provided by the Internet Society 💖✨

📦 where this page comes from