idnits 2.17.1 draft-mitchell-rtgwg-pseudo-bgp-nh-cost-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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 122: '...or. The key in this mechanism MUST be...' RFC 2119 keyword, line 125: '... cost MUST be an unsigned integer wi...' RFC 2119 keyword, line 128: '... when utilizing wide metrics [RFC3784]. Implementations MAY support...' RFC 2119 keyword, line 131: '...e implementation MAY choose to represe...' RFC 2119 keyword, line 134: '...e implementation MUST persist this inf...' (7 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 19, 2015) is 3110 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3784 (Obsoleted by RFC 5305) == Outdated reference: A later version (-28) exists of draft-ietf-idr-bgp-optimal-route-reflection-10 == Outdated reference: A later version (-03) exists of draft-ietf-idr-bgp-nh-cost-02 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Routing Area Working Group J. Mitchell 3 Internet-Draft October 19, 2015 4 Intended status: Informational 5 Expires: April 21, 2016 7 A Pseudo-Protocol for BGP Next Hop Cost Manipulation 8 draft-mitchell-rtgwg-pseudo-bgp-nh-cost-00 10 Abstract 12 This describes a local router implementation option that provides a 13 facility for the manipulation of the costs of IGP learned routes that 14 are utilized as BGP NextHops rather than using the SPF calculated 15 cost to the same route when running the BGP path selection algorithm. 16 The result is something that works like a pseudo-routing protocol but 17 only impacting the BGP decision making process. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 21, 2016. 36 Copyright Notice 38 Copyright (c) 2015 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Implementation Overview . . . . . . . . . . . . . . . . . . . 3 55 3. Implementation Details . . . . . . . . . . . . . . . . . . . 3 56 3.1. Key-Value Store . . . . . . . . . . . . . . . . . . . . . 3 57 3.2. Cost Replacement Mechanism . . . . . . . . . . . . . . . 4 58 3.2.1. Simple Implementation Option . . . . . . . . . . . . 4 59 3.2.2. Alternative Implementation Option (for use with ORR) 4 60 3.2.3. IGP Shortcuts Like Implementation Option . . . . . . 5 61 3.2.4. Handling Router Maintenance . . . . . . . . . . . . . 5 62 4. Relationship to Other Work . . . . . . . . . . . . . . . . . 6 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 68 8.2. Informative References . . . . . . . . . . . . . . . . . 7 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 71 1. Introduction 73 In networks where out of band route reflectors are in use that also 74 deploy tunneling technologies such as RSVP-TE LSPs and where the 75 operator has selected to use non-IGP SPF derived metrics on those 76 tunnels which influence the BGP path selection process at the point 77 when it reaches step (e) of section 9.1.2.2 of [RFC4271], an operator 78 wishing to make the same decision for BGP prefixes that reach this 79 point in the process on a router which does not deploy the tunneling 80 technology has little capability to do so given existing 81 functionality available in vendor implementations. This limits the 82 ability for the out of band BGP route reflector from being deployed 83 in these networks without implementing the tunnel technologies in use 84 similiar to a router in the forwarding path (in band) or choosing to 85 live with the IGP SPF derived decision for this step, neither of 86 which are an ideal deployment scenario. Presumably, the metrics 87 configured on the tunnels deployed have value from a traffic 88 engineering standpoint versus the IGP derived metrics, and issues may 89 occur meeting the network requirements if the route reflector in 90 question were to make a different decision than that made by a 91 similarly located client. 93 This draft proposes a way for an implementation to provide a simple 94 capability to manipulate the cost to the typically IGP learned 95 prefixes that are utilized as BGP next hops. 97 2. Implementation Overview 99 A pseudo-protocol can be used to manipulate the cost to a BGP nexthop 100 in cases where the normal IGP SPF cost is not desirable. To 101 accomplish this, the pseudo-protocol would need the desired cost and 102 a way to inject this cost in the BGP bestpath calculation. This can 103 be accomplished via two components: 105 o A key-value store (e.g. an associative array) for associating 106 nexthop prefixes to costs 108 o A cost replacement mechanism for utilizing the looked up 109 information in place of the normally utilized IGP cost to the 110 nexthop available in the routing table when doing the BGP bestpath 111 calculation. 113 3. Implementation Details 115 As discussed above the implementation must provide two distinct 116 components, a key-value store and a cost replacement mechanism. 118 3.1. Key-Value Store 120 An implementation must provide a basic key-value store such as an 121 associative array to store the replacement cost information 122 configured by the operator. The key in this mechanism MUST be 123 represented by an actual prefix, typically a host route such a /32 in 124 IPv4 or a /128 for IPv6. The value stored to represent the nexthop 125 cost MUST be an unsigned integer with possible values of 0 to a 126 minimum of 2^32 to cover the maximum path metrics utilized by the 127 most widely deployed IGPs, such as OSPF [RFC2328] or IS-IS [RFC1195] 128 when utilizing wide metrics [RFC3784]. Implementations MAY support 129 maximum values up to 2^64 for a wider range of applications. 131 The implementation MAY choose to represent the operator input data 132 into the store directly in the router configuration or utilize a 133 separate storage mechanism to store the configured information, 134 however the implementation MUST persist this information through 135 router reload or other events regardless of local representation of 136 the data. An implementation MAY also provide a separate ephemeral 137 mechanism for this information that replaces information from the 138 persistent option, however no use case requiring this is discussed 139 further in the draft. Specifying the method for configuring these 140 values (for instance through CLI or NetConf/Yang) is out of the scope 141 of this draft. 143 3.2. Cost Replacement Mechanism 145 There are several implementation options for using the data in key- 146 value store described above to replace the BGP nexthop costs. These 147 are described in the sections below. 149 3.2.1. Simple Implementation Option 151 Upon finishing the computation of the SPF, or for non link-state 152 protocols, at any point upon which a route is due to be added or 153 updated in the routing information base (RIB), a lookup MUST be done 154 on the route in the key value store and the cost to the nexthop for 155 that prefix MUST be replaced by the value returned if one is 156 available. The implementation SHOULD provide a mechanism that allows 157 the operator to utilize either the nexthop replacement information or 158 the SPF or normal routing protocol derived cost. For instance an 159 implementation MAY do this by associating a different, operator 160 configurable, route preference with the routes created by the pseudo- 161 protocol versus the IGP protocol route preference. If the 162 replacement routes are installed into the RIB and Forwarding 163 Information Base (FIB) of the router, the associated Layer3 and 164 Layer2 information and any other adjacency information required to 165 forward on the route should be copied from the original route so that 166 traffic from the router itself is still forwarding correctly. 168 3.2.2. Alternative Implementation Option (for use with ORR) 170 In the case that the router performing the implementation described 171 in this document does not actually need to forward along the BGP 172 prefixes received (is out of band from a network traffic forwarding 173 standpoint) and has an implementation of BGP optimal route reflection 174 [I-D.ietf-idr-bgp-optimal-route-reflection] in place, the BGP nexthop 175 costs can be associated only with the decision made for the BGP 176 optimal route reflection group. The information in the local key- 177 value store could be used to replace directly the IGP costs from the 178 topology standpoint of the out of band router or the costs that would 179 have been computed from the virtual IGP placement configured by ORR. 180 In either of these cases, there is no need to actually place the 181 information in the RIB or FIB of the local router, if nexthop 182 information is stored only for the purpose of BGP bestpath 183 calculations, as it is not necessary for local decisions as long as 184 the appropriately configured BGP clients receive the appropriate 185 paths as a result from the BGP bestpath decision. 187 3.2.3. IGP Shortcuts Like Implementation Option 189 In some cases, operators may not find it sufficient to only replace 190 configured nexthop costs directly using the mechanism described 191 above. If the desire of the operator is to utilize the BGP pseudo- 192 protocol to mirror the operational BGP bestpath behavior of traffic 193 forwarding routers in the network that utilize RSVP-TE LSPs in 194 conjunction with a deployment of IGP Shortcuts [RFC3906], a more 195 complicated implementation approach can resolve such a use case. It 196 should be noted this implementation option is only required if in the 197 use case the operator utilizes an absolute or relative configured 198 metric for the on the RSVP-TE LSPs in question, and does not 199 dynamically derive the metrics to points beyond the tail-end of the 200 tunnel strictly from the IGP SPF cost to that prefix. In this 201 situation the implementation MAY attempt to come to same cost system 202 as this design requires by implementing a similar approach as 203 sections 4 through 6 of [RFC3906] describe but with the important 204 difference that the router running this implementation does not 205 actually have RSVP-TE LSPs configured. The way that they can 206 implement the approach is by considering at every node processed in 207 the SPF algorithm whether the key-value store contains an entry 208 representing the traffic engineering router id for that node (for 209 instance as described in Section 4.3 of [RFC5305] for IS-IS or for 210 OSPF, Section 3.4.1 of [RFC3630] or Section 3 of [RFC5329] for OSPFv2 211 and OSPFv3 respectively. If the key-value store does have such an 212 entry, the cost up to that step in the SPF algorithm should be 213 replaced with the value for that entry so the end result is that all 214 downstream derived costs are influenced by the replacement cost 215 looked up in the key-value store. This is similar in operation to 216 Section 5 of [RFC3906] with the same end result in respect to the 217 costs used by the BGP path selection process. 219 3.2.4. Handling Router Maintenance 221 Having a hard coded value that represents the cost to a prefix 222 negates the normal reaction of costs to network events and for the 223 most part this is the operator desired behavior when utilizing this 224 feature. However in the case where the prefix in question was sent 225 by a router that has been taken out of service from an IGP 226 standpoint, for instance by utilizing the IS-IS overload bit or by 227 configuring unusually high IGP costs, for instance as described in 228 [RFC6987], the operator's intentions are likely to be different in 229 respect to direct traffic to that prefix. To simplify the language, 230 this draft refers to any of these mechanisms as "overloading" the 231 router. To avoid utilizing the pseudo-protocol's costs in the case 232 of overloaded routers, an implementation MAY choose not to replace 233 the costs normally derived via the IGP (effectively ignoring the 234 existence of the entry in the key-value store) in the cases where 235 that entry represents a router or prefix which appears to be 236 overloaded. In the case of implementations that have the "IGP 237 Shortcuts Like Implementation" functionality, no cost replacements 238 should happen for any nodes beyond the node that appears to be 239 overloaded either. 241 4. Relationship to Other Work 243 The mechanism in this draft solves similar problems as those 244 described in BGP optimal route reflection 245 [I-D.ietf-idr-bgp-optimal-route-reflection] with the primary 246 differences being the source of the authoritative information for the 247 nexthop replacement cost information as well as the optional 248 implementation approach outlined for IGP Shortcut Like impact on 249 downstream routers. 251 Another draft aimed at similar use cases is 252 [I-D.ietf-idr-bgp-nh-cost] which currently proposes utilizing BGP-LS 253 to distribute next hop cost information from a controller or router 254 in the network to the router upon which cost manipulation may happen. 255 The primary difference between this draft and that is the reduced 256 protocol complexity. In networks that use absolute metrics on tunnel 257 infrastructure that influence BGP bestpath decisions, this 258 information is already typically centrally stored, so adding protocol 259 complexity necessary to send this information between routers and 260 then utilize that information received is not necessary for the 261 solution to be implemented. This draft does not require or propose 262 any BGP protocol extensions. Another advantage of this approach than 263 receiving the information from the client is the lack of delay as the 264 router doing the calculation is receiving SPF updates on a similar 265 timeframe as the client and is not waiting for it to finish the 266 calculation and then repackage the information after change into a 267 BGP-LS message to send to the out of band route reflector. 269 5. Security Considerations 271 The design does not introduce any additional security concerns. 272 General BGP security considerations are discussed in [RFC4271] and 273 [RFC4272]. 275 6. IANA Considerations 277 This document includes no request to IANA. 279 7. Acknowledgements 281 Thanks to Ina Minei for initial review of this document and helpful 282 suggestions. 284 8. References 286 8.1. Normative References 288 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 289 Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 290 10.17487/RFC4271, January 2006, 291 . 293 8.2. Informative References 295 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 296 dual environments", RFC 1195, DOI 10.17487/RFC1195, 297 December 1990, . 299 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/ 300 RFC2328, April 1998, 301 . 303 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 304 (TE) Extensions to OSPF Version 2", RFC 3630, DOI 305 10.17487/RFC3630, September 2003, 306 . 308 [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate 309 System (IS-IS) Extensions for Traffic Engineering (TE)", 310 RFC 3784, DOI 10.17487/RFC3784, June 2004, 311 . 313 [RFC3906] Shen, N. and H. Smit, "Calculating Interior Gateway 314 Protocol (IGP) Routes Over Traffic Engineering Tunnels", 315 RFC 3906, DOI 10.17487/RFC3906, October 2004, 316 . 318 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 319 4272, DOI 10.17487/RFC4272, January 2006, 320 . 322 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 323 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 324 2008, . 326 [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., 327 "Traffic Engineering Extensions to OSPF Version 3", RFC 328 5329, DOI 10.17487/RFC5329, September 2008, 329 . 331 [RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D. 332 McPherson, "OSPF Stub Router Advertisement", RFC 6987, DOI 333 10.17487/RFC6987, September 2013, 334 . 336 [I-D.ietf-idr-bgp-optimal-route-reflection] 337 Raszuk, R., Cassar, C., Aman, E., Decraene, B., and S. 338 Litkowski, "BGP Optimal Route Reflection (BGP-ORR)", 339 draft-ietf-idr-bgp-optimal-route-reflection-10 (work in 340 progress), July 2015. 342 [I-D.ietf-idr-bgp-nh-cost] 343 Varlashkin, I., Raszuk, R., Patel, K., Bhardwaj, M., and 344 S. Bayraktar, "Carrying next-hop cost information in BGP", 345 draft-ietf-idr-bgp-nh-cost-02 (work in progress), May 346 2015. 348 Author's Address 350 Jon Mitchell 352 Email: jrmitche@puck.nether.net