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

["Kent Leung \(kleung\)" <[e-mail]>]

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.

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/