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

["Bernard Aboba" <[e-mail]>]

>(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.



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