draft-keyupate-i2rs-bgp-usecases-01.txt   draft-keyupate-i2rs-bgp-usecases-02.txt 
Network Working Group K. Patel I2RS K. Patel
Internet-Draft R. Fernando Internet-Draft R. Fernando
Intended status: Informational Cisco Systems Intended status: Informational Cisco Systems
Expires: August 16, 2014 H. Gredler Expires: December 6, 2014 H. Gredler
Juniper Networks Juniper Networks
S. Amante S. Amante
Level 3 Communications, Inc. Level 3 Communications, Inc.
R. White R. White
Ericsson Ericsson
S. Hares S. Hares
Hickory Hill Consulting Hickory Hill Consulting
February 12, 2014 June 4, 2014
Use Cases for an Interface to BGP Protocol Use Cases for an Interface to BGP Protocol
draft-keyupate-i2rs-bgp-usecases-01.txt draft-keyupate-i2rs-bgp-usecases-02.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, as
defined in [draft-ietf-i2rs-architecture], provides an alternate way defined in draft-ietf-i2rs-architecture, provides an alternate way to
to control and diagnose the operation of the BGP protocol. I2RS may control and diagnose the operation of the BGP protocol. I2RS may be
be used for the configuration, manipulation, analyzing or collecting used for the configuration, manipulation, analyzing or collecting the
the protocol data. This document describes set of use cases for protocol data. This document describes set of use cases for which
which I2RS can be used for BGP protocol. It is intended to provide a I2RS can be used for BGP protocol. It is intended to provide a base
base for the solution draft describing a set of interfaces to the BGP for the solution 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 August 16, 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 45 skipping to change at page 2, line 45
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. BGP Protocol Operation . . . . . . . . . . . . . . . . . . . 4 2. BGP Protocol Operation . . . . . . . . . . . . . . . . . . . 4
2.1. BGP Error Handling for Internal BGP Sessions . . . . . . 4 2.1. BGP Error Handling for Internal BGP Sessions . . . . . . 4
3. BGP Route Manipulation . . . . . . . . . . . . . . . . . . . 4 3. BGP Route Manipulation . . . . . . . . . . . . . . . . . . . 4
3.1. Customized Best Path Selection Criteria . . . . . . . . . 5 3.1. Customized Best Path Selection Criteria . . . . . . . . . 5
3.2. Flowspec Routes . . . . . . . . . . . . . . . . . . . . . 5 3.2. Flowspec Routes . . . . . . . . . . . . . . . . . . . . . 5
3.3. Route Filter Routes for Legacy Routers . . . . . . . . . 5 3.3. Route Filter Routes for Legacy Routers . . . . . . . . . 6
3.4. Optimized Exit Control . . . . . . . . . . . . . . . . . 6 3.4. Optimized Exit Control . . . . . . . . . . . . . . . . . 6
4. BGP Events . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. BGP Events . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Notification of Routing Events . . . . . . . . . . . . . 7 4.1. Notification of Routing Events . . . . . . . . . . . . . 7
4.2. Tracing Dropped BGP Routes . . . . . . . . . . . . . . . 8 4.2. Tracing Dropped BGP Routes . . . . . . . . . . . . . . . 8
4.3. BGP Protocol Statistics . . . . . . . . . . . . . . . . . 8 4.3. BGP Protocol Statistics . . . . . . . . . . . . . . . . . 8
5. Central membership computation for MPLS based VPNs . . . . . 9 5. Central membership computation for MPLS based VPNs . . . . . 9
6. Marking Overlapping Traffic Engineering Routes for Removal . 10 6. Marking Overlapping Traffic Engineering Routes for Removal . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. BGP Configuration . . . . . . . . . . . . . . . . . 13 Appendix A. BGP Configuration . . . . . . . . . . . . . . . . . 13
A.1. BGP Protocol Configuration . . . . . . . . . . . . . . . 14 A.1. BGP Protocol Configuration . . . . . . . . . . . . . . . 14
A.2. BGP Policy Configuration . . . . . . . . . . . . . . . . 14 A.2. BGP Policy Configuration . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
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.
The I2RS Framework document [I-D.ietf-i2rs-architecture] describes a The I2RS architecture document [I-D.ietf-i2rs-architecture] describes
mechanism to control network protocols like BGP using a set of a mechanism to control network protocols like BGP using a set of
programmatic interfaces. These programmatic interfaces allow one to programmatic interfaces. These programmatic interfaces allow one to
control the BGP protocol by analyzing its operational state and control the BGP protocol by analyzing its operational state and
routing protocol data, plus manipulating BGP's configuration to routing protocol data, plus manipulating BGP's configuration to
achieve various goals. The I2RS is not intended to replace any achieve various goals. The I2RS is not intended to replace any
existing configuration mechanisms, (i.e.: Command Line Interface or existing configuration mechanisms, (i.e.: Command Line Interface or
NETCONF). Instead, I2RS is intended to augment those existing NETCONF). Instead, I2RS is intended to augment those existing
mechanisms by defining a standardized set of programmatic interfaces mechanisms by defining a standardized set of programmatic interfaces
to enable easier configuration, interrogation and analysis of the BGP to enable easier configuration, interrogation and analysis of the BGP
protocol. protocol.
skipping to change at page 4, line 10 skipping to change at page 4, line 10
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 2. 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. The document Operational Requirements for malformed BGP attributes. Unfortunately, more fine-grained BGP error
Enhanced Error Handling Behaviour in BGP-4 handling solutions, which would result in little to no impact on the
[I-D.ietf-grow-ops-reqs-for-bgp-error-handling] outlines requirements operation of BGP protocol, remain elusive.
to try to minimize the scope of the impact attributed to such errors.
Unfortunately, more fine-grained BGP error handling solutions, which A planned Graceful must also carefully be handled to limit the amount
would result in little to no impact on the operation of BGP protocol, of traffic loss during a the shutdown. While operational
remain elusive. 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 2.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 controller(s). I2RS controller(s) may already have a toward an I2RS client(s). I2RS clients(s) may already have a real-
real-time view of BGP routes, and corresponding BGP attributes, or time view of BGP routes, and corresponding BGP attributes, or may
may dynamically interrogate BGP routers in the network to identify dynamically interrogate BGP routers in the network to identify the
the present propagation scope of the BGP route(s) that are affected. present propagation scope of the BGP route(s) that are affected.
Finally, the I2RS controller(s) could then signal back to BGP routers Finally, the I2RS client(s) could then signal back to BGP routers to
to apply a filter that would block propagation of the BGP attribute apply a filter that would block propagation of the BGP attribute or
or BGP route, as necessary, in order to temporarily aid in BGP route, as necessary, in order to temporarily aid in consistency
consistency of BGP routing information across the entire network of BGP routing information across the entire network until a
until a permanent fix can be developed and deployed within BGP permanent fix can be developed and deployed within BGP routers.
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. BGP Route Manipulation
skipping to change at page 5, line 18 skipping to change at page 5, line 24
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 controller 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 controller 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 3.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 controller to push With I2RS, it would be possible for an I2RS client to push traffic
traffic flow specifications to the BGP ASBRs and the PE routers. flow specifications to the BGP ASBRs and the PE routers. I2RS client
I2RS controller can act as a central entity tracking all the traffic can act as a central entity tracking all the traffic flow
flow specifications that are installed within an IBGP network. I2RS specifications that are installed within an IBGP network. I2RS
controller could also prioritize and control the announcement of client could also prioritize and control the announcement of traffic
traffic flow specifications according to various ASRBs and PE flow specifications according to various ASRBs and PE router's
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 3.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 within a VPN network. However,
it requires that all the BGP VPN routers are upgraded to support this it requires that all the BGP VPN routers are upgraded to support this
functionality. Otherwise, the graph information is incomplete when a functionality. Otherwise, the graph information is incomplete when a
VPN network consists of legacy routers that participates in VPN but VPN network consists of legacy routers that participates in VPN but
does not implement the BGP route filter address family. does not implement the BGP route filter address family.
With I2RS, it would be possible for an I2RS controller 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 controller can act as a central route filter address family. I2RS client can act as a central entity
entity tracking all the configured Route Filters for legacy routers tracking all the configured Route Filters for legacy routers and push
and push them on appropriate RRs who in turn would push it to ASBRs them on appropriate RRs who in turn would push it to ASBRs and PE
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 3.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 controller to manipulate With I2RS, it would be possible for an I2RS client to manipulate BGP
BGP routes and its parameters that influence BGP bestpath decisions. routes and its parameters that influence BGP bestpath decisions.
I2RS controller 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 controller into the network routes would then be injected by a I2RS client into the network so as
so as to get the load distribution for multiple network connections. to get the load distribution for multiple network connections.
4. BGP Events 4. 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 controller 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 4.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
skipping to change at page 7, line 27 skipping to change at page 7, line 32
routers in an AS. Then, the BGP monitoring system needs to look routers in an AS. Then, the BGP monitoring system needs to look
through all BGP UPDATE's in order to identify those events that are through all BGP UPDATE's in order to identify those events that are
of interest to it. Note, this doesn't account for the fact that of interest to it. Note, this doesn't account for the fact that
there are several applications that might be simultaneously there are several applications that might be simultaneously
interested in learning of events to a given IP prefix nor the fact interested in learning of events to a given IP prefix nor the fact
that some applications may want to dynamically insert or remove "IP that some applications may want to dynamically insert or remove "IP
prefixes of interest", depending on the needs of their constituent prefixes of interest", depending on the needs of their constituent
applications. applications.
With I2RS, it is conceivable that applications could tell an I2RS With I2RS, it is conceivable that applications could tell an I2RS
controller, through a North-Bound API, their "IP prefixes" (or, client, through a North-Bound API, their "IP prefixes" (or,
AS_PATH's, BGP communities, etc.) that are of interest. For example, AS_PATH's, BGP communities, etc.) that are of interest. For example,
a NOC application may be interested in changes to high visibility a NOC application may be interested in changes to high visibility
content or service-provider Web sites; alternatively, a security content or service-provider Web sites; alternatively, a security
application may be interested in events associated with a different application may be interested in events associated with a different
set of IP prefixes. The I2RS controller would then consolidate the set of IP prefixes. The I2RS client would then consolidate the list
list of IP prefixes, and associated characteristics, to be monitored of IP prefixes, and associated characteristics, to be monitored and
and program BGP routers in an AS to observe this subset of routes for program BGP routers in an AS to observe this subset of routes for
changes. Some examples of changes in routing state might include: changes. Some examples of changes in routing state might include:
o an IP prefix being announced or withdrawn o an IP prefix being announced or withdrawn
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 controller would then publish these events so applications
would immediately receive them and take the appropriate domain- The I2RS client would then publish these events so applications would
specific action necessary. immediately receive them and take the appropriate domain-specific
action necessary.
4.2. Tracing Dropped BGP Routes 4.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
skipping to change at page 8, line 30 skipping to change at page 8, line 34
lower LOCAL_PREF, longer AS_PATH length, etc.) was not chosen as the lower LOCAL_PREF, longer AS_PATH length, etc.) was not chosen as the
best path and, subsequently, this particular BGP route is not best path and, subsequently, this particular BGP route is not
forwarded on to other internal BGP speakers in the AS. In both forwarded on to other internal BGP speakers in the AS. In both
instances, the BGP route is only visible within the ASBR on which instances, the BGP route is only visible within the ASBR on which
that BGP route was first learned. Needless to say, in large Service that BGP route was first learned. Needless to say, in large Service
Provider networks with a numerous interconnects to a single customer Provider networks with a numerous interconnects to a single customer
it can be very time-consuming to discover where such a BGP route is it can be very time-consuming to discover where such a BGP route is
learned before ultimately determining why the route was blocked or learned before ultimately determining why the route was blocked or
not preferred. not preferred.
With I2RS, it would be possible for an I2RS controller to rapidly With I2RS, it would be possible for an I2RS client to rapidly gather
gather information from across a large set of BGP routers in the information from across a large set of BGP routers in the network to
network to determine at what ASBR's the BGP route is being learned. determine at what ASBR's the BGP route is being learned. Next, the
Next, the I2RS controller could interrogate those routers BGP I2RS client could interrogate those routers BGP policies to determine
policies to determine the root cause of why the route was either not the root cause of why the route was either not learned or not
learned or not preferred in BGP. Finally, if necessary, the I2RS preferred in BGP. Finally, if necessary, the I2RS client(s) could
controller(s) could amend BGP policies and push them out to BGP amend BGP policies and push them out to BGP routers to permit the BGP
routers to permit the BGP route or make it a preferred route route or make it a preferred route according to the BGP path
according to the BGP path selection algorithm. selection algorithm.
4.3. BGP Protocol Statistics 4.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
skipping to change at page 9, line 12 skipping to change at page 9, line 16
warning message is triggered and/or the eBGP session is torn down warning message is triggered and/or the eBGP session is torn down
completely. This configuration capability is often referred to as a completely. This configuration capability is often referred to as a
"max-prefix limit". This command must be routinely audited and, if "max-prefix limit". This command must be routinely audited and, if
necessary, adjusted in order to not trigger a false warning or necessary, adjusted in order to not trigger a false warning or
teardown due to the natural organic growth in BGP routes learned from teardown due to the natural organic growth in BGP routes learned from
a given BGP neighbor. a given BGP neighbor.
I2RS agents could provide an invaluable capability to help audit and I2RS agents could provide an invaluable capability to help audit and
re-program the "max-prefix limit" on a periodic basis, which is re-program the "max-prefix limit" on a periodic basis, which is
generally once per day. Specifically, the first task would be for an generally once per day. Specifically, the first task would be for an
I2RS controller to validate that there is a "max-prefix limit" I2RS client to validate that there is a "max-prefix limit" applied to
applied to every eBGP session. (If there is not, that should either every eBGP session. (If there is not, that should either trigger a
trigger a red alarm to the NOC to manually fix this condition or for red alarm to the NOC to manually fix this condition or for the I2RS
the I2RS controller to automatically apply a "max-prefix limit" that client to automatically apply a "max-prefix limit" that would
would alleviate this hazardous condition). Assuming there is a "max- alleviate this hazardous condition). Assuming there is a "max-prefix
prefix limit" already in place, the I2RS controller would limit" already in place, the I2RS client would simultaneously
simultaneously retrieve, from each BGP router, the current number of retrieve, from each BGP router, the current number of BGP routes
BGP routes learned through a BGP session and value used for the "max- learned through a BGP session and value used for the "max-prefix
prefix limit" on that same BGP session. These two values could then limit" on that same BGP session. These two values could then be
be handed off to an application that determines if adjustments in the handed off to an application that determines if adjustments in the
"max-prefix limit" value are required for each BGP session. The "max-prefix limit" value are required for each BGP session. The
application would then notify the I2RS controller of the subset of application would then notify the I2RS client of the subset of eBGP
eBGP sessions and their associated change in "max-prefix limit" sessions and their associated change in "max-prefix limit" value,
value, whereby the I2RS controller would then adjust the BGP protocol whereby the I2RS client would then adjust the BGP protocol
configuration on each requisite BGP router in the network. Finally, configuration on each requisite BGP router in the network. Finally,
it should be noted that the above is just one method whereby "max- it should be noted that the above is just one method whereby "max-
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
skipping to change at page 11, line 44 skipping to change at page 11, line 50
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 9. References
9.1. Normative References 9.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-00 (work in System", draft-ietf-i2rs-architecture-03 (work in
progress), August 2013. 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.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999. June 1999.
skipping to change at page 12, line 27 skipping to change at page 12, line 33
[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 9.2. Informative References
[I-D.ietf-grow-ops-reqs-for-bgp-error-handling] [I-D.ietf-grow-bgp-gshut]
Shakir, R., "Operational Requirements for Enhanced Error Francois, P., Decraene, B., Pelsser, C., Patel, K., and C.
Handling Behaviour in BGP-4", draft-ietf-grow-ops-reqs- Filsfils, "Graceful BGP session shutdown", draft-ietf-
for-bgp-error-handling-05 (work in progress), July 2012. grow-bgp-gshut-05 (work in progress), January 2014.
[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-00 (work in
progress), August 2013.
[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
in progress), September 2012. in progress), September 2012.
[I-D.white-grow-overlapping-routes] [I-D.white-grow-overlapping-routes]
White, R., Retana, A., and S. Hares, "Filtering of White, R., Retana, A., and S. Hares, "Filtering of
Overlapping Routes", draft-white-grow-overlapping- Overlapping Routes", draft-white-grow-overlapping-
skipping to change at page 13, line 18 skipping to change at page 13, line 18
[RFC5156] Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156, [RFC5156] Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156,
April 2008. April 2008.
[RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,
and D. McPherson, "Dissemination of Flow Specification and D. McPherson, "Dissemination of Flow Specification
Rules", RFC 5575, August 2009. Rules", RFC 5575, August 2009.
[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
RFC 5735, January 2010. RFC 5735, January 2010.
[RFC6198] Decraene, B., Francois, P., Pelsser, C., Ahmad, Z.,
Elizondo Armengol, A., and T. Takeda, "Requirements for
the Graceful Shutdown of BGP Sessions", RFC 6198, April
2011.
Appendix A. BGP Configuration Appendix A. BGP Configuration
The configuration of BGP is arduous to establish and maintain, The configuration of BGP is arduous to establish and maintain,
particularly on networks whose services have a requirement for particularly on networks whose services have a requirement for
complex routing policies. This need is magnified by the need to complex routing policies. This need is magnified by the need to
routinely perform changes to large numbers of BGP routers to, for routinely perform changes to large numbers of BGP routers to, for
example: add or remove customer's BGP sessions, announce or withdraw example: add or remove customer's BGP sessions, announce or withdraw
(customer) IP prefixes in BGP, modify BGP policies to effect changes (customer) IP prefixes in BGP, modify BGP policies to effect changes
in Traffic Engineering, audit BGP routers to ensure they have in Traffic Engineering, audit BGP routers to ensure they have
consistent and appropriate BGP policies, and others. consistent and appropriate BGP policies, and others.
skipping to change at page 14, line 34 skipping to change at page 14, line 38
configuration required to setup the control plane for Customer VPNs. configuration required to setup the control plane for Customer VPNs.
The configuration involves creating a Virtual Routing and Forwarding The configuration involves creating a Virtual Routing and Forwarding
instance (VRF), a Route Distinguisher (RD) that ensures each customer instance (VRF), a Route Distinguisher (RD) that ensures each customer
prefixes remains unique across VPNs, and Route Targets (RT) that help prefixes remains unique across VPNs, and Route Targets (RT) that help
ensure that the Customer prefixes are segregated appropriately so ensure that the Customer prefixes are segregated appropriately so
that they do not cross the VPN boundaries. I2RS would allow a that they do not cross the VPN boundaries. I2RS would allow a
network operator to push such configuration from a central location network operator to push such configuration from a central location
where a global VPN provisioning information could be stored. This where a global VPN provisioning information could be stored. This
helps avoid manual configuration of a VPN on multiple routers. helps avoid manual configuration of a VPN on multiple routers.
Instead the configuration is controlled and pushed though a central Instead the configuration is controlled and pushed though a central
I2RS controller using a programmatic set of APIs on targeted set of I2RS client using a programmatic set of APIs on targeted set of BGP
BGP speakers. speakers.
Use of I2RS agents to announce protocol configuration information Use of I2RS agents to announce protocol configuration information
would simplify and automate configuration of BGP protocol in IBGP would simplify and automate configuration of BGP protocol in IBGP
deployments where the protocol based policies are seldom used. To deployments where the protocol based policies are seldom used. To
facilitate such a centralized configuration model, BGP speakers could facilitate such a centralized configuration model, BGP speakers could
be extended to use programmatic APIs to announce their feature be extended to use programmatic APIs to announce their feature
capabilities as part of protocol initialization to the centralize capabilities as part of protocol initialization to the centralize
I2RS agents. This would assist I2RS agents to auto-discover BGP I2RS agents. This would assist I2RS agents to auto-discover BGP
protocol capabilities of various BGP speakers in a given network. protocol capabilities of various BGP speakers in a given network.
I2RS agents in turn would use the information towards enabling/ I2RS agents in turn would use the information towards enabling/
skipping to change at page 16, line 12 skipping to change at page 16, line 16
[I-D.mcpherson-irr-routing-policy-considerations] document for a more [I-D.mcpherson-irr-routing-policy-considerations] document for a more
thorough discussion of the history and present state of the IRR's. thorough discussion of the history and present state of the IRR's.
Currently, RPSL schemas are exchanged between non-routing systems Currently, RPSL schemas are exchanged between non-routing systems
(servers) used within the IRR system. In addition, open-source and (servers) used within the IRR system. In addition, open-source and
proprietary applications create or modify RPSL schemas, as necessary, proprietary applications create or modify RPSL schemas, as necessary,
to signal the announcement (or, withdrawal) of an IP prefix from an to signal the announcement (or, withdrawal) of an IP prefix from an
ASN or the creation (or, teardown) of a neighbor relationship between ASN or the creation (or, teardown) of a neighbor relationship between
two adjacent ASN's. Most importantly, these RPSL schemas are two adjacent ASN's. Most importantly, these RPSL schemas are
consumed by similar applications to automatically build routing consumed by similar applications to automatically build routing
policies, (i.e.: lists of IP prefixes, corresponding Origin ASN's and policies, (i.e.: lists of IP prefixes, corresponding Origin ASN's
/or AS_PATH's), that then get translated to device-specific syntax and/or AS_PATH's), that then get translated to device-specific syntax
(i.e.: CLI) before being pushed into individual BGP routers to effect (i.e.: CLI) before being pushed into individual BGP routers to effect
routing policy on the network. It is common for Internet Service routing policy on the network. It is common for Internet Service
Providers to perform updates to these routing policies across their Providers to perform updates to these routing policies across their
entire network on a daily basis. entire network on a daily basis.
With I2RS it would be desirable to change the last step in the above With I2RS it would be desirable to change the last step in the above
process so that BGP policies derived from RPSL schemas, and other process so that BGP policies derived from RPSL schemas, and other
information sources, are translated into standards-based schemas that information sources, are translated into standards-based schemas that
are then pushed, or pulled, into individual BGP routers. More are then pushed, or pulled, into individual BGP routers. More
generally, I2RS agents could use API's to gather information required generally, I2RS agents could use API's to gather information required
 End of changes. 31 change blocks. 
98 lines changed or deleted 104 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/