Hi Peter,
On Sat, Mar 29, 2014 at 3:32 AM, Peter McCann <peter.mcc...@huawei.com>wrote: > Ryuji, > > After viewing your slides from the presentation you did overnight (sorry I > couldn't > be on the call) I went back and re-read the > draft-matushima-stateless-uplane-vepc-02 > draft. I am still confused about a number of things: > Thanks. Let me try to answer your questions. > > You show in Figure 4, step 15 a Route Update (is this a BGP UPDATE?) going > from the > EPC-E to the core network RTR, containing a Destination of UE-prefix and a > Next-Hop > of EPC-E address. However, in Section 3.4, you describe the RTR as > knowing only the > PDN prefix, which is the same for all EPC-E, and the use of "hot-potato" > routing to > deliver the packets to the nearest EPC-E no matter the UE destination IP > address. > > Which one is it? Are the UE prefixes advertised into the core or not? > 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. > > Assuming for now that the UE prefixes are not advertised into the core, > but only the > PDN prefixes are advertised, then that means that every EPC-E must know > about every > UE session, including the eNB F-TEID for every UE in the network, correct? Yes, it's correct. > That's because any one of them at any time could receive a packet for the > UE from the core. > This doesn't seem scalable to me. > 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., > > 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. > 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? > > 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. cheers, --satoru
_______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
