Re: [v6ops] I-D Action: draft-chen-v6ops-ipv6-roaming-analysis-02.txt

["Heatley, Nick" <[e-mail]>]

Hi there Gang,
A useful draft thank you.

Some comments that, from my perspective, would make the content clearer. By all means take them or leave them :-))

Section 3
-Defining "failure" in this draft - in general I infer fallback is a success -so  you could adapt the middle sentences:
>There may be a mismatch between the subscriber request and network capability. In 3GPP networks a mismatch between the UE request and the bearer network could result in bearer negotiation and a fallback to a common bearer type. The failures here can be a result of no common bearer type existing and the UE is left disconnected. Or in the case of local breakout a failure could result from network functionality that is assumed by the UE configuration being absent in the visited network. The following table lists the potential failure cases.

Section3 - Table1
- I would prefer to say that the UEs request IPv4v6, rather than dual stack. That is also what you have defined at the start of section 3.
- I would prefer to see two tables in this section, one covering Home routing and one covering local breakout, because of the following specific comments
- Do you need to define what you mean by Dual Stack for the "Visited Network Capability"? I am wondering, in the case of Home routing, if "Visited Network Capability" is better expressed as "PDN/PDP IP Type permitted"? Then "dual stack" could become "all PDN/PDP IP types"? What do you think? 
Either way "dual stack" may leave some ambiguity to some readers not familiar with 3GPP networks here (especially as the terms appears in section 4.2. in association with separate single-IP-type PDP).
- The failure cases are potential failure cases - for the home routing table, I would like to see a middle column which describes "success" whether request is granted or a suitable fallback, as would be expected when visited networks are ready e.g. In an IPv4-only capable visited network, the terminal can request IPv4v6 and be downgraded to IPv4 PDP. I'd like to see all possible cases listed then, for example adding IPv4v6 request to "Dual Stack" visited network. If adding such a column is undesirable, then at least stressing that there is a *risk* of these failure cases, they are not an architectural certainty.
- So the current columns capturing failures could be labelled "potential failure cases (Home Routing)"
-Where there are no possible failure cases identified then "None" could replace "OK"
-To be clear I'd change"IPv6-only with 464xlat" to "IPv6-only (where UE is 464xlat enabled)" or similar. As this case is only highlighted for local breakout, then I'd not list it in the Home Routing table.

Section 4
- Would it make sense to keep section 4 as the "problem definition" text and split out the "mitigations" text? I am thinking some of the mitigations will mitigate more than one failure case?

Section4.2
-I am not clear whether failure case 2 is a failure or just a warning of knock-on effects? What is recommended at the home network or the visited network?
Would the approach of roaming profiles in HSS of section 4.1. also help here? Etc.

Section4.3.
>Since IMS roaming architecture will offload all traffic in the visited network
-Is this mandatory in all cases? I would suggest:
>In the IMS roaming architecture when traffic is offloaded in the visited network....

The next sections I must admit I found difficult - it may be my lack of understanding so apologies if so!
I assume you are trying to cover local breakout for both Data and IMS Voice use cases.

Section4.4.
-I am confused why this failure is not also applied to Home routing i.e. if visited network permits only IPv4 PDP?
Now I am wondering whether I understood the authors' intentions for "Visited Network Capability" column, if this is not a potential failure for Home Routing?
For local breakout do you mean specifically that the local breakout path at and beyond the GGSN /PGW is "IPv4-only" though the SGSN/SGW may allow all PDP/PDN types?
I would split out local breakout case into a table2, so the appropriate columns can be created and labelled.

Section 4.5
- So this is a local breakout issue where local DNS/NAT functionality is to be used?
-However, looking back at the table, a 464xlat capable UE could start by requesting IPv4v6, receive an IPv6 PDP, and try to invoke the CLAT functionality, could it not? 
So then it can go on to have the problems of case5. The bearer requested by the UE seems less relevant. Perhaps there are extra parameters assumed in the Local Breakout scenarios that I am missing e.g. the local breakout APN settings?; something more relevant to the case than what "UE requests"? I am not so familiar with all the local break out scenarios, but I would again suggest a separate table 2 for local breakout so that we can link the scenarios appropriately.
- Is the AAA server a solution for local breakout? I thought this was described by Dave as a Home Routing solution? The text is reasonable, just not sure why it appears specifically  in this section?

I hope this is useful.
Best Regards,
Nick Heatley


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of GangChen
Sent: 04 November 2013 17:50
To: v6ops
Cc: <[e-mail]>
Subject: [v6ops] I-D Action: draft-chen-v6ops-ipv6-roaming-analysis-02.txt

Wg,

We submit the new draft of IPv6 roaming. Please kindly check.
Your comments are appreciated

BRs

Gang

2013/11/5, [e-mail] <[e-mail]>:
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
>
>
> 	Title           : IPv6 Roaming Behavior Analysis
> 	Author(s)       : Gang Chen
>                           Hui Deng
>                           Dave Michaud
>                           Jouni Korhonen
>                           Mohamed Boucadair
>                           Vizdal Ales
>                           Cameron Byrne
> 	Filename        : draft-chen-v6ops-ipv6-roaming-analysis-02.txt
> 	Pages           : 12
> 	Date            : 2013-11-04
>
> Abstract:
>    This document intends to enumerate failure cases when a IPv6
>    subscriber roams into visited network areas.  The investigations on
>    those failed cases reveal the causes in order to notice improper
>    configurations, equipment's incomplete functions or inconsistent IPv6
>    strategy.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-chen-v6ops-ipv6-roaming-analysi
> s
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-chen-v6ops-ipv6-roaming-analysis-02
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-chen-v6ops-ipv6-roaming-analysi
> s-02
>
>
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at 
> tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
_______________________________________________
v6ops mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/v6ops
NOTICE AND DISCLAIMER
This e-mail (including any attachments) is intended for the above-named person(s).  If you are not the intended recipient, notify the sender immediately, delete this email from your system and do not disclose or use for any purpose.  
 
We may monitor all incoming and outgoing emails in line with current legislation. We have taken steps to ensure that this email and attachments are free from any virus, but it remains your responsibility to ensure that viruses do not adversely affect you. 

EE Limited
Registered in England and Wales
Company Registered Number: 02382161
Registered Office Address: Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9BW