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
