Subject: [netmod] review of ip draft

From: Martin Bjorklund <[email-masked]>
Date: Thu, 02 Aug 2012 16:00:15 -0700 (PDT)

Hi,

I got the following comments from an off-line reviewer, called ps
below.

ps> feature "non-contiguous-netmasks" should be called 
ps> "ipv4-non-contiguous-netmasks", since it is ipv4-specific.

I think this make sense.

ps> container ipv4 and ipv6 should be presence containers, since
ps> otherwise both ipv4 and ipv6 are enabled by default.

This is an important point.  The question to the WG is if
these address families should be enabled by default or not.  I think
this was discussed at some point, but I cannot find this in the
archives now.

ps> list "neighbor" should be called "static-address-map"

I do not have a strong preference; I used "neighbor" b/c it is called
Neighbor Cache in ipv6.  "static-address-map" might be a better name
if we want to augment it with (static) proxy arp entries in some
future...  Comments from the WG?

ps> since RFC 4941 is optional to implement, we should add a feature
ps> and use if-feature in the leafs from this rfc.

I think this makes sense, and propose:

  feature ipv6-privacy-autoconf {
    description
      "Indicates support for Privacy Extensions for Stateless Address
       Autoconfiguration in IPv6.";
    reference
      "RFC 4941: Privacy Extensions for Stateless Address
                 Autoconfiguration in IPv6";
  }

ps> the leafs "create-global-addresses" and "create-temporary-address"
ps> should be named in singular.

My reading of RFC 4862 is that there can actually be multiple global
(and thus temporary) addresses per interface.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 3 Aug 2012 01:37:24 +0200

> ps> "ipv4-non-contiguous-netmasks", since it is ipv4-specific.

ack
 
> this was discussed at some point, but I cannot find this in the

Now that we are sunsetting ipv4... ;-) I think there are enabled leafs
so I think the question boils down to whether the default is true or
false and not whether we need presence containers. That said, I assume
either both true or both false are the options we really have. What is
the concern with the both true defaults?

> future...  Comments from the WG?

Well, if we call it _static_-address-map, then we will not be able to
use these definitions for operational state. I personally think
'neighbor' is just fine.

>                  Autoconfiguration in IPv6";

Makese sense. 

> (and thus temporary) addresses per interface.

I agree, plural seems to be correct here.

/js (speaking as contributor)

-- 
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/>

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 24 Aug 2012 15:59:31 +0200 (CEST)

Hi,

I have one open issue on the ip config draft:

> the concern with the both true defaults?

So, currently we have:

  container ipv4 {   // ditto for ipv6
    leaf enabled {
      default "true";
      ...
    }
  }

The proposal is to change this into:

  container ipv4 {   // ditto for ipv6
    presence "...";
    leaf enabled {
      default "true";
      ...
    }
  }

Without the presence statement, both ipv4 and ipv6 are enabled by
default.  Explicit config is needed to disable it.

With the proposal to add presence statement, ipv4 & ipv6 are disabled
by default.  Explicit creation of the "ipv4" or "ipv6" container is
needed in order to enable ipv4 and ipv6.

Comments?

/martin

---

From: Phil Shafer <[email-masked]>
Date: Fri, 24 Aug 2012 11:19:19 -0400

>needed in order to enable ipv4 and ipv6.

+1.  Because:

- Nothing should be enabled by default.
- Most interfaces will run one of [46] or the other, and having to
  explicitly disable one is tacky/noisy.
- If you really believe that v4 is sunsetting, then making it require
  explicit unconfiguring is a "forever" requirement.
- It's a bad precedent for other protocols (mpls, etc).
- Since addressing information is needed anyway, adding the
  presence container is automatic and natural.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Fri, 24 Aug 2012 09:43:49 -0700

>   presence container is automatic and natural.

All very fine, but come up with a better presence
statement than "...".  If an empty ipv4 container
means that IPv4 is enabled, then what does this mean:

   <ipv4>
      <enabled>false</enabled>
   </ipv4>

It means the config sub-tree is a place-holder and IPv4
is not really enabled. The text has to clarify the 2 'enable'
mechanisms.

>  Phil

Andy

---

From: David Spakes <[email-masked]>
Date: Fri, 24 Aug 2012 13:01:55 -0400 (EDT)

> is not really enabled. The text has to clarify the 2 'enable'

Having two mechanisms makes perfect sense to me, but possibly with a
different semantic than what has been proposed.

  - A computer system may or may not have an IPv4 stack (presence).

  - If the IPv4 stack is present, then it may be enabled or disabled
    (leaf enabled with possible values true and false).

Hence, if this is returned in response to a get-config,

    <ipv4>
       <enabled>false</enabled>
    </ipv4>

