Closed dhcwg closed 6 years ago
Now ‘max-address/prefix-utilization-ratio’ is a configurable threshold value under 'server-config', and ‘address/prefix-utilization-ratio’ is under 'server-state' indicating current utilization ratio which is not configurable. These are used by notifications. I think this is a possible logic.
By the way, since 'address-pool' and 'prefix-pool' are independent, should we split the notification 'pool-running-out' into 'address-pool-running-out' and 'prefix-pool-running-out'?
Either have the two different notifications or provide an indication in the notification of the type?
BTW: I have to study these notifications a bit more. For addresses, using lease counts against the maximum seems sufficient. For prefix delegation, especially if variable length prefixes are allowed (i.e., a pool is not all of one prefix length), a count may not be that useful – instead, you’d like to use the percentage of the PD space used. Perhaps having both types (a count of “leases” and a usage) would be best for PD pools?
From: Zihao He [mailto:notifications@github.com] Sent: Sunday, January 28, 2018 10:32 PM To: dhcwg/yang yang@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: Re: [dhcwg/yang] Address/Prefix Pool Utilization (#5)
Now ‘max-address/prefix-utilization-ratio’ is a configurable threshold value under 'server-config', and ‘address/prefix-utilization-ratio’ is under 'server-state' indicating current utilization ratio which is not configurable. These are used by notifications. I think this is a possible logic.
By the way, since 'address-pool' and 'prefix-pool' are independent for , should we split the notification 'pool-running-out' into 'address-pool-running-out' and 'prefix-pool-running-out'?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/dhcwg/yang/issues/5#issuecomment-361131232, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABm3YdoNJDV1OIj2M_1FEbpXorLvWN-Nks5tPTuygaJpZM4Rh9rv.
Well, I mean we have two different notifications. Currently the container is 'pool-running-out', I'd like to split it into two containers 'address-pool-running-out' and 'pd-pool-running-out'. Yes, maybe for addresses count alone is enough. But I don't understand why count is not useful for prefix delegation. Wouldn't the percentage of the PD space used actually be calculated from the counts of total prefixes and allocated prefixes, even though there are variable-length prefixes in a pd-pool?
OK on splitting the notifications, though a more generalized approach would be to say “pool-low-threshold-reached” and specify details about the pool. If we have yet another type of resource, specifying something about the pool (name and IA_* type) might be more generic though? But I don’t think it is a big deal either way.
Counts are OK as one of the triggers for PD, but if variable prefix lengths are allowed, a count may not represent the “percentage” of space actually used. A count works best to fixed prefix lengths (or addresses).
From: Zihao He [mailto:notifications@github.com] Sent: Tuesday, January 30, 2018 3:56 AM To: dhcwg/yang yang@noreply.github.com Cc: Bernie Volz (volz) volz@cisco.com; Comment comment@noreply.github.com Subject: Re: [dhcwg/yang] Address/Prefix Pool Utilization (#5)
Well, I mean we have two different notifications. Currently the container is 'pool-running-out', I'd like to split it into two containers 'address-pool-running-out' and 'pd-pool-running-out'. Yes, maybe for addresses count alone is enough. But I don't understand why count is not useful for prefix delegation. Wouldn't the percentage of the PD space used actually be calculated from the counts of total prefixes and allocated prefixes, even though there are variable-length prefixes in a pd-pool?
— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/dhcwg/yang/issues/5#issuecomment-361520537, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABm3YYGesjH-vpDvevLBozLgSJeV0vo2ks5tPtk7gaJpZM4Rh9rv.
Understood. Now the two containers look like this (some less important nodes are removed from the original tree.) +--ro address-pool-running-out | +--ro total-address-count uint64 | +--ro max-address-count uint64 | +--ro allocated-address-conut uint64 +--ro pd-pool-running-out | +--ro max-pd-space-utilization threshold | +--ro pd-space-utilization threshold 'max-address-count' is maximum count of addresses that can be allocated in the pool. This value may be less than 'total-address-count'.
The intended function of the address/prefix pool utilization is to have a configurable threshold value which can be compared to the current pool utilization threshold (under the state tree). These are then used by the notifications section.
In the current model, the nodes around threshold are not defined this way and the logic for the notification needs to be added.