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