draft-ietf-i2rs-problem-statement-00.txt   draft-ietf-i2rs-problem-statement-01.txt 
Network Working Group A. Atlas, Ed. Network Working Group A. Atlas, Ed.
Internet-Draft T. Nadeau, Ed. Internet-Draft Juniper Networks
Intended status: Informational Juniper Networks Intended status: Informational T. Nadeau, Ed.
Expires: February 17, 2014 D. Ward Expires: November 2, 2014 Brocade
D. Ward
Cisco Systems Cisco Systems
August 16, 2013 May 1, 2014
Interface to the Routing System Problem Statement Interface to the Routing System Problem Statement
draft-ietf-i2rs-problem-statement-00 draft-ietf-i2rs-problem-statement-01
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 network applications to have access to and control In order to enable network applications to have access to and control
skipping to change at page 1, line 48 skipping to change at page 1, line 49
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 February 17, 2014. This Internet-Draft will expire on November 2, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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 . . . 5 3. Standard Data-Models of Routing State for Installation . . . 5
4. Learning Router Information . . . . . . . . . . . . . . . . . 5 4. Learning Router Information . . . . . . . . . . . . . . . . . 6
5. Desired Aspects of a Protocol for I2RS . . . . . . . . . . . 6 5. Desired Aspects of a Protocol for I2RS . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 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
skipping to change at page 3, line 18 skipping to change at page 3, line 18
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, the term
discuss and use the term "applications". This is meant to refer to "applications" is used. This is meant to refer to an executable
an executable program of some sort that has access to a network, such program of some sort that has access to a network, such as an IP or
as an IP network. MPLS 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 between multiple components within a protocols involves interactions between multiple components within a
device. Some of these components are virtual while some are device. Some of these components are virtual while some are
physical; it may be desirable for many, or even all of these physical; it may be desirable for many, or even all of these
components to be made available to be managed and manipulated by components to be made available to be managed and manipulated by
applications, given that appropriate access, authentication, and applications, given that appropriate access, authentication, and
policy hurdles have been crossed. The management of only some of policy hurdles have been crossed. The management of only some of
skipping to change at page 4, line 13 skipping to change at page 4, line 13
| +---------------+ +-------------+ | +---------------+ +-------------+
| | I2RS Client |<------->| Other I2RS | | | I2RS Client |<------->| Other I2RS |
| +---------------+ | Agents | | +---------------+ | Agents |
| ^ +-------------+ | ^ +-------------+
|________________ | |________________ |
| | <== I2RS Protocol | | <== I2RS Protocol
| | | |
...........................|..|.................................. ...........................|..|..................................
. v v . . v v .
. +*************+ +---------------+ +****************+ . . +*************+ +---------------+ +****************+ .
. * Policy * | | * Routing & * . . * Policy * | | * Routing & * .
. * Database *<***>| I2RS Agent |<****>* Signaling * . . * Database *<***>| I2RS Agent |<****>* Signaling * .
. +*************+ | | * Protocols * . . +*************+ | | * Protocols * .
. +---------------+ +****************+ . . +---------------+ +****************+ .
. ^ ^ ^ ^ . . ^ ^ ^ ^ .
. +*************+ * * * * . . +*************+ * * * * .
. * Topology * * * * * . . * Topology * * * * * .
. * Database *<*******+ * * v . . * Database *<*******+ * * v .
. +*************+ * * +****************+ . . +*************+ * * +****************+ .
. * +********>* RIB Manager * . . * +********>* RIB Manager * .
. * +****************+ . . * +****************+ .
. * ^ . . * ^ .
skipping to change at page 4, line 48 skipping to change at page 4, line 48
<**> interfaces NOT within the scope of I2RS <**> interfaces NOT within the scope of I2RS
+**+ objects NOT within the scope of I2RS +**+ objects NOT within the scope of I2RS
.... boundary of a router participating in the I2RS .... boundary of a router participating in the I2RS
Figure 1: I2RS model and Problem Area Figure 1: I2RS model and Problem Area
A critical aspect of I2RS is defining a suitable protocol or A critical aspect of I2RS is defining a suitable protocol or
protocols to carry messages between the I2RS Clients and the I2RS protocols to carry messages between the I2RS Clients and the I2RS
Agent, and defining the data-models for use with those I2RS Agent, and defining the data-models for use with those I2RS
protocol(s). The data models should translate into a clear transfer protocol(s). The protocol should provide the key features specified
in Section 5. The data models should translate into a clear transfer
syntax that is straightforward for applications to use (e.g., a Web syntax that is straightforward for applications to use (e.g., a Web
Services design paradigm), and should provide the key features Services design paradigm). The information transfer should use
specified in Section 5. The information should use existing existing transport protocols to provide the reliability, security,
transport protocols to provide the reliability, security, and and timeliness appropriate for the particular data.
timeliness appropriate for the particular data.
The second critical aspect are semantic-aware data-models for The second critical aspect are semantic-aware data-models for
information in the routing system and in a topology database. The information in the routing system and in a topology database. The
data-model should describe the meaning and relationships of the data-model should describe the meaning and relationships of the
modeled items. The data-models should be separable across different modeled items. The data-models should be separable across different
features of the managed components, versioned, and extendable. An features of the managed components, versioned, and extendable. As
application should be able to combine data from individual routing shown in Figure 1, I2RS needs to interact with several logical
elements to provide network-wide data-model(s). components of the routing element: policy database, topology
database, subscription and configuration for dynamic measuresments/
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).
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 and recursion (e.g. a prefix X is routed like prefix Y) indirection and recursion (e.g. a prefix X is routed like prefix Y)
as well as different types of tunneling and encapsulation. The as well as different types of tunneling and encapsulation. The
skipping to change at page 8, line 8 skipping to change at page 8, line 12
subject to authentication and authorization. Such communications subject to authentication and authorization. Such communications
must also have its integrity protected. must also have its integrity protected.
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, and Kwang-koog Lee for their suggestions and Carlos Pignataro, Kwang-koog Lee, Linda Dunbar, and Sue Hares for
review. 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 10, line 5 skipping to change at page 10, line 5
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 (editor)
Juniper Networks Brocade
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
USA
Email: tnadeau@juniper.net Email: tnadeau@lucidvision.com
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. 14 change blocks. 
29 lines changed or deleted 33 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/