--- 1/draft-keyupate-i2rs-bgp-usecases-02.txt 2014-06-17 10:14:25.652329253 -0700 +++ 2/draft-keyupate-i2rs-bgp-usecases-03.txt 2014-06-17 10:14:25.700330414 -0700 @@ -1,61 +1,59 @@ -I2RS K. Patel +I2RS Working Group K. Patel Internet-Draft R. Fernando Intended status: Informational Cisco Systems -Expires: December 6, 2014 H. Gredler +Expires: December 19, 2014 H. Gredler Juniper Networks S. Amante - Level 3 Communications, Inc. + Apple R. White Ericsson S. Hares - Hickory Hill Consulting - June 4, 2014 + Huawei + June 17, 2014 Use Cases for an Interface to BGP Protocol - draft-keyupate-i2rs-bgp-usecases-02.txt + draft-keyupate-i2rs-bgp-usecases-03.txt Abstract A network routing protocol like BGP is typically configured and analyzed through some form of Command Line Interface (CLI) or NETCONF. These interactions to control BGP and diagnose its operation encompass: configuration of protocol parameters, display of protocol data, setting of certain protocol state and debugging of the protocol. - Interface to the Routing System's (I2RS) Programmatic interfaces, as - defined in draft-ietf-i2rs-architecture, provides an alternate way to - control and diagnose the operation of the BGP protocol. I2RS may be - used for the configuration, manipulation, analyzing or collecting the - protocol data. This document describes set of use cases for which - I2RS can be used for BGP protocol. It is intended to provide a base - for the solution draft describing a set of interfaces to the BGP - protocol. + Interface to the Routing System's (I2RS) Programmatic interfaces + provides an alternate way to control and diagnose the operation of + the BGP protocol. I2RS may be used for the configuration, + manipulation, analyzing or collecting the protocol data. This + document describes set of use cases for which I2RS can be used for + BGP protocol. It is intended to provide a base for the solution + draft describing a set of interfaces to the BGP protocol. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - - This Internet-Draft will expire on December 6, 2014. + This Internet-Draft will expire on December 19, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -73,43 +71,49 @@ Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 - 2. BGP Protocol Operation . . . . . . . . . . . . . . . . . . . 4 - 2.1. BGP Error Handling for Internal BGP Sessions . . . . . . 4 - 3. BGP Route Manipulation . . . . . . . . . . . . . . . . . . . 4 - 3.1. Customized Best Path Selection Criteria . . . . . . . . . 5 - 3.2. Flowspec Routes . . . . . . . . . . . . . . . . . . . . . 5 - 3.3. Route Filter Routes for Legacy Routers . . . . . . . . . 6 - 3.4. Optimized Exit Control . . . . . . . . . . . . . . . . . 6 - 4. BGP Events . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 4.1. Notification of Routing Events . . . . . . . . . . . . . 7 - 4.2. Tracing Dropped BGP Routes . . . . . . . . . . . . . . . 8 - 4.3. BGP Protocol Statistics . . . . . . . . . . . . . . . . . 8 - 5. Central membership computation for MPLS based VPNs . . . . . 9 - 6. Marking Overlapping Traffic Engineering Routes for Removal . 11 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 - 9.2. Informative References . . . . . . . . . . . . . . . . . 12 - Appendix A. BGP Configuration . . . . . . . . . . . . . . . . . 13 - A.1. BGP Protocol Configuration . . . . . . . . . . . . . . . 14 - A.2. BGP Policy Configuration . . . . . . . . . . . . . . . . 15 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 + 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 + 1.2. Requirements for I2S . . . . . . . . . . . . . . . . . . 4 + 2. Summary of Requirements for I2RS . . . . . . . . . . . . . . 4 + 3. BGP Protocol Operation . . . . . . . . . . . . . . . . . . . 6 + 3.1. BGP Error Handling for Internal BGP Sessions . . . . . . 6 + 3.2. Summary of I2RS Capabilities and Interactions . . . . . . 7 + 4. BGP Route Manipulation . . . . . . . . . . . . . . . . . . . 7 + 4.1. Customized Best Path Selection Criteria . . . . . . . . . 7 + 4.2. Flowspec Routes . . . . . . . . . . . . . . . . . . . . . 8 + 4.3. Route Filter Routes for Legacy Routers . . . . . . . . . 8 + 4.4. Optimized Exit Control . . . . . . . . . . . . . . . . . 9 + 4.5. Summary of I2RS Capabilities and Interactions . . . . . . 9 + 5. BGP Events . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 5.1. Notification of Routing Events . . . . . . . . . . . . . 10 + 5.2. Tracing Dropped BGP Routes . . . . . . . . . . . . . . . 11 + 5.3. BGP Protocol Statistics . . . . . . . . . . . . . . . . . 12 + 5.4. Summary of I2RS Capabilities and Interactions for Event + statistics . . . . . . . . . . . . . . . . . . . . . . . 13 + 6. Central membership computation for MPLS based VPNs . . . . . 14 + 7. Marking Overlapping Traffic Engineering Routes for Removal . 15 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 + 10.2. Informative References . . . . . . . . . . . . . . . . . 16 + Appendix A. BGP Configuration . . . . . . . . . . . . . . . . . 17 + A.1. BGP Protocol Configuration . . . . . . . . . . . . . . . 18 + A.2. BGP Policy Configuration . . . . . . . . . . . . . . . . 19 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction Typically, a network routing protocol like BGP is configured and results of its operation are analyzed through some form of Command Line Interface (CLI) or NETCONF. These interactions to control BGP and diagnose its operation encompass: configuration of protocol parameters, display of protocol data, setting of certain protocol state and debugging of the protocol. @@ -134,169 +138,334 @@ fit within the overall I2RS architecture. It is intended to provide a basis for the solutions draft describing the set of Interfaces to the BGP protocol. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. -2. BGP Protocol Operation +1.2. Requirements for I2S + + Each of the sections below (BGP protocol operation, BGP Route + Manipulation, BGP Events, Central Membership for MPLS based VPNs, and + Marking Overlapping BGP Routes) have specified a use case + descriptions followed by a summary of I2RS requirements. Each + requirement listed in these sections is given an number [REQnn] where + nn is the unique BGP Requirement. Requirements duplicated from + previous sections are repeated with the original requirements number. + +2. Summary of Requirements for I2RS + + This is a summary of the requirements listed in this document. + + o REQ01: I2RS client/agent exchange SHOULD support the read, write + and quick notification of status of the BGP peer operational state + on each router within a given Autonomous System (AS). This + operational status includes the quick notification of protocol + events that proceed a destructive tear-down of BGP session + + o REQ02: I2RS client SHOULD be able to push BGP routes with custom + cost communities to specific I2RS agents on BGP routers for + insertion in specific BGP Peer(s) to aid Traffic engineering of + data paths. These routes SHOULD be tracked by the I2RS Agent as + specific BGP routes with customer cost communities. These routes + (will/will not) installed via the RIB-Info. + + o REQ03: I2RS client SHOULD be able to track via read/notifications + all Traffic engineering changes applied via I2RS agents to BGP + route processes in all routers in a network. + + o REQ04: I2RS Agents SHOULD support identification of routers as BGP + ASBRs, PE routers, and IBGP routers. + + o REQ05: I2RS client-agent SHOULD support writing traffic flow + specifications to I2RS Agents that will install them in associated + BGP ASBRs and the PE routers. + + o REQ06: I2RS Client SHOULD be able to track flow specifications + installed within a IBGP Cloud within an AS via reads of BGP Flow + Specification information in I2RS Agent, or via notifications from + I2RS agent + + o REQ07: I2RS client-agent exchange SHOULD support the I2RS client + being able to prioritize and control BGP's announcement of flow + specifications after status information reading BGP ASBR and PE + router's capacity. BGP ASBRs and PE routers functions within a + router MAY forward traffic flow specifications received from EBGP + speakers to I2RS agents, so the I2RS Agent SHOULD be able to send + these flow specifications from EBGP sources to a client in + response to a read or notification. + + o REQ08: I2RS Client SHOULD be able to read BGP route filter + information from I2RS Agents associated with legacy BGP routers, + and write filter information via the I2RS agent to be installed in + BGP RR. The I2RS Agent SHOULD be able to install these routes in + the BGP RR, and engage a BGP protocol action to push these routers + to ASBR and PE routers. + + o REQ09: I2RS client(s) SHOULD be able to request the I2RS agent to + read BGP routes with all BGP parameters that influence BGP best + path decision, and write appropriate changes to the BGP Routes to + BGP and to the RIB-Info in order to manipulate BGP routes + + o REQ10: I2RS client SHOULD be able instruct the I2RS agent(s) to + notify the I2RS client when the BGP processes on an associated + routing system observe a route change to a specific set of IP + Prefixes and associated prefixes. Route changes include: 1) + prefixes being announced or withdrawn, 2) prefixes being + suppressed due to flap damping, or 3) prefixes using an alternate + best-path for a given IP Prefix. The I2RS agent should be able to + notify the client via publish or subscribe mechanism. + + o REQ11: I2RS client SHOULD be able to read BGP route information + from BGP routers on routes in received but rejected from ADJ-RIB- + IN due to policy, on routes installed in ADJ-RIB-IN, but not + selected as best path, and on route not sent to IBGP peers (due to + non-selection). + + o REQ12: I2RS client SHOULD be able to request the I2RS agent to + read installed BGP Policies. + + o REQ13: I2RS client SHOULD be able to instruct the I2RS Agent to + write BGP Policies into the running BGP protocols and into the BGP + configurations. + + o REQ14: I2RS client-agent SHOULD be able to read BGP statistics + associated with Peer, and to receive notifications when certain + statistics have exceeded limits. An example of one of these + protocol statistics is the max-prefix limit. + + o REQ15: The I2RS client via the I2RS agent MUST have the ability to + read the loc-RIB-In BGP table that gets all the routes that the CE + has provided to a PE router. + + o REQ16: The I2RS client via the I2RS agent MUST have the ability to + install destination based routes in the local RIB of the PE + devices. This must include the ability to supply the destination + prefix (NLRI), a table identifier, a route preference, a route + metric, a next-hop tunnel through which traffic would be carried + + o REQ17: The I2RS client via the I2RS agent SHOULD have the the + ability to read the loc-RIB-in BGP table to discover overlapping + routes, and determine which may be safely marked for removal. + + o REQ18: The I2RS client via the I2RS Agent SHOULD have the ability + to modify filtering rules and initiate a re-computation of the + local BGP table through those policies to cause specific routes to + be marked for removal at the outbound eBGP edge. + +3. BGP Protocol Operation It is increasingly common for services facilitated via BGP to be subject to severe, widespread disruptions (outages), primarily due to the destructive teardown of BGP sessions as a result of receiving malformed BGP attributes. Unfortunately, more fine-grained BGP error handling solutions, which would result in little to no impact on the operation of BGP protocol, remain elusive. A planned Graceful must also carefully be handled to limit the amount of traffic loss during a the shutdown. While operational requirements for the BGP mechanism for graceful shutdown of a (set of) BGP sessions is describe din [RFC6198], and the operational procedures are described in [I-D.ietf-grow-bgp-gshut], additional fine-grained BGP error handling could improve graceful shutdown of BGP sessions. This section discussed how I2RS information could improve both the destructive teardown and the graceful teardown of sessions. -2.1. BGP Error Handling for Internal BGP Sessions +3.1. BGP Error Handling for Internal BGP Sessions It is possible that I2RS could enable enhanced error handling techniques for Internal BGP sessions. At a minimum, I2RS-capable BGP routers could signal an event such as "Malformed Attribute Received" - toward an I2RS client(s). I2RS clients(s) may already have a real- - time view of BGP routes, and corresponding BGP attributes, or may - dynamically interrogate BGP routers in the network to identify the - present propagation scope of the BGP route(s) that are affected. - Finally, the I2RS client(s) could then signal back to BGP routers to - apply a filter that would block propagation of the BGP attribute or - BGP route, as necessary, in order to temporarily aid in consistency - of BGP routing information across the entire network until a - permanent fix can be developed and deployed within BGP routers. + via an I2RS agent toward an I2RS client(s). I2RS client(s) may + already have a real-time view of BGP routes, and corresponding BGP + attributes, or may dynamically interrogate BGP routers in the network + to identify the present propagation scope of the BGP route(s) that + are affected. Finally, the I2RS client(s) could then signal back to + I2RS agents on BGP routers to apply a filter that would block + propagation of the BGP attribute or BGP route, as necessary, in order + to temporarily aid in consistency of BGP routing information across + the entire network until a permanent fix can be developed and + deployed within BGP routers. I2RS would enable the global visibility and global control over the operational state of BGP, within a given Autonomous System, that is necessary to facilitate the learning of, rapid response to and more fine-grained isolation/scoping of BGP protocol events that currently cause a destructive tear-down of BGP sessions that lead to widespread disruptions of services. -3. BGP Route Manipulation +3.2. Summary of I2RS Capabilities and Interactions + + o REQ01: I2RS client/agent exchange SHOULD support the read, write + and quick notification of status of the BGP peer operational state + on each router within a given Autonomous System (AS). This + operational status includes the quick notification of protocol + events that proceed a destructive tear-down of BGP session + +4. BGP Route Manipulation Multiprotocol BGP [RFC4760] provides support to carry routing information for different BGP address families. Route manipulation is heavily done across these different address families for different reasons. BGP IPv4 and IPv6 address families use BGP Communities - [RFC1997] and other IBGP and EBGP attributes to manipulate BGP routes - for Traffic Engineering purpose. BGP VPN adddress families use + for Traffic Engineering purpose. BGP VPN address families use Extended Communities [RFC4360] to filter unwanted BGP routes. BGP Flowspec address family [RFC5575] is used to install Flow based filters to filter unwanted data traffic. The following sub-sections describe the use of IRS towards BGP Route Manipulation for different BGP address families. -3.1. Customized Best Path Selection Criteria +4.1. Customized Best Path Selection Criteria The BGP customized Bestpath facilitates custom bestpath computations within a BGP speaking network. It is usually used within an IBGP network. Customized bestpaths use special extended communities known as cost communities. Cost communities carry enough information; Point of Insertion (POI) and the cost value to signal where in BGP bestpath the customize checks need to be done. Both, the traffic engineering as well as backdoor (SHAM) links use customized bestpath computation. With I2RS, it would be possible for an I2RS client to push routes with custom cost communities on the BGP routers for Traffic Engineering purpose. I2RS client now can act as a central entity keeping track of all Traffic engineering data that get applied to BGP routes within an IBGP network. -3.2. Flowspec Routes +4.2. Flowspec Routes The BGP flowspec address family is used to disseminate the traffic flow specification to the BGP Autonomous System Border Routers (ASBRs) and Provider Edge (PE) routers. Both, the BGP ASBRs and the PEs would translate the received BGP traffic flow specification into an Access Control List (ACL) and install it in router's forwarding path. Using such ACLs routers can now classify, shape, rate limit, filter, or redirect traffic flows. With I2RS, it would be possible for an I2RS client to push traffic flow specifications to the BGP ASBRs and the PE routers. I2RS client can act as a central entity tracking all the traffic flow specifications that are installed within an IBGP network. I2RS client could also prioritize and control the announcement of traffic flow specifications according to various ASRBs and PE router's capacity. BGP ASBRs and PE routers MAY forward traffic flow specifications received from EBGP speakers to I2RS Agents. This would allow I2RS agents to centrally manage and track any externally received traffic flow specifications. -3.3. Route Filter Routes for Legacy Routers +4.3. Route Filter Routes for Legacy Routers The BGP Route Filter address family is used to disseminate the Route Target filter information between VPN BGP speakers. This information is then used to build a route distribution graph that helps in - limiting the propagation of VPN NLRI within a VPN network. However, - it requires that all the BGP VPN routers are upgraded to support this - functionality. Otherwise, the graph information is incomplete when a - VPN network consists of legacy routers that participates in VPN but - does not implement the BGP route filter address family. + limiting the propagation of VPN NLRI (network Layer Reachabilty + Information) within a VPN network. However, it requires that all the + BGP VPN routers are upgraded to support this functionality. + Otherwise, the graph information is incomplete when a VPN network + consists of legacy routers that participates in VPN but does not + implement the BGP route filter address family. With I2RS, it would be possible for an I2RS client to push router filter information to BGP RR routers on behalf of all legacy routers that participates in VPN but does not support or implement the BGP route filter address family. I2RS client can act as a central entity tracking all the configured Route Filters for legacy routers and push them on appropriate RRs who in turn would push it to ASBRs and PE routers. In this way, I2RS agents help build an optimal route distribution graph that would assist in filtering of VPN NLRIs in a VPN network. -3.4. Optimized Exit Control +4.4. Optimized Exit Control Optimized Exit Control is used to provide route optimization and load distribution for multiple network connections between networks. Network operators can monitor IP traffic flows and then could define policies and rules based on traffic class performance, link bandwidth monetary costs, link load distribution, traffic types, link failures, etc. With I2RS, it would be possible for an I2RS client to manipulate BGP routes and its parameters that influence BGP bestpath decisions. I2RS client could act as a central entity that would monitor and manipulate BGP routes based on central network based policies. Such routes would then be injected by a I2RS client into the network so as to get the load distribution for multiple network connections. -4. BGP Events +4.5. Summary of I2RS Capabilities and Interactions + + o REQ02: I2RS client SHOULD be able to push BGP routes with custom + cost communities to specific I2RS agents on BGP routers for + insertion in specific BGP Peer(s) to aid Traffic engineering of + data paths. These routes SHOULD be tracked by the I2RS Agent as + specific BGP routes with customer cost communities. These routes + (will/will not) installed via the RIB-Info. + + o REQ03: I2RS client SHOULD be able to track via read/notifications + all Traffic engineering changes applied via I2RS agents to BGP + route processes in all routers in a network. + + o REQ04: I2RS Agents SHOULD support identification of routers as BGP + ASBRs, PE routers, IBGP routers. + + o REQ05: I2RS client-agent SHOULD support writing traffic flow + specifications to I2RS Agents that will install them in associated + BGP ASBRs and the PE routers. + + o REQ06: I2RS Client SHOULD be able to track flow specifications + installed within a IBGP Cloud within an AS via reads of BGP Flow + Specification information in I2RS Agent, or via notifications from + I2RS agent. + + o REQ07: I2RS client-agent exchange SHOULD support the I2RS client + being able to prioritize and control BGP's announcement of flow + specifications after status information reading BGP ASBR and PE + router's capacity. BGP ASBRs and PE routers functions within a + router MAY forward traffic flow specifications received from EBGP + speakers to I2RS agents, so the I2RS Agent SHOULD be able to send + these flow specifications from EBGP sources to a client in + response to a read or notification. + + o REQ08: I2RS Client SHOULD be able to read BGP route filter + information from I2RS Agents associated with legacy BGP routers, + and write filter information via the I2RS agent to be installed in + BGP RR. The I2RS Agent SHOULD be able to install these routes in + the BGP RR, and engage a BGP protocol action to push these routers + to ASBR and PE routers. + + o REQ09: I2RS client(s) SHOULD be able to request the I2RS agent to + read BGP routes with all BGP parameters that influence BGP best + path decision, and write appropriate changes to the BGP Routes to + BGP and to the RIB-Info in order to manipulate BGP routes + +5. BGP Events Given the extremely large number of BGP Routes in networks, it is critical to have scalable mechanisms that can be used to monitor for events affecting routing state and, consequently, reachability. In addition, similar tools are needed in order to monitor BGP protocol statistics, which help operators and developers better understand scalability of software and hardware that BGP utilizes. I2RS could provide a publish-subscribe capability to applications to: o request monitoring of BGP routes and related events; and, o subscribe to the I2RS client to receive events related to BGP routes or other protocol-related events of interest. -4.1. Notification of Routing Events +5.1. Notification of Routing Events There are certain IP prefixes, for example those that are arbitrarily classified by a given network operator as "high visibility" by its end-users, for which immediate notification of changes in their state are extremely useful to know about. Upon notification of such events, a Network Operations Center (NOC) could respond to customer inquiries in a more timely fashion; alternatively, the NOC may decide to perform Traffic Engineering to restore service, etc. Currently, the only way to learn of such events is for a BGP @@ -325,26 +494,25 @@ o an IP prefix being suppressed, due to route flap dampening o an alternative best-path being chosen for a given IP prefix When the requisite events for a BGP Route are observed by a BGP router, it would notify I2RS agents. The I2RS agents would have a publish/subscribe mechanism whereby various sets of applications may subscribe to events of interest. - The I2RS client would then publish these events so applications would immediately receive them and take the appropriate domain-specific action necessary. -4.2. Tracing Dropped BGP Routes +5.2. Tracing Dropped BGP Routes It is extremely useful to operators to be able to rapidly identify instances where a BGP route is not being propagated within an Autonomous System. At a minimum, this could result in sub-optimal performance when attempting to reach such destinations. There are two instances when this scenario will occur. First, when a Service Provider is using "Soft Reconfiguration Inbound", it allows their ASBR routers to receive a copy of a BGP route, but show that route was not permitted into the Adj-RIB-In most likely as a result @@ -365,21 +533,21 @@ With I2RS, it would be possible for an I2RS client to rapidly gather information from across a large set of BGP routers in the network to determine at what ASBR's the BGP route is being learned. Next, the I2RS client could interrogate those routers BGP policies to determine the root cause of why the route was either not learned or not preferred in BGP. Finally, if necessary, the I2RS client(s) could amend BGP policies and push them out to BGP routers to permit the BGP route or make it a preferred route according to the BGP path selection algorithm. -4.3. BGP Protocol Statistics +5.3. BGP Protocol Statistics There are a variety of statistics related to the operation of BGP that are invaluable to network operators. These statistics generally help operators, and developers, understand the present state and future scalability of BGP. One statistic that is invaluable to operators is the current number of BGP routes learned through an eBGP session. Operators then apply a command against each eBGP session to limit the maximum number of BGP routes that may be learned through that eBGP session before a @@ -412,21 +580,52 @@ prefix limit" values are adjusted. It's similarly possible that the BGP routers may, through the I2RS, pull the "max-prefix limit" values for each eBGP neighbor they have on-board on a periodic basis and validate their accuracy. The above is just one use case related to BGP protocol statistics. There are wealth of other BGP protocol statistics or state information that would be invaluable to have programmatic visibility into that operators do not have today. -5. Central membership computation for MPLS based VPNs +5.4. Summary of I2RS Capabilities and Interactions for Event statistics + + I2RS SHOULD have the ability to: + + o REQ10: I2RS client SHOULD be able instruct the I2RS agent(s) to + notify the I2RS client when the BGP processes on an associated + routing system observe a route change to a specific set of IP + Prefixes and associated prefixes. Route changes include: 1) + prefixes being announced or withdrawn, 2) prefixes being + suppressed due to flap damping, or 3) prefixes using an alternate + best-path for a given IP Prefix. The I2RS agent should be able to + notify the client via publish or subscribe mechanism. + + o REQ11: I2RS client SHOULD be able to read BGP route information + from BGP routers on routes in received but rejected from ADJ-RIB- + IN due to policy, on routes installed in ADJ-RIB-IN, but not + selected as best path, and on route not sent to IBGP peers (due to + non-selection). + + o REQ12: I2RS client SHOULD be able to request the I2RS agent to + read installed BGP Policies + + o REQ13: I2RS client SHOULD be able to instruct the I2RS Agent to + write BGP Policies into the running BGP protocols and into the BGP + configurations. + + o REQ14: I2RS client-agent SHOULD be able to read BGP statistics + associated with Peer, and to receive notifications when certain + statistics have exceeded limits. An example of one of these + protocol statistics is the max-prefix limit. + +6. Central membership computation for MPLS based VPNs MPLS based VPNs use route target extended communities to express membership information. Every PE router holds incoming BGP NLRI and processes them to determine membership and then import the NLRI into the appropriate MPLS/VPN routing tables. This consumes resources, both memory and compute on each of the PE devices. An alternative approach is to monitor routing updates on every PE from the attached CEs and then compute membership in a central manner. Once computed the routes are pushed to the VPN RIBs of the @@ -461,70 +660,71 @@ particularly been a challenge. Also note that one of the biggest promises of central route computation is simplification and reduction of computation and memory load on all devices in the network. This use case is just one example that illustrates these benefits of central computation very well. Summary of I2RS Capabilities and Interactions: - o The ability to read the loc-RIB-In BGP table that gets all the - routes that the CE has provided to a PE router. + o REQ15:The I2RS client via the I2RS agent MUST have the ability to + read the loc-RIB-In BGP table that gets all the routes that the CE + has provided to a PE router. - o The ability to install destination based routes in the local RIB - of the PE devices. This must include the ability to supply the - destination prefix (NLRI), a table identifier, a route preference, - a route metric, a next-hop tunnel through which traffic would be - carried + o REQ16:The I2RS client via the I2RS agent MUST have the ability to + install destination based routes in the local RIB of the PE + devices. This must include the ability to supply the destination + prefix (NLRI), a table identifier, a route preference, a route + metric, a next-hop tunnel through which traffic would be carried -6. Marking Overlapping Traffic Engineering Routes for Removal +7. Marking Overlapping Traffic Engineering Routes for Removal It is often the case that routes are advertised not to provide reachability (in the strict sense), but rather to provide optimal reachability, or to engineer the path traffic takes to a particular destination. While this can improve the efficiency of a network's operation, it can also increase the amount of state carried in the control plane beyond the point where the additional state has any real effect on traffic flow. Removing Overlapping Routes [I-D.white-grow-overlapping-routes] provides a mechanism designed to remove these traffic engineering routes once they are beyond the point of actually impacting traffic flows in the network. Summary of I2RS Capabilities and Interactions: - o The ability to read the loc-RIB-in BGP table to discover - overlapping routes, and determine which may be safely marked for - removal. + o REQ17: The I2RS client via the I2RS agent SHOULD have the the + ability to read the loc-RIB-in BGP table to discover overlapping + routes, and determine which may be safely marked for removal. - o The ability to modify filtering rules and initiate a re- - computation of the local BGP table through those policies to cause - specific routes to be marked for removal at the outbound eBGP - edge. + o REQ18: The I2RS client via the I2RS Agent SHOULD have the ability + to modify filtering rules and initiate a re-computation of the + local BGP table through those policies to cause specific routes to + be marked for removal at the outbound eBGP edge. -7. Security Considerations +8. Security Considerations The BGP use cases described in this document assumes use of I2RS programmatic interfaces described in the I2RS framework mentioned in [I-D.ietf-i2rs-architecture]. This document does not change the underlying security issues inherent in the existing in [I-D.ietf-i2rs-architecture]. -8. Acknowledgements +9. Acknowledgements The authors would like to thank Ed Crabbe, Joel Halpern, Wes George, Carlos Pignataro, Jon Mitchell and Bill Atwood for their comments and suggestions. -9. References +10. References -9.1. Normative References +10.1. Normative References [I-D.ietf-i2rs-architecture] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. Nadeau, "An Architecture for the Interface to the Routing System", draft-ietf-i2rs-architecture-03 (work in progress), May 2014. [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, August 1996. @@ -544,21 +744,21 @@ [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006. [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. -9.2. Informative References +10.2. Informative References [I-D.ietf-grow-bgp-gshut] Francois, P., Decraene, B., Pelsser, C., Patel, K., and C. Filsfils, "Graceful BGP session shutdown", draft-ietf- grow-bgp-gshut-05 (work in progress), January 2014. [I-D.mcpherson-irr-routing-policy-considerations] McPherson, D., Amante, S., Osterweil, E., and L. Blunk, "IRR & Routing Policy Configuration Considerations", draft-mcpherson-irr-routing-policy-considerations-01 (work @@ -769,26 +969,21 @@ Hannes Gredler Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 USA Email: hannes@juniper.net Shane Amante - Level 3 Communications, Inc. - 1025 Eldorado Blvd - Broomfield, CO 80021 - USA - - Email: shane@level3.net + Apple Russ White Ericsson Email: russw@riw.us Susan Hares - Hickory Hill Consulting + Huawei Email: shares@ndzh.com