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

[Jouni Korhonen <[e-mail]>]

On Jul 29, 2013, at 1:10 PM, GangChen <[e-mail]> wrote:

> 2013/7/29, Jouni Korhonen <[e-mail]>:
>> 
>> On Jul 28, 2013, at 9:25 PM, GangChen <[e-mail]> wrote:
>> 
>>> Hi Cameron,
>>> 
>>> Thank you for the comments.
>>> 
>>> 2013/7/28, cb.list6 <[e-mail]>:
>>>> 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 all
>>> 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.
>> 
>> Just to understand this better.. Does "data roaming between different
>> province's networks" mean the province's networks have different PLMN
>> codes? Do these "province's networks" belong to different operators or
>> to the same operator (from the administration/business point of view)?
> 
> The different province's networks belong to the same operator. The
> local-breakout roaming is enabled by adding APN-OI replacement into a
> subscriber's profile

So the PLMN codes are the same for all provinces? If that is the case, then
what you are doing hardly is "roaming" rather an intelligent gateway
selection.

Is the VPLMN dynamic address allowed flag set to ALLOWED? Does the APN-OI
replacement change dynamically in the subscriber profile based on the 
UE location or is it configured "statically" based on where the subscription
is assumed to be used most of the time?

- JOuni


> 
> BRs
> 
> Gang
> 
> 
>> - Jouni
>> 
>> 
>>> 
>>>> 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
>>> 
>>> 
>>> 
>>>> 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.
>>> 
>>> BRs
>>> 
>>> Gang
>>> 
>>> 
>>>> 
>>>> On Tue, Jul 9, 2013 at 5:45 AM,  <[e-mail]> 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
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>> 
>>> _______________________________________________
>>> v6ops mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/v6ops
>> 
>>