it means that the system does possess an IPv4 stack and it is currently
disabled.

If the response to a get-config does not include a section for <ipv4>,
then it means that there is no IPv4 stack present in the computer system.

-dss

-------------------------------------------------------------
 David Spakes                       email:   [email-masked]
 SNMP Research                      voice:   +1 865 573 1434
 3001 Kimberlin Heights Road          fax:   +1 865 573 9197
 Knoxville, TN  37920-9716  USA      http://www.snmp.com
-------------------------------------------------------------

---

From: Andy Bierman <[email-masked]>
Date: Fri, 24 Aug 2012 10:24:51 -0700

> then it means that there is no IPv4 stack present in the computer system.

The client creates the P-container, not the server.
Perhaps on some systems creating this container
will cause the IPv4 code to be loaded into the system,
but on most systems the code will be there, just disabled.
If not supported the server will reject the create request
on the ipv4 container.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 24 Aug 2012 21:38:27 +0200 (CEST)

>   presence container is automatic and natural.

An alternative is to simply make the "enabled" leaf have "false" as
default value.  With "ipv4" being a P-container, what exactly is the
meaning of its presence?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 24 Aug 2012 13:05:54 -0700

> default value.  With "ipv4" being a P-container, what exactly is the

duh! +1

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 25 Aug 2012 12:22:56 +0200

> default value.  With "ipv4" being a P-container, what exactly is the

Its *absence* means that no configuration within that container is ever seen, no matter what the with-defaults mode. If <ipv6> is a non-presence container and <enabled> defaults to "false", then a client with no interest in IPv6 would still get the following data for every interface in the "report-all" mode:

<ipv6>
  <enabled>false</enabled>
  <ip-forwarding>false</ip-forwarding>
  <dup-addr-detect-transmits>1</dup-addr-detect-transmits>
  <autoconf>
    <create-global-addresses>true</create-global-addresses>
    <create-temporary-addresses>false</create-temporary-addresses>
    <temporary-valid-lifetime>604800</temporary-valid-lifetime>
    <temporary-preferred-lifetime>86400</temporary-preferred-lifetime>
  </autoconf>
</ipv6>

So I am in favour of making <ipv4> and <ipv6> P-containers, and making the same in other places in the core models where appropriate.

Lada

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

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

---

From: Andy Bierman <[email-masked]>
Date: Sat, 25 Aug 2012 07:42:39 -0700

> Its *absence* means that no configuration within that container is ever seen, no matter what the with-defaults mode. If <ipv6> is a non-presence container and <enabled> defaults to "false", then a…

The difference between an NP container and a P container is that
an empty P container has some semantic meaning within the
data model and an NP container does not.  So what does an
empty ipv4 container mean?

>     <temporary-preferred-lifetime>86400</temporary-preferred-lifetime>

This is no big deal -- the client has to explicitly request with-defaults,
and getting back 6 default leafs in this case is the intended behavior.

> So I am in favour of making <ipv4> and <ipv6> P-containers, and making the same in other places in the core models where appropriate.

But what is the meaning of an empty P container in each case?

"protocol enabled"?  There is an 'enabled' leaf for that.
 "code is present"?  The client creates a P container, not the server

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 25 Aug 2012 18:29:44 +0200

> empty ipv4 container mean?

It means that the default contents defined under <ipv4> are present.

> and getting back 6 default leafs in this case is the intended behaviour.

Yes, but for each interface. The presence of defaults may also affect XPath expressions. 

> "protocol enabled"?  There is an 'enabled' leaf for that.

This depends on the default value for "enabled".

> "code is present"?  The client creates a P container, not the server

Sure.

Lada

---

From: Phil Shafer <[email-masked]>
Date: Mon, 27 Aug 2012 10:12:25 -0400

>default value.  With "ipv4" being a P-container, what exactly is the

Giving a box an IP address turns on ip by default.  This seems
like a natural fit.  One can disable it if needed, but the
normal case is trivial.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Mon, 27 Aug 2012 07:45:27 -0700

> like a natural fit.  One can disable it if needed, but the

Is this universal, or just Junos?
So should the 'enabled' leaf be removed?
What needs to change in the YANG modules?

IMO, we need a generic mechanism for disabling config,
not a bunch of 'enabled' leafs all over the place.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 27 Aug 2012 17:07:03 +0200

> What needs to change in the YANG modules?

It find it kind of useful to disable some function leaving the config
in place. Having to remove all config to disable something means more
work to enable it again. The presence container would be complementary
for those situations where there is a function I really do not care at
all about. It would make any noise related to it disappear.
 
> not a bunch of 'enabled' leafs all over the place.

These enabled leafs is what we have today and there is value in getting
implementable data models out at some hopefully close point in time.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 27 Aug 2012 17:07:23 +0200

