Re: [DNA] Revised text for link-information Ethernet section forcomment

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

Hi Dan,

Thanks for this.

Romascanu, Dan (Dan) wrote:
> Please see comments to this section below. As I said in my previous
> mail, it would be good to run this text with the Ethernet Interfaces MIB
> and Bridge MIB lists. 

I've just subscribed to the lists,
so I'll send the text to them, with suggested
amendments marked.

Below I've ACK'ed or asked questions about your comments.

Sorry about the length of the message, but I've tried to keep
sufficient context to allow discussion of alternate variants of
text.

Any further feedback you can provide would be appreciated.

Greg

> The co-chair of the Bridge MIB is also copied. 
> 
> Regards,
> 
> Dan
> 
> 
> 
>>-----Original Message-----
>>From: owner-dna@ecselists.eng.monash.edu.au 
>>[mailto:owner-dna@ecselists.eng.monash.edu.au] On Behalf Of Greg Daley
>>Sent: Monday, June 06, 2005 10:06 AM
>>To: dna@eng.monash.edu.au; Alper Yegin
>>Subject: [DNA] Revised text for link-information Ethernet 
>>section for comment
>>
>>Dear Alper and WG,
>>
>>Here is an update of the text provided before last IETF for 
>>Ethernet in the link-information document.
>>
>>I'm not sure how useful the recommendations are to people, 
>>and apparently there was some difficulty even amongst DNA 
>>illuminati in understanding what I was getting at in the last version.
>>
>>So if you have any opinions or experience, please comment 
>>on-list, in order that forward progress can be made.
>>
>>Greg
>>
>>
>>Text follows, potentially to be inserted as a section in the 
>>draft-ietf-dna-link-information.
>>
>>-------------------------------------------------
>>
>>Ethernet is the most commonly deployed Local Area Network 
>>technology in use today.
>>As deployed today, it is specified by both a physical 
>>layer/medium access control (MAC) layer specification 
>>[802.3], and a bridging specification used for connecting 
>>different ethernet LAN segments together [802.1d].
> 
> 
> No - this is not accurate. Ethernet is only IEEE 802.3 technology.
> Bridging technology as defined by IEEE 802.1D and other standards in the
> 802.1 family can run with different MAC technologies, Ethernet included,
> but is not Ethernet. 

I think Tom Petch has a description which could supply replacement
text.

I'll reply to that one separately.

[cut]
>>Such indications do not definitively ensure that packets will 
>>be able to be received through the switching infrastructure 
>>which composes a broadcast domain, though.  Such operations 
>>are governed by bridging.
> 
> 
> 'The term switching infrastructure' has no firm definition in standards.
> Beyond this, 'switches' can be deplotyed beyond one single broadcast
> domain. You probably would like to use 'bridging domain' instead. 

Thanks.
That sounds appropriate.

> 
>>Subsection: 802.1d Bridging and its effects on link indications
>>--------------------------------------------------------------
> 
> 
> The correct spelling is (IEEE) 802.1D

Thanks. I'll adopt the proper convention with document names.

>>Ethernet networks are commonly bridged.
>>Bridging is a mechanism which provides loopless paths across 
>>a series of link-segments.
> 
> 
> 'Link-segments' is again fuzzy from a standard terminology perspective.
> Maybe 'Briding is a mechanisms which provides loopless paths across LANs
> interconnected by IEEE 802.1D bridges'

That's good.  Thanks.

[cut]
>>The Spanning Tree Protocol (STP) exchanges Bridge Protocol Data Unit
>>(BPDU) frames in order to pass information about which 
>>switches are connected to others.
> 
> 
> Better use 'bridges' rather than 'switches'. 

OK.

>>By default, the spanning tree protocol does not know whether 
>>a particular newly connected piece of ethernet will cause a 
>>bridge loop.
> 
> 
> Just 'loop'.

OK.

> 
>>Therefore it typically blocks all traffic from a port until 
>>spanning tree operations can determine if a loop exists.
>>
> 
> 
> Better - 'therefore it will block all traffic from and to a newly
> connected ports with the exception of the STP BPDUs. The STP will
> determine is the port can be connected to the network in a loop-free
> environment'.

I have a question.  Doesn't it allow transmission of other
packets which are LAN only (non-bridged)?

I was trying to allow for 802.1AB LLDP packet arrival.

Perhaps:

"...therefore it will block all traffic from and to a newly
connected ports with the exception of some unbridged management frames.
The STP will determine if the port can be connected to the network in
a loop-free environment."

>>For these technologies, even though the link-layer appears 
>>available, no forwarding will occur until the network is 
>>satisfied that the connected is not another bridge or repeater port.
> 
> 
> Better '... Until it is determined that the port can be connected to the
> network in a loop-free environment'. 

Thanks.

[cut]
>>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.
> 
> 
> 
> No need to do this IMO. For its own availability a host knows when a
> local port is transiting into forwarding state. See IEEE 802.1D-1998:
> clause 8.5.5.2 and the dot1dStpPortState in the Bridge MIB (latest
> version
> http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-bridge-brid
> gemib-smiv2-10.txt to be published as a proposed standard any time now).

I guess that what I've been mostly focussed on is the action and
reasoning of an end-host connecting to an ethernet-LAN when the
host doesn't actually run STP itself.

I'd agree that if the host is actually capable of bridging these
rules would apply.

If the host isn't STP capable (for example by not being a bridge)
it won't know what its STP port state is.  It does need to know
if the frames will be dropped by an adjacent bridge.

Would it be useful to state some of these assumptions at the top
of the subsection?


>>If no bridge configuration messages are received within the 
>>default Bridge_Max_Age interval (20s), then it is unlikely 
>>that the peer device is a bridge, since at least two BPDU 
>>hello messages have been lost.
>>Upon this timeout, a host may (re)-send a link-layer 
>>indication showing that packets sent within the prior 
>>interval were likely to have traversed the forwarding path.
>>
>>If a BPDU is received, and the peer is running the original 
>>Spanning Tree Protocol, then host cannot successfully send 
>>packets until at
>>least the peer's ForwardDelay timer has expired twice.   This timeout
>>defaults to 30 seconds (2 * 15 seconds) [802.1d].  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.
>>
>>If the switch is identified as performing Rapid Spanning Tree 
>>Protocol (RSTP), it instead waits Bridge_Max_Age after packet 
>>reception (advertised in the BPDU's Max Age field), before forwarding.
>>For ports which are known to be point-to-point through 
>>autonegotiation, this delay is abbreviated to 3 seconds after 
>>autonegotiation completes [802.1d].
>>After either of these delays, a link-layer indication updating the
>>PMA_LINK.indicate(OK) can show that the interval between 
>>indications was a lossy interval.
> 
> 
> What is the bridge port is disabled by a management command? See IEEE
> 802.1D-1998: clause 8.5.5.2, and the dot1dStpPortEnable object in the
> Bridge MIB.
>

I guess that's a good point. The MAC on either device is actually
enabled, but it's not possible to tell except for the fact that no
packets are forwarded...

How about?:
(replacing the first quoted paragraph above, with three short paras)

"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), or the device
is not a bridge, since at least two BPDU hello messages have been
lost.

It is not easy for a non-STP host to distinguish between
Disabled 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 host may (re)-send a
link-layer indication showing that packets sent within the prior
interval were likely to have traversed the forwarding path
(unless the port is disabled)."

[cut]
>>
>>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.  This would allow an 
>>authoritative link-layer indication to be sent to 
>>upper-layers about the availability of packet transfer.
> 
> 
> This does not look right. The IEEE 802.1AB system capabilities reflects
> only what capabilities are enabled on the remote host (see Section
> 9.5.8.1 in the IEEE 802.1AB specification). The fact that a bridge for
> example is connected at the other end does not mean that the port of the
> bridge is enabled, or that spanning tree allows data packet transfer. 

You're right.

If the local host is not STP enabled (as assumed before), and neither
is the other port (at the other end advertises that it isn't a switch
or repeater) then I guess it can be inferred that STP won't be
available on the other end.

If this isn't a valid assumption, we may have to revisit this.

The disabled port issue would be the same as no LLDP, but the fact that
the link-layer device states it is not a bridge, means the issue
of whether packets can get through is not determinable through the
link-layer.

I'd suggest replacing the paragraph you were indicating
with the one below:


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

Is this text better?:

Below I'd also add the references to 802.1D discussed in the
previous section:

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

>>Proprietary extensions may also indicate that data forwarding 
>>is already available on such a port.  Discussions of such 
>>optimizations is out-of-scope for this document.

Here is some added text which may clarify fallback to 802.1D
assumptions:

"Where the LLDP indicates that a peer is a switch or a repeater,
  senders of link-layer indications need to assume that the peer is
  dropping frames on the newly connected link in conformance with
  STP[802.1D].  It should therefore adopt the delays as stated in
  (Subsection: 802.1D Bridging...) above."

>>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.
>>
>>
>>Summary
>>-------
>>
>>Link-Layer indications in Ethernet-like networks are 
>>complicated by additional unadvertised delays due to Spanning 
>>Tree calculations.
>>This may cause re-indication or retraction of indications 
>>previously sent to upper layer protocols.
>>
>>
>>Greg
>>
> 
>