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

[GangChen <[e-mail]>]

Hi David,

2013/7/18, [e-mail] <[e-mail]>:
> Hi
>
> Some comments below
> David
>
>> -----Message d'origine-----
>> De : [e-mail] [mailto:[e-mail]]
>> De la part de GangChen
>> Envoyé : jeudi 18 juillet 2013 10:46
>> À : Tore Anderson
>> Cc : [e-mail]
>> Objet : Re: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis
>>
>> 2013/7/18, Tore Anderson <[e-mail]>:
>> > * GangChen
>> >
>> >> Thanks for sharing your experience. Yes, you are right.
>> >> There is no such issue if the subscriber's traffic get back to the
>> >> gateway (e.g. GGSN) in the home network.
>> >> The described failure case occurred when the subscriber get an
>> >> address from the GGSN in the visited network. And traffic
>> flows would
>> >> be transmitted in a local-breakout manner.  3GPP allows such
>> >> local-breakout because it has more efficient routing
>> paths. 3GPP also
>> >> specified another architecture called "SIPTO". It guarantees the
>> >> subscriber would always select the closest GGSN to reside.
>> >
>> > I see. When roaming, I always get an IP address that belongs to my
>> > home provider (this goes both for IPv4 and IPv6), so I
>> assume that it
>> > is the home network's choice whether or not to enable this
>> "use closest GGSN"
>> > feature?
>>
>> Yes, those behaviors could be gauged by subscriber's profile.
>> For example, disable local-break-out
> David: Do you mean that you will use the "VPLMN address allowed" flag in the
> HLR ? Generally this flag is set to false and Home Routed is used by
> operators.
> Use of Local Break Out means also that the APN name is recognized in visited
> network.
> I think it could be useful to include Local Break Out scenario in this
> document as it is envisaged at least for IMS services.

Some cases in the draft already assume local breakout condition. But I
guess it should be clarified in the next version.

>>
>> > If so, I'd suggest adding some text that ensuring this feature is
>> > disabled (at least for the IPv6 PDP type, if it is possible to
>> > differentiate between the two) is a good way to prevent IPv6
>> > subscribers from experiencing problems when roaming in
>> IPv4-only networks.
>>
>> Good suggestion. I would add the point in the next update.
> David: Actually IPv6 PDP context has been specified for quite a long time
> and it is well supported in devices.

In the previous message
http://www.ietf.org/mail-archive/web/v6ops/current/msg17187.html
Dave reported "Section 4.1 makes an assumption about support for IPv6
that has been in
place for as long as IPv4 and it is well supported. Given that this is an
optional feature that must be turned-on on vendor equipment, it¹s not
really the case."

I will add texts to suggest turn-on the IPv6 support

> As far as charging architecture is OK
> and visited operators does not filter
> IPv6, I do not think it is the main issue in roaming context.

If there is no breakout, IPv6-only doesn't have the issue.


> IPv4v6 PDP
> context may bring more issues, in particular, if some visited SGSNs do not
> behave as they should do, considering unknown PDP
> contexts as IPv4 ones.

I agree. We should consider that seriously

BRs

Gang

>>
>> Best Regards
>>
>> Gang
>>
>> > Tore
>> >
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
>