draft-ietf-i2rs-problem-statement-11.txt   rfc7920.txt 
Network Working Group A. Atlas, Ed. Internet Engineering Task Force (IETF) A. Atlas, Ed.
Internet-Draft Juniper Networks Request for Comments: 7920 Juniper Networks
Intended status: Informational T. Nadeau, Ed. Category: Informational T. Nadeau, Ed.
Expires: November 11, 2016 Brocade ISSN: 2070-1721 Brocade
D. Ward D. Ward
Cisco Systems Cisco Systems
May 10, 2016 June 2016
Interface to the Routing System Problem Statement Problem Statement for the Interface to the Routing System
draft-ietf-i2rs-problem-statement-11
Abstract Abstract
Traditionally, routing systems have implemented routing and signaling Traditionally, routing systems have implemented routing and signaling
(e.g. MPLS) to control traffic forwarding in a network. Route (e.g., MPLS) to control traffic forwarding in a network. Route
computation has been controlled by relatively static policies that computation has been controlled by relatively static policies that
define link cost, route cost, or import and export routing policies. define link cost, route cost, or import and export routing policies.
With the advent of highly dynamic data center networking, on-demand Requirements have emerged to more dynamically manage and program
WAN services, dynamic policy-driven traffic steering and service routing systems due to the advent of highly dynamic data-center
chaining, the need for real-time security threat responsiveness via networking, on-demand WAN services, dynamic policy-driven traffic
traffic control, and a paradigm of separating policy-based decision- steering and service chaining, the need for real-time security threat
making from the router itself, requirements have emerged to more responsiveness via traffic control, and a paradigm of separating
dynamically manage and program routing systems. These requirements policy-based decision-making from the router itself. These
should allow controlling routing information and traffic paths and requirements should allow controlling routing information and traffic
extracting network topology information, traffic statistics, and paths and extracting network topology information, traffic
other network analytics from routing systems. statistics, and other network analytics from routing systems.
This document proposes meeting this need via an Interface to the This document proposes meeting this need via an Interface to the
Routing System (I2RS). Routing System (I2RS).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on November 11, 2016. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7920.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction ....................................................3
2. I2RS Model and Problem Area for the IETF . . . . . . . . . . 3 2. I2RS Model and Problem Area for the IETF ........................4
3. Standard Data-Models of Routing State for Installation . . . 6 3. Standard Data Models of Routing State for Installation ..........6
4. Learning Router Information . . . . . . . . . . . . . . . . . 6 4. Learning Router Information .....................................7
5. Aspects to be Considered for an I2RS Protocol . . . . . . . . 7 5. Aspects to be Considered for an I2RS Protocol ...................8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations .........................................9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. References .....................................................10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References ......................................10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.2. Informative References ....................................10
9.1. Normative References . . . . . . . . . . . . . . . . . . 9 Appendix A. Existing Management Interfaces .......................11
9.2. Informative References . . . . . . . . . . . . . . . . . 9 Acknowledgements ..................................................12
Appendix A. Existing Management Interfaces . . . . . . . . . . . 10 Authors' Addresses ................................................12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
Traditionally, routing systems have implemented routing and signaling Traditionally, routing systems have implemented routing and signaling
(e.g. MPLS) to control traffic forwarding in a network. Route (e.g., MPLS) to control traffic forwarding in a network. Route
computation has been controlled by relatively static policies that computation has been controlled by relatively static policies that
define link cost, route cost, or import and export routing policies. define link cost, route cost, or import and export routing policies.
With the advent of highly dynamic data center networking, on-demand The advent of highly dynamic data-center networking, on-demand WAN
WAN services, dynamic policy-driven traffic steering and service services, dynamic policy-driven traffic steering and service
chaining, the need for real-time security threat responsiveness via chaining, the need for real-time security threat responsiveness via
traffic control, and a paradigm of separating policy-based decision- traffic control, and a paradigm of separating policy-based decision-
making from the router itself, the need has emerged to more making from the router itself has created the need to more
dynamically manage and program routing systems in order to control dynamically manage and program routing systems in order to control
routing information and traffic paths and to extract network topology routing information and traffic paths and to extract network topology
information, traffic statistics, and other network analytics from information, traffic statistics, and other network analytics from
routing systems. routing systems.
As modern networks continue to grow in scale and complexity and As modern networks continue to grow in scale and complexity and
desired policy has become more complex and dynamic, there is a need desired policy has become more complex and dynamic, there is a need
to support rapid control and analytics. The scale of modern networks to support rapid control and analytics. The scale of modern networks
and data-centers and the associated operational expense drives the and data centers and the associated operational expense drives the
need to automate even the simplest operations. The ability to need to automate even the simplest operations. The ability to
quickly interact via more complex operations to support dynamic quickly interact via more complex operations to support dynamic
policy is even more critical. policy is even more critical.
In order to enable network applications to have access to and control In order to enable network applications to have access to and control
over information in the different vendors' routing systems, a over information in the different vendors' routing systems, a
publicly documented interface is required. The interface needs to publicly documented interface is required. The interface needs to
support real-time, asynchronous interactions using efficient data support real-time, asynchronous interactions using efficient data
models and encodings that are based on and extend those previously models and encodings that are based on and extend those previously
defined. Furthermore, the interface must be tailored to provide a defined. Furthermore, the interface must be tailored to provide a
skipping to change at page 3, line 48 skipping to change at page 4, line 17
program of some sort that has access to a network, such as an IP or program of some sort that has access to a network, such as an IP or
MPLS network, via a routing system. MPLS network, via a routing system.
2. I2RS Model and Problem Area for the IETF 2. I2RS Model and Problem Area for the IETF
Managing a network of systems running a variety of routing protocols Managing a network of systems running a variety of routing protocols
and/or providing one or more additional services (e.g., forwarding, and/or providing one or more additional services (e.g., forwarding,
classification and policing, firewalling) involves interactions classification and policing, firewalling) involves interactions
between multiple components within these systems. Some of these between multiple components within these systems. Some of these
systems or system components may be virtualized, co-located within systems or system components may be virtualized, co-located within
the same physical system or distributed. In all cases, it is the same physical system, or distributed. In all cases, it is
desirable to enable network applications to manage and control the desirable to enable network applications to manage and control the
services provided by many, if not all, of these components, subject services provided by many, if not all, of these components, subject
to authenticated and authorized access and policies. to authenticated and authorized access and policies.
A data-model driven interface to the routing system is needed. This A data-model-driven interface to the routing system is needed. This
will allow expansion of what information can be read and controlled will allow expansion of what information can be read and controlled
and allow for future flexibility. At least one accompanying protocol and allow for future flexibility. At least one accompanying protocol
with clearly defined operations is needed; the suitable protocol(s) with clearly defined operations is needed; the suitable protocol(s)
can be identified and expanded to support the requirements of an can be identified and expanded to support the requirements of an
Interface to the Routing System (I2RS). These solutions must be Interface to the Routing System (I2RS). These solutions must be
designed to facilitate rapid, isolated, secure, and dynamic changes designed to facilitate rapid, isolated, secure, and dynamic changes
to a device's routing system. These would facilitate wide-scale to a device's routing system. These would facilitate wide-scale
deployment of interoperable applications and routing systems. deployment of interoperable applications and routing systems.
The I2RS model and problem area for IETF work is illustrated in The I2RS model and problem area for IETF work is illustrated in
Figure 1. This document uses terminology defined in Figure 1. This document uses terminology defined in [RFC7921]. The
[I-D.ietf-i2rs-architecture]. The I2RS Agent is associated with a I2RS agent is associated with a routing element, which may or may not
routing element, which may or may not be co-located with a data- be co-located with a data plane. The I2RS client could be integrated
plane. The I2RS Client could be integrated in a network application in a network application or controlled and used by one or more
or controlled and used by one or more separate network applications. separate network applications. For instance, an I2RS client could be
For instance, an I2RS Client could be provided by a network provided by a network controller or a network orchestration system
controller or a network orchestration system that provides a non-I2RS that provides a non-I2RS interface to network applications and an
interface to network applications and an I2RS interface to I2RS I2RS interface to I2RS agents on the systems being managed. The
Agents on the systems being managed. The scope of the data-models scope of the data models used by I2RS extends across the entire
used by I2RS extends across the entire routing system and the routing system and the selected protocol(s) for I2RS.
selected protocol(s) for I2RS.
As depicted in Figure 1, the I2RS Client and I2RS Agent in a routing As depicted in Figure 1, the I2RS client and I2RS agent in a routing
system are objects with in the I2RS scope. The selected protocol(s) system are objects with in the I2RS scope. The selected protocol(s)
for I2RS extend between the I2RS client and I2RS Agent. All other for I2RS extend between the I2RS client and I2RS agent. All other
objects and interfaces in Figure 1 are outside the I2RS scope for objects and interfaces in Figure 1 are outside the I2RS scope for
standardization. standardization.
+***************+ +***************+ +***************+ +***************+ +***************+ +***************+
* Application * * Application * * Application * * Application * * Application * * Application *
+***************+ +***************+ +***************+ +***************+ +***************+ +***************+
| I2RS Client | ^ ^ | I2RS Client | ^ ^
+---------------+ * * +---------------+ * *
^ * **************** ^ * ****************
| * * | * *
skipping to change at page 5, line 28 skipping to change at page 6, line 6
. +*******************+ * . . +*******************+ * .
. * Subscription & * * . . * Subscription & * * .
. * Configuration * v . . * Configuration * v .
. * Templates for * +****************+ . . * Templates for * +****************+ .
. * Measurements, * * FIB Manager * . . * Measurements, * * FIB Manager * .
. * Events, QoS, etc. * * & Data Plane * . . * Events, QoS, etc. * * & Data Plane * .
. +*******************+ +****************+ . . +*******************+ +****************+ .
................................................................. .................................................................
<--> interfaces inside the scope of I2RS Protocol <--> interfaces inside the scope of I2RS Protocol
+--+ objects inside the scope of I2RS-defined behavior +--+ objects inside the scope of I2RS-defined behavior
<**> interfaces NOT within the scope of I2RS Protocol <**> interfaces NOT within the scope of I2RS Protocol
+**+ objects NOT within the scope of I2RS-defined behavior +**+ objects NOT within the scope of I2RS-defined behavior
<== used to point to the interface where the I2RS Protocol <== used to point to the interface where the I2RS Protocol
would be used would be used
.... boundary of a router supporting I2RS .... boundary of a router supporting I2RS
Figure 1: I2RS model and Problem Area Figure 1: I2RS Model and Problem Area
The protocol(s) used to carry messages between I2RS Clients and I2RS The protocol(s) used to carry messages between I2RS clients and I2RS
Agents should provide the key features specified in Section 5. agents should provide the key features specified in Section 5.
I2RS will use a set of meaningful data-models for information in the I2RS will use a set of meaningful data models for information in the
routing system and in a topology database. Each data-model should routing system and in a topology database. Each data model should
describe the meaning and relationships of the modeled items. The describe the meaning and relationships of the modeled items. The
data-models should be separable across different features of the data models should be separable across different features of the
managed components, versioned, and extendable. As shown in Figure 1, managed components, versioned, and extendable. As shown in Figure 1,
I2RS needs to interact with several logical components of the routing I2RS needs to interact with several logical components of the routing
element: policy database, topology database, subscription and element: policy database, topology database, subscription and
configuration for dynamic measurements/events, routing signaling configuration for dynamic measurements/events, routing and signaling
protocols, and its RIB manager. This interaction is both for writing protocols, and its Routing Information Base (RIB) manager. This
(e.g. to policy databases or RIB manager) as well as for reading interaction is both for writing (e.g., to policy databases or RIB
(e.g. dynamic measurement or topology database). An application manager) as well as for reading (e.g., dynamic measurement or
should be able to combine data from individual routing elements to topology database). An application should be able to combine data
provide network-wide data-model(s). from individual routing elements to provide network-wide data
model(s).
The data models should translate into a concise transfer syntax, sent The data models should translate into a concise transfer syntax, sent
via the I2RS protocol, that is straightforward for applications to via the I2RS protocol, that is straightforward for applications to
use (e.g., a Web Services design paradigm). The information transfer use (e.g., a web services design paradigm). The information transfer
should use existing transport protocols to provide the reliability, should use existing transport protocols to provide the reliability,
security, and timeliness appropriate for the particular data. security, and timeliness appropriate for the particular data.
3. Standard Data-Models of Routing State for Installation 3. Standard Data Models of Routing State for Installation
As described in Section 1, there is a need to be able to precisely As described in Section 1, there is a need to be able to precisely
control routing and signaling state based upon policy or external control routing and signaling state based upon policy or external
measures. One set of data-models that I2RS should focus on is for measures. One set of data models that I2RS should focus on is for
interacting with the RIB layer (e.g. RIB, LIB, multicast RIB, interacting with the RIB layer (e.g., RIB, Label Information Base
policy-based routing) to provide flexibility and routing (LIB), multicast RIB, policy-based routing) to provide flexibility
abstractions. As an example, the desired routing and signaling state and routing abstractions. As an example, the desired routing and
might range from simple static routes to policy-based routing to signaling state might range from simple static routes to policy-based
static multicast replication and routing state. This means that, to routing to static multicast replication and routing state. This
usefully model next-hops, the data model employed needs to handle means that, to usefully model next hops, the data model employed
next-hop indirection and recursion (e.g. a prefix X is routed like needs to handle next-hop indirection and recursion (e.g., a prefix X
prefix Y) as well as different types of tunneling and encapsulation. is routed like prefix Y) as well as different types of tunneling and
encapsulation.
Efforts to provide this level of control have focused on Efforts to provide this level of control have focused on
standardizing data models that describe the forwarding plane (e.g. standardizing data models that describe the forwarding plane (e.g.,
ForCES [RFC3746]). I2RS recognizes that the routing system and a Forwarding and Control Element Separation (ForCES) [RFC3746]). I2RS
router's OS provide useful mechanisms that applications could recognizes that the routing system and a router's OS provide useful
usefully harness to accomplish application-level goals. Using mechanisms that applications could usefully harness to accomplish
routing indirection, recursion and common routing abstractions (e.g. application-level goals. Using routing indirection, recursion, and
tunnels, LSPs, etc.) provides significant flexibility and common routing abstractions (e.g., tunnels, Label Switched Paths
functionality over collapsing the state to individual routes in the (LSPs), etc.) provides significant flexibility and functionality over
FIB that need to be individually modified when a change occurs. collapsing the state to individual routes in the Forwarding
Information Base (FIB) that need to be individually modified when a
change occurs.
In addition to interfaces to control the RIB layer, there is a need In addition to interfaces to control the RIB layer, there is a need
to dynamically configure policies and parameter values for the to dynamically configure policies and parameter values for the
various routing and signaling protocols based upon application-level various routing and signaling protocols based upon application-level
policy decisions. policy decisions.
4. Learning Router Information 4. Learning Router Information
A router has information that applications may require so that they A router has information that applications may require so that they
can understand the network, verify that programmed state is can understand the network, verify that programmed state is
installed, measure the behavior of various flows, and understand the installed, measure the behavior of various flows, and understand the
existing configuration and state of the router. I2RS should provide existing configuration and state of the router. I2RS should provide
a framework so that applications can register for asynchronous a framework so that applications can register for asynchronous
notifications and can make specific requests for information. notifications and can make specific requests for information.
Although there are efforts to extend the topological information Although there are efforts to extend the topological information
available, even the best of these (e.g., BGP-LS available, even the best of these (e.g., BGP-LS [RFC7752]) still only
[I-D.ietf-idr-ls-distribution]) still only provide the current active provide the current active state as seen at the IGP and BGP layers.
state as seen at the IGP and BGP layers. Detailed topological state Detailed topological state that provides more information than the
that provides more information than the current functional status current functional status (e.g., active paths and links) is needed by
(e.g. active paths and links) is needed by applications. Examples of applications. Examples of missing information include paths or links
missing information include paths or link that are potentially that are potentially available (e.g., administratively down) or
available (e.g. administratively down) or unknown (e.g. to peers or unknown (e.g., to peers or customers) to the routing topology.
customers) to the routing topology.
For applications to have a feedback loop that includes awareness of For applications to have a feedback loop that includes awareness of
the relevant traffic, an application must be able to request the the relevant traffic, an application must be able to request the
measurement and timely, scalable reporting of data. While a measurement and timely, scalable reporting of data. While a
mechanism such as IPFIX [RFC5470] may be the facilitator for mechanism such as IP Flow Information Export (IPFIX) [RFC5470] may be
delivering the data, providing the ability for an application to the facilitator for delivering the data, providing the ability for an
dynamically request that measurements be taken and data delivered is application to dynamically request that measurements be taken and
important. data delivered is important.
There are a wide range of events that applications could use for There is a wide range of events that applications could use to
either verification of router state before other network state is support verification of router state before other network state is
changed (e.g. that a route has been installed), to act upon changes changed (e.g., that a route has been installed) and to allow timely
to relevant routes by others, or upon router events (e.g. link up/ action in response to changes of relevant routes by others or to
down). While a few of these (e.g. link up/down) may be available via router events (e.g., link up/down). While a few of these (e.g., link
MIB notifications today, the full range is not (e.g. route-installed, up/down) may be available via MIB notifications today, the full range
route-changed, primary LSP changed, etc.) is not (e.g., route installed, route changed, primary LSP changed,
etc.)
5. Aspects to be Considered for an I2RS Protocol 5. Aspects to be Considered for an I2RS Protocol
This section describes required aspects of a protocol that could This section describes required aspects of a protocol that could
support I2RS. Whether such a protocol is built upon extending support I2RS. Whether such a protocol is built upon extending
existing mechanisms or requires a new mechanism requires further existing mechanisms or requires a new mechanism requires further
investigation. investigation.
The key aspects needed in an interface to the routing system are: The key aspects needed in an interface to the routing system are:
Multiple Simultaneous Asynchronous Operations: A single application Multiple Simultaneous Asynchronous Operations: A single application
should be able to send multiple independent atomic operations via should be able to send multiple independent atomic operations via
I2RS without being required to wait for each to complete before I2RS without being required to wait for each to complete before
sending the next. sending the next.
Very Fine Granularity of Data Locking for Writing: When an I2RS Very Fine Granularity of Data Locking for Writing: When an I2RS
operation is processed, it is required that the data locked for operation is processed, it is required that the data locked for
writing is very granular (e.g. a particular prefix and route) writing be very granular (e.g., a particular prefix and route)
rather than extremely coarse, as is done for writing rather than extremely coarse, as is done for writing
configuration. This should improve the number of concurrent I2RS configuration. This should improve the number of concurrent I2RS
operations that are feasible and reduce blocking delays. operations that are feasible and reduce blocking delays.
Multi-Headed Control: Multiple applications may communicate to the Multi-Headed Control: Multiple applications may communicate to the
same I2RS Agent in a minimally coordinated fashion. It is same I2RS agent in a minimally coordinated fashion. It is
necessary that the I2RS Agent can handle multiple requests in a necessary that the I2RS agent can handle multiple requests in a
well-known policy-based fashion. Data written can be owned by well-known policy-based fashion. Data written can be owned by
different I2RS Clients at different times; data may even be different I2RS clients at different times; data may even be
overwritten by a different I2RS Client. The details of how this overwritten by a different I2RS client. The details of how this
should be handled are described in [I-D.ietf-i2rs-architecture]. should be handled are described in [RFC7921].
Duplex: Communications can be established by either the I2RS Client Duplex: Communications can be established by either the I2RS client
(i.e., that resides within the application or is used by it to (i.e., that resides within the application or is used by it to
communicate with the I2RS Agent), or the I2RS Agent. Similarly, communicate with the I2RS agent) or the I2RS agent. Similarly,
events, acknowledgements, failures, operations, etc. can be sent events, acknowledgements, failures, operations, etc., can be sent
at any time by both the router and the application. The I2RS is 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 not a pure pull model where only the application queries to pull
responses. responses.
High-Throughput: At a minimum, the I2RS Agent and associated router High Throughput: At a minimum, the I2RS agent and associated router
should be able to handle a considerable number of operations per should be able to handle a considerable number of operations per
second (for example 10,000 per second to handle many individual second (for example, 10,000 per second to handle many individual
subscriber routes changing simultaneously). subscriber routes changing simultaneously).
Low-Latency: Within a sub-second time-scale, it should be possible Low Latency: Within a sub-second timescale, it should be possible
to complete simple operations (e.g. reading or writing a single to complete simple operations (e.g., reading or writing a single
prefix route). prefix route).
Multi-Channel: It should be possible for information to be Multiple Channels: It should be possible for information to be
communicated via the interface from different components in the communicated via the interface from different components in the
router without requiring going through a single channel. For router without requiring going through a single channel. For
example, for scaling, some exported data or events may be better example, for scaling, some exported data or events may be better
sent directly from the forwarding plane, while other interactions sent directly from the forwarding plane, while other interactions
may come from the control-plane. One channel, with authorization may come from the control plane. One channel, with authorization
and authentication, may be considered primary; only an authorized and authentication, may be considered primary; only an authorized
client can then request that information be delivered on a client can then request that information be delivered on a
different channel. Writes from a client are only expected on different channel. Writes from a client are only expected on
channels that provide authorization and authentication. channels that provide authorization and authentication.
Scalable, Filterable Information Access: To extract information in a Scalable, Filterable Information Access: To extract information in a
scalable fashion that is more easily used by applications, the scalable fashion that is more easily used by applications, the
ability to specify filtering constructs in an operation requesting ability to specify filtering constructs in an operation requesting
data or requesting an asynchronous notification is very valuable. data or requesting an asynchronous notification is very valuable.
Secure Control and Access: Any ability to manipulate routing state Secure Control and Access: Any ability to manipulate routing state
must be subject to authentication and authorization. Sensitive must be subject to authentication and authorization. Sensitive
routing information also may need to be provided via secure access routing information also may need to be provided via secure access
back to the I2RS Client. Such communications must be integrity back to the I2RS client. Such communications must be integrity
protected. Most communications will also require confidentiality. protected. Most communications will also require confidentiality.
Extensible and Interoperability: Both the I2RS protocol and models Extensibility and Interoperability: Both the I2RS protocol and
must be extensible and interoperate between different versions of models must be extensible and interoperate between different
protocols and models. versions of protocols and models.
6. Acknowledgements
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.
7. IANA Considerations
This document includes no request to IANA.
8. Security Considerations 6. Security Considerations
Security is a key aspect of any protocol that allows state Security is a key aspect of any protocol that allows state
installation and extracting of detailed router state. The need for installation and extracting of detailed router state. The need for
secure control and access is mentioned in Section 5. More secure control and access is mentioned in Section 5. More
architectural security considerations are discussed in architectural security considerations are discussed in [RFC7921].
[I-D.ietf-i2rs-architecture]. Briefly, the I2RS Agent is assumed to Briefly, the I2RS agent is assumed to have a separate authentication
have a separate authentication and authorization channel by which it and authorization channel by which it can validate both the identity
can validate both the identity and the permissions associated with an and the permissions associated with an I2RS client. Mutual
I2RS Client. Mutual authentication between the I2RS Agent and I2RS authentication between the I2RS agent and I2RS client is required.
Client is required. Different levels of integrity, confidentiality, Different levels of integrity, confidentiality, and replay protection
and replay protection are relevant for different aspects of I2RS. are relevant for different aspects of I2RS.
9. References 7. References
9.1. Normative References 7.1. Normative References
[I-D.ietf-i2rs-architecture] [RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
Nadeau, "An Architecture for the Interface to the Routing Nadeau, "An Architecture for the Interface to the Routing
System", draft-ietf-i2rs-architecture-15 (work in System", RFC 7921, DOI 10.17487/RFC7921, June 2016,
progress), April 2016. <http://www.rfc-editor.org/info/rfc7921>.
9.2. Informative References
[I-D.ietf-idr-ls-distribution] 7.2. Informative References
Gredler, H., Medved, J., Previdi, S., Farrel, A., and S.
Ray, "North-Bound Distribution of Link-State and TE
Information using BGP", draft-ietf-idr-ls-distribution-13
(work in progress), October 2015.
[RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal,
"Forwarding and Control Element Separation (ForCES) "Forwarding and Control Element Separation (ForCES)
Framework", RFC 3746, DOI 10.17487/RFC3746, April 2004, Framework", RFC 3746, DOI 10.17487/RFC3746, April 2004,
<http://www.rfc-editor.org/info/rfc3746>. <http://www.rfc-editor.org/info/rfc3746>.
[RFC4292] Haberman, B., "IP Forwarding Table MIB", RFC 4292,
DOI 10.17487/RFC4292, April 2006,
<http://www.rfc-editor.org/info/rfc4292>.
[RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek,
"Architecture for IP Flow Information Export", RFC 5470, "Architecture for IP Flow Information Export", RFC 5470,
DOI 10.17487/RFC5470, March 2009, DOI 10.17487/RFC5470, March 2009,
<http://www.rfc-editor.org/info/rfc5470>. <http://www.rfc-editor.org/info/rfc5470>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<http://www.rfc-editor.org/info/rfc6241>.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
S. Ray, "North-Bound Distribution of Link-State and
Traffic Engineering (TE) Information Using BGP", RFC 7752,
DOI 10.17487/RFC7752, March 2016,
<http://www.rfc-editor.org/info/rfc7752>.
Appendix A. Existing Management Interfaces Appendix A. Existing Management Interfaces
This section discusses as a single entity the combination of the This section discusses as a single entity the combination of the
abstract data models, their representation in a data language, and abstract data models, their representation in a data language, and
the transfer protocol commonly used with them. While other the transfer protocol commonly used with them. While other
combinations of these existing standard technologies are possible, combinations of these existing standard technologies are possible,
the ways described are those that have significant deployment. the ways described are ones that have significant deployment.
There are three basic ways that routers are managed. The most There are three basic ways that routers are managed. The most
popular is the command line interface (CLI), which allows both popular is the command-line interface (CLI), which allows both
configuration and learning of device state. This is a proprietary configuration and learning of device state. This is a proprietary
interface resembling a UNIX shell that allows for very customized interface resembling a UNIX shell that allows for very customized
control and observation of a device, and, specifically of interest in control and observation of a device, and, specifically of interest in
this case, its routing system. Some form of this interface exists on this case, its routing system. Some form of this interface exists on
almost every device (virtual or otherwise). Processing of almost every device (virtual or otherwise). Processing of
information returned to the CLI (called "screen scraping") is a information returned to the CLI (called "screen scraping") is a
burdensome activity because the data is normally formatted for use by burdensome activity because the data is normally formatted for use by
a human operator, and because the layout of the data can vary from a human operator and because the layout of the data can vary from
device to device, and between different software versions. Despite device to device and between different software versions. Despite
its ubiquity, this interface has never been standardized and is its ubiquity, this interface has never been standardized and is
unlikely to ever be standardized. CLI standardization is not unlikely to ever be standardized. CLI standardization is not
considered as a candidate solution for the problems motivating I2RS. considered as a candidate solution for the problems motivating I2RS.
The second most popular interface for interrogation of a device's The second most popular interface for interrogation of a device's
state, statistics, and configuration is the Simple Network Management state, statistics, and configuration is the Simple Network Management
Protocol (SNMP) and a set of relevant standards-based and proprietary Protocol (SNMP) and a set of relevant standards-based and proprietary
Management Information Base (MIB) modules. SNMP has a strong history Management Information Base (MIB) modules. SNMP has a strong history
of being used by network managers to gather statistical and state of being used by network managers to gather statistical and state
information about devices, including their routing systems. However, information about devices, including their routing systems. However,
SNMP is very rarely used to configure a device or any of its systems SNMP is very rarely used to configure a device or any of its systems
for reasons that vary depending upon the network operator. Some for reasons that vary depending upon the network operator. Some
example reasons include complexity, the lack of desired configuration example reasons include complexity, the lack of desired configuration
semantics (e.g., configuration "roll-back", "sandboxing" or semantics (e.g., configuration rollback, sandboxing, or configuration
configuration versioning), and the difficulty of using the semantics versioning) and the difficulty of using the semantics (or lack
(or lack thereof) as defined in the MIB modules to configure device thereof) as defined in the MIB modules to configure device features.
features. Therefore, SNMP is not considered as a candidate solution Therefore, SNMP is not considered as a candidate solution for the
for the problems motivating I2RS. problems motivating I2RS.
Finally, the IETF's Network Configuration (or NETCONF) protocol has Finally, the IETF's Network Configuration Protocol (NETCONF)
made many strides at overcoming most of the limitations around [RFC6241] has made many strides at overcoming most of the limitations
configuration that were just described. However, as a new technology around configuration that were just described. However, as a new
and with the initial lack of standard data models, the adoption of technology and with the initial lack of standard data models, the
NETCONF has been slow. I2RS will identify and define as needed adoption of NETCONF has been slow. As needed, I2RS will identify and
information and data models to support I2RS applications. Additional define information and data models to support I2RS applications.
extensions to handle multi-headed control may need to be added to Additional extensions to handle multi-headed control may need to be
NETCONF and/or appropriate data models. added to NETCONF and/or appropriate data models.
Acknowledgements
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.
Authors' Addresses Authors' Addresses
Alia Atlas (editor) Alia Atlas (editor)
Juniper Networks Juniper Networks
Email: akatlas@juniper.net Email: akatlas@juniper.net
Thomas D. Nadeau (editor) Thomas D. Nadeau (editor)
Brocade Brocade
 End of changes. 59 change blocks. 
185 lines changed or deleted 183 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/