Re: [netmod] opstate-reqs #7: Why limit scope to just IETF-defined modules

2015-09-22 Thread Robert Wilton 

Hi Kent,

Yes, fine with me.

BTW, please can I check that I correctly understand B and C.

Am I right in understanding that B means that multiple top level trees 
would be acceptable, and C means that having the structure defined in 
multiple modules would be acceptable?


Thanks,
Rob


On 21/09/2015 20:09, Kent Watsen wrote:

Thanks Robert, but I think I like Benoit's edit more.  Are you OK with it
as well?

PS: I've moved this issue to the VERIFY state.

Thanks,
Kent




On 9/21/15, 5:34 AM, "Robert Wilton"  wrote:


Hi,

I suggest changing the wording for A and adding D:

7.  Ability for distinct modules to leverage a common model-structure
A.  Scope is limited to providing a general model-structure only
B.  Multiple domain-specific trees are okay
C.  Multiple namespaces are okay
D.  The model-structure may be used or extended by other
organizations.

Justifications for (A):
  - Limiting the scope to IETF-defined modules almost implies that
'ietf' would end up in the path (which would be wrong/unnecessary).
  - Clients don't care which SDO defines the modules for the protocols
they use, they just want a coherent organization of modules.
  - General structure only to limit the scope because trying to
precisely place every protocol/feature is likely to be fragile in the
face of future changes.

Justifications for (D):
  - To suggest and encourage other SDOs to use the same structure, but
cannot mandate what they do.

Thanks,
Rob


On 18/09/2015 22:56, Kent Watsen wrote:

Regarding https://github.com/netmod-wg/opstate-reqs/issues/7


Jonathan> Why does 7(A) limit the scope to IETF-defined modules of
  others are now defining YANG modules?

Benoit> Good point. We need to provide guidance for the other SDOs.


Current text says:

 7.  Ability for distinct modules to leverage a common
model-structure
 A.  Scope is limited to IETF-defined modules
 B.  Multiple domain-specific trees are okay
 C.  Multiple namespaces are okay



Background:

I pulled 7A from Andy's message here:

  
https://mailarchive.ietf.org/arch/msg/netmod/I6clHE2665C40taRZHi0CKLD46U


and put a stake in the ground so that, if nothing else, it could
be discussed...and here we are!

FWIW, I wrote 7A this way because I didn't see how it can be
enforced outside of the IETF.  But maybe that doesn't matter?
Of course, we can have 6087bis guidance for other SDOs, but
I didn't put that in the text.


Thoughts on how the text should be updated?


PS: Please Reply-All to the list rather than post comments to the GitHub
issue tracker.


Thanks,
Kent

___
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] opstate-reqs #7: Why limit scope to just IETF-defined modules

2015-09-22 Thread Robert Wilton 

Hi Andy,

Please can you clarify. Is your concern specifically with requirement 
7?  Or the full set of requirements in 
draft-chairs-netmod-opstate-reqs-00?


Thanks,
Rob


On 21/09/2015 20:28, Andy Bierman wrote:

Hi,

I do not think the issue of scope is being considered very carefully.

IMO the solutions being proposed are extremely router-centric.
(e.g., most NETCONF servers DO NOT have any virtual servers within them).

The larger the scope, the more concern I have that
the IETF will be pushing expensive solutions on platforms
that don't have any of the "problems" in the first place.


Andy



On Mon, Sep 21, 2015 at 12:09 PM, Kent Watsen > wrote:



Thanks Robert, but I think I like Benoit's edit more.  Are you OK
with it
as well?

PS: I've moved this issue to the VERIFY state.

Thanks,
Kent




On 9/21/15, 5:34 AM, "Robert Wilton" mailto:rwil...@cisco.com>> wrote:

>Hi,
>
>I suggest changing the wording for A and adding D:
>
>7.  Ability for distinct modules to leverage a common
model-structure
>A.  Scope is limited to providing a general
model-structure only
>B.  Multiple domain-specific trees are okay
>C.  Multiple namespaces are okay
>D.  The model-structure may be used or extended by other
>organizations.
>
>Justifications for (A):
>  - Limiting the scope to IETF-defined modules almost implies that
>'ietf' would end up in the path (which would be wrong/unnecessary).
>  - Clients don't care which SDO defines the modules for the
protocols
>they use, they just want a coherent organization of modules.
>  - General structure only to limit the scope because trying to
>precisely place every protocol/feature is likely to be fragile in the
>face of future changes.
>
>Justifications for (D):
>  - To suggest and encourage other SDOs to use the same
structure, but
>cannot mandate what they do.
>
>Thanks,
>Rob
>
>
>On 18/09/2015 22:56, Kent Watsen wrote:
>> Regarding https://github.com/netmod-wg/opstate-reqs/issues/7
>>
>>
>>Jonathan> Why does 7(A) limit the scope to IETF-defined
modules of
>>  others are now defining YANG modules?
>>
>>Benoit> Good point. We need to provide guidance for the
other SDOs.
>>
>>
>> Current text says:
>>
>> 7.  Ability for distinct modules to leverage a common
>>model-structure
>> A.  Scope is limited to IETF-defined modules
>> B.  Multiple domain-specific trees are okay
>> C.  Multiple namespaces are okay
>>
>>
>>
>> Background:
>>
>>I pulled 7A from Andy's message here:
>>
>>
>>
https://mailarchive.ietf.org/arch/msg/netmod/I6clHE2665C40taRZHi0CKLD46U
>>
>>and put a stake in the ground so that, if nothing else, it could
>>be discussed...and here we are!
>>
>>FWIW, I wrote 7A this way because I didn't see how it can be
>>enforced outside of the IETF.  But maybe that doesn't matter?
>>Of course, we can have 6087bis guidance for other SDOs, but
>>I didn't put that in the text.
>>
>>
>> Thoughts on how the text should be updated?
>>
>>
>> PS: Please Reply-All to the list rather than post comments to
the GitHub
>> issue tracker.
>>
>>
>> Thanks,
>> Kent
>>
>> ___
>> 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] opstate-reqs #7: Why limit scope to just IETF-defined modules

