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

From: "Ron Cohen" <[email-masked]>
Date: Wed, 4 Sep 2002 11:20:33 +0200

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

---

From: "Dave Danenberg" <[email-masked]>
Date: Wed, 4 Sep 2002 17:25:22 -0400

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,
>

---

From: "Bob Barrett" <[email-masked]>
Date: Wed, 4 Sep 2002 23:46:22 +0100

Dave

I would prefer to see the objects deprecated at 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. Other drafts might need these objects, and by deleting
them now it could be said that the WG is assuming the outcome of PWE3 in
advance of the event. This could be construed by some as not within the
spirit of an open process. Deprecation rather than deletion avoids any
possibility of this accusation being made.

Best regards

Bob

-----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

> 9 Hamanofim st., P.O.Box 12256
_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

---

From: "Dave Danenberg" <[email-masked]>
Date: Wed, 4 Sep 2002 18:45:46 -0400

> 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.

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 04 Sep 2002 19:56:14 -0400

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

> > > 9 Hamanofim st., P.O.Box 12256

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