idnits 2.17.1 draft-ietf-ospf-ospfv2-hbit-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 14, 2017) is 2506 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) == Outdated reference: A later version (-28) exists of draft-ietf-idr-bgp-optimal-route-reflection-13 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OSPF K. Patel 3 Internet-Draft Arrcus 4 Intended status: Standards Track P. Pillay-Esnault 5 Expires: December 16, 2017 Huawei Technologies 6 M. Bhardwaj 7 S. Bayraktar 8 Cisco Systems 9 June 14, 2017 11 H-bit Support for OSPFv2 12 draft-ietf-ospf-ospfv2-hbit-03 14 Abstract 16 OSPFv3 defines an option field for router-LSAs known as a R-bit in 17 RFC5340. If the R-bit is clear, an OSPFv3 router can participate in 18 OSPF topology distribution without acting as a forwarder to forward 19 the transit traffic. In such cases, an OSPF router would only accept 20 traffic intended for local delivery. This draft defines R-bit 21 functionality for OSPFv2 defined in RFC2328. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 16, 2017. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 59 3. H-bit Support . . . . . . . . . . . . . . . . . . . . . . . . 3 60 4. SPF Modifications . . . . . . . . . . . . . . . . . . . . . . 5 61 5. Auto Discovery and Backwards Compatibility . . . . . . . . . 5 62 6. OSPF AS-External-LSAs/NSSA LSAs with Type 2 Metrics . . . . . 6 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 64 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 66 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 11.1. Normative References . . . . . . . . . . . . . . . . . . 7 69 11.2. Informative References . . . . . . . . . . . . . . . . . 7 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 72 1. Introduction 74 OSPFv3 [RFC5340] defines an option field for router-LSAs known as a 75 R-bit. If the R-bit is clear, an OSPF router can participate in 76 OSPFv3 topology distribution without acting as a forwarder to forward 77 the transit traffic. In such cases, an OSPF router would only accept 78 traffic intended for local delivery. 80 This functionality is particularly useful for BGP Route Reflectors 81 known as virtual Route Reflectors (vRRs) that are not in the 82 forwarding path but are in central location such as data centers. 83 Such Route Reflectors typically are used for route distribution and 84 are not capable of forwarding data traffic. However, they need to 85 participate in the IGP routing for: 1) computing SPFs for Optimal 86 Route Reflection functionality defined in 87 [I-D.ietf-idr-bgp-optimal-route-reflection], and 2) resolving 88 reachability for its Route Reflector Clients. 90 This draft defines R-bit functionality for OSPFv2 defined in 91 [RFC2328] by introducing a new Router LSA bit known as a "H-bit". 93 2. Requirements Language 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119] only when 98 they appear in all upper case. They may also appear in lower or 99 mixed case as English words, without any normative meaning. 101 3. H-bit Support 103 This draft defines a new Router-LSA bit known as a Host Bit or a 104 H-bit. The H-bit indicates the OSPFv2's capability of acting as a 105 transit router. When set, the OSPFv2 router indicates that the 106 transit capability is disabled. The bit value usage of the H-bit is 107 reversed as opposed to the R-bit value defined in OSPFv3 [RFC5340] to 108 support backward compatibility. The OSPFv2 Router LSA format is 109 defined as: 111 0 1 2 3 112 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | LS age | Options | 1 | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | Link State ID | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | Advertising Router | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | LS sequence number | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | LS checksum | length | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 |H|0|0|N|W|V|E|B| 0 | # links | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | Link ID | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | Link Data | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | Type | # TOS | metric | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | ... | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | TOS | 0 | TOS metric | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | Link ID | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | Link Data | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | ... | 142 bit H 143 When set, an OSPFv2 router is a non-transit router and is 144 incapable of acting as a forwarder. 146 When H-bit is set, an OSPFv2 router is a non-transit router and is 147 incapable of acting as a forwarder. In this mode, the other OSPFv2 148 routers SHOULD NOT use the originating OSPFv2 router for the transit 149 traffic, but they will use the OSPFv2 router for data traffic 150 destined to that OSPFv2 router. An OSPFv2 router originating a 151 Router LSA with the H-bit set SHOULD advertise its LINKS with MAX 152 Link cost as defined in Section 3 of [RFC6987]. This is to increase 153 the applicability of the H-bit in partial deployments where it is the 154 responsibility of the operator to ensure that the H-bit does not 155 result in routing loops. 157 When H-bit is set, IPv4 prefixes associated with local interfaces MAY 158 be advertised in summary LSAs. Non-local IPv4 prefixes, e.g., those 159 advertised by other routers and installed during the SPF computation, 160 MAY be advertised in summary-LSAs if configured by policy. Likewise, 161 when H-bit is set, only IPv4 prefixes associated with local 162 interfaces MAY be advertised in AS-external LSAs. Non-local IPv4 163 prefixes, e.g., those exported from other routing protocols, MUST NOT 164 be advertised in AS-external-LSAs. Finally, when H-bit is set, an 165 ABR MUST advertise a consistent H-bit setting in its self-originated 166 router-LSAs for all attached areas. 168 4. SPF Modifications 170 The SPF calculation described in section 16.1 [RFC2328] will be 171 modified to assure that the routers originating router-LSAs with the 172 H-bit set will not be used for transit traffic. Step 2 is modified 173 as follows: 175 2) Call the vertex just added to the 176 tree vertex V. Examine the LSA 177 associated with vertex V. This is 178 a lookup in the Area A's link state 179 database based on the Vertex ID. If 180 this is a router-LSA, and the H-bit 181 of the router-LSA is set, and 182 vertex V is not the root, then the 183 router should not be used for transit 184 and step (3) should be executed 185 immediately. If this is a router-LSA, 186 and bit V of the router-LSA (see 187 Section A.4.2) is set, set Area A's 188 TransitCapability to TRUE. In any case, 189 each link described by the LSA gives 190 the cost to an adjacent vertex. For 191 each described link, (say it joins 192 vertex V to vertex W): 194 5. Auto Discovery and Backwards Compatibility 196 To avoid the possibility of any routing loops due to partial 197 deployments, this draft defines a new OSPF Router Functional 198 Capability known as a Host Support Capability. The value of this 199 capability is a bit value to be assigned by IANA from OSPF Router 200 Functional Capability Bits registry [RFC7770] . 202 The Auto Discovery via announcement of the Host Support Functional 203 Capability ensures that the H-bit functionality and its associated 204 SPF changes SHOULD only take effect if all the routers in a given 205 OSPF area support this functionality. 207 Implementations are encouraged to provide a knob to manually override 208 enforcement of the H-bit functionality in partial deployment 209 scenarios for cases where the topology guarantees that the router 210 supporting the H-bit will not cause routing loops. 212 6. OSPF AS-External-LSAs/NSSA LSAs with Type 2 Metrics 214 When calculating the path to an OSPF AS-External-LSA or NSSA-LSA with 215 a Type-2 metric, the advertised Type-2 metric is taken as more 216 significant than the OSPF intra-area or inter-area path. Hence, 217 advertising the links with MaxLinkMetric as specified in [RFC6987] 218 does not discourage transit traffic when calculating AS external or 219 NSSA routes. Consequently, OSPF routers implementing [RFC6987] or 220 this specification should advertise a Type-2 metric of LSInfinity for 221 any self-originated AS-External-LSAs or NSSA-LSAs in situations when 222 the OSPF router is acting as a stub router [RFC6987] or implementing 223 this specification. 225 7. IANA Considerations 227 This draft defines a new Router LSA bit known as a H-bit. This draft 228 requests IANA to 1) Create a new OSPF Router LSA bits registry and 2) 229 assign a H-bit code type from the newly allocated OSPF Router LSA bit 230 registry. 232 This draft defines a new Router Functional Capability known as a Host 233 Support Functional Capability. This draft requests IANA to allocate 234 the value of this capability from the Router Functional Capability 235 Bits TLV. 237 8. Security Considerations 239 This document introduces no new security considerations above and 240 beyond those already specified in [RFC2328] and [RFC5340]. 242 9. Acknowledgements 244 The authors would like to acknowledge Hasmit Grover for discovery of 245 the limitation in [RFC6987], Acee Lindem, Abhay Roy, David Ward, 246 Burjiz Pithawala and Michael Barnes for their comments. 248 10. Change Log 250 Initial Version: April 23 2015 252 11. References 254 11.1. Normative References 256 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 257 Requirement Levels", BCP 14, RFC 2119, 258 DOI 10.17487/RFC2119, March 1997, 259 . 261 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 262 DOI 10.17487/RFC2328, April 1998, 263 . 265 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 266 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 267 . 269 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 270 S. Shaffer, "Extensions to OSPF for Advertising Optional 271 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 272 February 2016, . 274 11.2. Informative References 276 [I-D.ietf-idr-bgp-optimal-route-reflection] 277 Raszuk, R., Cassar, C., Aman, E., Decraene, B., Litkowski, 278 S., and K. Wang, "BGP Optimal Route Reflection (BGP-ORR)", 279 draft-ietf-idr-bgp-optimal-route-reflection-13 (work in 280 progress), January 2017. 282 [RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D. 283 McPherson, "OSPF Stub Router Advertisement", RFC 6987, 284 DOI 10.17487/RFC6987, September 2013, 285 . 287 Authors' Addresses 289 Keyur Patel 290 Arrcus 292 Email: keyur@arrcus.com 293 Padma Pillay-Esnault 294 Huawei Technologies 295 2330 Central Expressway 296 Santa Clara, CA 95050 297 USA 299 Email: padma@huawei.com 301 Manish Bhardwaj 302 Cisco Systems 303 170 W. Tasman Drive 304 San Jose, CA 95134 305 USA 307 Email: manbhard@cisco.com 309 Serpil Bayraktar 310 Cisco Systems 311 170 W. Tasman Drive 312 San Jose, CA 95134 313 USA 315 Email: serpil@cisco.com