2015-09-22 Thread Kent Watsen 


>Yes, fine with me.

Excellent!


>BTW, please can I check that I correctly understand B and C.
>
>Am I right in understanding that B means that multiple top level trees
>would be acceptable, and C means that having the structure defined in
>multiple modules would be acceptable?

Yes, this is what is intended, do you think the text needs to be clarified?


Thanks,
Kent

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

Re: [netmod] opstate-reqs #7: Why limit scope to just IETF-defined modules

2015-09-22 Thread Robert Wilton 



On 22/09/2015 13:45, Kent Watsen wrote:



Yes, fine with me.

Excellent!



BTW, please can I check that I correctly understand B and C.

Am I right in understanding that B means that multiple top level trees
would be acceptable, and C means that having the structure defined in
multiple modules would be acceptable?

Yes, this is what is intended, do you think the text needs to be clarified?

Personally, I don't mind.

For B, I presume that it is both multiple top level trees domain 
specific trees that are being considered, and also potentially multiple 
domain specific trees lower down the hierarchy (e.g. under 
if:interfaces).  If so I think that the current text for B is reasonable.


For C, possibly the following text helps clarify?

OLD:

  7.  Ability for distinct modules to leverage a common model-structure
   A.  Focus on the IETF-defined modules, and ideally provides guidance to 
other SDOs
   B.  Multiple domain-specific trees are okay
   C.  Multiple namespaces are okay

NEW:

  7.  Ability for distinct modules to leverage a common model-structure
   A.  Focus on the IETF-defined modules, and ideally provides guidance to 
other SDOs
   B.  Multiple domain-specific trees are okay
   C.  Model-structure may be defined in multiple modules with distinct 
namespaces.

Thanks,
Rob





Thanks,
Kent




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

Re: [netmod] opstate-reqs #7: Why limit scope to just IETF-defined modules

2015-09-22 Thread Andy Bierman 
On Tue, Sep 22, 2015 at 3:00 AM, Robert Wilton  wrote:

> Hi Andy,
>
> Please can you clarify. Is your concern specifically with requirement 7?
> Or the full set of requirements in draft-chairs-netmod-opstate-reqs-00
> ?
>
>

My concern is the impact on implementations that do not contain virtual
servers
or do not even contain routers. If the scope of a solution is only routers,
then
it does not matter how router-centric the solution.  But if the scope is
every
device that uses YANG, then it does matter.

To be quite specific:
   - most devices do not require long time intervals  to apply
configuration so any solution
 to identify intended vs. applied config is a waste of resources

  - most devices do not contain virtual servers so placing the data models
in a framework
for virtualization is a waste of resources

A good engineering solution would only use engineering resources, device
resources,
and/or network resources on platforms that actually have these problems.
It's the  difference between MAY leverage a common model-structure and MUST
leverage
a common model-structure. (Something IETFers should understand).

If the solution really is MAY, then I have no concerns, but I know YANG does
not actually support that, and it probably never will.  Relocatable YANG
would
be rather complicated, so that is not an option at this time.


Thanks,
> Rob
>


Andy


>
>
> On 21/09/2015 20:28, Andy Bierman wrote:
>
> Hi,
>
> I do not think the issue of scope is being considered very carefully.
>
> IMO the solutions being proposed are extremely router-centric.
> (e.g., most NETCONF servers DO NOT have any virtual servers within them).
>
> The larger the scope, the more concern I have that
> the IETF will be pushing expensive solutions on platforms
> that don't have any of the "problems" in the first place.
>
>
> Andy
>
>
>
> On Mon, Sep 21, 2015 at 12:09 PM, Kent Watsen  wrote:
>
>>
>> Thanks Robert, but I think I like Benoit's edit more.  Are you OK with it
>> as well?
>>
>> PS: I've moved this issue to the VERIFY state.
>>
>> Thanks,
>> Kent
>>
>>
>>
>>
>> On 9/21/15, 5:34 AM, "Robert Wilton" < 
>> rwil...@cisco.com> wrote:
>>
>> >Hi,
>> >
>> >I suggest changing the wording for A and adding D:
>> >
>> >7.  Ability for distinct modules to leverage a common model-structure
>> >A.  Scope is limited to providing a general model-structure only
>> >B.  Multiple domain-specific trees are okay
>> >C.  Multiple namespaces are okay
>> >D.  The model-structure may be used or extended by other
>> >organizations.
>> >
>> >Justifications for (A):
>> >  - Limiting the scope to IETF-defined modules almost implies that
>> >'ietf' would end up in the path (which would be wrong/unnecessary).
>> >  - Clients don't care which SDO defines the modules for the protocols
>> >they use, they just want a coherent organization of modules.
>> >  - General structure only to limit the scope because trying to
>> >precisely place every protocol/feature is likely to be fragile in the
>> >face of future changes.
>> >
>> >Justifications for (D):
>> >  - To suggest and encourage other SDOs to use the same structure, but
>> >cannot mandate what they do.
>> >
>> >Thanks,
>> >Rob
>> >
>> >
>> >On 18/09/2015 22:56, Kent Watsen wrote:
>> >> Regarding https://github.com/netmod-wg/opstate-reqs/issues/7
>> >>
>> >>
>> >>Jonathan> Why does 7(A) limit the scope to IETF-defined modules of
>> >>  others are now defining YANG modules?
>> >>
>> >>Benoit> Good point. We need to provide guidance for the other SDOs.
>> >>
>> >>
>> >> Current text says:
>> >>
>> >> 7.  Ability for distinct modules to leverage a common
>> >>model-structure
>> >> A.  Scope is limited to IETF-defined modules
>> >> B.  Multiple domain-specific trees are okay
>> >> C.  Multiple namespaces are okay
>> >>
>> >>
>> >>
>> >> Background:
>> >>
>> >>I pulled 7A from Andy's message here:
>> >>
>> >>
>> >>
>> https://mailarchive.ietf.org/arch/msg/netmod/I6clHE2665C40taRZHi0CKLD46U
>> >>
>> >>and put a stake in the ground so that, if nothing else, it could
>> >>be discussed...and here we are!
>> >>
>> >>FWIW, I wrote 7A this way because I didn't see how it can be
>> >>enforced outside of the IETF.  But maybe that doesn't matter?
>> >>Of course, we can have 6087bis guidance for other SDOs, but
>> >>I didn't put that in the text.
>> >>
>> >>
>> >> Thoughts on how the text should be updated?
>> >>
>> >>
>> >> PS: Please Reply-All to the list rather than post comments to the
>> GitHub
>> >> issue tracker.
>> >>
>> >>
>> >> Thanks,
>> >> Kent
>> >>
>> >> ___
>> >> netmod mailing list
>> >> netmod@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/netmod
>> >>
>> >
>>
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.iet

[netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?

2015-09-22 Thread Kent Watsen 

OK, how about another (hopefully) easy one.

Robert Wilton writes: "It wasn't clear to me where the requirement 3 (A)
came from. I'm not necessarily opposed to it, only that it doesn't appear
to be obviously specified in the openconfig-netmod-opstate draft."


For convenience, Requirement 3 is reproduced below in its entirety:

   3.  Support for both transactional, synchronous management systems as
   well as distributed, asynchronous management systems

   A.  For asynchronous systems, the ability to request a protocol
   operation to not return (i.e. block) until the intended
   configuration has been fully synchronized.

   B.  The protocol operation's response would indicate the result
   of the operation (success, failure, partial, etc.)




Regarding where requirement 3A came from, as the Appendix shows, the
entire requirement #3 is derived from draft-openconfig-netmod-opstate-01,
Section 4.2, which says:

   In a synchronous system, configuration changes are transactional and
   committed as an atomic unit.  This implies that the management system
   knows the success or failure of the configuration change based on the
   return value, and hence knows that the intended configuration matches
   what is on the system (i..e, what has been applied).




Given that we only have asynchronous systems today with NETCONF and
RESTCONF, I assumed that there was a need to make NETCONF/RESTCONF
synchronous with a blocking call.   This may have been a bad assumption on
my part, as Anees has since clarified that the solution may not even use
the NETCONF or RESTCONF protocols. Further, rather than assuming we need
to make an asynchronous system synchronous, it could be instead that we
merely just need to accept that synchronous systems may exist somewhere in
the world outside NETCONF/RESTCONF.  To that end, there may not be an
actionable requirement here and we should just remove Requirement #3
altogether.  Thoughts?


PS: please Reply-All to this thread, rather than post comments on the
GitHub issue tracker.

Thanks,
Kent



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

[netmod] Fwd: I-D Action: draft-rtgyangdt-rtgwg-device-model-01.txt

2015-09-22 Thread Lou Berger 

FYI we've updated the DT draft based on the following:

1) No single /device root 

This has been a topic of major discussion both publicly and within the
DT.  It's our hope that by making this change (okay, compromise),
discussion can now move on to the rest of the proposed structure.

2) The additions to if:interfaces are now shown as augmentations

There seemed to be confusion on the point of what exactly we were
proposing and we hope that this change clarifies the proposal. 

3)  identityref s are now used to identify different types of protocols
within the overall model. 

This approach was based on feedback from Mahesh Jethanandani, as a YANG Dr..

4) We've identified an open discussion/issue on an alternate approach 
to supporting logical network
elements using an enhanced version of draft-clemm-netmod-mount and plan
to explore this with the draft authors.

As always, feedback would be appreciated.

Lou (and co-authors)

 Forwarded Message 
Subject:I-D Action: draft-rtgyangdt-rtgwg-device-model-01.txt
Date:   Mon, 21 Sep 2015 17:40:39 -0700
From:   internet-dra...@ietf.org
Reply-To:   internet-dra...@ietf.org
To: i-d-annou...@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts directories.


Title   : Network Device YANG Organizational Model
Authors : Acee Lindem
  Lou Berger
  Dean Bogdanovic
  Christian Hopps
Filename: draft-rtgyangdt-rtgwg-device-model-01.txt
Pages   : 33
Date: 2015-09-21

Abstract:
   This document presents an approach for organizing YANG models in a
   comprehensive structure that defines how individual models may be
   composed to configure and operate network infrastructure and
   services.  The structure is itself represented as a YANG model,
   with all of the related component models logically
   organized in a way that is operationally intuitive. This document is
   derived from work submitted to the IETF by members of the informal
   OpenConfig working group of network operators and is a product of the
   Routing Area YANG Architecture design team.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-rtgyangdt-rtgwg-device-model/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-rtgyangdt-rtgwg-device-model-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-rtgyangdt-rtgwg-device-model-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt




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

Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?

