--- 1/draft-ietf-i2rs-problem-statement-08.txt 2016-01-15 11:16:06.555172669 -0800 +++ 2/draft-ietf-i2rs-problem-statement-09.txt 2016-01-15 11:16:06.583173341 -0800 @@ -1,21 +1,21 @@ Network Working Group A. Atlas, Ed. Internet-Draft Juniper Networks Intended status: Informational T. Nadeau, Ed. -Expires: June 20, 2016 Brocade +Expires: July 18, 2016 Brocade D. Ward Cisco Systems - December 18, 2015 + January 15, 2016 Interface to the Routing System Problem Statement - draft-ietf-i2rs-problem-statement-08 + draft-ietf-i2rs-problem-statement-09 Abstract Traditionally, routing systems have implemented routing and signaling (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 chaining, the need for real-time security threat responsiveness via @@ -37,25 +37,25 @@ 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 June 20, 2016. + This Internet-Draft will expire on July 18, 2016. Copyright Notice - Copyright (c) 2015 IETF Trust and the persons identified as the + Copyright (c) 2016 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -208,20 +208,23 @@ . * Events, QoS, etc. * * & Data Plane * . . +*******************+ +****************+ . ................................................................. <--> interfaces inside the scope of I2RS Protocol +--+ objects inside the scope of I2RS-defined behavior <**> interfaces NOT within the scope of I2RS Protocol +**+ objects NOT within the scope of I2RS-defined behavior + <== used to point to the interface where the I2RS Protocol + would be used + .... boundary of a router supporting I2RS Figure 1: I2RS model and Problem Area The I2RS Working Group must select the suitable protocol(s) to carry messages between the I2RS Clients and I2RS Agent. The protocol should provide the key features specified in Section 5. The I2RS Working Group must identify or define is a set of meaningful data-models for information in the routing system and in a topology @@ -331,21 +334,21 @@ Multi-Headed Control: Multiple applications may communicate to the same I2RS agent in a minimally coordinated fashion. It is necessary that the I2RS agent can handle multiple requests in a well-known policy-based fashion. Data written can be owned by 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 - (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, 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, within the I2RS scope, 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 @@ -399,21 +402,21 @@ 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 [I-D.ietf-i2rs-architecture] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. Nadeau, "An Architecture for the Interface to the Routing - System", draft-ietf-i2rs-architecture-11 (work in + System", draft-ietf-i2rs-architecture-12 (work in progress), December 2015. [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-13 (work in progress), October 2015. [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, "Forwarding and Control Element Separation (ForCES)