--- 1/draft-ietf-i2rs-architecture-03.txt 2014-06-23 16:14:25.656945893 -0700 +++ 2/draft-ietf-i2rs-architecture-04.txt 2014-06-23 16:14:25.724947544 -0700 @@ -1,50 +1,50 @@ Network Working Group A. Atlas Internet-Draft Juniper Networks Intended status: Informational J. Halpern -Expires: November 16, 2014 Ericsson +Expires: December 25, 2014 Ericsson S. Hares Hickory Hill Consulting D. Ward Cisco Systems T. Nadeau Brocade - May 15, 2014 + June 23, 2014 An Architecture for the Interface to the Routing System - draft-ietf-i2rs-architecture-03 + draft-ietf-i2rs-architecture-04 Abstract This document describes an architecture for a standard, programmatic - interface for state transfer in and out of the Internet's routing + interface for state transfer in and out of the internet routing system. It describes the basic architecture, the components, and their interfaces with particular focus on those to be standardized as part of I2RS. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on November 16, 2014. + This Internet-Draft will expire on December 25, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -90,97 +90,98 @@ 6.4.5.4. Object Relationships . . . . . . . . . . . . . . 23 6.4.5.4.1. Initialization . . . . . . . . . . . . . . . 23 6.4.5.4.2. Correlation Identification . . . . . . . . . 23 6.4.5.4.3. Object References . . . . . . . . . . . . . . 24 6.4.5.4.4. Active Reference . . . . . . . . . . . . . . 24 7. I2RS Client Agent Interface . . . . . . . . . . . . . . . . . 24 7.1. One Control and Data Exchange Protocol . . . . . . . . . 24 7.2. Communication Channels . . . . . . . . . . . . . . . . . 24 7.3. Capability Negotiation . . . . . . . . . . . . . . . . . 25 7.4. Identity and Security Role . . . . . . . . . . . . . . . 25 - 7.4.1. Client Redundancy . . . . . . . . . . . . . . . . . . 25 + 7.4.1. Client Redundancy . . . . . . . . . . . . . . . . . . 26 7.5. Connectivity . . . . . . . . . . . . . . . . . . . . . . 26 - 7.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 26 + 7.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 27 7.7. Information collection . . . . . . . . . . . . . . . . . 27 - 7.8. Multi-Headed Control . . . . . . . . . . . . . . . . . . 27 + 7.8. Multi-Headed Control . . . . . . . . . . . . . . . . . . 28 7.9. Transactions . . . . . . . . . . . . . . . . . . . . . . 28 - 8. Manageability Considerations . . . . . . . . . . . . . . . . 28 + 8. Operational and Manageability Considerations . . . . . . . . 29 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 - 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 - 11. Informative References . . . . . . . . . . . . . . . . . . . 29 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 + 11. Informative References . . . . . . . . . . . . . . . . . . . 30 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 1. Introduction - Routers that form the Internet's routing infrastructure maintain - state at various layers of detail and function. For example, a - typical router maintains a Routing Information Base (RIB), and - implements routing protocols such as OSPF, ISIS, and BGP to exchange - protocol state and other information about the state of the network - with other routers. + Routers that form the internet routing infrastructure maintain state + at various layers of detail and function. For example, a typical + router maintains a Routing Information Base (RIB), and implements + routing protocols such as OSPF, ISIS, and BGP to exchange protocol + state and other information about the state of the network with other + routers. - Routers know how to convert all of this information into the - forwarding operations that are installed in the forwarding plane. - The forwarding plane and the specified forwarding operations then + Routers convert all of this information into forwarding entries which + are then used to forward packets and flows between network elements. + The forwarding plane and the specified forwarding entries then contain active state information that describes the expected and observed operational behavior of the router and which is also needed by the network applications. Network-oriented applications require easy access to this information to learn the network topology, to verify that programmed state is installed in the forwarding plane, to measure the behavior of various flows, routes or forwarding entries, as well as to understand the configured and active states of the router. This document sets out an architecture for a common, standards-based interface to this information. This Interface to the Routing System (I2RS) facilitates control and observation of the routing-related state (for example, a Routing Element RIB manager's state), as well as enabling network-oriented applications to be built on top of today's routed networks. The I2RS is a programmatic asynchronous - interface for transferring state into and out of the Internet's - routing system. This I2RS architecture recognizes that the routing - system and a router's OS provide useful mechanisms that applications - could harness to accomplish application-level goals. + interface for transferring state into and out of the internet routing + system. This I2RS architecture recognizes that the routing system + and a router's OS provide useful mechanisms that applications could + harness to accomplish application-level goals. Fundamental to the I2RS are clear data models that define the semantics of the information that can be written and read. The I2RS provides a framework for registering for and requesting the appropriate information for each particular application. The I2RS provides a way for applications to customize network behavior while leveraging the existing routing system as desired. Although the I2RS architecture is general enough to support information and data models for a variety of data, and aspects of the I2RS solution may be useful in domain other than routing, I2RS and this document are specifically focused on an interface for routing data. 1.1. Drivers for the I2RS Architecture There are four key drivers that shape the I2RS architecture. First is the need for an interface that is programmatic, asynchronous, and - offers fast, interactive access. Second is the access to structured - information and state that is frequently not directly configurable or - modeled in existing implementations or configuration protocols. - Third is the ability to subscribe to structured, filterable event - notifications from the router. Fourth, the operation of I2RS is to - be data-model driven to facilitate extensibility and provide standard - data-models to be used by network applications. + offers fast, interactive access for atomic operations. Second is the + access to structured information and state that is frequently not + directly configurable or modeled in existing implementations or + configuration protocols. Third is the ability to subscribe to + structured, filterable event notifications from the router. Fourth, + the operation of I2RS is to be data-model driven to facilitate + extensibility and provide standard data-models to be used by network + applications. I2RS is described as an asynchronous programmatic interface, the key properties of which are described in Section 5 of [I-D.ietf-i2rs-problem-statement]. - The I2RS facilitates obtaining information from the router. The I2RS - provides the ability to not only read specific information, but also - to subscribe to targeted information streams and filtered and - thresholded events. + The I2RS architecture facilitates obtaining information from the + router. The I2RS architecture provides the ability to not only read + specific information, but also to subscribe to targeted information + streams and filtered and thresholded events. Such an interface also facilitates the injection of ephemeral state into the routing system. A non-routing protocol or application could inject state into a routing element via the state-insertion functionality of the I2RS and that state could then be distributed in a routing or signaling protocol and/or be used locally (e.g. to program the co-located forwarding plane). I2RS will only permit modification of state that would be safe, conceptually, to modify via local configuration; no direct manipulation of protocol-internal dynamically determined data is envisioned. @@ -190,21 +191,22 @@ Figure 1 shows the basic architecture for I2RS between applications using I2RS, their associated I2RS Clients, and I2RS Agents. Applications access I2RS services through I2RS clients. A single client can provide access to one or more applications. In the figure, Clients A and B provide access to a single application, while Client P provides access to multiple applications. Applications can access I2RS services through local or remote clients. In the figure, Applicatons A and B access I2RS services through local clients, while Applications C, D and E access I2RS - services through a remote client. + services through a remote client. The details of how applications + communicate with a remote client is out of scope for I2RS. An I2RS Client can access one or more I2RS agents. In the figure, Clients B and P access I2RS Agents 1 and 2. Likewise, an I2RS Agent can provide service to one or more clients. In the figure, I2RS Agent 1 provides services to Clients A, B and P while Agent 2 provides services to only Clients B and P. I2RS agents and clients communicate with one another using an asynchronous protocol. Therefore, a single client can post multiple simultaneous requests, either to a single agent or to multiple @@ -275,51 +277,51 @@ * Routing Element 1 * * Routing Element 2 * ******************************** ******************************** Figure 1: Architecture of I2RS clients and agents Routing Element: A Routing Element implements some subset of the routing system. It does not need to have a forwarding plane associated with it. Examples of Routing Elements can include: * A router with a forwarding plane and RIB Manager that runs - ISIS, OSPF, BGP, PIM, etc. + ISIS, OSPF, BGP, PIM, etc., - * A server that runs BGP as a Route Reflector + * A BGP speaker acting as a Route Reflector, * An LSR that implements RSVP-TE, OSPF-TE, and PCEP and has a - forwarding plane and associated RIB Manager. + forwarding plane and associated RIB Manager, * A server that runs ISIS, OSPF, BGP and uses ForCES to control a - remote forwarding plane. + remote forwarding plane, A Routing Element may be locally managed, whether via CLI, SNMP, or NETCONF. Routing and Signaling: This block represents that portion of the - Routing Element that implements part of the Internet routing + Routing Element that implements part of the internet routing system. It includes not merely standardized protocols (i.e. IS- IS, OSPF, BGP, PIM, RSVP-TE, LDP, etc.), but also the RIB Manager layer. Local Config: A Routing Element will provide the ability to configure and manage it. The Local Config may be provided via a combination of CLI, NETCONF, SNMP, etc. The black box behavior for interactions between the state that I2RS installs into the routing element and the Local Config must be defined. Dynamic System State: An I2RS agent needs access to state on a routing element beyond what is contained in the routing subsystem. - Such state may include various counters, statistics, and local - events. This is the subset of operational state that is needed by - network applications based on I2RS that is not contained in the - routing and signaling information. How this information is + Such state may include various counters, statistics, flow data, + and local events. This is the subset of operational state that is + needed by network applications based on I2RS that is not contained + in the routing and signaling information. How this information is provided to the I2RS agent is out of scope, but the standardized information and data models for what is exposed are part of I2RS. Static System State: An I2RS agent needs access to static state on a routing element beyond what is contained in the routing subsystem. An example of such state is specifying queueing behavior for an interface or traffic. How the I2RS agent modifies or obtains this information is out of scope, but the standardized information and data models for what is exposed are part of I2RS. @@ -357,22 +359,22 @@ In contrast, although multiple I2RS clients may need to supply data into the same list (e.g. a prefix or filter list), this is not considered an error and must be correctly handled. The nuances so that writers do not normally collide should be handled in the information models. The architectural goal for the I2RS is that such errors should produce predictable behaviors, and be reportable to interested clients. The details of the associated policy is discussed in Section 7.8. The same policy mechanism (simple priority per I2RS - client) applies to interactions between the I2RS agent and the CLI/ - SNMP/NETCONF as described in Section 6.3. + client) applies to interactions between the I2RS agent and the + CLI/SNMP/NETCONF as described in Section 6.3. In addition it must be noted that there may be indirect interactions between write operations. A basic example of this is when two different but overlapping prefixes are written with different forwarding behavior. Detection and avoidance of such interactions is outside the scope of the I2RS work and is left to agent design and implementation. 2. Terminology @@ -385,24 +387,23 @@ contacted by I2RS clients. client or I2RS Client: A client implements the I2RS protocol, uses it to communicate with I2RS Agents, and uses the I2RS services to accomplish a task. It interacts with other elements of the policy, provisioning, and configuration system by means outside of the scope of the I2RS effort. It interacts with the I2RS agents to collect information from the routing and forwarding system. Based on the information and the policy oriented interactions, the I2RS client may also interact with I2RS agents to modify the state - of the routing system the client interacts with to achieve - operational goals. An I2RS client can be seen as the part of an - application that uses and supports I2RS and could be a software - library. + of their associated routing systems to achieve operational goals. + An I2RS client can be seen as the part of an application that uses + and supports I2RS and could be a software library. service or I2RS Service: For the purposes of I2RS, a service refers to a set of related state access functions together with the policies that control their usage. The expectation is that a service will be represented by a data-model. For instance, 'RIB service' could be an example of a service that gives access to state held in a device's RIB. read scope: The set of information which the I2RS client is authorized to read. The read scope specifies the access @@ -461,24 +462,28 @@ There have been many efforts over the years to improve the access to the information available to the routing and forwarding system. Making such information visible and usable to network management and applications has many well-understood benefits. There are two related challenges in doing so. First, the quantity and diversity of information potentially available is very large. Second, the variation both in the structure of the data and in the kinds of operations required tends to introduce protocol complexity. - Having noted that, it is also critical to the utility of I2RS that it - be easily deployable and robust. Complexity in the protocol hinders - implementation, robustness, and deployability. Also, data models - complexity may complicate extensibility. + While the types of operations contemplated here are complex in their + nature, it is critical that I2RS be easily deployable and robust. + Adding complexity beyond what is needed to satisfy well known and + understood requirements would hinder the ease of implementation, the + robustness of the protocol, and the deployability of the protocol. + Overly complex data models tend to ossify information sets by + attempting to describe and close off every possible option, + complicating extensibility. Thus, one of the key aims for I2RS is the keep the protocol and modeling architecture simple. So for each architectural component or aspect, we ask ourselves "do we need this complexity, or is the behavior merely nice to have?" Protocol parsimony is clearly a goal. 3.2. Extensibility Naturally, extensibility of the protocol and data model is very important. In particular, given the necessary scope limitations of @@ -556,21 +561,21 @@ particular requests. Different levels of integrity, confidentiality, and replay protection are relevant for different aspects of I2RS. The primary communication channel that is used for client authentication and then used by the client to write data requires integrity, privacy and replay protection. Appropriate selection of a default required transport protocol is the preferred way of meeting these requirements. - Other communications via I2RS will not require integrity, + Other communications via I2RS may not require integrity, confidentiality, and replay protection. For instance, if an I2RS Client subscribes to an information stream of prefix announcements from OSPF, those may require integrity but probably not confidentiality or replay protection. Similarly, an information stream of interface statistics may not even require guaranteed delivery. In Section 7.2, more reasoning for multiple communication channels is provided. From the security perspective, it is critical to realize that an I2RS Agent may open a new communication channel based upon information provided by an I2RS Client (as described in Section 7.2). For example, a I2RS client may request notifications @@ -723,21 +728,21 @@ It is expected that an I2RS Agent may fail independently of the associated routing element. This could happen because I2RS is disabled on the routing element or because the I2RS Agent, a separate process or even running on a separate processor, experiences an unexpected failure. Just as routing state learned from a failed source is removed, the ephemeral I2RS state will usually be removed shortly after the failure is detected or as part of a graceful shutdown process. To handle I2RS Agent failure, the I2RS Agent must use two different notifications. - NOTIFICIATON_I2RS_AGENT_STARTING: This notification identifies that + NOTIFICATION_I2RS_AGENT_STARTING: This notification identifies that the associated I2RS Agent has started. It includes an agent-boot- count that indicates how many times the I2RS Agent has restarted since the associated routing element restarted. The agent-boot- count allows an I2RS Client to determine if the I2RS Agent has restarted. NOTIFICATION_I2RS_AGENT_TERMINATING: This notification reports that the associated I2RS Agent is shutting down gracefully. Ephemeral state will be removed. It can optionally include a timestamp indicating when the I2RS Agent will shutdown. Use of this @@ -862,23 +867,23 @@ * +-------------------+ +---------------+ * ************************************************************** Figure 2: Anticipated I2RS Services There are relationships between different I2RS Services - whether those be the need for the RIB to refer to specific interfaces, the desire to refer to common complex types (e.g. links, nodes, IP addresses), or the ability to refer to implementation-specific functionality (e.g. pre-defined templates to be applied to interfaces - or for QoS behaviors that traffic is direct into). - Section Section 6.4.5 discussing information modeling constructs and - the range of relationship types that are applicable. + or for QoS behaviors that traffic is direct into). Section 6.4.5 + discusses information modeling constructs and the range of + relationship types that are applicable. 6.4.1. Routing and Label Information Bases Routing elements may maintain one or more Information Bases. Examples include Routing Information Bases such as IPv4/IPv6 Unicast or IPv4/IPv6 Multicast. Another such example includes the MPLS Label Information Bases, per-platform- or per-interface." This functionality, exposed via an I2RS Service, must interact smoothly with the same mechanisms that the routing element already uses to handle RIB input from multiple sources, so as to safely change the @@ -918,22 +923,22 @@ For example, the interaction with OSPF might include modifying the local routing element's link metrics, announcing a locally-attached prefix, or reading some of the OSPF link-state database. However, direct modification of the link-state database MUST NOT be allowed in order to preserve network state consistency. 6.4.3. MPLS I2RS Services will be needed to expose the protocols that create - transport LSPs (e.g. LDP and RSVP-TE) as well as protocols (e.g. BGP, - LDP) that provide MPLS-based services (e.g. pseudowires, L3VPNs, + transport LSPs (e.g. LDP and RSVP-TE) as well as protocols (e.g. + BGP, LDP) that provide MPLS-based services (e.g. pseudowires, L3VPNs, L2VPNs, etc). This should include all local information about LSPs originating in, transiting, or terminating in this Routing Element. 6.4.4. Policy and QoS Mechanisms Many network elements have separate policy and QoS mechanisms, including knobs which affect local path computation and queue control capabilities. These capabilities vary widely across implementations, and I2RS cannot model the full range of information collection or manipulation of these attributes. A core set does need to be @@ -973,21 +978,21 @@ represent variations and additional capabilities. When applicable, there may be several levels of refinement. The I2RS protocol can then provide mechanisms to allow an I2RS client to determine which classes a given I2RS Agent has available. Clients which only want basic capabilities can operate purely in terms of base or parent classes, while a client needing more details or features can work with the supported sub-class(es). As part of I2RS information modeling, clear rules should be specified for how the parent class and subclass can relate; for example, what - changes a subclass can make to its parent? The description of such + changes can a subclass make to its parent? The description of such rules should be done so that it can apply across data modeling tools until the I2RS data modeling language is selected. 6.4.5.2. Managing Variation: Optionality I2RS Information Models must be clear about what aspects are optional. For instance, must an instance of a class always contain a particular data field X? If so, must the client provide a value for X when creating the object or is there a well-defined default value? From the Routing Element perspective, in the above example, each @@ -1085,43 +1090,53 @@ need to immediately propagate to the Tunnel MTU, then the tunnel is actively coupled to the link interface. This kind of active state coupling implies some sort of internal bookkeeping to ensure consistency, often conceptualized as a subscription model across objects. 7. I2RS Client Agent Interface 7.1. One Control and Data Exchange Protocol - This I2RS Architecture presumes that there is one I2RS protocol for - control and data exchange. This helps meet the goal of simplicity - and thereby enhances deployability. Whether such a protocol is built - upon extending existing mechanisms or requires a new mechanism is - under active investigation. That protocol may use several underlying - transports (TCP, SCTP, DCCP), with suitable authentication and - integrity protection mechanisms. These different transports can - support different types of communication (e.g. control, reading, - notifications, and information collection) and different sets of - data. Whatever transport is used for the data exchange, it must also - support suitable congestion control mechanisms. + As agreed by the I2RS working group, this I2RS architecture assumes + that there is a single I2RS protocol for control and data exchange; + that protocol will be based on NETCONF[RFC6241] and RESTCONF + [I-D.ietf-netconf-restconf]. This helps meet the goal of simplicity + and thereby enhances deployability. That protocol may need to use + several underlying transports (TCP, SCTP, DCCP), with suitable + authentication and integrity protection mechanisms. These different + transports can support different types of communication (e.g. + control, reading, notifications, and information collection) and + different sets of data. Whatever transport is used for the data + exchange, it must also support suitable congestion control + mechanisms. The transports chosen should be operator and implementor + friendly to ease adoption. 7.2. Communication Channels Multiple communication channels and multiple types of communication channels are required. There may be a range of requirements (e.g. confidentiality, reliability), and to support the scaling there may need to be channels originating from multiple sub-components of a routing element and/or to multiple parts of an I2RS client. All such communication channels will use the same higher level protocol. Use of additional channels for communication will be coordinated between the I2RS client and the I2RS agent. + I2RS protocol communication can be delivered in-band via the routing + system's data plane. I2RS protocol communication might be delivered + out-of-band via a management interface. Depending on what operations + are requested, it is possible for the I2RS protocol communication to + cause the in-band communication channels to stop working; this could + cause the I2RS agent to become unreachable across that communication + channel. + 7.3. Capability Negotiation The support for different protocol capabilities and I2RS Services will vary across I2RS Clients and Routing Elements supporting I2RS Agents. Since each I2RS Service is required to include a capability model (see Section 6.4), negotiation at the protocol level can be restricted to protocol specifics and which I2RS Services are supported. Capability negotiation (such as which transports are supported beyond @@ -1249,24 +1264,24 @@ outside of this system the data to be manipulated within the network element is appropriately partitioned so that any given piece of information is only being manipulated by a single I2RS Client. Nonetheless, unexpected interactions happen and two (or more) I2RS clients may attempt to manipulate the same piece of data. This is considered an error case. This architecture does not attempt to determine what the right state of data should be when such a collision happens. Rather, the architecture mandates that there be decidable means by which I2RS Agents handle the collisions. The - mechanism for this is to have a simple priority associated with each - I2RS clients, and the highest priority change remains in effect. In - the case of priority ties, the first client whose attribution is - associated with the data will keep control. + mechanism for ensuring predictability is to have a simple priority + associated with each I2RS clients, and the highest priority change + remains in effect. In the case of priority ties, the first client + whose attribution is associated with the data will keep control. In order for this approach to multi-headed control to be useful for I2RS Clients, it is important that it be possible for an I2RS Client to register for changes to any changes made by I2RS to data that it may care about. This is included in the I2RS event mechanisms. This also needs to apply to changes made by CLI/NETCONF/SNMP within the write-scope of the I2RS Agent, as the same priority mechanism (even if it is "CLI always wins") applies there. The I2RS client may then respond to the situation as it sees fit. @@ -1296,21 +1311,32 @@ 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. Manageability Considerations +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 @@ -1323,49 +1349,59 @@ This document includes no request to IANA. 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, Jamal Hadi Salim, Scott Brim, and - Thomas Narten for their suggestions and review. + 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-01 (work in progress), May 2014. + 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-04 - (work in progress), November 2013. + 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 - Joel Halpern Ericsson Email: Joel.Halpern@ericsson.com Susan Hares Hickory Hill Consulting Email: shares@ndzh.com