The DC Ops will love that idea - redesign and redeploy your IP routing protocols before deploying nvo3
===== Mistyped and autocorrected on a clunky virtual keyboard On 8. sep. 2012, at 01:33, Aldrin Isaac <[email protected]> wrote: > Where a BGP-base solution is involved, IMO, it should be possible for the > default gateway of the NVE to also be its RR. The transport tunnel could be > VXLAN, etc if MPLS is not an option. > > On Friday, September 7, 2012, Ivan Pepelnjak wrote: > 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
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
