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

[Jouni Korhonen <[e-mail]>]

Gang,

On Jul 20, 2013, at 5:07 PM, GangChen <[e-mail]> wrote:

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


The above are good examples that the draft needs to be much more exact
what it tries to say.  Specifically it needs to describe the assumed
network environment & configuration.

- Jouni





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