Re: [Diffserv] Dscp and DscpOrAny TCs
Brian E Carpenter <brian@hursley.ibm.com> Fri, 07 March 2003 10:29 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 FAA18122 for <diffserv-archive@odin.ietf.org>; Fri, 7 Mar 2003 05:29:48 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27AfFX08928 for diffserv-archive@odin.ietf.org; Fri, 7 Mar 2003 05:41:15 -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 h27AWqO07403; Fri, 7 Mar 2003 05:32:52 -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 h27AGeO06454 for <diffserv@optimus.ietf.org>; Fri, 7 Mar 2003 05:16:40 -0500
Received: from d12lmsgate-5.de.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17348 for <diffserv@ietf.org>; Fri, 7 Mar 2003 05:04:42 -0500 (EST)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-5.de.ibm.com (8.12.8/8.12.3) with ESMTP id h27A63OI125608; Fri, 7 Mar 2003 11:06:10 +0100
Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h27A5bJ0055062; Fri, 7 Mar 2003 11:05:38 +0100
Received: from gsine02.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA28508 from <brian@hursley.ibm.com>; Fri, 7 Mar 2003 11:05:23 +0100
Message-Id: <3E686E9B.BDB38CB7@hursley.ibm.com>
Date: Fri, 07 Mar 2003 11:04:11 +0100
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fr,de
Mime-Version: 1.0
To: Andrew Smith <ah_smith@acm.org>
Cc: Bert Wijnen <bwijnen@lucent.com>, 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
References: <04ac01c2e357$b2cfadd0$1500000a@ANDREWLAPTOP>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
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
Andrew, That is a valid point (we have the same issue for the IPv6 Flow Label). However, in answer to Bert's question, John Schnizlein is correct. It's a violation of the diffserv architecture to mask bits in a DSCP. There are no encoded bit fields in a DSCP; it's an opaque 6 bit quantity. docsSubMgtPktFilterDscpMask needs to be deleted. Brian Andrew Smith wrote: > > 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/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