--- 1/draft-ietf-i2rs-problem-statement-03.txt 2014-06-23 16:14:26.832974425 -0700 +++ 2/draft-ietf-i2rs-problem-statement-04.txt 2014-06-23 16:14:26.860975103 -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 +Expires: December 25, 2014 Brocade D. Ward Cisco Systems - June 6, 2014 + June 23, 2014 Interface to the Routing System Problem Statement - draft-ietf-i2rs-problem-statement-03 + draft-ietf-i2rs-problem-statement-04 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 @@ -38,21 +38,21 @@ 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on December 8, 2014. + This Internet-Draft will expire on December 25, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -125,20 +125,22 @@ policy hurdles have been crossed. The management of only some of these components require standardization, as others have already been standardized. The I2RS model is intended to incorporate existing mechanisms where appropriate, and to build extensions and new protocols where needed. The I2RS model and problem area for IETF work is illustrated in Figure 1. The I2RS Agent is associated with a 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 applications; they may be co-located or the I2RS Client might be part of a separate application, such as an orchestrator or controller. + The scope of the data-models used by I2RS extends across the entire + routing system and I2RS protocol. +***************+ +***************+ +***************+ * Application * * Application * * Application * +***************+ +***************+ +***************+ | I2RS Client | ^ ^ +---------------+ * * ^ * **************** | * * | v v | +---------------+ +-------------+ @@ -166,27 +168,27 @@ . v * . . +*******************+ * . . * Subscription & * * . . * Configuration * v . . * Templates for * +****************+ . . * Measurements, * * FIB Manager * . . * Events, QoS, etc. * * & Data Plane * . . +*******************+ +****************+ . ................................................................. - <--> interfaces inside the scope of I2RS - +--+ objects inside the scope of I2RS + <--> interfaces inside the scope of I2RS Protocol + +--+ objects inside the scope of I2RS-defined behavior - <**> interfaces NOT within the scope of I2RS - +**+ objects NOT within the scope of I2RS + <**> interfaces NOT within the scope of I2RS Protocol + +**+ objects NOT within the scope of I2RS-defined behavior - .... boundary of a router participating in the I2RS + .... boundary of a router supporting 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 concise transfer syntax that is straightforward for applications to use (e.g., a Web Services design paradigm). The information transfer @@ -226,20 +228,23 @@ 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 MIB modules at the present time. + 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. 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.