Subject: Re: [netmod] Y45 wrap up

From: Randy Presuhn <[email-masked]>
Date: Fri, 24 Apr 2015 12:21:10 -0700 (GMT-07:00)

Hi -

>From: Andy Bierman <[email-masked]>
>Sent: Apr 24, 2015 10:23 AM
>To: Randy Presuhn <[email-masked]>
>Cc: "[email-masked]" <[email-masked]>
>Subject: Re: [netmod] Y45 wrap up
>
>On Fri, Apr 24, 2015 at 10:12 AM, Randy Presuhn
><[email-masked]> wrote:
>> Hi -
>>
>>>From: Juergen Schoenwaelder <[email-masked]>
>>>Sent: Apr 24, 2015 12:37 AM
>>>To: Andy Bierman <[email-masked]>
>>>Cc: "[email-masked]" <[email-masked]>
>>>Subject: Re: [netmod] Y45 wrap up
>> ...
>>>The assumption that the set of imports used by all modules determines
>>>the version of modules a server implements does not work with the goal
>>>that a server implements exactly one version of every module. This
>> ...
>>
>> The goal that "a server implements exactly one version" strikes
>> me as unrealistic for multi-vendor / "open" systems and systems
>> with hot swappable (redundant) component subsystems.
>>
>
>But this is fairly unmanageable.
>You are suggesting (for example) that the interface instances
>on line card 1 are from rev 1, and the interface instances from
>line card 2 are from rev 5, etc.

I know products like this have existed.  
Perhaps the answer is simply that netconf
is the not right tool for that job.

>At this point, static conformance is worthless.  You need run-time
>operations to ask the server implementation what it will accept.

"Worthless" is perhaps a little strong, but yes.

>Or you use trial-and-error and do not have the luxury of coding
>to the data model.

I think "coding to the data model" (at least as I understand
the phrase) is a poor strategy for complex or long-lived
product lines.  The design has to be at a higher level, or
every minor rev will create major churn in the management
infrastructure.

>You build data silos so you can try obscere
>undocumented tricks to know what is really supported.
>Oh wait, that's how SNMP and CLI work today.

My experience in SNMP was that the "undocumented tricks"
were to cope with
   (1) errors in the implementation of the protocol
   (2) errors in the implementation of the data models

*This* discussion has thus far limited itself to assuming
that the protocol and data model implementations are correct.
It's only been about accurately representing model or the
configuration (in the classic sense of configuration management)
of an implementation.

>Hopefully we
>will do better with YANG. Maybe some future version.

Hope springs eternal.  It seems like things work fine until
the problem is actually one of configuration management.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 24 Apr 2015 12:50:23 -0700

> is the not right tool for that job.

I doubt these products use standard mechanisms to know
which instances are rev. 1 and which are rev. 5.
That's what I mean by data silos.

This may be too difficult to standardize in the data
modeling language. It would be scary if we need
an RPC operation so the client can ask for every instance
of every data node "what revision of the module are you from?"

> every minor rev will create major churn in the management

Not if the YANG update rules are followed carefully.
We expect old clients to keep working with new servers,
or at least that is the goal.

> configuration (in the classic sense of configuration management)

IMO, one could interpret the rev1/rev5 interface instances example
as a broken implementation.  The server advertises just 1 revision
of the ietf-interfaces module, and if it doesn't honor that,
then in (the simplistic) terms of YANG conformance,
is not implemented correctly.

> the problem is actually one of configuration management.

We want automated tools to do the right thing without intervention.
This is a hard problem that NETCONF and YANG are in
the early stages of solving.

> Randy

Andy

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod