draft-ietf-i2rs-problem-statement-04.txt   draft-ietf-i2rs-problem-statement-05.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: December 25, 2014 Brocade Expires: July 10, 2015 Brocade
D. Ward D. Ward
Cisco Systems Cisco Systems
June 23, 2014 January 6, 2015
Interface to the Routing System Problem Statement Interface to the Routing System Problem Statement
draft-ietf-i2rs-problem-statement-04 draft-ietf-i2rs-problem-statement-05
Abstract Abstract
As modern networks grow in scale and complexity, the need for rapid As modern networks grow in scale and complexity, the need for rapid
and dynamic control increases. With scale, the need to automate even and dynamic control increases. With scale, the need to automate even
the simplest operations is important, but even more critical is the the simplest operations is important, but even more critical is the
ability to quickly interact with more complex operations such as ability to quickly interact with more complex operations such as
policy-based controls. policy-based controls.
In order to enable network applications to have access to and control In order to enable network applications to have access to and control
skipping to change at page 1, line 49 skipping to change at page 1, line 49
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 December 25, 2014. This Internet-Draft will expire on July 10, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 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 . . . 5
4. Learning Router Information . . . . . . . . . . . . . . . . . 6 4. Learning Router Information . . . . . . . . . . . . . . . . . 6
5. Desired Aspects of a Protocol for I2RS . . . . . . . . . . . 6 5. Aspects to be Considered for an I2RS Protocol . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. Informative References . . . . . . . . . . . . . . . . . . . 8 9. Informative References . . . . . . . . . . . . . . . . . . . 8
Appendix A. Existing Management Interfaces . . . . . . . . . . . 9 Appendix A. Existing Management Interfaces . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
As modern networks grow in scale and complexity, the need for rapid, As modern networks grow in scale and complexity, the need for rapid,
skipping to change at page 5, line 6 skipping to change at page 5, line 6
.... 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 A critical aspect of I2RS is defining a suitable protocol or
protocols to carry messages between the I2RS Clients and the I2RS protocols to carry messages between the I2RS Clients and the I2RS
Agent, and defining the data-models for use with those I2RS Agent, and defining the data-models for use with those I2RS
protocol(s). The protocol should provide the key features specified protocol(s). The protocol should provide the key features specified
in Section 5. The data models should translate into a concise in Section 5. The data models should translate into a concise
transfer syntax that is straightforward for applications to use transfer syntax, sent via the I2RS protocol, that is straightforward
(e.g., a Web Services design paradigm). The information transfer for applications to use (e.g., a Web Services design paradigm). The
should use existing transport protocols to provide the reliability, information transfer should use existing transport protocols to
security, and timeliness appropriate for the particular data. provide the reliability, security, and timeliness appropriate for the
particular data.
The second critical aspect are meaningful data-models for information The second critical aspect of I2RS is a set of meaningful data-models
in the routing system and in a topology database. The data-model for information in the routing system and in a topology database.
should describe the meaning and relationships of the modeled items. The data-model should describe the meaning and relationships of the
The data-models should be separable across different features of the modeled items. The data-models should be separable across different
managed components, versioned, and extendable. As shown in Figure 1, features of the managed components, versioned, and extendable. As
I2RS needs to interact with several logical components of the routing shown in Figure 1, I2RS needs to interact with several logical
element: policy database, topology database, subscription and components of the routing element: policy database, topology
configuration for dynamic measuresments/events, routing signaling database, subscription and configuration for dynamic measurements/
protocols, and its RIB manager. This interaction is both for writing events, routing signaling protocols, and its 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 topology
should be able to combine data from individual routing elements to database). An application should be able to combine data from
provide network-wide data-model(s). individual routing elements to provide network-wide data-model(s).
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 There is a need to be able to precisely control routing and signaling
state based upon policy or external measures. This can range from state based upon policy or external measures. This can range from
simple static routes to policy-based routing to static multicast simple static routes to policy-based routing to static multicast
replication and routing state. This means that, to usefully model replication and routing state. This means that, to usefully model
next-hops, the data model employed needs to handle next-hop next-hops, the data model employed needs to handle next-hop
indirection and recursion (e.g. a prefix X is routed like prefix Y) indirection and recursion (e.g. a prefix X is routed like prefix Y)
as well as different types of tunneling and encapsulation. The as well as different types of tunneling and encapsulation. The
skipping to change at page 5, line 51 skipping to change at page 6, line 4
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 posits 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.
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 configure the various routing and signaling protocols with differing
dynamic state based upon application-level policy decisions. The dynamic state based upon application-level policy decisions. The
range desired is not available via MIB modules at the present time. range desired is not available via MIB modules at the present time.
Additionally, on March 2, 2014, the IESG issued a statement about Additionally, on March 2, 2014, the IESG issued a statement about
Writeable MIB Modules which is expected to limit creation of future Writeable MIB Modules [IESG-Statement] which is expected to limit
writeable MIB modules. 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 installed
in the forwarding plane, measure the behavior of various flows, and in the forwarding plane, measure the behavior of various flows, and
understand the existing configuration and state of the router. I2RS understand the existing configuration and state of the router. I2RS
provides a framework so that applications can register for provides a framework so that applications can register for
asynchronous notifications and can make specific requests for asynchronous 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.gredler-idr-ls-distribution]) still provide only the current [I-D.ietf-idr-ls-distribution]) still provide only the current active
active state as seen at the IGP layer and above. Detailed state as seen at the IGP layer and above. Detailed topological state
topological state that provides more information than the current that provides more information than the current functional status
functional status is needed by applications; only the active paths or (e.g. active paths and links) is needed by applications. Examples of
links are known versus those potentially available (e.g. missing information include paths or link that are potentially
administratively down) or unknown (e.g. to peers or customers) to the available (e.g. administratively down) or unknown (e.g. to peers or
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, the need for an application to be able to
dynamically request that measurements be taken and data delivered is dynamically request that measurements be taken and data delivered is
critical. critical.
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 - nor has there been
successfully deployed the standardized ability to set up the router successfully deployed the standardized ability to set up the router
to trigger different actions upon an event's occurrence so that a to trigger different actions upon an event's occurrence so that a
rapid reaction can be accomplished. rapid reaction can be accomplished.
5. Desired Aspects of a Protocol for I2RS 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
skipping to change at page 7, line 23 skipping to change at page 7, line 23
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 is 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. 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 [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, the I2RS Agent and associated router
skipping to change at page 8, line 7 skipping to change at page 8, line 10
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. Thus a single TCP session would
not be a good match. 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: Any ability to manipulate routing state must be Secure Control and Access: Any ability to manipulate routing state
subject to authentication and authorization. Such communications must be subject to authentication and authorization. Sensitive
must also have its integrity protected. 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.
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, and Sue Hares for Carlos Pignataro, Kwang-koog Lee, Linda Dunbar, Sue Hares, Russ
their suggestions and review. Housley, Eric Grey, Qin Wu, and Stephen Kent 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. More installation and extracting of detailed router state. The need for
investigation remains to fully define the security requirements, such secure control and access is mentioned in Section 5 More
as authorization and authentication levels. architectural security considerations are discussed in
[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.
9. Informative References 9. Informative References
[I-D.gredler-idr-ls-distribution] [I-D.ietf-i2rs-architecture]
Gredler, H., Medved, J., Previdi, S., and A. Farrel, Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
"North-Bound Distribution of Link-State and TE Information Nadeau, "An Architecture for the Interface to the Routing
using BGP", draft-gredler-idr-ls-distribution-02 (work in System", draft-ietf-i2rs-architecture-07 (work in
progress), July 2012. progress), December 2014.
[I-D.ietf-idr-ls-distribution]
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-07
(work in progress), November 2014.
[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, April 2004.
[RFC4292] Haberman, B., "IP Forwarding Table MIB", RFC 4292, April [RFC4292] Haberman, B., "IP Forwarding Table MIB", RFC 4292, April
2006. 2006.
[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,
skipping to change at page 9, line 25 skipping to change at page 9, line 47
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. I2RS does not involve CLI unlikely to ever be standardized. CLI standardization is not
standardization. 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
 End of changes. 18 change blocks. 
49 lines changed or deleted 73 lines changed or added

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