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

[Greg Daley <gregd@research.panasonic.com>]

Hi Bernard,

Bernard Aboba wrote:
>>    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).

I apologize.  I didn't fix that text.

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

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

DNAv6 will reset timers based on indications, as described
in RFC2461bis.

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.

As you know, hysteresis algorithms are not typically not
standardized in IETF, unless there is a particular reason,
which affects the network, or interoperability.


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

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.

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

It's the Link-layer's responsibility to provide hints.
We're not talking about DNA function. It just receives one
or more hints from the link-layer.

DNAv4 or v6 remains link-layer agnostic, since it's not interpreting
individual link-layers' events, and is being given only the
abstract "Transition to availability", regardless of whether the
link-layer monitored spanning tree, or auto-negotiation.

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


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


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.

Forward Delay is listed in the parameters of the BPDU.

If you don't delay, there will be no packet forwarding, on any
STP port.  The link indication is wasted, and timers for
retransmission in the network layer will be invoked as the
first packets are dropped.

Indeed, we're suggesting _two_ indications.  One on attachment,
and one on STP completion (And RSTP as indicated in other paragraphs).

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.

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

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

It's not actually more efficient to try all addresses in DNAv4 in the
case you mention, if any spanning tree calculation (Rapid or not) as
NONE of the addresses is operable and will respond to probing.

These additional link hints are exactly to reset the timers as you
indicated (as mentioned about RFC2461bis above).


Greg