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

[Jouni Korhonen <[e-mail]>]

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

> 2013/7/29, 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.
> 
> That is a good question. At http://en.wikipedia.org/wiki/Roaming, the
> roaming has been interpreted as "In wireless telecommunications,
> roaming is a general term referring to the extension of connectivity
> service in a location that is different from the home location where
> the service was registered." Roaming behavior is justified by whether
> the visited network has subscriber's registration information. MNC+MCC
> may not be the matter.


In 3GPP sense, you are in a visited network when the MNC+MCC codes
do not match your own expected HPLMN or EHPLMNs. I would stick with
3GPP definition of roaming when describing 3GPP specific things. I
agree that that a "HPLMN" may consist multiple PLMN codes. Again I
would be careful with the terminology when you mean a visited network
gateway or when a gateway (visited or home) that is topologically
selected close to the UE.. just to avoid confusion.

- Jouni


> 
>> 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?
> 
> The APN-OI replacement is configured in a static way and assumed to be
> used in most times.
> 
> -Gang
> 
> 
>> - 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
>>>> 
>>>> 
>> 
>>