draft-atlas-i2rs-problem-statement-01.txt   draft-atlas-i2rs-problem-statement-02.txt 
Network Working Group A. Atlas, Ed. Network Working Group A. Atlas, Ed.
Internet-Draft T. Nadeau, Ed. Internet-Draft T. Nadeau, Ed.
Intended status: Informational Juniper Networks Intended status: Informational Juniper Networks
Expires: January 16, 2014 D. Ward Expires: February 15, 2014 D. Ward
Cisco Systems Cisco Systems
July 15, 2013 August 14, 2013
Interface to the Routing System Problem Statement Interface to the Routing System Problem Statement
draft-atlas-i2rs-problem-statement-01 draft-atlas-i2rs-problem-statement-02
Abstract Abstract
As modern networks grow in scale and complexity, the need for rapid As modern networks grow in scale and complexity, the need for rapid
and dynamic control increases. With scale, the need to automate even and dynamic control increases. With scale, the need to automate even
the simplest operations is important, but even more critical is the the simplest operations is important, but even more critical is the
ability to quickly interact with more complex operations such as ability to quickly interact with more complex operations such as
policy-based controls. policy-based controls.
In order to enable applications to have access to and control over In order to enable network applications to have access to and control
information in the Internet's routing system, we need a publicly over information in the Internet's routing system, we need a publicly
documented interface specification. The interface needs to support documented interface specification. The interface needs to support
real-time, asynchronous interactions using data models and encodings real-time, asynchronous interactions using data models and encodings
that are efficient and potentially different from those available that are efficient and potentially different from those available
today. Furthermore, the interface must be tailored to support a today. Furthermore, the interface must be tailored to support a
variety of use cases. variety of use cases.
This document expands upon these statements of requirements to This document expands upon these statements of requirements to
provide a detailed problem statement for an Interface to the Internet provide a detailed problem statement for an Interface to the Routing
Routing System (I2RS). 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 January 16, 2014. This Internet-Draft will expire on February 15, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 2, line 27 skipping to change at page 2, line 27
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 . . . 5 3. Standard Data-Models of Routing State for Installation . . . 5
4. Learning Router Information . . . . . . . . . . . . . . . . . 5 4. Learning Router Information . . . . . . . . . . . . . . . . . 5
5. Desired Aspects of a Protocol for I2RS . . . . . . . . . . . 6 5. Desired Aspects of a Protocol for I2RS . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. Informative References . . . . . . . . . . . . . . . . . . . 8 9. Informative References . . . . . . . . . . . . . . . . . . . 8
Appendix A. Existing Management Interfaces . . . . . . . . . . . 8 Appendix A. Existing Management Interfaces . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
As modern networks grow in scale and complexity, the need for rapid, As modern networks grow in scale and complexity, the need for rapid,
flexible and dynamic control increases. With scale, the need to flexible and dynamic control increases. With scale, the need to
automate even the simplest operation is important, but even more automate even the simplest operation is important, but even more
critical is the ability for network operators to quickly interact critical is the ability for network operators to quickly interact
with these operations using mechanisms such as policy-based controls. with these operations using mechanisms such as policy-based controls.
With complexity comes the need for more sophisticated automated With complexity comes the need for more sophisticated automated
applications and orchestration software that can process large network applications and orchestration software that can process
quantities of data, run complex algorithms, and adjust the routing large quantities of data, run complex algorithms, and adjust the
state as required in order to support the network applications, their routing state as required in order to support the network
computations and their policies. Changes made to the routing state applications, their computations and their policies. Changes made to
of a network by external applications must be verifiable by those the routing state of a network by external applications must be
applications to ensure that the correct state has been installed in verifiable by those applications to ensure that the correct state has
the correct places. been installed in the correct places.
In the past, mechanisms to support the requirements outlined above In the past, mechanisms to support the requirements outlined above
have been developed piecemeal as proprietary solutions to specific have been developed piecemeal as proprietary solutions to specific
situations and needs. Many routing elements have an external situations and needs. Many routing elements have an external
interface to interact with routing - but since these vary between interface to interact with routing - but since these vary between
vendors, it is difficult to integrate use of those interfaces into a vendors, it is difficult to integrate use of those interfaces into a
network. The existence of such proprietary interfaces demonstrates network. The existence of such proprietary interfaces demonstrates
both that the need for such an interface is understood and that both that the need for such an interface is understood and that
technology solutions are understood. What is needed are technology solutions are understood. What is needed are
technological solutions with clearly defined operations that an technological solutions with clearly defined operations that an
application can initiate, and data-models to support such actions. application can initiate, and data-models to support such actions.
These would facilitate wide-scale deployment of interoperable These would facilitate wide-scale deployment of interoperable
applications and routing systems. These solutions must be designed applications and routing systems. These solutions must be designed
to facilitate rapid, isolated, secure, and dynamic changes to a to facilitate rapid, isolated, secure, and dynamic changes to a
device's routing system. In order to address these needs, the device's routing system. In order to address these needs, the
creation of an Interface to The Routing System (I2RS) is needed. creation of an Interface to the Routing System (I2RS) is needed.
It should be noted that during the course of this document, we will It should be noted that during the course of this document, we will
discuss and use the term "applications". This is meant to refer to discuss and use the term "applications". This is meant to refer to
an executable program of some sort that has access to a network, such an executable program of some sort that has access to a network, such
as an IP network. as an IP network.
2. I2RS Model and Problem Area for The IETF 2. I2RS Model and Problem Area for The IETF
Managing a network of production devices running a variety of routing Managing a network of production devices running a variety of routing
protocols involves interactions with an between multiple components protocols involves interactions with an between multiple components
skipping to change at page 3, line 50 skipping to change at page 3, line 50
of a separate application, such as an orchestrator or controller. of a separate application, such as an orchestrator or controller.
+***************+ +***************+ +***************+ +***************+ +***************+ +***************+
* Application * * Application * * Application * * Application * * Application * * Application *
+***************+ +***************+ +***************+ +***************+ +***************+ +***************+
| I2RS Client | ^ ^ | I2RS Client | ^ ^
+---------------+ * * +---------------+ * *
^ * **************** ^ * ****************
| * * | * *
| v v | v v
| +---------------+ | +---------------+ +-------------+
| | I2RS Client | | | I2RS Client |<------->| Other I2RS |
| +---------------+ | +---------------+ | Agents |
| ^ | ^ +-------------+
|________________ | |________________ |
| | <== I2RS Protocol | | <== I2RS Protocol
| | | |
...........................|..|.................................. ...........................|..|..................................
. v v . . v v .
. +*************+ +---------------+ +****************+ . . +*************+ +---------------+ +****************+ .
. * Policy * | | * Routing & * . . * Policy * | | * Routing & * .
. * Database *<***>| I2RS Agent |<****>* Signaling * . . * Database *<***>| I2RS Agent |<****>* Signaling * .
. +*************+ | | * Protocols * . . +*************+ | | * Protocols * .
. +---------------+ +****************+ . . +---------------+ +****************+ .
skipping to change at page 5, line 24 skipping to change at page 5, line 24
application should be able to combine data from individual routing application should be able to combine data from individual routing
elements to provide network-wide data-model(s). elements to provide network-wide data-model(s).
3. Standard Data-Models of Routing State for Installation 3. Standard Data-Models of Routing State for Installation
There is a need to be able to precisely control routing and signaling There is a need to be able to precisely control routing and signaling
state based upon policy or external measures. This can range from state based upon policy or external measures. This can range from
simple static routes to policy-based routing to static multicast simple static routes to policy-based routing to static multicast
replication and routing state. This means that, to usefully model replication and routing state. This means that, to usefully model
next-hops, the data model employed needs to handle next-hop next-hops, the data model employed needs to handle next-hop
indirection (e.g. a prefix X is routed like prefix Y) as well as indirection and recursion (e.g. a prefix X is routed like prefix Y)
different types of tunneling and encapsulation. The relevant MIB as well as different types of tunneling and encapsulation. The
modules (for example [RFC4292]) lack the necessary generality and relevant MIB modules (for example [RFC4292]) lack the necessary
flexibility. In addition, by having I2RS focus initially on generality and flexibility. In addition, by having I2RS focus
interfaces to the RIB layer (e.g. RIB, LIB, multicast RIB, policy- initially on interfaces to the RIB layer (e.g. RIB, LIB, multicast
based routing), the ability to use routing indirection allows RIB, policy-based routing), the ability to use routing indirection
flexibility and functionality that can't be as easily obtained at the allows flexibility and functionality that can't be as easily obtained
forwarding layer. at the forwarding layer.
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 posits that the routing system and a ForCES [RFC3746]). I2RS posits 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. usefully harness to accomplish application-level goals.
In addition to interfaces to the RIB layer, there is a need to In addition to interfaces to the RIB layer, there is a need to
configure the various routing and signaling protocols with differing configure the various routing and signaling protocols with differing
dynamic state based upon application-level policy decisions. The dynamic state based upon application-level policy decisions. The
skipping to change at page 6, line 50 skipping to change at page 6, line 50
5. Desired Aspects of a Protocol for I2RS 5. Desired Aspects of a Protocol for I2RS
This section describes required aspects of a protocol that could This section describes required aspects of a protocol that could
support I2RS. Whether such a protocol is built upon extending support I2RS. Whether such a protocol is built upon extending
existing mechanisms or requires a new mechanism requires further existing mechanisms or requires a new mechanism requires further
investigation. investigation.
The key aspects needed in an interface to the routing system are: The key aspects needed in an interface to the routing system are:
Multiple Simultaneous Asynchronous Operations: A single application Multiple Simultaneous Asynchronous Operations: A single application
should be able to send multiple operations to I2RS without being should be able to send multiple operations via I2RS without being
required to wait for each to complete before sending the next. required to wait for each to complete before sending the next.
Very Fine Granularity of Data Locking for Writing: When an I2RS Very Fine Granularity of Data Locking for Writing: When an I2RS
operation is processed, it is required that the data locked for operation is processed, it is required that the data locked for
writing is very granular (e.g. a particular prefix and route) writing is very granular (e.g. a particular prefix and route)
rather than extremely coarse, as is done for writing rather than extremely coarse, as is done for writing
configuration. This should improve the number of concurrent I2RS configuration. This should improve the number of concurrent I2RS
operations that are feasible and reduce blocking delays. operations that are feasible and reduce blocking delays.
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. different I2RS clients.
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 server), or the I2RS server. 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, the I2RS Agent and associated router High-Throughput: At a minimum, the I2RS Agent and associated router
should be able to handle a considerable number of operations per should be able to handle a considerable number of operations per
second above what basic Netconf or a propretiary CLI can. second above what basic Netconf or a propretiary CLI can.
Responsive: It should be possible to complete simple operations Responsive: It should be possible to complete simple operations
skipping to change at page 7, line 46 skipping to change at page 7, line 46
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
may come from the control-plane. Thus a single TCP session would may come from the control-plane. Thus a single TCP session would
not be a good match. not be a good match.
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.
Any ability to manipulate routing state must be subject to Secure Control: Any ability to manipulate routing state must be
authentication and authorization. subject to authentication and authorization. Such communications
must also have its integrity protected.
Extensible and Interoperability: Both the I2RS protocol and models
must be extensible and interoperate between different versions of
protocols and models.
6. Acknowledgements 6. Acknowledgements
The authors would like to thank Ken Gray, Ed Crabbe and Nic Leymann The authors would like to thank Ken Gray, Ed Crabbe, Nic Leymann,
for their suggestions and review. Carlos Pignataro, and Kwang-koog Lee for their suggestions and
review.
7. IANA Considerations 7. IANA Considerations
This document includes no request to IANA. This document includes no request to IANA.
8. Security Considerations 8. Security Considerations
Security is a key aspect of any protocol that allows state Security is a key aspect of any protocol that allows state
installation and extracting of detailed router state. More installation and extracting of detailed router state. More
investigation remains to fully define the security requirements, such investigation remains to fully define the security requirements, such
skipping to change at page 9, line 41 skipping to change at page 10, line 4
Authors' Addresses Authors' Addresses
Alia Atlas (editor) Alia Atlas (editor)
Juniper Networks Juniper Networks
10 Technology Park Drive 10 Technology Park Drive
Westford, MA 01886 Westford, MA 01886
USA USA
Email: akatlas@juniper.net Email: akatlas@juniper.net
Thomas D. Nadeau (editor)
Thomas D. Nadeau
Juniper Networks Juniper Networks
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
USA USA
Email: tnadeau@juniper.net Email: tnadeau@juniper.net
Dave Ward Dave Ward
Cisco Systems Cisco Systems
Tasman Drive Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: wardd@cisco.com Email: wardd@cisco.com
 End of changes. 17 change blocks. 
37 lines changed or deleted 43 lines changed or added

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