Subject: [dhcwg] AD Review Comments On: draft-ietf-dhc-dna-ipv4-09.txt

From: Margaret Wasserman <[email-masked]>
Date: Sun, 20 Mar 2005 09:13:04 -0500

Hi Bernard,

I have two questions about draft-ietf-dhc-dna-ipv4-09.txt that I 
would like to discuss before I send this document to IETF LC.

(1) Could you explain why sending an ARP request to the default 
gateway(s) of the MLPA (as described in section 2.2)  is a better 
mechanism to confirm what IPv4 configuration parameters should be 
used than re-initiating DHCPv4 and/or attempting to renew the DHCPv4 
lease (as described in section 2.3)?

The only text in the document that might explain this seems to be:

    In contrast to a DHCP exchange, which may be between a DHCP client
    and an off-link DHCP server, the reachability test is designed to
    verify bi-directional connectivity to the default gateway(s) on the
    MLPA.

But, I'm not sure why this is better than using DHCP and/or how this 
compensates for the possibility that the mechanisms described in this 
document may result in a two step process:  an ARP exchange (with a 
200ms timeout) followed by a DHCP exchange.  Has there been some 
analysis and/or empirical testing that shows that this mechanism 
produces superior results?

(2) Is it assumed that the host would not send any non-DNA-related 
IPv4 traffic using its presumed address on the MPLA during the 
reachability test and address acquisition phases?  If so, would it 
make sense to state that restriction here?  Do you expect that 
packets would be queued until the address status is resolved?  Or 
that upper layers would receive errors consistent with an interface 
that has not addresses configured?

Thanks,
Margaret

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

---

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 20 Mar 2005 07:37:39 -0800

>(1) Could you explain why sending an ARP request to the default gateway(s) 
>of the MLPA (as described in section 2.2)  is a better mechanism to confirm 
>what IPv4 configuration parameters should be used than re-initiating DHCPv4 
>and/or attempting to renew the DHCPv4 lease (as described in section 2.3)?

DNA is an optimization technique.  Where hints can "reliably determine" that 
the host has remained on the same subnet,  an ARP Request/Response exchange 
with the default gateway can be completed more quickly than a DHCPv4 
exchange with a DHCPv4 server that might be located off of the local 
network.

Note that if the host has in fact moved to a different subnet, then DNA can 
actually take longer than DHCPv4, since DNA will incur a timeout when the 
default gateway does not answer the ARP Request.  So the reliability of the 
hints is in practice quite important, as discussed in Appendix A.1.

>Has there been some analysis and/or empirical testing that shows that this 
>mechanism produces superior results?

Appendix A.1 analyzes the conditions under which DNA will produce better 
results.   Schemes similar to DNA have been shipping for several years now, 
and where the host changes subnets infrequently,  the benefits are 
substantial (e.g.  savings of 20 - 100 ms).

>(2) Is it assumed that the host would not send any non-DNA-related IPv4 
>traffic using its presumed address on the MPLA during the reachability test 
>and address acquisition phases?  If so, would it make sense to state that 
>restriction here?

I don't think this assumption is required.  If the lease is still valid, 
sending packets prior to completion of DNA cannot result in an address 
conflict, and MAC learning needs to occur anyway.

If the host is in fact on the MLPA and the configuration is valid, then 
sending the traffic is ok.  If not, then the packets will not elicit a 
response, but sending has no worse effect than an address change.  For 
example, if we are talking about VOIP traffic, the additional delay of DNA 
timeout + DHCP would probably be sufficient to cause the packet to arrive 
too late anyway, so the host might as well send it.  If we are talking about 
TCP traffic, then an address change would force connection teardown, at 
which point the additional loss would become irrelevant.

>Do you expect that packets would be queued until the address status is 
>resolved?  Or that upper layers would receive errors consistent with an 
>interface that has not addresses configured?

I don't believe it is necessary to queue packets pending completion of DNA, 
only pending receipt of an L2 "link up" event.  From the point of view of 
the host, if DNA is successful and the host confirms its existing IP 
configuration, there was no point during which the IP configuration became 
invalid; the host was attached to the same network all along.  An error 
message is only required if the configuration changes.