Re: [dhcwg] WG last calls on several WG documents

[Said Ouissal <[e-mail]>]

Richard,

The point I am trying to raise is that for subnet alloc draft, it is 
required to run a full DHCP client on any intermediate node (DHCP 
proxy) in the DHCP hierarchy. While the "h-flag" can be used to 
signal not to use the hierarchy from a end-client perspective, it 
does not allow for something in the middle, which is to run a DHCP 
proxy (meaning have hierarchy) but without the DHCP client state 
required on an intermediate node in the hierarchy.

So the discussion point is either the DHCP client state complexity vs 
no need for a DHCP client state at the DHCP proxy position, and 
probably this (third) option (use hierarchy in a light way) could be 
merged/integrated with the current subnet alloc proposal.

Hope this clarifies.

Tx,
Said.

At 07:58 20-12-2006, Richard Johnson wrote:
>Let me try to address what seems to be the main point here.  The
>"hierarchical" version of subnet allocation allows the client,
>receiving the subnet, to use the subnet in whatever way it wants;
>thus allowing it to function as a DHCP server on that subnet, if
>wanted.  The "non-hierarchical" version (with the "h" flag cleared)
>functions in the way in which you seem to say you want; i.e., the
>client, receiving the subnet, should relay any further requests for
>addresses back to the original server.
>
>/raj
>
>
>On Nov 19, 2006, at 3:45 PM, Said Ouissal wrote:
>
>>Ralph,
>>
>>At 12:15 16-11-2006, Ralph Droms wrote:
>>>draft-ietf-dhc-subnet-alloc-04
>>>   Subnet Allocation Option
>>>   Need to review IPR claims related to this document
>>
>>One action item which remains open with regards to this draft was
>>the discussion (and decision) of merging this draft with the micro- 
>>block allocation draft (draft-shen-dhc-block-alloc-00.txt).
>>
>>To refresh your mind, the view carried by the authors of the micro- 
>>block allocation draft is that while draft-ietf-dhc-subnet-alloc-04
>>addresses the ability to assign a subnet to a dhcp client, it does
>>not well enough address the ability to assign a subnet to a DHCP
>>proxy or a "remote DHCP server", which in turn can re-assign single
>>IPs to clients. Especially if this DHCP proxy is co-located within
>>an edge router, it allows for more efficient provisioning and
>>network routing information annoucement for reachability reasons.
>>
>>To be more precise, draft-ietf-dhc-subnet-alloc-04 does address the
>>ability to request a subnet (as a client) so that it can be then
>>servicing (mentioned in the draft as hierarchical DHCP servers)
>>other clients, the main difference is that for Micro-Block the mode
>>of operation is based around an intermediate DHCP proxy agent who
>>leverages option 82 field and piggy-backs on a true client DHCP IP
>>address assignment process. This is a more simple mode of operation
>>and does not require a DHCP client operating on the intermediate
>>router/agent.
>>
>>Tx,
>>Said.
>>
>>
>>_______________________________________________
>>dhcwg mailing list
>>[e-mail]
>>https://www1.ietf.org/mailman/listinfo/dhcwg



_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg