RE: [10GBASE-T] EFM OAM...

["Grow, Bob" <bob.grow@intel.com>]

Jonathan:

What is clear to me is that it is a much closer fit to add 10GbE OAM to 802.3ah than it is to warp the scope of a 10GbE copper PHY project to add changes for 10GbE fiber PHYs.  (In answer to the question in your other email, I haven't studied what would need to change in Std 802.3ae to make OAM work with 10GbE.  If PHY counters are required and they are not included in 802.3ae, then more has to change than 46.3.4.)  I think it would be totally inappropriate for either -CX4 or -T to sign up for more that including hardware hooks (e.g., counters) that enable OAM functionality.

Is consistent management of 10GbE feeder links to lower speed EFM PHY based links important to the deployment of Ethernet subscriber networks?  If not, then I have trouble accepting your assertion that it is valuable for any kind of Ethernet.

The P802.3ah PAR scope for speeds clearly includes 10GbE.  The counter arguement for including 10GbE OAM in 802.3ah is that 10GbE is not, nor within the foreseeable future will, be an access technology, and that anything that 10GbE OAM does to enable lower speed "transfer of 802.3 format frames in subscriber access networks" exceeds the restriction of "minimal".

--Bob Grow

-----Original Message-----
From: Jonathan Thatcher [mailto:Jonathan.Thatcher@worldwidepackets.com]
Sent: Tuesday, February 25, 2003 11:56 AM
To: Grow, Bob; stds-802-3-10gbt@ieee.org
Cc: Howard Frazier (E-mail); Hugh Barrass (E-mail); Wael William Diab
(E-mail); Brad Booth (E-mail); Matthew B. Squire (E-mail); Kevin Daines;
David Law (E-mail)
Subject: RE: [10GBASE-T] EFM OAM...


Bob,

You make an excellent point. My understanding from your note below that you believe that 10GbE OAM can be considered within the scope:
"Define 802.3 Media Access Control (MAC) parameters and minimal augmentation of the MAC operation, physical layer specifications, and management parameters for the transfer of 802.3 format frames in subscriber access networks at operating speeds within the scope of the current IEEE Std 802.3 and approved new projects"

Regarding the Task Forces interpretation of this scope, we see the objective:
Support far-end OAM for subscriber access networks:
o Remote Failure Indication
o Remote Loopback
o Link Monitoring

Thus far in EFM, no one has claimed that 10GbE is within the scope of "subscriber access networks."

If it is, then it is certainly the case that it is in the scope of EFM and can be done by EFM.
If it is not, then it falls outside of EFM and needs to be done somewhere where it is within the scope of the project.

I'll write a belated comment against Clause 57 (now 12 hours late). We'll see what happens.

No matter what the outcome here, we should plan to make some kind of progressive decision at the March meeting.

jonathan

p.s. The answer to your other question is that OAM is valuable to Ethernet, even when it is a non-subscriber access network.

-----Original Message-----
From: Grow, Bob [mailto:bob.grow@intel.com]
Sent: Tuesday, February 25, 2003 11:18 AM
To: stds-802-3-10gbt@ieee.org
Subject: RE: [10GBASE-T] EFM OAM...


Jonathan:

With all due respect, it seems like we are going about this backward.  If 10GbE OAM is valuable, why isn't it being done within 802.3ah by the OAM subtaskforce? 

1.  Such work would be within the P802.3ah PAR scope. 

2.  P802.3ah won't progress to WG ballot for at least two plenary meetings.  If it is more complex than that, throwing it on top of 10GBASE-T would certainly be the wrong place to do the service to humanity.

3.  If a consistent OAM mechanism is desirable over all speeds of operation, then it will be better reviewed for consistency if all speeds of operation are specified at the same time.

4.  The 10GbE fiber PHYs are already standard, the earlier a functionality is defined, the more likely it is to appear in supporting silicon.

5.  Why wait 2-3 years for 10GBASE-T to define something that would only be within their scope if the scope was intentionally warped to include OAM for all 10GbE PHYs.  Judging from the 10GBASE-CX4 Working Paper,

6.  Immediate definition of the OAM hooks for 10GBASE-LX4 would allow 10GBASE-CX4 to include the same counters in their initial standard.  Right now is the time to add the necessary counters to 10GBASE-CX4, not in 2-3 years, since the -CX4 people plan to request WG ballot in March.  In other words, someone should be requesting time of Dan Dove for a March OAM presentation at which they would propose the PHY layer capabilities required for OAM support of a 10GBASE-X4 PHY.


My conclusion is that 10GBASE-T should not be doing this service to humanity.  The place for the work is the OAM subtaskforce of 802.3ah, and those that care about OAM for 10GbE need to move very quickly to see that necessary hooks are included within 10GBASE-CX4.

--Bob Grow




-----Original Message-----
From: Jonathan Thatcher [mailto:Jonathan.Thatcher@worldwidepackets.com]
Sent: Tuesday, February 25, 2003 10:28 AM
To: Shimon Muller; stds-802-3-10gbt@ieee.org
Subject: RE: [10GBASE-T] EFM OAM...



Because, Shimon, you know as well as any that the symbol error counters do not exist two layers above the PHY.

Also, just as with clause 24 and 36, 10 Gig needs to have the unidirectional aspects clarified during operation with OAM.

Besides, if there is anyone that understands the concept of "benefit to humanity," we have ample evidence that you do.  ;-)

As 10 Gig passes the baton to 10GBASE-T, I beseech you guys to "do the right thing."

jonathan

-----Original Message-----
From: Shimon Muller [mailto:Shimon.Muller@Sun.COM]
Sent: Tuesday, February 25, 2003 9:47 AM
To: atuncay@solarflare.com; stds-802-3-10gbt@ieee.org; Jonathan Thatcher
Subject: RE: [10GBASE-T] EFM OAM...

> OAM is implemented as a sublayer above the MAC, using frames. So,
> exactly what would be the trouble? Passing frames?

Precisely.
10GBASE-T is a PHY project. So why are we arguing about support or
non-support of functionality that is two layers above it?

I don't believe there is any need for an objective with regard to
OAM in 10GBASE-T. It's a non-issue.


                                        Shimon.