Subject: [netmod] draft-ietf-netmod-interfaces-cfg-09 and draft-ietf-netmod-ip-cfg-08

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 6 Feb 2013 18:39:59 +0100

Hi,

Martin has posted two new IDs:

http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-09
http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-08

These documents did already pass WG last call. However, there were some
non-editorial changes (in particular in draft-ietf-netmod-ip-cfg-08)
in order to make use of the types that have been moved to 6021bis. I 
like to ask people to check the changes and to raise any issues they
might have with the changes as soon as possible but not later than
February 12th, 2013.

/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: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 6 Feb 2013 18:51:14 +0100

> might have with the changes as soon as possible but not later than

Speaking as technical contributor, I like to highlight that the new
version disallows zone indexes in IP addresses of interfaces and in
the neighbor tables. This is technically fine since everything is
scoped by an interface, so implicitely the information is always
there. The question is whether this is convenient or the approach
existing systems usually follow. It seems that BSD like systems tend
to show the zone index while Linux like systems tend to hide it,
leaving it to the context information. I do not know about Windows,
maybe Dave Thaler can inform us.

If we allow zone indexes (as we had before), of course the question
comes up whether the canonical representation is without a zone index
or with a zone index for non-global addresses. (This was not specified
before either but frankly should have been.)

I am raising this issue here explicitely since I want that the WG
takes an informed decision about this change.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 11 Feb 2013 13:48:39 +0100

> before either but frankly should have been.)

I think there is no common canonical form that would fit all potential uses of the "ipv[46]-address" type. Depending on the context, the zone index may be superfluous (global addresses), convenient but redundant (as in BSD ifconfig output) or necessary (link-local next hops in routing tables).

On the other hand, I agree that having no canonical form is a problem, because we cannot reliably determine whether two IP addresses are equal or not. For instance, in previous revisions of the "ip-cfg" draft, the following two addresses would have to be treated as different keys of the "ip" list:

fe80::7aac:c0ff:fe88:9494
fe80::7aac:c0ff:fe88:9494%bge1

Lada 

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

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

---

From: Dave Thaler <[email-masked]>
Date: Thu, 21 Feb 2013 22:19:41 +0000

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> university.de]
> Sent: Wednesday, February 6, 2013 9:51 AM
> To: [email-masked]; Dave Thaler
> Subject: Re: draft-ietf-netmod-interfaces-cfg-09 and draft-ietf-netmod-ip-
> cfg-08
> 
> > These documents did already pass WG last call. However, there were
> > some non-editorial changes (in particular in
> > draft-ietf-netmod-ip-cfg-08) in order to make use of the types that
> > have been moved to 6021bis. I like to ask people to check the changes
> > and to raise any issues they might have with the changes as soon as
> > possible but not later than February 12th, 2013.
> >
> 
> Speaking as technical contributor, I like to highlight that the new version
> disallows zone indexes in IP addresses of interfaces and in the neighbor
> tables. This is technically fine since everything is scoped by an interface, so
> implicitely the information is always there. The question is whether this is
> convenient or the approach existing systems usually follow. It seems that
> BSD like systems tend to show the zone index while Linux like systems tend
> to hide it, leaving it to the context information. I do not know about
> Windows, maybe Dave Thaler can inform us.

It is correct to disallow zone indexes in IP addresses that are already scoped
by an interface, and require them in cases that are not scoped to an interface.

When you say "tend to show", I'm not sure if you are referring to command
line tools or something else.  If command line tools and other UI, then on
Windows it varies by command/UI whether the zone id is shown or not.
It's obviously shown in any context that's not scoped to an interface.

Note that zone indexes are properties of an interface, and I'm not seeing
them as interface properties in http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-08

-Dave
 
> If we allow zone indexes (as we had before), of course the question comes
> up whether the canonical representation is without a zone index or with a
> zone index for non-global addresses. (This was not specified before either
> but frankly should have been.)
>
> I am raising this issue here explicitely since I want that the WG takes an
> informed decision about this change.
> 
> /js
> 
> --

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 22 Feb 2013 10:34:29 +0100

