RE: DSTM

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

Hi Margaret, 

> 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.

OK.  I will accept that and move on. Thanks.

> 
> 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, 

Clearly this is the case completely for difference.  But how does that
influence the IETF actual work.  I don't think it does just us as
thinking individuals.  Probably good to separate deployment evolution
from solutions to be specified.  All here may not want to hear this or
are we now in a technology area of discussion where we has technology
persons must discuss this aspect of IPv6?

>and (2) the purpose and effect of IETF 
> standardization, 

The IETF specifies standards that is all.  It is not a consulting body
for deployment to the market (individuals in the IETF may be
connsultants for sure).  People who spend 90% of their day job on IETF
mail lists and debating architecture often do it to long and begin to
think they have a larger mission to inflate their ego, justify their
time here, and their importance in the scheme of things.  The IPv6 Forum
and NAv6TF are in fact this for IPv6 and do it full time and full time
focus, and you have seen that input to private enterprise and
governments and they do affect deployment.  IETF is a place to build the
specs.  Implementation verification are the trials with real running
code ergo like Moonv6, 6NET, CNGI, et al.  all running IPv6 and the IPv6
Forum Logo certification.  

>and (3) whether DSTM is a solution that 
> should be standardized in the IETF.

I think standardized is too a broad term.  Should it be experimental,
informational, or standards track.  IETF provides venue for all three.

> 
> 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.

I don't believe most vendors will at all but that again is another point
to add to difference.  It is none of my business or in the IETF
regarding the systems view of implementation and out of scope for
defining a spec.

It is clearly possible for an implementation to implement all five or
whatever the number is to be.

What will prevent this is cost in engineering and IT box vendors and
ISVs selecting markets and strategy, not IETF deliberations.

If hardware or softwarwe messes up a user it will die in the market.

This is not within our scope at all.
  
> Since one of the good features of IPv6 is that it requires no 
> client-side IP stack configuration, 

The above is incomplete I believe.  It requires no server in stateless
is more accurate the stack is still configured at boot.

>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.

That is one model but all models do not have to support this.

And all our mechanisms require this and esp. where tunnels are required
to be set up from user space to kernel space in the network subsystem.

> 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.

None of this is required we will implement policy knobs for the user to
select and as I said they will not select all of them and 99% of the
time only one of them.

This is like saying I can't support TCP, UDP, SCTP, and all the loadable
modules available to a user at boot config because there are to many.
That is simply not valid and we all do this today very well thank you
:--)

> 
> >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.

Good.  Tell Pekka :--)

> 
> 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.

Agree.

> 
> 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!

Add Ipv6 Forum to that list and for transition if things don't work out
here in the IETF for transition all the vendors are sick of the game
here in v6ops and we are having to ship mechanisms and can no longer
wait on the IETF if it don't figure it out.  This has been stated
publicly and the market has said fine if that is what must be done.  I
would rather see it work out in the IETF quite frankly or I fear a
Internet Standars schism could happen and that will make all of our work
more difficult.

> 
> >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.

Change solutions to specifications.  IETF does not work on 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.

That is correct and I agree.

> 
> >>  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.

Good.

> 
> 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.

Once we wrap up the Enterprise Scenarios we will position DSTM across
all of them to apply or not apply being UMAN, 3GPP, ISP, and Enterprise.
Already started that discussion in DSTM community.  As one individual I
do not believe it applies to UMAN but clearly does to 3GPP, ISP, and
Enterprise scenarios.

> 
> >>  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...

Again a user on the same network is not going to use DHCPv6 and TSP for
providing the addresses that is just stupid. 

Its like PKI for IPsec.  There will be multiple PKI servers for IPsec
and users will deploy one of them for their networks with client daemon
interfaces to PKI then to IKE and then to IPsec.  This is simply
reality.

> 
> 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.

They do not have to interoperate with each other anymore than a PKI
client will for IPsec.  But this is a valid discussion for DSTM I agree.

> 
> 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.

That is true.

>  How will it know which one to try first?  

By the user selecting it as they do any layered network software product
on a platform.

> 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?

It will never use both and we will add that to the spec as a requirement
and we should have already.

> 
> 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.

Your applying user daemons to stateless and that is never going to
happen for a long time.  But only permitting one at a time on a network
removes the problem.

The objective is to provide the user a choice and I am always for lots
of choices and for networking.  I also am an engineer and architect and
know that can work in implementation and operationally for deployment.

> 
> >>  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!  :-)

Fair.  We really should not be going this far but it is useful
discussion.

> 
> >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.

Well this gets political.  But I agree.

> 
> 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.

Thanks for saying this and that is good to hear as your an IESG member
and it demonstrates your leadership views.  I wish more IESG members and
one of our Chairs for v6ops would make such statements periodically to
reinforce this to the WG.  Not all are as persistent as some of us and
may back off becuase of title in the IETF.  That is not cool.  Esp. new
people to the IETF could get the wrong impression.

> 
> 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.

100% agree.  The question of this is on the WG table as question and how
we proceed now and the fairness issue.

Regards,
/jim

> 
> Margaret
> 
> 
>