Subject: [Mip6] FW: DISCUSS: draft-ietf-mip6-dsmip-problem Brian's comments

From: "Hesham Soliman" <[email-masked]>
Date: Fri, 16 Mar 2007 23:18:42 +1100

Folks, 

FYI, we need to address Brian's comments on the doc. I sent the comments
below to Brian.
Your comments are welcome.

Hesham 

-----Original Message-----
From: Hesham Soliman [mailto:[email-masked]] 
Sent: Thursday, February 22, 2007 9:52 PM
To: 'Brian Carpenter'; [email-masked]'
Cc: [email-masked]'; [email-masked]'
Subject: RE: DISCUSS: draft-ietf-mip6-dsmip-problem 

 > Discuss:
 > The draft is very clear; the problem description is excellent
 > and long overdue. However, I have serious trouble with the
 > recommendation that we should simultaneously "create IPv4
 > extensions to Mobile IPv6" and "create IPv6 extensions to
 > Mobile IPv4".
 > 
 > This might console vendors or SPs who've invested heavily 
 > in one or the other, but it causes severe problems for roaming
 > users, whose need is a single Mobile IP, period. Roaming 
 > users may not be always bound to the same home site and 
 > service provider (that's called consumer choice). If a roaming 
 > user wants to choose between multiple SPs, and wants dual stack
 > service from all of them, the mobile host will in any case have
 > to support both varieties of dual stack MIP, and will have to
 > choose automagically between them. So the effect of this
 > dual recommendation is an increase in complexity and/or a
 > reduction in interoperability.

=> I think your concern above is valid for those cases where a device roams
into a network and wants to pick a local HA/MAP in that domain. OTOH, this
concern should not apply to cases where the device is connected to one or
more "permanent" home sites because those relationships are not established
on the fly. However, unfortunately, something has to give. Either SPs will
deploy both versions, or will have roaming agreements with others who deploy
the same version, or devices that want this relationship on the fly will
implement both versions for maximum freedom. 

But to put things in perspective I have to mention two important points for
this discussion. First, from a practical short term view, you can't go wrong
with MIPv4. Wherever MIP is deployed, MIPv4 is used. So at least in the
short term, devices that have MIPv4 only will be ok. The other point is that
(again from a practical point of view, given deployments today) the need for
this "on the fly" relationship with a local agent is limited to a few
deployments that really require it. Users don't really care where their
tunnel end point is located provided they have connectivity. Presumably a
user is ok with his/her permanent anchor as far as the service is concerned
(e.g. VPN is enabled..etc). The *need* for a different agent is typically
either due to a real need to reduce delays (e.g. for real time traffic) or
because the local technology being used requires it. IMHO both of those
scenarios today occur in well co-ordinated networks where such
interoperability issues are taken care of in other standard groups that I
don't go to anymore :) 

I know that this is not an ideal answer in terms of generality and
flexibility, but it's a "plan B" for those who don't want to run both
versions simultaneously. I just don't see the option of mandating one
extension as a valid one, I find it more limiting to operators and
implementers of mobile devices. For instance, if we go with the "one MIP
version" scenario, which one do we pick and why? We can't ignore the
deployed MIPv4, and of course we shouldn't deprive MIPv6 from this feature
for medium and long term deployments.

 > 
 > I didn't understand when MIP4 was rechartered that we
 > were in effect approving this dual approach in the words:
 > "A problem statement covering both Mobile IPv4 and IPv6 dual-stack
 > issues is expected to come out of MIP6 WG, and will not be developed
 > in MIP4 WG."
 > 
 > I think the choice of direction here is for the IETF, not
 > for a single WG or the IESG. I think we should not proceed 
 > on this path without a real debate, to reach consensus on one 
 > interoperable direction.

=> A debate about this is definitely useful for everyone.
I'm ok with the text below if we decide to go that way.

Hesham

 > 
 > As far as this draft goes, if the recommendation to do
 > both is the consensus of the MIP6 WG, I'd be satisfied with
 > a text change in section 5 that would make it clear
 > that this is not an IETF consensus. For example
 > 
 > OLD
 >    In order to allow for a gradual transition based on 
 > current standards
 >    and deployment, the following work areas seem to be reasonable:
 > 
 > NEW
 >    The Mobile IPv6 Working Group has reached the view that to allow 
 >    for a gradual transition based on current standards and 
 > deployment, 
 >    the following work areas would be reasonable:
 > 
 > and
 > OLD
 >    Following the steps listed above, a vendor can choose to 
 > support one
 >    mobility management protocol while avoiding the 
 > incompatibility and
 >    inefficiency problems listed in this document.  
 > Similarly, operators
 >    can decide to continue using one mobility management 
 > protocol while
 >    addressing the transition scenarios that a mobile node is 
 > likely to
 >    face when roaming within the Internet.
 > 
 > NEW
 >    If the IETF chooses to pursue all these paths, a vendor 
 > could choose 
 >    to support one mobility management protocol while avoiding the 
 >    incompatibility and inefficiency problems listed in this document.
 >    Similarly, operators could decide to continue using one mobility
 >    management protocol throughout the period of IPv4 and 
 > IPv6 coexistence.
 >    However, a mobile node would be forced to choose one approach
 >    or the other, or nevertheless to install both and use one or
 >    the other according to circumstances.
 > 
 > 
 > 

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6