From mailnull@www1.ietf.org Sat Jan 4 06:11: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 GAA09199 for ; Sat, 4 Jan 2003 06:11:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h04BKhr12433 for diffserv-archive@odin.ietf.org; Sat, 4 Jan 2003 06:20: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 h04B6gJ11359; Sat, 4 Jan 2003 06:06:42 -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 h04ApCJ10953 for ; Sat, 4 Jan 2003 05:51:12 -0500 Received: from localhost.localdomain (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08966 for ; Sat, 4 Jan 2003 05:41:24 -0500 (EST) Received: from valmiki ([192.168.10.8]) by localhost.localdomain (8.12.5/8.12.5) with ESMTP id h04AVUgw008641 for ; Sat, 4 Jan 2003 16:01:38 +0530 Content-Type: text/plain; charset="us-ascii" From: nerdboy Reply-To: nerdboy@rediffmail.com To: Subject: Re: [Diffserv] diffserv implementation on linux(rh 8.0) Date: Sat, 4 Jan 2003 16:16:41 +0530 User-Agent: KMail/1.4.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200301041616.42026.nerdboy@rediffmail.com> Content-Transfer-Encoding: 8bit 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 many many thanks to mohit , abiola and francis. i have spent the past few days poring over the lartc and diffserv archives. although i now know how to use the 'tc' commands , i yet am unaware of any way to test if tc works as it should do. presume it can be tested by passing packets throught the network. if any body in here who has implemented diffserv and aplied it to set of mpls routers can tell me about how to go about it, i'd be grateful. thanking you in anticipation nerd (have attached the list of responses i received in the hope that they will be of use to other members.) From: Mohit Singh u can implement it using open source libraries available for linux implementations - e.g. RED /RIO for linux ! to check how it works , u need to ascertain quality of the data u are processing. e.g., for VoIP qos, u need to test voice quality depending on system invloved. plz be in touch... mohit ------------------------------ "Abiola O. Adegboyega" Hi there! 1. Use a network simulator (ns-2 is available for free at www.isi.edu/nsnam/ns) 2. Follow the instructions and install on unix. 3. There are example scripts that you can simulate and observe results 4. You might want to use some perl scripts to measure average queue lengths, bandwidth provisioned etc. If u need further help, let me know. Rgds, 'Biola. ------------------------ From: "Scott Allen" If you receive direct replies to your email, could you forward me copies of the DiffServ advice? I also am tasked with building a DiffServ network (using a Cisco infrastructure however, not Linux, but who knows how things might change) and I'm interested in the replies you receive. If they are global replies to diffserv@ietf.org , of course, I'll see them. Thanks. Scott Allen Chief Information Officer TeleSuite Corporation 937-836-9995 option 2 ---------------------------- FrancisDomoney@aol.com you could try looking at this site http://www.nwfusion.com/auddev/pop/LANFOC208.html then hit the Cisco site for some teach yourself tutorials. then arm yourself with a modelling tool and build a model of the network. When it gives you the required theoretical performance buy some routers and build it. Frank Domoney Glencroft Ltd Cambridge _______________________________________________ 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 Jan 6 03:56: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 DAA29575 for ; Mon, 6 Jan 2003 03:56:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0696LU02269 for diffserv-archive@odin.ietf.org; Mon, 6 Jan 2003 04:06:21 -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 h068oDJ01285; Mon, 6 Jan 2003 03:50:13 -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 h068c1J00862 for ; Mon, 6 Jan 2003 03:38:01 -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 DAA29137 for ; Mon, 6 Jan 2003 03:27:21 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id h068UXMP012796; Mon, 6 Jan 2003 09:30:33 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id h068UUqb116188; Mon, 6 Jan 2003 09:30:31 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA30656 from ; Mon, 6 Jan 2003 09:30:28 +0100 Message-Id: <3E193E81.615F91F3@hursley.ibm.com> Date: Mon, 06 Jan 2003 09:29:53 +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: KiTae Nahm Cc: diffserv@ietf.org Subject: Re: [Diffserv] Are RED routers realistic enough? References: <000001c2ad8f$5d35a300$9e147d80@GREEN> 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 Kitae, This isn't really the list for this question. You might try the end2end-interest list. See http://www.postel.org/mailman/listinfo/end2end-interest Brian KiTae Nahm wrote: > > Dear folks, > > I'm interested in AF PHB. I'm curious about the deployment > statistics of RED-capable routers in the real-world ISPs. > I know there are many RED routers in the equipment market, > but I wonder how much of the real-world networks are now > ready for RED. Thanks. > > Kitae > > _______________________________________________ > 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 Jan 8 11:08: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 LAA23361 for ; Wed, 8 Jan 2003 11:08:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h08GK6d32502 for diffserv-archive@odin.ietf.org; Wed, 8 Jan 2003 11:20:06 -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 h08G3hJ30998; Wed, 8 Jan 2003 11:03: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 h08FrIJ30613 for ; Wed, 8 Jan 2003 10:53:18 -0500 Received: from web14310.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22740 for ; Wed, 8 Jan 2003 10:41:32 -0500 (EST) Message-ID: <20030108154446.18431.qmail@web14310.mail.yahoo.com> Received: from [155.198.17.120] by web14310.mail.yahoo.com via HTTP; Wed, 08 Jan 2003 07:44:46 PST Date: Wed, 8 Jan 2003 07:44:46 -0800 (PST) From: Goyan To: Diffserv IETF MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Diffserv] New MBS 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: , Dear all, I am currently working on a project about MBS (Measure-Based Scheduling Algorithm). I have read papers from R. M. Salles and Dr. J. Barria. However, is there any more algorithms or new development in such an area? Thanks for your time. Goyan __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.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 Fri Jan 17 07:36: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 HAA19853 for ; Fri, 17 Jan 2003 07:36:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0HCqQm27047 for diffserv-archive@odin.ietf.org; Fri, 17 Jan 2003 07:52:26 -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 h0HCfvJ26501; Fri, 17 Jan 2003 07:41: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 h0HCXoJ25621 for ; Fri, 17 Jan 2003 07:33:50 -0500 Received: from rediffmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA19242 for ; Fri, 17 Jan 2003 07:17:45 -0500 (EST) Received: (qmail 21862 invoked by uid 510); 17 Jan 2003 12:16:59 -0000 Date: 17 Jan 2003 12:16:59 -0000 Message-ID: <20030117121659.21861.qmail@webmail8.rediffmail.com> Received: from unknown (202.140.142.131) by rediffmail.com via HTTP; 17 jan 2003 12:16:59 -0000 MIME-Version: 1.0 From: "Manish Ramesh K" Reply-To: "Manish Ramesh K" To: diffServ@ietf.org Content-type: text/plain; format=flowed Content-Disposition: inline Subject: [Diffserv] MIB- Related clarifications 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: , Hi I am supporting SNMP configuration for DiffServ, based on DiffServ MIB taken from . I am facing some issues, it would be of great help if you could provide me with clarifications. We use a 2 layer model - forwarding plane and control plane. 1)When the row status is ACTIVE and user wants to modify an object of that row, is each change expected to be reflected in the forwarding plane ? 2)Is it appropriate to have a limitation that in order to modify objects of an ACTIVE row, the user must set the row status of the row being modified to NOTINSERVICE, then modify the object and again set the row status back to ACTIVE? 3)Also, when I have an ACTIVE configuration like this "DataPathStart--->ClassifierEntry--->MeterEntry---->MarkerEntry" and the user wants to modify the marker entry. If he sets the row status of the marker entry from ACTIVE to NOTINSERVICE. What should happen to the forwarding path ? a) Should we remove all the entries pointing to this marker entry, and its dependents as well ? Or b) Should we continue to have the marker entry till the user modifies it and sets the status to ACTIVE and then update it? TIA, Manish. _______________________________________________ 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 Tue Jan 21 05:37: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 FAA25250 for ; Tue, 21 Jan 2003 05:37:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0LAtGO06289 for diffserv-archive@odin.ietf.org; Tue, 21 Jan 2003 05:55:16 -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 h0LAmmJ05966; Tue, 21 Jan 2003 05:48:48 -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 h0LAd2J05691 for ; Tue, 21 Jan 2003 05:39:02 -0500 Received: from agitator.ibr.cs.tu-bs.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25068 for ; Tue, 21 Jan 2003 05:21:02 -0500 (EST) Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.6/8.12.6/Debian-6Woody) with ESMTP id h0LAONgQ004168 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Tue, 21 Jan 2003 11:24:23 +0100 Received: from hansa.ibr.cs.tu-bs.de (schoenw@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) with ESMTP id h0LAONAa026848 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Tue, 21 Jan 2003 11:24:23 +0100 Received: (from schoenw@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) id h0LAONtX026845; Tue, 21 Jan 2003 11:24:23 +0100 Date: Tue, 21 Jan 2003 11:24:23 +0100 Message-Id: <200301211024.h0LAONtX026845@hansa.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: bwijnen@lucent.com CC: rap@ops.ietf.org, diffserv@ietf.org In-reply-to: <7D5D48D2CAA3D84C813F5B154F43B155AA9B41@nl0006exch001u.nl.lucent.com> (bwijnen@lucent.com) References: <7D5D48D2CAA3D84C813F5B154F43B155AA9B41@nl0006exch001u.nl.lucent.com> Subject: [Diffserv] FlowId and FlowIdOrAny 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: , I changed the subject line and fixed the proposed TC. So here is where I think we are. I have also reduced the CC list and I have added the diffserv mailing list since diffserv folks should be in the loop I think. FlowId TECTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The flow identifier in an IPv6 header that may be used to discriminate traffic flows." REFERENCE "RFC 2460" SYNTAX Integer32 (0..1048575) FlowIdOrAny TECTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The flow identifier in an IPv6 header that may be used to discriminate traffic flows. The value of -1 is used to indicate a wildcard, i.e. any value." REFERENCE "RFC 2460" SYNTAX Integer32 (-1 | 0..1048575) Open issues: - Is the flow identifier the same as the flow label? I guess so. If this is true, then we should probably use the TC names FlowLabel and FlowLableOrAny and also change the wordings in the description clause. - The name of the MIB modules which will contain these definitions. - Since Fred kind of said that the diffServMultiFieldClfrFlowId object should have had a wildcard, can we agree that this is actually a bug in RFC 3289 which will be fixed by using FlowIdOrAny in the next revision of the DIFFSERV-MIB? /js -- Juergen Schoenwaelder _______________________________________________ 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 Tue Jan 21 07:22:56 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 HAA26768 for ; Tue, 21 Jan 2003 07:22:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0LCeSc12838 for diffserv-archive@odin.ietf.org; Tue, 21 Jan 2003 07:40: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 h0LCWfJ11811; Tue, 21 Jan 2003 07:32:41 -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 h0LCOdJ11549 for ; Tue, 21 Jan 2003 07:24:39 -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 HAA26567 for ; Tue, 21 Jan 2003 07:06:36 -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.2/Switch-2.2.0) with ESMTP id h0LCA0T24473 for ; Tue, 21 Jan 2003 07:10:01 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Jan 2003 13:10:00 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155BADE65@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Juergen Schoenwaelder , bwijnen@lucent.com Cc: rap@ops.ietf.org, diffserv@ietf.org Date: Tue, 21 Jan 2003 13:09:45 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Diffserv] RE: FlowId and FlowIdOrAny 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: , Ok, good, cause I was surprised to see a -1 in an Unsigned32. Now... if we do this, then this could still be used by the framework pib. However, for the diffserv-mib it would mean they must deprecate a current object and create a new one (switching from Unsigned to Integer32 causes a change on the wire!). The solution presented earlier could be considered as a bug fix and would not require the diffserv-MIB to deprecate the existing object Thanks, Bert > -----Original Message----- > From: Juergen Schoenwaelder [mailto:schoenw@ibr.cs.tu-bs.de] > Sent: dinsdag 21 januari 2003 11:24 > To: bwijnen@lucent.com > Cc: rap@ops.ietf.org; diffserv@ietf.org > Subject: FlowId and FlowIdOrAny > > > > I changed the subject line and fixed the proposed TC. So here is where > I think we are. I have also reduced the CC list and I have added the > diffserv mailing list since diffserv folks should be in the loop I > think. > > FlowId TECTUAL-CONVENTION > DISPLAY-HINT "d" > STATUS current > DESCRIPTION > "The flow identifier in an IPv6 header that may be used to > discriminate traffic flows." > REFERENCE > "RFC 2460" > SYNTAX Integer32 (0..1048575) > > FlowIdOrAny TECTUAL-CONVENTION > DISPLAY-HINT "d" > STATUS current > DESCRIPTION > "The flow identifier in an IPv6 header that may be used to > discriminate traffic flows. The value of -1 is used to > indicate a wildcard, i.e. any value." > REFERENCE > "RFC 2460" > SYNTAX Integer32 (-1 | 0..1048575) > > Open issues: > > - Is the flow identifier the same as the flow label? I guess so. If > this is true, then we should probably use the TC names FlowLabel > and FlowLableOrAny and also change the wordings in the description > clause. > > - The name of the MIB modules which will contain these definitions. > > - Since Fred kind of said that the diffServMultiFieldClfrFlowId > object should have had a wildcard, can we agree that this is > actually a bug in RFC 3289 which will be fixed by using FlowIdOrAny > in the next revision of the DIFFSERV-MIB? > > /js > > -- > Juergen Schoenwaelder _______________________________________________ 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 Tue Jan 21 07:53: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 HAA27774 for ; Tue, 21 Jan 2003 07:53:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0LDBEj14989 for diffserv-archive@odin.ietf.org; Tue, 21 Jan 2003 08:11:14 -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 h0LD4SJ13761; Tue, 21 Jan 2003 08:04:28 -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 h0LCseJ13277 for ; Tue, 21 Jan 2003 07:54:40 -0500 Received: from agitator.ibr.cs.tu-bs.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26970 for ; Tue, 21 Jan 2003 07:36:35 -0500 (EST) Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.6/8.12.6/Debian-6Woody) with ESMTP id h0LCdmgQ024811 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Tue, 21 Jan 2003 13:39:48 +0100 Received: from hansa.ibr.cs.tu-bs.de (schoenw@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) with ESMTP id h0LCdlAa029668 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Tue, 21 Jan 2003 13:39:47 +0100 Received: (from schoenw@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) id h0LCdh8T029652; Tue, 21 Jan 2003 13:39:43 +0100 Date: Tue, 21 Jan 2003 13:39:43 +0100 Message-Id: <200301211239.h0LCdh8T029652@hansa.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: bwijnen@lucent.com CC: bwijnen@lucent.com, rap@ops.ietf.org, diffserv@ietf.org In-reply-to: <7D5D48D2CAA3D84C813F5B154F43B155BADE65@nl0006exch001u.nl.lucent.com> (bwijnen@lucent.com) References: <7D5D48D2CAA3D84C813F5B154F43B155BADE65@nl0006exch001u.nl.lucent.com> Subject: [Diffserv] Re: FlowId and FlowIdOrAny 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: , >>>>> Wijnen, Bert (Bert) writes: Bert> Now... if we do this, then this could still be used by the Bert> framework pib. However, for the diffserv-mib it would mean they Bert> must deprecate a current object and create a new one (switching Bert> from Unsigned to Integer32 causes a change on the wire!). Oops, I missed that part of the picture. So if there is concensus to change the range as a bug fix in the DIFFSERV0MIB without introducing a new object (which formally the SMIv2 would require to do), then using Unsigned32 makes some sense. Note that this will also most likely include the definition of a DEFVAL which is in fact the new value. However, if we decided that it is safer to use deprecate the filter obejct and introduce a new one, I prefer to use Integer32. BTW, this is what I found in the INTEGRATED-SERVICES-MIB: intSrvFlowFlowId OBJECT-TYPE SYNTAX INTEGER (0..16777215) MAX-ACCESS read-only STATUS current DESCRIPTION "The flow ID that this sender is using, if this is an IPv6 session." ::= { intSrvFlowEntry 11 } Note that this range is [0..2^24-1] while the other definitions under discussion use a range of [0..2^20-1]. Note that RFC 2460 says: : Flow Label 20-bit flow label. See section 6. /js -- Juergen Schoenwaelder _______________________________________________ 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 Tue Jan 21 09:36:41 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 JAA01197 for ; Tue, 21 Jan 2003 09:36:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0LEsGi21789 for diffserv-archive@odin.ietf.org; Tue, 21 Jan 2003 09:54:16 -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 h0LEk8J21336; Tue, 21 Jan 2003 09:46:08 -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 h0LEdjJ21102 for ; Tue, 21 Jan 2003 09:39:45 -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 JAA00971 for ; Tue, 21 Jan 2003 09:21:39 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-4.de.ibm.com (8.12.3/8.12.3) with ESMTP id h0LEOx9J031248; Tue, 21 Jan 2003 15:25:00 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id h0LEIbm2207108; Tue, 21 Jan 2003 15:22:28 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA48648 from ; Tue, 21 Jan 2003 15:18:27 +0100 Message-Id: <3E2D5689.F92C3392@hursley.ibm.com> Date: Tue, 21 Jan 2003 15:17:45 +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: Juergen Schoenwaelder Cc: bwijnen@lucent.com, rap@ops.ietf.org, diffserv@ietf.org Subject: Re: [Diffserv] Re: FlowId and FlowIdOrAny References: <7D5D48D2CAA3D84C813F5B154F43B155BADE65@nl0006exch001u.nl.lucent.com> <200301211239.h0LCdh8T029652@hansa.ibr.cs.tu-bs.de> 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 flow label in IPv6 was 24 bits at one time. So that looks like a minor obsolescence in the Intserv MIB. Brian Juergen Schoenwaelder wrote: > > >>>>> Wijnen, Bert (Bert) writes: > > Bert> Now... if we do this, then this could still be used by the > Bert> framework pib. However, for the diffserv-mib it would mean they > Bert> must deprecate a current object and create a new one (switching > Bert> from Unsigned to Integer32 causes a change on the wire!). > > Oops, I missed that part of the picture. So if there is concensus to > change the range as a bug fix in the DIFFSERV0MIB without introducing > a new object (which formally the SMIv2 would require to do), then > using Unsigned32 makes some sense. Note that this will also most > likely include the definition of a DEFVAL which is in fact the new > value. However, if we decided that it is safer to use deprecate the > filter obejct and introduce a new one, I prefer to use Integer32. > > BTW, this is what I found in the INTEGRATED-SERVICES-MIB: > > intSrvFlowFlowId OBJECT-TYPE > SYNTAX INTEGER (0..16777215) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The flow ID that this sender is using, if > this is an IPv6 session." > ::= { intSrvFlowEntry 11 } > > Note that this range is [0..2^24-1] while the other definitions under > discussion use a range of [0..2^20-1]. Note that RFC 2460 says: > > : Flow Label 20-bit flow label. See section 6. > > /js > > -- > Juergen Schoenwaelder _______________________________________________ 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 Tue Jan 21 10:34:18 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 KAA02627 for ; Tue, 21 Jan 2003 10:34:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0LFpqT25928 for diffserv-archive@odin.ietf.org; Tue, 21 Jan 2003 10:51:52 -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 h0LFiLJ25403; Tue, 21 Jan 2003 10:44:21 -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 h0LFcCJ25169 for ; Tue, 21 Jan 2003 10:38:12 -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 KAA02169 for ; Tue, 21 Jan 2003 10:20:05 -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.2/Switch-2.2.0) with ESMTP id h0LFNSg17848 for ; Tue, 21 Jan 2003 10:23:28 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Jan 2003 16:23:26 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155BADF67@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Brian E Carpenter , Juergen Schoenwaelder Cc: bwijnen@lucent.com, rap@ops.ietf.org, diffserv@ietf.org Subject: RE: [Diffserv] Re: FlowId and FlowIdOrAny Date: Tue, 21 Jan 2003 16:21: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: , OK, so if I understand you correctly, then the newly proposed TCs would also be useable for the Intserv MIB when they do a revision, right? And again that can then be considered a bug fix. So we now have a conflict in that if we make it Integer32, then diffserv MIB needs to deprecate and create a new object If we make it Unsigned32, then Intserv MIB needs to deprecate and create a new object. It then seems to me that making it Integer32 as suggested by Juergen then makes the most sense, since that seems to be then more consistent with how we have done this at other places (that is, used a -1 value to mean any). Comments? Thanks, Bert > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: dinsdag 21 januari 2003 15:18 > To: Juergen Schoenwaelder > Cc: bwijnen@lucent.com; rap@ops.ietf.org; diffserv@ietf.org > Subject: Re: [Diffserv] Re: FlowId and FlowIdOrAny > > > The flow label in IPv6 was 24 bits at one time. So that looks like > a minor obsolescence in the Intserv MIB. > > Brian > > Juergen Schoenwaelder wrote: > > > > >>>>> Wijnen, Bert (Bert) writes: > > > > Bert> Now... if we do this, then this could still be used by the > > Bert> framework pib. However, for the diffserv-mib it > would mean they > > Bert> must deprecate a current object and create a new one > (switching > > Bert> from Unsigned to Integer32 causes a change on the wire!). > > > > Oops, I missed that part of the picture. So if there is concensus to > > change the range as a bug fix in the DIFFSERV0MIB without > introducing > > a new object (which formally the SMIv2 would require to do), then > > using Unsigned32 makes some sense. Note that this will also most > > likely include the definition of a DEFVAL which is in fact the new > > value. However, if we decided that it is safer to use deprecate the > > filter obejct and introduce a new one, I prefer to use Integer32. > > > > BTW, this is what I found in the INTEGRATED-SERVICES-MIB: > > > > intSrvFlowFlowId OBJECT-TYPE > > SYNTAX INTEGER (0..16777215) > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The flow ID that this sender is using, if > > this is an IPv6 session." > > ::= { intSrvFlowEntry 11 } > > > > Note that this range is [0..2^24-1] while the other > definitions under > > discussion use a range of [0..2^20-1]. Note that RFC 2460 says: > > > > : Flow Label 20-bit flow label. See section 6. > > > > /js > > > > -- > > Juergen Schoenwaelder > > _______________________________________________ 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 Tue Jan 21 11:55:03 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 LAA05072 for ; Tue, 21 Jan 2003 11:55:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0LHCdQ32673 for diffserv-archive@odin.ietf.org; Tue, 21 Jan 2003 12:12:39 -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 h0LH1eJ31005; Tue, 21 Jan 2003 12:01: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 h0LGqBJ30617 for ; Tue, 21 Jan 2003 11:52:11 -0500 Received: from ftpbox.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04369 for ; Tue, 21 Jan 2003 11:34:03 -0500 (EST) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h0LGbPOD024250; Tue, 21 Jan 2003 09:37:25 -0700 (MST) Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id JAA15071; Tue, 21 Jan 2003 09:37:24 -0700 (MST)] Received: from dma.isg.mot.com (ma07-0056.dma.isg.mot.com [150.21.30.201]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id LAA01833; Tue, 21 Jan 2003 11:34:14 -0500 (EST) Message-ID: <3E2D7686.F5E7AC92@dma.isg.mot.com> Date: Tue, 21 Jan 2003 11:34:14 -0500 From: Dan Grossman X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Schoenwaelder CC: bwijnen@lucent.com, rap@ops.ietf.org, diffserv@ietf.org Subject: Re: [Diffserv] FlowId and FlowIdOrAny References: <7D5D48D2CAA3D84C813F5B154F43B155AA9B41@nl0006exch001u.nl.lucent.com> <200301211024.h0LAONtX026845@hansa.ibr.cs.tu-bs.de> 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 Um... since you're bringing the Diffserv folks into the middle of the conversation, would it be possible to clue us in as to what we're talking about? Thanks. Juergen Schoenwaelder wrote: > I changed the subject line and fixed the proposed TC. So here is where > I think we are. I have also reduced the CC list and I have added the > diffserv mailing list since diffserv folks should be in the loop I > think. > > FlowId TECTUAL-CONVENTION > DISPLAY-HINT "d" > STATUS current > DESCRIPTION > "The flow identifier in an IPv6 header that may be used to > discriminate traffic flows." > REFERENCE > "RFC 2460" > SYNTAX Integer32 (0..1048575) > > FlowIdOrAny TECTUAL-CONVENTION > DISPLAY-HINT "d" > STATUS current > DESCRIPTION > "The flow identifier in an IPv6 header that may be used to > discriminate traffic flows. The value of -1 is used to > indicate a wildcard, i.e. any value." > REFERENCE > "RFC 2460" > SYNTAX Integer32 (-1 | 0..1048575) > > Open issues: > > - Is the flow identifier the same as the flow label? I guess so. If > this is true, then we should probably use the TC names FlowLabel > and FlowLableOrAny and also change the wordings in the description > clause. > > - The name of the MIB modules which will contain these definitions. > > - Since Fred kind of said that the diffServMultiFieldClfrFlowId > object should have had a wildcard, can we agree that this is > actually a bug in RFC 3289 which will be fixed by using FlowIdOrAny > in the next revision of the DIFFSERV-MIB? > > /js > > -- > Juergen Schoenwaelder > > _______________________________________________ > 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 Tue Jan 21 12:37: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 MAA06341 for ; Tue, 21 Jan 2003 12:37:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0LHt6l03059 for diffserv-archive@odin.ietf.org; Tue, 21 Jan 2003 12:55:06 -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 h0LHe8J02106; Tue, 21 Jan 2003 12:40:08 -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 h0LHYIJ01169 for ; Tue, 21 Jan 2003 12:34:18 -0500 Received: from agitator.ibr.cs.tu-bs.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05615 for ; Tue, 21 Jan 2003 12:16:09 -0500 (EST) Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.6/8.12.6/Debian-6Woody) with ESMTP id h0LHJMgQ005254 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Tue, 21 Jan 2003 18:19:22 +0100 Received: from hansa.ibr.cs.tu-bs.de (schoenw@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) with ESMTP id h0LHJLAa004975 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Tue, 21 Jan 2003 18:19:22 +0100 Received: (from schoenw@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) id h0LHJL8Q004972; Tue, 21 Jan 2003 18:19:21 +0100 Date: Tue, 21 Jan 2003 18:19:21 +0100 Message-Id: <200301211719.h0LHJL8Q004972@hansa.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: dan@dma.isg.mot.com CC: bwijnen@lucent.com, rap@ops.ietf.org, diffserv@ietf.org In-reply-to: <3E2D7686.F5E7AC92@dma.isg.mot.com> (message from Dan Grossman on Tue, 21 Jan 2003 11:34:14 -0500) Subject: Re: [Diffserv] FlowId and FlowIdOrAny References: <7D5D48D2CAA3D84C813F5B154F43B155AA9B41@nl0006exch001u.nl.lucent.com> <200301211024.h0LAONtX026845@hansa.ibr.cs.tu-bs.de> <3E2D7686.F5E7AC92@dma.isg.mot.com> 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: , >>>>> Dan Grossman writes: Dan> Um... since you're bringing the Diffserv folks into the middle of Dan> the conversation, would it be possible to clue us in as to what Dan> we're talking about? Thanks. I can try - not sure I have the details right though since I joined late in this as well. I think the core of the story is that the FRAMEWORK-PIB currently defined in draft-ietf-rap-frameworkpib-09.txt has the following definition (in a generic filter): frwkIpFilterFlowId OBJECT-TYPE SYNTAX Unsigned32 (0..1048575) STATUS current DESCRIPTION "The flow identifier in an IPv6 header." ::= { frwkIpFilterEntry 7 } Someone observed that this definition does not have a value to indicate that this specific attribute is to be ignored when matching packets. So it was suggested to change the definition. Note that this document is sitting in 48 hour RFC review. Some people observed this and checked the classifier definition in the DIFFSERV-MIB. The DIFFSERV-MIB says: diffServMultiFieldClfrFlowId OBJECT-TYPE SYNTAX Unsigned32 (0..1048575) MAX-ACCESS read-create STATUS current DESCRIPTION "The flow identifier in an IPv6 header." ::= { diffServMultiFieldClfrEntry 8 } It looks like this definition as well lacks a wildcard mechanism. Fred Baker already wrote that he had one in mind but somehow if never got into the mind. Note that the DIFFSERV-MIB is in RFC 3289 (Proposed Standard). Triggered by a query from Kwok, I checked the INTEGRATED-SERVICES-MIB which has this definition: intSrvFlowFlowId OBJECT-TYPE SYNTAX INTEGER (0..16777215) MAX-ACCESS read-only STATUS current DESCRIPTION "The flow ID that this sender is using, if this is an IPv6 session." ::= { intSrvFlowEntry 11 } This is published in RFC 2213 (Proposed Standard). It would be nice to have common TCs in place for flow labels (or are they called flow ids?) much in the same way we have common TCs for DSCPs. And this is how we got to where we are (as far as I understand the situation). While we can't put common definitions in place while the ID is in 48 hours review, we hopefully can figure out a plan how we can address this proliferation of different ways to represent flow lables when documents are revised. /js -- Juergen Schoenwaelder _______________________________________________ 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 Jan 22 09:38: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 JAA25826 for ; Wed, 22 Jan 2003 09:38:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0MEuBN26385 for diffserv-archive@odin.ietf.org; Wed, 22 Jan 2003 09:56: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 h0MEikJ25808; Wed, 22 Jan 2003 09:44:47 -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 h0MEYeJ24820 for ; Wed, 22 Jan 2003 09:34:40 -0500 Received: from agitator.ibr.cs.tu-bs.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25381 for ; Wed, 22 Jan 2003 09:16:05 -0500 (EST) Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.6/8.12.6/Debian-6Woody) with ESMTP id h0MEJVgQ027229 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Wed, 22 Jan 2003 15:19:31 +0100 Received: from hansa.ibr.cs.tu-bs.de (schoenw@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) with ESMTP id h0MEJVAa022848 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Wed, 22 Jan 2003 15:19:31 +0100 Received: (from schoenw@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) id h0MEJSZG022843; Wed, 22 Jan 2003 15:19:28 +0100 Date: Wed, 22 Jan 2003 15:19:28 +0100 Message-Id: <200301221419.h0MEJSZG022843@hansa.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: rap@ops.ietf.org, diffserv@ietf.org In-reply-to: <200301211024.h0LAONtX026845@hansa.ibr.cs.tu-bs.de> (message from Juergen Schoenwaelder on Tue, 21 Jan 2003 11:24:23 +0100) References: <7D5D48D2CAA3D84C813F5B154F43B155AA9B41@nl0006exch001u.nl.lucent.com> <200301211024.h0LAONtX026845@hansa.ibr.cs.tu-bs.de> Subject: [Diffserv] Re: FlowId and FlowIdOrAny 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: , I found some more objects that seem to model a flow label. It turns out that MIB authors are really creative... draft-ietf-ipsp-ipsec-conf-mib-05.txt: ihfIPv6FlowLabel OBJECT-TYPE SYNTAX OCTET STRING (SIZE(3)) MAX-ACCESS read-create STATUS current DESCRIPTION "The IPv6 Flow Label that the packet must match against. This object is only used if ipv6FlowLabel is set in ihfType." ::= { ipHeaderFilterEntry 13 } They obviously have another mechanism to control whether the object participates in a match. draft-ietf-rmonmib-sspm-mib-06.txt: sspmSourceProfileFlowLabel OBJECT-TYPE SYNTAX Integer32 (0..1048575) -- 20-bit range (0 to 0xfffff) MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to specify the Flow Label in a IPv6 packet (RFC 2460) to force special handling by the IPv6 routers for non-default quality-of-service. This object is meaningful only when sspmSourceDestAddressType is ipv6(2). The value of this object defaults to zero if not set." DEFVAL { 0 } ::= { sspmSourceProfileEntry 7 } This object seems to actually control how the flow label looks like in packets coming from a synthetic traffic source. Note that these objects are called flow label rather than flowid and hence I did not find them the first time... /js -- Juergen Schoenwaelder _______________________________________________ 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 Jan 22 21:14:22 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 VAA13964 for ; Wed, 22 Jan 2003 21:14:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0N2WeM06432 for diffserv-archive@odin.ietf.org; Wed, 22 Jan 2003 21:32:40 -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 h0N2JUJ05817; Wed, 22 Jan 2003 21:19:30 -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 h0N28fJ05543 for ; Wed, 22 Jan 2003 21:08:41 -0500 Received: from auemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13639 for ; Wed, 22 Jan 2003 20:49:51 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0N1rGU09527 for ; Wed, 22 Jan 2003 20:53:16 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Jan 2003 02:53:15 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155BAE372@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Rap-wg (E-mail)" , Diffserv@ietf.org Date: Thu, 23 Jan 2003 02:51:55 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Diffserv] FW: FW: FlowId and FlowIdOrAny 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: , I checked with authors and WG chair of SSPM MIB I have a request outstanding to author(s) of ipsec-conf-mib Thanks, Bert -----Original Message----- From: Andy Bierman [mailto:abierman@cisco.com] Sent: woensdag 22 januari 2003 23:15 To: Wijnen, Bert (Bert) Cc: Dan Romascanu (E-mail); Carl Kalbfleisch (E-mail); Bob Cole (E-mail) Subject: Re: FW: FlowId and FlowIdOrAny At 04:31 PM 1/22/2003 +0100, Wijnen, Bert (Bert) wrote: >Are you following RAP or DIFFSERV WG mailing lists? I am on the diffserv list. Thanks for bringing this to our attention. To be consistent with previous decisions related to the DSMON MIB, the RMONMIB WG would prefer it if the WG owning IPv6 flow standards would publish a MIB module containing the appropriate TCs, so we can import them into the SSPM MIB. thanks, Andy >We are discussing a common set of TCs to be used by multiple >MIB and PIB modules. > >If your not up to date, you may want to check the mailing lists >archives. Discussion was over teh last week or two. > >Thanks, >Bert >p.s. I know I have this doc in AD review.... but you may >want to check this part of it yet > >-----Original Message----- >From: Juergen Schoenwaelder [mailto:schoenw@ibr.cs.tu-bs.de] >Sent: woensdag 22 januari 2003 15:19 >To: rap@ops.ietf.org; diffserv@ietf.org >Subject: Re: FlowId and FlowIdOrAny > > > >I found some more objects that seem to model a flow label. It turns >out that MIB authors are really creative... > >draft-ietf-ipsp-ipsec-conf-mib-05.txt: > > ihfIPv6FlowLabel OBJECT-TYPE > SYNTAX OCTET STRING (SIZE(3)) > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The IPv6 Flow Label that the packet must match against. > This object is only used if ipv6FlowLabel is set in ihfType." > ::= { ipHeaderFilterEntry 13 } > > They obviously have another mechanism to control whether the > object participates in a match. > >draft-ietf-rmonmib-sspm-mib-06.txt: > > sspmSourceProfileFlowLabel OBJECT-TYPE > SYNTAX Integer32 (0..1048575) -- 20-bit range (0 to 0xfffff) > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "This object is used to specify the Flow Label in a IPv6 > packet (RFC 2460) to force special handling by the IPv6 routers for > non-default quality-of-service. > > This object is meaningful only when sspmSourceDestAddressType is > ipv6(2). The value of this object defaults to zero if not > set." > DEFVAL { 0 } > ::= { sspmSourceProfileEntry 7 } > > This object seems to actually control how the flow label looks like > in packets coming from a synthetic traffic source. > >Note that these objects are called flow label rather than flowid and >hence I did not find them the first time... > >/js > >-- >Juergen Schoenwaelder _______________________________________________ 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 Jan 27 17:17:22 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 RAA28971 for ; Mon, 27 Jan 2003 17:17:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0RMc0i23105 for diffserv-archive@odin.ietf.org; Mon, 27 Jan 2003 17:38:00 -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 h0RMGlJ21626; Mon, 27 Jan 2003 17:16:47 -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 h0RM78J20867 for ; Mon, 27 Jan 2003 17:07:08 -0500 Received: from hoemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28092 for ; Mon, 27 Jan 2003 16:45:59 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0RLnS600325 for ; Mon, 27 Jan 2003 16:49:28 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 27 Jan 2003 22:49:27 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155C82FA4@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Rap-wg (E-mail)" , Diffserv@ietf.org Date: Mon, 27 Jan 2003 22:49:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Diffserv] RE: FW: FlowId and FlowIdOrAny 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: , I am not hearing much progress. Appology for a long email posting. But I think it addresses all the issues and occurences of flowId or flowLabel (at least till someone tells me they found yet another one ;-)) The biggest problem exists for the RAP WG document for the framework PIB, cause it is in RFC 48-hour author call (for over a month already). The DIFFSERV PIB (also in RFC 38-hour author call for the same amount of time) of course cannot be published since it depends on the framework pib. The issue at hand is the question on how to specify that a flowID be ignored (wild-carded) for a filter. I think we've come to the conclusion that both the MIB and the PIB solutions need this. So we need a common solution. We've also found 3 other places where a flowID or a flowLabel (but the same thing is meant) is being used. That is in: - draft-ietf-ipsp-ipsec-conf-mib-05.txt which uses a 3-byte octet string and that seems wrong SYNTAX OCTET STRING (SIZE(3)) - draft-ietf-rmonmib-sspm-mib-06.txt which uses an Integer32: SYNTAX Integer32 (0..1048575) -- 20-bit range (0 to 0xfffff) - Integrated services MIB (RFC 2213) which uses INTEGER SYNTAX INTEGER (0..16777215) The Diffserv MIB (RFC3289) and the framework PIB were using an Unsigned 32, namely SYNTAX Unsigned32 (0..1048575) The framework PIB authors were suggesting a modification SYNTAX Unsigned32 (4294967295 | 0..1048575) So that the value 4294967295 would mean any (in other words one would ignore the flowID in when filtering). Fred (amin editor of the Diffserv MIB) wanted to add a boolean mib object to indicate if the flowID should be ignored when filtering. What I as OPS AD for the NM side see is that we have - too many different ways to represent a flowID or flowLabel. - there is currently no way to define a flowID or any - we need need a facility to specify flowIdOrAny. - we prefer to have one solution. - we have some docs that are still IDs and can easily be changed. - we have two docs that are difficult to change, namely the DIFSERV and the INTEGRATED SERVICES MIB. The difficulty is that if we change the encoding on the wire that we need to deprecate existing object and add a new one. If we keep the wire encoding the same, I think we can defend that it is a bug fix and the fact that some potential new values are now valid is acceptable; at least it would be less of a problem than having to deprecate an object and add a new one. - But even the two RFCs have different SYNTAX, so at least one of them needs to change if we want to specify flowID in a consistent way. So what do people want to do. My proposal is to do the following: - Someone creates a new ID that contains a small MIB module that contains two TCs: FlowId TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The flow identifier or flow Label in an IPv6 header that may be used to discriminate traffic flows. " SYNTAX Integer32 (0..1048575) FlowIdOrAny TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The flow identifier or flow lable in an IPv6 header that may be used to discriminate traffic flows. The value of -1 is used to indicate a wildcard, i.e. any value. " SYNTAX Integer32 (-1 | 0..1048575) We probably want to run this quickly by the IPv6 WG. What it would mean for the various documents is the following: - For the INTEGRATED-SERVICES-MIB (RFC2213), I see Fred as a co-author/editor..., whenever a new revision is done: - import the new FlowId TC - replace intSrvFlowFlowId OBJECT-TYPE SYNTAX INTEGER (0..16777215) with intSrvFlowFlowId OBJECT-TYPE SYNTAX FlowId I think we can consider this a BUG fix and allow this change that reduces the range of possible values. - by the way, I when I see intSrvFlowIfAddr, then probably we would want that to be done with the TCs from the INET-ADDRESS-MIB. I also wonder about the Port TC in that module - For the DIFFSERV-MIB (RFC3289), Fred is main editor, whenever a new revision is done, I think we need to: - import the new FlowIdOrAny TC - deprecate object diffServMultiFieldClfrFlowId - define a new object diffServMultiFieldClfrFlowLabel ?? or maybe diffServMultiFieldClfrFlowIdOrAny with syntax FlowIdOrAny - deprecate current MODULE-COMPLIANCEs, define a new one to remove ... FlowId and add ...FlowLable - For the draft-ietf-rap-frameworkpib-09.txt (or better the RFC-to-be) the final fix would be to make this change: - import FlowIdOrAny TC - replace frwkIpFilterFlowId OBJECT-TYPE SYNTAX Unsigned32 (0..1048575) with frwkIpFilterFlowId OBJECT-TYPE SYNTAX FlowIdOrAny - we can consider this as a last minute bug fix. If we agree that the final change may take too long, then we can make a temp fix: - replace frwkIpFilterFlowId OBJECT-TYPE SYNTAX Unsigned32 (0..1048575) with frwkIpFilterFlowId OBJECT-TYPE SYNTAX Integer32 (-1 | 0..1048575) DESCRIPTION "The flow identifier or flow lable in an IPv6 header that may be used to discriminate traffic flows. The value of -1 is used to indicate a wildcard, i.e. any value. " - whenever the RFC gets revised, then this can be replaced with the final fix, cause it does not change anything on the wire. - For draft-ietf-ipsp-ipsec-conf-mib-05.txt, main Editor Wes Hardaker, we can fix it as follows - import FlowId - replace ihfIPv6FlowLabel OBJECT-TYPE SYNTAX OCTET STRING (SIZE(3)) with ihfIPv6FlowLabel OBJECT-TYPE SYNTAX FlowId - this is still an ID, so the change is OK. Also, they use a BITS mask to indicate if the flowlabel must be ignored or not. So this works. It is a bit different than it is done in diffserv mib and framework pib, but at least it uses the same spec for FlowId. (or flowLabel) - for draft-ietf-rmonmib-sspm-mib-06.txt, not sure who is main editor it would mean - import FlowId - replace sspmSourceProfileFlowLabel OBJECT-TYPE SYNTAX Integer32 (0..1048575) -- 20-bit range (0 to 0xfffff) with sspmSourceProfileFlowLabel OBJECT-TYPE SYNTAX FlowId - this is still an ID, so the change is OK 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 Mon Jan 27 18:22:49 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 SAA00647 for ; Mon, 27 Jan 2003 18:22:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0RNhTs26736 for diffserv-archive@odin.ietf.org; Mon, 27 Jan 2003 18:43: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 h0RNXtJ25688; Mon, 27 Jan 2003 18:33: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 h0RNSPJ25484 for ; Mon, 27 Jan 2003 18:28:25 -0500 Received: from bastion.arraycomm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00289 for ; Mon, 27 Jan 2003 18:07:13 -0500 (EST) Received: from lester.arraycomm.com (lester.arraycomm.com [172.16.0.17]) by bastion.arraycomm.com (Postfix) with ESMTP id 6F8495E11A; Mon, 27 Jan 2003 15:10:43 -0800 (PST) Received: from ARRAYCOMM.COM (vclient-16.arraycomm.com [192.168.10.16]) by lester.arraycomm.com (8.12.6/8.12.6) with ESMTP id h0RNAfhK001845 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 27 Jan 2003 15:10:41 -0800 (PST) Message-Id: <200301272310.h0RNAfhK001845@lester.arraycomm.com> From: Branislav Meandzija To: "Wijnen, Bert (Bert)" , "Rap-wg (E-mail)" , Diffserv@ietf.org Subject: RE: [Diffserv] RE: FW: FlowId and FlowIdOrAny Date: Mon, 27 Jan 2003 15:10:17 -0800 X-Mailer: CorporateTime Outlook Connector 3.3 40513 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Filter-Version: 1.9 (lester) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0RNSPJ25485 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 Procedurally, very complex fix for something very simple but it seems the best possible one. Branislav > > My proposal is to do the following: > > - Someone creates a new ID that contains a small MIB module > that contains two TCs: > > FlowId TEXTUAL-CONVENTION > DISPLAY-HINT "d" > STATUS current > DESCRIPTION "The flow identifier or flow Label in an IPv6 > header that may be used to discriminate traffic > flows. > " > SYNTAX Integer32 (0..1048575) > > FlowIdOrAny TEXTUAL-CONVENTION > DISPLAY-HINT "d" > STATUS current > DESCRIPTION "The flow identifier or flow lable in an IPv6 > header that may be used to discriminate traffic > flows. The value of -1 is used to indicate a > wildcard, i.e. any value. > " > SYNTAX Integer32 (-1 | 0..1048575) _______________________________________________ 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 Tue Jan 28 07:52:35 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 HAA24321 for ; Tue, 28 Jan 2003 07:52:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SDDWD17869 for diffserv-archive@odin.ietf.org; Tue, 28 Jan 2003 08:13: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 h0SD4sJ16876; Tue, 28 Jan 2003 08:04: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 h0SCwhJ16658 for ; Tue, 28 Jan 2003 07:58:43 -0500 Received: from d12lmsgate-2.de.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23779 for ; Tue, 28 Jan 2003 07:37:13 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id h0SCegXf072710; Tue, 28 Jan 2003 13:40:43 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id h0SCefnr138850; Tue, 28 Jan 2003 13:40:42 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA26724 from ; Tue, 28 Jan 2003 13:40:40 +0100 Message-Id: <3E367A1D.C5CFC087@hursley.ibm.com> Date: Tue, 28 Jan 2003 13:39:57 +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: "Wijnen, Bert (Bert)" Cc: "Rap-wg (E-mail)" , Diffserv@ietf.org Subject: Re: [Diffserv] RE: FW: FlowId and FlowIdOrAny References: <7D5D48D2CAA3D84C813F5B154F43B155C82FA4@nl0006exch001u.nl.lucent.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 Bert, I'm not too distressed if we have to update the diffserv MIB; there isn't evidence of widespread deployment yet, so I think it's better to do it quickly. I agree that a common solution is desirable. The basic definition of the flow label still hasn't reached last call in the IPv6 WG (I am a co-author of that draft). So I don't think you could run your mini-MIB proposal past the WG "quickly", until the flow label has been through last call. Brian "Wijnen, Bert (Bert)" wrote: > > I am not hearing much progress. > > Appology for a long email posting. But I think it > addresses all the issues and occurences of flowId > or flowLabel (at least till someone tells me they > found yet another one ;-)) > > The biggest problem exists for the RAP WG document > for the framework PIB, cause it is in RFC 48-hour > author call (for over a month already). > > The DIFFSERV PIB (also in RFC 38-hour author call > for the same amount of time) of course cannot be > published since it depends on the framework pib. > > The issue at hand is the question on how to specify > that a flowID be ignored (wild-carded) for a filter. > I think we've come to the conclusion that both the > MIB and the PIB solutions need this. So we need > a common solution. > > We've also found 3 other places where a flowID > or a flowLabel (but the same thing is meant) is > being used. That is in: > > - draft-ietf-ipsp-ipsec-conf-mib-05.txt > which uses a 3-byte octet string and that seems wrong > SYNTAX OCTET STRING (SIZE(3)) > > - draft-ietf-rmonmib-sspm-mib-06.txt > which uses an Integer32: > SYNTAX Integer32 (0..1048575) -- 20-bit range (0 to 0xfffff) > > - Integrated services MIB (RFC 2213) > which uses INTEGER > SYNTAX INTEGER (0..16777215) > > The Diffserv MIB (RFC3289) and the framework PIB were > using an Unsigned 32, namely > SYNTAX Unsigned32 (0..1048575) > > The framework PIB authors were suggesting a modification > SYNTAX Unsigned32 (4294967295 | 0..1048575) > So that the value 4294967295 would mean any (in other words > one would ignore the flowID in when filtering). > > Fred (amin editor of the Diffserv MIB) wanted to add a > boolean mib object to indicate if the flowID should be > ignored when filtering. > > What I as OPS AD for the NM side see is that we have > - too many different ways to represent a flowID or flowLabel. > - there is currently no way to define a flowID or any > - we need need a facility to specify flowIdOrAny. > - we prefer to have one solution. > - we have some docs that are still IDs and can easily > be changed. > - we have two docs that are difficult to change, namely > the DIFSERV and the INTEGRATED SERVICES MIB. > The difficulty is that if we change the encoding on the > wire that we need to deprecate existing object and add > a new one. If we keep the wire encoding the same, I think > we can defend that it is a bug fix and the fact that some > potential new values are now valid is acceptable; at least > it would be less of a problem than having to deprecate > an object and add a new one. > - But even the two RFCs have different SYNTAX, so at least > one of them needs to change if we want to specify > flowID in a consistent way. > > So what do people want to do. > > My proposal is to do the following: > > - Someone creates a new ID that contains a small MIB module > that contains two TCs: > > FlowId TEXTUAL-CONVENTION > DISPLAY-HINT "d" > STATUS current > DESCRIPTION "The flow identifier or flow Label in an IPv6 > header that may be used to discriminate traffic > flows. > " > SYNTAX Integer32 (0..1048575) > > FlowIdOrAny TEXTUAL-CONVENTION > DISPLAY-HINT "d" > STATUS current > DESCRIPTION "The flow identifier or flow lable in an IPv6 > header that may be used to discriminate traffic > flows. The value of -1 is used to indicate a > wildcard, i.e. any value. > " > SYNTAX Integer32 (-1 | 0..1048575) > > We probably want to run this quickly by the IPv6 WG. > > What it would mean for the various documents is the following: > > - For the INTEGRATED-SERVICES-MIB (RFC2213), I see Fred as a > co-author/editor..., whenever a new revision is done: > - import the new FlowId TC > - replace > intSrvFlowFlowId OBJECT-TYPE > SYNTAX INTEGER (0..16777215) > with > intSrvFlowFlowId OBJECT-TYPE > SYNTAX FlowId > I think we can consider this a BUG fix and allow this change > that reduces the range of possible values. > - by the way, I when I see intSrvFlowIfAddr, then probably > we would want that to be done with the TCs from the > INET-ADDRESS-MIB. I also wonder about the Port TC in that > module > > - For the DIFFSERV-MIB (RFC3289), Fred is main editor, whenever > a new revision is done, I think we need to: > - import the new FlowIdOrAny TC > - deprecate object diffServMultiFieldClfrFlowId > - define a new object diffServMultiFieldClfrFlowLabel ?? > or maybe diffServMultiFieldClfrFlowIdOrAny > with syntax FlowIdOrAny > - deprecate current MODULE-COMPLIANCEs, define a new one > to remove ... FlowId and add ...FlowLable > > - For the draft-ietf-rap-frameworkpib-09.txt (or better the > RFC-to-be) the final fix would be to make this change: > - import FlowIdOrAny TC > - replace > frwkIpFilterFlowId OBJECT-TYPE > SYNTAX Unsigned32 (0..1048575) > with > frwkIpFilterFlowId OBJECT-TYPE > SYNTAX FlowIdOrAny > - we can consider this as a last minute bug fix. > If we agree that the final change may take too long, then we > can make a temp fix: > - replace > frwkIpFilterFlowId OBJECT-TYPE > SYNTAX Unsigned32 (0..1048575) > with > frwkIpFilterFlowId OBJECT-TYPE > SYNTAX Integer32 (-1 | 0..1048575) > DESCRIPTION "The flow identifier or flow lable in an IPv6 > header that may be used to discriminate traffic > flows. The value of -1 is used to indicate a > wildcard, i.e. any value. > " > - whenever the RFC gets revised, then this can be replaced > with the final fix, cause it does not change anything on the wire. > > - For draft-ietf-ipsp-ipsec-conf-mib-05.txt, main Editor > Wes Hardaker, we can fix it as follows > - import FlowId > - replace > ihfIPv6FlowLabel OBJECT-TYPE > SYNTAX OCTET STRING (SIZE(3)) > with > ihfIPv6FlowLabel OBJECT-TYPE > SYNTAX FlowId > - this is still an ID, so the change is OK. > Also, they use a BITS mask to indicate if the flowlabel > must be ignored or not. So this works. It is a bit different > than it is done in diffserv mib and framework pib, but at least > it uses the same spec for FlowId. (or flowLabel) > > - for draft-ietf-rmonmib-sspm-mib-06.txt, not sure who is main editor > it would mean > - import FlowId > - replace > sspmSourceProfileFlowLabel OBJECT-TYPE > SYNTAX Integer32 (0..1048575) -- 20-bit range (0 to 0xfffff) > with > sspmSourceProfileFlowLabel OBJECT-TYPE > SYNTAX FlowId > - this is still an ID, so the change is OK > > 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 -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 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 Fri Jan 31 08:39:49 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 IAA06116 for ; Fri, 31 Jan 2003 08:39:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0VDhK826615 for diffserv-archive@odin.ietf.org; Fri, 31 Jan 2003 08:43:20 -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 h0VDYJJ25570; Fri, 31 Jan 2003 08:34:19 -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 h0V5DlJ22804 for ; Fri, 31 Jan 2003 00:13:47 -0500 Received: from shell4.bayarea.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19196 for ; Fri, 31 Jan 2003 00:09:53 -0500 (EST) Received: from localhost (heard@localhost) by shell4.bayarea.net (8.9.3/8.9.3) with ESMTP id VAA11784; Thu, 30 Jan 2003 21:13:23 -0800 (envelope-from heard@pobox.com) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Thu, 30 Jan 2003 21:13:22 -0800 (PST) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: ipng@sunroof.eng.sun.com In-Reply-To: <5.1.0.14.2.20030116160908.03179010@mail.windriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Diffserv] Re: IPv6 w.g. Last Call on "IP Forwarding Table MIB" (1/2) 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: , [ Note: mibs@ops.ietf.org and diffserv@ietf.org have been bcc'd. Please direct followup discussion to ipng@sunroof.eng.sun.com ] On Thu, 16 Jan 2003, Bob Hinden wrote: > This is a IPv6 working group last call for comments on advancing the > following document as a Proposed Standard: > > Title : IP Forwarding Table MIB > Author(s) : M. Wasserman > Filename : draft-ietf-ipv6-rfc2096-update-02.txt > Pages : 30 > Date : 2002-11-7 > > Please send substantive comments to the ipng mailing list, and minor > editorial comments to the document editor. This last call period will > end on January 30, 2003. Thanks to Margaret Wasserman and Bob Hinden for forwarding this last-call notice to the mibs@ops.ietf.org mailing list. There are three major issues upon which I would like to comment in this message. Minor comments (documentation nits and mib-doctor stuff) will be dealt with in a separate message. The major technical issues are these: 1.) Appropriateness of using DSCP (differentiated services code point) as a forwarding table index. 2.) Appropriateness of offering only a full compliance statement when all reported implementations of the predecessor MIB (RFC 2096) provide just read-only access. 3.) MIB changes that appear either to be gratuitous (replacing ipRouteDiscards with inetCidrRouteDiscards) or erroneous (not providing inetCidrRouteNumber) and which are inconsistent with the text of Section 8. Issue #1: Appropriateness of using DSCP as forwarding table index --------- ------------------------------------------------------- Synopsis: I question the appropriateness of using the DSCP field to represent routing policy, and I recommend replacing the inetCidrRouteDscp object with a more generic inetCidrRoutePolicy object. I suggest that its SYNTAX be OBJECT IDENTIFIER for ease of administration, but an integer-valued object could in principle be made to serve the purpose. Discussion: in order to exhibit the proposed index structure for the inetCidrRouteTable and to compare it with that of the ipCidrRouteTable which it replaces, it is helpful to reproduce the definition of inetCidrRouteEntry: inetCidrRouteEntry OBJECT-TYPE SYNTAX InetCidrRouteEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A particular route to a particular destination, under a particular policy." INDEX { inetCidrRouteDestType, inetCidrRouteDest, inetCidrRoutePfxLen, inetCidrRouteDscp, inetCidrRouteNextHopType, inetCidrRouteNextHop } ::= { inetCidrRouteTable 1 } This is intended to replace ipCidrRouteEntry, whose definition is: ipCidrRouteEntry OBJECT-TYPE SYNTAX IpCidrRouteEntry ACCESS not-accessible STATUS current DESCRIPTION "A particular route to a particular destina- tion, under a particular policy." INDEX { ipCidrRouteDest, ipCidrRouteMask, ipCidrRouteTos, ipCidrRouteNextHop } ::= { ipCidrRouteTable 1 } The intended mapping is clear: ipCidrRouteDest -> ipCidrRouteMask -> inetCidrRoutePfxLen ipCidrRouteTos -> inetCidrRouteDscp ipCidrRouteNextHop -> It is obvious that ipCidrRouteDest, ipCidrRouteMask, and ipCidrRouteNextHop are being replaced with generalized objects that carry equivalent semantics but accomodate both IPv4 and IPv6 addresses, and I have no issue with that. The replacement objects are indeed the "minimal change" replacements that they were intended to be. However, I do NOT think that inetCidrRouteDscp can be considered a semantic equivalent to ipCidrRouteTos. What ipCidrRouteTos represented was the now-deprecated 4-bit Type of Service field, i.e., the DTRC bits (bits 3-6 of the TOS octet) defined in RFC 791 and RFC 1349. Note that it _excludes_ the three-bit Precedence field (bits 0-2 of the TOS octet). The TOS field had special support in routing protocols, notably early versions of OSPF, and was specifically intended to be used as a route selector. The Precedence field, however, had no such role. Now, if I correctly understand what I have read in RFC 2474 Section 4, the role played by the DSCP field is a generalization of that the Precedence field and maintains some backward compatibility with it, but it is in no sense analogous to the old TOS field (DTRC bits). For this reason inetCidrRouteDscp does not qualify as a "minimal change" replacement for ipCidrRouteTos. The next question to ask is whether inetCidrRouteDscp would, in fact, be sufficiently useful in the general case to merit its inclusion as an index in the inetCidrRouteTable. I'm inclined to think that it does not. RFC 3290, Diffserv Informal Management Model, says this: The routing core moves packets between interfaces according to policies outside the scope of Diffserv (note: it is possible that such policies for output-interface selection might involve use of packet fields such as the DSCP but this is outside the scope of this model). In other words, the DSCP field _might_ be used as _one_ of the criteria for choosing a next hop interface, but there is no explicit specification of a privileged role for it in route selection policy (in sharp contrast to the old TOS field). Last October the following message appeared in the thread "[ipv6mib] So, where were we?" that seems to suggest a much better alternative: On Wed, 9 Oct 2002, Dave Thaler wrote: > The intermediate solution previously discussed by the ipv6mib > design team was to add an instance number to the INDEX, > and have separate mapping tables describe how to interpret > (or map to) the instance number. Such mapping tables could > be part of the same MIB, or part of a proprietary MIB > (or both). This is the solution I prefer, modulo my response > to Margaret's next suggestion below, since it entails only > a small change from 2096 (just replace TOS field with a more > generic instance number). I see in the change log that an inetCidrRouteInstance object used to exist but was removed 27 Jun 2002 on the grounds that it was "obviated by new InetAddress types and inclusion of DSCP index object". It was not a bad idea to reinstate the InetAddress (and InetAddressType) objects, but I think that including the DSCP object was a mistake, and that it should be replaced with a more generic object, per Mr. Thaler's suggestion above. Its name should probably be inetCidrRoutePolicy, and it should either be a generic intger-valued object, with a definition along the lines of the (now-obsolete) ipForwardPolicy object, or else an OBJECT IDENTIFIER object. The tradeoff is basically one of ease of administration versus implementation complexity. Since one of the stated objectives of this effort is to get something quickly that can be extended later, I would suggest the OBJECT IDENTIFIER approach; it does not require central administration, and allows proprietary policies to be represented if one so desires. A first cut at a definition might be: inetCidrRoutePolicy OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS not-accessible STATUS current DESCRIPTION "Represents the general set of conditions that would cause the selection of one multipath route (set of next hops for a given destination) over another (referred to as 'policy'). The value { 0 0 } shall be used for the the default policy or if no particular policy applies." ::= { inetCidrRouteEntry 4 } Now, when inetCidrRouteDest and inetCidrRouteNextHop represent IPv6z addresses, they have a maximum length of 20 octets, and smilint tells me that inetCidrRoutePolicy could then have up to 71 components before the limit of 128 sub-identifiers for instance OIDs is reached. So I don't think that the length would be an issue (one might, however, wish to re-think the current size cap of 36 octets for inetCidrRouteDest and inetCidrRouteNextHop). Note that one could accomodate both TOS and DSCP based routing policies in this scheme by defining an OID prefix (e.g., via an OBJECT-IDENTITY invocation) and appending the TOS or DSCP value as the last sub-identifier. But much more general schemes could be dealt with as well, and they could be defined later, when the issues are better understood. My recommendation would actually be to NOT define any schemes other than "default", which would use the null OID { 0 0 }; since the ipCidrTos is zero in almost all implementations (otherwise we would not have had DSCPs in the first place), that would probably accomodate all important uses of the ipCidrRouteTable. Issue #2: Appropriateness of offering only a "full" compliance --------- ---------------------------------------------------- Synopsis: previous discussions revealed no knowledge of read-write implementations of the ipCidrRouteTable. I don't see that there is any reason to believe that the inetCidrRouteTable won't have the same fate, so I suggest that we "take the hint" and write a compliance statement that allows read-only access and subsetting of the InetAddressType variables to whatever flavors of IP the implementation actually supports (since these are indices, that has to be done via DESCRIPTION clauses). Discussion: Last October the following message appeared in the e-mail thread "[ipv6mib] So, where were we?", and it gives a hint as to how the ipCidrRouteTable is actually implemented in practice: On Wed, 9 Oct 2002, Brian Haberman wrote: > Margaret Wasserman wrote: > > > > Yes, but none of this really gets us closer to an answer to the > > really important questions: > > > > - Do people actually implement RFC 2096 today? > > - If so, are the implementations writable? > > > > [I personally know of several implementations of RFC 2096, but > > none of them are writable.] > > I do not know any that are writable either. > > > > > - Does anyone actually use RFC 2096 to manage, > > monitor, configure or debug a box? > > - If so, how and for what? > > From what I have been able to gather, no one with a "large" route > table ever uses 2096 to pull it down. This seems to be for > various reasons[0]. > > Some admins will query the table for specific routes to ensure > they exist. This is done during problem determination mode. As it happens, I have implemented the ipCidrRouteTable on a small end system, and I, too, chose to make it read-only. Its only real use on that system was for inspecting the route cache, and it certainly was not worth the very considerable effort that it would have taken to implement the machinery necessary to support add/delete/modify of route cache entries with SNMP. I strongly suspect that the same thing will be true of a fair number of implementations of the new inetCidrRouteTable; certainly, I see no reason for believing that the situation will be different than it was for the ipCidrRouteTable. Nonetheless, the compliance statements as written render a read-only implementation non-conformant, and because there are no provisions in the index column DESCRIPTION clauses that allow an implementation to support only a subset of the InetAddressType values, a full read-create implementation would technically have to support all possible address types. The suggested remedy is to add OBJECT clauses to the ipForwardCompliance2 statement that permit MIN-ACCESS of read-only to all columnar objects and a SYNTAX of INTEGER { active(1) } for the status column, or alternatively to rename the existing compliance to inetCidrFullCompliance and add an inetCidrReadOnlyCompliance that has the same effect. In either case the DESCRIPTION clauses of the InetAddressType index index objects need to make clear that an implementation need only allow values appropriate to the protocols it supports. Issue #3: Gratuitous/Erroneous MIB changes not consistent with text --------- --------------------------------------------------------- Synopsis: the object inetCidrRouteDiscards should be removed since ipRoutingDiscards (which dates back to MIB-II) already exists in the IP-MIB and does the same job. An object inetCidrRouteNumber, analogous to ipCidrRouteNumber, should be added (or reinstated). The text in Section 8 describing inetCidrRouteNumber should stay; the text in Section 8 describing inetCidrRouteDiscards should be removed (or, possibly, replaced with a mention of ipRouteDiscards). Discussion: the following object from the IP-MIB (RFC 2011) and MIB-II (RFC 1213) ipRoutingDiscards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of routing entries which were chosen to be discarded even though they are valid. One possible reason for discarding such an entry could be to free-up buffer space for other routing entries." ::= { ip 23 } provides _exactly_ the same functionality as the following object that (according to the change log) was added on 12 Jul 2001 to replace it: inetCidrRouteDiscards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of routing entries which were chosen to be discarded even though they are valid. One possible reason for discarding such an entry could be to free-up buffer space for other routing entries." ::= { ipForward 8 } Defining a new object with semantics identical to an old one is clearly an unnecessary change. Therefore, inetCidrRouteDiscards should be removed, and so should the following paragraph in Section 8: 2. The object inetCidrRouteDiscards counts the number of valid routes that were discarded for any reason. On the other hand, the following paragraph in Section 8 1. The object inetCidrRouteNumber indicates the number of current routes. This is primarily to avoid having to read the table in order to determine this number. refers to an object that does not exist. According to the change log, it was removed on 02 Nov 2002. Possibly this was an editing error and inetCidrRouteDiscards was supposed to have been removed instead; in any case, inetCidrRouteNumber should be added (or reinstated) because it would be useful and there is no equivalent object elsewhere. I would suggest registering it as { ipForward 7 } so that there are no gaps in the OID assignments to trip up the next maintainer. //cmh _______________________________________________ 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