Re: [netmod] comments on revised-datastores-00

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> 
> > On 17 Nov 2016, at 14:07, Andy Bierman  wrote:
> > 
> > 
> > 
> > On Wed, Nov 16, 2016 at 7:52 PM, Ladislav Lhotka 
> > wrote:
> > Martin Bjorklund  writes:
> > 
> > > Ladislav Lhotka  wrote:
> > >> Juergen Schoenwaelder  writes:
> > >>
> > >> > On Tue, Nov 15, 2016 at 09:48:35AM +0900, Ladislav Lhotka wrote:
> > >> >> Juergen Schoenwaelder  writes:
> > >> >>
> > >> >> > 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  is valid, it can still be in conflict with
> > >> >> >> the
> > >> >> >>actual content of  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.
> > >> >>
> > >> >> That's fine but it doesn't answer my question.
> > >> >>
> > >> >
> > >> > Then I do not understand the question. What does it mean for a
> > >> > datastore to be in conflict with a different datastore?
> > >>
> > >> For example:
> > >>
> > >> - the data model has a choice with caseA and caseB. A NC/RC client
> > >>   configures caseA,  is valid, but  already contains
> > >>   caseB configured by a "dynamic configuration protocol"; or
> > >>
> > >> - a leafref refers to a leaf that exists in  but not in
> > >>   .
> > >
> > > An open issue is what to do with semantic constrains.  For now, let's
> > > assume they do not have to be valid.  This implies that you can have
> > > leafrefs in  that refer to non-existing leafs.
> > >
> > > However, for choices, I don't think two cases can exist at the same
> > > time even in operational state.  If we allow this, where do we draw
> > > the line - can a container or leaf exist in multiple instances?  can
> > > a leaf of type int32 contain a string?
> > 
> > Certainly not. Rather than validate , it may be better to
> > first merge  with current content of  to get the
> > tentative
> > future content of , and apply validation on it.
> > 
> > 
> > 
> > IMO this is not correct.
> > 
> > The running config cannot really be safely validated under this new
> > model,
> > because unexpanded templates and inactive nodes should not part of the
> > validation.
> 
> I didn't mention validation of  at all.
> 
> > 
> > The intended datastore should always be YANG-valid.
> > It is disjoint from the applied datastore.
> 
> So let's say we have a list with min-elements = 1 (such as the list of
> RIBs), and there is already one entry provided by the system. what has
> to be done in order to make  valid? Should the
> system-controlled entry permeate up to ?

system-controlled entries are not part of intended.

If you have some template that adds this entry you're good.  Otherwise
the user has to provide it, in order to meet the constraint.



/martin


> > 
> > Using your example of case A and case B -- it is OK for a control
> > plane
> > protocol to override intended config (e.g., select case B causing case
> > A
> > to be deleted from applied).  The intended is not altered (case A
> > still exists
> > in intended).
> 
> According to the picture, control plane protocols affect operational
> state, so it is OK.
> 
> > 
> > The applied datastore should be valid independent of intended.
> > You cannot merge them (e.g. case A and B not allowed to both exist).
> 
> I can merge them and report they the submitted  would make
>  invalid, i.e. the edit would be rejected.
> 
> Lada
> 
> > You can only compare them to find out that intended was overridden
> > by a control protocol (e.g. case B is being used, not case A)
> > 
> > If the control protocol changes get removed then applied should
> > reflect
> > the intended (e.g. case A reappears in applied)
> > 
> > 
> > Andy
> > 
> > 
> > 
> > 
> > >
> > >> >> >> 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.
> > >> >>
> > >> >> OK, perhaps it can be said that dynamic configuration protocols modify
> > >> >> "config true" data. Maybe a term like "configuration interface" may be
> > >> >> better because it needn't be a communication protocol, and it needn't
> > >> >> be
> > >> >> any more dynamic than NETCONF/RESTCONF is.
> > >> >
> > >> > Yes, we know that 'dynamic' is potentially misleading.
> 

Re: [netmod] comments on revised-datastores-00

[Martin Bjorklund]

