RE: [EFM] RE: OAM functionals
Bob,
It seems like we are coming into a conclusion that:
An OAM mechanism is required to remotely manage the
CPEs. This mechanism is dedicated for OAM to ensure
centralized management model (That is, from EMS to OLT
and thus OLT to all CPE's. We are only interested in
the segment between OLT and CPE's). The most important
reason for needing a centralized management model is
to "avoid truck roll". The network operator from a
centralized NOC should be able to remotely manage the
OLT and CPE's.
If I interpreted your email correctly. You are suggesting
that as long as we have a mechanism, whatever OAM traffic
that is transported over the mechanism is up to the vendors?
I think the danger of this is that we might be taking away
SP's choices on OLT and CPE vendors. But if we say that
whatever OAM traffic that is transported over the mechanism
is out of scope of 802.3ah, I totally agree.
-faye
-----Original Message-----
From: Bob Barrett [mailto:bob.barrett@xxxxxxxxxxxxxxx]
Sent: Wednesday, September 26, 2001 10:19 AM
To: Romascanu, Dan (Dan); Roy Bynum; Faye Ly; ah_smith@xxxxxxxxxxx
Cc: stds-802-3-efm
Subject: RE: [EFM] RE: OAM functionals
A lot of the detailed management functions are product and vendor
specific.
The EFM standard should cater only for the basic management functions
for
test and possibly port enable/disable, but some would argue that one is
product specific and a step too far.
The EFM standard should provide the vendor with a channel down which to
run
their own management application in whatever protocol they choose be it
UDP
with SNMP or something proprietary. The vendors that talk to their
customers
(and some vendors even listen to the replies) will probably do better
than
those that don't :-).
Bob Barrett
> -----Original Message-----
> From: owner-stds-802-3-efm@majordomo.ieee.org
> [mailto:owner-stds-802-3-efm@majordomo.ieee.org]On Behalf Of
Romascanu,
> Dan (Dan)
> Sent: 26 September 2001 11:48
> To: Roy Bynum; Faye Ly; ah_smith@xxxxxxxxxxx
> Cc: stds-802-3-efm
> Subject: RE: [EFM] RE: OAM functionals
>
>
>
> Roy,
>
> I am trying to make a slightly different point, or ask a different
> question. I am actually with you on the issue of insertion of control
> plane messages in the traffic stream, but...
> >
> > To a certain extent, you are right. In some ways you are wrong.
> >
> > Upper layer applications can provide a very rich texture of
> > management and
> > provisioning messaging. The question would be whether this
> > messaging would
> > require insertion into the customer revenue traffic stream.
> > This works for
> > low margin services such as the Internet. It does not work
> > for high margin
> > services such as "Private Line".
> >
> > There are a lot of vendors that are trying to redefine
> > "Private Line". The
> > sad truth is that it is the customer of the service providers
> > that define
> > what "Private Line" is. At present, and in the foreseeable future,
> > "Private Line" is a private, secure, fixed bandwidth
> > facility, that is not
> > shared with other "customers". "Private Line" has the
> > service provider
> > management out side of the customer's revenue traffic.
> >
> >
>
> Note that you did not use the word Ethernet even once!
>
> My point is that the chassis management issues need to be part of a
> layer of management that is not Ethernet (or other data layer)
specific.
> What needs to be defined is the information model for a control plane
> (which is not lower layer specific) and than mappings to the specific
> layers. I sympathize with the need and I understand the requirement,
but
> I am not sure that the first part is within our charter. Maybe there
are
> other standard groups dealing with this. I am not sure that this group
> is well prepared to deal with chassis management or facilities alarms,
> and I am wondering if you as a service provider would not prefer one
> single interface to present such information, for all the data layer
> technologies that run the services that you sell.
>
> It might be that
> Regards,
>
> Dan