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

[Greg Daley <Greg.Daley@eng.monash.edu.au>]

Hi Bernard, 

----- Original Message -----
From: Bernard Aboba <bernard_aboba@hotmail.com>
Date: Monday, July 3, 2006 5:20 pm
Subject: Re: [DNA] Review of draft-ietf-dna-link-information-03.txt
To: gregd@research.panasonic.com
Cc: dna@eng.monash.edu.au, nicolas.montavont@enst-bretagne.fr,
alper.yegin@yegin.org, narten@us.ibm.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.

OK, I see your point more clearly now, as we're
taking the same approach with link-down.


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

I'd suggest that the special handling would be to ignore
the second indication, after receiving the original R-bit, if it
were used at all.

As you mentioned though, if there's no DNA protocol change,
we can leave it out.

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

OK, given this, and the fact that a node may not have processed
any STP/RSTP packets because of the boot operations, is it
reasonable to send an indication when the process receives
the link-up indication only?  

Or should it also send at  a timered indication associated with the
type of link (for point-to-point assuming RSTP) or STP (to be sure)?
The estimation could be wrong, and so would be conservative in 
that case (to ensure the medium is forwarding).



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

Yes.  This has been an issue with coaxial ethernet, and on systems
with faulty switches/hubs.  

Simultaneous indications only are prevented in causing storms from
the media becoming available, because the ports aren't forwarding though.  


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

802.1AB packets aren't forwarded by switches though, so
the impression I got was that they were available before
R/STP completed.

That's why we put this in the subsection on 802.1D networks.

It's not actually useful for this purpose anywhere else.

We could append a disclaimer about their applicability only
to .1D networks in this case.

> >NONE of the addresses is operable and will respond to probing.
> 
> In that case, DNAv4 will reset when the second "Link Up" is sent.

So do we need a second Link-Up indication from a timer?

Is it sufficient to recommend a small delay variation (+tive) to
prevent packet collisions?

Greg