idnits 2.17.1 draft-ietf-ospf-ospfv2-hbit-00.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 (October 18, 2015) is 3112 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-10 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 P. Pillay-Esnault 4 Intended status: Standards Track M. Bhardwaj 5 Expires: April 20, 2016 S. Bayraktar 6 Cisco Systems 7 October 18, 2015 9 H-bit Support for OSPFv2 10 draft-ietf-ospf-ospfv2-hbit-00 12 Abstract 14 OSPFv3 defines an option field for router-LSAs known as a R-bit in 15 RFC5340. If the R-bit is clear, an OSPFv3 router can participate in 16 OSPF topology distribution without acting as a forwarder to forward 17 the transit traffic. In such cases, an OSPF router would only accept 18 traffic intended for local delivery. This draft defines R-bit 19 functionality for OSPFv2 defined in RFC2328. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 20, 2016. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 57 3. H-bit Support . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. SPF Modifications . . . . . . . . . . . . . . . . . . . . . . 4 59 5. Auto Discovery and Backwards Compatibility . . . . . . . . . 5 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 62 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 63 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 66 10.2. Informative References . . . . . . . . . . . . . . . . . 6 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 69 1. Introduction 71 OSPFv3 [RFC5340] defines an option field for router-LSAs known as a 72 R-bit. If the R-bit is clear, an OSPF router can participate in 73 OSPFv3 topology distribution without acting as a forwarder to forward 74 the transit traffic. In such cases, an OSPF router would only accept 75 traffic intended for local delivery. 77 This functionality is particularly useful for BGP Route Reflectors 78 known as virtual Route Reflectors (vRRs) that are not in the 79 forwarding path but are in central location such as data centers. 80 Such Route Reflectors typically are used for route distribution and 81 are not capable of forwarding data traffic. However, they need to 82 participate in the IGP routing for: 1) computing SPFs for Optimal 83 Route Reflection functionality defined in 84 [I-D.ietf-idr-bgp-optimal-route-reflection], and 2) resolving 85 reachability for its Route Reflector Clients. 87 This draft defines R-bit functionality for OSPFv2 defined in 88 [RFC2328] by introducing a new Router LSA bit known as a "H-bit". 90 2. Requirements Language 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119] only when 95 they appear in all upper case. They may also appear in lower or 96 mixed case as English words, without any normative meaning. 98 3. H-bit Support 100 This draft defines a new Router-LSA bit known as a Host Bit or a 101 H-bit. The H-bit indicates the OSPFv2's capability of acting as a 102 transit router. When set, the OSPFv2 router indicates that the 103 transit capability is disabled. The bit value usage of the H-bit is 104 reversed as opposed to the R-bit value defined in OSPFv3 [RFC5340] to 105 support backward compatibility. The OSPFv2 Router LSA format is 106 defined as: 108 0 1 2 3 109 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 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | LS age | Options | 1 | 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | Link State ID | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 | Advertising Router | 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 | LS sequence number | 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 | LS checksum | length | 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 |H|0|0|N|W|V|E|B| 0 | # links | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | Link ID | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | Link Data | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | Type | # TOS | metric | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | ... | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | TOS | 0 | TOS metric | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | Link ID | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | Link Data | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | ... | 139 bit H 140 When set, an OSPFv2 router is a non-transit router and is 141 incapable of acting as a forwarder. 143 When H-bit is set, an OSPFv2 router is a non-transit router and is 144 incapable of acting as a forwarder. In this mode, the other OSPFv2 145 routers SHOULD NOT use the originating OSPFv2 router for the transit 146 traffic, but they will use the OSPFv2 router for data traffic 147 destined to that OSPFv2 router. An OSPFv2 router originating a 148 Router LSA with the H-bit set SHOULD advertise its LINKS with MAX 149 Link cost as defined in Section 3 of [RFC6987]. This is to increase 150 the applicability of the H-bit in partial deployments where it is the 151 responsibility of the operator to ensure that the H-bit does not 152 result in routing loops. 154 When H-bit is set, IPv4 prefixes associated with local interfaces MAY 155 be advertised in summary LSAs. Non-local IPv4 prefixes, e.g., those 156 advertised by other routers and installed during the SPF computation, 157 MAY be advertised in summary-LSAs if configured by policy. Likewise, 158 when H-bit is set, only IPv4 prefixes associated with local 159 interfaces MAY be advertised in AS-external LSAs. Non-local IPv4 160 prefixes, e.g., those exported from other routing protocols, MUST NOT 161 be advertised in AS-external-LSAs. Finally, when H-bit is set, an 162 ABR MUST advertise a consistent H-bit setting in its self-originated 163 router-LSAs for all attached areas. 165 4. SPF Modifications 167 The SPF calculation described in section 16.1 [RFC2328] will be 168 modified to assure that the routers originating router-LSAs with the 169 H-bit set will not be used for transit traffic. Step 2 is modified 170 as follows: 172 2) Call the vertex just added to the 173 tree vertex V. Examine the LSA 174 associated with vertex V. This is 175 a lookup in the Area A's link state 176 database based on the Vertex ID. If 177 this is a router-LSA, and the H-bit 178 of the router-LSA is set, and 179 vertex V is not the root, then the 180 router should not be used for transit 181 and step (3) should be executed 182 immediately. If this is a router-LSA, 183 and bit V of the router-LSA (see 184 Section A.4.2) is set, set Area A's 185 TransitCapability to TRUE. In any case, 186 each link described by the LSA gives 187 the cost to an adjacent vertex. For 188 each described link, (say it joins 189 vertex V to vertex W): 191 5. Auto Discovery and Backwards Compatibility 193 To avoid the possibility of any routing loops due to partial 194 deployments, this draft defines a new OSPF Router Functional 195 Capability known as a Host Support Capability. The value of this 196 capability is a bit value to be assigned by IANA from OSPF Router 197 Functional Capability Bits registry [I-D.ietf-ospf-rfc4970bis]. 199 The Auto Discovery via announcement of the Host Support Functional 200 Capability ensures that the H-bit functionality and its associated 201 SPF changes SHOULD only take effect if all the routers in a given 202 OSPF area support this functionality. 204 Implementations are encouraged to provide a knob to manually override 205 enforcement of the H-bit functionality in partial deployment 206 scenarios for cases where the topology guarantees that the router 207 supporting the H-bit will not cause routing loops. 209 6. IANA Considerations 211 This draft defines a new Router LSA bit known as a H-bit. This draft 212 requests IANA to 1) Create a new OSPF Router LSA bits registry and 2) 213 assign a H-bit code type from the newly allocated OSPF Router LSA bit 214 registry. 216 This draft defines a new Router Functional Capability known as a Host 217 Support Functional Capability. This draft requests IANA to allocate 218 the value of this capability from the Router Functional Capability 219 Bits TLV. 221 7. Security Considerations 223 This document introduces no new security considerations above and 224 beyond those already specified in [RFC2328] and [RFC5340]. 226 8. Acknowledgements 228 The authors would like to acknowledge Acee Lindem, Abhay Roy, David 229 Ward, Burjiz Pithawala and Michael Barnes for their comments. 231 9. Change Log 233 Initial Version: April 23 2015 235 10. References 237 10.1. Normative References 239 [I-D.ietf-ospf-rfc4970bis] 240 Lindem, A., Shen, N., Vasseur, J., Aggarwal, R., and S. 241 Shaffer, "Extensions to OSPF for Advertising Optional 242 Router Capabilities", draft-ietf-ospf-rfc4970bis-07 (work 243 in progress), October 2015. 245 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 246 Requirement Levels", BCP 14, RFC 2119, 247 DOI 10.17487/RFC2119, March 1997, 248 . 250 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 251 DOI 10.17487/RFC2328, April 1998, 252 . 254 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 255 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 256 . 258 10.2. Informative References 260 [I-D.ietf-idr-bgp-optimal-route-reflection] 261 Raszuk, R., Cassar, C., Aman, E., Decraene, B., and S. 262 Litkowski, "BGP Optimal Route Reflection (BGP-ORR)", 263 draft-ietf-idr-bgp-optimal-route-reflection-10 (work in 264 progress), July 2015. 266 [RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D. 267 McPherson, "OSPF Stub Router Advertisement", RFC 6987, 268 DOI 10.17487/RFC6987, September 2013, 269 . 271 Authors' Addresses 273 Keyur Patel 274 Cisco Systems 275 170 W. Tasman Drive 276 San Jose, CA 95124 95134 277 USA 279 Email: keyupate@cisco.com 281 Padma Pillay-Esnault 282 Cisco Systems 283 170 W. Tasman Drive 284 San Jose, CA 95124 95134 285 USA 287 Email: ppe@cisco.com 289 Manish Bhardwaj 290 Cisco Systems 291 170 W. Tasman Drive 292 San Jose, CA 95124 95134 293 USA 295 Email: manbhard@cisco.com 297 Serpil Bayraktar 298 Cisco Systems 299 170 W. Tasman Drive 300 San Jose, CA 95124 95134 301 USA 303 Email: serpil@cisco.com