[kea-dev] Client classification design

[Shawn Routhier]

> On Oct 13, 2015, at 8:31 AM, Tomek Mrugalski <tomasz at isc.org> wrote:
> 
> Folks,
> I took a first stab at the client classification design. See the
> document here: http://kea.isc.org/wiki/ClientClassificationDesign
> 
> For the reference, we have the requirements more or less described here:
> http://kea.isc.org/wiki/ClientClassificationRequirements.
> 
> We had some discussions about the syntax, but I did think about it a bit
> more and came up with three alternative proposals. Please comment on
> which one seems to be the best in your opinion (or reject all of them
> and propose a fourth one). I tried to be objective and not push for any
> specific one.
> 
> Keep in mind that we're working under very tight schedule here and
> client classification is a broad and complex topic. There's a lot we
> could do, but due to the time constraints, we need to be very selective
> for phase 1 (aka Kea 1.0).
> 
> Some parts of the design will likely be moved to the requirements page,
> but I want to keep it in the new doc for now, so you could review it
> more easily as one chunk.
> 
> It would be great if you could provide your comments by end of this week
> (Oct. 16th), so we could start an implementation the next week.
> 
> Thoughts? Comments? Tomatoes?
> 
> Tomek
> 
> _______________________________________________
> kea-dev mailing list
> kea-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-dev

I echo Thomas’s question about nailing down what the requirements are.

Some general thoughts:

1) Are we going to want to use the expression evaluation code for uses other than classification?
For example to construct an outgoing option which I don’t believe we allow yet.  This would not
be a feature for the near future but it may suggest if we want the expression code easily split from
the classification code.

2) Do we have or need a way to specify which relay options to use in the case that the packet
has traversed multiple relays to get to the server?  (I thought I remembered seeing a discussion
about adding some features in this area some time ago but was unable to find anything in the
manual.)  I think we can probably defer any general work till later but may need to specify
(in the documentation) what happens in 1.0

3) If I understand it correctly I think G.7 may lead to problems.  It sounds like the intention is to
have multiple classes all named “FOO” and a class is selected based on which subnet the client
is in.  I think that will end up confusing users and causing configuration errors.

4) It would be quite useful to have some method to help the admin debug these things.  In ISC DHCP 
the standard way is to insert a statement that will log something into the class definition 
or use of class in a subnet.  This provides a way for the admin to see if they wrote the
matching statements correctly for the given clients.

If we go with proposal 1 it would seem simple enough to have the class definitions be global
while the use of the classes would be only per subnet in phase 1.  It would also seem that we
would then be able to extend the global class definition to add option data in phase 2.

To me it seems like it will be easier to expand something like proposal 1 into phase 2 rather
than expanding proposal 2.  It also may be a bit easier for people to update their configuration
files .

While there is a possibility of mis-spelled names in proposal 1 this is similar to what is done
in ISC DHCP and people don’t seem to have a large problem with it.  Overall I think going
with something where the class definitions are easily split from the options is a good idea.

I’d also suggest that we be extremely clear in the documentation for whichever we decide.
In ISC DHCP the classes are global but can be defined within a subnet which leads to odd
behavior and generally not what the admin expected.  This is another reason why I would
suggest the class definitions be global and only able to be parsed at the proper level.

3A) Do we have either requirements or goals for the arrangement of classes?  That is
the total number that a user may define?  the number per-subnet?  Do we expect that
there may be a large number of classes but only a limited number of them active for
any subnet?  This may affect our decision about defining classes at the subnet level.

My assumption is that most admins will have a smallish number of classes and they will
probably be the same classes across most subnets.  Though if ISPs use classes to
provide per customer specific information they may end up with a lot of small classes.

4) I agree with Marcin I think E.6 is probably required.  At least I would put this as the very first
thing on the not required but really want to have list.

5) I also agree with Marcin that F.1 either needs to be broadened or F.3 needs to be added that
a class can override a subnet.  The documentation should be clear on which option will be used
if a given client could get that option from multiple places.  From the current description
it appears that while a client can be a member of many classes it will only get options from
one class at a time (I think we can only have one class per subnet currently?).  Eventually
if we allow options at a global level for classes we might want to specify options are chosen
(or simply state that it is undefined and the admin shouldn’t define an option in multiple
classes such that a client could get any of them).

6) I’m not sure if the idea is to limit the parsing to a stack of 3 tokens or that is simply for
example purposes.  There are expressions that may take more, though I’m not sure
if we will eventually want them or not.  The example I’m thinking of is the binary-to-ascii
expression.  This takes 4 arguments (base, width, separator and data to format).  I don’t think
we will need such a thing in phase 1 but we probably want to write the code to allow
for expansion in the future and allowing for arbitrary numbers of tokens might be useful.