From diffserv-admin@ietf.org Tue Jul 3 09:38:49 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA04544 for ; Tue, 3 Jul 2001 09:38:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA05751; Tue, 3 Jul 2001 08:58:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29995 for ; Mon, 2 Jul 2001 17:35:17 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29819 for ; Mon, 2 Jul 2001 17:34:33 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id WAA29028 for ; Mon, 2 Jul 2001 22:34:44 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id WAA69418 for ; Mon, 2 Jul 2001 22:34:43 +0100 Message-ID: <3B40E916.5B43588C@hursley.ibm.com> Date: Mon, 02 Jul 2001 16:35:18 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Diff Serv References: <200107021850.OAA15894@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Re: Last Call: An Expedited Forwarding PHB to Proposed Standard Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I must explain to the diffserv list that there was a bug in the recent WG last call on this: I mistyped "Draft Standard" instead of "Proposed Standard". This was my error, which nobody noticed during the WG last call. Sorry about the confusion. Brian The IESG wrote: > > The IESG has received a request from the Differentiated Services > Working Group to consider An Expedited Forwarding PHB > as a Proposed Standard. > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by July 16, 2001. > > Files can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-diffserv-rfc2598bis-01.txt _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Jul 3 09:39:02 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA04695 for ; Tue, 3 Jul 2001 09:39:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA05775; Tue, 3 Jul 2001 08:58:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24363 for ; Mon, 2 Jul 2001 14:51:06 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15894; Mon, 2 Jul 2001 14:50:22 -0400 (EDT) Message-Id: <200107021850.OAA15894@ietf.org> To: IETF-Announce: ; Cc: diffserv@ietf.org From: The IESG Reply-to: iesg@ietf.org Date: Mon, 02 Jul 2001 14:50:22 -0400 Subject: [Diffserv] Last Call: An Expedited Forwarding PHB to Proposed Standard Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org The IESG has received a request from the Differentiated Services Working Group to consider An Expedited Forwarding PHB as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by July 16, 2001. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-diffserv-rfc2598bis-01.txt _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Jul 12 03:21:03 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA07784 for ; Thu, 12 Jul 2001 03:21:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA06250; Thu, 12 Jul 2001 02:39:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA06220 for ; Thu, 12 Jul 2001 02:39:19 -0400 (EDT) Received: from web8101.in.yahoo.com (web8101.in.yahoo.com [203.199.70.28]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA03179 for ; Thu, 12 Jul 2001 02:38:29 -0400 (EDT) Message-ID: <20010712063848.17814.qmail@web8101.in.yahoo.com> Received: from [130.18.65.67] by web8101.in.yahoo.com via HTTP; Wed, 11 Jul 2001 23:38:48 PDT Date: Wed, 11 Jul 2001 23:38:48 -0700 (PDT) From: Christina Krishna To: diffserv@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Diffserv] per-flow qos Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org hi all, Can any one suggest me pointers to works on "per-flow" QoS provisioning in a diffserv network? Much work is done on per-aggregate QoS in diffserv network, but i need information on per-flow qos in difserv. I have one paper titled "Attaining per-flow QoS with class-based differentiated services" by M.Tufail, G.Jennes, G.Leduc, SPIE symposium on Voice, video and data communications, Conf: Broadband network, Sept 1999, MA, USA. Does any one have pointers to other works in this field? thanks in advance. ck. __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Jul 12 09:57:08 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA23469 for ; Thu, 12 Jul 2001 09:57:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15717; Thu, 12 Jul 2001 09:18:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15682 for ; Thu, 12 Jul 2001 09:17:56 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18175 for ; Thu, 12 Jul 2001 09:17:05 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id OAA19074; Thu, 12 Jul 2001 14:17:23 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id OAA60722; Thu, 12 Jul 2001 14:17:21 +0100 Message-ID: <3B4DA362.7541C905@hursley.ibm.com> Date: Thu, 12 Jul 2001 08:17:22 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Christina Krishna CC: diffserv@ietf.org Subject: Re: [Diffserv] per-flow qos References: <20010712063848.17814.qmail@web8101.in.yahoo.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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Diffserv is not a per-flow model, so any such work is in any case rather strange. Please take questions of this kind to the diffserv-interest mailing list, since they are outside the charter of this WG: > To post to this list, send your email to: > > diffserv-interest@ietf.org > > To join the list, go to > > http://www.ietf.org/mailman/listinfo/diffserv-interest > > or send a message to: > > diffserv-interest-request@ietf.org > > with the word `help' in the subject or body (don't include the > quotes), and you will get back a message with instructions. > > Thanks to the friendly staff at ietf.org for setting this up. Please use it for > non-standards discussions. There is also the diffserv implementation list at > > http://www.atnf.csiro.au/news/exploders/dsimplementation.html > Brian Carpenter diffserv WG co-chair Christina Krishna wrote: > > hi all, > Can any one suggest me pointers to works on "per-flow" > QoS provisioning in a diffserv network? Much work is > done on per-aggregate QoS in diffserv network, but i > need information on per-flow qos in difserv. > > I have one paper titled "Attaining per-flow QoS with > class-based differentiated services" by M.Tufail, > G.Jennes, G.Leduc, SPIE symposium on Voice, video and > data communications, Conf: Broadband network, Sept > 1999, MA, USA. > > Does any one have pointers to other works in this > field? > > thanks in advance. > ck. > > __________________________________________________ > Do You Yahoo!? > Get personalized email addresses from Yahoo! Mail > http://personal.mail.yahoo.com/ > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org "We shall need a number of efficient librarian types to keep us in order." - Alan Turing, 1947. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Jul 16 09:09:16 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03844 for ; Mon, 16 Jul 2001 09:09:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06253; Mon, 16 Jul 2001 08:30:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28136 for ; Thu, 12 Jul 2001 16:38:49 -0400 (EDT) Received: from usc.edu (root@usc.edu [128.125.253.136]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20607 for ; Thu, 12 Jul 2001 16:37:59 -0400 (EDT) Received: from aludra.usc.edu (demir@aludra.usc.edu [128.125.253.184]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id NAA00827; Thu, 12 Jul 2001 13:38:22 -0700 (PDT) Received: from localhost (demir@localhost) by aludra.usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id NAA03988; Thu, 12 Jul 2001 13:38:21 -0700 (PDT) Date: Thu, 12 Jul 2001 13:38:21 -0700 (PDT) From: demir To: Brian E Carpenter cc: Christina Krishna , diffserv@ietf.org Subject: Re: [Diffserv] per-flow qos In-Reply-To: <3B4DA362.7541C905@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Brian, > Diffserv is not a per-flow model, so any such work is > in any case rather strange. Please take questions of this (Assuming the core is diffserv) I am not sure how you define "strange". I think this depends on how one defines "service". There is a whole spectrum from very soft to very hard. Alper K. Demir > kind to the diffserv-interest mailing list, since they are > outside the charter of this WG: > > > To post to this list, send your email to: > > > > diffserv-interest@ietf.org > > > > To join the list, go to > > > > http://www.ietf.org/mailman/listinfo/diffserv-interest > > > > or send a message to: > > > > diffserv-interest-request@ietf.org > > > > with the word `help' in the subject or body (don't include the > > quotes), and you will get back a message with instructions. > > > > Thanks to the friendly staff at ietf.org for setting this up. Please use it for > > non-standards discussions. There is also the diffserv implementation list at > > > > http://www.atnf.csiro.au/news/exploders/dsimplementation.html > > > > Brian Carpenter > diffserv WG co-chair > > Christina Krishna wrote: > > > > hi all, > > Can any one suggest me pointers to works on "per-flow" > > QoS provisioning in a diffserv network? Much work is > > done on per-aggregate QoS in diffserv network, but i > > need information on per-flow qos in difserv. > > > > I have one paper titled "Attaining per-flow QoS with > > class-based differentiated services" by M.Tufail, > > G.Jennes, G.Leduc, SPIE symposium on Voice, video and > > data communications, Conf: Broadband network, Sept > > 1999, MA, USA. > > > > Does any one have pointers to other works in this > > field? > > > > thanks in advance. > > ck. > > > > __________________________________________________ > > Do You Yahoo!? > > Get personalized email addresses from Yahoo! Mail > > http://personal.mail.yahoo.com/ > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > http://www1.ietf.org/mailman/listinfo/diffserv > > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter > Distinguished Engineer, Internet Standards & Technology, IBM > On assignment for IBM at http://www.iCAIR.org > Board Chairman, Internet Society http://www.isoc.org > > "We shall need a number of efficient librarian types > to keep us in order." - Alan Turing, 1947. > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Jul 16 11:55:22 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07993 for ; Mon, 16 Jul 2001 11:55:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11149; Mon, 16 Jul 2001 11:27:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11120 for ; Mon, 16 Jul 2001 11:27:00 -0400 (EDT) Received: from mail.eecis.udel.edu (louie.udel.edu [128.175.7.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02562 for ; Mon, 16 Jul 2001 11:26:07 -0400 (EDT) Received: from louie.udel.edu by mail.eecis.udel.edu id aa19195; 16 Jul 2001 11:26 EDT Date: Mon, 16 Jul 2001 11:26:38 -0400 (EDT) From: Vasil Hnatyshin To: diffserv@ietf.org MMDF-Warning: Parse error in original version of preceding line at mail.eecis.udel.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Diffserv] DiffServ MIB how to maintain data? Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hello, Sorry for bothering you but I have a question regarding the DiffServ MIB implementation and I was not able to find the answer in the diffServ MIB draft. I'm facing the following problem: 1. We started a QoS enabled router and created a DiffServ MIB for it. 2. At some point of time QoS configuration of the router was changed: e.g. certain classification rules were changed (added and deleted). 3. The problem is: How should the MIB reflect these configuration changes? Currently I'm considering two possible approaches: 1. Remove all deleted Classifier Element entries from the diffServClfrElementTable (or whatever table that was changed) and add at the end newly added entries starting from the position diffServClfrElementNextFree. In this case a entries in the diffServClfrElementTable will not be contiguous, the space may be wasted and as the result we may run out of diffServClfrElementNextFree values after some time. 2. After the configuration changes we re-initialize the DiffServ MIB by re-scanning the current router configuration and re-setting all the tables. In this case all the Tables will have thier elements ordered in the contiguos fashion (except for the Data Path Table, which is indexed by the interface index and direction). However, MIB re-initializion may mess-up the managers, and cause configuration errors (e.g. manager may try to set the DiffServ MIB table entries that were deleted or even worse: entries that were replaced.). On the other hand individual MIB table entries can not be considered alone without examining the whole data path starting from the Data Path Table that contains information about the interface index and direction. (e.g. SixTupleClassifierEntry.14.2.3 -- means Row Status of the entry that corresponds to the classifier element #3 that belongs to classfier #2) So the question are: What the MIB behavior should be in this case? Is there an IETF standard for treating cases like this? Thank you for your help, Sincerely, Vasil Hnatyshin. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Jul 16 14:53:53 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16265 for ; Mon, 16 Jul 2001 14:53:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16282; Mon, 16 Jul 2001 14:18:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16214 for ; Mon, 16 Jul 2001 14:18:10 -0400 (EDT) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09707; Mon, 16 Jul 2001 14:17:16 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6GIHE916807; Mon, 16 Jul 2001 14:17:14 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Mon, 16 Jul 2001 14:17:25 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <3HJ26HT0>; Mon, 16 Jul 2001 14:17:27 -0400 Message-ID: From: "Muhammad Jaseemuddin" To: diffserv@ietf.org, "'diffserv-interest@ietf.org'" Date: Mon, 16 Jul 2001 14:17:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10E23.8DB15D60" X-Orig: Subject: [Diffserv] CFP: Next Generation Internet Symposium at ICC 2002 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C10E23.8DB15D60 Content-Type: text/plain CALL FOR PAPERS Next Generation Internet Symposium IN CONJUNCTION WITH ICC 2002 April 28-May 2, 2002 New York, NY USA As part of ICC 2002, a symposium on the Next Generation Internet will be held. Participation in this symposium is open to all registrants of ICC 2002 (i.e. a separate registration is not required). Papers submitted for consideration to the symposium should focus on topics related to the Next Generation Internet (i.e. addressing issues and areas that will not be deployed in the public Internet for at least 3-5 years). Examples of topics of interest include: * NGI Performance * NGI Architecture * QoS - Fact or Fiction * Streaming Media * Home Networking-based Internet * Voice over IP Services * Internet Service Management * Internet Appliances * Next Generation Optical * NGI Protocols Internet * NGI Operations & Management * NGI Applications and * Monitoring and measurements Services for next-generation networks * NGI modeling and * Middleboxes (in-the-net services) simulation tools * Network-friendly applications * Interplanetary issues Instructions: The paper submission schedule and process is the same as for the general ICC 2002 conference (see http://www.icc2002.com/InfoForAuthors.html). Be sure to indicate the Next Generation Internet (NGI) symposium as the target for your paper on the cover page and also list the relevant hot topic(s). See the ICC 2002 Call for Papers for detailed submission Instructions (i.e., schedule, paper-length, etc.). Business Application Sessions (i.e. panel discussions) proposals are also welcome. For these, please submit session proposals to Stan Moyer and include a brief description of the session, along with bios of the session organizer/moderator and the proposed speakers. Further information can be obtained from: Stan Moyer Michael Devetsikiotis General Co-Chair General Co-Chair Telcordia Technologies North Carolina State University stanm@research.telcordia.com mdevets@eos.ncsu.edu Sponsored by the following IEEE Communications Society Technical Committees: * Communications Systems * Computer Communications Integration & Modeling * Communications Software * Personal Communications Technical Program Committee: Symeon Papavassiliou, New Jersey Institute of Technology Nelson Fonseca, State University of Campinas, Brazil Pascal Lorenz, University of Haute-Alsace, France Mohammad Ilyas, Florida Atlantic University Algirdas Pakstas, University of North London Ray Sundararaman, Lucent Amitabh Mishra, Virginia Polytech Joe Touch, USC Information Sciences Institute Tim Moors, Polytechnic University Bassam Hashem, Nortel Networks Alagan Anpalagan, University of Toronto S.-H. Gary Chan, Hong Kong University of Science and Technology Sung Jun Lee, HP Labs Elizabeth Royer, UC Santa Barbara Muhammad Jaseemuddin, Nortel Networks Ted Faber, USC Information Sciences Institute Eric Nahum, IBM Watson Research Vishal Misra, University of Massachusetts Behcet Sarikaya, Alcatel USA David Harle, University of Strathclyde, Scotland Jogesh Muppala, Hong Kong University of Science & Technology l For more information, see: http://www.comsoc.org/socstr/techcom/commsoft/confs/ngi_cfp.htm ------_=_NextPart_001_01C10E23.8DB15D60 Content-Type: text/html Content-Transfer-Encoding: quoted-printable CFP: Next Generation Internet Symposium at ICC 2002

           &= nbsp;        CALL FOR PAPERS
           Next = Generation Internet Symposium

IN CONJUNCTION WITH ICC = 2002
April 28-May 2, 2002 New York, = NY USA

As part of ICC 2002, a symposium = on the Next Generation Internet
will be held. Participation in = this symposium is open to all
registrants of ICC 2002 (i.e. a = separate registration is not
required).

Papers submitted for = consideration to the symposium should focus on
topics related to the Next = Generation Internet (i.e. addressing
issues and areas that will not = be deployed in the public Internet
for at least 3-5 years). = Examples of topics of interest include:
  * NGI = Performance          &= nbsp;         * NGI = Architecture
  * QoS - Fact or = Fiction           = ;   * Streaming Media
  * Home Networking-based = Internet     * Voice over IP
    = Services          &nbs= p;           &nbs= p;    * Internet Service
           &= nbsp;           &= nbsp;           &= nbsp;     Management
  * Internet = Appliances          &n= bsp;     * Next Generation Optical
  * NGI = Protocols          &nb= sp;           &nb= sp; Internet
  * NGI Operations & = Management        * NGI Applications = and
  * Monitoring and = measurements          = Services
    for = next-generation networks       * NGI = modeling and
  * Middleboxes = (in-the-net services)    simulation tools
  * Network-friendly = applications      * Interplanetary = issues

