Martin et alii, The suggested protocol for i2rs is RESTCONF. Let me put quickly pros and cons for RESTCONF with few use cases.
Although there are many similarities between those two protocols, there are differences. Biggest negative for both, RESTCONF and NETCONF is lack of possibility to modify operational state of the device. Cons: No network locking model Can’t modify operational state of network device Using JSON only simple meta-data is supported Pros: Unified data store Provides atomicity of transaction Simplified defaults handling Allows multiple edits (with PATCH) within single message Providing abstracted simplified config model Supports XML and JSON Streaming via Server-Sent-Events Edit collision detection I2RS clearly needs capability to modify operational state of the device. With unified data store that should be easier to achieve for RESTCONF then NETCONF, where multiple data stores are supported. I envision that only transient changes are configured via RESTCONF. Any persistent changes IMO, should go via NETCONF. Does the WG see a need for i2rs to provide mechanism for persistent changes? Following 3, I view very connected, simplified defaults handling, atomicity of transaction and abstracted simplified config model. With simplified configuration models, we can create With RESTCONF we want to ensure that a single transaction is making a meaningful request that can be fulfilled. This means that request can be either fulfilled or the transaction will fail. The simplified defaults handling makes the process easier. In case of writing, if not all the parameters are provided and there are no default arguments for the missing parameter, transaction will fail. For the performance reasons, support for PATCH is very good, as it allows multiple updates in single transaction. It is not the same to send 1000 transactions to update 1000 routes or 1000 routes are updated in single transaction. With this capability clients can execute much faster changes to the system. Lacking support for network locking model is an issue if there is a service activated across multiple devices via i2rs and in case of an error on one device, client has to be able to clean up on the other devices. Is this a viable use case that would prevent use of RESTCONF for i2rs? Dean On Apr 23, 2014, at 1:08 PM, Martin Bjorklund <[email protected]> wrote: > t.petch <[email protected]> wrote: >> YANG (with NETCONF) is designed for writing configuration and reading >> everything else, and does an excellent job at it. Trouble is, for me, >> that configuration doesn't mean what I think of it as; it means, in the >> YANG context, what you might put in through the CLI and it excludes >> everything else, such as data learnt via a protocol. > > This is true, but more for NETCONF than for YANG. I think it has been > clear from the start that I2RS probably needs some (hopefully minor) > extensions to NETCONF and/or YANG, should we choose to use these > technologies. > > Also, I think it has been pretty clear that what is missing is a way > to identify writable data that is not configuration (in the > NETCONF/YANG sense). > >> In practice, this means that the YANG model comes in twin sets, one of >> read-write configuration and one of read-only not-configuration (as can >> be seen in the current I-Ds that the netmod WG is producing) > > Correct. This reflects how it usually works on devices; most routers > and similar equipment has a "config mode CLI" and "show commands"; a > linux box has config files and various ways of reading and writing > operational state (/proc, direct apis...) These are different > structures with different syntax and semantics. > > (SNMP tried to combine the two into one, but this turned out to be > problematic.) > >> with no >> formal way in YANG of relating the one to the other. So if you want >> e.g. the routing table, the host software has to know where to look and >> how to combine the pieces to produce a coherent picture (and then you >> cannot edit most of it). >> >> So if I2RS never wants to write anything to a router, YANG is fine; if >> I2RS is only producing a Information Model (and ignoring whether or not >> data is read-only or read-write), and not moving on to an >> implementation, then YANG is fine. >> >> Rather, as Andy Bierman said at IETF89, likely I2RS would need an >> extension to YANG, a new sub-statement for all data objects, semantics >> not too clear but designed to separate out the not-configuration, learnt >> via a protocol, 'editable-state' (and in doing so, making it >> read-write - but still 'config false'). >> >> Yes, YANG allows for such extensions but it seems to me that I2RS would >> then be getting YANG++ (and NETCONF++), once the necessary work has been >> done. > > You can call it YANG++ and NETCONF++, but the fact is that these > things can be done today, without having to revise the YANG or NETCONF > specs, by using the current extensibility mechanisms. > > > /martin > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
