RE: [EFM] RE: OAM functionals
Bob,
I was unaware that there was an OAM reflector. Could you direct me to
it? A lot of the OAM stuff will continue to effect some of the
architecture issues as well.
Thank you,
Roy Bynum
At 09:21 PM 9/26/01 +0100, Bob Barrett wrote:
>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
> >