draft-ietf-i2rs-problem-statement-10.txt   draft-ietf-i2rs-problem-statement-11.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: August 15, 2016 Brocade Expires: November 11, 2016 Brocade
D. Ward D. Ward
Cisco Systems Cisco Systems
February 12, 2016 May 10, 2016
Interface to the Routing System Problem Statement Interface to the Routing System Problem Statement
draft-ietf-i2rs-problem-statement-10 draft-ietf-i2rs-problem-statement-11
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
traffic control, and a paradigm of separating policy-based decision- traffic control, and a paradigm of separating policy-based decision-
making from the router itself, the need has emerged to more making from the router itself, requirements have emerged to more
dynamically manage and program routing systems in order to control dynamically manage and program routing systems. These requirements
routing information and traffic paths and to extract network topology should allow controlling routing information and traffic paths and
information, traffic statistics, and other network analytics from extracting network topology information, traffic statistics, and
routing systems. other network analytics from routing systems.
This document proposes meeting this need via an Interface to the This document proposes meeting this need via an Interface to the
Routing System (I2RS). Routing System (I2RS).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 August 15, 2016. This Internet-Draft will expire on November 11, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
skipping to change at page 3, line 47 skipping to change at page 3, line 47
"applications" is used. This is meant to refer to an executable "applications" is used. This is meant to refer to an executable
program of some sort that has access to a network, such as an IP or program of some sort that has access to a network, such as an IP or
MPLS network, via a routing system. MPLS network, via a routing system.
2. I2RS Model and Problem Area for the IETF 2. I2RS Model and Problem Area for the IETF
Managing a network of systems running a variety of routing protocols Managing a network of systems running a variety of routing protocols
and/or providing one or more additional services (e.g., forwarding, and/or providing one or more additional services (e.g., forwarding,
classification and policing, firewalling) involves interactions classification and policing, firewalling) involves interactions
between multiple components within these systems. Some of these between multiple components within these systems. Some of these
systems or system components may be virtualized, colocated within the systems or system components may be virtualized, co-located within
same physical system or distributed. In all cases, it is desirable the same physical system or distributed. In all cases, it is
to enable network applications to manage and control the services desirable to enable network applications to manage and control the
provided by many, if not all, of these components, subject to services provided by many, if not all, of these components, subject
authenticated and authorized access and policies. to authenticated and authorized access and policies.
A data-model driven interface to the routing system is needed. This A data-model driven interface to the routing system is needed. This
will allow expansion of what information can be read and controlled will allow expansion of what information can be read and controlled
and allow for future flexibility. At least one accompanying protocol and allow for future flexibility. At least one accompanying protocol
with clearly defined operations is needed; the suitable protocol(s) with clearly defined operations is needed; the suitable protocol(s)
can be identified and expanded to support the requirements of an can be identified and expanded to support the requirements of an
Interface to the Routing System (I2RS). These solutions must be Interface to the Routing System (I2RS). These solutions must be
designed to facilitate rapid, isolated, secure, and dynamic changes designed to facilitate rapid, isolated, secure, and dynamic changes
to a device's routing system. These would facilitate wide-scale to a device's routing system. These would facilitate wide-scale
deployment of interoperable applications and routing systems. deployment of interoperable applications and routing systems.
skipping to change at page 5, line 40 skipping to change at page 5, line 40
<**> 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 <== used to point to the interface where the I2RS Protocol
would be used 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 protocol(s) used to carry messages between I2RS Clients and I2RS
messages between the I2RS Clients and I2RS Agent. The protocol Agents 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 a set of 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 I2RS will use a set of meaningful data-models for information in the
for dynamic measurements/events, routing signaling protocols, and its routing system and in a topology database. Each data-model should
RIB manager. This interaction is both for writing (e.g. to policy describe the meaning and relationships of the modeled items. The
databases or RIB manager) as well as for reading (e.g. dynamic data-models should be separable across different features of the
measurement or topology database). An application should be able to managed components, versioned, and extendable. As shown in Figure 1,
combine data from individual routing elements to provide network-wide I2RS needs to interact with several logical components of the routing
data-model(s). element: policy database, topology database, subscription and
configuration for dynamic measurements/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 data models should translate into a concise transfer syntax, sent The data models should translate into a concise transfer syntax, sent
via the I2RS protocol, that is straightforward for applications to via the I2RS protocol, that is straightforward for applications to
use (e.g., a Web Services design paradigm). The information transfer use (e.g., a Web Services design paradigm). The information transfer
should use existing transport protocols to provide the reliability, should use existing transport protocols to provide the reliability,
security, and timeliness appropriate for the particular data. security, and timeliness appropriate for the particular data.
3. Standard Data-Models of Routing State for Installation 3. Standard Data-Models of Routing State for Installation
As described in Section 1, there is a need to be able to precisely As described in Section 1, there is a need to be able to precisely
skipping to change at page 8, line 23 skipping to change at page 8, line 23
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, the I2RS Agent and associated router
Agent and associated router should be able to handle a should be able to handle a considerable number of operations per
considerable number of operations per second (for example 10,000 second (for example 10,000 per second to handle many individual
per second to handle many individual subscriber routes changing subscriber routes changing simultaneously).
simultaneously).
Low-Latency: 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
skipping to change at page 8, line 51 skipping to change at page 8, line 50
different channel. Writes from a client are only expected on different channel. Writes from a client are only expected on
channels that provide authorization and authentication. channels that provide authorization and authentication.
Scalable, Filterable Information Access: To extract information in a Scalable, Filterable Information Access: To extract information in a
scalable fashion that is more easily used by applications, the scalable fashion that is more easily used by applications, the
ability to specify filtering constructs in an operation requesting ability to specify filtering constructs in an operation requesting
data or requesting an asynchronous notification is very valuable. data or requesting an asynchronous notification is very valuable.
Secure Control and Access: Any ability to manipulate routing state Secure Control and Access: Any ability to manipulate routing state
must be subject to authentication and authorization. Sensitive must be subject to authentication and authorization. Sensitive
routing information may also need to be provided via secure access routing information also may need to be provided via secure access
back to the I2RS Client. Such communications must be integrity back to the I2RS Client. Such communications must be integrity
protected. Some communications will also require confidentiality. protected. Most communications will also require confidentiality.
Extensible and Interoperability: Both the I2RS protocol and models Extensible and Interoperability: Both the I2RS protocol and models
must be extensible and interoperate between different versions of must be extensible and interoperate between different versions of
protocols and models. protocols and models.
6. Acknowledgements 6. Acknowledgements
The authors would like to thank Ken Gray, Ed Crabbe, Nic Leymann, The authors would like to thank Ken Gray, Ed Crabbe, Nic Leymann,
Carlos Pignataro, Kwang-koog Lee, Linda Dunbar, Sue Hares, Russ Carlos Pignataro, Kwang-koog Lee, Linda Dunbar, Sue Hares, Russ
Housley, Eric Grey, Qin Wu, Stephen Kent, Nabil Bitar, Deborah Housley, Eric Grey, Qin Wu, Stephen Kent, Nabil Bitar, Deborah
skipping to change at page 9, line 42 skipping to change at page 9, line 42
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. References 9. References
9.1. Normative References 9.1. Normative 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-12 (work in System", draft-ietf-i2rs-architecture-15 (work in
progress), December 2015. progress), April 2016.
9.2. Informative References 9.2. Informative References
[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,
skipping to change at page 11, line 12 skipping to change at page 11, line 12
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, as a new technology configuration that were just described. However, as a new technology
and with the initial lack of standard data models, the adoption of and with the initial lack of standard data models, the adoption of
NETCONF has been slow. I2RS will define needed information and data NETCONF has been slow. I2RS will identify and define as needed
models to support I2RS applications. Additional extensions to handle information and data models to support I2RS applications. Additional
multi-headed control may need to be added to NETCONF and/or extensions to handle multi-headed control may need to be added to
appropriate data models. NETCONF and/or appropriate data models.
Authors' Addresses Authors' Addresses
Alia Atlas (editor) Alia Atlas (editor)
Juniper Networks Juniper Networks
Email: akatlas@juniper.net Email: akatlas@juniper.net
Thomas D. Nadeau (editor) Thomas D. Nadeau (editor)
Brocade Brocade
 End of changes. 13 change blocks. 
45 lines changed or deleted 41 lines changed or added

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