NVO3 provides an overlay mechanism so that the hosts (or VMs) addresses are hidden from the switches in the core.
However, for the "L2 in IP" case of NVO3, all the overlay edge nodes are still exposed to all the hosts MAC addresses on the VLANs that are enabled on the edges, which can cause switches' FDB size explosion issue. p.s. If the number of VMs attached to an edge is very small (e.g. overlay edge in the server), then the number of VLANs enabled on the edge is limited. In this scenario, there could be very large number of edges/core nodes for large DC, which can make IGP in the core challenging. For a typical Access switch (Top of Rack) with 40 physical servers attached, where each server has 100 VMs, there are 4000 hosts under the Access Switch. If indeed hosts/VMs can be moved anywhere, the worst case for the Access Switch is when all those 4000 VMs belong to different VLANs, i.e. the access switch has 4000 VLANs enabled. If each VLAN has 200 hosts, this access switch's MAC table potentially has 200*4000 = 800,000 entries. https://tools.ietf.org/html/draft-nachum-sarp-06 proposes a proxy gateway method to get around this problem. The main idea of SARP is to represent all VMs (or hosts) under each access domain by their corresponding access (or aggregation) node's MAC address regardless whether the access (or aggregation) node is the VMs (hosts)' gateway or not. For example, when a host "a" under access domain "S" needs to communicate with peers on the same VLAN but connected to different access domains, SARP requires "a" to use remote access node's MAC address rather than peers' MAC addresses. By doing so, switches in each domain do not need to maintain a list of MAC addresses for all the VMs (hosts) in different access domains in their FDBs. Therefore, the switches' FDB size is limited regardless how VLAN is spread. We are going to present SARP in Interarea WG session this Friday. Hope you can come to express your feedback or concerns. If you can't come, can you express your feedback or concerns to [email protected]<mailto:[email protected]>? Thank you very much. Linda & Tal
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
