idnits 2.17.1 draft-ietf-ospf-stub-adv-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC2328]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (November 2000) is 8561 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) ** Obsolete normative reference: RFC 1247 (Obsoleted by RFC 1583) ** Obsolete normative reference: RFC 1583 (Obsoleted by RFC 2178) Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Alvaro Retana 2 Internet Draft Liem Nguyen 3 Expiration Date: May 2001 Russ White 4 File name: draft-ietf-ospf-stub-adv-01.txt Alex Zinin 5 Cisco Systems 6 Danny McPherson 7 Amber Networks 8 November 2000 10 OSPF Stub Router Advertisement 11 draft-ietf-ospf-stub-adv-01.txt 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its Areas, and its Working Groups. Note that other 20 groups may also distribute working documents as Internet Drafts. 22 Internet Drafts are draft documents valid for a maximum of six 23 months. Internet Drafts may be updated, replaced, or obsoleted by 24 other documents at any time. It is not appropriate to use Internet 25 Drafts as reference material or to cite them other than as a "working 26 draft" or "work in progress". 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 In some cases, it is desirable not to route transit traffic via a 37 specific OSPF router. However, OSPF [RFC2328] does not specify a 38 standard way to accomplish this. This memo describes a backward- 39 compatible technique that may be used by OSPF implementations to 40 advertise unavailability to forward transit traffic or to lower the 41 preference level for the paths through such a router. 43 1 Motivation 44 In some situations, it may be advantageous to inform routers in a 45 network not to use a specific router as a transit point, but still 46 route to it. Possible situations include the following. 48 o The router is in a critical condition (for example, has very 49 high CPU load or does not have enough memory to store all 50 LSAs or build the routing table). 52 o Graceful introduction and removal of the router to/from the 53 network. 55 o Other (administrative or traffic engineering) reasons. 57 Note that the proposed solution does not remove the router from the 58 topology view of the network (as could be done by just flushing that 59 router's router-LSA), but prevents other routers from using it for 60 transit routing, while still routing packets to router's own IP 61 addresses, i.e., the router is announced as stub. 63 It must be emphasized that the proposed solution provides real bene- 64 fits in networks designed with at least some level of redundancy so 65 that traffic can be routed around the stub router. Otherwise, traffic 66 destined for the networks reachable through such a stub router will 67 either be still routed through it. 69 2 Proposed Solution 71 The solution described in this document solves two challenges associ- 72 ated with the outlined problem. In the description below, router X is 73 the router announcing itself as a stub. 75 1) Making other routers prefer routes around router X while per- 76 forming the Dijkstra calculation. 78 2) Allowing other routers to reach IP prefixes directly con- 79 nected to router X 81 Note that it would be easy to address issue 1) alone by just flushing 82 router X's router-LSA from the domain. However, it does not solve 83 problem 2), since other routers will not be able to use links to 84 router X in Dijkstra (no back link), and because router X will not 85 have links to its neighbors. 87 To address both problems, router X announces its router-LSA to the 88 neighbors as follows. 90 o costs of all non-stub links (links of the types other than 3) 91 are set to LSInfinity (16-bit value 0xFFFF, rather than 24- 92 bit value 0xFFFFFF used in summary and AS-external LSAs). 94 o costs of stub links (type 3) are set to the interface output 95 cost. 97 This addresses issues 1) and 2). 99 3 Implementation details 101 To simplify the implementation of the described technique, it may be 102 useful for OSPF routers to keep two versions of their router-LSAs. 103 One version (public) is installed in the LSDB and sent to the neigh- 104 bors, while another version (internal) is used for local routing 105 table calculation. When the router announces itself as stub, it con- 106 structs the public version as indicated in Section 2, but the inter- 107 nal version is constructed as in standard OSPF [RFC2328]. When the 108 router does not announce itself as stub, both versions are con- 109 structed as in standard OSPF and would both yield the same result, 110 hence it is not necessary (though acceptable) to keep two versions of 111 the LSAs at this point. 113 4 Compatibility issues 115 Some inconsistency may be seen when the network is constructed of the 116 routers that perform intra-area Dijkstra calculation as specified in 117 [RFC1247] (discarding link records in router-LSAs that have LSInfin- 118 ity cost value) and routers that perform it as specified in [RFC1583] 119 and higher (do not treat links with LSInfinity cost as unreachable). 120 Note that this inconsistency will not lead to routing loops, because 121 if there are some alternate paths in the network, both types of 122 routers will agree on using them rather than the path through the 123 stub router. If the path through the stub router is the only one, the 124 routers of the first type will not use the stub router for transit 125 (which is the desired behavior), while the routers of the second type 126 will still use this path. 128 5 Acknowledgements 130 The authors of this document do not make any claims on the original- 131 ity of the ideas described. Among other people, we would like to 132 acknowledge Henk Smit for being part of one of the initial discus- 133 sions around this topic. 135 6 Security Considerations 136 The technique described in this document does not introduce any new 137 security issues into OSPF protocol. 139 7 References 141 [RFC2328] 142 J. Moy. OSPF version 2. Technical Report RFC 2328, 143 Internet Engineering Task Force, 1998. 144 ftp://ftp.isi.edu/in-notes/rfc2328.txt. 146 [RFC1247] 147 J. Moy. OSPF version 2. RFC 1247, 148 Internet Engineering Task Force, 1991. 149 ftp://ftp.isi.edu/in-notes/rfc1247.txt. 151 [RFC1583] 152 J. Moy. OSPF version 2. RFC 1583, 153 Internet Engineering Task Force, 1994. 154 ftp://ftp.isi.edu/in-notes/rfc1583.txt. 156 8 Authors' addresses 158 Alvaro Retana 159 7025 Kit Creek Rd. 160 Research Triangle Park, NC 27709 161 USA 162 e-mail: aretana@cisco.com 164 Liem Nguyen 165 7025 Kit Creek Rd. 166 Research Triangle Park, NC 27709 167 USA 168 e-mail: lhnguyen@cisco.com 170 Russ White 171 Cisco Systems, Inc. 172 7025 Kit Creek Rd. 173 Research Triangle Park, NC 27709 174 e-mail: riw@cisco.com 176 Alex D. Zinin 177 Cisco Systems 178 150 West Tasman Dr. 179 San Jose,CA 95134 180 E-mail: azinin@cisco.com 182 Danny McPherson 183 Amber Networks 184 2465 Augustine Drive 185 Santa Clara, CA 95054 186 e-mail: danny@ambernetworks.com