Changes between Version 2 and Version 3 of DhcpWorkflow


Ignore:
Timestamp:
May 30, 2011, 6:05:04 PM (6 years ago)
Author:
tomek
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • DhcpWorkflow

    v2 v3  
    2323  - cons: last sprint will not be aligned with release
    2424
    25 Probably proposal is better, if Shane can handle increased workloads during sprint ends
     25Probably proposal is better than alternative, if Shane can handle increased workloads during sprint ends.
    2626 
    2727== Releases ==
     
    3434  - cons: dependency problems
    3535
    36 It is strongly recommended to release both components together (3.1)
     36It is strongly recommended to release both components together to avoid dependency problems after code is released. This code is going to be used be many users. Frustrated users trying to find out which DNS and DHCP components are supposed to match may not be the best way to go.
    3737
    3838== Reused modules ==
     
    4343
    4444== Proposed modules ==
    45 See also [wiki:DHCPComponents] that contain more fine grained features. Probabyl those two lists should be merged.
     45See also [wiki:DHCPComponents] that contain more fine grained features. Probably those two lists should be merged.
    4646- libdhcp - utility library, message/option parsing, encapsulation
    4747  (relays in v6), sanity checks protocol correctness (missing mandatory
    4848  options, extra options), etc.
    49 - b10-ifaces - interfaces and system access abstration layer. Something that will provide list of network interfaces, will receive and send data, possibly detect interface changes (like link switch, necessary for client's confirm), execution of external scripts (if we choose that); provide list of existing addresses configured,
    50 
    51 
     49- b10-ifaces - interfaces and system access abstration layer. Something that will provide list of network interfaces, will receive and send data, possibly detect interface changes (like link switch, necessary for client's confirm), execution of external scripts (if we choose that); provide list of addresses (MAC/IPv4/IPv6) configured on network interfaces, probably several slightly different socket interfaces (Linux/BSD/solaris).
    5250- b10-dhcp4 - core DHCPv4 protocol logic (e.g. generate responses)
    5351- b10-dhcp6 - core DHCPv6 protocol logic (e.g. generate responses)
     
    6058I think that the first proof-of-concept prototype of DHCP in BIND10 implementation should cover at least the following modules:
    6159- libdhcp - at least a skeleton version, probably will not parse or build anything, but at least provide API
    62 - b10-dhcp6 - we should start with DHCPv6 as its implementation is simpler; there is no need to hack raw sockets, no backward compatiblity with bootp, no message validation with icmp etc. The only (minor) difficulty is the need to bind multicast (a single setsockopt
     60- b10-dhcp6 - we should start with DHCPv6 as its implementation is simpler; there is no socket funkyness, no backward compatiblity with bootp, no message validation with icmp etc. The only (minor) difficulty is the need to bind multicast (a single setsockopt will do the trick).