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

[Soliman Hesham <H.Soliman@flarion.com>]

Pekka, 

Thanks for the specific commments. Answers below
(I don't have comments on the ommitted text):

 > I did a quick pass on the dsmip-problem draft.
 > 
 > I tried to concentrate only on a couple of specific 
 > sections.  There are a 
 > lot of issues in the others as well, but it isn't worth the 
 > time to argue 
 > about the rest at this point.
 > 
 > To summarize:
 >  - most of the problems are not important or portrayed with specific 
 > assumptions
 >  - the most important remaining issue seems to be duplicate hand-off 
 > signalling
 >  - it might be best to change this to a requirements/goals 
 > document and 
 > give better coverage to other features which speak against 
 > any changes 
 > like these
 >  - I think you have to spell out your assumptions more explictly
 >  - I think you have to consider what your aim is in more 
 > detail: do you 
 > want bidirectional tunneling through the HA or do you want some more 
 > advanced mobility as well (the latter is probably highly 
 > problematic using 
 > your proposals, consider e.g. return routability checks)
 >  - based on this, I do not think the problem statement can be taken 
 > seriously, and I would recommend not starting any activity 
 > based on it.

=> I can't argue against any of the points above...too vague
for me. I'll answer the specific comments below

 > 
 > I'll just argue the problem description and it's subsections.
 > 
 > 2.0 Problem description
 >  
 >    Mobile IP (v4 and v6) uses a signaling protocol (Registration
 >    requests in MIPv4 and BUs in MIPv6) to set up tunnels 
 > between two end
 >    points. At the moment MIP "signaling" is tightly coupled with the
 >    "address family (i.e. IPv4 or IPv6)" used in the 
 > connections that it
 >    attempts to manipulate. There are no fundamental 
 > technical reasons   
 >    for such coupling. 
 > 
 > ==> 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??
See draft-soliman-v4v6-mipv6 for example

 > 
 >                              If Mobile IP were viewed as a 
 > tunnel setup
 >    protocol, it should be able to setup IP in IP tunnels, 
 > independently 
 >    of the IP version used in the outer and inner headers. 
 > 
 > ==> 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? What is the relationship between the 
MN and CN in MIPv6? 
I remember a couple of years ago draft-nordmark-foresight..
proposed that IP in IP is used between the MN and CN instead
of the current spec, no technical opposition was given.
So what do you call it if it's not setting up tunnels?


 > If you wanted a tunnel setup protocol, you would not need 
 > MIP in the first 
 > place, just dynamic VPN mechanism.

=> Like what ?? MIP sets up tunnels dynamically between the 
MN and HA (v4 and v6) and any-to-any (MIPv6 RO). 

 >       Other
 >    protocols, for example SIP, are able to use either IPv4 
 > or IPv6 based
 >    signaling plane to manipulate IPv4 AND IPv6 bearers.
 > 
 > ==> 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.

I wish we had that foresight in MIPv6, it would have saved
us arguing about it now.

    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?

 >    A mobile node using both Mobile IPv4 and Mobile IPv6 to 
 > roam within
 >    the Internet will require the following: 
 > 
 >    - Both implementations available in the mobile node 
 > 
 > ==> analogy: Both IPv4 and IPv6 must be implemented in the 
 > mobile node, 
 > and it is a problem.

=> But we argue that you don't need both MIPv4 and MIPv6.

 > 
 >    - The network operator needs to ensure that the home 
 > agent supports
 >      both protocols or that it has two separate Home Agents 
 > supporting
 >      the two protocols, each requiring its own management.
 > 
 > ==> analogy: The network operator must manage both DHCPv4 
 > and stateless 
 > address autoconfiguration (or more closely, DHCPv6) and this 
 > is a problem.

=> Yes it is, different WG. But clearly there are no 
significant performance issues here compared to mobility.

 > 
 >    - Double the amount of configuration in the mobile node 
 > and the home
 >      agent (e.g. security associations).
 > 
 > ==> analogy: applications must manage the access controls (like IP 
 > addresses, etc.) for both IPv4 and IPv6 nodes, and this is a problem.

=> Finding analogies does not mean that there is no 
problem and doesn't tell me whethere you agree/understand
that there are problems and how serious.

 > ==> See?  Even though the analogies are not 100% accurate, you are
 > describing issues inherent to dual-stack deployment (which are not
 > considered serious problems in general, but in all fairness, 
 > there hasn't
 > been much discussion on this in v6ops), and extrapolating them to be
 > serious Mobile IP problems which must be addressed.  Want to 
 > run both IPv4
 > and IPv6 but any new configuration is unacceptable? Tough.

=> Tough for v6 I suppose...
Who said _any_ new configuration is not acceptable?  
We are saying that there are significant performance
and service quality issues involved. And the only 
answer I'm getting from you is a dismissive 
"not a significant problem". Even if that's your opinion
I don't know what scale is used to decide what is significant
and what's not. In the cases I'm talking about these performance
and service quality problems are very significant by a wireless
operator's standard.

 > 
 > 2.1. Implementation burdens 
 >     
 >    As mentioned above, a dual stack mobile node would require both 
 >    mobility protocols implemented to roam seamlessly within the
 >    Internet. Clearly this will add implementation efforts, which we
 >    argue are not necessary.
 > 
 > ==> 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? 

 > 2.4. The impossibility of maintaining connectivity
 >     
 >    A final point to consider is that even if both mobility 
 > protocols are
 >    supported by a mobile node seamless connectivity would 
 > not in fact be
 >    guarantied since that also depends on the IPv4/IPv6 
 > capabilities of
 >    the networks the mobile is visiting i.e.: a dual stack node
 >    attempting to connect via a IPv4 only network would not 
 > be able to   
 >    maintain connectivity of its IPv6 applications and vice versa. 
 > 
 > ==> 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). 
- BW inefficient
- Only runs with MIPv4 (or at least you didn't explain it
for MIPv6). 

Hesham