Network Working Group                                      Alvaro Retana
Internet Draft                                               Liem Nguyen
Expiration Date: March 2001                                   Russ White
File name: draft-ietf-ospf-stub-adv-00.txt                    Alex Zinin
                                                           Cisco Systems
                                                         Danny McPherson
                                                          Amber Networks
                                                          September 2000

                     OSPF Stub Router Advertisement

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet Drafts are working documents of the Internet Engineering
   Task Force (IETF), its Areas, and its Working Groups. Note that other
   groups may also distribute working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months. Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time. It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a "working
   draft" or "work in progress".

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at


   In some cases, it is desirable not to route transit traffic via a
   specific OSPF router.  However, OSPF [RFC2328] does not specify a
   standard way to accomplish this. This memo describes a backward-
   compatible technique that may be used by OSPF implementations to
   advertise unavailability to forward transit traffic or to lower the
   preference level for the paths through such a router in order to
   discourage transit traffic from entering the router.

   The mechanism proposed here requires no OSPF protocol changes and is
   completely interoperable with the existing OSPF specification.

Retana, Nguyen, White, McPherson, Zinin                         [Page 1]

INTERNET DRAFT       OSPF Stub Router Advertisement            July 2000

1 Motivation

   In some situations, it may be advantageous to inform routers in a
   network not to use a specific router as a transit point, but still
   route to it. Possible situations include the following:

       o    The router is in a critical condition (e.g., has very high
            CPU load or does not have enough memory to store all LSAs or
            build the routing table).

       o    Graceful introduction and removal of the router to/from the

       o    Other (administrative or traffic engineering) reasons.

   Note that the proposed solution does not remove the router from the
   topology view of the network (as could be done by just flushing that
   router's router-LSA), but discourages other routers from using it for
   transit routing, while still forwarding packets to router's own IP
   addresses (i.e., the router is announced as a non-forwarding, or
   overloaded router, to borrow a term from the IS-IS protocol).

   It must be emphasized that the proposed solution provides real bene-
   fits in networks designed with at least some level of redundancy so
   that traffic can be routed around the non-forwarding (or overloaded)
   router. Otherwise, traffic destined for the networks reachable
   through such a stub router will either be still routed through it or
   black-holed (see Section 4 for more details).

2 Proposed Solution

   The solution described in this document solves three challenges asso-
   ciated with the outlined problem. In the description below, router X
   is the router announcing itself as a stub.

      1)   Making other routers prefer routes around router X when per-
           forming the Dijkstra calculation.

      2)   Allowing other routers to reach IP prefixes directly con-
           nected to router X.

      3)   Allowing router X itself to use its links to reach remote
           routers and destinations.

Retana, Nguyen, White, McPherson, Zinin                         [Page 2]

INTERNET DRAFT       OSPF Stub Router Advertisement            July 2000

   Note that it would be easy to address issue 1) alone by just flushing
   router X's router-LSA from the domain. However, it does not solve
   problems 2) and 3), since other routers will not be able to use links
   to router X in Dijkstra (no backup link), and because router X will
   not have links to its neighbors.

   To address all three problems, router X announces its router-LSA to
   the neighbors as follows.

      o    Costs of all non-stub links (links which are not type 3) are
           set to LSInfinity (16-bit value 0xFFFF, rather than 24-bit
           value 0xFFFFFF used in summary and AS-external LSAs).

      o    Costs of stub links (type 3) are set to the interface output

   This addresses issues 1) and 2). To address issue 3), router X must
   use real link costs in its Dijkstra calculation. This will allow it
   to use its links to reach remote routers.

3 Implementation details

   To simplify the implementation of the described technique, it may be
   useful for  OSPF routers to keep two versions of their router-LSAs.
   One version (public) is installed in the LSDB and sent to the neigh-
   bors, while another version (internal) is used for local routing
   table calculation. When the router announces itself as stub, it con-
   structs the public version as indicated in Section 2, but the inter-
   nal version is constructed as in standard OSPF [RFC2328]. When the
   router does not announce itself as stub, both versions are con-
   structed as in standard OSPF and would both yield the same result,
   hence it is not necessary (though acceptable) to keep two versions of
   the LSAs at this point.

4 Compatibility issues

   Some inconsistency may be seen when the network is constructed of the
   routers that perform intra-area Dijkstra calculation as specified in
   [RFC1247] (discarding link records in router-LSAs that have LSInfin-
   ity cost value) and routers that perform it as specified in [RFC1583]
   and higher (do not treat links with LSInfinity cost as unreachable).
   Note that this inconsistency will not lead to routing loops, because
   if there are some alternate paths in the network, both types of
   routers will agree on using them rather than the path through the
   non-forwarding router. If the path through the non-forwarding router
   is the only available path, the routers of the first type will not
   use it for transit (which is the desired behavior), while the routers

Retana, Nguyen, White, McPherson, Zinin                         [Page 3]

INTERNET DRAFT       OSPF Stub Router Advertisement            July 2000

   of the second type will still use this path.

Deployment Considerations

   Such a mechanism increases overall network availablity and allows
   network operators to alleviate the deterministic blackholing behavoir
   introduced in this scenario.  The IS-IS Overload Bit [ISO10589] has
   been employed in IS-IS routing domains to achieve similar behavior.

   Triggers for setting the link costs as described are left to the
   implementor.  Some potential triggers could include N seconds after
   booting, or N number of BGP prefixes in the BGP Loc-RIB.

   Also, understand that this mechanism assumes actual deployments
   assign substantially lower values for link costs (and the sum of sub-
   sequent path costs), and that a value of 0xFFFF for an individual
   link within a path would be sufficiently large enough to discourage
   transit traffic from entering the router.

5 Acknowledgements

   The authors of this document do not make any claims on the original-
   ity of the ideas described.  Among other people, we would like to
   acknowledge Henk Smit for being part of one of the initial discus-
   sions around this topic and Alex Zinin for his work on this draft as

6 Security Considerations

   The technique described in this document does not introduce any new
   security issues into OSPF protocol.

7 References

     [RFC1247]  J. Moy. OSPF version 2. RFC 1247, July 1991

     [RFC1583]  J. Moy. OSPF version 2. RFC 1583, March 1994

     [RFC2328]  J. Moy. OSPF version 2. Technical Report RFC 2328,
                April 1998

     [ISO10589] "Intermediate System to Intermediate System Intra-

Retana, Nguyen, White, McPherson, Zinin                         [Page 4]

INTERNET DRAFT       OSPF Stub Router Advertisement            July 2000

                Domain Routeing Exchange Protocol for use in
                Conjunction with the Protocol for Providing the
                Connectionless-mode Network Service (ISO 8473)",
                ISO DP 10589, February 1990.

8 Authors' Addresses

   Alvaro Retana                      Liem Nguyen
   7025 Kit Creek Rd.                 7025 Kit Creek Rd.
   Research Triangle Park, NC 27709   Research Triangle Park, NC 27709
   USA                                USA
   e-mail:          e-mail:

   Russ White                         Danny McPherson
   Cisco Systems, Inc.                Amber Networks, Inc.
   7025 Kit Creek Rd.                 2465 Augustine Drive
   Research Triangle Park, NC 27709   Santa Clara, CA  95054
   e-mail:              e-mail:

   Alex Zinin
   Cisco Systems, Inc.
   170 W. Tasman Dr.
   San Jose, CA 95134

Retana, Nguyen, White, McPherson, Zinin                         [Page 5]