RE: [EFM] Re: OAM - To side-band or not to side-band
Bob,
I would disagree slightly with your comment. Most of the OAM functions
will be performed by Operational Support Systems, which are "machines" not
human operators. A human operator only gets involved with remote problem
resolution issues, and today most of those are automated. Lack of "delay"
is what is perceived by the OSS and how long it would have to be in idle
while waiting for a message response under worst case customer revenue
traffic conditions. Any variance in the response times would add to the
OSS support delay issues.
Thank you,
Roy Bynum
At 06:57 PM 1/27/2002 +0000, you wrote:
>Ops, did I open a can of worms here, sorry Matt.
>
>What I meant was that the OAM transport should work under boundary
>conditions, which kind of maps to your Webster definition. The delta 'T' in
>this context is clearly set by the user interface requirements of an NMS. I
>don't think we will be relying on OAM message for rapid restoration. The OAM
>messages need to be delivered in a timely fashion under all network
>conditions, which I would define as a non-perceptible delay to human
>operator when remote access over EFM OAM is compared to access to a locally
>attached head-end unit.
>
>Thanks
>
>Bob
>
>-----Original Message-----
>From: msquire@xxxxxxxxxxxxxx [mailto:msquire@xxxxxxxxxxxxxx]On Behalf Of
>Matt Squire
>Sent: 27 January 2002 18:12
>To: Roy Bynum
>Cc: Bob Barrett; Geoff Thompson; Tony Jeffree; stds-802-3-efm
>Subject: Re: [EFM] Re: OAM - To side-band or not to side-band
>
>
>
>According to Webster, deterministic comes from determine which means 'to
>fix the boundaries.' Hence, setting a minimum and maximum is quite
>deterministic.
>
>Nothing we could do would operate on 'any specific granular time frame',
>for a time frame can always be chosen which is less than 1-bit time. I
>know you have time frames you find desirable - other folk have other
>views on desirable time frames. Time frame granularity is certinly one
>of the differentiators between the OAM transport proposals and should be
>considered by folks when making their evaulations of the transport
>proposals.
>
>I'm completely unclear on what we approach 802.3ah OAM will not be
>taking.
>
>Roy Bynum wrote:
> >
> > Matt,
> >
> > The moment that you say minimum and maximums, you have said that it is not
> > deterministic from the service provider viewpoint for any kind of service
> > than "Internet" related. Deterministic means that at any specific
> > granular time frame, a specific level of performance monitoring is
> > available. On today's infrastructure, where it is managed at all, that
> > time frame is measured in microseconds. Where infrastructure is not
> > managed, the facility is managed through the services using SNMP embedded
> > in the customer revenue stream. Sometimes ATM is used to create an
> > dedicated channel at L2 for the SNMP, but it is still embedded as part of
> > the service revenue stream. I think that we have agreed that the 802.3ah
> > OAM will not be taking that approach.
> >
> > Thank you,
> > Roy Bynum
> >
> > At 12:09 PM 1/27/2002 -0500, Matt Squire wrote:
> >
> > >All of the OAM transport proposals are completely contained within 802.3
> > >and do not rely on implementation specifics. Also, all of the transport
> > >proposals have easily derivable deterministic minimum and maximum
> > >performance (bps).
> > >
> > >Bob Barrett wrote:
> > > >
> > > > Gentlemen
> > > >
> > > > I would assert that anything we define for OAM transport should also
>be
> > > self
> > > > contained within 802.3 and not rely on implementation specifics in
>order to
> > > > work deterministically.
> > > >
> > > > Non-deterministic management transport will not meet the broad market
> > > > acceptance criterion imho.
> > > >
> > > > Bob
> > > >