Re: [Engine-devel] network subnet

----- Original Message ----- > From: "David Jaša" <djasa(a)redhat.com&gt; > To: engine-devel(a)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(a)redhat.com&gt; >>>> To: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; >>>> Cc: engine-devel(a)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(a)redhat.com&gt; >>>>>> To: engine-devel(a)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.

Alon. _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel