On 7/24/13 5:52 PM, Alia Atlas wrote: > Please review draft-atlas-i2rs-architecture-01 and comment on whether it > should be adopted by I2RS. Detailed technical conversation is also most > welcome. > > Authors: Are you aware of any IPR that applies to > draft-atlas-i2rs-architecture-01? Is so, has this IPR been disclosed in > compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for > more details). > > This WG call for adoption will complete on August 12.
I support adoption, but I do have some comments below (see JMC) Section 1: The I2RS, and therefore this document, are specifically focused on an interface for routing and forwarding data. JMC: Does an interface to the forwarding set the bar too broadly? Should this instead be an interface to the layer 3 forwarding data? Do we want to exclude this altogether in light of ForCES? Section 1.2: As can also be seen in Figure 1, an I2RS Agent may communicate with multiple clients. Each client may send the agent a variety of write operations. The handling of this situation has been a source of discussion in the working group. In order to keep the protocol simple, the current view is that two clients should not be attempting to write (modify) the same piece of information. Such collisions may happen, but are considered error cases that should be resolved by the network applications and management systems. JMC: I think more verbiage is needed around how to detect collisions. This is key to security considerations. Saying "clients should not" is not strong enough to keep our potential attackers. If each operation is tagged with an identifier that is unique to a client, then it will be possible to determine if the current client is trying to overwrite data from a previous client. This could fold into authz as well where there is a permission to allow global override of other application's state. Section 2: read scope: ... write scope: ... JMC: Should there be an event or notification scope in addition to read and write? Section 3.4: I2RS clients may be operating on behalf of other applications. While those applications' identities are not need for authorization, each application should have a unique opaque identifier that can be provided by the I2RS client to the I2RS agent for purposes of tracking attribution of operations. JMC: The opaque ID might make it hard to accurately attribute changes. I2RS should mandate a way to ensure traceability back to a client that made the change or was granted access. Section 4.1: JMC: I found the text here a bit confusing and potentially overreaching for the I2RS scope. I attempted to rewrite it. OLD: One example of such an application is a Topology Manager. Such an application includes an I2RS client which uses the I2RS protocol to collect information about the state of the network. The Topology Manager would collect device and interface state from devices it interacts with directly. It also collects routing configuration and operation data from those devices. Most importantly, it collects information about the routing system, including the contents of the IGP (e.g. IS-IS or OSPF) and BGP data sets. This information is provided to the I2RS client using the I2RS data models and protocols. The Topology Manager may be an integral part of an application. It would build internal data structures, and use the collected data to drive applications like path computations or anomalous routing detection. Alternatively, the Topology manager could combine the I2RS collected data with other information, abstract the result, and provide a coherent picture of the network state over another interface. That interface might use the same I2RS protocols, and could use extensions of the I2RS data models. Developing such mechanisms is outside the initial scope of the I2RS work. NEW: One example of such an application is a Topology Manager. A Topology Manager includes an I2RS client that uses the I2RS data models and protocol to collect information about the state of the network by communicating directly with one or more I2RS agents. From these I2RS agents, the Topology Manager collects routing configuration and operational data. Most importantly, it collects information about the routing system, including the contents of the IGP (e.g., IS-IS or OSPF) and BGP data sets. The Topology Manager may be embedded as a component of a larger application. It would construct internal data structures and use the collected data to drive functions such as path computations or anomalous routing detection. Alternatively, the Topology Manager could combine the I2RS-collected data with other information, abstract a composite set, and provide a coherent picture of the network state accessible via another interface. That interface might use the same I2RS protocol and could use extensions to the I2RS data models. Developing such mechanisms is outside the initial scope of the I2RS work. Section 5.2.1: An I2RS client applies changes via the I2RS interface based on policy and other application inputs... JMC: I2RS interface is redundant, perhaps I2RS protocol Section 5.2.2: An I2RS Agent may decide that some state should no longer be applied. An I2RS Client may instruct an Agent to remove state it has applied. In all such cases, the state will revert to what it would have been without the I2RS; that state is generally whatever was specified via the CLI, NetConf, SNMP, etc. I2RS Agents will not store multiple alternative states, nor try to determine which one among such a plurality it should fall back to. Thus, the model followed is not like the RIB, where multiple routes are stored at different preferences. JMC: Previously I had commented that one event that should be supported and perhaps documented here is that if the agent decides to revert the application can be notified that its state has been reverted. This might also be useful if another client overrides some portion of another client's state (this is covered in Section 6.8, but might be useful to mention here as well). Perhaps add at the end of Section 5.2.2: "A client may choose to be notified whenever its state is reverted either by another client or by the I2RS agent." Section 5.4.2: (Bulleted list of examples) JMC: Consider adding an example for an event such as a new route being learned or an OSPF neighbor removal. Section 5.4.4: 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 included in the I2RS data models and in the expected interfaces between the I2RS Agent and the network element, in order to provide basic capabilities and the hooks for future extensibility. JMC: I think this either needs an editor's note for more discussion or perhaps QoS in general should be out of scope. Section 6.1: As a result, this architecture views the I2RS interface as an interface supporting a single control and data exchange protocol. JMC: Another instance of I2RS interface. Section 6.1: That protocol may use several underlying transports (TCP, SCTP, DCCP), with suitable authentication and integrity protection mechanisms. Whatever transport is used for the data exchange, it must also support suitable congestion control mechanisms. JMC: I think Carlos (or someone) mentioned this, but I'm not sure DCCP is ideal for I2RS since we likely do want reliable order of delivery. Section 6.4: Each I2RS Client will have an identity; it can also have secondary identities to be used for troubleshooting. JMC: Each application will have a _unique_ identity. Section 6.5: JMC: Perhaps some normative language here to indicate a client may not maintain a persistent connection, but they may choose to do so as well. OLD: A client does not need to maintain an active communication channel with an agent. NEW: A client may not maintain... Section 6.7: One of the other important aspects of the I2RS is that it is intended to simplify collecting information about the state of network elements. JMC: I think this needs to be more specific to routing information versus any information from the network element (e.g., it does not cover CPU statistics). Joe -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: [email protected] ---------------------------------------------------------------------------- _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
