And how will a NVE behind a summarization boundary detect the BGP next hop is unreachable? You think people will deploy NVE BGP route reflectors at every aggregation boundary?
===== Mistyped and autocorrected on a clunky virtual keyboard On 7. sep. 2012, at 19:43, Michael Richardson <[email protected]> wrote: > >>>>>> "Ivan" == Ivan Pepelnjak <[email protected]> writes: > Ivan> I'm positive there are people who could make a beast with 100K > Ivan> /32 prefixes work using data center gear (not high-end SP > Ivan> routers) ... I'm also positive almost everyone else would walk > Ivan> away. > > So, we started with the problem of too many MAC addresses spreading all > over the data centre. We had millions of those. > > If we had a flat layer-2 DC network for the "underlay" network, we'd > have to manage 100K MAC addresses for the NVE boxes. That won't work, > so know that we have to go to a hierarchical model of address > allocation, which means not using layer-2 addresses. > > (/32 prefixes... don't you mean /128 prefixes?) > > It seems to me that in the canonical case of a ToR with single > trunks to NVEs, that the ToR should allocate addresses in topologically > significant ways, and if the "route-reflector" is not co-located inside > the ToR, that it will deal with a few racks only, and can deal with the > number of /128 routes required. > > In the non-canonical case where there are multiple trunks from the NVE > to multiple ToR, that one of the ToR switch needs to allocate the /128 > addresses which the NVE uses on loopback (if not the ToR itself, then > the DHCPv6 server that it relays to. DHCPv6PD might be appropriate for > this). Horizons (OSPF areas, etc.) would keep these /128 routes > contained in the minimal pieces that need to know. Since these > addresses would form a hierarchy, the entire data centre won't need to > know about all 100K NVE's /128. > > > -- > Michael Richardson <[email protected]>, Sandelman Software Works > > _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
