Subject: [netmod] LL review of draft-bjorklund-netmod-ip-cfg-00

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 21 Jul 2011 10:59:46 +0200

This module contains only a very basic configuration of IP
interfaces - IPv4 and IPv6 addresses and masks. It think this scope is
appropriate because it is important to publish this module soon.

The data are organized in two separate containers, one for IPv4 and
another for IPv6. This is IMO better than the alternatives, e.g. using
the union type

  list ip-address {
    key "ip";
    leaf ip {
      type inet:ip-address;
    }
  }

because in the latter case it is difficult to discriminate between IPv4 and
IPv6 addresses without parsing them.

The chosen organization won't be particularly handy in situations
where a reference to a configured IP address is needed, no matter
whether it is IPv4 or IPv6. An explicit 'choice' would be necessary in
this case - a single 'leafref' type cannot be used because its 'path'
cannot point to the two different locations.

Other comments:

1. The leaf name "prefix-length" is misleading, I suggest to change it
   to "netmask-length".

2. Typo "familiy" appears in two places.

Lada

--
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Jul 2011 11:14:14 +0200

> 1. The leaf name "prefix-length" is misleading, I suggest to change it

I fail to see why "prefix-length" would be misleading.

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 21 Jul 2011 11:42:24 +0200

> I fail to see why "prefix-length" would be misleading.

Because an IP prefix is often understood, e.g. in the routing context, as a block of addresses. What's defined here is a single IP address and a netmask that specifies its net and host bits.

Lada

--
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Jul 2011 12:00:18 +0200

> Because an IP prefix is often understood, e.g. in the routing context, as a block of addresses. What's defined here is a single IP address and a netmask that specifies its net and host bits.

Your proposal 'netmask-length' does not make sense to me since the
length of the netmask is a constant. 

The OSes I tend to use show the configured IP addresses in CIDR prefix
notations. This is surely true for IPv6 addresses but newer tools like
'ip addr' on Linux do this consistently also for IPv4 addresses.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 21 Jul 2011 12:27:13 +0200

> length of the netmask is a constant.

That's true, but so is prefix-length for a single unique address.

> 'ip addr' on Linux do this consistently also for IPv4 addresses.

I know, and for example JUNOS documentation even talks about "destination prefix", which is IMO a sheer nonsense:

"You can configure router or switch interfaces with a 32-bit IP version 4 (IPv4) address and optionally with a destination prefix, sometimes called a subnet mask."

Lada

--
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Jul 2011 12:34:39 +0200

> That's true, but so is prefix-length for a single unique address.

And that is why the prefix-length appears together with an address. I
miss your point. My point was that a netmask for IPv4 is always 32
bits and hence the term netmask-length is somewhat pointless if you
take it literally.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 21 Jul 2011 13:14:22 +0200

> bits and hence the term netmask-length is somewhat pointless if you

Agreed, but I have no better suggestion except the traditional

<netmask>255.255.255.0</netmask>

which has its share of problems from YANG point of view.

My point just is that there is a difference between IP prefix as an address aggregate on one hand (as it is used in CIDR) and interface address + netmask on the other.

Lada

--
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Jul 2011 13:40:14 +0200

On Thu, Jul 21, 2011 at 01:14:22PM +0200, Ladislav Lhotka wrote:

> My point just is that there is a difference between IP prefix as an
> address aggregate on one hand (as it is used in CIDR) and interface
> address + netmask on the other.

And the difference is? Are you saying ifconfig on Linux and MacOS for
IPv6 got it wrong? Is 'ip addr' on Linux wrong? Or is there a
fundamental difference here between IPv4 and IPv6 that I am missing?

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 21 Jul 2011 14:22:13 +0200

> fundamental difference here between IPv4 and IPv6 that I am missing?

