Subject: RE: [DNA] Revised text for link-information Ethernet section for comment

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 06 Jun 2005 12:00:58 +0300

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. 

Regards,

Dan

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Greg Daley
> Sent: Monday, June 06, 2005 10:06 AM
> To: [email-masked]; 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
> 
>

---

From: Tom Petch <[email-masked]>
Date: Mon, 06 Jun 2005 17:07:24 +0200

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)" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; "Alper Yegin"
<[email-masked]>
Cc: <[email-masked]>
Sent: Monday, June 06, 2005 11:00 AM
Subject: RE: [DNA] Revised text for link-information Ethernet section for
comment

---

From: Greg Daley <[email-masked]>
Date: Tue, 07 Jun 2005 12:42:32 +1000

Hi Dan,

Thanks for this.

> mail, it would be good to run this text with the Ethernet Interfaces MIB

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

> 802.1 family can run with different MAC technologies, Ethernet included,

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

I'll reply to that one separately.

[cut]
> domain. You probably would like to use 'bridging domain' instead. 

Thanks.
That sounds appropriate.

> The correct spelling is (IEEE) 802.1D

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

> interconnected by IEEE 802.1D bridges'

That's good.  Thanks.

[cut]
> Better use 'bridges' rather than 'switches'. 

OK.

>>a particular newly connected piece of ethernet will cause a 

OK.

> determine is the port can be connected to the network in a loop-free

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

> network in a loop-free environment'. 

Thanks.

[cut]
> 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?

> 802.1D-1998: clause 8.5.5.2, and the dot1dStpPortEnable object in the

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

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

---

From: Greg Daley <[email-masked]>
Date: Tue, 07 Jun 2005 15:39:55 +1000

Hi,

I've tried to address some of your concerns below.

Please tell me if it's still off-track.

> term Ethernet scarcely appears in IEEE 802.3).

That sounds fair enough.

How about the following introduction:

"Section title:   IEEE 802.3 CSMA/CD
------------------------------------

IEEE 802.3 CSMA/CD (commonly referred to as 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].
In order to provide connection of different LANs together into
a larger network, 802.3 LANs are often bridged together[802.1d].

In this section, the terms 802.3 and Ethernet are used interchangeably.
This section describes some issues in providing link-layer indications
on Ethernet networks, and shows how bridging affects these indications."

Is this more accurate?

> It is wrong to say that all media have Link Integrity Tests eg 10BASE5 (yes, it

OK...

Perhaps it is worth introducing the concept more explicitly.

"In order to determine whether the physical medium is ready for
  frame transfer, IEEE 802.3 Ethernet specifies its own link
  monitoring mechanism, which is defined for some, but not all
  classes of media.
  Where available, 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 twisted pair copper, light levels in fibre)."

Is that a reasonable description of the variation between media?

> happen, used to be common with slow - eg WAN - links)

I guess the peer LAN connected device could be either a bridge, an
end-station (router or host) or a repeater (in which case any other
device becomes visible on the LAN).

I there are bridges anywhere on the LAN, then you would expect
to see Hellos (although, topologies without bridges are valid too).

In section 8.10.2 of 802.1D 1998, (Table 8-3, the Hello timer has a
range of 1.0-10.0 seconds).

Also, there's an inequality:

Bridge_Max_Age >= 2 x (Bridge_Hello_Time + 1.0 seconds)

So I assumed that the inference of at least 2 messages were lost
could be applied.

Should I be more explicit about the maximum timeout?

I'm wondering if explicit statements about what a 'peer' may be,
and which devices are STP participants would help.  How about this?:

"...
For these technologies, even though the link-layer appears
available, no forwarding will occur until it is determined that
the port can be connected to the network in a loop-free
environment.

(new text)
   For host which are providing indications to upper layer protocols,
   even if the host itself does not implement bridging or STP,
   packet delivery across the network can be affected by their
   directly adjacent LAN peer which may be a bridge, or if this is
   a repeater, by the presence of STP bridges upon that LAN.

   Where the host is not running STP itself,
(end new text)
..."

Does this provide sufficient context to help disambiguate the
role of each device, and whether it is running STP?

Thanks for your work on this.

Greg