Andy Bierman  wrote:
> On Wed, Nov 16, 2016 at 7:52 PM, Ladislav Lhotka  wrote:
> 
> > Martin Bjorklund  writes:
> >
> > > Ladislav Lhotka  wrote:
> > >> Juergen Schoenwaelder  writes:
> > >>
> > >> > On Tue, Nov 15, 2016 at 09:48:35AM +0900, Ladislav Lhotka wrote:
> > >> >> Juergen Schoenwaelder  writes:
> > >> >>
> > >> >> > 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  is valid, it can still be in conflict with
> > the
> > >> >> >>actual content of  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.
> > >> >>
> > >> >> That's fine but it doesn't answer my question.
> > >> >>
> > >> >
> > >> > Then I do not understand the question. What does it mean for a
> > >> > datastore to be in conflict with a different datastore?
> > >>
> > >> For example:
> > >>
> > >> - the data model has a choice with caseA and caseB. A NC/RC client
> > >>   configures caseA,  is valid, but  already contains
> > >>   caseB configured by a "dynamic configuration protocol"; or
> > >>
> > >> - a leafref refers to a leaf that exists in  but not in
> > >>   .
> > >
> > > An open issue is what to do with semantic constrains.  For now, let's
> > > assume they do not have to be valid.  This implies that you can have
> > > leafrefs in  that refer to non-existing leafs.
> > >
> > > However, for choices, I don't think two cases can exist at the same
> > > time even in operational state.  If we allow this, where do we draw
> > > the line - can a container or leaf exist in multiple instances?  can
> > > a leaf of type int32 contain a string?
> >
> > Certainly not. Rather than validate , it may be better to
> > first merge  with current content of  to get the
> > tentative
> > future content of , and apply validation on it.
> >
> >
> 
> IMO this is not correct.
> 
> The running config cannot really be safely validated under this new model,
> because unexpanded templates and inactive nodes should not part of the
> validation.
> 
> The intended datastore should always be YANG-valid.
> It is disjoint from the applied datastore.
> 
> Using your example of case A and case B -- it is OK for a control plane
> protocol to override intended config (e.g., select case B causing case A
> to be deleted from applied).  The intended is not altered (case A still
> exists
> in intended).
> 
> The applied datastore should be valid independent of intended.
> You cannot merge them (e.g. case A and B not allowed to both exist).
> You can only compare them to find out that intended was overridden
> by a control protocol (e.g. case B is being used, not case A)
> 
> If the control protocol changes get removed then applied should reflect
> the intended (e.g. case A reappears in applied)

I agree.


/martin

> 
> 
> Andy
> 
> 
> 
> 
> >
> >> >> >> 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.
> >> >>
> >> >> OK, perhaps it can be said that dynamic configuration protocols modify
> >> >> "config true" data. Maybe a term like "configuration interface" may be
> >> >> better because it needn't be a communication protocol, and it needn't
> be
> >> >> any more dynamic than NETCONF/RESTCONF is.
> >> >
> >> > Yes, we know that 'dynamic' is potentially misleading.
> >>
> >> My take from yesterday's discussion is that in fact the classification
> >> is implementation-dependent.
> >
> > Yes it probably is.  But I'm not sure it is actually a problem.
> 
> It isn't, but you could base the classification on where each
> contribution comes in instead of using fuzzy terms like dynamic
> configuration protocol.
> 
> >
> >> For example, if I use standard Linux
> >> command-line tools such as "ip", their result can be seen only in
> >> operational state, so they are like control-plane protocols. However, if
> >> an implementation patches these tools so as to write to , then
> >> they are dynamic configuration protocols.
> >>
> >> >
> >> >> >> 5. Is it necessary that " 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.
> >> >> >
> 

Re: [netmod] comments on revised-datastores-00

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> Martin Bjorklund  writes:
> 
> > Ladislav Lhotka  wrote:
> >> Juergen Schoenwaelder  writes:
> >> 
> >> > On Tue, Nov 15, 2016 at 09:48:35AM +0900, Ladislav Lhotka wrote:
> >> >> Juergen Schoenwaelder  writes:
> >> >> 
> >> >> > 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  is valid, it can still be in conflict with the
> >> >> >>actual content of  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.
> >> >> 
> >> >> That's fine but it doesn't answer my question.
> >> >>
> >> >
> >> > Then I do not understand the question. What does it mean for a
> >> > datastore to be in conflict with a different datastore?
> >> 
> >> For example:
> >> 
> >> - the data model has a choice with caseA and caseB. A NC/RC client
> >>   configures caseA,  is valid, but  already contains
> >>   caseB configured by a "dynamic configuration protocol"; or
> >> 
> >> - a leafref refers to a leaf that exists in  but not in
> >>   .
> >
> > An open issue is what to do with semantic constrains.  For now, let's
> > assume they do not have to be valid.  This implies that you can have
> > leafrefs in  that refer to non-existing leafs.
> >
> > However, for choices, I don't think two cases can exist at the same
> > time even in operational state.  If we allow this, where do we draw
> > the line - can a container or leaf exist in multiple instances?  can
> > a leaf of type int32 contain a string?
> 
> Certainly not. Rather than validate , it may be better to
> first merge  with current content of  to get the tentative
> future content of , and apply validation on it. 
> 
> >
> >> >> >> 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.
> >> >> 
> >> >> OK, perhaps it can be said that dynamic configuration protocols modify
> >> >> "config true" data. Maybe a term like "configuration interface" may be
> >> >> better because it needn't be a communication protocol, and it needn't be
> >> >> any more dynamic than NETCONF/RESTCONF is.
> >> >
> >> > Yes, we know that 'dynamic' is potentially misleading.
> >> 
> >> My take from yesterday's discussion is that in fact the classification
> >> is implementation-dependent.
> >
> > Yes it probably is.  But I'm not sure it is actually a problem.
> 
> It isn't, but you could base the classification on where each
> contribution comes in instead of using fuzzy terms like dynamic
> configuration protocol.
> 
> >
> >> For example, if I use standard Linux
> >> command-line tools such as "ip", their result can be seen only in
> >> operational state, so they are like control-plane protocols. However, if
> >> an implementation patches these tools so as to write to , then
> >> they are dynamic configuration protocols.
> >> 
> >> >
> >> >> >> 5. Is it necessary that " 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  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  datastore is
> >> >> > probably a good idea.
> >> >> 
> >> >> But could this part of operational state be possibly different from
> >> >> what's already in ?
> >> >
> >> > This is subtle since we are not really able to define precisely what
> >> > the boundaries of a datastore are. Is something applied if the
> >> > responsible daemon accepted information? Or is it applied if the
> >> > daemon communicated information to the kernel? Or is it applied if the
> >> > linecard accepted the information from the kernel? Or is it applied if
> >> > the specific registers of the linecard have been programmed?
> >> 
> >> In 