> by an interface, and require them in cases that are not scoped to an interface.

So you are saying what we have in draft-ietf-netmod-ip-cfg-08 is
correct. That's useful input.
 
> them as interface properties in http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-08

The relevant information is in the definition of generic interfaces,
see http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-09. We
have an interface/name and an interface/if-index for every interface.
The IP model extends the generic interface model with IP specific
configuration information. So I think we are fine. Or do we need to
add text somewhere to make it clear that people find that information
when they just look at the IP configuration model?

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 22 Feb 2013 14:10:14 +0100 (CET)

Hi,

Juergen Schoenwaelder <[email-masked]> wrote:
> > them as interface properties in
> configuration information. So I think we are fine.

6021 (and bis) says:

         For link-local addresses, the zone index will
         typically be the interface index number or the name of an
         interface. 

First of all it says "typically", which I interpret to mean that it
can also be something else.  Second, it is not clear that the
interface index number is the same as ifIndex (I don't think it is the
same in all implementations), and further, ifIndex has an if-feature. 

So it is not clear what the zone index would be.

But even so, RFC 4007 talks about "link-local scope" and
"interface-local scope".  I assume the "interface-local scope" can be
the interface index, but the link local scope may be something else?

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 22 Feb 2013 14:30:04 +0100

> So it is not clear what the zone index would be.

I think API implementation often accept both a name and a number and
the number typically is the interface index. RFC 4007 says
implementations must support numbers and should support names as
well. In the SMIv2 MIB space, a zone identifier is always a number.
 
> the interface index, but the link local scope may be something else?

With link-local scope, you usually use the interface index/name of the
link to identify the zone.

Are you suggesting that there should be a separate (mandatory?)
zone-id object? Or are you suggesting we should make ifIndex
mandatory?

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 22 Feb 2013 14:36:24 +0100 (CET)

> link to identify the zone.

Isn't the difference between link-local scope and interface-local
scope that there can be more than one interface attached to one link?
Which interface's number would you use as the link zone identifier?

> zone-id object? Or are you suggesting we should make ifIndex

At this point I am not suggesting anything.  I just think it must be
clear what we mean and what we require from an implementation.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 22 Feb 2013 14:49:56 +0100

> Which interface's number would you use as the link zone identifier?

In this case, I assume implementations accept any of them as valid
input to identify the zone. Which one do you use as the canonical
output? No clue, likely no RFC ever talks about this.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 22 Feb 2013 16:45:23 +0100 (CET)

> output? No clue, likely no RFC ever talks about this.

Actually, RFC 4007 indicates that in this case, manual configuration
of the link zones should be used:

   Furthermore, to avoid performing manual configuration in most cases,
   an implementation should, by default, initially assign zone indices
   only as follows:

   o  A unique interface index for each interface.

   o  A unique link index for each interface.

   Then manual configuration would only be necessary for the less common
   cases of nodes with multiple interfaces to a single link or of those
   with interfaces to zones of different (multicast-only) scopes.

/martin

---

From: t.petch <[email-masked]>
Date: Fri, 22 Feb 2013 17:37:34 +0000

----- Original Message -----
From: "Martin Bjorklund" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Friday, February 22, 2013 1:10 PM
> same in all implementations), and further, ifIndex has an if-feature.

Martin,

As Juergen will know well, there were lengthy discussions last year
about zone index and its representation, triggered in part by Brian
Carpenter wanting to include it in a URI and finding that there was
widespread variation in how different systems displayed it and that IPv6
was to some degree incompatible with the URI specification.  The topic
also surfaced in DHCP in address selection.

Throughout this, I think that it was assumed to be synonymous with
ifIndex.

Tom Petch

---

From: Dave Thaler <[email-masked]>
Date: Fri, 22 Feb 2013 20:55:50 +0000

> From: Martin Bjorklund [mailto:[email-masked]]
> Sent: Friday, February 22, 2013 5:10 AM
> To: [email-masked]
> Cc: Dave Thaler; [email-masked]
> Subject: Re: [netmod] draft-ietf-netmod-interfaces-cfg-09 and draft-ietf-
> netmod-ip-cfg-08
> 
> Hi,
> 
> > > Note that zone indexes are properties of an interface, and I'm not
> > > seeing them as interface properties in
> First of all it says "typically", which I interpret to mean that it can also be
> something else.

