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

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

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

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

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