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

Re: DSTM

Hi Margaret, all,

Regarding your comment on the different mechanisms selection, please see http://www.watersprings.org/pub/id/draft-palet-v6ops-auto-trans-00.txt (and provide inputs !). By the way this document has disappeared from the RFC editor, not sure why ! (someone can provide some hint or what to do about it ?).

Regarding this thread in general, I've customers asking for only IPv6 deployment. If this is a solution I buy it ;-) I must recognize I've not played myself with DSTM, but it seems so, and clearly a fair decision needs to be taken with any transition mechanism if is the available solution for any identified scenario.

We can't rely in only a few 100% perfect mechanisms, or it will be too late. Similarly we can't rely in just 3, 4 or 5 mechanisms if they don't cover all the identified scenarios. I agree that as less mechanism we have, as better, but it seems that the 4 already identified are not enough ? Then what we are waiting for ? Deploying non-standard mechanisms ? No thanks, if we can avoid it.

I asked this in the last meetings ... What the rest believe ?

Regards,
Jordi

----- Original Message ----- 
From: "Margaret Wasserman" <margaret@thingmagic.com>
To: "Bound, Jim" <jim.bound@hp.com>; "Tim Chown" <tjc@ecs.soton.ac.uk>; <v6ops@ops.ietf.org>
Sent: Thursday, June 24, 2004 1:52 PM
Subject: 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
> 
> 
> 


**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.