Re: [netmod] [yang-doctors] Resigning Chair Position

[Benoit Claise]

Thanks Tom for your years of service in this very important WG.

Joel and I are working on a replacement plan.

Regards, Benoit


I am writing to the NETMOD WG to inform you all that I will be 
resigning my position as co-chair.  I will remain on as co-chair and continue 
my duties until Benoit finds a suitable replacement, which he tells me will not 
be too long.  It has been a challenge and pleasure serving the community as 
co-chair over the past 2 years. I learned a lot in this role, and I hope I 
served the community well.  I hope to continue working with many of you in the 
capacity of an individual contributor in and around the area of Yang and model 
creation.

Cheers,

—Tom

___
yang-doctors mailing list
yang-doct...@ietf.org
https://www.ietf.org/mailman/listinfo/yang-doctors


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

Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt

[Robert Wilton]

On 10/01/2016 11:21, Juergen Schoenwaelder wrote:

On Fri, Jan 08, 2016 at 01:46:44PM +, Acee Lindem (acee) wrote:

The draft is quite succinct and I’m not sure how you and Juergen do not
agree that there are requirements beyond intended/applied state. Perhaps
you do not agree with them? Refer to requirements 3.(B & C) and 4.(B & C).
For your convenience, I’ve excerpted them below:


3.  Separation of the applied configuration and derived state aspects
of operational state; ability to retrieve them independently and
together

A.  Be able to retrieve only the applied configuration aspects of
operational state

B.  Be able to retrieve only the derived state aspects of
operational state

This is nothing new. See for example section 4.3.3.2 of RFC 6244.


C.  Be able to retrieve both the applied configuration and
derived state aspects of operational state together

Did you notice that 3.C talks about 'applied configuration'?
  

4.  Ability to relate configuration with its corresponding
operational state

A.  Ability to map intended config nodes to corresponding applied
config nodes

B.  Ability to map intended config nodes to associated derived
state nodes

C.  The mappings needs to be programmatically consumable

I do not agree that 4.B and 4.C require to broaden the title.

In fact, I wonder why 4.B is useful. If we agree that the applied
config (an extended subset of the intended config) is the configration
that determines what the device is doing, then we likely should have a
mapping of the applied config to associated derived state.
Yes, in essence the relationship is intended config => applied config => 
derived state.  So I would say that derived state has a transitive 
association with the intended config.


Personally, I think that the relationship should be expressed in the 
reverse direction.  I.e. a particular node of derived state should be 
allowed to refer back to the config (intended/applied) that is derived 
from.  This is presumably an implementation detail rather than a 
requirement.


However, I'm not sure that we actually need to change the text, I think 
that the requirement text is probably sufficiently clear to compare 
solutions.


Thanks,
Rob




/js



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

Re: [netmod] 6087bis namespace recommendations

[Martin Bjorklund]

Juergen Schoenwaelder  wrote:
> On Mon, Jan 11, 2016 at 10:15:26AM +0100, Martin Bjorklund wrote:
> > Hi,
> > 
> > Currently, 6087bis says that standards-track, published and
> > unpublished modules SHOULD use the URN prefix
> > "urn:ietf:params:xml:ns:yang:".
> > 
> > There are two issues with this:
> > 
> >   1.  We already publish experimental modules w/ this prefix.
> >   (ietf-netconf-time and ietf-complex-types).
> > 
> >   So 6087bis should remove "standards track" from this
> >   recommendation.
> 
> Well, the current text is silent about non-standards-track modules

No, it says:

  Note that a different URN prefix string SHOULD be used for
  non-Standards-Track modules.

> so
> there is not really a conflict. While searching through 6087, I think
> it is more important to clarify the usage of 'publish'. One solution
> would be to use 'publishing' when we talk about the publication of
> RFCs and to use 'posting' when we talk about the posting of an
> Internet-Draft. But yes, this is a different can of worms.
> 
> >   2.  There was some discussion about recommending a different URN
> >   prefix for unpublished modules (i.e., modules in Internet
> >   Drafts).
> > 
> >   Should 6087bis recommend some special urn prefix for drafts,
> >   with a note to the RFC editor to change the namespace once it
> >   has been registered with IANA?
> 
> Do we have evidence that having such a rule makes the Internet work
> better?

I don't know, but apparently there can be confusion when an extracted
module from a draft is passed around.

What can we learn from the SNMP experience where the OID assignement
is done by IANA - good or bad?


/martin

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

Re: [netmod] 6087bis namespace recommendations

[Juergen Schoenwaelder]

On Mon, Jan 11, 2016 at 10:15:26AM +0100, Martin Bjorklund wrote:
> Hi,
> 
> Currently, 6087bis says that standards-track, published and
> unpublished modules SHOULD use the URN prefix
> "urn:ietf:params:xml:ns:yang:".
> 
> There are two issues with this:
> 
>   1.  We already publish experimental modules w/ this prefix.
>   (ietf-netconf-time and ietf-complex-types).
> 
>   So 6087bis should remove "standards track" from this
>   recommendation.

Well, the current text is silent about non-standards-track modules, so
there is not really a conflict. While searching through 6087, I think
it is more important to clarify the usage of 'publish'. One solution
would be to use 'publishing' when we talk about the publication of
RFCs and to use 'posting' when we talk about the posting of an
Internet-Draft. But yes, this is a different can of worms.

>   2.  There was some discussion about recommending a different URN
>   prefix for unpublished modules (i.e., modules in Internet
>   Drafts).
> 
>   Should 6087bis recommend some special urn prefix for drafts,
>   with a note to the RFC editor to change the namespace once it
>   has been registered with IANA?

Do we have evidence that having such a rule makes the Internet work
better?

> And another issue.  6087bis also has this:
> 
> OLD: 
> 
>   The following examples are for non-Standards-Track modules.
>   The domain "example.com" SHOULD be used in all namespace URIs
>   for example modules.
> 
>   http://example.com/ns/example-interfaces
> 
>   http://example.com/ns/example-system
> 
> 
> First of all, the sentence about non-Standards-Track modules is
> confusing.  Second, since the publication of RFC 6087, RFC 6963 has
> been published, which defines a URN for examples.  I suggest we update
> 6087bis like this:
> 
> NEW:
> 
>   Example modules in all types of documents SHOULD use a namespace
>   with either the example URN [RFC 6963] or the domain "example.com".
>   For example:
> 
>   urn:example:interfaces
> 
>   http://example.com/ns/example-system

Adopting urn:example makes sense to me.

/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] 6087bis namespace recommendations

[Martin Bjorklund]

Hi,

Currently, 6087bis says that standards-track, published and
unpublished modules SHOULD use the URN prefix
"urn:ietf:params:xml:ns:yang:".

There are two issues with this:

  1.  We already publish experimental modules w/ this prefix.
  (ietf-netconf-time and ietf-complex-types).

  So 6087bis should remove "standards track" from this
  recommendation.

  2.  There was some discussion about recommending a different URN
  prefix for unpublished modules (i.e., modules in Internet
  Drafts).

  Should 6087bis recommend some special urn prefix for drafts,
  with a note to the RFC editor to change the namespace once it
  has been registered with IANA?

And another issue.  6087bis also has this:

OLD: 

  The following examples are for non-Standards-Track modules.
  The domain "example.com" SHOULD be used in all namespace URIs
  for example modules.

  http://example.com/ns/example-interfaces

  http://example.com/ns/example-system


First of all, the sentence about non-Standards-Track modules is
confusing.  Second, since the publication of RFC 6087, RFC 6963 has
been published, which defines a URN for examples.  I suggest we update
6087bis like this:

NEW:

  Example modules in all types of documents SHOULD use a namespace
  with either the example URN [RFC 6963] or the domain "example.com".
  For example:

  urn:example:interfaces

  http://example.com/ns/example-system
 


/martin

  

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

Re: [netmod] 6087bis namespace recommendations

[Juergen Schoenwaelder]

