--- 1/draft-ietf-i2rs-problem-statement-02.txt 2014-06-06 13:14:25.649578673 -0700 +++ 2/draft-ietf-i2rs-problem-statement-03.txt 2014-06-06 13:14:25.673579255 -0700 @@ -1,21 +1,21 @@ Network Working Group A. Atlas, Ed. Internet-Draft Juniper Networks Intended status: Informational T. Nadeau, Ed. Expires: December 8, 2014 Brocade D. Ward Cisco Systems June 6, 2014 Interface to the Routing System Problem Statement - draft-ietf-i2rs-problem-statement-02 + draft-ietf-i2rs-problem-statement-03 Abstract As modern networks grow in scale and complexity, the need for rapid and dynamic control increases. With scale, the need to automate even the simplest operations is important, but even more critical is the ability to quickly interact with more complex operations such as policy-based controls. In order to enable network applications to have access to and control @@ -180,39 +180,39 @@ +**+ objects NOT within the scope of I2RS .... boundary of a router participating in the I2RS Figure 1: I2RS model and Problem Area A critical aspect of I2RS is defining a suitable protocol or protocols to carry messages between the I2RS Clients and the I2RS Agent, and defining the data-models for use with those I2RS protocol(s). The protocol should provide the key features specified - in Section 5. The data models should translate into a clear transfer - syntax 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. + in Section 5. The data models should translate into a concise + transfer syntax 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 are semantic-aware data-models for - information in the routing system and in a topology database. The - data-model should describe the meaning and relationships of the - modeled items. The data-models should be separable across different - features of the managed components, versioned, and extendable. As - shown in Figure 1, I2RS needs to interact with several logical - components of the routing element: policy database, topology - database, subscription and configuration for dynamic measuresments/ - events, routing signaling protocols, and its RIB manager. This - interaction is both for writing (e.g. to policy databases or RIB - manager) as well as for reading (e.g. dynamic measurement or topology - database). An application should be able to combine data from - individual routing elements to provide network-wide data-model(s). + The second critical aspect are meaningful data-models for information + in the routing system and in a topology database. The data-model + should describe the meaning and relationships of the modeled items. + The data-models should be separable across different features of the + managed components, versioned, and extendable. As shown in Figure 1, + I2RS needs to interact with several logical components of the routing + element: policy database, topology database, subscription and + configuration for dynamic measuresments/events, routing signaling + protocols, and its RIB manager. This interaction is both for writing + (e.g. to policy databases or RIB manager) as well as for reading + (e.g. dynamic measurement or topology database). An application + should be able to combine data from individual routing elements to + provide network-wide data-model(s). 3. Standard Data-Models of Routing State for Installation There is a need to be able to precisely control routing and signaling state based upon policy or external measures. This can range from simple static routes to policy-based routing to static multicast replication and routing state. This means that, to usefully model next-hops, the data model employed needs to handle next-hop indirection and recursion (e.g. a prefix X is routed like prefix Y) as well as different types of tunneling and encapsulation. The @@ -225,21 +225,21 @@ Efforts to provide this level of control have focused on standardizing data models that describe the forwarding plane (e.g. ForCES [RFC3746]). I2RS posits that the routing system and a router's OS provide useful mechanisms that applications could usefully harness to accomplish application-level goals. In addition to interfaces to the RIB layer, there is a need to configure the various routing and signaling protocols with differing 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 A router has information that applications may require so that they can understand the network, verify that programmed state is installed in the forwarding plane, measure the behavior of various flows, and understand the existing configuration and state of the router. I2RS provides a framework so that applications can register for asynchronous notifications and can make specific requests for information. @@ -260,38 +260,38 @@ mechanism such as IPFIX [RFC5470] may be the facilitator for delivering the data, the need for an application to be able to dynamically request that measurements be taken and data delivered is critical. There are a wide range of events that applications could use for either verification of router state before other network state is changed (e.g. that a route has been installed), to act upon changes to relevant routes by others, or upon router events (e.g. link up/ down). While a few of these (e.g. link up/down) may be available via - MIB Notifications today, the full range is not - nor is there the - standardized ability to set up the router to trigger different - actions upon an event's occurrence so that a rapid reaction can be - accomplished. + MIB notifications today, the full range is not - nor has there been + successfully deployed the standardized ability to set up the router + to trigger different actions upon an event's occurrence so that a + rapid reaction can be accomplished. 5. Desired Aspects of a Protocol for I2RS This section describes required aspects of a protocol that could support I2RS. Whether such a protocol is built upon extending existing mechanisms or requires a new mechanism requires further investigation. The key aspects needed in an interface to the routing system are: Multiple Simultaneous Asynchronous Operations: A single application - should be able to send multiple independent operations via I2RS - without being required to wait for each to complete before sending - the next. + should be able to send multiple independent atomic operations via + I2RS without being required to wait for each to complete before + sending the next. Very Fine Granularity of Data Locking for Writing: When an I2RS operation is processed, it is required that the data locked for writing is very granular (e.g. a particular prefix and route) rather than extremely coarse, as is done for writing configuration. This should improve the number of concurrent I2RS operations that are feasible and reduce blocking delays. Multi-Headed Control: Multiple applications may communicate to the same I2RS agent in a minimally coordinated fashion. It is @@ -305,21 +305,21 @@ events, acknowledgements, failures, operations, etc. can be sent at any time by both the router and the application. The I2RS is not a pure pull-model where only the application queries to pull responses. High-Throughput: At a minimum, the I2RS Agent and associated router should be able to handle a considerable number of operations per second (for example 10,000 per second to handle many individual subscriber routes changing simultaneously). - 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 prefix route). Multi-Channel: It should be possible for information to be communicated via the interface from different components in the router without requiring going through a single channel. For example, for scaling, some exported data or events may be better sent directly from the forwarding plane, while other interactions may come from the control-plane. Thus a single TCP session would not be a good match. @@ -404,27 +404,27 @@ information about devices, including their routing systems. However, SNMP is very rarely used to configure a device or any of its systems for reasons that vary depending upon the network operator. Some example reasons include complexity, the lack of desired configuration semantics (e.g., configuration "roll-back", "sandboxing" or configuration versioning), and the difficulty of using the semantics (or lack thereof) as defined in the MIB modules to configure device features. Therefore, SNMP is not considered as a candidate solution for the problems motivating I2RS. - 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 - configuration that were just described. However, the lack of - standard data models have hampered the adoption of NetConf. + configuration that were just described. However, the initial lack of + standard data models have hampered the adoption of NETCONF. Naturally, I2RS may help define needed information and data models. 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 Alia Atlas (editor) Juniper Networks 10 Technology Park Drive Westford, MA 01886 USA Email: akatlas@juniper.net