From mailnull@www1.ietf.org Tue Mar 4 18:35:08 2003 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 SAA15395 for ; Tue, 4 Mar 2003 18:35:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24NjoU24632 for diffserv-archive@odin.ietf.org; Tue, 4 Mar 2003 18:45:50 -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 h24NZE523198; Tue, 4 Mar 2003 18:35:14 -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 h24F83p11207 for ; Tue, 4 Mar 2003 10:08:03 -0500 Received: from merlot.juniper.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24885 for ; Tue, 4 Mar 2003 09:57:01 -0500 (EST) Received: from juniper.net (ssh.juniper.net [207.17.136.39]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h24Ex2S68656; Tue, 4 Mar 2003 06:59:02 -0800 (PST) (envelope-from kdubray@juniper.net) Message-ID: <3E64BF36.9080009@juniper.net> Date: Tue, 04 Mar 2003 09:59:02 -0500 From: Kevin Dubray User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 (CK-SillyDog) X-Accept-Language: en-us, en MIME-Version: 1.0 To: diffserv@ietf.org CC: Randy Bush , Bert Wijnen Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Benchmarking I-D: draft-ietf-bmwg-dsmterm-05.txt 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: , List-Id: Diffserv Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, The Benchmarking Methodology WG (BMWG) is currently reviewing an I-D, "Terminology for Benchmarking Network-layer Traffic Control Mechanisms." This I-D seeks to describes terminology for the benchmarking of devices that implement traffic control based on IP precedence or diff-serv code point criteria. Interested parties will find the related Internet-Draft here: http://www.ietf.org/internet-drafts/draft-ietf-bmwg-dsmterm-05.txt Discussion can be found on the BMWG mailing list and its archive: http://www.ietf.org/mail-archive/working-groups/bmwg/current/maillist.html Commentary posted to bmwg@ietf.org is welcome. Posted in the fine spirit of cross-WG feedback, Kevin _______________________________________________ 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 From mailnull@www1.ietf.org Wed Mar 5 11:57:40 2003 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 LAA12643 for ; Wed, 5 Mar 2003 11:57:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25H8hL15502 for diffserv-archive@odin.ietf.org; Wed, 5 Mar 2003 12:08:43 -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 h25GxW513239; Wed, 5 Mar 2003 11:59:32 -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 h25GkZ512734 for ; Wed, 5 Mar 2003 11:46:35 -0500 Received: from ihemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11246 for ; Wed, 5 Mar 2003 11:35:01 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.firewall.lucent.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h25Gb4O03988 for ; Wed, 5 Mar 2003 11:37:04 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Mar 2003 17:37:03 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501063C21@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: diffserv@ietf.org Cc: bwijnen@lucent.com Date: Wed, 5 Mar 2003 17:36:59 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Diffserv] Dscp and DscpOrAny TCs 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: , List-Id: Diffserv Discussion List List-Post: List-Help: List-Subscribe: , 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 From mailnull@www1.ietf.org Wed Mar 5 13:57:54 2003 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 NAA21780 for ; Wed, 5 Mar 2003 13:57:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25J8Y309104 for diffserv-archive@odin.ietf.org; Wed, 5 Mar 2003 14:08:34 -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 h25IxZO07868; Wed, 5 Mar 2003 13:59:35 -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 h25Ia4O06030 for ; Wed, 5 Mar 2003 13:36:04 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15011 for ; Wed, 5 Mar 2003 12:27:07 -0500 (EST) Received: from jschnizl-w2k.cisco.com (rtp-vpn1-11.cisco.com [10.82.224.11]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h25HSs82015169; Wed, 5 Mar 2003 09:28:54 -0800 (PST) Message-Id: <4.3.2.7.2.20030305122439.02246d80@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 05 Mar 2003 12:29:07 -0500 To: "Wijnen, Bert (Bert)" From: John Schnizlein Subject: Re: [Diffserv] Dscp and DscpOrAny TCs Cc: diffserv@ietf.org In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15501063C21@nl0006exch001u.nl .lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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: , List-Id: Diffserv Discussion List List-Post: List-Help: List-Subscribe: , 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 From mailnull@www1.ietf.org Wed Mar 5 16:01:42 2003 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 ; 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 ; 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 ; 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" 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: <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: , 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: 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 From mailnull@www1.ietf.org Fri Mar 7 05:29:48 2003 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 ; 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 ; 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 ; 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 ; 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 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 Cc: Bert Wijnen , 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: , List-Id: Diffserv Discussion List List-Post: List-Help: List-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 From mailnull@www1.ietf.org Fri Mar 7 06:22:13 2003 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 GAA19358 for ; Fri, 7 Mar 2003 06:22:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27BXgT13298 for diffserv-archive@odin.ietf.org; Fri, 7 Mar 2003 06:33:42 -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 h27BOeO12345; Fri, 7 Mar 2003 06:24:40 -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 h27B8gO11612 for ; Fri, 7 Mar 2003 06:08:42 -0500 Received: from hoemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18630 for ; Fri, 7 Mar 2003 05:56:43 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h27Awk227525 for ; Fri, 7 Mar 2003 05:58:47 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Mar 2003 11:58:35 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501156B3A@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Andrew Smith , Bert Wijnen 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: Fri, 7 Mar 2003 11:57:13 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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: , List-Id: Diffserv Discussion List List-Post: List-Help: List-Subscribe: , Andrew, Sure.... and what I am doing here is not the ideal solution, but clearly I am trying to get various solutions aligned as much as possible (you have seen my issues raised for common definitions for Dscp, DscpOrAny, FlowLabel, FlowLabelOrAny, VlanId, VlanIdOrAny ... etc etc. In the case of DOCSIS, the original stuff got developed outside IETF. They now try to bring their stuff under the IETF umbrella. We could tell them to drop/ditch all their own stuff and start from scratch... which I suspect will not work, or we can try to get them aligned as much as possible without making them start from scratch. I think I am on the latter path... Are you suggesting we (IETF) should be on the former path? Just trying to understand what you are urging us to do. Thanks, Bert > -----Original Message----- > From: Andrew Smith [mailto:ah_smith@acm.org] > Sent: woensdag 5 maart 2003 21:42 > To: Bert Wijnen > 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 > > > 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/curre nt/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 From mailnull@www1.ietf.org Fri Mar 7 12:08:47 2003 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 MAA17073 for ; Fri, 7 Mar 2003 12:08:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27HKMg14825 for diffserv-archive@odin.ietf.org; Fri, 7 Mar 2003 12:20:22 -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 h27H6hO12263; Fri, 7 Mar 2003 12:06:43 -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 h27Gr0O11466 for ; Fri, 7 Mar 2003 11:53:00 -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 LAA15408 for ; Fri, 7 Mar 2003 11:40:52 -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 18rKvq-0006IE-00; Fri, 07 Mar 2003 08:42:50 -0800 From: "Andrew Smith" To: "'Wijnen, Bert \(Bert\)'" Cc: , , , , Subject: RE: [Diffserv] Dscp and DscpOrAny TCs Date: Fri, 7 Mar 2003 08:44:41 -0800 Message-ID: <08c301c2e4c8$dd032c40$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: <7D5D48D2CAA3D84C813F5B154F43B15501156B3A@nl0006exch001u.nl.lucent.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: , List-Id: Diffserv Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Bert, When you say "bring their stuff under the IETF umbrella", are you saying that the original MIB in question was developed outside of IETF and is being brought in, or are you talking about the link technology itself? If the latter, then I think the older IEEE802/IETF cooperation model on MIBs works OK - there you had an IETF WG (bridge, maumib, ifmib etc.) defining SMI MIBs under IETF root OID and having WG contributors make sure that adequate coordination happened; a newer model where IEEE802 has defined some of its own SMI MIBs has also been working OK (e.g. Link Aggregation MIB from IEEE802, defined under IEEE802's own root OID). For the former case, what I don't think works is to have a MIB defined outside of IETF and then brought to the IETF for some reason. What would be the reason to do that? for IETF endorsement, for having IETF fixing things that are broken, just to use the IETF root OID? I don't know the specific reasons in this case for how this work got here. But it's obvious to me that, if you bring existing work to IETF for standardisation, be it the work of another standards' group, an industry group or individual contributions, *you give up change control* and you do not get any guarantees of backwards-compatibility: naturally you don't expect gratuitous non-compatibility with earlier work - the WG needs a valid reason to change something and one such reason would be alignment with other IETF MIBs. [Note that, for this particular example of filter/pattern-matching on IP packets with DSCPs, I'd originally proposed a separate generic MIB module (included a "sixTupleClassifier" table) for the reason of making it clear that this was general purpose and should be used by other MIBs, including the Diffserv MIB. However, in the end, it was decided to merge it into the main Diffserv MIB module (it became the "diffServMultiFieldClfrTable" in RFC3289 - maybe it is less visible there but maybe ADs can do something to raise awareness of its presence amongst other WGs]. Andrew Smith -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Friday, March 07, 2003 2:57 AM To: Andrew Smith; Bert Wijnen 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 Andrew, Sure.... and what I am doing here is not the ideal solution, but clearly I am trying to get various solutions aligned as much as possible (you have seen my issues raised for common definitions for Dscp, DscpOrAny, FlowLabel, FlowLabelOrAny, VlanId, VlanIdOrAny ... etc etc. In the case of DOCSIS, the original stuff got developed outside IETF. They now try to bring their stuff under the IETF umbrella. We could tell them to drop/ditch all their own stuff and start from scratch... which I suspect will not work, or we can try to get them aligned as much as possible without making them start from scratch. I think I am on the latter path... Are you suggesting we (IETF) should be on the former path? Just trying to understand what you are urging us to do. Thanks, Bert > -----Original Message----- > From: Andrew Smith [mailto:ah_smith@acm.org] > Sent: woensdag 5 maart 2003 21:42 > To: Bert Wijnen > 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 > > > 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/curre nt/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 From mailnull@www1.ietf.org Fri Mar 7 12:49:07 2003 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 MAA19673 for ; Fri, 7 Mar 2003 12:49:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27I0gM19843 for diffserv-archive@odin.ietf.org; Fri, 7 Mar 2003 13:00:42 -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 h27HrbO19012; Fri, 7 Mar 2003 12:53:37 -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 h27EoNO31822 for ; Fri, 7 Mar 2003 09:50:23 -0500 Received: from peacock.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05311 for ; Fri, 7 Mar 2003 09:38:17 -0500 (EST) Received: from mms01-relaya.tci.com (mms01-relaya.broadband.att.com [147.191.90.228]) by peacock.tci.com (8.12.2/8.12.2) with ESMTP id h27EeNJD029323 for ; Fri, 7 Mar 2003 07:40:23 -0700 (MST) Received: from 147.191.90.10 by mms01-relayb.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Fri, 07 Mar 2003 07:40:15 -0600 Received: by entexchimc03.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Fri, 7 Mar 2003 07:38:42 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC05663797@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'diffserv@ietf.org'" Subject: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Date: Fri, 7 Mar 2003 07:40:12 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 127670C51148509-01-01 Content-Type: text/plain; charset=iso-8859-1 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: , List-Id: Diffserv Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Diffserv folks, I'm looking for further reaction to my email below about DOCSIS/Dscp interaction. Note that I am not subscribed to your mailing list, so please include my email address on replies. -- Rich -----Original Message----- From: Woundy, Richard Sent: Friday, March 07, 2003 9:28 AM To: 'Wilson.Sawyer@arrisi.com'; Wijnen, Bert (Bert) Cc: bwijnen@lucent.com; Ipcdn (E-mail); Thomas Narten (E-mail) Subject: RE: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Folks, I think there are two issues here: are Dscp mask objects legal, and are they worthwhile? Note: in my latest DOCSIS Cable Device MIB submission (e.g. ), the new object docsDevFilterInetDscp is defined with SYNTAX DscpOrAny, with no mask object. I can't really say whether Wilson or I are correct on this topic. I agree with Wilson when he emphasizes that these Dscp objects in the various DOCSIS MIB are access filters, not PHB selectors. In fact, such objects enable the DOCSIS equipment to act precisely as "re-marking boundary nodes", which are also described in RFC 2474 Section 3, pages 8-9: The structure of the DS field shown above is incompatible with the existing definition of the IPv4 TOS octet in [RFC791]. The presumption is that DS domains protect themselves by deploying re- marking boundary nodes, as should networks using the RFC 791 Precedence designations. Correct operational procedure SHOULD follow [RFC791], which states: "If the actual use of these precedence designations is of concern to a particular network, it is the responsibility of that network to control the access to, and use of, those precedence designations." Validating the value of the DS field at DS boundaries is sensible in any case since an upstream node can easily set it to any arbitrary value. DS domains that are not isolated by suitably configured boundary nodes may deliver unpredictable service. Nodes MAY rewrite the DS field as needed to provide a desired local or end-to-end service. Specifications of DS field translations at DS boundaries are the subject of service level agreements between providers and users, and are outside the scope of this document. Standardized PHBs allow providers to build their services from a well-known set of packet forwarding treatments that can be expected to be present in the equipment of many vendors. On the other hand, I see the definite lack of structure in the DiffServ codepoints, and I am debating with myself whether a "Dscp mask" is worth the trouble or not. In particular, I am looking at the current codepoint assignments in , and wondering how I could optimize matching on Assured Forwarding class 1 (AF1x) using a Dscp value/mask pair. If I use Dscp value 001000 / mask 111000, I accidentally include Class Selector 1 (CS1) in the matched set. If I specifically add an "ignore" Dscp value 001000 / mask 111111 filter for CS1, then I need two Dscp value/mask filters to capture AF1x traffic -- instead of three Dscp value-only filters for AF1x traffic. This is a small savings. On the other hand, if I desire to optimize matching any of the non-default Class Selectors CS1-7, I could use an "ignore" Dscp value 000000 / mask 111111 filter for CS0, and a second Dscp value 000000 / mask 000111 filter for CS1-7. This is a significant savings compared to the seven Dscp value-only filters for CS1-7. A really tricky case is if I desire to optimize matching any Assured Forwarding or Expedited Forwarding codepoints. I might choose to use an "ignore" Dscp value 000000 / mask 000111 filter for CS0-7, and a second Dscp value 000000 / mask 000000 filter for AFxy and EF PHB. While this represents a huge savings over the thirteen Dscp value-only filters, it may capture traffic with Dscp codepoints that are not yet defined by the IETF/IANA, which represents some risk. -- Rich -----Original Message----- From: Wilson.Sawyer@arrisi.com [mailto:Wilson.Sawyer@arrisi.com] Sent: Friday, March 07, 2003 8:12 AM To: Wijnen, Bert (Bert) Cc: bwijnen@lucent.com; Ipcdn (E-mail); ipcdn-admin@ietf.org; Thomas Narten (E-mail) Subject: Re: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Keep in mind we're talking about a *filter* here, not a PHB selector. And we'e not inferring bit-structure in the implementation, merely allowing the network operator to take advantage of any structure that exists. Do we really want to require the operator to install three separate filters to catch one AF class? I don't find anything in the cited paragraph that contraindicates this sort of usage. The fact that today's PHB selector set is likely to change is all the more reason to give a filter-installer some options for concise representation. - Wilson "Wijnen, Bert (Bert)" To: "Ipcdn (E-mail)" Sent by: Subject: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs ipcdn-admin@ietf. org 03/07/03 05:57 AM This is one comment I got back from Diffserv list Thanks, Bert -----Original Message----- From: John Schnizlein [mailto:jschnizl@cisco.com] Sent: woensdag 5 maart 2003 18:29 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 From mailnull@www1.ietf.org Fri Mar 7 13:53:52 2003 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 NAA22814 for ; Fri, 7 Mar 2003 13:53:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27J5U926730 for diffserv-archive@odin.ietf.org; Fri, 7 Mar 2003 14:05:30 -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 h27It0O25705; Fri, 7 Mar 2003 13:55:00 -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 h27Ig0O25192 for ; Fri, 7 Mar 2003 13:42:00 -0500 Received: from auemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21824 for ; Fri, 7 Mar 2003 13:29:51 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail2.firewall.lucent.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h27IVsS05950 for ; Fri, 7 Mar 2003 13:31:54 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Mar 2003 19:31:53 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501156C60@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Andrew Smith , "'Wijnen, Bert (Bert)'" 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: Fri, 7 Mar 2003 19:31:47 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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: , List-Id: Diffserv Discussion List List-Post: List-Help: List-Subscribe: , Inline > -----Original Message----- > From: Andrew Smith [mailto:ah_smith@acm.org] > Sent: vrijdag 7 maart 2003 17:45 > To: 'Wijnen, Bert (Bert)' > 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 > > Bert, > > When you say "bring their stuff under the IETF umbrella", are you saying > that the original MIB in question was developed outside of IETF and is > being brought in, or are you talking about the link technology itself? > As far as I understand it, several (if not all) of the MIB modules (quite a few) have been developed in cablelabs context, and in fact have been implemented at a large scale. > If the latter, then I think the older IEEE802/IETF cooperation model on > MIBs works OK - there you had an IETF WG (bridge, maumib, ifmib etc.) > defining SMI MIBs under IETF root OID and having WG contributors make > sure that adequate coordination happened; a newer model where IEEE802 > has defined some of its own SMI MIBs has also been working OK (e.g. Link > Aggregation MIB from IEEE802, defined under IEEE802's own root OID). > > For the former case, what I don't think works is to have a MIB defined > outside of IETF and then brought to the IETF for some reason. What would > be the reason to do that? for IETF endorsement, for having IETF fixing > things that are broken, just to use the IETF root OID? I don't know the > specific reasons in this case for how this work got here. But it's > obvious to me that, if you bring existing work to IETF for > standardisation, be it the work of another standards' group, an industry > group or individual contributions, *you give up change control* and you > do not get any guarantees of backwards-compatibility: naturally you > don't expect gratuitous non-compatibility with earlier work - the WG > needs a valid reason to change something and one such reason would be > alignment with other IETF MIBs. > I think that is all understood. But I will leave it to Rich and JeanFrancois to answer the exact motives for coming to IETF. From my point of view, we will not just accept everything and rubber stamp. But I also understand that we have to be practical and that we do not just want to make them start from scratch just for the fun of it. By the way, quite a bit of the discussion about the Dscp, DscpOrAny, VlanID and VlanIDOrAny is also an issue for MIB modules from the past from IETF WGs. > [Note that, for this particular example of filter/pattern-matching on IP > packets with DSCPs, I'd originally proposed a separate generic MIB > module (included a "sixTupleClassifier" table) for the reason of making > it clear that this was general purpose and should be used by other MIBs, > including the Diffserv MIB. However, in the end, it was decided to merge > it into the main Diffserv MIB module (it became the > "diffServMultiFieldClfrTable" in RFC3289 - maybe it is less visible > there but maybe ADs can do something to raise awareness of its presence > amongst other WGs]. > That is why I DID ask the question to IPCDN WG, did you guys look at the other filter tables that we already have in the IETF. Bert > > Andrew Smith > > > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Friday, March 07, 2003 2:57 AM > To: Andrew Smith; Bert Wijnen > 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 > > > Andrew, > > Sure.... and what I am doing here is not the ideal solution, > but clearly I am trying to get various solutions aligned > as much as possible (you have seen my issues raised > for common definitions for Dscp, DscpOrAny, FlowLabel, > FlowLabelOrAny, VlanId, VlanIdOrAny ... etc etc. > > In the case of DOCSIS, the original stuff got developed > outside IETF. They now try to bring their stuff under the > IETF umbrella. We could tell them to drop/ditch all their own > stuff and start from scratch... which I suspect will not work, > or we can try to get them aligned as much as possible without > making them start from scratch. > > I think I am on the latter path... > Are you suggesting we (IETF) should be on the former path? > > Just trying to understand what you are urging us to do. > > Thanks, > Bert > > > -----Original Message----- > > From: Andrew Smith [mailto:ah_smith@acm.org] > > Sent: woensdag 5 maart 2003 21:42 > > To: Bert Wijnen > > 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 > > > > > > 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/curre > nt/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 From mailnull@www1.ietf.org Fri Mar 7 14:35:20 2003 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 OAA24421 for ; Fri, 7 Mar 2003 14:35:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27Jkxu31204 for diffserv-archive@odin.ietf.org; Fri, 7 Mar 2003 14:46:59 -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 h27JaEO29387; Fri, 7 Mar 2003 14:36:14 -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 h27JOkO28912 for ; Fri, 7 Mar 2003 14:24:46 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23721 for ; Fri, 7 Mar 2003 14:12:36 -0500 (EST) Received: from jschnizl-w2k.cisco.com (rtp-vpn1-704.cisco.com [10.82.226.192]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h27JEZSd026435; Fri, 7 Mar 2003 14:14:35 -0500 (EST) Message-Id: <4.3.2.7.2.20030307135304.00b7e818@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 07 Mar 2003 14:14:34 -0500 To: "Woundy, Richard" From: John Schnizlein Subject: Re: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Cc: "'diffserv@ietf.org'" In-Reply-To: <6732623D2548D61193C90002A5C88DCC05663797@entmaexch02.broad band.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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: , List-Id: Diffserv Discussion List List-Post: List-Help: List-Subscribe: , Comments embedded in context below: At 09:40 AM 3/7/2003, Woundy, Richard wrote: >I'm looking for further reaction to my email below about DOCSIS/Dscp >interaction. >... >I think there are two issues here: are Dscp mask objects legal, No. >and are they worthwhile? No. >... enable the DOCSIS equipment to act precisely as "re-marking boundary >nodes", which are also described in RFC 2474 Section 3, pages 8-9: > > The structure of the DS field shown above is incompatible with the > existing definition of the IPv4 TOS octet in [RFC791]. The > presumption is that DS domains protect themselves by deploying re- > marking boundary nodes, as should networks using the RFC 791 > Precedence designations. Correct operational procedure SHOULD follow > [RFC791], which states: "If the actual use of these precedence > designations is of concern to a particular network, it is the > responsibility of that network to control the access to, and use of, > those precedence designations." Validating the value of the DS field > at DS boundaries is sensible in any case since an upstream node can > easily set it to any arbitrary value. DS domains that are not > isolated by suitably configured boundary nodes may deliver > unpredictable service. > > Nodes MAY rewrite the DS field as needed to provide a desired local > or end-to-end service. Specifications of DS field translations at DS > boundaries are the subject of service level agreements between > providers and users, and are outside the scope of this document. > Standardized PHBs allow providers to build their services from a > well-known set of packet forwarding treatments that can be expected > to be present in the equipment of many vendors. > >On the other hand, I see the definite lack of structure in the DiffServ >codepoints, and I am debating with myself whether a "Dscp mask" is worth the >trouble or not. > >In particular, I am looking at the current codepoint assignments in >,... You may be running into a subtlety that was worried about early in defining the DiffServ field. The code points in the registry are just recommended values, not required values. While there are requirements regarding which behaviors must be supported to claim DiffServ compliance, there is no requirement that the recommended values be used to indicate these behaviors. The point is that there is no reliable structure for "the network operator to take advantage of". The presence of masks in data objects would encourage creating the sort of structure the RFC prohibits. Note the distinction between the SHOULD regarding values, and the MUST regarding treating the value as a unit (copied farther below): RFC 2474 section 2, page 5 Codepoint: a specific value of the DSCP portion of the DS field. Recommended codepoints SHOULD map to specific, standardized PHBs. >From: Wilson.Sawyer@arrisi.com [mailto:Wilson.Sawyer@arrisi.com] > >Keep in mind we're talking about a *filter* here, not a PHB selector. I don't appreciate the distinction. What was intended by PHB selector was that traffic could be selected from the aggregate by the DSCP. How is this different from filtering traffic based on DSCP matches? >And we'e not inferring bit-structure in the implementation, merely >allowing the network operator to take advantage of any structure >that exists. Do we really want to require the operator to install >three separate filters to catch one AF class? > >I don't find anything in the cited paragraph that contraindicates this sort >of usage. The fact that today's PHB selector set is likely to change is all >the more reason to give a filter-installer some options for concise >representation. >... >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 _______________________________________________ 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 From mailnull@www1.ietf.org Fri Mar 7 16:31:31 2003 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 QAA05982 for ; Fri, 7 Mar 2003 16:31:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27LhDi13822 for diffserv-archive@odin.ietf.org; Fri, 7 Mar 2003 16:43:13 -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 h27LUsO11344; Fri, 7 Mar 2003 16:30:54 -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 h27LDuO09748 for ; Fri, 7 Mar 2003 16:13:56 -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 QAA02928 for ; Fri, 7 Mar 2003 16:01:44 -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 18rP0M-0003Tf-00; Fri, 07 Mar 2003 13:03:47 -0800 From: "Andrew Smith" To: "'Woundy, Richard'" , Cc: , , , "'Wijnen, Bert \(Bert\)'" Subject: RE: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Date: Fri, 7 Mar 2003 13:05:37 -0800 Message-ID: <094601c2e4ed$510ffea0$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: <6732623D2548D61193C90002A5C88DCC05663797@entmaexch02.broadband.att.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: , List-Id: Diffserv Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Rich, You wrote: ... > I agree with Wilson when he emphasizes that these Dscp objects in the > various DOCSIS MIB are access filters, not PHB selectors. In fact, such > objects enable the DOCSIS equipment to act precisely as "re-marking boundary > nodes", which are also described in RFC 2474 Section 3, pages 8-9: ... If the pieces of DOCSIS equipment are acting as "re-marking boundary nodes, which are also described in RFC 2474 Section 3, pages 8-9" then shouldn't they, by definition, be implementing the IETF's existing Diffserv MIB RFC 3289 in order to control this functionality? I would hope that your WG would provide a strong argument why IETF should sanction another MIB for this same purpose when this work comes before the IESG for consideration. Andrew Smith _______________________________________________ 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 From mailnull@www1.ietf.org Fri Mar 7 18:18:55 2003 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 SAA13640 for ; Fri, 7 Mar 2003 18:18:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27NUbl24787 for diffserv-archive@odin.ietf.org; Fri, 7 Mar 2003 18:30:37 -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 h27NKtO24096; Fri, 7 Mar 2003 18:20:55 -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 h27N80O23674 for ; Fri, 7 Mar 2003 18:08:00 -0500 Received: from gamma.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11918; Fri, 7 Mar 2003 17:55:46 -0500 (EST) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id h27MvoZ19024; Fri, 7 Mar 2003 14:57:50 -0800 (PST) Message-Id: <200303072257.h27MvoZ19024@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, diffserv@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 07 Mar 2003 14:57:50 -0800 Subject: [Diffserv] RFC 3317 on Differentiated Services Quality of Service Policy Information Base 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: , List-Id: Diffserv Discussion List List-Post: List-Help: List-Subscribe: , --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3317 Title: Differentiated Services Quality of Service Policy Information Base Author(s): K. Chan, R. Sahita, S. Hahn, K. McCloghrie Status: Informational Date: March 2003 Mailbox: khchan@nortelnetworks.com, ravi.sahita@intel.com, scott.hahn@intel.com, kzm@cisco.com Pages: 96 Characters: 188553 Updates/Obsoletes/See Also: None I-D Tag: draft-ietf-diffserv-pib-09.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3317.txt This document describes a Policy Information Base (PIB) for a device implementing the Differentiated Services Architecture. The provisioning classes defined here provide policy control over resources implementing the Differentiated Services Architecture. These provisioning classes can be used with other none Differentiated Services provisioning classes (defined in other PIBs) to provide for a comprehensive policy controlled mapping of service requirement to device resource capability and usage. This document is a product of the Differentiated Services (DIFFSERV) Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030307145351.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3317 --OtherAccess Content-Type: Message/External-body; name="rfc3317.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030307145351.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ 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 From mailnull@www1.ietf.org Fri Mar 7 19:41:02 2003 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 TAA20191 for ; Fri, 7 Mar 2003 19:41:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h280ql400682 for diffserv-archive@odin.ietf.org; Fri, 7 Mar 2003 19:52:47 -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 h280j2O32228; Fri, 7 Mar 2003 19:45:02 -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 h280WbO30716 for ; Fri, 7 Mar 2003 19:32:37 -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 TAA17977; Fri, 7 Mar 2003 19:20:21 -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 18rS6Y-0001nX-00; Fri, 07 Mar 2003 16:22:22 -0800 From: "Andrew Smith" To: "'Woundy, Richard'" , , "'IPCDN WG \(E-mail\)'" Cc: , , , "'Wijnen, Bert \(Bert\)'" Subject: RE: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Date: Fri, 7 Mar 2003 16:24:13 -0800 Message-ID: <0ad901c2e509$0f2c40e0$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: <6732623D2548D61193C90002A5C88DCC056637AB@entmaexch02.broadband.att.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: , List-Id: Diffserv Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Rich, Thanks for the context - it wasn't clear from the draft or the WG charter that this was an update to an earlier MIB. I appreciate the momentum that comes with 20 million deployments! My comments were aimed exclusively at the CMTS, not the modem: I think a CMTS probably has a much better chance of supporting the Diffserv MIB, which sacrifices implementation simplicity for generality in ways that seemed appropriate for Diffserv switching nodes. I would also assume that deployment of updates to CMTSs is many orders of magnitude easier than changes to modems and that backwards-compatibility with RFC 2669 is also less of an issue. Regards, Andrew Smith -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] Sent: Friday, March 07, 2003 2:28 PM To: 'Andrew Smith'; diffserv@ietf.org; IPCDN WG (E-mail) Cc: jf.mule@cablelabs.com; narten@us.ibm.com; erik.nordmark@sun.com; 'Wijnen, Bert (Bert)' Subject: RE: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Andrew, Please keep in mind that the current Cable Device MIB is an update to RFC 2669, which pre-dates your RFC 3289 by three years. Since the publication of RFC 2669, about 20 million cable modems have been shipped, with our industry presumption that the Cable Device MIB was IETF-blessed. :^( I described the Cable Device MIB filters as "re-marking boundary nodes" using the language of RFC 2474. But the original Cable Device filters really were designed as extended access control lists for cable modems, e.g. to keep unwanted traffic off the cable network: NetBEUI, spoofed DHCP servers, etc. The filters also happen to contain IP ToS matching and overwriting capabilities. As we figure out how to update the RFC 2669 MIB, naturally we want to replace IPv4 ToS management with IPv4/v6 DSCP management... two weeks ago we start to look at RFC 3289 for the first time. :^( The Subscriber Management MIB is designed as a light-weight extension to the Cable Device MIB for Cable Modem Termination System (CMTS) filtering. That MIB separates TCP/UDP port filtering into separate filtering tables due to performance reasons. Otherwise, it is modelled after the Cable Device MIB. With all that said, the right thing to do may in fact be to adopt the DiffServ MIB for the filtering and/or classification functions in DOCSIS cable modems, particularly since: - it supports IPv6 addresses better than the filters in RFC 2669, - it supports DSCP and flow ID matching better than RFC 2669, - it supports more flexible traffic classification, and - it allows cable modems to reuse an existing IETF MIB used outside of cable. But take heed that this is a very significant change to a critical modem function used by most of the cable industry. It's going to take myself and others some time to figure out how to adopt more/all of the RFC 3289 DiffServ MIB. Here are two typical cable industry considerations: - The base DOCSIS 1.1 and 2.0 technology is not yet DiffServ-aware, since it currently relies on IP ToS masking and ranges for upstream traffic queuing. There is interest among the cable operators to start to fix this, but that may take a long time. To see what DOCSIS expects today, see Appendix C.2.1.5.1 in . - The standard DOCSIS cable modem is an inexpensive device (e.g. <$100), so simplicity of implementation is very critical. This might be satisfied by a simplified MIB compliance for DOCSIS cable modems -- if it is a real issue here. If you are volunteering to help us adopt the DiffServ MIB for DOCSIS, then I accept your help! I appreciate and support the IETF community's desire to reuse existing work. In return, please appreciate that this is changing the expectations of our IPCDN MIBs (and impacting its publication dates) yet again in a very significant way. -- Rich -----Original Message----- From: Andrew Smith [mailto:ah_smith@acm.org] Sent: Friday, March 07, 2003 4:06 PM To: Woundy, Richard; diffserv@ietf.org Cc: jf.mule@cablelabs.com; narten@us.ibm.com; erik.nordmark@sun.com; 'Wijnen, Bert (Bert)' Subject: RE: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Rich, You wrote: ... > I agree with Wilson when he emphasizes that these Dscp objects in the > various DOCSIS MIB are access filters, not PHB selectors. In fact, such > objects enable the DOCSIS equipment to act precisely as "re-marking boundary > nodes", which are also described in RFC 2474 Section 3, pages 8-9: ... If the pieces of DOCSIS equipment are acting as "re-marking boundary nodes, which are also described in RFC 2474 Section 3, pages 8-9" then shouldn't they, by definition, be implementing the IETF's existing Diffserv MIB RFC 3289 in order to control this functionality? I would hope that your WG would provide a strong argument why IETF should sanction another MIB for this same purpose when this work comes before the IESG for consideration. Andrew Smith _______________________________________________ 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 From mailnull@www1.ietf.org Sat Mar 8 06:09:34 2003 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 GAA14863 for ; Sat, 8 Mar 2003 06:09:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h28BLUb26037 for diffserv-archive@odin.ietf.org; Sat, 8 Mar 2003 06:21:30 -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 h28BEVO25592; Sat, 8 Mar 2003 06:14:31 -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 h28AuEO24426 for ; Sat, 8 Mar 2003 05:56:14 -0500 Received: from d12lmsgate-3.de.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10114 for ; Sat, 8 Mar 2003 05:43:47 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.8/8.12.8) with ESMTP id h28AjoEO074952 for ; Sat, 8 Mar 2003 11:45:50 +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 h28Ajomq186278 for ; Sat, 8 Mar 2003 11:45:50 +0100 Received: from gsine08.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA44454 from ; Sat, 8 Mar 2003 11:45:47 +0100 Message-Id: <3E69C98C.1C768A8B@hursley.ibm.com> Date: Sat, 08 Mar 2003 11:44:28 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: diffserv@ietf.org Subject: Re: [Diffserv] RFC 3317 on Differentiated Services Quality of Service Policy Information Base References: <200303072257.h27MvoZ19024@gamma.isi.edu> 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: , List-Id: Diffserv Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Diffservers, Our charter is now completed and this WG will shortly be officially closes. Thanks to everybody! I'd like to propose that instead of using this list for any future discussions, we use the diffserv-interest list instead. The reason is that this list is a major spam target (mostly filtered, but that creates a lot of work for the list managers). Unless there are loud objections in the next few days, we'll make that change (and announce here how to join diffserv-interest). Brian Carpenter diffserv co-chair rfc-editor@rfc-editor.org wrote: > > A new Request for Comments is now available in online RFC libraries. > > RFC 3317 > > Title: Differentiated Services Quality of Service Policy > Information Base > Author(s): K. Chan, R. Sahita, S. Hahn, K. McCloghrie > Status: Informational > Date: March 2003 > Mailbox: khchan@nortelnetworks.com, ravi.sahita@intel.com, > scott.hahn@intel.com, kzm@cisco.com > Pages: 96 > Characters: 188553 > Updates/Obsoletes/See Also: None > > I-D Tag: draft-ietf-diffserv-pib-09.txt > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc3317.txt > > This document describes a Policy Information Base (PIB) for a device > implementing the Differentiated Services Architecture. The > provisioning classes defined here provide policy control over > resources implementing the Differentiated Services Architecture. > These provisioning classes can be used with other none Differentiated > Services provisioning classes (defined in other PIBs) to provide for a > comprehensive policy controlled mapping of service requirement to > device resource capability and usage. > > This document is a product of the Differentiated Services (DIFFSERV) > Working Group of the IETF. > > This memo provides information for the Internet community. It does > not specify an Internet standard of any kind. Distribution of this > memo is unlimited. > _______________________________________________ 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 From mailnull@www1.ietf.org Sat Mar 8 08:14:28 2003 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 IAA08800 for ; Sat, 8 Mar 2003 08:14:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h28DQSY01040 for diffserv-archive@odin.ietf.org; Sat, 8 Mar 2003 08:26:28 -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 h28DEGO32668; Sat, 8 Mar 2003 08:14:16 -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 h28CxJO31565 for ; Sat, 8 Mar 2003 07:59:19 -0500 Received: from newdev.harvard.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03183 for ; Sat, 8 Mar 2003 07:46:49 -0500 (EST) Received: from newdev.harvard.edu (localhost [127.0.0.1]) by newdev.harvard.edu (8.12.7/8.12.2) with ESMTP id h28Cmse3017570 for ; Sat, 8 Mar 2003 07:48:54 -0500 (EST) Received: (from sob@localhost) by newdev.harvard.edu (8.12.7/8.12.2/Submit) id h28CmsFW017569 for diffserv@ietf.org; Sat, 8 Mar 2003 07:48:54 -0500 (EST) Date: Sat, 8 Mar 2003 07:48:54 -0500 (EST) From: Scott Bradner Message-Id: <200303081248.h28CmsFW017569@newdev.harvard.edu> To: diffserv@ietf.org Subject: [Diffserv] diffserv WG closing 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: , List-Id: Diffserv Discussion List List-Post: List-Help: List-Subscribe: , With the publication of the diffserv PIB the working group is now being closed. The working group was very successfull, producing 15 RFCs and technology that is widely seen as a key part of the Internet toolbox. I want to thank the WG chairs who put so much good work into this effort over more years than we thought it would take when we started. Scott _______________________________________________ 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 From mailnull@www1.ietf.org Sat Mar 8 10:39:33 2003 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 KAA07088 for ; Sat, 8 Mar 2003 10:39:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h28Fpbp10958 for diffserv-archive@odin.ietf.org; Sat, 8 Mar 2003 10:51:37 -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 h28FcqO10366; Sat, 8 Mar 2003 10:38: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 h28FPGO09194 for ; Sat, 8 Mar 2003 10:25:16 -0500 Received: from mserver.wlu.ca (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01955 for ; Sat, 8 Mar 2003 10:12:42 -0500 (EST) Received: from localhost (sisotupa@localhost) by mserver.wlu.ca (8.10.1/8.10.1) with SMTP id h28FEmM13897 for ; Sat, 8 Mar 2003 10:14:48 -0500 (EST) Date: Sat, 8 Mar 2003 10:14:48 -0500 (EST) From: Sapna Isotupa To: diffserv@ietf.org In-Reply-To: <3E686E9B.BDB38CB7@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Diffserv] simulator for diffserv 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: , List-Id: Diffserv Discussion List List-Post: List-Help: List-Subscribe: , Hello All: Is there a simulator available for testing various scheduling policies for diffserv? If yes, could you tell me whom to contact to obtain one. If there is no simulator available, will others be interested if a simulator for testing various scheduling policies is built? Thanks. Sapna _______________________________________________ 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 From mailnull@www1.ietf.org Sun Mar 9 05:51:05 2003 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 FAA14212 for ; Sun, 9 Mar 2003 05:51:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h29B3VW02473 for diffserv-archive@odin.ietf.org; Sun, 9 Mar 2003 06:03:31 -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 h29Am5O01528; Sun, 9 Mar 2003 05:48:05 -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 h29AZgO00488 for ; Sun, 9 Mar 2003 05:35:42 -0500 Received: from d12lmsgate-4.de.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09061 for ; Sun, 9 Mar 2003 05:22:43 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id h29AObdk121714; Sun, 9 Mar 2003 11:24:37 +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 h29AOa69156014; Sun, 9 Mar 2003 11:24:36 +0100 Received: from gsine05.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA35206 from ; Sun, 9 Mar 2003 11:24:31 +0100 Message-Id: <3E69DB1C.E07810D3@hursley.ibm.com> Date: Sat, 08 Mar 2003 12:59:24 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: John Schnizlein Cc: "Woundy, Richard" , "'diffserv@ietf.org'" Subject: Re: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs References: <4.3.2.7.2.20030307135304.00b7e818@wells.cisco.com> 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: , List-Id: Diffserv Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit What John writes is definitive. Masking DSCPs is simply wrong. The fact that the recommended AF code points happen to be numerically consecutive is just an accident of the code point assignment process; the bit positions are not significant, and network operators are free to ignore the recommended code points if they want to. Brian John Schnizlein wrote: > > Comments embedded in context below: > > At 09:40 AM 3/7/2003, Woundy, Richard wrote: > > >I'm looking for further reaction to my email below about DOCSIS/Dscp > >interaction. > >... > >I think there are two issues here: are Dscp mask objects legal, > > No. > > >and are they worthwhile? > > No. > > >... enable the DOCSIS equipment to act precisely as "re-marking boundary > >nodes", which are also described in RFC 2474 Section 3, pages 8-9: > > > > The structure of the DS field shown above is incompatible with the > > existing definition of the IPv4 TOS octet in [RFC791]. The > > presumption is that DS domains protect themselves by deploying re- > > marking boundary nodes, as should networks using the RFC 791 > > Precedence designations. Correct operational procedure SHOULD follow > > [RFC791], which states: "If the actual use of these precedence > > designations is of concern to a particular network, it is the > > responsibility of that network to control the access to, and use of, > > those precedence designations." Validating the value of the DS field > > at DS boundaries is sensible in any case since an upstream node can > > easily set it to any arbitrary value. DS domains that are not > > isolated by suitably configured boundary nodes may deliver > > unpredictable service. > > > > Nodes MAY rewrite the DS field as needed to provide a desired local > > or end-to-end service. Specifications of DS field translations at DS > > boundaries are the subject of service level agreements between > > providers and users, and are outside the scope of this document. > > Standardized PHBs allow providers to build their services from a > > well-known set of packet forwarding treatments that can be expected > > to be present in the equipment of many vendors. > > > >On the other hand, I see the definite lack of structure in the DiffServ > >codepoints, and I am debating with myself whether a "Dscp mask" is worth the > >trouble or not. > > > >In particular, I am looking at the current codepoint assignments in > >,... > > You may be running into a subtlety that was worried about early in > defining the DiffServ field. The code points in the registry are > just recommended values, not required values. While there are > requirements regarding which behaviors must be supported to claim > DiffServ compliance, there is no requirement that the recommended > values be used to indicate these behaviors. > > The point is that there is no reliable structure for "the network > operator to take advantage of". The presence of masks in data objects > would encourage creating the sort of structure the RFC prohibits. > > Note the distinction between the SHOULD regarding values, and the MUST regarding treating the value as a unit (copied farther below): > > RFC 2474 section 2, page 5 > Codepoint: a specific value of the DSCP portion of the DS field. > Recommended codepoints SHOULD map to specific, standardized PHBs. > > >From: Wilson.Sawyer@arrisi.com [mailto:Wilson.Sawyer@arrisi.com] > > > >Keep in mind we're talking about a *filter* here, not a PHB selector. > > I don't appreciate the distinction. What was intended by PHB selector > was that traffic could be selected from the aggregate by the DSCP. > How is this different from filtering traffic based on DSCP matches? > > >And we'e not inferring bit-structure in the implementation, merely > >allowing the network operator to take advantage of any structure > >that exists. Do we really want to require the operator to install > >three separate filters to catch one AF class? > > > >I don't find anything in the cited paragraph that contraindicates this sort > >of usage. The fact that today's PHB selector set is likely to change is all > >the more reason to give a filter-installer some options for concise > >representation. > >... > >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 _______________________________________________ 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 From mailnull@www1.ietf.org Sun Mar 9 05:57:42 2003 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 FAA15535 for ; Sun, 9 Mar 2003 05:57:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h29BA9603534 for diffserv-archive@odin.ietf.org; Sun, 9 Mar 2003 06:10:09 -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 h29AvAO01909; Sun, 9 Mar 2003 05:57:10 -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 h29AauO00503 for ; Sun, 9 Mar 2003 05:36:56 -0500 Received: from d12lmsgate.de.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09281 for ; Sun, 9 Mar 2003 05:23:56 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.8/8.12.3) with ESMTP id h29APrSo071858; Sun, 9 Mar 2003 11:25:53 +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 h29APq69179764; Sun, 9 Mar 2003 11:25:52 +0100 Received: from gsine05.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA35224 from ; Sun, 9 Mar 2003 11:25:45 +0100 Message-Id: <3E69DB1C.E07810D3@hursley.ibm.com> Date: Sat, 08 Mar 2003 12:59:24 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: John Schnizlein Cc: "Woundy, Richard" , "'diffserv@ietf.org'" Subject: Re: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs References: <4.3.2.7.2.20030307135304.00b7e818@wells.cisco.com> 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: , List-Id: Diffserv Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit What John writes is definitive. Masking DSCPs is simply wrong. The fact that the recommended AF code points happen to be numerically consecutive is just an accident of the code point assignment process; the bit positions are not significant, and network operators are free to ignore the recommended code points if they want to. Brian John Schnizlein wrote: > > Comments embedded in context below: > > At 09:40 AM 3/7/2003, Woundy, Richard wrote: > > >I'm looking for further reaction to my email below about DOCSIS/Dscp > >interaction. > >... > >I think there are two issues here: are Dscp mask objects legal, > > No. > > >and are they worthwhile? > > No. > > >... enable the DOCSIS equipment to act precisely as "re-marking boundary > >nodes", which are also described in RFC 2474 Section 3, pages 8-9: > > > > The structure of the DS field shown above is incompatible with the > > existing definition of the IPv4 TOS octet in [RFC791]. The > > presumption is that DS domains protect themselves by deploying re- > > marking boundary nodes, as should networks using the RFC 791 > > Precedence designations. Correct operational procedure SHOULD follow > > [RFC791], which states: "If the actual use of these precedence > > designations is of concern to a particular network, it is the > > responsibility of that network to control the access to, and use of, > > those precedence designations." Validating the value of the DS field > > at DS boundaries is sensible in any case since an upstream node can > > easily set it to any arbitrary value. DS domains that are not > > isolated by suitably configured boundary nodes may deliver > > unpredictable service. > > > > Nodes MAY rewrite the DS field as needed to provide a desired local > > or end-to-end service. Specifications of DS field translations at DS > > boundaries are the subject of service level agreements between > > providers and users, and are outside the scope of this document. > > Standardized PHBs allow providers to build their services from a > > well-known set of packet forwarding treatments that can be expected > > to be present in the equipment of many vendors. > > > >On the other hand, I see the definite lack of structure in the DiffServ > >codepoints, and I am debating with myself whether a "Dscp mask" is worth the > >trouble or not. > > > >In particular, I am looking at the current codepoint assignments in > >,... > > You may be running into a subtlety that was worried about early in > defining the DiffServ field. The code points in the registry are > just recommended values, not required values. While there are > requirements regarding which behaviors must be supported to claim > DiffServ compliance, there is no requirement that the recommended > values be used to indicate these behaviors. > > The point is that there is no reliable structure for "the network > operator to take advantage of". The presence of masks in data objects > would encourage creating the sort of structure the RFC prohibits. > > Note the distinction between the SHOULD regarding values, and the MUST regarding treating the value as a unit (copied farther below): > > RFC 2474 section 2, page 5 > Codepoint: a specific value of the DSCP portion of the DS field. > Recommended codepoints SHOULD map to specific, standardized PHBs. > > >From: Wilson.Sawyer@arrisi.com [mailto:Wilson.Sawyer@arrisi.com] > > > >Keep in mind we're talking about a *filter* here, not a PHB selector. > > I don't appreciate the distinction. What was intended by PHB selector > was that traffic could be selected from the aggregate by the DSCP. > How is this different from filtering traffic based on DSCP matches? > > >And we'e not inferring bit-structure in the implementation, merely > >allowing the network operator to take advantage of any structure > >that exists. Do we really want to require the operator to install > >three separate filters to catch one AF class? > > > >I don't find anything in the cited paragraph that contraindicates this sort > >of usage. The fact that today's PHB selector set is likely to change is all > >the more reason to give a filter-installer some options for concise > >representation. > >... > >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 seX-Mozilla-Status: 0009et 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 _______________________________________________ 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 From mailnull@www1.ietf.org Sun Mar 9 06:14:04 2003 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 GAA18742 for ; Sun, 9 Mar 2003 06:14:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h29BQWG04363 for diffserv-archive@odin.ietf.org; Sun, 9 Mar 2003 06:26:32 -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 h29BGOO03824; Sun, 9 Mar 2003 06:16:24 -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 h27MbwO20828 for ; Fri, 7 Mar 2003 17:37:59 -0500 Received: from snowmass.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10006; Fri, 7 Mar 2003 17:25:46 -0500 (EST) Received: from mms01-relayb.tci.com (mms01-relayb.broadband.att.com [147.191.90.1]) by snowmass.tci.com (8.12.2/8.12.2) with ESMTP id h27MRLH2016840; Fri, 7 Mar 2003 15:27:46 -0700 (MST) Received: from 147.191.89.203 by mms01-relaya.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Fri, 07 Mar 2003 15:27:40 -0600 Received: by entexchimc01.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Fri, 7 Mar 2003 15:28:32 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC056637AB@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'Andrew Smith'" , diffserv@ietf.org, "IPCDN WG (E-mail)" cc: jf.mule@cablelabs.com, narten@us.ibm.com, erik.nordmark@sun.com, "'Wijnen, Bert (Bert)'" Subject: RE: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Date: Fri, 7 Mar 2003 15:27:36 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 1277C3561235981-01-01 Content-Type: text/plain; charset=iso-8859-1 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: , List-Id: Diffserv Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Andrew, Please keep in mind that the current Cable Device MIB is an update to RFC 2669, which pre-dates your RFC 3289 by three years. Since the publication of RFC 2669, about 20 million cable modems have been shipped, with our industry presumption that the Cable Device MIB was IETF-blessed. :^( I described the Cable Device MIB filters as "re-marking boundary nodes" using the language of RFC 2474. But the original Cable Device filters really were designed as extended access control lists for cable modems, e.g. to keep unwanted traffic off the cable network: NetBEUI, spoofed DHCP servers, etc. The filters also happen to contain IP ToS matching and overwriting capabilities. As we figure out how to update the RFC 2669 MIB, naturally we want to replace IPv4 ToS management with IPv4/v6 DSCP management... two weeks ago we start to look at RFC 3289 for the first time. :^( The Subscriber Management MIB is designed as a light-weight extension to the Cable Device MIB for Cable Modem Termination System (CMTS) filtering. That MIB separates TCP/UDP port filtering into separate filtering tables due to performance reasons. Otherwise, it is modelled after the Cable Device MIB. With all that said, the right thing to do may in fact be to adopt the DiffServ MIB for the filtering and/or classification functions in DOCSIS cable modems, particularly since: - it supports IPv6 addresses better than the filters in RFC 2669, - it supports DSCP and flow ID matching better than RFC 2669, - it supports more flexible traffic classification, and - it allows cable modems to reuse an existing IETF MIB used outside of cable. But take heed that this is a very significant change to a critical modem function used by most of the cable industry. It's going to take myself and others some time to figure out how to adopt more/all of the RFC 3289 DiffServ MIB. Here are two typical cable industry considerations: - The base DOCSIS 1.1 and 2.0 technology is not yet DiffServ-aware, since it currently relies on IP ToS masking and ranges for upstream traffic queuing. There is interest among the cable operators to start to fix this, but that may take a long time. To see what DOCSIS expects today, see Appendix C.2.1.5.1 in . - The standard DOCSIS cable modem is an inexpensive device (e.g. <$100), so simplicity of implementation is very critical. This might be satisfied by a simplified MIB compliance for DOCSIS cable modems -- if it is a real issue here. If you are volunteering to help us adopt the DiffServ MIB for DOCSIS, then I accept your help! I appreciate and support the IETF community's desire to reuse existing work. In return, please appreciate that this is changing the expectations of our IPCDN MIBs (and impacting its publication dates) yet again in a very significant way. -- Rich -----Original Message----- From: Andrew Smith [mailto:ah_smith@acm.org] Sent: Friday, March 07, 2003 4:06 PM To: Woundy, Richard; diffserv@ietf.org Cc: jf.mule@cablelabs.com; narten@us.ibm.com; erik.nordmark@sun.com; 'Wijnen, Bert (Bert)' Subject: RE: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Rich, You wrote: ... > I agree with Wilson when he emphasizes that these Dscp objects in the > various DOCSIS MIB are access filters, not PHB selectors. In fact, such > objects enable the DOCSIS equipment to act precisely as "re-marking boundary > nodes", which are also described in RFC 2474 Section 3, pages 8-9: ... If the pieces of DOCSIS equipment are acting as "re-marking boundary nodes, which are also described in RFC 2474 Section 3, pages 8-9" then shouldn't they, by definition, be implementing the IETF's existing Diffserv MIB RFC 3289 in order to control this functionality? I would hope that your WG would provide a strong argument why IETF should sanction another MIB for this same purpose when this work comes before the IESG for consideration. Andrew Smith _______________________________________________ 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 From mailnull@www1.ietf.org Sun Mar 9 06:16:06 2003 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 GAA19179 for ; Sun, 9 Mar 2003 06:16:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h29BSYF04456 for diffserv-archive@odin.ietf.org; Sun, 9 Mar 2003 06:28:34 -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 h29B7iO03425; Sun, 9 Mar 2003 06:07:44 -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 h27LLYO10596 for ; Fri, 7 Mar 2003 16:21:34 -0500 Received: from snowmass.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03663; Fri, 7 Mar 2003 16:09:20 -0500 (EST) Received: from mms01-relaya.tci.com (mms01-relaya.broadband.att.com [147.191.90.228]) by snowmass.tci.com (8.12.2/8.12.2) with ESMTP id h27L9sH4020710; Fri, 7 Mar 2003 14:10:35 -0700 (MST) Received: from 147.191.90.10 by mms01-relayb.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Fri, 07 Mar 2003 14:10:27 -0600 Received: by entexchimc03.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Fri, 7 Mar 2003 14:08:54 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC056637A7@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'John Schnizlein'" cc: "'diffserv@ietf.org'" , "IPCDN WG (E-mail)" Subject: RE: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Date: Fri, 7 Mar 2003 14:10:24 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 1277D5491200844-02-01 Content-Type: text/plain; charset=iso-8859-1 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: , List-Id: Diffserv Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit John, Thanks for the pointing out that the DiffServ field code points in the registry are just recommended values, not required values. Let me react to this statement, which I believe is key to the discussion about Dscp "filtering" in the DOCSIS Cable Device and Subscriber Management MIBs: >I don't appreciate the distinction. What was intended by PHB selector >was that traffic could be selected from the aggregate by the DSCP. >How is this different from filtering traffic based on DSCP matches? The key difference between "PHB selection" and "filtering" is with regards to the purpose for the matching. I understand "PHB selection" to mean packet classifiers that map traffic --based on a specific DSCP -- to a particular per hop behavior aggregate. I understand "filtering" to mean packet classifiers that condition traffic -- based on a specific DSCP value or group of values -- at the DS boundaries, by re-marking DSCP values or similar actions. This function is mentioned again in RFC 2474 section 7.1 (page 16): The defense against this class of theft- and denial-of-service attacks consists of the combination of traffic conditioning at DS domain boundaries with security and integrity of the network infrastructure within a DS domain. DS domain boundary nodes MUST ensure that all traffic entering the domain is marked with codepoint values appropriate to the traffic and the domain, remarking the traffic with new codepoint values if necessary. These DS boundary nodes are the primary line of defense against theft- and denial-of- service attacks based on modified codepoints, as success of any such attack indicates that the codepoints used by the attacking traffic were inappropriate... The same device may apply both "filtering" and "PHB selection" to its inbound traffic, in that order. The most recent version of the DOCSIS Cable Device MIB (an update of RFC 2669), , will enable the Cable Modem (CM) to filter traffic based on criteria in the new docsDevFilterInetTable, and overwrite the Dscp according to the docsDevFilterDscpTable. The DOCSIS Subscriber Management MIB, , will enable the Cable Modem Termination System (CMTS) to filter traffic based on criteria in the docsSubMgtPktFilterTable. This table enables the DOCSIS CMTS to drop traffic with illegal DSCPs that happen to elude a compromised CM. These two MIBs should define their DSCP-related objects according to best practices for their intended functionality -- hence this email. We do have a MIB in the IPCDN WG, the DOCSIS QoS MIB , in which the docsQosPktClassTable is similar to a PHB selection table. Unlike the previous two MIBs, this MIB is constrained by some outdated notions of packet selection during the DOCSIS 1.1 specification process (late '98/early '99). For example, DOCSIS 1.1 specifically calls for an IP ToS comparison: the packet's ToS is masked and compared to a range between "tos-low" and "tos-high". See Appendix C.2.1.5.1 in . This implies that this base DOCSIS 1.1 specification is going to need to be made DiffServ-aware, before the MIB can be made DiffServ-aware. I believe there is some cable operator support for such a project. -- Rich -----Original Message----- From: John Schnizlein [mailto:jschnizl@cisco.com] Sent: Friday, March 07, 2003 2:15 PM To: Woundy, Richard Cc: 'diffserv@ietf.org' Subject: Re: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Comments embedded in context below: At 09:40 AM 3/7/2003, Woundy, Richard wrote: >I'm looking for further reaction to my email below about DOCSIS/Dscp >interaction. >... >I think there are two issues here: are Dscp mask objects legal, No. >and are they worthwhile? No. >... enable the DOCSIS equipment to act precisely as "re-marking boundary >nodes", which are also described in RFC 2474 Section 3, pages 8-9: > > The structure of the DS field shown above is incompatible with the > existing definition of the IPv4 TOS octet in [RFC791]. The > presumption is that DS domains protect themselves by deploying re- > marking boundary nodes, as should networks using the RFC 791 > Precedence designations. Correct operational procedure SHOULD follow > [RFC791], which states: "If the actual use of these precedence > designations is of concern to a particular network, it is the > responsibility of that network to control the access to, and use of, > those precedence designations." Validating the value of the DS field > at DS boundaries is sensible in any case since an upstream node can > easily set it to any arbitrary value. DS domains that are not > isolated by suitably configured boundary nodes may deliver > unpredictable service. > > Nodes MAY rewrite the DS field as needed to provide a desired local > or end-to-end service. Specifications of DS field translations at DS > boundaries are the subject of service level agreements between > providers and users, and are outside the scope of this document. > Standardized PHBs allow providers to build their services from a > well-known set of packet forwarding treatments that can be expected > to be present in the equipment of many vendors. > >On the other hand, I see the definite lack of structure in the DiffServ >codepoints, and I am debating with myself whether a "Dscp mask" is worth the >trouble or not. > >In particular, I am looking at the current codepoint assignments in >,... You may be running into a subtlety that was worried about early in defining the DiffServ field. The code points in the registry are just recommended values, not required values. While there are requirements regarding which behaviors must be supported to claim DiffServ compliance, there is no requirement that the recommended values be used to indicate these behaviors. The point is that there is no reliable structure for "the network operator to take advantage of". The presence of masks in data objects would encourage creating the sort of structure the RFC prohibits. Note the distinction between the SHOULD regarding values, and the MUST regarding treating the value as a unit (copied farther below): RFC 2474 section 2, page 5 Codepoint: a specific value of the DSCP portion of the DS field. Recommended codepoints SHOULD map to specific, standardized PHBs. >From: Wilson.Sawyer@arrisi.com [mailto:Wilson.Sawyer@arrisi.com] > >Keep in mind we're talking about a *filter* here, not a PHB selector. I don't appreciate the distinction. What was intended by PHB selector was that traffic could be selected from the aggregate by the DSCP. How is this different from filtering traffic based on DSCP matches? >And we'e not inferring bit-structure in the implementation, merely >allowing the network operator to take advantage of any structure >that exists. Do we really want to require the operator to install >three separate filters to catch one AF class? > >I don't find anything in the cited paragraph that contraindicates this sort >of usage. The fact that today's PHB selector set is likely to change is all >the more reason to give a filter-installer some options for concise >representation. >... >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 _______________________________________________ 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 From mailnull@www1.ietf.org Sun Mar 9 06:20:17 2003 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 GAA19859 for ; Sun, 9 Mar 2003 06:20:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h29BWjd04681 for diffserv-archive@odin.ietf.org; Sun, 9 Mar 2003 06:32:45 -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 h29BPKO04271; Sun, 9 Mar 2003 06:25:20 -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 h27NPeO24509 for ; Fri, 7 Mar 2003 18:25:40 -0500 Received: from peacock.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13392 for ; Fri, 7 Mar 2003 18:13:26 -0500 (EST) Received: from mms01-relaya.tci.com (mms01-relaya.broadband.att.com [147.191.90.228]) by peacock.tci.com (8.12.2/8.12.2) with ESMTP id h27NFNJD017214; Fri, 7 Mar 2003 16:15:23 -0700 (MST) Received: from 147.191.89.203 by mms01-relaya.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Fri, 07 Mar 2003 16:15:19 -0600 Received: by entexchimc01.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Fri, 7 Mar 2003 16:16:10 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC056637AE@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'Wijnen, Bert (Bert)'" , "Andrew Smith" cc: diffserv@ietf.org, jf.mule@cablelabs.com, narten@us.ibm.com, erik.nordmark@sun.com, "Woundy, Richard" Subject: RE: [Diffserv] Dscp and DscpOrAny TCs Date: Fri, 7 Mar 2003 16:15:16 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 1277F78D1240791-01-01 Content-Type: text/plain; charset=iso-8859-1 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: , List-Id: Diffserv Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks, The motive for most cable folks coming to the IETF is to collaborate on standards documents between IETF and cable industry experts, that adhere to the IETF architecture and meet the engineering requirements of the cable industry. Sometimes that means that folks extend the IETF architecture model due to considerations that are found first in (and are possibly unique to) the cable industry. Sometimes that means the cable industry adopts output from other IETF groups in place of ad-hoc cable industry solutions. Sometimes we agree not to collaborate -- after all, DOCSIS is supposed to be a layer two protocol. ;^) The IPCDN WG as a whole, and this chair in particular, understands that the IETF owns change control for its drafts and RFCs. That doesn't mean that folks in IPCDN will never object to changes -- but is that really unique to this WG? What Bert says below is all we can ask for from the IETF: >From my point of view, we will not just accept everything and rubber stamp. >But I also understand that we have to be practical and that we do not just >want to make them start from scratch just for the fun of it. -- Richard Woundy, IPCDN Co-Chair -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Friday, March 07, 2003 1:32 PM To: Andrew Smith; 'Wijnen, Bert (Bert)' Cc: diffserv@ietf.org; Woundy, Richard; jf.mule@cablelabs.com; narten@us.ibm.com; erik.nordmark@sun.com Subject: RE: [Diffserv] Dscp and DscpOrAny TCs Inline > -----Original Message----- > From: Andrew Smith [mailto:ah_smith@acm.org] > Sent: vrijdag 7 maart 2003 17:45 > To: 'Wijnen, Bert (Bert)' > 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 > > Bert, > > When you say "bring their stuff under the IETF umbrella", are you saying > that the original MIB in question was developed outside of IETF and is > being brought in, or are you talking about the link technology itself? > As far as I understand it, several (if not all) of the MIB modules (quite a few) have been developed in cablelabs context, and in fact have been implemented at a large scale. > If the latter, then I think the older IEEE802/IETF cooperation model on > MIBs works OK - there you had an IETF WG (bridge, maumib, ifmib etc.) > defining SMI MIBs under IETF root OID and having WG contributors make > sure that adequate coordination happened; a newer model where IEEE802 > has defined some of its own SMI MIBs has also been working OK (e.g. Link > Aggregation MIB from IEEE802, defined under IEEE802's own root OID). > > For the former case, what I don't think works is to have a MIB defined > outside of IETF and then brought to the IETF for some reason. What would > be the reason to do that? for IETF endorsement, for having IETF fixing > things that are broken, just to use the IETF root OID? I don't know the > specific reasons in this case for how this work got here. But it's > obvious to me that, if you bring existing work to IETF for > standardisation, be it the work of another standards' group, an industry > group or individual contributions, *you give up change control* and you > do not get any guarantees of backwards-compatibility: naturally you > don't expect gratuitous non-compatibility with earlier work - the WG > needs a valid reason to change something and one such reason would be > alignment with other IETF MIBs. > I think that is all understood. But I will leave it to Rich and JeanFrancois to answer the exact motives for coming to IETF. From my point of view, we will not just accept everything and rubber stamp. But I also understand that we have to be practical and that we do not just want to make them start from scratch just for the fun of it. By the way, quite a bit of the discussion about the Dscp, DscpOrAny, VlanID and VlanIDOrAny is also an issue for MIB modules from the past from IETF WGs. > [Note that, for this particular example of filter/pattern-matching on IP > packets with DSCPs, I'd originally proposed a separate generic MIB > module (included a "sixTupleClassifier" table) for the reason of making > it clear that this was general purpose and should be used by other MIBs, > including the Diffserv MIB. However, in the end, it was decided to merge > it into the main Diffserv MIB module (it became the > "diffServMultiFieldClfrTable" in RFC3289 - maybe it is less visible > there but maybe ADs can do something to raise awareness of its presence > amongst other WGs]. > That is why I DID ask the question to IPCDN WG, did you guys look at the other filter tables that we already have in the IETF. Bert > > Andrew Smith > > > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Friday, March 07, 2003 2:57 AM > To: Andrew Smith; Bert Wijnen > 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 > > > Andrew, > > Sure.... and what I am doing here is not the ideal solution, > but clearly I am trying to get various solutions aligned > as much as possible (you have seen my issues raised > for common definitions for Dscp, DscpOrAny, FlowLabel, > FlowLabelOrAny, VlanId, VlanIdOrAny ... etc etc. > > In the case of DOCSIS, the original stuff got developed > outside IETF. They now try to bring their stuff under the > IETF umbrella. We could tell them to drop/ditch all their own > stuff and start from scratch... which I suspect will not work, > or we can try to get them aligned as much as possible without > making them start from scratch. > > I think I am on the latter path... > Are you suggesting we (IETF) should be on the former path? > > Just trying to understand what you are urging us to do. > > Thanks, > Bert > > > -----Original Message----- > > From: Andrew Smith [mailto:ah_smith@acm.org] > > Sent: woensdag 5 maart 2003 21:42 > > To: Bert Wijnen > > 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 > > > > > > 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/curre > nt/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 From mailnull@www1.ietf.org Sun Mar 9 06:29:45 2003 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 GAA21664 for ; Sun, 9 Mar 2003 06:29:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h29BgBs06011 for diffserv-archive@odin.ietf.org; Sun, 9 Mar 2003 06:42:11 -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 h29BXsO04736; Sun, 9 Mar 2003 06:33:54 -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 h27NXmO25019 for ; Fri, 7 Mar 2003 18:33:48 -0500 Received: from ondar.cablelabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13825 for ; Fri, 7 Mar 2003 18:21:34 -0500 (EST) Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.8/8.12.8) with ESMTP id h27NNYKg008581; Fri, 7 Mar 2003 16:23:34 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Diffserv] Dscp and DscpOrAny TCs Date: Fri, 7 Mar 2003 16:23:34 -0700 Message-ID: Thread-Topic: [Diffserv] Dscp and DscpOrAny TCs thread-index: AcLk/3Yd6v25nOJSQGOi9eT3krDvaAAAEZzw From: "Jean-Francois Mule" To: "Woundy, Richard" , "Wijnen, Bert (Bert)" , "Andrew Smith" Cc: , , X-Approved: ondar Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h27NXmO25020 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: , List-Id: Diffserv Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > The IPCDN WG as a whole, and this chair in particular, > understands that the IETF owns change control for its drafts > and RFCs. That doesn't mean that folks in IPCDN will never > object to changes -- but is that really unique to this WG? > > What Bert says below is all we can ask for from the IETF: > > >From my point of view, we will not just accept everything and rubber > >stamp. But I also understand that we have to be practical > and that we > >do not just want to make them start from scratch just for the fun of > >it. > > -- Richard Woundy, IPCDN Co-Chair I second Rich's point above. The cable industry and CableLabs have made tremendous efforts to adopt a higher net citizen profile in working *with* IETF (of which some of us "cable" engineers feel a part of and have been a part of in previous lifes). Jean-Francois Mule, the other IPCDN Co-Chair _______________________________________________ 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 From mailnull@www1.ietf.org Sun Mar 9 06:39:10 2003 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 GAA23674 for ; Sun, 9 Mar 2003 06:39:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h29Bpao07475 for diffserv-archive@odin.ietf.org; Sun, 9 Mar 2003 06:51:36 -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 h29BgtO06049; Sun, 9 Mar 2003 06:42:55 -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 h292X6O23991 for ; Sat, 8 Mar 2003 21:33:06 -0500 Received: from dalziel.ucs.ed.ac.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07348; Sat, 8 Mar 2003 21:20:18 -0500 (EST) Received: from PYTHAGORAS.internetdesigntools.com (opal.epcc.ed.ac.uk [129.215.56.2]) by dalziel.ucs.ed.ac.uk (8.12.6/8.12.6) with ESMTP id h292J0Je013626; Sun, 9 Mar 2003 02:19:02 GMT Message-Id: <5.1.0.14.0.20030309015249.027bdbc0@localhost> X-Sender: martin@internetdesigntools.com@popmail.internetdesigntools.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 09 Mar 2003 02:20:36 +0000 To: Sapna Isotupa , diffserv@ietf.org From: Martin Westhead Subject: Re: [Diffserv] simulator for diffserv Cc: diffserv-interest@ietf.org In-Reply-To: References: <3E686E9B.BDB38CB7@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Edinburgh-Scanned: at dalziel.ucs.ed.ac.uk with MIMEDefang 2.29, Sophie 1.40rc1, Sophos Anti-Virus 3.66 X-Scanned-By: MIMEDefang 2.29 (www . roaringpenguin . com / mimedefang) 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: , List-Id: Diffserv Discussion List List-Post: List-Help: List-Subscribe: , At 08/03/2003 15:14 Saturday, Sapna Isotupa wrote: >Hello All: > >Is there a simulator available for testing various scheduling policies for >diffserv? If yes, could you tell me whom to contact to obtain one. If >there is no simulator available, will others be interested if a simulator >for testing various scheduling policies is built? Hi Sapna, This is off-topic for the diffserv list. I have cross posted to diffserv-interest and if there is any follow-up discussion it should go there. Intersim is a simulation platform that models very precisely the behaviour of Cisco diffserv algorithms. It is currently under development by Internet Design Tools, funded by Cisco Systems. We have access to the IOS source code and have taken a lot of trouble to ensure, and have lab tests to demonstrate, that the simulator's performance is indeed very close to that of the real router. We have plans to extend the simulator to generic diffserv models, and models of other vendor's platforms, however we do not a timescale for that development. There is more information available at www.internetdesigntools.com. Intersim is not commercially available at this point, but we have a small group of users, if you are interested in using it please contact me directly. Other simulators that also have (less specialised) models of diffserv behaviour include: Opnet: www.opnet.com Qualnet: www.qualnet.com ns-2: http://www.isi.edu/nsnam/ns/ The last one is open source and free, the others are commercial. Cheers, Martin ----------------------Internet-Design-Tools-Ltd.-------------------- Dr. Martin Westhead Phone: +44 77 189 189 64 Email: martin@InternetDeignTools.com ---------------------www.InternetDesignTools.com--------------------- _______________________________________________ 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 From mailnull@www1.ietf.org Sun Mar 9 17:46:46 2003 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 RAA22173 for ; Sun, 9 Mar 2003 17:46:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h29MxRX11941 for diffserv-archive@odin.ietf.org; Sun, 9 Mar 2003 17:59:27 -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 h29MouO11313; Sun, 9 Mar 2003 17:50:56 -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 h29McpO10974 for ; Sun, 9 Mar 2003 17:38:51 -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 RAA18097; Sun, 9 Mar 2003 17:25:35 -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 18s9Ge-0004wP-00; Sun, 09 Mar 2003 14:27:40 -0800 From: "Andrew Smith" To: "'Woundy, Richard'" Cc: , "'IPCDN WG \(E-mail\)'" Subject: RE: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Date: Sun, 9 Mar 2003 14:29:33 -0800 Message-ID: <0b9701c2e68b$5bcd9ec0$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: <6732623D2548D61193C90002A5C88DCC056637A7@entmaexch02.broadband.att.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: , List-Id: Diffserv Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Rich, I, and others in the Diffserv work including John, I believe, have always held a belief in a "null" or "no quality of service" PHB, aka the bit-bucket. Some of us even thought about writing a draft to describe this behaviour, recommending that its default DSCP value should be "everything else". Such a PHB implements part of the "defense against ... class of theft- and denial-of-service attacks" described by RFC 2474. With such a concept in place, there is no need for any additional filtering configuration: filtering becomes just a special case of the general Diffserv behaviour of a node. I have also argued, mostly during development of RFC 3290 in the Diffserv WG, that the QoS treatment that a packet receives is likely to be layer-independent (the differences between a L2 bridge, a L3 router, a L4-L7 load balancing switch etc. are mostly to do with the addresses on which a node makes switching/routing decisions, not the queueing treatment that packets receive). This implies that you may well need two classifiers on a packet, one to decide what QoS treatment, one to decide where to route it - the packet only goes through if both the routing and the QoS decide not to bit-bucket it. I think that "administrative bit-bucketing based on packet contents" is much more of a "QoS" thing than a "routing" thing: administrative controls on routing (e.g. BGP filters) are typically placed on the distribution of reachability of address information, not on data packet contents (other than the relevant address field(s)) themselves. Having said that, at least for nodes defending the edge of a Diffserv domain, I don't think it's worth having a purists' argument about whether bitmasks or ranges are appropriate for selecting behaviours based on DSCP fields. I think of DSCPs as just one more of the many possible fields used to classify the packet (a "Multi-Field Classifier" in Diffserv terminology): in fact you will often ignore the DSCP completely at this point if you don't trust the upstream domain to say anything reliable or useful (that is equivalent to "match 000000 with a bitmask of 000000"). It seems like it's more of an optimisation thing as to whether it really helps to be able to specify a range or mask vs. having to set out all the values explicitly. If this were a 16-bit field then I might think differently but it's really not much more work (given a suitable protocol and management information structure, of course) to have to spell out a list of 10s of discrete values, especially if you include an "everything else" case in the classifier (or possibly even a "NOT" operator in the classifier grammar). For the interior of a Diffserv domain though, I agree with Brian that ranges of DSCPs have no place. I do think it's worth arguing about whether "filters" deserve their own MIB/tables separate from "QoS". Andrew Smith -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org] On Behalf Of Woundy, Richard Sent: Friday, March 07, 2003 1:10 PM To: 'John Schnizlein' Cc: 'diffserv@ietf.org'; IPCDN WG (E-mail) Subject: RE: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs John, Thanks for the pointing out that the DiffServ field code points in the registry are just recommended values, not required values. Let me react to this statement, which I believe is key to the discussion about Dscp "filtering" in the DOCSIS Cable Device and Subscriber Management MIBs: >I don't appreciate the distinction. What was intended by PHB selector >was that traffic could be selected from the aggregate by the DSCP. >How is this different from filtering traffic based on DSCP matches? The key difference between "PHB selection" and "filtering" is with regards to the purpose for the matching. I understand "PHB selection" to mean packet classifiers that map traffic --based on a specific DSCP -- to a particular per hop behavior aggregate. I understand "filtering" to mean packet classifiers that condition traffic -- based on a specific DSCP value or group of values -- at the DS boundaries, by re-marking DSCP values or similar actions. This function is mentioned again in RFC 2474 section 7.1 (page 16): The defense against this class of theft- and denial-of-service attacks consists of the combination of traffic conditioning at DS domain boundaries with security and integrity of the network infrastructure within a DS domain. DS domain boundary nodes MUST ensure that all traffic entering the domain is marked with codepoint values appropriate to the traffic and the domain, remarking the traffic with new codepoint values if necessary. These DS boundary nodes are the primary line of defense against theft- and denial-of- service attacks based on modified codepoints, as success of any such attack indicates that the codepoints used by the attacking traffic were inappropriate... The same device may apply both "filtering" and "PHB selection" to its inbound traffic, in that order. The most recent version of the DOCSIS Cable Device MIB (an update of RFC 2669), , will enable the Cable Modem (CM) to filter traffic based on criteria in the new docsDevFilterInetTable, and overwrite the Dscp according to the docsDevFilterDscpTable. The DOCSIS Subscriber Management MIB, , will enable the Cable Modem Termination System (CMTS) to filter traffic based on criteria in the docsSubMgtPktFilterTable. This table enables the DOCSIS CMTS to drop traffic with illegal DSCPs that happen to elude a compromised CM. These two MIBs should define their DSCP-related objects according to best practices for their intended functionality -- hence this email. We do have a MIB in the IPCDN WG, the DOCSIS QoS MIB , in which the docsQosPktClassTable is similar to a PHB selection table. Unlike the previous two MIBs, this MIB is constrained by some outdated notions of packet selection during the DOCSIS 1.1 specification process (late '98/early '99). For example, DOCSIS 1.1 specifically calls for an IP ToS comparison: the packet's ToS is masked and compared to a range between "tos-low" and "tos-high". See Appendix C.2.1.5.1 in . This implies that this base DOCSIS 1.1 specification is going to need to be made DiffServ-aware, before the MIB can be made DiffServ-aware. I believe there is some cable operator support for such a project. -- Rich -----Original Message----- From: John Schnizlein [mailto:jschnizl@cisco.com] Sent: Friday, March 07, 2003 2:15 PM To: Woundy, Richard Cc: 'diffserv@ietf.org' Subject: Re: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Comments embedded in context below: At 09:40 AM 3/7/2003, Woundy, Richard wrote: >I'm looking for further reaction to my email below about DOCSIS/Dscp >interaction. >... >I think there are two issues here: are Dscp mask objects legal, No. >and are they worthwhile? No. >... enable the DOCSIS equipment to act precisely as "re-marking boundary >nodes", which are also described in RFC 2474 Section 3, pages 8-9: > > The structure of the DS field shown above is incompatible with the > existing definition of the IPv4 TOS octet in [RFC791]. The > presumption is that DS domains protect themselves by deploying re- > marking boundary nodes, as should networks using the RFC 791 > Precedence designations. Correct operational procedure SHOULD follow > [RFC791], which states: "If the actual use of these precedence > designations is of concern to a particular network, it is the > responsibility of that network to control the access to, and use of, > those precedence designations." Validating the value of the DS field > at DS boundaries is sensible in any case since an upstream node can > easily set it to any arbitrary value. DS domains that are not > isolated by suitably configured boundary nodes may deliver > unpredictable service. > > Nodes MAY rewrite the DS field as needed to provide a desired local > or end-to-end service. Specifications of DS field translations at DS > boundaries are the subject of service level agreements between > providers and users, and are outside the scope of this document. > Standardized PHBs allow providers to build their services from a > well-known set of packet forwarding treatments that can be expected > to be present in the equipment of many vendors. > >On the other hand, I see the definite lack of structure in the DiffServ >codepoints, and I am debating with myself whether a "Dscp mask" is worth the >trouble or not. > >In particular, I am looking at the current codepoint assignments in >,... You may be running into a subtlety that was worried about early in defining the DiffServ field. The code points in the registry are just recommended values, not required values. While there are requirements regarding which behaviors must be supported to claim DiffServ compliance, there is no requirement that the recommended values be used to indicate these behaviors. The point is that there is no reliable structure for "the network operator to take advantage of". The presence of masks in data objects would encourage creating the sort of structure the RFC prohibits. Note the distinction between the SHOULD regarding values, and the MUST regarding treating the value as a unit (copied farther below): RFC 2474 section 2, page 5 Codepoint: a specific value of the DSCP portion of the DS field. Recommended codepoints SHOULD map to specific, standardized PHBs. >From: Wilson.Sawyer@arrisi.com [mailto:Wilson.Sawyer@arrisi.com] > >Keep in mind we're talking about a *filter* here, not a PHB selector. I don't appreciate the distinction. What was intended by PHB selector was that traffic could be selected from the aggregate by the DSCP. How is this different from filtering traffic based on DSCP matches? >And we'e not inferring bit-structure in the implementation, merely >allowing the network operator to take advantage of any structure >that exists. Do we really want to require the operator to install >three separate filters to catch one AF class? > >I don't find anything in the cited paragraph that contraindicates this sort >of usage. The fact that today's PHB selector set is likely to change is all >the more reason to give a filter-installer some options for concise >representation. >... >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 _______________________________________________ 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 From mailnull@www1.ietf.org Sun Mar 9 22:01:27 2003 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 WAA09317 for ; Sun, 9 Mar 2003 22:01:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2A3EDT26800 for diffserv-archive@odin.ietf.org; Sun, 9 Mar 2003 22:14:13 -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 h2A35AO25546; Sun, 9 Mar 2003 22:05:11 -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 h2A20qO21993 for ; Sun, 9 Mar 2003 21:00:52 -0500 Received: from gandalf.icr.a-star.edu.sg (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25740 for ; Sun, 9 Mar 2003 20:47:33 -0500 (EST) Received: from mailer.icr.a-star.edu.sg (mailer.icr.a-star.edu.sg [137.132.31.243]) by gandalf.icr.a-star.edu.sg (8.12.8+Sun/8.12.2) with ESMTP id h2A1oIc1023061 for ; Mon, 10 Mar 2003 09:50:18 +0800 (SGT) Received: from bkdom-MTA by mailer.icr.a-star.edu.sg with Novell_GroupWise; Mon, 10 Mar 2003 09:42:49 +0800 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.3 Date: Mon, 10 Mar 2003 09:42:36 +0800 From: "Jiang Yuming" To: , Subject: Re: [Diffserv] diffserv WG closing Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2A20qO21996 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: , List-Id: Diffserv Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi All, Since the diffserv WG is closing, I am wondering to which WG a diffserv PDB, such as EF PDB, should be proposed. Yuming >>> Scott Bradner 03/08/03 08:48PM >>> With the publication of the diffserv PIB the working group is now being closed. The working group was very successfull, producing 15 RFCs and technology that is widely seen as a key part of the Internet toolbox. I want to thank the WG chairs who put so much good work into this effort over more years than we thought it would take when we started. Scott _______________________________________________ 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 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 From mailnull@www1.ietf.org Mon Mar 10 06:11:50 2003 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 GAA19840 for ; Mon, 10 Mar 2003 06:11:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2ABOli02332 for diffserv-archive@odin.ietf.org; Mon, 10 Mar 2003 06:24:47 -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 h2ABHOO01677; Mon, 10 Mar 2003 06:17:24 -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 h2AB23O00344 for ; Mon, 10 Mar 2003 06:02:03 -0500 Received: from d12lmsgate.de.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15565 for ; Mon, 10 Mar 2003 05:48:34 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.8/8.12.3) with ESMTP id h2AAo9So037926; Mon, 10 Mar 2003 11:50:12 +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 h2AAo1sx221350; Mon, 10 Mar 2003 11:50:02 +0100 Received: from dhcp22-14.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA44914 from ; Mon, 10 Mar 2003 11:49:59 +0100 Message-Id: <3E6C6D9C.CC0D88AE@hursley.ibm.com> Date: Mon, 10 Mar 2003 11:49:00 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Jiang Yuming Cc: sob@harvard.edu, diffserv@ietf.org Subject: Re: [Diffserv] diffserv WG closing References: 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: , List-Id: Diffserv Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The procedure for this is defined in RFC 3086. Brian Jiang Yuming wrote: > > Hi All, > > Since the diffserv WG is closing, I am wondering to which WG a diffserv PDB, such as EF PDB, should be proposed. > > Yuming > > >>> Scott Bradner 03/08/03 08:48PM >>> > > With the publication of the diffserv PIB the working group is now being closed. > > The working group was very successfull, producing 15 RFCs and technology > that is widely seen as a key part of the Internet toolbox. > > I want to thank the WG chairs who put so much good work into this effort > over more years than we thought it would take when we started. > > Scott > _______________________________________________ > 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 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 -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland _______________________________________________ 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 From mailnull@www1.ietf.org Wed Mar 12 18:23:28 2003 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 SAA29525 for ; Wed, 12 Mar 2003 18:23:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CNbaA26374 for diffserv-archive@odin.ietf.org; Wed, 12 Mar 2003 18:37:36 -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 h2CNQvO24754; Wed, 12 Mar 2003 18:26:57 -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 h2CNCJO24159 for ; Wed, 12 Mar 2003 18:12:19 -0500 Received: from snowmass.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27267; Wed, 12 Mar 2003 17:57:39 -0500 (EST) Received: from mms02-RelayB.tci.com (mms02-relayb.broadband.att.com [147.191.89.213]) by snowmass.tci.com (8.12.2/8.12.2) with ESMTP id h2CMxjH1013961; Wed, 12 Mar 2003 15:59:46 -0700 (MST) Received: from 147.191.90.10 by mms02-RelayB.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Wed, 12 Mar 2003 15:59:38 -0600 Received: by entexchimc03.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Wed, 12 Mar 2003 15:58:03 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC06B9ADD2@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "Brian E Carpenter" , "'diffserv@ietf.org'" cc: "IPCDN WG (E-mail)" , "Woundy, Richard" Subject: RE: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Date: Wed, 12 Mar 2003 15:59:30 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 12716450483534-02-01 Content-Type: text/plain; charset=iso-8859-1 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: , List-Id: Diffserv Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Brian (and many diffserv folks), Thanks for your input and of the diffserv WG. I will assume that our IPCDN MIBs need to use explicit DSCP values and not use DSCP masks. Please forgive this question for my DiffServ education. I have heard several times that "network operators are free to ignore the recommended code points", and that this is a major reason why we should not use DSCP masks. What benefits does a network operator achieve with an unstructured set of DSCPs? In fact, I *am* a network operator -- I work for Comcast Cable, which has lots of regional networks and millions of residential cable modem subscribers. I see the pain associated with network management of my boundary nodes with unstructured DSCP assignments. Where's the benefit to me? I don't mind if folks take this question off-list, or if folks refer me to specific diffserv mail archives (e.g. a specific "thread" name) where this was already discussed. Just as long as I am not mistaken as a spammer. ;^) -- Rich -----Original Message----- From: Brian E Carpenter [mailto:brian@hursley.ibm.com] Sent: Saturday, March 08, 2003 6:59 AM To: John Schnizlein Cc: Woundy, Richard; 'diffserv@ietf.org' Subject: Re: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs What John writes is definitive. Masking DSCPs is simply wrong. The fact that the recommended AF code points happen to be numerically consecutive is just an accident of the code point assignment process; the bit positions are not significant, and network operators are free to ignore the recommended code points if they want to. Brian John Schnizlein wrote: > > Comments embedded in context below: > > At 09:40 AM 3/7/2003, Woundy, Richard wrote: > > >I'm looking for further reaction to my email below about DOCSIS/Dscp > >interaction. > >... > >I think there are two issues here: are Dscp mask objects legal, > > No. > > >and are they worthwhile? > > No. > > >... enable the DOCSIS equipment to act precisely as "re-marking boundary > >nodes", which are also described in RFC 2474 Section 3, pages 8-9: > > > > The structure of the DS field shown above is incompatible with the > > existing definition of the IPv4 TOS octet in [RFC791]. The > > presumption is that DS domains protect themselves by deploying re- > > marking boundary nodes, as should networks using the RFC 791 > > Precedence designations. Correct operational procedure SHOULD follow > > [RFC791], which states: "If the actual use of these precedence > > designations is of concern to a particular network, it is the > > responsibility of that network to control the access to, and use of, > > those precedence designations." Validating the value of the DS field > > at DS boundaries is sensible in any case since an upstream node can > > easily set it to any arbitrary value. DS domains that are not > > isolated by suitably configured boundary nodes may deliver > > unpredictable service. > > > > Nodes MAY rewrite the DS field as needed to provide a desired local > > or end-to-end service. Specifications of DS field translations at DS > > boundaries are the subject of service level agreements between > > providers and users, and are outside the scope of this document. > > Standardized PHBs allow providers to build their services from a > > well-known set of packet forwarding treatments that can be expected > > to be present in the equipment of many vendors. > > > >On the other hand, I see the definite lack of structure in the DiffServ > >codepoints, and I am debating with myself whether a "Dscp mask" is worth the > >trouble or not. > > > >In particular, I am looking at the current codepoint assignments in > >,... > > You may be running into a subtlety that was worried about early in > defining the DiffServ field. The code points in the registry are > just recommended values, not required values. While there are > requirements regarding which behaviors must be supported to claim > DiffServ compliance, there is no requirement that the recommended > values be used to indicate these behaviors. > > The point is that there is no reliable structure for "the network > operator to take advantage of". The presence of masks in data objects > would encourage creating the sort of structure the RFC prohibits. > > Note the distinction between the SHOULD regarding values, and the MUST regarding treating the value as a unit (copied farther below): > > RFC 2474 section 2, page 5 > Codepoint: a specific value of the DSCP portion of the DS field. > Recommended codepoints SHOULD map to specific, standardized PHBs. > > >From: Wilson.Sawyer@arrisi.com [mailto:Wilson.Sawyer@arrisi.com] > > > >Keep in mind we're talking about a *filter* here, not a PHB selector. > > I don't appreciate the distinction. What was intended by PHB selector > was that traffic could be selected from the aggregate by the DSCP. > How is this different from filtering traffic based on DSCP matches? > > >And we'e not inferring bit-structure in the implementation, merely > >allowing the network operator to take advantage of any structure > >that exists. Do we really want to require the operator to install > >three separate filters to catch one AF class? > > > >I don't find anything in the cited paragraph that contraindicates this sort > >of usage. The fact that today's PHB selector set is likely to change is all > >the more reason to give a filter-installer some options for concise > >representation. > >... > >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 _______________________________________________ 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 From mailnull@www1.ietf.org Thu Mar 13 08:14:02 2003 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 IAA29328 for ; Thu, 13 Mar 2003 08:14:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DDSTV25770 for diffserv-archive@odin.ietf.org; Thu, 13 Mar 2003 08:28:29 -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 h2DDHpO24994; Thu, 13 Mar 2003 08:17:51 -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 h2DD5GO23600 for ; Thu, 13 Mar 2003 08:05:16 -0500 Received: from d12lmsgate-3.de.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28613 for ; Thu, 13 Mar 2003 07:50:17 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.8/8.12.8) with ESMTP id h2DCqNEO048258; Thu, 13 Mar 2003 13:52:24 +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 h2DCqNcx282588; Thu, 13 Mar 2003 13:52:23 +0100 Received: from dhcp23-54.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA53226 from ; Thu, 13 Mar 2003 13:52:21 +0100 Message-Id: <3E707ECA.18EBB328@hursley.ibm.com> Date: Thu, 13 Mar 2003 13:51:22 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Diff Serv References: <200303112008.PAA08957@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] List change [Re: WG Action: Differentiated Services (diffserv) to conclude] 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: , List-Id: Diffserv Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit As mentioned a few days ago, this mailing list will be closed, to evade massive amounts of spam. Discussion of diffserv issues is welcome on That list is moderated to suppress any spam that may find it, but since there is no longer a WG charter, anything relevant to diffserv is OK there. The best way to join the list is to point your browser at http://www1.ietf.org/mailman/listinfo/diffserv-interest (Alternatively: mail to containing only the word subscribe ) You may also be interested by http://www.tip.csiro.au/dsimplementation/ Regards Brian Carpenter diffserv co-chair (retired) The IESG wrote: > > The Differentiated Services (diffserv) Working Group in the Transport > Area of the IETF has concluded. > > The IESG Contact Persons are Scott Bradner and Allison Mankin. _______________________________________________ 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