Re: [DNA] (For reference) text with unconfirmed modifications to L2indications Ethernet/802.3 section

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

Hi Tom,

Tom Petch wrote:
> Some more comments in line.  I do find that my style is somewhat different to
> yours, so it may not be helpful to interpose my words directly between yours.

I've done that.  Thanks for the text.

> Two semantic concerns, I have not encountered hosts (ie not bridge/switches)
> that listen to BDPU to find out what is happening but that may be just my
> ignorance; certainly technically feasible and sensible for DNA, but do boxes
> actually do it?  You make several references to it.  (By contrast, I do
> encounter boxes which listen to routing protocol traffic to find out what is
> happening at layer three).

I think that what is not expressed properly is that devices which can't
inspect BPDU frames need to either:

a) Accept that up to 50 s of packets can be lost if they transmit
    immediately upon link arrival

b) Accept an induced delay of up to 50s (but probably 30s) before
    transmission of packets.

This has to be indicated to upper layer protocols.

The inspection of BPDU frames would have to be an optimization.

Here's my text proposal:

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

(added)
   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.
   This timeout defaults to 30 seconds (2 * 15 seconds), but may be
   as high as 60s[802.1d].  When sending indications to upper
   layers, the period where frame forwarding is potentially unavailable
   should be indicated to upper-layer protocols.

   Alternatively, a host can listen for BPDUs and use them to
   determine the length of port blockage which will occur in their
   particular circumstances.
(end added)

   Upon learning that an adjacent port is running STP or RSTP,
   the host may send a Link-Up indication with a 'forwarding available'
   parameter upon expiry of calculated delays to indicate that
   general packet transfer is available across the LAN.
..."

This brings forward discussion of Forward Delay parameters
Which means that the same gets removed from a later paragraph.

"...
  If a BPDU is received, and the adjacent switch is running the original
   Spanning Tree Protocol, then host cannot successfully send
   packets until at least twice the ForwardDelay value in the received
   BPDU has elapsed.  After this time, the host can send a link-layer up
   indication showing that the previous interval after the
   PMA_LINK.indicate(OK) event was one of loss.
..."


> And this peer thingy; I don't get it (except in the case of two boxes directly
> connected by one piece of UTP or fibre).  I don't see repeater or bridge as
> peer.  Repeater is physically repeating, passive except in so far as it
> propagates collisions and participates in Link Integrity.  Bridge is also
> (usually) transparent; you don't see it, apart from added delays, until it
> decides not to forward, for up to 50s, as part of a topology change (or unless
> you listen in to BPDU which, as I said, I only see bridges doing).  I struggle
> to see it as peer in any meaningful sense.

You're right about the peers.  They're misleading.  Any bridge on
the path between a host and its destination will block frames.

In addition to your suggestions, I've removed the references to
peers with the following two paragraphs.

------------
Replace:

"...
   Where the host is not running STP itself, no explicit indication
   that forwarding has begun is sent from a switch to its peer devices.
   Therefore, a host may not know when STP operations have completed,
   and when it is safe to inform upper layers to transmit packets.
..."


With:

"...
   Where the host is not running STP itself, no explicit indication
   that forwarding has begun is sent from a switch.
   Therefore, a host may not know when STP operations have completed,
   and when it is safe to inform upper layers to transmit packets.
..."

-----------
Replace:
"...
   If no bridge configuration messages are received within the
   default Bridge_Max_Age interval (20s), then it is likely that
   the peer's port is Disabled for bridging (S8.4.5 of [802.1D]),
   or the device is not a bridge, since at least two BPDU hello
   messages have been lost.
..."

With:

"...
   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 [802.1D]), since at least two BPDU hello messages would
   have been lost.
..."

-----------
Replace:

"...
   The recently defined 802.1AB Link-Layer Discovery Protocol
   (LLDP) provides information to directly connected devices
   about its MAC peer[802.1AB].
..."

With:

"...
   The recently defined 802.1AB Link-Layer Discovery Protocol
   (LLDP) provides information to devices which are directly
   adjacent to them on the local LAN[802.1AB].
..."

-----------

Replace:

"...
   The LLDP message may a System Capabilities TLV, which
   describes the MAC and IP layer functions which a device is
   currently using. Where a host receives the
   Systems Capabilities TLV which indicate that no Bridging or
   Repeating is occurring on the link-layer peer, then no delays
   for STP calculation will be applied to packets sent from this
   host, if does not perform STP itself.  This would allow the
   host's link-layer to indicate that to its knowledge the link
   is available for packet transfer.
..."

With:

"...
   The LLDP message may a System Capabilities TLV, which
   describes the MAC and IP layer functions which a device is
   currently using. Where a host receives the
   Systems Capabilities TLV which indicate that no Bridging or
   Repeating is occurring on the LLDP transmitter, then no delays
   for STP calculation will be applied to packets sent through this
   transmitter, if the host does not perform STP itself.  This
   would allow the host's link-layer to indicate that to its
   knowledge the link is available for packet transfer.
..."

---------

Replace:

"...
   Additionally, if a host receives a Systems Capabilities TLV
   which indicates that the peer is a switch or repeater, the
   host's advertisement that it is an (end-host) Station-Only,
   may tell the peer switch not to run STP, and immediately
   allow forwarding.
..."

With:
"...
   Additionally, if a host receives a Systems Capabilities TLV
   which indicates that the LLDP transmitter is a switch,
   the host's advertisement that it is an (end-host) Station-Only,
   may tell the switch not to run STP, and immediately
   allow forwarding.
..."

----------

I'll send a completed revision off-list.

Thanks once again for your input.


Greg.