I admit that that the bulk of roaming issues seem to go away if you never have local breakout, and all traffic passes to home network in the GTP tunnel, but somebody better tell that to the guys designing the next generation of voice.
-----Original Message----- From: Nick Heatley Sent: 04 December 2009 10:12 To: 'Xiangsong Cui'; Hui Deng; Sri Gundavelli; [email protected] Cc: [email protected] Subject: RE: Transition roadmap // Re: [Softwires] Host based translation: v4-v6 Hi Xiangsong, Subject line is good, perhaps even "Mobile Transition" :-) (My last mail didn't redistribute so perhaps I broke the rules?) My assumptions or opinions, if I am short-sighted please let me know: - the operator controls the bearer network and UE to some extent, so for the operator the transition starts here IMHO, regardless of what happens regarding the Content. - dual stack UE is compulsory if you wish to support roaming, as visited networks may require a fall back to IPv4. Otherwise roaming partners need to allow IPv6 PDP in coordination (I don't see this "flag day" in any standards?). - bearer network can have the capacity for dual stack, but what you offer each UE is selected by the network, then network can choose to offer a dual stack UE an IPv6-only bearer. If you want to support roaming visitors to your network then continued support of IPv4-only UEs is mandatory. So a true IPv6-only bearer network seems false to me. - from my view in Western Europe, shortage of public addressing for App Servers is not an issue at all. We are concerned with exhaustion of UE addressing. Is that true in other markets? (Therefore dual stack of App Servers where app allow, seems to be a prerequisite). - As above UEs need to be dual stack for roaming. I would not turn off that functionality. But any other change to the UE better be worth it - I agree UE functionality should otherwise be stripped down for cost. - I don't understand your transition, do you mean the network literally can only support IPv6-only? - My overall customer-centric opinion: I want to move to IPv6 in the long-term. But I don't want the exhaustion of IPv4 addressing, especially the artificial and arbitrary deadline provided by the 17 million private addressing to set my IPv6 introduction date. I want to do it when the customer experience offered by IPv4 is matched by IPv6. So in summary I don't support an aggressive move to IPv6 without the customer experience, non-standard changes to the UE client that I have to pay for, and I must support roamers and roaming in a universal way. Regards, Nick -----Original Message----- From: Xiangsong Cui [mailto:[email protected]] Sent: 04 December 2009 03:05 To: Nick Heatley; Hui Deng; Sri Gundavelli; [email protected] Cc: [email protected] Subject: Transition roadmap // Re: [Softwires] Host based translation: v4-v6 Dear Nick, Thank you very much for your detailed clarification!! > Your comment raises more requirements/assumptions that need to be > established. OMG, I just wanted to simplify the discussion, that is not my intention :) Since our discussion goes to another direction now, I would rename the subject. I do agree that the pace is very important, and in my understanding, you mean transition mainly starts from UEs, then bearer network, then App Server, is that correct? follow this rule, I have some additional questions, 1) for UEs, do you mean Dual Stack is very necessary? or recommended? 2) for bearer network, is it possible that IPv4 only network changes to IPv6 only network directly? if DS bearer network is taken as a middle phase, may DS functionality only be provided by some key gateways? 3) for the App Servers, is the exhaustion of IP address a severe issue? In this roadmap, the key point is the UE, UEs need to support more function. But, in fact, if the UEs do that, the price will be increased, it seems that the users and UE vendors don't like that, so the transition goes slowly? In my mind, I am thinking another roadmap, transition starts from the bearer network, and then UEs, and then App Servers. As you said, the main driver for IPv6 transition is the exhaustion of IP address, operator is the most related player on this issue. And since the bearer network has to go to IPv6 in any approaches, why not do it firstly? In this approach, UEs maybe get benefits after the bearer network has already been IPv6, For example, if the users can reduce the traffic amount, comparing to first approach, tunnel is reduced, so the traffic amount may also be reduced, this can save users' money, so users would like to pay a bit more money for these updated UEs, and the UE vendors would like to accept this roadmap, too. So IPv6 transition would goes easier. Maybe operators may also get additional benefit from this fast IPv6 transition. I am not sure is that correct, because it depends on accounting and other aspects. What do you think about that? Thanks and regards Xiangsong ----- Original Message ----- From: "Nick Heatley" <[email protected]> To: "Xiangsong Cui" <[email protected]>; "Hui Deng" <[email protected]>; "Sri Gundavelli" <[email protected]>; <[email protected]> Cc: <[email protected]> Sent: Thursday, December 03, 2009 7:26 PM Subject: RE: [Softwires] Host based translation: v4-v6 Dear Xiangsong, Your comment raises more requirements/assumptions that need to be established. There seems to be two sets of drivers: 1) exhaustion of IP addressing for UEs only 2) exhaustion of IP addressing for UEs and Servers 1) could be exhaustion of private addressing or public addressing. 2) leads to an additional focus on supporting the IPv6-only App server, where as 1) does not. I would suggest that currently operators may be in different positions in relation to these drivers. This really drives whether they wish to go straight to IPv6-only bearer networks (potentially higher demand for IPv6 content) or go through a phase of dual stack bearer network support. (Does Gateway-Initiated Dual Stack-lite stop the move to IPv6? IMHO the answer is NO, but it is not an aggressive move to IPv6-only. P-NAT is an aggressive move to IPv6-only bearer network.) A second assumption for an operator - will the operator provide access to IPv6-only Apps via an IPv4-only bearer network? My opinion: I expect many operators will not. This is my assumption. (IMHO this decision ensures there remains a valid reason for every operator to move to support IPv6, with the Content Providers setting the pace. But if IPv6-only content is niche in your market, then it may not happen at the same pace as UE address exhaustion.) My opinions: As a mobile operator I suggest that both "user" and "carrier" drivers (as you state) are somewhat in my control. I have a lot of control over the UEs and what they support. My primary goal: I must guarantee the user experience. And yes I agree, the end customer mainly does not care for IPv6 or IPv4, just good service, right? So points of interest in the App Server debate are these use cases: A) IPv4 only-app -> Dual Stack UE -> IPv6-only bearer -> IPv6 only server B) IPv4 only-app -> Dual Stack UE -> IPv6 only bearer -> IPv4 only server If the bearer network is dual-stacked then B) is trivial. If you believe your eco-system follows drivers in 1) then you can dual stack your server and network and A) becomes simple. Or in other words IPv6-only App servers are niche. But if you follow drivers 2) then you expect IPv6-only servers to be common place for your mass-market. To summarise, operators need to think about whether they go for an aggressive move to an IPv6-only bearer network approach or not. To make that decision I would say one of the factors is about content provider networks and the relative pace at which IPv6-only content is appearing compared to UE IP address exhaustion. (UEs functionality plays a massive part as well!). I welcome further discussion :-) Regards, Nick T-Mobile T-Mobile (UK) Limited Company Registered Number: 02382161 Registered Office Address: Hatfield Business Park, Hatfield, Hertfordshire, AL10 9BW Registered in England and Wales NOTICE AND DISCLAIMER This email (including attachments) is confidential. 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. _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
