Subject: Re: IETF 51 ZEROCONF Minutes

From: Stuart Cheshire <[email-masked]>
Date: Tue, 11 Sep 2001 01:12:41 -0700

>surely you will admit that there are scaling problems with appletalk
>that impact its reliability for ethernets with large #s of hosts?

For three years at Apple I was on a switched Ethernet with 1016 available 
AppleTalk addresses and about 1000 hosts. Watching the network with 
EtherPeek I saw it often took a host 50-100 tries to find an unused 
address. This process could take dozens of milliseconds. I don't 
recommend overloading a network to this extent, but to say it was 
unreliable is incorrect. Once a host found an unused AppleTalk address, 
it kept it, and defended it, and we never had any reliability problems 
caused by hosts trampling on each other's AppleTalk addresses.

>the point is that these link-local addresses aren't intended
>to be used directly - you need to use this mechanism in conjunction
>with some kind of service discovery mechanism.

Isn't this true of all addresses? What kinds of addresses *are* intended 
to be used directly, without use of DNS or SAP or some other kind of 
naming or discovery protocol?

I understand why at first glance self-assigned link-local addresses seem 
very weird and alien, because you don't know from one day to the next 
what IP address your machine may have, but for most users, exactly the 
same is true of DHCP addresses.

Can you suggest specific wording?

If we say, "Link-local addresses require some kind of naming protocol," 
then that is too vague and invites more questions than it answers.

If we say, "Link-local addresses require Multicast DNS," then that looks 
like a normative reference to other work that it not yet close to 
standardization.

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer
 * Chairman, IETF ZEROCONF
 * www.stuartcheshire.org

---

From: Keith Moore <[email-masked]>
Date: Tue, 11 Sep 2001 09:46:53 -0400

> caused by hosts trampling on each other's AppleTalk addresses.

Having an indication of expected scaling limits helps a lot.  I've
seen a single bridged ethernet supporting several thousand hosts.
(yes, there were a few problems...)

> naming or discovery protocol?

IP addresses are intended to be used directly.   DNS is optional.
Many applications expect IP addresses to be stable for weeks or more and 
not to be changed on a whim.

(In my day job I work with large scale distributed systems and Grid 
computing systems, so I see these every day.  It's a different 
perspective than that of a user who thinks of the 'net as the web and 
email and ICQ.)

> same is true of DHCP addresses.

I don't know what you mean by "most" users, and even if true, it's not
necessarily a good idea to take conditions that exist for "most" users
at the present time and say that they're right for "all" users for the 
future of the Internet.  DHCP can be used to assign long-term addresses -
just keep renewing the same lease.  The fact that it's often used differently
just reflects the current fashion to have most machines as "clients" that 
only initiate connections.  This may change in the future, and there are 
many valuable applications that employ large numbers of hosts and expect 
their addresses to be stable.

> like a normative reference to other work that it not yet close to

I think a paragraph somewhere as part of an introduction could say that
link-local addresses are expected to be used along with some sort of
name lookup scheme that works in ad hoc networks, which is TBD,
would suffice.  That way, it's not a normative reference.

From the point of view of a reader who hasn't been participating in the
zeroconf group, I think it makes more sense to give a vague explanation
than to give no explanation.

Keith

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 11 Sep 2001 07:21:38 -0700 (PDT)

> then that is too vague and invites more questions than it answers.

Linklocal addressing is no different than DHCP assignment with respect to
naming. RFC 2131 doesn't make any statements about naming; neither should
this specification. 

> like a normative reference to other work that it not yet close to 

I see no reason for this specification to include any references to mDNS,
normative or not.

---

From: Keith Moore <[email-masked]>
Date: Tue, 11 Sep 2001 10:42:50 -0400

> Most servers run with static addresses, and don't use DHCP. For similar
> reasons, I would expect that those servers will not want to serve clients
> using a linklocal address.

right, but one of the justifications for linklocal addresses is to support
plug-and-play appliances, and any $49 printer is a server.

Keith

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 11 Sep 2001 07:26:18 -0700 (PDT)

---

From: Keith Moore <[email-masked]>
Date: Tue, 11 Sep 2001 12:11:48 -0400

> naming. RFC 2131 doesn't make any statements about naming; neither should

I disagree, because 

- DHCP has different applicability than link-local addressing, 
- DHCP can be used as a means to assign stable addresses to hosts 
  that need them,
- the very environment which justifies creation of linklocal addresses 
  makes traditional DNS name lookup problematic
- even if this were a shortcoming in the DHCP specification (and I think
  there are some shortcomings there), this would not justify a shortcoming
  in the linklocal address specification.
 
> I see no reason for this specification to include any references to mDNS,

I don't see a need for a reference to any specific technology, only 
some background information to supply context to the reader.

I think folks are making too big a deal about this.  Most of what
I'm asking for are simple clarifications to the text, rather than 
changes to the protocol. They're not things that should delay the 
document by any significant amount of time.

Keith

---

From: Aidan Williams <[email-masked]>
Date: Wed, 12 Sep 2001 10:32:21 +1000

> using a linklocal address.

Well..  I have a "server" which gets an address from a pool via DHCP,
from my ISP.  This address, although dynamic, is quite stable.

I see no reason why a link-local address could not be stable in
a similar kind of way.

regards
	aidan
____
:wq!

---

From: Aidan Williams <[email-masked]>
Date: Wed, 12 Sep 2001 10:19:19 +1000

> would suffice.  That way, it's not a normative reference.

This would be good material for the host profile document
  http://www.ietf.org/internet-drafts/draft-ietf-zeroconf-host-prof-01.txt
rather than the IPv4 link-local draft.

- aidan