idnits 2.17.1 draft-ietf-ospf-rfc3137bis-02.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 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 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 16, 2012) is 4301 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: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Retana 3 Internet-Draft Hewlett-Packard Co. 4 Obsoletes: RFC3137 (if approved) L. Nguyen 5 Intended status: Informational A. Zinin 6 Expires: January 17, 2013 Cisco Systems, Inc. 7 R. White 8 D. McPherson 9 Verisign, Inc. 10 July 16, 2012 12 OSPF Stub Router Advertisement 13 draft-ietf-ospf-rfc3137bis-02 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 January 17, 2013. 39 Copyright Notice 41 Copyright (c) 2012 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. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 58 3. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3.1. OSPFv3-only Solution . . . . . . . . . . . . . . . . . . . 4 60 4. Maximum Link Metric . . . . . . . . . . . . . . . . . . . . . . 4 61 5. Deployment Considerations . . . . . . . . . . . . . . . . . . . 4 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 63 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 66 8.2. Informative References . . . . . . . . . . . . . . . . . . 5 67 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . . 6 68 A.1. Changes between the -00 and -01 versions. . . . . . . . . . 6 69 A.2. Changes between the -01 and -02 versions. . . . . . . . . . 6 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 72 1. Motivation 74 In some situations, it may be advantageous to inform routers in a 75 network not to use a specific router as a transit point, but still 76 route to it. Possible situations include the following: 78 o The router is in a critical condition (for example, has very high 79 CPU load or does not have enough memory to store all LSAs or build 80 the routing table). 82 o Graceful introduction and removal of the router to/from the 83 network. 85 o Other (administrative or traffic engineering) reasons. 87 Note that the solution introduced in this document does not remove 88 the router from the topology view of the network (as could be done by 89 just flushing that router's router-LSA), but discourages other 90 routers from using it for transit routing, while still routing 91 packets to the router's own IP addresses, i.e., the router is 92 announced as a stub. 94 It must be emphasized that the solution provides real benefits in 95 networks designed with at least some level of redundancy so that 96 traffic can be routed around the stub router. Otherwise, traffic 97 destined for the networks reachable through such a stub router may 98 still be routed through it. 100 2. Requirements Language 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC2119]. 106 3. Solutions 108 The solution introduced in this document solves two challenges 109 associated with the outlined problem. In the description below, 110 router X is the router announcing itself as a stub. 112 1) Making other routers prefer routes around router X while 113 performing the Dijkstra calculation. 115 2) Allowing other routers to reach IP prefixes directly connected to 116 router X. 118 Note that it would be easy to address issue 1) alone by just flushing 119 router X's router-LSA from the domain. However, it does not solve 120 problem 2), since other routers will not be able to use links to 121 router X in Dijkstra (no back link), and because router X will not 122 have links to its neighbors. 124 To address both problems, router X announces its router-LSA to the 125 neighbors with the costs of all non-stub links (links of the types 126 other than 3) set to MaxLinkMetric. 128 The solution above applies to both OSPFv2 [RFC2328] and OSPFv3 129 [RFC5340]. 131 3.1. OSPFv3-only Solution 133 OSPFv3 [RFC5340] introduced additional options to provide similar, if 134 not better, control of the forwarding topology; the R-bit provides a 135 more granular indication of whether a router is active and should be 136 used for transit traffic. 138 It is left to network operators to decide which technique to use in 139 their network. 141 4. Maximum Link Metric 143 Section 3 refers to the cost of all non-stub links as MaxLinkMetric, 144 which is a new fixed architectural value introduced in this document. 146 MaxLinkMetric 147 The metric value indicating that the link described by an LSA 148 should not be used as transit. Used in router-LSAs (see 149 Section 3). It is defined to be the 16-bit binary value of all 150 ones: 0xffff. 152 5. Deployment Considerations 154 When using MaxLinkMetric, some inconsistency may be seen if the 155 network is constructed of routers that perform intra-area Dijkstra 156 calculation as specified in [RFC1247] (discarding link records in 157 router-LSAs that have a MaxLinkMetric cost value) and routers that 158 perform it as specified in [RFC1583] and higher (do not treat links 159 with MaxLinkMetric cost as unreachable). Note that this 160 inconsistency will not lead to routing loops, because if there are 161 some alternate paths in the network, both types of routers will agree 162 on using them rather than the path through the stub router. If the 163 path through the stub router is the only one, the routers of the 164 first type will not use the stub router for transit (which is the 165 desired behavior), while the routers of the second type will still 166 use this path. 168 On the other hand, clearing the R-bit will consistently result in the 169 router not being used as transit. 171 6. Security Considerations 173 The technique described in this document does not introduce any new 174 security issues into the OSPF protocol. 176 7. Acknowledgements 178 The authors of this document do not make any claims on the 179 originality of the ideas described. Among other people, we would 180 like to acknowledge Henk Smit for being part of one of the initial 181 discussions around this topic. 183 We would also like to thank Shishio Tsuchiya, Gunter Van de Velde, 184 Tomohiro Yamagata, Faraz Shamim and Acee Lindem who provided 185 significant input for the latest version of this document. 187 8. References 189 8.1. Normative References 191 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 192 Requirement Levels", BCP 14, RFC 2119, March 1997. 194 8.2. Informative References 196 [RFC1247] Moy, J., "OSPF Version 2", RFC 1247, July 1991. 198 [RFC1583] Moy, J., "OSPF Version 2", RFC 1583, March 1994. 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 Appendix A. Change Log 207 A.1. Changes between the -00 and -01 versions. 209 o Defined a new architectural constant (MaxLinkMetric) to eliminate 210 any confusion about the interpretation of LSInfinity. 212 o Added a section to reference the R-bit and V6-bit in OSPFv3. 214 o Updated acks and contact information. 216 A.2. Changes between the -01 and -02 versions. 218 o Took out references to not having a standard solution and 219 incorporated the R-bit solution as part of the (renamed) 220 "Solutions" section. 222 o Various minor edits and reordered sections. 224 Authors' Addresses 226 Alvaro Retana 227 Hewlett-Packard Co. 228 2610 Wycliff Road 229 Raleigh, NC 27607 230 USA 232 Email: alvaro.retana@hp.com 234 Liem Nguyen 235 Cisco Systems, Inc. 236 3750 Cisco Way 237 San Jose, CA 95134 238 USA 240 Email: lhnguyen@cisco.com 242 Alex Zinin 243 Cisco Systems, Inc. 244 Capital Tower, 168 Robinson Rd. 245 Singapore, Singapore 068912 246 Singapore 248 Email: azinin@cisco.com 249 Russ White 250 Verisign, Inc. 251 12061 Bluemont Way 252 Reston, VA 20190 253 USA 255 Email: riwhite@verisign.com 257 Danny McPherson 258 Verisign, Inc. 259 21345 Ridgetop Circle 260 Dulles, VA 20166 261 USA 263 Email: dmcpherson@verisign.com