Instructions: The paper = submission schedule and process is the same
as for the general ICC 2002 = conference (see
http://www.icc2002.com/InfoForAuthors.html<= /U>). Be sure to indicate = the
Next Generation Internet (NGI) = symposium as the target for your
paper on the cover page and = also list the relevant hot topic(s).
See the ICC 2002 Call for = Papers for detailed submission
Instructions (i.e., schedule, = paper-length, etc.).

Business Application Sessions = (i.e. panel discussions) proposals are
also welcome. For these, please = submit session proposals to Stan
Moyer and include a brief = description of the session, along with
bios of the session = organizer/moderator and the proposed speakers.
           &= nbsp;           &= nbsp;           &= nbsp;           &= nbsp;
Further information can be = obtained from:
  Stan = Moyer           &= nbsp;           = Michael Devetsikiotis
  General = Co-Chair          &nbs= p;      General Co-Chair
  Telcordia = Technologies          = North Carolina State University
  = stanm@research.telcordia.com     = mdevets@eos.ncsu.edu

Sponsored by the following IEEE = Communications Society Technical
Committees:
 * Communications = Systems    * Computer Communications
   Integration & = Modeling    * Communications Software
 * Personal = Communications

Technical Program = Committee:

     Symeon = Papavassiliou, New Jersey Institute of Technology
     Nelson = Fonseca, State University of Campinas, Brazil
     Pascal = Lorenz, University of Haute-Alsace, France
     = Mohammad Ilyas, Florida Atlantic University
     = Algirdas Pakstas, University of North London
     Ray = Sundararaman, Lucent
     = Amitabh Mishra, Virginia Polytech
     Joe = Touch, USC Information Sciences Institute
     Tim = Moors, Polytechnic University
     Bassam = Hashem, Nortel Networks
     Alagan = Anpalagan, University of Toronto
     S.-H. = Gary Chan, Hong Kong University of Science and Technology
     Sung = Jun Lee, HP Labs
     = Elizabeth Royer, UC Santa Barbara
     = Muhammad Jaseemuddin, Nortel Networks
     Ted = Faber, USC Information Sciences Institute
     Eric = Nahum, IBM Watson Research
     Vishal = Misra, University of Massachusetts
     Behcet = Sarikaya, Alcatel USA
     David = Harle, University of Strathclyde, Scotland
     Jogesh = Muppala, Hong Kong University of Science & Technology
           &= nbsp;           &= nbsp;            = l
For more information, = see:
http://www.comsoc.org/socstr/techcom/commsoft/confs/ng= i_cfp.htm

------_=_NextPart_001_01C10E23.8DB15D60-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Jul 16 16:56:04 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08212 for ; Mon, 16 Jul 2001 16:56:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19456; Mon, 16 Jul 2001 16:11:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19429 for ; Mon, 16 Jul 2001 16:11:13 -0400 (EDT) Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.121.85]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00749 for ; Mon, 16 Jul 2001 16:10:19 -0400 (EDT) Received: from ANDREWHOME (user-vcauodp.dsl.mindspring.com [216.175.97.185]) by gull.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id NAA19900; Mon, 16 Jul 2001 13:02:44 -0700 (PDT) Reply-To: From: "Andrew Smith" To: "Vasil Hnatyshin" , Subject: RE: [Diffserv] DiffServ MIB how to maintain data? Date: Mon, 16 Jul 2001 13:19:38 -0700 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Vasil, I think you are misunderstanding the use of the "NextFree" objects. The manager and agent have a mutual knowledge of which classifier element entry has which index. You cannot "re-initialize" the MIB and change those index values. So your option 2 is not viable. For option 1, why do you need the the entries to have contiguous indices? Values are not "wasted" (at least in a reasonable implementation) - it is the agent who chooses what the next free index is to be and it can loop around when it gets to 2^^32. You will only run out of values when there are (2^^32-1) classifier elements present - an unlikely scenario (I hope) - you are more likely first to run up against the capacity of the device to classify. If this is not clear from the current draft then let us know (the definition of the usage has to be clear and complete, although it does not need to be obvious). Andrew -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of Vasil Hnatyshin Sent: Monday, July 16, 2001 8:27 AM To: diffserv@ietf.org Subject: [Diffserv] DiffServ MIB how to maintain data? Hello, Sorry for bothering you but I have a question regarding the DiffServ MIB implementation and I was not able to find the answer in the diffServ MIB draft. I'm facing the following problem: 1. We started a QoS enabled router and created a DiffServ MIB for it. 2. At some point of time QoS configuration of the router was changed: e.g. certain classification rules were changed (added and deleted). 3. The problem is: How should the MIB reflect these configuration changes? Currently I'm considering two possible approaches: 1. Remove all deleted Classifier Element entries from the diffServClfrElementTable (or whatever table that was changed) and add at the end newly added entries starting from the position diffServClfrElementNextFree. In this case a entries in the diffServClfrElementTable will not be contiguous, the space may be wasted and as the result we may run out of diffServClfrElementNextFree values after some time. 2. After the configuration changes we re-initialize the DiffServ MIB by re-scanning the current router configuration and re-setting all the tables. In this case all the Tables will have thier elements ordered in the contiguos fashion (except for the Data Path Table, which is indexed by the interface index and direction). However, MIB re-initializion may mess-up the managers, and cause configuration errors (e.g. manager may try to set the DiffServ MIB table entries that were deleted or even worse: entries that were replaced.). On the other hand individual MIB table entries can not be considered alone without examining the whole data path starting from the Data Path Table that contains information about the interface index and direction. (e.g. SixTupleClassifierEntry.14.2.3 -- means Row Status of the entry that corresponds to the classifier element #3 that belongs to classfier #2) So the question are: What the MIB behavior should be in this case? Is there an IETF standard for treating cases like this? Thank you for your help, Sincerely, Vasil Hnatyshin. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Jul 16 21:09:33 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA25626 for ; Mon, 16 Jul 2001 21:09:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA25742; Mon, 16 Jul 2001 20:43:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA25716 for ; Mon, 16 Jul 2001 20:43:44 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19759 for ; Mon, 16 Jul 2001 20:42:52 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id BAA33430 for ; Tue, 17 Jul 2001 01:43:13 +0100 Received: from hursley.ibm.com ([9.242.148.96]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id BAA64502 for ; Tue, 17 Jul 2001 01:43:12 +0100 Message-ID: <3B538934.D1A02FDB@hursley.ibm.com> Date: Mon, 16 Jul 2001 19:39:16 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Diff Serv Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] [Fwd: Last Call: MPLS Support of Differentiated Services to ProposedStandard] Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Diffservers, Please note the attached IETF last call. If you have any remaining comments, please send them as instructed below (not to this list!) Brian Carpenter diffserv co-chair -------- Original Message -------- Subject: Last Call: MPLS Support of Differentiated Services to ProposedStandard Date: Mon, 16 Jul 2001 15:52:55 -0400 From: The IESG Reply-To: iesg@ietf.org To: IETF-Announce: ; CC: mpls@uu.net The IESG has received a request from the Multiprotocol Label Switching Working Group to consider MPLS Support of Differentiated Services as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by July 30, 2001. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mpls-diff-ext-09.txt _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Jul 17 15:56:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29810 for ; Tue, 17 Jul 2001 15:56:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01174; Tue, 17 Jul 2001 14:04:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00096 for ; Tue, 17 Jul 2001 13:57:24 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23758; Tue, 17 Jul 2001 13:16:53 -0400 (EDT) Message-Id: <200107171716.NAA23758@ietf.org> From: The IESG To: AAA Working Group , ACAP Working Group , ADSLMIB Working Group , AFT Working Group , AGENTX Working Group , APEX Working Group , ATOMMIB Working Group , AVT Working Group , BEEP Working Group , BGMP Working Group , BMWG Working Group , BRIDGE Working Group , CALSCH Working Group , CAT Working Group , CCAMP Working Group , CNRP Working Group , DELTAV Working Group , DHC Working Group , DIFFSERV Working Group , DISMAN Working Group , DNSEXT Working Group , DNSOP Working Group , ECM Working Group , EDIINT Working Group , ENTMIB Working Group , ENUM Working Group , EOS Working Group , FAX Working Group , FRNETMIB Working Group , FTPEXT Working Group , GEOPRIV Working Group , GRIP Working Group , GSMP Working Group , HUBMIB Working Group , IDMR Working Group , IDN Working Group , IDR Working Group , IDWG Working Group , IFMIB Working Group , IMAPEXT Working Group , IMPP Working Group , IPCDN Working Group , IPFC Working Group , IPNGWG Working Group , IPO Working Group , IPORPR Working Group , IPP Working Group , IPPM Working Group , IPS Working Group , IPSEC Working Group , IPSP Working Group , IPSRA Working Group , IPTEL Working Group , ISIS Working Group , ISSLL Working Group , ITRACE Working Group , KINK Working Group , KRB-WG Working Group , L2TPEXT Working Group , LDAPBIS Working Group , LDAPEXT Working Group , LDUP Working Group , MALLOC Working Group , MANET Working Group , MBONED Working Group , MEGACO Working Group , MIDCOM Working Group , MMUSIC Working Group , MOBILEIP Working Group , MPLS Working Group , MSDP Working Group , MSEC Working Group , MSGTRK Working Group , MULTI6 Working Group , NASREQ Working Group , NAT Working Group , NFSV4 Working Group , NGTRANS Working Group , NNTPEXT Working Group , OPENPGP Working Group , OSPF Working Group , OTP Working Group , PILC Working Group , PIM Working Group , PKIX Working Group , POISSON Working Group , POLICY Working Group , PPPEXT Working Group , PPVPN Working Group , PROVREG Working Group , PWE3 Working Group , RAP Working Group , RESCAP Working Group , RIP Working Group , RMONMIB Working Group , RMT Working Group , ROHC Working Group , RSERPOOL Working Group , RUN Working Group , SACRED Working Group , SEAMOBY Working Group , SECSH Working Group , SIGTRAN Working Group , SIMPLE Working Group , SIP Working Group , SMIME Working Group , SMING Working Group , SNMPCONF Working Group , SNMPV3 Working Group , SPIRITS Working Group , SSM Working Group , STIME Working Group , SYSLOG Working Group , TEWG Working Group , TLS Working Group , TN3270E Working Group , TRADE Working Group , TSVWG Working Group , UDLR Working Group , URN Working Group , USEFOR Working Group , USWG Working Group , VPIM Working Group , VRRP Working Group , WEBDAV Working Group , WEBI Working Group , WTS Working Group , XMLDSIG Working Group , ZEROCONF Working Group cc: iesg@ietf.org Date: Tue, 17 Jul 2001 13:16:53 -0400 Subject: [Diffserv] Note Well Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Greetings, This is the revised text of the NOTE WELL statement. ------------------------------------------------------ NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to: - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Jul 17 16:15:31 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA04401 for ; Tue, 17 Jul 2001 16:15:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01175; Tue, 17 Jul 2001 14:04:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28841 for ; Tue, 17 Jul 2001 13:27:37 -0400 (EDT) Received: from roam.psg.com (H-135-207-10-122.research.att.com [135.207.10.122]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26319; Tue, 17 Jul 2001 13:26:36 -0400 (EDT) Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15MYb7-0000LK-00; Tue, 17 Jul 2001 13:25:25 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Rsent-To: eos@ops.ietf.org From: The IESG To: AAA Working Group , ACAP Working Group , ADSLMIB Working Group , AFT Working Group , AGENTX Working Group , APEX Working Group , ATOMMIB Working Group , AVT Working Group , BEEP Working Group , BGMP Working Group , BMWG Working Group , BRIDGE Working Group , CALSCH Working Group , CAT Working Group , CCAMP Working Group , CNRP Working Group , DELTAV Working Group , DHC Working Group , DIFFSERV Working Group , DISMAN Working Group , DNSEXT Working Group , DNSOP Working Group , ECM Working Group , EDIINT Working Group , ENTMIB Working Group , ENUM Working Group , EOS Working Group , FAX Working Group , FRNETMIB Working Group , FTPEXT Working Group , GEOPRIV Working Group , GRIP Working Group , GSMP Working Group , HUBMIB Working Group , IDMR Working Group , IDN Working Group , IDR Working Group , IDWG Working Group , IFMIB Working Group , IMAPEXT Working Group , IMPP Working Group , IPCDN Working Group , IPFC Working Group , IPNGWG Working Group , IPO Working Group , IPORPR Working Group , IPP Working Group , IPPM Working Group , IPS Working Group , IPSEC Working Group , IPSP Working Group , IPSRA Working Group , IPTEL Working Group , ISIS Working Group , ISSLL Working Group , ITRACE Working Group , KINK Working Group , KRB-WG Working Group , L2TPEXT Working Group , LDAPBIS Working Group , LDAPEXT Working Group , LDUP Working Group , MALLOC Working Group , MANET Working Group , MBONED Working Group , MEGACO Working Group , MIDCOM Working Group , MMUSIC Working Group , MOBILEIP Working Group , MPLS Working Group , MSDP Working Group , MSEC Working Group , MSGTRK Working Group , MULTI6 Working Group , NASREQ Working Group , NAT Working Group , NFSV4 Working Group , NGTRANS Working Group , NNTPEXT Working Group , OPENPGP Working Group , OSPF Working Group , OTP Working Group , PILC Working Group , PIM Working Group , PKIX Working Group , POISSON Working Group , POLICY Working Group , PPPEXT Working Group , PPVPN Working Group , PROVREG Working Group , PWE3 Working Group , RAP Working Group , RESCAP Working Group , RIP Working Group , RMONMIB Working Group , RMT Working Group , ROHC Working Group , RSERPOOL Working Group , RUN Working Group , SACRED Working Group , SEAMOBY Working Group , SECSH Working Group , SIGTRAN Working Group , SIMPLE Working Group , SIP Working Group , SMIME Working Group , SMING Working Group , SNMPCONF Working Group , SNMPV3 Working Group , SPIRITS Working Group , SSM Working Group , STIME Working Group , SYSLOG Working Group , TEWG Working Group , TLS Working Group , TN3270E Working Group , TRADE Working Group , TSVWG Working Group , UDLR Working Group , URN Working Group , USEFOR Working Group , USWG Working Group , VPIM Working Group , VRRP Working Group , WEBDAV Working Group , WEBI Working Group , WTS Working Group , XMLDSIG Working Group , ZEROCONF Working Group cc: iesg@ietf.org Message-Id: Date: Tue, 17 Jul 2001 13:25:25 -0400 Content-Transfer-Encoding: 7bit Subject: [Diffserv] Note Well Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Greetings, This is the revised text of the NOTE WELL statement. ------------------------------------------------------ NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to: - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Jul 18 18:27:50 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20649 for ; Wed, 18 Jul 2001 18:27:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03766; Wed, 18 Jul 2001 17:52:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03728 for ; Wed, 18 Jul 2001 17:52:39 -0400 (EDT) Received: from salween.dallas.wrs.com ([204.181.206.196]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12961 for ; Wed, 18 Jul 2001 17:51:44 -0400 (EDT) Received: from windriver.com (mountain.dallas.wrs.com [204.181.204.71]) by salween.dallas.wrs.com (8.9.3/8.9.3) with ESMTP id QAA20567 for ; Wed, 18 Jul 2001 16:48:49 -0500 (CDT) Message-ID: <3B560508.87227BD7@windriver.com> Date: Wed, 18 Jul 2001 16:52:08 -0500 From: Tom Irwin X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: DiffServ WG Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Draft DiffServ MIB rev 10 Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit When will the draft DiffServ MIB rev 10 be available? Thanks, Tom Irwin Member of Technical Staff Wind River Systems, Inc. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Jul 19 09:52:12 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03522 for ; Thu, 19 Jul 2001 09:52:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06402; Thu, 19 Jul 2001 08:56:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06371 for ; Thu, 19 Jul 2001 08:56:35 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA18681 for ; Thu, 19 Jul 2001 08:55:38 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id NAA30988; Thu, 19 Jul 2001 13:55:57 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id NAA45072; Thu, 19 Jul 2001 13:55:56 +0100 Message-ID: <3B56D7D2.D689E094@hursley.ibm.com> Date: Thu, 19 Jul 2001 07:51:30 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Tom Irwin CC: DiffServ WG Subject: Re: [Diffserv] Draft DiffServ MIB rev 10 References: <3B560508.87227BD7@windriver.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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Fred Baker is editing it and he hopes to have it submitted by the cutoff date (this Friday). Brian Carpenter diffserv co-chair Tom Irwin wrote: > > When will the draft DiffServ MIB rev 10 be available? > > Thanks, > Tom Irwin > Member of Technical Staff > Wind River Systems, Inc. > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Thu Jul 19 20:01:48 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA23664 for ; Thu, 19 Jul 2001 20:01:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16061; Thu, 19 Jul 2001 13:03:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16029 for ; Thu, 19 Jul 2001 13:03:16 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11903 for ; Thu, 19 Jul 2001 13:02:20 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id SAA14484 for ; Thu, 19 Jul 2001 18:02:44 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id SAA71880 for ; Thu, 19 Jul 2001 18:02:39 +0100 Message-ID: <3B571143.247D470C@hursley.ibm.com> Date: Thu, 19 Jul 2001 11:56:35 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Diff Serv Content-Type: multipart/mixed; boundary="------------16B80BDE33A9F88500C7C1ED" Subject: [Diffserv] [Fwd: I-D ACTION:draft-conta-ipv6-flow-label-02.txt] Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. --------------16B80BDE33A9F88500C7C1ED Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Diffservers, The attached draft is relevant to diffserv, although it is aimed primarily at the IPNG WG. It proposes a use of the IPv6 Flow Label for diffserv. Brian -------- Original Message -------- Subject: I-D ACTION:draft-conta-ipv6-flow-label-02.txt Date: Thu, 19 Jul 2001 07:03:05 -0400 From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org To: IETF-Announce: ; A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A proposal for the IPv6 Flow Label Specification Author(s) : A. Conta, B. Carpenter Filename : draft-conta-ipv6-flow-label-02.txt Pages : 27 Date : 18-Jul-01 At the time when the IPv6 specifications were written, the IPv6 flow label was still experimental, and subject to change, as the requirements for flow support in the Internet were evolving. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-conta-ipv6-flow-label-02.txt --------------16B80BDE33A9F88500C7C1ED Content-Type: Message/External-body; name="draft-conta-ipv6-flow-label-02.txt" Content-Disposition: inline; filename="draft-conta-ipv6-flow-label-02.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <20010718141739.I-D@ietf.org> --------------16B80BDE33A9F88500C7C1ED-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Jul 20 09:22:57 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24770 for ; Fri, 20 Jul 2001 09:22:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA27758; Fri, 20 Jul 2001 08:52:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA04662 for ; Wed, 18 Jul 2001 05:02:49 -0400 (EDT) Received: from iraun1.uka.de (iraun1.uka.de [129.13.10.90]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA02408 for ; Wed, 18 Jul 2001 05:01:53 -0400 (EDT) Received: from i72pc127.tm.uni-karlsruhe.de by iraun1 (PP) with ESMTP; Wed, 18 Jul 2001 11:02:46 +0200 Received: from i72pc127.tm.uni-karlsruhe.de (localhost [127.0.0.1]) by i72pc127.tm.uni-karlsruhe.de (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id f6I92jt02990; Wed, 18 Jul 2001 11:02:45 +0200 Message-Id: <200107180902.f6I92jt02990@i72pc127.tm.uni-karlsruhe.de> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.3 To: diffserv@ietf.org cc: diffserv-interest@external.cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 18 Jul 2001 11:02:45 +0200 From: Roland Bless Subject: [Diffserv] I-D ACTION:draft-bless-diffserv-mcast-routerext-00.txt (fwd) Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi, when looking back to 46th IETF meeting minutes, there are still some open multicast issues. This short proposal might be of interest for some people here. It would be nice to get any feedback from people here, especially manufacturers of routers. Regards, Roland P.S.: Sorry, I currently don't know any other WG that is more appropriate for discussion of this issue. ------- Forwarded Message A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Router Extension to Support Multicast in Differentiated Services Networks Author(s) : R. Bless, K. Wehrle Filename : draft-bless-diffserv-mcast-routerext-00.txt Pages : 4 Date : 16-Jul-01 This draft proposes an extension to the multicast routing table in routers in order to achieve better support for using multicast within Differentiated Services (DS) networks. Only one additional DS codepoint for each virtual interface in the multicast routing table is required to open up a variety of different uses, e.g., to solve resource provisioning problems or to support heterogeneous DiffServ multicast groups. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bless-diffserv-mcast-routerext-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-bless-diffserv-mcast-routerext-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-bless-diffserv-mcast-routerext-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------- End of Forwarded Message -- Roland Bless -- e-Mail: bless@tm.uka.de Institute of Telematics, University of Karlsruhe, Germany Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358 Phone: +49 721 608-6413 Fax: +49 721 388097 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Jul 20 11:38:04 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04988 for ; Fri, 20 Jul 2001 11:38:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03070; Fri, 20 Jul 2001 11:10:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03039 for ; Fri, 20 Jul 2001 11:10:14 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29337 for ; Fri, 20 Jul 2001 11:09:13 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA19006; Fri, 20 Jul 2001 16:09:34 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA58930; Fri, 20 Jul 2001 16:09:30 +0100 Message-ID: <3B584814.AF21DF29@hursley.ibm.com> Date: Fri, 20 Jul 2001 10:02:44 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Roland Bless CC: diffserv@ietf.org Subject: Re: [Diffserv] I-D ACTION:draft-bless-diffserv-mcast-routerext-00.txt (fwd) References: <200107180902.f6I92jt02990@i72pc127.tm.uni-karlsruhe.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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Roland, Have you discussed with the Routing ADs how to follow up on this? That is certainly something to do in London. Brian Roland Bless wrote: > > Hi, > > when looking back to 46th IETF meeting minutes, there are still > some open multicast issues. This short proposal might be of interest > for some people here. It would be nice to get any feedback from people > here, especially manufacturers of routers. > > Regards, > Roland > > P.S.: Sorry, I currently don't know any other WG that is more appropriate > for discussion of this issue. > > ------- Forwarded Message > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : A Router Extension to Support Multicast in > Differentiated Services Networks > Author(s) : R. Bless, K. Wehrle > Filename : draft-bless-diffserv-mcast-routerext-00.txt > Pages : 4 > Date : 16-Jul-01 > > This draft proposes an extension to the multicast routing table in > routers in order to achieve better support for using multicast > within Differentiated Services (DS) networks. Only one additional DS > codepoint for each virtual interface in the multicast routing table > is required to open up a variety of different uses, e.g., to solve > resource provisioning problems or to support heterogeneous DiffServ > multicast groups. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-bless-diffserv-mcast-routerext-00.txt _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Jul 20 14:50:25 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28732 for ; Fri, 20 Jul 2001 14:50:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10892; Fri, 20 Jul 2001 14:15:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10862 for ; Fri, 20 Jul 2001 14:15:26 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16296; Fri, 20 Jul 2001 14:14:28 -0400 (EDT) Received: from FRED-W2K.cisco.com ([171.71.21.235]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f6KIF5T21230; Fri, 20 Jul 2001 11:15:05 -0700 (PDT) Message-Id: <5.1.0.14.2.20010720111322.0278ef00@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 20 Jul 2001 11:13:56 -0700 To: internet-drafts@ietf.org From: Fred Baker Cc: diffserv@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] new MIB draft Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org You may find a new MIB draft at ftp://ftpeng.cisco.com/fred/diffserv-mib/draft-ietf-diffserv-mib-10.txt _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Jul 20 14:53:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29794 for ; Fri, 20 Jul 2001 14:53:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10797; Fri, 20 Jul 2001 14:13:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10765 for ; Fri, 20 Jul 2001 14:13:09 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15435 for ; Fri, 20 Jul 2001 14:12:12 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id TAA29154; Fri, 20 Jul 2001 19:12:35 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id TAA76008; Fri, 20 Jul 2001 19:12:32 +0100 Message-ID: <3B5871AF.A786A7E2@hursley.ibm.com> Date: Fri, 20 Jul 2001 13:00:15 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Roland Bless CC: diffserv@ietf.org Subject: Re: [Diffserv] I-D ACTION:draft-bless-diffserv-mcast-routerext-00.txt (fwd) References: <200107201637.f6KGbHt11790@i72pc127.tm.uni-karlsruhe.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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit We are scheduled to meet, if the MIB and PIB drafts get submitted before the cutoff (er, about 3 hours from now). In the latest variant of the agenda, we are on THURSDAY, August 9, 2001 from 0900-1130. The detailed agenda is due by July 31 at the latest. Brian Roland Bless wrote: > > Brian, > > > Have you discussed with the Routing ADs how to follow up on this? > > That is certainly something to do in London. > > Yes, I followed Kathie's advice to contact them in order to > get a hint for an appropriate WG for discussion of this issue. > So we already contacted the Routing ADs by e-mail, but Rob wanted > to know something about the operational requirements for this work > (this was before we wrote the draft). Therefore, we'd like to get > feedback from the community. However, we are looking forward to > discuss about it in London. > > Roland > > P.S.: Will the diffserv WG meet in London? I didn't see any > agenda yet. > > > Brian > > > > Roland Bless wrote: > > > > > > Hi, > > > > > > when looking back to 46th IETF meeting minutes, there are still > > > some open multicast issues. This short proposal might be of interest > > > for some people here. It would be nice to get any feedback from people > > > here, especially manufacturers of routers. > > > > > > Regards, > > > Roland > > > > > > P.S.: Sorry, I currently don't know any other WG that is more appropriate > > > for discussion of this issue. > > > > > > ------- Forwarded Message > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > > > > Title : A Router Extension to Support Multicast in > > > Differentiated Services Networks > > > Author(s) : R. Bless, K. Wehrle > > > Filename : draft-bless-diffserv-mcast-routerext-00.txt > > > Pages : 4 > > > Date : 16-Jul-01 > > > > > > This draft proposes an extension to the multicast routing table in > > > routers in order to achieve better support for using multicast > > > within Differentiated Services (DS) networks. Only one additional DS > > > codepoint for each virtual interface in the multicast routing table > > > is required to open up a variety of different uses, e.g., to solve > > > resource provisioning problems or to support heterogeneous DiffServ > > > multicast groups. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-bless-diffserv-mcast-routerext-00.txt > > -- > Roland Bless -- e-Mail: bless@tm.uka.de > Institute of Telematics, University of Karlsruhe, Germany > Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358 > Phone: +49 721 608-6413 Fax: +49 721 388097 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Jul 20 15:01:19 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA02007 for ; Fri, 20 Jul 2001 15:01:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11054; Fri, 20 Jul 2001 14:16:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10945 for ; Fri, 20 Jul 2001 14:16:01 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16639 for ; Fri, 20 Jul 2001 14:15:05 -0400 (EDT) Received: from FRED-W2K.cisco.com ([171.71.21.235]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f6KIFQT21516; Fri, 20 Jul 2001 11:15:26 -0700 (PDT) Message-Id: <5.1.0.14.2.20010719203400.0293b138@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 20 Jul 2001 11:15:12 -0700 To: "Kwok-Ho Chan" From: Fred Baker Cc: Brian E Carpenter , "Kwok-Ho Chan" , andrew@allegronetworks.com, nichols@packetdesign.com, diffserv@ietf.org In-Reply-To: <200107122227.f6CMRDb19064@zcars0m9.ca.nortel.com> References: <3B3C9F03.BAC4B055@hursley.ibm.com> <200106122101.OAA05832@irp-view7.cisco.com> <5.1.0.14.2.20010626115844.032dd068@mira-sjcm-2.cisco.com> <3B38E86F.8AD59CEB@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] Re: MIB draft [Kwok's Rvw Result #2] Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 04:24 AM 7/12/2001, Kwok-Ho Chan wrote: >As for the diffServClfrTable/Entry issue: Based on no agreement with >Removal of diffServClfrTable/Entry, I think we should add >diffServClfrTable/Entry back into the MIB (this was not one of the agreed >changes when we were at Minniapolis) and create an open issue for removing it. A few observations... Let's presume that ClfrNextFree counts and ClfrElementNextFree counts. Now I go to create three classifiers, each of which gets one element put into it, and then one of which gets two more. Consider the behavior: Assume that clfrNextFree and clfrElementNextFree each initially have the value 1. 1) read clfrnextfree (1) and clfrelementnextfree (1) 2) create clfrEntry[1] by writing createAndGo to ClfrStatus[1] 3) create clfrSixTypleEntry[1][1] by writing and createAndGo to ClfrSixTupleStatus[1][1] 4) create clfrElementEntry[1][1] by writing ^ClfrSixTupleEntry[1][1] to ClfrElementSpecific[1][1] and createAndGo to ClfrElementStatus[1][1] This took four round trips. New we create the second and third entries: 5) read clfrnextfree (2) and clfrelementnextfree (2) 6) create clfrEntry[1] by writing createAndGo to ClfrStatus[2] 7) create clfrSixTypleEntry[2][2] by writing and createAndGo to ClfrSixTupleStatus[2][2] 8) create clfrElementEntry[2][2] by writing ^ClfrSixTupleEntry[2][2] to ClfrElementSpecific[2][2] and createAndGo to ClfrElementStatus[2][2] 9) read clfrnextfree (3) and clfrelementnextfree (3) 10) create clfrEntry[3] by writing createAndGo to ClfrStatus[3] 11) create clfrSixTypleEntry[1][1] by writing and createAndGo to ClfrSixTupleStatus[3][3] 12) create clfrElementEntry[3][3] by writing ^ClfrSixTupleEntry[3][3] to ClfrElementSpecific[3][3] and createAndGo to ClfrElementStatus[3][3] We now have: ClfrEntry[1], ClfrSixTupleEntry[1][1], ClfrElementEntry[1][1] ClfrEntry[2], ClfrSixTupleEntry[2][2], ClfrElementEntry[2][2] ClfrEntry[3], ClfrSixTupleEntry[3][3], ClfrElementEntry[3][3] Each Classifier took four round trips to build New we create the second and third elements of the first classifier: 5) read clfrelementnextfree (4) 6) create clfrSixTypleEntry[1][4] by writing and createAndGo to ClfrSixTupleStatus[1][4] 7) create clfrElementEntry[1][4] by writing ^ClfrElementENtry[1][4] to ClfrElementNext[1][1] ^ClfrSixTupleEntry[1][4] to ClfrElementSpecific[1][4] and createAndGo to ClfrElementStatus[1][4] 8) link to ClfrEntry[1] by writing ^ClfrElementENtry[1][4] to ClfrElementNext[1][1] 9) read clfrelementnextfree (5) 10) create clfrSixTypleEntry[1][5] by writing and createAndGo to ClfrSixTupleStatus[1][5] 11) create clfrElementEntry[1][5] by writing ^ClfrSixTupleEntry[1][5] to ClfrElementSpecific[1][5] and createAndGo to ClfrElementStatus[1][5] 12) link to ClfrEntry[1] by writing ^ClfrElementENtry[1][5] to ClfrElementNext[1][4] We now have: ClfrEntry[1], ClfrSixTupleEntry[1][1], ClfrElementEntry[1][1] ClfrSixTupleEntry[1][4], ClfrElementEntry[1][4] ClfrSixTupleEntry[1][5], ClfrElementEntry[1][5] ClfrEntry[2], ClfrSixTupleEntry[2][2], ClfrElementEntry[2][2] ClfrEntry[3], ClfrSixTupleEntry[3][3], ClfrElementEntry[3][3] Each new Classifier element took four round trips to build Notice, first, that the second index of the classifier element was completely sufficient to make these unambiguous. Notice that apart from the DataPath Table (which I neglected to mention) we have no record of the start of any classifier. Now, let two NMS's simultaneously try to create a new classifier, and have to collide and recover. Call them A and B. 1) A and B each read clfrnextfree (4) and clfrelementnextfree (6) 2) A and B create clfrEntry[4] by writing createAndGo to ClfrStatus[4] A gets an acknowledgement B gets a failure 3a) A creates clfrSixTypleEntry[4][6] by writing and createAndGo to ClfrSixTupleStatus[4][6] 4a) A creates clfrElementEntry[4][6] by writing ^ClfrSixTupleEntry[4][6] to ClfrElementSpecific[4][6] and createAndGo to ClfrElementStatus[4][6] meanwhile, 3b) B reads clfrnextfree (5) and clfrelementnextfree (6) 4b) B creates clfrEntry[5] by writing createAndGo to ClfrStatus[5] 5b) B creates clfrSixTypleEntry[5][6] by writing and createAndGo to ClfrSixTupleStatus[5][6] 7b) B creates clfrSixTypleEntry[5][6] by writing and createAndGo to ClfrSixTupleStatus[5][6] 8b) A creates clfrElementEntry[5][6] by writing ^ClfrSixTupleEntry[5][6] to ClfrElementSpecific[5][6] and createAndGo to ClfrElementStatus[5][6] In this case, the classifier Id disambiguates two instances of classifierElementId=6. Now, let's redo that sequence assuming that the classifier table doesn't exist, and only the classifier element table exists. Again, two NMS's (A and B) simultaneously try to create a new classifier, and have to collide and recover. 1) A and B each read clfrnextfree (4) and clfrelementnextfree (6) 2) A and B each attempt to create clfrSixTupleEntry[4][6] by writing , and createAndGo to ClfrSixTupleStatus[4][6] A gets an acknowledge B gets a failure 3a) A creates clfrElementEntry[4][6] by writing ^ClfrSixTupleEntry[4][6] to ClfrElementSpecific[4][6] and createAndGo to ClfrElementStatus[4][6] 3b) B reads clfrnextfree (5) and clfrelementnextfree (7) 4b) B creates clfrSixTypleEntry[5][7] by writing , and createAndGo to ClfrSixTupleStatus[5][7] 5b) B creates clfrElementEntry[5][7] by writing ^ClfrSixTupleEntry[5][7] to ClfrElementSpecific[5][7] and createAndGo to ClfrElementStatus[5][7] There are several differences between the two cases: a) with the classifier table, it is possible to have an error condition in which a classifier exists but contains no elements; if the classifier table does not exist, this is not possible b) with the classifier table, the recovering system took eight round trips to create a classifier; without it, the recovering system took only five. c) with the classifier table, any classifier creation takes four round trips, but without it such a thing only takes three. d) with the classifier table, in the special case that two NMS's try to configure the device simultaneously, the classifier Id disambiguates the classifier element Id. However, without the classifier table, the ambiguity doesn't exist and so does not need to be disambiguated. I now go on to mention the other things that bother me. In draft 9, the only readable attribute in the classifier table is the RowStatus variable; the classifier entry can be used to create or delate a classifier, and if you read the RowStatus variables I suppose that you can determine what classifiers exist. Each of these things can be done using the classifier element table. Therefore, the complexity I have described the classifier table as creating comes with no redeeming value in terms of something that cannot be done by another part of the MIB. I noted earlier that clfrElementId is sufficient to disambiguate classifiers; the classifier number itself contributed nothing to making the structure unambiguous. If we keep the classifier ID at all, that argues that it should be an attribute of the classifier element ("I am a member of this classifier") rather than an integer extending the name (an index of) of the classifier element. I'm easily argued into keeping it as an attribute; I'm far less sure of it as a reasonable index. If instead of creating ClfrEntry[1], ClfrSixTupleEntry[1][1], ClfrElementEntry[1][1] ClfrSixTupleEntry[1][4], ClfrElementEntry[1][4] ClfrSixTupleEntry[1][5], ClfrElementEntry[1][5] ClfrEntry[2], ClfrSixTupleEntry[2][2], ClfrElementEntry[2][2] ClfrEntry[3], ClfrSixTupleEntry[3][3], ClfrElementEntry[3][3] we wanted to create ClfrEntry[1], ClfrSixTupleEntry[1][1], ClfrElementEntry[1][1] ClfrSixTupleEntry[1][2], ClfrElementEntry[1][2] ClfrSixTupleEntry[1][3], ClfrElementEntry[1][3] ClfrEntry[2], ClfrSixTupleEntry[2][1], ClfrElementEntry[2][1] ClfrEntry[3], ClfrSixTupleEntry[3][1], ClfrElementEntry[3][1] then we need to have a clfrElementNextFree instance per classifier; this would require that clfrElementNextFree become an attribute of the classifier (an object in the clfrEntry). It would also mean that we cannot read clfrNextFree and clfrElementNextFree in the same read; we would either read clfrNextFree and then read clfrElementNextFree[clfrNextFree] (an extra round trip) or read clfrNextFree and assume that clfrElementNextFree[clfrNextFree] could be assumed to be one. Leaving that by the side, I observed that we have the DataPathStartTable to tell us where a given data path starts, but we don't have a corresponding attribute that tells us what the first element in any given classifier is. This can be deduced, so it is not a showstopper, but deducing it requires some effort. One could argue that there should exist a ClfrDataPathStart object to indicate this head-of-list. What I have done is left the classifier table in, which I think adds a huge amount of gratuitous complexity. My conscience will not let me visit this on the world without any redeeming social value, so I have added a clfrDataPathStart attribute. Whether that actually justifies the gratuitous complexity or not is a judgement call that I'm not prepared to make. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Jul 20 15:14:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA05689 for ; Fri, 20 Jul 2001 15:14:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10933; Fri, 20 Jul 2001 14:15:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10905 for ; Fri, 20 Jul 2001 14:15:47 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16519 for ; Fri, 20 Jul 2001 14:14:51 -0400 (EDT) Received: from FRED-W2K.cisco.com ([171.71.21.235]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f6KIFRT21531 for ; Fri, 20 Jul 2001 11:15:27 -0700 (PDT) Message-Id: <5.1.0.14.2.20010720024857.026b1240@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 20 Jul 2001 11:15:12 -0700 To: diffserv@ietf.org From: Fred Baker Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by sj-msg-core-2.cisco.com id f6KIFRT21531 X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA10906 Subject: [Diffserv] MIB Comments from Kwok Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org X-MIME-Autoconverted: from 8bit to quoted-printable by optimus.ietf.org id OAA10933 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA05689 On the MIB I am posting today, Kwok has made a number of comments that I have not had the cycles to correct. These are comments on an interim document that I circulated among the authors, and some of them don't quite apply to the current draft. However, rather than making Kwok sort through them and reword for the posted draft, I simply post the comments. You will see in a separate note that I have been scratching my head about the classifier table; several folks have complained about complexity in using the MIB as designed, and I think this particular table is a major contributor there. There are some comments in this list that apply if and only if we decide to remove the classifier table from the MIB, as I did in the interim draft. >Title: Review Results of draft-ietf-diffserv-mib-10.txt 06/12/2001 Version >Author: Kwok Ho Chan >Date: 07/02/2001 > > >Comments for the Text Sections: >1. Pg 3 Sec 2.1 Last Paragraph. "The Data Path Start Table provides >a starting …", it should be "The Data Path Table provides…". >2. Pg 4 Sec 2.2 2nd Paragraph. "Other MIBs and data structure >definitions … the model in other ways.", please change to "Other MIBs and >data structure … the model in other ways, for example, [DSPIB]. >3. Pg 5 Sec 3 Last Paragraph, Last Sentence. "Similarly, if a new >action is required, the "next" pointer of the previous functional datapath >element could point to an Entry defined in a proprietary MIB or one >defined in another standard." Is misleading. If new Action is required, >new Action Parameterization Table/Entry can be defined in some other MIB, >and diffServActionTable/Entry does not need to be changed. As I am >thinking for this part of the paragraph you are trying to express how a >new Data Path Functional Element (the first part of the paragraph already >gave a new parameterization table example) can be defined, I think using >the Queuing structure may be a better example. Hence I propose to replace >the affect sentence with "Similarly, if a device uses a completely >different Queuing Architecture, the "next" pointer of the previous >functional datapath element could point to a Queuing datapath functional >element table entry defined in a proprietary MIB or one defined in another >standard." >4. Pg 7 Sec 3.2.1 Second Paragraph. Classifier. >5. Pg 8 Sec 3.2.1 Last Paragraph. Classifier >6. Pg 8 Sec 3.2.2 First Paragraph. "This classifier >matches:", should we use "This filter matches:" ?? >7. Pg 9 Sec 3.3 First Paragraph. "However, various factors ... >multiple classes of traffic may occasionally schedule their traffic and >the same time," typo, should be "schedule their traffic at the same >time,". Also need consistent usage of quoting "meter" and "shaper". >8. Pg 11 Sec 3.3.2. Spelling error "montonically" should be >"monotonically". >9. Pg 12 Sec 3.4. "create-and-go" and "create-and-wait" sometimes >have extra space after the "-". There are other instances of this in >other parts of the text using "create-and-XXX". This is a nroff feature, >correct? >10. Pg 13 Sec 3.4.3. "I might be viewed not …" should be "It might be >viewed not …". >11. Pg 14 Bottom. Numbering the picture Figure 1. >12. Pg 15 Sec 3.4.5. Usage of DiffServRandomDropInvWeight, should use >diffServRandomDropWeight as in the MIB module. Also uppercase MIB >attribute name "DiffServ.." should be changed back to lowercase >"diffServ…" in multiple places. >13. Pg 16 Sec 3.5.1 Third Paragraph. "… as in Section .sh 4 " The >parameter is associated with the queue, however, using the Assured or >Shaping Rate Parameter Table." need some fixing. >14. Pg 16 Sec 3.5.1 Last Paragraph. "agent- specific" extra space >after the dash. >15. Pg 17 Sec 3.5.3 First Paragraph. How about replacing "This MIB >assumes excess capacity is distributed proportionally among the inputs to >a scheduler." with "This MIB assumes excess capacity is distributed >proportionally among the inputs to a scheduler using the assured >rate. More complex excess capacity handling may be described by >augmenting this MIB." >16. Pg 17 Sec 3.5.3 Second Paragraph. "The effect of combining >priority and rate …" paragraph is not very clear, may need more explanation. >17. Pg 18 Sec 3.5.4 Second Paragraph. "In this case, an algorithm such >as SHAPING" should be "In this case, an algorithm such as [SHAPER]". >18. Pg 18 Sec 3.5.5 Second Paragraph. "For Weighed Queuing methods", >should we use "For Weighted Scheduling methods"? >19. Pg 18 Bottom. Numbering the picture Figure 2. >20. Pg 19 Sec 3.5.5 at top of page. "The rate may be represented by a >relative value, as a fraction of the interface's current line >rate. DiffServAssuredRateRel to assist …" should be "The rate may be >represented by a relative value, diffServAssuredRateRel, as a fraction of >the interface's current line rate to assist …". >21. Pg 19 Sec 3.5.5 at top of page. "An example is found in figure >4.". Should this be changed to Figure 3? >22. Pg 19 Sec 3.5.5 Fourth Paragraph. "MODEL" should be >"[MODEL]". Also in other places in the draft. >23. Pg 19 Bottom. Numbering the picture Figure 3. >24. Pg 20 Bottom. Numbering the top picture Figure 4, the bottom >picture Figure 5. Should the terms Max Rate, Maximum Rate, Min Rate be >changed to Assured Rate and Shaping Rate as used in the MIB module? Also >moving the Figures closer to where they are referenced will help, but may >do this as the last thing as moving pictures in nroff is not that fun. >25. Pg 21 First Two Paragraphs. "Queue Table entries …" and "A common >requirement of a queue …" are extra cut and paste repeating Section 3.5.1 >Paragraph 2. >26. Pg 21 Last sentence before Sec 3.6. "See figure 4." should be >"See Figure 6." >27. Pg 21 Bottom. Number the picture Figure 6 and put it before >Section 3.6. >28. Pg 22 Sec 3.6.1. "dealth" should be "dealt". >29. Pg 22 Sec 3.6.1.1. The paragraph "An example of a classifier for >an AFm …" can also be described with "A single Classifier with 13 >Classifier Elements: 1 EF Classifier Element, 12 AF Classifier Elements >(4 AFm with m={1,2,3}). But this have to do with keeping >ClassfierTable/Entry or not. >30. Pg 22 Bottom. Numbering the picture Figure 7 and moving it to >before Section 3.6.1.1. >31. Pg 23 Sec 3.6.1.1. Third Paragraph. "parameter blocks spedifying >individual telephone calls". Not sure we want to make such a suggestion >or example. I didn't think this is the right thing to do but there are a >lot of things I don't know of. >32. Pg 23 Sec 3.6.1.2 and 3.6.1.2.1. "Each Afm" should be "Each AFm". >33. Pg 24 Sec 3.6.1.2.2 and 3.6.1.3.2. "To indicate this, we set the >"SucceedNext" pointer of the Mark Action is left at ZeroDotZero." Should >be "To indicate this, the "SucceedNext" pointer of the Mark Action is left >at ZeroDotZero.". >34. Pg 25 Top. Number the picture Figure 8. >35. Pg 26 Sec 3.7.1 Second and Third Paragraphs. "An example of a >classifier for an AFm class would be a succession of three classifier >elements, …". How does this works? I think each classifier element of >an AFm class must have the same Classifier ID to indicate they are to be >evaluated together. From outside of the box, the evaluation needs to look >like being done together, not in succession, hence the use of Classifier >Table/Entry (keeping it). >36. Pg 26 Sec 3.7.2 and 3.7.2.1. "Each Afm" should be "Each AFm". >37. Pg 29 Sec 4.1 First Paragraph. "One of the ways it this MIB" >should be "One of the ways this MIB". >38. Pg 29 Sec 4.1 Second, Third Paragraphs and in Note --. "MODEL" >should be "[MODEL]". >39. Pg 29 Sec 4.1 Third Paragraph. "that suchconfiguration" should be >"that such configureation". >40. Pg 30 Sec 5 Last Paragraph. "one. counter actions." cleanup. >41. Pg 104 Sec 9 Reference. The spell checker 'in-corrected' >"draft-ietf-diffserv-…" into "draft-ietf-Differentiated Services-…". >42. Pg 105 Sec 9 Reference. "MODEL" should be "[MODEL]". >Title: Review Results #2 of draft-ietf-diffserv-mib-10.txt 06/12/2001 >Version >Author: Kwok Ho Chan >Date: 07/11/2001 > > >The Review Results in this memo is IN ADDITION to the Review Results dated >07/02/2001. Hence the comments numbering continues with 43. > >More Comments for the Text Sections: >43. Pg 6 Sec 3.1.1 Last Paragraph. Use of "ZeroDotZero" in the text >sections should be "zeroDotZero". Also on Pg 7(twice), 11, 24(twice), >65(diffServAlgDropType). >44. Pg 6 Sec 3.2 End of 3rd Paragraph. Current: "all classification >elements of one precedence are applied as if in parallel, and then all >classification elements of the next precedence." Suggest new text: >"within a single classifier, all classification elements of one precedence >are applied as if in parallel (the logical AND operation), and then all >classification elements of the next precedence (the logical OR operation)." > >Comments for the MIB Module: >45. Usage of "Differentiated Services Functional Data Path Elements" >and "Differentiated Services Functional Data Path elements" be more consistent. >46. Pg 38 Classifier Table explanation text. After removal of >diffServClfrTable/Entry, Classifier Table does not exist anymore, only the >concept remains with the use of diffServClfrElementClfrId. The >explanation text at the top of the MIB classifier section (and the section >name itself) needs to be re-worded. >47. Pg 38 diffServClfrNextFree, Description Clause. "diffServClfrId" >should be "diffServClfrElementClfrId". "diffServClfrTable" don't exist >anymore. >48. Pg 40 diffServClfrElementClfrId, Description Clause. "… >enumerates the classifier entries", what entries? (I want the entries.) >49. Pg 40 diffServClfrElementClfrId and diffServClfrElementId >attribute numbering swapped. >50. Pg 42 diffServClfrElementStatus, Description Clause. "writ- able" >side effect of auto text formatting. You may want to search for other >occurrence of "- ". >51. Pg 43-44 diffServSixTupleClfrEntry. Attribute numbering need fixing. >52. Pg 47 Meters Section description, srTCM, trTCM, and tswTCM >writeups. Can we change them to: "srTCM meters (RFC 2697) can be >specified using two sets of diffServMeterEntry and diffServTBParamEntry. >First set specifies the Committed Information Rate and Committed Burst >Size token-bucket. Second set specifies the Excess Burst Size >token-bucket." "trTCM meters (RFC 2698) can be specified using two sets >of diffServMeterEntry and diffServTBParamEntry. First set specifies the >Committed Information Rate and Committed Burst Size token-bucket. Second >set specifies the Peak Information Rate and Peak Burst Size >token-bucket." "tswTCM meters (RFC 2859) can be specified using two sets >of diffServMeterEntry and diffServTBParamEntry. First set specifies the >Committed Target Rate token-bucket. Second set specifies the Peak Target >Rate token-bucket. diffServTBParamInterval in each token bucket reflects >the Average Interval." >53. Pg 47 Meters Section description. the "" that ends the >descpription section (the line below "diffServMeter") needs to be moved to >before "diffServMeterNextFree". >54. Pg 48-51. Since diffServShapingRateTable/Entry is introduced, >diffServMeter and diffServTBParamTable will not be used for shaping >purpose, hence removing any reference to shaping. Specifically: >Pg 48 diffServMeterTable Description Clause. "may use to police, or >shape, a stream" should be "may use to police a stream". >Pg 50 diffServTBParam Description Section. "shared by multiple >diffServMeterTable and diffServSchedulerTable entries" should be "shared >by multiple diffServMeterTable entries". >Page 51 diffServTBParamTable Description Clause. "may use to police or >shape a stream" should be "may use to police a stream". >55. Pg 52 diffServTBParamType Description Clause. "OBJECT-IDENTITYS" >should be "OBJECT-IDENTITYs". >56. Pg 52 diffServTBParamRate Description Clause. "2. PIR and CIR in >RFC 2698…" should be "2. CIR and PIR in RFC 2698…". >57. Pg 53 diffServTBParamSimpleTokenBucket Description >Clause. Replace "The value tokenBucket (2) indicates" with "Indicates". >58. Pg 53 diffServTBParamAvgRate Description Clause. Replace "The >value avgRate (3) indicates" with "Indicates". >59. Pg 54 diffServTBParamSrTCMBlind Description Clause. Replace "The >values srTCMBlind (4) and srTCMAware (5) indicate" with >"Indicates". Replace "in either the 'Color Blind' and 'Color Aware' mode" >with "in the 'Color Blind' mode". >60. Pg 54 diffServTBParamSrTCMAware Description Clause. Replace "The >values srTCMBlind (4) and srTCMAware (5) indicate" with >"Indicates". Replace "in either the 'Color Blind' and 'Color Aware' mode" >with "in the 'Color Aware' mode". >61. Pg 54 diffServTBParamTrTCMBlind Description Clause. Replace "The >values trTCMBlind (6) and trTCMAware (7) indicate" with >"Indicates". Replace "in either the 'Color Blind' and 'Color Aware' mode" >with "in the 'Color Blind' mode". >62. Pg 54 diffServTBParamTrTCMAware Description Clause. Replace "The >values trTCMBlind (6) and trTCMAware (7) indicate" with >"Indicates". Replace "in either the 'Color Blind' and 'Color Aware' mode" >with "in the 'Color Aware' mode". >63. Pg 54 diffServTBParamTswTCM Description Clause. Replace "The >value tswTCM (8) indicates" with "Indicates". >64. Pg 57 diffServActionNext Description >Clause. "diffServAlgDropEntry" was removed, reasoning? Let me try to >answer this: After removing AlwaysDrop Action and with counters in AlgDrop >, it will not make sense to put Action before AlgDrop. One will always >perform AlgDrop before MarkAct. Correct? Do we want to put such a limit >on linking Action before AlgDrop? >65. Pg 59 Count Action Table Description Section. "for example before >a drop action", AlwaysDropAct don't exist anymore, hence this phase should >be removed. >66. Pg 65 diffServAlgDropType Description Clause. "In the randomDrop >(4) … diffServAlgQThreshold" should be "diffServAlgDropQThreshold". "The >alwaysDrop (5) … There is no useful the queue are not useful. Therefore," >should be "In this case the queue is not used, therefore". And some >typos: "diffServAlgQNext" should be "diffServAlgDropNext", >"diffServAlgQMeasure" should be "diffServAlgDropQMeasure", >"diffServAlgQSpecific" should be "diffServAlgDropSpecific". Also >"ZeroDotZero" should be "zeroDotZero". >67. Pg 68 diffServAlgDropStatus. "{ diffServAlgDropEntry 11 }" should >be "{ diffServAlgDropEntry 12 }". >68. Pg 78 diffServSchedulerPriority Description Clause. "When the >next scheduler …" should be "For use with diffServSchedulerMethod when the >next scheduler …". >69. Pg 80 diffServAssuredRatePriority Description Clause. How about >adding a phase "Higher Priority value indicates the associated >queue/scheduler will get service first before others with lower Priority >values.". >70. Pg 81 diffServAssuredRateRel Description Clause. "in units of >1/1000 of 1." should be "in units of 1/10,000 of 1" as in DSMIB-09. >71. Pg 81 diffServAssuredRateAbs/Rel and diffServShapingRateAbs/Rel >Description Clause. IFMIB/RFC2233 have ifSpeed as Garge32 in units of >bits per second, and ifHighSpeed as Garge32 in units of 1,000,000 bits per >second. This yields the following equations: >RateRel = [ (RateAbs * 1000) / ifSpeed ] * 10,000 >Where 1000 is for converting kbps used by RateAbs to bps used by ifSpeed, >10,000 is for "in units of 1/10,000 of 1" for RateRel. >And > RateRel = { [ (RateAbs * 1000) / 1,000,000 ] / ifHIghSpeed } * 10,000 >Where 1000 and 1,000,000 is for converting kbps used by RateAbs to 1 >million bps used by ifHighSpeed, 10,000 is for "in units of 1/10,000 of 1" >for RateRel. >Laying all the numbers out and with the explanation should minimize the >confusion. >72. Pg 83 Shaping Parameter Table Description Section Second >Paragraph. "positing" do you mean "positioning"? _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Jul 23 09:51:30 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20771 for ; Mon, 23 Jul 2001 09:51:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA25863; Mon, 23 Jul 2001 08:47:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA07484 for ; Fri, 20 Jul 2001 12:37:28 -0400 (EDT) Received: from iraun1.uka.de (iraun1.uka.de [129.13.10.90]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21560 for ; Fri, 20 Jul 2001 12:36:32 -0400 (EDT) Received: from i72pc127.tm.uni-karlsruhe.de by iraun1 (PP) with ESMTP; Fri, 20 Jul 2001 18:37:18 +0200 Received: from i72pc127.tm.uni-karlsruhe.de (localhost [127.0.0.1]) by i72pc127.tm.uni-karlsruhe.de (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id f6KGbHt11790; Fri, 20 Jul 2001 18:37:17 +0200 Message-Id: <200107201637.f6KGbHt11790@i72pc127.tm.uni-karlsruhe.de> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.3 To: Brian E Carpenter cc: diffserv@ietf.org Subject: Re: [Diffserv] I-D ACTION:draft-bless-diffserv-mcast-routerext-00.txt (fwd) In-Reply-To: Message from Brian E Carpenter of "Fri, 20 Jul 2001 10:02:44 CDT." <3B584814.AF21DF29@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 20 Jul 2001 18:37:17 +0200 From: Roland Bless Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Brian, > Have you discussed with the Routing ADs how to follow up on this? > That is certainly something to do in London. Yes, I followed Kathie's advice to contact them in order to get a hint for an appropriate WG for discussion of this issue. So we already contacted the Routing ADs by e-mail, but Rob wanted to know something about the operational requirements for this work (this was before we wrote the draft). Therefore, we'd like to get feedback from the community. However, we are looking forward to discuss about it in London. Roland P.S.: Will the diffserv WG meet in London? I didn't see any agenda yet. > Brian > > Roland Bless wrote: > > > > Hi, > > > > when looking back to 46th IETF meeting minutes, there are still > > some open multicast issues. This short proposal might be of interest > > for some people here. It would be nice to get any feedback from people > > here, especially manufacturers of routers. > > > > Regards, > > Roland > > > > P.S.: Sorry, I currently don't know any other WG that is more appropriate > > for discussion of this issue. > > > > ------- Forwarded Message > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > > Title : A Router Extension to Support Multicast in > > Differentiated Services Networks > > Author(s) : R. Bless, K. Wehrle > > Filename : draft-bless-diffserv-mcast-routerext-00.txt > > Pages : 4 > > Date : 16-Jul-01 > > > > This draft proposes an extension to the multicast routing table in > > routers in order to achieve better support for using multicast > > within Differentiated Services (DS) networks. Only one additional DS > > codepoint for each virtual interface in the multicast routing table > > is required to open up a variety of different uses, e.g., to solve > > resource provisioning problems or to support heterogeneous DiffServ > > multicast groups. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-bless-diffserv-mcast-routerext-00.txt -- Roland Bless -- e-Mail: bless@tm.uka.de Institute of Telematics, University of Karlsruhe, Germany Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358 Phone: +49 721 608-6413 Fax: +49 721 388097 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Jul 23 15:21:04 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17624 for ; Mon, 23 Jul 2001 15:21:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA08175; Mon, 23 Jul 2001 14:16:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA08144 for ; Mon, 23 Jul 2001 14:16:53 -0400 (EDT) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12738 for ; Mon, 23 Jul 2001 14:15:58 -0400 (EDT) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6NIHVI25577 for ; Mon, 23 Jul 2001 13:17:41 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Mon, 23 Jul 2001 13:16:43 -0500 content-class: urn:content-classes:message Date: Mon, 23 Jul 2001 13:13:20 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: silent drop vs. drop with notice X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Index: AcEToyFqp/Ycjn9tEdWJjQAGKRXvpA== From: "Li Man.M (NRC/Boston)" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA08145 Subject: [Diffserv] silent drop vs. drop with notice Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 8bit Hi, It seems to me that both Diffserv PIB and MIB specify an absolute drop action meaning "silently discards". See for example section 4.5.2 of Diffserv PIB. Some devices support two types of drops: 1) silent drop without notifying sender 2) drop and notify sender It would be helpful to distinguish these two cases in Diffserv PIB and MIB as well. It can be done by simply adding a new codepoint. Man Li Nokia 5 Wayside Road, Burlington, MA 01803 man.m.li@nokia.com phone 1-781-993-3923 GSM 1-781-492-2850 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Jul 23 16:16:54 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21005 for ; Mon, 23 Jul 2001 16:16:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10774; Mon, 23 Jul 2001 15:36:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10743 for ; Mon, 23 Jul 2001 15:36:07 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18385 for ; Mon, 23 Jul 2001 15:35:10 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id UAA14216; Mon, 23 Jul 2001 20:35:35 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id UAA19162; Mon, 23 Jul 2001 20:35:34 +0100 Message-ID: <3B5C7B0F.BEB70BE3@hursley.ibm.com> Date: Mon, 23 Jul 2001 14:29:19 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Li Man.M (NRC/Boston)" CC: diffserv@ietf.org Subject: Re: [Diffserv] silent drop vs. drop with notice 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Hi, The Internet doesn't tell you when it drops a packet. I don't think diffserv is going to change this. Brian "Li Man.M (NRC/Boston)" wrote: > > Hi, > > It seems to me that both Diffserv PIB and MIB specify an absolute drop > action meaning "silently discards". See for example section 4.5.2 of > Diffserv PIB. > > Some devices support two types of drops: > 1) silent drop without notifying sender > 2) drop and notify sender > > It would be helpful to distinguish these two cases in Diffserv PIB and > MIB as well. It can be done by simply adding a new codepoint. > > Man Li > Nokia > 5 Wayside Road, Burlington, MA 01803 > man.m.li@nokia.com > phone 1-781-993-3923 > GSM 1-781-492-2850 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Jul 23 16:25:24 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21348 for ; Mon, 23 Jul 2001 16:25:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA11154; Mon, 23 Jul 2001 15:51:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA11124 for ; Mon, 23 Jul 2001 15:51:11 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19279 for ; Mon, 23 Jul 2001 15:50:17 -0400 (EDT) Received: from FRED-W2K.cisco.com ([171.71.21.235]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f6NJoqT01185; Mon, 23 Jul 2001 12:50:52 -0700 (PDT) Message-Id: <5.1.0.14.2.20010723123832.08063e88@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 23 Jul 2001 12:41:20 -0700 To: "Li Man.M (NRC/Boston)" From: Fred Baker Subject: Re: [Diffserv] silent drop vs. drop with notice Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 11:13 AM 7/23/2001, Li Man.M (NRC/Boston) wrote: >2) drop and notify sender silly question: how is the sender notified? If it is with an ICMP message, what ICMP message, specified by what RFC? How does this play when a DDOS attack is causing the drops? Does it spread the DDOS attack to each of the drone sites as well as the attacked site? I'll happily support an IETF standard if you can point me to it, but not a proprietary behavior whose use is inadvisable in the Internet. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Jul 24 00:44:04 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA12368 for ; Tue, 24 Jul 2001 00:44:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA23258; Tue, 24 Jul 2001 00:04:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA23236 for ; Tue, 24 Jul 2001 00:04:38 -0400 (EDT) Received: from interceptor.mahinetworks.com (216-174-224-194.atgi.net [216.174.224.194]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA11232 for ; Tue, 24 Jul 2001 00:03:45 -0400 (EDT) Received: from 172.16.0.40 by interceptor.mahinetworks.com (InterScan E-Mail VirusWall NT); Mon, 23 Jul 2001 21:04:38 -0700 Received: by main.mahinetworks.com with Internet Mail Service (5.5.2650.21) id <3XVB0SXW>; Mon, 23 Jul 2001 21:04:49 -0700 Message-ID: <9D6D37E97A57D411BB7C00508BAE29C992150A@main.mahinetworks.com> From: Jayaram Beladakere To: diffserv@ietf.org Date: Mon, 23 Jul 2001 21:04:48 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] Token bucket meters Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Referring to the discussions on token buckets in Diffserv Informal Management Model, Feb. 2001. There is description of a packet of length L arriving at time t' (Appendix A.4). Is there any assumption about when t' should be taken? That is, is t' the time of arrival of the first byte of the packet or the last byte of the packet? Does this selection of time matter for the operation of token bucket? Is one selection preferable? Regards, Jayaram Beladakere Mahi Networks, Inc. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Jul 24 04:21:13 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03736 for ; Tue, 24 Jul 2001 04:21:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA06548; Tue, 24 Jul 2001 03:29:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA06517 for ; Tue, 24 Jul 2001 03:29:40 -0400 (EDT) Received: from iraun1.uka.de (iraun1.uka.de [129.13.10.90]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03132 for ; Tue, 24 Jul 2001 03:28:45 -0400 (EDT) Received: from i72pc127.tm.uni-karlsruhe.de by iraun1 (PP) with ESMTP; Tue, 24 Jul 2001 09:29:36 +0200 Received: from i72pc127.tm.uni-karlsruhe.de (localhost [127.0.0.1]) by i72pc127.tm.uni-karlsruhe.de (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id f6O7Tat02292; Tue, 24 Jul 2001 09:29:36 +0200 Message-Id: <200107240729.f6O7Tat02292@i72pc127.tm.uni-karlsruhe.de> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.3 To: "Manfredi, Albert E" cc: diffserv@ietf.org Subject: Re: [Diffserv] I-D ACTION:draft-bless-diffserv-mcast-routerext-00 .txt (fwd) In-Reply-To: Message from "Manfredi, Albert E" of "Mon, 23 Jul 2001 10:15:36 EDT." <8D6509B44ACCEB43A96E032B9C3EA0C8021F560C@xch-ne-02.ne.nos.boeing.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 24 Jul 2001 09:29:36 +0200 From: Roland Bless Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Albert, > This I-D makes the case for allowing individual DS codepoints for each DS > tunnel or physical interface used by a multicast router to distribute IP > multicast packets. Yes. > You say in your I-D: > > A virtual interface means in this context, > that it is either a multicast tunnel or a real physical network > interface. So there may be several configured tunnels over one > physical interface present. The multicast routing table entry > contains usually information about the multicast group address > (destination address), source address and (virtual) outgoing > interfaces where packets should be copied to during packet > forwarding. > > I believe that a "virtual interface" in the context of this I-D might > potentially be defined as any combination of source and destination IP > address, source and destination UDP port ID, incoming DS codepoint, _and_ > outgoing physical interface? (The Protocol field will always indicate UDP.) Yes, the entry should basically identify the pair of tunnel endpoints. Personally, I don't think it's a good idea to assume always UDP as protocol. We don't know what mcast-capable transport protocols will be used instead of UDP one day in future. > If you agree with this, perhaps the word "only" in the abstract: > > Only one additional DS > codepoint for each virtual interface in the multicast routing table > is required to open up a variety of different uses, ... > > should be deleted. This could be a large number of additional codepoints, in > principle. I disagree here, because it really depends on how many tunnel endpoints or branches you have. "Only" means the overhead compared to one complete entry/row in the multicast routing table that describes a virtual interface. So one additional byte for the DSCP in comparison to your above list of source/dest IP addresses and ports (which are already 12 bytes for IPv4) is not that much... So if you have a large number of additional codepoints you'll also have a large number of virtual interfaces anyway, and that's why the overhead is still small in relation to the whole multicast routing table. Regards, Roland -- Roland Bless -- e-Mail: bless@tm.uka.de Institute of Telematics, University of Karlsruhe, Germany Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358 Phone: +49 721 608-6413 Fax: +49 721 388097 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Jul 24 06:57:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA07777 for ; Tue, 24 Jul 2001 06:57:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA11406; Tue, 24 Jul 2001 06:29:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA11375 for ; Tue, 24 Jul 2001 06:29:51 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05801; Tue, 24 Jul 2001 06:28:54 -0400 (EDT) Message-Id: <200107241028.GAA05801@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: diffserv@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 24 Jul 2001 06:28:53 -0400 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-pdb-ar-01.txt Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Differentiated Services Working Group of the IETF. Title : An Assured Rate Per-Domain Behaviour for Differentiated Services Author(s) : N. Seddigh et al. Filename : draft-ietf-diffserv-pdb-ar-01.txt Pages : 8 Date : 23-Jul-01 This document describes a diffserv per-domain behaviour (PDB) called Assured Rate (AR). The AR PDB is suitable for carrying traffic aggregates that require rate assurance but do not require delay and jitter bounds. The traffic aggregate will also have the opportunity to obtain excess bandwidth beyond the assured rate. The PDB can be created using the diffserv AF PHB along with suitable policers at the domain ingress nodes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-pdb-ar-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-diffserv-pdb-ar-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-diffserv-pdb-ar-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010723140328.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-pdb-ar-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-pdb-ar-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010723140328.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Jul 24 10:24:37 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20227 for ; Tue, 24 Jul 2001 10:24:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA18297; Tue, 24 Jul 2001 09:57:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA18266 for ; Tue, 24 Jul 2001 09:56:56 -0400 (EDT) Received: from father.pmc-sierra.bc.ca (father.pmc-sierra.bc.ca [216.241.224.13]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18105 for ; Tue, 24 Jul 2001 09:55:58 -0400 (EDT) Received: (qmail 15840 invoked by uid 104); 24 Jul 2001 13:56:25 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.40765 secs); 24/07/2001 06:56:25 Received: from unknown (HELO plymouth.pmc-sierra.bc.ca) (134.87.114.227) by father.pmc-sierra.bc.ca with SMTP; 24 Jul 2001 13:56:25 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by plymouth.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f6ODuWP18758; Tue, 24 Jul 2001 06:56:32 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jul 2001 07:02:26 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D9F@BBY1EXM01> From: Shahram Davari To: "'Jayaram Beladakere'" , diffserv@ietf.org Subject: RE: [Diffserv] Token bucket meters Date: Tue, 24 Jul 2001 07:02:23 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Jayaram, My understanding is that Appendix A.4 assumes that "t'" is the time that the last byte of the packet is received. This is called a strict token bucket. The draft also talks about a loose token bucket in which, you accept the packet without knowing its length, and after you receive the whole packet and you know the exact size of the packet, then you adjust the number of tokens, possibly to a negative value to account for packets that required more tokens that existed at the time of their arrival. The Strict and Loose TB are the extreme ends of the possible TB implementation. Any other implementation is probably something in between. Therefore it is perfectly acceptable to assume "t'" being the time of arrival of the first byte of the packet if you know the length of the packet in advance (which may not be practical with variable length IP packets), or if you guess the size of the packet, etc. So my answer is that the implementation is not a matter of standard, rather a matter of engineering compromise, practicality and taste. Yours, -Shahram > -----Original Message----- > From: Jayaram Beladakere [mailto:jbeladakere@mahinetworks.com] > Sent: Tuesday, July 24, 2001 12:05 AM > To: diffserv@ietf.org > Subject: [Diffserv] Token bucket meters > > > Referring to the discussions on token buckets in Diffserv Informal > Management Model, Feb. 2001. There is description of a > packet of length L > arriving at time t' (Appendix A.4). Is there any assumption > about when t' > should be taken? That is, is t' the time of arrival of the > first byte of > the packet or the last byte of the packet? Does this > selection of time > matter for the operation of token bucket? Is one selection > preferable? > > Regards, > Jayaram Beladakere > Mahi Networks, Inc. > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > http://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/curr ent/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Jul 24 12:06:14 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA27523 for ; Tue, 24 Jul 2001 12:06:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21134; Tue, 24 Jul 2001 11:38:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21103 for ; Tue, 24 Jul 2001 11:38:34 -0400 (EDT) Received: from malmo.trab.se (malmo.trab.se [131.115.48.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25489 for ; Tue, 24 Jul 2001 11:37:35 -0400 (EDT) Received: from lulea.trab.se (oriander.lulea.trab.se [131.115.47.4]) by malmo.trab.se (8.10.1/TRAB-primary-2) with ESMTP id f6OFalP27368; Tue, 24 Jul 2001 17:36:47 +0200 (MEST) Received: from telia.se ([131.115.146.20]) by lulea.trab.se (8.9.1a/TRAB-secondary-1) with ESMTP id RAA20928; Tue, 24 Jul 2001 17:38:32 +0200 (MET DST) Message-ID: <3B5D96AA.50AA32B4@telia.se> Date: Tue, 24 Jul 2001 17:39:22 +0200 From: Anders Bergsten Organization: Telia Research AB X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Fred Baker CC: diffserv@ietf.org Subject: Re: [Diffserv] new MIB draft References: <5.1.0.14.2.20010720111322.0278ef00@mira-sjcm-2.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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Fred, I have a quick question that I have been thinking about: I was looking through the statistics that you collect in the MIB for random droppers (diffServAlgDropPkts, diffServAlgDropHCPkts and the two for Octets) and, if I understood it correctly, you do not differentiate between 'random drops', drops caused by exceeding max_th (diffServRandomDropMaxThreshBytes), and drops caused by exceeding the queue depth. As I understand RED algorithms, there is a hugh difference between these types of drops; exceeding max_th should rarely occur. If it does, then I should take some action (either increase max_p or move min_th or max_th). Drops due to exceeding the queue depth should never occur. On the other hand true random drops are ok. Wouldn't it be sensible to separate these three types of drops in the MIB and have a counter for each? I mean, for me as an operator they give different types of information and should be treated separately. Anders _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Jul 24 12:55:44 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01830 for ; Tue, 24 Jul 2001 12:55:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23059; Tue, 24 Jul 2001 12:27:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22979 for ; Tue, 24 Jul 2001 12:27:26 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29228 for ; Tue, 24 Jul 2001 12:26:26 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id RAA22220; Tue, 24 Jul 2001 17:26:45 +0100 Received: from hursley.ibm.com (gsine08.us.sine.ibm.com [9.14.6.48]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id RAA74566; Tue, 24 Jul 2001 17:26:43 +0100 Message-ID: <3B5DA11A.C9ECE457@hursley.ibm.com> Date: Tue, 24 Jul 2001 11:23:54 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Shahram Davari CC: "'Jayaram Beladakere'" , diffserv@ietf.org Subject: Re: [Diffserv] Token bucket meters References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6D9F@BBY1EXM01> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Correct. The model is *informal* and doesn't attempt to standardise this with mathematical precision, since different vendors might prefer different solutions. Brian Shahram Davari wrote: > > Jayaram, > > My understanding is that Appendix A.4 assumes that "t'" is the time that the last byte of the packet is received. This is called a strict token bucket. > > The draft also talks about a loose token bucket in which, you accept the packet without knowing its length, and after you receive the whole packet and you know the exact size of the packet, then you adjust the number of tokens, possibly to a negative value to account for packets that required more tokens that existed at the time of their arrival. > > The Strict and Loose TB are the extreme ends of the possible TB implementation. Any other implementation is probably something in between. Therefore it is perfectly acceptable to assume "t'" being the time of arrival of the first byte of the packet if you know the length of the packet in advance (which may not be practical with variable length IP packets), or if you guess the size of the packet, etc. > > So my answer is that the implementation is not a matter of standard, rather a matter of engineering compromise, practicality and taste. > > Yours, > -Shahram > > > -----Original Message----- > > From: Jayaram Beladakere [mailto:jbeladakere@mahinetworks.com] > > Sent: Tuesday, July 24, 2001 12:05 AM > > To: diffserv@ietf.org > > Subject: [Diffserv] Token bucket meters > > > > > > Referring to the discussions on token buckets in Diffserv Informal > > Management Model, Feb. 2001. There is description of a > > packet of length L > > arriving at time t' (Appendix A.4). Is there any assumption > > about when t' > > should be taken? That is, is t' the time of arrival of the > > first byte of > > the packet or the last byte of the packet? Does this > > selection of time > > matter for the operation of token bucket? Is one selection > > preferable? > > > > Regards, > > Jayaram Beladakere > > Mahi Networks, Inc. _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Jul 24 14:14:46 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08262 for ; Tue, 24 Jul 2001 14:14:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25678; Tue, 24 Jul 2001 13:39:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25647 for ; Tue, 24 Jul 2001 13:39:21 -0400 (EDT) Received: from emerson.torrentnet.com (emerson.torrentnet.com [198.78.51.110]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05138 for ; Tue, 24 Jul 2001 13:38:23 -0400 (EDT) Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.2/8.11.2) with ESMTP id f6OHdJg38501; Tue, 24 Jul 2001 13:39:19 -0400 (EDT) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by imperial.torrentnet.com (8.11.2/8.11.2) with ESMTP id f6OHdIu98694; Tue, 24 Jul 2001 13:39:18 -0400 (EDT) Received: from castillo.torrentnet.com (localhost.torrentnet.com [127.0.0.1]) by castillo.torrentnet.com (8.9.3/8.9.3) with ESMTP id NAA23557; Tue, 24 Jul 2001 13:39:18 -0400 (EDT) Message-Id: <200107241739.NAA23557@castillo.torrentnet.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Jayaram Beladakere cc: diffserv@ietf.org Subject: Re: [Diffserv] Token bucket meters In-reply-to: Your message of "Mon, 23 Jul 2001 21:04:48 PDT." <9D6D37E97A57D411BB7C00508BAE29C992150A@main.mahinetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 24 Jul 2001 13:39:17 -0400 From: Steve Blake Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Jayaram Beladakere wrote: > Referring to the discussions on token buckets in Diffserv Informal > Management Model, Feb. 2001. There is description of a packet of length L > arriving at time t' (Appendix A.4). Is there any assumption about when t' > should be taken? That is, is t' the time of arrival of the first byte of > the packet or the last byte of the packet? Does this selection of time > matter for the operation of token bucket? Is one selection preferable? The equations should hold for either case, as long as you are consistent. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure (919)472-9913 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Jul 24 16:57:33 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22386 for ; Tue, 24 Jul 2001 16:57:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00215; Tue, 24 Jul 2001 16:19:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00180 for ; Tue, 24 Jul 2001 16:18:59 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17791 for ; Tue, 24 Jul 2001 16:18:01 -0400 (EDT) Received: from FRED-W2K.cisco.com (dhcp-sjc9-1-132.cisco.com [171.70.136.132]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f6OKIcT01252; Tue, 24 Jul 2001 13:18:39 -0700 (PDT) Message-Id: <5.1.0.14.2.20010724131506.043056d0@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 24 Jul 2001 13:15:25 -0700 To: Anders Bergsten From: Fred Baker Subject: Re: [Diffserv] new MIB draft Cc: diffserv@ietf.org In-Reply-To: <3B5D96AA.50AA32B4@telia.se> References: <5.1.0.14.2.20010720111322.0278ef00@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 08:39 AM 7/24/2001, Anders Bergsten wrote: >Wouldn't it be sensible to separate these three types of drops in the >MIB and have a counter for each? point taken _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Jul 25 17:56:26 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13391 for ; Wed, 25 Jul 2001 17:56:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20300; Wed, 25 Jul 2001 17:27:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20267 for ; Wed, 25 Jul 2001 17:27:49 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10508 for ; Wed, 25 Jul 2001 17:26:45 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id WAA24554 for ; Wed, 25 Jul 2001 22:27:13 +0100 Received: from hursley.ibm.com (gsine08.us.sine.ibm.com [9.14.6.48]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id WAA44180 for ; Wed, 25 Jul 2001 22:27:10 +0100 Message-ID: <3B5F392B.2DED3C7F@hursley.ibm.com> Date: Wed, 25 Jul 2001 16:24:59 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Diff Serv Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Official diffserv agenda will come in a few days... Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Diffservers, I haven't seen either the -10 version of the MIB, or the -04 version of the PIB, announced yet but I believe they are both in the pipeline and they will be the most important agenda items in London. Fred supplied a URL for the MIB: ftp://ftpeng.cisco.com/fred/diffserv-mib/draft-ietf-diffserv-mib-10.txt The PIB will be draft-ietf-diffserv-pib-04.txt when it comes. Other drafts we expect to discuss: draft-mcdysan-diffserv-consistent-meter-00.txt draft-ietf-diffserv-model-06.txt (no update- brief) draft-ietf-diffserv-new-terms-04.txt (no update- brief) draft-conta-ipv6-flow-label-02.txt (brief- main discussion will be in IPNGWG) draft-ietf-diffserv-pdb-ar-01.txt (brief) Brian _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Wed Jul 25 18:49:39 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18280 for ; Wed, 25 Jul 2001 18:49:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17102; Wed, 25 Jul 2001 15:50:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29277 for ; Mon, 23 Jul 2001 10:15:44 -0400 (EDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22889 for ; Mon, 23 Jul 2001 10:14:49 -0400 (EDT) Received: from blv-av-02.boeing.com ([192.54.3.92]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id HAA08711; Mon, 23 Jul 2001 07:15:12 -0700 (PDT) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id HAA22205; Mon, 23 Jul 2001 07:15:38 -0700 (PDT) Received: from xch-phlbh-01.ne.nos.boeing.com (xch-phlbh-01.ne.nos.boeing.com [128.225.22.200]) by stl-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id f6NEFb002968; Mon, 23 Jul 2001 09:15:37 -0500 (CDT) Received: by xch-phlbh-01.ne.nos.boeing.com with Internet Mail Service (5.5.2650.21) id <36A44461>; Mon, 23 Jul 2001 10:15:37 -0400 Message-ID: <8D6509B44ACCEB43A96E032B9C3EA0C8021F560C@xch-ne-02.ne.nos.boeing.com> From: "Manfredi, Albert E" To: "'Roland Bless'" Cc: diffserv@ietf.org Subject: RE: [Diffserv] I-D ACTION:draft-bless-diffserv-mcast-routerext-00 .txt (fwd) Date: Mon, 23 Jul 2001 10:15:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Roland, This I-D makes the case for allowing individual DS codepoints for each DS tunnel or physical interface used by a multicast router to distribute IP multicast packets. You say in your I-D: A virtual interface means in this context, that it is either a multicast tunnel or a real physical network interface. So there may be several configured tunnels over one physical interface present. The multicast routing table entry contains usually information about the multicast group address (destination address), source address and (virtual) outgoing interfaces where packets should be copied to during packet forwarding. I believe that a "virtual interface" in the context of this I-D might potentially be defined as any combination of source and destination IP address, source and destination UDP port ID, incoming DS codepoint, _and_ outgoing physical interface? (The Protocol field will always indicate UDP.) If you agree with this, perhaps the word "only" in the abstract: Only one additional DS codepoint for each virtual interface in the multicast routing table is required to open up a variety of different uses, ... should be deleted. This could be a large number of additional codepoints, in principle. Bert > -----Original Message----- > From: Roland Bless [mailto:bless@tm.uka.de] > Sent: Friday, July 20, 2001 12:37 PM > To: Brian E Carpenter > Cc: diffserv@ietf.org > Subject: Re: [Diffserv] I-D > ACTION:draft-bless-diffserv-mcast-routerext-00.txt (fwd) > > > Brian, > > > Have you discussed with the Routing ADs how to follow up on this? > > That is certainly something to do in London. > > Yes, I followed Kathie's advice to contact them in order to > get a hint for an appropriate WG for discussion of this issue. > So we already contacted the Routing ADs by e-mail, but Rob wanted > to know something about the operational requirements for this work > (this was before we wrote the draft). Therefore, we'd like to get > feedback from the community. However, we are looking forward to > discuss about it in London. > > Roland > > P.S.: Will the diffserv WG meet in London? I didn't see any > agenda yet. > > > Brian > > > > Roland Bless wrote: > > > > > > Hi, > > > > > > when looking back to 46th IETF meeting minutes, there are still > > > some open multicast issues. This short proposal might be > of interest > > > for some people here. It would be nice to get any > feedback from people > > > here, especially manufacturers of routers. > > > > > > Regards, > > > Roland > > > > > > P.S.: Sorry, I currently don't know any other WG that is > more appropriate > > > for discussion of this issue. > > > > > > ------- Forwarded Message > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > > > > Title : A Router Extension to Support > Multicast in > > > Differentiated Services Networks > > > Author(s) : R. Bless, K. Wehrle > > > Filename : > draft-bless-diffserv-mcast-routerext-00.txt > > > Pages : 4 > > > Date : 16-Jul-01 > > > > > > This draft proposes an extension to the multicast routing table in > > > routers in order to achieve better support for using multicast > > > within Differentiated Services (DS) networks. Only one > additional DS > > > codepoint for each virtual interface in the multicast > routing table > > > is required to open up a variety of different uses, e.g., to solve > > > resource provisioning problems or to support > heterogeneous DiffServ > > > multicast groups. > > > > > > A URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-bless-diffserv-mcast -routerext-00.txt -- Roland Bless -- e-Mail: bless@tm.uka.de Institute of Telematics, University of Karlsruhe, Germany Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358 Phone: +49 721 608-6413 Fax: +49 721 388097 _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Fri Jul 27 17:51:13 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07357 for ; Fri, 27 Jul 2001 17:51:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17241; Fri, 27 Jul 2001 16:59:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17213 for ; Fri, 27 Jul 2001 16:59:21 -0400 (EDT) Received: from mailman.packetdesign.com (dns.packetdesign.com [65.192.41.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02957; Fri, 27 Jul 2001 16:58:20 -0400 (EDT) Received: from packetdesign.com (dhcp-168-0-13.packetdesign.com [192.168.0.13]) by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id f6RKwm242489; Fri, 27 Jul 2001 13:58:48 -0700 (PDT) (envelope-from nichols@packetdesign.com) Message-ID: <3B61D66A.3B60713C@packetdesign.com> Date: Fri, 27 Jul 2001 14:00:26 -0700 From: Kathleen Nichols X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 4.3-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: agenda@ietf.org, diffserv@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Diffserv WG agenda Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Diffserv WG Agenda August 9, 0900-1130 Chairs: Brian Carpenter & Kathleen Nichols Transport Area (If your name is in parenthesis, we are expecting you to be prepared to speak to the issue. Please let us know if we are mistaken. If your name isn't there, we aren't expecting you to speak.) (10) Agenda bashing and WG status (20) Changes/issues on MIB (Fred) draft-ietf-diffserv-mib-10.txt (20) Changes/issues on PIB (Kwok) draft-ietf-diffserv-pib-04.txt (10) Comments on informal model (Dave McDysan) draft-mcdysan-diffserv-consistent-meter-00.txt draft-ietf-diffserv-model-06.txt (10) Decide how to proceed with minor updates draft-ietf-diffserv-new-terms-04.txt ( 5) IPv6 flow label proposal FYI (Brian or Alex Conta) draft-conta-ipv6-flow-label-02.txt ( 5) draft-ietf-diffserv-pdb-ar-01.txt (authors if present) _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Jul 30 04:31:11 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07759 for ; Mon, 30 Jul 2001 04:30:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA12836; Mon, 30 Jul 2001 03:54:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA12803 for ; Mon, 30 Jul 2001 03:54:42 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA05999 for ; Mon, 30 Jul 2001 03:53:41 -0400 (EDT) Received: from FRED-W2K2.cisco.com ([171.71.21.236]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6U7rfg15279; Mon, 30 Jul 2001 00:53:41 -0700 (PDT) Message-Id: <5.1.0.14.2.20010730003818.0254ce30@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 30 Jul 2001 00:51:04 +0100 To: Frank Strauss From: Fred Baker Subject: Re: [Diffserv] new MIB draft Cc: diffserv@ietf.org In-Reply-To: References: <5.1.0.14.2.20010720111322.0278ef00@mira-sjcm-2.cisco.com> <5.1.0.14.2.20010720111322.0278ef00@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 13:21 29/07/2001, Frank Strauss wrote: >Purely from the SMIv2 syntax perspective I'd like to let you know about >some things that should be fixed. Maybe, you would like to use smilint >(http://www.ibr.cs.tu-bs.de/projects/libsmi/) yourself. ;-) I use smicng, which I have been using as a test for some years; the observation has been made in many circles that something it will pass can be compiled on any compiler. Perhaps you can get Dave Perkins to update it to your specifications. >- Dates in in LAST-UPDATED and REVISION clauses must have a 4-digit year. Funny, doesn't match the specifications I find in the RFC I saw that in draft 9, when smicng told me it was in error. I checked the RFC archives to verify, and chandged it when I found that the format of the date is specified in ASN.1 and matches what I have done in this draft. Can you instruct me on the point? My research didn't support you. >- Where the old ASN.1-fashioned type INTEGER is used for signed 32-bit > integers, you should use Integer32 in SMIv2 modules instead. Fine, if the range of the integer is -2^32..+2^32. When it's not, one needs to select a TC supporting the correct enumeration. Go check the uses here, and you will find that the enumeration is correctly specified, rather than specifying that range. Maybe you need to check the logic of blanket assertions like "all useful integers have valid negative values." _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Jul 30 09:55:33 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA22268 for ; Mon, 30 Jul 2001 09:55:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20217; Mon, 30 Jul 2001 09:13:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA14258 for ; Sun, 29 Jul 2001 08:21:25 -0400 (EDT) Received: from mumm.ibr.cs.tu-bs.de (root@mumm.ibr.cs.tu-bs.de [134.169.34.190]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA18196 for ; Sun, 29 Jul 2001 08:20:22 -0400 (EDT) Received: from hansa.ibr.cs.tu-bs.de (IDENT:root@hansa [134.169.34.137]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id OAA08703; Sun, 29 Jul 2001 14:21:22 +0200 (MET DST) Received: (from strauss@localhost) by hansa.ibr.cs.tu-bs.de (8.9.3/8.9.3) id OAA20131; Sun, 29 Jul 2001 14:21:22 +0200 X-Authentication-Warning: hansa.ibr.cs.tu-bs.de: strauss set sender to strauss@ibr.cs.tu-bs.de using -f From: Frank Strauss To: Fred Baker Cc: diffserv@ietf.org Subject: Re: [Diffserv] new MIB draft References: <5.1.0.14.2.20010720111322.0278ef00@mira-sjcm-2.cisco.com> Date: 29 Jul 2001 14:21:22 +0200 In-Reply-To: <5.1.0.14.2.20010720111322.0278ef00@mira-sjcm-2.cisco.com> Message-ID: Lines: 51 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi! Fred> You may find a new MIB draft at Fred> ftp://ftpeng.cisco.com/fred/diffserv-mib/draft-ietf-diffserv-mib-10.txt Purely from the SMIv2 syntax perspective I'd like to let you know about some things that should be fixed. Maybe, you would like to use smilint (http://www.ibr.cs.tu-bs.de/projects/libsmi/) yourself. ;-) - Dates in in LAST-UPDATED and REVISION clauses must have a 4-digit year. - Where the old ASN.1-fashioned type INTEGER is used for signed 32-bit integers, you should use Integer32 in SMIv2 modules instead. ./DIFFSERV-MIB:23: date specification `0102210000Z' contains a two-digit year representing `1901' ./DIFFSERV-MIB:23: date specification `0102210000Z' contains an illegal value ./DIFFSERV-MIB:55: date specification `0106030000Z' contains a two-digit year representing `1901' ./DIFFSERV-MIB:55: date specification `0106030000Z' contains an illegal value ./DIFFSERV-MIB:235: use Integer32 instead of INTEGER in SMIv2 ./DIFFSERV-MIB:361: use Integer32 instead of INTEGER in SMIv2 ./DIFFSERV-MIB:425: use Integer32 instead of INTEGER in SMIv2 ./DIFFSERV-MIB:438: use Integer32 instead of INTEGER in SMIv2 ./DIFFSERV-MIB:540: use Integer32 instead of INTEGER in SMIv2 ./DIFFSERV-MIB:592: use Integer32 instead of INTEGER in SMIv2 ./DIFFSERV-MIB:803: use Integer32 instead of INTEGER in SMIv2 ./DIFFSERV-MIB:854: use Integer32 instead of INTEGER in SMIv2 ./DIFFSERV-MIB:960: use Integer32 instead of INTEGER in SMIv2 ./DIFFSERV-MIB:1009: use Integer32 instead of INTEGER in SMIv2 ./DIFFSERV-MIB:1237: use Integer32 instead of INTEGER in SMIv2 ./DIFFSERV-MIB:1287: use Integer32 instead of INTEGER in SMIv2 ./DIFFSERV-MIB:1418: use Integer32 instead of INTEGER in SMIv2 ./DIFFSERV-MIB:1464: use Integer32 instead of INTEGER in SMIv2 ./DIFFSERV-MIB:1589: use Integer32 instead of INTEGER in SMIv2 ./DIFFSERV-MIB:1643: use Integer32 instead of INTEGER in SMIv2 ./DIFFSERV-MIB:1860: use Integer32 instead of INTEGER in SMIv2 ./DIFFSERV-MIB:1910: use Integer32 instead of INTEGER in SMIv2 ./DIFFSERV-MIB:1978: use Integer32 instead of INTEGER in SMIv2 ./DIFFSERV-MIB:1996: use Integer32 instead of INTEGER in SMIv2 ./DIFFSERV-MIB:2016: use Integer32 instead of INTEGER in SMIv2 ./DIFFSERV-MIB:2065: use Integer32 instead of INTEGER in SMIv2 ./DIFFSERV-MIB:2109: use Integer32 instead of INTEGER in SMIv2 ./DIFFSERV-MIB:2205: use Integer32 instead of INTEGER in SMIv2 ./DIFFSERV-MIB:2252: use Integer32 instead of INTEGER in SMIv2 ./DIFFSERV-MIB:2427: use Integer32 instead of INTEGER in SMIv2 ./DIFFSERV-MIB:2472: use Integer32 instead of INTEGER in SMIv2 ./DIFFSERV-MIB:2631: use Integer32 instead of INTEGER in SMIv2 ./DIFFSERV-MIB:2677: use Integer32 instead of INTEGER in SMIv2 ./DIFFSERV-MIB:2688: use Integer32 instead of INTEGER in SMIv2 -frank _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Jul 30 09:55:34 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA22270 for ; Mon, 30 Jul 2001 09:55:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20245; Mon, 30 Jul 2001 09:14:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA13618 for ; Mon, 30 Jul 2001 04:23:50 -0400 (EDT) Received: from mumm.ibr.cs.tu-bs.de (root@mumm.ibr.cs.tu-bs.de [134.169.34.190]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07421 for ; Mon, 30 Jul 2001 04:22:49 -0400 (EDT) Received: from hansa.ibr.cs.tu-bs.de (IDENT:root@hansa [134.169.34.137]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id KAA02832; Mon, 30 Jul 2001 10:23:47 +0200 (MET DST) Received: (from strauss@localhost) by hansa.ibr.cs.tu-bs.de (8.9.3/8.9.3) id KAA26818; Mon, 30 Jul 2001 10:23:47 +0200 X-Authentication-Warning: hansa.ibr.cs.tu-bs.de: strauss set sender to strauss@ibr.cs.tu-bs.de using -f From: Frank Strauss To: Fred Baker Cc: diffserv@ietf.org Subject: Re: [Diffserv] new MIB draft References: <5.1.0.14.2.20010720111322.0278ef00@mira-sjcm-2.cisco.com> <5.1.0.14.2.20010720111322.0278ef00@mira-sjcm-2.cisco.com> <5.1.0.14.2.20010730003818.0254ce30@mira-sjcm-2.cisco.com> Date: 30 Jul 2001 10:23:47 +0200 In-Reply-To: <5.1.0.14.2.20010730003818.0254ce30@mira-sjcm-2.cisco.com> Message-ID: Lines: 70 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi! >> Purely from the SMIv2 syntax perspective I'd like to let you know about >> some things that should be fixed. Maybe, you would like to use smilint >> (http://www.ibr.cs.tu-bs.de/projects/libsmi/) yourself. ;-) Fred> I use smicng, which I have been using as a test for some years; the Fred> observation has been made in many circles that something it will pass Fred> can be compiled on any compiler. Perhaps you can get Dave Perkins to Fred> update it to your specifications. I'm quite sure, Dave Perkins is aware of the problem that the SMICng that many people use is older than RFC 2578-80 which introduced a number of clarifications. One of these clarifications is more of a change: the date length has to be 13 for any date after 1999. >> - Dates in in LAST-UPDATED and REVISION clauses must have a 4-digit year. Fred> Funny, doesn't match the specifications I find in the RFC I saw that Fred> in draft 9, when smicng told me it was in error. I checked the RFC Fred> archives to verify, and chandged it when I found that the format of Fred> the date is specified in ASN.1 and matches what I have done in this Fred> draft. Can you instruct me on the point? My research didn't support Fred> you. According to RFC 2578 (SMIv2) the Date in LAST-UPDATED and REVISION clauses is defined by ExtUTCTime on pages 4-5: ExtUTCTime ::= OCTET STRING(SIZE(11 | 13)) -- [...] -- 8:15pm GMT on 19 February 1995. Years after 1999 must use -- the four digit year format. Years 1900-1999 may use the -- two or four digit format. >> - Where the old ASN.1-fashioned type INTEGER is used for signed 32-bit >> integers, you should use Integer32 in SMIv2 modules instead. Fred> Fine, if the range of the integer is -2^32..+2^32. The range of both INTEGER and Integer32 is -2^31 .. 2^31-1. Fred> When it's not, one needs to select a TC supporting the correct Fred> enumeration. You don't have to define a TC in this case. You can also add a range restriction to the basetype at the place where it's used (in the SYNTAX clause of an OBJECT-TYPE). Fred> Go check the uses here, and you will find that the enumeration Fred> is correctly specified, rather than specifying that range. I'm not talking about enumerations or ranges. I'm talking about using `Integer32' instead of `INTEGER', e.g.: diffServClfrNextFree OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS read-only [...] instead of diffServClfrNextFree OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS read-only [...] However, this is more of a `should' than a `must'. -frank _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Jul 30 09:55:37 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA22290 for ; Mon, 30 Jul 2001 09:55:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20194; Mon, 30 Jul 2001 09:13:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14694 for ; Fri, 27 Jul 2001 15:02:39 -0400 (EDT) Received: from mail1.telefonica.com.ar (mail.telefonica.com.ar [168.226.49.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20170 for ; Fri, 27 Jul 2001 15:01:40 -0400 (EDT) Received: by MAIL1 with Internet Mail Service (5.5.2448.0) id ; Fri, 27 Jul 2001 16:02:35 -0300 Message-ID: <3D9C91EAD5D1D411851300508BCF243F02BE151F@MSTELEFONICA3> From: Fabris Sergio To: diffserv@ietf.org Date: Fri, 27 Jul 2001 16:02:30 -0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Subject: [Diffserv] end-to-end qos Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org If in a DiffServ network I use RSVP for signaling and reserve resources and some routers are not aware RSVP , how can I guaranteed end-to-end QoS?? I know that RSVP messages can pass through not aware RSVP routers. Thank Sergio _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Jul 30 16:43:36 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23220 for ; Mon, 30 Jul 2001 16:43:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29869; Mon, 30 Jul 2001 14:29:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29844 for ; Mon, 30 Jul 2001 14:29:33 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14087 for ; Mon, 30 Jul 2001 14:28:33 -0400 (EDT) Received: from FRED-W2K2.cisco.com ([171.71.21.236]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6UISWg13536; Mon, 30 Jul 2001 11:28:32 -0700 (PDT) Message-Id: <5.1.0.14.2.20010730110350.041d4e60@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 30 Jul 2001 11:27:52 +0100 To: Frank Strauss From: Fred Baker Subject: Re: [Diffserv] new MIB draft Cc: diffserv@ietf.org In-Reply-To: References: <5.1.0.14.2.20010730003818.0254ce30@mira-sjcm-2.cisco.com> <5.1.0.14.2.20010720111322.0278ef00@mira-sjcm-2.cisco.com> <5.1.0.14.2.20010720111322.0278ef00@mira-sjcm-2.cisco.com> <5.1.0.14.2.20010730003818.0254ce30@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 09:23 AM 7/30/2001, Frank Strauss wrote: >The range of both INTEGER and Integer32 is -2^31 .. 2^31-1. You and I must be reading different versions of ASN.1. last I checked, INTEGER was a primitive type, and can (at least theoretically) represent an integer which is arbitrarily large. Integer32 is a TC specified in RFC 1442 and later which limits the range to 32 bits. Integer32 ::= [UNIVERSAL 2] IMPLICIT INTEGER (-2147483648..2147483647) Jeff's comment in 1442 was that "Integer32 is indistinguishable from INTEGER"; it is an unfortunate comment, as it is in fact very distinguishable. If it were indistinguishable, the following specification (which is found on the next page, and says that a Counter64 is one of the subset of positive integers that can be represented as a 64 bit number) would not be very meaningful: Counter64 ::= [APPLICATION 6] IMPLICIT INTEGER (0..18446744073709551615) This limitation was imposed a decade and a half ago when computers were typically 32 bits wide. The limitation made life easier for early SNMP implementors - they could simply pass integers around as ints. I'll change the dates to have four digit years. As to the cases where I call out an INTEGER, please explain which of the following is incorrect, and why? I'll accept a statement that I should have defined a TC for the range 1..2147483647, or that there is one in existence that I could have imported and used, but the assertion that I should specify one TC and then change it to another mystifies me. IfDirection ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "IfDirection specifies a direction of data travel on an interface. 'inbound' traffic is operated on during reception from the interface, while 'outbound' traffic is operated on prior to transmission on the interface." SYNTAX INTEGER { inbound(1), -- ingress interface outbound(2) -- egress interface } diffServClfrNextFree OBJECT-TYPE SYNTAX INTEGER (1..2147483647) diffServClfrElementNextFree OBJECT-TYPE SYNTAX INTEGER (1..2147483647) diffServClfrElementClfrId OBJECT-TYPE SYNTAX INTEGER (1..2147483647) diffServClfrElementId OBJECT-TYPE SYNTAX INTEGER (1..2147483647) diffServSixTupleClfrNextFree OBJECT-TYPE SYNTAX INTEGER (1..2147483647) diffServSixTupleClfrId OBJECT-TYPE SYNTAX INTEGER (1..2147483647) diffServMeterNextFree OBJECT-TYPE SYNTAX INTEGER (1..2147483647) diffServMeterId OBJECT-TYPE SYNTAX INTEGER (1..2147483647) diffServTBParamNextFree OBJECT-TYPE SYNTAX INTEGER (1..2147483647) diffServTBParamId OBJECT-TYPE SYNTAX INTEGER (1..2147483647) diffServActionNextFree OBJECT-TYPE SYNTAX INTEGER (1..2147483647) diffServActionId OBJECT-TYPE SYNTAX INTEGER (1..2147483647) diffServCountActNextFree OBJECT-TYPE SYNTAX INTEGER (1..2147483647) diffServCountActId OBJECT-TYPE SYNTAX INTEGER (1..2147483647) diffServAlgDropNextFree OBJECT-TYPE SYNTAX INTEGER (1..2147483647) diffServAlgDropId OBJECT-TYPE SYNTAX INTEGER (1..2147483647) diffServAlgDropType OBJECT-TYPE SYNTAX INTEGER { other(1), tailDrop(2), headDrop(3), randomDrop(4), alwaysDrop(5) } diffServRandomDropNextFree OBJECT-TYPE SYNTAX INTEGER (1..2147483647) diffServRandomDropId OBJECT-TYPE SYNTAX INTEGER (1..2147483647) diffServRandomDropProbMax OBJECT-TYPE SYNTAX INTEGER (0..1000) diffServRandomDropWeight OBJECT-TYPE SYNTAX INTEGER (0..65536) diffServRandomDropSamplingRate OBJECT-TYPE SYNTAX INTEGER (0..1000000) diffServQNextFree OBJECT-TYPE SYNTAX INTEGER (1..2147483647) diffServQId OBJECT-TYPE SYNTAX INTEGER (1..2147483647) diffServSchedulerNextFree OBJECT-TYPE SYNTAX INTEGER (1..2147483647) diffServSchedulerId OBJECT-TYPE SYNTAX INTEGER (1..2147483647) diffServAssuredRateNextFree OBJECT-TYPE SYNTAX INTEGER (1..2147483647) diffServAssuredRateId OBJECT-TYPE SYNTAX INTEGER (1..2147483647) diffServShapingRateNextFree OBJECT-TYPE SYNTAX INTEGER (1..2147483647) diffServShapingRateId OBJECT-TYPE SYNTAX INTEGER (1..2147483647) diffServShapingRateLevel OBJECT-TYPE SYNTAX INTEGER (1..2147483647) _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Mon Jul 30 18:12:25 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29354 for ; Mon, 30 Jul 2001 18:12:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05815; Mon, 30 Jul 2001 17:39:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05782 for ; Mon, 30 Jul 2001 17:39:25 -0400 (EDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27057 for ; Mon, 30 Jul 2001 17:38:24 -0400 (EDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id WAA09364; Mon, 30 Jul 2001 22:37:39 +0100 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id WAA47986; Mon, 30 Jul 2001 22:37:39 +0100 Message-ID: <3B65C82E.B7CE63AE@hursley.ibm.com> Date: Mon, 30 Jul 2001 15:48:46 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Fabris Sergio CC: diffserv@ietf.org Subject: Re: [Diffserv] end-to-end qos References: <3D9C91EAD5D1D411851300508BCF243F02BE151F@MSTELEFONICA3> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Diffserv doesn't use RSVP. It offers end-to-end behaviours, not end-to-end QOS. I suggest that you re-read RFC 2474 and 2475. Brian Fabris Sergio wrote: > > If in a DiffServ network I use RSVP for signaling and reserve resources and > some routers are not aware RSVP , how can I guaranteed end-to-end QoS?? > I know that RSVP messages can pass through not aware RSVP routers. > > Thank > > Sergio _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Jul 31 11:24:36 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21157 for ; Tue, 31 Jul 2001 11:24:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06931; Tue, 31 Jul 2001 10:55:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06900 for ; Tue, 31 Jul 2001 10:54:56 -0400 (EDT) Received: from wiproecmx1.wipro.com (wiproecmx1.wipro.com [164.164.31.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19327 for ; Tue, 31 Jul 2001 10:53:53 -0400 (EDT) Received: from ecvwall11.wipro.com (ecvwall1.wipro.com [192.168.181.23]) by wiproecmx1.wipro.com (8.11.3/8.11.3) with SMTP id f711CsL24546 for ; Tue, 31 Jul 2001 20:12:55 -0500 (GMT) Received: from gopal ([192.168.178.221]) by ecmail.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GHCEN700.4TH for ; Tue, 31 Jul 2001 20:22:19 +0530 Message-ID: <00e701c11a28$ea708060$ddb2a8c0@wipro.com> From: "GOPAL NAYAK" To: Date: Tue, 31 Jul 2001 20:25:57 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: [Diffserv] Linux Diffserv Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hello All, In which layer most of these diffserver work ? Though ideally they should work in IP layer ( Network layer) but I wonder whether most diffserver implementation support it in Data Link Layer ? Where is it implemented in Linux ? Second, do we have a situation where route has two ingress and two egress o/p and each of them having different SLA ? SLA1 ------------------------------- SLA3 From domain 1 ---------| dm1 FIB module dm3 |--------------------> To domain 3 From domain 2 ---------| dm2 | dm4 |---------------------> To domain 4 SLA3 ------------------------------- SLA4 In this case do we need to have diffserver module (classifier, scheduler ect) at each interface ? Regards, Gopal --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit The Information contained and transmitted by this E-MAIL is proprietary to Wipro Limited and is intended for use only by the individual or entity to which it is addressed, and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If this is a forwarded message, the content of this E-MAIL may not have been sent with the authority of the Company. If you are not the intended recipient, an agent of the intended recipient or a person responsible for delivering the information to the named recipient, you are notified that any use, distribution, transmission, printing, copying or dissemination of this information in any way or in any manner is strictly prohibited. If you have received this communication in error, please delete this mail & notify us immediately at mailadmin@wipro.com --------------InterScan_NT_MIME_Boundary-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Jul 31 12:46:44 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26194 for ; Tue, 31 Jul 2001 12:46:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10847; Tue, 31 Jul 2001 12:26:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10816 for ; Tue, 31 Jul 2001 12:26:44 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24673 for ; Tue, 31 Jul 2001 12:25:43 -0400 (EDT) Received: from FRED-W2K2.cisco.com ([171.71.21.236]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6VGPjg20487; Tue, 31 Jul 2001 09:25:45 -0700 (PDT) Message-Id: <5.1.0.14.2.20010731092528.0246c348@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 31 Jul 2001 09:25:49 +0100 To: Juergen Schoenwaelder From: Fred Baker Cc: diffserv@ietf.org In-Reply-To: <200107311338.PAA17290@henkell.ibr.cs.tu-bs.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] Re: draft-ietf-diffserv-mib-10.txt Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 02:38 PM 7/31/2001, Juergen Schoenwaelder wrote: >you can now remove diffServSixTupleClfrSrcAddrType and change >diffServSixTupleClfrDstAddrType to e.g. diffServSixTupleClfrAddrType if >you like and save a column. Thanks. That makes a lot more sense. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Jul 31 18:15:10 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27106 for ; Tue, 31 Jul 2001 18:15:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18868; Tue, 31 Jul 2001 17:27:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02108 for ; Tue, 31 Jul 2001 07:32:15 -0400 (EDT) Received: from cmail.mantraonline.com (cmail.mantraonline.com [202.56.230.27]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA12887 for ; Tue, 31 Jul 2001 07:31:11 -0400 (EDT) Received: from mtv01ex01.mindtree.com ([202.56.254.10]) by cmail.mantraonline.com (Netscape Messaging Server 4.15) with ESMTP id GHC5DF01.166 for ; Tue, 31 Jul 2001 17:02:03 +0530 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mimeole: Produced By Microsoft Exchange V6.0.4417.0 Date: Tue, 31 Jul 2001 17:02:59 +0530 Message-ID: <2330401A6FE03445ADA682F5EBB7502D02B13E05@mtv01ex01.mindtree.com> Thread-Topic: Pls. help me to find about the detail of leaky bucket algo Thread-Index: AcEZtI0DGIOTcWDDSU6yGRgL1fbfhg== From: "Ashish Kumar Batwara" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id HAA02109 Subject: [Diffserv] Pls. help me to find about the detail of leaky bucket algo Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 8bit Hello, I am looking for a detailed reference related to leaky bucket algorithm for diffserv. Pls. give me some information about where i can find the detail about that. I have just starting working on diffserv.. Regards Ashish _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Jul 31 18:15:11 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27120 for ; Tue, 31 Jul 2001 18:15:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18807; Tue, 31 Jul 2001 17:27:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22330 for ; Mon, 30 Jul 2001 10:06:09 -0400 (EDT) Received: from mail1.telefonica.com.ar (mail.telefonica.com.ar [168.226.49.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22913 for ; Mon, 30 Jul 2001 10:05:09 -0400 (EDT) Received: by MAIL1 with Internet Mail Service (5.5.2448.0) id ; Mon, 30 Jul 2001 11:05:56 -0300 Message-ID: <3D9C91EAD5D1D411851300508BCF243F02BE19C3@MSTELEFONICA3> From: Fabris Sergio To: diffserv@ietf.org Date: Mon, 30 Jul 2001 11:05:54 -0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Subject: [Diffserv] compatibility Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org If I have non-DIffServ router that can manage IP Precedence, could I use this router in a DiffServ network and use IP Precedence for mapping DSCPs? _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Jul 31 18:30:04 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27125 for ; Tue, 31 Jul 2001 18:15:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18881; Tue, 31 Jul 2001 17:27:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05155 for ; Tue, 31 Jul 2001 09:38:53 -0400 (EDT) Received: from mumm.ibr.cs.tu-bs.de (root@mumm.ibr.cs.tu-bs.de [134.169.34.190]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15595 for ; Tue, 31 Jul 2001 09:37:51 -0400 (EDT) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id PAA04302; Tue, 31 Jul 2001 15:38:47 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id PAA17290; Tue, 31 Jul 2001 15:38:47 +0200 Date: Tue, 31 Jul 2001 15:38:47 +0200 Message-Id: <200107311338.PAA17290@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: Fred Baker CC: diffserv@ietf.org Subject: [Diffserv] draft-ietf-diffserv-mib-10.txt Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Fred, the latest INET-ADDRESS-MIB in relaxes the rules for InetAddressType/InetAddress tuples as discussed on the MIBS mailing list. Thus, you can now remove diffServSixTupleClfrSrcAddrType and change diffServSixTupleClfrDstAddrType to e.g. diffServSixTupleClfrAddrType if you like and save a column. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Jul 31 18:30:05 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27122 for ; Tue, 31 Jul 2001 18:15:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18882; Tue, 31 Jul 2001 17:27:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA28103 for ; Tue, 31 Jul 2001 04:10:31 -0400 (EDT) Received: from mumm.ibr.cs.tu-bs.de (root@mumm.ibr.cs.tu-bs.de [134.169.34.190]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09380 for ; Tue, 31 Jul 2001 04:09:30 -0400 (EDT) Received: from hansa.ibr.cs.tu-bs.de (IDENT:root@hansa [134.169.34.137]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id KAA16953; Tue, 31 Jul 2001 10:10:30 +0200 (MET DST) Received: (from strauss@localhost) by hansa.ibr.cs.tu-bs.de (8.9.3/8.9.3) id KAA16639; Tue, 31 Jul 2001 10:10:30 +0200 X-Authentication-Warning: hansa.ibr.cs.tu-bs.de: strauss set sender to strauss@ibr.cs.tu-bs.de using -f From: Frank Strauss To: Fred Baker Cc: diffserv@ietf.org Subject: Re: [Diffserv] new MIB draft References: <5.1.0.14.2.20010730003818.0254ce30@mira-sjcm-2.cisco.com> <5.1.0.14.2.20010720111322.0278ef00@mira-sjcm-2.cisco.com> <5.1.0.14.2.20010720111322.0278ef00@mira-sjcm-2.cisco.com> <5.1.0.14.2.20010730003818.0254ce30@mira-sjcm-2.cisco.com> <5.1.0.14.2.20010730110350.041d4e60@mira-sjcm-2.cisco.com> Date: 31 Jul 2001 10:10:30 +0200 In-Reply-To: <5.1.0.14.2.20010730110350.041d4e60@mira-sjcm-2.cisco.com> Message-ID: Lines: 93 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi! Fred Baker writes: >> The range of both INTEGER and Integer32 is -2^31 .. 2^31-1. Fred> You and I must be reading different versions of ASN.1. last I checked, Fred> INTEGER was a primitive type, and can (at least theoretically) Fred> represent an integer which is arbitrarily large. Integer32 is a TC Fred> specified in RFC 1442 and later which limits the range to 32 bits. I think we should refer the current SMIv2 specifications in RFC 2578-80 and neither the obsoleted RFC 1442 nor ASN.1. There are important differences. Both types are `formally' defined the SNMPv2-SMI module: SimpleSyntax ::= CHOICE { -- INTEGERs with a more restrictive range -- may also be used integer-value -- includes Integer32 INTEGER (-2147483648..2147483647), [...] -- indistinguishable from INTEGER, but never needs more than -- 32-bits for a two's complement representation Integer32 ::= INTEGER (-2147483648..2147483647) (BTW, Integer32 is not defined through the TEXTUAL-CONVENTION macro, hence it's not a TC) and described in Section 7.1.1: 7.1.1. Integer32 and INTEGER The Integer32 type represents integer-valued information between -2^31 and 2^31-1 inclusive (-2147483648 to 2147483647 decimal). This type is indistinguishable from the INTEGER type. Both the INTEGER and Integer32 types may be sub-typed to be more constrained than the Integer32 type. (From the ASN.1 point of view, you are right: INTEGER is unlimited in range.) Fred> Integer32 ::= Fred> [UNIVERSAL 2] Fred> IMPLICIT INTEGER (-2147483648..2147483647) Fred> Jeff's comment in 1442 was that "Integer32 is indistinguishable from Fred> INTEGER"; it is an unfortunate comment, as it is in fact very Fred> distinguishable. INTEGER and Integer32 are indistinguishable in the sense that when they are used in the SNMP protocol, both use the same type tag so that a receiver of an SNMP PDU cannot distinguish them just by the tag. Fred> I'll change the dates to have four digit years. Thanks. Fred> As to the cases where I call out an INTEGER, please explain which of Fred> the following is incorrect, and why? I'll accept a statement that I Fred> should have defined a TC for the range 1..2147483647, or that there is Fred> one in existence that I could have imported and used, but the Fred> assertion that I should specify one TC and then change it to another Fred> mystifies me. Fred> IfDirection ::= TEXTUAL-CONVENTION Fred> STATUS current Fred> DESCRIPTION Fred> "IfDirection specifies a direction of data travel on an Fred> interface. 'inbound' traffic is operated on during reception from Fred> the interface, while 'outbound' traffic is operated on prior to Fred> transmission on the interface." Fred> SYNTAX INTEGER { Fred> inbound(1), -- ingress interface Fred> outbound(2) -- egress interface Fred> } This is correct. In case of enumerations you have to use INTEGER (RFC 2578, Section 7.1.1, second paragraph). Fred> diffServClfrNextFree OBJECT-TYPE Fred> SYNTAX INTEGER (1..2147483647) In all these cases where you want to use a 32bit signed basetype (either range restricted or not) I *suggest* to use Integer32 instead of INTEGER. It is not incorrect as it is right now. I would just prefer Integer32 simply for alignment with the `common practice' to use the `new' xxx32 and xxx64 types. -frank _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Jul 31 18:34:08 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28879 for ; Tue, 31 Jul 2001 18:34:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA20429; Tue, 31 Jul 2001 18:05:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA20398 for ; Tue, 31 Jul 2001 18:05:50 -0400 (EDT) Received: from bridge.axiowave.com (mail.axiowave.com [209.6.34.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26019 for ; Tue, 31 Jul 2001 18:04:49 -0400 (EDT) Message-ID: From: Jeff Parker To: "'Ashish Kumar Batwara'" , diffserv@ietf.org Subject: RE: [Diffserv] Pls. help me to find about the detail of leaky buc ket algo Date: Tue, 31 Jul 2001 18:05:10 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org > Hello, > I am looking for a detailed reference related to leaky > bucket algorithm > > Ashish Where did you look? A search with google.com on the topic "leaky bucket" gives a number of excellent resources. - jeff parker - axiowave networks _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From diffserv-admin@ietf.org Tue Jul 31 19:22:15 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA02356 for ; Tue, 31 Jul 2001 19:22:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22030; Tue, 31 Jul 2001 18:52:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22001 for ; Tue, 31 Jul 2001 18:51:56 -0400 (EDT) Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00041 for ; Tue, 31 Jul 2001 18:50:57 -0400 (EDT) From: Black_David@emc.com Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id <3W0TM8LN>; Tue, 31 Jul 2001 18:51:27 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD539@CORPMX14> To: fabriss@TELEFONICA.COM.AR, diffserv@ietf.org Subject: RE: [Diffserv] compatibility Date: Tue, 31 Jul 2001 18:46:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Yes, with some care, as there are things one can do with diffserv that would not interact will with such a router (so take care not to do them). See Section 4 of RFC of RFC 2474 for a longer discussion. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- > -----Original Message----- > From: Fabris Sergio [mailto:fabriss@TELEFONICA.COM.AR] > Sent: Monday, July 30, 2001 10:06 AM > To: diffserv@ietf.org > Subject: [Diffserv] compatibility > > > If I have non-DIffServ router that can manage IP Precedence, > could I use > this router in a DiffServ network and use IP Precedence for > mapping DSCPs? > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/curr > ent/maillist.html > _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html