Changes between Version 12 and Version 13 of DeclineDesign


Ignore:
Timestamp:
Nov 18, 2015, 3:56:54 PM (2 years ago)
Author:
tomek
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • DeclineDesign

    v12 v13  
    1515
    16161. set its state to DECLINED
    17 2. reassign it to special, well known "client" that represents declined state. This can be implemented as a special hardware address (v4) or DUID (v6).
     172. ~~reassign it to special, well known "client" that represents declined state. This can be implemented as a special hardware address (v4) or DUID (v6).~~
    1818
    19 Step 1 is useful for any new code to easily check whether a lease is declined or not. Step 2 is useful for existing code that may try to reuse or reassign the lease while it is still declined. Since the extra 'state' column will be also useful for lease expiration, it was decided to go along that route. It would be possible to do both 1. and 2., but objections were raised about redundant information. Hence the design calls for setting state to Declined and setting hwaddr/DUID to NULL.
     19Step 1 is useful for any new code to easily check whether a lease is declined or not. Step 2 is useful for existing code that may try to reuse or reassign the lease while it is still declined. Since the extra 'state' column will be also useful for lease expiration, it was decided to go along that route. It would be possible to do both 1. and 2., but objections were raised about redundant information. Hence the design calls for setting state to Declined and setting hwaddr/DUID to NULL. Technically speaking, the v6 lease is always expected to have duid_ field set to non-NULL value. Therefore a special representation was implemented for no-duid. See DUID::generateEmpty() method.
    2020
    2121There was a proposal to keep client info in the declined lease. That would be wrong for two reasons. First, once the lease is declined, it is no longer associated with the client who declined it. This would essentially be keeping historical information on purpose. The second reason is more practical. Had we kept the client info, there would be a risk for the lease to be used while still being in the declined state. There are many places in the existing code that check whether there's a lease for a given client. All of those checks would have to be augmented with extra conditions (something like: && lease->state != DECLINED). Some of those checks are done in quite complicated scenarios (like recovering from a conflict where client has a reservation, but is currently using a different address). It is much simpler and more technically correct to unassociate the lease from the client. If there's an operational need to determine who declined a lease, that information is available through the logging system.
     
    3535
    3636The following steps are taken when v6 lease is marked as declined:
    37 - DUID is set to null;
     37- DUID is set to special DUID object that represents null (see DUID::generateEmpty());
    3838- hwaddr is set to null (if present);
    3939- if there was a DNS update conducted, name change request for removing entries is started and all DNS related fields (hostname_, fqdn_fwd_, fqdn_rev_) are cleared;