[Engine-devel] network subnet

[Alon Bar-Lev]

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

Alon.