RE: [EFM] Re: OAM - this is Ethernet Bob but not as we know it
Hi Andrew
I guess all OAM transports need a scheduler, it's just that some are simpler
to implement than others. You only need a really simple one for IPG,
slightly more complicated for preamble because of the zero packet boundary
case, more complicated still for 'in-frames', as this may need pre-emptive
pause to cope with the 100% boundary case without packet loss (this will
work so long as the attached equipment implements pause).
I'll explain part two over a beer sometime.
Let me have your opinions on my email to Denny et al on the private circuit
issue please.
Matt - I am still at it at 0100 after that 0500 start this morning, must
have been that cappuccino at eleven AM, or I am getting conditioned by all
those ten hour flights and eight hour time shifts :-).
Thanks
Bob
-----Original Message-----
From: Andrew Smith [mailto:ah_smith@xxxxxxx]
Sent: 29 January 2002 00:46
To: Bob Barrett
Cc: stds-802-3-efm
Subject: RE: [EFM] Re: OAM - this is Ethernet Bob but not as we know it
Bob,
This is the bit of your message that I don't understand:
"The scheduler as you refer to it should be defined within EFM if there
needs to be one (that need depends on which OAM transport we choose)."
Could you elaborate on why you think some of the OAM transports need a
scheduler and some don't?
I couldn't parse most of your "part two" so maybe I haven't been spending
enough time with the "ILEC types" recently :-)
Andrew Smith
-----Original Message-----
From: Bob Barrett [mailto:bob.barrett@xxxxxxxxxxxxxxxxxx]
Sent: Monday, January 28, 2002 3:25 PM
To: Andrew Smith
Cc: stds-802-3-efm
Subject: RE: [EFM] Re: OAM - this is Ethernet Bob but not as we know it
Andrew
The first part is to address your email to me, the second half is my usual
soap box stuff.
Part one:
I think it's part a misunderstanding, actually probably mostly
misunderstanding :-).
What I am asserting is that the particular mechanism for prioritisation of
OAM transport (which ever we vote in) should be defined within the scope of
the EFM standard, and not documented as 'implementation specific', nor, as
appears to have become custom and practice within some 802 standards, not
mentioned as a requirement at all. The scheduler as you refer to it should
be defined within EFM if there needs to be one (that need depends on which
OAM transport we choose).
The device I describe as a "transparent non-filtering (non-802) bridge"
typically does have the capability to insert and remove bits, symbols and/or
packets in the stream of data flowing through it e.g. IPG and idle. It can
insert data in the IPG or preamble without affecting frame throughput. It
can generate frames for 'OAM in frames' but in so doing will have to delay
user frames, and it's buffer will runeth over at 100% load of frames with
min. IPG spacing (however unlikely that may be in the real world).
Part two:
I fear that if EFM fails to grasp the opportunity to define telco class
Ethernet transport in the last / first mile then the world will be left with
implementation based OAM transports that will meet the xLEC's perceived
needs, and the EFM OAM will be just a vehicle for negotiating which
implementation specific OAM transport mechanism will be used - the devices
will be EFM compliant technically, but not use EFM OAM in practice -
bizarre.
EFM is Ethernet transport in the 'transport of bits' sense, not the ISO
layer four sense. The latter is down to services that run over the facility,
as Roy likes to call the wire.
May be I have been spending too much time with ILEC types. May be that's
because they are still the market leaders in transport and services (not
integrated transport and services).
Rhetorical question: how does an integrated service box like a router
support the wholesale transport business model?
Best regards
Bob
-----Original Message-----
From: owner-stds-802-3-efm@majordomo.ieee.org
[mailto:owner-stds-802-3-efm@majordomo.ieee.org]On Behalf Of Andrew
Smith
Sent: 28 January 2002 08:50
To: Bob Barrett
Cc: stds-802-3-efm
Subject: 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.
...