Correct
2009/12/4 Nick Heatley <[email protected]>: > 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