On Mon, Jan 11, 2016 at 11:21:43AM +0100, Martin Bjorklund wrote:
> Juergen Schoenwaelder  wrote:
> > On Mon, Jan 11, 2016 at 10:15:26AM +0100, Martin Bjorklund wrote:
> > > Hi,
> > > 
> > > Currently, 6087bis says that standards-track, published and
> > > unpublished modules SHOULD use the URN prefix
> > > "urn:ietf:params:xml:ns:yang:".
> > > 
> > > There are two issues with this:
> > > 
> > >   1.  We already publish experimental modules w/ this prefix.
> > >   (ietf-netconf-time and ietf-complex-types).
> > > 
> > >   So 6087bis should remove "standards track" from this
> > >   recommendation.
> > 
> > Well, the current text is silent about non-standards-track modules
> 
> No, it says:
> 
>   Note that a different URN prefix string SHOULD be used for
>   non-Standards-Track modules.

Well, yes, this is likely in need of a fix then.
 
> > so
> > there is not really a conflict. While searching through 6087, I think
> > it is more important to clarify the usage of 'publish'. One solution
> > would be to use 'publishing' when we talk about the publication of
> > RFCs and to use 'posting' when we talk about the posting of an
> > Internet-Draft. But yes, this is a different can of worms.
> > 
> > >   2.  There was some discussion about recommending a different URN
> > >   prefix for unpublished modules (i.e., modules in Internet
> > >   Drafts).
> > > 
> > >   Should 6087bis recommend some special urn prefix for drafts,
> > >   with a note to the RFC editor to change the namespace once it
> > >   has been registered with IANA?
> > 
> > Do we have evidence that having such a rule makes the Internet work
> > better?
> 
> I don't know, but apparently there can be confusion when an extracted
> module from a draft is passed around.
> 
> What can we learn from the SNMP experience where the OID assignement
> is done by IANA - good or bad?

With MIB modules, the module OID is assigned by IANA and we usually
have a placeholder (which makes the module not compile). With SNMP, we
converged to register the majority of modules below mib-2 and hence if
people pick numbers, they have a high potential for collision. With
NETCONF namespaces, the collision probability is rather low. The other
aspect is that an official assignment happens late during the process,
e.g., as part of the RFC publication process and there might be early
implementations that use a 'speculative' namespace value. In a perfect
world, we should likely use a different prefix while the module is
under development and then let IANA have the final say on the official
prefix. And if Lada is really concerned about problems caused if I-D
implementations, we could do lets say a series of

  urn:ietf:params:xml:ns:yang:draft-ietf-netmod-routing-cfg-00
  ...
  urn:ietf:params:xml:ns:yang:draft-ietf-netmod-routing-cfg-20

in I-Ds and then the RFC editor finally changes things to

  urn:ietf:params:xml:ns:yang:ietf-routing

if IANA agrees to allocate this URN to the module. Of course, this
means more work for the editors involved and so far our lax handling
of this issue seems to have worked. (But so it did for MIB modules
until problems started to show up.)

/js

PS: Note that JSON encoding uses the module name and not the namespace
and hence even if we do the above, module names in JSON won't
signal the difference between I-D and published RFC versions of a
module. So to be really fool proof one would have to change the
module name also with every posted I-D. The question is at which
point in time bureaucracy hampers productivity and perhaps what we
do today is not perfect but a reasonable trade-off.

PS: Another option could be a YANG keyword that declares the status of
a module, 'draft', 'published', 'experimental', 'example',
'obsolete' and then the RFC editor would only have to toggle this
value and tools could still distinguish the different kinds of
YANG modules.

-- 
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] I-D Action: draft-ietf-netmod-opstate-reqs-03.txt

[Kent Watsen]

Hi Benoit,


>You use MUST, SHOULD, MAY, and you refer to RFC 2119. Fine.
>However, it might be beneficial to say something such as in RFC 7698
>
>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>document are to be interpreted as described in [RFC2119].
>
>While [RFC2119] describes interpretations of these key words in terms
>of protocol specifications and implementations, they are used in this
>document to describe design requirements for protocol extensions.

Is this needed?  Looking at RFC2119, I don’t read it as being very particular 
about the context it’s terms are used in.

Additionally, other requirements docs use RFC2119 without any such a paragraph 
(e.g., RFC7698, RFC7497, RFC7449, etc.)...


>Btw, I never quite understood what a MAY means for a requirement.
>See requirement 2B and 2C

For 2B, would you rather is be a SHOULD?
For 2C, would you rather this be a “may”?

FWIW, the other requirements docs listed above also use "MAY" in some of their 
“requirements"


Kent


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

Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-02.txt

[Juergen Schoenwaelder]

On Mon, Jan 11, 2016 at 11:02:30AM +, Robert Wilton wrote:
> 
> 
> On 10/01/2016 11:21, Juergen Schoenwaelder wrote:
> >On Fri, Jan 08, 2016 at 01:46:44PM +, Acee Lindem (acee) wrote:
> >>The draft is quite succinct and I’m not sure how you and Juergen do not
> >>agree that there are requirements beyond intended/applied state. Perhaps
> >>you do not agree with them? Refer to requirements 3.(B & C) and 4.(B & C).
> >>For your convenience, I’ve excerpted them below:
> >>
> >>
> >>3.  Separation of the applied configuration and derived state aspects
> >>of operational state; ability to retrieve them independently and
> >>together
> >>
> >>A.  Be able to retrieve only the applied configuration aspects of
> >>operational state
> >>
> >>B.  Be able to retrieve only the derived state aspects of
> >>operational state
> >This is nothing new. See for example section 4.3.3.2 of RFC 6244.
> >
> >>C.  Be able to retrieve both the applied configuration and
> >>derived state aspects of operational state together
> >Did you notice that 3.C talks about 'applied configuration'?
> >  
> >>4.  Ability to relate configuration with its corresponding
> >>operational state
> >>
> >>A.  Ability to map intended config nodes to corresponding applied
> >>config nodes
> >>
> >>B.  Ability to map intended config nodes to associated derived
> >>state nodes
> >>
> >>C.  The mappings needs to be programmatically consumable
> >I do not agree that 4.B and 4.C require to broaden the title.
> >
> >In fact, I wonder why 4.B is useful. If we agree that the applied
> >config (an extended subset of the intended config) is the configration
> >that determines what the device is doing, then we likely should have a
> >mapping of the applied config to associated derived state.
> Yes, in essence the relationship is intended config => applied config => 
> derived state.  So I would say that derived state has a transitive 
> association with the intended config.

Yes. But applied config might include something that is not intended
config, which would be lost if we map intended config => derived state.
 
> Personally, I think that the relationship should be expressed in the 
> reverse direction.  I.e. a particular node of derived state should be 
> allowed to refer back to the config (intended/applied) that is derived 
> from.  This is presumably an implementation detail rather than a 
> requirement.

Yes, I wrote about this earlier - some several weeks ago. What is
really helpful for a managing system is to know the source of derived
state, be it applied config, be it a routing protocol daemon, be it a
dhcp server, be it a piece of tunneling software, be it an I2RS
agent. So yes, I agree with you that the reverse direction is
desirable (e.g., have meta data for derived state that explains where
the state if originating from). What I also explained back then is
that a standard Linux kernel does not track this context for many
resources, which makes this somewhat difficult (= expensive) to
implement. But yes, from a management point perspective, knowing the
source of derived state is truly helpful in my experience.

> However, I'm not sure that we actually need to change the text, I think 
> that the requirement text is probably sufficiently clear to compare 
> solutions.

Perhaps. I just wanted to point out in my email that even 4.B involves
applied config if done right and hence the document really is grounded
on the distinction of applied config and intended config.

/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] applied configuration and system-controlled entries

[Acee Lindem (acee)]

On 1/11/16, 2:54 PM, "netmod on behalf of Martin Bjorklund"
 wrote:

>Ladislav Lhotka  wrote:
>> Hi Gert,
>> 
>> > On 11 Jan 2016, at 14:25, Gert Grammel  wrote:
>> > 
>> > Lada,
>> > 
>> > The requirement says:
>> >   D.  When a configuration change for any intended configuration
>> >   node has been successfully applied to the server (e.g. not
>> >   failed, nor deferred due to absent hardware) then the
>> >   existence and value of the corresponding applied
>> >   configuration node must match the intended configuration
>> >   node.
>> > 
>> > I don't see that this would limit the case you described below. In
>> > your case there is no intended config, hence there is no
>> > "corresponding applied configuration" either.
>> 
>> You are right, the requirement can be interpreted this way. I thought
>> that applied configuration was supposed to be identical to intended
>> after some synchronization period.
>
>This is a very important point to clarify.  Can there ever be data in
>"applied" that is not in "intended"?  I think Anees & Rob previously
>said "no", but I might be wrong.

