RE: Comments on draft-tsirtsis-dsmip-problem-01.txt

 > >  > ==> the last statement is wrong.  The fundamental technical 
 > >  > reason is that
 > >  > MIPv4 and MIPv6 are *two* different protocols.
 > > 
 > > => And what is the fundamental reason for having those 2??
 > 
 > Probably that MIPv4 was developed before they could 
 > seriously consider 
 > IPv6?

=> In other words there is no fundamental reason.

 > 
 > If we were designing Mobile IP *today*, we'd probably 
 > intergrate the two 
 > versions somehow.   But we aren't, what's done is done.  The 
 > possiblity 
 > that if we would now design it differently doesn't 
 > automatically mean that 
 > it would be useful to to try to enhance the two protocols or 
 > re-engineer 
 > them to work together.

=> Are these comments in the context of the two drafts
or in general? I think they can be extended with very 
little work as we showed in the drafts. Others might 
have even simpler ways.

 > >  > ==> this is a very flawed analogy.  MIP is *not* a tunnel 
 > >  > setup protocol.  
 > > 
 > > => That's news to me. How do you describe the relationship between
 > > the MN and the HA? 
 > 
 > An IPsec tunnel.

=> This is factually wrong for MIPv4 and MIPv6.
Neither has any requirement for IPsec protection
of the tunnel. It's an IP in IP tunnel!

 > 
 > > What is the relationship between the 
 > > MN and CN in MIPv6? 
 > 
 > Direct communication between two nodes (sharing the same IP 
 > protocol), if
 > route optimization is used.

=> Again, factually wrong. RO in MIPv6 is effectively
a tunnelling mechanism that instead of using IP in IP, 
uses RH and HAO to save bits. This was discussed many
years ago and discussed again when Erik published his draft.

 > >  > ==> there is a fundamental difference there.  SIP was 
 > >  > architected *from 
 > >  > the start* to deal with two protocols (AFAIK).  
 > > 
 > > => So because it was designed like that from the start
 > > you are arguing that it's not analogous? The only difference
 > > here is foresight on the SIP designers' behalf and the ease
 > > of doing so on the application layer.
 > 
 > Yes, we don't have two entirely differently specified 
 > protocols, SIPv4 and 
 > SIPv6 which we would like to merge to some extent.
 > 
 > Note that it's just not about the address family used, the 
 > differences in 
 > the design and the details are significantly different with 
 > MIPv4 and 
 > MIPv6.

=> Not as far as the MN-HA relationship is concerned. That
part is very similar. RO is the only real difference IMO.
RO is not impacted in our proposals.

 > >     As I stated, 
 > >  > if we want to 
 > >  > do it, something like HIP is possible a right direction (not 
 > >  > necessarily 
 > > 
 > > => I'm confused, so you do agree that one protocol can do the job?
 > 
 > One protocol, designed from scratch, could do the job.

=> I think this is becoming a bit argumentative. You do
acknowledge that one protocol can do the job and I've shown
you examples of how to do it using either MIPv4 and MIPv6.

 > > => But we argue that you don't need both MIPv4 and MIPv6.
 > 
 > Yep, but another argument might be that it would be  better 
 > to have them 
 > separate because they were designed to be two separate 
 > protocols, and 
 > that they are in fact quite different.

=> This is a baseless argument though because they are not
that different if RO for IPv4 is ignored.

 > >  > ==> implementations are already there; the same 
 > argument as IPv4/6 
 > >  > dual-stack deployment.
 > > 
 > > => Which implementations ?? Have you seen commercial MIPv4 running
 > > on windows? how widely deployed is it? 
 > 
 > Right.  That's the other point: if there has been no 
 > interest to implement 
 > and deploy MIPv4, why should we care to add the support in 
 > MIPv6?  Isn't 
 > this a clear indication that a) MIPv4 isn't sufficiently 
 > deployed to be 
 > worth implementing in the majority systems, b) MIPv4 may be 
 > technically 
 > flawed to be interesting (FA requirements) for general 
 > deployment, 

=> MIPv4 is widely deployed today and used by on a commercial 
level. My point was that there are not many implementations with 
both MIPv4 and MIPv6. You took that to another meaning and 
the conclusion isn't accurate.

   and c) 
 > MIPv6 may be the much better direction all-in-all?

=> Of  course, so is IPv6, hence the need for transition...

 > 
 > IMHO, this seems to just prove that there is no MIPv4 
 > deployment except 
 > perhaps in very restricted scenarios w/ very small set of 
 > hosts.  

=> Factually wrong. It is deployed on a large scale.

 > >  > ==> this is totally incorrect as shown many, many times; you 
 > >  > are just 
 > >  > assuming that the mobile node could not run a transition 
 > >  > mechanism on its 
 > >  > own to enable IP protocol access.
 > > 
 > > => You have not shown that at all. the solution you showed:
 > > 
 > > - Lacks Bidirectionality (6-to-4). 
 > 
 > By adding 6to4 on HA, you should be able to obtain that.

=> If you have a proposal I suggest you write something 
up; designing it on email won't work. The above suggestion
won't work in the reverse tunnel ,I've already said that
many times...

 > 
 > > - Only runs with MIPv4 (or at least you didn't explain it
 > > for MIPv6). 
 > 
 > I'm not sure if I understood your point.  Did you mean that I didn't
 > describe how to enable MIPv4 mobility in an IPv6-only 
 > network? 

=> No. You didn't show how MIPv6-only can be used 
for both IPv4 and IPv6.

Hesham