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

RE: [EFM] RE: OAM functionals




Dan,

Upper layer applications service provisioning and management are clearly 
within the domain of upper layers and not part of EFM.  802.3 defines the 
MAC and Physical layer properties for Ethernet.  Very low layer/fundamental 
functions have always been within the domain of the most fundamental 
communications layer.  This is because fundamental communications layer 
should have the least complex method of sending information back to an EML 
gateway, hopefully providing an additional level of reliability in 
catastrophic failure situations. (For those  not familiar with the 
Telecommunications Management Network (TMN) ISO standards, "EML" refers to 
"Element Management Layer".)

Thank you,
Roy Bynum

At 12:48 PM 9/26/01 +0200, Romascanu, Dan (Dan) wrote:
>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