Re: [netmod] comments on revised-datastores-00

[Ladislav Lhotka]

> On 17 Nov 2016, at 17:03, Phil Shafer  wrote:
> 
> Ladislav Lhotka writes:
>> So let's say we have a list with min-elements = 1 (such as the list of 
>> RIBs), and there 
>> is already one entry provided by the system. what has to be done in order to 
>> make > ded> valid? Should the system-controlled entry permeate up to ?
> 
> We should update the draft to make it clear to allow system-controlled
> data to appear as part of the template/expansion activity so that
> such data can be referred to from the running config.  For example,
> a static route could have a next-hop of a system-defined lo0.  Not
> that this is a good idea, but...

I agree, this is often needed for system-controlled instances (default RIB is 
another use case), and so far the only option was to put a dummy entry into the 
configuration manually.

Lada 

> 
> Thanks,
> Phil

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] comments on revised-datastores-00

[Phil Shafer]

Ladislav Lhotka writes:
>So let's say we have a list with min-elements = 1 (such as the list of RIBs), 
>and there 
>is already one entry provided by the system. what has to be done in order to 
>make ded> valid? Should the system-controlled entry permeate up to ?

We should update the draft to make it clear to allow system-controlled
data to appear as part of the template/expansion activity so that
such data can be referred to from the running config.  For example,
a static route could have a next-hop of a system-defined lo0.  Not
that this is a good idea, but...

Thanks,
 Phil

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] comments on revised-datastores-00

[Ladislav Lhotka]

> On 17 Nov 2016, at 14:07, Andy Bierman  wrote:
> 
> 
> 
> On Wed, Nov 16, 2016 at 7:52 PM, Ladislav Lhotka  wrote:
> Martin Bjorklund  writes:
> 
> > Ladislav Lhotka  wrote:
> >> Juergen Schoenwaelder  writes:
> >>
> >> > On Tue, Nov 15, 2016 at 09:48:35AM +0900, Ladislav Lhotka wrote:
> >> >> Juergen Schoenwaelder  writes:
> >> >>
> >> >> > 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  is valid, it can still be in conflict with the
> >> >> >>actual content of  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.
> >> >>
> >> >> That's fine but it doesn't answer my question.
> >> >>
> >> >
> >> > Then I do not understand the question. What does it mean for a
> >> > datastore to be in conflict with a different datastore?
> >>
> >> For example:
> >>
> >> - the data model has a choice with caseA and caseB. A NC/RC client
> >>   configures caseA,  is valid, but  already contains
> >>   caseB configured by a "dynamic configuration protocol"; or
> >>
> >> - a leafref refers to a leaf that exists in  but not in
> >>   .
> >
> > An open issue is what to do with semantic constrains.  For now, let's
> > assume they do not have to be valid.  This implies that you can have
> > leafrefs in  that refer to non-existing leafs.
> >
> > However, for choices, I don't think two cases can exist at the same
> > time even in operational state.  If we allow this, where do we draw
> > the line - can a container or leaf exist in multiple instances?  can
> > a leaf of type int32 contain a string?
> 
> Certainly not. Rather than validate , it may be better to
> first merge  with current content of  to get the tentative
> future content of , and apply validation on it.
> 
> 
> 
> IMO this is not correct.
> 
> The running config cannot really be safely validated under this new model,
> because unexpanded templates and inactive nodes should not part of the
> validation.