2015-09-22 Thread Juergen Schoenwaelder 
On Tue, Sep 22, 2015 at 02:04:16PM +, Kent Watsen wrote:
> 
> Given that we only have asynchronous systems today with NETCONF and
> RESTCONF, I assumed that there was a need to make NETCONF/RESTCONF
> synchronous with a blocking call.   This may have been a bad assumption on
> my part, as Anees has since clarified that the solution may not even use
> the NETCONF or RESTCONF protocols. Further, rather than assuming we need
> to make an asynchronous system synchronous, it could be instead that we
> merely just need to accept that synchronous systems may exist somewhere in
> the world outside NETCONF/RESTCONF.  To that end, there may not be an
> actionable requirement here and we should just remove Requirement #3
> altogether.  Thoughts?
>

Big confusion here. NETCONF/RESTCONF is synchronous not asynchronous.
Did you messes up the terms throughout this paragraph? If I swap all
of them, the text starts to make 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

Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?

2015-09-22 Thread Robert Wilton 



On 22/09/2015 15:22, Juergen Schoenwaelder wrote:

On Tue, Sep 22, 2015 at 02:04:16PM +, Kent Watsen wrote:

Given that we only have asynchronous systems today with NETCONF and
RESTCONF, I assumed that there was a need to make NETCONF/RESTCONF
synchronous with a blocking call.   This may have been a bad assumption on
my part, as Anees has since clarified that the solution may not even use
the NETCONF or RESTCONF protocols. Further, rather than assuming we need
to make an asynchronous system synchronous, it could be instead that we
merely just need to accept that synchronous systems may exist somewhere in
the world outside NETCONF/RESTCONF.  To that end, there may not be an
actionable requirement here and we should just remove Requirement #3
altogether.  Thoughts?


Big confusion here. NETCONF/RESTCONF is synchronous not asynchronous.
Did you messes up the terms throughout this paragraph? If I swap all
of them, the text starts to make sense to me.

I can see that they are both:
(i) They are synchronous with respect to the config operation. I.e. they 
don't send a reply until the config operation has completed.
(ii) They are asynchronous with respect to the communication.  I.e. the 
client isn't blocked while the config operation is ongoing, and a client 
may send additional requests whilst waiting for a reply.


I believe that the text in draft-openconfig-netmod-opstate-01, Section 
4.2 is mainly concerned with (i) and not (ii), but I read it as 
describing both sync vs async management systems as well as sync vs 
async YANG servers.  From my reading of the text:


The first paragraph of section 4.2 is just describing existing NETCONF 
like protocols.  Hence, no new requirement here, and so I think that 3.A 
can be deleted.


The second paragraph of section 4.2 states that async servers may reply 
early, and applied cfg state is used to check the system state (which is 
effectively already covered as a separate requirement). However, does a 
client need to be able to know that a server will process a particular 
config request, or all config requests, in an asynchronous fashion?  I 
don't think that the opstate draft states this - presumably on the 
assumption is that they can always use intended vs applied config leaves 
for both sync and async servers and so don't need to differentiate.  Is 
this assumption valid for all client/server interactions?


The third paragraph only provides justification and doesn't introduce 
any new requirements.


Thanks,
Rob




/js



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

Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?

2015-09-22 Thread Robert Wilton 



On 22/09/2015 17:20, Andy Bierman wrote:



On Tue, Sep 22, 2015 at 9:06 AM, Kent Watsen > wrote:





> Big confusion here. NETCONF/RESTCONF is synchronous not
asynchronous.
> Did you messes up the terms throughout this paragraph? If I swap all
> of them, the text starts to make sense to me.

Nope, but I grant you there are terminology issues here. What I
mean, and have said before, is that NETCONF/RESTCONF make no
assertions with regard to the applied configuration when the
RPC-reply or HTTP response is provided.   In my experience, only
the control plane is updated and sometime later the changes are
propagated to dataplane.



NETCONF and RESTCONF are asynchronous, meaning the client and server
run in separate processes and communication between client and server can
occur at any time.

If the server returns  to an edit request, that means it is 
accepted in

the intended config.


I would expect that if a normal NETCONF server returned  from an 
edit request, then that means that it is accepted in both the intended 
and applied config. I.e. it is what you would get back if you made a 
get-config request.


A server behaving in an async fashion would reply immediately the 
intended config was updated, and the applied config would be updated later.


Thanks,
Rob




Kent



Andy

___
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] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?

2015-09-22 Thread Kent Watsen 



> Big confusion here. NETCONF/RESTCONF is synchronous not asynchronous.
> Did you messes up the terms throughout this paragraph? If I swap all
> of them, the text starts to make sense to me.

Nope, but I grant you there are terminology issues here.  What I mean, and have 
said before, is that NETCONF/RESTCONF make no assertions with regard to the 
applied configuration when the RPC-reply or HTTP response is provided.   In my 
experience, only the control plane is updated and sometime later the changes 
are propagated to dataplane. 

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

Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?

2015-09-22 Thread Andy Bierman 
On Tue, Sep 22, 2015 at 9:06 AM, Kent Watsen  wrote:

>
>
>
> > Big confusion here. NETCONF/RESTCONF is synchronous not asynchronous.
> > Did you messes up the terms throughout this paragraph? If I swap all
> > of them, the text starts to make sense to me.
>
> Nope, but I grant you there are terminology issues here.  What I mean, and
> have said before, is that NETCONF/RESTCONF make no assertions with regard
> to the applied configuration when the RPC-reply or HTTP response is
> provided.   In my experience, only the control plane is updated and
> sometime later the changes are propagated to dataplane.
>
>

NETCONF and RESTCONF are asynchronous, meaning the client and server
run in separate processes and communication between client and server can
occur at any time.

If the server returns  to an edit request, that means it is accepted in
the intended config.


Kent
>


Andy


