draft-keyupate-i2rs-bgp-usecases-03.txt   draft-keyupate-i2rs-bgp-usecases-04.txt 
I2RS Working Group K. Patel I2RS Working Group K. Patel
Internet-Draft R. Fernando Internet-Draft R. Fernando
Intended status: Informational Cisco Systems Intended status: Informational Cisco Systems
Expires: December 19, 2014 H. Gredler Expires: January 5, 2015 H. Gredler
Juniper Networks Juniper Networks
S. Amante S. Amante
Apple Apple
R. White R. White
Ericsson Ericsson
S. Hares S. Hares
Huawei Huawei
June 17, 2014 July 4, 2014
Use Cases for an Interface to BGP Protocol Use Cases for an Interface to BGP Protocol
draft-keyupate-i2rs-bgp-usecases-03.txt draft-keyupate-i2rs-bgp-usecases-04.txt
Abstract Abstract
A network routing protocol like BGP is typically configured and A network routing protocol like BGP is typically configured and
analyzed through some form of Command Line Interface (CLI) or analyzed through some form of Command Line Interface (CLI) or
NETCONF. These interactions to control BGP and diagnose its NETCONF. These interactions to control BGP and diagnose its
operation encompass: configuration of protocol parameters, display of operation encompass: configuration of protocol parameters, display of
protocol data, setting of certain protocol state and debugging of the protocol data, setting of certain protocol state and debugging of the
protocol. protocol.
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 19, 2014. This Internet-Draft will expire on January 5, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 25 skipping to change at page 4, line 25
Marking Overlapping BGP Routes) have specified a use case Marking Overlapping BGP Routes) have specified a use case
descriptions followed by a summary of I2RS requirements. Each descriptions followed by a summary of I2RS requirements. Each
requirement listed in these sections is given an number [REQnn] where requirement listed in these sections is given an number [REQnn] where
nn is the unique BGP Requirement. Requirements duplicated from nn is the unique BGP Requirement. Requirements duplicated from
previous sections are repeated with the original requirements number. previous sections are repeated with the original requirements number.
2. Summary of Requirements for I2RS 2. Summary of Requirements for I2RS
This is a summary of the requirements listed in this document. This is a summary of the requirements listed in this document.
o REQ01: I2RS client/agent exchange SHOULD support the read, write o BGP-REQ01: I2RS client/agent exchange SHOULD support the read,
and quick notification of status of the BGP peer operational state write and quick notification of status of the BGP peer operational
on each router within a given Autonomous System (AS). This state on each router within a given Autonomous System (AS). This
operational status includes the quick notification of protocol operational status includes the quick notification of protocol
events that proceed a destructive tear-down of BGP session events that proceed a destructive tear-down of BGP session
o REQ02: I2RS client SHOULD be able to push BGP routes with custom o BGP-REQ02: I2RS client SHOULD be able to push BGP routes with
cost communities to specific I2RS agents on BGP routers for custom cost communities to specific I2RS agents on BGP routers for
insertion in specific BGP Peer(s) to aid Traffic engineering of insertion in specific BGP Peer(s) to aid Traffic engineering of
data paths. These routes SHOULD be tracked by the I2RS Agent as data paths. These routes SHOULD be tracked by the I2RS Agent as
specific BGP routes with customer cost communities. These routes specific BGP routes with customer cost communities. These routes
(will/will not) installed via the RIB-Info. (will/will not) installed via the RIB-Info.
o REQ03: I2RS client SHOULD be able to track via read/notifications o BGP-REQ03: I2RS client SHOULD be able to track via read/
all Traffic engineering changes applied via I2RS agents to BGP notifications all Traffic engineering changes applied via I2RS
route processes in all routers in a network. agents to BGP route processes in all routers in a network.
o REQ04: I2RS Agents SHOULD support identification of routers as BGP o BGP-REQ04: I2RS Agents SHOULD support identification of routers as
ASBRs, PE routers, and IBGP routers. BGP ASBRs, PE routers, and IBGP routers.
o REQ05: I2RS client-agent SHOULD support writing traffic flow o BGP-REQ05: I2RS client-agent SHOULD support writing traffic flow
specifications to I2RS Agents that will install them in associated specifications to I2RS Agents that will install them in associated
BGP ASBRs and the PE routers. BGP ASBRs and the PE routers.
o REQ06: I2RS Client SHOULD be able to track flow specifications o BGP-REQ06: I2RS Client SHOULD be able to track flow specifications
installed within a IBGP Cloud within an AS via reads of BGP Flow installed within a IBGP Cloud within an AS via reads of BGP Flow
Specification information in I2RS Agent, or via notifications from Specification information in I2RS Agent, or via notifications from
I2RS agent I2RS agent
o REQ07: I2RS client-agent exchange SHOULD support the I2RS client o BGP-REQ07: I2RS client-agent exchange SHOULD support the I2RS
being able to prioritize and control BGP's announcement of flow client being able to prioritize and control BGP's announcement of
specifications after status information reading BGP ASBR and PE flow specifications after status information reading BGP ASBR and
router's capacity. BGP ASBRs and PE routers functions within a PE router's capacity. BGP ASBRs and PE routers functions within a
router MAY forward traffic flow specifications received from EBGP router MAY forward traffic flow specifications received from EBGP
speakers to I2RS agents, so the I2RS Agent SHOULD be able to send speakers to I2RS agents, so the I2RS Agent SHOULD be able to send
these flow specifications from EBGP sources to a client in these flow specifications from EBGP sources to a client in
response to a read or notification. response to a read or notification.
o REQ08: I2RS Client SHOULD be able to read BGP route filter o BGP-REQ08: I2RS Client SHOULD be able to read BGP route filter
information from I2RS Agents associated with legacy BGP routers, information from I2RS Agents associated with legacy BGP routers,
and write filter information via the I2RS agent to be installed in 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 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 the BGP RR, and engage a BGP protocol action to push these routers
to ASBR and PE routers. to ASBR and PE routers.
o REQ09: I2RS client(s) SHOULD be able to request the I2RS agent to o BGP-REQ09: I2RS client(s) SHOULD be able to request the I2RS agent
read BGP routes with all BGP parameters that influence BGP best to read BGP routes with all BGP parameters that influence BGP best
path decision, and write appropriate changes to the BGP Routes to path decision, and write appropriate changes to the BGP Routes to
BGP and to the RIB-Info in order to manipulate BGP routes 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 o BGP-REQ10: I2RS client SHOULD be able instruct the I2RS agent(s)
notify the I2RS client when the BGP processes on an associated to notify the I2RS client when the BGP processes on an associated
routing system observe a route change to a specific set of IP routing system observe a route change to a specific set of IP
Prefixes and associated prefixes. Route changes include: 1) Prefixes and associated prefixes. Route changes include: 1)
prefixes being announced or withdrawn, 2) prefixes being prefixes being announced or withdrawn, 2) prefixes being
suppressed due to flap damping, or 3) prefixes using an alternate 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 best-path for a given IP Prefix. The I2RS agent should be able to
notify the client via publish or subscribe mechanism. notify the client via publish or subscribe mechanism.
o REQ11: I2RS client SHOULD be able to read BGP route information o BGP-REQ11: I2RS client SHOULD be able to read BGP route
from BGP routers on routes in received but rejected from ADJ-RIB- information from BGP routers on routes in received but rejected
IN due to policy, on routes installed in ADJ-RIB-IN, but not from ADJ-RIB-IN due to policy, on routes installed in ADJ-RIB-IN,
selected as best path, and on route not sent to IBGP peers (due to but not selected as best path, and on route not sent to IBGP peers
non-selection). (due to non-selection).
o REQ12: I2RS client SHOULD be able to request the I2RS agent to o BGP-REQ12: I2RS client SHOULD be able to request the I2RS agent to
read installed BGP Policies. read installed BGP Policies.
o REQ13: I2RS client SHOULD be able to instruct the I2RS Agent to o BGP-REQ13: I2RS client SHOULD be able to instruct the I2RS Agent
write BGP Policies into the running BGP protocols and into the BGP to write BGP Policies into the running BGP protocols and into the
configurations. BGP configurations.
o REQ14: I2RS client-agent SHOULD be able to read BGP statistics o BGP-REQ14: I2RS client-agent SHOULD be able to read BGP statistics
associated with Peer, and to receive notifications when certain associated with Peer, and to receive notifications when certain
statistics have exceeded limits. An example of one of these statistics have exceeded limits. An example of one of these
protocol statistics is the max-prefix limit. protocol statistics is the max-prefix limit.
o REQ15: The I2RS client via the I2RS agent MUST have the ability to o BGP-REQ15: The I2RS client via the I2RS agent MUST have the
read the loc-RIB-In BGP table that gets all the routes that the CE ability to read the loc-RIB-In BGP table that gets all the routes
has provided to a PE router. that the CE has provided to a PE router.
o REQ16: The I2RS client via the I2RS agent MUST have the ability to o BGP-REQ16: The I2RS client via the I2RS agent MUST have the
install destination based routes in the local RIB of the PE ability to install destination based routes in the local RIB of
devices. This must include the ability to supply the destination the PE devices. This must include the ability to supply the
prefix (NLRI), a table identifier, a route preference, a route destination prefix (NLRI), a table identifier, a route preference,
metric, a next-hop tunnel through which traffic would be carried 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 o BGP-REQ17: The I2RS client via the I2RS agent SHOULD have the the
ability to read the loc-RIB-in BGP table to discover overlapping ability to read the loc-RIB-in BGP table to discover overlapping
routes, and determine which may be safely marked for removal. routes, and determine which may be safely marked for removal.
o REQ18: The I2RS client via the I2RS Agent SHOULD have the ability o BGP-REQ18: The I2RS client via the I2RS Agent SHOULD have the
to modify filtering rules and initiate a re-computation of the ability to modify filtering rules and initiate a re-computation of
local BGP table through those policies to cause specific routes to the local BGP table through those policies to cause specific
be marked for removal at the outbound eBGP edge. routes to be marked for removal at the outbound eBGP edge.
3. BGP Protocol Operation 3. BGP Protocol Operation
It is increasingly common for services facilitated via BGP to be It is increasingly common for services facilitated via BGP to be
subject to severe, widespread disruptions (outages), primarily due to subject to severe, widespread disruptions (outages), primarily due to
the destructive teardown of BGP sessions as a result of receiving the destructive teardown of BGP sessions as a result of receiving
malformed BGP attributes. Unfortunately, more fine-grained BGP error malformed BGP attributes. Unfortunately, more fine-grained BGP error
handling solutions, which would result in little to no impact on the handling solutions, which would result in little to no impact on the
operation of BGP protocol, remain elusive. operation of BGP protocol, remain elusive.
skipping to change at page 7, line 20 skipping to change at page 7, line 21
I2RS would enable the global visibility and global control over the I2RS would enable the global visibility and global control over the
operational state of BGP, within a given Autonomous System, that is operational state of BGP, within a given Autonomous System, that is
necessary to facilitate the learning of, rapid response to and more necessary to facilitate the learning of, rapid response to and more
fine-grained isolation/scoping of BGP protocol events that currently fine-grained isolation/scoping of BGP protocol events that currently
cause a destructive tear-down of BGP sessions that lead to widespread cause a destructive tear-down of BGP sessions that lead to widespread
disruptions of services. disruptions of services.
3.2. Summary of I2RS Capabilities and Interactions 3.2. Summary of I2RS Capabilities and Interactions
o REQ01: I2RS client/agent exchange SHOULD support the read, write o BGP-REQ01: I2RS client/agent exchange SHOULD support the read,
and quick notification of status of the BGP peer operational state write and quick notification of status of the BGP peer operational
on each router within a given Autonomous System (AS). This state on each router within a given Autonomous System (AS). This
operational status includes the quick notification of protocol operational status includes the quick notification of protocol
events that proceed a destructive tear-down of BGP session events that proceed a destructive tear-down of BGP session
4. BGP Route Manipulation 4. BGP Route Manipulation
Multiprotocol BGP [RFC4760] provides support to carry routing Multiprotocol BGP [RFC4760] provides support to carry routing
information for different BGP address families. Route manipulation information for different BGP address families. Route manipulation
is heavily done across these different address families for different is heavily done across these different address families for different
reasons. BGP IPv4 and IPv6 address families use BGP Communities reasons. BGP IPv4 and IPv6 address families use BGP Communities
[RFC1997] and other IBGP and EBGP attributes to manipulate BGP routes [RFC1997] and other IBGP and EBGP attributes to manipulate BGP routes
skipping to change at page 9, line 23 skipping to change at page 9, line 23
With I2RS, it would be possible for an I2RS client to manipulate BGP With I2RS, it would be possible for an I2RS client to manipulate BGP
routes and its parameters that influence BGP bestpath decisions. routes and its parameters that influence BGP bestpath decisions.
I2RS client could act as a central entity that would monitor and I2RS client could act as a central entity that would monitor and
manipulate BGP routes based on central network based policies. Such manipulate BGP routes based on central network based policies. Such
routes would then be injected by a I2RS client into the network so as routes would then be injected by a I2RS client into the network so as
to get the load distribution for multiple network connections. to get the load distribution for multiple network connections.
4.5. Summary of I2RS Capabilities and Interactions 4.5. Summary of I2RS Capabilities and Interactions
o REQ02: I2RS client SHOULD be able to push BGP routes with custom o BGP-REQ02: I2RS client SHOULD be able to push BGP routes with
cost communities to specific I2RS agents on BGP routers for custom cost communities to specific I2RS agents on BGP routers for
insertion in specific BGP Peer(s) to aid Traffic engineering of insertion in specific BGP Peer(s) to aid Traffic engineering of
data paths. These routes SHOULD be tracked by the I2RS Agent as data paths. These routes SHOULD be tracked by the I2RS Agent as
specific BGP routes with customer cost communities. These routes specific BGP routes with customer cost communities. These routes
(will/will not) installed via the RIB-Info. (will/will not) installed via the RIB-Info.
o REQ03: I2RS client SHOULD be able to track via read/notifications o BGP-REQ03: I2RS client SHOULD be able to track via read/
all Traffic engineering changes applied via I2RS agents to BGP notifications all Traffic engineering changes applied via I2RS
route processes in all routers in a network. agents to BGP route processes in all routers in a network.
o REQ04: I2RS Agents SHOULD support identification of routers as BGP o BGP-REQ04: I2RS Agents SHOULD support identification of routers as
ASBRs, PE routers, IBGP routers. BGP ASBRs, PE routers, IBGP routers.
o REQ05: I2RS client-agent SHOULD support writing traffic flow o BGP-REQ05: I2RS client-agent SHOULD support writing traffic flow
specifications to I2RS Agents that will install them in associated specifications to I2RS Agents that will install them in associated
BGP ASBRs and the PE routers. BGP ASBRs and the PE routers.
o REQ06: I2RS Client SHOULD be able to track flow specifications o BGP-REQ06: I2RS Client SHOULD be able to track flow specifications
installed within a IBGP Cloud within an AS via reads of BGP Flow installed within a IBGP Cloud within an AS via reads of BGP Flow
Specification information in I2RS Agent, or via notifications from Specification information in I2RS Agent, or via notifications from
I2RS agent. I2RS agent.
o REQ07: I2RS client-agent exchange SHOULD support the I2RS client o BGP-REQ07: I2RS client-agent exchange SHOULD support the I2RS
being able to prioritize and control BGP's announcement of flow client being able to prioritize and control BGP's announcement of
specifications after status information reading BGP ASBR and PE flow specifications after status information reading BGP ASBR and
router's capacity. BGP ASBRs and PE routers functions within a PE router's capacity. BGP ASBRs and PE routers functions within a
router MAY forward traffic flow specifications received from EBGP router MAY forward traffic flow specifications received from EBGP
speakers to I2RS agents, so the I2RS Agent SHOULD be able to send speakers to I2RS agents, so the I2RS Agent SHOULD be able to send
these flow specifications from EBGP sources to a client in these flow specifications from EBGP sources to a client in
response to a read or notification. response to a read or notification.
o REQ08: I2RS Client SHOULD be able to read BGP route filter o BGP-REQ08: I2RS Client SHOULD be able to read BGP route filter
information from I2RS Agents associated with legacy BGP routers, information from I2RS Agents associated with legacy BGP routers,
and write filter information via the I2RS agent to be installed in 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 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 the BGP RR, and engage a BGP protocol action to push these routers
to ASBR and PE routers. to ASBR and PE routers.
o REQ09: I2RS client(s) SHOULD be able to request the I2RS agent to o BGP-REQ09: I2RS client(s) SHOULD be able to request the I2RS agent
read BGP routes with all BGP parameters that influence BGP best to read BGP routes with all BGP parameters that influence BGP best
path decision, and write appropriate changes to the BGP Routes to path decision, and write appropriate changes to the BGP Routes to
BGP and to the RIB-Info in order to manipulate BGP routes BGP and to the RIB-Info in order to manipulate BGP routes
5. BGP Events 5. BGP Events
Given the extremely large number of BGP Routes in networks, it is Given the extremely large number of BGP Routes in networks, it is
critical to have scalable mechanisms that can be used to monitor for critical to have scalable mechanisms that can be used to monitor for
events affecting routing state and, consequently, reachability. In events affecting routing state and, consequently, reachability. In
addition, similar tools are needed in order to monitor BGP protocol addition, similar tools are needed in order to monitor BGP protocol
statistics, which help operators and developers better understand statistics, which help operators and developers better understand
skipping to change at page 13, line 24 skipping to change at page 13, line 24
The above is just one use case related to BGP protocol statistics. The above is just one use case related to BGP protocol statistics.
There are wealth of other BGP protocol statistics or state There are wealth of other BGP protocol statistics or state
information that would be invaluable to have programmatic visibility information that would be invaluable to have programmatic visibility
into that operators do not have today. into that operators do not have today.
5.4. Summary of I2RS Capabilities and Interactions for Event statistics 5.4. Summary of I2RS Capabilities and Interactions for Event statistics
I2RS SHOULD have the ability to: I2RS SHOULD have the ability to:
o REQ10: I2RS client SHOULD be able instruct the I2RS agent(s) to o BGP-REQ10: I2RS client SHOULD be able instruct the I2RS agent(s)
notify the I2RS client when the BGP processes on an associated to notify the I2RS client when the BGP processes on an associated
routing system observe a route change to a specific set of IP routing system observe a route change to a specific set of IP
Prefixes and associated prefixes. Route changes include: 1) Prefixes and associated prefixes. Route changes include: 1)
prefixes being announced or withdrawn, 2) prefixes being prefixes being announced or withdrawn, 2) prefixes being
suppressed due to flap damping, or 3) prefixes using an alternate 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 best-path for a given IP Prefix. The I2RS agent should be able to
notify the client via publish or subscribe mechanism. notify the client via publish or subscribe mechanism.
o REQ11: I2RS client SHOULD be able to read BGP route information o BGP-REQ11: I2RS client SHOULD be able to read BGP route
from BGP routers on routes in received but rejected from ADJ-RIB- information from BGP routers on routes in received but rejected
IN due to policy, on routes installed in ADJ-RIB-IN, but not from ADJ-RIB-IN due to policy, on routes installed in ADJ-RIB-IN,
selected as best path, and on route not sent to IBGP peers (due to but not selected as best path, and on route not sent to IBGP peers
non-selection). (due to non-selection).
o REQ12: I2RS client SHOULD be able to request the I2RS agent to o BGP-REQ12: I2RS client SHOULD be able to request the I2RS agent to
read installed BGP Policies read installed BGP Policies
o REQ13: I2RS client SHOULD be able to instruct the I2RS Agent to o BGP-REQ13: I2RS client SHOULD be able to instruct the I2RS Agent
write BGP Policies into the running BGP protocols and into the BGP to write BGP Policies into the running BGP protocols and into the
configurations. BGP configurations.
o REQ14: I2RS client-agent SHOULD be able to read BGP statistics o BGP-REQ14: I2RS client-agent SHOULD be able to read BGP statistics
associated with Peer, and to receive notifications when certain associated with Peer, and to receive notifications when certain
statistics have exceeded limits. An example of one of these statistics have exceeded limits. An example of one of these
protocol statistics is the max-prefix limit. protocol statistics is the max-prefix limit.
6. Central membership computation for MPLS based VPNs 6. Central membership computation for MPLS based VPNs
MPLS based VPNs use route target extended communities to express MPLS based VPNs use route target extended communities to express
membership information. Every PE router holds incoming BGP NLRI and membership information. Every PE router holds incoming BGP NLRI and
processes them to determine membership and then import the NLRI into processes them to determine membership and then import the NLRI into
the appropriate MPLS/VPN routing tables. This consumes resources, the appropriate MPLS/VPN routing tables. This consumes resources,
skipping to change at page 15, line 5 skipping to change at page 15, line 5
particularly been a challenge. particularly been a challenge.
Also note that one of the biggest promises of central route Also note that one of the biggest promises of central route
computation is simplification and reduction of computation and memory computation is simplification and reduction of computation and memory
load on all devices in the network. This use case is just one load on all devices in the network. This use case is just one
example that illustrates these benefits of central computation very example that illustrates these benefits of central computation very
well. well.
Summary of I2RS Capabilities and Interactions: Summary of I2RS Capabilities and Interactions:
o REQ15:The I2RS client via the I2RS agent MUST have the ability to o BGP-REQ15:The I2RS client via the I2RS agent MUST have the ability
read the loc-RIB-In BGP table that gets all the routes that the CE to read the loc-RIB-In BGP table that gets all the routes that the
has provided to a PE router. CE has provided to a PE router.
o REQ16:The I2RS client via the I2RS agent MUST have the ability to o BGP-REQ16:The I2RS client via the I2RS agent MUST have the ability
install destination based routes in the local RIB of the PE to install destination based routes in the local RIB of the PE
devices. This must include the ability to supply the destination devices. This must include the ability to supply the destination
prefix (NLRI), a table identifier, a route preference, a route prefix (NLRI), a table identifier, a route preference, a route
metric, a next-hop tunnel through which traffic would be carried metric, a next-hop tunnel through which traffic would be carried
7. 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 It is often the case that routes are advertised not to provide
reachability (in the strict sense), but rather to provide optimal reachability (in the strict sense), but rather to provide optimal
reachability, or to engineer the path traffic takes to a particular reachability, or to engineer the path traffic takes to a particular
destination. While this can improve the efficiency of a network's destination. While this can improve the efficiency of a network's
operation, it can also increase the amount of state carried in the operation, it can also increase the amount of state carried in the
control plane beyond the point where the additional state has any control plane beyond the point where the additional state has any
real effect on traffic flow. Removing Overlapping Routes real effect on traffic flow. Removing Overlapping Routes
[I-D.white-grow-overlapping-routes] provides a mechanism designed to [I-D.white-grow-overlapping-routes] provides a mechanism designed to
remove these traffic engineering routes once they are beyond the remove these traffic engineering routes once they are beyond the
point of actually impacting traffic flows in the network. point of actually impacting traffic flows in the network.
Summary of I2RS Capabilities and Interactions: Summary of I2RS Capabilities and Interactions:
o REQ17: The I2RS client via the I2RS agent SHOULD have the the o BGP-REQ17: The I2RS client via the I2RS agent SHOULD have the the
ability to read the loc-RIB-in BGP table to discover overlapping ability to read the loc-RIB-in BGP table to discover overlapping
routes, and determine which may be safely marked for removal. routes, and determine which may be safely marked for removal.
o REQ18: The I2RS client via the I2RS Agent SHOULD have the ability o BGP-REQ18: The I2RS client via the I2RS Agent SHOULD have the
to modify filtering rules and initiate a re-computation of the ability to modify filtering rules and initiate a re-computation of
local BGP table through those policies to cause specific routes to the local BGP table through those policies to cause specific
be marked for removal at the outbound eBGP edge. routes to be marked for removal at the outbound eBGP edge.
8. Security Considerations 8. Security Considerations
The BGP use cases described in this document assumes use of I2RS The BGP use cases described in this document assumes use of I2RS
programmatic interfaces described in the I2RS framework mentioned in programmatic interfaces described in the I2RS framework mentioned in
[I-D.ietf-i2rs-architecture]. This document does not change the [I-D.ietf-i2rs-architecture]. This document does not change the
underlying security issues inherent in the existing in underlying security issues inherent in the existing in
[I-D.ietf-i2rs-architecture]. [I-D.ietf-i2rs-architecture].
9. Acknowledgements 9. Acknowledgements
 End of changes. 40 change blocks. 
89 lines changed or deleted 90 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/