I didn't mention validation of  at all.

> 
> The intended datastore should always be YANG-valid.
> It is disjoint from the applied datastore.

So let's say we have a list with min-elements = 1 (such as the list of RIBs), 
and there is already one entry provided by the system. what has to be done in 
order to make  valid? Should the system-controlled entry permeate up 
to ?

> 
> Using your example of case A and case B -- it is OK for a control plane
> protocol to override intended config (e.g., select case B causing case A
> to be deleted from applied).  The intended is not altered (case A still exists
> in intended).

According to the picture, control plane protocols affect operational state, so 
it is OK. 

> 
> The applied datastore should be valid independent of intended.
> You cannot merge them (e.g. case A and B not allowed to both exist).

I can merge them and report they the submitted  would make  
invalid, i.e. the edit would be rejected.

Lada

> You can only compare them to find out that intended was overridden
> by a control protocol (e.g. case B is being used, not case A)
> 
> If the control protocol changes get removed then applied should reflect
> the intended (e.g. case A reappears in applied)
> 
> 
> Andy
> 
> 
> 
> 
> >
> >> >> >> 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.
> >> >>
> >> >> OK, perhaps it can be said that dynamic configuration protocols modify
> >> >> "config true" data. Maybe a term like "configuration interface" may be
> >> >> better because it needn't be a communication protocol, and it needn't be
> >> >> any more dynamic than NETCONF/RESTCONF is.
> >> >
> >> > Yes, we know that 'dynamic' is potentially misleading.
> >>
> >> My take from yesterday's discussion is that in fact the classification
> >> is implementation-dependent.
> >
> > Yes it probably is.  But I'm not sure it is actually a problem.
> 
> It isn't, but you could base the classification on where each
> contribution comes in instead of using fuzzy terms like dynamic
> configuration protocol.
> 
> >
> >> For example, if I use standard Linux
> >> command-line tools such as "ip", their result can be seen only in
> >> operational state, so they are like control-plane 

Re: [netmod] comments on revised-datastores-00

[Andy Bierman]

On Wed, Nov 16, 2016 at 7:52 PM, Ladislav Lhotka  wrote:

> Martin Bjorklund  writes:
>
> > Ladislav Lhotka  wrote:
> >> Juergen Schoenwaelder  writes:
> >>
> >> > On Tue, Nov 15, 2016 at 09:48:35AM +0900, Ladislav Lhotka wrote:
> >> >> Juergen Schoenwaelder  writes:
> >> >>
> >> >> > 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  is valid, it can still be in conflict with
> the
> >> >> >>actual content of  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.
> >> >>
> >> >> That's fine but it doesn't answer my question.
> >> >>
> >> >
> >> > Then I do not understand the question. What does it mean for a
> >> > datastore to be in conflict with a different datastore?
> >>
> >> For example:
> >>
> >> - the data model has a choice with caseA and caseB. A NC/RC client
> >>   configures caseA,  is valid, but  already contains
> >>   caseB configured by a "dynamic configuration protocol"; or
> >>
> >> - a leafref refers to a leaf that exists in  but not in
> >>   .
> >
> > An open issue is what to do with semantic constrains.  For now, let's
> > assume they do not have to be valid.  This implies that you can have
> > leafrefs in  that refer to non-existing leafs.
> >
> > However, for choices, I don't think two cases can exist at the same
> > time even in operational state.  If we allow this, where do we draw
> > the line - can a container or leaf exist in multiple instances?  can
> > a leaf of type int32 contain a string?
>
> Certainly not. Rather than validate , it may be better to
> first merge  with current content of  to get the
> tentative
> future content of , and apply validation on it.
>
>

IMO this is not correct.

The running config cannot really be safely validated under this new model,
because unexpanded templates and inactive nodes should not part of the
validation.

The intended datastore should always be YANG-valid.
It is disjoint from the applied datastore.

Using your example of case A and case B -- it is OK for a control plane
protocol to override intended config (e.g., select case B causing case A
to be deleted from applied).  The intended is not altered (case A still
exists
in intended).

The applied datastore should be valid independent of intended.
You cannot merge them (e.g. case A and B not allowed to both exist).
You can only compare them to find out that intended was overridden
by a control protocol (e.g. case B is being used, not case A)

If the control protocol changes get removed then applied should reflect
the intended (e.g. case A reappears in applied)


Andy




