Hi Satoru, I have a question about vEPC.
As the UE moves around its default router changes. Which node is the default router? EPC-E? Regards, Behcet On Tue, Apr 1, 2014 at 10:07 PM, Satoru Matsushima < [email protected]> wrote: > Peter, > > > On Mon, Mar 31, 2014 at 10:18 PM, Peter McCann <[email protected]>wrote: > --snip-- > > >> > No, it isn't meant that specific routes to indicate each UEs prefix >> > are advertised into the core. >> > I'll try to improve that text in next revision of the draft. >> >> Yes please clarify because the current text seems to say that UE prefixes >> are advertised into the core. >> >> > Yes, thanks. > > > >> > I agree with you if a EPC-E has whole UE specific routes that exceed >> > its capacity, it doesn't scale, yes. In the recent presentation >> > through the webex, Ryuji were trying to explain that it's not intended >> to do. >> > Routes contained in EPC-E will be limited/partitioned by operators >> > policy, such as region, service, population scale, etc., >> >> I was a bit confused by the suggestion to partition by region, because >> there would be no mobility across regions if you partitioned in this way. >> That's because different regions would use different PDN prefixes. But, >> I suppose it would be ok to do this if you didn't need to support UE >> mobility across regions (or if you used OTT mobility such as client MIP >> for those cases). >> >> > Partitioned by region sounds like that each regional network is isolated > so that they has no connectivity between them. > But it is not what I meant. Although a PDN prefix would be partitioned by > region, the networks doesn't really need to be isolated. > For example, when all EPC-E routers have connectivity to reach all RAN > nodes, it makes easy to provide mobility across regions. > Do you think that describing in the draft this kind of networking concept > would be helpful to make things clear? > > > >> >> You seem to attempt to address this issue in Section 4.1 when you >> talk >> >> about multiple "sets" of EPC-E devices, each one dedicated to a >> given >> >> geographic region. >> > >> > >> > Ah, no. Sec 4.1 is intended to explain just scalability issue, and how >> > to deal that issues with routing techniques in operation. >> >> Ok, I guess in the most common case you would have several "slices" of >> EPC-E, each set serving a different PDN prefix and a different set of UEs. >> There would be one EPC-E from each slice, each representing a partition of >> the PDN prefixes, at each EPC-E deployment site between eNBs and core. >> A given UE's current location would need to be BGP UPDATEd to each of the >> EPC-E in the slice that covered that UE's PDN prefix. >> > > In my mind, that sounds like when an operator assign a prefix to a PDN, > the operator can divide the prefix into several longer prefixes. Each > divided prefix, let's say "sub-PDN prefix", may be allocated to a region, > or any other operator's partition policy. It doesn't need to be assign a > whole PDN prefix to a partition, or "slice" you said. > > > >> >> >> It seems to me that each "set" of EPC-E could cover no more than >> the >> >> scope covered by a single SGW today, because they each have the same >> >> amount of state as an SGW. Essentially you have described how to >> build >> >> a replicated SGW with failover to different nodes based on the >> >> re-convergence of BGP after a failure (presumably you could get the >> >> core network to react to the closure of a BGP TCP session). So I >> think >> >> this addresses the problem of fault-tolerance that has been >> identified >> >> with the tunnel-based solutions, but not really the scalability >> >> bottleneck problem. >> > >> > The nature of BGP makes easy to do that. I think Sec 3.4 would be >> > right place to explain that. But I couldn't see that flavor of text in >> > sec 4.1. Would you point which text in Sec 4.1 makes you confuse? >> >> It was the text in the penultimate paragraph that talked about >> partitioning >> by region. If you do that, there is no mobility across regions, right? >> > > As I mentioned before, mobility across regions is available. > > > >> But if you partition by PDN prefix (sets of UEs) then you can have a whole >> stack of EPC-E at each deployment site, covering the entire population of >> UEs. >> >> >> In fact, if you consider mobility from one "set" to another, if >> you >> >> want to keep the >> >> UE's IP address, you would need to broadcast the same set of PDN >> >> prefixes from all >> >> sets of EPC-E. In fact this would mean that all EPC-E throughout >> the >> >> network, even >> >> if they are in different "sets", need to be prepared to handle >> >> packets for any UE >> >> and so they ALL would need the eNB F-TEIDs for ALL UEs. Please >> tell >> >> me where I have >> >> made a mistake. >> > >> > >> > >> > No, an EPC-E just only receives packets from v6 core network toward >> > UEs that routes installed into EPC-E. Because of that an EPC-E should >> > advertise aggregated routes only for that includes its downstream UEs. >> > When the EPC-E advertises whole routes to the core as you explained, >> > yes I agree with you that won't be scalable. But it would depend on >> > EPC-E capacity and size of UE population in the network. >> >> Ok, so each EPC-E just serves a slice (set of PDN prefixes) of the UE >> population, right? There is no need to put all UEs on all EPC-Es. >> > > Right. > > cheers, > --satoru > > _______________________________________________ > dmm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmm > >
_______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