RFC 2373 says this:

   When writing both a node address and a prefix of that node address
   (e.g., the node's subnet prefix), the two can combined as follows:

      the node address      12AB:0:0:CD30:123:4567:89AB:CDEF
      and its subnet number 12AB:0:0:CD30::/60

      can be abbreviated as 12AB:0:0:CD30:123:4567:89AB:CDEF/60

So how about "subnet-prefix-length" (for both IPv4 and IPv6)?

Lada

--
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Jul 2011 14:26:25 +0200

> So how about "subnet-prefix-length" (for both IPv4 and IPv6)?

Not sure what this would fix except making things more verbose. Is
there any OS out there using this?

/js

---

From: Phil Shafer <[email-masked]>
Date: Thu, 21 Jul 2011 09:54:29 -0400

>So how about "subnet-prefix-length" (for both IPv4 and IPv6)?

"prefix-length" is the common term and the one we should be using.

Another issue is non-contiguous netmasks, where an operator
may do multi-path filtering using the lower bits of the
prefix.

http://www.tcpipguide.com/free/t_IPSubnetMasksNotationandSubnetCalculations-4.htm

In JUNOS, we put prefix length with the address in the traditional
notation "a.b.c.d/e", where e is 0..32 and allow non-contiguous
netmasks as "a.b.c.d/f.g.h.i".

http://www.juniper.net/techpubs/software/junos/junos70/swconfig70-policy/html/firewall-config12.html

Non-contiguous netmasks may not be common, but you'll need to include
them in your model.  That said, the having to specify the bits in
a netmask like <netmask>255.255.242.0</netmask> is both painful and
a common source of errors.  <prefix>172.25.128.0/21</prefix> and
<address>172.25.128.1/21</address> are much easier.

Yes, I see the benefit from making them two distinct fields, but the
annoyance factor overwhelms that benefit.

Thanks,
 Phil

---

From: "t.petch" <[email-masked]>
Date: Fri, 22 Jul 2011 18:31:59 +0200

----- Original Message -----
From: "Phil Shafer" <[email-masked]>
To: "Ladislav Lhotka" <[email-masked]>
Cc: "NETMOD Working Group" <[email-masked]>
Sent: Thursday, July 21, 2011 3:54 PM

> "prefix-length" is the common term and the one we should be using.

I agree.

> may do multi-path filtering using the lower bits of the
http://www.tcpipguide.com/free/t_IPSubnetMasksNotationandSubnetCalculations-4.ht
m
> netmasks as "a.b.c.d/f.g.h.i".
http://www.juniper.net/techpubs/software/junos/junos70/swconfig70-policy/html/fi
rewall-config12.html
> <address>172.25.128.1/21</address> are much easier.

Ouch; I disagree.  I have come across non-contiguous netmasks invariably
created by accident and boy, were they a nightmare to track down and put right.
I have not checked what the standards say but my recollection is that they are
taboo.  (I would say suicidal).

Tom Petch

---

From: Phil Shafer <[email-masked]>
Date: Fri, 22 Jul 2011 13:35:03 -0400

>taboo.  (I would say suicidal).

Suicidal or not, customers use them on both our gear and that other router
company's gear.  We had to implement to allow customers to upgrade to our
boxes, so I know that they are in use and quite intentional.  OSPF doesn't
like this, but it's definitely out there.

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 22 Jul 2011 20:07:57 +0200 (CEST)

> like this, but it's definitely out there.

So the question is if it is worth standardizing, or if a
vendor-specific augmentation will do it?

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 22 Jul 2011 20:22:36 +0200

> vendor-specific augmentation will do it?

Some standards-track MIB modules will not work with non-contiguous
netmasks. I think this was discussed when the IP-FORWARD-MIB was
revised and IP folks told us that nobody does this. Of course, the
real deployed world might be more ugly than what people believe it is
but perhaps this is just legacy uglyness? Out of curiosity, does
anybody know _why_ people do this?

/js

---

From: Phil Shafer <[email-masked]>
Date: Fri, 22 Jul 2011 14:39:39 -0400

Juergen Schoenwaelder writes:
>Out of curiosity, does

Poor mans multi-path: Make 1/2 your prefixes go out one interface
and 1/2 out the other.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Fri, 22 Jul 2011 14:43:33 -0400

>vendor-specific augmentation will do it?

Or is the question whether we want to model ipv4 address as they
work .vs. model the subset of how we want them to work?  I'd hate
to tell an operator that we can't handle their network because they
use IP netmasks in a way the WG didn't like.

Thanks,
 Phil

---

From: [email-masked]
Date: Sat, 23 Jul 2011 12:23:27 +0200

> like this, but it's definitely out there.

Also, Phil's employer uses "primary" tag for the address that will be  
used as source address, while the other router company uses  
"secondary" to mean the opposite. I think the module should offer this  
flag, too.

Lada

---

From: "t.petch" <[email-masked]>
Date: Sat, 23 Jul 2011 12:34:29 +0200

----- Original Message -----
From: "Martin Bjorklund" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Friday, July 22, 2011 8:07 PM
> vendor-specific augmentation will do it?

vendor-specific:-)