Correct.

>  Second, it is not clear that the interface index number is the
> same as ifIndex (I don't think it is the same in all implementations), 

Yes interface index number and ifIndex are synonyms.

> and
> further, ifIndex has an if-feature.
> 
> But even so, RFC 4007 talks about "link-local scope" and "interface-local
> scope".  I assume the "interface-local scope" can be the interface index, but
> the link local scope may be something else?

Correct the link scope zone id and the interface index can be different.

-Dave

---

From: Dave Thaler <[email-masked]>
Date: Fri, 22 Feb 2013 20:57:11 +0000

> Sent: Friday, February 22, 2013 5:30 AM
> To: Martin Bjorklund
> > > see http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-09.
> > > We have an interface/name and an interface/if-index for every interface.
> I think API implementation often accept both a name and a number and the
> number typically is the interface index. RFC 4007 says implementations must
> support numbers and should support names as well. In the SMIv2 MIB space,
> a zone identifier is always a number.

Correct.

> With link-local scope, you usually use the interface index/name of the link to
> identify the zone.

Not in general, no.   It's true that "usually" the value of the link scope zone id
and the value of the interface index are the same.   But that's not guaranteed
to be the case and nothing should depend on that being the case.

-Dave

> Are you suggesting that there should be a separate (mandatory?) zone-id
> object? Or are you suggesting we should make ifIndex mandatory?
> 
> /js
> 
> --

---

From: Dave Thaler <[email-masked]>
Date: Fri, 22 Feb 2013 21:10:21 +0000

> Sent: Friday, February 22, 2013 5:50 AM
> To: Martin Bjorklund
> > > > "interface-local scope".  I assume the "interface-local scope" can
> > > > be the interface index, but the link local scope may be something else?
> > >
> > > With link-local scope, you usually use the interface index/name of
> > > the link to identify the zone.
> >

That's correct.

In general, each interface has up to 16 zone ids of which only about 13 are interesting
(reference: RFC 4291 section 2.7, see the list of scope levels for multicast).
Level 1 is interface-local scope for which the zone id == the interface id.
Level 14 = global for which the zone id is not used.
For level 2-13 the zone id can be configurable, and levels 2 (link-local) and
5 (site-local) are the most interesting but for multicast all are relevant and
can be different.   So in terms of IP configuration, on platforms that support
all levels of zone id, then you'd need to be able to configure the zone ids for
levels 2 through 13. 
On Windows, level 2 (link) defaults to the same value as level 1 (i.e. by 
default it assumes every interface is on a separate link) but can be configured otherwise.

> > Which interface's number would you use as the link zone identifier?

Possibly none of them.  The link zone id is a separate numbering space and
need not have any relationship to an interface index.   Common implementations
use the same integer value by default though.

So in short: whatever number is configured.

> In this case, I assume implementations accept any of them as valid input to
> identify the zone. Which one do you use as the canonical output? No clue,
> likely no RFC ever talks about this.

No, an interface index identifies an interface, not a link scope zone.
A link scope zone id identifies a link scope zone.

Some APIs on some platforms might allow constraining the use of a destination
address to a smaller set of interfaces than it would be valid on.   A common case
is sending to a global address (for which all interfaces are in the same
global zone) via a specific local interface.   I'm not aware of a platform that
allows this more generally though (i.e. constraining to something other than 
the zone full index or a single interface).

But it would be incorrect to ever grab an interface index and simply assume
that's the right scope id to use with an address.

-Dave

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 25 Feb 2013 22:03:57 +0100

[...]

My conclusion from this exchange is that what we have in
draft-ietf-netmod-ip-cfg-08 appears to be correct. I do not think
there is a need to provide a standard way to configure zones and
zone-ids at this point in time - I rather like to get these document
out of the door so that we get implementation experience.

If someone has a different conclusions, speak up now.

/js