----- Original Message ----- From: <[email protected]> To: "t.petch" <[email protected]> Cc: <[email protected]>; "i2rs" <[email protected]>; "'Jeffrey Haas'" <[email protected]>; "Susan Hares" <[email protected]> Sent: Friday, May 09, 2014 1:54 AM Subject: Re: [i2rs] edit-data substatement Re: Operational State
> I have raised a issue about this in netmod WG, > see: http://www.ietf.org/mail-archive/web/netmod/current/msg09716.html > /frank I see. I have speculated on something similar for I2RS, to be able to group meaningful sets of data, into datasets, perhaps with an optional name assuming that once we move away from the 'config true' dataset/datastore, then the floodgates are open and we are likely to want many such datasets. But I disagree that YANG should get into datastores of any kind; where this logical collection of data is copied to and from currently rests with NETCONF and that seems right, that the copy function, not the schema tree, specifies the two localities as part of the protocol, the schema tree specifies what the data set is. There are other issues, about how much sense it makes to have this set of data. The 'config true' dataset does make sense, it is a logical whole, what it takes to get a box up and running, in a way that no other dataset I can think of does. It may make sense to have an easy to read set of data for I2RS, so perhaps a new YANG substatement for data nodes to identify this and a get-i2rs function to go with it, but writing it back seems fraught with potential pitfalls. So underneath this, I wonder if a copy function makes any sense for I2RS because there is no meaningful set of data. Use cases would help (have you got any?). I have yet to see anyhing in the current I-Ds that requires a copy function. Tom Petch > "i2rs" <[email protected]> 写于 2014-05-09 01:45:34: > > > > > > 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 > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
