idnits 2.17.1 draft-keyupate-idr-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == 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 (March 21, 2016) is 2956 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'REQnn' is mentioned on line 152, but not defined == Unused Reference: 'RFC2629' is defined on line 750, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 754, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 759, but no explicit reference was found in the text == Unused Reference: 'RFC5492' is defined on line 768, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-i2rs-architecture-09 == Outdated reference: A later version (-03) exists of draft-ietf-i2rs-usecase-reqs-summary-01 ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) == Outdated reference: A later version (-13) exists of draft-ietf-grow-bgp-gshut-06 == Outdated reference: A later version (-04) exists of draft-white-grow-overlapping-routes-03 -- Obsolete informational reference (is this intentional?): RFC 5575 (Obsoleted by RFC 8955) Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR K. Patel 3 Internet-Draft Cisco Systems 4 Intended status: Informational R. White 5 Expires: September 22, 2016 Ericsson 6 S. Hares 7 Huawei 8 March 21, 2016 10 Use Cases for an Interface to BGP Protocol 11 draft-keyupate-idr-i2rs-bgp-usecases-02.txt 13 Abstract 15 A network routing protocol like BGP is typically configured and 16 analyzed through some form of Command Line Interface (CLI) or 17 NETCONF. These interactions to control BGP and diagnose its 18 operation encompass: configuration of protocol parameters, display of 19 protocol data, setting of certain protocol state and debugging of the 20 protocol. 22 Interface to the Routing System's (I2RS) Programmatic interfaces 23 provides an alternate way to control and diagnose the operation of 24 the BGP protocol. I2RS may be used for the configuration, 25 manipulation, analyzing or collecting the protocol data. This 26 document describes set of use cases for which I2RS can be used for 27 BGP protocol. It is intended to provide a base for the solution 28 draft describing a set of interfaces to the BGP protocol. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on September 22, 2016. 47 Copyright Notice 49 Copyright (c) 2016 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 This document may contain material from IETF Documents or IETF 63 Contributions published or made publicly available before November 64 10, 2008. The person(s) controlling the copyright in some of this 65 material may not have granted the IETF Trust the right to allow 66 modifications of such material outside the IETF Standards Process. 67 Without obtaining an adequate license from the person(s) controlling 68 the copyright in such materials, this document may not be modified 69 outside the IETF Standards Process, and derivative works of it may 70 not be created outside the IETF Standards Process, except to format 71 it for publication as an RFC or to translate it into languages other 72 than English. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 77 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 78 1.2. Requirements for I2S . . . . . . . . . . . . . . . . . . 4 79 2. Summary of Requirements for I2RS Module for BGP . . . . . . . 4 80 3. BGP Protocol Operation . . . . . . . . . . . . . . . . . . . 6 81 3.1. BGP Error Handling for Internal BGP Sessions . . . . . . 7 82 3.2. Summary of I2RS Capabilities and Interactions . . . . . . 7 83 4. BGP Route Manipulation . . . . . . . . . . . . . . . . . . . 7 84 4.1. Customized Best Path Selection Criteria . . . . . . . . . 8 85 4.2. Flowspec Routes . . . . . . . . . . . . . . . . . . . . . 8 86 4.3. Route Filter Routes for Legacy Routers . . . . . . . . . 8 87 4.4. Optimized Exit Control . . . . . . . . . . . . . . . . . 9 88 4.5. Summary of I2RS Capabilities and Interactions . . . . . . 9 89 5. BGP Events . . . . . . . . . . . . . . . . . . . . . . . . . 10 90 5.1. Notification of Routing Events . . . . . . . . . . . . . 10 91 5.2. Tracing Dropped BGP Routes . . . . . . . . . . . . . . . 11 92 5.3. BGP Protocol Statistics . . . . . . . . . . . . . . . . . 12 93 5.4. Summary of I2RS Capabilities and Interactions for Event 94 statistics . . . . . . . . . . . . . . . . . . . . . . . 13 96 6. Central membership computation for MPLS based VPNs . . . . . 14 97 7. Marking Overlapping Traffic Engineering Routes for Removal . 15 98 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 99 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 100 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 101 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 102 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 103 11.2. Informative References . . . . . . . . . . . . . . . . . 17 104 Appendix A. BGP Configuration . . . . . . . . . . . . . . . . . 18 105 A.1. BGP Protocol Configuration . . . . . . . . . . . . . . . 19 106 A.2. BGP Policy Configuration . . . . . . . . . . . . . . . . 20 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 109 1. Introduction 111 Typically, a network routing protocol like BGP is configured and 112 results of its operation are analyzed through some form of Command 113 Line Interface (CLI) or NETCONF. These interactions to control BGP 114 and diagnose its operation encompass: configuration of protocol 115 parameters, display of protocol data, setting of certain protocol 116 state and debugging of the protocol. 118 The I2RS architecture document [I-D.ietf-i2rs-architecture] describes 119 a mechanism to control network protocols like BGP using a set of 120 programmatic interfaces. These programmatic interfaces allow one to 121 control the BGP protocol by analyzing its operational state and 122 routing protocol data, plus manipulating BGP's configuration to 123 achieve various goals. The I2RS is not intended to replace any 124 existing configuration mechanisms, (i.e.: Command Line Interface or 125 NETCONF). Instead, I2RS is intended to augment those existing 126 mechanisms by defining a standardized set of programmatic interfaces 127 to enable easier configuration, interrogation and analysis of the BGP 128 protocol. 130 This document describes set of use cases for which I2RS's 131 programmatic interfaces can be used to control and analyze the 132 operation of BGP. The use cases described in this document cover the 133 following aspects of BGP: protocol parameter configuration, protocol 134 route manipulation and tracking of protocol events. The goal is to 135 inform the community's understanding of where the I2RS BGP extensions 136 fit within the overall I2RS architecture. It is intended to provide 137 a basis for the solutions draft describing the set of Interfaces to 138 the BGP protocol. 140 1.1. Requirements Language 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in RFC 2119 [RFC2119]. 146 1.2. Requirements for I2S 148 Each of the sections below (BGP protocol operation, BGP Route 149 Manipulation, BGP Events, Central Membership for MPLS based VPNs, and 150 Marking Overlapping BGP Routes) have specified a use case 151 descriptions followed by a summary of I2RS requirements. Each 152 requirement listed in these sections is given an number [REQnn] where 153 nn is the unique BGP Requirement. Requirements duplicated from 154 previous sections are repeated with the original requirements number. 156 2. Summary of Requirements for I2RS Module for BGP 158 This is a summary of the requirements for an IDR I2RS Yang Module 159 listed in this document. 161 o BGP-REQ01: I2RS client/agent exchange SHOULD support the read, 162 write and quick notification of status of the BGP peer operational 163 state on each router within a given Autonomous System (AS). This 164 operational status includes the quick notification of protocol 165 events that proceed a destructive tear-down of BGP session 167 o BGP-REQ02: I2RS client SHOULD be able to push BGP routes with 168 custom cost communities to specific I2RS agents on BGP routers for 169 insertion in specific BGP Peer(s) to aid Traffic engineering of 170 data paths. These routes SHOULD be tracked by the I2RS Agent as 171 specific BGP routes with customer cost communities. These routes 172 (will/will not) installed via the RIB-Info. 174 o BGP-REQ03: I2RS client SHOULD be able to track via read/ 175 notifications all Traffic engineering changes applied via I2RS 176 agents to BGP route processes in all routers in a network. 178 o BGP-REQ04: I2RS Agents SHOULD support identification of routers as 179 BGP ASBRs, PE routers, and IBGP routers. 181 o BGP-REQ05: I2RS client-agent SHOULD support writing traffic flow 182 specifications to I2RS Agents that will install them in associated 183 BGP ASBRs and the PE routers. 185 o BGP-REQ06: I2RS Client SHOULD be able to track flow specifications 186 installed within a IBGP Cloud within an AS via reads of BGP Flow 187 Specification information in I2RS Agent, or via notifications from 188 I2RS agent 190 o BGP-REQ07: I2RS client-agent exchange SHOULD support the I2RS 191 client being able to prioritize and control BGP's announcement of 192 flow specifications after status information reading BGP ASBR and 193 PE router's capacity. BGP ASBRs and PE routers functions within a 194 router MAY forward traffic flow specifications received from EBGP 195 speakers to I2RS agents, so the I2RS Agent SHOULD be able to send 196 these flow specifications from EBGP sources to a client in 197 response to a read or notification. 199 o BGP-REQ08: I2RS Client SHOULD be able to read BGP route filter 200 information from I2RS Agents associated with legacy BGP routers, 201 and write filter information via the I2RS agent to be installed in 202 BGP RR. The I2RS Agent SHOULD be able to install these routes in 203 the BGP RR, and engage a BGP protocol action to push these routers 204 to ASBR and PE routers. 206 o BGP-REQ09: I2RS client(s) SHOULD be able to request the I2RS agent 207 to read BGP routes with all BGP parameters that influence BGP best 208 path decision, and write appropriate changes to the BGP Routes to 209 BGP and to the RIB-Info in order to manipulate BGP routes 211 o BGP-REQ10: I2RS client SHOULD be able instruct the I2RS agent(s) 212 to notify the I2RS client when the BGP processes on an associated 213 routing system observe a route change to a specific set of IP 214 Prefixes and associated prefixes. Route changes include: 1) 215 prefixes being announced or withdrawn, 2) prefixes being 216 suppressed due to flap damping, or 3) prefixes using an alternate 217 best-path for a given IP Prefix. The I2RS agent should be able to 218 notify the client via publish or subscribe mechanism. 220 o BGP-REQ11: I2RS client SHOULD be able to read BGP route 221 information from BGP routers on routes in received but rejected 222 from ADJ-RIB-IN due to policy, on routes installed in ADJ-RIB-IN, 223 but not selected as best path, and on route not sent to IBGP peers 224 (due to non-selection). 226 o BGP-REQ12: I2RS client SHOULD be able to request the I2RS agent to 227 read installed BGP Policies. 229 o BGP-REQ13: I2RS client SHOULD be able to instruct the I2RS Agent 230 to write BGP Policies into the running BGP protocols and into the 231 BGP configurations. 233 o BGP-REQ14: I2RS client-agent SHOULD be able to read BGP statistics 234 associated with Peer, and to receive notifications when certain 235 statistics have exceeded limits. An example of one of these 236 protocol statistics is the max-prefix limit. 238 o BGP-REQ15: The I2RS client via the I2RS agent MUST have the 239 ability to read the LOC-RIB-In BGP table that gets all the routes 240 that the CE has provided to a PE router. 242 o BGP-REQ16: The I2RS client via the I2RS agent MUST have the 243 ability to install destination based routes in the local RIB of 244 the PE devices. This must include the ability to supply the 245 destination prefix (NLRI), a table identifier, a route preference, 246 a route metric, a next-hop tunnel through which traffic would be 247 carried 249 o BGP-REQ17: The I2RS client via the I2RS agent SHOULD have the the 250 ability to read the loc-RIB-in BGP table to discover overlapping 251 routes, and determine which may be safely marked for removal. 253 o BGP-REQ18: The I2RS client via the I2RS Agent SHOULD have the 254 ability to modify filtering rules and initiate a re-computation of 255 the local BGP table through those policies to cause specific 256 routes to be marked for removal at the outbound eBGP edge. 258 This summary is also listed in the 259 [I-D.ietf-i2rs-usecase-reqs-summary]. 261 3. BGP Protocol Operation 263 It is increasingly common for services facilitated via BGP to be 264 subject to severe, widespread disruptions (outages), primarily due to 265 the destructive teardown of BGP sessions as a result of receiving 266 malformed BGP attributes. Unfortunately, more fine-grained BGP error 267 handling solutions, which would result in little to no impact on the 268 operation of BGP protocol, remain elusive. 270 A planned Graceful must also carefully be handled to limit the amount 271 of traffic loss during a the shutdown. While operational 272 requirements for the BGP mechanism for graceful shutdown of a (set 273 of) BGP sessions is described in [RFC6198], and the operational 274 procedures are described in [I-D.ietf-grow-bgp-gshut], additional 275 fine-grained BGP error handling could improve graceful shutdown of 276 BGP sessions. 278 This section discussed how I2RS information could improve both the 279 destructive teardown and the graceful teardown of sessions. 281 3.1. BGP Error Handling for Internal BGP Sessions 283 It is possible that I2RS could enable enhanced error handling 284 techniques for Internal BGP sessions. At a minimum, I2RS-capable BGP 285 routers could signal an event such as "Malformed Attribute Received" 286 via an I2RS agent toward an I2RS client(s). I2RS client(s) may 287 already have a real-time view of BGP routes, and corresponding BGP 288 attributes, or may dynamically interrogate BGP routers in the network 289 to identify the present propagation scope of the BGP route(s) that 290 are affected. Finally, the I2RS client(s) could then signal back to 291 I2RS agents on BGP routers to apply a filter that would block 292 propagation of the BGP attribute or BGP route, as necessary, in order 293 to temporarily aid in consistency of BGP routing information across 294 the entire network until a permanent fix can be developed and 295 deployed within BGP routers. 297 I2RS would enable the global visibility and global control over the 298 operational state of BGP, within a given Autonomous System, that is 299 necessary to facilitate the learning of, rapid response to and more 300 fine-grained isolation/scoping of BGP protocol events that currently 301 cause a destructive tear-down of BGP sessions that lead to widespread 302 disruptions of services. 304 3.2. Summary of I2RS Capabilities and Interactions 306 o BGP-REQ01: I2RS client/agent exchange SHOULD support the read, 307 write and quick notification of status of the BGP peer operational 308 state on each router within a given Autonomous System (AS). This 309 operational status includes the quick notification of protocol 310 events that proceed a destructive tear-down of BGP session 312 4. BGP Route Manipulation 314 Multiprotocol BGP [RFC4760] provides support to carry routing 315 information for different BGP address families. Route manipulation 316 is heavily done across these different address families for different 317 reasons. BGP IPv4 and IPv6 address families use BGP Communities 318 [RFC1997] and other IBGP and EBGP attributes to manipulate BGP routes 319 for Traffic Engineering purpose. BGP VPN address families use 320 Extended Communities [RFC4360] to filter unwanted BGP routes. BGP 321 Flowspec address family [RFC5575] is used to install Flow based 322 filters to filter unwanted data traffic. The following sub-sections 323 describe the use of IRS towards BGP Route Manipulation for different 324 BGP address families. 326 4.1. Customized Best Path Selection Criteria 328 The BGP customized Bestpath facilitates custom bestpath computations 329 within a BGP speaking network. It is usually used within an IBGP 330 network. Customized bestpaths use special extended communities known 331 as cost communities. Cost communities carry enough information; 332 Point of Insertion (POI) and the cost value to signal where in BGP 333 bestpath the customize checks need to be done. Both, the traffic 334 engineering as well as backdoor (SHAM) links use customized bestpath 335 computation. 337 With I2RS, it would be possible for an I2RS client to push routes 338 with custom cost communities on the BGP routers for Traffic 339 Engineering purpose. I2RS client now can act as a central entity 340 keeping track of all Traffic engineering data that get applied to BGP 341 routes within an IBGP network. 343 4.2. Flowspec Routes 345 The BGP flowspec address family is used to disseminate the traffic 346 flow specification to the BGP Autonomous System Border Routers 347 (ASBRs) and Provider Edge (PE) routers. Both, the BGP ASBRs and the 348 PEs would translate the received BGP traffic flow specification into 349 an Access Control List (ACL) and install it in router's forwarding 350 path. Using such ACLs routers can now classify, shape, rate limit, 351 filter, or redirect traffic flows. 353 With I2RS, it would be possible for an I2RS client to push traffic 354 flow specifications to the BGP ASBRs and the PE routers. I2RS client 355 can act as a central entity tracking all the traffic flow 356 specifications that are installed within an IBGP network. I2RS 357 client could also prioritize and control the announcement of traffic 358 flow specifications according to various ASRBs and PE router's 359 capacity. BGP ASBRs and PE routers MAY forward traffic flow 360 specifications received from EBGP speakers to I2RS Agents. This 361 would allow I2RS agents to centrally manage and track any externally 362 received traffic flow specifications. 364 4.3. Route Filter Routes for Legacy Routers 366 The BGP Route Filter address family is used to disseminate the Route 367 Target filter information between VPN BGP speakers. This information 368 is then used to build a route distribution graph that helps in 369 limiting the propagation of VPN NLRI (network Layer Reachabilty 370 Information) within a VPN network. However, it requires that all the 371 BGP VPN routers are upgraded to support this functionality. 372 Otherwise, the graph information is incomplete when a VPN network 373 consists of legacy routers that participates in VPN but does not 374 implement the BGP route filter address family. 376 With I2RS, it would be possible for an I2RS client to push router 377 filter information to BGP RR routers on behalf of all legacy routers 378 that participates in VPN but does not support or implement the BGP 379 route filter address family. I2RS client can act as a central entity 380 tracking all the configured Route Filters for legacy routers and push 381 them on appropriate RRs who in turn would push it to ASBRs and PE 382 routers. In this way, I2RS agents help build an optimal route 383 distribution graph that would assist in filtering of VPN NLRIs in a 384 VPN network. 386 4.4. Optimized Exit Control 388 Optimized Exit Control is used to provide route optimization and load 389 distribution for multiple network connections between networks. 390 Network operators can monitor IP traffic flows and then could define 391 policies and rules based on traffic class performance, link bandwidth 392 monetary costs, link load distribution, traffic types, link failures, 393 etc. 395 With I2RS, it would be possible for an I2RS client to manipulate BGP 396 routes and its parameters that influence BGP bestpath decisions. 397 I2RS client could act as a central entity that would monitor and 398 manipulate BGP routes based on central network based policies. Such 399 routes would then be injected by a I2RS client into the network so as 400 to get the load distribution for multiple network connections. 402 4.5. Summary of I2RS Capabilities and Interactions 404 o BGP-REQ02: I2RS client SHOULD be able to push BGP routes with 405 custom cost communities to specific I2RS agents on BGP routers for 406 insertion in specific BGP Peer(s) to aid Traffic engineering of 407 data paths. These routes SHOULD be tracked by the I2RS Agent as 408 specific BGP routes with customer cost communities. These routes 409 (will/will not) installed via I2RS RIB. 411 o BGP-REQ03: I2RS client SHOULD be able to track via read/ 412 notifications all Traffic engineering changes applied via I2RS 413 agents to BGP route processes in all routers in a network. 415 o BGP-REQ04: I2RS Agents SHOULD support identification of routers as 416 BGP ASBRs, PE routers, IBGP routers. 418 o BGP-REQ05: I2RS client-agent SHOULD support writing traffic flow 419 specifications to I2RS Agents that will install them in associated 420 BGP ASBRs and the PE routers. 422 o BGP-REQ06: I2RS Client SHOULD be able to track flow specifications 423 installed within a IBGP Cloud within an AS via reads of BGP Flow 424 Specification information in I2RS Agent, or via notifications from 425 I2RS agent. 427 o BGP-REQ07: I2RS client-agent exchange SHOULD support the I2RS 428 client being able to prioritize and control BGP's announcement of 429 flow specifications after the reading of status information on 430 capacity of BGP routers (ASBR and PE). BGP ASBRs and PE routers 431 functions within a router MAY forward traffic flow specifications 432 received from EBGP speakers to I2RS agents, so the I2RS Agent 433 SHOULD be able to send these flow specifications from EBGP sources 434 to a client in response to a client query or as part of pub/sub 435 event notification. 437 o BGP-REQ08: I2RS Client SHOULD be able to read BGP route filter 438 information from I2RS Agents associated with legacy BGP routers, 439 and write filter information via the I2RS agent to be installed in 440 BGP RR. The I2RS Agent SHOULD be able to install these routes in 441 the BGP RR, and engage a BGP protocol action to push these routers 442 to ASBR and PE routers. 444 o BGP-REQ09: I2RS client(s) SHOULD be able to request the I2RS agent 445 to read BGP routes with all BGP parameters that influence BGP best 446 path decision, and write appropriate changes to the BGP Routes to 447 BGP and to the RIB-Info in order to manipulate BGP routes 449 5. BGP Events 451 Given the extremely large number of BGP Routes in networks, it is 452 critical to have scalable mechanisms that can be used to monitor for 453 events affecting routing state and, consequently, reachability. In 454 addition, similar tools are needed in order to monitor BGP protocol 455 statistics, which help operators and developers better understand 456 scalability of software and hardware that BGP utilizes. 458 I2RS could provide a publish-subscribe capability to applications to: 460 o request monitoring of BGP routes and related events; and, 462 o subscribe to the I2RS client to receive events related to BGP 463 routes or other protocol-related events of interest. 465 5.1. Notification of Routing Events 467 There are certain IP prefixes, for example those that are arbitrarily 468 classified by a given network operator as "high visibility" by its 469 end-users, for which immediate notification of changes in their state 470 are extremely useful to know about. Upon notification of such 471 events, a Network Operations Center (NOC) could respond to customer 472 inquiries in a more timely fashion; alternatively, the NOC may decide 473 to perform Traffic Engineering to restore service, etc. 475 Currently, the only way to learn of such events is for a BGP 476 monitoring system to establish a BGP session with a multitude of BGP 477 routers in an AS. Then, the BGP monitoring system needs to look 478 through all BGP UPDATE's in order to identify those events that are 479 of interest to it. Note, this doesn't account for the fact that 480 there are several applications that might be simultaneously 481 interested in learning of events to a given IP prefix nor the fact 482 that some applications may want to dynamically insert or remove "IP 483 prefixes of interest", depending on the needs of their constituent 484 applications. 486 With I2RS, it is conceivable that applications could tell an I2RS 487 client, through a North-Bound API, their "IP prefixes" (or, 488 AS_PATH's, BGP communities, etc.) that are of interest. For example, 489 a NOC application may be interested in changes to high visibility 490 content or service-provider Web sites; alternatively, a security 491 application may be interested in events associated with a different 492 set of IP prefixes. The I2RS client would then consolidate the list 493 of IP prefixes, and associated characteristics, to be monitored and 494 program BGP routers in an AS to observe this subset of routes for 495 changes. Some examples of changes in routing state might include: 497 o an IP prefix being announced or withdrawn 499 o an IP prefix being suppressed, due to route flap dampening 501 o an alternative best-path being chosen for a given IP prefix 503 When the requisite events for a BGP Route are observed by a BGP 504 router, it would notify I2RS agents. 506 The I2RS agents would have a publish/subscribe mechanism whereby 507 various sets of applications may subscribe to events of interest. 508 The I2RS client would then publish these events so applications would 509 immediately receive them and take the appropriate domain-specific 510 action necessary. 512 5.2. Tracing Dropped BGP Routes 514 It is extremely useful to operators to be able to rapidly identify 515 instances where a BGP route is not being propagated within an 516 Autonomous System. At a minimum, this could result in sub-optimal 517 performance when attempting to reach such destinations. 519 There are two instances when this scenario will occur. First, when a 520 Service Provider is using "Soft Reconfiguration Inbound", it allows 521 their ASBR routers to receive a copy of a BGP route, but show that 522 route was not permitted into the Adj-RIB-In most likely as a result 523 of the inbound BGP policy not permitting that IP prefix. Thus, this 524 BGP route is not even eligible for BGP Path Selection. The second 525 instance is where the BGP route is permitted by the inbound BGP 526 policy into the Adj-RIB-In, but due to BGP Path Selection (i.e.: 527 lower LOCAL_PREF, longer AS_PATH length, etc.) was not chosen as the 528 best path and, subsequently, this particular BGP route is not 529 forwarded on to other internal BGP speakers in the AS. In both 530 instances, the BGP route is only visible within the ASBR on which 531 that BGP route was first learned. Needless to say, in large Service 532 Provider networks with a numerous interconnects to a single customer 533 it can be very time-consuming to discover where such a BGP route is 534 learned before ultimately determining why the route was blocked or 535 not preferred. 537 With I2RS, it would be possible for an I2RS client to rapidly gather 538 information from across a large set of BGP routers in the network to 539 determine at what ASBR's the BGP route is being learned. Next, the 540 I2RS client could interrogate those routers BGP policies to determine 541 the root cause of why the route was either not learned or not 542 preferred in BGP. Finally, if necessary, the I2RS client(s) could 543 amend BGP policies and push them out to BGP routers to permit the BGP 544 route or make it a preferred route according to the BGP path 545 selection algorithm. 547 5.3. BGP Protocol Statistics 549 There are a variety of statistics related to the operation of BGP 550 that are invaluable to network operators. These statistics generally 551 help operators, and developers, understand the present state and 552 future scalability of BGP. 554 One statistic that is invaluable to operators is the current number 555 of BGP routes learned through an eBGP session. Operators then apply 556 a command against each eBGP session to limit the maximum number of 557 BGP routes that may be learned through that eBGP session before a 558 warning message is triggered and/or the eBGP session is torn down 559 completely. This configuration capability is often referred to as a 560 "max-prefix limit". This command must be routinely audited and, if 561 necessary, adjusted in order to not trigger a false warning or 562 teardown due to the natural organic growth in BGP routes learned from 563 a given BGP neighbor. 565 I2RS agents could provide an invaluable capability to help audit and 566 re-program the "max-prefix limit" on a periodic basis, which is 567 generally once per day. Specifically, the first task would be for an 568 I2RS client to validate that there is a "max-prefix limit" applied to 569 every eBGP session. (If there is not, that should either trigger a 570 red alarm to the NOC to manually fix this condition or for the I2RS 571 client to automatically apply a "max-prefix limit" that would 572 alleviate this hazardous condition). Assuming there is a "max-prefix 573 limit" already in place, the I2RS client would simultaneously 574 retrieve, from each BGP router, the current number of BGP routes 575 learned through a BGP session and value used for the "max-prefix 576 limit" on that same BGP session. These two values could then be 577 handed off to an application that determines if adjustments in the 578 "max-prefix limit" value are required for each BGP session. The 579 application would then notify the I2RS client of the subset of eBGP 580 sessions and their associated change in "max-prefix limit" value, 581 whereby the I2RS client would then adjust the BGP protocol 582 configuration on each requisite BGP router in the network. Finally, 583 it should be noted that the above is just one method whereby "max- 584 prefix limit" values are adjusted. It's similarly possible that the 585 BGP routers may, through the I2RS, pull the "max-prefix limit" values 586 for each eBGP neighbor they have on-board on a periodic basis and 587 validate their accuracy. 589 The above is just one use case related to BGP protocol statistics. 590 There are wealth of other BGP protocol statistics or state 591 information that would be invaluable to have programmatic visibility 592 into that operators do not have today. 594 5.4. Summary of I2RS Capabilities and Interactions for Event statistics 596 I2RS SHOULD have the ability to: 598 o BGP-REQ10: I2RS client SHOULD be able instruct the I2RS agent(s) 599 to notify the I2RS client when the BGP processes on an associated 600 routing system observe a route change to a specific set of IP 601 Prefixes and associated prefixes. Route changes include: 1) 602 prefixes being announced or withdrawn, 2) prefixes being 603 suppressed due to flap damping, or 3) prefixes using an alternate 604 best-path for a given IP Prefix. The I2RS agent should be able to 605 notify the client via publish or subscribe mechanism. 607 o BGP-REQ11: I2RS client SHOULD be able to read BGP route 608 information from BGP routers on routes in received but rejected 609 from ADJ-RIB-IN due to policy, on routes installed in ADJ-RIB-IN, 610 but not selected as best path, and on route not sent to IBGP peers 611 (due to non-selection). 613 o BGP-REQ12: I2RS client SHOULD be able to request the I2RS agent to 614 read installed BGP Policies 616 o BGP-REQ13: I2RS client SHOULD be able to instruct the I2RS Agent 617 to write BGP Policies into the running BGP protocols and into the 618 BGP configurations. 620 o BGP-REQ14: I2RS client-agent SHOULD be able to read BGP statistics 621 associated with Peer, and to receive notifications when certain 622 statistics have exceeded limits. An example of one of these 623 protocol statistics is the max-prefix limit. 625 6. Central membership computation for MPLS based VPNs 627 MPLS based VPNs use route target extended communities to express 628 membership information. Every PE router holds incoming BGP NLRI and 629 processes them to determine membership and then import the NLRI into 630 the appropriate MPLS/VPN routing tables. This consumes resources, 631 both memory and compute on each of the PE devices. 633 An alternative approach is to monitor routing updates on every PE 634 from the attached CEs and then compute membership in a central 635 manner. Once computed the routes are pushed to the VPN RIBs of the 636 participating PEs. 638 This centralization of membership control has a few advantages. 640 o The membership mechanism (route-targets) need not be configured in 641 each of the PEs and can be expressed once centrally. 643 o No resources in the PEs need to be spent to categorize routes into 644 the VRF tables that they belong and to filter out unwanted state. 646 o Doing it centrally means the availability of almost unlimited 647 compute capacity to compute membership and hence can be done in a 648 scaleable manner. 650 o More sophisticated routing policies and filters can be applied 651 during the central import/export process than can be expressed and 652 performed using the traditional route target mechanism. 654 o Routes can be selectively pushed only to the participating PE's 655 further reducing the memory load on the individual routers in the 656 network. This further obviates for a distributed mechanisms such 657 as rt constraints to reduce unnecessary path state in the routers. 659 Note that centrally computation of membership can be applied to other 660 scenarios as well such as VPLS, MVPNs, MAC VPNs and others. 661 Depending on the scenario, what gets monitored from the CE might 662 vary. Central computation will especially help VPLS where multi- 663 homing and load balancing using distributed techniques has 664 particularly been a challenge. 666 Also note that one of the biggest promises of central route 667 computation is simplification and reduction of computation and memory 668 load on all devices in the network. This use case is just one 669 example that illustrates these benefits of central computation very 670 well. 672 Summary of I2RS Capabilities and Interactions: 674 o BGP-REQ15:The I2RS client via the I2RS agent MUST have the ability 675 to read the loc-RIB-In BGP table that gets all the routes that the 676 CE has provided to a PE router. 678 o BGP-REQ16:The I2RS client via the I2RS agent MUST have the ability 679 to install destination based routes in the local RIB of the PE 680 devices. This must include the ability to supply the destination 681 prefix (NLRI), a table identifier, a route preference, a route 682 metric, a next-hop tunnel through which traffic would be carried 684 7. Marking Overlapping Traffic Engineering Routes for Removal 686 It is often the case that routes are advertised not to provide 687 reachability (in the strict sense), but rather to provide optimal 688 reachability, or to engineer the path traffic takes to a particular 689 destination. While this can improve the efficiency of a network's 690 operation, it can also increase the amount of state carried in the 691 control plane beyond the point where the additional state has any 692 real effect on traffic flow. Removing Overlapping Routes 693 [I-D.white-grow-overlapping-routes] provides a mechanism designed to 694 remove these traffic engineering routes once they are beyond the 695 point of actually impacting traffic flows in the network. 697 Summary of I2RS Capabilities and Interactions: 699 o BGP-REQ17: The I2RS client via the I2RS agent SHOULD have the the 700 ability to read the loc-RIB-in BGP table to discover overlapping 701 routes, and determine which may be safely marked for removal. 703 o BGP-REQ18: The I2RS client via the I2RS Agent SHOULD have the 704 ability to modify filtering rules and initiate a re-computation of 705 the local BGP table through those policies to cause specific 706 routes to be marked for removal at the outbound eBGP edge. 708 8. IANA Considerations 710 This document makes no request of IANA. 712 9. Security Considerations 714 The BGP use cases described in this document assumes use of I2RS 715 programmatic interfaces described in the I2RS framework mentioned in 716 [I-D.ietf-i2rs-architecture]. This document does not change the 717 underlying security issues inherent in the existing in 718 [I-D.ietf-i2rs-architecture]. 720 10. Acknowledgements 722 The authors would like to thank Ed Crabbe, Joel Halpern, Wes George, 723 Carlos Pignataro, Jon Mitchell, Rex Fernando, Hannes Gredler, Shane 724 Amante, Bill Atwood for their comments and suggestions. 726 11. References 728 11.1. Normative References 730 [I-D.ietf-i2rs-architecture] 731 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 732 Nadeau, "An Architecture for the Interface to the Routing 733 System", draft-ietf-i2rs-architecture-09 (work in 734 progress), March 2015. 736 [I-D.ietf-i2rs-usecase-reqs-summary] 737 Hares, S. and M. Chen, "Summary of I2RS Use Case 738 Requirements", draft-ietf-i2rs-usecase-reqs-summary-01 739 (work in progress), May 2015. 741 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 742 Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, 743 . 745 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 746 Requirement Levels", BCP 14, RFC 2119, 747 DOI 10.17487/RFC2119, March 1997, 748 . 750 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 751 DOI 10.17487/RFC2629, June 1999, 752 . 754 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 755 Text on Security Considerations", BCP 72, RFC 3552, 756 DOI 10.17487/RFC3552, July 2003, 757 . 759 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 760 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 761 DOI 10.17487/RFC4271, January 2006, 762 . 764 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 765 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 766 February 2006, . 768 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 769 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 770 2009, . 772 11.2. Informative References 774 [I-D.ietf-grow-bgp-gshut] 775 Francois, P., Decraene, B., Pelsser, C., Patel, K., and C. 776 Filsfils, "Graceful BGP session shutdown", draft-ietf- 777 grow-bgp-gshut-06 (work in progress), August 2014. 779 [I-D.mcpherson-irr-routing-policy-considerations] 780 McPherson, D., Amante, S., Osterweil, E., and L. Blunk, 781 "IRR & Routing Policy Configuration Considerations", 782 draft-mcpherson-irr-routing-policy-considerations-01 (work 783 in progress), September 2012. 785 [I-D.white-grow-overlapping-routes] 786 White, R., Retana, A., and S. Hares, "Filtering of 787 Overlapping Routes", draft-white-grow-overlapping- 788 routes-03 (work in progress), October 2014. 790 [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., 791 Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, 792 "Routing Policy Specification Language (RPSL)", RFC 2622, 793 DOI 10.17487/RFC2622, June 1999, 794 . 796 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 797 "Multiprotocol Extensions for BGP-4", RFC 4760, 798 DOI 10.17487/RFC4760, January 2007, 799 . 801 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 802 and D. McPherson, "Dissemination of Flow Specification 803 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 804 . 806 [RFC6198] Decraene, B., Francois, P., Pelsser, C., Ahmad, Z., 807 Elizondo Armengol, A., and T. Takeda, "Requirements for 808 the Graceful Shutdown of BGP Sessions", RFC 6198, 809 DOI 10.17487/RFC6198, April 2011, 810 . 812 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 813 "Special-Purpose IP Address Registries", BCP 153, 814 RFC 6890, DOI 10.17487/RFC6890, April 2013, 815 . 817 Appendix A. BGP Configuration 819 The configuration of BGP is arduous to establish and maintain, 820 particularly on networks whose services have a requirement for 821 complex routing policies. This need is magnified by the need to 822 routinely perform changes to large numbers of BGP routers to, for 823 example: add or remove customer's BGP sessions, announce or withdraw 824 (customer) IP prefixes in BGP, modify BGP policies to effect changes 825 in Traffic Engineering, audit BGP routers to ensure they have 826 consistent and appropriate BGP policies, and others. 828 There are three categories of BGP configuration: 830 1. Local BGP routing protocol configuration: local Autonomous System 831 Number (ASN), BGP path selection properties of the router, 832 injection of (aggregate) routes into BGP, etc. 834 2. Local BGP policies: policies designed to filter and/or manipulate 835 BGP attributes associated with BGP routes learned through BGP 836 sessions. These policies typically live in the global 837 configuration of a BGP router, but are applied on a per-BGP 838 neighbor basis (or, group of BGP neighbors); and, 840 3. BGP neighbor sessions: remote ASN, remote IP address, address 841 families, BGP policies to applied to routes, max-prefix limits, 842 etc. 844 The sum total of BGP configuration on a BGP router is typically the 845 largest quantify of configuration on Service Provider's BGP routers, 846 by a fairly large margin. When that is combined with the large set 847 of routine configuration changes, mentioned above, it should be 848 fairly clear that systematic reading, configuration and control of 849 BGP routers through a mechanism like I2RS would greatly benefit all 850 operators of BGP routers. 852 While it may not be possible to provide programmatic APIs for 853 esoteric vendor-specific policy configuration, it is possible to 854 provide such API's for BGP protocol specific configuration and the 855 more commonly used BGP routing policies. 857 A.1. BGP Protocol Configuration 859 Ability to enable and disable new address families within a BGP 860 protocol for a network of BGP speaking routers is a challenge. The 861 challenge is mainly in keeping track of BGP speaker's feature 862 capabilities and then configuration of new address families on a 863 multiple BGP speakers within a given network. With the necessary 864 information, I2RS agents allow a network operator to push 865 configuration information for enabling and disabling of new address 866 families on a partial or entire set of BGP speakers within a given 867 network. This would assist in building BGP overlay networks as 868 needed. 870 For VPN address families, the main challenge lies in the complex VPN 871 configuration required to setup the control plane for Customer VPNs. 872 The configuration involves creating a Virtual Routing and Forwarding 873 instance (VRF), a Route Distinguisher (RD) that ensures each customer 874 prefixes remains unique across VPNs, and Route Targets (RT) that help 875 ensure that the Customer prefixes are segregated appropriately so 876 that they do not cross the VPN boundaries. I2RS would allow a 877 network operator to push such configuration from a central location 878 where a global VPN provisioning information could be stored. This 879 helps avoid manual configuration of a VPN on multiple routers. 880 Instead the configuration is controlled and pushed though a central 881 I2RS client using a programmatic set of APIs on targeted set of BGP 882 speakers. 884 Use of I2RS agents to announce protocol configuration information 885 would simplify and automate configuration of BGP protocol in IBGP 886 deployments where the protocol based policies are seldom used. To 887 facilitate such a centralized configuration model, BGP speakers could 888 be extended to use programmatic APIs to announce their feature 889 capabilities as part of protocol initialization to the centralize 890 I2RS agents. This would assist I2RS agents to auto-discover BGP 891 protocol capabilities of various BGP speakers in a given network. 892 I2RS agents in turn would use the information towards enabling/ 893 disabling of BGP specific features on BGP speakers. 895 A.2. BGP Policy Configuration 897 Filtering of BGP routes is strongly recommended to control the 898 announcements of BGP prefixes across the internet. Most providers 899 make extensive use of BGP prefix filtering policies at the edge of 900 their networks. The reasons for filtering BGP prefixes are: 902 o Avoid Unwanted Route Announcements. Filter prefixes that MUST NOT 903 be routed [RFC6890]. Filter prefixes that are not allocated by 904 Internet Routing Registries. 906 o Facilitate Route Summarization. Filter prefixes beyond certain 907 agreed prefix mask length between providers. Route Summarization 908 helps control BGP RIB and FIB table size. 910 o Defensive Security. Filter prefixes from Stub customer ASes that 911 are not owned by the customers. Filter customer prefixes 912 announced by other providers. This helps avoid prefix hijacking. 914 A set of standards-based schemas to enable configuration of Local BGP 915 policies and BGP neighbor sessions was realized through the Routing 916 Policy Specification Language (RSPL) [RFC2622]. The RPSL defined a 917 standards-based schemas, or 'objects' as it called them, that 918 defined: 920 o binding of IP prefixes to (one or more) Origin AS, (route 921 objects); 923 o collections of routes (route-set objects); 925 o collections of Autonomous Systems (as-set objects); and, 927 o routing policy of an Autonomous System to/from its adjacent 928 neighbor AS'es, (aut-num objects) 930 Each ASN is responsible for creation, modification and deletion of 931 its RPSL objects in an Internet Routing Registry (IRR). IRR's are 932 typically operated by Regional Internet Registries (RIR's) and a few 933 dozen larger ISP's and independent organizations. The IRR's provide 934 a well-known location for all organizations attached to the Internet 935 to retrieve or update RPSL objects. 937 While still widely and actively used by Internet Service Providers, 938 the prevailing belief is that the data contained in the IRR's is 939 inaccurate, primarily due to a lack of deployed authorization method 940 with respect to the creation of modification of RPSL objects. It 941 should be noted that this criticism is not directed at the previously 942 defined RPSL schemas, but rather at the data contained in RPSL 943 schemas by end-users of the IRR system. Please refer to the IRR And 944 Routing Policy Configuration Considerations 945 [I-D.mcpherson-irr-routing-policy-considerations] document for a more 946 thorough discussion of the history and present state of the IRR's. 948 Currently, RPSL schemas are exchanged between non-routing systems 949 (servers) used within the IRR system. In addition, open-source and 950 proprietary applications create or modify RPSL schemas, as necessary, 951 to signal the announcement (or, withdrawal) of an IP prefix from an 952 ASN or the creation (or, teardown) of a neighbor relationship between 953 two adjacent ASN's. Most importantly, these RPSL schemas are 954 consumed by similar applications to automatically build routing 955 policies, (i.e.: lists of IP prefixes, corresponding Origin ASN's 956 and/or AS_PATH's), that then get translated to device-specific syntax 957 (i.e.: CLI) before being pushed into individual BGP routers to effect 958 routing policy on the network. It is common for Internet Service 959 Providers to perform updates to these routing policies across their 960 entire network on a daily basis. 962 With I2RS it would be desirable to change the last step in the above 963 process so that BGP policies derived from RPSL schemas, and other 964 information sources, are translated into standards-based schemas that 965 are then pushed, or pulled, into individual BGP routers. More 966 generally, I2RS agents could use API's to gather information required 967 to build various types of BGP routing policies plus the corresponding 968 set of Autonomous System Border Routers (ASBR's) where such policies 969 need to be applied in the network and, finally, making those changes 970 to individual network elements so those BGP policies take effect in 971 the network. In doing so, a network operator now has a centralized 972 way of building and making these policies take effect across the 973 network in a coordinated manner. 975 Authors' Addresses 977 Keyur Patel 978 Cisco Systems 979 170 W. Tasman Drive 980 San Jose, CA 95134 981 USA 983 Email: keyupate@cisco.com 985 Russ White 986 Ericsson 988 Email: russw@riw.us 989 Susan Hares 990 Huawei 992 Email: shares@ndzh.com