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

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

Alper Yegin wrote:
[cut]
>> Section 2.4.2
>>
>> "   Ethernet networks commonly consist of LANs joined together by
>>     transparent bridges (usually implemented as switches).  Transparent
>>     bridges require the active topology to be loop free.  The Spanning
>>     Tree Protocol (STP) achieves this by the exchange of Bridge Protocol
>>     Data Unit (BPDU), as defined in [IEEE-802.1D], which leads to, where
>>     required, the blocking of ports (i.e., not forwarding)."
>>
>> I think you need to mention RSTP here as well.

How about this?

    "Ethernet networks commonly consist of LANs joined together by
    transparent bridges (usually implemented as switches).  Transparent
    bridges require the active topology to be loop free.  The Spanning
    Tree Protocol (STP) and Rapid Spanning Tree Protocol (RSTP) achieve
    this by the exchange of Bridge Protocol Data Unit (BPDU), as defined
    in [IEEE-802.1D], which leads to, where required, the blocking of
    ports (i.e., not forwarding)."



>> "   Most hosts today do not listen to BPDU frames.  For these hosts,
>>     connectivity to the a port which is potentially bridged (any Ethernet
>>     port) carries the potential of frame loss if transmissions occur
>>     before any bridges' ForwardDelay timers have expired twice."
>>
>> "to the a port" - "to the port"

Thanks.

>> "   If no bridge configuration messages are received within the
>>     Bridge_Max_Age interval (default 20s), then it is likely that there
>>     is no visible bridge whose port is enabled for bridging (S8.4.5 of
>>     [IEEE-802.1D]), since at least two BPDU hello messages would have
>>     been lost.  Upon this timeout, a link up notification MUST be
>>     generated.
>>
>>     It is not easy for a non-STP host to distinguish between Disabled
>>     bridge ports and non-bridge ports with no IP nodes on them, as
>>     Disabled ports will have no traffic on them, and incur 100% sender
>>     loss.
>>
>>     Upon this Bridge_Max_Age timeout, a link up notification must be
>>     generated.  If an earlier link up was generated with the R-flag set,
>>     this new one MUST set the A-flag showing that packets sent within the
>>     prior interval were likely to have traversed the forwarding path
>>     (unless the port is disabled)."
>>
>> The next section talks about when to enable the delay, but I think you
>> could be more clear about this here as well.  For example, are you
>> recommending that hosts listen for STP/RSTP messages, or use 802.1AB
>> in order to decide on the appropriate delay?  Delaying for 20 seconds
>> by default probably isn't a good idea now that RSTP is becoming more
>> common.

I think the problem here can mostly be rectified by modifying
prior paragraphs.

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


And:

(Paragraph 12)
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.
    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.  If the previous link up notification had the R-flag set,
    then the B-flag) MUST be set in this notification.  The B-flag
    signifies that the packets sent within the prior interval were lost.


>> "  Due to the protocol's newness and lack of deployment, it is unclear
>>     how this protocol will eventually affect DNA in IPv4 or IPv6
>>     networks."
>>
>> DNAv4 does not utilize 802.1AB "hints", so this could be clarified.

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.


>> Section 2.4.4
>>
>> "   Link-Layer indications in Ethernet-like networks are complicated by
>>     additional unadvertised delays due to Spanning Tree calculations.
>>     This may cause re-indication (link up with A-flag) or retraction
>>     (link up with B-flag) of indications previously sent to upper layer
>>     protocols."
>>
>> What are the A and B flags?  Is this an artifact of a previous revision?
>>

The A and B flags are described in section 2, first paragraph of page 6.

The A and B flags provide an ability to re-indicate after an event
with an (R:Risk) flag set.  These flags can identify to the
upper-layer if the prior related event was associated with an
incorrect link-up indication (B: Blocked) or successful indication
(A: Allowed).  These indications are sent when the uncertainty of
the prior indication has passed.

The B-Flag is necessary if the host wishes to take corrective action
after reacting to the prior indication, for example,  resetting Router
Solicitation transmission counts or replaying data.

The A flag in a second indication may be sent since the initial
indication with an R-Flag may be ignored by cautious upper-layer
protocols.


Do you think it would be worthwhile to include it, or is the
description in section 2 OK?

Greg