idnits 2.17.1 draft-ietf-ospf-rfc3137bis-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3137]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 23, 2013) is 4020 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 1247 (Obsoleted by RFC 1583) -- Obsolete informational reference (is this intentional?): RFC 1583 (Obsoleted by RFC 2178) -- Obsolete informational reference (is this intentional?): RFC 3137 (Obsoleted by RFC 6987) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Retana 3 Internet-Draft L. Nguyen 4 Obsoletes: 3137 (if approved) Cisco Systems, Inc. 5 Intended status: Informational A. Zinin 6 Expires: October 25, 2013 Cinarra Systems 7 R. White 8 D. McPherson 9 Verisign, Inc. 10 April 23, 2013 12 OSPF Stub Router Advertisement 13 draft-ietf-ospf-rfc3137bis-04 15 Abstract 17 This document describes a backward-compatible technique that may be 18 used by OSPF (Open Shortest Path First) implementations to advertise 19 a router's unavailability to forward transit traffic, or to lower the 20 preference level for the paths through such a router. 22 This document obsoletes [RFC3137]. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on October 25, 2013. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.1. OSPFv3-only Solution . . . . . . . . . . . . . . . . . . 3 61 3. Maximum Link Metric . . . . . . . . . . . . . . . . . . . . . 4 62 4. Deployment Considerations . . . . . . . . . . . . . . . . . . 4 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 68 8.2. Informative References . . . . . . . . . . . . . . . . . 5 69 Appendix A. Changes from RFC3137 . . . . . . . . . . . . . . . . 5 70 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 5 71 B.1. Changes between the -00 and -01 versions. . . . . . . . . 6 72 B.2. Changes between the -01 and -02 versions. . . . . . . . . 6 73 B.3. Changes between the -02 and -03 versions. . . . . . . . . 6 74 B.4. Changes between the -03 and -04 versions . . . . . . . . 6 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 77 1. Introduction 79 In some situations, it may be advantageous to inform routers in a 80 network not to use a specific router as a transit point, but still 81 route to it. Possible situations include the following: 83 o The router is in a critical condition (for example, has very high 84 CPU load or does not have enough memory to store all Link State 85 Advertisements (LSAs) or build the routing table). 87 o Graceful introduction and removal of the router to/from the 88 network. 90 o Other (administrative or traffic engineering) reasons. 92 Note that the solution introduced in this document does not remove 93 the router from the topology view of the network (as could be done by 94 just flushing that router's router-LSA), but discourages other 95 routers from using it for transit routing, while still routing 96 packets to the router's own IP addresses, i.e., the router is 97 announced as a stub. 99 It must be emphasized that the solution provides real benefits in 100 networks designed with at least some level of redundancy so that 101 traffic can be routed around the stub router. Otherwise, traffic 102 destined for the networks reachable through such a stub router may 103 still be routed through it. 105 2. Solutions 107 The solution introduced in this document solves two challenges 108 associated with the outlined problem. In the description below, 109 router X is the router announcing itself as a stub. 111 1) Making other routers prefer routes around router X while 112 performing the Dijkstra calculation. 114 2) Allowing other routers to reach IP prefixes directly connected to 115 router X. 117 Note that it would be easy to address issue 1) alone by just flushing 118 router X's router-LSA from the domain. However, it does not solve 119 problem 2), since other routers will not be able to use links to 120 router X in Dijkstra (no back link), and because router X will not 121 have links to its neighbors. 123 To address both problems, router X announces its router-LSA to the 124 neighbors with the costs of all non-stub links (links of the types 125 other than 3) set to MaxLinkMetric (defined in Section 3). 127 The solution above applies to both OSPFv2 [RFC2328] and OSPFv3 128 [RFC5340]. 130 2.1. OSPFv3-only Solution 132 OSPFv3 [RFC5340] introduced additional options to provide similar 133 control of the forwarding topology; the R-bit provides an indication 134 of whether a router is active and should be used for transit traffic. 136 It is left to network operators to decide which technique to use in 137 their network. See Section 4 for more details. 139 3. Maximum Link Metric 141 Section 2 refers to the cost of all non-stub links as MaxLinkMetric, 142 which is a new fixed architectural value introduced in this document. 144 MaxLinkMetric 145 The metric value indicating that the link described by an LSA 146 should not be used as transit. Used in router-LSAs (see 147 Section 2). It is defined to be the 16-bit binary value of all 148 ones: 0xffff. 150 4. Deployment Considerations 152 When using MaxLinkMetric, some inconsistency may be seen if the 153 network is constructed of routers that perform intra-area Dijkstra 154 calculation as specified in [RFC1247] (discarding link records in 155 router-LSAs that have a MaxLinkMetric cost value) and routers that 156 perform it as specified in [RFC1583] and higher (do not treat links 157 with MaxLinkMetric cost as unreachable). Note that this 158 inconsistency will not lead to routing loops, because if there are 159 some alternate paths in the network, both types of routers will agree 160 on using them rather than the path through the stub router. If the 161 path through the stub router is the only one, the routers of the 162 first type will not use the stub router for transit (which is the 163 desired behavior), while the routers of the second type will still 164 use this path. 166 On the other hand, clearing the R-bit will consistently result in the 167 router not being used as transit. 169 The use of MaxLinkMetric or the R-bit in a network depends on the 170 objectives of the operator. One of the possible considerations for 171 selecting one or the other is in the desired behavior if the path 172 through the stub router is the only one available. Using 173 MaxLinkMetric allows for that path to be used, while the R-bit 174 doesn't. 176 5. Security Considerations 178 The technique described in this document does not introduce any new 179 security issues into the OSPF protocol. 181 6. IANA Considerations 183 This document has no actions for IANA. 185 7. Acknowledgements 186 The authors of this document do not make any claims on the 187 originality of the ideas described. Among other people, we would 188 like to acknowledge Henk Smit for being part of one of the initial 189 discussions around this topic. 191 We would like to thank Shishio Tsuchiya, Gunter Van de Velde, 192 Tomohiro Yamagata, Faraz Shamim and Acee Lindem who provided 193 significant input for the latest version of this document. Dave 194 Cridland and Tom Yu also provided valuable comments. 196 8. References 198 8.1. Normative References 200 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 202 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 203 for IPv6", RFC 5340, July 2008. 205 8.2. Informative References 207 [RFC1247] Moy, J., "OSPF Version 2", RFC 1247, July 1991. 209 [RFC1583] Moy, J., "OSPF Version 2", RFC 1583, March 1994. 211 [RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D. 212 McPherson, "OSPF Stub Router Advertisement", RFC 3137, 213 June 2001. 215 Appendix A. Changes from RFC3137 217 This document obsoletes [RFC3137]. 219 In addition to editorial updates, this documents defines a new 220 architectural constant (MaxLinkMetric in Section 3) to eliminate any 221 confusion about the interpretation of LSInfinity. It also 222 incorporates and explains the use of the R-bit [RFC5340] as a 223 solution to the problem addressed in the text. 225 Appendix B. Change Log 227 This section should be removed by the RFC Editor before publication. 229 B.1. Changes between the -00 and -01 versions. 231 o Defined a new architectural constant (MaxLinkMetric) to eliminate 232 any confusion about the interpretation of LSInfinity. 234 o Added a section to reference the R-bit and V6-bit in OSPFv3. 236 o Updated acks and contact information. 238 B.2. Changes between the -01 and -02 versions. 240 o Took out references to not having a standard solution and 241 incorporated the R-bit solution as part of the (renamed) 242 "Solutions" section. 244 o Various minor edits and reordered sections. 246 B.3. Changes between the -02 and -03 versions. 248 o Updated contact information. 250 o Renamed the 'Motivation' section to 'Introduction' becuase of an 251 error in idnits. 253 o Took out the rfc2119 references as none of the keywords are used 254 in the text. 256 o Added an 'IANA Considerations' section to indicate that there are 257 no actions required. 259 B.4. Changes between the -03 and -04 versions 261 o Clearly indicated in the text that this document obsoletes 262 RFC3137. 264 o Various minor edits. 266 o Clarified the use of the R-bit and included text in the 267 "Deployment Considerations" section about it. 269 o Updated acks. 271 o Ordered the References section to provide some Normative ones. 273 o Added an Appendix summarizing the changes form RFC3137. 275 Authors' Addresses 276 Alvaro Retana 277 Cisco Systems, Inc. 278 7025 Kit Creek Rd. 279 Research Triangle Park, NC 27709 280 USA 282 Email: aretana@cisco.com 284 Liem Nguyen 285 Cisco Systems, Inc. 286 3750 Cisco Way 287 San Jose, CA 95134 288 USA 290 Email: lhnguyen@cisco.com 292 Alex Zinin 293 Cinarra Systems 294 Menlo Park, CA 295 USA 297 Email: alex.zinin@gmail.com 299 Russ White 300 Verisign, Inc. 301 12061 Bluemont Way 302 Reston, VA 20190 303 USA 305 Email: riwhite@verisign.com 307 Danny McPherson 308 Verisign, Inc. 309 21345 Ridgetop Circle 310 Dulles, VA 20166 311 USA 313 Email: dmcpherson@verisign.com