idnits 2.17.1 draft-ietf-ospf-rfc3137bis-03.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 draft header indicates that this document obsoletes RFC3137, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 17, 2013) is 4117 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) Summary: 0 errors (**), 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: July 21, 2013 Cinarra Systems 7 R. White 8 D. McPherson 9 Verisign, Inc. 10 January 17, 2013 12 OSPF Stub Router Advertisement 13 draft-ietf-ospf-rfc3137bis-03 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 unavailability to forward transit traffic or to lower the preference 20 level for the paths through such a router. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on July 21, 2013. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. OSPFv3-only Solution . . . . . . . . . . . . . . . . . . . 4 59 3. Maximum Link Metric . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Deployment Considerations . . . . . . . . . . . . . . . . . . . 4 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 63 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 64 8. Informative References . . . . . . . . . . . . . . . . . . . . 5 65 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . . 5 66 A.1. Changes between the -00 and -01 versions. . . . . . . . . . 5 67 A.2. Changes between the -01 and -02 versions. . . . . . . . . . 6 68 A.3. Changes between the -02 and -03 versions. . . . . . . . . . 6 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 71 1. Introduction 73 In some situations, it may be advantageous to inform routers in a 74 network not to use a specific router as a transit point, but still 75 route to it. Possible situations include the following: 77 o The router is in a critical condition (for example, has very high 78 CPU load or does not have enough memory to store all LSAs or build 79 the routing table). 81 o Graceful introduction and removal of the router to/from the 82 network. 84 o Other (administrative or traffic engineering) reasons. 86 Note that the solution introduced in this document does not remove 87 the router from the topology view of the network (as could be done by 88 just flushing that router's router-LSA), but discourages other 89 routers from using it for transit routing, while still routing 90 packets to the router's own IP addresses, i.e., the router is 91 announced as a stub. 93 It must be emphasized that the solution provides real benefits in 94 networks designed with at least some level of redundancy so that 95 traffic can be routed around the stub router. Otherwise, traffic 96 destined for the networks reachable through such a stub router may 97 still be routed through it. 99 2. Solutions 101 The solution introduced in this document solves two challenges 102 associated with the outlined problem. In the description below, 103 router X is the router announcing itself as a stub. 105 1) Making other routers prefer routes around router X while 106 performing the Dijkstra calculation. 108 2) Allowing other routers to reach IP prefixes directly connected to 109 router X. 111 Note that it would be easy to address issue 1) alone by just flushing 112 router X's router-LSA from the domain. However, it does not solve 113 problem 2), since other routers will not be able to use links to 114 router X in Dijkstra (no back link), and because router X will not 115 have links to its neighbors. 117 To address both problems, router X announces its router-LSA to the 118 neighbors with the costs of all non-stub links (links of the types 119 other than 3) set to MaxLinkMetric. 121 The solution above applies to both OSPFv2 [RFC2328] and OSPFv3 122 [RFC5340]. 124 2.1. OSPFv3-only Solution 126 OSPFv3 [RFC5340] introduced additional options to provide similar, if 127 not better, control of the forwarding topology; the R-bit provides a 128 more granular indication of whether a router is active and should be 129 used for transit traffic. 131 It is left to network operators to decide which technique to use in 132 their network. 134 3. Maximum Link Metric 136 Section 2 refers to the cost of all non-stub links as MaxLinkMetric, 137 which is a new fixed architectural value introduced in this document. 139 MaxLinkMetric 140 The metric value indicating that the link described by an LSA 141 should not be used as transit. Used in router-LSAs (see 142 Section 2). It is defined to be the 16-bit binary value of all 143 ones: 0xffff. 145 4. Deployment Considerations 147 When using MaxLinkMetric, some inconsistency may be seen if the 148 network is constructed of routers that perform intra-area Dijkstra 149 calculation as specified in [RFC1247] (discarding link records in 150 router-LSAs that have a MaxLinkMetric cost value) and routers that 151 perform it as specified in [RFC1583] and higher (do not treat links 152 with MaxLinkMetric cost as unreachable). Note that this 153 inconsistency will not lead to routing loops, because if there are 154 some alternate paths in the network, both types of routers will agree 155 on using them rather than the path through the stub router. If the 156 path through the stub router is the only one, the routers of the 157 first type will not use the stub router for transit (which is the 158 desired behavior), while the routers of the second type will still 159 use this path. 161 On the other hand, clearing the R-bit will consistently result in the 162 router not being used as transit. 164 5. Security Considerations 166 The technique described in this document does not introduce any new 167 security issues into the OSPF protocol. 169 6. IANA Considerations 171 This document has no actions for IANA. 173 7. Acknowledgements 175 The authors of this document do not make any claims on the 176 originality of the ideas described. Among other people, we would 177 like to acknowledge Henk Smit for being part of one of the initial 178 discussions around this topic. 180 We would also like to thank Shishio Tsuchiya, Gunter Van de Velde, 181 Tomohiro Yamagata, Faraz Shamim and Acee Lindem who provided 182 significant input for the latest version of this document. 184 8. Informative References 186 [RFC1247] Moy, J., "OSPF Version 2", RFC 1247, July 1991. 188 [RFC1583] Moy, J., "OSPF Version 2", RFC 1583, March 1994. 190 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 192 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 193 for IPv6", RFC 5340, July 2008. 195 Appendix A. Change Log 197 A.1. Changes between the -00 and -01 versions. 199 o Defined a new architectural constant (MaxLinkMetric) to eliminate 200 any confusion about the interpretation of LSInfinity. 202 o Added a section to reference the R-bit and V6-bit in OSPFv3. 204 o Updated acks and contact information. 206 A.2. Changes between the -01 and -02 versions. 208 o Took out references to not having a standard solution and 209 incorporated the R-bit solution as part of the (renamed) 210 "Solutions" section. 212 o Various minor edits and reordered sections. 214 A.3. Changes between the -02 and -03 versions. 216 o Updated contact information. 218 o Renamed the 'Motivation' section to 'Introduction' becuase of an 219 error in idnits. 221 o Took out the rfc2119 references as none of the keywords are used 222 in the text. 224 o Added an 'IANA Considerations' section to indicate that there are 225 no actions required. 227 Authors' Addresses 229 Alvaro Retana 230 Cisco Systems, Inc. 231 7025 Kit Creek Rd. 232 Research Triangle Park, NC 27709 233 USA 235 Email: aretana@cisco.com 237 Liem Nguyen 238 Cisco Systems, Inc. 239 3750 Cisco Way 240 San Jose, CA 95134 241 USA 243 Email: lhnguyen@cisco.com 244 Alex Zinin 245 Cinarra Systems 246 Menlo Park, CA 247 USA 249 Email: alex.zinin@gmail.com 251 Russ White 252 Verisign, Inc. 253 12061 Bluemont Way 254 Reston, VA 20190 255 USA 257 Email: riwhite@verisign.com 259 Danny McPherson 260 Verisign, Inc. 261 21345 Ridgetop Circle 262 Dulles, VA 20166 263 USA 265 Email: dmcpherson@verisign.com