My opinion is that there is a 1-1 relationship between “applied” and
“intended” config.

Thanks,
Acee 

>
>
>
>/martin
>
>
>> 
>> > 
>> > Besides that, the case you mentioned should be clearly in scope.
>> 
>> Great, then I am open to discussing what this could mean for the
>> existing modules (ietf-interfaces, ietf-routing, ACL etc.).
>> 
>> One useful change to YANG semantics could be that a leafref with
>> require-instance=true would refer to applied
>> configuration. Specifically, the ACL module could then simply use
>> "if:interface-ref" (with require-instance=true) as the type for
>> "input-interface".
>> 
>> Thanks, Lada
>> 
>> >  
>> > 
>> > --Gert
>> > 
>> >> -Original Message-
>> >> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Ladislav
>> >> Lhotka
>> >> Sent: 07 January 2016 11:20
>> >> To: NETMOD WG
>> >> Subject: [netmod] applied configuration and system-controlled entries
>> >> 
>> >> Hi,
>> >> 
>> >> a good use of applied configuration could be to formalize the concept
>> >> of
>> >> system-controlled entries as defined in RFC 7223, routing-cfg, and
>> >> probably
>> >> elsewhere, too.
>> >> 
>> >> My idea is that system-controlled interfaces or other entries would
>> >> appear in
>> >> applied configuration, but not in intended configuration until
>> >> something needs
>> >> to be really configured. We could then permit leafrefs from intended
>> >> configuration to refer to leafs in applied configuration. One case
>> >> where this
>> >> would be useful is the ACL module, where match conditions refering to
>> >> interfaces currently have to use plain strings as references to
>> >> interface names.
>> >> 
>> >> However, the above idea seems to be at odds with requirement 1D in
>> >> opstate-
>> >> reqs-02. I wonder: could that requirement be relaxed or removed so
>> >> that the
>> >> above use case can be supported?
>> >> 
>> >> Thanks, Lada
>> >> 
>> >> --
>> >> Ladislav Lhotka, CZ.NIC Labs
>> >> PGP Key ID: E74E8C0C
>> >> 
>> >> 
>> >> 
>> >> 
>> >> ___
>> >> netmod mailing list
>> >> netmod@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/netmod
>> 
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>> 
>> 
>> 
>> 
>> ___
>> 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] applied configuration and system-controlled entries

[Ladislav Lhotka]

> On 11 Jan 2016, at 15:07, Acee Lindem (acee)  wrote:
> 
> 
> 
> On 1/11/16, 2:54 PM, "netmod on behalf of Martin Bjorklund"
>  wrote:
> 
>> Ladislav Lhotka  wrote:
>>> Hi Gert,
>>> 
 On 11 Jan 2016, at 14:25, Gert Grammel  wrote:
 
 Lada,
 
 The requirement says:
  D.  When a configuration change for any intended configuration
  node has been successfully applied to the server (e.g. not
  failed, nor deferred due to absent hardware) then the
  existence and value of the corresponding applied
  configuration node must match the intended configuration
  node.
 
 I don't see that this would limit the case you described below. In
 your case there is no intended config, hence there is no
 "corresponding applied configuration" either.
>>> 
>>> You are right, the requirement can be interpreted this way. I thought
>>> that applied configuration was supposed to be identical to intended
>>> after some synchronization period.
>> 
>> This is a very important point to clarify.  Can there ever be data in
>> "applied" that is not in "intended"?  I think Anees & Rob previously
>> said "no", but I might be wrong.
> 
> My opinion is that there is a 1-1 relationship between “applied” and
> “intended” config.

Do you mean their data model or instances? The point is: if the device has an 
interface, say "eth0" that is operational and configurable, but hasn't been 
configured so far via intended config, then does "eth0" entry appear in the 
"if:interface" list of applied config or not?

Lada

> 
> Thanks,
> Acee 
> 
>> 
>> 
>> 
>> /martin
>> 
>> 
>>> 
 
 Besides that, the case you mentioned should be clearly in scope.
>>> 
>>> Great, then I am open to discussing what this could mean for the
>>> existing modules (ietf-interfaces, ietf-routing, ACL etc.).
>>> 
>>> One useful change to YANG semantics could be that a leafref with
>>> require-instance=true would refer to applied
>>> configuration. Specifically, the ACL module could then simply use
>>> "if:interface-ref" (with require-instance=true) as the type for
>>> "input-interface".
>>> 
>>> Thanks, Lada
>>> 
 
 
 --Gert
 
> -Original Message-
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Ladislav
> Lhotka
> Sent: 07 January 2016 11:20
> To: NETMOD WG
> Subject: [netmod] applied configuration and system-controlled entries
> 
> Hi,
> 
> a good use of applied configuration could be to formalize the concept
> of
> system-controlled entries as defined in RFC 7223, routing-cfg, and
> probably
> elsewhere, too.
> 
> My idea is that system-controlled interfaces or other entries would
> appear in
> applied configuration, but not in intended configuration until
> something needs
> to be really configured. We could then permit leafrefs from intended
> configuration to refer to leafs in applied configuration. One case
> where this
> would be useful is the ACL module, where match conditions refering to
> interfaces currently have to use plain strings as references to
> interface names.
> 
> However, the above idea seems to be at odds with requirement 1D in
> opstate-
> reqs-02. I wonder: could that requirement be relaxed or removed so
> that the
> above use case can be supported?
> 
> Thanks, Lada
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> 
> 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>>> 
>>> --
>>> Ladislav Lhotka, CZ.NIC Labs
>>> PGP Key ID: E74E8C0C
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> 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

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




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

Re: [netmod] [yang-doctors] [Rtg-dt-yang-arch] Working group Last Call: draft-ietf-netmod-acl-model-06

[Juergen Schoenwaelder]

I think we discussed at one of the previous IETFs that we will use
YANG 1.1 in the IETF once it is published. Please check the archives.
If I am correct, then you would have to be fast with finishing the ACL
model.

/js

On Mon, Jan 11, 2016 at 12:16:40PM +0100, Dean Bogdanovic wrote:
> Are there any other opinions on switching YANG version for ACL model from 1.0 
> to 1.1? Would like to get more opinions on this, besides Martin.
> 
> Dean
> 
> > On Jan 8, 2016, at 1:26 PM, Martin Bjorklund  wrote:
> > 
> > Dean Bogdanovic > wrote:
> >> 
> >>> On Jan 8, 2016, at 1:09 PM, Juergen Schoenwaelder
> >>>  wrote:
> >>> 
> >>> On Fri, Jan 08, 2016 at 12:52:37PM +0100, Martin Bjorklund wrote:
>  Juergen Schoenwaelder  wrote:
> > On Thu, Jan 07, 2016 at 04:21:42PM +0100, Martin Bjorklund wrote:
> >> 
> >> With YANG 1.1, a leafref can be marked as "require-instance false",
> >> which allows a interface-state-ref to be used in config:
> >> 
> >>  type if:interface-state-ref {
> >>require-instance false;
> >>  }
> >>  // + add description that explains what happens if there is no such
> >>  //   instance
> >> 
> >> 
> >> (NOTE: this doesn't work w/ pyang at the momement, I am working on a
> >> fix)
> >> 
> > 
> > And it would have to be if:interface-ref instead
> > if:interface-state-ref
> > I think.
>  
>  No, I meant interface-state-ref.  This way you can put a filter on
>  non-configured interfaces.
>  
> >>> 
> >>> But with require-instance false, this is also true for
> >>> if:interface-ref.  If I preconfigure and interface, I might also want
> >>> to preconfigure ACLs refering the preconfigure interface. And note
> >>> that if:interface-state-ref refers to a config false leaf.
> >> 
> >> In this case we have to change to yang-version 1.1. The plan was to
> >> have it for 1.0. Do we want to move the ACL model to YANG minimum
> >> version 1.1?
> > 
> > I think it is ok.  We're fixing issues like this one in 1.1 so that we
> > don't have to rely on various workarounds.  Note that the second WGLC
> > for 1.1 just ended, w/ mostly minor proposed edits.
> > 
> > 
> > /martin
> 

-- 
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] [yang-doctors] [Rtg-dt-yang-arch] Working group Last Call: draft-ietf-netmod-acl-model-06

