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

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

FYI

-----Original Message-----
From: Muhanna, Ahmad (RICH1:2H10) 
Sent: Wednesday, October 14, 2009 12:50 AM
To: 'Hidetoshi Yokota'
Cc: Vijay Devarapalli
Subject: RE: [Mipshop] AD review of draft-ietf-mipshop-pfmipv6

Hi Hidetoshi,
I am responding to your original email and this one here. Please see
inline.

Regards,
Ahmad
> -----Original Message-----
> From: Hidetoshi Yokota [mailto:yokota at kddilabs.jp] 
> Sent: Tuesday, October 13, 2009 8:22 PM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: Vijay Devarapalli; Hidetoshi Yokota
> Subject: Re: [Mipshop] AD review of draft-ietf-mipshop-pfmipv6
> 
> >> -----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). 
[Ahmad]
They seem fine with me. Please see below.

> >> 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. 
[Ahmad]
I am fine to include this option AS LONG AS THE LIMITATION IS CAPTURED
in the draft somewhere.


>>> 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.
[Ahmad]
That should be fine with me too.

> >>
> >> Are we getting closer or still far apart?
[Ahmad]
YES.
Let us follow on this. Hopefully we are not going to go back and
renegotiate this proposal again! :)

> >>
> >> 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
> >>>