RE: [EFM] RE: OAM Transport Protocol
Dan,
To your comment below, I was assuming that the RS layer would not pass
OAMiP Null Frames up to the MAC layer
Martin
> 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.
-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:dromasca@xxxxxxxxx]
Sent: Tuesday, April 23, 2002 2:16 PM
To: mattsquire@acm.org; stds-802-3-efm@ieee.org
Subject: [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
>