[Dnsmasq-discuss] IP address based on switch port number (option 82)

[richardvoigt at gmail.com]

On Wed, Feb 17, 2010 at 3:05 PM, Simon Kelley <simon at thekelleys.org.uk> wrote:
> richardvoigt at gmail.com wrote:
>
>> Actually, I think you can avoid that without loss of generality.
>>
>> By DeMorgan's theorem, the AND and NOT operations currently available
>> are sufficient to define any expression.  You just need a way to do
>> grouping, which a syntax for setting one tag conditionally based on
>> another tag would do.
>>
>> Remember that the example given doesn't need a complement applied, you
>> can negate it in the match later.
>>
>> Since "if" is a very well understood concept, I'd propose
>>
>> tag-if switch1,port1 newtag
>>
>> Where newtag gets set if all listed tags are matched.  Using multiple
>> tag-if lines lets you effectively OR things together (this yields
>> sum-of-products capability).  Allow a user to unset a tag with
>>
>> tag-if #switch1,port15 #newtag
>>
>> for even more flexibility, but now all tag-if commands need to be
>> processed in order.
>>
>
> Genius!
>
> That's perfect. I think the second form might not be sensible, since the
>  order of lines in the configuration file(s) is not significant anywhere
> else.
>
> The simplest scheme would ban tags defined in tag-if declarations from
> use in other tag-if declarations. If that wasn't done, there would be a
> need for multiple iterations to find all the tag values, and the
> possibility of unresolvable data-loops exemplified by
>
> tag-if black, white
> tag-if white, black

as long as you're not going to prohibit

tag-if set:hipower tag:uv
tag-if set:hipower tag:violet
tag-if set:hipower tag:indigo
tag-if set:hipower tag:blue

tag-if set:visible tag:violet
tag-if set:visible tag:indigo
tag-if set:visible tag:blue
tag-if set:visible tag:green
tag-if set:visible tag:yellow
tag-if set:visible tag:orange
tag-if set:visible tag:red

which means

hipower := blue + indigo + violet + uv;
visible := violet + indigo + blue + green + yellow + orange + red;

and then you could e.g. assign a dhcp pool to tag:visible while
assigning a default gateway to tag:hipower (and a different one to
tag:!hipower), and then assign a different bootp image for each color
individually.

Actually, instead of prohibiting use of tags set by tag-if for further
tag-if, I think it's more reasonable to execute the lines in order and
generate a warning if there's any attempted backpropagation.  I mean,
build a cumulative list of tags which appear on the condition side
(tag:xyz) of tag-if lines.  If any tag-if would set:xyz when xyz is in
the list of matched tags, warn.  But allow this:

tag-if set:F tag:A,tag:B
tag-if set:F tag:C
tag-if set:G tag:F,tag:D

which yields
G := ((A*B) + C) * D;

without recursive parsing.

But then warn if a later line contained:
tag-if set:D (any condition here)

because D is already tested in a tag-if

Of course this isn't really necessary, we can expand to
sum-of-products as follows:
G := (A*B*D) + (C*D);

and get the same result via non-iterative conditional tagging:

tag-if set:G tag:A,tag:B,tag:D
tag-if set:G tag:C,tag:D

>
> I'd modify the syntax to match the changes in 2.53 where testing the
> value of a tag is always done with tag:<tagname> and setting a tag is
> always done with set:<tagname>, and ! is used for NOT. So we end up with
>
> tag-if set:newtag, tag:!switch1, tag:port15
>
> I like. Back soon with a test implementation.
>
>
> Simon.