Re: [nvo3] Applicability of RFC 5512 to NVO3?

Hi Robert,

1) I was viewing RFC 5512 as something that may be able to be run only down to and on ToR switches, not (necessarily/always) down to individual Hypervisors, specifically for the scale reasons you cite.
2) With respect to the latter point, I can potentially see something like draft-marques-l3vpn-end-system-03 as being complementary to RFC 5512. Specifically, draft-marques-l3vpn-end-system-03 would run on/in a Hypervisor and talk to a ToR (running RFC 5512), as appropriate.

Regardless, at a high level, my question was really meant to ask the more broad question of whether RFC 5512 had been reviewed by the authors/proponents of NVO3 to see if it was applicable and, if not, why not. When I reviewed the Section 6 of the NVO3 draft, (and attended the NVO3 discussion in Taipei), I had not seen it mentioned (even though there are several other protocols/mechanisms discussed), which is what prompted my question.
https://tools.ietf.org/html/draft-narten-nvo3-overlay-problem-statement-01#section-6
... or, said differently, could the NVO3 effort go *faster* (and, hopefully avoid inventing a new, almost identical signaling protocol) if it was able to leverage RFC 5512 for its signaling control plane[1] and, perhaps, focus mostly on (for example) adopting/refining/etc. (something like) draft-marques-l3vpn-end-system, as I mention in #2 above (and, others have mentioned on the list previously).

In summary, I was attempting to help narrow the scope of NVO3, by re-using /if possible/ what we've already developed and, secondarily, focus on the new things that don't exist.

-shane

[1] As you mention, BGP may be challenged from a scaling perspective, wrt to NVO3. Then again, the same arguments were made about BGP back during the early days of the L2VPN & L3VPN, when those WG's were just getting off the ground and look where the industry is now.

On Feb 18, 2012, at 3:35 AM, Robert Raszuk wrote:
> Hi Shane,
> 
> 5512 would require each host to support BGP.
> 
> That for amount of information scaling would automatically mean that each host in the data center would need to also support RTC (rfc4684).
> 
> Session scaling is another challenge if we follow Igor's numbers.
> 
> And I am not sure that the p2mp information distribution nature of BGP fits well to the set of requirements here. It seems that host to VM controller/orchestration/ect is much more p2p in it's nature. From looking at our data centers I see the common user's VMs residing on very little number of hosts.
> 
> Even if one would go that path (and maybe we would restart talks about bgp-lite .. what may be regardless useful for PE-CE bgp scaling in other areas) which BGP implementation you would recommend to use on the hosts ?
> 
> Cheers,
> R.
> 
>> I am curious to know if the following RFC has been looked at to see
>> if it's applicable to the NVO3 solution space. Furthermore, if it was
>> looked at, I'd be curious to know why it was insufficient?
>> 
>> http://tools.ietf.org/html/rfc5512
>> 
>> Thanks,
>> 
>> -shane _______________________________________________ nvo3 mailing
>> list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3
>> 
>> 
> 