Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: [EFM] Re: OAM - To side-band or not to side-band


I would assert that anything we define for OAM transport should also be self
contained within 802.3 and not rely on implementation specifics in order to
work deterministically.

Non-deterministic management transport will not meet the broad market
acceptance criterion imho.


-----Original Message-----
[]On Behalf Of Roy Bynum
Sent: 24 January 2002 23:21
To: Geoff Thompson
Cc: Tony Jeffree; Geoff Thompson; stds-802-3-efm
Subject: Re: [EFM] Re: OAM - To side-band or not to side-band


This was a thread that got off into the distinction between the marketing
vernacular and the specific terminology of the standard.  It was an effort
to get some of the participants to get a better definition of what terms
were going to be used for what meanings.  I don't think it worked.

Thank you,
Roy Bynum

At 07:34 AM 1/24/2002 -0800, Geoff Thompson wrote:
>Rummaging through old mail. I don't think I saw this one in September.
>At 05:37 PM 9/26/01 -0500, Roy Bynum wrote:
>>Again, I think you may not be understanding what I am talking about.
>>Actually, according to Geoff Thompson, there is no such thing as a "full
>>duplex repeater".
>That is true within Ethernet Standards
>>A hub is not a repeater, it is a half duplex bridge.
>That is a new one on me! I certainly do not agree.
>A hub is:
>         1) An undefined term within 802.3 outside of the context of 1
> Mbps StarLANs (clause 12)
>         2) A commonly used commercial term for an 802.3 repeater and its
> included MAUs/PHYs/PMDs
>A repeater is not a bridge.
>A bridge is a packet store and forward device that separates collision
>domains, can accommodate speed changes beyond mere differences within a
>single speed clock tolerance and support full-duplex links.
>A repeater (802.3 def'n) is a bit level regenerate and reclock device that
>does not support full-duplex or speed changes. It does not separate
>collision domains. It does participate in collision/contention resolution.
>>A switch is a full duplex "bridge".  Both have 802.1 functionality.
>A "Hub" has no 802.1 functionality. All of the 802 pieces in a hub appear
>in 802.3.
>>What I am referring does not have any 802.1 or 802.2 functionality.  It
>>has no visibility into the revenue data traffic stream.  It can not get
>>access to the revenue traffic data stream to put upper level application
>>management traffic such as SNMP into the revenue traffic data stream in
>>either direction.
>>Thank you,
>>Roy Bynum
>>At 07:47 PM 9/26/01 +0100, Tony Jeffree wrote:
>>>Roy -
>>>Managed Ethernet repeaters (more commonly known as hubs these days) have
>>>been around for some while, and they use MAC frames to carry their
>>>(SNMP) management exchanges. I would therefore hesitate to use that
>>>particular argument either for or against the use of a side-band for OAM.
>>>Having said that, in networks with repeaters there may be distinct
>>>advantages in *not* using such a side-band for OAM - for example, where
>>>it is the device the other side of the repeater that you want to manage.
>>>Unless, of course, you start putting some form of addressing into this
>>>PHY-based side channel, which rapidly starts to look like you're
>>>replicating MAC functionality in the PHY, which begins to look like a
>>>waste of time & effort.
>>>As to T1 and T3, there's no doubt that some of the EFM participants
>>>(myself for one) are not intimately acquainted with the management
>>>entrails of these technologies, and with the thinking behind why they
>>>are that way. I'm sure that some of that information may be useful in
>>>informing what we do in EFM.  However, I'm equally sure that
>>>re-inventing T1 or T3, giving it a bit-rate that is a power of 10, &
>>>then badging it "Ethernet", would be a total waste of our time.  After
>>>all, if you continue to do what you have always done, you inevitably end
>>>up with what you have always had.
>>>At 11:31 26/09/2001 -0500, Roy Bynum wrote:
>>>>There are a lot of other reasons to have the OAM ou-of-band to the MAC
>>>>traffic, such as being able to support OAM on an intelligent
>>>>"transparent" full duplex repeater in the future.  When this group took
>>>>on the task of adding subscription network support for edge access
>>>>infrastructure into Ethernet, they took on applying most all of the
>>>>functionality that is being used today.  There is a long history of why
>>>>the functionality for these types of services is what it is.  How many
>>>>of the EFM Task Force people have looked at how the OAM overhead of T1
>>>>or T3 framing works today?  How many of the EFM Task Force people have
>>>>looked into why the OAM overhead of T1 or T3 framing works the way that
>>>>it does?