idnits 2.17.1 draft-zinin-ospf-stub-adv-00.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 3 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 4 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 (July 2000) is 8687 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 Alex Zinin 2 Internet Draft Alvaro Retana 3 Expiration Date: January 2001 Liem Nguyen 4 File name: draft-zinin-ospf-stub-adv-00.txt Russ White 5 Cisco Systems 6 July 2000 8 OSPF Stub Router Advertisement 9 draft-zinin-ospf-stub-adv-00.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its Areas, and its Working Groups. Note that other 18 groups may also distribute working documents as Internet Drafts. 20 Internet Drafts are draft documents valid for a maximum of six 21 months. Internet Drafts may be updated, replaced, or obsoleted by 22 other documents at any time. It is not appropriate to use Internet 23 Drafts as reference material or to cite them other than as a "working 24 draft" or "work in progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 In some cases, it is desirable not to route transit traffic via a 35 specific OSPF router. However, OSPF [RFC2328] does not specify a 36 standard way to accomplish this. This memo describes a backward- 37 compatible technique that may be used by OSPF implementations to 38 advertise unavailability to forward transit traffic or to lower the 39 preference level for the paths through such a router. 41 1 Motivation 43 In some situations, it may be advantageous to inform routers in a 44 network not to use a specific router as a transit point, but still 45 route to it. Possible situations include the following. 47 o The router is in a critical condition (for example, has very 48 high CPU load or does not have enough memory to store all 49 LSAs or build the routing table). 51 o Graceful introduction and removal of the router to/from the 52 network. 54 o Other (administrative or traffic engineering) reasons. 56 Note that the proposed solution does not remove the router from the 57 topology view of the network (as could be done by just flushing that 58 router's router-LSA), but prevents other routers from using it for 59 transit routing, while still routing packets to router's own IP 60 addresses, i.e., the router is announced as stub. 62 It must be emphasized that the proposed solution provides real bene- 63 fits in networks designed with at least some level of redundancy so 64 that traffic can be routed around the stub router. Otherwise, traffic 65 destined for the networks reachable through such a stub router will 66 either be still routed through it or black-holed (see Section 4 for 67 more details). 69 2 Proposed Solution 71 The solution described in this document solves three challenges asso- 72 ciated with the outlined problem. In the description below, router X 73 is 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 3) Allowing router X itself to use its links to reach remote 82 routers and destinations. 84 Note that it would be easy to address issue 1) alone by just flushing 85 router X's router-LSA from the domain. However, it does not solve 86 problems 2) and 3), since other routers will not be able to use links 87 to router X in Dijkstra (no back link), and because router X will not 88 have links to its neighbors. 90 To address all three problems, router X announces its router-LSA to 91 the neighbors as follows. 93 o costs of all non-stub links (links of the types other than 3) 94 are set to LSInfinity (16-bit value 0xFFFF, rather than 24- 95 bit value 0xFFFFFF used in summary and AS-external LSAs). 97 o costs of stub links (type 3) are set to the interface output 98 cost. 100 This addresses issues 1) and 2). To address issue 3), router X must 101 use real link costs in its Dijkstra calculation. This will allow it 102 to use its links to reach remote routers. 104 3 Implementation details 106 To simplify the implementation of the described technique, it may be 107 useful for OSPF routers to keep two versions of their router-LSAs. 108 One version (public) is installed in the LSDB and sent to the neigh- 109 bors, while another version (internal) is used for local routing 110 table calculation. When the router announces itself as stub, it con- 111 structs the public version as indicated in Section 2, but the inter- 112 nal version is constructed as in standard OSPF [RFC2328]. When the 113 router does not announce itself as stub, both versions are con- 114 structed as in standard OSPF and would both yield the same result, 115 hence it is not necessary (though acceptable) to keep two versions of 116 the LSAs at this point. 118 4 Compatibility issues 120 Some inconsistency may be seen when the network is constructed of the 121 routers that perform intra-area Dijkstra calculation as specified in 122 [RFC1247] (discarding link records in router-LSAs that have LSInfin- 123 ity cost value) and routers that perform it as specified in [RFC1583] 124 and higher (do not treat links with LSInfinity cost as unreachable). 125 Note that this inconsistency will not lead to routing loops, because 126 if there are some alternate paths in the network, both types of 127 routers will agree on using them rather than the path through the 128 stub router. If the path through the stub router is the only one, the 129 routers of the first type will not use the stub router for transit 130 (which is the desired behavior), while the routers of the second type 131 will still use this path. 133 5 Acknowledgements 135 The authors of this document do not make any claims on the original- 136 ity of the ideas described. Among other people, we would like to 137 acknowledge Henk Smit for being part of one of the initial 138 discussions around this topic. 140 6 Security Considerations 142 The technique described in this document does not introduce any new 143 security issues into OSPF protocol. 145 7 References 147 [RFC2328] 148 J. Moy. OSPF version 2. Technical Report RFC 2328, 149 Internet Engineering Task Force, 1998. 150 ftp://ftp.isi.edu/in-notes/rfc2328.txt. 152 [RFC1247] 153 J. Moy. OSPF version 2. RFC 1247, 154 Internet Engineering Task Force, 1991. 155 ftp://ftp.isi.edu/in-notes/rfc1247.txt. 157 [RFC1583] 158 J. Moy. OSPF version 2. RFC 1583, 159 Internet Engineering Task Force, 1994. 160 ftp://ftp.isi.edu/in-notes/rfc1583.txt. 162 8 Authors' addresses 164 Alex D. Zinin Liem Nguyen 165 Cisco Systems 7025 Kit Creek Rd. 166 150 West Tasman Dr. Research Triangle Park, NC 27709 167 San Jose,CA 95134 USA 168 E-mail: azinin@cisco.com e-mail: lhnguyen@cisco.com 170 Alvaro Retana Russ White 171 7025 Kit Creek Rd. Cisco Systems, Inc. 172 Research Triangle Park, NC 27709 7025 Kit Creek Rd. 173 USA Research Triangle Park, NC 27709 174 e-mail: aretana@cisco.com e-mail: riw@cisco.com