One document matched: draft-white-i2rs-use-case-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!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 RFC3746 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3746.xml">
<!ENTITY I-D.atlas-irs-problem-statement SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.atlas-irs-problem-statement.xml">
<!ENTITY I-D.ward-irs-framework SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ward-irs-framework.xml">
<!ENTITY I-D.lapukhov-bgp-routing-large-dc SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-lapukhov-bgp-routing-large-dc-06.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="no" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="info" docName="draft-white-i2rs-use-case-01" ipr="trust200902">
<front>
<title abbrev="IRS Use Cases">Protocol Independent Use Cases for an
Interface to the Routing System</title>
<author fullname="Russ White" initials="R" surname="White">
<organization>IETF</organization>
<address>
<email>russw@riw.us</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Susan Hares" initials="S" surname="Hares">
<organization>ADARA</organization>
<address>
<email>shares@ndzh.com</email>
</address>
</author>
<author fullname="Alvaro Retana" initials="A" surname="Retana">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>7025 Kit Creek Road</street>
<city>Research Triangle Park</city>
<region>NC</region>
<code>27617</code>
<country>USA</country>
</postal>
<email>aretana@cisco.com</email>
</address>
</author>
<date month="August" year="2013"/>
<area>Routing</area>
<workgroup>i2rs</workgroup>
<abstract>
<t>Programmatic interfaces to provide control over individual forwarding
devices in a network promise to reduce operational costs while improving
scaling, control, and visibility into the operation of large scale
networks. To this end, several programmatic interfaces have been
proposed. OpenFlow, for instance, provides a mechanism to replace the
dynamic control plane processes on individual forwarding devices
throughout a network with off box processes that interact with the
forwarding tables on each device. Another example is NETCONF, which
provides a fast and flexible mechanism to interact with device
configuration and policy.</t>
<t>There is, however, no proposal which provides an interface to all
aspects of the routing system as a system. Such a system would not
interact with the forwarding system on individual devices, but rather
with the control plane processes already used to discover the best path
to any given destination through the network, as well as interact with
the routing information base (RIB), which feeds the forwarding table the
information needed to actually switch traffic at a local level.</t>
<t>This document describes a set of use cases such a system could
fulfill. It is designed to provide underlying support for the framework,
policy, and other drafts describing the Interface to the Routing System
(I2RS).</t>
</abstract>
</front>
<middle>
<section title="Introduction" toc="default">
<t>The <xref target="I-D.ward-i2rs-framework">Interface to the Routing
System Framework</xref> describes a mechanism where the distributed
control plane can be augmented by an outside control plane through an
open, accessible interface, including the Routing Information Base
(RIB), in individual devices. This represents a "halfway point" between
completely replacing the traditional distributed control plane and
directly configuring devices to distribute policy or modifications to
routing through off-board processes. This draft proposes a set of use
cases that explain where the work described in [I2RS - should this be a
reference to the framework as above, or to the architecture, or the WG
charter or ??] will be useful. The goal is to inform not only the
community's understanding of where I2RS fits in the larger scheme of SDN
proposals, but also to inform the requirements, framework, and
specification of I2RS to provide the best fit for the purposes which
make the most sense for this type of programmatic interface.</t>
<t>Towards this end the authors have searched for a number of different
use cases representing not only complex modifications of the control
plane, including interaction with applications and network conditions,
but also simpler use cases. The array of use cases presented here should
provide the reader with a solid understanding of the power of an SDN
solution that will augment, rather than replace, traditional distributed
control planes.</t>
<t>Each use case is presented in its own section.</t>
</section>
<section title="Distributed Reaction to Network Based Attacks"
toc="default">
<t/>
<t>Quickly modifying the control plane to reroute traffic for one
destination while leaving a standard configuration in place (filters,
metrics, and other policy mechanisms) is a challenge --but this is
precisely the challenge of a network engineer attempting to deal with a
network incursion. The ability to redirect specific flows of information
or specific classes of traffic into, through, and back out of traffic
analyzers on the fly is crucial in these situations. The following
network diagram provides an illustration of the problem.</t>
<figure align="center" alt="" height="" suppress-title="false" title=""
width="">
<artwork align="center" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
Valid Source---\ /--R2--------------------\
R1 R3---Valid Destination
Attack Source--/ \--Monitoring Device-----/]]></artwork>
</figure>
<t>Modifying the cost of the link between R1 and R2 to draw the attack
traffic through the monitoring device in the distributed control plane
will, of necessity, also draw the valid traffic through the monitoring
device. Drawing valid traffic through a monitoring device introduces
delay, jitter, and other quality of service issues, as well as posing a
problem for the monitoring device itself in terms of traffic load and
management.</t>
<t>An I2RS controller could stand between the detection of the attack
and the control plane to facilitate the rapid modification of control
and forwarding planes to either block the traffic or redirect it to
analysis devices connected to the network.</t>
<t>Summary of IRS Capabilities and Interactions:</t>
<t><list style="symbols">
<t>The ability to monitor the available routes installed in the RIB
of each forwarding device, including near real time notification of
route installation and removal. This information must include the
destination prefix (NLRI), a table identifier (if the forwarding
device has multiple forwarding instances), the metric of the
installed route, and an identifier indicating the installing
process.</t>
<t>The ability to install source and destination based routes in the
local RIB of each forwarding device. This must include the ability
to supply the destination prefix (NLRI), the source prefix (NLRI), a
table identifier (if the forwarding device has multiple forwarding
instances), a route preference, a route metric, a next hop, an
outbound interface, and a route process identifier.</t>
<t>The ability to install a route to a null destination, effectively
filtering traffic to this destination.</t>
<t>The ability to interact with various policies configured on the
forwarding devices, in order to inform the policies implemented by
the dynamic routing processes. This interaction should be through
existing configuration mechanisms, such as NETCONF, and should be
recorded in the configuration of the local device so operators are
aware of the full policy implemented in the network from the running
configuration.</t>
<t>The ability to interact with traffic flow and other network
traffic level measurement protocols and systems, in order to
determine path performance, top talkers, and other information
required to make an informed path decision based on locally
configured policy.</t>
</list></t>
</section>
<section title="Remote Service Routing" toc="default">
<t/>
<t>In hub and spoke overlay networks, there is always an issue with
balancing between the information held in the spoke routing table,
optimal routing through the network underlying the overlay, and
mobility. Most solutions in this space use some form of centralized
route server that acts as a directory of all reachable destinations and
next hops, a protocol by which spoke devices and this route server
communicate, and caches at the remote sites.</t>
<t>An I2RS solution would use the same elements, but with a different
control plane. Remote sites would register (or advertise through some
standard routing protocol, such as BGP), the reachable destinations at
each site, along with the address of the router (or other device) used
to reach that destination. These would, as always, be stored in a route
server (or several redundant route servers) at a central location.</t>
<t>When a remote site sends a set of packets to the central location
that are eventually destined to some other remote site, the central
location can forward this traffic, but at the same time simply directly
insert the correct routing information into the remote site's routing
table. If the location of the destination changes, the route server can
directly modify the routing information at the remote site as
needed.</t>
<t>An interesting aspect of this solution is that no new and specialized
protocols are needed between the remote sites and the centralized route
server(s). Normal routing protocols can be used to notify the
centralized route server(s) of modifications in reachability
information, and the route server(s) can respond as needed, based on
local algorithms optimized for a particular application or network. For
instance, short lived flows might be allowed to simply pass through the
hub site with no reaction, while longer lived flows might warrant a
specific route to be installed in the remote router. Algorithms can also
be developed that would optimize traffic flow through the overlay, and
also to remove routing entries from remote devices when they are no
longer needed based on far greater intelligence than simple non-use for
some period of time.</t>
<t>Summary of IRS Capabilities and Interactions:</t>
<t><list style="symbols">
<t>The ability to read the local RIB of each forwarding device,
including the destination prefix (NLRI), a table identifier (if the
forwarding device has multiple forwarding instances), the metric of
each installed route, a route preference, and an identifier
indicating the installing process.</t>
<t>The ability to monitor the available routes installed in the RIB
of each forwarding device, including near real time notification of
route installation and removal. This information must include the
destination prefix (NLRI), a table identifier (if the forwarding
device has multiple forwarding instances), the metric of the
installed route, and an identifier indicating the installing
process.</t>
<t>The ability to install destination based routes in the local RIB
of each forwarding device. This must include the ability to supply
the destination prefix (NLRI), a table identifier (if the forwarding
device has multiple forwarding instances), a route preference, a
route metric, a next hop, an outbound interface, and a route process
identifier.</t>
</list></t>
</section>
<section title="Within Data Center Routing" toc="default">
<t/>
<t>Data Centers have evolved into massive topologies with thousands of
server racks and millions of hosts. Data Centers use BGP with ECMP, ISIS
(with multiple LAGs), or other protocols to tie the data center
together. Data centers are currently designed around a three or four
tier structure with: server, top-of-rack switches, aggregation switches,
and router interfacing the data center to the Internet. <xref
target="I-D.lapukhov-bgp-routing-large-dc"/> examines many of these
elements of data center design.</t>
<t>One element of these Data Center routing infrastructures is the
ability to quickly read topology information and execute configuration
from a centralized location. Key to this environment is the tight
feedback loop between learning about topology changes or loading
changes, and instantiating new routing policy. Without I2RS, may Data
Centers are using extra physical topologies or logical topologies to
work around the features.</t>
<t>An I2RS solution would use the same elements, but with a different
control plane. The I2RS enabled control plane could provide the Data
Center 4 tier infrastructure the quick access to topology and data flow
information needed for traffic flow optimization. Changes to the Data
Center infrastructure done via I2RS could have a tight feedback
loop.</t>
<t>Again, this solution would reduce the need for new and specialized
protocols while giving the Data Center the control it desire. The I2RS
routing interface could be extended to virtual routers.</t>
<t>Summary of IRS Capabilities and Interactions:</t>
<t><list style="symbols">
<t>The ability to read the local RIB of each forwarding device,
including the destination prefix (NLRI), a table identifier (if the
forwarding device has multiple forwarding instances), the metric of
each installed route, a route preference, and an identifier
indicating the installing process.</t>
<t>The ability to monitor the available routes installed in the RIB
of each forwarding device, including near real time notification of
route installation and removal. This information must include the
destination prefix (NLRI), a table identifier (if the forwarding
device has multiple forwarding instances), the metric of the
installed route, and an identifier indicating the installing
process.</t>
<t>The ability to install destination based routes in the local RIB
of each forwarding device. This must include the ability to supply
the destination prefix (NLRI), a table identifier (if the forwarding
device has multiple forwarding instances), a route preference, a
route metric, a next hop, an outbound interface, and a route process
identifier.</t>
<t>The ability to read the tables of other local protocol processes
running on the device. This reading action should be supported
through an import/export interface which can present the information
in a consistent manner across all protocol implementations, rather
than using a protocol specific model for each type of available
process.</t>
<t>The ability to inject information directly into the local tables
of other protocol processes running on the forwarding device. This
injection should be supported through an import/export interface
which can inject routing information in a consistent manner across
all protocol implementations, rather than using a protocol specific
model for each type of available process.</t>
<t>The ability to interact with various policies configured on the
forwarding devices, in order to inform the policies implemented by
the dynamic routing processes. This interaction should be through
existing configuration mechanisms, such as NETCONF, and should be
recorded in the configuration of the local device so operators are
aware of the full policy implemented in the network from the running
configuration.</t>
<t>The ability to interact with traffic flow and other network
traffic level measurement protocols and systems, in order to
determine path performance, top talkers, and other information
required to make an informed path decision based on locally
configured policy.</t>
</list></t>
</section>
<section title="Temporary Overlays between Data Centers" toc="default">
<t/>
<t>Data Centers within one organization may operate as one single entity
even though they may be geographically distributed. Applications are
load balanced within Data Centers and between data centers to take
advantage of cost economics in power, storage, and server availability
for compute resources. Applications are also transfer to alternate data
centers in case of failures within a data center. To reduce time during
failure, Data Centers often replicate user storage between two or more
data centers. During the transfer of stored information prior to a Data
Center to Data Center move, the Data Center controllers need to
dynamically acquire a large amount of inter-data center bandwidth
through an overlay network, often during off hours.</t>
<t>I2RS could provide the connection between the overlay network
configuration, local policies, and the control plane to dynamically
bring a large bandwidth inter-data center overlay or channel into use,
and then to remove it from use when the data transfer is completed.</t>
<t>Similarly, during a fail-over, a control process within data centers
interacts with a group host process and the network to seamless move the
processing to another data center. During the fail-over case, additional
process state may need to be moved as well to restart the system. The
difference between these data-to-data center moves is immediate and
urgent need to move systems. If an application (such as medical or
banking services) pays to have this type of fail-over, it is likely the
service will pay for preemption on network bandwidth. I2RS can allow the
Data Center network and the Network connecting the data center to
preempt other best-effort traffic to send this priority data flow. After
the high priority data flow has finished, networks can return to their
previous condition.</t>
<t>Summary of IRS Capabilities and Interactions:</t>
<t><list style="symbols">
<t>The ability to read the local RIB of each forwarding device,
including the destination prefix (NLRI), a table identifier (if the
forwarding device has multiple forwarding instances), the metric of
each installed route, a route preference, and an identifier
indicating the installing process.</t>
<t>The ability to monitor the available routes installed in the RIB
of each forwarding device, including near real time notification of
route installation and removal. This information must include the
destination prefix (NLRI), a table identifier (if the forwarding
device has multiple forwarding instances), the metric of the
installed route, and an identifier indicating the installing
process.</t>
<t>The ability to install destination based routes in the local RIB
of each forwarding device. This must include the ability to supply
the destination prefix (NLRI), a table identifier (if the forwarding
device has multiple forwarding instances), a route preference, a
route metric, a next hop, an outbound interface, and a route process
identifier.</t>
<t>The ability to interact with various policies configured on the
forwarding devices, in order to inform the policies implemented by
the dynamic routing processes. This interaction should be through
existing configuration mechanisms, such as NETCONF, and should be
recorded in the configuration of the local device so operators are
aware of the full policy implemented in the network from the running
configuration.</t>
<t>The ability to interact with policies and configurations on the
forwarding devices using time based processing, either through timed
auto-rollback or some other mechanism. This interaction should be
through existing configuration mechanisms, such as NETCONF, and
should be recorded in the configuration of the local device so
operators are aware of the full policy implemented in the network
from the running configuration.</t>
<t>The ability to interact with traffic flow and other network
traffic level measurement protocols and systems, in order to
determine path performance, top talkers, and other information
required to make an informed path decision based on locally
configured policy.</t>
</list></t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.2119'?>
</references>
<references title="Informative References">
<?rfc include='reference.I-D.lapukhov-bgp-routing-large-dc'?>
<?rfc include='reference.I-D.ward-i2rs-framework'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:18:56 |