RE: [EFM] Re: OAM - this is Ethernet Bob but not as we know it
Carlos
I think this (service defintions and QoS) is the area where the EFM A and
the MEF have a chance to solve the problem.
802.3 is not the body for services, as Geoff et al have pointed out.
These other bodies can do that, why not pay the $15k, join up and put your
views in a forum where they can be acted upon?
Thanks
Bob
-----Original Message-----
From: owner-stds-802-3-efm@majordomo.ieee.org
[mailto:owner-stds-802-3-efm@majordomo.ieee.org]On Behalf Of Carlos
Ribeiro
Sent: 29 January 2002 01:33
To: Bob Barrett; Andrew Smith
Cc: stds-802-3-efm
Subject: Re: [EFM] Re: OAM - this is Ethernet Bob but not as we know it
[Bob Barrett]:
> I fear that if EFM fails to grasp the opportunity to define telco class
> Ethernet transport in the last / first mile then the world will be left
> with implementation based OAM transports that will meet the xLEC's
> perceived needs, and the EFM OAM will be just a vehicle for negotiating
> which implementation specific OAM transport mechanism will be used - the
> devices will be EFM compliant technically, but not use EFM OAM in practice
> - bizarre.
This is a special case of my overall concern with interoperability. I
believe
EFM should provide a clean and extensible framework; however, leave too much
functionality left open to the implementation, and then you'll get
incompatible implementations.
> May be I have been spending too much time with ILEC types. May be that's
> because they are still the market leaders in transport and services (not
> integrated transport and services).
ILEC needs are just different. It's not because we like to be conservative.
We have to. Legacy is important, keeping customers is important., and
offering a service that is at least as good as the existing one is of utmost
importance.
Carlos Ribeiro
CTBC Telecom