<?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 RFC5492 SYSTEM
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5492.xml">
<!ENTITY RFC5735 SYSTEM
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5735.xml">
<!ENTITY RFC6890 SYSTEM
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6890.xml">
<!ENTITY RFC5575 SYSTEM
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5575.xml">
  <!ENTITY RFC6198 SYSTEM
  "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6198.xml">
<!ENTITY I-D.ietf-i2rs-architecture SYSTEM 
  "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-i2rs-architecture-09.xml">
  <!ENTITY I-D.ietf-i2rs-usecase-reqs-summary SYSTEM 
  "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-i2rs-usecase-reqs-summary-01.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-bgp-gshut SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-grow-bgp-gshut-06.xml">
<!ENTITY I-D.white-grow-overlapping-routes SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-white-grow-overlapping-routes-03.xml">
]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="info" docName="draft-keyupate-idr-i2rs-bgp-usecases-02.txt" ipr="pre5378Trust200902">
  <front>
    <title abbrev="Use Cases for an Interface to BGP">    Use Cases for an Interface to BGP Protocol</title>
    <author fullname="Keyur Patel" initials="K.P."
            surname="Patel">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street>170 W. Tasman Drive</street>
          <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="Russ White" initials="R" surname="White">
      <organization>Ericsson</organization>
      <address>
        <email>russw@riw.us</email>
      </address>
    </author>
		
	<author fullname="Susan Hares" initials="S" surname="Hares">
      <organization>Huawei</organization>
      <address>
        <email>shares@ndzh.com</email>
      </address>
    </author>

    <date year="2016" />
    <area>Routing</area>
    <workgroup>IDR</workgroup>
	<keyword>BGP</keyword>
    <keyword>I2RS BGP Use Case</keyword>
<abstract>
<t>
A network routing protocol like BGP is typically configured  
and analyzed through some form of Command Line Interface (CLI) or
NETCONF.  These interactions to control BGP and diagnose its operation
encompass: configuration of protocol parameters, display of protocol
data, setting of certain protocol state and debugging of the protocol.
</t>
<t>
Interface to the Routing System's (I2RS) Programmatic interfaces provides an alternate way to 
control and diagnose the operation of the BGP protocol.  I2RS
may be used for the configuration, manipulation, analyzing or collecting the protocol 
data. This document describes set of use cases for which I2RS can be used for 
BGP protocol. It is intended to provide a base for the solution draft 
describing a set of interfaces to the BGP protocol.
</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 architecture document <xref target="I-D.ietf-i2rs-architecture"> </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, 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 title="Requirements for I2S"> 
	  <t> 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. 
	 </t>
	 </section> 
    </section> <!-- for Introductions section -->

<section title="Summary of Requirements for I2RS Module for BGP" toc="default">
<t> This is a summary of the requirements for an IDR I2RS Yang Module listed in this document. 
<list style="symbols">
	<t>BGP-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 </t>
	 <t>BGP-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.  </t>
	<t>BGP-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. 
	</t> 
	<t>BGP-REQ04: I2RS Agents SHOULD support identification of routers as BGP ASBRs, PE routers, and IBGP routers. </t>
	<t>BGP-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.</t>
	<t>BGP-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 </t> 
	<t>BGP-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.</t> 
	<t>BGP-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.  
	</t> 
	<t>BGP-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</t> 
	 <t>BGP-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. 
	</t>    
	<t>BGP-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).  </t>
	<t>BGP-REQ12: I2RS client SHOULD be able to request the I2RS agent to read installed BGP Policies.</t> 
	<t>BGP-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. 
	</t> 
	<t> BGP-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. </t>
     <t>BGP-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.</t>
	<t>BGP-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</t>
    <t>BGP-REQ17: The I2RS client via the I2RS agent SHOULD have the the ability to read the loc-RIB-in BGP table to 
	discover overlapping routes, and determine which may be safely marked for removal.</t>
	<t>BGP-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.</t>
 </list>
 </t> 
 <t> This summary is also listed in the <xref target="I-D.ietf-i2rs-usecase-reqs-summary"></xref>. </t>
</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.
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>
<t> 
A planned Graceful must also carefully be handled to limit the amount of 
traffic loss during a the shutdown.  While operational requirements for the 
BGP mechanism for graceful shutdown of a (set of) BGP sessions is
described in <xref target="RFC6198"> </xref>, and the operational procedures
are described in <xref target="I-D.ietf-grow-bgp-gshut"> </xref>, additional
fine-grained BGP error handling could improve graceful shutdown of BGP sessions. 
</t>
<t> This section discussed how I2RS information could improve both the 
destructive teardown and the graceful teardown of sessions. 
</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" via an I2RS agent toward an I2RS client(s).  
I2RS client(s) may already have a real-time view of BGP routes, and
corresponding BGP attributes, or may dynamically interrogate BGP routers in the
network to identify the present propagation scope of the BGP route(s) that
are affected.  Finally, the I2RS client(s) could then signal back to I2RS agents
on BGP routers to apply a filter that would block propagation of the BGP attribute
or BGP route, as necessary, in order to temporarily aid in consistency of BGP
routing information across the entire network until a permanent fix can be
developed and deployed within BGP routers.
</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> <!-- for error handling internal -->
<section  title="Summary of I2RS Capabilities and Interactions"> 
 <t>
 <list style="symbols">
	<t>BGP-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 </t>
 </list>
 </t>
 </section>
