RE: zeroconf draft

[Pekka Savola <pekkas@netcore.fi>]

On Tue, 24 Aug 2004, Soininen Jonne (Nokia-NET/Helsinki) wrote:
> > Initially, it was thought that 3GPP scenarios would have been suitably
> > addressed by the simple mode of the assisted tunneling, but you guys
> > felt it was better to have a separate document; that's fine, it seems
> > to me that such a document should include all the related, similar
> > scenarios.
> 
> This, of course, has been a sticky point from the beginning. There seems
> to be two schools of thought: One saying that assisted tunneling's
> simple mode would fit the 3GPP scenarios. The other is saying that
> assisted simple mode does not fit the requirements of 3GPP. Thus, an
> additional document was decided to be created to see if the requirements
> are the same instead of artificially putting the two possibly
> distinguished set of requirements into the same document.
> 
> I believe if the scope is kept well and not bloating the document with
> non related requirements we can do the analysis of the two set of
> requirements and see of the two sets are equal. 
> 
> So, from my perspective I think it is important that the scope of the
> document is kept narrow instead of over widening it. 

It doesn't seem useful to argue this point, so I'll just note that
I'll disagree with this approach because I don't think the
requirements actually are all that different.  The biggest difference
comes from the no-NAT assumption and the rest should be about the
same.

> > I'm not sure which words to use to describe this situation, but I 
> > personally feel it's pretty important, because this could set very 
> > tight requirements on the applications folks may wish to deploy now or 
> > later, or deployments in more general.  
> 
> Are you saying that everything that is supported by native v6 (e.g.
> multicast) must be supported by the tunneling mechanism, or are you
> stating that if something is not required it should be explicitly
> documented? 

It's up to the requirements of the scenarios to decide that :-).

The document could for example list examples of mechanisms/protocols
which do not need to be supported, or require that all should be
supported.  It depends on the scenario and conceived application
usage, both now and in future.  The key point in my comment is that it
needs to be very clearly stated if it's OK that certain v6 mechanisms
or protocols (such as DHCPv6, multicast, SEND, etc.) do not need to
work.

> If the terminal has to keep the tunnel alive, would it mean that it
> has to wake up the radio periodically (even when it would not need
> it otherwise) send a packet over the radio and possibly wait for
> answer. This means that it cannot be in a "dormant" mode all the
> time it's idle. This consumes battery quite a bit. In addition, it
> reserves radio resources for the sending of the keep-alive
> unnecessarily.

You mention good points and these should probably go in the draft in 
some form, as clarifying material.

(I certainly can't think of any protocol on the table which would 
*require* such keep-alives when there are no NATs to cross, but it's 
still good to have that goal specified.)

> > This is already discussed in another thread, but I think the key point
> > here is *node-to-node* communication, not direct tunneling as such.
> 
> Maybe I'll find the definition in the other thread, but I don't really
> understand what is node-to-node communication in the sense you put it
> here. I guess, IP is all about node-to-node communication.

I was using "node-to-node" communication as a shorthand for something
like "node-to-node communication inside the direct tunneling range",
i.e., local communication between nodes which could be directly
tunneled if the protocol supported it.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings