Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
 by ietfa.amsl.com (Postfix) with ESMTP id 237101200FC
 for <netmod@ietfa.amsl.com>; Tue,  9 Jan 2018 03:29:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01,
 URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44])
 by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id NoBXlCWFQxqB for <netmod@ietfa.amsl.com>;
 Tue,  9 Jan 2018 03:29:51 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45])
 by ietfa.amsl.com (Postfix) with ESMTP id 53E96126DEE
 for <netmod@ietf.org>; Tue,  9 Jan 2018 03:29:51 -0800 (PST)
Received: from localhost (unknown [173.38.220.56])
 by mail.tail-f.com (Postfix) with ESMTPSA id E03671AE0144;
 Tue,  9 Jan 2018 12:29:49 +0100 (CET)
Date: Tue, 09 Jan 2018 12:28:07 +0100 (CET)
Message-Id: <20180109.122807.1121028038684414186.mbj@tail-f.com>
To: rwilton@cisco.com
Cc: andy@yumaworks.com, netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <d2f8abd1-56fb-93b0-da3c-37cf16d2d4db@cisco.com>
References: <cf27d398-1883-c1ce-a54a-4644bac8a1dc@cisco.com>
 <CABCOCHQCv8ih9uKFxmews_=3c_rX6fSAA=L8vtW91k-pMSHOEg@mail.gmail.com>
 <d2f8abd1-56fb-93b0-da3c-37cf16d2d4db@cisco.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/HWAi4pN4tQeYHcCFZwpZZ4FtBHo>
Subject: Re: [netmod] AD review: draft-ietf-netmod-revised-datastores-08
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>,
 <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>,
 <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jan 2018 11:29:55 -0000

Robert Wilton <rwilton@cisco.com> wrote:
> Hi Andy,
> =

> =

> On 08/01/2018 19:45, Andy Bierman wrote:
> >
> >
> > On Mon, Jan 8, 2018 at 5:55 AM, Robert Wilton <rwilton@cisco.com
> > <mailto:rwilton@cisco.com>> wrote:
> >
> >     Hi Andy,
> >
> >     Regarding your comment below, this intent is captured by this t=
ext
> >     describing the operational datastore in section 5.3:
> >
> >         <operational> SHOULD conform to any constraints specified i=
n the
> >         data
> >         model, but given the principal aim of returning "in use" va=
lues, it
> >         is possible that constraints MAY be violated under some
> >         circumstances, e.g., an abnormal value is "in use", the str=
ucture of
> >         a list is being modified, or due to remnant configuration (=
see
> >         Section 5.3.1).  Note, that deviations SHOULD be used when =
it is
> >         known in advance that a device does not fully conform to th=
e
> >         <operational> schema.
> >
> >         Only semantic constraints MAY be violated, these are the YA=
NG
> >         "when",
> >         "must", "mandatory", "unique", "min-elements", and "max-ele=
ments"
> >         statements; and the uniqueness of key values.
> >
> >         Syntactic constraints MUST NOT be violated, including hiera=
rchical
> >         organization, identifiers, and type-based constraints.  If =
a node in
> >         <operational> does not meet the syntactic constraints then =
it MUST
> >         NOT be returned, and some other mechanism should be used to=
 flag the
> >         error.
> >
> >
> >     Do you agree that this is sufficient?
> >
> >
> >
> > Not really.
> > It does not address my concern, which is that NMDA is
> > removing the YANG constraints on config=3Dfalse data nodes
> > for no apparent reason.
> =

> There is a reason. I don't think that the constraints on config=3Dfal=
se
> is really being removed, because I don't think that they truly existe=
d
> in the first place (despite what RFC 7950 might indicate!).

I agree.  But note that RFC 7950 says:

   o  If the constraint is defined on state data, it MUST be true in a
      valid state data tree.

It is not defined anywhere that <get> must return a "valid state data
tree".

In reality, I suspect that all implementations of <get> call various
instrumentation call back functions in some order, possibly in
parallell, which means that data will be collected at different times
from the backend systems.  I don't think it is feasible to freeze the
operational state of a device, collect all data, and unfreeze, in
order to get a consistent snapshot of the operational state.


/martin

> 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 ensur=
e
> that <running> always holds a consistent configuration.=A0 Having a
> consistent configuration is the most important property here.=A0
> 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.=A0 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:
> =A0- if the message is garbled or not sane then it makes sense to
> discard it.
> =A0- however, what should the client do if the message is well formed=