</section> <!-- Error handling -->

<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 address 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 IRS 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 client to push routes with custom
cost communities on the BGP routers for Traffic Engineering purpose. I2RS client
now can act as a central entity keeping track of all Traffic engineering data that
get applied to BGP routes within an IBGP network.
</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 client to push traffic flow specifications
to the BGP ASBRs and the PE routers. I2RS client can act as a central entity tracking all the
traffic flow specifications that are installed within an IBGP network. I2RS client
could also prioritize and control the announcement of traffic flow specifications 
according to various ASRBs and PE router's capacity. BGP ASBRs and PE routers MAY forward
traffic flow specifications received from EBGP speakers to I2RS Agents.
This would allow I2RS agents to centrally manage and track any externally received
traffic flow specifications.
</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 (network Layer Reachabilty Information)
within a VPN network. However, it requires that all the BGP VPN routers are
upgraded to support this functionality. Otherwise, the graph information is 
incomplete when a VPN network consists of legacy routers that participates in VPN 
but does not implement the BGP route filter address family.
</t>
<t>
With I2RS, it would be possible for an I2RS client to push router filter information
to BGP RR routers on behalf of all legacy routers that participates in VPN but does
not support or implement the BGP route filter address family. I2RS client can act 
as a central entity tracking all the configured Route Filters for legacy routers and
push them on appropriate RRs who in turn would push it to ASBRs and PE routers. In this way,
I2RS agents help build an optimal route distribution graph that would assist in 
filtering of VPN NLRIs in a VPN network.
</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 client to manipulate BGP routes and its
parameters that influence BGP bestpath decisions. I2RS client could act as a central
entity that would monitor and manipulate BGP routes based on central network based policies.
Such routes would then be injected by a I2RS client into the network so as to get
the load distribution for multiple network connections.
</t>
</section>
<section  title="Summary of I2RS Capabilities and Interactions"> 
 <t>
 <list style="symbols">
 <t>BGP-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 I2RS RIB. 
 </t>    
 <t>BGP-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. 
</t> 
<t> BGP-REQ04: I2RS Agents SHOULD support identification of routers as BGP ASBRs, PE routers, IBGP routers. </t>
<t> BGP-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.</t>
<t> BGP-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. </t> 
<t> BGP-REQ07: I2RS client-agent exchange SHOULD support the I2RS client 
being able to prioritize and control BGP's announcement of 
flow specifications after the reading of status information on capacity of BGP routers (ASBR and PE). 
 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 client query or as part of pub/sub event notification.
  
</t> 
<t> BGP-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.  
</t> 
<t>BGP-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</t> 
 </list>
 </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 client 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 client,
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 client 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 agents.
</t>

<t>
The I2RS agents would have a publish/subscribe mechanism whereby various
sets of applications may subscribe to events of interest.  The I2RS client
would then publish these events so applications would immediately receive them
and take the appropriate domain-specific action necessary.
</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 client to rapidly gather information
from across a large set of BGP routers in the network to determine at what ASBR's
the BGP route is being learned.  Next, the I2RS client could interrogate those
routers BGP policies to determine the root cause of why the route was either
not learned or not preferred in BGP.  Finally, if necessary, the I2RS client(s)
could amend BGP policies and push them out to BGP routers to permit the BGP
route or make it a preferred route according to the BGP path selection algorithm.
</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 agents 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 client 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 client 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 client 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 client of the subset of
eBGP sessions and their associated change in "max-prefix limit" value, whereby
the I2RS client 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 on-board 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 information that would be
invaluable to have programmatic visibility into that operators do not have
today.
</t>

</section> <!-- EO bgp_protocol_statistics -->
<section  title="Summary of I2RS Capabilities and Interactions for Event statistics "> 
 <t>
 I2RS SHOULD have the ability to: 
 <list style="symbols">
 <t>BGP-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. 
 </t>    
 <t> BGP-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).  </t>
 <t>BGP-REQ12: I2RS client SHOULD be able to request the I2RS agent to read installed BGP Policies </t> 
 <t>BGP-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. 
</t> 
<t> BGP-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. </t>
 </list>
 </t>
   </section>
