On Wed, Dec 23, 2015 at 12:52 PM, Robert Wilton <robert.pub...@wilton.org.uk > wrote:
> Hi, > > On 23/12/2015 18:22, Acee Lindem (acee) wrote: > > > > From: Andy Bierman < <a...@yumaworks.com>a...@yumaworks.com> > Date: Wednesday, December 23, 2015 at 11:18 AM > To: Acee Lindem < <a...@cisco.com>a...@cisco.com> > Cc: Ladislav Lhotka <lho...@nic.cz>, Kent Watsen <kwat...@juniper.net>, " > netmod@ietf.org" <netmod@ietf.org> > Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01 > > > > On Wed, Dec 23, 2015 at 8:11 AM, Acee Lindem (acee) <a...@cisco.com> > wrote: > >> >> >> From: Andy Bierman <a...@yumaworks.com> >> Date: Wednesday, December 23, 2015 at 10:46 AM >> To: Acee Lindem <a...@cisco.com> >> Cc: Ladislav Lhotka <lho...@nic.cz>, Kent Watsen <kwat...@juniper.net>, " >> netmod@ietf.org" < <netmod@ietf.org>netmod@ietf.org> >> Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01 >> >> >> >> On Wed, Dec 23, 2015 at 7:01 AM, Acee Lindem (acee) <a...@cisco.com> >> wrote: >> >>> >>> On 12/23/15, 3:22 AM, "netmod on behalf of Ladislav Lhotka" >>> <netmod-boun...@ietf.org on behalf of lho...@nic.cz> wrote: >>> >>> > >>> >> On 23 Dec 2015, at 04:06, Kent Watsen < <kwat...@juniper.net> >>> kwat...@juniper.net> wrote: >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> On 12/21/15, 2:21 PM, "netmod on behalf of Ladislav Lhotka" >>> >>< <netmod-boun...@ietf.org>netmod-boun...@ietf.org on behalf of >>> lho...@nic.cz> wrote: >>> >> >>> >>> >>> >>>> On 21 Dec 2015, at 19:02, Juergen Schoenwaelder >>> >>>>< <j.schoenwael...@jacobs-university.de> >>> j.schoenwael...@jacobs-university.de> wrote: >>> >>>> >>> >>>> On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Claise wrote: >>> >>>> >>> >>>>> I hope that nobody disagrees that the operational state design and >>> >>>>>how >>> >>>>> to structure the models are the two blocking factors to publish >>> YANG >>> >>>>> models. If you disagree or don't see this, let me know, I should >>> >>>>> communicate better. >>> >>>> >>> >>>> Even if it may spoil your day, I disagree that there is a blocking >>> >>>> factor that should stop us from publishing models. There seem to be >>> >>>> ways to address the requirements without having to block all work or >>> >>>> to redo what that we have published. But sure, if you make it a >>> >>>> blocking factor, it will be one. >>> >>> >>> >>> I agree with Juergen. It is not clear to me how the proposed split >>> >>>between intended and applied configuration is supposed to affect the >>> >>>data models we are working on. >>> >> >>> >> >>> >> As I understand it, solution #1 affects the models themselves, whereas >>> >>solutions #2 and #3 are transparent to the models. >>> > >>> >Then #1 looks like a non-starter to me. >>> >>> I’d like to point out that we also have the requirement to allow >>> retrieval >>> of derived-state along with intended-config and applied-config. This will >>> require modification to most of the existing YANG drafts as most now have >>> separate trees for config and operational state. Note that this is >>> discussed in sections 6, 7.3, and 7.4 of >>> https://www.ietf.org/id/draft-wilton-netmod-opstate-yang-02.txt. >>> >>> >> A NETCONF <get> with a subtree filter can retrieveg both config and >> non-config subtrees >> at the same time. A new RPC can be added (or existing <get> RPC >> extended) to >> filter various conditions. I don't see how the YANG data layout affects >> the definition >> of "rpc" statements in another module. >> >> >> There is the requirement to be able to do the retrievals but there is >> also this requirement: >> >> C. The mappings needs to be programmatically consumable >> >> >> Now, if the derived-state nodes are located with the config-nodes, then >> this is readily satisfied. Another way of satisfying the requirement may be >> structural and naming conventions but this is not as sure as co-location. >> >> > There can be meta-data returned (XML attributes) that identify the > additional properties. > This is better co-location since the pattern cannot be unintentional (as > it can with the > config-within-state containers). > > > This may be an option for published models. However, for models in > development, wouldn’t it be easier to just move the nodes rather than > defining the relationships in meta-data? > > > Just relying on meta-data to relate config and state would probably add a > lot of relations noise to the models. I would imagine that this would make > the models source YANG files harder to read, and potentially have a slight > negative performance impact in the clients - which may be important if they > have to relate many nodes. > > The meta-data is not defined in the YANG models. It is defined for the protocol. Co-location doesn't really scale. A system may have candidate, running, startup, and even proprietary "state-related" data collections. It would take 3 or 4 copies of the data to model these datastores inside the data models. But IMO any solution that burdens the server with retrieval requests while the device is busy applying config will only make the problem worse. > Hence why I think that it is best to use co-location where possible, and > just use explicit meta-data where the nodes are further apart in the data > tree. > > I looked at your draft. Is it implemented anywhere? It requires a custom parser that sometimes parses the leaf "foo" as a YANG leaf but if the special request is made, then the reply will be returning "foo" as a container of leafs, instead of a leaf like normal. > This still leaves the question as to what to do with the interfaces vs > interfaces-state. There would seem to be two possible solutions to me: (1) > merge the trees together as per OpenConfig, or (2) add a special case rule > for interfaces. I think that this is an issue that neither Kent's nor my > draft fully addresses. > This is different -- interfaces-state can contain discovered interfaces that have not been configured yet. > > Thanks, > Rob > > > Andy > > > Thanks, > Acee > > > > > >> Thanks, >> Acee >> >> > Andy > > >> >> >> Thanks, >>> Acee >>> >> >> >> Andy >> >> >>> >>> >>> > >>> >Lada >>> > >>> >> >>> >> Kent >>> >> >>> >> >>> >> >>> >>> Lada >>> >>> >>> >>>> >>> >>>>> I hope that nobody really believes that because some people in IETF >>> >>>>>(or >>> >>>>> in any other SDOs) thinks that what those operators want is a bad >>> >>>>>idea, >>> >>>>> those operators will not get what they request/pay for from their >>> >>>>>suppliers. >>> >>>> >>> >>>> To be fair, those operators also tell us that they use protocols >>> that >>> >>>> are not IETF protocols and it remains somewhat unclear what those >>> >>>> protocols are we are expected to optimize data model solutions for. >>> >>>> >>> >>>> /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 >>> >>>> <netmod@ietf.org>netmod@ietf.org >>> >>>> <https://www.ietf.org/mailman/listinfo/netmod> >>> https://www.ietf.org/mailman/listinfo/netmod >>> >>> >>> >>> -- >>> >>> Ladislav Lhotka, CZ.NIC Labs >>> >>> PGP Key ID: E74E8C0C >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> netmod mailing list >>> >>> <netmod@ietf.org>netmod@ietf.org >>> >>> <https://www.ietf.org/mailman/listinfo/netmod> >>> https://www.ietf.org/mailman/listinfo/netmod >>> > >>> >-- >>> >Ladislav Lhotka, CZ.NIC Labs >>> >PGP Key ID: E74E8C0C >>> > >>> > >>> > >>> > >>> >_______________________________________________ >>> >netmod mailing list >>> >netmod@ietf.org >>> >https://www.ietf.org/mailman/listinfo/netmod >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> >> >> > > > _______________________________________________ > netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod > > >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
