[Mipshop] FW: AD review of draft-ietf-mipshop-pfmipv6

["Ahmad Muhanna" <amuhanna at nortel.com>]

Forwarding to the mailing list!

-----Original Message-----
From: Hidetoshi Yokota [mailto:yokota at kddilabs.jp] 
Sent: Tuesday, October 13, 2009 8:20 AM
To: Muhanna, Ahmad (RICH1:2H10)
Cc: Vijay Devarapalli; Hidetoshi Yokota
Subject: Re: [Mipshop] AD review of draft-ietf-mipshop-pfmipv6

Hi Ahmad,

I see that you really want to include Option 3, which is a dynamic
tunnel-type negotiation and which is the gap between us... Let me make
sure one thing. In the case of the fast handover protocol, there is no
second HI/HAck exchange for determining the tunnel-type, which otherwise
would cause an unexpected delay. So, if the PMAG sends the PBU with the
GRE Key option and receives the PBA with some error status or without
the GRE Key option, then the PMAG selects IPv6-in-IPv6 for the user data
tunneling. This seems to be a "speculative" negotiation and is that
acceptable for you?

Assuming the above is ok, I would then propose two recommendations: one
is a static configuration (Options 1+2) and the other is a dynamic
negotiation (Option 3). In the former case, one type of tunneling
(IPv6-in-IPv6 or GRE or others) is statically configured, which
obviously has some limitations at the expense of simplicity. In the
latter case, the PMAG determines the tunnel-type per session, which
gives more flexibility, but the negotiation procedure must be specified
for interoperability.

Are we getting closer or still far apart?

Regards,
-- 
Hidetoshi

Ahmad Muhanna wrote:
> Hi Hidetoshi,
> It seems that we are back to square one. But, it does not hurt to
> capture the possible solutions that I suggested earlier.
> 
> OPTION No. 1:
> ===========
> Inter-MAG tunnel type can be statically configured with NO change on
the
> MAG. i.e., no new functionality added. If that is the option, then the
> draft needs to capture the limitation of this choice and define what
> encapsulation would work and what would not work. In other words, make
> some recommendation, kind of.
> This option means the draft will define, for example, if IP6-in-IP6 is
> used for inter-MAG tunnel, then the draft will say that ONLY
IP6-in-IP6
> will be supported between the MAG and the LMA. Then repeat the same
for
> all types of encapsulation...
> 
> 
> OPTION No. 2:
> ===========
> Define a specific type of encapsulation, for example, GRE
encapsulation
> with keys. Then the draft needs to define what kind of enhancement the
> MAG needs to have to map the traffic of all types of encapsulation
> between the MAG and the LMA to the GRE tunnel with keys over the
> inter-MAG tunnel. This also requires a sane GRE keys exchange between
> the PMAG and NMAG. If there is any limitation, it needs to be
specified.
> 
> 
> OPTION No. 3:
> ===========
> Dynamic negotiation of the per-mobility session tunnel type between
the
> PMAG and NMAG using HI/HAck messages. This is the most appropriate
> solution, IMO. There could be some exceptions that needs to be
> documented and some difficulties that need to be addressed.
> 
> Any option used, the traffic needs to be exchanged between the NMAG
and
> PMAG without any ambiguity in order to have a meaningful fast handoff
> mechanism. Otherwise, there is no point of having the whole thing to
> start with.
> 
> Hope this will help.
> Cheers!
> 
> Regards,
> Ahmad
>  
>