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

RE: DSTM


Hi Jim,

I did not mean anything that I said in my previous note as a personal attack on you or anyone else involved in the DSTM work. I think it is possible for well-intentioned, reasonable people to have a difference of opinion, and I think that is the case here.

In particular, I think that we have a difference of opinion regarding three things (1) the effect on the market of having multiple solutions/mechanisms to resolve overlapping problems, and (2) the purpose and effect of IETF standardization, and (3) whether DSTM is a solution that should be standardized in the IETF.

At 3:24 AM -0400 6/24/04, Bound, Jim wrote: 
 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.

Many stack vendors attempt to write generic implementations that will work properly in a wide range of environments. So, even though each network administrator would choose a single mechanism, if there are five different mechanisms in widespread use some vendors will need to implement all five. Since one of the good features of IPv6 is that it requires no client-side IP stack configuration, there shouldn't be a need (and there may be no opportunity) to configure each client to know which transition mechanisms are in use on a given network. So, if there are five (or more) different mechanisms by which a client could obtain an IPv4 or IPv6 connectivity, the client will need to know (1) which mechanisms to try in which order, (2) whether to continue trying new mechanisms when IP (v4 or v6) connectivity has (apparently) been obtained through one of them, and (3) which IP address/connectivity mechanism to use for each communication if it has obtained connectivity via more than one mechanism.

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.

I do not believe that the IETF has the power to force anyone to do anything, nor do I think we should try.

I think that it is our role to put forth what we think are technically and architecturally sound, useful, interoperable standards that make the Internet work better and promote our shared IETF values like the openness of the Internet, end-to-end security, privacy and end-user empowerment. If people find our standards to be valuable, relevant and trustworthy they will use them.

Lots of other groups also develop standards, or de facto standards, for the Internet (the W3C, 3GPP, the IEEE, Microsoft...) and more power to them!

What the IETF cannot do is try to dictate the policy for deployment in
the market at all.

I agree, and I don't think that we try to do this. By choosing to standardize one thing and not another, or by publishing documents as Information or BCP RFCs, we do offer our advice to the market regarding what we (the IETF) consider to be sound, useful and interoperable solutions. But, we certainly don't try to dictate what vendors can or cannot implement, nor do we have any means to dictate what users will/will not deploy.

 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?

Jim, I did not mean to imply that the people you have talked to do not exist! And, I don't think that you are a liar.

I merely said that I can't assess the needs of users that I don't know in scenarios that have not been described to me in detail. I have not (personally) talked to someone who has told me that they are deploying a large IPv6-only network.

 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.

I believe that the paragraph above is a comment on the spec...

The specification for DSTM includes two separate mechanisms to obtain an IPv4 address -- DHCPv6 and TSP. There doesn't seem to be a mandatory-to-implement mechanism on either end, and the two mechanisms are not interoperable with each other. So, it is quite possible to build a TSP-only DSTM client and a DHCPv6-only DSTM server (or vice versa) that are both fully compliant with the DSTM spec but which will not interoperate with each other.

So, for example, if a vendor wants to write a client implementation that can work in both types of DSTM environment, it will need to include client support for both flavors of DSTM. How will it know which one to try first? Should it try both, even if the first one seems to work? If they both work and provide different configuration information, which information should the node use? If it uses both sets of information, how will it decide which connectivity path to use for each communication?

Even if you were to remove one of the mechanisms from the DSTM draft, it won't resolve the larger issue that we're creating regarding how an IPv6 host comes up on the network and how it chooses between the multiple methods of IPv6 connectivity and address configuration that may be available.

 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.

Since the subject of this thread is "Re: DSTM", I am not sure that it can get more DSTM-specific than that! :-)

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.

I am very happy for you and for others that have worked so hard on DSTM that people are using it.

It isn't necessarily the case, though, that the IETF should standardize everything that people choose to use. Nor, is it the case that people should only use things that are standardized in the IETF.

Please note that I don't consider it my decision (alone) whether DSTM is or is not standardized by the IETF. It is my personal opinion that we should not standardize DSTM (at least as currently documented) because of the technical/deployment issues that I have stated above and in my earlier message. However, it is quite possible that the consensus of the v6ops WG will not agree with me.

Before we can fruitfully make that decision, though, we need to document the expected deployment scenarios in an enterprise scenario document, and we need to reach WG consensus on that document. Then we can talk about whether DSTM applies to one or more of the expected scenarios and whether it is the best solution, technically and architecturally, to address any of those scenarios.

Margaret