Subject: RE: RE: JtrBfrRebuildOor in draft-pwe3-cep-mib-00

From: "Bob Barrett" <[email-masked]>
Date: Thu, 5 Sep 2002 13:24:06 +0100

Yes but .....

it isn't that hard to include the currently unused objects in an
implementation is it? Looks to me like they have an 'off' and 'don't care'
state.

I can see a use for these objects but not in the Sonet or VT drafts. What I
thought I read between the lines was that these objects get taken out now
and then if and when a draft comes along that requires them there would be a
blocker because of the need to change the MIB. Paranoid or what ;-).

Bob

-----Original Message-----
From: Thomas D. Nadeau [mailto:[email-masked]]
Sent: 05 September 2002 00:56
To: Dave Danenberg
Cc: [email-masked]; David Zelig; Ron Cohen; PWE3 (IETF)
Subject: RE: [PWE3] RE: JtrBfrRebuildOor in draft-pwe3-cep-mib-00

         I disagree.  Doing so just complicates the initial
implementations. Given the newness of the MIB, and the
fact that it is still an IETF draft does not require that
any deprecation of objects be done.

         --Tom

> > I would prefer to see the objects deprecated as that is the
> > normal procedure for obsolete/unused objects in publised MIBs.
> > I think that even though this MIB has not been formally accepted
> > that deprecation would be the best action at this time.
>
>OK - no problem - will do.
>
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On
> > Behalf Of Dave
> > Danenberg
> > Sent: 04 September 2002 22:25
> > To: Ron Cohen; PWE3 (IETF)
> > Cc: David Zelig
> > Subject: [PWE3] RE: JtrBfrRebuildOor in draft-pwe3-cep-mib-00
> >
> > Ron,
> >
> > I agree. The feature described in the objects below is not
> > central to the
> > pwe3-sonet draft. More detail (additional objects) is required for the
> > feature to be useable - and then it may still be debated.
> > Instead of trying
> > to make it useable, I will remove it.
> >
> > So, unless anybody else on the mailing list objects, the 2
> > objects (below)
> > will be deleted for the next version. I assume, at this point, with no
> > implementations, it is OK to re-use the OIDs - not deprecate them.
> >
> > Btw, I have been keeping a list of cep-mib issues collected
> > over the past
> > few months. I will send these to the mailing list (including
> > this issue -
> > although it is essentially a closed issue) to solicit more opinions.
> > Hopefully you can offer some.
> >
> > Thanks,
> > -Dave
> >
> > > -----Original Message-----
> > > From: Ron Cohen [mailto:[email-masked]]
> > > Sent: Wednesday, September 04, 2002 5:21 AM
> > > To: PWE3 (IETF); Dave Danenberg
> > > Cc: David Zelig
> > > Subject: JtrBfrRebuildOor in draft-pwe3-cep-mib-00
> > >
> > >
> > > Hi,
> > >
> > > The jitter buffer rebuild algorithm defined in the two variables:
> > >
> > >    pwVcCepCfgJtrBfrRebuildOor OBJECT-TYPE
> > >       SYNTAX        TruthValue
> > >       MAX-ACCESS    read-create
> > >       STATUS        current
> > >       DESCRIPTION
> > >           "When set TRUE, the jitter buffer will rebuild when
> > >            the RebuildOorCoutnt (consecutive out-of-range
> > >            packet counter) has reached it's config'ed setting.
> > >            If set FALSE, then the jitter buffer will continue
> > >            to function regardless of out-of-range packets."
> > >       DEFVAL { true }
> > >       ::= { pwVcCepCfgEntry 8 }
> > >
> > >    pwVcCepCfgJtrBfrRebuildOorCount  OBJECT-TYPE
> > >       SYNTAX        Unsigned32 (0..255)
> > >       MAX-ACCESS    read-create
> > >       STATUS        current
> > >       DESCRIPTION
> > >           "Used by RebuildOor above. For every consecutive
> > >            out-of-range packet received, a count is incremented.
> > >            If it matches this value, the jitter bfr resets and
> > >            rebuilds."
> > >       DEFVAL { 3 }
> > >       ::= { pwVcCepCfgEntry 9 }
> > >
> > > Is very problematic. It doesn't take into account the status of the
> > > 'good' sequence. Here is a scenario: You have a sequence of
> > > packets say
> > > numbered 101, 102, .., 110 delayed. These ten packets are
> > delayed such
> > > that when they arrive, they have already being played out as dropped
> > > packets, and the effective sequence now is 112 and up. The current
> > > series is working fine and there is no problem what so
> > ever. When the
> > > delayed sequence arrive, their sequence numbers are out of
> > range. Now,
> > > the buffer would rebuild due to this delayed sequence while
> > > the existing
> > > sequence is working fine.
> > >
> > > I would suggest to remove these two variables altogether
> > from the MIB.
> > > They are not needed in order to manage CEP circuits as defined in
> > > draft-pwe3-sonet-00 and draft-pwe3-sonet-vt-00.
> > >
> > > Ron
> > >
> > > Ron Cohen
> > > Lycium Networks
> > > Tel: +972-9-9717794
> > > Mobile: +972-55-245104
> > > Fax: +972-9-9717798
> > > email: [email-masked]
> > > home email: [email-masked]
> > > 9 Hamanofim st., P.O.Box 12256
> > > Herzliya 46733 Israel
> > >
> > >
> > >
> > >
> > _______________________________________________
> > pwe3 mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/pwe3
> >
> >
> >
>_______________________________________________
>pwe3 mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/pwe3

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time.

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 05 Sep 2002 09:48:12 -0400

>implementation is it? Looks to me like they have an 'off' and 'don't care'

         It actually wastes OIDs because there will eventually be holes
in a brand new implementation's OID space. It also does unnecessarily 
complicate
the implementation.  Let me explain why. If an object is marked as 
"deprecated" then
an implementation must support the object for at least 1 new release in 
order to
inform the management stations of its intent to change the state of the 
object to
"obsolete".  Why would an implementation want to implement an object that
we just agreed was unnecessary or impossible to implement?   Also,
to properly follow the object deprecation procedures, we would have to mess
around with the conformance statement as well.  So what does all of that
fuss buy us? Not much if you ask me.

>blocker because of the need to change the MIB. Paranoid or what ;-).

         That may or may not happen with any IETF draft or WG document
(assuming the WG approves of the change).   What it comes down to is the
difference between theory and practice.  I view any new MIBs as
theoretical until we have implementation experience from several device
and NMS vendors to prove that it is designed correctly. So just because
objects are in there now, does not mean that changes will not come down
the road to more align them how implementations really operate.
We definitely strive to get things right the first time, but having
done this enough times now I know that changes will come down the
road.

         --Tom