On Mon, Sep 15, 2014 at 5:21 PM, Jmh.direct <[email protected]> wrote:
> 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. > > I am OK with leaving out persistence. If glitches cause problems, vendors will extend the standard with proprietary attempts to fix them. There is complexity either way. > Yours, > Joel > > Andy > > 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