[Robert Wilton]

Hi Dean,

I agree with Martin's proposed solution.

I.e. switch to YANG 1.1, and use his proposed interface-state-ref & 
require-instance false solution.


Thanks,
Rob


On 11/01/2016 11:16, Dean Bogdanovic wrote:
Are there any other opinions on switching YANG version for ACL model 
from 1.0 to 1.1? Would like to get more opinions on this, besides Martin.


Dean

On Jan 8, 2016, at 1:26 PM, Martin Bjorklund > wrote:


Dean Bogdanovic > wrote:



On Jan 8, 2016, at 1:09 PM, Juergen Schoenwaelder
> wrote:


On Fri, Jan 08, 2016 at 12:52:37PM +0100, Martin Bjorklund wrote:
Juergen Schoenwaelder > wrote:

On Thu, Jan 07, 2016 at 04:21:42PM +0100, Martin Bjorklund wrote:


With YANG 1.1, a leafref can be marked as "require-instance false",
which allows a interface-state-ref to be used in config:

 type if:interface-state-ref {
   require-instance false;
 }
 // + add description that explains what happens if there is no such
 //   instance


(NOTE: this doesn't work w/ pyang at the momement, I am working on a
fix)



And it would have to be if:interface-ref instead
if:interface-state-ref
I think.


No, I meant interface-state-ref.  This way you can put a filter on
non-configured interfaces.



But with require-instance false, this is also true for
if:interface-ref.  If I preconfigure and interface, I might also want
to preconfigure ACLs refering the preconfigure interface. And note
that if:interface-state-ref refers to a config false leaf.


In this case we have to change to yang-version 1.1. The plan was to
have it for 1.0. Do we want to move the ACL model to YANG minimum
version 1.1?


I think it is ok.  We're fixing issues like this one in 1.1 so that we
don't have to rely on various workarounds.  Note that the second WGLC
for 1.1 just ended, w/ mostly minor proposed edits.


/martin




___
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] applied configuration and system-controlled entries

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> Hi Gert,
> 
> > On 11 Jan 2016, at 14:25, Gert Grammel  wrote:
> > 
> > Lada,
> > 
> > The requirement says:
> >   D.  When a configuration change for any intended configuration
> >   node has been successfully applied to the server (e.g. not
> >   failed, nor deferred due to absent hardware) then the
> >   existence and value of the corresponding applied
> >   configuration node must match the intended configuration
> >   node.
> > 
> > I don't see that this would limit the case you described below. In
> > your case there is no intended config, hence there is no
> > "corresponding applied configuration" either.
> 
> You are right, the requirement can be interpreted this way. I thought
> that applied configuration was supposed to be identical to intended
> after some synchronization period.

This is a very important point to clarify.  Can there ever be data in
"applied" that is not in "intended"?  I think Anees & Rob previously
said "no", but I might be wrong.



/martin


> 
> > 
> > Besides that, the case you mentioned should be clearly in scope.
> 
> Great, then I am open to discussing what this could mean for the
> existing modules (ietf-interfaces, ietf-routing, ACL etc.).
> 
> One useful change to YANG semantics could be that a leafref with
> require-instance=true would refer to applied
> configuration. Specifically, the ACL module could then simply use
> "if:interface-ref" (with require-instance=true) as the type for
> "input-interface".
> 
> Thanks, Lada
> 
> >  
> > 
> > --Gert
> > 
> >> -Original Message-
> >> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Ladislav
> >> Lhotka
> >> Sent: 07 January 2016 11:20
> >> To: NETMOD WG
> >> Subject: [netmod] applied configuration and system-controlled entries
> >> 
> >> Hi,
> >> 
> >> a good use of applied configuration could be to formalize the concept
> >> of
> >> system-controlled entries as defined in RFC 7223, routing-cfg, and
> >> probably
> >> elsewhere, too.
> >> 
> >> My idea is that system-controlled interfaces or other entries would
> >> appear in
> >> applied configuration, but not in intended configuration until
> >> something needs
> >> to be really configured. We could then permit leafrefs from intended
> >> configuration to refer to leafs in applied configuration. One case
> >> where this
> >> would be useful is the ACL module, where match conditions refering to
> >> interfaces currently have to use plain strings as references to
> >> interface names.
> >> 
> >> However, the above idea seems to be at odds with requirement 1D in
> >> opstate-
> >> reqs-02. I wonder: could that requirement be relaxed or removed so
> >> that the
> >> above use case can be supported?
> >> 
> >> Thanks, Lada
> >> 
> >> --
> >> Ladislav Lhotka, CZ.NIC Labs
> >> PGP Key ID: E74E8C0C
> >> 
> >> 
> >> 
> >> 
> >> ___
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netmod
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> 
> 
> 
> ___
> 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] applied configuration and system-controlled entries

[Acee Lindem (acee)]

On 1/11/16, 3:13 PM, "Juergen Schoenwaelder"
 wrote:

>On Mon, Jan 11, 2016 at 02:07:13PM +, Acee Lindem (acee) wrote:
>> 
>> My opinion is that there is a 1-1 relationship between “applied” and
>> “intended” config.
>>
>
>I do not understand. Please clarify what 1-1 means here.

In the context of these requirements, I do not agree that applied config
includes anything else. The data models for the intended and applied
config are the aligned and all other state falls in the category of
derived state.  

Thanks,
Acee 

>
>/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] applied configuration and system-controlled entries

[Robert Wilton]

On 11/01/2016 14:11, Juergen Schoenwaelder wrote:

On Mon, Jan 11, 2016 at 02:54:36PM +0100, Martin Bjorklund wrote:

Ladislav Lhotka  wrote:

Hi Gert,


On 11 Jan 2016, at 14:25, Gert Grammel  wrote:

Lada,

The requirement says:
   D.  When a configuration change for any intended configuration
   node has been successfully applied to the server (e.g. not
   failed, nor deferred due to absent hardware) then the
   existence and value of the corresponding applied
   configuration node must match the intended configuration
   node.

I don't see that this would limit the case you described below. In
your case there is no intended config, hence there is no
"corresponding applied configuration" either.

You are right, the requirement can be interpreted this way. I thought
that applied configuration was supposed to be identical to intended
after some synchronization period.

This is a very important point to clarify.  Can there ever be data in
"applied" that is not in "intended"?  I think Anees & Rob previously
said "no", but I might be wrong.


If there is time delay between editing intended and the applied config
matching the edits of intended, then I supose this can happen (I
delete a resource from intended but it is still around until intended
has been fully synced). I would find it interesting if some edits are
always assumed to be synchronous but others may be asynchronous.

And Lada, I think applied may happen to be never identical to intended
if, for example, hardware is absent or other missing resources prevent
certain parts of intended to become applied.

My understanding is that applied config in general forms an extended
subset of intended config. And to fully understand what a device is
doing, I may need to obtain its entire operational state since the
applied config may not include state obtained dynamically from other
sources.

But I might still all be wrong...

I think that your articulation is correct.

Thanks,
Rob




/js



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

Re: [netmod] applied configuration and system-controlled entries

[Ladislav Lhotka]

Hi Gert,

> On 11 Jan 2016, at 14:25, Gert Grammel  wrote:
> 
> Lada,
> 
> The requirement says:
>   D.  When a configuration change for any intended configuration
>   node has been successfully applied to the server (e.g. not
>   failed, nor deferred due to absent hardware) then the
>   existence and value of the corresponding applied
>   configuration node must match the intended configuration
>   node.
> 
> I don't see that this would limit the case you described below. In your case 
> there is no intended config, hence there is no "corresponding applied 
> configuration" either.

You are right, the requirement can be interpreted this way. I thought that 
applied configuration was supposed to be identical to intended after some 
synchronization period.

> 
> Besides that, the case you mentioned should be clearly in scope.

Great, then I am open to discussing what this could mean for the existing 
modules (ietf-interfaces, ietf-routing, ACL etc.).

One useful change to YANG semantics could be that a leafref with 
require-instance=true would refer to applied configuration. Specifically, the 
ACL module could then simply use "if:interface-ref" (with 
require-instance=true) as the type for "input-interface". 

Thanks, Lada

