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. 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 > >
_______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
