RE: [EFM] Re: OAM - this is Ethernet Bob but not as we know it
Matt
So is deterministic delivery of OAM data over the OAM transport an objective
for the OAM transport track or not? That bit is still unclear to me despite
your clarification. If it is not an objective I guess I have the option to
put it up as a motion at the March meeting.
This is not an objection, it's a request for clarification. (Stupid arrows
T-shirts may be pointed at me at will, I have a thick skin, and I am renown
for my persistence.)
For the wags I don't think we are in the realms of quantum physics yet.
Ethernet frames are bigger than photons even at 10G. We may have to start
worrying about wave particle duality at a tera bit :0)
Bob
-----Original Message-----
From: owner-stds-802-3-efm@majordomo.ieee.org
[mailto:owner-stds-802-3-efm@majordomo.ieee.org]On Behalf Of Richard
Brand
Sent: 29 January 2002 02:54
To: mattsquire@xxxxxxx
Cc: Bob Barrett; stds-802-3-efm
Subject: Re: [EFM] Re: OAM - this is Ethernet Bob but not as we know it
Thanks Matt. That's definitive and we need that in the EFM work. Anybody
object?
Richard Brand
Matt Squire wrote:
> I know Denny addressed the issue in a later note, but just to be clear
> to the masses -
>
> Whatever transport mechanism is defined for OAM will be defined
> completely and definitively within the 802.3 specification and will not
> require 802.1D or any other non-802.3 mechanism for either
> implementation or specification.
>
> I hope this officially becomes dead issue. I think these exchanges
> should satisfy all that we will define a complete specification within
> 802.3ah.
>
> - Matt
>
> >
> > I think it would be a good idea to ask Denny for some further
explanation as
> > to how the 'management in frames' frames take priority over payload
frames
> > within the scope of 802.3. I think I remember (seeing or hearing the
answer)
> > that this relied on an implementation specific use of two queues which
is
> > outside of the scope of 802.3.
> >
> > >From what I remember of 802.1D the prioritisation of BPDUs is an
> > implementation issue. 802.1D is a protocol specification. There is no
> > definition of transport over which BPDUs run within the 802.1D spec.,
other
> > than an assumption that it is an 802 MAC of some type.
> >
> > My point being that whilst OAM is a protocol within 802.3, and as such
the
> > protocol can be compared with 802.1D, we are also defining an OAM
transport.
> > The delivery mechanism for OAM transport needs to be deterministic
> > irrespective of MAC traffic load in order to meet the requirements of
the
> > service provider market place. We can argue semantics on deterministic
until
> > our BSE infected cows come home, but I think we all know what is
reasonable
> > and what is not reasonable from the service provider's point of view.
They
> > will test with zero packets and with flood packets, and expect OAM to
work
> > at both extremes.
> >