idnits 2.17.00 (12 Aug 2021) /tmp/idnits17763/draft-ietf-ospf-ospfv2-hbit-01.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 (July 5, 2016) is 2145 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: draft-ietf-idr-bgp-optimal-route-reflection has been published as RFC 9107 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 Cisco Systems 4 Intended status: Standards Track P. Pillay-Esnault 5 Expires: January 6, 2017 Huawei Technologies 6 M. Bhardwaj 7 S. Bayraktar 8 Cisco Systems 9 July 5, 2016 11 H-bit Support for OSPFv2 12 draft-ietf-ospf-ospfv2-hbit-01 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 January 6, 2017. 40 Copyright Notice 42 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . 2 59 3. H-bit Support . . . . . . . . . . . . . . . . . . . . . . . . 3 60 4. SPF Modifications . . . . . . . . . . . . . . . . . . . . . . 5 61 5. Auto Discovery and Backwards Compatibility . . . . . . . . . 5 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 65 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 68 10.2. Informative References . . . . . . . . . . . . . . . . . 7 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 71 1. Introduction 73 OSPFv3 [RFC5340] defines an option field for router-LSAs known as a 74 R-bit. If the R-bit is clear, an OSPF router can participate in 75 OSPFv3 topology distribution without acting as a forwarder to forward 76 the transit traffic. In such cases, an OSPF router would only accept 77 traffic intended for local delivery. 79 This functionality is particularly useful for BGP Route Reflectors 80 known as virtual Route Reflectors (vRRs) that are not in the 81 forwarding path but are in central location such as data centers. 82 Such Route Reflectors typically are used for route distribution and 83 are not capable of forwarding data traffic. However, they need to 84 participate in the IGP routing for: 1) computing SPFs for Optimal 85 Route Reflection functionality defined in 86 [I-D.ietf-idr-bgp-optimal-route-reflection], and 2) resolving 87 reachability for its Route Reflector Clients. 89 This draft defines R-bit functionality for OSPFv2 defined in 90 [RFC2328] by introducing a new Router LSA bit known as a "H-bit". 92 2. Requirements Language 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119] only when 97 they appear in all upper case. They may also appear in lower or 98 mixed case as English words, without any normative meaning. 100 3. H-bit Support 102 This draft defines a new Router-LSA bit known as a Host Bit or a 103 H-bit. The H-bit indicates the OSPFv2's capability of acting as a 104 transit router. When set, the OSPFv2 router indicates that the 105 transit capability is disabled. The bit value usage of the H-bit is 106 reversed as opposed to the R-bit value defined in OSPFv3 [RFC5340] to 107 support backward compatibility. The OSPFv2 Router LSA format is 108 defined as: 110 0 1 2 3 111 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 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | LS age | Options | 1 | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 | Link State ID | 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 | Advertising Router | 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 | LS sequence number | 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | LS checksum | length | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 |H|0|0|N|W|V|E|B| 0 | # links | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | Link ID | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | Link Data | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | Type | # TOS | metric | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | ... | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | TOS | 0 | TOS metric | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | Link ID | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | Link Data | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | ... | 141 bit H 142 When set, an OSPFv2 router is a non-transit router and is 143 incapable of acting as a forwarder. 145 When H-bit is set, an OSPFv2 router is a non-transit router and is 146 incapable of acting as a forwarder. In this mode, the other OSPFv2 147 routers SHOULD NOT use the originating OSPFv2 router for the transit 148 traffic, but they will use the OSPFv2 router for data traffic 149 destined to that OSPFv2 router. An OSPFv2 router originating a 150 Router LSA with the H-bit set SHOULD advertise its LINKS with MAX 151 Link cost as defined in Section 3 of [RFC6987]. This is to increase 152 the applicability of the H-bit in partial deployments where it is the 153 responsibility of the operator to ensure that the H-bit does not 154 result in routing loops. 156 When H-bit is set, IPv4 prefixes associated with local interfaces MAY 157 be advertised in summary LSAs. Non-local IPv4 prefixes, e.g., those 158 advertised by other routers and installed during the SPF computation, 159 MAY be advertised in summary-LSAs if configured by policy. Likewise, 160 when H-bit is set, only IPv4 prefixes associated with local 161 interfaces MAY be advertised in AS-external LSAs. Non-local IPv4 162 prefixes, e.g., those exported from other routing protocols, MUST NOT 163 be advertised in AS-external-LSAs. Finally, when H-bit is set, an 164 ABR MUST advertise a consistent H-bit setting in its self-originated 165 router-LSAs for all attached areas. 167 4. SPF Modifications 169 The SPF calculation described in section 16.1 [RFC2328] will be 170 modified to assure that the routers originating router-LSAs with the 171 H-bit set will not be used for transit traffic. Step 2 is modified 172 as follows: 174 2) Call the vertex just added to the 175 tree vertex V. Examine the LSA 176 associated with vertex V. This is 177 a lookup in the Area A's link state 178 database based on the Vertex ID. If 179 this is a router-LSA, and the H-bit 180 of the router-LSA is set, and 181 vertex V is not the root, then the 182 router should not be used for transit 183 and step (3) should be executed 184 immediately. If this is a router-LSA, 185 and bit V of the router-LSA (see 186 Section A.4.2) is set, set Area A's 187 TransitCapability to TRUE. In any case, 188 each link described by the LSA gives 189 the cost to an adjacent vertex. For 190 each described link, (say it joins 191 vertex V to vertex W): 193 5. Auto Discovery and Backwards Compatibility 195 To avoid the possibility of any routing loops due to partial 196 deployments, this draft defines a new OSPF Router Functional 197 Capability known as a Host Support Capability. The value of this 198 capability is a bit value to be assigned by IANA from OSPF Router 199 Functional Capability Bits registry [RFC7770] . 201 The Auto Discovery via announcement of the Host Support Functional 202 Capability ensures that the H-bit functionality and its associated 203 SPF changes SHOULD only take effect if all the routers in a given 204 OSPF area support this functionality. 206 Implementations are encouraged to provide a knob to manually override 207 enforcement of the H-bit functionality in partial deployment 208 scenarios for cases where the topology guarantees that the router 209 supporting the H-bit will not cause routing loops. 211 6. IANA Considerations 213 This draft defines a new Router LSA bit known as a H-bit. This draft 214 requests IANA to 1) Create a new OSPF Router LSA bits registry and 2) 215 assign a H-bit code type from the newly allocated OSPF Router LSA bit 216 registry. 218 This draft defines a new Router Functional Capability known as a Host 219 Support Functional Capability. This draft requests IANA to allocate 220 the value of this capability from the Router Functional Capability 221 Bits TLV. 223 7. Security Considerations 225 This document introduces no new security considerations above and 226 beyond those already specified in [RFC2328] and [RFC5340]. 228 8. Acknowledgements 230 The authors would like to acknowledge Acee Lindem, Abhay Roy, David 231 Ward, Burjiz Pithawala and Michael Barnes for their comments. 233 9. Change Log 235 Initial Version: April 23 2015 237 10. References 239 10.1. Normative References 241 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 242 Requirement Levels", BCP 14, RFC 2119, 243 DOI 10.17487/RFC2119, March 1997, 244 . 246 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 247 DOI 10.17487/RFC2328, April 1998, 248 . 250 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 251 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 252 . 254 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 255 S. Shaffer, "Extensions to OSPF for Advertising Optional 256 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 257 February 2016, . 259 10.2. Informative References 261 [I-D.ietf-idr-bgp-optimal-route-reflection] 262 Raszuk, R., Cassar, C., Aman, E., Decraene, B., Litkowski, 263 S., and K. Wang, "BGP Optimal Route Reflection (BGP-ORR)", 264 draft-ietf-idr-bgp-optimal-route-reflection-11 (work in 265 progress), January 2016. 267 [RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D. 268 McPherson, "OSPF Stub Router Advertisement", RFC 6987, 269 DOI 10.17487/RFC6987, September 2013, 270 . 272 Authors' Addresses 274 Keyur Patel 275 Cisco Systems 276 170 W. Tasman Drive 277 San Jose CA 95134, 278 USA 280 Email: keyupate@cisco.com 282 Padma Pillay-Esnault 283 Huawei Technologies 284 2330 Central Expressway 285 Santa Clara, CA 95050 286 USA 288 Email: padma@huawei.com 289 Manish Bhardwaj 290 Cisco Systems 291 170 W. Tasman Drive 292 San Jose, CA 95134 293 USA 295 Email: manbhard@cisco.com 297 Serpil Bayraktar 298 Cisco Systems 299 170 W. Tasman Drive 300 San Jose, CA 95134 301 USA 303 Email: serpil@cisco.com