Subject: Re: Test ServiceState in Termination State Descriptor]

From: Tom-PT Taylor <[email-masked]>
Date: Tue, 18 Apr 2000 09:37:14 -0400

I'd say the states are mainly useful to coordinate between multiple entities
-- in failover cases, as Brian has mentioned, and when maintenance access to
the MG has to be reflected to the MGC.  I guess we do need discussions such
as the one you have initiated to decide on the operational significance of
these states.

> -----Original Message-----
> From: Hemant Agrawal [SMTP:[email-masked]]
> Sent: Tuesday, April 18, 2000 9:29 AM
> To:   [email-masked]
> Subject:      Re: Test ServiceState in Termination State Descriptor]
>
> Hi Brown, list,
>
>  My comments are inserted inline with HA>
>
>
> > The test state is different from "in service" in that a termination can
> be
> "in
> > service", "OOS", "in service - test" or "OOS - test".
> >
>
> HA>  In TerminationStateDescriptor, ServiceState has only three valid
> states, IS, OOS and Test. There is no state as "IS-TEST" or "OOS-TEST".
> The
> state "test" is independent of the IS or OOS state.
>
> > I would say that there are no specific actions which would be applied
> simply by placing the line in the
> > test state.
> >
>  HA> Agreed. (In fact that's what we have said)
> >
> > In my opinion, it would be something of a flag to indicate that the
> signals and
> > events associated with test package could be applied to a termination.
> >
> > The behavior associated with those signals and events would be defined
> as
> part of
> > the package and may be different depending on whether the termination is
> IS or
> > OOS.
> >
> > I would think that the intelligence to determine whether or not to apply
> a
> > particular signal or event would be under the control of the MGC or a
> > maintenance interface, but it might be desirable for an implementation
> in
> the MG
> > to do some minimal defensive coding to prevent MGC or maintenance
> request
> > "mistakes".
> >
>  HA> is it that when the termination is not in test state, then the MG
> should  not allow test events and signals to be applied ? What happens to
> the test  signals & events when a termination which is in test state moves
> to a IS state -
>  does the MG stop those signals and events ?
>
> >I do agree that the intelligence for handling the test state should be
> driven by
> > the MGC and actions taken in the MG implemented in packages. One of the
> reasons
> > I believe that the test state is needed is to have this knowledge
> available
> > associated with the termination in the event of the MG performing a
> failover to
> > a secondary MGC. The MGC could determine those terminations which were
> under
> > test using audit mechanisms and could then take action accordingly.
> >
> > Regarding your last question, I would say that the MG would behave no
> > differently in allocating a termination on a CHOOSE when it is IS-test
> or
> IS.
> > The point is that the termination should be used as IS except that
> specified
> > test functions will be performed (under MGC control) during normal use.
>
> HA> Agreed
>
> > I am currently in process of working with Nortel development groups on
> producing
> > a test package for line test functions. This will be coming out in the
> near
> > future and I think it will help to further clarify my comments.
> >
>
> Regards,
> Hemant Agrawal
>
> >
> > Hemant Agrawal wrote:
> >
> > > Hi All,
> > >         I have few questions related to serviceState in
> > > terminationStatedDescriptor.
> > > TerminationStateDescriptor has three values for serviceState : In
> Service,
> > > Out Of Service and Test.
> > > The draft mentions "The state "test" indicates that the termination is
> being
> > > tested" (sec 7.1.5 para 2).
> > >
> > > How is "test" state different from "in service"? Is their any special
> action
> > > to be taken by MG, when it receives a termination state to be set as
> test.
> > >
> > > Does it mean that if the said termination supports test packages, the
> events
> > > , signals etc pertaining to these can be applied only in test state.
> Also in
> > > that case what happens to the non "test" package events and signals.
> Are
> > > they stopped by the MG on getting service state property as "test" and
> vice
> > > versa.
> > >
> > > I think this differentiation between what constitutes test and what
> not
> > > should not be done at MG level. But in that case how from an MG point
> of
> > > view, are the service states "test" and "in service" different ?
> > >
> > > Another question in this regards. Should the MG "prefer" allocating
> "in
> > > service" terminations over terminations with service state "test"
> while
> > > resolving CHOOSE in Add.
> > >
> > > Thanks in advance,
> > > Hemant Agrawal
> > >
> > > ________________________________________
> > > Hemant Agrawal
> > > Ficon Technology
> > > E-mail: [email-masked]
> > > Web: http://www.ficon-tech.com
> >