> but either (i) contains some values outside the permitted schema rang=
e
> (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 tha=
t
> doesn't seem to be helpful, since it allows for a very fragile model
> of system management.=A0 I.e. if one small thing is bad then the whol=
e
> 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.=A0 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.=A0 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:
> =A0- what if the real value in use (e.g. that is read from the hardwa=
re)
> is outside the permitted range (because of a logic defect)?=A0 Is it
> really better to suppress that value entirely or return a value that
> server knows to be wrong?
> =A0- 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 i=
s
> very hard (if not impossible) to do.
> =

> So what the NMDA architecture states is:
> =A0(i) if a server knows that it won't conform to the operational sch=
ema
> then it must use deviations,
> =A0(ii) a server in a normal steady state should conform to the
> operational schema (and be valid),
> =A0(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,
> =A0(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 lon=
g
> as it can be encoded).
> =A0(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 constraint=
s
> > are applicable to any data node, not just config=3Dtrue data nodes.=

> > The requirement to implement the ancestor nodes (with keys) does no=
t
> > change.
> =

> The draft does not allow this to be violated.=A0 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=3Dfalse
> > data nodes does not change.
> >
> > To do otherwise does not make sense.=A0 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 ev=
ery
> > interface?
> =

> It is not OK for a server to ignore that and add Ethernet counters to=

> every interface (without using a deviation).=A0 The draft is not tryi=
ng
> 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 allowe=
d
> 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).=A0 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=3Dtrue 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=3Dfalse data
> >>     that is valid according to the YANG definitions is not affecte=
d
> >>     by NMDA.
> >>     That is not being taken away.=A0 The ability to validate
> >>     operational values
> >>     of configuration data has never been provided, and therefore i=
s
> >>     not being taken away either.
> >>
> >>     A constraint on config=3Dtrue nodes only applies to configurat=
ion
> >>     datastores.
> >>     These are the only constraints that should be ignored in
> >>     <operational>.
> >>     Constraints on config=3Dfalse nodes still apply in <operationa=
l>.
> >>
> >>
> >>     Andy
> >>
> >>
> >>
> >>     On Thu, Dec 21, 2017 at 2:27 PM, Juergen Schoenwaelder
> >>     <j.schoenwaelder@jacobs-university.de
> >>     <mailto:j.schoenwaelder@jacobs-university.de>> wrote:
> >>
> >>         On Thu, Dec 21, 2017 at 07:52:54PM +0100, Vladimir Vassile=
v
> >>         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.=A0 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 ap=
ply
> >>         configuration for
> >>         > > > > resources that are missing (which seems reasonable=
).=A0
> >>         E.g. I cannot
> >>         > > > > configure an IP address on a physical interface th=
at
> >>         isn't there.=A0 Or if
> >>         > > > > the physical interface gets removed then the
> >>         configuration associated
> >>         > > > > with that interface is also removed from operation=
al.
> >>         > > > >
> >>         > > > > 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 validi=
tiy
> >>         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 t=
he 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 conform=
ing
> >>         to the model
> >>         > can. If not a better model is needed not a hack that bre=
aks
> >>         the datastore
> >>         > conformance to the YANG model. I do not see how
> >>         > /interfaces/interface/oper-status=3Dnot-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. I=
f your
> >>         system knows about interfaces that are not present (i.e.,
> >>         there is
> >>         operational state about them), you can report these
> >>         interfaces.=A0 But
> >>         'is configured' is confusing here. I am not sure a line ca=
rd
> >>         that does
> >>         not exist should be considered configured. But yes, this m=
ay
> >>         be system
> >>         specific. Anyway, draft-ietf-netmod-rfc7223bis-01.txt stil=
l has
> >>         oper-status 'not-present' - so this seems to be a mood poi=
nt.
> >>
> >>         > > > If this is about to change it will compromise
> >>         interoperability
> >>         > > > and a significant portion of the client implementati=
on
> >>         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-identifie=
r
> >>         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 implementat=
ion
> >>         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=3Dnot-present) Thi=
s
> >>         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 mo=
dels.
> >>         > >
> >>         > > > 2. Even with the change in 1. I do not see the remov=
al
> >>         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 t=
he
> >>         models e.g.
> >>         > > > /interfaces/interface/oper-status=3Dnot-present is
> >>         oversimplified solution but
> >>         > > > it needs to be extended exactly as much as the solut=
ion
> >>         provided by the
> >>         > > > removal of config true; nodes without the sacrifice =
of
> >>         YANG validity of
> >>         > > > operational.
> >>         > > Your thinking is likely wrong. <operational> reports t=
he
> >>         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. Reusi=
ng
> >>         the model of a
> >>         > config true; data to represent state absent of intent (e=
.g.
> >>         > /interfaces/interface with origin=3D"or:system") is a ha=
ck.
> >>         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=3Dnot-present instead =
of
> >>         adding the straw
> >>         > that breaks the camel's back.
> >>
> >>         I fail to see why you believe all objects that appear in i=
ntended
> >>         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 se=
c.
> >>         5.3. The Operational
> >>         > > > State Datastore (<operational>) is that plug-and-pla=
y
> >>         solutions can be
> >>         > > > implemented without this limited approach that has t=
he
> >>         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:
> >>         > > >
> >>         > > >=A0 =A0=A0 configuration data nodes supported in a
> >>         configuration datastore
> >>         > > >=A0 =A0=A0 MAY be omitted from <operational> if a ser=
ver is
> >>         not able to
> >>         > > >=A0 =A0=A0 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 th=
ink
> >>         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 exampl=
e
> >>         information
> >>         > indicating when the line card became unavailable, what w=
as
> >>         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 accomodat=
e the
> >>         differnet styles.
> >>
> >>         /js
> >>
> >>         --
> >>         Juergen Schoenwaelder=A0 =A0 =A0 =A0 =A0 =A0Jacobs Univers=
ity Bremen gGmbH
> >>         Phone: +49 421 200 3587=A0 =A0 =A0 =A0 =A0Campus Ring 1 | =
28759 Bremen
> >>         | Germany
> >>         Fax:=A0 =A0+49 421 200 3103=A0 =A0 =A0 =A0
> >>         =A0<http://www.jacobs-university.de/
> >>         <http://www.jacobs-university.de/>>
> >>
> >>         _______________________________________________
> >>         netmod mailing list
> >>         netmod@ietf.org <mailto:netmod@ietf.org>
> >>         https://www.ietf.org/mailman/listinfo/netmod
> >>         <https://www.ietf.org/mailman/listinfo/netmod>
> >>
> >>
> >>
> >>
> >>     _______________________________________________
> >>     netmod mailing list
> >>     netmod@ietf.org <mailto:netmod@ietf.org>
> >>     https://www.ietf.org/mailman/listinfo/netmod
> >>     <https://www.ietf.org/mailman/listinfo/netmod>
> >
> >
> =