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