> ___
> 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] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?

2015-09-22 Thread Juergen Schoenwaelder 
On Tue, Sep 22, 2015 at 09:20:18AM -0700, Andy Bierman wrote:
> 
> NETCONF and RESTCONF are asynchronous, meaning the client and server
> run in separate processes and communication between client and server can
> occur at any time.
>

I thought the openconfig discussion was centered around the server
side...

> If the server returns  to an edit request, that means it is accepted in
> the intended config.

I think we need to use precise terminology otherwise we keep talking
past each other. An  to an  means the edit got
'accepted' (not sure what this term means) in the configuration
datastore being edited, such as  or .

Perhaps  === intended configuration datastore. But I think
it is important to not forget that there are multiple configuration
datastores in NETCONF.

My understanding is that the  operation is synchronous
with respect to the change of the configuration datastore. The
propagation of the data from the  configuration datastore to
the internal pieces of hardware and software being configured may be
asynchronous and is usually considered an implementation detail. The
protocol itself allows asynchronous clients to be written that can
talk to multiple servers and in principle the protocol supports
pipelining of requests from a single client to a single server but all
requests are executed serially. I think the same applies to RESTCONF
but I am a bit less confident.

/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] YANG Mount = Alias Mount + Peer Mount (was RE: Motivations for Structuring Models)

2015-09-22 Thread Eric Voit (evoit) 
Hi Lada,

Thanks for your feedback.   I do think that there is value in an integrated 
technology solution.   OpenDaylight combines (1) and (2) usefully.  For example 
there are examples on the page:
http://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf
such as:
http://localhost:8080/restconf/operations/network-topology:network-topology/topology/topology-netconf/node//yang-ext:mount/
 
which enables a server to reference remote device info embedded within a 
network-topology url

Beyond that, OpenDaylight has the ability to do (1) in the form of " loopback 
mount".  See:
http://wiki.opendaylight.org/view/Controller_Core_Functionality_Tutorials:Tutorials:Netconf_Mount#Testing_against_ODL_itself_.28MD-SAL_netconf_northbound_loopback_mount.29
While this is used mostly for testing, aliasing is also viable.

Eric

-Original Message-
From: Ladislav Lhotka, September 21, 2015 4:34 AM

Hi Eric,

we are dealing with two rather different problems:

1. A pull-type method for combining YANG schemas as a complement to
   "augment".

2. A proxy function that mediates access to data that are located
   elsewhere.

I believe the recent thread on structuring YANG models has been about #1 while 
both this draft and draft-clemm-netmod-mount-03 mainly address #2. Each problem 
has its share of issues to solve but the issues don't overlap, so I believe it 
would be useful to keep both problems separate.

Lada

"Eric Voit (evoit)"  writes:

> There was a recent thread on structuring YANG models so that application 
> developers might be able to reference alternative local hierarchies/tree 
> structures for certain objects.  This thread motivated Alex, Sander, and I to 
> rework the YANG Mount requirements draft.  v03 is posted at:
> http://datatracker.ietf.org/doc/draft-voit-netmod-peer-mount-requireme
> nts/
>
> This draft has been retitled to "Requirements for mounting of local and 
> remote YANG subtrees".  This retitling was done because we have separated the 
> thinking on what it takes to Mount objects from remote devices (Peer Mount) 
> from what it takes to Mount within the same device (Alias Mount).
>
> We would be interested in your thoughts.   
>
> Eric
>
> -Original Message-
> From: Ladislav Lhotka, August 31, 2015 11:05 AM
>
> Randy Presuhn  writes:
>
>> Hi -
>>
>> It is with no little amusement that I watch this thread struggling 
>> with questions that were solved fairly neatly a quarter century ago 
>> in GDMO/CMIP-land.  I'm *not* suggesting we go back there, but would 
>> like to offer an observation about modeling that might help.
>>
>> The organization of instance data in SNMP is a direct mirror of the 
>> "object" definitions.  Simple at first, but quickly becoming baroque 
>> as various minds of "multiplexing" are added to compensate for post 
>> hoc deficiencies in the index structures.
>>
>> Life is such that once a resource has been modeled, it will be 
>> used/re-used/embedded in systems in ways in which its designers 
>> couldn't be expected to imagine.  A consequence of this is that if 
>> instance naming is completely locked down when the management 
>> interface for a resource is first defined (as it is in SNMP) then all 
>> sorts of peculiar hacks will be needed to deal with, for example, 
>> virtual routers.  Unfortunately, an SNMP/SMI-like mindset is so 
>> pervasive that folks seem to overlook that there are other ways to 
>> deal with this situation.
>>
>> What GDMO did was to use a separate "NAME BINDING" construct to 
>> specify contexts in which instances might show up, allowing instances 
>> to be put in places that weren't even imagined when the original 
>> class definition was written.  Name bindings could be standardized, 
>> or be vendor or even product-specific, allowing the simplicity or 
>> complexity of a given system's instance tree to reflect the actual 
>> simplicity or complexity of that system, rather than requiring all 
>> systems to be structured for the worst case.
>
> How could this be expressed in YANG terms? (I tried to figure it out myself 
> but I unfortunately couldn't make any sense of sec. 8.6 in CCITT 
> Recommendation X.722).
>
> Thanks, Lada
>
>>
>> Yes, separating the specification of instance naming in large part 
>> from class definition does have implications for how one does access 
>> control, and how clients figure out how to ask a server to create 
>> something, but it's not a huge deal - it's just not like VACM, and a 
>> whole slew of hacky solutions and "wierd plumbing adapters" (to 
>> borrow from Jeff Case) just go away.  Strangely, it makes the job of 
>> the initial modeler and of the eventual user much easier.
>>
>> Randy
>>
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>

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

