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




Matt

Some emails may cross on the wires due to the time difference, even with my
long hours.

I hope you found my latest effort on the private circuit issue constructive
rather than destructive.

This is an open democratic forum and all I am doing is pitching for what I
want to be in the spec., just like everybody else.

Best regards

Bob

-----Original Message-----
From: msquire@xxxxxxxxxxxxxx [mailto:msquire@xxxxxxxxxxxxxx]On Behalf Of
Matt Squire
Sent: 29 January 2002 01:18
To: Bob Barrett
Cc: stds-802-3-efm
Subject: Re: [EFM] Re: OAM - this is Ethernet Bob but not as we know it



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