> What needs to change in the YANG modules?

I think it should suffice to add "presence" to the container definition and keep the "true" default for "enabled".
Then:
1. The protocol is disabled and no configuration data are present unless the client creates the corresponding container (descendant defaults are inactive).
2. If the container is created, the protocol becomes enabled and all the defaults are activated.
3. The client can disable the protocol but keep the configuration by setting "enabled" to "false".

> not a bunch of 'enabled' leafs all over the place.

A universal XML attribute, such as

<ipv4 yang:enabled="false">

would fit this purpose quite nicely.

Lada

---

From: Phil Shafer <[email-masked]>
Date: Mon, 27 Aug 2012 11:04:13 -0400

>Is this universal, or just Junos?

This is how JUNOS works.  There's a "disable" leaf but we work hard
to avoid "noise" in the configuration data, so we avoid having an
explicit "enable".  You just assign an address and the protocol is
turned on ("set interface fe-0/0/0.0 family inet address 10.1.2.3/24").

>So should the 'enabled' leaf be removed?

We "hide" it in JUNOS (from the CLI user), but still have it since
it may be needed for overriding our inheritance model (where you
can disable some interfaces in a config group and then explicitly
enable them in the main config).

None of which is interesting to netmod, but gives some background
into our choices in JUNOS.

>not a bunch of 'enabled' leafs all over the place.

In JUNOS, we made this happen as a generic attribute of configuration
data.  If you mark a node as "inactive" is remains in the config
data, but is ignored, essentially commenting it out while retaining
it in place.  In the CLI, this is rendered with an "inactive:" tag.
See below.....

Thanks,
 Phil

-----------
In this example, the interface has multiple addresses, one of which
has been deactivated:

[edit]
phil@dent# show 
## Last changed: 2012-08-27 12:12:02 EDT
interfaces {
    fe-0/0/0 {
        unit 0 {
            family inet {
                address 10.1.2.3/24;
                inactive: address 10.4.5.6/24;
                address 10.7.8.9/24;
            }
        }
    }
}

[edit]
phil@dent# show | display xml 
<rpc-reply xmlns:junos="http://xml.juniper.net/junos/11.4I0/junos">
    <configuration junos:changed-seconds="1346083922" junos:changed-localtime="2012-08-27 12:12:02 EDT">
            <interfaces>
                <interface>
                    <name>fe-0/0/0</name>
                    <unit>
                        <name>0</name>
                        <family>
                            <inet>
                                <address>
                                    <name>10.1.2.3/24</name>
                                </address>
                                <address inactive="inactive">
                                    <name>10.4.5.6/24</name>
                                </address>
                                <address>
                                    <name>10.7.8.9/24</name>
                                </address>
                            </inet>
                        </family>
                    </unit>
                </interface>
            </interfaces>
    </configuration>
</rpc-reply>

[edit]
phil@dent#

---

From: David Kessens <[email-masked]>
Date: Mon, 27 Aug 2012 12:44:34 -0700

Phil,

> like a natural fit.  One can disable it if needed, but the

How about not configuring an IP address but enabling accepting route
advertisements ? How about link local addresses ?

David Kessens
---

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 27 Aug 2012 23:07:18 +0200 (CEST)

Phil Shafer <[email-masked]> wrote:
> it in place.

This is a great feature, and we have something similar.  We also have
user-defined comments as such meta-data.

This makes it possible for users to disable and comment any part of
the config, without the data model designer adding leafs such as
"enabled" and "comment" or "description".   Unfortunately, as long as
this is not part of the standard "meta model", we have to add such
leafs in our data models...

/martin

---

From: Phil Shafer <[email-masked]>
Date: Mon, 27 Aug 2012 17:57:52 -0400

>advertisements ? How about link local addresses ?

We require at address for the former and the latter requires
other interface-related config, so the v4 or v6 container
would have to exist.

Thanks,
 Phil

---

From: David Kessens <[email-masked]>
Date: Mon, 27 Aug 2012 16:20:33 -0700

Phil,

> other interface-related config, so the v4 or v6 container

Can you be more specific for the latter:

I thought the "other interface-related config" was enabling ipv6 on the
interface.

David Kessens
---

---

From: Phil Shafer <[email-masked]>
Date: Mon, 27 Aug 2012 23:16:24 -0400

>I thought the "other interface-related config" was enabling ipv6 on the

My bad.  Just turning on v6 ("set interfaces xxx family inet6") is
sufficient to enable v6 and link local addresses.  I was thinking
that it was a flag on the address, but it's not.  So for JUNOS, inet6
is already a P container.  Strictly speaking, so is v4 ("family inet"),
but I don't think anything interesting happens without either an
address or the "unnumbered-interface" flag.

Thanks,
 Phil