RE: [Diffserv] Dscp and DscpOrAny TCs
"Andrew Smith" <ah_smith@acm.org> Wed, 05 March 2003 21:01 UTC
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28328 for <diffserv-archive@odin.ietf.org>; Wed, 5 Mar 2003 16:01:42 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25LCOC20623 for diffserv-archive@odin.ietf.org; Wed, 5 Mar 2003 16:12:24 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25L3TO19074; Wed, 5 Mar 2003 16:03:29 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25KpZO18692 for <diffserv@optimus.ietf.org>; Wed, 5 Mar 2003 15:51:35 -0500
Received: from albatross.mail.pas.earthlink.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27546 for <diffserv@ietf.org>; Wed, 5 Mar 2003 15:40:23 -0500 (EST)
Received: from user-11206ng.dsl.mindspring.com ([66.32.26.240] helo=ANDREWLAPTOP) by albatross.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18qfiZ-0002OX-00; Wed, 05 Mar 2003 12:42:23 -0800
From: Andrew Smith <ah_smith@acm.org>
To: Bert Wijnen <bwijnen@lucent.com>
Cc: diffserv@ietf.org, Richard_Woundy@cable.comcast.com, jf.mule@cablelabs.com, narten@us.ibm.com, erik.nordmark@sun.com
Subject: RE: [Diffserv] Dscp and DscpOrAny TCs
Date: Wed, 05 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: <4.3.2.7.2.20030305122439.02246d80@wells.cisco.com>
Importance: Normal
Content-Transfer-Encoding: 7bit
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-BeenThere: diffserv@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/diffserv>, <mailto:diffserv-request@ietf.org?subject=unsubscribe>
List-Id: Diffserv Discussion List <diffserv.ietf.org>
List-Post: <mailto:diffserv@ietf.org>
List-Help: <mailto:diffserv-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/diffserv>, <mailto:diffserv-request@ietf.org?subject=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: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org] On Behalf Of John Schnizlein Sent: Wednesday, March 05, 2003 9:29 AM To: Wijnen, Bert (Bert) Cc: diffserv@ietf.org 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 behaviors. John 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 > DESCRIPTION > "The Differentiated Services Code Point (DSCP) value to match > in the IP packet." > DEFVAL { 0 } > ::= { docsSubMgtPktFilterEntry 9 } > > docsSubMgtPktFilterDscpMask OBJECT-TYPE > SYNTAX Dscp > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The mask to apply against the DSCP value to be matched in > the IP packet. The default for both these objects taken together > 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. > >Thanks, >Bert _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillis t.html _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html
- [Diffserv] Dscp and DscpOrAny TCs Wijnen, Bert (Bert)
- Re: [Diffserv] Dscp and DscpOrAny TCs John Schnizlein
- RE: [Diffserv] Dscp and DscpOrAny TCs Andrew Smith
- Re: [Diffserv] Dscp and DscpOrAny TCs Brian E Carpenter
- RE: [Diffserv] Dscp and DscpOrAny TCs Wijnen, Bert (Bert)
- RE: [Diffserv] Dscp and DscpOrAny TCs Andrew Smith
- FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Woundy, Richard
- RE: [Diffserv] Dscp and DscpOrAny TCs Wijnen, Bert (Bert)
- Re: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny… John Schnizlein
- RE: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Andrew Smith
- RE: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Andrew Smith
- [Diffserv] simulator for diffserv Sapna Isotupa
- Re: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny… Brian E Carpenter
- RE: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Woundy, Richard
- RE: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny… Woundy, Richard
- RE: [Diffserv] Dscp and DscpOrAny TCs Woundy, Richard
- RE: [Diffserv] Dscp and DscpOrAny TCs Jean-Francois Mule
- Re: [Diffserv] simulator for diffserv Martin Westhead
- RE: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny… Andrew Smith
- RE: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny… Woundy, Richard