Re: [netmod] opstate-reqs #3: Is there a requirement for asynchronous systems to provide a blocking config update?

2015-09-22 Thread Andy Bierman 
On Tue, Sep 22, 2015 at 10:00 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Tue, Sep 22, 2015 at 09:20:18AM -0700, Andy Bierman wrote:
> >
> > NETCONF and RESTCONF are asynchronous, meaning the client and server
> > run in separate processes and communication between client and server can
> > occur at any time.
> >
>
> I thought the openconfig discussion was centered around the server
> side...
>
> > If the server returns  to an edit request, that means it is
> accepted in
> > the intended config.
>
> I think we need to use precise terminology otherwise we keep talking
> past each other. An  to an  means the edit got
> 'accepted' (not sure what this term means) in the configuration
> datastore being edited, such as  or .
>
>

OK -- the edit is accepted as part of the  datastore.
That means is passes the YANG validation tests.
I guess our terminology is so poor that we cannot even describe that
means wrt/ the device or the network.





> Perhaps  === intended configuration datastore. But I think
> it is important to not forget that there are multiple configuration
> datastores in NETCONF.
>
> My understanding is that the  operation is synchronous
> with respect to the change of the configuration datastore. The
> propagation of the data from the  configuration datastore to
> the internal pieces of hardware and software being configured may be
> asynchronous and is usually considered an implementation detail. The
> protocol itself allows asynchronous clients to be written that can
> talk to multiple servers and in principle the protocol supports
> pipelining of requests from a single client to a single server but all
> requests are executed serially. I think the same applies to RESTCONF
> but I am a bit less confident.
>
>

I agree with Carl that there is no problem to solve wrt/ "show running"
being delayed.  I think implementations just return the intended values.

/js
>


Andy


>
> --
> 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 Mount = Alias Mount + Peer Mount (was RE: Motivations for Structuring Models)

2015-09-22 Thread Acee Lindem (acee) 
Hi Eric, Lada, 

I agree with Eric that the mount requirements should include both use
cases. We have been discussing this mechanism as potentially providing
support for meta model components that may or not be present in a network
device. 

Thanks,
Acee

On 9/22/15, 1:59 PM, "netmod on behalf of Eric Voit (evoit)"
 wrote:

>Hi Lada,
>
>Thanks for your feedback.   I do think that there is value in an
>integrated technology solution.   OpenDaylight combines (1) and (2)
>usefully.  For example there are examples on the page:
>http://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:
>Netconf
>such as:
>http://localhost:8080/restconf/operations/network-topology:network-topolog
>y/topology/topology-netconf/node//yang-ext:mount/
>which enables a server to reference remote device info embedded within a
>network-topology url
>
>Beyond that, OpenDaylight has the ability to do (1) in the form of "
>loopback mount".  See:
>http://wiki.opendaylight.org/view/Controller_Core_Functionality_Tutorials:
>Tutorials:Netconf_Mount#Testing_against_ODL_itself_.28MD-SAL_netconf_north
>bound_loopback_mount.29
>While this is used mostly for testing, aliasing is also viable.
>
>Eric
>
>-Original Message-
>From: Ladislav Lhotka, September 21, 2015 4:34 AM
>
>Hi Eric,
>
>we are dealing with two rather different problems:
>
>1. A pull-type method for combining YANG schemas as a complement to
>   "augment".
>
>2. A proxy function that mediates access to data that are located
>   elsewhere.
>
>I believe the recent thread on structuring YANG models has been about #1
>while both this draft and draft-clemm-netmod-mount-03 mainly address #2.
>Each problem has its share of issues to solve but the issues don't
>overlap, so I believe it would be useful to keep both problems separate.
>
>Lada
>
>"Eric Voit (evoit)"  writes:
>
>> There was a recent thread on structuring YANG models so that
>>application developers might be able to reference alternative local
>>hierarchies/tree structures for certain objects.  This thread motivated
>>Alex, Sander, and I to rework the YANG Mount requirements draft.  v03 is
>>posted at:
>> http://datatracker.ietf.org/doc/draft-voit-netmod-peer-mount-requireme
>> nts/
>>
>> This draft has been retitled to "Requirements for mounting of local and
>>remote YANG subtrees".  This retitling was done because we have
>>separated the thinking on what it takes to Mount objects from remote
>>devices (Peer Mount) from what it takes to Mount within the same device
>>(Alias Mount).
>>
>> We would be interested in your thoughts.
>>
>> Eric
>>
>> -Original Message-
>> From: Ladislav Lhotka, August 31, 2015 11:05 AM
>>
>> Randy Presuhn  writes:
>>
>>> Hi -
>>>
>>> It is with no little amusement that I watch this thread struggling
>>> with questions that were solved fairly neatly a quarter century ago
>>> in GDMO/CMIP-land.  I'm *not* suggesting we go back there, but would
>>> like to offer an observation about modeling that might help.
>>>
>>> The organization of instance data in SNMP is a direct mirror of the
>>> "object" definitions.  Simple at first, but quickly becoming baroque
>>> as various minds of "multiplexing" are added to compensate for post
>>> hoc deficiencies in the index structures.
>>>
>>> Life is such that once a resource has been modeled, it will be
>>> used/re-used/embedded in systems in ways in which its designers
>>> couldn't be expected to imagine.  A consequence of this is that if
>>> instance naming is completely locked down when the management
>>> interface for a resource is first defined (as it is in SNMP) then all
>>> sorts of peculiar hacks will be needed to deal with, for example,
>>> virtual routers.  Unfortunately, an SNMP/SMI-like mindset is so
>>> pervasive that folks seem to overlook that there are other ways to
>>> deal with this situation.
>>>
>>> What GDMO did was to use a separate "NAME BINDING" construct to
>>> specify contexts in which instances might show up, allowing instances
>>> to be put in places that weren't even imagined when the original
>>> class definition was written.  Name bindings could be standardized,
>>> or be vendor or even product-specific, allowing the simplicity or
>>> complexity of a given system's instance tree to reflect the actual
>>> simplicity or complexity of that system, rather than requiring all
>>> systems to be structured for the worst case.
>>
>> How could this be expressed in YANG terms? (I tried to figure it out
>>myself but I unfortunately couldn't make any sense of sec. 8.6 in CCITT
>>Recommendation X.722).
>>
>> Thanks, Lada
>>
>>>
>>> Yes, separating the specification of instance naming in large part
>>> from class definition does have implications for how one does access
>>> control, and how clients figure out how to ask a server to create
>>> something, but it's not a huge deal - it's just not like VACM, and a
>>> whole slew of hacky solutions and "wierd plumbing adapters" (to
>>> borrow from Jeff Case) just go away.  St

