Re: [DNA] Review of draft-ietf-dna-link-information-03.txt

[Bernard Aboba <bernard_aboba@hotmail.com>]

>The R-flag isn't necessarily being used, but the information
>that a prior indication may have been false can probably be
>fed into hysteresis algorithms.

If the DNAv6 specification doesn't use the 'R-flag' then I'm not clear why 
it has to be defined here.

>We don't want to even suggest that DNA can't be implemented without
>spanning tree knowledge.  It is beneficial in this case though, so
>we should probably change it to a MAY.

That makes sense.

>I'd contend that this has nothing to do with DNA (v4 or v6) at all, though.

I'd agree that this doesn't have anything to do with DNA.

>To suggest that either v4 or v6 hosts will not be interested in this, is 
>near-sighted, IMO.

The DNAv4 specification depends only on "Link Up".   On receipt of a "Link 
Up" event, the DNAv4 reachability tests will be carried out, and timers will 
be reset. However DNAv4 is rate limited so that "jittery" links will not 
result in packet storms (maximum of one DNAv4 reachability test/second).  So 
if the "Link Up" events occur more closely spaced than this they will be 
delayed.  Overall, there is no special processing that will occur due to the 
'R' bit, since there is no backoff or other state created by the false 
indication, other than the dampening.

>Estimation's not so hard as you indicate.   We're not talking
>about boot anyway, DNA is not for boot, it's for change detection.

DNAv4 is applicable both to boot/resume from sleep as well as movement 
between networks. If operational addresses are saved in stable storage, they 
are tested like any other address when the host reboots or resumes from 
sleep.  This can have a major impact on boot time reduction (several 
seconds) so that DNAv4 boot integration is expected to be fairly popular.

>This means that at the earliest possible time, the host is informed
>of the availability of the link.  If the prior indication is erroneous, and 
>DNA(?) packets may have been lost, it gets another shot because of the 
>additional indication.

The issue with multiple indications is that this causes twice as many 
packets to be sent.  This is particularly problematic if the link is jittery 
and hosts do not implement dampening, since packet storms can result.

>Events generated due to 802.1AB and RSTP/STP completion _are_ Link Up 
>indications. They just are generated on other events than completion of 
>autonegotiation.

IEEE 802.1AB packets can only be sent *after* a link is already usable by IP 
traffic.  For example, .1AB traffic occurs after completion of IEEE 802.1X,  
IEEE 802.11i 4-way handshake, etc.  So .1AB packets are not indicative of 
"Link Up", except in the unauthenticated wired case, where receipt of the 
packets might be taken as an indication that the link is up, short 
circuiting an RSTP/STP timer.

>NONE of the addresses is operable and will respond to probing.

In that case, DNAv4 will reset when the second "Link Up" is sent.