Liu, Yes, scalability issue is not discussed on the draft. Thanks for good clarification. Since EPC-E has two side of network that one is RAN side and another is core side, scalability issue is not only on this architecture. The core side could be the size of grobe as the Internet scale. But RAN side, an operator would separate to some networks by region, or population, whatever. So the question is to about how big the area will be to support is a requirement of each operator.
There could be multiple EPC-E routers are deployed to support multiple RAN, or to solve scalability issue which huge number of MN population that exceed the capacity of single EPC-E. This architecture should cover all of these scenarios by routing basis strategy, so we'll update the draft in a next version. thanks! --satoru On Fri, Jul 12, 2013 at 6:11 PM, Liu Dapeng <maxpass...@gmail.com> wrote: > Hi Satoru, > > Then the question is how big this area will be to support all the > users of an operator? > > regards, > Dapeng Liu > > 2013/7/12 Satoru Matsushima <satoru.matsush...@gmail.com>: > > Liu, > > > > MN's prefixes could be converged into an aggregated route. It is > routing. So > > MN are always expected within the area where it covers as long as the > > aggregated route existed in the core network. > > > > cheers, > > --satoru > > > > > > On Fri, Jul 12, 2013 at 10:59 AM, Liu Dapeng <maxpass...@gmail.com> > wrote: > >> > >> 2013/7/12 Satoru Matsushima <satoru.matsush...@gmail.com>: > >> > Hi Liu, > >> > > >> > Thanks for your good question. We, bgp operator are struggle fast > >> > convergence for bgp that most of the issues come from best path > >> > recalculation on bgp speaker. In the proposed architecture we expect > no > >> > such > >> > kind of recalc but just simple update to epc-e from vepc. BGP is an > >> > incremental routing protocol so that bgp should be capable to > >> > continuously > >> > update route to mobile nodes as they moving. Please noted that it is > >> > happened only on RAN facing side on epc-e, not on ipv6 core network > >> > side. > >> > >> [Dapeng] You mean the MN's prefix can be converged in the core network? > >> You can > >> do this when the MN moves in a small area, but if the MN moves out > >> from that area, > >> it is difficult to converge. > >> > >> Thanks, > >> Dapeng Liu > >> > >> So > >> > routing in ipv6 core can be much stable. > >> > > >> > cheers, > >> > --satoru > >> > > >> > > >> > > >> > > >> > On Fri, Jul 12, 2013 at 12:24 AM, Ryuji Wakikawa > >> > <ryuji.wakik...@gmail.com> > >> > wrote: > >> >> > >> >> Hi Liu > >> >> > >> >> For routing update matter, I will let my colleague to answer this. > >> >> The routing update is happened just within an operator's network. > >> >> The route for UE is just overwritten with the new information. I > >> >> believe > >> >> BGP can easily handle these updates. > >> >> > >> >> We haven't discussed billing and roaming. but what we are thinking > now > >> >> is > >> >> following. > >> >> If special treatment is needed (like roaming), we keep using the > >> >> original > >> >> EPC functions available at NFV. Packets are routed to EPC U-/C-planes > >> >> on > >> >> NFV. > >> >> For billing, we need some mechanism between U-/C- plane and didn't > >> >> identify a solution yet. We will try to identify it at the next > >> >> revision. > >> >> > >> >> thanks > >> >> ryuji > >> >> > >> >> On Jul 11, 2013, at 1:12 AM, Liu Dapeng <maxpass...@gmail.com> > wrote: > >> >> > >> >> > Hi Ryuji, > >> >> > > >> >> > Thanks for posting an very interesting draft. Build distributed > >> >> > mobility using BGP has been discussed in DMM before. For example: > >> >> > http://tools.ietf.org/html/draft-mccann-dmm-flatarch-00. > >> >> > > >> >> > My comments: > >> >> > 1. How to deal with routing fluctuation problem? Using BGP in > Boeing > >> >> > on-board system is quite different from mobile network. Boeing > >> >> > on-board system normally does not have too much mobile node (the > >> >> > flight is only one mobile node), but for the mobile network, there > >> >> > could be hundreds of millions of mobile nodes keep moving and will > >> >> > result in lots of routing updates. > >> >> > > >> >> > 2. Billing and policy enforcement is not discussed in the draft. Do > >> >> > you have any thoughts on this? > >> >> > > >> >> > Thanks, > >> >> > Dapeng Liu > >> >> > > >> >> > 2013/7/11 Ryuji Wakikawa <ryuji.wakik...@gmail.com>: > >> >> >> Hi > >> >> >> > >> >> >> We submit a new document. Your comments are appreciated! > >> >> >> > >> >> >> thanks, > >> >> >> ryuji > >> >> >> > >> >> >> > >> >> >> Begin forwarded message: > >> >> >> > >> >> >>> From: internet-dra...@ietf.org > >> >> >>> Subject: New Version Notification for > >> >> >>> draft-matsushima-stateless-uplane-vepc-00.txt > >> >> >>> Date: July 10, 2013 9:09:44 AM PDT > >> >> >>> To: Ryuji Wakikawa <ryuji.wakik...@gmail.com>, Satoru Matsushima > >> >> >>> <satoru.matsush...@g.softbank.co.jp> > >> >> >>> > >> >> >>> > >> >> >>> A new version of I-D, > draft-matsushima-stateless-uplane-vepc-00.txt > >> >> >>> has been successfully submitted by Satoru Matsushima and posted > to > >> >> >>> the > >> >> >>> IETF repository. > >> >> >>> > >> >> >>> Filename: draft-matsushima-stateless-uplane-vepc > >> >> >>> Revision: 00 > >> >> >>> Title: Stateless user-plane architecture for > >> >> >>> virtualized EPC (vEPC) > >> >> >>> Creation date: 2013-07-10 > >> >> >>> Group: Individual Submission > >> >> >>> Number of pages: 19 > >> >> >>> URL: > >> >> >>> > >> >> >>> > http://www.ietf.org/internet-drafts/draft-matsushima-stateless-uplane-vepc-00.txt > >> >> >>> Status: > >> >> >>> > >> >> >>> > http://datatracker.ietf.org/doc/draft-matsushima-stateless-uplane-vepc > >> >> >>> Htmlized: > >> >> >>> > >> >> >>> > http://tools.ietf.org/html/draft-matsushima-stateless-uplane-vepc-00 > >> >> >>> > >> >> >>> > >> >> >>> Abstract: > >> >> >>> We envision a new mobile architecture for the future Evolved > >> >> >>> Packet > >> >> >>> Core (EPC). The new architecture is designed to support the > >> >> >>> virtualization scheme called NFV (Network Function > >> >> >>> Virtualization). > >> >> >>> In our architecture, the user plane of EPC is decoupled from the > >> >> >>> control-plane and uses routing information to forward packets of > >> >> >>> mobile nodes. Although the EPC control plane will run on > >> >> >>> hypervisor, > >> >> >>> our proposal does not modify the signaling of the EPC control > >> >> >>> plane. > >> >> >>> The benefits of our architecture are 1) scalability, 2) > >> >> >>> flexibility > >> >> >>> and 3) Manageability. How to run the EPC control plane on NFV > is > >> >> >>> out > >> >> >>> of our focus in this document. > >> >> >>> > >> >> >>> > >> >> >>> > >> >> >>> > >> >> >>> The IETF Secretariat > >> >> >>> > >> >> >> > >> >> >> _______________________________________________ > >> >> >> dmm mailing list > >> >> >> dmm@ietf.org > >> >> >> https://www.ietf.org/mailman/listinfo/dmm > >> >> > > >> >> > > >> >> > > >> >> > -- > >> >> > > >> >> > ------ > >> >> > Best Regards, > >> >> > Dapeng Liu > >> >> > >> > > >> > >> > >> > >> -- > >> > >> ------ > >> Best Regards, > >> Dapeng Liu > > > > > > > > -- > > ------ > Best Regards, > Dapeng Liu >
_______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
