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

[Tom Petch <nwnetworks@dial.pipex.com>]

I agree with Dan and would add:

Properly the technology is IEEE 802.3 CSMA/CD (and even that leaves out quite a
lot of the
title) and I would like you to introduce it as such, adding something like
'commonly referred to as Ethernet'

If you are going to use Ethernet (as opposed to say CSMA/CD or IEEE 802.3) in
the rest of the document, then you should add a sentence to that effect (the
term Ethernet scarcely appears in IEEE 802.3).

It is wrong to say that all media have Link Integrity Tests eg 10BASE5 (yes, it
is still in use).

The default I see is BPDU Hello every two seconds so within the default 20s,
more than two will have been lost.  But this paragraph and the following one
confuse me with references to peer device.  This is broadcast, a degenerate case
being only two devices, and if there is a bridge anywhere in the topology, then
I expect to see BPDU every 2s. Spanning Tree will not work without them so not
seeing them says either no bridges or Spanning Tree has been disabled (does
happen, used to be common with slow - eg WAN - links)

Tom Petch

----- Original Message -----
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: <greg.daley@eng.monash.edu.au>; <dna@eng.monash.edu.au>; "Alper Yegin"
<alper.yegin@samsung.com>
Cc: <dbharrington@comcast.net>
Sent: Monday, June 06, 2005 11:00 AM
Subject: RE: [DNA] Revised text for link-information Ethernet section for
comment

> 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.
>
> The co-chair of the Bridge MIB is also copied.
>
> 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.
>
> >
> > In Ethernet networks, hosts are connected by wires or by
> > optic fibre to a switch (bridge), a bus (e.g. co-axial
> > cable), a repeater (hub), or directly to another ethernet
> > device.  Interfaces are symmetric, in that while many
> > different physical laters may be present, medium access
> > control is uniform for all devices.
> >
> > In order to determine whether the physical medium is ready
> > for frame transfer, Ethernet specifies its own link
> > monitoring mechanism.
> > This Link Integrity Test operation is used to identify when
> > packets are able to be received on an ethernet segment.
> > It is applicable to both wired and optical physical layers,
> > although details vary between technologies (link pulses in
> > copper, light levels in fibre).
> >
> > Subsection: Link Integrity Tests in 802.3 networks.
> > ---------------------------------------------------
> >
> > The status of the link as determined by the Link Integrity
> > Test is stored in the variable 'link_status'.  Changes to the
> > value of link_status (for example due to Link Integrity Test
> > failure) will generate link indications if the technology
> > dependent interface is implemented on an ethernet device [802.3].
> >
> > The link_status has possible values of FAIL, READY and OK.
> > When an interface is in FAIL state, Link Integrity Tests have failed.
> > Where status is READY, the link segment has passed integrity
> > tests, but autonegotiation has not completed.  OK state
> > indicates that the medium is able to send and receive packets.
> >
> > Upon transition to a particular state the Physical Medium
> > Attachment subsystems generates a
> > PMA_LINK.indicate(link_status).  Indications of OK state may
> > be used as Link-Up indications for DNA.
> > PMA_LINK.indicate(FAIL) may be used as a Link-Down indication
> > reliably by DNA[802.3].
> >
> > 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.
>
> >
> > Subsection: 802.1d Bridging and its effects on link indications
> > --------------------------------------------------------------
>
> The correct spelling is (IEEE) 802.1D
>
> >
> > 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'
>
> >
> > Due to its necessity in preventing bridge loops, bridging has
> > become synonymous with the spanning tree protocol.
> > The spanning tree protocol and its variants provide loopless
> > forwarding between ethernet-like switches within a broadcast domain.
> >
> > 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'.
>
> > By default, the spanning tree protocol does not know whether
> > a particular newly connected piece of ethernet will cause a
> > bridge loop.
>
> Just 'loop'.
>
> > 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'.
>
> > 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'.
>
> >
> > 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.
> >
> > As described in (Subsection on 802.1AB LLDP) explicit
> > knowledge may be available through the new Link-Layer
> > Discovery Protocol as to whether frame forwarding operation
> > is immediately available.
> >
> > 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
> > reception of BPDUs or timeouts.
> >
> > 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).
>
> >
> > 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.
>
> >
> >
> > Subsection: 802.1AB Link-Layer Discovery Protocol.
> > -------------------------------------------------
> >
> > The recently defined 802.1AB Link-Layer Discovery Protocol
> > (LLDP) provides information to directly connected devices
> > about its MAC peer[802.1AB].
> >
> > LLDP sends information periodically, and at link status
> > change time to indicate the configuration parameters of the device.
> > Devices may either send or receive these messages, or both.
> >
> > 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.
>
> >
> > 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.
> >
> > 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
> >
> >