[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: WGLC ent-analysis-03: DSTM

On Tue, 30 Aug 2005, Tim Chown wrote: 
HOWEVER, I don't see why you [in
practical scenarios] need mechanisms to give (very) temporary global
v4 addresses on the nodes, and then take them away (e.g., c) or d)
from the list below).  You can just deploy private v4 addresses if you
have address shortage, or use more stable v4 global addresses.


Well, there is a tradeoff.  You could run IPv4+NAT on all the nodes that
need IPv4.   If you have enough IPv4 global addresses you could run stable
permanent addresses on all those nodes.  Either of these could/should use
tunnel setup and address allocation mechanisms that could also be used
by something 'DSTM-like'.

But if you have limited IPv4 global addresses, and would like to avoid NAT,
then some form of dynamic, short-term addressing is desirable.  I guess the
question then is how realistic a scenario is that?

Yes that's the question, and in addition, "is this something v6ops WG should be concerned about?" I don't think that's given -- our business is (IMHO) not extending the life of (public) IPv4 addresses, becuase there are alternatives (get more addresses; use private addresses; use proxies)

If someone wants to create a clear specification how you do that, get a WG started or whatever, that's OK, but let's not discuss or recommend it here.

 - the DSTM spec is not clear enough on its scope and intent and
should not be referred to in a WG document.  My own take here is (if I
understand the intent of the spec) that we don't (anymore) require a
document like that, but rather should concentrate (in some other WG
like softwires, it's out of charter here) on creating the actual
protocol specification(s).


Which is exactly what was suggested - take the 'DSTM-like' requirements and
potential solutions into the softwires WG.

But I would still maintain that the ent-analysis must include the 'IPv6
dominant' scenario, talk about the issues we've discussed on this list,


I've no objection with this.

and
can cite DSTM as an example (the only example to date?) of a solution
approach.

I do object to this though, as I think DSTM will do more to confuse the readers than help -- becuase it seems to be trying to describe both a number of concepts and a bunch or protocols that could be used to fulfill the concepts (and the protocols are not interoperable).

Note that TSP for example (which can be one implementation of DSTM "concept") already includes most if not functionality -- certainly (AFAICS) everything that's needed for interoperability.

The text can also say that further work on nailing down the
'DSTM-like' protocol details is required, and could even recommend that that
happens in softwires.   That's pretty similar to how Teredo was supported
in the unman analysis I recall.

What actually emerges from softwires, well, we'll just have to wait and see;
so far there hasn't been any charter discussion.

Lot's of stuff should happen on softwires (or somewhere else but not here, as we're explicitly chartered NOT to do protocols). But IMHO, we just can't reference a half-baked spec at this point.

It's fine (and recommended!) to discuss these requirements in the enterprise analysis, e.g., based on the list of a) - d) goals I included in the previous message. But pointing at specs should be done with great care because many of those specs may not be clear enough on what their scope is (for example, I think TSP spec is clear enough -- it's clearly defines a protocol specification with a definite scope).

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