Re: [netmod] operational knobs

[Andy Bierman <andy at netconfcentral.com>]

Phil Shafer wrote:
> Andy Bierman writes:
>>   start-dhcp (start-address=192.168.1.10, end-address=192.168.1.100, ...)
> 
> This is fine if the customer doesn't care about any of the details
> of how dhcp is deployed, or it your RPC contains all the parameters
> they need.  But each customer is different; beware of underestimating
> the diversity of the marketplace.
> 
> IMHO the world's just not that simple.  Eventually, you'll need
> access to other config data (interfaces) and datastore-wide constraint
> checking.   The good news is that YANG handle do all this.
> 

Maybe it's a better-than-nothing approach, but nothing
is what we have now wrt/ standard configuration.
For 20 years, vendors have been claiming they
cannot agree on every detail of any sort of config.

YANG has some formal clauses, bit no new optionality features
that have not existed before, so I do not think 'if-feature'
will be enough to facilitate standard data models.

It is a total myth that there is any sort of procedural interoperability
with NETCONF. When it comes to applying arbitrary
explicit and implicit nc:operation attributes throughout
the conceptual config tree -- especially for copy-config and commit,
it is very implementation-dependent.

What constitutes an edit?
Is it just the data that changed?
What about applying defaults?
For 'explicit default' servers, a 'client-replacing-server-default'
is an edit, but it is not an edit anywhere else.
Do non-edits get saved to NV-storage?  Does confirmed-commit
still proceed for NO-OP edits?  What about nested nc:operation
attributes?  Which combinations does the server allow?
Does the server support alteration of every parameter for an
existing list entry?


>> I am not
>> convinced that the forklift data-model (ala ipfix-psamp.yang)
>> has much chance of widespread deployment.
> 
> My hope is that I can define simple transformations between IETF
> models and JUNOS models.  I think it's unlikely that JUNOS will
> adopt the DHCP module directly, but if we can generate data that
> is ietf-dhcp.yang with junos augmentations.
> 

An analogy from another industry is General MIDI.
Even though a fancy keyboard has 1000 details to create
an instrument, not everybody wants to spend 5 years
studying the manual before they could just make the thing
sound like a piano, organ, trombone, etc.

So all the keyboards support a standard set of instruments,
which can be used as-is, or edited like the 'from-scratch'
instruments.  It is understood that the Classical Piano
from 2 different vendors may not sound exactly the same,
and certainly will not be configured the same.

So back to Junos -- in this analogy, you would support
the general IETF RPC operations that do limited things,
and these RPCs would map directly to your vendor data structure(s),
for experts to use.

Summary:

  ietf-start-dhcp(P1, P2, P3)

      [server implementation]
       --->  Junos 'dhcp' container;  P1 --> Junos(P1), etc.

Your expert customers will just use the complex vendor config data,
but if they do not care about the details, they may use ietf-start-dhcp.

IMO, the current IETF processes have produced no positive results,
so maybe the all-or-nothing, giant data-model or bust approach
is the reason why.

> Thanks,
>  Phil
> 

Andy