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

[Larry Kreeger <[e-mail]>]

On 2/20/12 11:22 PM, "Shane Amante" <[e-mail]> wrote:

> 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.

An Overlay Border Point (OBP), as it is called in
draft-kreeger-nvo3-overlay-cp-00 performs the encap/decap function.  In
order to do this it needs a table mapping inner Virtual Network addresses to
outer Underlying Network addresses.  The document discusses the requirements
for a control plane protocol to populate this mapping table.  I understood
that you were suggesting using RFC5512 as this protocol, but you mentioned
doing it only on ToR and not hypervisors; However, it would need to also run
on hypervisors since they will likely be the main place OBPs would exist.

 - Larry
> 
> -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#s
>>> ec
>>> 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
>