Hi, How do the YANG validation rules for datastores apply to this new framework? The YANG RFC just refers to a 'valid' datastore. Is validation ever done on the 'intended' datastore, or just 'running' (what we have now).
The framework you propose seems reasonable but the real issues show up in the protocol interaction model(s) that are out of scope for this draft. Each datastore (running, intended, applied) can all be different, they can all be YANG-valid, but I;m not sure that buys anything. It seems complicated to determine that my specific edit is applied yet, while there are many writers to the data subtrees. Andy On Mon, Nov 14, 2016 at 1:10 PM, Martin Bjorklund <[email protected]> wrote: > Hi, > > "Susan Hares" <[email protected]> wrote: > > Juergen and Lada: > > > > #2 - is interesting to me. Is dynamic configuration protocol = I2RS? Or > > control-plane protocols = I2RS? > > Details tbd, but this architecture allows for a new kind of datastore > ("control-plane datastore") which could be defined for i2rs. > > > On #5 - how do you merge I2RS RIB static routes + routing-configuration > rib > > routes? > > That is not covered by this architecture. It has to be defined in i2rs. > > > Can you see the difference in the applied configuration? > > You can see the result in the applied configuration, and you can see > the statically configured routes in <intended> and the i2rs-defined > routes in the-new-i2rs-datastore. > > > /martin > > > > > > Thanks, > > > > Sue > > > > -----Original Message----- > > From: netmod [mailto:[email protected]] On Behalf Of Juergen > > Schoenwaelder > > Sent: Monday, November 14, 2016 4:42 AM > > To: Ladislav Lhotka > > Cc: [email protected] > > Subject: Re: [netmod] comments on revised-datastores-00 > > > > On Mon, Nov 14, 2016 at 11:23:04AM +0900, Ladislav Lhotka wrote: > > > Hi, > > > > > > I've read the revised-datastores-00 document, in general I like it, > > > here are my initial comments and questions: > > > > > > 1. Even if <intended> is valid, it can still be in conflict with the > > > actual content of <applied> that may come from e.g. dynamic > > > configuration protocols. How are such cases supposed to be resolved? > > > > Yes. The whole idea is to expose these potential differences instead of > > hiding them behind a curtain. > > > > > 2. What is the distinction between dynamic configuration protocols and > > > control-plane protocols? > > > > Good question. I believe this to be at the end implementation specific. > > The question I think really is whether a control-plane protocol interacts > > with the configuration management component or not. > > > > > 3. Shared <candidate> has known problems. Maybe it's time to part with > > > it in this new datastore model? > > > > This clearly was not the focus of this work. > > > > > 4. Templates are briefly mentioned in several places, it would be > useful > > > to explain this concept in more detail. > > > > I agree. > > > > > 5. Is it necessary that "<operational-state> datastore contains all > > > configuration data actually used by the system"? For example, static > > > routes should appear in RIBs, so having them separately in > operational > > > state seems redundant. > > > > I do not understand your question. Is the RIB exposed or not? Anyway, we > > need a general model and not a model for specific aspects such as > routing. > > Yes, there can be redundancy but there can also be semantic differences. > The > > <operational-state> datastore tells me what is actually used (regardless > of > > what has happened with the statically configured values). In other > words, if > > I want to debug what my box is actually doing, looking at the > > <operational-state> datastore is probably a good idea. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> > > > > _______________________________________________ > > netmod mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ > > netmod mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
