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]<javascript:;>> > wrote: > > > > >>>>>> "Ivan" == Ivan Pepelnjak <[email protected] <javascript:;>> > 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] <javascript:;>>, Sandelman > Software Works > > > > > _______________________________________________ > nvo3 mailing list > [email protected] <javascript:;> > https://www.ietf.org/mailman/listinfo/nvo3 >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
