RE: [Diffserv] Dscp and DscpOrAny TCs

"Andrew Smith" <> Wed, 05 March 2003 21:01 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id QAA28328 for <>; Wed, 5 Mar 2003 16:01:42 -0500 (EST)
Received: (from mailnull@localhost) by (8.11.6/8.11.6) id h25LCOC20623 for; Wed, 5 Mar 2003 16:12:24 -0500
Received: from (localhost.localdomain []) by (8.11.6/8.11.6) with ESMTP id h25L3TO19074; Wed, 5 Mar 2003 16:03:29 -0500
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id h25KpZO18692 for <>; Wed, 5 Mar 2003 15:51:35 -0500
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id PAA27546 for <>; Wed, 5 Mar 2003 15:40:23 -0500 (EST)
Received: from ([] helo=ANDREWLAPTOP) by with esmtp (Exim 3.33 #1) id 18qfiZ-0002OX-00; Wed, 05 Mar 2003 12:42:23 -0800
From: "Andrew Smith" <>
To: "Bert Wijnen" <>
Cc: <>, <>, <>, <>, <>
Subject: RE: [Diffserv] Dscp and DscpOrAny TCs
Date: Wed, 5 Mar 2003 12:42:11 -0800
Message-ID: <04ac01c2e357$b2cfadd0$1500000a@ANDREWLAPTOP>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <>
Importance: Normal
Content-Transfer-Encoding: 7bit
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <>, <>
List-Id: Diffserv Discussion List <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: 7bit

I've not been following the DOCSIS MIB work closely and don't know the
context in which this MIB was developed. That said, shouldn't IETF be
promoting the use of generic, already-standards-track solutions, instead
of trying to police each new reincarnation of the same thing? It would
have been nice if, given that this MIB is a work item of an IETF WG, the
IESG had put in some provision in the WG charter about re-use of
existing IETF work where appropriate, rather than reinventing the wheel
(which this looks like - see my first sentence above though). Granted,
there is a choice of almost-equivalent wheels for packet
matching/filtering in the IETF standards-track repertoire but that's not
an argument for creating yet another one.

This is one aspect of the general IETF process issue of how to ensure
that appropriate "subject matter experts" are available to a WG that
needs them, even when that subject matter's own WG is no longer
existent: the more generic the solutions that IESG steers us to, the
less this maintenance problem will be.

Reuse of already-defined MIB ojects/tables is also one of the issues
that an SMIng should try to make easier (and people have been looking at
doing this, I believe).

Andrew Smith

-----Original Message-----
From: [] On Behalf
Of John Schnizlein
Sent: Wednesday, March 05, 2003 9:29 AM
To: Wijnen, Bert (Bert)
Subject: Re: [Diffserv] Dscp and DscpOrAny TCs

Good catch, Bert.
The idea of a mask for the DSCP was killed some time ago in Policy
Framework based on its incompatibility with the following explicit
prohibition in the definition of the Differentiated Services Field:

RFC 2474 Section 3, page 7
   Implementors should note that the DSCP field is six bits wide.  DS-
   compliant nodes MUST select PHBs by matching against the entire 6-bit
   DSCP field, e.g., by treating the value of the field as a table index
   which is used to select a particular packet handling mechanism which
   has been implemented in that device.  The value of the CU field MUST
   be ignored by PHB selection.  The DSCP field is defined as an
   unstructured field to facilitate the definition of future per-hop


At 11:36 AM 3/5/2003, Wijnen, Bert (Bert) wrote:
>Do Diffservers think that the following is wise and makes sense?
>   docsSubMgtPktFilterDscpValue OBJECT-TYPE
>       SYNTAX      Dscp
>       MAX-ACCESS  read-create
>       STATUS      current
>           "The Differentiated Services Code Point (DSCP) value to
>            in the IP packet."
>       DEFVAL { 0 }
>       ::= { docsSubMgtPktFilterEntry 9 }
>   docsSubMgtPktFilterDscpMask OBJECT-TYPE
>       SYNTAX      Dscp
>       MAX-ACCESS  read-create
>       STATUS      current
>           "The mask to apply against the DSCP value to be matched in
>       the IP packet.  The default for both these objects taken
>       matches all DSCP values. A packet matches this filter if the
>       following is true:
>           AND (FilterDscpValue, FilterDscpMask) ==
>           AND (Packet DSCP Value, FilterDscpMask)."
>       DEFVAL { 0 }
>       ::= { docsSubMgtPktFilterEntry 10 }
>It is defined in draft-ietf-ipcdn-subscriber-mib-10.txt and I'd like
>to hear comments from Diffserv experts.

diffserv mailing list

diffserv mailing list