One document matched: draft-atlas-i2rs-problem-statement-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 RFC3746 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3746.xml">
<!ENTITY RFC4292 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4292.xml">
<!ENTITY RFC5470 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5470.xml">
<!ENTITY I-D.gredler-idr-ls-distribution SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.gredler-idr-ls-distribution.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="no" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="5"?>
<!-- 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-atlas-i2rs-problem-statement-01"
ipr="trust200902">
<!-- 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>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="I2RS Problem Statement">Interface to the Routing System
Problem Statement</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Alia Atlas" initials="A.K.A." role="editor"
surname="Atlas">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>10 Technology Park Drive</street>
<city>Westford</city>
<region>MA</region>
<code>01886</code>
<country>USA</country>
</postal>
<email>akatlas@juniper.net</email>
</address>
</author>
<author fullname="Thomas D. Nadeau" initials="T.N." surname="Nadeau">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>1194 N. Mathilda Ave.</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>USA</country>
</postal>
<email>tnadeau@juniper.net</email>
</address>
</author>
<author fullname="Dave Ward" initials="D.W." surname="Ward">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>wardd@cisco.com</email>
</address>
</author>
<date year="2013"/>
<!-- If the month and year are both specified and are the current
ones, xml2rfc will fill in the current day for you. If only the
current year is specified, xml2rfc will fill in the current day
and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if
not specified for the purpose of calculating the expiry date).
With drafts it is normally sufficient to specify just the
year. -->
<!-- Meta-data Declarations -->
<area>Routing</area>
<!--
<workgroup>I2RS Working Group</workgroup>
-->
<abstract>
<t>As modern networks grow in scale and complexity, the need for rapid
and dynamic control increases. With scale, the need to automate even the
simplest operations is important, but even more critical is the ability
to quickly interact with more complex operations such as policy-based
controls.</t>
<t>In order to enable applications to have access to and control over
information in the Internet's routing system, we need a publicly
documented interface specification. The interface needs to support
real-time, transaction-based interactions using data models and
encodings that are efficient and potentially different from those
available today. Furthermore, the interface must be tailored to support
a variety of use cases. </t>
<t> This document expands upon these statements of requirements to
provide a detailed problem statement for an Interface to the Internet
Routing System (I2RS).</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>As modern networks grow in scale and complexity, the need for rapid
and dynamic control increases. With scale, the need to automate even the
simplest operations is important, but even more critical is the ability
to quickly interact with more complex operations such as policy-based
controls.</t>
<t>With complexity comes the need for more sophisticated automated
applications and orchestration software that can process large
quantities of data, run complex algorithms, and adjust the routing state
as required in order to support the applications, their calculations and
their policies. Changes made to the routing state of a network by
external applications must be verifiable by those applications to ensure
that the correct state has been installed in the right places.</t>
<t>Mechanisms to support the requirements outlined above have
been developed piecemeal as proprietary solutions to specific
situations and needs. A standard protocol, clearly defined
operations that an application can initiate with that protocol,
and data-models to support such actions would facilitate
wide-scale deployment of interoperable applications and routing
systems. That a protocol designed to facilitate rapid, isolated,
secure, and dynamic routing changes is needed motivates the
creation of an Interface to The Routing System (I2RS).</t>
</section>
<!-- End of Introduction !-->
<section title="I2RS Model and Problem Area for The IETF">
<t>Managing a network of deployed devices running a variety of
routing protocols involves interactions among multiple different
components that exist within the network. Some of these
components are virtual while some are physical; all should be
made available to be managed and manipulated by applications,
given that appropriate access, authentication, and policy
hurdles have been crossed. The management of only some of these
components requires standardization, as others have already been
standardized. The I2RS model is intended to incorporate existing
mechanisms where appropriate, and to build extensions and new
protocols where needed. The I2RS model and problem area proposed
for IETF work is illustrated in <xref target="I2RS_model"/>. The
I2RS Agent is associated with a routing element, which may or
may not be co-located with a data-plane. The I2RS Client is used
and controlled by a network application; they may be co-located
or the I2RS Client might be part of a separate application, such
as an orchestrator or controller.</t>
<figure align="center" anchor="I2RS_model"
title="I2RS model and Problem Area">
<artwork align="center"><![CDATA[
+***************+ +***************+ +***************+
* Application * * Application * * Application *
+***************+ +***************+ +***************+
| I2RS Client | ^ ^
+---------------+ * *
^ * ****************
| * *
| v v
| +---------------+
| | I2RS Client |
| +---------------+
| ^
|________________ |
| | <== I2RS Protocol
| |
...........................|..|..................................
. v v .
. +*************+ +---------------+ +****************+ .
. * Policy * | | * Routing & * .
. * Database *<***>| I2RS Agent |<****>* Signaling * .
. +*************+ | | * Protocols * .
. +---------------+ +****************+ .
. ^ ^ ^ ^ .
. +*************+ * * * * .
. * Topology * * * * * .
. * Database *<*******+ * * v .
. +*************+ * * +****************+ .
. * +********>* RIB Manager * .
. * +****************+ .
. * ^ .
. v * .
. +*******************+ * .
. * Subscription & * * .
. * Configuration * v .
. * Templates for * +****************+ .
. * Measurements, * * FIB Manager * .
. * Events, QoS, etc. * * & Data Plane * .
. +*******************+ +****************+ .
.................................................................
<--> interfaces inside the scope of I2RS
+--+ objects inside the scope of I2RS
<**> interfaces NOT within the scope of I2RS
+**+ objects NOT within the scope of I2RS
.... boundary of a router participating in the I2RS
]]></artwork>
</figure>
<t>A critical aspect of I2RS is defining a suitable protocol or
protocols to carry messages between the I2RS Clients and the I2RS Agent,
and defining the encapsulation of data within those messages. This
should provide a clear transfer syntax that is straightforward for
applications to use (e.g., a Web Services design paradigm), and should
provide the key features specified in <xref
target="sec_i2rs_proto_aspects"/>.</t>
<t>The second critical aspect is semantic-aware data-models for
information in the routing system and in a topology database. The
data-models should be separable across different features of the managed
components, versioned, and combine to provide a network data-model.</t>
</section>
<section title="Standard Data-Models of Routing State for Installation">
<t>There is a need to be able to precisely control routing and
signaling state based upon policy or external measures. This can
range from simple static routes to policy-based routing to
static multicast replication and routing state. This means that,
to usefully model next-hops, the data model employed needs to
handle indirection as well as different types of tunneling and
encapsulation. The relevant MIB modules (for example <xref
target="RFC4292"/>) lack the necessary generality and
flexibility. In addition, by having I2RS focus initially on
interfaces to the RIB layer (e.g. RIB, LFIB, multicast RIB,
policy-based routing), the ability to use routing indirection
allows flexibility and functionality that can't be as easily
obtained at the forwarding layer.</t>
<t>Efforts to provide this level of control have focused on
standardizing data models that describe the forwarding plane (e.g.
ForCES <xref target="RFC3746"/>). I2RS posits that the routing
system and a router's OS provide useful mechanisms that applications
could usefully harness to accomplish application-level goals.</t>
<t>In addition to interfaces to the RIB layer, there is a need to
configure the various routing and signaling protocols with differing
dynamic state based upon application-level policy decisions. The range
desired is not available via MIBs at the present time.</t>
</section>
<section title="Learning Router Information">
<t>A router has information that applications may require so that they
can understand the network, verify that programmed state is installed in
the forwarding plane, measure the behavior of various flows, and
understand the existing configuration and state of the router. I2RS
provides a framework for applications to register for asynchronous
notifications and for them to make specific requests for
information.</t>
<t>Although there are efforts to extend the topological
information available, even the best of these (e.g., BGP-LS
<xref target="I-D.gredler-idr-ls-distribution"/>) still provides
only the current active state as seen at the IGP layer and
above. Detailed topological state that provides more information
than the current functional status is needed by applications;
only the active paths or links are known versus those
potentially available or unknown to the routing topology.</t>
<t>For applications to have a feedback loop that includes awareness of
the relevant traffic, an application must be able to request the
measurement and timely, scalable reporting of data. While a mechanism
such as IPFIX <xref target="RFC5470"/> may be the facilitator for
delivering the data, the need for an application to be able to
dynamically request that measurements be taken and data delivered is
critical.</t>
<t>There are a wide range of events that applications could use
for either verification of router state before other network
state is changed (e.g. that a route has been installed), to act
upon changes to relevant routes by others, or upon router events
(e.g. link up/down). While a few of these (e.g. link up/down)
may be available via MIB Notifications today, the full range is
not - nor is there the standardized ability to set up the router
to trigger different actions upon an event's occurrence.</t>
</section>
<section anchor="sec_i2rs_proto_aspects"
title="Desired Aspects of a Protocol for I2RS">
<t>This section describes required aspects of a protocol that could
support I2RS. Whether such a protocol is built upon extending existing
mechanisms or requires a new mechanism requires further
investigation.</t>
<t>The key aspects needed in an interface to the routing system are:</t>
<t><list style="hanging">
<t hangText="Multiple Simultaneous Asynchronous Operations: ">A
single application should be able to send multiple operations to
I2RS without needing to wait for each to complete before sending the
next.</t>
<t
hangText="Very Fine Granularity of Data Locking for Writing: ">When
an I2RS operation is processed, it is required that the data locked
for writing is very granular (e.g. a particular prefix and route)
rather than extremely coarse, as is done for writing configuration.
This should improve the number of concurrent I2RS operations that
are feasible and reduce blocking delays.</t>
<t hangText="Multi-Headed Control: ">Multiple applications may
communicate to the same I2RS agent in a minimally coordinated
fashion. It is necessary that the I2RS agent can handle multiple
conflicting requests in a well-known policy-based fashion. Data
written can be owned by different I2RS clients.</t>
<t hangText="Duplex: ">Communications can be established by either
the router or the application. Similarly, events, acknowledgements,
failures, operations, etc. can be sent at any time by both the
router and the application. The I2RS is not a pure pull-model where
only the application queries to pull responses.</t>
<t hangText="High-Throughput: ">At a minimum, the I2RS Agent and
associated router should be able to handle hundreds of simple
operations per second.</t>
<t hangText="Responsive: ">It should be possible to complete simple
operations within a sub-second time-scale.</t>
<t hangText="Multi-Channel: ">It should be possible for information
to be communicated via the interface from different components in
the router without requiring going through a single channel. For
example, for scaling, some exported data or events may be better
sent directly from the forwarding plane, while other interactions
may come from the control-plane. Thus a single TCP session would not
be a good match.</t>
<t hangText="Temporal State for Installation and Expiration:
">The ability to have state installed with different
lifetimes and different start-times is very valuable. In
particular, the ability of an I2RS client to request that a
pre-sent operation be started based upon a dynamic event
would provide a powerful functionality.</t>
<t hangText="Scalable, Filterable Information Access:">To
extract information in a scalable fashion that is more
easily used by applications, the ability to specify
filtering constructs in an operation requesting data or
requesting an asynchronous notification is very
valuable.</t> </list></t>
</section>
<section title="Existing Management Interfaces">
<t>This section discusses as a single entity the combination of
the abstract data models, their representation in a data
language, and the transfer protocol commonly used with
them. While other combinations are possible, the ways
described are those that have significant deployment.</t>
<t>There are three basic ways that routers are managed. The most popular
is the command line interface (CLI), which allows both configuration and
learning of device state. This is a proprietary interface resembling a
UNIX shell that allows for very customized control and observation of a
device, and, specifically of interest in this case, its routing system.
Some form of this interface exists on almost every device (virtual or
otherwise). Processing of information returned to the CLI (called
"screen scraping") is a burdensome activity because the data is normally
formatted for use by a human operator, and because the layout of the
data can vary from device to device, and between different software
versions. Despite its ubiquity, this interface has never been
standardized and is unlikely to ever be standardized. I2RS does not
involve CLI standardization.</t>
<t>The second most popular interface for interrogation of a device's
state, statistics, and configuration is The Simple Network Management
Protocol (SNMP) and a set of relevant standards-based and proprietary
Management Information Base (MIB) modules. SNMP has a strong history of
being used by network managers to gather statistical and state
information about devices, including their routing systems. However,
SNMP is very rarely used to configure a device or any of its systems for
reasons that vary depending upon the network operator. Some example
reasons include complexity, the lack of desired configuration semantics
(e.g., configuration "roll-back", "sandboxing" or configuration
versioning), and the difficulty of using the semantics (or lack thereof)
as defined in the MIB modules to configure device features. Therefore,
SNMP is not considered as a candidate solution for the problems
motivating I2RS.</t>
<t>Finally, the IETF's Network Configuration (or NetConf) protocol has
made many strides at overcoming most of the limitations around
configuration that were just described. However, the lack of standard
data models have hampered the adoption of NetConf. Naturally, I2RS may
help define needed information and data models. Additional extensions to
handle multi-headed control and time-based state installation and
expiration may need to be added to NetConf and/or appropriate data
models.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thank Ken Gray for his suggestions and
review.</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This document includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>Security is a key aspect of any protocol that allows state
installation and extracting of detailed router state. More investigation
remains to fully define the security requirements, such as authorization
and authentication levels.</t>
</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">
</references>
-->
<references title="Informative References">
&RFC3746;
&RFC4292;
&RFC5470;
&I-D.gredler-idr-ls-distribution;
</references>
<!-- Change Log
v00 2012-07-11 AKA Initial version
v01 2013-02-05 AKA Minor updates - change to I2RS
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 10:03:23 |