Hi Ivan, Thank you for pointing out this scenario. We updates the vpn gap analysis draft to capture this. Typically, BGP/MPLS VPN is configured at network edge device, not at a host. NVO3 requires NVE on a server and the server is a host, not network edge device. However, BGP/MPLS [RFC4364] support Multi-ASes, in which Option B is similar to this case, i.e. PE may connect to multi-ASBRs. Here is the draft. Any comment are welcome.
http://www.ietf.org/id/draft-hy-nvo3-vpn-protocol-gap-analysis-01.txt Regards, Lucy From: [email protected] [mailto:[email protected]] On Behalf Of Ivan Pepelnjak Sent: Saturday, September 08, 2012 1:30 AM To: Aldrin Isaac Cc: Michael Richardson; [email protected]; [email protected] Subject: Re: [nvo3] Support for multi-homed NVEs 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]<mailto:[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]<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
