draft-ietf-i2rs-problem-statement-01.txt   draft-ietf-i2rs-problem-statement-02.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: November 2, 2014 Brocade Expires: December 8, 2014 Brocade
D. Ward D. Ward
Cisco Systems Cisco Systems
May 1, 2014 June 6, 2014
Interface to the Routing System Problem Statement Interface to the Routing System Problem Statement
draft-ietf-i2rs-problem-statement-01 draft-ietf-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 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 49 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 November 2, 2014. This Internet-Draft will expire on December 8, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 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
skipping to change at page 2, line 31 skipping to change at page 2, line 31
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 . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
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
skipping to change at page 5, line 34 skipping to change at page 5, line 34
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
relevant MIB modules (for example [RFC4292]) lack the necessary relevant MIB modules (for example [RFC4292]) lack the necessary
generality and flexibility. In addition, by having I2RS focus generality and flexibility. In addition, by having I2RS focus
initially on interfaces to the RIB layer (e.g. RIB, LIB, multicast initially on interfaces to the RIB layer (e.g. RIB, LIB, multicast
RIB, policy-based routing), the ability to use routing indirection RIB, policy-based routing), the ability to use routing indirection
allows flexibility and functionality that can't be as easily obtained allows flexibility and functionality that can't be as easily obtained
at the 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.
skipping to change at page 7, line 6 skipping to change at page 7, line 6
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 via I2RS without being should be able to send multiple independent operations via I2RS
required to wait for each to complete before sending the next. without being 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
skipping to change at page 7, line 32 skipping to change at page 7, line 33
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, 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 (for example 10,000 per second to handle many individual
subscriber routes changing simultaneously).
Responsive: It should be possible to complete simple operations Responsive: Within a sub-second time-scale, it should be possible
within a sub-second time-scale. to complete simple operations (e.g. reading or writing a single
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
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
 End of changes. 9 change blocks. 
12 lines changed or deleted 15 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/