I will look for the statements that I think exist in standards-track protocol
RFC about them.  As Juergen says, MIB modules do not support it and I believe
that that reflects the underlying protocol but I will look some more.

Tom Petch

---

From: Phil Shafer <[email-masked]>
Date: Sat, 23 Jul 2011 22:25:19 -0400

>"secondary" to mean the opposite. I think the module should offer this  

Worse:  there's the idea of a primary interface for packets
going out an interface, and the idea of an address for the
entire box.  So we have the "preferred" and "primary" flags.

Configuration is fun until you get to the dirty little details.

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 25 Jul 2011 17:41:49 -0400 (EDT)

> entire box.  So we have the "preferred" and "primary" flags.

Could you suggest some 'description' text for such leafs?

/martin

---

From: Yoshifumi Atarashi <[email-masked]>
Date: Tue, 26 Jul 2011 16:33:04 -0400

IPv4 is ordinary one i/f, one address.
But IPv6 is one i/f, one Link Local Address and multiple addresses.

So I wonder if IPv6 address list is down below.

- IPv6 Link Local address
- IPv6 address[1]
- IPv6 address[2]
- IPv6 address[3]
.......
- IPv6 address[n]

------
  Yoshifumi Atarashi

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 26 Jul 2011 22:50:36 +0200

> - IPv6 Link Local address

The ipv4 and the ipv6 containers in draft-bjorklund-netmod-ip-cfg
each contain a list of IP addresses.

/js

---

From: Yoshifumi Atarashi <[email-masked]>
Date: Tue, 26 Jul 2011 16:59:02 -0400

I missed to read address list to address.
But my point is Link Local Address, GLA, ULA separate class in IPv6.
   Yoshifumi Atarashi

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 26 Jul 2011 23:46:26 +0200

> But my point is Link Local Address, GLA, ULA separate class in IPv6.

Please elaborate, I do not understand your question.

/js

---

From: Yoshifumi Atarashi <[email-masked]>
Date: Tue, 26 Jul 2011 18:12:29 -0400

IPv6 address is 3 kinds and more in address architecture document.
Each i/f automatically assign one Link Local Address ( fe80:: ......).
By auto/manual configure, Global Unique Address(GUA) add.
Sometimes, operators use to add Unique Local Address(ULA).
IPv6 spec can use multiple GUA.
LLA, GUA, ULA are different to use.
Operators recognize and operate which address kind.
So I  think GUA, LLA, ULA class in netmod ip cfg.

    Yoshifumi Atarashi

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 27 Jul 2011 00:18:08 +0200

> So I  think GUA, LLA, ULA class in netmod ip cfg.

Perhaps it helps if you can point out what you believe is missing.

Note also that the focus of this document is configuration, some of
the address classes won't normally be part of configuration (but then
the document does not preclude this).

/js

---

From: Yoshifumi Atarashi <[email-masked]>
Date: Wed, 27 Jul 2011 06:29:06 -0400

I understand you have no experience of IPv6 operation, don't you?
I suggest that you have to add Link Local Address.
Because Link Local Address is special.
When some WAN router and data center operators want to change
Link Local Address, they used -i option, % descriptor and so on
for Link Local Address indication.
This is from my long time IPv6 experience.
I was one of management member of KAME project....
   Yoshifumi Atarashi

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 27 Jul 2011 08:06:43 -0400

> I was one of management member of KAME project....

So could you please specify the necessary changes to the existing data model, as Juergen suggested?

