idnits 2.17.1 draft-keyupate-i2rs-bgp-usecases-02.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.) 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 (June 4, 2014) is 3607 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2629' is defined on line 534, but no explicit reference was found in the text == Unused Reference: 'RFC3392' is defined on line 537, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 540, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 544, but no explicit reference was found in the text == Unused Reference: 'RFC2858' is defined on line 577, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-i2rs-architecture-03 ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) ** Obsolete normative reference: RFC 3392 (Obsoleted by RFC 5492) == Outdated reference: A later version (-13) exists of draft-ietf-grow-bgp-gshut-05 == Outdated reference: A later version (-04) exists of draft-white-grow-overlapping-routes-01 -- 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: 3 errors (**), 0 flaws (~~), 11 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2RS K. Patel 3 Internet-Draft R. Fernando 4 Intended status: Informational Cisco Systems 5 Expires: December 6, 2014 H. Gredler 6 Juniper Networks 7 S. Amante 8 Level 3 Communications, Inc. 9 R. White 10 Ericsson 11 S. Hares 12 Hickory Hill Consulting 13 June 4, 2014 15 Use Cases for an Interface to BGP Protocol 16 draft-keyupate-i2rs-bgp-usecases-02.txt 18 Abstract 20 A network routing protocol like BGP is typically configured and 21 analyzed through some form of Command Line Interface (CLI) or 22 NETCONF. These interactions to control BGP and diagnose its 23 operation encompass: configuration of protocol parameters, display of 24 protocol data, setting of certain protocol state and debugging of the 25 protocol. 27 Interface to the Routing System's (I2RS) Programmatic interfaces, as 28 defined in draft-ietf-i2rs-architecture, provides an alternate way to 29 control and diagnose the operation of the BGP protocol. I2RS may be 30 used for the configuration, manipulation, analyzing or collecting the 31 protocol data. This document describes set of use cases for which 32 I2RS can be used for BGP protocol. It is intended to provide a base 33 for the solution draft describing a set of interfaces to the BGP 34 protocol. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on December 6, 2014. 53 Copyright Notice 55 Copyright (c) 2014 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 This document may contain material from IETF Documents or IETF 69 Contributions published or made publicly available before November 70 10, 2008. The person(s) controlling the copyright in some of this 71 material may not have granted the IETF Trust the right to allow 72 modifications of such material outside the IETF Standards Process. 73 Without obtaining an adequate license from the person(s) controlling 74 the copyright in such materials, this document may not be modified 75 outside the IETF Standards Process, and derivative works of it may 76 not be created outside the IETF Standards Process, except to format 77 it for publication as an RFC or to translate it into languages other 78 than English. 80 Table of Contents 82 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 83 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 84 2. BGP Protocol Operation . . . . . . . . . . . . . . . . . . . 4 85 2.1. BGP Error Handling for Internal BGP Sessions . . . . . . 4 86 3. BGP Route Manipulation . . . . . . . . . . . . . . . . . . . 4 87 3.1. Customized Best Path Selection Criteria . . . . . . . . . 5 88 3.2. Flowspec Routes . . . . . . . . . . . . . . . . . . . . . 5 89 3.3. Route Filter Routes for Legacy Routers . . . . . . . . . 6 90 3.4. Optimized Exit Control . . . . . . . . . . . . . . . . . 6 91 4. BGP Events . . . . . . . . . . . . . . . . . . . . . . . . . 6 92 4.1. Notification of Routing Events . . . . . . . . . . . . . 7 93 4.2. Tracing Dropped BGP Routes . . . . . . . . . . . . . . . 8 94 4.3. BGP Protocol Statistics . . . . . . . . . . . . . . . . . 8 95 5. Central membership computation for MPLS based VPNs . . . . . 9 96 6. Marking Overlapping Traffic Engineering Routes for Removal . 11 97 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 98 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 99 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 100 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 101 9.2. Informative References . . . . . . . . . . . . . . . . . 12 102 Appendix A. BGP Configuration . . . . . . . . . . . . . . . . . 13 103 A.1. BGP Protocol Configuration . . . . . . . . . . . . . . . 14 104 A.2. BGP Policy Configuration . . . . . . . . . . . . . . . . 15 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 107 1. Introduction 109 Typically, a network routing protocol like BGP is configured and 110 results of its operation are analyzed through some form of Command 111 Line Interface (CLI) or NETCONF. These interactions to control BGP 112 and diagnose its operation encompass: configuration of protocol 113 parameters, display of protocol data, setting of certain protocol 114 state and debugging of the protocol. 116 The I2RS architecture document [I-D.ietf-i2rs-architecture] describes 117 a mechanism to control network protocols like BGP using a set of 118 programmatic interfaces. These programmatic interfaces allow one to 119 control the BGP protocol by analyzing its operational state and 120 routing protocol data, plus manipulating BGP's configuration to 121 achieve various goals. The I2RS is not intended to replace any 122 existing configuration mechanisms, (i.e.: Command Line Interface or 123 NETCONF). Instead, I2RS is intended to augment those existing 124 mechanisms by defining a standardized set of programmatic interfaces 125 to enable easier configuration, interrogation and analysis of the BGP 126 protocol. 128 This document describes set of use cases for which I2RS's 129 programmatic interfaces can be used to control and analyze the 130 operation of BGP. The use cases described in this document cover the 131 following aspects of BGP: protocol parameter configuration, protocol 132 route manipulation and tracking of protocol events. The goal is to 133 inform the community's understanding of where the I2RS BGP extensions 134 fit within the overall I2RS architecture. It is intended to provide 135 a basis for the solutions draft describing the set of Interfaces to 136 the BGP protocol. 138 1.1. Requirements Language 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in RFC 2119 [RFC2119]. 144 2. BGP Protocol Operation 146 It is increasingly common for services facilitated via BGP to be 147 subject to severe, widespread disruptions (outages), primarily due to 148 the destructive teardown of BGP sessions as a result of receiving 149 malformed BGP attributes. Unfortunately, more fine-grained BGP error 150 handling solutions, which would result in little to no impact on the 151 operation of BGP protocol, remain elusive. 153 A planned Graceful must also carefully be handled to limit the amount 154 of traffic loss during a the shutdown. While operational 155 requirements for the BGP mechanism for graceful shutdown of a (set 156 of) BGP sessions is describe din [RFC6198], and the operational 157 procedures are described in [I-D.ietf-grow-bgp-gshut], additional 158 fine-grained BGP error handling could improve graceful shutdown of 159 BGP sessions. 161 This section discussed how I2RS information could improve both the 162 destructive teardown and the graceful teardown of sessions. 164 2.1. BGP Error Handling for Internal BGP Sessions 166 It is possible that I2RS could enable enhanced error handling 167 techniques for Internal BGP sessions. At a minimum, I2RS-capable BGP 168 routers could signal an event such as "Malformed Attribute Received" 169 toward an I2RS client(s). I2RS clients(s) may already have a real- 170 time view of BGP routes, and corresponding BGP attributes, or may 171 dynamically interrogate BGP routers in the network to identify the 172 present propagation scope of the BGP route(s) that are affected. 173 Finally, the I2RS client(s) could then signal back to BGP routers to 174 apply a filter that would block propagation of the BGP attribute or 175 BGP route, as necessary, in order to temporarily aid in consistency 176 of BGP routing information across the entire network until a 177 permanent fix can be developed and deployed within BGP routers. 179 I2RS would enable the global visibility and global control over the 180 operational state of BGP, within a given Autonomous System, that is 181 necessary to facilitate the learning of, rapid response to and more 182 fine-grained isolation/scoping of BGP protocol events that currently 183 cause a destructive tear-down of BGP sessions that lead to widespread 184 disruptions of services. 186 3. BGP Route Manipulation 188 Multiprotocol BGP [RFC4760] provides support to carry routing 189 information for different BGP address families. Route manipulation 190 is heavily done across these different address families for different 191 reasons. BGP IPv4 and IPv6 address families use BGP Communities 193 [RFC1997] and other IBGP and EBGP attributes to manipulate BGP routes 194 for Traffic Engineering purpose. BGP VPN adddress families use 195 Extended Communities [RFC4360] to filter unwanted BGP routes. BGP 196 Flowspec address family [RFC5575] is used to install Flow based 197 filters to filter unwanted data traffic. The following sub-sections 198 describe the use of IRS towards BGP Route Manipulation for different 199 BGP address families. 201 3.1. Customized Best Path Selection Criteria 203 The BGP customized Bestpath facilitates custom bestpath computations 204 within a BGP speaking network. It is usually used within an IBGP 205 network. Customized bestpaths use special extended communities known 206 as cost communities. Cost communities carry enough information; 207 Point of Insertion (POI) and the cost value to signal where in BGP 208 bestpath the customize checks need to be done. Both, the traffic 209 engineering as well as backdoor (SHAM) links use customized bestpath 210 computation. 212 With I2RS, it would be possible for an I2RS client to push routes 213 with custom cost communities on the BGP routers for Traffic 214 Engineering purpose. I2RS client now can act as a central entity 215 keeping track of all Traffic engineering data that get applied to BGP 216 routes within an IBGP network. 218 3.2. Flowspec Routes 220 The BGP flowspec address family is used to disseminate the traffic 221 flow specification to the BGP Autonomous System Border Routers 222 (ASBRs) and Provider Edge (PE) routers. Both, the BGP ASBRs and the 223 PEs would translate the received BGP traffic flow specification into 224 an Access Control List (ACL) and install it in router's forwarding 225 path. Using such ACLs routers can now classify, shape, rate limit, 226 filter, or redirect traffic flows. 228 With I2RS, it would be possible for an I2RS client to push traffic 229 flow specifications to the BGP ASBRs and the PE routers. I2RS client 230 can act as a central entity tracking all the traffic flow 231 specifications that are installed within an IBGP network. I2RS 232 client could also prioritize and control the announcement of traffic 233 flow specifications according to various ASRBs and PE router's 234 capacity. BGP ASBRs and PE routers MAY forward traffic flow 235 specifications received from EBGP speakers to I2RS Agents. This 236 would allow I2RS agents to centrally manage and track any externally 237 received traffic flow specifications. 239 3.3. Route Filter Routes for Legacy Routers 241 The BGP Route Filter address family is used to disseminate the Route 242 Target filter information between VPN BGP speakers. This information 243 is then used to build a route distribution graph that helps in 244 limiting the propagation of VPN NLRI within a VPN network. However, 245 it requires that all the BGP VPN routers are upgraded to support this 246 functionality. Otherwise, the graph information is incomplete when a 247 VPN network consists of legacy routers that participates in VPN but 248 does not implement the BGP route filter address family. 250 With I2RS, it would be possible for an I2RS client to push router 251 filter information to BGP RR routers on behalf of all legacy routers 252 that participates in VPN but does not support or implement the BGP 253 route filter address family. I2RS client can act as a central entity 254 tracking all the configured Route Filters for legacy routers and push 255 them on appropriate RRs who in turn would push it to ASBRs and PE 256 routers. In this way, I2RS agents help build an optimal route 257 distribution graph that would assist in filtering of VPN NLRIs in a 258 VPN network. 260 3.4. Optimized Exit Control 262 Optimized Exit Control is used to provide route optimization and load 263 distribution for multiple network connections between networks. 264 Network operators can monitor IP traffic flows and then could define 265 policies and rules based on traffic class performance, link bandwidth 266 monetary costs, link load distribution, traffic types, link failures, 267 etc. 269 With I2RS, it would be possible for an I2RS client to manipulate BGP 270 routes and its parameters that influence BGP bestpath decisions. 271 I2RS client could act as a central entity that would monitor and 272 manipulate BGP routes based on central network based policies. Such 273 routes would then be injected by a I2RS client into the network so as 274 to get the load distribution for multiple network connections. 276 4. BGP Events 278 Given the extremely large number of BGP Routes in networks, it is 279 critical to have scalable mechanisms that can be used to monitor for 280 events affecting routing state and, consequently, reachability. In 281 addition, similar tools are needed in order to monitor BGP protocol 282 statistics, which help operators and developers better understand 283 scalability of software and hardware that BGP utilizes. 285 I2RS could provide a publish-subscribe capability to applications to: 287 o request monitoring of BGP routes and related events; and, 289 o subscribe to the I2RS client to receive events related to BGP 290 routes or other protocol-related events of interest. 292 4.1. Notification of Routing Events 294 There are certain IP prefixes, for example those that are arbitrarily 295 classified by a given network operator as "high visibility" by its 296 end-users, for which immediate notification of changes in their state 297 are extremely useful to know about. Upon notification of such 298 events, a Network Operations Center (NOC) could respond to customer 299 inquiries in a more timely fashion; alternatively, the NOC may decide 300 to perform Traffic Engineering to restore service, etc. 302 Currently, the only way to learn of such events is for a BGP 303 monitoring system to establish a BGP session with a multitude of BGP 304 routers in an AS. Then, the BGP monitoring system needs to look 305 through all BGP UPDATE's in order to identify those events that are 306 of interest to it. Note, this doesn't account for the fact that 307 there are several applications that might be simultaneously 308 interested in learning of events to a given IP prefix nor the fact 309 that some applications may want to dynamically insert or remove "IP 310 prefixes of interest", depending on the needs of their constituent 311 applications. 313 With I2RS, it is conceivable that applications could tell an I2RS 314 client, through a North-Bound API, their "IP prefixes" (or, 315 AS_PATH's, BGP communities, etc.) that are of interest. For example, 316 a NOC application may be interested in changes to high visibility 317 content or service-provider Web sites; alternatively, a security 318 application may be interested in events associated with a different 319 set of IP prefixes. The I2RS client would then consolidate the list 320 of IP prefixes, and associated characteristics, to be monitored and 321 program BGP routers in an AS to observe this subset of routes for 322 changes. Some examples of changes in routing state might include: 324 o an IP prefix being announced or withdrawn 326 o an IP prefix being suppressed, due to route flap dampening 328 o an alternative best-path being chosen for a given IP prefix 330 When the requisite events for a BGP Route are observed by a BGP 331 router, it would notify I2RS agents. 333 The I2RS agents would have a publish/subscribe mechanism whereby 334 various sets of applications may subscribe to events of interest. 336 The I2RS client would then publish these events so applications would 337 immediately receive them and take the appropriate domain-specific 338 action necessary. 340 4.2. Tracing Dropped BGP Routes 342 It is extremely useful to operators to be able to rapidly identify 343 instances where a BGP route is not being propagated within an 344 Autonomous System. At a minimum, this could result in sub-optimal 345 performance when attempting to reach such destinations. 347 There are two instances when this scenario will occur. First, when a 348 Service Provider is using "Soft Reconfiguration Inbound", it allows 349 their ASBR routers to receive a copy of a BGP route, but show that 350 route was not permitted into the Adj-RIB-In most likely as a result 351 of the inbound BGP policy not permitting that IP prefix. Thus, this 352 BGP route is not even eligible for BGP Path Selection. The second 353 instance is where the BGP route is permitted by the inbound BGP 354 policy into the Adj-RIB-In, but due to BGP Path Selection (i.e.: 355 lower LOCAL_PREF, longer AS_PATH length, etc.) was not chosen as the 356 best path and, subsequently, this particular BGP route is not 357 forwarded on to other internal BGP speakers in the AS. In both 358 instances, the BGP route is only visible within the ASBR on which 359 that BGP route was first learned. Needless to say, in large Service 360 Provider networks with a numerous interconnects to a single customer 361 it can be very time-consuming to discover where such a BGP route is 362 learned before ultimately determining why the route was blocked or 363 not preferred. 365 With I2RS, it would be possible for an I2RS client to rapidly gather 366 information from across a large set of BGP routers in the network to 367 determine at what ASBR's the BGP route is being learned. Next, the 368 I2RS client could interrogate those routers BGP policies to determine 369 the root cause of why the route was either not learned or not 370 preferred in BGP. Finally, if necessary, the I2RS client(s) could 371 amend BGP policies and push them out to BGP routers to permit the BGP 372 route or make it a preferred route according to the BGP path 373 selection algorithm. 375 4.3. BGP Protocol Statistics 377 There are a variety of statistics related to the operation of BGP 378 that are invaluable to network operators. These statistics generally 379 help operators, and developers, understand the present state and 380 future scalability of BGP. 382 One statistic that is invaluable to operators is the current number 383 of BGP routes learned through an eBGP session. Operators then apply 384 a command against each eBGP session to limit the maximum number of 385 BGP routes that may be learned through that eBGP session before a 386 warning message is triggered and/or the eBGP session is torn down 387 completely. This configuration capability is often referred to as a 388 "max-prefix limit". This command must be routinely audited and, if 389 necessary, adjusted in order to not trigger a false warning or 390 teardown due to the natural organic growth in BGP routes learned from 391 a given BGP neighbor. 393 I2RS agents could provide an invaluable capability to help audit and 394 re-program the "max-prefix limit" on a periodic basis, which is 395 generally once per day. Specifically, the first task would be for an 396 I2RS client to validate that there is a "max-prefix limit" applied to 397 every eBGP session. (If there is not, that should either trigger a 398 red alarm to the NOC to manually fix this condition or for the I2RS 399 client to automatically apply a "max-prefix limit" that would 400 alleviate this hazardous condition). Assuming there is a "max-prefix 401 limit" already in place, the I2RS client would simultaneously 402 retrieve, from each BGP router, the current number of BGP routes 403 learned through a BGP session and value used for the "max-prefix 404 limit" on that same BGP session. These two values could then be 405 handed off to an application that determines if adjustments in the 406 "max-prefix limit" value are required for each BGP session. The 407 application would then notify the I2RS client of the subset of eBGP 408 sessions and their associated change in "max-prefix limit" value, 409 whereby the I2RS client would then adjust the BGP protocol 410 configuration on each requisite BGP router in the network. Finally, 411 it should be noted that the above is just one method whereby "max- 412 prefix limit" values are adjusted. It's similarly possible that the 413 BGP routers may, through the I2RS, pull the "max-prefix limit" values 414 for each eBGP neighbor they have on-board on a periodic basis and 415 validate their accuracy. 417 The above is just one use case related to BGP protocol statistics. 418 There are wealth of other BGP protocol statistics or state 419 information that would be invaluable to have programmatic visibility 420 into that operators do not have today. 422 5. Central membership computation for MPLS based VPNs 424 MPLS based VPNs use route target extended communities to express 425 membership information. Every PE router holds incoming BGP NLRI and 426 processes them to determine membership and then import the NLRI into 427 the appropriate MPLS/VPN routing tables. This consumes resources, 428 both memory and compute on each of the PE devices. 430 An alternative approach is to monitor routing updates on every PE 431 from the attached CEs and then compute membership in a central 432 manner. Once computed the routes are pushed to the VPN RIBs of the 433 participating PEs. 435 This centralization of membership control has a few advantages. 437 o The membership mechanism (route-targets) need not be configured in 438 each of the PEs and can be expressed once centrally. 440 o No resources in the PEs need to be spent to categorize routes into 441 the VRF tables that they belong and to filter out unwanted state. 443 o Doing it centrally means the availability of almost unlimited 444 compute capacity to compute membership and hence can be done in a 445 scaleable manner. 447 o More sophisticated routing policies and filters can be applied 448 during the central import/export process than can be expressed and 449 performed using the traditional route target mechanism. 451 o Routes can be selectively pushed only to the participating PE's 452 further reducing the memory load on the individual routers in the 453 network. This further obviates for a distributed mechanisms such 454 as rt constraints to reduce unnecessary path state in the routers. 456 Note that centrally computation of membership can be applied to other 457 scenarios as well such as VPLS, MVPNs, MAC VPNs and others. 458 Depending on the scenario, what gets monitored from the CE might 459 vary. Central computation will especially help VPLS where multi- 460 homing and load balancing using distributed techniques has 461 particularly been a challenge. 463 Also note that one of the biggest promises of central route 464 computation is simplification and reduction of computation and memory 465 load on all devices in the network. This use case is just one 466 example that illustrates these benefits of central computation very 467 well. 469 Summary of I2RS Capabilities and Interactions: 471 o The ability to read the loc-RIB-In BGP table that gets all the 472 routes that the CE has provided to a PE router. 474 o The ability to install destination based routes in the local RIB 475 of the PE devices. This must include the ability to supply the 476 destination prefix (NLRI), a table identifier, a route preference, 477 a route metric, a next-hop tunnel through which traffic would be 478 carried 480 6. Marking Overlapping Traffic Engineering Routes for Removal 482 It is often the case that routes are advertised not to provide 483 reachability (in the strict sense), but rather to provide optimal 484 reachability, or to engineer the path traffic takes to a particular 485 destination. While this can improve the efficiency of a network's 486 operation, it can also increase the amount of state carried in the 487 control plane beyond the point where the additional state has any 488 real effect on traffic flow. Removing Overlapping Routes 489 [I-D.white-grow-overlapping-routes] provides a mechanism designed to 490 remove these traffic engineering routes once they are beyond the 491 point of actually impacting traffic flows in the network. 493 Summary of I2RS Capabilities and Interactions: 495 o The ability to read the loc-RIB-in BGP table to discover 496 overlapping routes, and determine which may be safely marked for 497 removal. 499 o The ability to modify filtering rules and initiate a re- 500 computation of the local BGP table through those policies to cause 501 specific routes to be marked for removal at the outbound eBGP 502 edge. 504 7. Security Considerations 506 The BGP use cases described in this document assumes use of I2RS 507 programmatic interfaces described in the I2RS framework mentioned in 508 [I-D.ietf-i2rs-architecture]. This document does not change the 509 underlying security issues inherent in the existing in 510 [I-D.ietf-i2rs-architecture]. 512 8. Acknowledgements 514 The authors would like to thank Ed Crabbe, Joel Halpern, Wes George, 515 Carlos Pignataro, Jon Mitchell and Bill Atwood for their comments and 516 suggestions. 518 9. References 520 9.1. Normative References 522 [I-D.ietf-i2rs-architecture] 523 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 524 Nadeau, "An Architecture for the Interface to the Routing 525 System", draft-ietf-i2rs-architecture-03 (work in 526 progress), May 2014. 528 [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP 529 Communities Attribute", RFC 1997, August 1996. 531 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 532 Requirement Levels", BCP 14, RFC 2119, March 1997. 534 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 535 June 1999. 537 [RFC3392] Chandra, R. and J. Scudder, "Capabilities Advertisement 538 with BGP-4", RFC 3392, November 2002. 540 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 541 Text on Security Considerations", BCP 72, RFC 3552, July 542 2003. 544 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 545 Protocol 4 (BGP-4)", RFC 4271, January 2006. 547 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 548 Communities Attribute", RFC 4360, February 2006. 550 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 551 "Multiprotocol Extensions for BGP-4", RFC 4760, January 552 2007. 554 9.2. Informative References 556 [I-D.ietf-grow-bgp-gshut] 557 Francois, P., Decraene, B., Pelsser, C., Patel, K., and C. 558 Filsfils, "Graceful BGP session shutdown", draft-ietf- 559 grow-bgp-gshut-05 (work in progress), January 2014. 561 [I-D.mcpherson-irr-routing-policy-considerations] 562 McPherson, D., Amante, S., Osterweil, E., and L. Blunk, 563 "IRR & Routing Policy Configuration Considerations", 564 draft-mcpherson-irr-routing-policy-considerations-01 (work 565 in progress), September 2012. 567 [I-D.white-grow-overlapping-routes] 568 White, R., Retana, A., and S. Hares, "Filtering of 569 Overlapping Routes", draft-white-grow-overlapping- 570 routes-01 (work in progress), February 2013. 572 [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., 573 Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, 574 "Routing Policy Specification Language (RPSL)", RFC 2622, 575 June 1999. 577 [RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, 578 "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. 580 [RFC5156] Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156, 581 April 2008. 583 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 584 and D. McPherson, "Dissemination of Flow Specification 585 Rules", RFC 5575, August 2009. 587 [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", 588 RFC 5735, January 2010. 590 [RFC6198] Decraene, B., Francois, P., Pelsser, C., Ahmad, Z., 591 Elizondo Armengol, A., and T. Takeda, "Requirements for 592 the Graceful Shutdown of BGP Sessions", RFC 6198, April 593 2011. 595 Appendix A. BGP Configuration 597 The configuration of BGP is arduous to establish and maintain, 598 particularly on networks whose services have a requirement for 599 complex routing policies. This need is magnified by the need to 600 routinely perform changes to large numbers of BGP routers to, for 601 example: add or remove customer's BGP sessions, announce or withdraw 602 (customer) IP prefixes in BGP, modify BGP policies to effect changes 603 in Traffic Engineering, audit BGP routers to ensure they have 604 consistent and appropriate BGP policies, and others. 606 There are three categories of BGP configuration: 608 1. Local BGP routing protocol configuration: local Autonomous System 609 Number (ASN), BGP path selection properties of the router, 610 injection of (aggregate) routes into BGP, etc. 612 2. Local BGP policies: policies designed to filter and/or manipulate 613 BGP attributes associated with BGP routes learned through BGP 614 sessions. These policies typically live in the global 615 configuration of a BGP router, but are applied on a per-BGP 616 neighbor basis (or, group of BGP neighbors); and, 618 3. BGP neighbor sessions: remote ASN, remote IP address, address 619 families, BGP policies to applied to routes, max-prefix limits, 620 etc. 622 The sum total of BGP configuration on a BGP router is typically the 623 largest quantify of configuration on Service Provider's BGP routers, 624 by a fairly large margin. When that is combined with the large set 625 of routine configuration changes, mentioned above, it should be 626 fairly clear that systematic reading, configuration and control of 627 BGP routers through a mechanism like I2RS would greatly benefit all 628 operators of BGP routers. 630 While it may not be possible to provide programmatic APIs for 631 esoteric vendor-specific policy configuration, it is possible to 632 provide such API's for BGP protocol specific configuration and the 633 more commonly used BGP routing policies. 635 A.1. BGP Protocol Configuration 637 Ability to enable and disable new address families within a BGP 638 protocol for a network of BGP speaking routers is a challenge. The 639 challenge is mainly in keeping track of BGP speaker's feature 640 capabilities and then configuration of new address families on a 641 multiple BGP speakers within a given network. With the necessary 642 information, I2RS agents allow a network operator to push 643 configuration information for enabling and disabling of new address 644 families on a partial or entire set of BGP speakers within a given 645 network. This would assist in building BGP overlay networks as 646 needed. 648 For VPN address families, the main challenge lies in the complex VPN 649 configuration required to setup the control plane for Customer VPNs. 650 The configuration involves creating a Virtual Routing and Forwarding 651 instance (VRF), a Route Distinguisher (RD) that ensures each customer 652 prefixes remains unique across VPNs, and Route Targets (RT) that help 653 ensure that the Customer prefixes are segregated appropriately so 654 that they do not cross the VPN boundaries. I2RS would allow a 655 network operator to push such configuration from a central location 656 where a global VPN provisioning information could be stored. This 657 helps avoid manual configuration of a VPN on multiple routers. 658 Instead the configuration is controlled and pushed though a central 659 I2RS client using a programmatic set of APIs on targeted set of BGP 660 speakers. 662 Use of I2RS agents to announce protocol configuration information 663 would simplify and automate configuration of BGP protocol in IBGP 664 deployments where the protocol based policies are seldom used. To 665 facilitate such a centralized configuration model, BGP speakers could 666 be extended to use programmatic APIs to announce their feature 667 capabilities as part of protocol initialization to the centralize 668 I2RS agents. This would assist I2RS agents to auto-discover BGP 669 protocol capabilities of various BGP speakers in a given network. 670 I2RS agents in turn would use the information towards enabling/ 671 disabling of BGP specific features on BGP speakers. 673 A.2. BGP Policy Configuration 675 Filtering of BGP routes is strongly recommended to control the 676 announcements of BGP prefixes across the internet. Most providers 677 make extensive use of BGP prefix filtering policies at the edge of 678 their networks. The reasons for filtering BGP prefixes are: 680 o Avoid Unwanted Route Announcements. Filter prefixes that MUST not 681 be routed [RFC5735], [RFC5156]. Filter prefixes that are not 682 allocated by Internet Routing Registries. 684 o Facilitate Route Summarization. Filter prefixes beyond certain 685 agreed prefix mask length between providers. Route Summarization 686 helps control BGP RIB and FIB table size. 688 o Defensive Security. Filter prefixes from Stub customer ASes that 689 are not owned by the customers. Filter customer prefixes 690 announced by other providers. This helps avoid prefix hijacking. 692 A set of standards-based schemas to enable configuration of Local BGP 693 policies and BGP neighbor sessions was realized through the Routing 694 Policy Specification Language (RSPL) [RFC2622]. The RPSL defined a 695 standards-based schemas, or 'objects' as it called them, that 696 defined: 698 o binding of IP prefixes to (one or more) Origin AS, (route 699 objects); 701 o collections of routes (route-set objects); 703 o collections of Autonomous Systems (as-set objects); and, 705 o routing policy of an Autonomous System to/from its adjacent 706 neighbor AS'es, (aut-num objects) 708 Each ASN is responsible for creation, modification and deletion of 709 its RPSL objects in an Internet Routing Registry (IRR). IRR's are 710 typically operated by Regional Internet Registries (RIR's) and a few 711 dozen larger ISP's and independent organizations. The IRR's provide 712 a well-known location for all organizations attached to the Internet 713 to retrieve or update RPSL objects. 715 While still widely and actively used by Internet Service Providers, 716 the prevailing belief is that the data contained in the IRR's is 717 inaccurate, primarily due to a lack of deployed authorization method 718 with respect to the creation of modification of RPSL objects. It 719 should be noted that this criticism is not directed at the previously 720 defined RPSL schemas, but rather at the data contained in RPSL 721 schemas by end-users of the IRR system. Please refer to the IRR And 722 Routing Policy Configuration Considerations 723 [I-D.mcpherson-irr-routing-policy-considerations] document for a more 724 thorough discussion of the history and present state of the IRR's. 726 Currently, RPSL schemas are exchanged between non-routing systems 727 (servers) used within the IRR system. In addition, open-source and 728 proprietary applications create or modify RPSL schemas, as necessary, 729 to signal the announcement (or, withdrawal) of an IP prefix from an 730 ASN or the creation (or, teardown) of a neighbor relationship between 731 two adjacent ASN's. Most importantly, these RPSL schemas are 732 consumed by similar applications to automatically build routing 733 policies, (i.e.: lists of IP prefixes, corresponding Origin ASN's 734 and/or AS_PATH's), that then get translated to device-specific syntax 735 (i.e.: CLI) before being pushed into individual BGP routers to effect 736 routing policy on the network. It is common for Internet Service 737 Providers to perform updates to these routing policies across their 738 entire network on a daily basis. 740 With I2RS it would be desirable to change the last step in the above 741 process so that BGP policies derived from RPSL schemas, and other 742 information sources, are translated into standards-based schemas that 743 are then pushed, or pulled, into individual BGP routers. More 744 generally, I2RS agents could use API's to gather information required 745 to build various types of BGP routing policies plus the corresponding 746 set of Autonomous System Border Routers (ASBR's) where such policies 747 need to be applied in the network and, finally, making those changes 748 to individual network elements so those BGP policies take effect in 749 the network. In doing so, a network operator now has a centralized 750 way of building and making these policies take effect across the 751 network in a coordinated manner. 753 Authors' Addresses 755 Keyur Patel 756 Cisco Systems 757 170 W. Tasman Drive 758 San Jose, CA 95134 759 USA 761 Email: keyupate@cisco.com 762 Rex Fernando 763 Cisco Systems 764 170 W. Tasman Drive 765 San Jose, CA 95134 766 USA 768 Email: rex@cisco.com 770 Hannes Gredler 771 Juniper Networks 772 1194 N. Mathilda Ave 773 Sunnyvale, CA 94089 774 USA 776 Email: hannes@juniper.net 778 Shane Amante 779 Level 3 Communications, Inc. 780 1025 Eldorado Blvd 781 Broomfield, CO 80021 782 USA 784 Email: shane@level3.net 786 Russ White 787 Ericsson 789 Email: russw@riw.us 791 Susan Hares 792 Hickory Hill Consulting 794 Email: shares@ndzh.com