>  
> 
> --Gert
> 
>> -Original Message-
>> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Ladislav Lhotka
>> Sent: 07 January 2016 11:20
>> To: NETMOD WG
>> Subject: [netmod] applied configuration and system-controlled entries
>> 
>> Hi,
>> 
>> a good use of applied configuration could be to formalize the concept of
>> system-controlled entries as defined in RFC 7223, routing-cfg, and probably
>> elsewhere, too.
>> 
>> My idea is that system-controlled interfaces or other entries would appear in
>> applied configuration, but not in intended configuration until something 
>> needs
>> to be really configured. We could then permit leafrefs from intended
>> configuration to refer to leafs in applied configuration. One case where this
>> would be useful is the ACL module, where match conditions refering to
>> interfaces currently have to use plain strings as references to interface 
>> names.
>> 
>> However, the above idea seems to be at odds with requirement 1D in opstate-
>> reqs-02. I wonder: could that requirement be relaxed or removed so that the
>> above use case can be supported?
>> 
>> Thanks, Lada
>> 
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>> 
>> 
>> 
>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod

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




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

Re: [netmod] applied configuration and system-controlled entries

[Robert Wilton]

On 11/01/2016 14:51, Ladislav Lhotka wrote:

On 11 Jan 2016, at 15:15, Robert Wilton  wrote:

Hi Gert, Lada,

On 11/01/2016 13:48, Ladislav Lhotka wrote:

Hi Gert,


On 11 Jan 2016, at 14:25, Gert Grammel  wrote:

Lada,

The requirement says:
   D.  When a configuration change for any intended configuration
   node has been successfully applied to the server (e.g. not
   failed, nor deferred due to absent hardware) then the
   existence and value of the corresponding applied
   configuration node must match the intended configuration
   node.

I don't see that this would limit the case you described below. In your case there is no 
intended config, hence there is no "corresponding applied configuration" either.

You are right, the requirement can be interpreted this way. I thought that 
applied configuration was supposed to be identical to intended after some 
synchronization period.

Yes, when the system settles, and assuming that all configuration has been 
successfully applied, then the applied config nodes MUST exactly match the 
intended config nodes.

This point has been explicitly asked of Rob Shakir and Anees and they have 
confirmed that these are the semantics that are expected.

OK, back to square 1. :-) Then I think the requirements should make this point 
very clear.
They try to, but it is quite tricky to express given there are scenarios 
where the two can differ (e.g. failures (depending on config edit 
semantics), missing hardware, etc).  The intention of the word existence 
in the paragraph above is meant to indicate that a node must either 
exist in both intended and applied, or not exist in either.


Going back to your original problem, my understanding is that the only 
solution in YANG today is to have a config false hierarchy to represent 
system-controlled objects whose lifetime is independent from 
configuration, hence the existence of "interfaces-state" separate from 
"interfaces".  With this approach you lose the ability to retrieve all 
configuration and state together in a single sub-tree within a request 
but gain the flexibility of independent data lifetime.


Thanks,
Rob




Lada


Thanks,
Rob



Besides that, the case you mentioned should be clearly in scope.

Great, then I am open to discussing what this could mean for the existing 
modules (ietf-interfaces, ietf-routing, ACL etc.).

One useful change to YANG semantics could be that a leafref with require-instance=true would refer 
to applied configuration. Specifically, the ACL module could then simply use 
"if:interface-ref" (with require-instance=true) as the type for 
"input-interface".

Thanks, Lada

  
--Gert



-Original Message-
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Ladislav Lhotka
Sent: 07 January 2016 11:20
To: NETMOD WG
Subject: [netmod] applied configuration and system-controlled entries

Hi,

a good use of applied configuration could be to formalize the concept of
system-controlled entries as defined in RFC 7223, routing-cfg, and probably
elsewhere, too.

My idea is that system-controlled interfaces or other entries would appear in
applied configuration, but not in intended configuration until something needs
to be really configured. We could then permit leafrefs from intended
configuration to refer to leafs in applied configuration. One case where this
would be useful is the ACL module, where match conditions refering to
interfaces currently have to use plain strings as references to interface names.

However, the above idea seems to be at odds with requirement 1D in opstate-
reqs-02. I wonder: could that requirement be relaxed or removed so that the
above use case can be supported?

Thanks, Lada

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




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

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




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

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




.



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

Re: [netmod] [Rtg-dt-yang-arch] [yang-doctors] Working group Last Call: draft-ietf-netmod-acl-model-06

[Dean Bogdanovic]

> On Dec 21, 2015, at 4:33 PM, Juergen Schoenwaelder 
>  wrote:
> 
> On Sat, Dec 19, 2015 at 07:50:58AM -0500, Dean Bogdanovic wrote:
>> Juergen,
>> 
>> Please see answers inline
>> 
>> Dean
>> 
>>> On Dec 11, 2015, at 12:31 PM, Juergen Schoenwaelder 
>>>  wrote:
>>> 
>>> On Wed, Dec 09, 2015 at 08:27:04AM -0800, Nadeau Thomas wrote:
 
This email initiates a NETMOD WG Last call for 
 draft-ietf-netmod-acl-model-06. 
 Please review the draft and make any comments to the list by Wednesday, 16 
 December, 2015
 by 8AM EST.
 
>>> 
>>> Technical
>>> 
>>> - I am not sure I personally like the acl-oper-data and ace-oper-data
>>> containers in the middle of the config true tree. I understand that
>>> operational state in this case is likely tightly bound to the
>>> lifetime of the config state but I also generally prefer to have a
>>> clean separation of config from state. But since I am not
>>> implementing this, I am happy to leave the decision to those who
>>> write the code.
>>> 
>>> - I would probably have used src-ipv4-prefix and dst-ipv4-prefix
>>> instead of source-ipv4-network and destination-ipv4-network and
>>> I would probably have used src-mac-address and src-mac-address-mask
>>> and dst-mac-address and dst-mac-address-mask. Generally simple
>>> src instead source and dst instead destination - lines up all
>>> much more nicely.
>> 
>> I know that src and dst are pretty standard abbreviations, but have 
>> preference to use full words.
>> 
> 
> My eyes prefer the shorter versions but it might be subjective where
> the line between arconyms and words is drawn. For me, things are not
> done consistently according to my personal preferences. ;-)

As many people, so many different preferences :)

> 
>>> - I would have put the acl-name and acl-type first followed by the
>>> entries list.
>> 
>> Can you please expand on this? Is there any major difference? OR just design 
>> choice?
> 
> Technically you can define key leafs anywhere but I think there are some
> benefits of defining them at the beginning of a list:
> 
> a) I find it nice if the leafs listed in the key statement follow the
>   key statement and not N pages down the document.
> b) If you put them at the end and you have to add additional definitions,
>   you will end up with leafs somewhere in the middle.
> c) The XML encoding requires to ship key leafs first and it might be
>   simpler if the key leafs are also defined first in the data model
>   (so if you use the same order, you actually get things correct).
> 
> Now you tell me what the advantages are to put them at the end…

I think this ended up being an edit oversight. In the draft 02, the stated 
leafs were at the top

module: ietf-acl
+--rw access-lists
+--rw access-list* [access-control-list-name]
+--rw access-control-list-name string
+--rw access-control-list-type?access-control-list-type
+--ro access-control-list-oper-data
|  +--ro (targets)?
| +--:(interface-name)
|+--ro interface-name*   string
+--rw access-list-entries
+--rw access-list-entry* [rule-name]

I don’t remember if there was any specific reason to push the acl-name and 
acl-type to the end. Will bring it back up.
> 
>>> - I also wonder why we use both the term 'entry' and 'rule', why not
>>> pick one of them? You have for example rule-name (which is the key
>>> of the list but again comes last).
>> This is a bit of compromise between Cisco and Juniper terminology. In Cisco 
>> it is ACE and in Juniper term. But in the yang model and in the text we are 
>> using consistently one or the other word.
> 
> For the sake of clarity, I personally would prefer to have a single
> term. I think Linux packet filters call things rules. I think BSD
> packet filtering calls things rules. Wikipedia seem say that packet
> filters consist of filtering rules... So I guess I have a preference
> but I will not get a sleepless night over this.

Authors are Cisco/Juniper people, so were using that terminology and I believe 
that CSCO and JNPR are more used in networking then Linux :)