Re: [netmod] opstate-reqs #7: Why limit scope to just IETF-defined modules

2015-09-22 Thread Andy Bierman 
On Tue, Sep 22, 2015 at 11:39 AM, Dean Bogdanovic 
wrote:

> Andy,
>
> Mobile operators are sharing infrastructure more and more. They are even
> now considering sharing spectrum. Today there are already use cases where
> Radio Access Network (RAN) is shared between multiple operators and they
> are interested in sharing core resources as well. I can see multiple
> NETCONF servers running on Mobile Switching Center (MSC), server per each
> virtual instance for tenant.
>
>
That's all fine but it does not alter my opinion at all that platforms that
do not need this feature should not be impacted by it.  If that means that
YANG will "fork" into a solution for big routers and a different solution
for not-a-routers, then that's fine.  The market can decide better than the
IETF anyway.


Dean
>

Andy


>
> On Sep 22, 2015, at 9:38 AM, Andy Bierman  wrote:
>
>
>
> On Tue, Sep 22, 2015 at 3:00 AM, Robert Wilton  wrote:
>
>> Hi Andy,
>>
>> Please can you clarify. Is your concern specifically with requirement 7?
>> Or the full set of requirements in draft-chairs-netmod-opstate-reqs-00
>> ?
>>
>>
>
> My concern is the impact on implementations that do not contain virtual
> servers
> or do not even contain routers. If the scope of a solution is only
> routers, then
> it does not matter how router-centric the solution.  But if the scope is
> every
> device that uses YANG, then it does matter.
>
> To be quite specific:
>- most devices do not require long time intervals  to apply
> configuration so any solution
>  to identify intended vs. applied config is a waste of resources
>
>   - most devices do not contain virtual servers so placing the data models
> in a framework
> for virtualization is a waste of resources
>
> A good engineering solution would only use engineering resources, device
> resources,
> and/or network resources on platforms that actually have these problems.
> It's the  difference between MAY leverage a common model-structure and
> MUST leverage
> a common model-structure. (Something IETFers should understand).
>
> If the solution really is MAY, then I have no concerns, but I know YANG
> does
> not actually support that, and it probably never will.  Relocatable YANG
> would
> be rather complicated, so that is not an option at this time.
>
>
> Thanks,
>> Rob
>>
>
>
> Andy
>
>
>>
>>
>> On 21/09/2015 20:28, Andy Bierman wrote:
>>
>> Hi,
>>
>> I do not think the issue of scope is being considered very carefully.
>>
>> IMO the solutions being proposed are extremely router-centric.
>> (e.g., most NETCONF servers DO NOT have any virtual servers within them).
>>
>> The larger the scope, the more concern I have that
>> the IETF will be pushing expensive solutions on platforms
>> that don't have any of the "problems" in the first place.
>>
>>
>> Andy
>>
>>
>>
>> On Mon, Sep 21, 2015 at 12:09 PM, Kent Watsen 
>> wrote:
>>
>>>
>>> Thanks Robert, but I think I like Benoit's edit more.  Are you OK with it
>>> as well?
>>>
>>> PS: I've moved this issue to the VERIFY state.
>>>
>>> Thanks,
>>> Kent
>>>
>>>
>>>
>>>
>>> On 9/21/15, 5:34 AM, "Robert Wilton" < 
>>> rwil...@cisco.com> wrote:
>>>
>>> >Hi,
>>> >
>>> >I suggest changing the wording for A and adding D:
>>> >
>>> >7.  Ability for distinct modules to leverage a common
>>> model-structure
>>> >A.  Scope is limited to providing a general model-structure only
>>> >B.  Multiple domain-specific trees are okay
>>> >C.  Multiple namespaces are okay
>>> >D.  The model-structure may be used or extended by other
>>> >organizations.
>>> >
>>> >Justifications for (A):
>>> >  - Limiting the scope to IETF-defined modules almost implies that
>>> >'ietf' would end up in the path (which would be wrong/unnecessary).
>>> >  - Clients don't care which SDO defines the modules for the protocols
>>> >they use, they just want a coherent organization of modules.
>>> >  - General structure only to limit the scope because trying to
>>> >precisely place every protocol/feature is likely to be fragile in the
>>> >face of future changes.
>>> >
>>> >Justifications for (D):
>>> >  - To suggest and encourage other SDOs to use the same structure, but
>>> >cannot mandate what they do.
>>> >
>>> >Thanks,
>>> >Rob
>>> >
>>> >
>>> >On 18/09/2015 22:56, Kent Watsen wrote:
>>> >> Regarding https://github.com/netmod-wg/opstate-reqs/issues/7
>>> >>
>>> >>
>>> >>Jonathan> Why does 7(A) limit the scope to IETF-defined modules of
>>> >>  others are now defining YANG modules?
>>> >>
>>> >>Benoit> Good point. We need to provide guidance for the other SDOs.
>>> >>
>>> >>
>>> >> Current text says:
>>> >>
>>> >> 7.  Ability for distinct modules to leverage a common
>>> >>model-structure
>>> >> A.  Scope is limited to IETF-defined modules
>>> >> B.  Multiple domain-specific trees are okay
>>> >> C.  Multiple namespaces are okay
>>> >>
>>> >>
>>> >>
>>>

