----- Original Message ----- > From: "David Jaša" <[email protected]> > To: [email protected] > 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" <[email protected]> > > >> To: "Alon Bar-Lev" <[email protected]> > > >> Cc: [email protected] > > >> 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" <[email protected]> > > >>>> To: [email protected] > > >>>> 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 [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