> 
>>> - Should there be features for ace-eth and ace-ipv4 and ace-ipv6 or do
>>> we expect that all implementations will always support all three?
>>> Another option would be to have the generic model completely without
>>> any protocol specific elements and to have separate models to
>>> augment in ipv4, ipv6, and ethernet specific ace types. I actually
>>> think this would make much more sense since you would not have a
>>> module 'packet fields' but instead a clear extension of the
>>> ietf-access-control-list module. You could also drop the examples
>>> how to extend the core model since the ip and ethernet extensions
>>> would already serve the purpose. You also would not need features
>>> since an implementation advertises the extension modules.
>> 
>> We started early with such design, but then the WG feedback moved 

Re: [netmod] applied configuration and system-controlled entries

[Robert Wilton]

On 11/01/2016 16:13, Juergen Schoenwaelder wrote:

On Mon, Jan 11, 2016 at 03:30:18PM +, Robert Wilton wrote:

Going back to your original problem, my understanding is that the only
solution in YANG today is to have a config false hierarchy to represent
system-controlled objects whose lifetime is independent from
configuration, hence the existence of "interfaces-state" separate from
"interfaces".  With this approach you lose the ability to retrieve all
configuration and state together in a single sub-tree within a request
but gain the flexibility of independent data lifetime.


I think  filters even today allow you to retrieve both subtrees
(intended and operational state) together if that is desired.

Yes, I think that this partly helps.

I think that it may be desirable (perhaps via a protocol extension) to 
have the two sub-trees merged into a single tree so that the config and 
state data is co-located.  However, to achieve this programmatically 
would probably require some more rules on consistent node naming between 
related config and state sub-trees.


Arguably it is similar to having separate datastores for intended and 
applied configuration, but wanting to retrieve with the data co-located 
in the same tree structure.  Which IIRC, you have previously suggested 
could be solved via an appropriate protocol extension as well.


Thanks,
Rob



/js



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

Re: [netmod] applied configuration and system-controlled entries

[Gert Grammel]

>-Original Message-
>From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Ladislav Lhotka
>Sent: 11 January 2016 16:36
>To: Robert Wilton
>Cc: netmod@ietf.org
>Subject: Re: [netmod] applied configuration and system-controlled entries
>
>
>> On 11 Jan 2016, at 15:58, Robert Wilton  wrote:
>>
>>
>>
>> On 11/01/2016 14:27, Ladislav Lhotka wrote:
 On 11 Jan 2016, at 15:11, Juergen Schoenwaelder
> wrote:

 On Mon, Jan 11, 2016 at 02:54:36PM +0100, Martin Bjorklund wrote:
> Ladislav Lhotka  wrote:
>> Hi Gert,
>>
>>> On 11 Jan 2016, at 14:25, Gert Grammel 
>wrote:
>>>
>>> Lada,
>>>
>>> The requirement says:
>>>  D.  When a configuration change for any intended configuration
>>>  node has been successfully applied to the server (e.g. not
>>>  failed, nor deferred due to absent hardware) then the
>>>  existence and value of the corresponding applied
>>>  configuration node must match the intended configuration
>>>  node.
>>>
>>> I don't see that this would limit the case you described below.
>>> In your case there is no intended config, hence there is no
>>> "corresponding applied configuration" either.
>> You are right, the requirement can be interpreted this way. I
>> thought that applied configuration was supposed to be identical to
>> intended after some synchronization period.
> This is a very important point to clarify.  Can there ever be data
> in "applied" that is not in "intended"?  I think Anees & Rob
> previously said "no", but I might be wrong.
>
 If there is time delay between editing intended and the applied
 config matching the edits of intended, then I supose this can happen
 (I delete a resource from intended but it is still around until
 intended has been fully synced). I would find it interesting if some
 edits are
>>> Using applied config for system-controlled entries would require that such
>an entry stays (forever) in applied config even after it has been deleted from
>intended.
>> I think that this would make life harder for clients.
>
>Hmm, I would say the opposite. For one, we could simplify the data models by
>reducing the duplicities in configuration and state trees.
>

Let's look at a practical example and see if we can converge:
1) A Server is happily running with intended == applied config and operational 
state is aligned with intended config.
2) A new HW is plugged into that server and that HW has some kind of 
identification number

This can practically fall into 3 cases:
a) it's a plug device and it is accepted to be used
b) it's an accepted device but shall be configured prior to become operational
c) it's considered a harmful (unplanned) event and the device shall be removed

In terms of a possible implementation, the event 
1) would update the applied config which -  among others - include the 
identification number and update the operational state of that HW in line with 
the applied config
2) Since the new applied config differs from the intended config, the client is 
notified about the change
3) Upon inspection of the config change, the client decides how to deal with 
the new item:
a) accepting it the way it is: pushing down an intended config in line 
with the applied config information
b) accepting it with modifications: pushing down a new intended config 
with additional leafs
c) rejecting it: raising an alarm indicating the configuration 
mismatch, requiring manual intervention

>>
>> With the requirements as they are today, the client gives the intended config
>to the system, which it can monitor until the applied config matches the
>intended config.  At this point it knows everything is good and the config is
>fully applied.  Over time, if everything is behaving as expected, the client 
>can
>reasonably expect that the applied configuration will always converge on the
>intended configuration.

Which is the case above. By updating the intended config the client accepts the 
config change.
>
>One could argue that leafs with default values are in applied configuration
>before they appear in intended. So my idea was to extend this to default
>entries of certain lists.
>
>>
>> Using applied config for system-controlled entries would break the simple
>logical relationship between intended and applied configuration, since there
>are now some special entries for which this rule does not always apply.
>
Don't get to the same conclusion, see above.

>The introduction of applied configuration would mean significant
>complications to all protocols, and perhaps even to YANG (although I'd hope
>not). Solving only the synchonicity issue with it is IMO insufficient payoff 
>for all
>the troubles.
>
Don't see this either.



>Lada
>
>>
>>>
 always assumed to be synchronous 

Re: [netmod] applied configuration and system-controlled entries

[Robert Wilton]

Hi Gert,

Please see inline ...

On 11/01/2016 16:19, Gert Grammel wrote:



-Original Message-
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Ladislav Lhotka
Sent: 11 January 2016 16:36
To: Robert Wilton
Cc: netmod@ietf.org
Subject: Re: [netmod] applied configuration and system-controlled entries



On 11 Jan 2016, at 15:58, Robert Wilton  wrote:



On 11/01/2016 14:27, Ladislav Lhotka wrote:

On 11 Jan 2016, at 15:11, Juergen Schoenwaelder

 wrote:

On Mon, Jan 11, 2016 at 02:54:36PM +0100, Martin Bjorklund wrote:

Ladislav Lhotka  wrote:

Hi Gert,


On 11 Jan 2016, at 14:25, Gert Grammel 

wrote:

Lada,

The requirement says:
  D.  When a configuration change for any intended configuration
  node has been successfully applied to the server (e.g. not
  failed, nor deferred due to absent hardware) then the
  existence and value of the corresponding applied
  configuration node must match the intended configuration
  node.

I don't see that this would limit the case you described below.
In your case there is no intended config, hence there is no
"corresponding applied configuration" either.

You are right, the requirement can be interpreted this way. I
thought that applied configuration was supposed to be identical to
intended after some synchronization period.

This is a very important point to clarify.  Can there ever be data
in "applied" that is not in "intended"?  I think Anees & Rob
previously said "no", but I might be wrong.


If there is time delay between editing intended and the applied
config matching the edits of intended, then I supose this can happen
(I delete a resource from intended but it is still around until
intended has been fully synced). I would find it interesting if some
edits are

Using applied config for system-controlled entries would require that such

an entry stays (forever) in applied config even after it has been deleted from
intended.

I think that this would make life harder for clients.

Hmm, I would say the opposite. For one, we could simplify the data models by
reducing the duplicities in configuration and state trees.


Let's look at a practical example and see if we can converge:
1) A Server is happily running with intended == applied config and operational 
state is aligned with intended config.
2) A new HW is plugged into that server and that HW has some kind of 
identification number
I think that you can solve this more cleanly with interfaces-state or 
equivalent.  I don't think that a device should be creating 
configuration, the configuration should solely be controlled by the 
operator, and hence the ownership and flow of information is well defined.