>
>> >> >> 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.
>> >>
>> >> OK, perhaps it can be said that dynamic configuration protocols modify
>> >> "config true" data. Maybe a term like "configuration interface" may be
>> >> better because it needn't be a communication protocol, and it needn't
be
>> >> any more dynamic than NETCONF/RESTCONF is.
>> >
>> > Yes, we know that 'dynamic' is potentially misleading.
>>
>> My take from yesterday's discussion is that in fact the classification
>> is implementation-dependent.
>
> Yes it probably is.  But I'm not sure it is actually a problem.

It isn't, but you could base the classification on where each
contribution comes in instead of using fuzzy terms like dynamic
configuration protocol.

>
>> For example, if I use standard Linux
>> command-line tools such as "ip", their result can be seen only in
>> operational state, so they are like control-plane protocols. However, if
>> an implementation patches these tools so as to write to , then
>> they are dynamic configuration protocols.
>>
>> >
>> >> >> 5. Is it necessary that " 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  datastore tells me what is
>> >> > actually used (regardless of 

Re: [netmod] comments on revised-datastores-00

[Ladislav Lhotka]

Martin Bjorklund  writes:

> Ladislav Lhotka  wrote:
>> Juergen Schoenwaelder  writes:
>> 
>> > On Tue, Nov 15, 2016 at 09:48:35AM +0900, Ladislav Lhotka wrote:
>> >> Juergen Schoenwaelder  writes:
>> >> 
>> >> > 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  is valid, it can still be in conflict with the
>> >> >>actual content of  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.
>> >> 
>> >> That's fine but it doesn't answer my question.
>> >>
>> >
>> > Then I do not understand the question. What does it mean for a
>> > datastore to be in conflict with a different datastore?
>> 
>> For example:
>> 
>> - the data model has a choice with caseA and caseB. A NC/RC client
>>   configures caseA,  is valid, but  already contains
>>   caseB configured by a "dynamic configuration protocol"; or
>> 
>> - a leafref refers to a leaf that exists in  but not in
>>   .
>
> An open issue is what to do with semantic constrains.  For now, let's
> assume they do not have to be valid.  This implies that you can have
> leafrefs in  that refer to non-existing leafs.
>
> However, for choices, I don't think two cases can exist at the same
> time even in operational state.  If we allow this, where do we draw
> the line - can a container or leaf exist in multiple instances?  can
> a leaf of type int32 contain a string?

Certainly not. Rather than validate , it may be better to
first merge  with current content of  to get the tentative
future content of , and apply validation on it. 

>
>> >> >> 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.
>> >> 
>> >> OK, perhaps it can be said that dynamic configuration protocols modify
>> >> "config true" data. Maybe a term like "configuration interface" may be
>> >> better because it needn't be a communication protocol, and it needn't be
>> >> any more dynamic than NETCONF/RESTCONF is.
>> >
>> > Yes, we know that 'dynamic' is potentially misleading.
>> 
>> My take from yesterday's discussion is that in fact the classification
>> is implementation-dependent.
>
> Yes it probably is.  But I'm not sure it is actually a problem.

It isn't, but you could base the classification on where each
contribution comes in instead of using fuzzy terms like dynamic
configuration protocol.

>
>> For example, if I use standard Linux
>> command-line tools such as "ip", their result can be seen only in
>> operational state, so they are like control-plane protocols. However, if
>> an implementation patches these tools so as to write to , then
>> they are dynamic configuration protocols.
>> 
>> >
>> >> >> 5. Is it necessary that " 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  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  datastore is
>> >> > probably a good idea.
>> >> 
>> >> But could this part of operational state be possibly different from
>> >> what's already in ?
>> >
>> > This is subtle since we are not really able to define precisely what
>> > the boundaries of a datastore are. Is something applied if the
>> > responsible daemon accepted information? Or is it applied if the
>> > daemon communicated information to the kernel? Or is it applied if the
>> > linecard accepted the information from the kernel? Or is it applied if
>> > the specific registers of the linecard have been programmed?
>> 
>> In my view, at some point the configuration system hands over the data
>> to the backend that's responsible for performing the changes, and the
>> data passed to the backend should be the content of .
>
> The data passed to the backends is .  The backend then tries
> to apply it, and the result is /.

Hmm, 

Re: [netmod] comments on revised-datastores-00

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> Juergen Schoenwaelder  writes:
> 
> > On Tue, Nov 15, 2016 at 09:48:35AM +0900, Ladislav Lhotka wrote:
> >> Juergen Schoenwaelder  writes:
> >> 
> >> > 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  is valid, it can still be in conflict with the
> >> >>actual content of  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.
> >> 
> >> That's fine but it doesn't answer my question.
> >>
> >
> > Then I do not understand the question. What does it mean for a
> > datastore to be in conflict with a different datastore?
> 
> For example:
> 
> - the data model has a choice with caseA and caseB. A NC/RC client
>   configures caseA,  is valid, but  already contains
>   caseB configured by a "dynamic configuration protocol"; or
> 
> - a leafref refers to a leaf that exists in  but not in
>   .

An open issue is what to do with semantic constrains.  For now, let's
assume they do not have to be valid.  This implies that you can have
leafrefs in  that refer to non-existing leafs.

However, for choices, I don't think two cases can exist at the same
time even in operational state.  If we allow this, where do we draw
the line - can a container or leaf exist in multiple instances?  can
a leaf of type int32 contain a string?

> >> >> 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.
> >> 
> >> OK, perhaps it can be said that dynamic configuration protocols modify
> >> "config true" data. Maybe a term like "configuration interface" may be
> >> better because it needn't be a communication protocol, and it needn't be
> >> any more dynamic than NETCONF/RESTCONF is.
> >
> > Yes, we know that 'dynamic' is potentially misleading.
> 
> My take from yesterday's discussion is that in fact the classification
> is implementation-dependent.

Yes it probably is.  But I'm not sure it is actually a problem.

> For example, if I use standard Linux
> command-line tools such as "ip", their result can be seen only in
> operational state, so they are like control-plane protocols. However, if
> an implementation patches these tools so as to write to , then
> they are dynamic configuration protocols.
> 
> >
> >> >> 5. Is it necessary that " 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  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  datastore is
> >> > probably a good idea.
> >> 
> >> But could this part of operational state be possibly different from
> >> what's already in ?
> >
> > This is subtle since we are not really able to define precisely what
> > the boundaries of a datastore are. Is something applied if the
> > responsible daemon accepted information? Or is it applied if the
> > daemon communicated information to the kernel? Or is it applied if the
> > linecard accepted the information from the kernel? Or is it applied if
> > the specific registers of the linecard have been programmed?
> 
> In my view, at some point the configuration system hands over the data
> to the backend that's responsible for performing the changes, and the
> data passed to the backend should be the content of .

The data passed to the backends is .  The backend then tries
to apply it, and the result is /.



/martin

> Whether
> the changes take effect in the system or not may be discovered from
> operational state data but the configuration processing should be
> already over.  
> 
> > Similarily, how is operational state obtained? It is likely that an
> > implementation does not read linecard registers on every operational
> > state request. As a consequence, we might have systems where applied
> > really is just a subset of operational state and this may be true for
> > a large number of 

Re: [netmod] comments on revised-datastores-00

[Martin Bjorklund]

Juergen Schoenwaelder  wrote:
> On Tue, Nov 15, 2016 at 09:48:35AM +0900, Ladislav Lhotka wrote:
> > Juergen Schoenwaelder  writes:
> > 
> > > 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  is valid, it can still be in conflict with the
> > >>actual content of  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.
> > 
> > That's fine but it doesn't answer my question.
> >
> 
> Then I do not understand the question. What does it mean for a
> datastore to be in conflict with a different datastore?
> 
> > >> 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.
> > 
> > OK, perhaps it can be said that dynamic configuration protocols modify
> > "config true" data. Maybe a term like "configuration interface" may be
> > better because it needn't be a communication protocol, and it needn't be
> > any more dynamic than NETCONF/RESTCONF is.
> 
> Yes, we know that 'dynamic' is potentially misleading.
> 
> > >> 5. Is it necessary that " 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  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  datastore is
> > > probably a good idea.
> > 
> > But could this part of operational state be possibly different from
> > what's already in ?
> 
> This is subtle since we are not really able to define precisely what
> the boundaries of a datastore are. Is something applied if the
> responsible daemon accepted information? Or is it applied if the
> daemon communicated information to the kernel? Or is it applied if the
> linecard accepted the information from the kernel? Or is it applied if
> the specific registers of the linecard have been programmed?
> Similarily, how is operational state obtained? It is likely that an
> implementation does not read linecard registers on every operational
> state request. As a consequence, we might have systems where applied
> really is just a subset of operational state and this may be true for
> a large number of systems but I would not rule out the possibility of
> having differences between applied and operational state.

Note that in the draft,  is defined in terms of being a
subset of .  Specifially,  is the subset
of  where origin is 'static' or 'dynamic' (or
derived from them).


/martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] comments on revised-datastores-00

