Search RFCs

RFC Editor

Found 3 records.

Status:Verified (2)

RFC 3289, "Management Information Base for the Differentiated Services Architecture", May 2002

Errata ID: 300

Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tom Irwin
Date Reported: 2002-08-08
Report Text:

In the process of implementing the RFC 3289 DiffServ MIB, the followingerrors and discrepancies were noted.1. In the diffServClfrTable description (second paragraph),diffServClfrStatus should be diffServClfrStorage.  This is anunderstandability issue.2. The diffServClfrElementStatus description indicates that this entrycannot be deleted if there is a RowPointer pointing to it.  A RowPointeris not used to select a classifier element, but rather thediffServClfrId and diffServClfrElementId index values.  Consequently,the diffServClfrElementTable does not require a UsageCounter or aDestroyFlag.  This is an understandability issue.3. In the diffServActionSpecific description (third paragraph)erroneously references a meter.  This is an understandability issue.4. The diffServMinRateAbsolute description indicates that zero is avalid value.  The SYNTAX range indicates (1..4294967295), but should be(0..4294967295).  This is an understandability issue and a MIBimplementation issue.5. The diffServMinRateRelative description indicates that zero is avalid value and that the values are in units of 1/1000 of 1.  The SYNTAXrange indicates (1..4294967295), but should be (0..1000).  This is anunderstandability issue and a MIB implementation issue.6. The diffServMaxRateAbsolute description indicates that zero is avalid value.  The SYNTAX range indicates (1..4294967295), but should be(0..4294967295).  This is an understandability issue and a MIBimplementation issue.7. The diffServMaxRateRelative description indicates that zero is avalid value and that the values are in units of 1/1000 of 1.  The SYNTAXrange indicates (1..4294967295), but should be (0..1000).  This is anunderstandability issue and a MIB implementation issue.

Errata ID: 301

Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tom Irwin
Date Reported: 2002-08-27
Report Text:

1.  During implementation, there has been some confusion on the "reuseof structural elements" in section 2.2.  It is clear from the commentsand the MIB that counters cannot be effectively reused.  What appearsconfusing is the case when an entire (or partial) DiffServ tree used fora specific interface ifIndex and direction is reused.  Is the DiffServtree in this case just a template such that all of the data pathelements are replicated (counters will not work properly) for anotherinterface?  This seems reasonable since other data path elements such asqueues and schedulers are clearly interface dependent. It is importantto remove this ambiguity since the RowPointer usage does not prohibitthis "not generally recommended" application.  What is the intent?2. Minor update in section 3.2.2:     ' Differentiated Services Code Point ' to     ' Differentiated Services Code Point, including "any" '3. Figure 9b in section 3.7.2.1 is somewhat difficult at first to followdue to how the multiplexing is shown in the Yellow "Count Action" (anaction only has a single input).

Status:Held for Document Update (1)

RFC 3289, "Management Information Base for the Differentiated Services Architecture", May 2002

Errata ID:2976
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Ina Singh
Date Reported: 2011-09-21
Held for Document Update by: Wesley Eddy

Section 3.4.5. says:

   diffServRandomDropInvProbMax represents Pmax (inverse).  This MIB   does not represent Pmin (assumed to be zero unless otherwise   represented).  In addition, since message memory is finite, queues   generally have some upper bound above which they are incapable of   storing additional traffic.  Normally this number is equal to Qclip,   specified by diffServAlgDropQThreshold.

It should say:

       The average queue depth beyond which traffic has a probability       indicated by diffServRandomDropProbMax of being dropped or       marked. Note that this differs from the physical queue limit,       which is stored in diffServAlgDropQThreshold.

Notes:

diffServRandomDropInvProbMax should be removed

Attaching the e-mail confirmation from Fred :
==============================================


From: Fred Baker (fred)
Sent: Tuesday, September 20, 2011 10:54 PM
To: Ina Singh (inasingh)
Subject: Re: RFC3289/DiffesrvMIB SFS

Thanks for pointing this out. Correct me if I'm wrong; it looks to me like diffServRandomDropInvProbMax only shows up in the comment in section 3.4.5, and diffServRandomDropProbMax is used throughout the MIB. Yes, the comment should be fixed, but the MIB is itself correct with diffServRandomDropProbMax. Correct?

The right thing to do is file an erratum against RFC 3289, so that if it is edited in the future the error can be picked up, and implementers can see it.

http://www.ietf.org/iesg/statement/errata-processing.html describes the process.


On Sep 20, 2011, at 6:50 PM, Ina Singh (inasingh) wrote:

> Hey Fred,
>
> While implementing RFC3289/DiffesrvMIB SFS recently on IOS, we noticed the following error :
> It would seem that diffServRandomDropInvProbMax was replaced by
> diffServRandomDropProbMax (?) , but the reference to “diffServRandomDropInvProbMax” was not removed on subsequent versions.
>
> Can you please confirm, if so, what’s the procedure to correct it ..
>
> Thanks in advance for your help in this and appreciate your time..
>
> Ina
>
> Definition of "diffServRandomDropInvProbMax" upto version 7, here is a link for draft version 6.
>
> http://tools.ietf.org/html/draft-ietf-diffserv-mib-06
>
> iffServRandomDropInvProbMax OBJECT-TYPE
> SYNTAX Unsigned32
> MAX-ACCESS read-create
> STATUS current
> DESCRIPTION
> "The worst case random drop probability, expressed as
> the inverse of the drop probability. With special
> case of the value zero meaning zero probability of
> drop.
>
> For example, if every packet may be dropped in the
> worst case (100%), this has the value of
> 4,294,967,295."
> ::= { diffServRandomDropEntry 6 }
>
>
>
> In contrast to "diffServRandomDropProbMax" starting from version 8.
>
>
> diffServRandomDropProbMax OBJECT-TYPE
>
> SYNTAX Unsigned32 (0..1000)
> MAX-ACCESS read-create
> STATUS current
> DESCRIPTION
> "The worst case random drop probability, expressed in drops per
> thousand packets.
>
> For example, if in the worst case every arriving packet may be
> dropped (100%) for a period, this has the value 1000.
> Alternatively, if in the worst case only one percent (1%) of
> traffic may be dropped, it has the value 10."
> ::= { diffServRandomDropEntry 6 }

Report New Errata