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

[GangChen <[e-mail]>]

2013/7/19, 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.

I just realize we may have different definition for "IPv4 network". In
my understanding, visited SGSN could implement PDP Type IPv6 in an
IPv4 network . But visited GGSN restricts IP address assignment only
to PDP type IPv4.

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

The issue is not about SGSN receiving an unknow PDP request. That is
the home HSS sends the extended attribute for dual-stack as
a part of the subscriber profile. But old SGSN can't parse the
information and result failed registration.

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

That is a good clarification. We would add that in the next update.

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

Thanks for the correction.


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

We would try to figure out the combination.


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

Good. We will add it

Best Regards

Gang

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