From daemon@optimus.ietf.org Fri Feb 1 03:43:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03845 for ; Fri, 1 Feb 2002 03:43:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA02062 for diffserv-archive@odin.ietf.org; Fri, 1 Feb 2002 03:43:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA00491; Fri, 1 Feb 2002 03:27:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA00452 for ; Fri, 1 Feb 2002 03:27:44 -0500 (EST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02264 for ; Fri, 1 Feb 2002 03:27:40 -0500 (EST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id JAA10296; Fri, 1 Feb 2002 09:27:12 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA66786 from ; Fri, 1 Feb 2002 09:27:10 +0100 Message-Id: <3C5A515E.A745715D@hursley.ibm.com> Date: Fri, 01 Feb 2002 09:27:10 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Marco De Bernardi Cc: "'diffserv@ietf.org'" Subject: Re: [Diffserv] Capabilities information References: <7B6D8AAF768F194EB3090A0325C8520206AB1E@rumba.cefriel.it> 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 Not sure how this is relevant to the diffserf WG. Sounds like a question for RAP? Brian Marco De Bernardi wrote: > > Hi everybody, > > I have a little question for you. How does the PDP uses the capabilities > information reported by the PEP's request message? > Do you have an exemple? > > Thanks. > > You can mail to debernar@cefriel.it > > _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Fri Feb 1 03:44:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03878 for ; Fri, 1 Feb 2002 03:44:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA02106 for diffserv-archive@odin.ietf.org; Fri, 1 Feb 2002 03:44:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA00398; Fri, 1 Feb 2002 03:26:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA00368 for ; Fri, 1 Feb 2002 03:26:11 -0500 (EST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02254 for ; Fri, 1 Feb 2002 03:26:08 -0500 (EST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id JAA10790; Fri, 1 Feb 2002 09:25:14 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA50624 from ; Fri, 1 Feb 2002 09:25:07 +0100 Message-Id: <3C5A50E3.CF5E2BD9@hursley.ibm.com> Date: Fri, 01 Feb 2002 09:25:07 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: lei.yao@wcom.com Cc: Andrzej Czerczak , diffserv@ietf.org, Steve Silverman Subject: Re: [Diffserv] RE: 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 Now we really are getting into implementation and deployment questions, which are suitable for http://www.atnf.csiro.au/news/exploders/dsimplementation.html Brian Lei Yao wrote: > > Would the access links be the most likely congestion points to protect? > > Lei > > -----Original Message----- > From: Andrzej Czerczak [mailto:Andrzej_Czerczak/HeadQ@netia.pl] > Sent: Thursday, January 31, 2002 10:31 AM > To: lei.yao@wcom.com > Cc: diffserv@ietf.org; Brian E Carpenter; Steve Silverman > Subject: > > Hi, > I hope you agree, that it has to be provisioned only in the places where it > makes sense -> where you have scare resources and where you need to > differentiate treatment of the traffic, eg. to schedule it differently or > route it to different TE-tunnel (with different traffic parameters) -> I > hope that none will claim that's the violation of diffserv architecture. > Openly, with xDSL concetrators/routers the gain of implementation of > complicated scheduling mechanism would probably be to high to be returned. > This approach reduce the number of routers where you configure treatment > per group of users. > > rgrds, > Andrzej > > >Andrzej, > > >Even for a single service provider's network, your suggested approach is > not > >trivial to implement. You have to proxy on EVERY edge router for the > >"priority" groups and "non-priority" groups. How can it be provisioned? > > > Lei > > -----Original Message----- > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of > Andrzej Czerczak > Sent: Thursday, January 31, 2002 9:30 AM > To: Steve Silverman > Cc: diffserv@ietf.org; Brian E Carpenter > Subject: Re: [Diffserv] Bidirectional flows, Emergency Services > > Hi Steve, > I believe, that at the momoment it is more technical than diff-serv > standarization problem. > If you group your users say into 2 groups, using addressing, every router > in your network will know exactly how to treat returning packet: if your > customer belongs to "priority" group then he will get priority treatment > even for return traffic, if it belongs to "standard" group he will get > "standard" treatment. And so on. > It will easily work in your AS, and no "states" need to be introduced. > > If you want to have such treatment all over internet, then you need to > think about such solutions as receiver-based traffic control. > > rgrds > Andrzej > > Steve Silverman wrote: > > > > In response to my question about bidirectional flows, Fred Baker didn't > want > > to impose the requirement on the routers to mark return packets because > that > > would mean keeping state info on every flow. I sympathize with the > desire > > to avoid complicating the switch but: > > > > If the system is going to allow DSCP marking to affect packet treatment, > the > > access router is going to have to be a gatekeeper to ensure that such > > markings aren't abused. Otherwise most spam will be sent at high > priority. > > One would assume that Service Providers will want to limit use of and/or > > charge for high priority markings. This creates a state-keeping burden > that > > can't be avoided. If UserA has premium service, and sends a packet to > > ServerX, packets from ServerX to UserA should get that premium service > but > > not packets from ServerX to other users. The only way for the network to > > validate these service requests is to note the packet from UserA to > ServerX, > > keep this state, and allow ServerX to UserA traffic to use this Diffserv > > marking. > > > > If IP is to be the global data/voice network of the future, I think > > emergency services (and bidirectional flows) are going to be an > unavoidable > > part of the package even though it complicates the switch. > > > > As I remember, when the Diffserv WG was first set up, allowing SPs to > create > > a premium service was a major driver for the WG. This was presumed to > > include web browsing. Web browsing with Diffserv only makes sense if > > priority is given to the return packets. > > > > Steve Silverman > > Houston Associates > > steves@shentel.net _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Sun Feb 3 10:13:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26386 for ; Sun, 3 Feb 2002 10:13:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA26552 for diffserv-archive@odin.ietf.org; Sun, 3 Feb 2002 10:13:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25371; Sun, 3 Feb 2002 09:57:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25343 for ; Sun, 3 Feb 2002 09:57:13 -0500 (EST) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25883 for ; Sun, 3 Feb 2002 09:57:11 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g13EufH04502; Sun, 3 Feb 2002 09:56:41 -0500 (EST) Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g13EucY20256; Sun, 3 Feb 2002 09:56:38 -0500 (EST) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id D8Z26WKD; Sun, 3 Feb 2002 09:56:36 -0500 Received: from tweedy.NortelNetworks.com (artpt5tq.us.nortel.com [47.140.52.240]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DR4GJZN8; Sun, 3 Feb 2002 09:56:35 -0500 Message-Id: <5.0.0.25.0.20020203093120.020a3eb0@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sun, 03 Feb 2002 09:55:57 -0500 To: rap@ops.ietf.org, diffserv@ietf.org From: Kwok Ho Chan Cc: saurabh.kapoor@wipro.com, srinivasu.nampelli@wipro.com, ravi.attili@wipro.com, naganna.vydyula@wipro.com, krishna.akkineni@wipro.com, khchan@NortelNetworks.com In-Reply-To: <5.0.0.25.0.20020201175520.02c0d050@zbl6c002.corpeast.bayne tworks.com> References: <009601c1938c$35c8c860$838fa8c0@wipsys.stph.net> <49FF5C6DDBD8D311BBBD009027DE980C031F44CB@UNIWEST1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] ifSpeed with DiffServ PIB and Framework PIB [Previously Re: draft-ietf-rap-frameworkpib-06] 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 An alternative to the treatment of ifSpeed by the DiffServ PIB is to add an attribute qosIfSchedulerCapsIfSpeed to qosIfSchedulerCapsEntry to indicate the bit rate that can "sink" the output of the Scheduler Data Path Element. This will allow the DiffServ PIB to not rely on the Interface MIB. The above alternative is possible because the Framework PIB now allows multiple interface capability sets belonging to the same Role Combination, hence policies belonging to the same Role Combination can be used for interfaces with different interface capability sets (different interface speeds). I have also put this on the diffserv mailing list as this need to be decided with the DiffServ WG. I can change this in the DiffServ PIB-06 I am submitting. Notice DiffServ PIB-05 have already passed WG Last Call, so this will be a minor change after WG Last Call before IESG Review. -- Kwok -- At 06:18 PM 2/1/02 -0500, Chan, Kwok-Ho [BL60:470:EXCH] wrote: >Saurabh: >Sorry for not responding to this earlier. >Currently the "ifSpeed" refers to the interface speed provided by >the MIB's ifTable in RFC 2863. >Design of the DiffServ PIB is to be Role Combination specific and not >interface specific. We also didn't want to pull in the MIB's ifTable into >a PIB as there are many proprietary extensions to the ifTable already. >Another point is that we can add this as part of the capabilities for >a specific Role Combination, but we may want to have a single Role >Combination containing interfaces of more than one interface speed. > >I would like to leave it the way it is and just use the ifSpeed from the >MIB's ifTable. >Let the DiffServ PIB get to Proposed Standard RFC. >Get more implementation experience to determine what is the right thing to do >before modifying it, as there are other things we will learn from more >implementation experience. > >-- Kwok -- > > >At 06:21 PM 1/2/02 +0530, saurabh.kapoor@wipro.com wrote: >> The qosAssuredRateAbs parameter of the qosAssuredRate table specifies >>the minimum absolute rate, in kbps that a downstream scheduler element >>should allocate to the queue. >>This attributes value is coupled to that of qosAssuredRateRel : changes to >>one will affect the value of other. They are related to each other by the >>equation : >>RateRel = [ (RateAbs * 1000) / ifSpeed ] * 10000 >> >>My question is how does the PDP get the value of 'ifSpeed'? Does the PEP >>specify the value? If yes, then in which PIb is the value found ? >> >>Regards, >>Saurabh Kapoor >>---------------------------------------------------------------------------- >>---------- >> >> > _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Mon Feb 4 03:31:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16436 for ; Mon, 4 Feb 2002 03:31:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA15957 for diffserv-archive@odin.ietf.org; Mon, 4 Feb 2002 03:31:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14476; Mon, 4 Feb 2002 03:14:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14440 for ; Mon, 4 Feb 2002 03:14:08 -0500 (EST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16212 for ; Mon, 4 Feb 2002 03:14:05 -0500 (EST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id JAA04906; Mon, 4 Feb 2002 09:13:35 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA50498 from ; Mon, 4 Feb 2002 09:13:34 +0100 Message-Id: <3C5E42AD.6E7D4A72@hursley.ibm.com> Date: Mon, 04 Feb 2002 09:13:33 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Kwok Ho Chan , Diff Serv Subject: Re: [Diffserv] ifSpeed with DiffServ PIB and Framework PIB [Previously Re:draft-ietf-rap-frameworkpib-06] References: <009601c1938c$35c8c860$838fa8c0@wipsys.stph.net> <49FF5C6DDBD8D311BBBD009027DE980C031F44CB@UNIWEST1> <5.0.0.25.0.20020203093120.020a3eb0@zbl6c002.corpeast.baynetworks.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 Even though it's a small change, it's technical not editorial. So if this change is made in the -06 version (which seems entirely reasonable since it removes a dependency), it would be a legitimate topic for discussion in the IETF-wide last call. So if anyone thinks it is a Bad Idea to make this change, please say so *now*. Thanks Brian Carpenter diffserv co-chair Kwok Ho Chan wrote: > > An alternative to the treatment of ifSpeed by the DiffServ PIB is to add > an attribute qosIfSchedulerCapsIfSpeed to qosIfSchedulerCapsEntry > to indicate the bit rate that can "sink" the output of the Scheduler > Data Path Element. This will allow the DiffServ PIB to not rely on the > Interface MIB. > > The above alternative is possible because the Framework PIB now > allows multiple interface capability sets belonging to the same Role > Combination, hence policies belonging to the same Role Combination > can be used for interfaces with different interface capability sets > (different interface speeds). > > I have also put this on the diffserv mailing list as this need to be decided > with the DiffServ WG. > I can change this in the DiffServ PIB-06 I am submitting. > Notice DiffServ PIB-05 have already passed WG Last Call, > so this will be a minor change after WG Last Call before IESG Review. > > -- Kwok -- > > At 06:18 PM 2/1/02 -0500, Chan, Kwok-Ho [BL60:470:EXCH] wrote: > >Saurabh: > >Sorry for not responding to this earlier. > >Currently the "ifSpeed" refers to the interface speed provided by > >the MIB's ifTable in RFC 2863. > >Design of the DiffServ PIB is to be Role Combination specific and not > >interface specific. We also didn't want to pull in the MIB's ifTable into > >a PIB as there are many proprietary extensions to the ifTable already. > >Another point is that we can add this as part of the capabilities for > >a specific Role Combination, but we may want to have a single Role > >Combination containing interfaces of more than one interface speed. > > > >I would like to leave it the way it is and just use the ifSpeed from the > >MIB's ifTable. > >Let the DiffServ PIB get to Proposed Standard RFC. > >Get more implementation experience to determine what is the right thing to do > >before modifying it, as there are other things we will learn from more > >implementation experience. > > > >-- Kwok -- > > > > > >At 06:21 PM 1/2/02 +0530, saurabh.kapoor@wipro.com wrote: > >> The qosAssuredRateAbs parameter of the qosAssuredRate table specifies > >>the minimum absolute rate, in kbps that a downstream scheduler element > >>should allocate to the queue. > >>This attributes value is coupled to that of qosAssuredRateRel : changes to > >>one will affect the value of other. They are related to each other by the > >>equation : > >>RateRel = [ (RateAbs * 1000) / ifSpeed ] * 10000 > >> > >>My question is how does the PDP get the value of 'ifSpeed'? Does the PEP > >>specify the value? If yes, then in which PIb is the value found ? > >> > >>Regards, > >>Saurabh Kapoor _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Mon Feb 4 06:08:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18496 for ; Mon, 4 Feb 2002 06:08:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA24766 for diffserv-archive@odin.ietf.org; Mon, 4 Feb 2002 06:08:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA23451; Mon, 4 Feb 2002 05:55:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA23427 for ; Mon, 4 Feb 2002 05:55:15 -0500 (EST) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18244 for ; Mon, 4 Feb 2002 05:55:11 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g14Ashr12933 for ; Mon, 4 Feb 2002 05:54:43 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id <1ACQC4WS>; Mon, 4 Feb 2002 11:54:19 +0100 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0E69BCAE@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Kwok Ho Chan , rap@ops.ietf.org, diffserv@ietf.org Cc: saurabh.kapoor@wipro.com, srinivasu.nampelli@wipro.com, ravi.attili@wipro.com, naganna.vydyula@wipro.com, krishna.akkineni@wipro.com Subject: RE: [Diffserv] ifSpeed with DiffServ PIB and Framework PIB [Previ ously Re: draft-ietf-rap-frameworkpib-06] Date: Mon, 4 Feb 2002 11:54:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain 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 Kwok writes: > > An alternative to the treatment of ifSpeed by the DiffServ PIB is to > add an attribute qosIfSchedulerCapsIfSpeed to qosIfSchedulerCapsEntry > to indicate the bit rate that can "sink" the output of the Scheduler > Data Path Element. This will allow the DiffServ PIB to not > rely on the Interface MIB. > So to me that sounds as "duplicating" information. How does this new field get filled out by the PEP? What if that field conflicts with ifSpeed? Would any network device not have the IF-MIB implemented anyway, so the fact that you remove the dependency from the PIB, does not mean that the IF-MIB does not have to be implemented in the device, does it? Bert _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@ns.ietf.org Mon Feb 4 11:56:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29032 for ; Mon, 4 Feb 2002 11:56:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA14886 for diffserv-archive@odin.ietf.org; Mon, 4 Feb 2002 11:56:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13461; Mon, 4 Feb 2002 11:36:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13430 for ; Mon, 4 Feb 2002 11:36:47 -0500 (EST) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28076 for ; Mon, 4 Feb 2002 11:36:44 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g14GaAH19909; Mon, 4 Feb 2002 11:36:10 -0500 (EST) Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g14Ga7706584; Mon, 4 Feb 2002 11:36:07 -0500 (EST) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1CJ1ZQDX; Mon, 4 Feb 2002 11:36:07 -0500 Received: from tweedy.NortelNetworks.com (dhcp229-100.engeast.baynetworks.com [192.32.229.100]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DR4GJ5Q8; Mon, 4 Feb 2002 11:36:07 -0500 Message-Id: <5.0.0.25.0.20020204110610.025da1f0@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 04 Feb 2002 11:35:28 -0500 To: "Wijnen, Bert (Bert)" From: Kwok Ho Chan Subject: RE: [Diffserv] ifSpeed with DiffServ PIB and Framework PIB [Previ ously Re: draft-ietf-rap-frameworkpib-06] Cc: "Kwok-Ho Chan", rap@ops.ietf.org, diffserv@ietf.org, saurabh.kapoor@wipro.com, srinivasu.nampelli@wipro.com, ravi.attili@wipro.com, naganna.vydyula@wipro.com, krishna.akkineni@wipro.com In-Reply-To: <2413FED0DFE6D111B3F90008C7FA61FB0E69BCAE@nl0006exch002u.nl .lucent.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 Bert: Please see response inline. -- Kwok -- At 11:54 AM 2/4/02 +0100, Wijnen, Bert (Bert) wrote: >Kwok writes: > > > > An alternative to the treatment of ifSpeed by the DiffServ PIB is to > > add an attribute qosIfSchedulerCapsIfSpeed to qosIfSchedulerCapsEntry > > to indicate the bit rate that can "sink" the output of the Scheduler > > Data Path Element. This will allow the DiffServ PIB to not > > rely on the Interface MIB. > > >So to me that sounds as "duplicating" information. >How does this new field get filled out by the PEP? The "ifSpeed" being discussed is the information required for the PDP to formulate the correct scheduling policy parameters based on network wide policies. May be we should not use the term "ifSpeed" and allow the scheduling policy parameter be not tightly coupled to interface. This field should be filled out by the PEP as it sees what it needs to be controlled by policy, and this is not necessarily an interface. >What if that field conflicts with ifSpeed? The scheduling policy parameter here may be totally different from ifSpeed in the IF-MIB. So I don't think the notion of conflict exists. >Would any network device not have the IF-MIB implemented anyway, >so the fact that you remove the dependency from the PIB, does not >mean that the IF-MIB does not have to be implemented in the device, >does it? The removal of this dependency from the PIB does not say anything about implementation of the IF-MIB at all. It is up to the implementation what it wants/needs to do. >Bert _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@ns.ietf.org Mon Feb 4 12:43:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01045 for ; Mon, 4 Feb 2002 12:43:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA19275 for diffserv-archive@odin.ietf.org; Mon, 4 Feb 2002 12:43:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17088; Mon, 4 Feb 2002 12:12:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17056 for ; Mon, 4 Feb 2002 12:12:53 -0500 (EST) Received: from energia3.cosern.com.br ([200.179.191.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29681 for ; Mon, 4 Feb 2002 12:12:47 -0500 (EST) Received: from dsilab09rn (DSI_LAB09_RN [10.12.10.13]) by energia3.cosern.com.br with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id D21TQTC6; Mon, 4 Feb 2002 15:08:36 -0200 Message-ID: <006901c1ad9e$f1cbfc40$0d0a0c0a@cosernet> From: "webmaster" To: References: <009601c1938c$35c8c860$838fa8c0@wipsys.stph.net> <49FF5C6DDBD8D311BBBD009027DE980C031F44CB@UNIWEST1> <5.0.0.25.0.20020203093120.020a3eb0@zbl6c002.corpeast.baynetworks.com> Date: Mon, 4 Feb 2002 15:10:58 -0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 8bit Subject: [Diffserv] IPng and 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 Content-Transfer-Encoding: 8bit Hi Let introduce myself : My name is Bernardo Oliveira and I am a pos-graduate student of Rio Grande do Norta Federal University (this is a state of northwest of Brazil). Now I'm searching material for my thesis. My subject refer to DIFFSERV over IPNG to transport VOIP traffic. So I am interested in the use of flow label field for DIFFSERV. In draft-conta-ipv6-flow-label-02 of july/01 (A. Conta and B. Carpenter) we have a proposal to use the flow label field to DIFFSERV, but I dont understand yet how to do it ! The flow label field is bigger than traffic class field (this is a fact), so to me it means that we have a possibility to use one more granularity that is, we can define more classes beyond of AF,EF,BE existent classes, or more "levels" of these classes , something like "AF Super" or "EF GOLD Hiper". So to do this it is necessary create a news DSCPs . This idea looks like a "new DIFFSERV" or a "Extended DIFFSERV" Are my ideas corrects ??? Is there anybody talking (writing) about this new classification (news DSCPs) ?. I found nothing about it. On the other hand in draft-rajahalme-ipv6-flow.label-00 of November/01 (A. Conta and J. Rajahalme) Alex Conta doesn´t talk anything about DIFFSERV. what does it means ? Is The first draft a dead idea ? , Wouldn't we use the flow label to DIFFSERV ? Bernardo Oliveira _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@ns.ietf.org Mon Feb 4 13:24:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02067 for ; Mon, 4 Feb 2002 13:24:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA21896 for diffserv-archive@odin.ietf.org; Mon, 4 Feb 2002 13:24:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20561; Mon, 4 Feb 2002 13:03:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20530 for ; Mon, 4 Feb 2002 13:03:03 -0500 (EST) Received: from avocet.prod.itd.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01589 for ; Mon, 4 Feb 2002 13:03:01 -0500 (EST) Received: from user-vcaulgn.dsl.mindspring.com ([216.175.86.23] helo=ANDREWHOME) by avocet.prod.itd.earthlink.net with smtp (Exim 3.33 #1) id 16XnRM-0002vj-00; Mon, 04 Feb 2002 10:02:05 -0800 From: "Andrew Smith" To: "Kwok Ho Chan" , "Wijnen, Bert \(Bert\)" Cc: , , , , , , Subject: RE: [Diffserv] ifSpeed with DiffServ PIB and Framework PIB [Previ ously Re: draft-ietf-rap-frameworkpib-06] Date: Mon, 4 Feb 2002 10:30:40 -0800 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) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <5.0.0.25.0.20020204110610.025da1f0@zbl6c002.corpeast.baynetworks.com> 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 I think you're all missing the point here. The relationship between the "xxxRel" and the "xxxAbs" objects in the Diffserv PIB is just the same as in the Diffserv MIB: RateRel = [ (RateAbs * 1000) / ifSpeed ] * 10000 The reason that both objects are present is that sometime you want to set a configuration based on an absolute bandwidth (e.g. 1 Mbps), sometimes you want to set it based on a fraction of the link's bandwidth (e.g. 20% of line rate). In order to allow people to use either type of "policy", we duplicated the object and had the two incarnations of it linked by the above equation (it's a clumsy solution but it seemed like the best we could do given the languages we have for describing the semantics of objects in SMI or SPPI). The manager (or PDP) only has to set one of the two objects and, therefore, does not need to know the ifSpeed if it sets the "xxxRel" object. If it sets the "xxxAbs" object then it probably should have some way of knowing, a priori, what speed each interface covered by a RoleCombination can handle - I'd suggest that the ifTable is a good way of discovering this information ahead of time, through SNMP probably. [There's a larger issue too: what is the defined behaviour when one or more members of a RoleCombination cannot support a given policy rule (e.g. manager tries to set a 10Mbps RateAbs policy on a 2Mbps interface?] So I'd object to Kwok's proposed change. Andrew Smith -----Original Message----- From: owner-rap@ops.ietf.org [mailto:owner-rap@ops.ietf.org]On Behalf Of Kwok Ho Chan Sent: Monday, February 04, 2002 8:35 AM To: Wijnen, Bert (Bert) Cc: Kwok-Ho Chan; rap@ops.ietf.org; diffserv@ietf.org; saurabh.kapoor@wipro.com; srinivasu.nampelli@wipro.com; ravi.attili@wipro.com; naganna.vydyula@wipro.com; krishna.akkineni@wipro.com Subject: RE: [Diffserv] ifSpeed with DiffServ PIB and Framework PIB [Previ ously Re: draft-ietf-rap-frameworkpib-06] Bert: Please see response inline. -- Kwok -- At 11:54 AM 2/4/02 +0100, Wijnen, Bert (Bert) wrote: >Kwok writes: > > > > An alternative to the treatment of ifSpeed by the DiffServ PIB is to > > add an attribute qosIfSchedulerCapsIfSpeed to qosIfSchedulerCapsEntry > > to indicate the bit rate that can "sink" the output of the Scheduler > > Data Path Element. This will allow the DiffServ PIB to not > > rely on the Interface MIB. > > >So to me that sounds as "duplicating" information. >How does this new field get filled out by the PEP? The "ifSpeed" being discussed is the information required for the PDP to formulate the correct scheduling policy parameters based on network wide policies. May be we should not use the term "ifSpeed" and allow the scheduling policy parameter be not tightly coupled to interface. This field should be filled out by the PEP as it sees what it needs to be controlled by policy, and this is not necessarily an interface. >What if that field conflicts with ifSpeed? The scheduling policy parameter here may be totally different from ifSpeed in the IF-MIB. So I don't think the notion of conflict exists. >Would any network device not have the IF-MIB implemented anyway, >so the fact that you remove the dependency from the PIB, does not >mean that the IF-MIB does not have to be implemented in the device, >does it? The removal of this dependency from the PIB does not say anything about implementation of the IF-MIB at all. It is up to the implementation what it wants/needs to do. >Bert _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@ns.ietf.org Mon Feb 4 18:18:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08042 for ; Mon, 4 Feb 2002 18:18:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA06809 for diffserv-archive@odin.ietf.org; Mon, 4 Feb 2002 18:18:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05509; Mon, 4 Feb 2002 17:58:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05470 for ; Mon, 4 Feb 2002 17:58:37 -0500 (EST) Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07722 for ; Mon, 4 Feb 2002 17:58:34 -0500 (EST) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id RAA22571 for ; Mon, 4 Feb 2002 17:57:04 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h149-49-38-91.avaya.com [149.49.38.91]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id RAA22564 for ; Mon, 4 Feb 2002 17:57:03 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Diffserv] ifSpeed with DiffServ PIB and Framework PIB [Previously Re: draft-ietf-rap-frameworkpib-06] Date: Tue, 5 Feb 2002 00:57:39 +0200 Message-ID: Thread-Topic: [Diffserv] ifSpeed with DiffServ PIB and Framework PIB [Previously Re: draft-ietf-rap-frameworkpib-06] Thread-Index: AcGtamAQN1GapWijSsePFyJqXQoa4QABdxKA From: "Romascanu, Dan (Dan)" To: "Wijnen, Bert (Bert)" , "Kwok Ho Chan" , , Cc: , , , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA05471 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 This discussion has for me some confusing aspects. The existence of several management protocols is not something new. After all most of the devices that I know 'always' supported at least two management protocols - CLI and SNMP - now COPS emerged for policy configuration on some devices, and there are several other around. I am not sure that the requirement of not duplicating information is caught in any of the standards. It is more a common sense requirement, but behind it hides the more complex issue of a single data model for all IETF management protocols. This is the real issue that we need to face as we advance towards the 'new generation' of management protocols, and in the absence of a valid solution to this problem no real consistence can be expected in this space. Before Brian jumps on me, I would say that this discussion might be appropriate for one of the 'management - new generation' lists, but before we move there (if anybody is interested in the continuation of a thread on this) I wanted to have the reply visible for the participants in the original thread. Regards, Dan > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Monday, February 04, 2002 12:54 PM > To: Kwok Ho Chan; rap@ops.ietf.org; diffserv@ietf.org > Cc: saurabh.kapoor@wipro.com; srinivasu.nampelli@wipro.com; > ravi.attili@wipro.com; naganna.vydyula@wipro.com; > krishna.akkineni@wipro.com > Subject: RE: [Diffserv] ifSpeed with DiffServ PIB and > Framework PIB [Previously Re: draft-ietf-rap-frameworkpib-06] > > > Kwok writes: > > > > An alternative to the treatment of ifSpeed by the DiffServ PIB is to > > add an attribute qosIfSchedulerCapsIfSpeed to > qosIfSchedulerCapsEntry > > to indicate the bit rate that can "sink" the output of the Scheduler > > Data Path Element. This will allow the DiffServ PIB to not > > rely on the Interface MIB. > > > So to me that sounds as "duplicating" information. > How does this new field get filled out by the PEP? > What if that field conflicts with ifSpeed? > > Would any network device not have the IF-MIB implemented anyway, > so the fact that you remove the dependency from the PIB, does not > mean that the IF-MIB does not have to be implemented in the device, > does it? > > Bert > > _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@ns.ietf.org Mon Feb 4 18:35:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08292 for ; Mon, 4 Feb 2002 18:35:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA08201 for diffserv-archive@odin.ietf.org; Mon, 4 Feb 2002 18:36:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06652; Mon, 4 Feb 2002 18:15:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06621 for ; Mon, 4 Feb 2002 18:15:46 -0500 (EST) Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08017 for ; Mon, 4 Feb 2002 18:15:43 -0500 (EST) Received: from user-vcaulvl.dsl.mindspring.com ([216.175.87.245] helo=ANDREWHOME) by albatross.prod.itd.earthlink.net with smtp (Exim 3.33 #1) id 16XsKX-0001Rk-00; Mon, 04 Feb 2002 15:15:21 -0800 From: "Andrew Smith" To: "Kwok Ho Chan" Cc: , Subject: RE: [Diffserv] ifSpeed with DiffServ PIB and Framework PIB [Previ ously Re: draft-ietf-rap-frameworkpib-06] Date: Mon, 4 Feb 2002 15:44:04 -0800 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) In-reply-to: <5.0.0.25.0.20020204160524.0342d1a0@zbl6c002.corpeast.baynetworks.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal 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 Kwok wrote: > But the policy does not always have to be > associated to an interface, and that is where ifTable will not come into play. > And that is why we may only want to indicate the capability as a "sink" > or "drain" rate out of a scheduler data path element. Also even when only > "xxxRel" is used, the PDP may still want to know the "xxxAbs" numbers > to make sure a specific service is supported with the policy. That's a whole different issue to that which Saurabh brought up. In the Diffserv Management Model, all scheduler data path elements are associated with a particular interface. It seems like you are describing a policy that is formulated without reference to a specific interface but which will, eventually, be applied to a set of interfaces (ideas like "bandwidth" and "rate" are meaningless **until they are applied to an interface**, or something physical like that). The value of "ifSpeed" to be used in the equation is only relevant when the policy is actually applied to the set of interfaces and, as you pointed out, a different value of ifSpeed may be used for each interface instance in the set: you can only read back the set of different ifSpeed values if you index the "read requests" by interface number (sounds like an SNMP GET operation to me). I don't understand your last sentence above: by definition, a PDP "knows the xxxAbs numbers" - at least in the COPS model, PDPs know all the rules that have been installed in a PEP. In this case the xxxAbs value will be either (a) "don't care" for rules that were installed with a xxxRel value or (b) the value that the PDP already installed for rules that were installed with a xxxAbs value. A "policy install" operation often contains a bunch of wildcards: one policy might choose a "RateAbs" value with "RateRel" as a don't care. Another policy might choose the opposite. Another policy might use just a scheduling-priority value and have both RateRel and RateAbs as don't cares. I guess the general issue is that you cannot always usefully do a "read request" indexed by something abstract like policy-ID on objects that only have relevance at the physical instance level - I am assuming that by "PDP may still want to know" you are implying some such read request issued by the PDP of the PEP. I'm not sure what COPS-PR protocol has to say about this - perhaps it should say something. It's just as much an "snmpconf WG" or "policy WG" issue as a "rap WG" one though (although it's not, I believe, a "diffserv WG" thing, assuming we don't make any changes to the PIB in question). Andrew Smith -----Original Message----- From: Kwok Ho Chan [mailto:khchan@NortelNetworks.com] Sent: Monday, February 04, 2002 1:21 PM To: Andrew Smith Cc: Kwok-Ho Chan; Wijnen, Bert (Bert); rap@ops.ietf.org; diffserv@ietf.org; saurabh.kapoor@wipro.com; srinivasu.nampelli@wipro.com; ravi.attili@wipro.com; naganna.vydyula@wipro.com; krishna.akkineni@wipro.com Subject: RE: [Diffserv] ifSpeed with DiffServ PIB and Framework PIB [Previ ously Re: draft-ietf-rap-frameworkpib-06] Andrew: Thanks for the clarification, Please see response inline. -- Kwok -- At 10:30 AM 2/4/02 -0800, Andrew Smith wrote: >I think you're all missing the point here. The relationship between the >"xxxRel" and the "xxxAbs" objects in the Diffserv PIB is just the same as in >the Diffserv MIB: > >RateRel = [ (RateAbs * 1000) / ifSpeed ] * 10000 > >The reason that both objects are present is that sometime you want to set a >configuration based on an absolute bandwidth (e.g. 1 Mbps), sometimes you >want to set it based on a fraction of the link's bandwidth (e.g. 20% of line >rate). In order to allow people to use either type of "policy", we >duplicated the object and had the two incarnations of it linked by the above >equation (it's a clumsy solution but it seemed like the best we could do >given the languages we have for describing the semantics of objects in SMI >or SPPI). > >The manager (or PDP) only has to set one of the two objects and, therefore, >does not need to know the ifSpeed if it sets the "xxxRel" object. If it sets >the "xxxAbs" object then it probably should have some way of knowing, a >priori, what speed each interface covered by a RoleCombination can handle - The above have not changed. But the policy does not always have to be associated to an interface, and that is where ifTable will not come into play. And that is why we may only want to indicate the capability as a "sink" or "drain" rate out of a scheduler data path element. Also even when only "xxxRel" is used, the PDP may still want to know the "xxxAbs" numbers to make sure a specific service is supported with the policy. >I'd suggest that the ifTable is a good way of discovering this information >ahead of time, through SNMP probably. Notice my reply to Bert is this change does not say anything about implementation and usage of ifTable. If policy is associated with an interface, there may be an association. But we may not want to have such a limitation from the policy sense. > [There's a larger issue too: what is >the defined behaviour when one or more members of a RoleCombination cannot >support a given policy rule (e.g. manager tries to set a 10Mbps RateAbs >policy on a 2Mbps interface?] > >So I'd object to Kwok's proposed change. > >Andrew Smith > > >-----Original Message----- >From: owner-rap@ops.ietf.org [mailto:owner-rap@ops.ietf.org]On Behalf Of >Kwok Ho Chan >Sent: Monday, February 04, 2002 8:35 AM >To: Wijnen, Bert (Bert) >Cc: Kwok-Ho Chan; rap@ops.ietf.org; diffserv@ietf.org; >saurabh.kapoor@wipro.com; srinivasu.nampelli@wipro.com; >ravi.attili@wipro.com; naganna.vydyula@wipro.com; >krishna.akkineni@wipro.com >Subject: RE: [Diffserv] ifSpeed with DiffServ PIB and Framework PIB >[Previ ously Re: draft-ietf-rap-frameworkpib-06] > > >Bert: >Please see response inline. >-- Kwok -- > >At 11:54 AM 2/4/02 +0100, Wijnen, Bert (Bert) wrote: > >Kwok writes: > > > > > > An alternative to the treatment of ifSpeed by the DiffServ PIB is to > > > add an attribute qosIfSchedulerCapsIfSpeed to qosIfSchedulerCapsEntry > > > to indicate the bit rate that can "sink" the output of the Scheduler > > > Data Path Element. This will allow the DiffServ PIB to not > > > rely on the Interface MIB. > > > > >So to me that sounds as "duplicating" information. > >How does this new field get filled out by the PEP? > >The "ifSpeed" being discussed is the information required for the PDP >to formulate the correct scheduling policy parameters based on network >wide policies. May be we should not use the term "ifSpeed" and allow >the scheduling policy parameter be not tightly coupled to interface. >This field should be filled out by the PEP as it sees what it needs to be >controlled by policy, and this is not necessarily an interface. > > >What if that field conflicts with ifSpeed? > >The scheduling policy parameter here may be totally different from >ifSpeed in the IF-MIB. So I don't think the notion of conflict exists. > > > >Would any network device not have the IF-MIB implemented anyway, > >so the fact that you remove the dependency from the PIB, does not > >mean that the IF-MIB does not have to be implemented in the device, > >does it? > >The removal of this dependency from the PIB does not say anything about >implementation of the IF-MIB at all. It is up to the implementation what it >wants/needs to do. > > > >Bert > > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >https://www1.ietf.org/mailman/listinfo/diffserv >Archive: >http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Tue Feb 5 09:38:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01074 for ; Tue, 5 Feb 2002 09:38:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA02493 for diffserv-archive@odin.ietf.org; Tue, 5 Feb 2002 09:38:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00648; Tue, 5 Feb 2002 09:21:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00618 for ; Tue, 5 Feb 2002 09:21:12 -0500 (EST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00595 for ; Tue, 5 Feb 2002 09:21:08 -0500 (EST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id PAA10546; Tue, 5 Feb 2002 15:20:39 +0100 Received: from lig32-239-172-111.emea.lig-dial.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA63782 from ; Tue, 5 Feb 2002 15:20:32 +0100 Message-Id: <3C5FA8F5.865E897B@hursley.ibm.com> Date: Tue, 05 Feb 2002 10:42:13 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: webmaster Cc: diffserv@ietf.org Subject: Re: [Diffserv] IPng and Diffserv References: <009601c1938c$35c8c860$838fa8c0@wipsys.stph.net> <49FF5C6DDBD8D311BBBD009027DE980C031F44CB@UNIWEST1> <5.0.0.25.0.20020203093120.020a3eb0@zbl6c002.corpeast.baynetworks.com> <006901c1ad9e$f1cbfc40$0d0a0c0a@cosernet> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA00619 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 Bernardo, This is a mailing list for standardisation work, not for thesis research. Also, you are looking at an obsolete draft - please look at draft-rajahalme-ipv6-flow-label-00.txt (which will be updated soon). For general discussion of diffserv, please use diffserv-interest@ietf.org instead. To join the list, go to http://www.ietf.org/mailman/listinfo/diffserv-interest Brian Carpenter diffserv WG co-chair webmaster wrote: > > Hi > > Let introduce myself : My name is Bernardo Oliveira and I am a pos-graduate > student of Rio Grande do Norta Federal University (this is a state of > northwest > of Brazil). > Now I'm searching material for my thesis. My subject refer to > DIFFSERV over IPNG to transport VOIP traffic. > So I am interested in the use of flow label field for DIFFSERV. > In draft-conta-ipv6-flow-label-02 of july/01 (A. Conta and B. Carpenter) > we have a proposal to use the flow label field to DIFFSERV, but I dont > understand yet how to do it ! > The flow label field is bigger than traffic class field (this is a fact), so > to me it means that we have a possibility to use one more granularity > that is, we can define more classes beyond of AF,EF,BE existent classes, or > more "levels" of these classes , something like "AF Super" or "EF GOLD > Hiper". > So to do this it is necessary create a news DSCPs . This idea looks like a > "new > DIFFSERV" or a "Extended DIFFSERV" > Are my ideas corrects ??? > Is there anybody talking (writing) about this new classification (news > DSCPs) ?. I found nothing > about it. > On the other hand in draft-rajahalme-ipv6-flow.label-00 of November/01 (A. > Conta > and J. Rajahalme) Alex Conta doesn´t talk anything about DIFFSERV. > what does it means ? Is The first draft a dead idea ? , Wouldn't we use the > flow label to DIFFSERV ? > > Bernardo Oliveira > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland Board Chairman, Internet Society http://www.isoc.org _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Tue Feb 5 11:44:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07557 for ; Tue, 5 Feb 2002 11:44:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA13490 for diffserv-archive@odin.ietf.org; Tue, 5 Feb 2002 11:45:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11967; Tue, 5 Feb 2002 11:32:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01148 for ; Mon, 4 Feb 2002 16:22:44 -0500 (EST) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06220 for ; Mon, 4 Feb 2002 16:22:41 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g14LMBH19979; Mon, 4 Feb 2002 16:22:11 -0500 (EST) Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g14LM7707419; Mon, 4 Feb 2002 16:22:08 -0500 (EST) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1CJ1ZQTM; Mon, 4 Feb 2002 16:22:07 -0500 Received: from tweedy.NortelNetworks.com (dhcp229-100.engeast.baynetworks.com [192.32.229.100]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1JPBYXAB; Mon, 4 Feb 2002 16:22:07 -0500 Message-Id: <5.0.0.25.0.20020204160524.0342d1a0@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 04 Feb 2002 16:21:22 -0500 To: "Andrew Smith" From: Kwok Ho Chan Subject: RE: [Diffserv] ifSpeed with DiffServ PIB and Framework PIB [Previ ously Re: draft-ietf-rap-frameworkpib-06] Cc: "Kwok-Ho Chan", "Wijnen, Bert \(Bert\)" , , , , , , , In-Reply-To: References: <5.0.0.25.0.20020204110610.025da1f0@zbl6c002.corpeast.baynetworks.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 Andrew: Thanks for the clarification, Please see response inline. -- Kwok -- At 10:30 AM 2/4/02 -0800, Andrew Smith wrote: >I think you're all missing the point here. The relationship between the >"xxxRel" and the "xxxAbs" objects in the Diffserv PIB is just the same as in >the Diffserv MIB: > >RateRel = [ (RateAbs * 1000) / ifSpeed ] * 10000 > >The reason that both objects are present is that sometime you want to set a >configuration based on an absolute bandwidth (e.g. 1 Mbps), sometimes you >want to set it based on a fraction of the link's bandwidth (e.g. 20% of line >rate). In order to allow people to use either type of "policy", we >duplicated the object and had the two incarnations of it linked by the above >equation (it's a clumsy solution but it seemed like the best we could do >given the languages we have for describing the semantics of objects in SMI >or SPPI). > >The manager (or PDP) only has to set one of the two objects and, therefore, >does not need to know the ifSpeed if it sets the "xxxRel" object. If it sets >the "xxxAbs" object then it probably should have some way of knowing, a >priori, what speed each interface covered by a RoleCombination can handle - The above have not changed. But the policy does not always have to be associated to an interface, and that is where ifTable will not come into play. And that is why we may only want to indicate the capability as a "sink" or "drain" rate out of a scheduler data path element. Also even when only "xxxRel" is used, the PDP may still want to know the "xxxAbs" numbers to make sure a specific service is supported with the policy. >I'd suggest that the ifTable is a good way of discovering this information >ahead of time, through SNMP probably. Notice my reply to Bert is this change does not say anything about implementation and usage of ifTable. If policy is associated with an interface, there may be an association. But we may not want to have such a limitation from the policy sense. > [There's a larger issue too: what is >the defined behaviour when one or more members of a RoleCombination cannot >support a given policy rule (e.g. manager tries to set a 10Mbps RateAbs >policy on a 2Mbps interface?] > >So I'd object to Kwok's proposed change. > >Andrew Smith > > >-----Original Message----- >From: owner-rap@ops.ietf.org [mailto:owner-rap@ops.ietf.org]On Behalf Of >Kwok Ho Chan >Sent: Monday, February 04, 2002 8:35 AM >To: Wijnen, Bert (Bert) >Cc: Kwok-Ho Chan; rap@ops.ietf.org; diffserv@ietf.org; >saurabh.kapoor@wipro.com; srinivasu.nampelli@wipro.com; >ravi.attili@wipro.com; naganna.vydyula@wipro.com; >krishna.akkineni@wipro.com >Subject: RE: [Diffserv] ifSpeed with DiffServ PIB and Framework PIB >[Previ ously Re: draft-ietf-rap-frameworkpib-06] > > >Bert: >Please see response inline. >-- Kwok -- > >At 11:54 AM 2/4/02 +0100, Wijnen, Bert (Bert) wrote: > >Kwok writes: > > > > > > An alternative to the treatment of ifSpeed by the DiffServ PIB is to > > > add an attribute qosIfSchedulerCapsIfSpeed to qosIfSchedulerCapsEntry > > > to indicate the bit rate that can "sink" the output of the Scheduler > > > Data Path Element. This will allow the DiffServ PIB to not > > > rely on the Interface MIB. > > > > >So to me that sounds as "duplicating" information. > >How does this new field get filled out by the PEP? > >The "ifSpeed" being discussed is the information required for the PDP >to formulate the correct scheduling policy parameters based on network >wide policies. May be we should not use the term "ifSpeed" and allow >the scheduling policy parameter be not tightly coupled to interface. >This field should be filled out by the PEP as it sees what it needs to be >controlled by policy, and this is not necessarily an interface. > > >What if that field conflicts with ifSpeed? > >The scheduling policy parameter here may be totally different from >ifSpeed in the IF-MIB. So I don't think the notion of conflict exists. > > > >Would any network device not have the IF-MIB implemented anyway, > >so the fact that you remove the dependency from the PIB, does not > >mean that the IF-MIB does not have to be implemented in the device, > >does it? > >The removal of this dependency from the PIB does not say anything about >implementation of the IF-MIB at all. It is up to the implementation what it >wants/needs to do. > > > >Bert > > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >https://www1.ietf.org/mailman/listinfo/diffserv >Archive: >http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Tue Feb 5 11:52:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07949 for ; Tue, 5 Feb 2002 11:52:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA14361 for diffserv-archive@odin.ietf.org; Tue, 5 Feb 2002 11:52:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11933; Tue, 5 Feb 2002 11:32:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00660 for ; Tue, 5 Feb 2002 09:21:33 -0500 (EST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00611 for ; Tue, 5 Feb 2002 09:21:28 -0500 (EST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id PAA09436; Tue, 5 Feb 2002 15:20:30 +0100 Received: from lig32-239-172-111.emea.lig-dial.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA71554 from ; Tue, 5 Feb 2002 15:20:20 +0100 Message-Id: <3C5FA7A0.EA70F4A1@hursley.ibm.com> Date: Tue, 05 Feb 2002 10:36:32 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: "Romascanu, Dan (Dan)" Cc: "Wijnen, Bert (Bert)" , Kwok Ho Chan , rap@ops.ietf.org, diffserv@ietf.org, saurabh.kapoor@wipro.com, srinivasu.nampelli@wipro.com, ravi.attili@wipro.com, naganna.vydyula@wipro.com, krishna.akkineni@wipro.com Subject: Re: [Diffserv] ifSpeed with DiffServ PIB and Framework PIB [Previously Re: draft-ietf-rap-frameworkpib-06] 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 I'm not going to jump on anybody... but it seems to me that we don't have a consensus for this non-editorial change, and the WG Last Call ended about 2 months ago. So Kwok, please DO NOT make this change unless you want me to start a new WG Last Call. Thanks Brian "Romascanu, Dan (Dan)" wrote: > > This discussion has for me some confusing aspects. The existence of > several management protocols is not something new. After all most of the > devices that I know 'always' supported at least two management protocols > - CLI and SNMP - now COPS emerged for policy configuration on some > devices, and there are several other around. > > I am not sure that the requirement of not duplicating information is > caught in any of the standards. It is more a common sense requirement, > but behind it hides the more complex issue of a single data model for > all IETF management protocols. This is the real issue that we need to > face as we advance towards the 'new generation' of management protocols, > and in the absence of a valid solution to this problem no real > consistence can be expected in this space. > > Before Brian jumps on me, I would say that this discussion might be > appropriate for one of the 'management - new generation' lists, but > before we move there (if anybody is interested in the continuation of a > thread on this) I wanted to have the reply visible for the participants > in the original thread. > > Regards, > > Dan > > > -----Original Message----- > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > Sent: Monday, February 04, 2002 12:54 PM > > To: Kwok Ho Chan; rap@ops.ietf.org; diffserv@ietf.org > > Cc: saurabh.kapoor@wipro.com; srinivasu.nampelli@wipro.com; > > ravi.attili@wipro.com; naganna.vydyula@wipro.com; > > krishna.akkineni@wipro.com > > Subject: RE: [Diffserv] ifSpeed with DiffServ PIB and > > Framework PIB [Previously Re: draft-ietf-rap-frameworkpib-06] > > > > > > Kwok writes: > > > > > > An alternative to the treatment of ifSpeed by the DiffServ PIB is to > > > add an attribute qosIfSchedulerCapsIfSpeed to > > qosIfSchedulerCapsEntry > > > to indicate the bit rate that can "sink" the output of the Scheduler > > > Data Path Element. This will allow the DiffServ PIB to not > > > rely on the Interface MIB. > > > > > So to me that sounds as "duplicating" information. > > How does this new field get filled out by the PEP? > > What if that field conflicts with ifSpeed? > > > > Would any network device not have the IF-MIB implemented anyway, > > so the fact that you remove the dependency from the PIB, does not > > mean that the IF-MIB does not have to be implemented in the device, > > does it? > > > > Bert _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Tue Feb 5 11:54:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07997 for ; Tue, 5 Feb 2002 11:54:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA14527 for diffserv-archive@odin.ietf.org; Tue, 5 Feb 2002 11:54:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12762; Tue, 5 Feb 2002 11:40:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12659 for ; Tue, 5 Feb 2002 11:40:03 -0500 (EST) Received: from energia3.cosern.com.br ([200.179.191.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07280 for ; Tue, 5 Feb 2002 11:39:54 -0500 (EST) Received: from dsilab09rn (DSI_LAB09_RN [10.12.10.13]) by energia3.cosern.com.br with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id D21TQ45G; Tue, 5 Feb 2002 14:35:39 -0200 Message-ID: <004701c1ae63$81e5c940$0d0a0c0a@cosernet> From: "webmaster" To: References: <009601c1938c$35c8c860$838fa8c0@wipsys.stph.net> <49FF5C6DDBD8D311BBBD009027DE980C031F44CB@UNIWEST1> <5.0.0.25.0.20020203093120.020a3eb0@zbl6c002.corpeast.baynetworks.com> <006901c1ad9e$f1cbfc40$0d0a0c0a@cosernet> <3C5FA8F5.865E897B@hursley.ibm.com> Subject: Re: [Diffserv] IPng and Diffserv Date: Tue, 5 Feb 2002 14:38:13 -0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 8bit 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 Ok Carpenter, Brian I will change to diffserv-interest list , my apologise . But , if you read my mail completely you wil see when I talk (write) about draft-rajahalme-ipv6-flow-label-00.txt . Thanks . Bernardo Oliveira . ----- Original Message ----- From: "Brian E Carpenter" To: "webmaster" Cc: Sent: Tuesday, February 05, 2002 7:42 AM Subject: Re: [Diffserv] IPng and Diffserv Bernardo, This is a mailing list for standardisation work, not for thesis research. Also, you are looking at an obsolete draft - please look at draft-rajahalme-ipv6-flow-label-00.txt (which will be updated soon). For general discussion of diffserv, please use diffserv-interest@ietf.org instead. To join the list, go to http://www.ietf.org/mailman/listinfo/diffserv-interest Brian Carpenter diffserv WG co-chair webmaster wrote: > > Hi > > Let introduce myself : My name is Bernardo Oliveira and I am a pos-graduate > student of Rio Grande do Norta Federal University (this is a state of > northwest > of Brazil). > Now I'm searching material for my thesis. My subject refer to > DIFFSERV over IPNG to transport VOIP traffic. > So I am interested in the use of flow label field for DIFFSERV. > In draft-conta-ipv6-flow-label-02 of july/01 (A. Conta and B. Carpenter) > we have a proposal to use the flow label field to DIFFSERV, but I dont > understand yet how to do it ! > The flow label field is bigger than traffic class field (this is a fact), so > to me it means that we have a possibility to use one more granularity > that is, we can define more classes beyond of AF,EF,BE existent classes, or > more "levels" of these classes , something like "AF Super" or "EF GOLD > Hiper". > So to do this it is necessary create a news DSCPs . This idea looks like a > "new > DIFFSERV" or a "Extended DIFFSERV" > Are my ideas corrects ??? > Is there anybody talking (writing) about this new classification (news > DSCPs) ?. I found nothing > about it. > On the other hand in draft-rajahalme-ipv6-flow.label-00 of November/01 (A. > Conta > and J. Rajahalme) Alex Conta doesn´t talk anything about DIFFSERV. > what does it means ? Is The first draft a dead idea ? , Wouldn't we use the > flow label to DIFFSERV ? > > Bernardo Oliveira > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.ht ml -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland Board Chairman, Internet Society http://www.isoc.org _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.ht ml _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@ns.ietf.org Tue Feb 5 18:27:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23489 for ; Tue, 5 Feb 2002 18:27:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA08805 for diffserv-archive@odin.ietf.org; Tue, 5 Feb 2002 18:27:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08065; Tue, 5 Feb 2002 18:12:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08035 for ; Tue, 5 Feb 2002 18:12:53 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22950; Tue, 5 Feb 2002 18:12:46 -0500 (EST) Message-Id: <200202052312.SAA22950@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , diffserv@ietf.org From: The IESG Date: Tue, 05 Feb 2002 18:12:46 -0500 Subject: [Diffserv] Document Action: New Terminology and Clarification for Diffserv to Informational 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 approved the Internet-Draft 'New Terminology and Clarification for Diffserv' as an Informational RFC. This document is the product of the Differentiated Services Working Group. The IESG contact persons are Allison Mankin and Scott Bradner. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Wed Feb 6 20:42:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06609 for ; Wed, 6 Feb 2002 20:42:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA09202 for diffserv-archive@odin.ietf.org; Wed, 6 Feb 2002 20:42:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA08012; Wed, 6 Feb 2002 20:26:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA07985 for ; Wed, 6 Feb 2002 20:26:42 -0500 (EST) Received: from web20406.mail.yahoo.com (web20406.mail.yahoo.com [216.136.226.125]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA06281 for ; Wed, 6 Feb 2002 20:26:39 -0500 (EST) Message-ID: <20020207012641.24388.qmail@web20406.mail.yahoo.com> Received: from [128.230.14.53] by web20406.mail.yahoo.com via HTTP; Wed, 06 Feb 2002 17:26:41 PST Date: Wed, 6 Feb 2002 17:26:41 -0800 (PST) From: Ali badilli To: diffserv@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Diffserv] A multi-domain PHB question 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, I am doing researh that is partly related Diffserv. I have the following question if anybody has comments I will be really appreciated. In a single Diffserv domain a customer has SLA that specifies the service will be received by customer. For example a domain can guarantee that the customer's traffic will receive EF PHB within domain. SLA does not specifies the metrics value. Lets say EF require less than 20 ms delay and 0.1% loss, but this not specified in SLA. This is ok in single domain. If a domain is geting service from another domain and providing its customer how it will make sure that the requirements are still satisfied. For clarification let consider the following situation. Domain A is the customer of domain B and has service from B for EF traffic, and then provides this service to its customers. Now, assume that in domain B EF packets will have 15ms delay, and 0.1%loss and in domain A will have 15ms delay and 0.1% loss. Now, the EF traffic from a customer in domain A to any destination in domain B will have 30ms which exceeds the EF requirement. We cannot avoid this situation because the value of constraints are not specified. How this situation will be taken care of it? I am sorry if I am missing something. Thanks. __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@ns.ietf.org Thu Feb 7 13:36:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05127 for ; Thu, 7 Feb 2002 13:36:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA08232 for diffserv-archive@odin.ietf.org; Thu, 7 Feb 2002 13:36:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06951; Thu, 7 Feb 2002 13:23:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06906 for ; Thu, 7 Feb 2002 13:23:08 -0500 (EST) Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04624 for ; Thu, 7 Feb 2002 13:23:06 -0500 (EST) From: Mark_Hamilton@3com.com Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g17IN3Q03597 for ; Thu, 7 Feb 2002 10:23:03 -0800 (PST) Received: from hqsmtp01.3com.com (hqsmtp01.ops.3com.com [139.87.49.79]) by opal.3com.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g17IN2C02552 for ; Thu, 7 Feb 2002 10:23:02 -0800 (PST) To: Importance: Normal Date: Thu, 7 Feb 2002 10:22:46 -0800 Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Diffserv] unsubscribe 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 unsubscribe ----- Original Message ----- From: "Ali badilli" To: Sent: Wednesday, February 06, 2002 5:26 PM Subject: [Diffserv] A multi-domain PHB question > > Hi all, > > I am doing researh that is partly related Diffserv. I > have the following question if anybody has comments I > will be really appreciated. > > In a single Diffserv domain a customer has SLA that > specifies the service will be received by customer. > For example a domain can guarantee that the customer's > traffic will receive EF PHB within domain. SLA does > not specifies the metrics value. Lets say EF require > less than 20 ms delay and 0.1% loss, but this not > specified in SLA. This is ok in single domain. > > If a domain is geting service from another domain and > providing its customer how it will make sure that the > requirements are still satisfied. For clarification > let consider the following situation. > > Domain A is the customer of domain B and has service > from B for EF traffic, and then provides this service > to its customers. Now, assume that in domain B EF > packets will have 15ms delay, and 0.1%loss and in > domain A will have 15ms delay and 0.1% loss. Now, the > EF traffic from a customer in domain A to any > destination in domain B will have 30ms which exceeds > the EF requirement. We cannot avoid this situation > because the value of constraints are not specified. > > How this situation will be taken care of it? > > I am sorry if I am missing something. > > Thanks. > > > > > > > > > __________________________________________________ > Do You Yahoo!? > Send FREE Valentine eCards with Yahoo! Greetings! > http://greetings.yahoo.com > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.ht ml _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@ns.ietf.org Thu Feb 7 13:52:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05609 for ; Thu, 7 Feb 2002 13:52:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA09291 for diffserv-archive@odin.ietf.org; Thu, 7 Feb 2002 13:52:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08697; Thu, 7 Feb 2002 13:43:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08669 for ; Thu, 7 Feb 2002 13:43:00 -0500 (EST) Received: from mother.pmc-sierra.bc.ca (mother.pmc-sierra.bc.ca [216.241.224.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05288 for ; Thu, 7 Feb 2002 13:42:53 -0500 (EST) Received: (qmail 27105 invoked by uid 104); 7 Feb 2002 18:42:24 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4185. . Clean. Processed in 0.460125 secs); 07 Feb 2002 18:42:24 -0000 Received: from unknown (HELO procyon.pmc-sierra.bc.ca) (134.87.115.1) by mother.pmc-sierra.bc.ca with SMTP; 7 Feb 2002 18:42:23 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g17IgNm05779; Thu, 7 Feb 2002 10:42:23 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Feb 2002 10:42:24 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A527@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Ali badilli'" , diffserv@ietf.org Subject: RE: [Diffserv] A multi-domain PHB question Date: Thu, 7 Feb 2002 10:42:21 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi Ali, I think what you have missed is that the SLA should not be based on PHB, rather it should be based on PDB. Any Diffserv provider will probably offer a number of PDB services, with some bounds on delay, jitter, and loss. If a customer requires a service with < 0.1% loss and <15ms delay, then it is up to the service provider A to come up with a combination of its own PDB and PDBs offered by service provider B, to fulfill customer's SLA. For example service provider A may offer 3 types of services based on some PDBs which are in turn based on some PHBs: A1) delay < 5ms, jitter < 5ms, loss < 0.02% A2) delay < 10ms, jitter < 10ms, loss < 0.1% A3) delay < 50ms , jitter < 50ms, loss < 1% And service provider B may offer 3 types of services based on some PDBs which are in turn based on some PHBs: B1) delay < 10 ms, jitter < 10ms, loss < 0.05% B2) delay < 50ms, jitter < 50ms, loss < 0.5% B3) delay not guaranteed , jitter not guaranteed, loss < 10% To fulfill customer's SLA provider A could choose A1+B1. Note: This means that provider A may not be able to fulfill some customer's SLAs. For example if a customer was asking for delay <10ms and the packet had to be routed through provider B. Does that answer your question? -Shahram > -----Original Message----- > From: Ali badilli [mailto:hasanoglu69@yahoo.com] > Sent: Wednesday, February 06, 2002 8:27 PM > To: diffserv@ietf.org > Subject: [Diffserv] A multi-domain PHB question > > > Hi all, > > I am doing researh that is partly related Diffserv. I > have the following question if anybody has comments I > will be really appreciated. > > In a single Diffserv domain a customer has SLA that > specifies the service will be received by customer. > For example a domain can guarantee that the customer's > traffic will receive EF PHB within domain. SLA does > not specifies the metrics value. Lets say EF require > less than 20 ms delay and 0.1% loss, but this not > specified in SLA. This is ok in single domain. > > If a domain is geting service from another domain and > providing its customer how it will make sure that the > requirements are still satisfied. For clarification > let consider the following situation. > > Domain A is the customer of domain B and has service > from B for EF traffic, and then provides this service > to its customers. Now, assume that in domain B EF > packets will have 15ms delay, and 0.1%loss and in > domain A will have 15ms delay and 0.1% loss. Now, the > EF traffic from a customer in domain A to any > destination in domain B will have 30ms which exceeds > the EF requirement. We cannot avoid this situation > because the value of constraints are not specified. > > How this situation will be taken care of it? > > I am sorry if I am missing something. > > Thanks. > > > > > > > > > __________________________________________________ > Do You Yahoo!? > Send FREE Valentine eCards with Yahoo! Greetings! > http://greetings.yahoo.com > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Fri Feb 8 03:13:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00891 for ; Fri, 8 Feb 2002 03:13:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA22955 for diffserv-archive@odin.ietf.org; Fri, 8 Feb 2002 03:13:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA21703; Fri, 8 Feb 2002 02:59:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA21673 for ; Fri, 8 Feb 2002 02:59:11 -0500 (EST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00550 for ; Fri, 8 Feb 2002 02:59:09 -0500 (EST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id IAA07116; Fri, 8 Feb 2002 08:58:31 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA29906 from ; Fri, 8 Feb 2002 08:58:30 +0100 Message-Id: <3C638523.67AEE930@hursley.ibm.com> Date: Fri, 08 Feb 2002 08:58:27 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Shahram Davari Cc: "'Ali badilli'" , diffserv@ietf.org Subject: Re: [Diffserv] A multi-domain PHB question References: <4B6D09F3B826D411A67300D0B706EFDE84A527@nt-exch-yow.pmc-sierra.bc.ca> 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 Shahram, An even more basic point is that there must be an SLA in place at every ISP/ISP boundary, in order for end to end diffserv to work in the general case. This is clearly many years into the future, and it's a business issue and not something we can usefully debate in the IETF. Certainly RFC 3086 is relevant, but beyond that it is perhaps more in the scope of the NSIS working group than this one. Brian Shahram Davari wrote: > > Hi Ali, > > I think what you have missed is that the SLA should not > be based on PHB, rather it should be based on PDB. Any > Diffserv provider will probably offer a number of PDB > services, with some bounds on delay, jitter, and loss. > > If a customer requires a service with < 0.1% loss > and <15ms delay, then it is up to the service provider A to > come up with a combination of its own PDB and PDBs offered > by service provider B, to fulfill customer's SLA. > > For example service provider A may offer 3 types of services > based on some PDBs which are in turn based on some PHBs: > > A1) delay < 5ms, jitter < 5ms, loss < 0.02% > A2) delay < 10ms, jitter < 10ms, loss < 0.1% > A3) delay < 50ms , jitter < 50ms, loss < 1% > And service provider B may offer 3 types of services > based on some PDBs which are in turn based on some PHBs: > > B1) delay < 10 ms, jitter < 10ms, loss < 0.05% > B2) delay < 50ms, jitter < 50ms, loss < 0.5% > B3) delay not guaranteed , jitter not guaranteed, loss < 10% > > To fulfill customer's SLA provider A could choose A1+B1. > > Note: This means that provider A may not be able to > fulfill some customer's SLAs. For example if a customer > was asking for delay <10ms and the packet had to be routed > through provider B. > > Does that answer your question? > > -Shahram > > > -----Original Message----- > > From: Ali badilli [mailto:hasanoglu69@yahoo.com] > > Sent: Wednesday, February 06, 2002 8:27 PM > > To: diffserv@ietf.org > > Subject: [Diffserv] A multi-domain PHB question > > > > > > Hi all, > > > > I am doing researh that is partly related Diffserv. I > > have the following question if anybody has comments I > > will be really appreciated. > > > > In a single Diffserv domain a customer has SLA that > > specifies the service will be received by customer. > > For example a domain can guarantee that the customer's > > traffic will receive EF PHB within domain. SLA does > > not specifies the metrics value. Lets say EF require > > less than 20 ms delay and 0.1% loss, but this not > > specified in SLA. This is ok in single domain. > > > > If a domain is geting service from another domain and > > providing its customer how it will make sure that the > > requirements are still satisfied. For clarification > > let consider the following situation. > > > > Domain A is the customer of domain B and has service > > from B for EF traffic, and then provides this service > > to its customers. Now, assume that in domain B EF > > packets will have 15ms delay, and 0.1%loss and in > > domain A will have 15ms delay and 0.1% loss. Now, the > > EF traffic from a customer in domain A to any > > destination in domain B will have 30ms which exceeds > > the EF requirement. We cannot avoid this situation > > because the value of constraints are not specified. > > > > How this situation will be taken care of it? > > > > I am sorry if I am missing something. > > > > Thanks. > > _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Fri Feb 8 12:19:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15660 for ; Fri, 8 Feb 2002 12:19:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA23392 for diffserv-archive@odin.ietf.org; Fri, 8 Feb 2002 12:19:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22569; Fri, 8 Feb 2002 12:07:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA22543 for ; Fri, 8 Feb 2002 12:07:10 -0500 (EST) 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 MAA14918 for ; Fri, 8 Feb 2002 12:07:07 -0500 (EST) Received: (qmail 6249 invoked by uid 104); 8 Feb 2002 17:06:39 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4185. . Clean. Processed in 0.457785 secs); 08 Feb 2002 17:06:39 -0000 Received: from unknown (HELO procyon.pmc-sierra.bc.ca) (134.87.115.1) by father.pmc-sierra.bc.ca with SMTP; 8 Feb 2002 17:06:39 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id g18H6am00589; Fri, 8 Feb 2002 09:06:37 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Feb 2002 09:06:34 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE84A539@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Brian E Carpenter'" Cc: "'Ali badilli'" , diffserv@ietf.org Subject: RE: [Diffserv] A multi-domain PHB question Date: Fri, 8 Feb 2002 09:06:31 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi Brian I agree with you that NSIS WG is the right place for this topic. Yours, -Shahram > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Friday, February 08, 2002 2:58 AM > To: Shahram Davari > Cc: 'Ali badilli'; diffserv@ietf.org > Subject: Re: [Diffserv] A multi-domain PHB question > > > Shahram, > > An even more basic point is that there must be an SLA in place > at every ISP/ISP boundary, in order for end to end diffserv > to work in the general case. This is clearly many years into > the future, and it's a business issue and not something we > can usefully debate in the IETF. > > Certainly RFC 3086 is relevant, but beyond that it is perhaps more > in the scope of the NSIS working group than this one. > > Brian > > Shahram Davari wrote: > > > > Hi Ali, > > > > I think what you have missed is that the SLA should not > > be based on PHB, rather it should be based on PDB. Any > > Diffserv provider will probably offer a number of PDB > > services, with some bounds on delay, jitter, and loss. > > > > If a customer requires a service with < 0.1% loss > > and <15ms delay, then it is up to the service provider A to > > come up with a combination of its own PDB and PDBs offered > > by service provider B, to fulfill customer's SLA. > > > > For example service provider A may offer 3 types of services > > based on some PDBs which are in turn based on some PHBs: > > > > A1) delay < 5ms, jitter < 5ms, loss < 0.02% > > A2) delay < 10ms, jitter < 10ms, loss < 0.1% > > A3) delay < 50ms , jitter < 50ms, loss < 1% > > And service provider B may offer 3 types of services > > based on some PDBs which are in turn based on some PHBs: > > > > B1) delay < 10 ms, jitter < 10ms, loss < 0.05% > > B2) delay < 50ms, jitter < 50ms, loss < 0.5% > > B3) delay not guaranteed , jitter not guaranteed, loss < 10% > > > > To fulfill customer's SLA provider A could choose A1+B1. > > > > Note: This means that provider A may not be able to > > fulfill some customer's SLAs. For example if a customer > > was asking for delay <10ms and the packet had to be routed > > through provider B. > > > > Does that answer your question? > > > > -Shahram > > > > > -----Original Message----- > > > From: Ali badilli [mailto:hasanoglu69@yahoo.com] > > > Sent: Wednesday, February 06, 2002 8:27 PM > > > To: diffserv@ietf.org > > > Subject: [Diffserv] A multi-domain PHB question > > > > > > > > > Hi all, > > > > > > I am doing researh that is partly related Diffserv. I > > > have the following question if anybody has comments I > > > will be really appreciated. > > > > > > In a single Diffserv domain a customer has SLA that > > > specifies the service will be received by customer. > > > For example a domain can guarantee that the customer's > > > traffic will receive EF PHB within domain. SLA does > > > not specifies the metrics value. Lets say EF require > > > less than 20 ms delay and 0.1% loss, but this not > > > specified in SLA. This is ok in single domain. > > > > > > If a domain is geting service from another domain and > > > providing its customer how it will make sure that the > > > requirements are still satisfied. For clarification > > > let consider the following situation. > > > > > > Domain A is the customer of domain B and has service > > > from B for EF traffic, and then provides this service > > > to its customers. Now, assume that in domain B EF > > > packets will have 15ms delay, and 0.1%loss and in > > > domain A will have 15ms delay and 0.1% loss. Now, the > > > EF traffic from a customer in domain A to any > > > destination in domain B will have 30ms which exceeds > > > the EF requirement. We cannot avoid this situation > > > because the value of constraints are not specified. > > > > > > How this situation will be taken care of it? > > > > > > I am sorry if I am missing something. > > > > > > Thanks. > > > > _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@ns.ietf.org Mon Feb 11 03:50:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26657 for ; Mon, 11 Feb 2002 03:50:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA24418 for diffserv-archive@odin.ietf.org; Mon, 11 Feb 2002 03:50:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA23103; Mon, 11 Feb 2002 03:23:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA23072 for ; Mon, 11 Feb 2002 03:23:47 -0500 (EST) Received: from essi.essi.fr (essi.essi.fr [157.169.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26387 for ; Mon, 11 Feb 2002 03:23:35 -0500 (EST) Received: from essi.fr (eaux.essi.fr [157.169.2.1]) by essi.essi.fr (8.11.2/8.11.1) with ESMTP id g1B8MAw09430 for ; Mon, 11 Feb 2002 09:22:10 +0100 (MET) Message-ID: <3C677F17.A02A1F97@essi.fr> Date: Mon, 11 Feb 2002 09:21:43 +0100 From: Lamia ROMDHANI Organization: essi X-Mailer: Mozilla 4.77 [fr] (X11; U; Linux 2.4.3-12 i686) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Diffserv provisionning with COPS.. 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, What about Diffserv provisionning with COPS:performance degree , problems and eventual solutions that can be made? Thankyou. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@ns.ietf.org Mon Feb 11 05:50:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28024 for ; Mon, 11 Feb 2002 05:50:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA00410 for diffserv-archive@odin.ietf.org; Mon, 11 Feb 2002 05:51:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA29451; Mon, 11 Feb 2002 05:35:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA29423 for ; Mon, 11 Feb 2002 05:35:28 -0500 (EST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27873 for ; Mon, 11 Feb 2002 05:35:25 -0500 (EST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id LAA09598; Mon, 11 Feb 2002 11:34:55 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA82706 from ; Mon, 11 Feb 2002 11:34:52 +0100 Message-Id: <3C679E49.8CE1BC87@hursley.ibm.com> Date: Mon, 11 Feb 2002 11:34:49 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Lamia ROMDHANI Cc: diffserv@ietf.org Subject: Re: [Diffserv] Diffserv provisionning with COPS.. References: <3C677F17.A02A1F97@essi.fr> 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 I'm not sure I see the relevance of this qustion to the goals of this WG. Brian Lamia ROMDHANI wrote: > > Hi, > What about Diffserv provisionning with COPS:performance degree , > problems and eventual solutions that can be made? > Thankyou. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html