Re: New Version Notification for draft-matsushima-stateless-uplane-vepc-00.txt

2013/7/12 Satoru Matsushima <[email protected]>:
> 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 <[email protected]>
> 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 <[email protected]> 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 <[email protected]>:
>> >> Hi
>> >>
>> >> We submit a new document.  Your comments are appreciated!
>> >>
>> >> thanks,
>> >> ryuji
>> >>
>> >>
>> >> Begin forwarded message:
>> >>
>> >>> From: [email protected]
>> >>> Subject: New Version Notification for
>> >>> draft-matsushima-stateless-uplane-vepc-00.txt
>> >>> Date: July 10, 2013 9:09:44 AM PDT
>> >>> To: Ryuji Wakikawa <[email protected]>, Satoru Matsushima
>> >>> <[email protected]>
>> >>>
>> >>>
>> >>> 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
>> >> [email protected]
>> >> https://www.ietf.org/mailman/listinfo/dmm
>> >
>> >
>> >
>> > --
>> >
>> > ------
>> > Best Regards,
>> > Dapeng Liu
>>
>



--

------
Best Regards,
Dapeng Liu