Hi Dean, On 23 Apr 2014, at 19:20, Dean Bogdanovic <[email protected]> wrote:
> Does the WG see a need for i2rs to provide mechanism for persistent changes? Whilst it would be nice from an i2rs view to say “no, we can clearly make these changes via NETCONF”, from my perspective, it is very important that we ensure that we do not end up with unnecessary fragmentation between different approaches to changing the state of an element of the routing system. As soon as we say we interact with the i2rs agent for a particular set of ephemeral state, and then with via a separate path using NETCONF other persistent state then we drive complexity into the systems layer above the element - which is, IMVHO, best avoided. We end up having to have such fragmentation today where we have MIBs that give us a subset of information/writable configuration, and another subset available via CLI - and it causes pain. >From my reading of the architecture -02 draft, then within the overview of the >architecture (§1.2) then currently we state (under the definition of “Static >System State”) “How the I2RS agent modifies of obtains this information is out >of scope” — which seems to support the view that persistent changes are >something we consider required for I2RS. Cheers, r. > > 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 _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
