One document matched: draft-atlas-i2rs-problem-statement-02.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-02"
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" role="editor">
<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 network 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, asynchronous 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
Routing System (I2RS).</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>As modern networks grow in scale and complexity, the need for rapid,
flexible and dynamic control increases. With scale, the need to automate
even the simplest operation is important, but even more critical is the
ability for network operators to quickly interact with these operations
using mechanisms such as policy-based controls.</t>
<t>With complexity comes the need for more sophisticated
automated network 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
network applications, their computations 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
correct places.</t>
<t>In the past, mechanisms to support the requirements outlined above
have been developed piecemeal as proprietary solutions to specific
situations and needs. Many routing elements have an external interface
to interact with routing - but since these vary between vendors, it is
difficult to integrate use of those interfaces into a network. The
existence of such proprietary interfaces demonstrates both that the need
for such an interface is understood and that technology solutions are
understood. What is needed are technological solutions with clearly
defined operations that an application can initiate, and data-models to
support such actions. These would facilitate wide-scale deployment of
interoperable applications and routing systems. These solutions must be
designed to facilitate rapid, isolated, secure, and dynamic changes to a
device's routing system. In order to address these needs, the creation
of an Interface to the Routing System (I2RS) is needed.</t>
<t>It should be noted that during the course of this document, we will
discuss and use the term "applications". This is meant to refer to an
executable program of some sort that has access to a network, such as an
IP network.</t>
</section>
<!-- End of Introduction !-->
<section title="I2RS Model and Problem Area for The IETF">
<t>Managing a network of production devices running a variety of routing
protocols involves interactions with an between multiple components
within a device. Some of these components are virtual while some are
physical; it may be desirable for many, or even all of these components
to 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 require
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 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 one or more network applications; 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 |<------->| Other I2RS |
| +---------------+ | Agents |
| ^ +-------------+
|________________ |
| | <== 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 data-models for use with those I2RS protocol(s). The
data models should translate into 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"/>. The information should use existing
transport protocols to provide the reliability, security, and timeliness
appropriate for the particular data.</t>
<t>The second critical aspect are semantic-aware data-models for
information in the routing system and in a topology database. The
data-model should describe the meaning and relationships of the modeled
items. The data-models should be separable across different features of
the managed components, versioned, and extendable. An application should
be able to combine data from individual routing elements to provide
network-wide data-model(s).</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 next-hop indirection and recursion (e.g. a prefix X is
routed like prefix Y) 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, LIB, 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 so that applications can register for asynchronous
notifications and can 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 provide 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 (e.g.
administratively down) or unknown (e.g. to peers or customers) 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 so that a rapid reaction can be
accomplished.</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 via
I2RS without being required 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
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 I2RS client (i.e.: that resides within the application or is
used by it to communicate with the I2RS agent), or the I2RS agent.
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 a considerable number of
operations per second above what basic Netconf or a propretiary CLI
can.</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="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>
<t hangText="Secure Control: ">Any ability to manipulate routing
state must be subject to authentication and authorization. Such
communications must also have its integrity protected.</t>
<t hangText="Extensible and Interoperability: ">Both the I2RS
protocol and models must be extensible and interoperate between
different versions of protocols and models.</t>
</list></t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thank Ken Gray, Ed Crabbe, Nic
Leymann, Carlos Pignataro, and Kwang-koog Lee for their
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>
<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 of
these existing standard technologies 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 may need to be added to NetConf and/or
appropriate data models.</t>
</section>
<!-- Change Log
v00 2012-07-11 AKA Initial version
v01 2013-02-05 AKA Minor updates - change to I2RS
Planned changes for next time:
"not only the automation should be mentioned but also the fact that it
is necessary to be able to react on external triggers (as fast as
possible and only for a certain/short period of time). There are
scenarios - e.g. if a network node or customers are attacked - where
you want to redirect the traffic using an I2RS interface without
changing the full routing within you network (only the necessary
modifications are enabled by using I2RS). This might also be valid for
LI scenarios." from Nic Leymann at DT
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 10:03:24 |