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