Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: [EFM] Re: OAM - this is Ethernet Bob but not as we know it




Bob,

What you call "implementation specific prioritisation" has nothing to do
with bridges, routers or other relay agents. It's a characteristic of a
scheduler that is placing units of data onto an outgoing link. It doesn't
matter whether these units are bits, symbols or frames, there's still a
scheduler there in all of the schemes I've seen presented. It seems like the
main argument here is just about whether it is bits, symbols or packets that
are scheduled and about whether it is simpler to implement one over the
others.

Or am I misunderstanding what you mean by an "EFM interface"? Does the
device you describe as a "transparent non-filtering (non-802) bridge"
typically have the capability to insert and remove bits, symbols and/or
packets in the stream of data flowing through it?

Andrew Smith


-----Original Message-----
From: owner-stds-802-3-efm@majordomo.ieee.org
[mailto:owner-stds-802-3-efm@majordomo.ieee.org]On Behalf Of Bob Barrett
Sent: Sunday, January 27, 2002 3:21 PM
To: mattsquire@xxxxxxx; Geoff Thompson; Tony Jeffree
Cc: stds-802-3-efm
Subject: RE: [EFM] Re: OAM - this is Ethernet Bob but not as we know it



Matt

I know most delegates to EFM have the basic assumption that any
implementation will include a bridge or a router, and that implementation
specific prioritisation will meet the need. However, this is not a pure
specification from an engineering point of view. If a company chooses to
build a product that has EFM interfaces and does not include a bridge or a
router engine e.g. a non-802 full duplex repeater with an 802.3 EFM
interface and an 802.3 interface, then they should still be able to
implement the OAM standard on the EFM interface. You could call such a box a
transparent non-filtering (non-802) bridge, that IS an implementation issue.
The point being that such a system might meet a market need and that the EFM
OAM standard should not preclude such a system from using EFM OAM.

If the final EFM standard does not define OAM that works with just an EFM
interface (whatever the OAM transport) then I would assert that we will not
have met the terms of the PAR.
...