draft-ietf-i2rs-problem-statement-06.txt   draft-ietf-i2rs-problem-statement-07.txt 
Network Working Group A. Atlas, Ed. Network Working Group A. Atlas, Ed.
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Informational T. Nadeau, Ed. Intended status: Informational T. Nadeau, Ed.
Expires: July 11, 2015 Brocade Expires: June 19, 2016 Brocade
D. Ward D. Ward
Cisco Systems Cisco Systems
January 7, 2015 December 17, 2015
Interface to the Routing System Problem Statement Interface to the Routing System Problem Statement
draft-ietf-i2rs-problem-statement-06 draft-ietf-i2rs-problem-statement-07
Abstract Abstract
As modern networks grow in scale and complexity, the need for rapid Traditionally, routing systems have implemented routing and signaling
and dynamic control increases. With scale, the need to automate even (e.g. MPLS) to control traffic forwarding in a network. Route
the simplest operations is important, but even more critical is the computation has been controlled by relatively static policies that
ability to quickly interact with more complex operations such as define link cost, route cost, or import and export routing policies.
policy-based controls. With the advent of highly dynamic data center networking, on-demand
WAN services, dynamic policy-driven traffic steering and service
In order to enable network applications to have access to and control chaining, the need for real-time security threat responsiveness via
over information in the Internet's routing system, we need a publicly traffic control, and a paradigm of separating policy-based decision-
documented interface specification. The interface needs to support making from the router itself, the need has emerged to more
real-time, asynchronous interactions using data models and encodings dynamicaly manage and program routing systems in order to control
that are efficient and potentially different from those available routing information and traffic paths and to extract network topology
today. Furthermore, the interface must be tailored to support a information, traffic statistics, and other network analytics from
variety of use cases. routing systems.
This document expands upon these statements of requirements to This document proposes meeting this need via an Interface to the
provide a detailed problem statement for an Interface to the Routing Routing System (I2RS).
System (I2RS).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 11, 2015. This Internet-Draft will expire on June 19, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. I2RS Model and Problem Area for The IETF . . . . . . . . . . 3 2. I2RS Model and Problem Area for The IETF . . . . . . . . . . 3
3. Standard Data-Models of Routing State for Installation . . . 5 3. Standard Data-Models of Routing State for Installation . . . 6
4. Learning Router Information . . . . . . . . . . . . . . . . . 6 4. Learning Router Information . . . . . . . . . . . . . . . . . 6
5. Aspects to be Considered for an I2RS Protocol . . . . . . . . 7 5. Aspects to be Considered for an I2RS Protocol . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. Informative References . . . . . . . . . . . . . . . . . . . 9 9. Informative References . . . . . . . . . . . . . . . . . . . 9
Appendix A. Existing Management Interfaces . . . . . . . . . . . 9 Appendix A. Existing Management Interfaces . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
As modern networks grow in scale and complexity, the need for rapid, Traditionally, routing systems have implemented routing and signaling
flexible and dynamic control increases. (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
chainging, the need for rea-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
dynamicaly 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.
With scale, the need to automate even the simplest operation is As modern network continue to grow in scale and complexity and
important, but even more critical is the ability for network desired policy has become more complex and dynamic, there is a need
operators to quickly interact with these operations using mechanisms to support rapid control and analytics. The scale of modern networks
such as policy-based controls. 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.
With complexity comes the need for more sophisticated automated In order to enable network applications to have access to and control
network applications and orchestration software that can process over information in the Internet's routing system, a publicly
large quantities of data, run complex algorithms, and adjust the documented interface is required. The interface needs to support
routing state as required in order to support the network real-time, asynchronous interactions using efficient data models and
applications, their computations and their policies. Changes made to encodings that could extend on those previously defined.
the routing state of a network by external applications must be Furthermore, the interface must be tailored to provide a solid base
verifiable by those applications to ensure that the correct state has on which a variety of use cases can be supported.
been installed in the correct places.
In the past, mechanisms to support the requirements outlined above To support the requirements of orchestration software and automated
have been developed piecemeal as proprietary solutions to specific network applications to dynamically modify the network, there is a
situations and needs. Many routing elements have an external need to learn topology, networka analytics, and existing state from
interface to interact with routing - but since these vary between the network as well as to create or modify routing information and
vendors, it is difficult to integrate use of those interfaces into a network paths. A feedback loop is needed so that changes made can be
network. The existence of such proprietary interfaces demonstrates verifiable and so that these applications can learn and react to
both that the need for such an interface is understood and that network changes.
technology solutions are understood. What is needed are
technological solutions with clearly defined operations that an Proprietary solutions to partially support the requirements outlined
application can initiate, and data-models to support such actions. above have been developed to handle specific situations and needs.
These would facilitate wide-scale deployment of interoperable Standardizing an interface to the routing system will makae it easier
applications and routing systems. These solutions must be designed to integrate use of it into a network. Because there are proprietary
to facilitate rapid, isolated, secure, and dynamic changes to a partial solutions, the standardization of a common interface should
device's routing system. In order to address these needs, the be feasible.
creation of an Interface to the Routing System (I2RS) is needed.
It should be noted that during the course of this document, the term It should be noted that during the course of this document, the term
"applications" is used. This is meant to refer to an executable "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 program of some sort that has access to a network, such as an IP or
MPLS network. MPLS network.
2. I2RS Model and Problem Area for The IETF 2. I2RS Model and Problem Area for The IETF
Managing a network of production devices running a variety of routing Managing a network of systems running a variety of routing protocols
protocols involves interactions between multiple components within a and/or providing one or more additional service (e.g., forwarding,
device. Some of these components are virtual while some are classification and policing, firewalling) involves interactions
physical; it may be desirable for many, or even all of these between multiple components within these systems. Some of these
components to be made available to be managed and manipulated by systems or system components may be virtualized, colocqted within the
applications, given that appropriate access, authentication, and same physical system or distributed. In all cases, it is desirable
policy hurdles have been crossed. The management of only some of to enable network applications to manage and control the services
these components require standardization, as others have already been provided by many, if not all, of these components, subject to
standardized. The I2RS model is intended to incorporate existing authenticated and authorized access and policies.
mechanisms where appropriate, and to build extensions and new
protocols where needed. The I2RS model and problem area for IETF A data-model driven interfase to the routing system is needed. This
work is illustrated in Figure 1. The I2RS Agent is associated with a will allow expansion of what information can be read and controlled
and allow for future flexiblity. 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.
The I2RS model and problem area for IETF work is illustrated in
Figure 1. This document uses terminology defined in
[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- 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 plane. The I2RS Client could be integrated in a network application
applications; they may be co-located or the I2RS Client might be part or controlled and used by one or more separate network applications.
of a separate application, such as an orchestrator or controller. For instance, an I2RS Client could be provided by a network
The scope of the data-models used by I2RS extends across the entire controller or a network orchestration system that provides a non-I2RS
routing system and I2RS protocol. 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.
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)
for I2RS extend between the I2RS client and I2RS Agent. All other
objects and interfaces in Figure 1 are outside the I2RS scope for
standardization.
+***************+ +***************+ +***************+ +***************+ +***************+ +***************+
* Application * * Application * * Application * * Application * * Application * * Application *
+***************+ +***************+ +***************+ +***************+ +***************+ +***************+
| I2RS Client | ^ ^ | I2RS Client | ^ ^
+---------------+ * * +---------------+ * *
^ * **************** ^ * ****************
| * * | * *
| v v | v v
| +---------------+ +-------------+ | +---------------+ +-------------+
skipping to change at page 5, line 5 skipping to change at page 5, line 34
<--> 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
.... 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
A critical aspect of I2RS is defining a suitable protocol or The I2RS Working Group must select the suitable protocol(s) to carry
protocols to carry messages between the I2RS Clients and the I2RS messages between the I2RS Clients and I2RS Agent. The protocol
Agent, and defining the data-models for use with those I2RS should provide the key features specified in Section 5.
protocol(s). The protocol should provide the key features specified
in Section 5. 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.
The second critical aspect of I2RS is a set of meaningful data-models The I2RS Working Group must identify or define is a set of meaningful
for information in the routing system and in a topology database. data-models for information in the routing system and in a topology
The data-model should describe the meaning and relationships of the database. The data-model should describe the meaning and
modeled items. The data-models should be separable across different relationships of the modeled items. The data-models should be
features of the managed components, versioned, and extendable. As separable across different features of the managed components,
shown in Figure 1, I2RS needs to interact with several logical versioned, and extendable. As shown in Figure 1, I2RS needs to
components of the routing element: policy database, topology interact with several logical components of the routing element:
database, subscription and configuration for dynamic measurements/ policy database, topology database, subscription and configuration
events, routing signaling protocols, and its RIB manager. This for dynamic measurements/events, routing signaling protocols, and its
interaction is both for writing (e.g. to policy databases or RIB RIB manager. This interaction is both for writing (e.g. to policy
manager) as well as for reading (e.g. dynamic measurement or topology databases or RIB manager) as well as for reading (e.g. dynamic
database). An application should be able to combine data from measurement or topology database). An application should be able to
individual routing elements to provide network-wide data-model(s). combine data from individual routing elements to provide network-wide
data-model(s).
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.
3. Standard Data-Models of Routing State for Installation 3. Standard Data-Models of Routing State for Installation
There is a need to be able to precisely control routing and signaling As described in Section 1, there is a need to be able to precisely
state based upon policy or external measures. This can range from control routing and signaling state based upon policy or external
simple static routes to policy-based routing to static multicast measures. One set of data-models that I2RS should focus on is for
replication and routing state. This means that, to usefully model interacting with the RIB layer (e.g. RIB, LIB, multicast RIB,
next-hops, the data model employed needs to handle next-hop policy-based routing) to provide flexibility and routing
indirection and recursion (e.g. a prefix X is routed like prefix Y) abstractions. As an example, the desired routing and signaling state
as well as different types of tunneling and encapsulation. The might range from simple static routes to policy-based routing to
relevant MIB modules (for example [RFC4292]) lack the necessary static multicast replication and routing state. This means that, to
generality and flexibility. In addition, by having I2RS focus usefully model next-hops, the data model employed needs to handle
initially on interfaces to the RIB layer (e.g. RIB, LIB, multicast next-hop indirection and recursion (e.g. a prefix X is routed like
RIB, policy-based routing), the ability to use routing indirection prefix Y) as well as different types of tunneling and encapsulation.
allows flexibility and functionality that can't be as easily obtained
at the forwarding layer.
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 posits that the routing system and a ForCES [RFC3746]). I2RS recognizes that the routing system and a
router's OS provide useful mechanisms that applications could router's OS provide useful mechanisms that applications could
usefully harness to accomplish application-level goals. 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.
In addition to interfaces to the RIB layer, there is a need to In addition to interfaces to the RIB layer, there is a need to
configure the various routing and signaling protocols with differing dynamically configure policies and values for parameters for the
dynamic state based upon application-level policy decisions. The various routing and signaling protocols based upon application-level
range desired is not available via MIB modules at the present time. policy decisions.
Additionally, on March 2, 2014, the IESG issued a statement about
Writeable MIB Modules [IESG-Statement] which is expected to limit
creation of future writeable MIB modules.
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 installed can understand the network, verify that programmed state is
in the forwarding plane, measure the behavior of various flows, and installed, measure the behavior of various flows, and understand the
understand the existing configuration and state of the router. I2RS existing configuration and state of the router. I2RS should provide
provides a framework so that applications can register for a framework so that applications can register for asynchronous
asynchronous notifications and can make specific requests for notifications and can make specific requests for information.
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
[I-D.ietf-idr-ls-distribution]) still provide only the current active [I-D.ietf-idr-ls-distribution]) still provide only the current active
state as seen at the IGP layer and above. Detailed topological state state as seen at the IGP and BGP layers. Detailed topological state
that provides more information than the current functional status that provides more information than the current functional status
(e.g. active paths and links) is needed by applications. Examples of (e.g. active paths and links) is needed by applications. Examples of
missing information include paths or link that are potentially missing information include paths or link that are potentially
available (e.g. administratively down) or unknown (e.g. to peers or available (e.g. administratively down) 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 IPFIX [RFC5470] may be the facilitator for
delivering the data, the need for an application to be able to delivering the data, providing the ability for an application to
dynamically request that measurements be taken and data delivered is dynamically request that measurements be taken and data delivered is
critical. important.
There are a wide range of events that applications could use for There are a wide range of events that applications could use for
either verification of router state before other network state is either 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), to act upon changes
to relevant routes by others, or upon router events (e.g. link up/ 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 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 MIB notifications today, the full range is not (e.g. route-installed,
successfully deployed the standardized ability to set up the router route-changed, primary LSP changed, etc.)
to trigger different actions upon an event's occurrence so that a
rapid reaction can be accomplished.
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:
skipping to change at page 7, line 42 skipping to change at page 8, line 21
should be handled are described in [I-D.ietf-i2rs-architecture]. should be handled are described in [I-D.ietf-i2rs-architecture].
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, within the I2RS scope, the I2RS
should be able to handle a considerable number of operations per Agent and associated router should be able to handle a
second (for example 10,000 per second to handle many individual considerable number of operations per second (for example 10,000
subscriber routes changing simultaneously). per second to handle many individual subscriber routes changing
simultaneously).
Low-Latency: Within a sub-second time-scale, it should be possible Low-Latency: Within a sub-second time-scale, 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 Multi-Channel: 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. Thus a single TCP session would may come from the control-plane.
not be a good match.
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 may also need to be provided via secure access routing information may also 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. Some communications will also require confidentiality. protected. Some communications will also require confidentiality.
Extensible and Interoperability: Both the I2RS protocol and models Extensible and Interoperability: Both the I2RS protocol and models
must be extensible and interoperate between different versions of must be extensible and interoperate between different versions of
protocols and models. protocols and models.
6. Acknowledgements 6. Acknowledgements
The authors would like to thank Ken Gray, Ed Crabbe, Nic Leymann, The authors would like to thank Ken Gray, Ed Crabbe, Nic Leymann,
Carlos Pignataro, Kwang-koog Lee, Linda Dunbar, Sue Hares, Russ Carlos Pignataro, Kwang-koog Lee, Linda Dunbar, Sue Hares, Russ
Housley, Eric Grey, Qin Wu, and Stephen Kent for their suggestions Housley, Eric Grey, Qin Wu, Stephen Kent, Nabil Bitar, Deborah
and review. Brungard, and Sarah Banks for their suggestions and review.
7. IANA Considerations 7. IANA Considerations
This document includes no request to IANA. This document includes no request to IANA.
8. Security Considerations 8. 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
[I-D.ietf-i2rs-architecture]. Briefly, the I2RS Agent is assumed to [I-D.ietf-i2rs-architecture]. Briefly, the I2RS Agent is assumed to
have a separate authentication and authorization channel by which it have a separate authentication and authorization channel by which it
can validate both the identity and the permissions associated with an can validate both the identity and the permissions associated with an
I2RS Client. Mutual authentication between the I2RS Agent and I2RS I2RS Client. Mutual authentication between the I2RS Agent and I2RS
Client is required. Different levels of integrity, confidentiality, Client is required. Different levels of integrity, confidentiality,
and replay protection are relevant for different aspects of I2RS. and replay protection are relevant for different aspects of I2RS.
9. Informative References 9. Informative References
[I-D.ietf-i2rs-architecture] [I-D.ietf-i2rs-architecture]
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-07 (work in System", draft-ietf-i2rs-architecture-11 (work in
progress), December 2014. progress), December 2015.
[I-D.ietf-idr-ls-distribution] [I-D.ietf-idr-ls-distribution]
Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. Gredler, H., Medved, J., Previdi, S., Farrel, A., and S.
Ray, "North-Bound Distribution of Link-State and TE Ray, "North-Bound Distribution of Link-State and TE
Information using BGP", draft-ietf-idr-ls-distribution-07 Information using BGP", draft-ietf-idr-ls-distribution-13
(work in progress), November 2014. (work in progress), October 2015.
[IESG-Statement]
IESG, "Writable MIB Module IESG Statement", March 2014,
<https://www.ietf.org/iesg/statement/writable-mib-
module.html>.
[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, April 2004. Framework", RFC 3746, DOI 10.17487/RFC3746, April 2004,
<http://www.rfc-editor.org/info/rfc3746>.
[RFC4292] Haberman, B., "IP Forwarding Table MIB", RFC 4292, April [RFC4292] Haberman, B., "IP Forwarding Table MIB", RFC 4292,
2006. 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,
March 2009. DOI 10.17487/RFC5470, March 2009,
<http://www.rfc-editor.org/info/rfc5470>.
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 those 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
skipping to change at page 10, line 10 skipping to change at page 10, line 34
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 "roll-back", "sandboxing" or
configuration versioning), and the difficulty of using the semantics configuration versioning), and the difficulty of using the semantics
(or lack thereof) as defined in the MIB modules to configure device (or lack thereof) as defined in the MIB modules to configure device
features. Therefore, SNMP is not considered as a candidate solution features. Therefore, SNMP is not considered as a candidate solution
for the problems motivating I2RS. for the problems motivating I2RS.
Finally, the IETF's Network Configuration (or NETCONF) protocol has Finally, the IETF's Network Configuration (or NETCONF) protocol has
made many strides at overcoming most of the limitations around made many strides at overcoming most of the limitations around
configuration that were just described. However, the initial lack of configuration that were just described. However, the initial lack of
standard data models have hampered the adoption of NETCONF. standard data models have hampered the adoption of NETCONF. I2RS
Naturally, I2RS may help define needed information and data models. will define needed information and data models to support I2RS
Additional extensions to handle multi-headed control may need to be applications. Additional extensions to handle multi-headed control
added to NETCONF and/or appropriate data models. may need to be added to NETCONF and/or appropriate data models.
Authors' Addresses Authors' Addresses
Alia Atlas (editor) Alia Atlas (editor)
Juniper Networks Juniper Networks
10 Technology Park Drive
Westford, MA 01886
USA
Email: akatlas@juniper.net Email: akatlas@juniper.net
Thomas D. Nadeau (editor) Thomas D. Nadeau (editor)
Brocade Brocade
Email: tnadeau@lucidvision.com Email: tnadeau@lucidvision.com
Dave Ward Dave Ward
Cisco Systems Cisco Systems
Tasman Drive
San Jose, CA 95134
USA
Email: wardd@cisco.com Email: wardd@cisco.com
 End of changes. 40 change blocks. 
162 lines changed or deleted 182 lines changed or added

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