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

From: Bernard Aboba <[email-masked]>
Date: Sun, 02 Jul 2006 13:38:12 -0700

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

---

From: Greg Daley <[email-masked]>
Date: Sun, 02 Jul 2006 20:24:18 -0400

Hi Bernard,

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

> indication and reset the timers (causing another reachability test to be 

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.

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

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

---

From: Greg Daley <[email-masked]>
Date: Sun, 02 Jul 2006 21:03:59 -0400

Greg Daley wrote:
[cut]
> which affects the network, or interoperability.

Please ignore the double negative, the additional not emerged
in editing a sentence.

Greg

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 03 Jul 2006 14:12:50 -0700

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

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

>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 

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.

---

From: Greg Daley <[email-masked]>
Date: Mon, 03 Jul 2006 21:07:07 -0400

Hi Bernard, 

----- Original Message -----
From: Bernard Aboba <[email-masked]>
Date: Monday, July 3, 2006 5:20 pm
Subject: Re: [DNA] Review of draft-ietf-dna-link-information-03.txt
To: [email-masked]
Cc: [email-masked], [email-masked],
[email-masked], [email-masked]

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

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

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

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.

> 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