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

[Bernard Aboba <bernard_aboba@hotmail.com>]

>    Where it is not known that forwarding operations are available, a
>    host needs to assume that STP is being performed, and may  indicate
>    full connectivity only based on timeouts or reception of BPDUs.

RSTP is now the default on new switches, so this paragraph introduces a 
delay even in situations where it is not necessary.  In practice, DNA should 
be able to handle the situation of a non-ready port by retransmitting (at 
least this is what DNAv4 would do).

>X  The host may send link up indications as soon as the link is viable
>X  for packet transfer, although all such all indications sent until
>X  forwarding confirmation MUST contain the R-flag set to indicate  risk
>X  of loss.

Does the DNAv6 specification state what to do on receipt of the 'R-flag' 
(e.g. reset timers)?  DNAv4 would just treat it as another "Link Up" 
indication and reset the timers (causing another reachability test to be 
sent).

>X  Where possible, hosts SHOULD monitor for Bridge PDUs, in order to
>X  determine what type of spanning tree may be running on the  network.

In practice, this would require hosts to implement passive RSTP/STP in order 
to provide a fully compliant DNA implementation.  I'd question whether any 
implementations are likely to do this.  DNAv4 implementations certainly will 
not do this (since DNAv4 is link layer agnostic).

>    If a BPDU is received, and the adjacent bridge is running the
>    original Spanning Tree Protocol, then a host cannot successfully send
>    packets until at least twice the ForwardDelay value in the  received
>    BPDU has elapsed.  After this time, a link up notification MUST be
>    generated.

The host may not be capable of receiving packets until it has fully booted, 
so that it may have difficulty estimating when twice the ForwardDelay period 
has elapsed.  Forcing a mandatory waiting period therefore may not be 
possible or even desirable.  DNAv4 implementations will not implement this 
delay.

>OK.  I don't see why it can't use those hints, but we can modify the text 
>to.
>
>  Due to the protocol's newness and lack of deployment, it is  unclear
>  how this protocol will eventually affect DNA, particularly in IPv6
>  networks.

DNAv4 does not utilize any link layer hints other than 'Link Up'.   It does 
not do so because it is faster and more general to try all operable 
addresses instead.  Therefore DNAv4 implementations will not utilize 802.1AB 
(or RSTP/STP for that matter).   The proposed text still seems vague about 
this.