Re: [Engine-devel] network subnet

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