---- Original Message ----- From: "Susan Hares" <[email protected]> To: "'t.petch'" <[email protected]> Cc: "'Jeffrey Haas'" <[email protected]>; <[email protected]> Sent: Friday, May 09, 2014 5:52 AM > Tom: > > Thank you for your note of your preference email reading, and I've also read > earlier of your need for html compliant i2rs notes rather than a pdf form. > Please let me know if your format issues regarding email have been addressed > by the format of this email. Thank you for your comments on yang. > > My questions were: 1) Why only is the copy-to-local-config feature out of > scope for the I2rs-config? 2) Are you indicating that there is no > write-config/ack and complete-write config interactions? My questions did > not have to do with Yang's functionality, but with your > statements/assumptions with I2RS. If you answered these questions, please > send email clip (private/public).
I think that we are in uncharted territory. My thanks to Juergen for correcting my terminology. The NETCONF RFC does define datastore as distinct from configuration datastore but then defines all its operations in terms of configuration datastores while the YANG RFC uses datastore without qualification but clearly means configuration ones. Um. So configuration datastores only contain 'config true' nodes and contain a complete set thereof, in accordance with a schema tree. <running/> is one such datastore, along with <startup/> and user-defined ones; these can be copied in their entirety and the nature of them means that I see it as practical for a device to lock them against any changes during a copy - the copy is atomic, no acknowledgements needed. The rest of the data in the device, state, is not a datastore, cannot be edited, cannot be copied can only be (selectively) gotten, NETCONF get RPC, and is not <running/> because that is a term with a special meaning, of a specific configuration datastore. Likewise 'config' is a term with special meaning of what goes into a configuration datastore (so I am uncertain what is meant by config or running in the context of I2RS). So that is the model at the back of my mind, which I find hard to let go of. If I2RS wants to edit state (eg the RIB entries learnt from BGP), which the use-cases clearly describe, then that is a new ballgame, needing, if YANG is used, a new substatement to mark those data nodes and a new protocol, perhaps a NETCONF extension, to write to them. Or else we do not use the existing data models as a base, and create new ones with only data nodes of interest to I2RS in them in whatever language we choose, perhaps a new protocol (quite easily done). If I2RS wants to operate on sets of data (I would avoid the term datastores because I still see it as a a technical term with a special meaning in Ops Area), and I am uncertain whether or not it should - the use cases seem silent on this - well that is another new ballgame. There is nothing in NETCONF or YANG to guide us here, we would need to tag (e.g. YANG substatement) the data nodes that form such a dataset, or datasets, and define new protocols, perhaps extensions to NETCONF, to copy those datasets from somewhere to somewhere. This could be fraught on a practical level. My experience of routers is that the storage used for state, eg the full BGP table, is greater than that used for (NETCONF type) config (typically semi-permanent storage), so there might be nowhere for the state to be copied to on the device, nowhere that survives a restart. Likewise, in a parallel context, one trick I play is an SNMP get-next on RMON tables - it never ends, because new entries are being added to the tables faster than the get-next can retrieve them! Would an attempt to copy the full BGP table meet the same fate? I do not know, but it is these practical thoughts that colour my thinking which is perhaps why I think that I2RS does not want a copy function because it would be a challenge to implement - but I would be happy to be corrected by manufacturers of high-end routers. Um. Tom Petch > -----Original Message----- > From: t.petch [mailto:[email protected]] > Sent: Thursday, May 08, 2014 1:46 PM > To: Susan Hares > Cc: 'Jeffrey Haas'; [email protected] > Subject: Re: [i2rs] edit-data substatement Re: Operational State > > Sue > > I am afraid I cannot parse this e-mail to see where the text is yours and > where it is something earlier and where the questions are unanswered:-( > > Datastores in NETCONF/YANG are a NETCONF construct and define a set of > configuration information. YANG has no concept of where data is or its > persistence except to a limited extent when it is applying validation logic, > as in RFC6020 s7.5.3 (which probably does not make much sense in isolation - > my I-D might help). > > So a datastore is a set of 'config true' data nodes stored somewhere. > Move away from configuration and there is no other concept, apart from > everything else, all the statistics, routing tables and so on. Hence my > suggestion that I2RS will need a YANG substatement to mark out the data of > interest to I2RS, perhaps with a name attached so that there can be multiple > sets of I2RS data, to read, to write, to copy and so on as a meaningful > unit; it would probably be a mistake to call that a datastore given the more > specific meaning that that term has acquired in NETCONF, of a unit of > configuration data. > > Tom Petch > > ----- Original Message ----- > From: "Susan Hares" <[email protected]> > To: "'Andy Bierman'" <[email protected]>; "'Thomas Nadeau'" > <[email protected]> > Cc: "'Jeffrey Haas'" <[email protected]>; <[email protected]>; "'Juergen > Schoenwaelder'" <[email protected]>; "'t. petch'" > <[email protected]> > Sent: Wednesday, May 07, 2014 11:56 AM > > > > Andy: > > > > > > > > Thank you for detailed discussion with Tom Petch/Jeff/Juergen/Tom > Nadeau: > > > > > > > > <snip> > > > > I imagine I2RS will be completely separate from NETCONF and it should > have > > its own datastore -- so "i2rs-config" is appropriate because I2RS is > the > > only protocol using that datastore. The combined "operational state" > is not > > editable. > > > > > > > > Yes, that makes sense. Then if at some point in time you want to save > the > > running config (i2rs), the system has to explicitly copy it over. But > until > > then, its separate. The only question is: what is the complete > running > > config represented as? And what if Netconf wants to modify the running > > config (i.e.: and the RIB in particular)? > > > > > > > > That copy-to-local-config feature would be extra, outside the scope of > the > > i2rs-config. > > > > </snip> > > > > ----- > > > > > > > > Why only is the copy-to-local-config feature out of scope for the > > I2rs-config? How can the work be interoperable if this feature > (required > > or optional) does not work the same in different vendor's boxes? If > the > > implementations are different, this is great (differentiated products > = > > good); but IMHO this feature actions has to be interoperable. that is > give > > the same effective response in the different vendors. > > > > > > > > Can you explain further? > > > > > > > > > > <snip> > > > > > > > > Right. If we take that approach we need to have a way of the i2rs > "protocol" > > to signal that the config > > > > needs to be saved "soon". That is, its not done in real time, but > rather as > > a background process. > > > > Its probably. This can either be through a single keyword that is > added > > under the i2rs-config section, or > > > > per element or even per-element, if we decide to be more granular. > > > > </snip> > > > > > > > > IMHO it is important to know when the write to local-config is done > even if > > done in background. Are you indicating there is no > > write-config/ack-complete-write config interaction? > > > > > > > > <snip> > > > > You seem to be suggesting that the I2RS behavior of forgetting all > injected > > state > > > > if the router happens to reboot is not that useful, and therefore it > needs > > to be > > > > saved in the background (best-effort). > > > > > > > > I think it is up to all the I2RS clients to always be around to > receive some > > > > sort of agent-reboot event, and re-install any required I2RS config. > > > > I can't imagine any use cases where the operator thinks "I only need > to > > > > install this RIB data until that router accidentally reboots". > > > > </snip> > > > > > > > > If you re-install any required I2RS config, are you sure this is what > the > > I2RS client wants? > > > > > > > > Sue > > > > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
