draft-ietf-i2rs-problem-statement-02.txt   draft-ietf-i2rs-problem-statement-03.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 8, 2014 Brocade Expires: December 8, 2014 Brocade
D. Ward D. Ward
Cisco Systems Cisco Systems
June 6, 2014 June 6, 2014
Interface to the Routing System Problem Statement Interface to the Routing System Problem Statement
draft-ietf-i2rs-problem-statement-02 draft-ietf-i2rs-problem-statement-03
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 4, line 49 skipping to change at page 4, line 49
+**+ objects NOT within the scope of I2RS +**+ objects NOT within the scope of I2RS
.... boundary of a router participating in the I2RS .... boundary of a router participating in the 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 clear transfer in Section 5. The data models should translate into a concise
syntax that is straightforward for applications to use (e.g., a Web transfer syntax that is straightforward for applications to use
Services design paradigm). The information transfer should use (e.g., a Web Services design paradigm). The information transfer
existing transport protocols to provide the reliability, security, should use existing transport protocols to provide the reliability,
and timeliness appropriate for the particular data. security, and timeliness appropriate for the particular data.
The second critical aspect are semantic-aware data-models for The second critical aspect are meaningful data-models for information
information in the routing system and in a topology database. The in the routing system and in a topology database. The data-model
data-model should describe the meaning and relationships of the should describe the meaning and relationships of the modeled items.
modeled items. The data-models should be separable across different The data-models should be separable across different features of the
features of the managed components, versioned, and extendable. As managed components, versioned, and extendable. As shown in Figure 1,
shown in Figure 1, I2RS needs to interact with several logical I2RS needs to interact with several logical components of the routing
components of the routing element: policy database, topology element: policy database, topology database, subscription and
database, subscription and configuration for dynamic measuresments/ configuration for dynamic measuresments/events, routing signaling
events, routing signaling protocols, and its RIB manager. This protocols, and its RIB manager. This interaction is both for writing
interaction is both for writing (e.g. to policy databases or RIB (e.g. to policy databases or RIB manager) as well as for reading
manager) as well as for reading (e.g. dynamic measurement or topology (e.g. dynamic measurement or topology database). An application
database). An application should be able to combine data from should be able to combine data from individual routing elements to
individual routing elements to provide network-wide data-model(s). 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 48 skipping to change at page 5, line 48
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 MIBs at the present time. range desired is not available via MIB modules at the present time.
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.
skipping to change at page 6, line 38 skipping to change at page 6, line 38
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 is there the MIB notifications today, the full range is not - nor has there been
standardized ability to set up the router to trigger different successfully deployed the standardized ability to set up the router
actions upon an event's occurrence so that a rapid reaction can be to trigger different actions upon an event's occurrence so that a
accomplished. rapid reaction can be accomplished.
5. Desired Aspects of a Protocol for I2RS 5. Desired Aspects of a Protocol for I2RS
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 operations via I2RS should be able to send multiple independent atomic operations via
without being required to wait for each to complete before sending I2RS without being required to wait for each to complete before
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 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
skipping to change at page 7, line 36 skipping to change at page 7, line 36
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).
Responsive: 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. Thus a single TCP session would
not be a good match. not be a good match.
skipping to change at page 9, line 43 skipping to change at page 9, line 43
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 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.
Naturally, I2RS may help define needed information and data models. Naturally, I2RS may help define needed information and data models.
Additional extensions to handle multi-headed control may need to be Additional extensions to handle multi-headed control may need to be
added to NetConf and/or appropriate data models. 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 10 Technology Park Drive
Westford, MA 01886 Westford, MA 01886
USA USA
Email: akatlas@juniper.net Email: akatlas@juniper.net
 End of changes. 10 change blocks. 
32 lines changed or deleted 32 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/