... | @@ -32,7 +32,7 @@ solution, Kea project is interested in providing multiple management interfaces: |
... | @@ -32,7 +32,7 @@ solution, Kea project is interested in providing multiple management interfaces: |
|
This is a complex goal and its full implementation will take a long time. However, major parts
|
|
This is a complex goal and its full implementation will take a long time. However, major parts
|
|
of the desired functionality can be achieved much faster, if certain compromises are acceptable.
|
|
of the desired functionality can be achieved much faster, if certain compromises are acceptable.
|
|
|
|
|
|
[[Image(long-term-goal.jpg)]]
|
|
![long-term-goal](/uploads/58af17410f25b2c367ee8aecc95b66ae/long-term-goal.jpg)
|
|
|
|
|
|
## 1.1 Design principles
|
|
## 1.1 Design principles
|
|
|
|
|
... | @@ -99,11 +99,11 @@ This does not cover all configuration elements Kea-dhcp4 is capable of. Other as |
... | @@ -99,11 +99,11 @@ This does not cover all configuration elements Kea-dhcp4 is capable of. Other as |
|
|
|
|
|
Translating the whole YANG model at once is not realistic due to its complexity. Also, the whole configuration changes very infrequently, so it would be very inefficient to re-apply all parameters. Therefore kea-netconf needs to offer finer granularity. To address this problem, a concept of translators has been invented.
|
|
Translating the whole YANG model at once is not realistic due to its complexity. Also, the whole configuration changes very infrequently, so it would be very inefficient to re-apply all parameters. Therefore kea-netconf needs to offer finer granularity. To address this problem, a concept of translators has been invented.
|
|
|
|
|
|
[[Image(trans-1.jpg)]]
|
|
![trans-1](/uploads/b9f0e65f142696460c32a26698df3eb4/trans-1.jpg)
|
|
|
|
|
|
Once the startup is complete, Kea-netconf will install callbacks on specific parts of the YANG model to receive notifications if any configuration element changes. A class providing such a callback will be called a Translator (as it translates parts of YANG model into JSON commands understandable by Kea). kea-netconf will provide the ability to load arbitrary number of such translators. kea-netconf will send those commands over UNIX control channel to kea-dhcp4 and kea-dhcp6. Translators will be mostly defined in hook libraries that will be loaded by kea-netconf. This approach will provide maximum flexibility.
|
|
Once the startup is complete, Kea-netconf will install callbacks on specific parts of the YANG model to receive notifications if any configuration element changes. A class providing such a callback will be called a Translator (as it translates parts of YANG model into JSON commands understandable by Kea). kea-netconf will provide the ability to load arbitrary number of such translators. kea-netconf will send those commands over UNIX control channel to kea-dhcp4 and kea-dhcp6. Translators will be mostly defined in hook libraries that will be loaded by kea-netconf. This approach will provide maximum flexibility.
|
|
|
|
|
|
[[Image(trans-2.jpg)]]
|
|
![trans-2](/uploads/e1bcaab036a048cffbe50a911761072d/trans-2.jpg)
|
|
|
|
|
|
## 3.3 Sysrepo - a netconf backend
|
|
## 3.3 Sysrepo - a netconf backend
|
|
|
|
|
... | @@ -123,7 +123,7 @@ This is the most basic scenario. There is one Kea instance that is managed using |
... | @@ -123,7 +123,7 @@ This is the most basic scenario. There is one Kea instance that is managed using |
|
|
|
|
|
Although this deployment scenario has some merits of its own, it is typically considered a first stepping stone towards more robust deployments that feature stateless DHCP.
|
|
Although this deployment scenario has some merits of its own, it is typically considered a first stepping stone towards more robust deployments that feature stateless DHCP.
|
|
|
|
|
|
[[Image(scenario-1a.jpeg)]]
|
|
![scenario-1a](/uploads/ac6a78b8a03fdab4969ba23a5e104640/scenario-1a.jpeg)
|
|
|
|
|
|
## 4.2: Single instance managed via Netconf
|
|
## 4.2: Single instance managed via Netconf
|
|
|
|
|
... | | ... | |