idnits 2.17.1 draft-keyupate-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5340], [RFC2328]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: When H-bit is set, an OSPFv2 router is a non-transit router and is incapable of acting as a forwarder. In this mode, the other OSPFv2 routers MUST not use the originating OSPFv2 router for the transit traffic, but they will use the OSPFv2 router for data traffic destined to that OSPFv2 router. An OSPFv2 router originating a Router LSA with the H-bit set SHOULD advertise its LINKS with MAX Link cost as defined in Section 3 of [RFC6987]. This is to increase the applicability of the H-bit in partial deployments where it is the responsibility of the operator to ensure that the H-bit does not result in routing loops. -- The document date (May 21, 2015) is 3263 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) == Missing Reference: 'I-D.ietf-idr-bgp-orr' is mentioned on line 83, but not defined == Unused Reference: 'I-D.ietf-idr-bgp-optimal-route-reflection' is defined on line 258, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-ospf-rfc4970bis-00 ** Downref: Normative reference to an Informational RFC: RFC 6987 == Outdated reference: A later version (-28) exists of draft-ietf-idr-bgp-optimal-route-reflection-09 Summary: 2 errors (**), 0 flaws (~~), 7 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: November 22, 2015 S. Bayraktar 6 Cisco Systems 7 May 21, 2015 9 H-bit Support for OSPFv2 10 draft-keyupate-ospf-ospfv2-hbit-01 12 Abstract 14 OSPFv3 [RFC5340] defines an option field for router-LSAs known as a 15 R-bit. 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 November 22, 2015. 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 [I-D.ietf-idr-bgp-orr], and 84 2) resolving reachability for its Route Reflector Clients. 86 This draft defines R-bit functionality for OSPFv2 defined in 87 [RFC2328] by introducing a new Router LSA bit known as a "H-bit". 89 2. Requirements Language 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to 93 be interpreted as described in [RFC2119] only when they appear in all 94 upper case. They may also appear in lower or mixed case as English 95 words, without any normative meaning. 97 3. H-bit Support 99 This draft defines a new Router-LSA bit known as a Host Bit or a 100 H-bit. The H-bit indicates the OSPFv2's capability of acting as a 101 forwarder router. When set, the OSPFv2 router indicates that the 102 forwarding capability is disabled. The bit value usage of the H-bit 103 is reversed as opposed to the R-bit value defined in OSPFv3 [RFC5340] 104 to support backward compatibility. The OSPFv2 Router LSA format is 105 defined as: 107 0 1 2 3 108 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 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | LS age | Options | 1 | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | Link State ID | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | Advertising Router | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | LS sequence number | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | LS checksum | length | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 |H|0|0|N|W|V|E|B| 0 | # links | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | Link ID | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | Link Data | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | Type | # TOS | metric | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | ... | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | TOS | 0 | TOS metric | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | Link ID | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | Link Data | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | ... | 138 bit H 139 When set, an OSPFv2 router is a non-transit router and is 140 incapable of acting as a forwarder. 142 When H-bit is set, an OSPFv2 router is a non-transit router and is 143 incapable of acting as a forwarder. In this mode, the other OSPFv2 144 routers MUST not use the originating OSPFv2 router for the transit 145 traffic, but they will use the OSPFv2 router for data traffic 146 destined to that OSPFv2 router. An OSPFv2 router originating a 147 Router LSA with the H-bit set SHOULD advertise its LINKS with MAX 148 Link cost as defined in Section 3 of [RFC6987]. This is to increase 149 the applicability of the H-bit in partial deployments where it is the 150 responsibility of the operator to ensure that the H-bit does not 151 result in routing loops. 153 When H-bit is set, only IPv4 prefixes associated with local 154 interfaces MAY be advertised in summary LSAs. Non-local IPv4 155 prefixes, e.g., those advertised by other routers and installed 156 during the SPF computation, MUST NOT be adverised in summary-LSAs. 157 Likewise, when H-bit is set, only IPv4 prefixes associated with local 158 interfaces MAY be advertised in AS-external LSAs. Non-local IPv4 159 prefixes, e.g., those exported from other routing protocols, MUST NOT 160 be advertised in AS-external-LSAs. Finally, when H-bit is set, an 161 ABR MUST advertise a consistent H-bit setting in its self-originated 162 router-LSAs for all attached areas. 164 4. SPF Modifications 166 The SPF calculation described in section 16.1 [RFC2328] will be 167 modified to assure that the routers originating router-LSAs with the 168 H-bit set will not be used for transit traffic. Step 2 is modified 169 as follows: 171 2) Call the vertex just added to the 172 tree vertex V. Examine the LSA 173 associated with vertex V. This is 174 a lookup in the Area A's link state 175 database based on the Vertex ID. If 176 this is a router-LSA, and the H-bit 177 of the router-LSA is set, and 178 vertex V is not the root, then the 179 router should not be used for transit 180 and step (3) should be executed 181 immediatately. If this is a router-LSA, 182 and bit V of the router-LSA (see 183 Section A.4.2) is set, set Area A's 184 TransitCapability to TRUE. In any case, 185 each link described by the LSA gives 186 the cost to an adjacent vertex. For 187 each described link, (say it joins 188 vertex V to vertex W): 190 5. Auto Discovery and Backwards Compatibility 192 To avoid the possibility of any routing loops due to partial 193 deployments, this draft defines a new OSPF Router Functional 194 Capability known as a Host Support Capability. The value of this 195 capability is a bit value to be assigned by IANA from OSPF Router 196 Functional Capability Bits registry [I-D.ietf-ospf-rfc4970bis]. 198 The Auto Discovery via announcement of the Host Support Functional 199 Capability ensures that the H-bit functionality and its associated 200 SPF changes SHOULD only take effect if all the routers in a given 201 OSPF area support this functionality. 203 Implementations are encouraged to provide a knob to manually override 204 enforcement of the H-bit functionality in partial deployment 205 scenarios for cases where the topology gurantees that the router 206 supporting the H-bit will not cause routing loops. 208 6. IANA Considerations 210 This draft defines a new Router LSA bit known as a H-bit. This draft 211 requests IANA to 1) Create a new OSPF Router LSA bits registry and 2) 212 assign a H-bit code type from the newly allocated OSPF Router LSA bit 213 registry. 215 This draft defines a new Router Fucntional Capability known as a Host 216 Support Functional Capability. This draft requests IANA to allocate 217 the value of this capability from the Router Functional Capability 218 Bits TLV. 220 7. Security Considerations 222 This document introduces no new security considerations above and 223 beyond those already specified in [RFC2328] and [RFC5340]. 225 8. Acknowledgements 227 The authors would like to acknowledge Acee Lindem, Abhay Roy, David 228 Ward, Burjiz Pithawala and Michael Barnes for their comments. 230 9. Change Log 232 Initial Version: April 23 2015 234 10. References 236 10.1. Normative References 238 [I-D.ietf-ospf-rfc4970bis] 239 Lindem, A., Shen, N., Vasseur, J., Aggarwal, R., and S. 240 Shaffer, "Extensions to OSPF for Advertising Optional 241 Router Capabilities", draft-ietf-ospf-rfc4970bis-00 (work 242 in progress), January 2015. 244 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 245 Requirement Levels", BCP 14, RFC 2119, March 1997. 247 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 249 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 250 for IPv6", RFC 5340, July 2008. 252 [RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D. 253 McPherson, "OSPF Stub Router Advertisement", RFC 6987, 254 September 2013. 256 10.2. Informative References 258 [I-D.ietf-idr-bgp-optimal-route-reflection] 259 Raszuk, R., Cassar, C., Aman, E., Decraene, B., and S. 260 Litkowski, "BGP Optimal Route Reflection (BGP-ORR)", 261 draft-ietf-idr-bgp-optimal-route-reflection-09 (work in 262 progress), April 2015. 264 Authors' Addresses 266 Keyur Patel 267 Cisco Systems 268 170 W. Tasman Drive 269 San Jose, CA 95124 95134 270 USA 272 Email: keyupate@cisco.com 274 Padma Pillay-Esnault 275 Cisco Systems 276 170 W. Tasman Drive 277 San Jose, CA 95124 95134 278 USA 280 Email: ppe@cisco.com 282 Manish Bhardwaj 283 Cisco Systems 284 170 W. Tasman Drive 285 San Jose, CA 95124 95134 286 USA 288 Email: manbhard@cisco.com 290 Serpil Bayraktar 291 Cisco Systems 292 170 W. Tasman Drive 293 San Jose, CA 95124 95134 294 USA 296 Email: serpil@cisco.com