Subject: Re: [netmod] LL review of ip-cfg-02

From: Martin Bjorklund <[email-masked]>
Date: Fri, 23 Mar 2012 21:40:58 +0100 (CET)

Hi,

Ladislav Lhotka <[email-masked]> wrote:
> Hi,
> 
> this is my review od the ip-cfg-02 draft module. Some of the issues have
> already been discussed.
> 
> *** Proposed changes
>    1. (ad issue #ip-02.02) Change "ipv4" and "ipv6" nodes into
>       presence containers but keep the "enabled" knob.
> 
>       In the current version, IPv6 is enabled on an interface even if
>       the "ipv6" container is not present and there is no other
>       mention about IPv6. If "ipv6" becomes a presence container,
>       three states of the configuration are possible:
>       - no IPv6 configuration is present => IPv6 is disabled
>       - IPv6 configuration is present but IPv6 disabled via
>         enabled=false.
>       - IPv6 configuration is present and IPv6 enabled.

It seems you want ipv6 to be disabled, unless the operator explicitly
says so.  If so, why not simply make "enabled" false by default?
Having two mechanism (enabled and P-container) seems redundant.

>    2. Put the "address" list into a container, e.g. "addresses".
> 
>       Reason: avoid interleaving the addresses with other nodes, e.g.
>         <address>...</address>
>         <enabled>...</enabled>
>         <address>...</address>

I'd rather not invent artificial nodes in order to tweak the XML
encoding... if this is a real problem, we should consider changing the
encoding rules in 6020.

>    3. Add boolean leaf "is-router" (or "ip-forwarding") under both
>       "ipv4" and "ipv6".

Ok, this makes sense.  I have added this as an issue to discuss.

>       For IPv6, this configuration variable is required by RFC 4861,
>       sec. 6.2.1 and IMO belongs to this module. The other
>       router-specific configuration variables from that section are
>       defined in the 'routing-cfg' module.
> 
>       The leaf "create-global-addresses" then should have a dynamic
>       default equal to not(is-router).
> 
>    4. Add a config=false list of all addresses on an interface
>       (manually or automatically configured).
> 
>    5. Add the variables required by RFC 4861, sec. 6.3.2 (config=false
>       for all):
>       - link-mtu
>       - cur-hop-limit
>       - base-reachable-time
>       - reachable-time
>       - retrans-timer
> 
>    6. Add the following global (i.e. not per-interface) config=false
>       structures as required by RFC 4861, sec. 5.1.:
>       - neighbour cache
>       - routing table
> 
>       Do the same also for IPv4.

For all these, see my open issue ip-09.  The first question is if we
should add read-only objects already defined in the corresponding MIB
or not.

> *** Formal
> 
>     - p. 4: s/familiy/family/

Fixed.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 24 Mar 2012 10:08:52 +0100

> says so.  If so, why not simply make "enabled" false by default?

But then you also have the "autoconf/create-global-addresses" toggle. Its default value is also "true" but it should not apply if IPv6 is not enabled on the interface.

> Having two mechanism (enabled and P-container) seems redundant.

Actually, the very notion of P-container seems redundant as nobody is using it.

> encoding... if this is a real problem, we should consider changing the

It's not a real problem, just a matter of style. I am using such extra containers for almost all lists in the routing modules. Both approaches have their pros and cons, but we should probably unify the style for the core modules.

> should add read-only objects already defined in the corresponding MIB

If not, could such read-only objects be referred to from configuration?

Lada

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 24 Mar 2012 16:39:28 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> But then you also have the "autoconf/create-global-addresses" toggle. Its
> default value is also "true" but it should not apply if IPv6 is not enabled on
> the interface.

Sure.  But that needs needs to be clarified also in the solution
proposed by you, right?

> Actually, the very notion of P-container seems redundant as nobody is using it.

We use it in snmp-cfg in a few places.  I think it has its merits in
certain cases.

> It's not a real problem, just a matter of style. I am using such extra
> containers for almost all lists in the routing modules. Both approaches have
> their pros and cons, but we should probably unify the style for the core
> modules.
> 
> > 

non-config objects can never be referred to by configuration (leafrefs
and i-i).

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 24 Mar 2012 17:28:04 +0100

> Sure.  But that needs needs to be clarified also in the solution

Yes, but my point is that with "ipv6" being a P-container, there are the three different options above. As long as the operator doesn't create the container, he needn't bother about IPv6, its default values etc. - IPv6 simply doesn't exist on that interface. This is the principle of least embarrassment.

...

> non-config objects can never be referred to by configuration (leafrefs

Oh well, I forgot. This is however quite limiting. For example, an IP address might be configured to serve a certain purpose (as the source address for a routing protocol, say) with the restriction that it must be an address that exists on the device - but this may potentially also include *autoconfigured* addresses which are not present in configuration data. So this semantic constraint cannot be expressed in the data model, right?

Lada

---

From: Phil Shafer <[email-masked]>
Date: Sat, 24 Mar 2012 16:48:39 -0400

>Having two mechanism (enabled and P-container) seems redundant.

As a modeler, I encourage you _not_ to use the <disable> tags to
turn features off.  We did this early in JUNOS and it was painful,
since the model has to explicitly allow enable/disable values and
they are never in the right spots for the customer's needs.

Instead consider something like the JUNOS "inactive" which can be
be applied anywhere in the configuration (as a generic mechanism),
is completely flexible, and requires no work from the modeler.

http://www.juniper.net/techpubs/en_US/junos/topics/task/configuration/junos-software-configuration-statements-identifiers-deactivating-reactivating.html

>encoding... if this is a real problem, we should consider changing the

I'm assuming you are not really serious here.

>Ok, this makes sense.  I have added this as an issue to discuss.

Are you talking about a knob to indicate the role of the device?
What around multi-purpose devices?

>>    5. Add the variables required by RFC 4861, sec. 6.3.2 (config=false

I would suggest using full words ("current", "retransmit").  Otherwise
every modeler will roll their own abbreviation.  Or worse, you end
up with semi-official abbreviations.
 
>>       structures as required by RFC 4861, sec. 5.1.:

Are we reimplementing MIBs?

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 24 Mar 2012 22:07:43 +0100 (CET)

> is completely flexible, and requires no work from the modeler.

I absolutely agree with this.  I do not like putting meta-data leafs
likte "enable" among the data nodes.  FWIW, our implementation also
supports something like the "inactive" mechansim.  (another similar
meta-data thing is "comment" or "annotation", which sometimes show up
among data nodes as a "description" leaf).

However, as it currently stands, there is no standard "inactive"
mechanism.  Thus, we have to resort to "enable" leafs.  The
alternative would be to stall the development of data models and work
on an "inactive" feature.  I don't think this is optimal or realistic.

> I'm assuming you are not really serious here.

The text is in 7.8.5 of 6020:

   The XML elements representing
   list entries MAY be interleaved with other sibling elements, unless
   the list defines RPC input or output parameters.

Note that the precondition to my statement is *if* this is a real
problem.  I don't think it is.

> What around multi-purpose devices?

I think we need this per interface.  See issue ip-07 in my earlier
email.

> Are we reimplementing MIBs?

That's the question... When should we write config false data models?
Do we recommend people to use SNMP/MIBs for stats only and
NETCONF/YANG for config only?  If so, we need to be very clear about
how to map between these two worlds.

/martin