Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis

2013/7/29, cb.list6 <cb.list6@gmail.com>:
> Gang,
>
>
> On Sun, Jul 28, 2013 at 11:23 AM, GangChen <phdgang@gmail.com> wrote:
>> Hi Cameron,
>>
>> Thank you for the comments.
>>
>> 2013/7/28, cb.list6 <cb.list6@gmail.com>:
>>> As general feedback
>>>
>>> 1. As others have noted, it is important to clarify that home routed
>>> is the default case and local-breakout is only relavent for IMS, but
>>
>> local-breakout may not be only for IMS. We have deployed that for the
>> data roaming between different province's networks in China. It offers
>> efficient routes. Besides, 3GPP specified the SIPTO architecture for
>> roaming. That may bring impacts in the future.
>>
>
> AFAIK, these are very different cases, but i do not know much about SIPTO
>
>  SIPTO requires that the UE have an IP address from the home network.
> So, in SIPTO cases, my customers always have an IP address from my
> network and they also have an IP address from LAN.  In this way, SIPTO
> is still home routed.

The SIPTO process can be found at TS 23.060(R10) clause 5.3.12 and TS
23.401 clause 4.3.15. Once the proper GGSN is selected, the SGSN
should deactivate the attached subscribers. The subscriber should
initiate another PDP/PDN requests to the selected GGSN. So, I guess
the assigned address would belong to the visited network.

> The IMS case, your receive the IP address from the visited network.
> So, when my IMS subscribers roam to your network, they no longer have
> an IP address from my network, they only have an IP address from the
> visited network.

I will add it to the draft. thanks

>
>>> IMS based roaming and local breakout is yet to see its first
>>> deployment, and may still be years in the future for roaming to work
>>> this way.  So, local breakout is not  a real case and seems to be
>>> causing more confusion.
>>>
>>> 2.  There is a hazard in assuming the well known prefix is always
>>> available.  Any device should not assume the well known prefix is
>>> available.  This is essentially a misconfiguration that should not
>>> occur.
>>
>> Ok. You don't recommend using WKP. How about taking different priority
>> for the deployment
>>
>> High priority:  nat64-discovery
>> Medium: WKP
>> Low: manual configuration
>>
>>
>
> I would not put it that way, i would just say discovery is best.
> Discovery can discover the wkp or nsp.
>
> Manual configuration of pref64, wkp or nsp, can result in a lot of
> trouble for nomadic / mobile nodes.

Yes. but do you have better idea in the case of non-DNS64?

>
>>
>>> 3.  What i have learned
>>>
>>> a.  dual-stack 2 PDP will never work, charging issues in the billing
>>> system, and too much capacity wasted for no real gain
>>>
>>> b.  dual-stack 1 PDP (v4v6) will not work any time soon.  Enabling
>>> this feature in the HSS/HLR breaks roaming and there is no way to
>>> ensure this issue is fixed in the hundreds of networks that are
>>> potentially impacted.  There are some backs to do on the home network
>>> that can make this easier but not exposing partner networks to the new
>>> release 8 features.
>>>
>>> c.  What does work and adds value (saves IPv4 address for the common
>>> case of not-roaming) :  IPv6-only single PDP 464XLAT on the home
>>> network, IPv4-only single PDP when roaming.  This is how i am moving
>>> forward.  The when at home, the UE has default configs for ipv6-only
>>> and when roaming the ue only attempts to connect using IPv4.  This
>>> gets the vast majority of users in my home network off v4 and keeps
>>> ipv4 for the complicated yet relatively small percentage of roaming
>>> users.
>>>
>>
>> Thanks for the good summary. That is the lesson we have leaned.
>>
>
> Then it must be a BCP :)

I'm in favor of the BCP ;)

BRs

Gang

>
> CB
>
>> BRs
>>
>> Gang
>>
>>
>>>
>>> On Tue, Jul 9, 2013 at 5:45 AM,  <fred@cisco.com> wrote:
>>>>
>>>> A new draft has been posted, at
>>>> http://tools.ietf.org/html/draft-chen-v6ops-ipv6-roaming-analysis.
>>>> Please
>>>> take a look at it and comment.
>>>> _______________________________________________
>>>> v6ops mailing list
>>>> v6ops@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>
>