One document matched: draft-ietf-i2rs-problem-statement-10.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-10"
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>
<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>
<email>wardd@cisco.com</email>
</address>
</author>
<date year="2016"/>
<!-- 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>Traditionally, routing systems have implemented routing and
signaling (e.g. MPLS) to control traffic forwarding in a network.
Route computation has been controlled by relatively static
policies that define link cost, route cost, or import and export
routing policies. With the advent of highly dynamic data center
networking, on-demand WAN services, dynamic policy-driven traffic
steering and service chaining, the need for real-time security
threat responsiveness via traffic control, and a paradigm of
separating policy-based decision-making from the router itself,
the need has emerged to more dynamically manage and program
routing systems in order to control routing information and
traffic paths and to extract network topology information,
traffic statistics, and other network analytics from routing
systems.</t>
<t>This document proposes meeting this need via an Interface to
the Routing System (I2RS).</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>Traditionally, routing systems have implemented routing and
signaling (e.g. MPLS) to control traffic forwarding in a network.
Route computation has been controlled by relatively static
policies that define link cost, route cost, or import and export
routing policies. With the advent of highly dynamic data center
networking, on-demand WAN services, dynamic policy-driven traffic
steering and service chaining, the need for real-time security
threat responsiveness via traffic control, and a paradigm of
separating policy-based decision-making from the router itself,
the need has emerged to more dynamically manage and program
routing systems in order to control routing information and
traffic paths and to extract network topology information,
traffic statistics, and other network analytics from routing
systems.</t>
<t>As modern networks continue to grow in scale and complexity and
desired policy has become more complex and dynamic, there is a
need to support rapid control and analytics. The scale of modern
networks and data-centers and the associated operational expense
drives the need to automate even the simplest operations. The
ability to quickly interact via more complex operations to
support dynamic policy is even more critical.</t>
<t>In order to enable network applications to have access to and
control over information in the different vendors' routing systems, a
publicly documented interface is required. The interface needs to
support real-time, asynchronous interactions using efficient data
models and encodings that are based on and extend those previously
defined. Furthermore, the interface must be tailored to provide
a solid base on which a variety of use cases can be
supported.</t>
<t>To support the requirements of orchestration software and
automated network applications to dynamically modify the network,
there is a need to learn topology, network analytics, and
existing state from the network as well as to create or modify
routing information and network paths. A feedback loop is needed
so that changes made can be verifiable and so that these
applications can learn and react to network changes.</t>
<t>Proprietary solutions to partially support the requirements
outlined above have been developed to handle specific situations
and needs. Standardizing an interface to the routing system will
make it easier to integrate use of it into a network. Because
there are proprietary partial solutions already, the
standardization of a common interface should be feasible.</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, via a routing system.</t>
</section>
<!-- End of Introduction !-->
<section title="I2RS Model and Problem Area for the IETF">
<t>Managing a network of systems running a variety of routing
protocols and/or providing one or more additional services (e.g.,
forwarding, classification and policing, firewalling) involves
interactions between multiple components within these
systems. Some of these systems or system components may be
virtualized, colocated within the same physical system or
distributed. In all cases, it is desirable to enable network
applications to manage and control the services provided by many,
if not all, of these components, subject to authenticated and
authorized access and policies.</t>
<t>A data-model driven interface to the routing system is needed.
This will allow expansion of what information can be read and
controlled and allow for future flexibility. At least one
accompanying protocol with clearly defined operations is needed;
the suitable protocol(s) can be identified and expanded to
support the requirements of an Interface to the Routing System
(I2RS). These solutions must be designed to facilitate rapid,
isolated, secure, and dynamic changes to a device's routing
system. These would facilitate wide-scale deployment of
interoperable applications and routing systems. </t>
<t> The I2RS model and problem area for IETF work is illustrated
in <xref target="I2RS_model"/>. This document uses terminology
defined in <xref target="I-D.ietf-i2rs-architecture"/>. The I2RS
Agent is associated with a routing element, which may or may not
be co-located with a data-plane. The I2RS Client could be
integrated in a network application or controlled and used by one
or more separate network applications. For instance, an I2RS
Client could be provided by a network controller or a network
orchestration system that provides a non-I2RS interface to
network applications and an I2RS interface to I2RS Agents on the
systems being managed. The scope of the data-models used by I2RS
extends across the entire routing system and the selected
protocol(s) for I2RS.</t>
<t>As depicted in <xref target="I2RS_model"/>, the I2RS Client
and I2RS Agent in a routing system are objects with in the I2RS
scope. The selected protocol(s) for I2RS extend between the I2RS
client and I2RS Agent. All other objects and interfaces in <xref
target="I2RS_model"/> are outside the I2RS scope for
standardization.</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
<== used to point to the interface where the I2RS Protocol
would be used
.... boundary of a router supporting I2RS
]]></artwork>
</figure>
<t>The I2RS Working Group must select the suitable protocol(s)
to carry messages between the I2RS Clients and I2RS Agent. The
protocol should provide the key features specified in <xref
target="sec_i2rs_proto_aspects"/>.</t>
<t>The I2RS Working Group must identify or define 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>
<t>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>
</section>
<section title="Standard Data-Models of Routing State for Installation">
<t>As described in <xref target="intro"/>, there is a need to be
able to precisely control routing and signaling state based upon
policy or external measures. One set of data-models that I2RS
should focus on is for interacting with the RIB layer (e.g. RIB,
LIB, multicast RIB, policy-based routing) to provide flexibility
and routing abstractions. As an example, the desired routing
and signaling state might 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. </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 recognizes that
the routing system and a router's OS provide useful mechanisms
that applications could usefully harness to accomplish
application-level goals. Using routing indirection, recursion
and common routing abstractions (e.g. tunnels, LSPs, etc.)
provides significant flexibility and functionality over
collapsing the state to individual routes in the FIB that need
to be individually modified when a change occurs.</t>
<t>In addition to interfaces to control the RIB layer, there is
a need to dynamically configure policies and parameter values
for the various routing and signaling protocols based upon
application-level policy decisions.</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, measure the behavior of various flows, and
understand the existing configuration and state of the
router. I2RS should provide 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 only
provide the current active state as seen at the IGP and BGP
layers. 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, providing the
ability for an application to dynamically request that
measurements be taken and data delivered is important.</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 (e.g. route-installed, route-changed, primary LSP changed,
etc.)</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, within the
I2RS scope, 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. One channel, with authorization and
authentication, may be considered primary; only an
authorized client can then request that information be
delivered on a different channel. Writes from a client are
only expected on channels that provide authorization and
authentication.</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, Stephen Kent, Nabil
Bitar, Deborah Brungard, and Sarah Banks 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">
&I-D.ietf-i2rs-architecture;
</references>
<references title="Informative References">
&RFC3746;
&RFC4292;
&RFC5470;
&I-D.ietf-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. 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, as a new technology and with the initial
lack of standard data models, the adoption of NETCONF has been
slow. I2RS will define needed information and data models to
support I2RS applications. 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
v06 2015-10-29 AKA Improved based on reviews (Nabil, Deborah, Sarah Banks)
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 04:27:35 |