This can practically fall into 3 cases:
a) it's a plug device and it is accepted to be used
In this case, it could generate a YANG notification from something like 
the Entity YANG model (or equivalent), and instantiate the new resources 
in interfaces-state as appropriate (or equivalent).  The operator can 
then discover this and apply whatever configuration is appropriate (or 
perhaps they have put the configuration in previously waiting for the 
hardware to be inserted).



b) it's an accepted device but shall be configured prior to become operational

Same as above.


c) it's considered a harmful (unplanned) event and the device shall be removed
It generates a syslog error message, and perhaps Entity YANG model 
notification.  The system doesn't accept any configuration related to 
the unsupported HW.





In terms of a possible implementation, the event
1) would update the applied config which -  among others - include the 
identification number and update the operational state of that HW in line with 
the applied config
2) Since the new applied config differs from the intended config, the client is 
notified about the change
3) Upon inspection of the config change, the client decides how to deal with 
the new item:
a) accepting it the way it is: pushing down an intended config in line 
with the applied config information
b) accepting it with modifications: pushing down a new intended config 
with additional leafs
c) rejecting it: raising an alarm indicating the configuration 
mismatch, requiring manual intervention


I don't think that you need to use applied config to solve this. You can 
support this using operational state and notifications, this then allows 
the configuration to be controlled by a single entity (i.e. the operator).





With the requirements as they are today, the client gives the intended config

to the system, which it can monitor until the applied config matches the
intended config.  At this point it knows everything is good and the config is
fully applied.  Over time, if everything is behaving as expected, the client can
reasonably expect that the applied configuration will always converge on the

Re: [netmod] applied configuration and system-controlled entries

[Juergen Schoenwaelder]

On Mon, Jan 11, 2016 at 03:30:18PM +, Robert Wilton wrote:
> 
> Going back to your original problem, my understanding is that the only 
> solution in YANG today is to have a config false hierarchy to represent 
> system-controlled objects whose lifetime is independent from 
> configuration, hence the existence of "interfaces-state" separate from 
> "interfaces".  With this approach you lose the ability to retrieve all 
> configuration and state together in a single sub-tree within a request 
> but gain the flexibility of independent data lifetime.
>

I think  filters even today allow you to retrieve both subtrees
(intended and operational state) together if that is desired.

/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] applied configuration and system-controlled entries

[Robert Wilton]

On 11/01/2016 14:27, Ladislav Lhotka wrote:

On 11 Jan 2016, at 15:11, Juergen Schoenwaelder 
 wrote:

On Mon, Jan 11, 2016 at 02:54:36PM +0100, Martin Bjorklund wrote:

Ladislav Lhotka  wrote:

Hi Gert,


On 11 Jan 2016, at 14:25, Gert Grammel  wrote:

Lada,

The requirement says:
  D.  When a configuration change for any intended configuration
  node has been successfully applied to the server (e.g. not
  failed, nor deferred due to absent hardware) then the
  existence and value of the corresponding applied
  configuration node must match the intended configuration
  node.

I don't see that this would limit the case you described below. In
your case there is no intended config, hence there is no
"corresponding applied configuration" either.

You are right, the requirement can be interpreted this way. I thought
that applied configuration was supposed to be identical to intended
after some synchronization period.

This is a very important point to clarify.  Can there ever be data in
"applied" that is not in "intended"?  I think Anees & Rob previously
said "no", but I might be wrong.


If there is time delay between editing intended and the applied config
matching the edits of intended, then I supose this can happen (I
delete a resource from intended but it is still around until intended
has been fully synced). I would find it interesting if some edits are

Using applied config for system-controlled entries would require that such an 
entry stays (forever) in applied config even after it has been deleted from 
intended.

I think that this would make life harder for clients.

With the requirements as they are today, the client gives the intended 
config to the system, which it can monitor until the applied config 
matches the intended config.  At this point it knows everything is good 
and the config is fully applied.  Over time, if everything is behaving 
as expected, the client can reasonably expect that the applied 
configuration will always converge on the intended configuration.


Using applied config for system-controlled entries would break the 
simple logical relationship between intended and applied configuration, 
since there are now some special entries for which this rule does not 
always apply.





always assumed to be synchronous but others may be asynchronous.

And Lada, I think applied may happen to be never identical to intended
if, for example, hardware is absent or other missing resources prevent
certain parts of intended to become applied.

Yes, this is the use case of pre-provisioning, which is important, too, but in 
fact opposite: the question here is whether applied can contain stuff that's 
not (and never been) in intended.


I think that the answer is basically no, unless it is an error condition 
and it is representing configuration that should be deleted.


Thanks,
Rob




Lada


My understanding is that applied config in general forms an extended
subset of intended config. And to fully understand what a device is
doing, I may need to obtain its entire operational state since the
applied config may not include state obtained dynamically from other
sources.

But I might still all be wrong...

/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
.



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

Re: [netmod] applied configuration and system-controlled entries

[Juergen Schoenwaelder]

On Mon, Jan 11, 2016 at 02:20:05PM +, Acee Lindem (acee) wrote:
> 
> 
> On 1/11/16, 3:13 PM, "Juergen Schoenwaelder"
>  wrote:
> 
> >On Mon, Jan 11, 2016 at 02:07:13PM +, Acee Lindem (acee) wrote:
> >> 
> >> My opinion is that there is a 1-1 relationship between “applied” and
> >> “intended” config.
> >>
> >
> >I do not understand. Please clarify what 1-1 means here.
> 
> In the context of these requirements, I do not agree that applied config
> includes anything else. The data models for the intended and applied
> config are the aligned and all other state falls in the category of
> derived state.  
>

Apparently, you talk about the data model while I think Martin's
question and the subsequent discussion was about instances.

/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] applied configuration and system-controlled entries

[Ladislav Lhotka]

> On 11 Jan 2016, at 15:15, Robert Wilton  wrote:
> 
> Hi Gert, Lada,
> 
> On 11/01/2016 13:48, Ladislav Lhotka wrote:
>> Hi Gert,
>> 
>>> On 11 Jan 2016, at 14:25, Gert Grammel  wrote:
>>> 
>>> Lada,
>>> 
>>> The requirement says:
>>>   D.  When a configuration change for any intended configuration
>>>   node has been successfully applied to the server (e.g. not
>>>   failed, nor deferred due to absent hardware) then the
>>>   existence and value of the corresponding applied
>>>   configuration node must match the intended configuration
>>>   node.
>>> 
>>> I don't see that this would limit the case you described below. In your 
>>> case there is no intended config, hence there is no "corresponding applied 
>>> configuration" either.
>> You are right, the requirement can be interpreted this way. I thought that 
>> applied configuration was supposed to be identical to intended after some 
>> synchronization period.
> Yes, when the system settles, and assuming that all configuration has been 
> successfully applied, then the applied config nodes MUST exactly match the 
> intended config nodes.
> 
> This point has been explicitly asked of Rob Shakir and Anees and they have 
> confirmed that these are the semantics that are expected.

OK, back to square 1. :-) Then I think the requirements should make this point 
very clear.

Lada

> 
> Thanks,
> Rob
> 
> 
>> 
>>> Besides that, the case you mentioned should be clearly in scope.
>> Great, then I am open to discussing what this could mean for the existing 
>> modules (ietf-interfaces, ietf-routing, ACL etc.).
>> 
>> One useful change to YANG semantics could be that a leafref with 
>> require-instance=true would refer to applied configuration. Specifically, 
>> the ACL module could then simply use "if:interface-ref" (with 
>> require-instance=true) as the type for "input-interface".
>> 
>> Thanks, Lada
>> 
>>>  
>>> --Gert
>>> 
 -Original Message-
 From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Ladislav Lhotka
 Sent: 07 January 2016 11:20
 To: NETMOD WG
 Subject: [netmod] applied configuration and system-controlled entries
 
 Hi,
 
 a good use of applied configuration could be to formalize the concept of
 system-controlled entries as defined in RFC 7223, routing-cfg, and probably
 elsewhere, too.
 
 My idea is that system-controlled interfaces or other entries would appear 
 in
 applied configuration, but not in intended configuration until something 
 needs
 to be really configured. We could then permit leafrefs from intended
 configuration to refer to leafs in applied configuration. One case where 
 this
 would be useful is the ACL module, where match conditions refering to
 interfaces currently have to use plain strings as references to interface 
 names.
 
 However, the above idea seems to be at odds with requirement 1D in opstate-
 reqs-02. I wonder: could that requirement be relaxed or removed so that the
 above use case can be supported?
 
 Thanks, Lada
 
 --
 Ladislav Lhotka, CZ.NIC Labs
 PGP Key ID: E74E8C0C
 
 
 
 
 ___
 netmod mailing list
 netmod@ietf.org
 https://www.ietf.org/mailman/listinfo/netmod
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>> 
>> 
>> 
>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>> .

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




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

