One document matched: draft-ietf-i2rs-problem-statement-05.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.ietf-idr-ls-distribution SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-idr-ls-distribution.xml">
<!ENTITY I-D.ietf-i2rs-architecture SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-architecture.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-ietf-i2rs-problem-statement-05"
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>Brocade</organization>
<address>
<email>tnadeau@lucidvision.com</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="2015"/>
<!-- 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,
the term "applications" is used. This is meant to refer to an
executable program of some sort that has access to a network,
such as an IP or MPLS 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 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. The scope
of the data-models used by I2RS extends across the entire
routing system and I2RS protocol.</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 Protocol
+--+ objects inside the scope of I2RS-defined behavior
<**> interfaces NOT within the scope of I2RS Protocol
+**+ objects NOT within the scope of I2RS-defined behavior
.... boundary of a router supporting 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 protocol should provide the key features
specified in <xref target="sec_i2rs_proto_aspects"/>. The data
models should translate into a concise transfer syntax, sent via
the I2RS protocol, that is straightforward for applications to
use (e.g., a Web Services design paradigm). The information
transfer should use existing transport protocols to provide the
reliability, security, and timeliness appropriate for the
particular data.</t>
<t>The second critical aspect of I2RS is a set of meaningful
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. As shown in <xref
target="I2RS_model"/>, I2RS needs to interact with several
logical components of the routing element: policy database,
topology database, subscription and configuration for dynamic
measurements/events, routing signaling protocols, and its RIB
manager. This interaction is both for writing (e.g. to policy
databases or RIB manager) as well as for reading (e.g. dynamic
measurement or topology database). 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 MIB modules at
the present time. Additionally, on March 2, 2014, the IESG
issued a statement about Writeable MIB Modules <xref target="IESG-Statement"/>
which is expected
to limit creation of future writeable MIB modules.</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.ietf-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 (e.g. active paths and links)
is needed by applications. Examples of missing information
include paths or link that are 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 has there been successfully deployed 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="Aspects to be Considered for an I2RS Protocol">
<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 independent atomic
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 at different times; data may even
be overwritten by a different I2RS client. The details of how this
should be handled are described in <xref target="I-D.ietf-i2rs-architecture"/>.
</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 (for example
10,000 per second to handle many individual subscriber
routes changing simultaneously).</t>
<t hangText="Low-Latency: ">Within a sub-second time-scale,
it should be possible to complete simple operations
(e.g. reading or writing a single prefix route).</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 and Access: ">Any ability to
manipulate routing state must be subject to authentication and
authorization. Sensitive routing information may also need to
be provided via secure access back to the I2RS client. Such
communications must be integrity protected. Some communications
will also require confidentiality.</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, Kwang-koog Lee, Linda Dunbar, Sue
Hares, Russ Housley, Eric Grey, Qin Wu, and Stephen Kent 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. The need
for secure control and access is mentioned in <xref
target="sec_i2rs_proto_aspects"/> More architectural security
considerations are discussed in <xref
target="I-D.ietf-i2rs-architecture"/>. Briefly, the I2RS Agent
is assumed to have a separate authentication and authorization
channel by which it can validate both the identity and the
permissions associated with an I2RS Client. Mutual
authentication between the I2RS Agent and I2RS Client is
required. Different levels of integrity, confidentiality, and
replay protection are relevant for different aspects of
I2RS.</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.ietf-idr-ls-distribution;
&I-D.ietf-i2rs-architecture;
<reference anchor="IESG-Statement"
target="https://www.ietf.org/iesg/statement/writable-mib-module.html">
<front>
<title>Writable MIB Module IESG Statement</title>
<author>
<organization>IESG</organization>
</author>
<date month="March" day="2" year= "2014"/>
</front>
</reference>
</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. CLI standardization is not considered as
a candidate solution for the problems motivating I2RS.</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 initial 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 04:27:35 |