Subject: [netext] Comment on draft-gundavelli-netext-pmipv6-sipto-option-01

From: Hidetoshi Yokota <[email-masked]>
Date: Thu, 21 Jul 2011 21:01:31 +0900

Hi Sri,

I think that SIPTO is very important work and PMIPv6 should support this
feature as you described in your draft.

I have one clarification question on this draft. What's the relationship
with the PMIPv6 flow mobility draft
"draft-bernardos-netext-pmipv6-flowmob-03", which also defines a spec to
send the traffic selector (i.e., Flow ID Mobility option in the FMI)?

I suppose that these two specs are intended to be used in different
situations, but I would appreciate if you could clarify whether they are
complementary or one can cover the other.

Regards,
-- 
Hidetoshi

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 21 Jul 2011 09:09:26 -0700

Hi Yokota-san,

Thanks for your review.

This is essentially about IPv4 traffic offload, not about flow distribution
for multi-access terminals/flow mobility. This is not about tunnel/interface
selection for a given flow, but rather about the IPv4 flows for NAT offload
at the access edge/MAG.

Regards
Sri

---

From: Hidetoshi Yokota <[email-masked]>
Date: Sun, 24 Jul 2011 09:47:16 +0900

Hi Sri,

> selection for a given flow, but rather about the IPv4 flows for NAT offload

I understand the mechanism that this spec describes. I just thought that
the IP Traffic Offload Selector Option in your draft and the FID
mobility option in RFC6089 have the equivalent capability from the
perspective of carrying the (IPv4) traffic selector. Anyway, I hope that
this will activate the SIPTO discussion in IETF as well.

Regards,
-- 
Hidetoshi

> Regards
> Sri
> 
> 
> 
> 
> 
> 
> On 7/21/11 5:01 AM, "Hidetoshi Yokota"<[email-masked]>  wrote:
> 
>> Hi Sri,
>>

---

From: Sri Gundavelli <[email-masked]>
Date: Sat, 23 Jul 2011 19:56:59 -0700

Hi Yokota-san,

Sure. The options have similar properties, they both use the 6088 formats
for flow selectors. While 6089 identifies the flows for a given access, and
does not cover offload. We could have surely extended this option to DSMIP,
but that is not our main interest at this point of time. Good to see your
interest on SIPTO, we believe this is burning issue for every operator as
well. 

Regards
Sri

---

From: Hidetoshi Yokota <[email-masked]>
Date: Tue, 26 Jul 2011 10:20:21 +0900

Hi Sri,

Thanks for your clarification. SIPTO capability extension for PMIP is as
much important. I just thought if these two capabilities (flow mobility
and offload) could be combined as a protocol. Either to use the option
in your draft or to define a new flag in PMIP flow mobility draft. I
would like to see the discussion in the meeting.

Regards,
-- 
Hidetoshi

(2011/07/24 11:56), Sri Gundavelli wrote:
> On 7/23/11 5:47 PM, "Hidetoshi Yokota"<[email-masked]>  wrote:
> 
>> Hi Sri,
>>

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 25 Jul 2011 21:30:26 -0700

Hi Yokota-san,

Thanks. More than the option, the specification scope and use-case is
different. We don't need to add SIPTO to flow mobility scope, already that
draft is struggling to make any progress with the amount of features it has
and finding convergence among authors/WG. We don't have to add this to the
mix :) and make it more interesting. Hopefully, that draft will cut some
features and make some progress.

Again, thanks for your review and support for the work.

Regards
Sri

---

From: Hidetoshi Yokota <[email-masked]>
Date: Wed, 27 Jul 2011 09:01:43 +0900

Hi Sri,

I see that you want them to be separated for fast move. I really feel
empathy for the flow mobility draft and I do hope to see some progress
in this meeting...

Regards,
-- 
Hidetoshi

(2011/07/26 13:30), Sri Gundavelli wrote:
> On 7/25/11 6:20 PM, "Hidetoshi Yokota"<[email-masked]>  wrote:
> 
>> Hi Sri,
>>

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 26 Jul 2011 22:07:19 -0700

Hi Yokota-san,

> I see that you want them to be separated for fast move.

Nope, both have different purposes. One is about offload and other is about
IP flow mobility across multi-access. Offload takes away the mobility, its
non-mobility, its RO and is not specific to multi-interface terminals...so,
the use-cases are different and the option purpose is different. Use of the
same option does not mandate feature collapse in one document. Offload is
not associating a flow with an access. But, on the same access, its taking
two flows in two different paths. This is routing. Hope this clarifies.

The issue about flow mobility draft is finding the common base line that we
can find agreement and move it forward.

Regards
Sri