Re: [netmod] applied configuration and system-controlled entries

[Ladislav Lhotka]

> On 11 Jan 2016, at 15:58, Robert Wilton  wrote:
> 
> 
> 
> On 11/01/2016 14:27, Ladislav Lhotka wrote:
>>> On 11 Jan 2016, at 15:11, Juergen Schoenwaelder 
>>>  wrote:
>>> 
>>> On Mon, Jan 11, 2016 at 02:54:36PM +0100, Martin Bjorklund wrote:
 Ladislav Lhotka  wrote:
> Hi Gert,
> 
>> On 11 Jan 2016, at 14:25, Gert Grammel  wrote:
>> 
>> Lada,
>> 
>> The requirement says:
>>  D.  When a configuration change for any intended configuration
>>  node has been successfully applied to the server (e.g. not
>>  failed, nor deferred due to absent hardware) then the
>>  existence and value of the corresponding applied
>>  configuration node must match the intended configuration
>>  node.
>> 
>> I don't see that this would limit the case you described below. In
>> your case there is no intended config, hence there is no
>> "corresponding applied configuration" either.
> You are right, the requirement can be interpreted this way. I thought
> that applied configuration was supposed to be identical to intended
> after some synchronization period.
 This is a very important point to clarify.  Can there ever be data in
 "applied" that is not in "intended"?  I think Anees & Rob previously
 said "no", but I might be wrong.
 
>>> If there is time delay between editing intended and the applied config
>>> matching the edits of intended, then I supose this can happen (I
>>> delete a resource from intended but it is still around until intended
>>> has been fully synced). I would find it interesting if some edits are
>> Using applied config for system-controlled entries would require that such 
>> an entry stays (forever) in applied config even after it has been deleted 
>> from intended.
> I think that this would make life harder for clients.

Hmm, I would say the opposite. For one, we could simplify the data models by 
reducing the duplicities in configuration and state trees.

> 
> With the requirements as they are today, the client gives the intended config 
> to the system, which it can monitor until the applied config matches the 
> intended config.  At this point it knows everything is good and the config is 
> fully applied.  Over time, if everything is behaving as expected, the client 
> can reasonably expect that the applied configuration will always converge on 
> the intended configuration.

One could argue that leafs with default values are in applied configuration 
before they appear in intended. So my idea was to extend this to default 
entries of certain lists.

> 
> Using applied config for system-controlled entries would break the simple 
> logical relationship between intended and applied configuration, since there 
> are now some special entries for which this rule does not always apply.

The introduction of applied configuration would mean significant complications 
to all protocols, and perhaps even to YANG (although I'd hope not). Solving 
only the synchonicity issue with it is IMO insufficient payoff for all the 
troubles. 

Lada

> 
>> 
>>> always assumed to be synchronous but others may be asynchronous.
>>> 
>>> And Lada, I think applied may happen to be never identical to intended
>>> if, for example, hardware is absent or other missing resources prevent
>>> certain parts of intended to become applied.
>> Yes, this is the use case of pre-provisioning, which is important, too, but 
>> in fact opposite: the question here is whether applied can contain stuff 
>> that's not (and never been) in intended.
> 
> I think that the answer is basically no, unless it is an error condition and 
> it is representing configuration that should be deleted.
> 
> Thanks,
> Rob
> 
> 
>> 
>> Lada
>> 
>>> My understanding is that applied config in general forms an extended
>>> subset of intended config. And to fully understand what a device is
>>> doing, I may need to obtain its entire operational state since the
>>> applied config may not include state obtained dynamically from other
>>> sources.
>>> 
>>> But I might still all be wrong...
>>> 
>>> /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
>> .

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




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

Re: [netmod] applied configuration and system-controlled entries

[Gert Grammel]

Rob,

I realize that the pre-conditions of the example made weren't clear. There is 
certainly the possibility to pre-configure a node in the intended config and 
wait until some HW is inserted. Indeed in a Telco environment this is the 
preferred case and will stay so for a while.

Lada mentioned a case which didn't have an intended config to begin with and 
asked how it fits in the model. I was using the HW insertion case to show how 
it can be dealt with: either by physical intervention (removing the HW) or by 
updating the intended config to accept the server state. Admittedly this is not 
the norm, but rather an exception. In any event, the difference between 
intended and applied is temporary.

--Gert

>-Original Message-
>From: Robert Wilton [mailto:rwil...@cisco.com]
>Sent: 11 January 2016 17:58
>To: Gert Grammel; Ladislav Lhotka
>Cc: netmod@ietf.org
>Subject: Re: [netmod] applied configuration and system-controlled entries
>
>Hi Gert,
>
>Please see inline ...
>
>On 11/01/2016 16:19, Gert Grammel wrote:
>>
>>> -Original Message-
>>> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Ladislav
>>> Lhotka
>>> Sent: 11 January 2016 16:36
>>> To: Robert Wilton
>>> Cc: netmod@ietf.org
>>> Subject: Re: [netmod] applied configuration and system-controlled
>>> entries
>>>
>>>
 On 11 Jan 2016, at 15:58, Robert Wilton  wrote:



 On 11/01/2016 14:27, Ladislav Lhotka wrote:
>> On 11 Jan 2016, at 15:11, Juergen Schoenwaelder
>>>  wrote:
>> On Mon, Jan 11, 2016 at 02:54:36PM +0100, Martin Bjorklund wrote:
>>> Ladislav Lhotka  wrote:
 Hi Gert,

> On 11 Jan 2016, at 14:25, Gert Grammel 
>>> wrote:
> Lada,
>
> The requirement says:
>   D.  When a configuration change for any intended configuration
>   node has been successfully applied to the server (e.g. not
>   failed, nor deferred due to absent hardware) then the
>   existence and value of the corresponding applied
>   configuration node must match the intended configuration
>   node.
>
> I don't see that this would limit the case you described below.
> In your case there is no intended config, hence there is no
> "corresponding applied configuration" either.
 You are right, the requirement can be interpreted this way. I
 thought that applied configuration was supposed to be identical
 to intended after some synchronization period.
>>> This is a very important point to clarify.  Can there ever be
>>> data in "applied" that is not in "intended"?  I think Anees & Rob
>>> previously said "no", but I might be wrong.
>>>
>> If there is time delay between editing intended and the applied
>> config matching the edits of intended, then I supose this can
>> happen (I delete a resource from intended but it is still around
>> until intended has been fully synced). I would find it interesting
>> if some edits are
> Using applied config for system-controlled entries would require
> that such
>>> an entry stays (forever) in applied config even after it has been
>>> deleted from intended.
 I think that this would make life harder for clients.
>>> Hmm, I would say the opposite. For one, we could simplify the data
>>> models by reducing the duplicities in configuration and state trees.
>>>
>> Let's look at a practical example and see if we can converge:
>> 1) A Server is happily running with intended == applied config and
>operational state is aligned with intended config.
>> 2) A new HW is plugged into that server and that HW has some kind of
>> identification number
>I think that you can solve this more cleanly with interfaces-state or 
>equivalent.
>I don't think that a device should be creating configuration, the configuration
>should solely be controlled by the operator, and hence the ownership and flow
>of information is well defined.
>
I would rephrase your words a bit:
I don't think that a device should be creating *intended* configuration, the 
*intended* configuration
should solely be controlled by the operator, and hence the ownership and flow 
of information is well defined.
Instead the applied configuration should represent the server as-is and an 
inserted HW can't be changed by SW. 
However HW can be put in an operational state that inhibits it from being used.

>
>>
>> This can practically fall into 3 cases:
>> a) it's a plug device and it is accepted to be used
>In this case, it could generate a YANG notification from something like the
>Entity YANG model (or equivalent), and instantiate the new resources in
>interfaces-state as appropriate (or equivalent).  The operator can then 
>discover
>this and apply whatever configuration is appropriate (or perhaps they have put
>the