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
