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

[Shane Amante <[e-mail]>]

Hi Larry,

On Feb 20, 2012, at 1:35 AM, Larry Kreeger wrote:
> Hi Shane,
> 
> On 2/18/12 8:35 AM, "Shane Amante" <[e-mail]> wrote:
> 
>> 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.
> 
> While the overlay solution should allow for the ToR switches to be the
> encap/decap points, the other requirement is that it must be possible for
> the overlays to terminate in the Virtual Switch inside the hypervisor.  We
> certainly wouldn't want to use two different protocols, with one for
> hypervisors and one for ToR switches.  In fact, I believe it quite likely
> that the same DC will have overlays terminating in both hypervisors and in
> physical network switches.

Please clarify what you mean above, wrt data-plane encapsulation/de-encapsulation vs. control-plane protocols.

RFC 5512 is strictly a control-plane signaling protocol, which can signal any combination of: GRE/IP, IP/IP or L2TPv3/IP for data-plane encapsulation.

-shane



>> 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#sec
>> tion-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 [e-mail] https://www.ietf.org/mailman/listinfo/nvo3
>>>> 
>>>> 
>>> 
>> 
>> _______________________________________________
>> nvo3 mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/nvo3
> 
> _______________________________________________
> nvo3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nvo3