RE: DSTM

["Bound, Jim" <jim.bound@hp.com>]

Margaret,

I am sure Tim will respond to your entire mail thread but I want to
respond to a few of your assumptions and questions below. 

> This is also the biggest problem with having a large tool-box 
> of transition mechanisms -- everyone can reach in and pick 
> out a different tool...  So, in order for a given host 
> implementation or piece of networking equipment to operate 
> properly on multiple networks, it will need to implement or 
> interoperate with _all_ of the tools.

This is simply invalid logic and it is none of yours, mine, or the
IETF's business what a free enterprise systems does at all.

The more tools the better.

> 
> This leads to increased complexity, more security issues, 
> more points of failure, larger code sizes, higher costs for 
> networking infrastructure, etc.

I don't agree at all.  Each mechanism will be used for a solution not
all mechanisms in one network.  I don't know of any user that is that
stupid to use 5 mechanisms at once.  The point you continue to miss is
that there could be 5 different usrs with 5 different needs for
transition and each of the 5 mechanisms are useful to them each
individually as one tool.

Forcing all users to use only X, Y, and Z is absurd and the market,
implementers, and users will reject that IETF view and will simply
ignore the IETF regarding transition and seek the solutions they need
elsewhere.  if that happens we have failed here in the IETF and it will
be recorded as so for sure.

> 
> One of the points of standardization, IMO, is to promote 
> small, simple, interoperable implementations.

And because there are 6 or 8 transitiion mechanisms that do not
duplicate each other does not prevent your statement above.

What the IETF cannot do is try to dictate the policy for deployment in
the market at all.  That is absurd and will be rejected by the people in
the IETF and the market.  It will also cause serious discussions with
the IETF's higher authority for sure.
 
> I have not personally heard any ISP or Enterprise operators 
> indicate their intention to run IPv6-only backbones any time 
> soon.  

Well they do exist because you have not heard of them does not mean they
don't exist.  

Or are you calling us who say this liars?

>I believe that this will happen at some point in the 
> future, but I am not certain (from my own experience or any 
> direct communication) that this is a widespread need today.  
> If this won't be needed until later, I think that we should 
> wait until later to provide it -- when we will know more 
> about how IPv6 has been deployed.

It is needed now as much as any mechanism is needed now.

> 
> However, even if I accept that there is a need for a solution 
> in this space now, I have some serious reservations about the 
> DSTM solution as it is currently documented.  In particular, 
> I don't know why we would want to standardize a solution in 
> this space that includes multiple non-interoperable options 
> for how a dual-stack host can obtain a temporary IPv4 address 
> (DHCPv6 and TSP). 

You should comment on the spec then rather than taking general pot-shots
at engineers work in the IETF.

And by the way they are interoperable across multiple OSs and platforms
and in fact saw them running today in a network lab.  Go read the DSTM
web page pointer I sent and download the implementations and test it for
your self.  It works.

> Would a client need to implement both to 
> work on different networks?  And how would a client know 
> which one to use in any particular situation?  Would it try 
> one and then fail over to the other?

> 
> I'm also not sure how/why we need a specific DSTM server at all... 
> How is DSTM superior to using a DHCPv6 option to get the 
> configuration information needed to set-up a configured 
> IPv4-in-IPv6 tunnel and then using DHCPv4 over that tunnel?

We should take these questions to specific DSTM thread and I think they
are implementation questions not standards questions, but we could
debate that on such a thread.

Regarding divulging who the users are?  I and no one here has to do that
and no one has done that other than generically for Teredo, 6to4, or any
mechanism. DSTM should not be treated unfairly because you, Pekka, or
Thomas are uninformed of this deploymet. So please don't use that
argument here its a valuing difference issue and I don't want to have to
go there.  I will say the users who are wanting DSTM are Military,
Security Defense Concerns, and Provider type users and world wide and
not in just one geography.  I am sure you realize myself or other DSTM
team members, and others on this list cannot share with you who exactly
they are for confidence reasons.

DSTM will be deployed as priority on Moonv6 as transition mechanism and
across North American, European, and Asian geogrpahys as Moonv6 is now
an International Network Pilot in process for your information.  So we
are not talking about a little lab in the corner of the world or a mom
and pop small business wanting the benefits of DSTM and more importantly
moving to dominant IPv6 backbone networks. And a network does not mean
just the public Internet. 

Regards,
/jim
> 
> Margaret
> 
> 
> 
> 
>