draft-ietf-i2rs-problem-statement-07.txt   draft-ietf-i2rs-problem-statement-08.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 19, 2016 Brocade Expires: June 20, 2016 Brocade
D. Ward D. Ward
Cisco Systems Cisco Systems
December 17, 2015 December 18, 2015
Interface to the Routing System Problem Statement Interface to the Routing System Problem Statement
draft-ietf-i2rs-problem-statement-07 draft-ietf-i2rs-problem-statement-08
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, the need has emerged to more
dynamicaly manage and program routing systems in order to control dynamically manage and program routing systems in order to control
routing information and traffic paths and to extract network topology routing information and traffic paths and to extract network topology
information, traffic statistics, and other network analytics from information, traffic statistics, and other network analytics from
routing systems. 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
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 19, 2016. This Internet-Draft will expire on June 20, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. I2RS Model and Problem Area for The IETF . . . . . . . . . . 3 2. I2RS Model and Problem Area for the IETF . . . . . . . . . . 3
3. Standard Data-Models of Routing State for Installation . . . 6 3. Standard Data-Models of Routing State for Installation . . . 6
4. Learning Router Information . . . . . . . . . . . . . . . . . 6 4. Learning Router Information . . . . . . . . . . . . . . . . . 6
5. Aspects to be Considered for an I2RS Protocol . . . . . . . . 7 5. Aspects to be Considered for an I2RS Protocol . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. Informative References . . . . . . . . . . . . . . . . . . . 9 9. Informative References . . . . . . . . . . . . . . . . . . . 9
Appendix A. Existing Management Interfaces . . . . . . . . . . . 10 Appendix A. Existing Management Interfaces . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
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
chainging, the need for rea-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, the need has emerged to more
dynamicaly manage and program routing systems in order to control dynamically manage and program routing systems in order to control
routing information and traffic paths and to extract network topology routing information and traffic paths and to extract network topology
information, traffic statistics, and other network analytics from information, traffic statistics, and other network analytics from
routing systems. routing systems.
As modern network continue to grow in scale and complexity and As modern networks continue to grow in scale and complexity and
desired policy has become more complex and dynamic, there is a need desired policy has become more complex and dynamic, there is a need
to support rapid control and analytics. The scale of modern networks to support rapid control and analytics. The scale of modern networks
and data-centers and the associated operational expense drives the and data-centers and the associated operational expense drives the
need to automate even the simplest operations. The ability to need to automate even the simplest operations. The ability to
quickly interact via more complex operations to support dynamic quickly interact via more complex operations to support dynamic
policy is even more critical. policy is even more critical.
In order to enable network applications to have access to and control In order to enable network applications to have access to and control
over information in the Internet's routing system, a publicly over information in the different vendors' routing systems, a
documented interface is required. The interface needs to support publicly documented interface is required. The interface needs to
real-time, asynchronous interactions using efficient data models and support real-time, asynchronous interactions using efficient data
encodings that could extend on those previously defined. models and encodings that are based on and extend those previously
Furthermore, the interface must be tailored to provide a solid base defined. Furthermore, the interface must be tailored to provide a
on which a variety of use cases can be supported. solid base on which a variety of use cases can be supported.
To support the requirements of orchestration software and automated To support the requirements of orchestration software and automated
network applications to dynamically modify the network, there is a network applications to dynamically modify the network, there is a
need to learn topology, networka analytics, and existing state from need to learn topology, network analytics, and existing state from
the network as well as to create or modify routing information and the network as well as to create or modify routing information and
network paths. A feedback loop is needed so that changes made can be network paths. A feedback loop is needed so that changes made can be
verifiable and so that these applications can learn and react to verifiable and so that these applications can learn and react to
network changes. network changes.
Proprietary solutions to partially support the requirements outlined Proprietary solutions to partially support the requirements outlined
above have been developed to handle specific situations and needs. above have been developed to handle specific situations and needs.
Standardizing an interface to the routing system will makae it easier Standardizing an interface to the routing system will make it easier
to integrate use of it into a network. Because there are proprietary to integrate use of it into a network. Because there are proprietary
partial solutions, the standardization of a common interface should partial solutions already, the standardization of a common interface
be feasible. should be feasible.
It should be noted that during the course of this document, the term It should be noted that during the course of this document, the term
"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. 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 service (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, colocqted within the systems or system components may be virtualized, colocated within the
same physical system or distributed. In all cases, it is desirable same physical system or distributed. In all cases, it is desirable
to enable network applications to manage and control the services to enable network applications to manage and control the services
provided by many, if not all, of these components, subject to provided by many, if not all, of these components, subject to
authenticated and authorized access and policies. authenticated and authorized access and policies.
A data-model driven interfase 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 flexiblity. 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.
The I2RS model and problem area for IETF work is illustrated in The I2RS model and problem area for IETF work is illustrated in
Figure 1. This document uses terminology defined in Figure 1. This document uses terminology defined in
[I-D.ietf-i2rs-architecture]. The I2RS Agent is associated with a [I-D.ietf-i2rs-architecture]. The I2RS Agent is associated with a
skipping to change at page 6, line 37 skipping to change at page 6, line 37
Efforts to provide this level of control have focused on Efforts to provide this level of control have focused on
standardizing data models that describe the forwarding plane (e.g. standardizing data models that describe the forwarding plane (e.g.
ForCES [RFC3746]). I2RS recognizes that the routing system and a ForCES [RFC3746]). I2RS recognizes that the routing system and a
router's OS provide useful mechanisms that applications could router's OS provide useful mechanisms that applications could
usefully harness to accomplish application-level goals. Using usefully harness to accomplish application-level goals. Using
routing indirection, recursion and common routing abstractions (e.g. routing indirection, recursion and common routing abstractions (e.g.
tunnels, LSPs, etc.) provides significant flexibility and tunnels, LSPs, etc.) provides significant flexibility and
functionality over collapsing the state to individual routes in the functionality over collapsing the state to individual routes in the
FIB that need to be individually modified when a change occurs. FIB that need to be individually modified when a change occurs.
In addition to interfaces to the RIB layer, there is a need to In addition to interfaces to control the RIB layer, there is a need
dynamically configure policies and values for parameters for the to dynamically configure policies and values for parameters for the
various routing and signaling protocols based upon application-level various routing and signaling protocols based upon application-level
policy decisions. policy decisions.
4. Learning Router Information 4. Learning Router Information
A router has information that applications may require so that they A router has information that applications may require so that they
can understand the network, verify that programmed state is can understand the network, verify that programmed state is
installed, measure the behavior of various flows, and understand the installed, measure the behavior of various flows, and understand the
existing configuration and state of the router. I2RS should provide existing configuration and state of the router. I2RS should provide
a framework so that applications can register for asynchronous a framework so that applications can register for asynchronous
skipping to change at page 10, line 50 skipping to change at page 10, line 50
for reasons that vary depending upon the network operator. Some for reasons that vary depending upon the network operator. Some
example reasons include complexity, the lack of desired configuration example reasons include complexity, the lack of desired configuration
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, the initial lack of configuration that were just described. However, as a new technology
standard data models have hampered the adoption of NETCONF. I2RS and with the initial lack of standard data models, the adoption of
will define needed information and data models to support I2RS NETCONF has been slow. I2RS will define needed information and data
applications. Additional extensions to handle multi-headed control models to support I2RS applications. Additional extensions to handle
may need to be added to NETCONF and/or appropriate data models. multi-headed control may need to be added to 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. 21 change blocks. 
32 lines changed or deleted 33 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/