An Architecture for the Interface to the Routing System
draft-ietf-i2rs-architecture-04

Internet-Draft                  I2RS Arch                      June 2014

      further operations are applied, and an error is returned
      indicating the failure.  This is useful if there are dependencies
      among the operations and they can be topologically sorted.

   Perform all storing errors:   In this case, the I2RS Agent will
      attempt to perform all the operations in the message, and will
      return error indications for each one that fails.  This is useful
      when there is no dependency across the operation, or where the
      client would prefer to sort out the effect of errors on its own.

   In the interest of robustness and clarity of protocol state, the
   protocol will include an explicit reply to modification or write
   operations even when they fully succeed.

8.  Operational and Manageability Considerations

   In order to facilitate troubleshooting of routing elements
   implementing I2RS agents, those routing elements should provide for a
   mechanism to show actively provisioned I2RS state and other I2RS
   Agent internal information.  Note that this information may contain
   highly sensitive material subject to the Security Considerations of
   any data models implemented by that Agent and thus must be protected
   according to those considerations.  Preferably, this mechanism should
   use a different privileged means other than simply connecting as an
   I2RS client to learn the data.  Using a different mechanism should
   improve traceability and failure management.

   Manageability plays a key aspect in I2RS.  Some initial examples
   include:

   Resource Limitations:   Using I2RS, applications can consume
      resources, whether those be operations in a time-frame, entries in
      the RIB, stored operations to be triggered, etc.  The ability to
      set resource limits based upon authorization is important.

   Configuration Interactions:   The interaction of state installed via
      the I2RS and via a router's configuration needs to be clearly
      defined.  As described in this architecture, a simple priority
      that is configured is used to provide sufficient policy
      flexibility.

9.  IANA Considerations

   This document includes no request to IANA.

Atlas, et al.           Expires December 25, 2014              [Page 29]
Internet-Draft                  I2RS Arch                      June 2014

10.  Acknowledgements

   Significant portions of this draft came from draft-ward-i2rs-
   framework-00 and draft-atlas-i2rs-policy-framework-00.

   The authors would like to thank Nitin Bahadur, Shane Amante, Ed
   Crabbe, Ken Gray, Carlos Pignataro, Wes George, Ron Bonica, Joe
   Clarke, Juergen Schoenwalder, Jeff Haas, Jamal Hadi Salim, Scott
   Brim, Thomas Narten, Dean Bogdanovi, Tom Petch, Robert Raszuk, and
   Sriganesh Kini for their suggestions and review.

11.  Informative References

   [I-D.ietf-i2rs-problem-statement]
              Atlas, A., Nadeau, T., and D. Ward, "Interface to the
              Routing System Problem Statement", draft-ietf-i2rs-
              problem-statement-03 (work in progress), June 2014.

   [I-D.ietf-idr-ls-distribution]
              Gredler, H., Medved, J., Previdi, S., Farrel, A., and S.
              Ray, "North-Bound Distribution of Link-State and TE
              Information using BGP", draft-ietf-idr-ls-distribution-05
              (work in progress), May 2014.

   [I-D.ietf-netconf-restconf]
              Bierman, A., Bjorklund, M., Watsen, K., and R. Fernando,
              "RESTCONF Protocol", draft-ietf-netconf-restconf-00 (work
              in progress), March 2014.

   [RFC6241]  Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
              Bierman, "Network Configuration Protocol (NETCONF)", RFC
              6241, June 2011.

   [RFC6536]  Bierman, A. and M. Bjorklund, "Network Configuration
              Protocol (NETCONF) Access Control Model", RFC 6536, March
              2012.

Authors' Addresses

   Alia Atlas
   Juniper Networks
   10 Technology Park Drive
   Westford, MA  01886
   USA

   Email: akatlas@juniper.net

Atlas, et al.           Expires December 25, 2014              [Page 30]
Internet-Draft                  I2RS Arch                      June 2014

   Joel Halpern
   Ericsson

   Email: Joel.Halpern@ericsson.com

   Susan Hares
   Hickory Hill Consulting

   Email: shares@ndzh.com

   Dave Ward
   Cisco Systems
   Tasman Drive
   San Jose, CA  95134
   USA

   Email: wardd@cisco.com

   Thomas D. Nadeau
   Brocade

   Email: tnadeau@lucidvision.com

Atlas, et al.           Expires December 25, 2014              [Page 31]