Hi Tomek, once again thanks for the quick reply. Sadly no, the identifier must be both the circuit-id and remote-id. Like I said before, circuit-ids can be equal when sent from different relays (remote-ids), I the pair <remote-id, circuit-id> to identify the device.
Best Regards, Rui <https://about.me/rpcaldeira?promo=email_sig&utm_source=email_sig&utm_medium=email_sig&utm_campaign=external_links> [https://aboutme.imgix.net/background/users/r/p/c/rpcaldeira_outlook.com_1455023098_86.jpg?w=105&q=90&dpr=1&auto=format,redeye&rect=0,14,756,504] Rui Pedro Caldeira about.me/rpcaldeira On Wed, Feb 1, 2017 at 9:01 PM, Tomek Mrugalski <[email protected]<mailto:[email protected]>> wrote: W dniu 01.02.2017 o 11:37, Rui Pedro Caldeira pisze: > Hello Tomek, I would like to thank your openness for my need of this > capability and I need it badly. > Since circuit-ids can be equal even when sent from different relays > (different remote-ids), I need the remote-id to disambiguate the > circuit-ids. Therefore, I need to specify the remote-id in the config > file next to the circuit-id, like in the following example: > > "reservations": [ > { > "remote-id": "<Remote ID Here>", > "circuit-id": "02:0A:00:01:06:07:00:00:00:00:00:00", > "ip-address": "192.168.168.66" > } > ], > "subnet": "192.168.168.0/24<http://192.168.168.0/24> > <http://192.168.168.0/24>" > }, This kind of definition is not something I had in mind. The problem with your proposal are two identifiers used: remote-id and circuit-id. This would be impossible to store in Kea reservation tables. Kea stores reservations in MySQL and PostgreSQL in a table that has the following columns: identifier-type, identifier, ip-address. There are several other columns, but they're not important for this problem. The remote-id value is unique on its own, right? So you could use the remote-id only to distinguish between clients, right? We currently support several identifier-types. When we add remote-id, we will simply enable additional value to be specified there. This way we can continue adding new identifiers without requiring every deployment that stores them in SQL database to change the schema. So it would look more like this: "reservations": [ { "remote-id": "<Remote ID Here>", "ip-address": "192.168.168.66" } ], "subnet": "192.168.168.0/24<http://192.168.168.0/24> <http://192.168.168.0/24>" }, Would something like that work for you? > I would like to ask how fast a patch to v1.1.0 could become available. Adding new identifier type is maybe 2 weeks of work. We need to implement the ability to find reservations by new identifier (that's very simple), but we also need to update all reservation storages (config file, MySQL and PostgreSQL) to store them. Finally, we need to develop some tests that verify they are working. At the very minimum those would have to be unit-tests, but preferably we should also have system tests. That's what needs to be done from the engineering perspective. Sadly, that doesn't mean you'll get it by mid February. We are currently working on our 1.2 milestone and remote-id was not part of that work. > Otherwise, do you have any tips as to how can I resolve this issue? There are couple options. First, ISC sets the roadmap in a way to accommodate requests from support customers, if possible. If such a request came from a customer, we would do our best to implement it promptly. Second, ISC offers custom development contracts. Sometimes we are asked to develop certain feature with specific deadline and agreed functionality. Depending on the agreed schedule, the code is then released in the upcoming release (sometimes we do an engineering drop earlier if the customer cannot wait for a release that is couple months away). Both of those options require some financial commitment. Another option would be to develop a patch yourself (or find someone who will develop it for you) and send us a patch. I must honestly say that we recently received quite a few patches that we still haven't reviewed. So it's not an instant process by any means, but having a patch definitely speed things up. Finally, there's the "convince us" option. There are lots of missing features in Kea and our resources are limited. Therefore we try to pick those features for implementation that are most frequently requested, would be useful for large number of users or give us a prospect for improving financial stability of Kea. These are basically your options. You are not the first one to ask for remote-id reservations, so there's non-trivial chance that we'll decide to put it on our plan for 1.3. 1.3 doesn't have any scope or release date defined, but I could speculate it would be release some time in the autumn. Hope that helps. Sorry if that's not exactly what you were hoping for. Tomek
_______________________________________________ Kea-users mailing list [email protected] https://lists.isc.org/mailman/listinfo/kea-users
