[EFM] RE: OAM Transport Protocol
> -----Original Message-----
> From: Matt Squire [mailto:mattsquire@xxxxxxx]
> Sent: Tuesday, April 23, 2002 8:57 PM
> To: stds-802-3-efm@ieee.org; Romascanu, Dan (Dan)
> Subject: Re: OAM Transport Protocol
>
>
>
> >
> >> 4) Null/dummy frames break MIBs? I don't think its that bad.
> >> Certainly
> >> the MIB would have to be enhanced with a counter for the
> >> number of such
> >> frames, but the changes are minimal.
> >>
> >>
> >> - Matt
> >
> >It's a little bit more complicated, I am afraid. If the
> >required change would be adding one or even more objects, this
> >would be certainly palatable. This is not considered as
> >'breaking' current standards. However, changing the threshold
> >of what is considered a minimal length frame is a change in
> >semantics that would make the existing implementations of the
> >Ethernet and RMON MINS counters inaccurate for EFM. It is not
> >only that the new type of frames are ignored, but also
> >existing counters become inaccurate. We also need to take into
> >account that most implementations do this counters in silicon.
> >EFM will require replacing the current installed base of
> >management silicon and monitoring devices and applications,
> >and will not be capable of coming and saying 'you can use the
> >current deployed base of applications and monitoring problems'.
>
> I disagree that the existing counters would be inaccurate.
> First, I'll
> make the assumption that the null/dummy frame concept is not
> used unless
> its supported by both sides. This is one of the foundations of the
> baseline, that capabilities negotiation is done via frames and any
> preamble signaling is not used unless supported by both
> sides. Second,
> I'll make the assumption that we augment the MIB with a
> counter for the
> number of dummy frames, and that such frames are not counted
> against the
> currently existing counters but are counted against these new
> variables.
No problem until this point.
> Existing counters do not become innacurate, they still
> register the same things they do today (a null/dummy frame
> would not be
> indicated by any existing counter).
>
Here is the problem. You have counters (in silicon in most cases) that whenever they see anything shorter than the current minimal frame, will say too short packet. You cannot change this with out implementing what is called a semantic change. Moreover, you have filters there (again, most of them in silicon) that would not allow these 'illegal packets' to be brought to some protocol decoding machine to have their content inspected.
> The proposal does not require replacing the currently
> installed base of
> silicon and management applications. Certainly the MIB will be
> enhanced. We've talked about enhancing it for better performance
> monitoring (ie get closer to calculating BER as an example).
> The change
> for adding a variable for null/dummy frames is relatively
> insignificant
> and not applicable unless supported, just like any other new variables
> we add.
The problem that this is not an incremental change only, as you try to present it, but implies changes in the already existing semantics of what is a legal Ethernet packet.
>
> >
> >This relates to the later question (#6 in your list) as a
> >strong argument to make the null/dummy frames be 'true'
> >Ethernet frames of minimal size'.
> >
> >
>
> Its certainly a factor to consider. Although I think there
> are reasons
> one might reach the same conclusion, IMHO this MIB factor isn't a big
> consideration. I'm not arguing against your conclusion,
> there are valid
> reasons to get there, but I don't believe that MIB
> augmentation is that
> big of a stick.
I do not disagree. The stick is as big as it is...
>
> - Matt
>