On 29/09/2015 21:22, Andy Bierman wrote:
On Tue, Sep 29, 2015 at 12:51 PM, Phil Shafer <[email protected]
<mailto:[email protected]>> wrote:
Andy Bierman writes:
>Perhaps the operational requirements are not that clear, so
>the terminology is also not that clear?
Are we trying to agree on the former without the later?
>Is there really a requirement to know detailed info about the
>differences between intended and applied config?
I'm assuming this will end up impacting either netconf operations
or yang data model construction. At that point (if not before),
we'll need clear terms for app writers and data modelers.
I don't have any objection to "intended" and "applied" as terms.
+1.
I think that the terms will be fine once we agree on the definitions of
them, and I think that we probably already agree on "intended".
>It seems like the general requirement is that the client
>needs to know when it can start using the network resource
>that has been added or modified in the intended config.
I agree.
Perhaps some wording based around the above might be a better way of
defining "applied configuration"?
E.g. considering that case where an VPWS service is being provisioned.
I would expect that a programmatic client might choose to wait until the
configuration to instantiate the VPWS service has been applied before
starting to verify the end-to-end connectivity as a pre-requisite to
using the service.
Consider that case where you add interface config for an interface
FRU that's not been inserted. This config might not be used for
months, until the tech inserts the FRU.
Clearly a case where the client should pick (2)
>There are 2 modes that fall out from this requirement:
> 1) synchronous: do not return from this RPC until resources are
ready
For a synchronous request I would suggest that the server should wait
until it has programmed all resources that are currently available (i.e.
installed in the system) and to warn on any resources which can't be
programmed because they are not present. Not returning from a request
because an item of hardware is physically not present in the system
doesn't sound like a usable design to me.
> 2) asynchronous: return right away from this RPC, and inform
the client
> when the resources are ready (could indicate ready in the
RPC response)
Given the inherently squishy definition of "ready", I'd prefer to
avoid #1.
None of the protocols actually tell the client which one they did, for
a given edit.
Ideally, I think that it would be good if a server could indicate
whether it supports (1) or (2) or both, and to allow a client to choose
which semantics are expected to be used when making the request.
Rob
I agree the best we could say is "I think it's ready right now".
However, I think even this much could require massive code changes in
many systems.
Thanks,
Phil
Andy
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
