Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: [EFM] RE: OAM functionals




Roy,

We use this architecture on, hopefully, high margin metro access services.

Harry

-----Original Message-----
From: Roy Bynum [mailto:rabynum@xxxxxxxxxxxxxx]
Sent: Wednesday, September 26, 2001 3:39 PM
To: Harry Hvostov; 'Faye Ly'; bob.barrett@xxxxxxxxxxxxxxx; Romascanu,
Dan (Dan); ah_smith@xxxxxxxxxxx
Cc: stds-802-3-efm
Subject: RE: [EFM] RE: OAM functionals


Harry,

Yes this works very well for low margin "Internet" type services.

Thank you,
Roy Bynum

At 11:57 AM 9/26/01 -0700, Harry Hvostov wrote:
>Gents,
>
>1. SP's use OSS systems such as available from Portal S/W, Micromuse and
>others. These are typically distributed applications based on CORBA or
>similar
>distributed protocols. All this is resolved at the application layer.
>
>2. SNMP is again an application protocol. Hence transport of SNMP messages
>can be done as payload of Ethernet frames - in band. That is the method of
>choice today for cable access.
>
>Harry
>
>-----Original Message-----
>From: Faye Ly [mailto:faye@xxxxxxxxxx]
>Sent: Wednesday, September 26, 2001 10:58 AM
>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