</section> <!-- EO event_registration -->
<section title="Central membership computation for MPLS based VPNs" toc="default">
  	  <t> </t>
      <t>MPLS based VPNs use route target extended communities to express membership information. Every PE router holds incoming BGP NLRI and processes them to determine membership and then import the NLRI into the appropriate MPLS/VPN routing tables. This consumes resources, both memory and compute on each of the PE devices.</t>
	  <t>An alternative approach is to monitor routing updates on every PE from the attached CEs and then compute membership in a central manner. Once computed the routes are pushed to the VPN RIBs of the participating PEs.</t>
	  <t>This centralization of membership control has a few advantages.</t>
      <t>
  	  <list style="symbols">
	    <t>The membership mechanism (route-targets) need not be configured in each of the PEs and can be expressed once centrally.</t>
		<t>No resources in the PEs need to be spent to categorize routes into the VRF tables that they belong and to filter out unwanted state.</t>
		<t>Doing it centrally means the availability of almost unlimited compute capacity to compute membership and hence can be done in a scaleable manner.</t>
		<t>More sophisticated routing policies and filters can be applied during the central import/export process than can be expressed and performed using the traditional route target mechanism.</t>
		<t>Routes can be selectively pushed only to the participating PE's further reducing the memory load on the individual routers in the network. This further obviates for a distributed mechanisms such as rt constraints to reduce unnecessary path state in the routers.</t>
      </list>
      </t>
      <t> Note that centrally computation of membership can be applied to other scenarios
	  as well such as VPLS, MVPNs, MAC VPNs and others. Depending on the scenario, what gets
	  monitored from the CE might vary. Central computation will especially help VPLS where 
	  multi-homing and load balancing using distributed techniques has particularly been
	  a challenge.</t>
	  <t>Also note that one of the biggest promises of central route computation is simplification
	  and reduction of computation and memory load on all devices in the network. This use case is
	  just one example that illustrates these benefits of central computation very well.</t>
      <t>Summary of I2RS Capabilities and Interactions:</t>
      <t>
      <list style="symbols">
        <t>BGP-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.</t>
		<t>BGP-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</t>
      </list>
      </t>
   </section>

<section title="Marking Overlapping Traffic Engineering Routes for Removal" toc="default">
  	  <t> </t>
      <t>It is often the case that routes are advertised not to provide reachability 
	 (in the strict sense), but rather to provide optimal reachability, or to engineer 
	 the path traffic takes to a particular destination. While this can improve the 
	 efficiency of a network's operation, it can also increase the amount of state carried
	 in the control plane beyond the point where the additional state has any real effect 
	 on traffic flow. <xref target="I-D.white-grow-overlapping-routes">Removing Overlapping Routes</xref> 
	 provides a mechanism designed to remove these traffic engineering routes once they are beyond
	 the point of actually impacting traffic flows in the network.</t>
      <t>Summary of I2RS Capabilities and Interactions:</t>
      <t>
      <list style="symbols">
        <t>BGP-REQ17: The I2RS client via the I2RS agent SHOULD have the the ability to read the loc-RIB-in BGP table to 
		 discover overlapping routes, and determine which may be safely marked for removal.</t>
		<t>BGP-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.</t>
      </list>
      </t>
   </section>
<section anchor="IANA" title="IANA Considerations">
<t>
This document makes no request of IANA.
</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
The BGP use cases described in this document assumes use of I2RS programmatic
interfaces described in the I2RS framework mentioned
in <xref target="I-D.ietf-i2rs-architecture"></xref>. This document does not change 
the underlying security issues inherent in the existing in   
<xref target="I-D.ietf-i2rs-architecture"></xref>.
</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>
  The authors would like to thank Ed Crabbe, Joel Halpern, Wes George, Carlos Pignataro,
  Jon Mitchell, Rex Fernando, Hannes Gredler, Shane Amante, Bill Atwood for their comments and suggestions.
</t>
</section>

    <!-- Possibly a 'Contributors' section ... -->

</middle>

  <!--  *****BACK MATTER ***** -->

<back>

    <references title="Normative References">
      &RFC2119;
      &RFC2629;
      &RFC1997;
      &RFC5492;
      &RFC3552;
      &RFC4271;
      &RFC4360;
      &I-D.ietf-i2rs-architecture;
	  &I-D.ietf-i2rs-usecase-reqs-summary;
    </references>
    <references title="Informative References">
      &RFC2622;
      &RFC4760;
      &RFC5575;
	  &RFC6198;
      &RFC6890;
      &I-D.mcpherson-irr-routing-policy-considerations;
	  &I-D.white-grow-overlapping-routes;
	  &I-D.ietf-grow-bgp-gshut; 

    </references>
<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, and others. 
</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/or 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 agents 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 client using a programmatic set of APIs on targeted
set of BGP speakers.
</t>

<t>
Use of I2RS agents 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 centralize I2RS agents. This would assist I2RS
agents to auto-discover BGP protocol capabilities of various BGP speakers in
a given network. I2RS agents 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="RFC6890"/>. 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 agents 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>
    <!-- Change Log

v00 2013-03-10  KP    Initial version
v01 2013-02-14  KP/SH remove Configuration add MPLS 
V02 2014-05-30  SKH   correct agents to client, update 
V03 2014-05-03  SKH Add requirements section to each part
v04 2014-07-03 	SKH Requirements numbering to match all use case draft
    -->
  </back>
</rfc>

