I think that we all agree on the expected behavior for configuration:
If a client sends configuration to a server that would cause <running>
to become invalid then the server should reject that change, to ensure
that <running> always holds a consistent configuration. Having a
consistent configuration is the most important property here.
I.e. the server has the right to reject an invalid configuration
request from a client.
However, the flow of operational state data in opposite direction
cannot hold to the same rules. If during the processing of a get
request (or YANG push) a server sends operational state data back to a
client then a client has to choose how to process the message:
- if the message is garbled or not sane then it makes sense to
discard it.
- however, what should the client do if the message is well formed
but either (i) contains some values outside the permitted schema range
(but can be represented by the schema datatype), or (ii) by applying
the values would cause the clients copy of <operational> to become
invalid?
If the client discards the message because of one bad value, then that
doesn't seem to be helpful, since it allows for a very fragile model
of system management. I.e. if one small thing is bad then the whole
house of cards collapses.
So I think that the only sensible behaviour here is that the client
has to process the operational state update in a best effort fashion,
keep all the good data and probably flag any values that are outside
the value constraints. Similarly any reference constraint failures
(i.e. when/must) can similarly be flagged up, but throwing away an
update message that would cause the operational state to become
inconsistent doesn't seem to be helpful. I.e. it is much better if
the client gets to see the true state of the server, even if that
state isn't good (or consistent).
Similar questions arise on the server itself:
- what if the real value in use (e.g. that is read from the hardware)
is outside the permitted range (because of a logic defect)? Is it
really better to suppress that value entirely or return a value that
server knows to be wrong?
- can a server even know that its operational view is consistent? For
complex systems where the real operational state is split across
multiple underlying linecards, or remote devices, I think that this is
very hard (if not impossible) to do.
So what the NMDA architecture states is:
(i) if a server knows that it won't conform to the operational schema
then it must use deviations,
(ii) a server in a normal steady state should conform to the
operational schema (and be valid),
(iii) but, if the system is churning (e.g. configuration, route
update, etc) then the operational state of the server might be
transiently inconsistent and this is OK,
(iv) if, the server is in a bad state, then it is better to return
the actual state than to lie or not report a particular value (as long
as it can be encoded).
(v) a server does not need to explicitly validate that its view of
operational is valid. It is unclear what it would/could do if it
detected that the operational state is invalid, nor is it clear that
servers would generally be able to always perform this operation.
The server implementation requirements expressed in YANG constraints
are applicable to any data node, not just config=true data nodes.
The requirement to implement the ancestor nodes (with keys) does not
change.
The draft does not allow this to be violated. I.e. the following
statement prevents this: "Syntactic constraints MUST NOT be violated,
including hierarchical organization".
The requirement to conform to the YANG constraints defined within
config=false
data nodes does not change.
To do otherwise does not make sense. E.g. "when" conditions that add
ethernet
counters only when the interface type is ethernetCsmacd. Why would it
be OK for
the server to ignore that when-stmt and add ethernet counters to every
interface?
It is not OK for a server to ignore that and add Ethernet counters to
every interface (without using a deviation). The draft is not trying
to allow that.
But if an interface could change type (e.g. between Ethernet and ATM
via a different optics module being inserted) then it would be allowed
for a server to transiently report the ethernet counters on the
interface whilst it is in the process of changing the interface type
from ethernet to ATM (e.g. if the counters are maintained by a
separate daemon that is updated asynchronously with respect to the
config or optics change). Once the change had completed, the the
system reaches steady state then the Ethernet counter must no longer
be reported.
Thanks,
Rob
IMO the text above can only apply to the operational values of
config=true nodes.
Thanks,
Rob
Andy
On 21/12/2017 22:49, Andy Bierman wrote:
Hi,
It should be clear somehow that server requirements to provide
config=false data
that is valid according to the YANG definitions is not affected
by NMDA.
That is not being taken away. The ability to validate
operational values
of configuration data has never been provided, and therefore is
not being taken away either.
A constraint on config=true nodes only applies to configuration
datastores.
These are the only constraints that should be ignored in
<operational>.
Constraints on config=false nodes still apply in <operational>.
Andy
On Thu, Dec 21, 2017 at 2:27 PM, Juergen Schoenwaelder
<[email protected]
<mailto:[email protected]>> wrote:
On Thu, Dec 21, 2017 at 07:52:54PM +0100, Vladimir Vassilev
wrote:
> On 12/21/2017 02:20 PM, Juergen Schoenwaelder wrote:
>
> > On Thu, Dec 21, 2017 at 02:03:45PM +0100, Vladimir
Vassilev wrote:
> > > On 12/21/2017 11:34 AM, Robert Wilton wrote:
> > >
> > > > Hi Vladimir,
> > > >
> > > > First point of clarification is that this is not
about running/intended
> > > > at all. The contents of running/intended do not
change in anyway
> > > > depending on whether hardware is present or absent.
> > > >
> > > > The section is only concerned with how the
configuration is applied in
> > > > operational, and basically says that you cannot apply
configuration for
> > > > resources that are missing (which seems reasonable).
E.g. I cannot
> > > > configure an IP address on a physical interface that
isn't there. Or if
> > > > the physical interface gets removed then the
configuration associated
> > > > with that interface is also removed from operational.
> > > >
> > > > Operational isn't validated and data model
constraints are allowed to be
> > > > broken (ideally transiently).
> > > I want to focus on this. IMO giving up schema validitiy
for any datastore is
> > > unacceptable price. Pre-NMDA devices had full model
support in operational
> > > data (all YANG constrains part of the model without
discrimination were
> > > enforced).
> > There was a long debate about the value of returning the true
> > operational state. What do you do if the operational
state is invalid?
> > A server can reject configuration changes if they lead to
invalid
> > state, a server can not reject reality.
> IMO if the model can represent reality then data conforming
to the model
> can. If not a better model is needed not a hack that breaks
the datastore
> conformance to the YANG model. I do not see how
> /interfaces/interface/oper-status=not-present was not
representing the
> reality of a system with removed line card that is
configured and ready to
> resume operation as soon as the line card is reconnected.
I assume this is all system and implementation specific. If your
system knows about interfaces that are not present (i.e.,
there is
operational state about them), you can report these
interfaces. But
'is configured' is confusing here. I am not sure a line card
that does
not exist should be considered configured. But yes, this may
be system
specific. Anyway, draft-ietf-netmod-rfc7223bis-01.txt still has
oper-status 'not-present' - so this seems to be a mood point.
> > > If this is about to change it will compromise
interoperability
> > > and a significant portion of the client implementation
workload that can be
> > > automated will need to be coded in hand and tested.
Unresolved leafrefs,
> > > undefined behaviour of different implementations
removing different
> > > configuration nodes in violation of YANG semantic
constraints (which I do
> > > not think can be so clearly separated from the
syntactic constraints when
> > > one considers types like leafref, instance-identifier
etc.) and the
> > > corresponding side effects based on the server
implementators own creativity
> > > is eventually going to create more problems.
> > >
> > > 1. IMO the only acceptable solution is to have YANG
valid operational
> > > datastore at all times. operational like any other
datastore MUST be valid
> > > YANG data tree and it has to be a system implementation
task to consider all
> > > complications resulting from the removal of the
resources leading to any
> > > data transformations. If this is difficult or
impossible other mechanisms to
> > > flag missing resources should be used (e.g.
> > > /interfaces/interface/oper-status=not-present) This
sounds like a useful
> > > contract providing the value of a standard the
alternative does not.
> > As said above, it is impossible to report valid
operational state if
> > the operational state is not valid according to the models.
> >
> > > 2. Even with the change in 1. I do not see the removal
of intended
> > > configuration nodes from operational as a solution
worth implementing on our
> > > servers. I do not see a real world plug-and-play
scenario that can be
> > > automatically solved without specific additions to the
models e.g.
> > > /interfaces/interface/oper-status=not-present is
oversimplified solution but
> > > it needs to be extended exactly as much as the solution
provided by the
> > > removal of config true; nodes without the sacrifice of
YANG validity of
> > > operational.
> > Your thinking is likely wrong. <operational> reports the
operational
> > state. It may have little in common with <intended>.
Trying to derive
> > operational from intended is likely a not well working
approach.
> The proposal for this solution ("derive operational from
intended" e.g.
> merge /interfaces-state in /interfaces) comes from the
revised datastores
> draft not me.
>
> By definition config true; data represents intent. Reusing
the model of a
> config true; data to represent state absent of intent (e.g.
> /interfaces/interface with origin="or:system") is a hack.
The hack works
> fine without compromising the conformance of operational to
the YANG model
> as long as certain conditions are met. I am pointing out
that one of the
> conditions is to keep all of the intended configuration
data present in
> 'operational' and handle missing resources with
conventional means e.g.
> /interfaces/interface/oper-status=not-present instead of
adding the straw
> that breaks the camel's back.
I fail to see why you believe all objects that appear in intended
configuration needs to exist in applied configuration. In fact,
operators told us very clearly that they care about the
distinction
between intended and applied config.
> > > 3. Solutions like /interfaces/interface/admin-state
stop working. With the
> > > interface removed you can no longer figure if the
if-mib has or does not
> > > have the interface enabled so an operator has to use
SNMP or wait for a
> > > replacement line card to be connected to figure this
bit of information.
> > At least on my boxes, if I remove a line card, the
interface also
> > disappears in SNMP tables. Stuff that is operationally
not present is
> > simply operationally not present.
> >
> > > My
> > > interpretation of the MAY as requirement level in sec.
5.3. The Operational
> > > State Datastore (<operational>) is that plug-and-play
solutions can be
> > > implemented without this limited approach that has the
same problem as the
> > > pre-NMDA only now we have to have /interfaces-state to
keep config false;
> > > data relevant to hardware that is configured but not
present:
> > >
> > > configuration data nodes supported in a
configuration datastore
> > > MAY be omitted from <operational> if a server is
not able to
> > > accurately report them.
> > >
> > > I realize this discussion comes late. I have stated my
objections to this
> > > particular part of the NMDA draft earlier.
> > I believe there is a conceptual misunderstanding. I think
there never
> > was a requirement that a server reports the state of
hardware that is
> > not present.
> "Data relevant to hardware that is configured but not
present" is different
> from "state of hardware that is not present". For example
information
> indicating when the line card became unavailable, what was
the reason, or
> other information like how many packets that had this
interface as egress
> destination are being dropped as a result of the removal.
I think that systems handle non-existing interfaces
differently. It
seems that ietf-interfaces is flexible enough to accomodate the
differnet styles.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen
| Germany
Fax: +49 421 200 3103
<http://www.jacobs-university.de/
<http://www.jacobs-university.de/>>
_______________________________________________
netmod mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netmod
<https://www.ietf.org/mailman/listinfo/netmod>
_______________________________________________
netmod mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netmod
<https://www.ietf.org/mailman/listinfo/netmod>