[Juergen Schoenwaelder]

On Wed, Nov 16, 2016 at 12:34:36PM +0900, Ladislav Lhotka wrote:
> Juergen Schoenwaelder  writes:
> 
> > On Tue, Nov 15, 2016 at 09:48:35AM +0900, Ladislav Lhotka wrote:
> >> Juergen Schoenwaelder  writes:
> >> 
> >> > 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  is valid, it can still be in conflict with the
> >> >>actual content of  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.
> >> 
> >> That's fine but it doesn't answer my question.
> >>
> >
> > Then I do not understand the question. What does it mean for a
> > datastore to be in conflict with a different datastore?
> 
> For example:
> 
> - the data model has a choice with caseA and caseB. A NC/RC client
>   configures caseA,  is valid, but  already contains
>   caseB configured by a "dynamic configuration protocol"; or
> 
> - a leafref refers to a leaf that exists in  but not in
>   .

It could be that  just did not get applied yet. It may also
be that some mechanism simply overruled what  wanted to
have. The whole reason we talk about these different datastores is to
be able to expose differences that may exist.

> >> >> 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.
> >> 
> >> OK, perhaps it can be said that dynamic configuration protocols modify
> >> "config true" data. Maybe a term like "configuration interface" may be
> >> better because it needn't be a communication protocol, and it needn't be
> >> any more dynamic than NETCONF/RESTCONF is.
> >
> > Yes, we know that 'dynamic' is potentially misleading.
> 
> My take from yesterday's discussion is that in fact the classification
> is implementation-dependent. For example, if I use standard Linux
> command-line tools such as "ip", their result can be seen only in
> operational state, so they are like control-plane protocols. However, if
> an implementation patches these tools so as to write to , then
> they are dynamic configuration protocols.

