Re: [EFM] Re: OAM Transport Proposal
Brad,
Some feedback to your comments:
Best Regards,
Rich
--
"Booth, Bradley" wrote:
>
> Just a few comments below:
>
> Thanks,
> Brad
>
> -----Original Message-----
> From: Matt Squire [mailto:mattsquire@xxxxxxx]
> Sent: Tuesday, April 23, 2002 10:29 PM
> To: stds-802-3-efm@ieee.org
> Subject: [EFM] Re: OAM Transport Proposal
>
> Another attempt to address multiple questions at one time.
>
> 1) MDIO slowing preamble down. The intent is that the any
> bit handling
> of the preamble is done below the MDIO interface. One of
> the reasons,
> for me anyway, to keep the use of preamble to communicating
> a few very
> specific states was for this point exactly. Trying to
> communicate real
> 'data' would be slowed down by getting the data from the
> MDIO
> interface. The assumption is that the RS is enhanced to
> hold a small
> number of state variables which can be communicated via the
> preamble
> without turning into management frames over MDIO.
>
> BJB> Using the RS for the preamble will bypass the need for
> use of the MDIO. I just want to be sure that we do clarify that "pervasive
> access" does not mean instantaneous or high-speed access. I believe David
> Law's term "pervasive" means that the MAC, MAC Control and RS all have the
> same direct access to the MIBs rather than via MDIO. The management entity
> would have the same speed of access to the MAC Control MIB data as it would
> to the RS MIB data. Therefore, the only way the RS can be more responsive
> than MAC Control is if there are state machines in the RS to handle OAMinP
> without management intervention.
[RT] We're talking about responding to bits, such as fault and alarm
here. These conditions may be reported via MIB or MDIO/MDC for
posterity. However, the real value is in fast processing of these
conditions for protection, failover, etc. EFM may go to the residence,
but the residence is attached to the central office. That's where
protection and failover are important.
> 3) Null/Dummy frames screwing up MIBS. Yes semantics of the
> undersized
> frames variable will have to change to say something like
> "except for
> null/dummy frames which are counted by ...". But I think
> things can be
> defined in a way thats backward compatible. This, along with
> only using
> those frames when the other side supports it, should have
> the effect of
> MIB compatibility.
>
> BJB> I get the feeling that there are a lot of people that
> would rather live without this feature.
[RT] Let's stop calling them frames then. These OAM reports don't go to
the MAC and are merely 8-byte link messages not much different in nature
than 10GbE's Local Fault/Remote Fault 4-byte messages.
> 4) Clauses effected. We did a preliminary examination of
> the clauses
> that needed to be addressed by the proposal. The following
> is the list
> as I see it.
> - Clause 30 (Management). New MIB objects, enhanced
> locally and also
> enhanced to include peer info.
> - Clause 31 (MAC Control). Add OAM section, fraem
> formats, protocol
> operation, bla bla bla
> - Annex 43B. Add OAM types to slow protocols list, maybe
> change slow
> protocol definition, etc.
> - Clauses 22 & 45. New PHY monitoring registers for
> things like RX
> power, signal-to-noise ration, etc.
> - Annex 30A & 30B. New OIDs for managed objects.
> - Clause (new). OAM preamble byte format, use,
> description, etc.
> - Clause 22 & 35 (RS/MII, RS/GMII) - Dummy/null frame
> generation,
> inclusion of preamble transport capability.
> The preamble specific changes are the latter two. Please
> point out if
> we're missing some clause changes somewhere. This list does
> not reflect
> which clause changes are significant and which are minor.
>
> BJB> Do you have a list of clause editors to perform these
> modifications?
>
> - Matt
>
---------------------------------------------------------
Richard Taborek Sr. Intel Corporation
XAUI Sherpa Intel Communications Group
3101 Jay Street, Suite 110 Optical Strategic Marketing
Santa Clara, CA 95054 Santa Clara Design Center
408-496-3423 JAY1-101
Cell: 408-832-3957 mailto:rich.taborek@xxxxxxxxx
Fax: 408-486-9783 http://www.intel.com