Re: [netmod] opstate-reqs #7: Why limit scope to just IETF-defined modules

2015-09-22 Thread Andy Bierman 
On Tue, Sep 22, 2015 at 11:53 AM, Dean Bogdanovic 
wrote:

>
> On Sep 22, 2015, at 2:46 PM, Andy Bierman  wrote:
>
>
>
> On Tue, Sep 22, 2015 at 11:39 AM, Dean Bogdanovic 
> wrote:
>
>> Andy,
>>
>> Mobile operators are sharing infrastructure more and more. They are even
>> now considering sharing spectrum. Today there are already use cases where
>> Radio Access Network (RAN) is shared between multiple operators and they
>> are interested in sharing core resources as well. I can see multiple
>> NETCONF servers running on Mobile Switching Center (MSC), server per each
>> virtual instance for tenant.
>>
>>
> That's all fine but it does not alter my opinion at all that platforms that
> do not need this feature should not be impacted by it.  If that means that
> YANG will "fork" into a solution for big routers and a different solution
> for not-a-routers, then that's fine.  The market can decide better than
> the IETF anyway.
>
>
> To certain extent agree with your comment. But when you are talking about
> forking YANG for different domains, shouldn’t we try to have features in
> YANG and then implementers can decide which features they want to use? And
> then market can decide, which implementations they like the best?
>
>
OK - I guess we are in agreement.

There is nothing particularly difficult about extracting text from a YANG
module
and pasting it into a different YANG module.  In my experience, vendors
are not willing to spend unlimited resources to comply to a standard.
If the standard does not fit, they will use the parts that do fit and figure
something else out for the rest.

E.g., if a YANG module is deemed too heavy-weight because it assumes
a set of use-cases that do not apply to a platform, it will be quite easy
to use a different YANG module.  Market forces will not sustain false
commonality.


Dean
>
>
Andy


>
>
> Dean
>>
>
> Andy
>
>
>>
>> On Sep 22, 2015, at 9:38 AM, Andy Bierman  wrote:
>>
>>
>>
>> On Tue, Sep 22, 2015 at 3:00 AM, Robert Wilton  wrote:
>>
>>> Hi Andy,
>>>
>>> Please can you clarify. Is your concern specifically with requirement
>>> 7?  Or the full set of requirements in draft-chairs-netmod-opstate-reqs-00
>>> ?
>>>
>>>
>>
>> My concern is the impact on implementations that do not contain virtual
>> servers
>> or do not even contain routers. If the scope of a solution is only
>> routers, then
>> it does not matter how router-centric the solution.  But if the scope is
>> every
>> device that uses YANG, then it does matter.
>>
>> To be quite specific:
>>- most devices do not require long time intervals  to apply
>> configuration so any solution
>>  to identify intended vs. applied config is a waste of resources
>>
>>   - most devices do not contain virtual servers so placing the data
>> models in a framework
>> for virtualization is a waste of resources
>>
>> A good engineering solution would only use engineering resources, device
>> resources,
>> and/or network resources on platforms that actually have these problems.
>> It's the  difference between MAY leverage a common model-structure and
>> MUST leverage
>> a common model-structure. (Something IETFers should understand).
>>
>> If the solution really is MAY, then I have no concerns, but I know YANG
>> does
>> not actually support that, and it probably never will.  Relocatable YANG
>> would
>> be rather complicated, so that is not an option at this time.
>>
>>
>> Thanks,
>>> Rob
>>>
>>
>>
>> Andy
>>
>>
>>>
>>>
>>> On 21/09/2015 20:28, Andy Bierman wrote:
>>>
>>> Hi,
>>>
>>> I do not think the issue of scope is being considered very carefully.
>>>
>>> IMO the solutions being proposed are extremely router-centric.
>>> (e.g., most NETCONF servers DO NOT have any virtual servers within them).
>>>
>>> The larger the scope, the more concern I have that
>>> the IETF will be pushing expensive solutions on platforms
>>> that don't have any of the "problems" in the first place.
>>>
>>>
>>> Andy
>>>
>>>
>>>
>>> On Mon, Sep 21, 2015 at 12:09 PM, Kent Watsen 
>>> wrote:
>>>

 Thanks Robert, but I think I like Benoit's edit more.  Are you OK with
 it
 as well?

 PS: I've moved this issue to the VERIFY state.

 Thanks,
 Kent




 On 9/21/15, 5:34 AM, "Robert Wilton" < 
 rwil...@cisco.com> wrote:

 >Hi,
 >
 >I suggest changing the wording for A and adding D:
 >
 >7.  Ability for distinct modules to leverage a common
 model-structure
 >A.  Scope is limited to providing a general model-structure
 only
 >B.  Multiple domain-specific trees are okay
 >C.  Multiple namespaces are okay
 >D.  The model-structure may be used or extended by other
 >organizations.
 >
 >Justifications for (A):
 >  - Limiting the scope to IETF-defined modules almost implies that
 >'ietf' would end up in the path (which would be wro