[Engine-devel] network subnet

[David Jaša]

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.
> 
> 
> Thanks, Livnat
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel

-- 

David Jaša, RHCE

SPICE QE based in Brno
GPG Key:     22C33E24 
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24