The WG discussed this extensively. Any effort to persist I2RS state introduces significant complexity. In particular, very few configs have a mechanism to store a prrvious state so that thr system will behave correctly when the I2RS agent deletes the state it has created. And there were other problems noted. Whime some folks wanted petsistance, as a participant the conclusion of the WG was quite clear.
Yours, Joel Sent from my Samsung smartphone on AT&T -------- Original message -------- Subject: Re: [i2rs] I-D Action: draft-haas-i2rs-netmod-netconf-requirements-00.txt From: Andy Bierman <[email protected]> To: Jeffrey Haas <[email protected]> CC: "Joel M. Halpern" <[email protected]>,"[email protected]" <[email protected]> On Mon, Sep 15, 2014 at 11:01 AM, Jeffrey Haas <[email protected]> wrote: On Fri, Sep 12, 2014 at 06:09:02PM -0700, Andy Bierman wrote: > There is nothing in YANG or RESTCONF to support it (yet). > For some features the I2RS agent is supposedly simple and mostly stateless. > This template service does not seem to fit with that theme. Attempting to summarize discussions with various I2RS WG participants, I think it's a matter of perspective - and somewhat of preference. The tension seems to lie roughly along two points of view: 1. This is a programmatically driven API environment. As such, there's little excuse to not simply send everything needed as a large configuration block - templates are extraneous. 2. By permitting templates, you enable much smaller transactions. You also potentially allow for a stronger security model by "locking down" stuff outside of the template. To offer a somewhat concrete example, consider an application for provisioning L3VPN customers. Some minimum required configuration on a per-device basis includes: VRF name. A route-distinguisher. A route-target for the VPN. Customer PE-CE protocol and endpoint configuration. Fully expanded, this is probably a few dozens of lines of configuration in YANG. What's interesting is that the above information is potentially generic related to that configuration, which may have per-device variance - potentially based upon vendor. Thought about perhaps another way, the template inputs are effectively a mini-YANG module with much of the back-end abstracted. > Are these templates ephemeral? That would be annoying. They are not > straight > config, so a new a configuration data model is needed to manage the > templates. > New protocol mechanisms to use templates in addition to payload data will > be needed. All agreed. > > You talk about the priority requirements. You should probably mention the > > multi-headed behavioral requirements there (as I think that the resolutions > > will be tightly coupled.) > > > > Section 7.9 of the archtiecture document talks about several transactional > > scopes. The text you have does not seem to deal with all of these. Does > > YANG handle them all easily? > > > > I would need to review this again -- I don't remember any problems last > time I read the arch draft. Some of this is a matter of where this information lives. For tie-breaking of ephemeral vs. static config, is this provisioned per-module or per element in the module? Are there explicit lines of YANG in each module for this? For tie-breaking user priorities, NACM extensions may make sense. This particular state is effectively meta-data on the ephemeral config. Since the epehemeral state is "highest priority wins", but there's no requirement that the lower priority state is kept in any fashion, how do we deal with inconsistent configuration that may result by a higher priority user deleting part of their configured state? > I am confused about some text in the draft about ephemeral config: > > In 2.1: > > The author wishes to > prevent any action that would lead to preserving any configuration > state entered via the I2RS agent across reboots. If state has to be > restored, it should be solely by replay actions from I2RS client via > I2RS agent. > > > Why does the author wish to prevent NV-storage of the I2RS data? > What is it about the accidental reboot of the router that makes it the > I2RS data needed before the accidental reboot, but not after? I think my point of confusion is why you believe ephemeral configuration would ever get NV-stored? Several people have asked about "copy to local config", which is really "NV-save the I2RS state". What if the operator wants the state to be active until it is explicitly removed? There may be significant latency between the time the client discovers the agent has rebooted and the state is re-installed. > If the reason is because I2RS agents are simple and NV-storage is not > simple, > then why does the agent need to support templates? This is more a "clean slate" decision. When the device comes up, it has no I2RS state. Note that the fully ephemeral nature of I2RS still doesn't feel fully-settled in the WG. See prior thread comments about wanting to do copy-config on it. :-) > This section might mention that the I2RS datastore has its own > access control model, that is not the same as the running config. > > 2. Configuration state in the existing running datastore where the > module is "tagged ephemeral". > > 3. Permitting existing configuration to be optionally configured as > ephemeral. As an example, the NETCONF server advertises in its > <hello> message if it supports the specified YANG module > persistently and/or ephemerally. > > > > I thought the I2RS charter said I2RS was not altering the local config. Correct. > Why does I2RS need to change the meaning of YANG configuration nodes > in an ad-hoc manner (via tagging)? For point 2, it'd be identifying I2RS modules (having the ephemeral properties) in the YANG. Point 3 is submitted as an option based on comments at the last IETF netmod session where someone else indicated being able to store things ephemerally would potentially be useful. If this is indeed a wider use case, let's discuss it. > This does not really work because YANG validation may fail without some > config data > that has been tagged "do not save". If the router reboots and the startup > config > does not validate, it is probably wedged. It can't really fall back to a > "known good config" > if I2RS has forced some of the data to be omitted from the saved config. Agreed. See also the priority discussion above. > In sec 2.1.3, if you want a new third choice for the config-stmt for > "ephemeral", > then I2RS is gated on the completion of YANG 1.1 (and development of YANG > 1.1 tools). > Are you really sure you want that? That's why a YANG extension was > suggested instead > (or maybe do both). Worth discussing during the interim. It has been suggested to me that many of the above properties can already be implemented in a proprietary manner with no language extensions. They would simply not be either interoperable or clear about their ephemeral nature based on module contents. So, we're looking for a balance of expeditious and correct for the long term maintainenace of the protocols and YANG. -- Jeff Andy
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
