Hi Juergen, Alex, Currently in the L2 topology model there is one leaf "tp-state" which is state data. We can remove it first before we reach some agreement on how to introduce operational/state information to topology models.
Besides the approach Juergen suggested, do we also need to consider the approach proposed by openconfig-opstate? Best regards, Jie > -----Original Message----- > From: i2rs [mailto:[email protected]] On Behalf Of Alexander Clemm (alex) > Sent: Saturday, October 10, 2015 5:55 AM > To: Juergen Schoenwaelder; Susan Hares > Cc: Andy Bierman; [email protected]; Martin Bjorklund; Ladislav Lhotka; 'Alia > Atlas'; > 'Jeffrey Haas' > Subject: Re: [i2rs] WG LC for Topology (10/1 to 10/14) > > Hi Juergen, > > which specific objects/ subtrees are you referring to? > > Essentially, in ietf-network and ietf-network-topology, we have all > configuration information. The same is true for the Layer 3 topology - all > configuration information. (I cannot comment on L2 topology as I am not > involved there.) > > Are you saying that we should add an additional branch as a placeholder (and > perhaps an augmentation target) for operational data, even if we have not > otherwise defined any operational data? > > The only item in the topology that is read-only concerns the "server-provided" > flag, but this concerns a separate issue that was also discussed (I am not > sure if > this is what you are referring to). It is analogous to the other discussion > concerning distinguishing configuration that has been intended, versus one > that > is in effect etc . This concerns the issue that some topologies are > populated by > the server whereas some topologies can be populated by client applications. > We have had discussions in the past whether to "split this up", having a (rw) > branch to populate "intended" topologies and a (ro) branch for topologies "in > effect". We decided against it for various reasons - every piece of > information > would essentially be duplicated inside the model (this is not your normal > config > vs oper data distinction, but would essentially reflect a limitation of the > framework), leading to unnecessary additional complexity in the model (every > augmentation has to be conducted in two ! > places), > more complex validation rules, etc. > > --- Alex > > -----Original Message----- > From: i2rs [mailto:[email protected]] On Behalf Of Juergen Schoenwaelder > Sent: Friday, October 09, 2015 12:22 AM > To: Susan Hares <[email protected]> > Cc: [email protected]; Martin Bjorklund <[email protected]>; Ladislav Lhotka > <[email protected]>; Andy Bierman <[email protected]>; 'Jeffrey Haas' > <[email protected]>; 'Alia Atlas' <[email protected]> > Subject: Re: [i2rs] WG LC for Topology (10/1 to 10/14) > > Hi, > > there is a discussion on the yang doctors mailing list about the data model > design that mixes state data and configuration data into one subtree and that > uses a data model specific runtime object to identify what is config data and > what is state data. One of the main outcomes of the IAB workshop back in 2002 > was the need to clearly separate configuration from operational state and this > has been driven the design of NETCONF and YANG. YANG data model validation > rules, for example, make a distinction between config true and config false > data. > The config true or false property impacts what is returned by NETCONF's > get-config operation. Also note that config data is not allowed to refer to > config false data in constraints. > > It is unclear why the document does not follow the typical design pattern, > namely to have a config true subtree > > /networks/network* > > and a config false subtree > > /networks-state/network* > > Section 3.5 describes this approach in the 3rd paragraph and states "As most > data is defined in those groupings, the amount of additional definitions > required > will be limited." and there are no strong reasons given why this approach has > not been followed. > > /js > > On Thu, Oct 01, 2015 at 06:41:34PM -0400, Susan Hares wrote: > > This begins a 2 week WG Last call (10/1 to 10/14) > > > > > > > > draft-ietf-yang-network-topo - modeling draft > > > > http://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/ > > > > > > > > draft-ietf-i2rs-yang-l3-topology - L3 topology > > > > http://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ > > > > > > > > draft-ietf-i2rs-yang-l2-topology - L2 topology > > > > http://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l2-network-topolo > > gy/ > > > > > > > > Implementation status: > > > > > > > > This an OpenDaylight (ODL) implementation of the L3 topology and > > general model. It is likely the L2 topology model will be supported in > > future > ODL > > implementations. Jeff and I would appreciate anyone who has > > implementations of these topology models to provide details on list or > > offlist to the chairs. > > > > > > > > Sue Hares > > > > > _______________________________________________ > > i2rs mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/i2rs > > > -- > 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/> > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
