draft-ietf-i2rs-architecture-04.txt   draft-ietf-i2rs-architecture-05.txt 
Network Working Group A. Atlas Network Working Group A. Atlas
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Informational J. Halpern Intended status: Informational J. Halpern
Expires: December 25, 2014 Ericsson Expires: January 21, 2015 Ericsson
S. Hares S. Hares
Hickory Hill Consulting Hickory Hill Consulting
D. Ward D. Ward
Cisco Systems Cisco Systems
T. Nadeau T. Nadeau
Brocade Brocade
June 23, 2014 July 20, 2014
An Architecture for the Interface to the Routing System An Architecture for the Interface to the Routing System
draft-ietf-i2rs-architecture-04 draft-ietf-i2rs-architecture-05
Abstract Abstract
This document describes an architecture for a standard, programmatic This document describes an architecture for a standard, programmatic
interface for state transfer in and out of the internet routing interface for state transfer in and out of the internet routing
system. It describes the basic architecture, the components, and system. It describes the basic architecture, the components, and
their interfaces with particular focus on those to be standardized as their interfaces with particular focus on those to be standardized as
part of I2RS. part of I2RS.
Status of This Memo Status of This Memo
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 December 25, 2014. This Internet-Draft will expire on January 21, 2015.
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 12, line 32 skipping to change at page 12, line 32
channel by which it can validate both the identity and permissions channel by which it can validate both the identity and permissions
associated with an I2RS Client. To support numerous and speedy associated with an I2RS Client. To support numerous and speedy
interactions between the I2RS Agent and I2RS Client, it is assumed interactions between the I2RS Agent and I2RS Client, it is assumed
that the I2RS Agent can also cache that particular I2RS Clients are that the I2RS Agent can also cache that particular I2RS Clients are
trusted and their associated authorized scope. This implies that the trusted and their associated authorized scope. This implies that the
permission information may be old either in a pull model until the permission information may be old either in a pull model until the
I2RS Agent re-requests it, or in a push model until the I2RS Agent re-requests it, or in a push model until the
authentication and authorization channel can notify the I2RS Agent of authentication and authorization channel can notify the I2RS Agent of
changes. changes.
Mutual authentication between the I2RS Client and I2RS Agent is
required. An I2RS Client must be able to trust that the I2RS Agent
is attached to the relevant Routing Element so that write/modify
operations are correctly applied and so that information received
from the I2RS Agent can be trusted by the I2RS Client.
An I2RS Client is not automatically trustworthy. It has identity An I2RS Client is not automatically trustworthy. It has identity
information and applications using that I2RS Client should be aware information and applications using that I2RS Client should be aware
of the scope limitations of that I2RS Client. If the I2RS Client is of the scope limitations of that I2RS Client. If the I2RS Client is
acting as a broker for multiple applications, managing the security, acting as a broker for multiple applications, managing the security,
authentication and authorization for that communication is out of authentication and authorization for that communication is out of
scope; nothing prevents I2RS and a separate authentication and scope; nothing prevents I2RS and a separate authentication and
authorization channel from being used. Regardless of mechanism, an authorization channel from being used. Regardless of mechanism, an
I2RS Client that is acting as a broker is responsible for determining I2RS Client that is acting as a broker is responsible for determining
that applications using it are trusted and permitted to make the that applications using it are trusted and permitted to make the
particular requests. particular requests.
skipping to change at page 16, line 5 skipping to change at page 16, line 5
For scalability and generality, the I2RS agent may be responsible for For scalability and generality, the I2RS agent may be responsible for
collecting and delivering large amounts of data from various parts of collecting and delivering large amounts of data from various parts of
the routing element. Those parts may or may not actually be part of the routing element. Those parts may or may not actually be part of
a single physical device. Thus, for scalability and robustness, it a single physical device. Thus, for scalability and robustness, it
is important that the architecture allow for a distributed set of is important that the architecture allow for a distributed set of
reporting components providing collected data from the I2RS agent reporting components providing collected data from the I2RS agent
back to the relevant I2RS clients. There may be multiple I2RS Agents back to the relevant I2RS clients. There may be multiple I2RS Agents
within the same router. In such a case, they must have non- within the same router. In such a case, they must have non-
overlapping sets of information which they manipulate. overlapping sets of information which they manipulate.
To facilitate operations, deployment and troubleshooting, it is
important that traceability of the I2RS Agent's requests and actions
be supported via a common data model.
6.2. I2RS State Storage 6.2. I2RS State Storage
State modification requests are sent to the I2RS agent in a routing State modification requests are sent to the I2RS agent in a routing
element by I2RS clients. The I2RS agent is responsible for applying element by I2RS clients. The I2RS agent is responsible for applying
these changes to the system, subject to the authorization discussed these changes to the system, subject to the authorization discussed
above. The I2RS agent will retain knowledge of the changes it has above. The I2RS agent will retain knowledge of the changes it has
applied, and the client on whose behalf it applied the changes. The applied, and the client on whose behalf it applied the changes. The
I2RS agent will also store active subscriptions. These sets of data I2RS agent will also store active subscriptions. These sets of data
form the I2RS data store. This data is retained by the agent until form the I2RS data store. This data is retained by the agent until
the state is removed by the client, overridden by some other the state is removed by the client, overridden by some other
skipping to change at page 30, line 13 skipping to change at page 30, line 13
This document includes no request to IANA. This document includes no request to IANA.
10. Acknowledgements 10. Acknowledgements
Significant portions of this draft came from draft-ward-i2rs- Significant portions of this draft came from draft-ward-i2rs-
framework-00 and draft-atlas-i2rs-policy-framework-00. framework-00 and draft-atlas-i2rs-policy-framework-00.
The authors would like to thank Nitin Bahadur, Shane Amante, Ed The authors would like to thank Nitin Bahadur, Shane Amante, Ed
Crabbe, Ken Gray, Carlos Pignataro, Wes George, Ron Bonica, Joe Crabbe, Ken Gray, Carlos Pignataro, Wes George, Ron Bonica, Joe
Clarke, Juergen Schoenwalder, Jeff Haas, Jamal Hadi Salim, Scott Clarke, Juergen Schoenwalder, Jeff Haas, Jamal Hadi Salim, Scott
Brim, Thomas Narten, Dean Bogdanovi, Tom Petch, Robert Raszuk, and Brim, Thomas Narten, Dean Bogdanovi, Tom Petch, Robert Raszuk,
Sriganesh Kini for their suggestions and review. Sriganesh Kini, and John Mattsson for their suggestions and review.
11. Informative References 11. Informative References
[I-D.ietf-i2rs-problem-statement] [I-D.ietf-i2rs-problem-statement]
Atlas, A., Nadeau, T., and D. Ward, "Interface to the Atlas, A., Nadeau, T., and D. Ward, "Interface to the
Routing System Problem Statement", draft-ietf-i2rs- Routing System Problem Statement", draft-ietf-i2rs-
problem-statement-03 (work in progress), June 2014. problem-statement-04 (work in progress), June 2014.
[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-05 Information using BGP", draft-ietf-idr-ls-distribution-05
(work in progress), May 2014. (work in progress), May 2014.
[I-D.ietf-netconf-restconf] [I-D.ietf-netconf-restconf]
Bierman, A., Bjorklund, M., Watsen, K., and R. Fernando, Bierman, A., Bjorklund, M., Watsen, K., and R. Fernando,
"RESTCONF Protocol", draft-ietf-netconf-restconf-00 (work "RESTCONF Protocol", draft-ietf-netconf-restconf-01 (work
in progress), March 2014. in progress), July 2014.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)", RFC Bierman, "Network Configuration Protocol (NETCONF)", RFC
6241, June 2011. 6241, June 2011.
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", RFC 6536, March Protocol (NETCONF) Access Control Model", RFC 6536, March
2012. 2012.
Authors' Addresses Authors' Addresses
 End of changes. 9 change blocks. 
9 lines changed or deleted 19 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/