Re: [Mip4] review of draft-devarapalli-mip4-mobike-connectivity-00.txt

[Vijay Devarapalli <[e-mail]>]

Kent Leung (kleung) wrote:
> I agree with Sami.
> 
> 1) x-MIP solution should go forth as it directly addressed the problem
> statement, RFC 4093.
> 
> 2) Now, there is the effort to provide a solution that can avoid the
> extra tunnel overhead on the airlink and layering on the MN for data
> traffic.

which solution? draft-devarapalli-mip4-mobike-connectivity-00.txt
is definitely not targeting this. it is only addressing a scenario
where IKEv2 IPsec VPNs with MOBIKE support are used. it is doing
this because there are some immediate use cases.

however, I would support an effort to define requirements for a
more optimal solution involving MIPv4 and *any kind* of VPN
gateway and encourage MIPv4 WG to look into an optimal solution.

Vijay

> For #2, assuming this is the new requirement/problem statement to
> support VPN traversal, one possible solution is MOBIKE while another is
> x-MIP with optimization.  MOBIKE requires changes to VPN GW and can't
> work with FAs.  X-MIP w/optimization don't have these restrictions.
> It's worth defining the requirements of the long-term solution.
> 
> Kent 
> 
> 
>>-----Original Message-----
>>From: [e-mail] [mailto:[e-mail]] On 
>>Behalf Of Sami Vaarala
>>Sent: Sunday, August 28, 2005 7:30 AM
>>To: Jari Arkko
>>Cc: [e-mail]
>>Subject: Re: [Mip4] review of 
>>draft-devarapalli-mip4-mobike-connectivity-00.txt
>>
>>Hi,
>>
>>
>>>>The problem I see w.r.t. to using IKEv2/MOBIKE is that it 
>>
>>does not, 
>>
>>>>alone, match the current problem statement.  The 
>>
>>assumption made in 
>>
>>>>draft-ietf-mip4-vpn-problem-statement-03.txt is that existing 
>>>>deployed VPN infrastructure should be used (see e.g.
>>>>Section 5.1).
>>>> 
>>>>
>>>
>>>Yes. I still view that as the main and most urgent use case, so the 
>>>problem statement is OK. However, I believe we are also at 
>>
>>a situation 
>>
>>>where we can see future deployments (particularly those based on
>>>IKEv2) start to do new things. I don't see a problem with 
>>
>>pursuing two 
>>
>>>tracks simultaneously. Its not like they would be two redundant 
>>>solutions, its more like points in different stages of evolution.
>>
>>Right, I agree.  And I agree we can pursue two tracks at the 
>>same time.  However, given that these two tracks have so much 
>>in common, it doesn't seem useful to specify them in two 
>>seemginly separate specifications.  Given the way the 
>>solutions are specified, x-MIP + IKEv1 vs. MOBIKE + IKEv2 are 
>>just two different access modes.
>>The overall approach, the intranet detection, etc, are all same.
>>
>>But stepping back a little, if we relax either the "existing VPN"
>>or "minimal MIPv4 changes" assumptions, we get a number of 
>>different solutions.  For instance:
>>
>>    - A *very* straightforward way of getting mobility without x-MIP
>>      (and just IKEv1+IPsec) is just to use the "implicit ESP update"
>>      mechanism already deployed by some vendors.  I believe a similar
>>      mechanism is used in the MIPv6 + IPsec draft.  This is rather
>>      simple to implement and does away with the x-MIP overhead
>>      completely.
>>
>>    - We could specify IKEv1 mobility extensions to allow more or less
>>      the same effect albeit with more vendor effort.  Vijay's draft's
>>      Appendix has a suggestion for this.
>>
>>    - Looking at x-MIP, we can also eliminate x-MIP overhead 
>>completely
>>      by defining an optimization extension between the MN 
>>and the x-HA.
>>      This approach retains FA support, while eliminating all x-MIP
>>      overhead in non-FA scenarios.  The rough approach was 
>>described in
>>      draft-vaarala-mip4-optudp-00 [*].
>>
>>    - A very important concern in practice is managing the keys and
>>      authentication in a dual MIP or MOBIKE+MIP solution.  Should we
>>      define something to make this easier?
>>
>>At least to me it's not at all clear which avenue would 
>>produce the best possible solution - minimal changes, maximum 
>>impact, and maximum generality (especially).  So going past 
>>absolute minimum changes (dual
>>MIP) needs more thought on what criteria we should apply to solutions.
>>
>>
>>>>If we decide that there is no deployment issue w.r.t. MIPv4 and 
>>>>already deployed VPNs, we should IMO take a larger view of 
>>
>>improving 
>>
>>>>MIPv4/VPN coexistence.  Minimizing overlap between the two 
>>
>>mechanisms 
>>
>>>>would give a much better solution.  For instance, there is 
>>
>>room for 
>>
>>>>improvement in MIPv4 packet overhead, MIPv4/VPN compression 
>>>>interactions, and integrated MIPv4/VPN packet authentication.
>>>>
>>>
>>>I believe we will eventually get there. Probably step by step, 
>>>however. I view Vijay's draft one of those steps... eliminating one 
>>>unnecessary level in the stack.
>>>Or are you arguing that we should spend more time thinking 
>>
>>what to do, 
>>
>>>if we discard the no-changes-at-all assumption?
>>
>>I think we should work on defining what the longer term goal is w.r.t.
>>IPsec and MIPv4 integration.  I don't think it's clear people 
>>agree what that goal should be.  And proposing, discussing, 
>>and comparing solutions beyond dual MIP is difficult at the 
>>moment, because we have nothing to compare them against.
>>
>>As far as dual MIP is concerned, going forward with it would 
>>be useful as a baseline and as documenting existing practice 
>>(as far as I know, some people are deploying it, although I'm 
>>not sure at what scale).
>>But if we agree on working on a better long-term solution, 
>>that would of course be preferable to working on a limited 
>>dual MIP solution.
>>
>>Best,
>>
>>-Sami
>>
>>[*]
>>http://users.tkk.fi/~svaarala/publications/draft-vaarala-mip4-
>>optudp-00.txt
>>
>>
>>--
>>Mip4 mailing list: [e-mail]
>>    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
>>     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
>>Supplemental site: http://www.mip4.org/
>>
> 
> 


-- 
Mip4 mailing list: [e-mail]
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/