Subject: comments on zeroconf requirements

From: [email-masked]
Date: Wed, 27 Sep 2000 16:07:08 +0200

---------------------- Forwarded by Peter van der Stok/EHV/RESEARCH/PHILIPS on 27-09-2000 16:04 ---------------------------

Peter van der Stok
27-09-2000 15:16
To:	[email-masked]@SMTP 
cc:	Peter van der Stok/EHV/RESEARCH/PHILIPS@EMEA3 
Subject:	comments on zeroconf requirements  
Classification:	Unclassified

Dear all,

This is the first time I contact you from Philips research to comment on the ZeroConf
Requirements document. My comments are coloured by my region of interest: 
home networks.

The document is much improved with respect to former versions I saw elsewhere.
I like the increase in rigour and the motivation of the requirements.

I do have problems with the requirement mentioned at the end of section 1.6:
.... resolve conflicts and state changes in a timely manner

Two questions:
- what is a timely manner
- what are conflicts and state changes and what is their relation?

It may well help to define a view that each participant has on the network.
Each participant knows a set of IP addresses with a host name and a physical address.
One can then define consistency constraints on these views, like

- when host A with IP address aa knows host B with IP address bb 
then also host B with IP address bb knows host A with IP address aa
- The view of host A may contain other hosts than the view of host B
- The hosts that are present in the view of host A and the view of host B
are known by the same IP address, host name and physical address.
- A host, present in the view of a correct host that is connected to a network, 
is correct and connected to the network
-  A correct host connected to a subnet is present in the views of the correct hosts connected
to that subnet

Items like default route and netmask need not be in the view but can be known only locally.
However then a consistency criterium  about hosts in the same subnet must be specified

- Hosts in the same subnets have the same default route and netmask

Once these or other consistency criteria are defined, requirements on time may be put forward.
I expect that different manufacturers wil have attributed different time out values on the time that
resonses are expected from other hosts. So negociation between hosts needs to be possible
to agree on the time span, DT, that views do not satisfy the consistency criteria.

Requirement
- Hosts negotiate the maximum time that the views of the hosts in their view may be
inconsistent

Requirement on inconsistency
- Within DT timeunits after the last modification on the network, all views 
of hosts connected to the network are consistent.

A major problem is the definition of a network. What limits a network? It does not look as if
a given hop count of TTL defines a network properly. In the home there are some natural
boundaries on a network and routers that connect the home network to the outside world can
be easily identified. These routers seem to be the natural boundary and anything that
connects networks within the home is part of one home network. More difficult is the situation that
a WAP telephone tries to look at the devices in the home network. Is the WAP telephone then
part of the network. The telephone certainly needs to know the state of the devices
connected tot the home network. From the former consistency definition that means that
the devices in the home need to know about the WAP phone. 

As last comment I like to react to the process definition.
A process is something active while in the definition it is something static.

I like to modify the definition

process - A process executes the implementation of an algorithm in hardware, software
or a combination of both.

Eventually one may add that it sequentially executes this implementation because later on
the set of processes is defined.

I hope this is a useful contribution to the discussion

Greetings

peter van der Stok

Peter van der Stok                Philips Research Laboratories Eindhoven
Bldg: WL P 311                      Prof. Holstlaan 4
Phone: +31 40 2742649       5656 AA Eindhoven
Fax:       +31 40 274                The Netherlands
Mailto: Peter.van.der.Stok@ philips.com

---

From: Erik Guttman <[email-masked]>
Date: Fri, 29 Sep 2000 16:06:11 +0200 (MET DST)

> .... resolve conflicts and state changes in a timely manner

This is a requirements document, not a protocol specification.  Conflicts
which were never detected or resolved would not be timely.  Conflicts which
were detected and resolved in microseconds would surely be timely.  We have
a shared notion of timeliness (from our experience with DHCP and DNS for
instance). 

The goal is that we state what the issues and priorities are in the 
requirements doc so that we will have criteria for evaluating candidate 
zeroconf protocols for standardization.

> - what are conflicts and state changes and what is their relation?

These are described in various sections.  2.1.2 shows how topology
changes can create conflicts such as duplicate IP addresses.  2.2.2
discusses duplicate names.  Multicast address allocation would also
be a source of conflicts if one address was allocated in distinct
networks and those networks were fused.  I agree it would be useful
to draw out this point.

> A major problem is the definition of a network. What limits a network? 

Why do we need a limiting definition?

draft-ietf-zeroconf-reqts-05.txt says:

   Zeroconf protocols have no specific topological restrictions or 
   requirements; networks may consist of multiple IP subnets or a 
   single IP subnet; networks may be isolated or connected to larger 
   networks (e.g. Internet). However, there is a conditional 
   requirement. The condition exists if a protocol is targeted to     
   operate in multiple IP subnet topologies. The requirement is the 
   protocol MUST be routable. For example, a protocol MUST use IP 
   multicast and not use IP broadcast. 
    
   Requirement: 
   - If a protocol is to operate in multiple IP subnet topologies, 
     the protocol MUST be routable. 

If a zeroconf protocol operates on a single subnet (link-local only)
then it is by definition applicable only to a limited topology.  If
the protocol is not link-local only, it must use a routable protocol.
We are defining requirements for zeroconf protocols without creating 
arbitrary restrictions on them (such as which networks they can and 
cannot be used).  

Thanks for your input,

Erik