[ovs-dev] OVN based distributed virtual routing for VLAN backed networks

[Guru Shetty]

On Wed, 7 Nov 2018 at 15:01, Guru Shetty <guru at ovn.org> wrote:

>
>
> On Fri, 19 Oct 2018 at 15:17, Ankur Sharma <ankur.sharma at nutanix.com>
> wrote:
>
>> Hi Guru,
>>
>> Thanks for taking a look.
>> Please find the detailed explanation of problem statement inline.
>>
>> Thanks
>>
>> Regards,
>> Ankur
>>
>>
>>
>> *From:* Guru Shetty <guru at ovn.org>
>> *Sent:* Friday, October 19, 2018 9:35 AM
>> *To:* Ankur Sharma <ankur.sharma at nutanix.com>
>> *Cc:* ovs-dev <ovs-dev at openvswitch.org>
>> *Subject:* Re: [ovs-dev] OVN based distributed virtual routing for VLAN
>> backed networks
>>
>>
>>
>>
>>
>> On Tue, 16 Oct 2018 at 15:43, Ankur Sharma <ankur.sharma at nutanix.com>
>> wrote:
>>
>> Hi,
>>
>> We have done some effort in evaluating usage of OVN for
>> Distributed Virtual Routing (DVR) for vlan backed networks.
>>
>>
>>
>> Would you mind explaining the above statement with a lot of details? I
>> would like to understand the problem well before looking at the proposed
>> solution.
>>
>> [ANKUR]:
>> a. OVN provides logical routing and switching, but was designed for
>> scenario where logical switch is of type “overlay”.
>>
>>      i.e Packets going on the wire are always encapsulated (exception
>> would be communication with external network, via NAT).
>>
>> b. Our proposal is to enhance OVN to support cases where logical switch
>> is of type “vlan”,
>>
>>      i.e there is no encapsulation and “inner” packet goes on the wire
>> “as is”.
>>
>>
>>
>> c. We evaluated current OVN implementation for both logical-switches and
>> logical-routers.
>>
>>
>>
>> d. Our proposal is meant to highlight the gaps (as of now) and how we
>> plan to fix them.
>>
>
> Let me summarize my understanding of your mail and you can poke holes in
> it, if I am wrong and probably rephrase your problem statement.
>
> Current state of OVN
> ================
>
> The following is the current state of OVN's "localnet" feature. I haven't
> used "localnet" feature for a long time and this is my understanding based
> on reading the man pages and the localnet test in tests/ovn.at today.
>
> OVN currently supports logical switches and lets you interconnect them
> with logical routers. In a particular logical switch, you can have many
> logical ports which are backed by a VM running on different hypervisors.
> The VMs across multiple hypervisors which are backed by a OVN logical port
> only talk via overlay networks. In addition, you can add a logical port of
> type "localnet" to these logical switches. This "localnet" logical port has
> a "tag" associated with it. This localnet port is used to let the VMs of a
> OVN logical switch talk to other network endpoints that are not in OVN (for
> e.g a baremetal machine), but are in the same subnet. When OVN (i.e br-int)
> receives a ARP broadcast packet from a OVN logical port in a logical
> switch, it will be sent to all other logical ports including the "localnet"
> port.
>
> You can potentially connect two of these logical switches via a OVN
> router. The OVN known logical ports will talk to each other via overlay
> networks. But, if you want to exit the network, you need to go out of a
> gateway port.
>
> You can also use a "l2gateway" to connect to multiple vlan backed machines
> in the same logical switch that are outside OVN.
>
> My understanding of your problem statement
> ===================================
>
> You want to achieve the same feature set as what currently exists in OVN,
> but you don't want to use overlay networks when 2 known logical ports of
> OVN (say backed by a VM) exists in a "vlan backed logical switch". Is that
> the only difference? If that is the only difference, my question is "why?".
> Why do you want to avoid overlay networks? Do you gain anything else out of
> it? What is it?
>
>
>
I am not saying that "avoiding overlay networks" in itself is not a valid
reason for a new feature (for e.g., I can see how it is very useful when
public cloud VMs are your hypervisors). But I want to make sure that I
understand that is the only problem statement here.