RE: [EFM] RE: OAM functionals
Bob,
I agree and we should. Regarding test mode, sorry to be
ignorant. Do you think you can summarize the requirements
for us? Also things like loss of signal/power ... Do we
care about these as well? It will also be nice to know
if we have any APS requirement?
Thanks.
-faye
-----Original Message-----
From: Bob Barrett [mailto:bob.barrett@xxxxxxxxxxxxxxx]
Sent: Wednesday, September 26, 2001 1:21 PM
To: Faye Ly; Romascanu, Dan (Dan); Roy Bynum; ah_smith@xxxxxxxxxxx
Cc: stds-802-3-efm
Subject: RE: [EFM] RE: OAM functionals
Faye, the answer is 'sort of' :-).
I am suggesting that EFM specify some basic functions like test modes
for
example, and an OAM channel. I agree that all but the basic OAM
functions
are outside the scope if 802.3ah.
I guess we should move strand to the OAM reflector now.
Bob
> -----Original Message-----
> From: owner-stds-802-3-efm@majordomo.ieee.org
> [mailto:owner-stds-802-3-efm@majordomo.ieee.org]On Behalf Of Faye Ly
> Sent: 26 September 2001 18:58
> To: bob.barrett@xxxxxxxxxxxxxxx; Romascanu, Dan (Dan); Roy Bynum;
> ah_smith@xxxxxxxxxxx
> Cc: stds-802-3-efm
> Subject: 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
>