Fully agree. Lucy -----Original Message----- From: Jon Hudson [mailto:[email protected]] Sent: Wednesday, August 01, 2012 6:24 PM To: James Kempf Cc: Lucy yong; Xuxiaohu; [email protected]; [email protected] Subject: Re: [nvo3] Is it too earlier to make a choice from L2 and L3-based NV solutions?
Thank you!!!!!! Many users believe that their L2 switches are running L3 code because they set a static ipaddr on the management interface. Limiting possible solutions by caging NVo3 to L2 or L3 is.....not an efficient use of the valuable NVo3 resources. On Jul 31, 2012, at 5:50 PM, James Kempf <[email protected]> wrote: > Is anybody going to care if the WG makes a choice? People are out there > deploying stuff. > > I don't think the WG should make a choice. I think it should confine itself > to the charter. > > jak > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On >> Behalf Of Lucy yong >> Sent: Tuesday, July 31, 2012 2:38 PM >> To: Xuxiaohu; [email protected] >> Cc: [email protected] >> Subject: Re: [nvo3] Is it too earlier to make a choice from >> L2 and L3-based NV solutions? >> >> Hence, I believe it's too earlier to make a choice between L2 >> and L3-based VN approaches at this stage. In other word, the >> NVo3 problem statement and requirement drafts should be more >> generic without focusing too much on specific approaches/solutions. >> >> [[LY]] I think that both L2 or L3 VN should be address by the >> WG, period. We should let operator pick which they use. >> >> Lucy >> >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On >> Behalf Of Xuxiaohu >> Sent: Tuesday, July 31, 2012 1:06 PM >> To: [email protected] >> Cc: [email protected] >> Subject: Re: [nvo3] Is it too earlier to make a choice from >> L2 and L3-based NV solutions? >> >> Hi Robert, >> >> I fully agree with you that there are use cases for both approaches. >> >> However, based on the assumption that there will be only one >> PS doc to be accepted as claimed by WG chairs and the fact >> that there are many common places between L2 and L3 based NV >> approaches (e.g., multi-tenancy, support of VM mobility >> without renumbering, etc), I believe it would be better to >> make the problem statement more generic, with more focus on >> the problem itself, rather than focusing too much on specific >> solutions. >> >> Best regards, >> Xiaohu >> >> ________________________________________ >> 发件人: Robert Raszuk [[email protected]] >> 发送时间: 2012年8月1日 1:41 >> 到: Xuxiaohu >> Cc: [email protected] >> 主题: Re: [nvo3] Is it too earlier to make a choice from L2 and >> L3-based NV solutions? >> >> Hi Xuxiaohu, >> >> I would not really say that this is too early. >> >> I think there is already substantial evidence that this WG >> needs to work on both L2 and L3 based solutions. >> >> If this is in one or two problem statements documents I think >> it really does not matter provided that the document honestly >> reflects both needs. >> >> I am not sure what can change in weeks or months to come >> which would allow to dismiss one of the above spaces. I see >> the real use cases for both for at least next few years. >> >> Best regards, >> Robert. >> >> >>> Hi all, >>> >>> As stated in the current NVo3 WG charter, the current task >> for NVo3 >>> is to define the data center network problems and requirements. >>> >>> IMHO, one major driver for a large VLAN or subnet aross >> multiple racks >>> even multiple data center is to allow VM mobility without >> renumbering. >>> To support this, we can either use MAC-based forwarding (i.e., >>> L2-based NV) or host-route based forwarding (i.e., L3-based NV). Of >>> course, some may argue that server cluster is another driver. >>> As far as I know, there are still some legacy cluster technologies >>> which heavily rely on L2 connectivity (e.g., using non-IP >> protocol for >>> cluster membership keepalive), however, there are also some cluster >>> technologies which can run well on L3. And most importantly, those >>> vendors of legacy cluster technologies have already upgraded or >>> started to consider upgrading their cluster technologies to support >>> L3. Hence both L2 and L3 approaches have their own target scenarios. >>> >>> As we already know, each approach has its pros and cons, >> for example, >>> L2-based NV is more applicable (i.e., it can support both IP and >>> non-IP traffic), and L3-based NV is more scalable (e.g., >> the flooding >>> domain and MAC domain associated with the extended subnet can be >>> partitioned and therefore be confined within a very small scope). >>> For those data center operators who still have some L2 applications >>> running in their data centers, they can choose L2-based NV, >> otherwise, >>> they can choose L3-based NV. >>> >>> Hence, I believe it's too earlier to make a choice between L2 and >>> L3-based VN approaches at this stage. In other word, the >> NVo3 problem >>> statement and requirement drafts should be more generic without >>> focusing too much on specific approaches/solutions. >>> >>> Best regards, Xiaohu _______________________________________________ >>> nvo3 mailing list [email protected] >>> https://www.ietf.org/mailman/listinfo/nvo3 >>> >>> >> _______________________________________________ >> nvo3 mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/nvo3 >> _______________________________________________ >> nvo3 mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/nvo3 >> > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
