[kea-dev] Client classification design

[Tomek Mrugalski]

On 15.10.2015 05:09, Shawn Routhier wrote:
> 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.
I surely hope it won't ever get to that. It would be recreating all the
annoyances of ISC DHCP *on top* of new hooks related annoyances that are
unique to Kea. But just in case someone some time in the future would
think it's a good idea, I updated the design. It now clearly states that
the expressions code should be a stand-alone library with minimal
dependencies. More realistic use case would be a client or maybe a
feature rich relay?

> 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
Good point. Added E.11 and E.12 requirements.

> 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.
See my response to Marcin's mail. This is something we need to sort out
as currently classification is used to select a subnet, so we need to do
1. classification
2. subnet selection

which is incompatible with the requirement to define classes on a per
subnet basis.

> 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.
This will be taken case with a dedicated logger in the expressions
library. Added G.9 requirement to explicitly state that.

> 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 .
Ack. So it's now a tie:
Proposal 1: 1
Proposal 2: 1


> 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.
I'm ok with that approach. Actually, having this insight from ISC DHCP
world is a strong indicator that this is indeed what we want to do.

> 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.
Each expression has to be evaluated for each incoming packet. Also, a
packet can belong to more than one class. That brings several
implications. First, we need to evaluate each expression for every
packet, so it doesn't matter in which order we do it. Each class defined
will incur performance penalty, even if it never matches.

> 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.
I added a requirement G.10. Number of allowed classes is not limited.
However, after a certain arbitrary chosen number of classes, the code
would print out a warning that large number of classes will degrade
performance.

> 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.
It's now phase 1.

> 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).
Please let me know if the requirements F.1-F.3 are sufficient or should
I tweak it more? Also, proposing a text would be very welcome.

> 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.
That was the intention for phase 1. But since we added substring
operator, that's no longer true and we have to do full parsing. The good
news about it is that we will handle arbitrary number of tokens. That
bad news about it that we'll need a full flex/Bison grammar to do that.

Tomek