Talking about 'control-plane protocols' is difficult since there is
not precise definition people agree on. That said, it is an
implementation decision how things work. I can implement a
control-plane mechanism that it either modifies operational-state
directly or that it goes through a configuration management component
to coordinate changes. But yes, the Linux "ip" command talks to the
kernel an directly modifies operational state. (And this is true for
pretty much all open source control plane daemon implementations I
have seen on Linux.)

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] comments on revised-datastores-00

[Ladislav Lhotka]

Juergen Schoenwaelder  writes:

> On Tue, Nov 15, 2016 at 09:48:35AM +0900, Ladislav Lhotka wrote:
>> Juergen Schoenwaelder  writes:
>> 
>> > 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  is valid, it can still be in conflict with the
>> >>actual content of  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.
>> 
>> That's fine but it doesn't answer my question.
>>
>
> Then I do not understand the question. What does it mean for a
> datastore to be in conflict with a different datastore?

For example:

- the data model has a choice with caseA and caseB. A NC/RC client
  configures caseA,  is valid, but  already contains
  caseB configured by a "dynamic configuration protocol"; or

- a leafref refers to a leaf that exists in  but not in
  .

>
>> >> 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.
>> 
>> OK, perhaps it can be said that dynamic configuration protocols modify
>> "config true" data. Maybe a term like "configuration interface" may be
>> better because it needn't be a communication protocol, and it needn't be
>> any more dynamic than NETCONF/RESTCONF is.
>
> Yes, we know that 'dynamic' is potentially misleading.

My take from yesterday's discussion is that in fact the classification
is implementation-dependent. For example, if I use standard Linux
command-line tools such as "ip", their result can be seen only in
operational state, so they are like control-plane protocols. However, if
an implementation patches these tools so as to write to , then
they are dynamic configuration protocols.

>
>> >> 5. Is it necessary that " 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  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  datastore is
>> > probably a good idea.
>> 
>> But could this part of operational state be possibly different from
>> what's already in ?
>
> This is subtle since we are not really able to define precisely what
> the boundaries of a datastore are. Is something applied if the
> responsible daemon accepted information? Or is it applied if the
> daemon communicated information to the kernel? Or is it applied if the
> linecard accepted the information from the kernel? Or is it applied if
> the specific registers of the linecard have been programmed?

In my view, at some point the configuration system hands over the data
to the backend that's responsible for performing the changes, and the
data passed to the backend should be the content of . Whether
the changes take effect in the system or not may be discovered from
operational state data but the configuration processing should be
already over.  

> Similarily, how is operational state obtained? It is likely that an
> implementation does not read linecard registers on every operational
> state request. As a consequence, we might have systems where applied
> really is just a subset of operational state and this may be true for
> a large number of systems but I would not rule out the possibility of
> having differences between applied and operational state.

We don't currently have static routes in routing-state, despite all
criticism about duplication of config and state values, so it seems
rather backwards to duplicate it in the new datastore model. What's
important for an operator is to see whether a static route appears in a
RIB or not.

Lada

>
> /js
>
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] comments on revised-datastores-00

[Juergen Schoenwaelder]

On Tue, Nov 15, 2016 at 09:48:35AM +0900, Ladislav Lhotka wrote:
> Juergen Schoenwaelder  writes:
> 
> > 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  is valid, it can still be in conflict with the
> >>actual content of  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.
> 
> That's fine but it doesn't answer my question.
>

