Martin: Thank you. As usual, your answer is clear and enables me to work on the next steps of coding and standardization.
I'd love to talk off-list on how I've merged to I2RS RIB ephemeral control protocol data store and Netconf intended datastore in a prototype in the CONFD code. Sue -----Original Message----- From: Martin Bjorklund [mailto:[email protected]] Sent: Monday, November 14, 2016 4:11 PM To: [email protected] Cc: [email protected]; [email protected]; [email protected] Subject: Re: [netmod] comments on revised-datastores-00 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
