> > 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?
I would say - No, since that would equate to flooding layer 2 frames in an L3VPN environment. The traffic to an unknown host should be eventually dropped (closer to the source point) in any L3 environment, IMO. Cheers, Rajiv > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Xuxiaohu > Sent: Tuesday, July 02, 2013 9:11 PM > To: Eric Osborne (eosborne); 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 Eric, > > Thanks for your comments. Please see my reply inline. > > > -----邮件原件----- > > 发件人: [email protected] [mailto:[email protected]] 代表 Eric > > Osborne (eosborne) > > 发送时间: 2013年7月2日 20:07 > > 收件人: 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 > > > > Hi Xiaohu- > > > > Let me first say that I agree that L3 is the way things should be > > built. But > > That's great. > > > 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? > > Yes. > > > 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? > > ARP is just one possible approach for CE host discovery. You can also use > other approaches (e.g., an orchestration system) to fill this goal. > > > 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? > > The basic assumption of this draft is that local PE routers could timely > discover their own local CE hosts through a given approach. However, the > approach you proposed may be worthwhile to be considered in this draft. > > > 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? > > Almost the same from the forwarding table size perspective. And both can > suppress the unknown uncast flooding. However, from the maturity degree > of technology and product and the operation experience perspectives, > L3VPN is absolutely a better choice, IMHO. > > > 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. > > As mentioned just after the text you quoted, > > "... Note that in the case where the RR is > not available for transferring L3VPN traffic between PE routers > for some reason (e.g., the RR is implemented on a server, rather > than a router), the APR function could actually be performed by a > given PE router other than the RR as long as that PE router has > installed all host routes belonging to the virtual subnet into its > FIB." > > > 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. > > Your observation is correct. To some extent, LISP can be looked as another > type of L3VPN approach. Furthermore, LISP-mobility is another type of host > route based subnet extension approach just like the one defined in this > draft. It's up to the cloud providers to make a choice between L3VPN and > LISP. BTW, if you were a cloud provider, which one would you choose in > practice? > > Best regards, > Xiaohu > > > 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 > > _______________________________________________ > > nvo3 mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/nvo3
