idnits 2.17.1 draft-keyupate-irs-bgp-usecases-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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([I-D.ward-irs-framework]), 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 == 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: o Avoid Unwanted Route Announcements. Filter prefixes that MUST not be routed [RFC5735], [RFC5156]. Filter prefixes that are not allocated by Internet Routing Registries. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 14, 2012) is 4205 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2629' is defined on line 413, but no explicit reference was found in the text == Unused Reference: 'RFC3392' is defined on line 416, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 419, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 423, but no explicit reference was found in the text == Unused Reference: 'RFC2858' is defined on line 445, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) ** Obsolete normative reference: RFC 3392 (Obsoleted by RFC 5492) == Outdated reference: A later version (-07) exists of draft-ietf-grow-ops-reqs-for-bgp-error-handling-05 -- Obsolete informational reference (is this intentional?): RFC 2858 (Obsoleted by RFC 4760) -- Obsolete informational reference (is this intentional?): RFC 5156 (Obsoleted by RFC 6890) -- Obsolete informational reference (is this intentional?): RFC 5735 (Obsoleted by RFC 6890) Summary: 4 errors (**), 0 flaws (~~), 9 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Patel 3 Internet-Draft Cisco Systems 4 Intended status: Informational H. Gredler 5 Expires: April 17, 2013 Juniper Networks 6 R. Fernando 7 Cisco Systems 8 S. Amante 9 Level 3 Communications, Inc. 10 October 14, 2012 12 Use Cases for an Interface to BGP Protocol 13 draft-keyupate-irs-bgp-usecases-00.txt 15 Abstract 17 A network routing protocol like BGP is typically configured and 18 results of its operation are analyzed through some form of Command 19 Line Interface (CLI) or NETCONF. These interactions to control BGP 20 and diagnose its operation encompass: configuration of protocol 21 parameters, display of protocol data, setting of certain protocol 22 states and debugging of the protocol. 24 Interface to the Routing System's (IRS) Programatic interfaces, as 25 defined in [I-D.ward-irs-framework], provides an alternate way to 26 control the configuration and diagnose the operation of the BGP 27 protocol. IRS may be used for the configuration, manipulation, 28 polling or analyzing protocol data. This document describes a set of 29 use cases for which IRS can be used for BGP protocol. It is indended 30 to provide a base for the solution draft descibring a set of 31 Interfaces to the BGP protocol. 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 17, 2013. 50 Copyright Notice 52 Copyright (c) 2012 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 This document may contain material from IETF Documents or IETF 66 Contributions published or made publicly available before November 67 10, 2008. The person(s) controlling the copyright in some of this 68 material may not have granted the IETF Trust the right to allow 69 modifications of such material outside the IETF Standards Process. 70 Without obtaining an adequate license from the person(s) controlling 71 the copyright in such materials, this document may not be modified 72 outside the IETF Standards Process, and derivative works of it may 73 not be created outside the IETF Standards Process, except to format 74 it for publication as an RFC or to translate it into languages other 75 than English. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 80 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 81 2. BGP Configuration . . . . . . . . . . . . . . . . . . . . . . 4 82 2.1. BGP Protocol Configuration . . . . . . . . . . . . . . . . 5 83 2.2. BGP Policy Configuration . . . . . . . . . . . . . . . . . 6 84 3. BGP Protocol Operation . . . . . . . . . . . . . . . . . . . . 8 85 3.1. BGP Error Handling for Internal BGP Sessions . . . . . . . 8 86 3.2. Tracing Dropped BGP Routes . . . . . . . . . . . . . . . . 8 87 4. BGP Route Manipulation . . . . . . . . . . . . . . . . . . . . 9 88 4.1. Customized Best Path Selection Criteria . . . . . . . . . 9 89 4.2. Flowspec Routes . . . . . . . . . . . . . . . . . . . . . 9 90 4.3. Route Filter Routes . . . . . . . . . . . . . . . . . . . 9 91 4.4. Optimised Exit Control . . . . . . . . . . . . . . . . . . 9 92 4.5. Offline Validation of Routes . . . . . . . . . . . . . . . 10 93 5. Registration . . . . . . . . . . . . . . . . . . . . . . . . . 10 94 5.1. Polling of Routing Events . . . . . . . . . . . . . . . . 10 95 5.2. Polling of Protocol Statistics . . . . . . . . . . . . . . 10 96 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 97 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 98 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 99 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 100 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 103 1. Introduction 105 Typically, a network routing protocol like BGP is configured and 106 results of its operation are analyzed through some form of Command 107 Line Interface (CLI) or NETCONF. These interactions to control BGP 108 and diagnose its operation encompass: configuration of protocol 109 parameters, display of protocol data, setting of certain protocol 110 states and debugging of the protocol. 112 The IRS Framework document [I-D.ward-irs-framework] describes a 113 mechanism to control network protocols like BGP using a set of 114 programmatic interfaces. These programmatic interfaces allow one to 115 control the BGP protocol by analyzing its operational state and 116 routing protocol data, plus manipulating BGP's configuration to 117 achieve various goals. The IRS is not intended to replace any 118 existing configuration mechanisms, (i.e.: Command Line Interface or 119 NETCONF). Instead, IRS is intended to augment those existing 120 mechanisms by defining a standardized set of programmatic interfaces 121 to enable easier configuration, interrogation and analysis of the BGP 122 protocol. 124 This document describes a set of use cases for which IRS's 125 programmatic interfaces can be used to control and analyze the 126 operation of BGP. The use cases described in this document cover the 127 following aspects of BGP: protocol parameter configuration, 128 configuration of routing policies, protocol route manipulation and 129 tracking of protocol events. The goal is to inform the community's 130 understanding of where the IRS BGP extensions fit within the overall 131 IRS architecture. It is indended to provide a basis for the 132 solutions draft descibring the set of Interfaces to the BGP protocol. 134 1.1. Requirements Language 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in RFC 2119 [RFC2119]. 140 2. BGP Configuration 142 The configuration of BGP is arduous to establish and maintain, 143 particularly on networks whose services have a requirement for 144 complex routing policies. This need is magnified by the need to 145 routinely perform changes to large numbers of BGP routers to, for 146 example: add or remove customer's BGP sessions, announce or withdraw 147 (customer) IP prefixes in BGP, modify BGP policies to effect changes 148 in Traffic Engineering, audit BGP routers to ensure they have 149 consistent and appropriate BGP policies, etc. 151 There are three categories of BGP configuration: 153 1. Local BGP routing protocol configuration: local Autonomous System 154 Number (ASN), BGP path selection properties of the router, 155 injection of (aggregate) routes into BGP, etc. 157 2. Local BGP policies: policies designed to filter and then 158 manipulate BGP attributes associated with BGP routes learned 159 through BGP sessions. These policies typically live in the 160 global configuration of a BGP router, but are applied on a per- 161 BGP neighbor basis (or, group of BGP neighbors); and, 163 3. BGP neighbor sessions: remote ASN, remote IP address, address 164 families, BGP policies to applied to routes, max-prefix limits, 165 etc. 167 The sum total of BGP configuration on a BGP router is typically the 168 largest quantify of configuration on Service Provider's BGP routers, 169 by a fairly large margin. When that is combined with the large set 170 of routine configuration changes, mentioned above, it should be 171 fairly clear that systematic reading, configuration and control of 172 BGP routers through a mechanism like IRS would greatly benefit all 173 operators of BGP routers. 175 While it may not be possible to provide programmatic APIs for 176 esoteric vendor-specific policy configuration, it is possible to 177 provide such API's for BGP protocol specific configuration and the 178 more commonly used BGP routing policies. 180 2.1. BGP Protocol Configuration 182 Ability to enable and disable new address families within a BGP 183 protocol for a network of BGP speaking routers is a challenge. The 184 challenge is mainly in keeping track of BGP speaker's feature 185 capabilities and then configuration of new address families on a 186 multiple BGP speakers within a given network. With the necessary 187 information, IRS controllers allow a network operator to push 188 configuration information for enabling and disabling of new address 189 families on a partial or entire set of BGP speakers within a given 190 network. This would assist in building BGP overlay networks as 191 needed. 193 For VPN address families, the main challenge lies in the complex VPN 194 configuration required to setup the control plane for Customer VPNs. 195 The configuration involves creating a Virtual Routing and Forwarding 196 instance (VRF), a Route Distinguisher (RD) that ensures each customer 197 prefixes remains unique across VPNs, and Route Targets (RT) that help 198 ensure that the Customer prefixes are segregated appropriately so 199 that they do not cross the VPN boundries. IRS would allow a network 200 operator to push such configuration from a central location where a 201 global VPN provisioning information could be stored. This helps 202 avoid manual configuration of a VPN on multiple routers. Instead the 203 configuration is controlled and pushed though a central IRS 204 controller using a programmatic set of APIs on targetted set of BGP 205 speakers. 207 Use of IRS controllers to announce protocol configuration information 208 would simplify and automate configuration of BGP protocol in IBGP 209 deployments where the protocol based policies are seldom used. To 210 facilitate such a centralized configuration model, BGP speakers could 211 be extended to use programmatic APIs to announce their feature 212 capabilities as part of protocol initialization to the centralize IRS 213 controllers. This would assist IRS controllers to auto-discover BGP 214 protocol capabilities of various BGP speakers in a given network. 215 IRS controllers inturn would use the information towards enabling/ 216 disabling of BGP specific features on BGP speakers. 218 2.2. BGP Policy Configuration 220 Filtering of BGP routes is strongly recommended to control the 221 announcements of BGP prefixes across the internet. Most providers 222 make extensive use of BGP prefix filtering policies at the edge of 223 their networks. The reasons for filtering BGP prefixes are: 225 o Avoid Unwanted Route Announcements. Filter prefixes that MUST not 226 be routed [RFC5735], [RFC5156]. Filter prefixes that are not 227 allocated by Internet Routing Registries. 229 o Facilitate Route Summarization. Filter prefixes beyond certain 230 agreed prefix mask length between providers. Route Summarization 231 helps control BGP RIB and FIB table size. 233 o Defensive Security. Filter prefixes from Stub customer ASes that 234 are not owned by the customers. Filter customer prefixes 235 announced by other providers. This helps avoid prefix hijacking. 237 A set of standards-based schemas to enable configuration of Local BGP 238 policies and BGP neighbor sessions was realized through the Routing 239 Policy Specification Language (RSPL) [RFC2622]. The RPSL defined a 240 standards-based schemas, or 'objects' as it called them, that 241 defined: 243 o binding of IP prefixes to (one or more) Origin AS, (route 244 objects); 246 o collections of routes (route-set objects); 248 o collections of Autonomous Systems (as-set objects); and, 250 o routing policy of an Autonomous System to/from its adjacent 251 neighbor AS'es, (aut-num objects) 253 Each ASN is responsible for creation, modification and deletion of 254 its RPSL objects in an Internet Routing Registry (IRR). IRR's are 255 typically operated by Regional Internet Registries (RIR's) and a few 256 dozen larger ISP's and independent organizations. The IRR's provide 257 a well-known location for all organizations attached to the Internet 258 to retrieve or update RPSL objects. 260 While still widely and actively used by Internet Service Providers, 261 the prevailing belief is that the data contained in the IRR's is 262 inaccurate, primarily due to a lack of deployed authorization method 263 with respect to the creation of modification of RPSL objects. It 264 should be noted that this criticism is not directed at the previously 265 defined RPSL schemas, but rather at the data contained in RPSL 266 schemas by end-users of the IRR system. Please refer to the IRR & 267 Routing Policy Configuration Considerations 268 [I-D.mcpherson-irr-routing-policy-considerations] document for a more 269 thorough discussion of the history and present state of the IRR's. 271 Currently, RPSL schemas are exchanged between non-routing systems 272 (servers) used within the IRR system. In addition, open-source and 273 proprietary applications create or modify RPSL schemas, as necessary, 274 to signal the announcement (or, withdrawl) of an IP prefix from an 275 ASN or the creation (or, teardown) of a neighbor relationship between 276 two adjacent ASN's. Most importantly, these RPSL schemas are 277 consumed by similar applications to automatically build routing 278 polcies, (i.e.: lists of IP prefixes, corresponding Origin ASN's 279 and/or AS_PATH's), that then get translated to device-specific syntax 280 (i.e.: CLI) before being pushed into individual BGP routers to effect 281 routing policy on the network. It is common for Internet Service 282 Providers to perform updates to these routing policies across their 283 entire network on a daily basis. 285 With IRS it would be desirable to change the last step in the above 286 process so that BGP policies derived from RPSL schemas, and other 287 information sources, are translated into standards-based schemas that 288 are then pushed, or pulled, into individual BGP routers. More 289 generally, IRS controllers could use API's to gather information 290 required to build various types of BGP routing policies plus the 291 corresponding set of Autonomous System Border Routers (ASBR's) where 292 such policies need to be applied in the network and, finally, making 293 those changes to individual network elements so those BGP policies 294 take effect in the network. In doing so, a network operator now has 295 a centralized way of building and making these policies take effect 296 across the network in a coordinated manner. 298 3. BGP Protocol Operation 300 It is increasingly common for services facilitated via BGP to be 301 subject to severe, widespread disruptions (outages), primarily due to 302 the destructive teardown of BGP sessions as a result of receiving 303 malformed BGP attributes. The document Operational Requirements for 304 Enhanced Error Handling Behaviour in BGP-4 305 [I-D.ietf-grow-ops-reqs-for-bgp-error-handling] outlines requirements 306 to try to minimize the scope of the impact attributed to such errors. 307 Unfortunately, more fine-grained BGP error handling solutions, which 308 would result in little to no impact on the operation of BGP protocol, 309 remain elusive. 311 3.1. BGP Error Handling for Internal BGP Sessions 313 It is possible that IRS could enable enhanced error handling 314 techniques for Internal BGP sessions. At a minimum, IRS-capable BGP 315 routers could signal an event such as "Malformed Attribute Received" 316 toward an IRS controller(s). IRS controller(s) may already have a 317 real-time view of BGP routes, and corresponding BGP attributes, or 318 may dynamically interrogate BGP routers in the network to identify 319 the present propagation scope of the BGP route(s) that are affected. 320 Finally, the IRS controller(s) could then signal back to BGP routers 321 to apply a filter that would block propagation of the BGP attribtue 322 or BGP route, as necessary, in order to temporarily aid in 323 consistency of BGP routing information across the entire network 324 until a permanent fix can be developed and deployed within BGP 325 routers. 327 IRS would enable the global visibility and global control over the 328 operational state of BGP, within a given Autonomous System, that are 329 necessary to faciliate the learning of, rapid response to and more 330 fine-grained isolation/scoping of BGP protocol events that currently 331 cause a destructive tear-down of BGP sessions that lead to widespread 332 disruptions of services. 334 3.2. Tracing Dropped BGP Routes 336 It is extremely useful to operators to be able to rapidly identify 337 instances where a BGP route is not being propagated within an 338 Autonomous System. At a minimum, this could result in sub-optimal 339 performance when attempting to reach such destinations. 341 There are two instances when this scenario will occur. First, when a 342 Service Provider is using "Soft Reconfiguration Inbound", it allows 343 their ASBR routers to receive a copy of a BGP route, but show that 344 route was not permitted into the Adj-RIB-In most likely as a result 345 of the inbound BGP policy not permitting that IP prefix. Thus, this 346 BGP route is not even eligible for BGP Path Selection. The second 347 instance is where the BGP route is permitted by the inbound BGP 348 policy into the Adj-RIB-In, but due to BGP Path Selection (i.e.: 349 lower LOCAL_PREF, longer AS_PATH length, etc.) was not chosen as the 350 best path and, subsequently, this particular BGP route is not 351 forwarded on to other internal BGP speakers in the AS. In both 352 instances, the BGP route is only visible within the ASBR on which 353 that BGP route was first learned. Needless to say, in large Service 354 Provider networks with a numerous interconnects to a single customer 355 it can be very time-consuming to discover where such a BGP route is 356 learned before ultimately determining why the route was blocked or 357 not preferred. 359 With IRS, it would be possible for an IRS controller to rapidly 360 gather information from across a large set of BGP routers in the 361 network to determine at what ASBR's the BGP route is being learned. 362 Next, the IRS controller could interrogate those routers BGP policies 363 to determine the root cause of why the route was either not learned 364 or not preferred in BGP. Finally, if necessary, the IRS 365 controller(s) could amend BGP policies and push them out to BGP 366 routers to permit the BGP route or make it a preferred route 367 according to the BGP path selection algorithm. 369 4. BGP Route Manipulation 371 4.1. Customized Best Path Selection Criteria 373 4.2. Flowspec Routes 375 Installation of flow spec filters on RR and let RRs flood it within 376 the network 378 4.3. Route Filter Routes 380 Installation of RT filters on RR ?? 382 4.4. Optimised Exit Control 384 This is really a bgp feature. One could tweak BGP parameters to 385 ensure optimized bgp paths/exit points are chosen 387 4.5. Offline Validation of Routes 389 5. Registration 391 5.1. Polling of Routing Events 393 5.2. Polling of Protocol Statistics 395 6. Security Considerations 397 7. Acknowledgements 399 TBD. 401 8. References 403 8.1. Normative References 405 [I-D.ward-irs-framework] 406 Atlas, A., Nadeau, T., and D. Ward, "Interface to the 407 Routing System Framework", draft-ward-irs-framework-00 408 (work in progress), July 2012. 410 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 411 Requirement Levels", BCP 14, RFC 2119, March 1997. 413 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 414 June 1999. 416 [RFC3392] Chandra, R. and J. Scudder, "Capabilities Advertisement 417 with BGP-4", RFC 3392, November 2002. 419 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 420 Text on Security Considerations", BCP 72, RFC 3552, 421 July 2003. 423 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 424 Protocol 4 (BGP-4)", RFC 4271, January 2006. 426 8.2. Informative References 428 [I-D.ietf-grow-ops-reqs-for-bgp-error-handling] 429 Shakir, R., "Operational Requirements for Enhanced Error 430 Handling Behaviour in BGP-4", 431 draft-ietf-grow-ops-reqs-for-bgp-error-handling-05 (work 432 in progress), July 2012. 434 [I-D.mcpherson-irr-routing-policy-considerations] 435 McPherson, D., Amante, S., Osterweil, E., and L. Blunk, 436 "IRR & Routing Policy Configuration Considerations", 437 draft-mcpherson-irr-routing-policy-considerations-01 (work 438 in progress), September 2012. 440 [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., 441 Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, 442 "Routing Policy Specification Language (RPSL)", RFC 2622, 443 June 1999. 445 [RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, 446 "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. 448 [RFC5156] Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156, 449 April 2008. 451 [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", 452 BCP 153, RFC 5735, January 2010. 454 Authors' Addresses 456 Keyur Patel 457 Cisco Systems 458 170 W. Tasman Drive 459 San Jose, CA 95134 460 USA 462 Email: keyupate@cisco.com 464 Hannes Gredler 465 Juniper Networks 466 1194 N. Mathilda Ave 467 Sunnyvale, CA 94089 468 USA 470 Email: hannes@juniper.net 471 Rex Fernando 472 Cisco Systems 473 170 W. Tasman Drive 474 San Jose, CA 95134 475 USA 477 Email: rex@cisco.com 479 Shane Amante 480 Level 3 Communications, Inc. 481 1025 Eldorado Blvd 482 Broomfield, CO 80021 483 USA 485 Email: shane@level3.net