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