[EFM] 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. 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).
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.
>
>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.
- Matt