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.
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.
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.
Vladimir
/js
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
