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
