[Engine-devel] network subnet

[Livnat Peer]

On 12/09/12 12:51, Alon Bar-Lev wrote:
> 
> 
> ----- Original Message -----
>> From: "David Jaša" <djasa at redhat.com>
>> To: engine-devel at ovirt.org
>> Sent: Tuesday, September 11, 2012 2:47:56 PM
>> Subject: Re: [Engine-devel] network subnet
>>
>> Livnat Peer píše v Út 11. 09. 2012 v 09:21 +0300:
>>> On 30/08/12 23:11, Alon Bar-Lev wrote:
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Livnat Peer" <lpeer at redhat.com>
>>>>> To: "Alon Bar-Lev" <alonbl at redhat.com>
>>>>> Cc: engine-devel at ovirt.org
>>>>> Sent: Thursday, August 30, 2012 10:16:05 PM
>>>>> Subject: Re: [Engine-devel] network subnet
>>>>>
>>>>> On 30/08/12 21:39, Alon Bar-Lev wrote:
>>>>>>
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Livnat Peer" <lpeer at redhat.com>
>>>>>>> To: engine-devel at ovirt.org
>>>>>>> Sent: Thursday, August 30, 2012 3:22:29 PM
>>>>>>> Subject: [Engine-devel] network subnet
>>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>> Today when a user wants to define a network subnet mask, he
>>>>>>> does
>>>>>>> it
>>>>>>> when
>>>>>>> he attaches the network to a host NIC.
>>>>>>>
>>>>>>> I was wondering if there is a reason not to define the network
>>>>>>> subnet
>>>>>>> on
>>>>>>> the logical network entity (Data center level).
>>>>>>>
>>>>>>> Thanks, Livnat
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I am sorry, maybe I do not understand... the IP scheme enforces
>>>>>> the
>>>>>> use of address mask in order to properly route packets.
>>>>>
>>>>> of course. My proposal is related to our user usage of the
>>>>> system.
>>>>> Today
>>>>> ovirt user, who wants to define a network subnet, has to type
>>>>> the
>>>>> subnet
>>>>> per host (per network), I think the user should only define it
>>>>> once
>>>>> on
>>>>> the logical network entity in the Data Center.
>>>>> Propagating the value to all hosts is needed but it should be
>>>>> our
>>>>> internal implementation detail.
>>>>>
>>>>>>
>>>>>> Network mask is used in any case, I guess it can be dropped
>>>>>> from
>>>>>> configuration in favour of using the address class as mask, is
>>>>>> that what you suggest?
>>>>>>
>>>>>
>>>>> No, hope the above paragraph made it more clear.
>>>>>
>>>>
>>>> Hello,
>>>>
>>>> Then you assume that a logical network, which is actually layer 2
>>>> network in our implementation, has layer 3 characteristics,
>>>> right?
>>>>
>>>> In our current implementation "data center logical network" is
>>>> pure layer 2 segment aka layer 2 broadcast domain.
>>>>
>>>> One can use the same logical network for multiple layer 3
>>>> segments, which is totally valid and consistent with standard
>>>> physical layer 2 setup.
>>>>
>>>> Unless I am missing something crucial, I would suggest to keep
>>>> the consistent physical->virtual mapping, unless we emulate
>>>> layer 3 switching. Layer 2 does not have layer 3
>>>> characteristics.
>>>>
>>>> Regards,
>>>> Alon.
>>>>
>>>
>>> Generally I agree with what you wrote.
>>>
>>> I would like to open for discussion the definition mentioned above
>>> that
>>> a logical network is a layer 2 broadcast domain.
>>>
>>> We have 2 types of logical networks, VM networks and 'other' (host
>>> functionality?) networks.
>>>
>>> When talking about VM networks, I think the definition above is
>>> accurate, the guests using the network should get a layer 2
>>> broadcast
>>> domain.
>>> It can be implemented over a single (physical) layer 2 domain or it
>>> can
>>> be implemented over multiple (physical) layer 2 domains using
>>> technologies like tunneling or vxlan.
>>>
>>> When talking about other networks like storage, display, migration,
>>> etc. we are actually discussing a network which represent a common
>>> functionality the hosts are using but I am not sure guaranteeing a
>>> layer
>>> 2 broadcast domain is interesting for such network.
>>>
>>
>> IMHO the requirements for the "logical networks" could be
>> differentiated
>> depending on their function:
>>       * management: engine must reach each host on L3
>>       * storage: each host can reach the storage on L3 (FCP or IP)
>>       * VM network: all VNICs in one  are in L2 broadcast domain by
>>         default
>>       * migration: mutual reachability of hosts on L3
>>       * display: reachability on from clients
>> that in turn could make
>>
>> Note that engine or hosts can not really test if display network is
>> working in conditions like split-horizon DNS.
>>
>> David
>>
>>> Going forward I expect we'll associate layer 3 services with
>>> logical
>>> networks. For example DHCP, DNS, LB etc.
>>>
>>> Any thoughts/comments on the above are welcomed.
>>>
> 
> I agree that we should distinguish between terms.
> 
> "Layer 2 Segment" which is what you connect "Network Element" to.
> 
> Now I understand the we have "XXX Group", I guess this is what you refer as "Storage Network" for example?
> 
> Most of these groups only need network reachability so the term "Network" in this sense is somewhat confusing.
> 
> But I may got this wrong.

You got it exactly right, I'm not sure we should create a network for
such groups.

Anyway it is just a set of initial thoughts, I need to build a more
formal proposal what to do with this and I'll send it to the list.

Thanks for your inputs.

Livnat

> 
> Alon.
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>