Then I do not understand the question. What does it mean for a
datastore to be in conflict with a different datastore?

> >> 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.
> 
> OK, perhaps it can be said that dynamic configuration protocols modify
> "config true" data. Maybe a term like "configuration interface" may be
> better because it needn't be a communication protocol, and it needn't be
> any more dynamic than NETCONF/RESTCONF is.

Yes, we know that 'dynamic' is potentially misleading.

> >> 5. Is it necessary that " 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  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  datastore is
> > probably a good idea.
> 
> But could this part of operational state be possibly different from
> what's already in ?

This is subtle since we are not really able to define precisely what
the boundaries of a datastore are. Is something applied if the
responsible daemon accepted information? Or is it applied if the
daemon communicated information to the kernel? Or is it applied if the
linecard accepted the information from the kernel? Or is it applied if
the specific registers of the linecard have been programmed?
Similarily, how is operational state obtained? It is likely that an
implementation does not read linecard registers on every operational
state request. As a consequence, we might have systems where applied
really is just a subset of operational state and this may be true for
a large number of systems but I would not rule out the possibility of
having differences between applied and operational state.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] comments on revised-datastores-00

[Juergen Schoenwaelder]

On Mon, Nov 14, 2016 at 01:42:18PM -0800, Andy Bierman wrote:
> 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).

Note that running == intended as long as you do not support inactive
node (commented out notes) or template expansion. If you do support
either of these extensions, that what you validate is actually
intended and not running. For example, inactive (comment out) nodes do
not matter for the validation.
 
> 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.

Yes, the protocol interaction do of course matter.

> Each datastore (running, intended, applied) can all be different, they can
> all be YANG-valid, but I;m not sure that buys anything.

The current YANG valication rules apply to running/intended. The applied
configuration datastore includes dynamic elements hence validation (if
does exist for applied) likely has to have different semantics.

> It seems complicated to determine that my specific edit is applied
> yet, while there are many writers to the data subtrees.

Yes, since applied and operational-state are in general constantly
changing, it is not really possible to have well-defined
synchronization points at which things can be checked to be valid.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] comments on revised-datastores-00

[Andy Bierman]

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 <m...@tail-f.com> wrote:

> Hi,
>
> "Susan Hares" <sha...@ndzh.com> 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  and the i2rs-defined
> routes in the-new-i2rs-datastore.
>
>
> /martin
>
>
> >
> > Thanks,
> >
> > Sue
> >
> > -Original Message-
> > From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Juergen
> > Schoenwaelder
> > Sent: Monday, November 14, 2016 4:42 AM
> > To: Ladislav Lhotka
> > Cc: netmod@ietf.org
> > 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  is valid, it can still be in conflict with the
> > >actual content of  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  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 " 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
> >  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
> >  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
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] comments on revised-datastores-00

[Martin Bjorklund]

Hi,

"Susan Hares" <sha...@ndzh.com> 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  and the i2rs-defined
routes in the-new-i2rs-datastore.


/martin


> 
> Thanks, 
> 
> Sue 
> 
> -Original Message-
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Juergen
> Schoenwaelder
> Sent: Monday, November 14, 2016 4:42 AM
> To: Ladislav Lhotka
> Cc: netmod@ietf.org
> 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  is valid, it can still be in conflict with the
> >actual content of  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  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 " 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
>  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
>  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
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] comments on revised-datastores-00

[Susan Hares]

Juergen and Lada: 

#2 - is interesting to me.  Is dynamic configuration protocol = I2RS? Or
control-plane protocols = I2RS? 
On #5 - how do you merge I2RS RIB static routes  + routing-configuration rib
routes?  Can you see the difference in the applied configuration? 

Thanks, 

Sue 

-Original Message-
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Juergen
Schoenwaelder
Sent: Monday, November 14, 2016 4:42 AM
To: Ladislav Lhotka
Cc: netmod@ietf.org
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  is valid, it can still be in conflict with the
>actual content of  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  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 " 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
 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
 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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] comments on revised-datastores-00

[Juergen Schoenwaelder]

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  is valid, it can still be in conflict with the
>actual content of  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  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 " 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  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  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 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] comments on revised-datastores-00

[Ladislav Lhotka]

Hi,

I've read the revised-datastores-00 document, in general I like it, here
are my initial comments and questions:

1. Even if  is valid, it can still be in conflict with the
   actual content of  that may come from e.g. dynamic
   configuration protocols. How are such cases supposed to be resolved?

2. What is the distinction between dynamic configuration protocols and
   control-plane protocols?

3. Shared  has known problems. Maybe it's time to part with
   it in this new datastore model?

4. Templates are briefly mentioned in several places, it would be useful
   to explain this concept in more detail.

5. Is it necessary that " 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.

Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod