Subject: RE: [Hubmib] RFC 2665 Updates

From: Dan Romascanu <[email-masked]>
Date: Sun, 11 Mar 2001 14:18:15 +0200

I am trying to play the devils advocate here. 

> 9. Insert the following paragraph in the DESCRIPTION clause of
>    dot3StatsSymbolErrors:
>      "For operation at 10 Gb/s, it is a count of the number of
>       times the receiving media is non-idle (a carrier event) for
>       a period of time equal to or greater than minFrameSize, and
>       during which there was at least one occurrence of an event
>       that causes the PHY to indicate ReceiveError on the XGMII."
> 
	[Dan]  I am not sure this change will fly if we intent to advance
RFC 2665 to Draft. Sure the semantics for lower speeds remained unchanged,
and possible the implementation reports will prove that they work and
interoperate - but the new semantics for 10 Gb/s functionality did not go
through the same advancement criteria filter. 

	Regards,

	Dan

_______________________________________________
Hubmib mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/hubmib

---

From: John Flick <[email-masked]>
Date: Mon, 12 Mar 2001 12:26:13 -0800

I am hoping the IESG won't be quite so devilish here.  Otherwise, we
really would not be able to mention 10Gig at all in this document,
since none of the objects in this document have been implemented on
10Gig yet.  This really does not change the semantics of the object -
it just maps the existing semantics onto the signals you would get
from a 10Gig phy.

If it looks like it would create a problem, I guess we could leave
it out - it is primarily of interest to a chip designer, and the
wording is basically just copied from 802.3ae (which is the document
that a chip designer would most likely be reading anyway).  I was
just trying to be complete.  However, I would be kind of surprised
if the IESG saw this as a reason for not advancing to Draft.

John

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 12 Mar 2001 19:34:43 -0500

>> >       that causes the PHY to indicate ReceiveError on the XGMII."

        From an operational perspective, dot3StatsSymbolErrors
is pretty darn useful in troubleshooting a problem with packet
loss/frame loss on a particular interface.  THat object could
help fault isolation tremendously.  I would hope we wouldn't
drop such a useful object because our processes are too cumbersome.

Ran

---

From: John Flick <[email-masked]>
Date: Mon, 12 Mar 2001 17:05:08 -0800

To clarify, I was not suggesting leaving out the counter - it is
an existing object in RFC 2665.  It is one of the more useful counters
in this MIB for 100 Mbit and greater interfaces.  It was the additional
paragraph in the DESCRIPTION clause describing the mapping of this
counter to the 10Gig PHY signals that we may be able to leave out if
it causes process problems.  However, I really don't think it will
come to that.  From the operations perspective, this counter still
means exactly the same thing at 10 Gig as it meant at 1 Gig and at
100 Mbit.

John