Thanks, Lada

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

--
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 27 Jul 2011 14:12:10 +0200

> I understand you have no experience of IPv6 operation, don't you?

Just about 10 years...

> for Link Local Address indication.

I would have helped if you would have asked "are zone identifiers for
link local addresses covered?" And then my answer would have been "yes,
see RFC 6021 for the definition of an ipv6-address".

/js

---

From: Yoshifumi Atarashi <[email-masked]>
Date: Wed, 27 Jul 2011 09:20:52 -0400

I read RFC 6021.
Generally, IPv6-address definition is no problem.
But in only ip config and i/f case, I want to add Link Local Address
separately.
Because i/f depends on description of Link Local Address. It is special
case.
 -----
     Yoshifumi Atarashi

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 27 Jul 2011 15:35:09 +0200

On Wed, Jul 27, 2011 at 09:20:52AM -0400, Yoshifumi Atarashi wrote:
> I read RFC 6021.
> Generally, IPv6-address definition is no problem.  But in only ip
> config and i/f case, I want to add Link Local Address separately.
> Because i/f depends on description of Link Local Address. It is
> special case.

What does "I want to add Link Local Address separately" mean?
Anyway, on Linux, ipaddr does not seem to make any distinction
whether you configure a global or link-local address.

/js

---

From: Yoshifumi Atarashi <[email-masked]>
Date: Wed, 27 Jul 2011 09:46:27 -0400

I know Linux and BSD implementation.
They are automatically assign Link Local Address by i/f.
But WAN router operator configure another Link Local Address overwrite
MAC based Link Local Address for routing protocols.
So I think IP config model define  Link Local Address separately IPv6
address.
   Yoshifumi Atarashi

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 27 Jul 2011 15:52:45 +0200

> They are automatically assign Link Local Address by i/f.

Yes, but that is outside the scope of the configuration model and not
the point of the discussion (I thought).

> But WAN router operator configure another Link Local Address
> overwrite MAC based Link Local Address for routing protocols.  So I
> think IP config model define Link Local Address separately IPv6
> address.

I just configured a second link local address manually on my Linux box
and there was really no difference compared to configuring a global
address as far as the command line interface is concerned.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 27 Jul 2011 09:57:36 -0400

> So I think IP config model define  Link Local Address separately IPv6

Link-local addresses are easily recognizable, so I don't see any need for them to carry any tag or something. Additional link-local addresses can be configured using the current data model.

The only case that might not be covered is if an operator doesn't want the LL address that is normally assigned automatically to each interface. This could be achieved by a boolean leaf, e.g. 'automatic-link-local-address', with a default value of "true".

Lada

--
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 27 Jul 2011 16:05:50 +0200

On Wed, Jul 27, 2011 at 09:57:36AM -0400, Ladislav Lhotka wrote:
 
> The only case that might not be covered is if an operator doesn't
> want the LL address that is normally assigned automatically to each
> interface. This could be achieved by a boolean leaf,
> e.g. 'automatic-link-local-address', with a default value of "true".

Yes, there will be a number of such knobs needed for IPv6 interfaces
to control various functions of the IPv6 implementation. But yes,
tagging addresses that are already tagged seems pointless.

/js

---

From: Phil Shafer <[email-masked]>
Date: Fri, 29 Jul 2011 09:38:18 -0400

>Could you suggest some 'description' text for such leafs?

Check out:

http://www.juniper.net/techpubs/en_US/junos9.5/information-products/topic-collections/config-guide-network-interfaces/interfaces-configuring-default-primary-and-preferred-addresses-and-interfaces.html

http://books.google.com/books?id=JUJ-zPDayd4C&pg=PT232&lpg=PT232&dq=junos+primary+preferred+interface&source=bl&ots=ePQwE22qTa&sig=uw5TUnBSwBKRgJztnHbmioxDWiU&hl=en&ei=ur0yTpG1HMLYgAfe5b2uCg&sa=X&oi=book_result&ct=result&resnum=4&ved=0CCwQ6AEwAw#v=onepage&q=junos%20primary%20preferred%20interface&f=false

Thanks,
 Phil