> -----邮件原件----- > 发件人: Rajiv Asati (rajiva) [mailto:[email protected]] > 发送时间: 2013年7月2日 22:57 > 收件人: Eric Osborne (eosborne); Xuxiaohu; L3VPN > 抄送: [email protected] > 主题: RE: [nvo3] Why not use L3VPN for data center interconnect?//re: > Request a WG adoption poll for draft-xu-virtual-subnet-10 > > > > > The whole of Section 3.6 feels a little like LISP or NHRP or something. If > > this > > Very good analogy. NHRP based solution e.g. DMVPN, which is commonly used > by enterprises to build site-to-site CE-based overlay (with or without L3VPN > inside the enterprise network), fits the bill here (beyond just DCI, strictly > speaking) very well. > > Having said that, NHRP is not perceived to scale as well as that of BGP.
Fully agree. Best regards, Xiaohu > Cheers, > Rajiv > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On Behalf > > Of Eric Osborne (eosborne) > > Sent: Tuesday, July 02, 2013 8:07 AM > > To: Xuxiaohu; L3VPN > > Cc: [email protected] > > Subject: RE: [nvo3] Why not use L3VPN for data center interconnect?//re: > > Request a WG adoption poll for draft-xu-virtual-subnet-10 > > > > Hi Xiaohu- > > > > Let me first say that I agree that L3 is the way things should be built. > > But > > I'm not sure that your draft adds much to existing methods, and it seems to > > make a number of assumptions. > > > > "PE routers (i.e., > > PE-1 and PE-2) which are used for interconnecting these two data > > centers create host routes for their local CE hosts respectively and > > then advertise them via L3VPN signaling.... In fact, such subnet is a > virtual > > subnet which is emulated by using host routes." > > > > > > So if I have a /24 I will end up with (up to) 253 host addresses in the > > network? > > > > How does a PE know which hosts exist? Does it wait until it sees local ARP > > in order to determine that there is a valid /32? > > > > What happens if Host A wants to reach Host C, homed off of PE-3, but PE-3 > > does not know about Host C because it's never participated in ARP? Do I > > need to relay the ARP from PE-3 to the other PEs for the VPN? > > > > What scale benefits are there if I have to advertise all the host routes on > > my > > local portion of the subnet? Specifically, can you compare the scale > > benefits of advertising a bunch of /32s to, say, EVPN, where MAC addresses > > are basically /48 host routes? > > > > > > > > In section 3.6.1: > > > > --- > > the ingress PE router will forward the packet to the > > RR according to one of the VP routes learnt from the RR, which in > > turn forwards the packet to the relevant egress PE router > > according to the host route learnt from that egress PE router. > > --- > > > > This makes me nervous, as you've now made a Route Reflector (often a box > > with lots of CPU and memory but not necessarily much forwarding > > throughput) into basically a Broadcast/Unknown Multicast server. > > > > The whole of Section 3.6 feels a little like LISP or NHRP or something. If > > this > > is really what you're after you may want to look at how they approached this > > problem and show what's different about your solution. > > > > > > > > > > eric > > > > > > > -----Original Message----- > > > From: [email protected] [mailto:[email protected]] On Behalf > > > Of Xuxiaohu > > > Sent: Tuesday, July 02, 2013 2:52 AM > > > To: L3VPN > > > Cc: [email protected] > > > Subject: [nvo3] Why not use L3VPN for data center interconnect?//re: > > > Request a WG adoption poll for draft-xu-virtual-subnet-10 > > > > > > Hi all, > > > > > > Till now, it seems that too much attention has been paid to the use of > > > L2VPN for data center interconnect. Although there are still a few > > > clustering applications which rely on non-IP or non-routable IP > > > communications (e.g., heartbeat messages between cluster nodes), more > > > and more cluster vendors are offering clustering applications based on > > > Layer 3 interconnection. In addition, geographical high-availability > > > clusters is not a must in many data center interconnect cases. > > > > > > As L3VPN has many distinct advantages over L2VPN for data center > > > interconnect such as: scaling forwarding tables of data center > > > switches, path optimization, unknown unicast and ARP suppression... > > > why not try to use the proven L3VPN technology for data center > > > interconnect in the scenario where the limitations as mentioned above > > don't exist? > > > > > > Best regards, > > > Xiaohu > > > > > > > -----邮件原件----- > > > > 发件人: [email protected] > [mailto:[email protected]] > > > > 发送时间: 2013年7月1日 21:14 > > > > 收件人: Xuxiaohu > > > > 抄送: [email protected]; martin.vigoureux@alcatel- > > > lucent.com; > > > > L3VPN > > > > 主题: Re: Request a WG adoption poll for draft-xu-virtual-subnet-10 > > > > > > > > Hello Xuxiaohu, > > > > > > > > Before eventually starting a discussion on the adoption on this > > > > document, we chairs would like to see more discussion and have the > > > > feedback from more readers (during the 2 previous meetings, only 5 > > > > to > > > 10 > > > > people raised their hand when the room was polled on having read the > > > > document). > > > > > > > > Regards, > > > > > > > > -Thomas and Martin, > > > > l3vpn co-chairs > > > > > > > > > > > > 2013-07-01, Xuxiaohu: > > > > > Hi Thomas and Martin, > > > > > > > > > > I haven't received any response from any of you. Hence I resend it. > > > > > > > > > > Best regards, > > > > > Xiaohu > > > > > > > > > >> -----邮件原件----- > > > > >> 发件人: Xuxiaohu > > > > >> 发送时间: 2013年6月20日 15:07 > > > > >> 收件人: '[email protected]'; '[email protected]'; > > > > >> '[email protected]' > > > > >> 抄送: L3VPN > > > > >> 主题: Request a WG adoption poll for draft-xu-virtual-subnet-10 > > > > >> > > > > >> Hi WG co-chairs, > > > > >> > > > > >> As mentioned before, this draft > > > > >> (http://tools.ietf.org/html/draft-xu-virtual-subnet-10) describes > > > how to > > > > reuse > > > > >> the proven L3VPN technology to realize subnet extension for data > > > center > > > > >> interconnect, with the aid of many concrete experiments and > > > verifications. > > > > >> > > > > >> We co-authors believe the information contained in this draft > > > > >> would > > > be > > > > valuable > > > > >> for cloud service providers to evaluate the feasibility of > > > > >> adopting > > > the proven > > > > >> L3VPN technology for data center interconnection (by the way, > > > > >> some > > > people > > > > >> had shown their interests on the scheme described in this draft > > > when > > > > visiting > > > > >> our implementation demo of this scheme at the Bits-N-Bites event > > > > >> of > > > > IETF86). > > > > >> Hence we would like co-chairs to start a WG adoption poll for > > > > >> this > > > draft. > > > > >> > > > > >> Best regards, > > > > >> Xiaohu (on behalf of all co-authors) > > > > > > > > > ________________________________________________________________ > > > > _________________________________________________________ > > > > > > > > Ce message et ses pieces jointes peuvent contenir des informations > > > > confidentielles ou privilegiees et ne doivent donc pas etre > > > > diffuses, exploites ou copies sans autorisation. Si vous avez > > > recu ce > > > > message par erreur, veuillez le signaler a l'expediteur et le > > > > detruire ainsi que les pieces jointes. Les > > > messages > > > > electroniques etant susceptibles d'alteration, Orange decline toute > > > > responsabilite si ce message a ete altere, > > > deforme ou > > > > falsifie. Merci. > > > > > > > > This message and its attachments may contain confidential or > > > privileged > > > > information that may be protected by law; they should not be > > > > distributed, used or copied without authorisation. > > > > If you have received this email in error, please notify the sender > > > > and > > > delete this > > > > message and its attachments. > > > > As emails may be altered, Orange is not liable for messages that > > > > have > > > been > > > > modified, changed or falsified. > > > > Thank you. > > > > > > _______________________________________________ > > > nvo3 mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/nvo3
