Re: [v6ops] draft-chen-v6ops-ipv6-roaming-analysis (GangChen)

[GangChen <[e-mail]>]

Hi Pete,
Thank you for the times to review. Sorry for the delay (I'm being the
trip to IETF meeting)

2013/7/25, Pete Vickers <[e-mail]>:
> Some minor typos & comments on your doc:
>
> 2.  Roaming Descriptions
> dual-tack -> dual-stack
> That are -> They are
> equipments -> equipment
> restored -> stored
> different IPv6 supports -> different IPv6 support
> The following is like to document the failure cases -> The following are
> likely failure cases scenarios (?)

I will fix those in the next update

>
> 3.2.  Roaming to early dual-stack networks
> A roaming subscriber with IPv4v6 PDP/
> PDN type should change the request to two separated PDP/PDN messages
> of single IP version in order to achieve equivalent results.  Some
> operators may turn off the function only allow one PDP/PDN is alive
> for each subscriber.
>
> This is also likely to fail in more subtle ways, e.g. a visited network
> commonly permits two concurrent PDP, since it is usual for MMS (picture
> messaging) services to be accessed via a seperate APN to Internet services.
> Thus if both available PDPs are in use for IPv4+IPv6 Internet access, then
> attempts to send/recieve picture messages would (silently?) fail due to lack
> of PDP resourses.
>

Your case seems assuming only two PDP activation are allowed for each
subscriber. I'm not sure that is a common case. It may be different
with my experience. Multiple PDPs are allowed to be activated if a
subscriber intends to access separated APNs.

> Therefore, the subscriber may lost -> lose IPv6 connection in the visited
> network
> Even /if/ the two parallel PDP/PDN activations are allowed


I guess it may be worth to list your consumption, for example "in some
cases a subscriber only allowed to activate two PDP contexts, ..."

>
> 4.1.  Roaming to IPv4-only networks
> Those fallback mechanisms 'are deserved' -> 'deserve' to be implemented and
> standardized
>
>
>
> 5.  Discussions
> but didn't support /it/ well in the third generation network.
> The situations may cause the roaming issues/,/ dropping
>
>
> As an alternative solution for dual-stack, operators may change a
> unified PDP/PDN request into two separated single IP version
> requests.  However, this approach is problematic in the Charging
> records and QoS policy enforcement.  In addition, it doubles the PDP
> resource uses.  It may be unappealing for the deployment.
>
> I think you should also add 'licensing costs' to the point about additional
> PDP resource usage - that is a very significant issues in many operators.
>
Good. I will add it.

>
> There are also several other failure senarios, for example where the visited
> operator has a 'Gp' (GRX border) GTP aware firewall, and this (by design or
> inappropriate configuration) filters out GTP traffic containing certain
> flavours of IPv6 PDP requests/responses.  It may thus be approriate to
> mention that connectivity/security devices can also cause  IPv6 related
> roaming issues.


Thanks for sharing your experiences. That may be caused by incorrect
configurations on the firewall. I will add the suggestion to avoid the
issue.

>
> I agree with the comment about IR.21 - the purpose of that document (and the
> IREG testing procedure that reference it) is to ensure that such issues are
> identified and corrected such that roaming is seamless. As Deng commented to
> me on Google's mobile-ipv6-networks group several months ago, the IR.21
> appears overdue an update. However I note that IR.88 is the equivalent for
> LTE/EPC environments, so perhaps that is more appropriate ?
>
IR.88 didn't deprecate the IR.21. They cover different areas. IR.88
cited IR.21 as a reference for roaming database configuration. I would
include both for a complete view.

Best Regards

Gang


>
> /Pete
>
>
>
>
>