[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: zeroconf draft
Hi Jonne, Pekka,
I completely agree with Jonne's view
that we should keep zeroconf and assisted tunnelling separate
as a starting point and only merge parts of the documents if
it actually turns out that they are addressing similar concepts.
Right now I don't see that happening.
Zeroconf, in my mind at least, is NOT about emulating full native IPv6.
It is about providing some basic means over which some basic IPv6 applications
can be run.
We shall try to clarify the point you raise Pekka, both in terms of
motivating the goals better (e.g., the keep alive message issue) as well as
in terms of more clearly stating the limitations anticipated compared to native IPv6.
Karen
> -----Original Message-----
> From: Pekka Savola [mailto:pekkas@netcore.fi]
> Sent: Tuesday, August 24, 2004 10:04 AM
> To: Soininen Jonne (Nokia-NET/Helsinki)
> Cc: Karen E. Nielsen (AH/TED); v6ops@ops.ietf.org
> Subject: RE: zeroconf draft
>
>
> 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
>
>