idnits 2.17.1 draft-keyupate-irs-bgp-usecases-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 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 22, 2012) is 4176 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2629' is defined on line 595, but no explicit reference was found in the text == Unused Reference: 'RFC3392' is defined on line 598, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 601, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 605, but no explicit reference was found in the text == Unused Reference: 'RFC2858' is defined on line 634, 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 5575 (Obsoleted by RFC 8955) -- Obsolete informational reference (is this intentional?): RFC 5735 (Obsoleted by RFC 6890) Summary: 4 errors (**), 0 flaws (~~), 9 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Patel 3 Internet-Draft R. Fernando 4 Intended status: Informational Cisco Systems 5 Expires: April 25, 2013 H. Gredler 6 Juniper Networks 7 S. Amante 8 Level 3 Communications, Inc. 9 October 22, 2012 11 Use Cases for an Interface to BGP Protocol 12 draft-keyupate-irs-bgp-usecases-01.txt 14 Abstract 16 A network routing protocol like BGP is typically configured and 17 results of its operation are analyzed through some form of Command 18 Line Interface (CLI) or NETCONF. These interactions to control BGP 19 and diagnose its operation encompass: configuration of protocol 20 parameters, display of protocol data, setting of certain protocol 21 state and debugging of the protocol. 23 Interface to the Routing System's (IRS) Programmatic interfaces, as 24 defined in [I-D.ward-irs-framework], provides an alternate way to 25 control the configuration and diagnose the operation of the BGP 26 protocol. IRS may be used for the configuration, manipulation, 27 polling or analyzing protocol data. This document describes set of 28 use cases for which IRS can be used for BGP protocol. It is intended 29 to provide a base for the solution draft describing a set of 30 interfaces to the BGP protocol. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on April 25, 2013. 49 Copyright Notice 51 Copyright (c) 2012 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 This document may contain material from IETF Documents or IETF 65 Contributions published or made publicly available before November 66 10, 2008. The person(s) controlling the copyright in some of this 67 material may not have granted the IETF Trust the right to allow 68 modifications of such material outside the IETF Standards Process. 69 Without obtaining an adequate license from the person(s) controlling 70 the copyright in such materials, this document may not be modified 71 outside the IETF Standards Process, and derivative works of it may 72 not be created outside the IETF Standards Process, except to format 73 it for publication as an RFC or to translate it into languages other 74 than English. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 79 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 80 2. BGP Configuration . . . . . . . . . . . . . . . . . . . . . . 4 81 2.1. BGP Protocol Configuration . . . . . . . . . . . . . . . . 5 82 2.2. BGP Policy Configuration . . . . . . . . . . . . . . . . . 6 83 3. BGP Protocol Operation . . . . . . . . . . . . . . . . . . . . 8 84 3.1. BGP Error Handling for Internal BGP Sessions . . . . . . . 8 85 4. BGP Route Manipulation . . . . . . . . . . . . . . . . . . . . 8 86 4.1. Customized Best Path Selection Criteria . . . . . . . . . 9 87 4.2. Flowspec Routes . . . . . . . . . . . . . . . . . . . . . 9 88 4.3. Route Filter Routes for Legacy Routers . . . . . . . . . . 10 89 4.4. Optimized Exit Control . . . . . . . . . . . . . . . . . . 10 90 5. BGP Events . . . . . . . . . . . . . . . . . . . . . . . . . . 10 91 5.1. Notification of Routing Events . . . . . . . . . . . . . . 11 92 5.2. Tracing Dropped BGP Routes . . . . . . . . . . . . . . . . 12 93 5.3. BGP Protocol Statistics . . . . . . . . . . . . . . . . . 12 94 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 95 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 96 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 97 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 98 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 101 1. Introduction 103 Typically, a network routing protocol like BGP is configured and 104 results of its operation are analyzed through some form of Command 105 Line Interface (CLI) or NETCONF. These interactions to control BGP 106 and diagnose its operation encompass: configuration of protocol 107 parameters, display of protocol data, setting of certain protocol 108 state and debugging of the protocol. 110 The IRS Framework document [I-D.ward-irs-framework] describes a 111 mechanism to control network protocols like BGP using a set of 112 programmatic interfaces. These programmatic interfaces allow one to 113 control the BGP protocol by analyzing its operational state and 114 routing protocol data, plus manipulating BGP's configuration to 115 achieve various goals. The IRS is not intended to replace any 116 existing configuration mechanisms, (i.e.: Command Line Interface or 117 NETCONF). Instead, IRS is intended to augment those existing 118 mechanisms by defining a standardized set of programmatic interfaces 119 to enable easier configuration, interrogation and analysis of the BGP 120 protocol. 122 This document describes set of use cases for which IRS's programmatic 123 interfaces can be used to control and analyze the operation of BGP. 124 The use cases described in this document cover the following aspects 125 of BGP: protocol parameter configuration, configuration of routing 126 policies, protocol route manipulation and tracking of protocol 127 events. The goal is to inform the community's understanding of where 128 the IRS BGP extensions fit within the overall IRS architecture. It 129 is intended to provide a basis for the solutions draft describing the 130 set of Interfaces to the BGP protocol. 132 1.1. Requirements Language 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in RFC 2119 [RFC2119]. 138 2. BGP Configuration 140 The configuration of BGP is arduous to establish and maintain, 141 particularly on networks whose services have a requirement for 142 complex routing policies. This need is magnified by the need to 143 routinely perform changes to large numbers of BGP routers to, for 144 example: add or remove customer's BGP sessions, announce or withdraw 145 (customer) IP prefixes in BGP, modify BGP policies to effect changes 146 in Traffic Engineering, audit BGP routers to ensure they have 147 consistent and appropriate BGP policies, etc. 149 There are three categories of BGP configuration: 151 1. Local BGP routing protocol configuration: local Autonomous System 152 Number (ASN), BGP path selection properties of the router, 153 injection of (aggregate) routes into BGP, etc. 155 2. Local BGP policies: policies designed to filter and then 156 manipulate BGP attributes associated with BGP routes learned 157 through BGP sessions. These policies typically live in the 158 global configuration of a BGP router, but are applied on a per- 159 BGP neighbor basis (or, group of BGP neighbors); and, 161 3. BGP neighbor sessions: remote ASN, remote IP address, address 162 families, BGP policies to applied to routes, max-prefix limits, 163 etc. 165 The sum total of BGP configuration on a BGP router is typically the 166 largest quantify of configuration on Service Provider's BGP routers, 167 by a fairly large margin. When that is combined with the large set 168 of routine configuration changes, mentioned above, it should be 169 fairly clear that systematic reading, configuration and control of 170 BGP routers through a mechanism like IRS would greatly benefit all 171 operators of BGP routers. 173 While it may not be possible to provide programmatic APIs for 174 esoteric vendor-specific policy configuration, it is possible to 175 provide such API's for BGP protocol specific configuration and the 176 more commonly used BGP routing policies. 178 2.1. BGP Protocol Configuration 180 Ability to enable and disable new address families within a BGP 181 protocol for a network of BGP speaking routers is a challenge. The 182 challenge is mainly in keeping track of BGP speaker's feature 183 capabilities and then configuration of new address families on a 184 multiple BGP speakers within a given network. With the necessary 185 information, IRS controllers allow a network operator to push 186 configuration information for enabling and disabling of new address 187 families on a partial or entire set of BGP speakers within a given 188 network. This would assist in building BGP overlay networks as 189 needed. 191 For VPN address families, the main challenge lies in the complex VPN 192 configuration required to setup the control plane for Customer VPNs. 193 The configuration involves creating a Virtual Routing and Forwarding 194 instance (VRF), a Route Distinguisher (RD) that ensures each customer 195 prefixes remains unique across VPNs, and Route Targets (RT) that help 196 ensure that the Customer prefixes are segregated appropriately so 197 that they do not cross the VPN boundaries. IRS would allow a network 198 operator to push such configuration from a central location where a 199 global VPN provisioning information could be stored. This helps 200 avoid manual configuration of a VPN on multiple routers. Instead the 201 configuration is controlled and pushed though a central IRS 202 controller using a programmatic set of APIs on targeted set of BGP 203 speakers. 205 Use of IRS controllers to announce protocol configuration information 206 would simplify and automate configuration of BGP protocol in IBGP 207 deployments where the protocol based policies are seldom used. To 208 facilitate such a centralized configuration model, BGP speakers could 209 be extended to use programmatic APIs to announce their feature 210 capabilities as part of protocol initialization to the centralize IRS 211 controllers. This would assist IRS controllers to auto-discover BGP 212 protocol capabilities of various BGP speakers in a given network. 213 IRS controllers in turn would use the information towards enabling/ 214 disabling of BGP specific features on BGP speakers. 216 2.2. BGP Policy Configuration 218 Filtering of BGP routes is strongly recommended to control the 219 announcements of BGP prefixes across the internet. Most providers 220 make extensive use of BGP prefix filtering policies at the edge of 221 their networks. The reasons for filtering BGP prefixes are: 223 o Avoid Unwanted Route Announcements. Filter prefixes that MUST not 224 be routed [RFC5735], [RFC5156]. Filter prefixes that are not 225 allocated by Internet Routing Registries. 227 o Facilitate Route Summarization. Filter prefixes beyond certain 228 agreed prefix mask length between providers. Route Summarization 229 helps control BGP RIB and FIB table size. 231 o Defensive Security. Filter prefixes from Stub customer ASes that 232 are not owned by the customers. Filter customer prefixes 233 announced by other providers. This helps avoid prefix hijacking. 235 A set of standards-based schemas to enable configuration of Local BGP 236 policies and BGP neighbor sessions was realized through the Routing 237 Policy Specification Language (RSPL) [RFC2622]. The RPSL defined a 238 standards-based schemas, or 'objects' as it called them, that 239 defined: 241 o binding of IP prefixes to (one or more) Origin AS, (route 242 objects); 244 o collections of routes (route-set objects); 246 o collections of Autonomous Systems (as-set objects); and, 248 o routing policy of an Autonomous System to/from its adjacent 249 neighbor AS'es, (aut-num objects) 251 Each ASN is responsible for creation, modification and deletion of 252 its RPSL objects in an Internet Routing Registry (IRR). IRR's are 253 typically operated by Regional Internet Registries (RIR's) and a few 254 dozen larger ISP's and independent organizations. The IRR's provide 255 a well-known location for all organizations attached to the Internet 256 to retrieve or update RPSL objects. 258 While still widely and actively used by Internet Service Providers, 259 the prevailing belief is that the data contained in the IRR's is 260 inaccurate, primarily due to a lack of deployed authorization method 261 with respect to the creation of modification of RPSL objects. It 262 should be noted that this criticism is not directed at the previously 263 defined RPSL schemas, but rather at the data contained in RPSL 264 schemas by end-users of the IRR system. Please refer to the IRR And 265 Routing Policy Configuration Considerations 266 [I-D.mcpherson-irr-routing-policy-considerations] document for a more 267 thorough discussion of the history and present state of the IRR's. 269 Currently, RPSL schemas are exchanged between non-routing systems 270 (servers) used within the IRR system. In addition, open-source and 271 proprietary applications create or modify RPSL schemas, as necessary, 272 to signal the announcement (or, withdrawal) of an IP prefix from an 273 ASN or the creation (or, teardown) of a neighbor relationship between 274 two adjacent ASN's. Most importantly, these RPSL schemas are 275 consumed by similar applications to automatically build routing 276 policies, (i.e.: lists of IP prefixes, corresponding Origin ASN's 277 and/or AS_PATH's), that then get translated to device-specific syntax 278 (i.e.: CLI) before being pushed into individual BGP routers to effect 279 routing policy on the network. It is common for Internet Service 280 Providers to perform updates to these routing policies across their 281 entire network on a daily basis. 283 With IRS it would be desirable to change the last step in the above 284 process so that BGP policies derived from RPSL schemas, and other 285 information sources, are translated into standards-based schemas that 286 are then pushed, or pulled, into individual BGP routers. More 287 generally, IRS controllers could use API's to gather information 288 required to build various types of BGP routing policies plus the 289 corresponding set of Autonomous System Border Routers (ASBR's) where 290 such policies need to be applied in the network and, finally, making 291 those changes to individual network elements so those BGP policies 292 take effect in the network. In doing so, a network operator now has 293 a centralized way of building and making these policies take effect 294 across the network in a coordinated manner. 296 3. BGP Protocol Operation 298 It is increasingly common for services facilitated via BGP to be 299 subject to severe, widespread disruptions (outages), primarily due to 300 the destructive teardown of BGP sessions as a result of receiving 301 malformed BGP attributes. The document Operational Requirements for 302 Enhanced Error Handling Behaviour in BGP-4 303 [I-D.ietf-grow-ops-reqs-for-bgp-error-handling] outlines requirements 304 to try to minimize the scope of the impact attributed to such errors. 305 Unfortunately, more fine-grained BGP error handling solutions, which 306 would result in little to no impact on the operation of BGP protocol, 307 remain elusive. 309 3.1. BGP Error Handling for Internal BGP Sessions 311 It is possible that IRS could enable enhanced error handling 312 techniques for Internal BGP sessions. At a minimum, IRS-capable BGP 313 routers could signal an event such as "Malformed Attribute Received" 314 toward an IRS controller(s). IRS controller(s) may already have a 315 real-time view of BGP routes, and corresponding BGP attributes, or 316 may dynamically interrogate BGP routers in the network to identify 317 the present propagation scope of the BGP route(s) that are affected. 318 Finally, the IRS controller(s) could then signal back to BGP routers 319 to apply a filter that would block propagation of the BGP attribute 320 or BGP route, as necessary, in order to temporarily aid in 321 consistency of BGP routing information across the entire network 322 until a permanent fix can be developed and deployed within BGP 323 routers. 325 IRS would enable the global visibility and global control over the 326 operational state of BGP, within a given Autonomous System, that is 327 necessary to facilitate the learning of, rapid response to and more 328 fine-grained isolation/scoping of BGP protocol events that currently 329 cause a destructive tear-down of BGP sessions that lead to widespread 330 disruptions of services. 332 4. BGP Route Manipulation 334 Multiprotocol BGP [RFC4760] provides support to carry routing 335 information for different BGP address families. Route manipulation 336 is heavily done across these different address families for different 337 reasons. BGP IPv4 and IPv6 address families use BGP Communities 339 [RFC1997] and other IBGP and EBGP attributes to manipulate BGP routes 340 for Traffic Engineering purpose. BGP VPN adddress families use 341 Extended Communities [RFC4360] to filter unwanted BGP routes. BGP 342 Flowspec address family [RFC5575] is used to install Flow based 343 filters to filter unwanted data traffic. The following sub-sections 344 describe the use of IRS towards BGP Route Manipulation for different 345 BGP address families. 347 4.1. Customized Best Path Selection Criteria 349 The BGP customized Bestpath facilitates custom bestpath computations 350 within a BGP speaking network. It is usually used within an IBGP 351 network. Customized bestpaths use special extended communities known 352 as cost communities. Cost communities carry enough information; 353 Point of Insertion (POI) and the cost value to signal where in BGP 354 bestpath the customize checks need to be done. Both, the traffic 355 engineering as well as backdoor (SHAM) links use customized bestpath 356 computation. 358 With IRS, it would be possible for an IRS controller to push routes 359 with custom cost communities on the BGP routers for Traffic 360 Engineering purpose. IRS controller now can act as a central entity 361 keeping track of all Traffic engineering data that get applied to BGP 362 routes within an IBGP network. 364 4.2. Flowspec Routes 366 The BGP flowspec address family is used to disseminate the traffic 367 flow specification to the BGP Autonomous System Border Routers 368 (ASBRs) and Provider Edge (PE) routers. Both, the BGP ASBRs and the 369 PEs would translate the received BGP traffic flow specification into 370 an Access Control List (ACL) and install it in router's forwarding 371 path. Using such ACLs routers can now classify, shape, rate limit, 372 filter, or redirect traffic flows. 374 With IRS, it would be possible for an IRS controller to push traffic 375 flow specifications to the BGP ASBRs and the PE routers. IRS 376 controller can act as a central entity tracking all the traffic flow 377 specifications that are installed within an IBGP network. IRS 378 controller could also prioritize and control the announcement of 379 traffic flow specifications according to various ASRBs and PE 380 router's capacity. BGP ASBRs and PE routers MAY forward traffic flow 381 specifications received from EBGP speakers to IRS Controllers. This 382 would allow IRS controllers to centrally manage and track any 383 externally received traffic flow specifications. 385 4.3. Route Filter Routes for Legacy Routers 387 The BGP Route Filter address family is used to disseminate the Route 388 Target filter information between VPN BGP speakers. This information 389 is then used to build a route distribution graph that helps in 390 limiting the propagation of VPN NLRI within a VPN network. However, 391 it requires that all the BGP VPN routers are upgraded to support this 392 functionality. Otherwise, the graph information is incomplete when a 393 VPN network consists of legacy routers that participates in VPN but 394 does not implement the BGP route filter address family. 396 With IRS, it would be possible for an IRS controller to push router 397 filter information to BGP RR routers on behalf of all legacy routers 398 that participates in VPN but does not support or implement the BGP 399 route filter address family. IRS controller can act as a central 400 entity tracking all the configured Route Filters for legacy routers 401 and push them on appropriate RRs who in turn would push it to ASBRs 402 and PE routers. In this way, IRS controllers help build an optimal 403 route distribution graph that would assist in filtering of VPN NLRIs 404 in a VPN network. 406 4.4. Optimized Exit Control 408 Optimized Exit Control is used to provide route optimization and load 409 distribution for multiple network connections between networks. 410 Network operators can monitor IP traffic flows and then could define 411 policies and rules based on traffic class performance, link bandwidth 412 monetary costs, link load distribution, traffic types, link failures, 413 etc. 415 With IRS, it would be possible for an IRS controller to manipulate 416 BGP routes and its parameters that influence BGP bestpath decisions. 417 IRS controller could act as a central entity that would monitor and 418 manipulate BGP routes based on central network based policies. Such 419 routes would then be injected by a IRS controller into the network so 420 as to get the load distribution for multiple network connections. 422 5. BGP Events 424 Given the extremely large number of BGP Routes in networks, it is 425 critical to have scalable mechanisms that can be used to monitor for 426 events affecting routing state and, consequently, reachability. In 427 addition, similar tools are needed in order to monitor BGP protocol 428 statistics, which help operators and developers better understand 429 scalability of software and hardware that BGP utilizes. 431 IRS could provide a publish-subscribe capability to applications to: 433 o request monitoring of BGP routes and related events; and, 435 o subscribe to the IRS controller to receive events related to BGP 436 routes or other protocol-related events of interest. 438 5.1. Notification of Routing Events 440 There are certain IP prefixes, for example those that are arbitrarily 441 classified by a given network operator as "high visibility" by its 442 end-users, for which immediate notification of changes in their state 443 are extremely useful to know about. Upon notification of such 444 events, a Network Operations Center (NOC) could respond to customer 445 inquiries in a more timely fashion; alternatively, the NOC may decide 446 to perform Traffic Engineering to restore service, etc. 448 Currently, the only way to learn of such events is for a BGP 449 monitoring system to establish a BGP session with a multitude of BGP 450 routers in an AS. Then, the BGP monitoring system needs to look 451 through all BGP UPDATE's in order to identify those events that are 452 of interest to it. Note, this doesn't account for the fact that 453 there are several applications that might be simultaneously 454 interested in learning of events to a given IP prefix nor the fact 455 that some applications may want to dynamically insert or remove "IP 456 prefixes of interest", depending on the needs of their constituent 457 applications. 459 With IRS, it is conceivable that applications could tell an IRS 460 controller, through a North-Bound API, their "IP prefixes" (or, 461 AS_PATH's, BGP communities, etc.) that are of interest. For example, 462 a NOC application may be interested in changes to high visibility 463 content or service-provider Web sites; alternatively, a security 464 application may be interested in events associated with a different 465 set of IP prefixes. The IRS controller would then consolidate the 466 list of IP prefixes, and associated characteristics, to be monitored 467 and program BGP routers in an AS to observe this subset of routes for 468 changes. Some examples of changes in routing state might include: 470 o an IP prefix being announced or withdrawn 472 o an IP prefix being suppressed, due to route flap dampening 474 o an alternative best-path being chosen for a given IP prefix 476 When the requisite events for a BGP Route are observed by a BGP 477 router, it would notify IRS controllers. 479 The IRS controllers would have a publish/subscribe mechanism whereby 480 various sets of applications may subscribe to events of interest. 482 The IRS controller would then publish these events so applications 483 would immediately receive them and take the appropriate domain- 484 specific action necessary. 486 5.2. Tracing Dropped BGP Routes 488 It is extremely useful to operators to be able to rapidly identify 489 instances where a BGP route is not being propagated within an 490 Autonomous System. At a minimum, this could result in sub-optimal 491 performance when attempting to reach such destinations. 493 There are two instances when this scenario will occur. First, when a 494 Service Provider is using "Soft Reconfiguration Inbound", it allows 495 their ASBR routers to receive a copy of a BGP route, but show that 496 route was not permitted into the Adj-RIB-In most likely as a result 497 of the inbound BGP policy not permitting that IP prefix. Thus, this 498 BGP route is not even eligible for BGP Path Selection. The second 499 instance is where the BGP route is permitted by the inbound BGP 500 policy into the Adj-RIB-In, but due to BGP Path Selection (i.e.: 501 lower LOCAL_PREF, longer AS_PATH length, etc.) was not chosen as the 502 best path and, subsequently, this particular BGP route is not 503 forwarded on to other internal BGP speakers in the AS. In both 504 instances, the BGP route is only visible within the ASBR on which 505 that BGP route was first learned. Needless to say, in large Service 506 Provider networks with a numerous interconnects to a single customer 507 it can be very time-consuming to discover where such a BGP route is 508 learned before ultimately determining why the route was blocked or 509 not preferred. 511 With IRS, it would be possible for an IRS controller to rapidly 512 gather information from across a large set of BGP routers in the 513 network to determine at what ASBR's the BGP route is being learned. 514 Next, the IRS controller could interrogate those routers BGP policies 515 to determine the root cause of why the route was either not learned 516 or not preferred in BGP. Finally, if necessary, the IRS 517 controller(s) could amend BGP policies and push them out to BGP 518 routers to permit the BGP route or make it a preferred route 519 according to the BGP path selection algorithm. 521 5.3. BGP Protocol Statistics 523 There are a variety of statistics related to the operation of BGP 524 that are invaluable to network operators. These statistics generally 525 help operators, and developers, understand the present state and 526 future scalability of BGP. 528 One statistic that is invaluable to operators is the current number 529 of BGP routes learned through an eBGP session. Operators then apply 530 a command against each eBGP session to limit the maximum number of 531 BGP routes that may be learned through that eBGP session before a 532 warning message is triggered and/or the eBGP session is torn down 533 completely. This configuration capability is often referred to as a 534 "max-prefix limit". This command must be routinely audited and, if 535 necessary, adjusted in order to not trigger a false warning or 536 teardown due to the natural organic growth in BGP routes learned from 537 a given BGP neighbor. 539 IRS controllers could provide an invaluable capability to help audit 540 and re-program the "max-prefix limit" on a periodic basis, which is 541 generally once per day. Specifically, the first task would be for an 542 IRS controller to validate that there is a "max-prefix limit" applied 543 to every eBGP session. (If there is not, that should either trigger 544 a red alarm to the NOC to manually fix this condition or for the IRS 545 controller to automatically apply a "max-prefix limit" that would 546 alleviate this hazardous condition). Assuming there is a "max-prefix 547 limit" already in place, the IRS controller would simultaneously 548 retrieve, from each BGP router, the current number of BGP routes 549 learned through a BGP session and value used for the "max-prefix 550 limit" on that same BGP session. These two values could then be 551 handed off to an application that determines if adjustments in the 552 "max-prefix limit" value are required for each BGP session. The 553 application would then notify the IRS controller of the subset of 554 eBGP sessions and their associated change in "max-prefix limit" 555 value, whereby the IRS controller would then adjust the BGP protocol 556 configuration on each requisite BGP router in the network. Finally, 557 it should be noted that the above is just one method whereby "max- 558 prefix limit" values are adjusted. It's similarly possible that the 559 BGP routers may, through the IRS, pull the "max-prefix limit" values 560 for each eBGP neighbor they have onboard on a periodic basis and 561 validate their accuracy. 563 The above is just one use case related to BGP protocol statistics. 564 There are wealth of other BGP protocol statistics or state 565 informatioin that would be invaluable to have programmatic visibility 566 into that operators do not have today. 568 6. Security Considerations 570 The BGP use cases described in this document assumes use of IRS's 571 programmatic interfaces described in the IRS framework mentioned in 572 [I-D.ward-irs-framework]. This document does not change the 573 underlying security issues inherent in the existing 574 [I-D.ward-irs-framework]. 576 7. Acknowledgements 578 TBD. 580 8. References 582 8.1. Normative References 584 [I-D.ward-irs-framework] 585 Atlas, A., Nadeau, T., and D. Ward, "Interface to the 586 Routing System Framework", draft-ward-irs-framework-00 587 (work in progress), July 2012. 589 [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP 590 Communities Attribute", RFC 1997, August 1996. 592 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 593 Requirement Levels", BCP 14, RFC 2119, March 1997. 595 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 596 June 1999. 598 [RFC3392] Chandra, R. and J. Scudder, "Capabilities Advertisement 599 with BGP-4", RFC 3392, November 2002. 601 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 602 Text on Security Considerations", BCP 72, RFC 3552, 603 July 2003. 605 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 606 Protocol 4 (BGP-4)", RFC 4271, January 2006. 608 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 609 Communities Attribute", RFC 4360, February 2006. 611 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 612 "Multiprotocol Extensions for BGP-4", RFC 4760, 613 January 2007. 615 8.2. Informative References 617 [I-D.ietf-grow-ops-reqs-for-bgp-error-handling] 618 Shakir, R., "Operational Requirements for Enhanced Error 619 Handling Behaviour in BGP-4", 620 draft-ietf-grow-ops-reqs-for-bgp-error-handling-05 (work 621 in progress), July 2012. 623 [I-D.mcpherson-irr-routing-policy-considerations] 624 McPherson, D., Amante, S., Osterweil, E., and L. Blunk, 625 "IRR & Routing Policy Configuration Considerations", 626 draft-mcpherson-irr-routing-policy-considerations-01 (work 627 in progress), September 2012. 629 [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., 630 Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, 631 "Routing Policy Specification Language (RPSL)", RFC 2622, 632 June 1999. 634 [RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, 635 "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. 637 [RFC5156] Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156, 638 April 2008. 640 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 641 and D. McPherson, "Dissemination of Flow Specification 642 Rules", RFC 5575, August 2009. 644 [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", 645 BCP 153, RFC 5735, January 2010. 647 Authors' Addresses 649 Keyur Patel 650 Cisco Systems 651 170 W. Tasman Drive 652 San Jose, CA 95134 653 USA 655 Email: keyupate@cisco.com 657 Rex Fernando 658 Cisco Systems 659 170 W. Tasman Drive 660 San Jose, CA 95134 661 USA 663 Email: rex@cisco.com 664 Hannes Gredler 665 Juniper Networks 666 1194 N. Mathilda Ave 667 Sunnyvale, CA 94089 668 USA 670 Email: hannes@juniper.net 672 Shane Amante 673 Level 3 Communications, Inc. 674 1025 Eldorado Blvd 675 Broomfield, CO 80021 676 USA 678 Email: shane@level3.net