One document matched: draft-keyupate-i2rs-bgp-usecases-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
    which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
    There has to be one entity for each item to be referenced.
    An alternate method (rfc include) is described in the references. -->

<!ENTITY RFC2119 SYSTEM
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2622 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2622.xml">
<!ENTITY RFC2629 SYSTEM
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC1997 SYSTEM
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1997.xml">
<!ENTITY RFC3552 SYSTEM
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC4271 SYSTEM
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4271.xml">
<!ENTITY RFC4360 SYSTEM
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4360.xml">
<!ENTITY RFC4760 SYSTEM
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4760.xml">
<!ENTITY RFC5065 SYSTEM
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5065.xml">
<!ENTITY RFC3392 SYSTEM
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3392.xml">
<!ENTITY RFC2858 SYSTEM
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2858.xml">
<!ENTITY RFC5735 SYSTEM
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5735.xml">
<!ENTITY RFC5156 SYSTEM
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5156.xml">
<!ENTITY RFC5575 SYSTEM
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5575.xml">
<!ENTITY I-D.ward-i2rs-framework SYSTEM
  "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ward-i2rs-framework-00.xml">
<!ENTITY I-D.mcpherson-irr-routing-policy-considerations SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-mcpherson-irr-routing-policy-considerations-01.xml">
<!ENTITY I-D.ietf-grow-ops-reqs-for-bgp-error-handling SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.xml">
]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
    please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that
    most I-Ds might want to use.
    (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
    (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-keyupate-i2rs-bgp-usecases-00.txt"
ipr="pre5378Trust200902">
  <!-- category values: std, bcp, info, exp, and historic
    ipr values: full3667, noModification3667, noDerivatives3667
    you can add the attributes updates="NNNN" and obsoletes="NNNN"
    they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>

    <title abbrev="Use Cases for an Interface to BGP">
    Use Cases for an Interface to BGP Protocol</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

    <author fullname="Keyur Patel" initials="K.P."
            surname="Patel">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street>170 W. Tasman Drive</street>

          <!-- Reorder these if your country does things differently -->

          <city>San Jose</city>

          <region>CA</region>

          <code>95134</code>

          <country>USA</country>
        </postal>

        <email>keyupate@cisco.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <author fullname="Rex Fernando" initials="R"
            surname="Fernando">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street>170 W. Tasman Drive</street>

          <!-- Reorder these if your country does things differently -->

          <city>San Jose</city>

          <region>CA</region>

          <code>95134</code>

          <country>USA</country>
        </postal>

        <email>rex@cisco.com</email>

        <!-- uri and facsimile elements may also be added -->
        </address>
    </author>

    <author fullname="Hannes Gredler" initials="H"
            surname="Gredler">
      <organization>Juniper Networks</organization>

      <address>
        <postal>
          <street>1194 N. Mathilda Ave</street>

          <!-- Reorder these if your country does things differently -->

          <city>Sunnyvale</city>

          <region>CA</region>

          <code>94089</code>

          <country>USA</country>
        </postal>

        <email>hannes@juniper.net</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <author fullname="Shane Amante" initials="S"
          surname="Amante">
    <organization>Level 3 Communications, Inc.</organization>
    
    <address>
      <postal>
        <street>1025 Eldorado Blvd</street>
    
        <!-- Reorder these if your country does things differently -->
    
        <city>Broomfield</city>
    
        <region>CO</region>
    
        <code>80021</code>
    
        <country>USA</country>
      </postal>
    
      <email>shane@level3.net</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <date year="2013" />

    <!-- Meta-data Declarations -->

    <area>General</area>

    <workgroup>Network Working Group</workgroup>

    <keyword>RTGWG</keyword>

    <!-- Keywords will be incorporated into HTML output
        files in a meta tag but they have no effect on text or nroff
        output. If you submit your draft to the RFC Editor, the
        keywords will be used for the search engine. -->

<abstract>
<t>
A network routing protocol like BGP is typically configured and results of its 
operation are analyzed through some form of Command Line Interface (CLI) or
NETCONF.  These interactions to control BGP and diagnose its operation
encompass: configuration of protocol parameters, display of protocol
data, setting of certain protocol state and debugging of the protocol.
</t>
<t>
Interface to the Routing System's (I2RS) Programmatic interfaces, as 
defined in [I-D.ward-i2rs-framework], provides an alternate way to 
control the configuration and diagnose the operation of the BGP protocol.  I2RS
may be used for the configuration, manipulation, polling or analyzing protocol 
data. This document describes set of use cases for which I2RS can be used for 
BGP protocol. It is intended to provide a base for the solution draft 
describing a set of interfaces to the BGP protocol.
</t>
</abstract>

  </front>

  <middle>

<section anchor="introduction" title="Introduction">
<t>
Typically, a network routing protocol like BGP is configured and results of its
operation are analyzed through some form of Command Line Interface (CLI) or
NETCONF.  These interactions to control BGP and diagnose its operation
encompass: configuration of protocol parameters, display of protocol
data, setting of certain protocol state and debugging of the protocol.
</t>

<t>
The I2RS Framework document <xref target="I-D.ward-i2rs-framework"> </xref>
describes a mechanism to control network protocols like BGP using a set of 
programmatic interfaces.  These programmatic interfaces allow one to control
the BGP protocol by analyzing its operational state and routing protocol data,
plus manipulating BGP's configuration to achieve various goals.  The I2RS is
not intended to replace any existing configuration mechanisms, (i.e.:
Command Line Interface or NETCONF).  Instead, I2RS is intended to augment those
existing mechanisms by defining a standardized set of programmatic interfaces
to enable easier configuration, interrogation and analysis of the BGP protocol.
</t>

<t>
This document describes set of use cases for which I2RS's programmatic
interfaces can be used to control and analyze the operation of BGP. The use
cases described in this document cover the following aspects of BGP:
protocol parameter configuration, configuration of routing policies, protocol
route manipulation and tracking of protocol events.  The goal is to inform the
community's understanding of where the I2RS BGP extensions fit within the
overall I2RS architecture.  It is intended to provide a basis for the solutions 
draft describing the set of Interfaces to the BGP protocol.
</t>

      <section title="Requirements Language">
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
        document are to be interpreted as described in <xref
        target="RFC2119">RFC 2119</xref>.</t>
      </section>
    </section> <!-- for Introductions section -->

<section title="BGP Configuration">
<t>
The configuration of BGP is arduous to establish and maintain, particularly on
networks whose services have a requirement for complex routing policies. This
need is magnified by the need to routinely perform changes to large numbers of
BGP routers to, for example: add or remove customer's BGP sessions, announce or
withdraw (customer) IP prefixes in BGP, modify BGP policies to effect changes
in Traffic Engineering, audit BGP routers to ensure they have consistent and
appropriate BGP policies, etc.
</t>

<t>
There are three categories of BGP configuration:
<list style="numbers">
  <t>Local BGP routing protocol configuration: local Autonomous System Number
  (ASN), BGP path selection properties of the router, injection of (aggregate)
  routes into BGP, etc.</t>
  <t>Local BGP policies: policies designed to filter and then manipulate
  BGP attributes associated with BGP routes learned through BGP sessions.
  These policies typically live in the global configuration of a BGP router,
  but are applied on a per-BGP neighbor basis (or, group of BGP neighbors); and,</t>
  <t>BGP neighbor sessions: remote ASN, remote IP address, address families,
  BGP policies to applied to routes, max-prefix limits, etc.</t>
</list>
The sum total of BGP configuration on a BGP router is typically the largest
quantify of configuration on Service Provider's BGP routers, by a fairly large
margin.  When that is combined with the large set of routine configuration
changes, mentioned above, it should be fairly clear that systematic reading,
configuration and control of BGP routers through a mechanism like I2RS would
greatly benefit all operators of BGP routers.
</t>

<t>
While it may not be possible to provide programmatic APIs for esoteric
vendor-specific policy configuration, it is possible to
provide such API's for BGP protocol specific configuration and the more commonly
used BGP routing policies.
</t>

<section title="BGP Protocol Configuration">
<t>
Ability to enable and disable new address families within a BGP protocol for a
network of BGP speaking routers is a challenge. The challenge is mainly in 
keeping track of BGP speaker's feature capabilities and then configuration of new 
address families on a multiple BGP speakers within a given network. With
the necessary information, I2RS controllers allow a
network operator to push configuration information for enabling and disabling 
of new address families on a partial or entire set of BGP speakers 
within a given network. This would assist in building BGP overlay networks as needed.
</t>

<t>
For VPN address families, the main challenge lies in the complex VPN configuration
required to setup the control plane for Customer VPNs. The configuration involves
creating a Virtual Routing and Forwarding instance (VRF), a Route Distinguisher (RD) 
that ensures each customer prefixes remains
unique across VPNs, and Route Targets (RT) that help ensure that the Customer prefixes
are segregated appropriately so that they do not cross the VPN boundaries. I2RS
would allow a network operator to push such configuration from a central location where
a global VPN provisioning information could be stored. This helps avoid manual
configuration of a VPN on multiple routers. Instead the configuration is controlled 
and pushed though a central I2RS controller using a programmatic set of APIs on targeted
set of BGP speakers.
</t>

<t>
Use of I2RS controllers to announce protocol configuration information would simplify
and automate configuration of BGP protocol in IBGP deployments where the protocol
based policies are seldom used.
To facilitate such a centralized configuration model, BGP speakers could
be extended to use programmatic APIs to announce their feature capabilities as part of
protocol initialization to the centralized I2RS controllers. This would assist I2RS
controllers to auto-discover BGP protocol capabilities of various BGP speakers in
a given network. I2RS controllers in turn would use the information towards 
enabling/disabling of BGP specific features on BGP speakers.
</t>
</section>

<section title="BGP Policy Configuration">
<t> 
Filtering of BGP routes is strongly recommended to control the announcements of
BGP prefixes across the internet. Most providers make extensive use of BGP 
prefix filtering policies at the edge of their networks. The reasons for 
filtering BGP prefixes are:
<list style="symbols">
  <t>
  Avoid Unwanted Route Announcements. Filter prefixes that MUST not be 
  routed <xref target="RFC5735"/>, <xref target="RFC5156"/>. Filter
  prefixes that are not allocated by Internet Routing Registries.
  </t>

  <t>
  Facilitate Route Summarization. Filter prefixes beyond 
  certain agreed prefix mask length between providers. Route Summarization
  helps control BGP RIB and FIB table size.
  </t>

  <t>
  Defensive Security. Filter prefixes from Stub customer ASes that are not 
  owned by the customers. Filter customer prefixes announced by other providers.
  This helps avoid prefix hijacking.
  </t>
</list>
</t>

<t>
A set of standards-based schemas to enable configuration of Local
BGP policies and BGP neighbor sessions was realized through the Routing Policy
Specification Language (RSPL) <xref target="RFC2622"></xref>.
The RPSL defined a standards-based schemas, or 'objects' as it called them,
that defined:
<list style="symbols">
  <t>binding of IP prefixes to (one or more) Origin AS, (route objects);</t>
  <t>collections of routes (route-set objects);</t>
  <t>collections of Autonomous Systems (as-set objects); and, </t>
  <t>routing policy of an Autonomous System to/from its adjacent neighbor AS'es,
  (aut-num objects)</t>
</list>
Each ASN is responsible for creation, modification and deletion of its RPSL
objects in an Internet Routing Registry (IRR).  IRR's are typically operated
by Regional Internet Registries (RIR's) and a few dozen larger ISP's and
independent organizations.  The IRR's provide a well-known location for all
organizations attached to the Internet to retrieve or update RPSL objects.
</t>

<t>
While still widely and actively used by Internet Service Providers, the
prevailing belief is that the data contained in the IRR's is inaccurate,
primarily due to a lack of deployed authorization method with respect to the
creation of modification of RPSL objects.  It should be noted that this
criticism is not directed at the previously defined RPSL schemas, but
rather at the data contained in RPSL schemas by end-users of the IRR system.
Please refer to the
<xref target="I-D.mcpherson-irr-routing-policy-considerations">IRR And Routing Policy Configuration Considerations</xref>
document for a more thorough discussion of the history and present state of
the IRR's.
</t>

<t>
Currently, RPSL schemas are exchanged between non-routing systems (servers)
used within the IRR system.  In addition, open-source
and proprietary applications create or modify RPSL schemas, as necessary, to
signal the announcement (or, withdrawal) of an IP prefix from an ASN or the
creation (or, teardown) of a neighbor relationship between two adjacent ASN's.
Most importantly, these RPSL schemas are consumed by similar applications to
automatically build routing policies, (i.e.: lists of IP prefixes, corresponding
Origin ASN's 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
routing policy on the network.  It is common for Internet Service Providers to
perform updates to these routing policies across their entire network on a
daily basis.
</t>

<t>
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 information sources,
are translated into standards-based schemas that are then pushed, or pulled,
into individual BGP routers.  More generally, I2RS controllers could use API's
to gather information required to build various types of BGP routing policies
plus the corresponding set of Autonomous System Border Routers (ASBR's) where
such policies need to be applied in the network and, finally, making those
changes to individual network elements so those BGP policies take effect
in the network.  In doing so, a network operator now has a centralized way of
building and making these policies take effect across the network in a
coordinated manner.
 </t>

</section>
</section>

<section title="BGP Protocol Operation">

<t>
It is increasingly common for services facilitated via BGP to be subject to
severe, widespread disruptions (outages), primarily due to the destructive
teardown of BGP sessions as a result of receiving malformed BGP attributes.
The document <xref target="I-D.ietf-grow-ops-reqs-for-bgp-error-handling">
Operational Requirements for Enhanced Error Handling Behaviour in BGP-4</xref>
outlines requirements to try to minimize the scope of the impact attributed
to such errors.  Unfortunately, more fine-grained BGP error handling solutions,
which would result in little to no impact on the operation of BGP protocol,
remain elusive.
</t>

<section title="BGP Error Handling for Internal BGP Sessions">
<t>
It is possible that I2RS could enable enhanced error handling techniques for
Internal BGP sessions.  At a minimum, I2RS-capable BGP routers could signal an
event such as "Malformed Attribute Received" toward an I2RS controller(s).
I2RS controller(s) may already have a real-time view of BGP routes, and
corresponding BGP attributes, or may dynamically interrogate BGP routers in the
network to identify the present propagation scope of the BGP route(s) that
are affected.  Finally, the I2RS controller(s) could then signal back to
BGP routers to apply a filter that would block propagation of the BGP attribute
or BGP route, as necessary, in order to temporarily aid in consistency of BGP
routing information across the entire network until a permanent fix can be
developed and deployed within BGP routers.
</t>

<t>
I2RS would enable the global visibility and global control over the operational
state of BGP, within a given Autonomous System, that is necessary to facilitate
the learning of, rapid response to and more fine-grained isolation/scoping of
BGP protocol events that currently cause a destructive tear-down of BGP
sessions that lead to widespread disruptions of services.
</t>
</section>

</section>

<section title="BGP Route Manipulation">
<t>
Multiprotocol BGP <xref target="RFC4760"></xref> provides support to carry 
routing information for different BGP address families. Route manipulation is 
heavily done across these different address families for different reasons. 
BGP IPv4 and IPv6 address families use BGP Communities <xref target="RFC1997"></xref> 
and other IBGP and EBGP attributes to manipulate BGP routes for Traffic 
Engineering purpose. BGP VPN adddress families use Extended Communities
<xref target="RFC4360"></xref> to filter unwanted BGP routes.
BGP Flowspec address family <xref target="RFC5575"></xref> is used to install Flow based filters 
to filter unwanted data traffic. The following sub-sections
describe the use of I2RS towards BGP Route Manipulation for different BGP
address families.
</t>

<section title="Customized Best Path Selection Criteria">

<t>
The BGP customized Bestpath facilitates custom bestpath computations within
a BGP speaking network. It is usually used within an IBGP network. Customized
bestpaths use special extended communities known as cost communities. Cost 
communities carry enough information; Point of Insertion (POI) and the cost value 
to signal where in BGP bestpath the customize checks need to be done. Both, the
traffic engineering as well as backdoor (SHAM) links use customized bestpath
computation.
</t>

<t>
With I2RS, it would be possible for an I2RS controller to push routes with custom
cost communities on the BGP routers for Traffic Engineering purpose. I2RS controller
now can act as a central entity keeping track of all Traffic engineering data that
get applied to BGP routes within an IBGP network.
</t>
</section>

<section title="Flowspec Routes">
<t>
The BGP flowspec address family is used to disseminate the traffic flow specification
to the BGP Autonomous System Border Routers (ASBRs) and Provider Edge (PE) routers. Both, the BGP 
ASBRs and the PEs would translate the received BGP traffic flow specification into an
Access Control List (ACL) and install it in router's forwarding path. Using such
ACLs routers can now classify, shape, rate limit, filter, or redirect traffic flows.
</t>

<t>
With I2RS, it would be possible for an I2RS controller to push traffic flow specifications
to the BGP ASBRs and the PE routers. I2RS controller can act as a central entity tracking all the
traffic flow specifications that are installed within an IBGP network. I2RS controller
could also prioritize and control the announcement of traffic flow specifications 
according to various ASRBs and PE router's capacity. BGP ASBRs and PE routers MAY forward
traffic flow specifications received from EBGP speakers to I2RS Controllers.
This would allow I2RS controllers to centrally manage and track any externally received
traffic flow specifications.
</t>
</section>

<section title="Route Filter Routes for Legacy Routers">
<t> 
The BGP Route Filter address family is used to disseminate the Route Target 
filter information between VPN BGP speakers. This information is then used to 
build a route distribution graph that helps in limiting the propagation of VPN NLRI 
within a VPN network. However, it requires that all the BGP VPN routers are
upgraded to support this functionality. Otherwise, the graph information is 
incomplete when a VPN network consists of legacy routers that participates in VPN 
but does not implement the BGP route filter address family.
</t>

<t>
With I2RS, it would be possible for an I2RS controller to push router filter information
to BGP RR routers on behalf of all legacy routers that participates in VPN but does
not support or implement the BGP route filter address family. I2RS controller can act 
as a central entity tracking all the configured Route Filters for legacy routers and
push them on appropriate RRs who in turn would push it to ASBRs and PE routers. In this way,
I2RS controllers help build an optimal route distribution graph that would assist in 
filtering of VPN NLRIs in a VPN network.
</t>
</section>

<section title="Optimized Exit Control">
<t> 
Optimized Exit Control is used to provide route optimization and load distribution for
multiple network connections between networks. Network operators can monitor IP traffic
flows and then could define policies and rules based on traffic class performance,
link bandwidth monetary costs, link load distribution, traffic types, link failures, etc.
</t>


<t>
With I2RS, it would be possible for an I2RS controller to manipulate BGP routes and its
parameters that influence BGP bestpath decisions. I2RS controller could act as a central
entity that would monitor and manipulate BGP routes based on central network based policies.
Such routes would then be injected by a I2RS controller into the network so as to get
the load distribution for multiple network connections.
</t>

</section>

</section>

<section title="BGP Events" anchor="event_registration">

<t>
Given the extremely large number of BGP Routes in networks, it is critical to
have scalable mechanisms that can be used to monitor for events affecting routing
state and, consequently, reachability.  In addition, similar tools are needed
in order to monitor BGP protocol statistics, which help operators and developers
better understand scalability of software and hardware that BGP utilizes.
</t>

<t>
I2RS could provide a publish-subscribe capability to applications to:
<list style="symbols">
  <t>request monitoring of BGP routes and related events; and,</t>
  <t>subscribe to the I2RS controller to receive events related to BGP routes
  or other protocol-related events of interest.</t>
</list>
</t>

<section title="Notification of Routing Events" anchor="routing_events_notification">

<t>
There are certain IP prefixes, for example those that are arbitrarily classified
by a given network operator as "high visibility" by its end-users, for which
immediate notification of changes in their state are extremely useful to know
about.  Upon notification of such events, a Network Operations Center (NOC)
could respond to customer inquiries in a more timely fashion; alternatively,
the NOC may decide to perform Traffic Engineering to restore service, etc.
</t>

<t>
Currently, the only way to learn of such events is for a BGP monitoring system
to establish a BGP session with a multitude of BGP 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 of interest to it.  Note, this doesn't account
for the fact that there are several applications that might be simultaneously
interested in learning of events to a given IP prefix nor the fact that some
applications may want to dynamically insert or remove "IP prefixes of interest",
depending on the needs of their constituent applications.
</t>

<t>
With I2RS, it is conceivable that applications could tell an I2RS controller,
through a North-Bound API, their "IP prefixes" (or, AS_PATH's, BGP communities,
etc.) that are of interest.  For example, a NOC application may be interested
in changes to high visibility content or service-provider Web sites;
alternatively, a security application may be interested in events associated
with a different set of IP prefixes.  The I2RS controller would then consolidate
the list of IP prefixes, and associated characteristics, to be monitored and
program BGP routers in an AS to observe this subset of routes for changes.
Some examples of changes in routing state might include:
<list style="symbols">
  <t>an IP prefix being announced or withdrawn</t>
  <t>an IP prefix being suppressed, due to route flap dampening</t>
  <t>an alternative best-path being chosen for a given IP prefix</t>
</list>
When the requisite events for a BGP Route are observed by a BGP router, it
would notify I2RS controllers.
</t>

<t>
The I2RS controllers would have a publish/subscribe mechanism whereby 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-specific action necessary.
</t>
</section> <!-- EO routing_events_notification -->

<section title="Tracing Dropped BGP Routes" anchor="tracing_bgp_routes">
<t>
It is extremely useful to operators to be able to rapidly identify instances
where a BGP route is not being propagated within an Autonomous System.  At
a minimum, this could result in sub-optimal performance when attempting to
reach such destinations.
</t>

<t>
There are two instances when this scenario will occur.  First, when a Service
Provider is using "Soft Reconfiguration Inbound", it allows their ASBR routers
to receive a copy of a BGP route, but show that route was not permitted into
the Adj-RIB-In most likely as a result of the inbound BGP policy not permitting
that IP prefix.  Thus, this BGP route is not even eligible for BGP Path
Selection.  The second instance is where the BGP route is permitted by
the inbound BGP policy into the Adj-RIB-In, but due to BGP Path Selection
(i.e.: lower LOCAL_PREF, longer AS_PATH length, etc.) was not chosen as the
best path and, subsequently, this particular BGP route is not forwarded on to
other internal BGP speakers in the AS.  In both instances, the BGP route is
only visible within the ASBR on which that BGP route was first learned.
Needless to say, in large Service Provider networks with a numerous interconnects
to a single customer it can be very time-consuming to discover where such a
BGP route is learned before ultimately determining why the route was blocked
or not preferred.
</t>

<t>
With I2RS, it would be possible for an I2RS controller to rapidly gather information
from across a large set of BGP routers in the network to determine at what ASBR's
the BGP route is being learned.  Next, the I2RS controller could interrogate those
routers BGP policies to determine the root cause of why the route was either
not learned or not preferred in BGP.  Finally, if necessary, the I2RS controller(s)
could amend BGP policies and push them out to BGP routers to permit the BGP
route or make it a preferred route according to the BGP path selection algorithm.
</t>
</section> <!-- EO tracing_bgp_routes -->

<section title="BGP Protocol Statistics" anchor="bgp_protocol_statistics">

<t>
There are a variety of statistics related to the operation of BGP that are
invaluable to network operators.  These statistics generally help operators,
and developers, understand the present state and future scalability of BGP.
</t>

<t>
One statistic that is invaluable to operators is the current number of BGP
routes learned through an eBGP session.  Operators then apply a command against
each eBGP session to limit the maximum number of BGP routes that may be learned
through that eBGP session before a warning message is triggered and/or the eBGP
session is torn down completely.  This configuration capability is often referred
to as a "max-prefix limit".  This command must be routinely audited and, if
necessary, adjusted in order to not trigger a false warning or teardown due to
the natural organic growth in BGP routes learned from a given BGP neighbor.
</t>

<t>
I2RS controllers could provide an invaluable capability to help audit and
re-program the "max-prefix limit" on a periodic basis, which is generally once
per day.  Specifically, the first task would be for an I2RS controller to validate
that there is a "max-prefix limit" applied to every eBGP session.  (If there is
not, that should either trigger a red alarm to the NOC to manually fix this
condition or for the I2RS controller to automatically apply a "max-prefix limit"
that would alleviate this hazardous condition).  Assuming there is a "max-prefix
limit" already in place, the I2RS controller would simultaneously retrieve,
from each BGP router, the current number of BGP routes learned through a BGP
session and value used for the "max-prefix limit" on that same BGP session.
These two values could then be handed off to an application that determines
if adjustments in the "max-prefix limit" value are required for each BGP
session.  The application would then notify the I2RS controller of the subset of
eBGP sessions and their associated change in "max-prefix limit" value, whereby
the I2RS controller would then adjust the BGP protocol configuration on each
requisite BGP router in the network.  Finally, it should be noted that the
above is just one method whereby "max-prefix limit" values are adjusted.  It's
similarly possible that the BGP routers may, through the I2RS, pull the
"max-prefix limit" values for each eBGP neighbor they have onboard on a
periodic basis and validate their accuracy.
</t>

<t>
The above is just one use case related to BGP protocol statistics.  There are
wealth of other BGP protocol statistics or state informatioin that would be
invaluable to have programmatic visibility into that operators do not have
today.
</t>

</section> <!-- EO bgp_protocol_statistics -->
</section> <!-- EO event_registration -->

<section anchor="Security" title="Security Considerations">
<t>
The BGP use cases described in this document assumes use of I2RS's programmatic
interfaces described in the I2RS framework mentioned
in <xref target="I-D.ward-i2rs-framework"></xref>. This document does not
change the underlying security issues inherent in the existing 
<xref target="I-D.ward-i2rs-framework"></xref>.
</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>
TBD.
</t>
</section>

    <!-- Possibly a 'Contributors' section ... -->

  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
    1. define an ENTITY at the top, and use "ampersand character"RFC2629;
        here (as shown)
    2. simply use a PI
        "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds:
          include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

    Both are cited textually in the same manner: by using xref elements.
    If you use the PI option, xml2rfc will, by default, try to find included
    files in the same directory as the including file. You can also define
    the XML_LIBRARY environment variable
    with a value containing a set of directories to search.  These can be
    either in the local
    filing system or remote ones accessed by http (http://domain/dir/... ).-->

    <references title="Normative References">
      <!--?rfc include=
      "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
      &RFC2119;

      &RFC2629;

      &RFC1997;

      &RFC3392;

      &RFC3552;

      &RFC4271;

      &RFC4360;

      &RFC4760;

      &I-D.ward-i2rs-framework;
    </references>

    <references title="Informative References">
      &RFC2622;

      &RFC2858;

      &RFC5156;

      &RFC5575;

      &RFC5735;
      
      &I-D.mcpherson-irr-routing-policy-considerations;
      
      &I-D.ietf-grow-ops-reqs-for-bgp-error-handling;

    </references>
    <!-- Change Log

v00 2008-10-01  KP    Initial version
    -->
  </back>
</rfc>