On Thu, 2009-06-18 at 16:06 +0200, Daniel Veillard wrote: > On Thu, Jun 18, 2009 at 10:46:45AM +0100, Daniel P. Berrange wrote: > > On Wed, Jun 17, 2009 at 10:59:20PM +0000, David Lutterkort wrote: > > > The problem with the propsal is that it opens the door to a variety of > errors like using the same familly twice, which I would like to avoid > at the RNG level but it's not trivial. An alternative is to drop the <addresses/> tag and just stick a type=ipv4|ipv6 attribute on the <ip/> tags .. though that requirs that we do the same for <route/> tags, and I have no idea what routing in non-IP protocols looks like. > We should allow standalone IPv4 and IPv6, or both. Each could either > use DHCP or allow one or more IP address and routes. > I think if we have routes, at most one need to be a gateway and the > other ones having destination + prefix. > > So I suggest the following rewrite of interface-addressing > > <!-- Assignment of IP address to an interface --> > <define name="interface-addressing"> > <choice> > <ref name="interface-addr-ipv4"/> > <ref name="interface-addr-ipv6"/> > <group> > <ref name="interface-addr-ipv4"/> > <ref name="interface-addr-ipv6"/> > </group> > </choice> > </define> Ok. > This allows one or 2 blocks of addresses ipv4, ipv6 or both > > <define name="interface-addr-ipv4"> > <element name="addresses"> > <attribute name="family"> > <value>ipv4</value> > </attribute> > <choice> > <ref name="interface-addr-static"/> > <ref name="interface-addr-dhcp"/> > </choice> > </element> > </define> > > An IPv4 addresses block, allows for either static or dhcp > > <define name="interface-addr-ipv6"> > <element name="addresses"> > <attribute name="family"> > <value>ipv6</value> > </attribute> > <choice> > <ref name="interface-addr-static"/> > <ref name="interface-addr-dhcp"/> > </choice> > </element> > </define> interface-addr-static and interface-addr-dhcp need to be split into ipv4 and ipv6 specific branches, so that we can typecheck that we don't use an ipv6 address in an ipv4 addressing block. Ultimately, that means we need ipv4 and ipv6 versions of ip-addr and prefix-pattern. > For DHCP the only option is the peerdns yes/no attribute There's a few more options we need to add for completeness, at least PERSISTENT_DHCLIENT, DHCPRELEASE, and DHCLIENT_IGNORE_GATEWAY are supported by initscripts. > And for routes we have at least one default route Default route should be optional. > This makes parsing a bit heavier, and I didn't checked if this really > affected bridging and bonding interfaces in a wrong way, but I think > that at least at an ethernet level definition this looks more complete. It only affects it in so far as interface-addressing is also used for the toplevel bridge/bond devices, which AFAIK is ok. > That said I have no idea how much of a problem it would be on the netcf > impletmentation side. I will find out ;) > P.S.: full rng attached, double check the prefix-pattern definition > I have no idea if it's sufficient for Ipv6 For ipv4, prefix is in the range 1..32, for ipv6, it's 1..128. David -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list