idnits 2.17.1 draft-shishio-ospf-ospfv3-stub-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 document seems to lack an Introduction section. -- The draft header indicates that this document updates RFC3137, but the abstract doesn't seem to directly say this. It does mention RFC3137 though, so this could be OK. 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. (Using the creation date from RFC3137, updated by this document, for RFC5378 checks: 2000-09-18) -- 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 (January 5, 2011) is 4861 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 informational reference (is this intentional?): RFC 3137 (Obsoleted by RFC 6987) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Tsuchiya, Ed. 3 Internet-Draft G. Van de Velde 4 Updates: 3137 (if approved) Cisco Systems 5 Intended status: Standards Track T. Yamagata 6 Expires: July 9, 2011 KDDI Corporation 7 January 5, 2011 9 OSPFv3 Stub Router Advertisement 10 draft-shishio-ospf-ospfv3-stub-03 12 Abstract 14 OSPFv3 accommodates for the possibility to indicate through the R-bit 15 if a router is an active router and should be taken into 16 consideration as a transit device. Another method available is the 17 v6-bit indicating if a router or link should be excluded from IPv6 18 routing calculations. 20 A direct result is that OSPFv3 has "no transit capability" 21 potentially based upon the setting of R-bit and V6-bit, unlike the 22 stub OSPFv2 router functionality. This feature proposal has as 23 purpose to re-introduce existing OSPFv2 stub router behavior into 24 OSPFv3 to keep the operational service provider experience used to 25 deploy, troubleshoot and be familiar with OSPFv2 stub routing. 27 OSPFv3 has similar metric field information field of all of LSAs, 28 with exception of the Link-LSA, so RFC3137 method can be re-utilized 29 in OSPFv3. 31 To drive consistency between OSPFv2 and OSPFv3, there should be next 32 to supporting both R-bit and v6-bit be support for"max-metric". 34 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on July 9, 2011. 50 Copyright Notice 52 Copyright (c) 2011 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 4 69 3. OSPFv2 operation . . . . . . . . . . . . . . . . . . . . . . . 4 70 3.1. Wait for BGP during booting . . . . . . . . . . . . . . . . 5 71 3.2. LDP Synchronization . . . . . . . . . . . . . . . . . . . . 5 72 3.3. Configuration change . . . . . . . . . . . . . . . . . . . 6 73 4. OSPFv3 operation . . . . . . . . . . . . . . . . . . . . . . . 6 74 4.1. R-bit and v6-bit . . . . . . . . . . . . . . . . . . . . . 6 75 4.2. OSPFv2 compatibility mode . . . . . . . . . . . . . . . . . 6 76 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 80 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 81 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 82 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . . 8 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 85 1. Motivation 87 OSPF Stub Router Advertisement [RFC3137] describes a set of 88 situations when the Service provider has a desire to utilize this 89 functionality. 91 o The router is in a critical condition resulting in either a very 92 high CPU load, or not enough memory to store all LSAs, or doesn't 93 succeed to build the routing table 95 o Graceful introduction or removal of a router to or from the 96 network 98 o Other (administrative or traffic engineering) reasons 100 Even if the network will be moved or migrated towards from IPv4 in 101 combination with OSPFv2 towards IPv6 using OSPFv3 [OSPFv3] 102 technology, it remains important that the operational behaviour 103 remains similar between routing protocols. 105 2. Requirements Language 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC 2119 [RFC2119]. 111 3. OSPFv2 operation 113 RFC3137 [RFC3137] describes in section 2 in detail the behavior of 114 link cost metrics. i.e. Router X announces its Router LSA to the 115 neighbor with costs of all non-stub links which are set to 116 LSInfinity(0xFFFF), while stub links are announced with interface 117 cost. 119 Often the operator will check interface metric of ospf database 120 assuming he would like to confirm whether the router is announcing 121 LSInfinity. 123 Many service provider operators are using OSPF stub router 124 advertisement [RFC3137] for OSPFv2 [OSPFv2]. This feature is 125 supported by majority of OSPFv2 implementations. Use cases are 126 below; 128 3.1. Wait for BGP during booting 130 |R1|--|R2|---|R4|---internet 131 | | 132 +----|R3|-----+ 134 Figure 1 136 In this example R2 can be assumed it is the best path towards the 137 Internet from R1. When R2 reloads it would result that R3 would be 138 best path for going towards Internet. From the moment R2 is reloaded 139 and OSPF has converged, there may be a situation when BGP is still 140 not converged to the full. If in this situation R1 should not send 141 traffic towards R2 just yet. R2 should send LSInfinity(0xFFFF) to 142 indicate that R1 should wait for R2's BGP converge. Once BGP is 143 fully converged, R2 LSA's out with correct interface metric value in 144 OSPFv2 area which will result in R2 being reintroduced as the primary 145 path. 147 3.2. LDP Synchronization 149 |R1|--|R2|---|R4| 150 | | 151 +----|R3|----+ 153 Figure 2 155 Assume that from R1 the best path to R4 is via R2 in this MPLS 156 network. When R2 is reloaded, then R3 is the only and hence also the 157 best path. At some point in time R2 is fully successfully reloaded 158 resulting that OSPF has converged also. This does not necessary mean 159 LDP has fully converged either. In this situation R1 should not send 160 traffic to R2 immediately. In that case R2 could send 161 LSInfinity(0xFFFF) resulting in a situation where R1 must wait for R2 162 to be fully be available and transit states have been passed. From 163 the moment LDP converged on R2, it can distribute the traditional 164 Interface OSPF metric value. This operation will result that OSPF 165 and LDP have a converged behaviour. The importance and the 166 description of this behaviour can be found in [LDP-Sync]. 168 3.3. Configuration change 170 |R1|--|R2|---|R4| 171 | | 172 +----|R3|-----+ 174 Figure 3 176 When operator needs R2 configuration change,R2 sends 177 LSInfinity(0xFFFF) for traffic engineering. R2 configuration 178 completed,R2 sends correct metric value in OSPFv2 area. 180 4. OSPFv3 operation 182 4.1. R-bit and v6-bit 184 [OSPFv3] explains at section 2.7 the following: If the "R-bit" is 185 clear, an OSPF speaker can participate in OSPF topology distribution 186 without being used to forward transit traffic. The V6-bit 187 specializes the R-bit; if the V6-bit is clear, an OSPF speaker can 188 participate in OSPF topology distribution without being used to 189 forward IPv6 datagrams. If the R-bit is set and the V6-bit is clear, 190 IPv6 datagrams are not forwarded but datagrams belonging to another 191 protocol family may be forwarded. 193 This protocol implementation is useful in multi address family 194 environment such as [OSPFv3-AF]. But Service Provider operators have 195 to check both the "R-bit" and "v6-bit" during their operation and 196 introduce both training and operational changes to make this a true 197 usable technology. Operators have believe that a useful approach 198 would be to rely upon successful IPv4 OSPFv2 behaviour and to add a 199 "OSPFv2 compatibility mode" in IPv6 only environment to mimic OSPFv2 200 behavior in this environment. 202 The functionality of the R-bit and v6-bit operations is described in 203 [OSPFv3]'s Errata 2078 more detail. 205 A Router should support a "R-bit" know with a clear wait for BGP or 206 waiting-before-becoming-active time on start-up same as [RFC3137] 207 indicates. 209 4.2. OSPFv2 compatibility mode 211 An OSPFv3 routing device has through the area scope LSAs metric 212 information of all of devices. As result the router can announce the 213 interface metric LSInfinity(0xFFFF). This is simple implementation 214 model not requiring operational service provider changes. 216 5. Acknowledgements 218 This document is based on RFC3137 [RFC3137] and RFC5340 219 [OSPFv3]Errata 2078. RFC3137 [RFC3137] done by Alvaro Retana,Liem 220 Nguyen,Russ White,Alex Zinin and Danny McPherson. RFC5340 [OSPFv3] 221 done by Rob Coltun,Dennis Ferguson,John Moy and Acee Lindem. Balaji 222 Ganesh pointed out problem of Section 4.8.1RFC5340 [OSPFv3]on Errata 223 2046. Michael Barnes brought up the fact,Acee Lindem reported on 224 Errata 2078. Tsuyoshi Momose advised us about how to write internet- 225 draft. Fred Baker was reviewed this document in initial stage. 226 Cisco OSPF coder's are gave comments about this document. Especially 227 Peter Psenak did deep discussion about both modes. Michael Barnes 228 pointed out Errata 2078 exists. The authors would like to thank all 229 of them for their activity,comments and help. 231 6. IANA Considerations 233 This document has no actions for IANA. 235 7. Security Considerations 237 The technique described in this document does not introduce any new 238 security issues into OSPFv3 protocol. 240 8. References 242 8.1. Normative References 244 [OSPFv2] Moy, J., ""OSPF Version 2"", RFC 2328, STD 54, April 1998, 245 . 247 [OSPFv3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, ""OSPF 248 for IPv6"", RFC 5340, July 2008, 249 . 251 [OSPFv3-AF] 252 Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. 253 Aggarwal, ""Support of Address Families in OSPFv3"", 254 RFC 5838, Apri 2010, . 256 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 257 Requirement Levels", BCP 14, RFC 2119, March 1997. 259 8.2. Informative References 261 [LDP-Sync] 262 Jork, M., Atlas, A., and L. Fang, ""LDP IGP 263 Synchronization"", RFC 5443, March 2009, 264 . 266 [RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D. 267 McPherson, ""OSPF Stub Router Advertisement"", RFC 3137, 268 June 2001, . 270 Appendix A. Additional Stuff 272 This becomes an Appendix. 274 Authors' Addresses 276 Shishio Tsuchiya (editor) 277 Cisco Systems 278 Shinjuku Mitsui Building, 2-1-1, Nishi-Shinjuku 279 Shinjuku-Ku, Tokyo 163-0409 280 Japan 282 Phone: +81 3 6434 6543 283 Email: shtsuchi@cisco.com 285 Gunter Van de Velde 286 Cisco Systems 287 Pegasus Parc 288 De kleetlaan 6a, DIEGEM, BRABANT 1831 289 BELGIUM 291 Phone: +32 2 704 5473 292 Email: gunter@cisco.com 294 Tomohiro Yamagata 295 KDDI Corporation 296 Garden Air Tower,3-10-10, Iidabashi 297 Chiyoda-Ku, Tokyo 102-8460 298 Japan 300 Phone: +81 3 6678 3089 301 Email: to-yamagata@kddi.com