draft-keyupate-i2rs-bgp-usecases-02.txt   draft-keyupate-i2rs-bgp-usecases-03.txt 
I2RS 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 6, 2014 H. Gredler Expires: December 19, 2014 H. Gredler
Juniper Networks Juniper Networks
S. Amante S. Amante
Level 3 Communications, Inc. Apple
R. White R. White
Ericsson Ericsson
S. Hares S. Hares
Hickory Hill Consulting Huawei
June 4, 2014 June 17, 2014
Use Cases for an Interface to BGP Protocol Use Cases for an Interface to BGP Protocol
draft-keyupate-i2rs-bgp-usecases-02.txt draft-keyupate-i2rs-bgp-usecases-03.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.
Interface to the Routing System's (I2RS) Programmatic interfaces, as Interface to the Routing System's (I2RS) Programmatic interfaces
defined in draft-ietf-i2rs-architecture, provides an alternate way to provides an alternate way to control and diagnose the operation of
control and diagnose the operation of the BGP protocol. I2RS may be the BGP protocol. I2RS may be used for the configuration,
used for the configuration, manipulation, analyzing or collecting the manipulation, analyzing or collecting the protocol data. This
protocol data. This document describes set of use cases for which document describes set of use cases for which I2RS can be used for
I2RS can be used for BGP protocol. It is intended to provide a base BGP protocol. It is intended to provide a base for the solution
for the solution draft describing a set of interfaces to the BGP draft describing a set of interfaces to the BGP protocol.
protocol.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 December 6, 2014.
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 2, line 39 skipping to change at page 2, line 36
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. BGP Protocol Operation . . . . . . . . . . . . . . . . . . . 4 1.2. Requirements for I2S . . . . . . . . . . . . . . . . . . 4
2.1. BGP Error Handling for Internal BGP Sessions . . . . . . 4 2. Summary of Requirements for I2RS . . . . . . . . . . . . . . 4
3. BGP Route Manipulation . . . . . . . . . . . . . . . . . . . 4 3. BGP Protocol Operation . . . . . . . . . . . . . . . . . . . 6
3.1. Customized Best Path Selection Criteria . . . . . . . . . 5 3.1. BGP Error Handling for Internal BGP Sessions . . . . . . 6
3.2. Flowspec Routes . . . . . . . . . . . . . . . . . . . . . 5 3.2. Summary of I2RS Capabilities and Interactions . . . . . . 7
3.3. Route Filter Routes for Legacy Routers . . . . . . . . . 6 4. BGP Route Manipulation . . . . . . . . . . . . . . . . . . . 7
3.4. Optimized Exit Control . . . . . . . . . . . . . . . . . 6 4.1. Customized Best Path Selection Criteria . . . . . . . . . 7
4. BGP Events . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Flowspec Routes . . . . . . . . . . . . . . . . . . . . . 8
4.1. Notification of Routing Events . . . . . . . . . . . . . 7 4.3. Route Filter Routes for Legacy Routers . . . . . . . . . 8
4.2. Tracing Dropped BGP Routes . . . . . . . . . . . . . . . 8 4.4. Optimized Exit Control . . . . . . . . . . . . . . . . . 9
4.3. BGP Protocol Statistics . . . . . . . . . . . . . . . . . 8 4.5. Summary of I2RS Capabilities and Interactions . . . . . . 9
5. Central membership computation for MPLS based VPNs . . . . . 9 5. BGP Events . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Marking Overlapping Traffic Engineering Routes for Removal . 11 5.1. Notification of Routing Events . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5.2. Tracing Dropped BGP Routes . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 5.3. BGP Protocol Statistics . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.4. Summary of I2RS Capabilities and Interactions for Event
9.1. Normative References . . . . . . . . . . . . . . . . . . 11 statistics . . . . . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . 12 6. Central membership computation for MPLS based VPNs . . . . . 14
Appendix A. BGP Configuration . . . . . . . . . . . . . . . . . 13 7. Marking Overlapping Traffic Engineering Routes for Removal . 15
A.1. BGP Protocol Configuration . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
A.2. BGP Policy Configuration . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 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 1. Introduction
Typically, a network routing protocol like BGP is configured and Typically, a network routing protocol like BGP is configured and
results of its operation are analyzed through some form of Command results of its operation are analyzed through some form of Command
Line Interface (CLI) or NETCONF. These interactions to control BGP Line Interface (CLI) or NETCONF. These interactions to control BGP
and diagnose its operation encompass: configuration of protocol and diagnose its operation encompass: configuration of protocol
parameters, display of protocol data, setting of certain protocol parameters, display of protocol data, setting of certain protocol
state and debugging of the protocol. state and debugging of the protocol.
skipping to change at page 4, line 5 skipping to change at page 4, line 11
fit within the overall I2RS architecture. It is intended to provide fit within the overall I2RS architecture. It is intended to provide
a basis for the solutions draft describing the set of Interfaces to a basis for the solutions draft describing the set of Interfaces to
the BGP protocol. the BGP protocol.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. 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 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.
A planned Graceful must also carefully be handled to limit the amount A planned Graceful must also carefully be handled to limit the amount
of traffic loss during a the shutdown. While operational of traffic loss during a the shutdown. While operational
requirements for the BGP mechanism for graceful shutdown of a (set requirements for the BGP mechanism for graceful shutdown of a (set
of) BGP sessions is describe din [RFC6198], and the operational of) BGP sessions is describe din [RFC6198], and the operational
procedures are described in [I-D.ietf-grow-bgp-gshut], additional procedures are described in [I-D.ietf-grow-bgp-gshut], additional
fine-grained BGP error handling could improve graceful shutdown of fine-grained BGP error handling could improve graceful shutdown of
BGP sessions. BGP sessions.
This section discussed how I2RS information could improve both the This section discussed how I2RS information could improve both the
destructive teardown and the graceful teardown of sessions. 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 It is possible that I2RS could enable enhanced error handling
techniques for Internal BGP sessions. At a minimum, I2RS-capable BGP techniques for Internal BGP sessions. At a minimum, I2RS-capable BGP
routers could signal an event such as "Malformed Attribute Received" routers could signal an event such as "Malformed Attribute Received"
toward an I2RS client(s). I2RS clients(s) may already have a real- via an I2RS agent toward an I2RS client(s). I2RS client(s) may
time view of BGP routes, and corresponding BGP attributes, or may already have a real-time view of BGP routes, and corresponding BGP
dynamically interrogate BGP routers in the network to identify the attributes, or may dynamically interrogate BGP routers in the network
present propagation scope of the BGP route(s) that are affected. to identify the present propagation scope of the BGP route(s) that
Finally, the I2RS client(s) could then signal back to BGP routers to are affected. Finally, the I2RS client(s) could then signal back to
apply a filter that would block propagation of the BGP attribute or I2RS agents on BGP routers to apply a filter that would block
BGP route, as necessary, in order to temporarily aid in consistency propagation of the BGP attribute or BGP route, as necessary, in order
of BGP routing information across the entire network until a to temporarily aid in consistency of BGP routing information across
permanent fix can be developed and deployed within BGP routers. 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 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. 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 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
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 Extended Communities [RFC4360] to filter unwanted BGP routes. BGP
Flowspec address family [RFC5575] is used to install Flow based Flowspec address family [RFC5575] is used to install Flow based
filters to filter unwanted data traffic. The following sub-sections filters to filter unwanted data traffic. The following sub-sections
describe the use of IRS towards BGP Route Manipulation for different describe the use of IRS towards BGP Route Manipulation for different
BGP address families. 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 The BGP customized Bestpath facilitates custom bestpath computations
within a BGP speaking network. It is usually used within an IBGP within a BGP speaking network. It is usually used within an IBGP
network. Customized bestpaths use special extended communities known network. Customized bestpaths use special extended communities known
as cost communities. Cost communities carry enough information; as cost communities. Cost communities carry enough information;
Point of Insertion (POI) and the cost value to signal where in BGP Point of Insertion (POI) and the cost value to signal where in BGP
bestpath the customize checks need to be done. Both, the traffic bestpath the customize checks need to be done. Both, the traffic
engineering as well as backdoor (SHAM) links use customized bestpath engineering as well as backdoor (SHAM) links use customized bestpath
computation. computation.
With I2RS, it would be possible for an I2RS client to push routes With I2RS, it would be possible for an I2RS client to push routes
with custom cost communities on the BGP routers for Traffic with custom cost communities on the BGP routers for Traffic
Engineering purpose. I2RS client now can act as a central entity Engineering purpose. I2RS client now can act as a central entity
keeping track of all Traffic engineering data that get applied to BGP keeping track of all Traffic engineering data that get applied to BGP
routes within an IBGP network. routes within an IBGP network.
3.2. Flowspec Routes 4.2. Flowspec Routes
The BGP flowspec address family is used to disseminate the traffic The BGP flowspec address family is used to disseminate the traffic
flow specification to the BGP Autonomous System Border Routers flow specification to the BGP Autonomous System Border Routers
(ASBRs) and Provider Edge (PE) routers. Both, the BGP ASBRs and the (ASBRs) and Provider Edge (PE) routers. Both, the BGP ASBRs and the
PEs would translate the received BGP traffic flow specification into PEs would translate the received BGP traffic flow specification into
an Access Control List (ACL) and install it in router's forwarding an Access Control List (ACL) and install it in router's forwarding
path. Using such ACLs routers can now classify, shape, rate limit, path. Using such ACLs routers can now classify, shape, rate limit,
filter, or redirect traffic flows. filter, or redirect traffic flows.
With I2RS, it would be possible for an I2RS client to push traffic 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 flow specifications to the BGP ASBRs and the PE routers. I2RS client
can act as a central entity tracking all the traffic flow can act as a central entity tracking all the traffic flow
specifications that are installed within an IBGP network. I2RS specifications that are installed within an IBGP network. I2RS
client could also prioritize and control the announcement of traffic client could also prioritize and control the announcement of traffic
flow specifications according to various ASRBs and PE router's flow specifications according to various ASRBs and PE router's
capacity. BGP ASBRs and PE routers MAY forward traffic flow capacity. BGP ASBRs and PE routers MAY forward traffic flow
specifications received from EBGP speakers to I2RS Agents. This specifications received from EBGP speakers to I2RS Agents. This
would allow I2RS agents to centrally manage and track any externally would allow I2RS agents to centrally manage and track any externally
received traffic flow specifications. 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 The BGP Route Filter address family is used to disseminate the Route
Target filter information between VPN BGP speakers. This information Target filter information between VPN BGP speakers. This information
is then used to build a route distribution graph that helps in is then used to build a route distribution graph that helps in
limiting the propagation of VPN NLRI within a VPN network. However, limiting the propagation of VPN NLRI (network Layer Reachabilty
it requires that all the BGP VPN routers are upgraded to support this Information) within a VPN network. However, it requires that all the
functionality. Otherwise, the graph information is incomplete when a BGP VPN routers are upgraded to support this functionality.
VPN network consists of legacy routers that participates in VPN but Otherwise, the graph information is incomplete when a VPN network
does not implement the BGP route filter address family. 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 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 filter information to BGP RR routers on behalf of all legacy routers
that participates in VPN but does not support or implement the BGP that participates in VPN but does not support or implement the BGP
route filter address family. I2RS client can act as a central entity route filter address family. I2RS client can act as a central entity
tracking all the configured Route Filters for legacy routers and push 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 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 routers. In this way, I2RS agents help build an optimal route
distribution graph that would assist in filtering of VPN NLRIs in a distribution graph that would assist in filtering of VPN NLRIs in a
VPN network. VPN network.
3.4. Optimized Exit Control 4.4. Optimized Exit Control
Optimized Exit Control is used to provide route optimization and load Optimized Exit Control is used to provide route optimization and load
distribution for multiple network connections between networks. distribution for multiple network connections between networks.
Network operators can monitor IP traffic flows and then could define Network operators can monitor IP traffic flows and then could define
policies and rules based on traffic class performance, link bandwidth policies and rules based on traffic class performance, link bandwidth
monetary costs, link load distribution, traffic types, link failures, monetary costs, link load distribution, traffic types, link failures,
etc. etc.
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. 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 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
scalability of software and hardware that BGP utilizes. scalability of software and hardware that BGP utilizes.
I2RS could provide a publish-subscribe capability to applications to: I2RS could provide a publish-subscribe capability to applications to:
o request monitoring of BGP routes and related events; and, o request monitoring of BGP routes and related events; and,
o subscribe to the I2RS client to receive events related to BGP o subscribe to the I2RS client to receive events related to BGP
routes or other protocol-related events of interest. 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 There are certain IP prefixes, for example those that are arbitrarily
classified by a given network operator as "high visibility" by its classified by a given network operator as "high visibility" by its
end-users, for which immediate notification of changes in their state end-users, for which immediate notification of changes in their state
are extremely useful to know about. Upon notification of such are extremely useful to know about. Upon notification of such
events, a Network Operations Center (NOC) could respond to customer events, a Network Operations Center (NOC) could respond to customer
inquiries in a more timely fashion; alternatively, the NOC may decide inquiries in a more timely fashion; alternatively, the NOC may decide
to perform Traffic Engineering to restore service, etc. to perform Traffic Engineering to restore service, etc.
Currently, the only way to learn of such events is for a BGP Currently, the only way to learn of such events is for a BGP
skipping to change at page 8, line 4 skipping to change at page 11, line 30
o an IP prefix being suppressed, due to route flap dampening o an IP prefix being suppressed, due to route flap dampening
o an alternative best-path being chosen for a given IP prefix 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 When the requisite events for a BGP Route are observed by a BGP
router, it would notify I2RS agents. router, it would notify I2RS agents.
The I2RS agents would have a publish/subscribe mechanism whereby The I2RS agents would have a publish/subscribe mechanism whereby
various sets of applications may subscribe to events of interest. various sets of applications may subscribe to events of interest.
The I2RS client would then publish these events so applications would The I2RS client would then publish these events so applications would
immediately receive them and take the appropriate domain-specific immediately receive them and take the appropriate domain-specific
action necessary. 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 It is extremely useful to operators to be able to rapidly identify
instances where a BGP route is not being propagated within an instances where a BGP route is not being propagated within an
Autonomous System. At a minimum, this could result in sub-optimal Autonomous System. At a minimum, this could result in sub-optimal
performance when attempting to reach such destinations. performance when attempting to reach such destinations.
There are two instances when this scenario will occur. First, when a There are two instances when this scenario will occur. First, when a
Service Provider is using "Soft Reconfiguration Inbound", it allows Service Provider is using "Soft Reconfiguration Inbound", it allows
their ASBR routers to receive a copy of a BGP route, but show that 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 route was not permitted into the Adj-RIB-In most likely as a result
skipping to change at page 8, line 44 skipping to change at page 12, line 21
With I2RS, it would be possible for an I2RS client to rapidly gather 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 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 determine at what ASBR's the BGP route is being learned. Next, the
I2RS client could interrogate those routers BGP policies to determine I2RS client could interrogate those routers BGP policies to determine
the root cause of why the route was either not learned or not the root cause of why the route was either not learned or not
preferred in BGP. Finally, if necessary, the I2RS client(s) could 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 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 route or make it a preferred route according to the BGP path
selection algorithm. selection algorithm.
4.3. BGP Protocol Statistics 5.3. BGP Protocol Statistics
There are a variety of statistics related to the operation of BGP There are a variety of statistics related to the operation of BGP
that are invaluable to network operators. These statistics generally that are invaluable to network operators. These statistics generally
help operators, and developers, understand the present state and help operators, and developers, understand the present state and
future scalability of BGP. future scalability of BGP.
One statistic that is invaluable to operators is the current number One statistic that is invaluable to operators is the current number
of BGP routes learned through an eBGP session. Operators then apply of BGP routes learned through an eBGP session. Operators then apply
a command against each eBGP session to limit the maximum number of a command against each eBGP session to limit the maximum number of
BGP routes that may be learned through that eBGP session before a BGP routes that may be learned through that eBGP session before a
skipping to change at page 9, line 42 skipping to change at page 13, line 20
prefix limit" values are adjusted. It's similarly possible that the prefix limit" values are adjusted. It's similarly possible that the
BGP routers may, through the I2RS, pull the "max-prefix limit" values 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 for each eBGP neighbor they have on-board on a periodic basis and
validate their accuracy. validate their accuracy.
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. 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 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,
both memory and compute on each of the PE devices. both memory and compute on each of the PE devices.
An alternative approach is to monitor routing updates on every PE An alternative approach is to monitor routing updates on every PE
from the attached CEs and then compute membership in a central from the attached CEs and then compute membership in a central
manner. Once computed the routes are pushed to the VPN RIBs of the manner. Once computed the routes are pushed to the VPN RIBs of the
skipping to change at page 10, line 43 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 The ability to read the loc-RIB-In BGP table that gets all the o REQ15:The I2RS client via the I2RS agent MUST have the ability to
routes that the CE has provided to a PE router. 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 o REQ16:The I2RS client via the I2RS agent MUST have the ability to
of the PE devices. This must include the ability to supply the install destination based routes in the local RIB of the PE
destination prefix (NLRI), a table identifier, a route preference, devices. This must include the ability to supply the destination
a route metric, a next-hop tunnel through which traffic would be prefix (NLRI), a table identifier, a route preference, a route
carried 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 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 The ability to read the loc-RIB-in BGP table to discover o REQ17: The I2RS client via the I2RS agent SHOULD have the the
overlapping routes, and determine which may be safely marked for ability to read the loc-RIB-in BGP table to discover overlapping
removal. routes, and determine which may be safely marked for removal.
o The ability to modify filtering rules and initiate a re- o REQ18: The I2RS client via the I2RS Agent SHOULD have the ability
computation of the local BGP table through those policies to cause to modify filtering rules and initiate a re-computation of the
specific routes to be marked for removal at the outbound eBGP local BGP table through those policies to cause specific routes to
edge. 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 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].
8. Acknowledgements 9. Acknowledgements
The authors would like to thank Ed Crabbe, Joel Halpern, Wes George, The authors would like to thank Ed Crabbe, Joel Halpern, Wes George,
Carlos Pignataro, Jon Mitchell and Bill Atwood for their comments and Carlos Pignataro, Jon Mitchell and Bill Atwood for their comments and
suggestions. suggestions.
9. References 10. References
9.1. Normative References 10.1. Normative References
[I-D.ietf-i2rs-architecture] [I-D.ietf-i2rs-architecture]
Atlas, A., Halpern, J., Hares, S., Ward, D., and T. Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
Nadeau, "An Architecture for the Interface to the Routing Nadeau, "An Architecture for the Interface to the Routing
System", draft-ietf-i2rs-architecture-03 (work in System", draft-ietf-i2rs-architecture-03 (work in
progress), May 2014. progress), May 2014.
[RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP
Communities Attribute", RFC 1997, August 1996. Communities Attribute", RFC 1997, August 1996.
skipping to change at page 12, line 31 skipping to change at page 16, line 41
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, February 2006. Communities Attribute", RFC 4360, February 2006.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, January "Multiprotocol Extensions for BGP-4", RFC 4760, January
2007. 2007.
9.2. Informative References 10.2. Informative References
[I-D.ietf-grow-bgp-gshut] [I-D.ietf-grow-bgp-gshut]
Francois, P., Decraene, B., Pelsser, C., Patel, K., and C. Francois, P., Decraene, B., Pelsser, C., Patel, K., and C.
Filsfils, "Graceful BGP session shutdown", draft-ietf- Filsfils, "Graceful BGP session shutdown", draft-ietf-
grow-bgp-gshut-05 (work in progress), January 2014. grow-bgp-gshut-05 (work in progress), January 2014.
[I-D.mcpherson-irr-routing-policy-considerations] [I-D.mcpherson-irr-routing-policy-considerations]
McPherson, D., Amante, S., Osterweil, E., and L. Blunk, McPherson, D., Amante, S., Osterweil, E., and L. Blunk,
"IRR & Routing Policy Configuration Considerations", "IRR & Routing Policy Configuration Considerations",
draft-mcpherson-irr-routing-policy-considerations-01 (work draft-mcpherson-irr-routing-policy-considerations-01 (work
skipping to change at page 17, line 21 skipping to change at page 21, line 29
Hannes Gredler Hannes Gredler
Juniper Networks Juniper Networks
1194 N. Mathilda Ave 1194 N. Mathilda Ave
Sunnyvale, CA 94089 Sunnyvale, CA 94089
USA USA
Email: hannes@juniper.net Email: hannes@juniper.net
Shane Amante Shane Amante
Level 3 Communications, Inc. Apple
1025 Eldorado Blvd
Broomfield, CO 80021
USA
Email: shane@level3.net
Russ White Russ White
Ericsson Ericsson
Email: russw@riw.us Email: russw@riw.us
Susan Hares Susan Hares
Hickory Hill Consulting Huawei
Email: shares@ndzh.com Email: shares@ndzh.com
 End of changes. 37 change blocks. 
95 lines changed or deleted 290 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/