There is some concern about the use of MPLS because of the number of transport tunnels that the NVE would need to maintain. In the architecture I describe below where the default gateway router is also the RR of the NVE, it is possible (if your favorite vendor is willing to add the feature) that the NVE can get the MPLS transport tunnel to remote NVE over labelled unicast BGP and automatically filtered down to only the subset of remote NVE from which a VPN route is also received.
On Sep 8, 2012, at 11:34 AM, Aldrin Isaac wrote: > I am a DC Op, so with that hat on let me speak for my network and similar > network design: > > Since my access routers exchange access/subnet routes over BGP (the IGP only > has to worry about router loopbacks and transit links), the only change to > these access routers should be to allow peering from adjacent NVE RRC on its > access subnets. > > In this configuration if a default gateway is configured for passive peering > from local NVE subnets then I can see how, with some simple scripting, an NVE > can be made to automatically peer with it's default gateways once it gets > address from DHCP. There are details that would need to be worked out but I > don't believe these are insurmountable. > > On Saturday, September 8, 2012, Ivan Pepelnjak wrote: > 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
