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

[Jouni Korhonen <[e-mail]>]

Hi,

On Jul 19, 2013, at 10:36 AM, GangChen <[e-mail]> wrote:

> Jouni,
> 
> 2013/7/18, Jouni Korhonen <[e-mail]>:
>> 
>> Gang,
>> 
>> I was more like thinking of IR.33, TAP documents and the IPv6 white paper,
>> etc stuff that GSMA has worked on. I think aligning with GSMA is important
>> since they are far more important for 3GPP roaming aspects than any IETF
>> document.
>> 
>> Then some other notes. When reading the draft I always get confused
>> when the draft assumes local breakout, when home routed traffic and
>> when a specific "phenomenon" is due visited/home APN/HLR intentional
>> configuration, licensing restriction or some known implementation
>> issue on some vendor equipment. Also some behaviour are due the UE
>> specific implementation beyond what 3GPP specs say. I would encourage
>> to detail these assumptions out on each claim/description so that
>> possible readers can map the issues to their deployments easier
>> without guesswork.
> 
> I noticed that after the discussions on the list. We will complete the
> descriptions to detail the assumed conditions. Also the GSMA document
> would be cited to align the consideration.
> 
>> In Section 3.1 it states:
>> 
>>  "Subscriber Server).  When the subscriber roams to the IPv4 network,"
>> 
>> Does this mean the visited SGSN would not implement PDP Type IPv6?
> 
> The reason is visited SGSN doesn't support PDP Type IPv4v6, other than
> PDP type IPv6. PDP type IPv6 has well been supported AFAIK.

Ok. But then what you write is not really what you intend to say. The network
in not IPv4 network, since it implements the IPv6 PDP Type. It is just the
standardized behavior that a Gn-based SGSN treats an unknown PDP Type as IPv4
PDP Type. In this case where a visited SGSN does understand IPv6 but not IPv4v6,
then it treats the context request as IPv4. That is different from the network
being IPv4.

Also, I would be careful when using SGSN and PDP Type IPv4v6. A Gn-based SGSN
had PDP Type IPv4v6 supported from Rel-9 onwards but S4-SGSN had since Rel-8. 
Also the treatment of unknown PDP/PDN type can be different from SGSN and S4-SGSN.

>> I know such exist(ed) but how common are those on live today?
> 
> When we do IPv6 trials, we have to upgrade all SGSN to understand PDP
> Type IPv4v6. I also had some discussions with other operator
> colleague. They also have same issues.

I was talking about IPv4 _only_ SGSNs. Those were around and are still
possible e.g. due licensing/configuration.. not that it would make any
sense to have an IPv4-only SGSN around..

>>  "land to retrieve the subscriber profile.  Roaming with IPv4v6 type in
>>   the subscriber profile may cause issues because the visited SGSN/SGW
>>   can't parse the information.  The subscriber is failed to register in
>>   this case."
>> 
>> I guess you mean above SGSN/MME.. an SGW not implementing IPv4v6 would
>> be kind of surprising. I have seen a MME that did not implement IPv4v6 very
>> early of rel-8 testing phase, though.
> 
> If I correct, SGSNs introduce IPv4v6 since Release-8; SGWs introduces
> IPv4v6 since Release-9. You may be right it's a rare case if SGW

Just the other way around. However, S4-SGSN had PDN Type IPv4v6 since Rel-8.

> doesn't implement IPv4v6. The failure cases we are facing are mainly
> on SGSN.  SGW is listed just because the rel-8 SGW implementations.
> Thank you for the information there is no such case in the real world.
> We will update the draft with your comments accordingly.
> 
>> Here I would like to see text
>> describing what is the actual failure scenario when the subscriber gets
>> no connection at all. I know one SGSN+HLR combination which is very
>> unlikely to happen in commercial networks.
> 
> The failure scenario is subscriber can't register to the visited
> network. Would you mind to add something to help me understand what's
> your expected texts here?

Just list exactly what is configured in HLR, supported by SGSN and GGSN,
configured in GGSN and what the UE requests for. The combination and the
description why the combination fails is what people are interested in, IMHO. 

For the completeness, I would also like to see some discussion on the
DAF flag configuration in SGSN/MME, which also affects the context
creation end result.


>> 
>> In Section 3.2. it states:
>> 
>>  "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.  For example, IPv6 PDP/PDN would be rejected if
>>   the subscriber has an active IPv4 PDP/PDN.  Therefore, the subscriber
>>   may lost IPv6 connection in the visited network.  Even the two"
>> 
>> I am confused here. Are we assuming visited GGSN here?
> 
> Yes. The local breakout is considered here.
> 
>> 
>> In Section 4.1. it states:
>> 
>>  "requested protocol and always adhere to IPv4 when roaming.  Those
>>   fallback mechanisms are deserved to be implemented and standardized
>>   timely."
>> 
>> Does the standardization mean fallback mechanisms beyond what 3GPP
>> already defined?
> 
> A proper fallback mechanism is not defined in 3GPP.  The advocated
> standardization more likes to do defacto standard. But the suggestion
> is align with cuurent 3GPP spec. And some implementations are
> available.

Ok.

- JOuni


> 
> Best Regards
> 
> Gang
> 
> 
>> - Jouni
>> 
>> On Jul 15, 2013, at 6:28 PM, GangChen <[e-mail]> wrote:
>> 
>>> 2013/7/15, Jouni Korhonen <[e-mail]>:
>>>> 
>>>> Gang,
>>>> 
>>>> Regarding roaming in general, have you looked at what GSMA is doing
>>>> on this front? I was kind of expecting at least a reference to some
>>>> GSMA document since they are quite important when it comes to 3GPP
>>>> based networks & roaming.
>>> 
>>> I guess GSMA IR.21 could be cited here.
>>> http://www.gsma.com/newsroom/wp-content/uploads/2012/06/IR2180.pdf
>>> Most failures cases are occurred if a roaming partner's IR.21 only
>>> states v4 support
>>> 
>>> -g
>>> 
>>> 
>>>> 
>>>> - Jouni
>>>> 
>>>> 
>>>> On Jul 15, 2013, at 5:56 AM, GangChen <[e-mail]> wrote:
>>>> 
>>>>> Hi Alexis,
>>>>> 
>>>>> Thanks for the interests. We are experiencing the issues recently when
>>>>> IPv6 is tested/deployed. For the goal of the draft, it reports that to
>>>>> the community and hopes to mature IPv6 supports either by encouraging
>>>>> proper implementations on mobile terminals or completing global
>>>>> roaming contracts.
>>>>> 
>>>>> Your reviews/comments are appreciated
>>>>> 
>>>>> BRs
>>>>> 
>>>>> Gang
>>>>> 
>>>>> 2013/7/9, Alexis Munoz (Gmail) <[e-mail]>:
>>>>>> It looks so interesting. I will check it and I will give you my
>>>>>> comments
>>>>>> very soon.
>>>>>> 
>>>>>> Thanks,
>>>>>> 
>>>>>> Alexis Muñoz
>>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: [e-mail] [mailto:[e-mail]] On Behalf
>>>>>> Of
>>>>>> [e-mail]
>>>>>> Sent: Tuesday, July 09, 2013 7:45 AM
>>>>>> To: [e-mail]
>>>>>> Cc: [e-mail]
>>>>>> Subject: [v6ops] new draft: draft-chen-v6ops-ipv6-roaming-analysis
>>>>>> 
>>>>>> 
>>>>>> 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
>>>> 
>>>> 
>> 
>>