draft-ietf-i2rs-problem-statement-08.txt   draft-ietf-i2rs-problem-statement-09.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: June 20, 2016 Brocade Expires: July 18, 2016 Brocade
D. Ward D. Ward
Cisco Systems Cisco Systems
December 18, 2015 January 15, 2016
Interface to the Routing System Problem Statement Interface to the Routing System Problem Statement
draft-ietf-i2rs-problem-statement-08 draft-ietf-i2rs-problem-statement-09
Abstract Abstract
Traditionally, routing systems have implemented routing and signaling Traditionally, routing systems have implemented routing and signaling
(e.g. MPLS) to control traffic forwarding in a network. Route (e.g. MPLS) to control traffic forwarding in a network. Route
computation has been controlled by relatively static policies that computation has been controlled by relatively static policies that
define link cost, route cost, or import and export routing policies. define link cost, route cost, or import and export routing policies.
With the advent of highly dynamic data center networking, on-demand With the advent of highly dynamic data center networking, on-demand
WAN services, dynamic policy-driven traffic steering and service WAN services, dynamic policy-driven traffic steering and service
chaining, the need for real-time security threat responsiveness via chaining, the need for real-time security threat responsiveness via
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 June 20, 2016. This Internet-Draft will expire on July 18, 2016.
Copyright Notice 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. 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
skipping to change at page 5, line 30 skipping to change at page 5, line 30
. * Events, QoS, etc. * * & Data Plane * . . * Events, QoS, etc. * * & Data Plane * .
. +*******************+ +****************+ . . +*******************+ +****************+ .
................................................................. .................................................................
<--> interfaces inside the scope of I2RS Protocol <--> interfaces inside the scope of I2RS Protocol
+--+ objects inside the scope of I2RS-defined behavior +--+ objects inside the scope of I2RS-defined behavior
<**> interfaces NOT within the scope of I2RS Protocol <**> interfaces NOT within the scope of I2RS Protocol
+**+ objects NOT within the scope of I2RS-defined behavior +**+ 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 .... boundary of a router supporting I2RS
Figure 1: I2RS model and Problem Area Figure 1: I2RS model and Problem Area
The I2RS Working Group must select the suitable protocol(s) to carry The I2RS Working Group must select the suitable protocol(s) to carry
messages between the I2RS Clients and I2RS Agent. The protocol messages between the I2RS Clients and I2RS Agent. The protocol
should provide the key features specified in Section 5. should provide the key features specified in Section 5.
The I2RS Working Group must identify or define is a set of meaningful 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 data-models for information in the routing system and in a topology
skipping to change at page 8, line 14 skipping to change at page 8, line 14
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 at different times; data may even be different I2RS clients at different times; data may even be
overwritten by a different I2RS client. The details of how this overwritten by a different I2RS client. The details of how this
should be handled are described in [I-D.ietf-i2rs-architecture]. 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, within the I2RS scope, the I2RS High-Throughput: At a minimum, within the I2RS scope, the I2RS
Agent and associated router should be able to handle a Agent and associated router should be able to handle a
considerable number of operations per second (for example 10,000 considerable number of operations per second (for example 10,000
per second to handle many individual subscriber routes changing per second to handle many individual subscriber routes changing
skipping to change at page 9, line 34 skipping to change at page 9, line 34
can validate both the identity and the permissions associated with an can validate both the identity and the permissions associated with an
I2RS Client. Mutual authentication between the I2RS Agent and I2RS I2RS Client. Mutual authentication between the I2RS Agent and I2RS
Client is required. Different levels of integrity, confidentiality, Client is required. Different levels of integrity, confidentiality,
and replay protection are relevant for different aspects of I2RS. and replay protection are relevant for different aspects of I2RS.
9. Informative References 9. Informative References
[I-D.ietf-i2rs-architecture] [I-D.ietf-i2rs-architecture]
Atlas, A., Halpern, J., Hares, S., Ward, D., and T. Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
Nadeau, "An Architecture for the Interface to the Routing 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. progress), December 2015.
[I-D.ietf-idr-ls-distribution] [I-D.ietf-idr-ls-distribution]
Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. Gredler, H., Medved, J., Previdi, S., Farrel, A., and S.
Ray, "North-Bound Distribution of Link-State and TE Ray, "North-Bound Distribution of Link-State and TE
Information using BGP", draft-ietf-idr-ls-distribution-13 Information using BGP", draft-ietf-idr-ls-distribution-13
(work in progress), October 2015. (work in progress), October 2015.
[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)
 End of changes. 8 change blocks. 
7 lines changed or deleted 10 lines changed or added

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