From daemon@optimus.ietf.org Fri Nov 2 17:58:06 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21267 for ; Fri, 2 Nov 2001 17:58:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA03308 for diffserv-archive@odin.ietf.org; Fri, 2 Nov 2001 17:58:08 -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 RAA02700; Fri, 2 Nov 2001 17:32: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 RAA02670 for ; Fri, 2 Nov 2001 17:32:09 -0500 (EST) Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20514 for ; Fri, 2 Nov 2001 17:32:06 -0500 (EST) Received: from pmismtp03.wcomnet.com ([166.38.62.38]) by firewall.wcom.com (PMDF V5.2-33 #42260) with ESMTP id <0GM700I0B2KQSP@firewall.wcom.com> for diffserv@ietf.org; Fri, 2 Nov 2001 22:31:38 +0000 (GMT) Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GM700C012KBGQ@pmismtp03.wcomnet.com>; Fri, 02 Nov 2001 22:31:37 +0000 (GMT) Received: from lyao ([166.60.2.199]) by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GM7009CP2JYNC@pmismtp03.wcomnet.com>; Fri, 02 Nov 2001 22:31:10 +0000 (GMT) Date: Fri, 02 Nov 2001 17:30:59 -0500 From: Lei Yao To: diffserv@ietf.org, nichols@packetdesign.com Reply-to: lei.yao@wcom.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Subject: [Diffserv] backward compatiblity with RFC 1349 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 In RFC1349, the TOS byte is divided into three fields: Precedence(0-2), TOS(3-6) and MBZ(7). The second field, "TOS", is intended to denote how the network should treat packets differently on delay, throughput, reliability and cost. The following marks of the TOS field have been defined 1000 -- minimize delay 0100 -- maximize throughput 0010 -- maximize reliability 0001 -- minimize monetary cost 0000 -- normal service RFC 2474 only describes the backward compatibility with the IP Precedence field. I wonder if the backward compatibility with the TOS field was discussed in the working group. If yes, what is the conclusion? If no, please comment. Thanks. Lei _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Sun Nov 4 01:39:57 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29298 for ; Sun, 4 Nov 2001 01:39:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA24141 for diffserv-archive@odin.ietf.org; Sun, 4 Nov 2001 01:39:58 -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 AAA15751; Sun, 4 Nov 2001 00:44: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 AAA15686 for ; Sun, 4 Nov 2001 00:44:45 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24135; Sun, 4 Nov 2001 00:44:43 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id fA45i9T12356; Sat, 3 Nov 2001 21:44:09 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id fA45iVP25283; Sat, 3 Nov 2001 21:44:31 -0800 (PST) Received: from PC2.cisco.com (sjc-vpn1-554.cisco.com [10.21.98.42]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id VAA16851; Sat, 3 Nov 2001 21:44:07 -0800 (PST) Message-Id: <4.3.2.7.2.20011103212234.0228afb8@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 03 Nov 2001 21:42:17 -0800 To: "Andrew Smith" From: Andy Bierman Cc: , "Diffserv" In-Reply-To: References: <4.3.2.7.2.20011102081257.022bb5d0@fedex.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Diffserv] Re: [RMONMIB] RE: DEFVAL in dsmonAggGroupIndex - SMIC error Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 01:11 PM 11/2/2001 -0800, Andrew Smith wrote: >I've (still) got serious problems with this MIB, its relationship to the >DiffServ MIB and the "aggregation group" concept. Haven't spoken up recently >because I thought others would taken care of it by now. > >1. You're duplicating functionality from the DiffServ MIB here. If that's >fine with IESG then OK but it seems like a bad idea to me. People have >argued on the RMON list before that DSMON is meant for probes, not switches >but I believe a large proportion of DSMON implementations will end up inside >switches with consequent waste of resources. I do not think there is a good >case to be made for optimising this MIB for the "standalone probe" case. Which objects exactly are being duplicated? >2. You're inventing a new grouping concept with its own number space for >something that the DiffServ conceptual management model, MIB and PIB do >using their "data path" concept and which they have their own numberspace >for. You should re-use that concept or else persuade DiffServ to use your >concept but there is no excuse for having duplicate mechanisms in MIBs that >are being developed/published at roughly the same time by IETF (is this due >to OPS and TSV ADs not talking to each other enough? No apologies for adding >Diffserv WG to this message). Please be specific. What exactly are you talking about? Are you referring to the DSMON Aggregation Profiles? We try to make it very clear in the draft that these DSCP to aggregation group mappings are for monitoring purposes only, intended for the case where the DSMON probe has less then 64 'buckets' per counter object (e.g. packet counter). >3. You're overloading your dsmonAggGroupIndex numberspace with the >"convenience functionality" of letting the group index equal the DSCP. >There's no need for this and it cannot be useful unless you have some >mandated behaviour that relies on this 1:1 mapping e.g. a default setting >for the table on power-up or initial state. Leaving it as an option (see >"SHOULD" below) makes it useless in a multi-vendor world. I don't understand the objection here. Are you referring to the INDEX range that starts from zero instead of one? This is a rather minor SMI warning, isn't it? What is useless in a multi-vendor world? >Specifics: > >4. "dsmonAggGroupIndex OBJECT-TYPE > SYNTAX DsmonAggGroupIndex > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The aggregation group which contains this DSCP value. Upon > creation of a new sub-tree (set of 64 entries with the same > dsmonAggControlIndex value) in this table, the agent SHOULD > initialize all related instances of this object to the value > zero. > > This object MUST NOT be modified if the > dsmonAggControlLocked object is equal to 'true'." > DEFVAL { 0 }" > >a) This description does not make sense (to me): dsmonAggControlIndex does >not appear in this table so how is creation of a new sub-tree related to >entries in this table? Please clarify this wording. Or is this a typo? dsmonAggControlIndex is the first INDEX component of the dsmonAggProfileEntry, where dsmonAggGroupIndex is defined. Not a typo. >b) What's the point of the "SHOULD" directive here? Some people insisted that there should be a default configuration, with all DSCPs mapped to the same aggregation group. I don't really agree, but that's the point. >c) Define "related instances" more precisely. All entries in this table with the same INDEX values. Standard meaning. >d) You can't say that a read-write variable "MUST NOT" be modified (by >whom?) - you can define that if you try to do so then the operation will >pass/fail etc. but you can't use a MIB to enforce what a manager can/cannot >attempt (you might as well add "please" :-)). Where in the SMI does it say this type of 'lock statement' is not allowed? There is a high-level lock for modifying any of the aggregation profiles in the MIB design. Modifying the DSCP mappings on the fly is bad for statistics aggregation and may make implementation harder. >e) I don't think you can rely on "0" as a special value of DSCP here - use >something like -1 if you really need to use a DEFVAL. Zero is not really a special value -- and I think you are referring to the aggregation group index zero, not a DSCP value of zero. There's nothing special about this group index value either -- people thought that some number had to be picked for a default. >That's all on this particular issue, I guess I ought to read the rest of the >MIB now ... > >Andrew Smith Andy >-----Original Message----- >From: owner-mibs@ops.ietf.org [mailto:owner-mibs@ops.ietf.org]On Behalf >Of Andy Bierman >Sent: Friday, November 02, 2001 8:31 AM >To: Harrie Hazewinkel >Cc: bwijnen@lucent.com; rmonmib@ietf.org; mibs@ops.ietf.org >Subject: DEFVAL in dsmonAggGroupIndex - SMIC error > > >At 06:33 PM 11/1/2001 -0800, Harrie Hazewinkel wrote: > > > >Now that I looked at this some more, I think the SMIC is wrong. >This DEFVAL should not be a syntax error. > >The dsmonAggGroupIndex object itself is read-write object >and not an INDEX in the table its defined in. The DEFVAL clause >indicates that the initial aggGroup value an agent should set for each >DSCP mapping. All DSCPs in the same group -- perfectly valid concept, >perfectly valid SMIv2 syntax. > >However, the dsmonAggGroupIndex object is also declared as one of the >INDEX components in the dsmonAggGroupEntry. SMIC is complaining about >the DEFVAL that is only meant to apply to original OBJECT-TYPE macro, >not a DEFVAL for the INDEX -- that doesn't even make sense. > > >--On Thursday, November 1, 2001 7:40 AM -0800 Andy Bierman > > wrote: > > > >>At 01:39 PM 11/1/2001 +0100, Wijnen, Bert (Bert) wrote: > >>>OK, 2 issues basically came out after your approval. > >>> > >>>- SMICng complains about having a DEFVAL for dsmonAggGroupIndex > >>> since this object is used as an index object as well. Andy > >>> did put it in since you insisted. I am discussing the matter > >>> with the SMIv2 doc editors > >>>- Frank Strauss (I asked him to check to see if his compiler > >>> would also complain about that indexing thing, which it did not, > >>> but then Juergen has now added a lvl 4 warning about it). > >>> Frank brought out that the OID could become too long based on > >>> some index definitions. So Andy has posted a new rev to address > >>> that > > >.... > > > >>The rules are too strict! > > > >I agree here. When a default value is written in a description > >it seems to be allowe, but when a DEFVAL is used it is > >not because of compilers complain. That sounds > >contradictionary to me. The DEFVAL-cluase is > >(IMHO) there to support more formally the > >semantics of the object, but it may neither > >create a conflict with the semantics provided in > >the description-clause. > > > > > >Maybe far fetched, but I can envision such a scenario. > >Someone can create some object in X-MIB with > >a read-create ACCESS and a DEFVAL seems appropriate. > >Later someone else in Y-MIB uses that object in an > >index, because it wants to extend information for > >that perticular object only. > >The only option (to keep compilers happy) will then > >be create/duplicate the object and provide the same > >semantics without DEFVAL. > > > >Hmm.... > >Someone already did that -- in DSMON-MIB ! > > > > > >My thoughts about it, > > > > > >Harrie Hazewinkel > >Andy > > > > >_______________________________________________ >RMONMIB mailing list >RMONMIB@ietf.org >http://www1.ietf.org/mailman/listinfo/rmonmib _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Mon Nov 5 04:14:00 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09504 for ; Mon, 5 Nov 2001 04:13:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA28912 for diffserv-archive@odin.ietf.org; Mon, 5 Nov 2001 04:14: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 DAA28107; Mon, 5 Nov 2001 03:52:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29435 for ; Fri, 2 Nov 2001 15:48:39 -0500 (EST) Received: from swan.prod.itd.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17632; Fri, 2 Nov 2001 15:48:37 -0500 (EST) Received: from user-vcaul5i.dsl.mindspring.com ([216.175.84.178] helo=ANDREWHOME) by swan.prod.itd.earthlink.net with smtp (Exim 3.33 #1) id 15zlEw-0001Tj-00; Fri, 02 Nov 2001 12:48:34 -0800 From: "Andrew Smith" To: Cc: "Diffserv" Date: Fri, 2 Nov 2001 13:11:46 -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 In-reply-to: <4.3.2.7.2.20011102081257.022bb5d0@fedex.cisco.com> Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Diffserv] RE: DEFVAL in dsmonAggGroupIndex - SMIC error 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've (still) got serious problems with this MIB, its relationship to the DiffServ MIB and the "aggregation group" concept. Haven't spoken up recently because I thought others would taken care of it by now. 1. You're duplicating functionality from the DiffServ MIB here. If that's fine with IESG then OK but it seems like a bad idea to me. People have argued on the RMON list before that DSMON is meant for probes, not switches but I believe a large proportion of DSMON implementations will end up inside switches with consequent waste of resources. I do not think there is a good case to be made for optimising this MIB for the "standalone probe" case. 2. You're inventing a new grouping concept with its own number space for something that the DiffServ conceptual management model, MIB and PIB do using their "data path" concept and which they have their own numberspace for. You should re-use that concept or else persuade DiffServ to use your concept but there is no excuse for having duplicate mechanisms in MIBs that are being developed/published at roughly the same time by IETF (is this due to OPS and TSV ADs not talking to each other enough? No apologies for adding Diffserv WG to this message). 3. You're overloading your dsmonAggGroupIndex numberspace with the "convenience functionality" of letting the group index equal the DSCP. There's no need for this and it cannot be useful unless you have some mandated behaviour that relies on this 1:1 mapping e.g. a default setting for the table on power-up or initial state. Leaving it as an option (see "SHOULD" below) makes it useless in a multi-vendor world. Specifics: 4. "dsmonAggGroupIndex OBJECT-TYPE SYNTAX DsmonAggGroupIndex MAX-ACCESS read-write STATUS current DESCRIPTION "The aggregation group which contains this DSCP value. Upon creation of a new sub-tree (set of 64 entries with the same dsmonAggControlIndex value) in this table, the agent SHOULD initialize all related instances of this object to the value zero. This object MUST NOT be modified if the dsmonAggControlLocked object is equal to 'true'." DEFVAL { 0 }" a) This description does not make sense (to me): dsmonAggControlIndex does not appear in this table so how is creation of a new sub-tree related to entries in this table? Please clarify this wording. Or is this a typo? b) What's the point of the "SHOULD" directive here? c) Define "related instances" more precisely. d) You can't say that a read-write variable "MUST NOT" be modified (by whom?) - you can define that if you try to do so then the operation will pass/fail etc. but you can't use a MIB to enforce what a manager can/cannot attempt (you might as well add "please" :-)). e) I don't think you can rely on "0" as a special value of DSCP here - use something like -1 if you really need to use a DEFVAL. That's all on this particular issue, I guess I ought to read the rest of the MIB now ... Andrew Smith -----Original Message----- From: owner-mibs@ops.ietf.org [mailto:owner-mibs@ops.ietf.org]On Behalf Of Andy Bierman Sent: Friday, November 02, 2001 8:31 AM To: Harrie Hazewinkel Cc: bwijnen@lucent.com; rmonmib@ietf.org; mibs@ops.ietf.org Subject: DEFVAL in dsmonAggGroupIndex - SMIC error At 06:33 PM 11/1/2001 -0800, Harrie Hazewinkel wrote: Now that I looked at this some more, I think the SMIC is wrong. This DEFVAL should not be a syntax error. The dsmonAggGroupIndex object itself is read-write object and not an INDEX in the table its defined in. The DEFVAL clause indicates that the initial aggGroup value an agent should set for each DSCP mapping. All DSCPs in the same group -- perfectly valid concept, perfectly valid SMIv2 syntax. However, the dsmonAggGroupIndex object is also declared as one of the INDEX components in the dsmonAggGroupEntry. SMIC is complaining about the DEFVAL that is only meant to apply to original OBJECT-TYPE macro, not a DEFVAL for the INDEX -- that doesn't even make sense. >--On Thursday, November 1, 2001 7:40 AM -0800 Andy Bierman > wrote: > >>At 01:39 PM 11/1/2001 +0100, Wijnen, Bert (Bert) wrote: >>>OK, 2 issues basically came out after your approval. >>> >>>- SMICng complains about having a DEFVAL for dsmonAggGroupIndex >>> since this object is used as an index object as well. Andy >>> did put it in since you insisted. I am discussing the matter >>> with the SMIv2 doc editors >>>- Frank Strauss (I asked him to check to see if his compiler >>> would also complain about that indexing thing, which it did not, >>> but then Juergen has now added a lvl 4 warning about it). >>> Frank brought out that the OID could become too long based on >>> some index definitions. So Andy has posted a new rev to address >>> that >.... >>The rules are too strict! > >I agree here. When a default value is written in a description >it seems to be allowe, but when a DEFVAL is used it is >not because of compilers complain. That sounds >contradictionary to me. The DEFVAL-cluase is >(IMHO) there to support more formally the >semantics of the object, but it may neither >create a conflict with the semantics provided in >the description-clause. > > >Maybe far fetched, but I can envision such a scenario. >Someone can create some object in X-MIB with >a read-create ACCESS and a DEFVAL seems appropriate. >Later someone else in Y-MIB uses that object in an >index, because it wants to extend information for >that perticular object only. >The only option (to keep compilers happy) will then >be create/duplicate the object and provide the same >semantics without DEFVAL. > >Hmm.... Someone already did that -- in DSMON-MIB ! >My thoughts about it, > > >Harrie Hazewinkel Andy _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Mon Nov 5 05:03:43 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10265 for ; Mon, 5 Nov 2001 05:03:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA01481 for diffserv-archive@odin.ietf.org; Mon, 5 Nov 2001 05:03:45 -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 EAA00578; Mon, 5 Nov 2001 04:49:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA00516 for ; Mon, 5 Nov 2001 04:49:52 -0500 (EST) Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09950; Mon, 5 Nov 2001 04:49:50 -0500 (EST) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id fA59msM00822; Mon, 5 Nov 2001 04:48:54 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h149-49-38-91.avaya.com [149.49.38.91]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id fA59mqK00818; Mon, 5 Nov 2001 04:48:53 -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] RE: DEFVAL in dsmonAggGroupIndex - SMIC error Date: Mon, 5 Nov 2001 11:49:43 +0200 Message-ID: Thread-Topic: [Diffserv] RE: DEFVAL in dsmonAggGroupIndex - SMIC error Thread-Index: AcFl2OGxZwDxrMoXRyyhTQQOKDQWFQAAxq9A From: "Romascanu, Dan (Dan)" To: "Andrew Smith" , Cc: "Diffserv" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA00519 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 Andy, Please allow me to comment on some of your concerns. I agree that duplication is a bad thing in principle. However, one cannot ignore the fact that remote monitoring probes are being deployed and used quite extensively, and defining specific MIBs for these probes helps in extending their functionality and creating the tools for monitoring a DiffServ enabled network. MIBs belonging to the RMON family complement the MIBs runing in the devices themselves. The obvious example is that the RMON and RMON-2 MIBs from RMON probes complement from a network operator point of view the information that can be obtained by looking at MIB-II, Bridge MIB and IP forwarding MIBs in the bridges and routers deployed in the network. You cannot expect such a probe to implement much of the DiffServ MIB for the simple reason that they are not DiffServ enabled routers. I agree with you that many of the DS-MON MIB implementation will end by being implemented in switches and routers. Such implementations are already available. This is exactly where the optimizations that the DS-MON MIB tried to propose can help. Embedded devices tend to be sometimes scarce in resources, and doing monitoring is not their primary job. The concept of aggregation that bothers you in the example that you provided is such a case, as it helps to focus on the case where only some of the DSCP values are relevant for the specific network, and avoids wasting resources (like tables of counters mostly filled with zeroes) that cost on the device and on the wire. Optimization for monitoring purposes is different from what the 'data path' concept, and a network operator application may need to focus on different sources. I think that the problem spaces of providing data for the protocol management, and monitoring the network (by stand-alone or embedded probes) are complementary sets of tools, which deserve each their separate definition and MIB interface. Regards, Dan > -----Original Message----- > From: Andrew Smith [mailto:ah_smith@acm.org] > Sent: Friday, November 02, 2001 11:12 PM > To: rmonmib@ietf.org > Cc: Diffserv > Subject: [Diffserv] RE: DEFVAL in dsmonAggGroupIndex - SMIC error > > > I've (still) got serious problems with this MIB, its > relationship to the > DiffServ MIB and the "aggregation group" concept. Haven't > spoken up recently > because I thought others would taken care of it by now. > > 1. You're duplicating functionality from the DiffServ MIB > here. If that's > fine with IESG then OK but it seems like a bad idea to me. People have > argued on the RMON list before that DSMON is meant for > probes, not switches > but I believe a large proportion of DSMON implementations > will end up inside > switches with consequent waste of resources. I do not think > there is a good > case to be made for optimising this MIB for the "standalone > probe" case. > > 2. You're inventing a new grouping concept with its own > number space for > something that the DiffServ conceptual management model, MIB > and PIB do > using their "data path" concept and which they have their own > numberspace > for. You should re-use that concept or else persuade DiffServ > to use your > concept but there is no excuse for having duplicate > mechanisms in MIBs that > are being developed/published at roughly the same time by > IETF (is this due > to OPS and TSV ADs not talking to each other enough? No > apologies for adding > Diffserv WG to this message). > > 3. You're overloading your dsmonAggGroupIndex numberspace with the > "convenience functionality" of letting the group index equal the DSCP. > There's no need for this and it cannot be useful unless you have some > mandated behaviour that relies on this 1:1 mapping e.g. a > default setting > for the table on power-up or initial state. Leaving it as an > option (see > "SHOULD" below) makes it useless in a multi-vendor world. > > Specifics: > > 4. "dsmonAggGroupIndex OBJECT-TYPE > SYNTAX DsmonAggGroupIndex > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The aggregation group which contains this DSCP > value. Upon > creation of a new sub-tree (set of 64 entries > with the same > dsmonAggControlIndex value) in this table, the > agent SHOULD > initialize all related instances of this object > to the value > zero. > > This object MUST NOT be modified if the > dsmonAggControlLocked object is equal to 'true'." > DEFVAL { 0 }" > > a) This description does not make sense (to me): > dsmonAggControlIndex does > not appear in this table so how is creation of a new sub-tree > related to > entries in this table? Please clarify this wording. Or is this a typo? > b) What's the point of the "SHOULD" directive here? > c) Define "related instances" more precisely. > d) You can't say that a read-write variable "MUST NOT" be modified (by > whom?) - you can define that if you try to do so then the > operation will > pass/fail etc. but you can't use a MIB to enforce what a > manager can/cannot > attempt (you might as well add "please" :-)). > e) I don't think you can rely on "0" as a special value of > DSCP here - use > something like -1 if you really need to use a DEFVAL. > > That's all on this particular issue, I guess I ought to read > the rest of the > MIB now ... > > Andrew Smith > > > -----Original Message----- > From: owner-mibs@ops.ietf.org > [mailto:owner-mibs@ops.ietf.org]On Behalf > Of Andy Bierman > Sent: Friday, November 02, 2001 8:31 AM > To: Harrie Hazewinkel > Cc: bwijnen@lucent.com; rmonmib@ietf.org; mibs@ops.ietf.org > Subject: DEFVAL in dsmonAggGroupIndex - SMIC error > > > At 06:33 PM 11/1/2001 -0800, Harrie Hazewinkel wrote: > > > > Now that I looked at this some more, I think the SMIC is wrong. > This DEFVAL should not be a syntax error. > > The dsmonAggGroupIndex object itself is read-write object > and not an INDEX in the table its defined in. The DEFVAL clause > indicates that the initial aggGroup value an agent should set for each > DSCP mapping. All DSCPs in the same group -- perfectly valid concept, > perfectly valid SMIv2 syntax. > > However, the dsmonAggGroupIndex object is also declared as one of the > INDEX components in the dsmonAggGroupEntry. SMIC is complaining about > the DEFVAL that is only meant to apply to original OBJECT-TYPE macro, > not a DEFVAL for the INDEX -- that doesn't even make sense. > > >--On Thursday, November 1, 2001 7:40 AM -0800 Andy Bierman > > wrote: > > > >>At 01:39 PM 11/1/2001 +0100, Wijnen, Bert (Bert) wrote: > >>>OK, 2 issues basically came out after your approval. > >>> > >>>- SMICng complains about having a DEFVAL for dsmonAggGroupIndex > >>> since this object is used as an index object as well. Andy > >>> did put it in since you insisted. I am discussing the matter > >>> with the SMIv2 doc editors > >>>- Frank Strauss (I asked him to check to see if his compiler > >>> would also complain about that indexing thing, which it did not, > >>> but then Juergen has now added a lvl 4 warning about it). > >>> Frank brought out that the OID could become too long based on > >>> some index definitions. So Andy has posted a new rev to address > >>> that > > >.... > > > >>The rules are too strict! > > > >I agree here. When a default value is written in a description > >it seems to be allowe, but when a DEFVAL is used it is > >not because of compilers complain. That sounds > >contradictionary to me. The DEFVAL-cluase is > >(IMHO) there to support more formally the > >semantics of the object, but it may neither > >create a conflict with the semantics provided in > >the description-clause. > > > > > >Maybe far fetched, but I can envision such a scenario. > >Someone can create some object in X-MIB with > >a read-create ACCESS and a DEFVAL seems appropriate. > >Later someone else in Y-MIB uses that object in an > >index, because it wants to extend information for > >that perticular object only. > >The only option (to keep compilers happy) will then > >be create/duplicate the object and provide the same > >semantics without DEFVAL. > > > >Hmm.... > > Someone already did that -- in DSMON-MIB ! > > > > > >My thoughts about it, > > > > > >Harrie Hazewinkel > > Andy > > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/curr ent/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Mon Nov 5 05:46:33 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10788 for ; Mon, 5 Nov 2001 05:46:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA03154 for diffserv-archive@odin.ietf.org; Mon, 5 Nov 2001 05:46:35 -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 FAA01953; Mon, 5 Nov 2001 05:27:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA29169 for ; Mon, 5 Nov 2001 04:28:54 -0500 (EST) Received: from lut.fi (stalk.cc.lut.fi [157.24.8.95]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09620 for ; Mon, 5 Nov 2001 04:28:51 -0500 (EST) Received: from [157.24.25.96] (HELO elwe) by lut.fi (CommuniGate Pro SMTP 3.4.7) with SMTP id 1337379; Mon, 05 Nov 2001 11:28:50 +0200 From: "Sergio Andreozzi" To: Cc: "DiffServ@ietf. org" Subject: Re: [Diffserv] backward compatiblity with RFC 1349 Date: Mon, 5 Nov 2001 11:26:42 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit In the following draft: draft-ietf-diffserv-new-terms-05.txt there are more clarifications about your question. In particular in paragraph 7: "No attempt is made to maintain backwards compatibility with the "DTR/MBZ" or TOS bits of the IPv4 TOS octet, as defined in [RFC791] and [RFC1349] Bye, Sergio _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Mon Nov 5 05:49:28 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10837 for ; Mon, 5 Nov 2001 05:49:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA03226 for diffserv-archive@odin.ietf.org; Mon, 5 Nov 2001 05:49: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 FAA02530; Mon, 5 Nov 2001 05:33:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA02501 for ; Mon, 5 Nov 2001 05:32:56 -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 FAA10636 for ; Mon, 5 Nov 2001 05:32:52 -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 LAA07744; Mon, 5 Nov 2001 11:32:08 +0100 Received: from dhcp22-51.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA67520 from ; Mon, 5 Nov 2001 11:32:01 +0100 Message-Id: <3BE669B6.89A752C7@hursley.ibm.com> Date: Mon, 05 Nov 2001 11:28:07 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: lei.yao@wcom.com Cc: diffserv@ietf.org, nichols@packetdesign.com Subject: Re: [Diffserv] backward compatiblity with RFC 1349 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 RFC 2474 obsoletes RFC 1349. So those TOS bits are dead. Brian Lei Yao wrote: > > In RFC1349, the TOS byte is divided into three fields: Precedence(0-2), > TOS(3-6) and MBZ(7). The second field, "TOS", is intended to denote how the > network should treat packets differently on delay, throughput, reliability > and cost. The following marks of the TOS field have been defined > 1000 -- minimize delay > 0100 -- maximize throughput > 0010 -- maximize reliability > 0001 -- minimize monetary cost > 0000 -- normal service > > RFC 2474 only describes the backward compatibility with the IP Precedence > field. I wonder if the backward compatibility with the TOS field was > discussed in the working group. If yes, what is the conclusion? If no, > please comment. > > Thanks. > > Lei _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Mon Nov 5 08:19:13 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15037 for ; Mon, 5 Nov 2001 08:19:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA08604 for diffserv-archive@odin.ietf.org; Mon, 5 Nov 2001 08:19: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 HAA07457; Mon, 5 Nov 2001 07:50:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA07420 for ; Mon, 5 Nov 2001 07:50:19 -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 HAA13561; Mon, 5 Nov 2001 07:50:15 -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 NAA13670; Mon, 5 Nov 2001 13:49:47 +0100 Received: from dhcp22-51.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA13440 from ; Mon, 5 Nov 2001 13:49:45 +0100 Message-Id: <3BE6891B.25F3F8AE@hursley.ibm.com> Date: Mon, 05 Nov 2001 13:42:03 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: "Romascanu, Dan (Dan)" Cc: Andrew Smith , rmonmib@ietf.org, Diffserv Subject: Re: [Diffserv] RE: DEFVAL in dsmonAggGroupIndex - SMIC error 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 Dan, "Romascanu, Dan (Dan)" wrote: ... > I think that the problem spaces of providing data for the protocol > management, and monitoring the network (by stand-alone or embedded > probes) are complementary sets of tools, which deserve each their > separate definition and MIB interface. That is why the diffserv MIB has two conformance levels, one for read-only (i.e. monitoring) and one for read-write (i.e. control). A priori, the diffserv MIB is what you need for complete monitoring of a diffserv router. It certainly doesn't seem appropriate to construct a *different* virtual model of such a router for an RMON MIB; surely it should be a strict subset of the same model? Otherwise life will become very confusing for operational staff. The diffserv MIB deconstructs the path for each traffic aggregate and maintains some counters deep down in the deconstructed elements of the path. You are going the opposite way in the DSMON MIB - you are synthesizing something that doesn't exist (the aggregation group), which may or may not map to the paths defined in the diffserv MIB. In practice I think that will force implementors to do extra work, and cost extra overhead. It would indeed seem more logical for the DSMON MIB to collect up the counters already defined by the diffserv MIB, but that means a different approach to aggregating the counters. Brian > > -----Original Message----- > > From: Andrew Smith [mailto:ah_smith@acm.org] > > Sent: Friday, November 02, 2001 11:12 PM > > To: rmonmib@ietf.org > > Cc: Diffserv > > Subject: [Diffserv] RE: DEFVAL in dsmonAggGroupIndex - SMIC error > > > > > > I've (still) got serious problems with this MIB, its > > relationship to the > > DiffServ MIB and the "aggregation group" concept. Haven't > > spoken up recently > > because I thought others would taken care of it by now. > > > > 1. You're duplicating functionality from the DiffServ MIB > > here. If that's > > fine with IESG then OK but it seems like a bad idea to me. People have > > argued on the RMON list before that DSMON is meant for > > probes, not switches > > but I believe a large proportion of DSMON implementations > > will end up inside > > switches with consequent waste of resources. I do not think > > there is a good > > case to be made for optimising this MIB for the "standalone > > probe" case. > > > > 2. You're inventing a new grouping concept with its own > > number space for > > something that the DiffServ conceptual management model, MIB > > and PIB do > > using their "data path" concept and which they have their own > > numberspace > > for. You should re-use that concept or else persuade DiffServ > > to use your > > concept but there is no excuse for having duplicate > > mechanisms in MIBs that > > are being developed/published at roughly the same time by > > IETF (is this due > > to OPS and TSV ADs not talking to each other enough? No > > apologies for adding > > Diffserv WG to this message). > > > > 3. You're overloading your dsmonAggGroupIndex numberspace with the > > "convenience functionality" of letting the group index equal the DSCP. > > There's no need for this and it cannot be useful unless you have some > > mandated behaviour that relies on this 1:1 mapping e.g. a > > default setting > > for the table on power-up or initial state. Leaving it as an > > option (see > > "SHOULD" below) makes it useless in a multi-vendor world. > > > > Specifics: > > > > 4. "dsmonAggGroupIndex OBJECT-TYPE > > SYNTAX DsmonAggGroupIndex > > MAX-ACCESS read-write > > STATUS current > > DESCRIPTION > > "The aggregation group which contains this DSCP > > value. Upon > > creation of a new sub-tree (set of 64 entries > > with the same > > dsmonAggControlIndex value) in this table, the > > agent SHOULD > > initialize all related instances of this object > > to the value > > zero. > > > > This object MUST NOT be modified if the > > dsmonAggControlLocked object is equal to 'true'." > > DEFVAL { 0 }" > > > > a) This description does not make sense (to me): > > dsmonAggControlIndex does > > not appear in this table so how is creation of a new sub-tree > > related to > > entries in this table? Please clarify this wording. Or is this a typo? > > b) What's the point of the "SHOULD" directive here? > > c) Define "related instances" more precisely. > > d) You can't say that a read-write variable "MUST NOT" be modified (by > > whom?) - you can define that if you try to do so then the > > operation will > > pass/fail etc. but you can't use a MIB to enforce what a > > manager can/cannot > > attempt (you might as well add "please" :-)). > > e) I don't think you can rely on "0" as a special value of > > DSCP here - use > > something like -1 if you really need to use a DEFVAL. > > > > That's all on this particular issue, I guess I ought to read > > the rest of the > > MIB now ... > > > > Andrew Smith > > > > > > -----Original Message----- > > From: owner-mibs@ops.ietf.org > > [mailto:owner-mibs@ops.ietf.org]On Behalf > > Of Andy Bierman > > Sent: Friday, November 02, 2001 8:31 AM > > To: Harrie Hazewinkel > > Cc: bwijnen@lucent.com; rmonmib@ietf.org; mibs@ops.ietf.org > > Subject: DEFVAL in dsmonAggGroupIndex - SMIC error > > > > > > At 06:33 PM 11/1/2001 -0800, Harrie Hazewinkel wrote: > > > > > > > > Now that I looked at this some more, I think the SMIC is wrong. > > This DEFVAL should not be a syntax error. > > > > The dsmonAggGroupIndex object itself is read-write object > > and not an INDEX in the table its defined in. The DEFVAL clause > > indicates that the initial aggGroup value an agent should set for each > > DSCP mapping. All DSCPs in the same group -- perfectly valid concept, > > perfectly valid SMIv2 syntax. > > > > However, the dsmonAggGroupIndex object is also declared as one of the > > INDEX components in the dsmonAggGroupEntry. SMIC is complaining about > > the DEFVAL that is only meant to apply to original OBJECT-TYPE macro, > > not a DEFVAL for the INDEX -- that doesn't even make sense. > > > > >--On Thursday, November 1, 2001 7:40 AM -0800 Andy Bierman > > > wrote: > > > > > >>At 01:39 PM 11/1/2001 +0100, Wijnen, Bert (Bert) wrote: > > >>>OK, 2 issues basically came out after your approval. > > >>> > > >>>- SMICng complains about having a DEFVAL for dsmonAggGroupIndex > > >>> since this object is used as an index object as well. Andy > > >>> did put it in since you insisted. I am discussing the matter > > >>> with the SMIv2 doc editors > > >>>- Frank Strauss (I asked him to check to see if his compiler > > >>> would also complain about that indexing thing, which it did not, > > >>> but then Juergen has now added a lvl 4 warning about it). > > >>> Frank brought out that the OID could become too long based on > > >>> some index definitions. So Andy has posted a new rev to address > > >>> that > > > > >.... > > > > > > >>The rules are too strict! > > > > > >I agree here. When a default value is written in a description > > >it seems to be allowe, but when a DEFVAL is used it is > > >not because of compilers complain. That sounds > > >contradictionary to me. The DEFVAL-cluase is > > >(IMHO) there to support more formally the > > >semantics of the object, but it may neither > > >create a conflict with the semantics provided in > > >the description-clause. > > > > > > > > >Maybe far fetched, but I can envision such a scenario. > > >Someone can create some object in X-MIB with > > >a read-create ACCESS and a DEFVAL seems appropriate. > > >Later someone else in Y-MIB uses that object in an > > >index, because it wants to extend information for > > >that perticular object only. > > >The only option (to keep compilers happy) will then > > >be create/duplicate the object and provide the same > > >semantics without DEFVAL. > > > > > >Hmm.... > > > > Someone already did that -- in DSMON-MIB ! > > > > > > > > > > >My thoughts about it, > > > > > > > > >Harrie Hazewinkel > > > > Andy > > > > > > > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > https://www1.ietf.org/mailman/listinfo/diffserv > > Archive: > > http://www2.ietf.org/mail-archive/working-groups/diffserv/curr > ent/maillist.html > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 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://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Mon Nov 5 11:06:36 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26354 for ; Mon, 5 Nov 2001 11:06:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA15714 for diffserv-archive@odin.ietf.org; Mon, 5 Nov 2001 11:06:38 -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 KAA14424; Mon, 5 Nov 2001 10:48:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14281 for ; Mon, 5 Nov 2001 10:48:20 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24941; Mon, 5 Nov 2001 10:48:08 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id fA5FioM03369; Mon, 5 Nov 2001 07:44:51 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id fA5Fl0x00996; Mon, 5 Nov 2001 07:47:00 -0800 (PST) Received: from PC2.cisco.com (sjc-vpn1-939.cisco.com [10.21.99.171]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id HAA24843; Mon, 5 Nov 2001 07:46:59 -0800 (PST) Message-Id: <4.3.2.7.2.20011105072403.01d37440@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 05 Nov 2001 07:45:02 -0800 To: Brian E Carpenter From: Andy Bierman Subject: Re: [Diffserv] RE: DEFVAL in dsmonAggGroupIndex - SMIC error Cc: "Romascanu, Dan (Dan)" , Andrew Smith , rmonmib@ietf.org, Diffserv In-Reply-To: <3BE6891B.25F3F8AE@hursley.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 01:42 PM 11/5/2001 +0100, Brian E Carpenter wrote: >Dan, > >"Romascanu, Dan (Dan)" wrote: >... > > I think that the problem spaces of providing data for the protocol > > management, and monitoring the network (by stand-alone or embedded > > probes) are complementary sets of tools, which deserve each their > > separate definition and MIB interface. > >That is why the diffserv MIB has two conformance levels, one for >read-only (i.e. monitoring) and one for read-write (i.e. control). >A priori, the diffserv MIB is what you need for complete monitoring >of a diffserv router. It certainly doesn't seem appropriate to >construct a *different* virtual model of such a router for an RMON >MIB; surely it should be a strict subset of the same model? >Otherwise life will become very confusing for operational staff. I think you might have missed Dan's point. RMON focuses on aggregating statistics from the network user POV. Simple, high-level statistics of the nature "What is the traffic mix on network X?" RMON does not focus at all on the performance or health of individual forwarding elements within the network. Although RMON can run inside switches, it is designed to run in many environments, and it provides an intentionally simplified control interface to allow such implementations. In DSMON, the dsmonAggControl group allows an administrator to configure which DSCPs to lump together for counting purposes only. This allows for implementations with hardware-based counters to 'share' those counters. It also can reduce the number of MIB objects an application has to retrieve -- the agent can do the counter roll-up for the application if so configured. RMON applications are not intended for use as DS forwarding device fault and performance monitoring tools. >The diffserv MIB deconstructs the path for each traffic aggregate >and maintains some counters deep down in the deconstructed elements >of the path. You are going the opposite way in the DSMON MIB - you >are synthesizing something that doesn't exist (the aggregation group), >which may or may not map to the paths defined in the diffserv MIB. >In practice I think that will force implementors to do extra work, >and cost extra overhead. It would indeed seem more logical for >the DSMON MIB to collect up the counters already defined by the >diffserv MIB, but that means a different approach to aggregating >the counters. The DIFFSERV-MIB I-D is 127 pages. The DSMON-MIB I-D is 128 pages. For those of us on the list who have not memorized every MIB object in both MIBs, can somebody please list these DIFFSERV-MIB objects and the DSMON-MIB objects that overlap them? > Brian Andy > > > -----Original Message----- > > > From: Andrew Smith [mailto:ah_smith@acm.org] > > > Sent: Friday, November 02, 2001 11:12 PM > > > To: rmonmib@ietf.org > > > Cc: Diffserv > > > Subject: [Diffserv] RE: DEFVAL in dsmonAggGroupIndex - SMIC error > > > > > > > > > I've (still) got serious problems with this MIB, its > > > relationship to the > > > DiffServ MIB and the "aggregation group" concept. Haven't > > > spoken up recently > > > because I thought others would taken care of it by now. > > > > > > 1. You're duplicating functionality from the DiffServ MIB > > > here. If that's > > > fine with IESG then OK but it seems like a bad idea to me. People have > > > argued on the RMON list before that DSMON is meant for > > > probes, not switches > > > but I believe a large proportion of DSMON implementations > > > will end up inside > > > switches with consequent waste of resources. I do not think > > > there is a good > > > case to be made for optimising this MIB for the "standalone > > > probe" case. > > > > > > 2. You're inventing a new grouping concept with its own > > > number space for > > > something that the DiffServ conceptual management model, MIB > > > and PIB do > > > using their "data path" concept and which they have their own > > > numberspace > > > for. You should re-use that concept or else persuade DiffServ > > > to use your > > > concept but there is no excuse for having duplicate > > > mechanisms in MIBs that > > > are being developed/published at roughly the same time by > > > IETF (is this due > > > to OPS and TSV ADs not talking to each other enough? No > > > apologies for adding > > > Diffserv WG to this message). > > > > > > 3. You're overloading your dsmonAggGroupIndex numberspace with the > > > "convenience functionality" of letting the group index equal the DSCP. > > > There's no need for this and it cannot be useful unless you have some > > > mandated behaviour that relies on this 1:1 mapping e.g. a > > > default setting > > > for the table on power-up or initial state. Leaving it as an > > > option (see > > > "SHOULD" below) makes it useless in a multi-vendor world. > > > > > > Specifics: > > > > > > 4. "dsmonAggGroupIndex OBJECT-TYPE > > > SYNTAX DsmonAggGroupIndex > > > MAX-ACCESS read-write > > > STATUS current > > > DESCRIPTION > > > "The aggregation group which contains this DSCP > > > value. Upon > > > creation of a new sub-tree (set of 64 entries > > > with the same > > > dsmonAggControlIndex value) in this table, the > > > agent SHOULD > > > initialize all related instances of this object > > > to the value > > > zero. > > > > > > This object MUST NOT be modified if the > > > dsmonAggControlLocked object is equal to 'true'." > > > DEFVAL { 0 }" > > > > > > a) This description does not make sense (to me): > > > dsmonAggControlIndex does > > > not appear in this table so how is creation of a new sub-tree > > > related to > > > entries in this table? Please clarify this wording. Or is this a typo? > > > b) What's the point of the "SHOULD" directive here? > > > c) Define "related instances" more precisely. > > > d) You can't say that a read-write variable "MUST NOT" be modified (by > > > whom?) - you can define that if you try to do so then the > > > operation will > > > pass/fail etc. but you can't use a MIB to enforce what a > > > manager can/cannot > > > attempt (you might as well add "please" :-)). > > > e) I don't think you can rely on "0" as a special value of > > > DSCP here - use > > > something like -1 if you really need to use a DEFVAL. > > > > > > That's all on this particular issue, I guess I ought to read > > > the rest of the > > > MIB now ... > > > > > > Andrew Smith > > > > > > > > > -----Original Message----- > > > From: owner-mibs@ops.ietf.org > > > [mailto:owner-mibs@ops.ietf.org]On Behalf > > > Of Andy Bierman > > > Sent: Friday, November 02, 2001 8:31 AM > > > To: Harrie Hazewinkel > > > Cc: bwijnen@lucent.com; rmonmib@ietf.org; mibs@ops.ietf.org > > > Subject: DEFVAL in dsmonAggGroupIndex - SMIC error > > > > > > > > > At 06:33 PM 11/1/2001 -0800, Harrie Hazewinkel wrote: > > > > > > > > > > > > Now that I looked at this some more, I think the SMIC is wrong. > > > This DEFVAL should not be a syntax error. > > > > > > The dsmonAggGroupIndex object itself is read-write object > > > and not an INDEX in the table its defined in. The DEFVAL clause > > > indicates that the initial aggGroup value an agent should set for each > > > DSCP mapping. All DSCPs in the same group -- perfectly valid concept, > > > perfectly valid SMIv2 syntax. > > > > > > However, the dsmonAggGroupIndex object is also declared as one of the > > > INDEX components in the dsmonAggGroupEntry. SMIC is complaining about > > > the DEFVAL that is only meant to apply to original OBJECT-TYPE macro, > > > not a DEFVAL for the INDEX -- that doesn't even make sense. > > > > > > >--On Thursday, November 1, 2001 7:40 AM -0800 Andy Bierman > > > > wrote: > > > > > > > >>At 01:39 PM 11/1/2001 +0100, Wijnen, Bert (Bert) wrote: > > > >>>OK, 2 issues basically came out after your approval. > > > >>> > > > >>>- SMICng complains about having a DEFVAL for dsmonAggGroupIndex > > > >>> since this object is used as an index object as well. Andy > > > >>> did put it in since you insisted. I am discussing the matter > > > >>> with the SMIv2 doc editors > > > >>>- Frank Strauss (I asked him to check to see if his compiler > > > >>> would also complain about that indexing thing, which it did not, > > > >>> but then Juergen has now added a lvl 4 warning about it). > > > >>> Frank brought out that the OID could become too long based on > > > >>> some index definitions. So Andy has posted a new rev to address > > > >>> that > > > > > > >.... > > > > > > > > > >>The rules are too strict! > > > > > > > >I agree here. When a default value is written in a description > > > >it seems to be allowe, but when a DEFVAL is used it is > > > >not because of compilers complain. That sounds > > > >contradictionary to me. The DEFVAL-cluase is > > > >(IMHO) there to support more formally the > > > >semantics of the object, but it may neither > > > >create a conflict with the semantics provided in > > > >the description-clause. > > > > > > > > > > > >Maybe far fetched, but I can envision such a scenario. > > > >Someone can create some object in X-MIB with > > > >a read-create ACCESS and a DEFVAL seems appropriate. > > > >Later someone else in Y-MIB uses that object in an > > > >index, because it wants to extend information for > > > >that perticular object only. > > > >The only option (to keep compilers happy) will then > > > >be create/duplicate the object and provide the same > > > >semantics without DEFVAL. > > > > > > > >Hmm.... > > > > > > Someone already did that -- in DSMON-MIB ! > > > > > > > > > > > > > > > >My thoughts about it, > > > > > > > > > > > >Harrie Hazewinkel > > > > > > Andy > > > > > > > > > > > > > > > _______________________________________________ > > > diffserv mailing list > > > diffserv@ietf.org > > > https://www1.ietf.org/mailman/listinfo/diffserv > > > Archive: > > > http://www2.ietf.org/mail-archive/working-groups/diffserv/curr > > ent/maillist.html > > > > _______________________________________________ > > diffserv mailing list > > diffserv@ietf.org > > https://www1.ietf.org/mailman/listinfo/diffserv > > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > >-- >- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >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://www2.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://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Tue Nov 6 01:45:43 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22867 for ; Tue, 6 Nov 2001 01:45:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA14864 for diffserv-archive@odin.ietf.org; Tue, 6 Nov 2001 01:45:43 -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 BAA14273; Tue, 6 Nov 2001 01:30:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA14193 for ; Tue, 6 Nov 2001 01:30:34 -0500 (EST) Received: from pimout1-int.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20766; Tue, 6 Nov 2001 01:30:33 -0500 (EST) Received: from [0.0.0.0] (ppp-209-232-54-8.dialup.snfc21.pacbell.net [209.232.54.8]) by pimout1-int.prodigy.net (8.11.0/8.11.0) with ESMTP id fA66UPq222916; Tue, 6 Nov 2001 01:30:26 -0500 Date: Mon, 05 Nov 2001 22:28:45 -0800 From: Harrie Hazewinkel To: Brian E Carpenter , "Romascanu, Dan (Dan)" cc: Andrew Smith , rmonmib@ietf.org, Diffserv Message-ID: <400290.1004999325@localhost> X-Mailer: Mulberry/2.1.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [Diffserv] Differences between DSMON-MIB and DIFFSERV-MIB 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, (Note I changed the subject) --On Monday, November 5, 2001 1:42 PM +0100 Brian E Carpenter wrote: > Dan, > > "Romascanu, Dan (Dan)" wrote: > ... >> I think that the problem spaces of providing data for the protocol >> management, and monitoring the network (by stand-alone or embedded >> probes) are complementary sets of tools, which deserve each their >> separate definition and MIB interface. > > That is why the diffserv MIB has two conformance levels, one for > read-only (i.e. monitoring) and one for read-write (i.e. control). > A priori, the diffserv MIB is what you need for complete monitoring > of a diffserv router. IMHO, the two conformance levels are there to have a different SNMP access which in perticular reflect the approach the system gets configured. The 'full compliance' makes it that a diffserv capable router can be monitored and configured via SNMP. The 'read-only compliance' is mainly to support toses diffserv capable routers who do not do configuration via SNMP. It can indeed be used for monitoring, but the system can be configured in other ways than SNMP. > It certainly doesn't seem appropriate to > construct a *different* virtual model of such a router for an RMON > MIB; surely it should be a strict subset of the same model? The virtual model mainly creates the concept of the datapath and its elements. Those datapaths and elements cause in a diffserv capable router traffic treatment. Different treatment can be given based on the way the traffic is filtered and goes through the datapath elements. Traffic behavior can be altered/shaped or just treated differently. RMON is just a probe sitting on the sideline looking at the traffic. It does not do any traffic treatment or shaping. Traffic streams are NOT altered. > Otherwise life will become very confusing for operational staff. This is maybe already caused by the existance of RMON. Like D.Romascanu said; "The obvious example is that the RMON and RMON-2 MIBs from RMON probes complement from a network operator point of view the information that can be obtained by looking at MIB-II, Bridge MIB and IP forwarding MIBs in the bridges and routers deployed in the network." I beleive the models are different where DSMON-MIB is monitoring a particular traffic pattern and the DIFFSERV-MIB is monitoring a perticular datapath configuration (and if 'full compliant' also configuration itself. A big difference is the end of a datapath configuration is the router core. In DSMON-MIB monitoring is no router core. Also the DIFFSERV-MIB has for each count action a next datapath element which is not in the DSMON-MIB. > > The diffserv MIB deconstructs the path for each traffic aggregate > and maintains some counters deep down in the deconstructed elements > of the path. You are going the opposite way in the DSMON MIB - you > are synthesizing something that doesn't exist (the aggregation group), > which may or may not map to the paths defined in the diffserv MIB. Indeed, this is a difference. > In practice I think that will force implementors to do extra work, > and cost extra overhead. It would indeed seem more logical for > the DSMON MIB to collect up the counters already defined by the > diffserv MIB, but that means a different approach to aggregating > the counters. I am not sure if I follow it completely; correct me if I am wrong. What you are saying is that the counter which are combined with a particular DSCP counting from as well the DSMON-MIB and the DIFFSERV-MIB can be the same?? But where does the traffic gets delivered in case of an DSMON situation with the DIFFSERV-MIB?? The value zeroDotZero for a next pointer does not seem to be appropriate if you just have a normal RMON probe. I beleive this will force also extra work to configure the system. Maybe one will not have the same DSMON monitoring (filtering) as one has traffic treatment. That would mean: A traffic filter that feeds the various counters to do traffic monitoring. The next pointer of all the count actions need to be the same from where a complete new set of traffic filters is created in order to have a traffic treatment one would like to have. Maybe a farfetched idea, but still. Looks possible to me. However, when the DSMON-MIB is just in a probe, I am not sure how to use the filters and more precise the count actions of the DIFFSERV-MIB need to be set up than. What is the next pointer of the count actions?? These count actions (datapath elements) are not in the path of the traffic and neither can the traffic be delivered at the router core as the DIFFSERV-MIB does. Maybe the case where an RMON probe in the DIFFSERV capable router resides is a border case. But this is (I beleive) not to be expected the case always. Hope this all makes sense, (if not say so) Harrie > > Brian > >> > -----Original Message----- >> > From: Andrew Smith [mailto:ah_smith@acm.org] >> > Sent: Friday, November 02, 2001 11:12 PM >> > To: rmonmib@ietf.org >> > Cc: Diffserv >> > Subject: [Diffserv] RE: DEFVAL in dsmonAggGroupIndex - SMIC error >> > >> > >> > I've (still) got serious problems with this MIB, its >> > relationship to the >> > DiffServ MIB and the "aggregation group" concept. Haven't >> > spoken up recently >> > because I thought others would taken care of it by now. >> > >> > 1. You're duplicating functionality from the DiffServ MIB >> > here. If that's >> > fine with IESG then OK but it seems like a bad idea to me. People have >> > argued on the RMON list before that DSMON is meant for >> > probes, not switches >> > but I believe a large proportion of DSMON implementations >> > will end up inside >> > switches with consequent waste of resources. I do not think >> > there is a good >> > case to be made for optimising this MIB for the "standalone >> > probe" case. >> > >> > 2. You're inventing a new grouping concept with its own >> > number space for >> > something that the DiffServ conceptual management model, MIB >> > and PIB do >> > using their "data path" concept and which they have their own >> > numberspace >> > for. You should re-use that concept or else persuade DiffServ >> > to use your >> > concept but there is no excuse for having duplicate >> > mechanisms in MIBs that >> > are being developed/published at roughly the same time by >> > IETF (is this due >> > to OPS and TSV ADs not talking to each other enough? No >> > apologies for adding >> > Diffserv WG to this message). >> > >> > 3. You're overloading your dsmonAggGroupIndex numberspace with the >> > "convenience functionality" of letting the group index equal the DSCP. >> > There's no need for this and it cannot be useful unless you have some >> > mandated behaviour that relies on this 1:1 mapping e.g. a >> > default setting >> > for the table on power-up or initial state. Leaving it as an >> > option (see >> > "SHOULD" below) makes it useless in a multi-vendor world. >> > >> > Specifics: >> > >> > 4. "dsmonAggGroupIndex OBJECT-TYPE >> > SYNTAX DsmonAggGroupIndex >> > MAX-ACCESS read-write >> > STATUS current >> > DESCRIPTION >> > "The aggregation group which contains this DSCP >> > value. Upon >> > creation of a new sub-tree (set of 64 entries >> > with the same >> > dsmonAggControlIndex value) in this table, the >> > agent SHOULD >> > initialize all related instances of this object >> > to the value >> > zero. >> > >> > This object MUST NOT be modified if the >> > dsmonAggControlLocked object is equal to 'true'." >> > DEFVAL { 0 }" >> > >> > a) This description does not make sense (to me): >> > dsmonAggControlIndex does >> > not appear in this table so how is creation of a new sub-tree >> > related to >> > entries in this table? Please clarify this wording. Or is this a typo? >> > b) What's the point of the "SHOULD" directive here? >> > c) Define "related instances" more precisely. >> > d) You can't say that a read-write variable "MUST NOT" be modified (by >> > whom?) - you can define that if you try to do so then the >> > operation will >> > pass/fail etc. but you can't use a MIB to enforce what a >> > manager can/cannot >> > attempt (you might as well add "please" :-)). >> > e) I don't think you can rely on "0" as a special value of >> > DSCP here - use >> > something like -1 if you really need to use a DEFVAL. >> > >> > That's all on this particular issue, I guess I ought to read >> > the rest of the >> > MIB now ... >> > >> > Andrew Smith >> > >> > >> > -----Original Message----- >> > From: owner-mibs@ops.ietf.org >> > [mailto:owner-mibs@ops.ietf.org]On Behalf >> > Of Andy Bierman >> > Sent: Friday, November 02, 2001 8:31 AM >> > To: Harrie Hazewinkel >> > Cc: bwijnen@lucent.com; rmonmib@ietf.org; mibs@ops.ietf.org >> > Subject: DEFVAL in dsmonAggGroupIndex - SMIC error >> > >> > >> > At 06:33 PM 11/1/2001 -0800, Harrie Hazewinkel wrote: >> > >> > >> > >> > Now that I looked at this some more, I think the SMIC is wrong. >> > This DEFVAL should not be a syntax error. >> > >> > The dsmonAggGroupIndex object itself is read-write object >> > and not an INDEX in the table its defined in. The DEFVAL clause >> > indicates that the initial aggGroup value an agent should set for each >> > DSCP mapping. All DSCPs in the same group -- perfectly valid concept, >> > perfectly valid SMIv2 syntax. >> > >> > However, the dsmonAggGroupIndex object is also declared as one of the >> > INDEX components in the dsmonAggGroupEntry. SMIC is complaining about >> > the DEFVAL that is only meant to apply to original OBJECT-TYPE macro, >> > not a DEFVAL for the INDEX -- that doesn't even make sense. >> > >> > > --On Thursday, November 1, 2001 7:40 AM -0800 Andy Bierman >> > > wrote: >> > > >> > >> At 01:39 PM 11/1/2001 +0100, Wijnen, Bert (Bert) wrote: >> > >>> OK, 2 issues basically came out after your approval. >> > >>> >> > >>> - SMICng complains about having a DEFVAL for dsmonAggGroupIndex >> > >>> since this object is used as an index object as well. Andy >> > >>> did put it in since you insisted. I am discussing the matter >> > >>> with the SMIv2 doc editors >> > >>> - Frank Strauss (I asked him to check to see if his compiler >> > >>> would also complain about that indexing thing, which it did not, >> > >>> but then Juergen has now added a lvl 4 warning about it). >> > >>> Frank brought out that the OID could become too long based on >> > >>> some index definitions. So Andy has posted a new rev to address >> > >>> that >> > >> > > .... >> > >> > >> > >> The rules are too strict! >> > > >> > > I agree here. When a default value is written in a description >> > > it seems to be allowe, but when a DEFVAL is used it is >> > > not because of compilers complain. That sounds >> > > contradictionary to me. The DEFVAL-cluase is >> > > (IMHO) there to support more formally the >> > > semantics of the object, but it may neither >> > > create a conflict with the semantics provided in >> > > the description-clause. >> > > >> > > >> > > Maybe far fetched, but I can envision such a scenario. >> > > Someone can create some object in X-MIB with >> > > a read-create ACCESS and a DEFVAL seems appropriate. >> > > Later someone else in Y-MIB uses that object in an >> > > index, because it wants to extend information for >> > > that perticular object only. >> > > The only option (to keep compilers happy) will then >> > > be create/duplicate the object and provide the same >> > > semantics without DEFVAL. >> > > >> > > Hmm.... >> > >> > Someone already did that -- in DSMON-MIB ! >> > >> > >> > >> > >> > > My thoughts about it, >> > > >> > > >> > > Harrie Hazewinkel >> > >> > Andy >> > >> > >> > >> > >> > _______________________________________________ >> > diffserv mailing list >> > diffserv@ietf.org >> > https://www1.ietf.org/mailman/listinfo/diffserv >> > Archive: >> > http://www2.ietf.org/mail-archive/working-groups/diffserv/curr >> ent/maillist.html >> >> _______________________________________________ >> diffserv mailing list >> diffserv@ietf.org >> https://www1.ietf.org/mailman/listinfo/diffserv >> Archive: >> http://www2.ietf.org/mail-archive/working-groups/diffserv/current/mailli >> st.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 > > > _______________________________________________ > RMONMIB mailing list > RMONMIB@ietf.org > http://www1.ietf.org/mailman/listinfo/rmonmib > > _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Tue Nov 6 04:42:50 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04798 for ; Tue, 6 Nov 2001 04:42:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA20458 for diffserv-archive@odin.ietf.org; Tue, 6 Nov 2001 04:42:44 -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 EAA19708; Tue, 6 Nov 2001 04:30: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 EAA18888 for ; Tue, 6 Nov 2001 04:15:14 -0500 (EST) Received: from robin.mail.pas.earthlink.net (robin.mail.pas.earthlink.net [207.217.120.65]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04491; Tue, 6 Nov 2001 04:15:09 -0500 (EST) Received: from user-1120fam.dsl.mindspring.com ([66.32.61.86] helo=ANDREWHOME) by robin.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1612K6-0004Y1-00; Tue, 06 Nov 2001 01:15:10 -0800 Reply-To: From: "Andrew Smith" To: "Harrie Hazewinkel" Cc: , "Diffserv" Date: Tue, 6 Nov 2001 01:38:31 -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: <400290.1004999325@localhost> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Subject: [Diffserv] RE: Differences between DSMON-MIB and DIFFSERV-MIB 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 Harrie, The basic issue here is whether DSMON should invent a new concept ("aggregation group") for something that does not exist in the Diffserv architecture or in any of the drafts that discuss management of Diffserv. It seems wrong to do so if there is already an existing concept (a "data path") that is a candidate for performing the necessary monitoring actions. Your message, Harrie, goes into the details of how we might or might not re-use existing objects but I'm trying to establish the general concept first. "Data path" is not the same as "aggregation group" (neither is "PHB"). As currently defined in DSMON, an aggregation group can be defined to include traffic with assorted DSCPs totally orthogonally to the Diffserv treatment that nodes might give those DSCPs: that's great - it's as as flexible as anyone could want. But does it bare any relationship to the things that network managers want to see? Andy asserts that it does, I would disagree. I would argue that the things that people will want to train their DSMON probes on are precisely the things that are a result of the Diffserv configuration and that the manager (or the management tools, to be precise) should not have to convert from one model used for configuration of the network nodes into an orthogonal model used by the monitoring probes. That's just unnecessary work. I'd also argue that, to turn Andy's example against him, DSMON should be to the Diffserv MIB as RMON is to the Ethernet MIB or RMON2 is to IP MIB statistics: xxxMON should be a tool to take MIB objects and "wrap them up" with history samples, trending and traffic matrix mechanisms. An xxxMON module should not go off on its own in defining new management models for the xxx technology. Until we can agree (or agree to disagree) on these fundamentals, there's no point diving into the details. Andrew -----Original Message----- From: Harrie Hazewinkel [mailto:harrie@covalent.net] Sent: Monday, November 05, 2001 10:29 PM To: Brian E Carpenter; Romascanu, Dan (Dan) Cc: Andrew Smith; rmonmib@ietf.org; Diffserv Subject: Differences between DSMON-MIB and DIFFSERV-MIB Hi, (Note I changed the subject) --On Monday, November 5, 2001 1:42 PM +0100 Brian E Carpenter wrote: > Dan, > > "Romascanu, Dan (Dan)" wrote: > ... >> I think that the problem spaces of providing data for the protocol >> management, and monitoring the network (by stand-alone or embedded >> probes) are complementary sets of tools, which deserve each their >> separate definition and MIB interface. > > That is why the diffserv MIB has two conformance levels, one for > read-only (i.e. monitoring) and one for read-write (i.e. control). > A priori, the diffserv MIB is what you need for complete monitoring > of a diffserv router. IMHO, the two conformance levels are there to have a different SNMP access which in perticular reflect the approach the system gets configured. The 'full compliance' makes it that a diffserv capable router can be monitored and configured via SNMP. The 'read-only compliance' is mainly to support toses diffserv capable routers who do not do configuration via SNMP. It can indeed be used for monitoring, but the system can be configured in other ways than SNMP. > It certainly doesn't seem appropriate to > construct a *different* virtual model of such a router for an RMON > MIB; surely it should be a strict subset of the same model? The virtual model mainly creates the concept of the datapath and its elements. Those datapaths and elements cause in a diffserv capable router traffic treatment. Different treatment can be given based on the way the traffic is filtered and goes through the datapath elements. Traffic behavior can be altered/shaped or just treated differently. RMON is just a probe sitting on the sideline looking at the traffic. It does not do any traffic treatment or shaping. Traffic streams are NOT altered. > Otherwise life will become very confusing for operational staff. This is maybe already caused by the existance of RMON. Like D.Romascanu said; "The obvious example is that the RMON and RMON-2 MIBs from RMON probes complement from a network operator point of view the information that can be obtained by looking at MIB-II, Bridge MIB and IP forwarding MIBs in the bridges and routers deployed in the network." I beleive the models are different where DSMON-MIB is monitoring a particular traffic pattern and the DIFFSERV-MIB is monitoring a perticular datapath configuration (and if 'full compliant' also configuration itself. A big difference is the end of a datapath configuration is the router core. In DSMON-MIB monitoring is no router core. Also the DIFFSERV-MIB has for each count action a next datapath element which is not in the DSMON-MIB. > > The diffserv MIB deconstructs the path for each traffic aggregate > and maintains some counters deep down in the deconstructed elements > of the path. You are going the opposite way in the DSMON MIB - you > are synthesizing something that doesn't exist (the aggregation group), > which may or may not map to the paths defined in the diffserv MIB. Indeed, this is a difference. > In practice I think that will force implementors to do extra work, > and cost extra overhead. It would indeed seem more logical for > the DSMON MIB to collect up the counters already defined by the > diffserv MIB, but that means a different approach to aggregating > the counters. I am not sure if I follow it completely; correct me if I am wrong. What you are saying is that the counter which are combined with a particular DSCP counting from as well the DSMON-MIB and the DIFFSERV-MIB can be the same?? But where does the traffic gets delivered in case of an DSMON situation with the DIFFSERV-MIB?? The value zeroDotZero for a next pointer does not seem to be appropriate if you just have a normal RMON probe. I beleive this will force also extra work to configure the system. Maybe one will not have the same DSMON monitoring (filtering) as one has traffic treatment. That would mean: A traffic filter that feeds the various counters to do traffic monitoring. The next pointer of all the count actions need to be the same from where a complete new set of traffic filters is created in order to have a traffic treatment one would like to have. Maybe a farfetched idea, but still. Looks possible to me. However, when the DSMON-MIB is just in a probe, I am not sure how to use the filters and more precise the count actions of the DIFFSERV-MIB need to be set up than. What is the next pointer of the count actions?? These count actions (datapath elements) are not in the path of the traffic and neither can the traffic be delivered at the router core as the DIFFSERV-MIB does. Maybe the case where an RMON probe in the DIFFSERV capable router resides is a border case. But this is (I beleive) not to be expected the case always. Hope this all makes sense, (if not say so) Harrie > > Brian > >> > -----Original Message----- >> > From: Andrew Smith [mailto:ah_smith@acm.org] >> > Sent: Friday, November 02, 2001 11:12 PM >> > To: rmonmib@ietf.org >> > Cc: Diffserv >> > Subject: [Diffserv] RE: DEFVAL in dsmonAggGroupIndex - SMIC error >> > >> > >> > I've (still) got serious problems with this MIB, its >> > relationship to the >> > DiffServ MIB and the "aggregation group" concept. Haven't >> > spoken up recently >> > because I thought others would taken care of it by now. >> > >> > 1. You're duplicating functionality from the DiffServ MIB >> > here. If that's >> > fine with IESG then OK but it seems like a bad idea to me. People have >> > argued on the RMON list before that DSMON is meant for >> > probes, not switches >> > but I believe a large proportion of DSMON implementations >> > will end up inside >> > switches with consequent waste of resources. I do not think >> > there is a good >> > case to be made for optimising this MIB for the "standalone >> > probe" case. >> > >> > 2. You're inventing a new grouping concept with its own >> > number space for >> > something that the DiffServ conceptual management model, MIB >> > and PIB do >> > using their "data path" concept and which they have their own >> > numberspace >> > for. You should re-use that concept or else persuade DiffServ >> > to use your >> > concept but there is no excuse for having duplicate >> > mechanisms in MIBs that >> > are being developed/published at roughly the same time by >> > IETF (is this due >> > to OPS and TSV ADs not talking to each other enough? No >> > apologies for adding >> > Diffserv WG to this message). >> > >> > 3. You're overloading your dsmonAggGroupIndex numberspace with the >> > "convenience functionality" of letting the group index equal the DSCP. >> > There's no need for this and it cannot be useful unless you have some >> > mandated behaviour that relies on this 1:1 mapping e.g. a >> > default setting >> > for the table on power-up or initial state. Leaving it as an >> > option (see >> > "SHOULD" below) makes it useless in a multi-vendor world. >> > >> > Specifics: >> > >> > 4. "dsmonAggGroupIndex OBJECT-TYPE >> > SYNTAX DsmonAggGroupIndex >> > MAX-ACCESS read-write >> > STATUS current >> > DESCRIPTION >> > "The aggregation group which contains this DSCP >> > value. Upon >> > creation of a new sub-tree (set of 64 entries >> > with the same >> > dsmonAggControlIndex value) in this table, the >> > agent SHOULD >> > initialize all related instances of this object >> > to the value >> > zero. >> > >> > This object MUST NOT be modified if the >> > dsmonAggControlLocked object is equal to 'true'." >> > DEFVAL { 0 }" >> > >> > a) This description does not make sense (to me): >> > dsmonAggControlIndex does >> > not appear in this table so how is creation of a new sub-tree >> > related to >> > entries in this table? Please clarify this wording. Or is this a typo? >> > b) What's the point of the "SHOULD" directive here? >> > c) Define "related instances" more precisely. >> > d) You can't say that a read-write variable "MUST NOT" be modified (by >> > whom?) - you can define that if you try to do so then the >> > operation will >> > pass/fail etc. but you can't use a MIB to enforce what a >> > manager can/cannot >> > attempt (you might as well add "please" :-)). >> > e) I don't think you can rely on "0" as a special value of >> > DSCP here - use >> > something like -1 if you really need to use a DEFVAL. >> > >> > That's all on this particular issue, I guess I ought to read >> > the rest of the >> > MIB now ... >> > >> > Andrew Smith >> > >> > >> > -----Original Message----- >> > From: owner-mibs@ops.ietf.org >> > [mailto:owner-mibs@ops.ietf.org]On Behalf >> > Of Andy Bierman >> > Sent: Friday, November 02, 2001 8:31 AM >> > To: Harrie Hazewinkel >> > Cc: bwijnen@lucent.com; rmonmib@ietf.org; mibs@ops.ietf.org >> > Subject: DEFVAL in dsmonAggGroupIndex - SMIC error >> > >> > >> > At 06:33 PM 11/1/2001 -0800, Harrie Hazewinkel wrote: >> > >> > >> > >> > Now that I looked at this some more, I think the SMIC is wrong. >> > This DEFVAL should not be a syntax error. >> > >> > The dsmonAggGroupIndex object itself is read-write object >> > and not an INDEX in the table its defined in. The DEFVAL clause >> > indicates that the initial aggGroup value an agent should set for each >> > DSCP mapping. All DSCPs in the same group -- perfectly valid concept, >> > perfectly valid SMIv2 syntax. >> > >> > However, the dsmonAggGroupIndex object is also declared as one of the >> > INDEX components in the dsmonAggGroupEntry. SMIC is complaining about >> > the DEFVAL that is only meant to apply to original OBJECT-TYPE macro, >> > not a DEFVAL for the INDEX -- that doesn't even make sense. >> > >> > > --On Thursday, November 1, 2001 7:40 AM -0800 Andy Bierman >> > > wrote: >> > > >> > >> At 01:39 PM 11/1/2001 +0100, Wijnen, Bert (Bert) wrote: >> > >>> OK, 2 issues basically came out after your approval. >> > >>> >> > >>> - SMICng complains about having a DEFVAL for dsmonAggGroupIndex >> > >>> since this object is used as an index object as well. Andy >> > >>> did put it in since you insisted. I am discussing the matter >> > >>> with the SMIv2 doc editors >> > >>> - Frank Strauss (I asked him to check to see if his compiler >> > >>> would also complain about that indexing thing, which it did not, >> > >>> but then Juergen has now added a lvl 4 warning about it). >> > >>> Frank brought out that the OID could become too long based on >> > >>> some index definitions. So Andy has posted a new rev to address >> > >>> that >> > >> > > .... >> > >> > >> > >> The rules are too strict! >> > > >> > > I agree here. When a default value is written in a description >> > > it seems to be allowe, but when a DEFVAL is used it is >> > > not because of compilers complain. That sounds >> > > contradictionary to me. The DEFVAL-cluase is >> > > (IMHO) there to support more formally the >> > > semantics of the object, but it may neither >> > > create a conflict with the semantics provided in >> > > the description-clause. >> > > >> > > >> > > Maybe far fetched, but I can envision such a scenario. >> > > Someone can create some object in X-MIB with >> > > a read-create ACCESS and a DEFVAL seems appropriate. >> > > Later someone else in Y-MIB uses that object in an >> > > index, because it wants to extend information for >> > > that perticular object only. >> > > The only option (to keep compilers happy) will then >> > > be create/duplicate the object and provide the same >> > > semantics without DEFVAL. >> > > >> > > Hmm.... >> > >> > Someone already did that -- in DSMON-MIB ! >> > >> > >> > >> > >> > > My thoughts about it, >> > > >> > > >> > > Harrie Hazewinkel >> > >> > Andy >> > >> > >> > >> > >> > _______________________________________________ >> > diffserv mailing list >> > diffserv@ietf.org >> > https://www1.ietf.org/mailman/listinfo/diffserv >> > Archive: >> > http://www2.ietf.org/mail-archive/working-groups/diffserv/curr >> ent/maillist.html >> >> _______________________________________________ >> diffserv mailing list >> diffserv@ietf.org >> https://www1.ietf.org/mailman/listinfo/diffserv >> Archive: >> http://www2.ietf.org/mail-archive/working-groups/diffserv/current/mailli >> st.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 > > > _______________________________________________ > RMONMIB mailing list > RMONMIB@ietf.org > http://www1.ietf.org/mailman/listinfo/rmonmib > > _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Tue Nov 6 04:43:52 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04832 for ; Tue, 6 Nov 2001 04:43:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA20503 for diffserv-archive@odin.ietf.org; Tue, 6 Nov 2001 04:43: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 EAA19007; Tue, 6 Nov 2001 04:21:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA18976 for ; Tue, 6 Nov 2001 04:21:50 -0500 (EST) Received: from robin.mail.pas.earthlink.net (robin.mail.pas.earthlink.net [207.217.120.65]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04526 for ; Tue, 6 Nov 2001 04:21:46 -0500 (EST) Received: from user-1120fam.dsl.mindspring.com ([66.32.61.86] helo=ANDREWHOME) by robin.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1612QW-0006pN-00 for diffserv@ietf.org; Tue, 06 Nov 2001 01:21:48 -0800 From: "Andrew Smith" To: "Diffserv" Date: Tue, 6 Nov 2001 01:45:09 -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: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Subject: [Diffserv] RE: Differences between DSMON-MIB and DIFFSERV-MIB 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 To: Harrie Hazewinkel Cc: rmonmib@ietf.org Harrie, The basic issue here is whether DSMON should invent a new concept ("aggregation group") for something that does not exist in the Diffserv architecture or in any of the drafts that discuss management of Diffserv. It seems wrong to do so if there is already an existing concept (a "data path") that is a candidate for performing the necessary monitoring actions. Your message, Harrie, goes into the details of how we might or might not re-use existing objects but I'm trying to establish the general concept first. "Data path" is not the same as "aggregation group" (neither is "PHB"). As currently defined in DSMON, an aggregation group can be defined to include traffic with assorted DSCPs totally orthogonally to the Diffserv treatment that nodes might give those DSCPs: that's great - it's as as flexible as anyone could want. But does it bare any relationship to the things that network managers want to see? Andy asserts that it does, I would disagree. I would argue that the things that people will want to train their DSMON probes on are precisely the things that are a result of the Diffserv configuration and that the manager (or the management tools, to be precise) should not have to convert from one model used for configuration of the network nodes into an orthogonal model used by the monitoring probes. That's just unnecessary work. I'd also argue that, to turn Andy's example against him, DSMON should be to the Diffserv MIB as RMON is to the Ethernet MIB or RMON2 is to IP MIB statistics: xxxMON should be a tool to take MIB objects and "wrap them up" with history samples, trending and traffic matrix mechanisms. An xxxMON module should not go off on its own in defining new management models for the xxx technology. Until we can agree (or agree to disagree) on these fundamentals, there's no point diving into the details. Andrew -----Original Message----- From: Harrie Hazewinkel [mailto:harrie@covalent.net] Sent: Monday, November 05, 2001 10:29 PM To: Brian E Carpenter; Romascanu, Dan (Dan) Cc: Andrew Smith; rmonmib@ietf.org; Diffserv Subject: Differences between DSMON-MIB and DIFFSERV-MIB Hi, (Note I changed the subject) --On Monday, November 5, 2001 1:42 PM +0100 Brian E Carpenter wrote: > Dan, > > "Romascanu, Dan (Dan)" wrote: > ... >> I think that the problem spaces of providing data for the protocol >> management, and monitoring the network (by stand-alone or embedded >> probes) are complementary sets of tools, which deserve each their >> separate definition and MIB interface. > > That is why the diffserv MIB has two conformance levels, one for > read-only (i.e. monitoring) and one for read-write (i.e. control). > A priori, the diffserv MIB is what you need for complete monitoring > of a diffserv router. IMHO, the two conformance levels are there to have a different SNMP access which in perticular reflect the approach the system gets configured. The 'full compliance' makes it that a diffserv capable router can be monitored and configured via SNMP. The 'read-only compliance' is mainly to support toses diffserv capable routers who do not do configuration via SNMP. It can indeed be used for monitoring, but the system can be configured in other ways than SNMP. > It certainly doesn't seem appropriate to > construct a *different* virtual model of such a router for an RMON > MIB; surely it should be a strict subset of the same model? The virtual model mainly creates the concept of the datapath and its elements. Those datapaths and elements cause in a diffserv capable router traffic treatment. Different treatment can be given based on the way the traffic is filtered and goes through the datapath elements. Traffic behavior can be altered/shaped or just treated differently. RMON is just a probe sitting on the sideline looking at the traffic. It does not do any traffic treatment or shaping. Traffic streams are NOT altered. > Otherwise life will become very confusing for operational staff. This is maybe already caused by the existance of RMON. Like D.Romascanu said; "The obvious example is that the RMON and RMON-2 MIBs from RMON probes complement from a network operator point of view the information that can be obtained by looking at MIB-II, Bridge MIB and IP forwarding MIBs in the bridges and routers deployed in the network." I beleive the models are different where DSMON-MIB is monitoring a particular traffic pattern and the DIFFSERV-MIB is monitoring a perticular datapath configuration (and if 'full compliant' also configuration itself. A big difference is the end of a datapath configuration is the router core. In DSMON-MIB monitoring is no router core. Also the DIFFSERV-MIB has for each count action a next datapath element which is not in the DSMON-MIB. > > The diffserv MIB deconstructs the path for each traffic aggregate > and maintains some counters deep down in the deconstructed elements > of the path. You are going the opposite way in the DSMON MIB - you > are synthesizing something that doesn't exist (the aggregation group), > which may or may not map to the paths defined in the diffserv MIB. Indeed, this is a difference. > In practice I think that will force implementors to do extra work, > and cost extra overhead. It would indeed seem more logical for > the DSMON MIB to collect up the counters already defined by the > diffserv MIB, but that means a different approach to aggregating > the counters. I am not sure if I follow it completely; correct me if I am wrong. What you are saying is that the counter which are combined with a particular DSCP counting from as well the DSMON-MIB and the DIFFSERV-MIB can be the same?? But where does the traffic gets delivered in case of an DSMON situation with the DIFFSERV-MIB?? The value zeroDotZero for a next pointer does not seem to be appropriate if you just have a normal RMON probe. I beleive this will force also extra work to configure the system. Maybe one will not have the same DSMON monitoring (filtering) as one has traffic treatment. That would mean: A traffic filter that feeds the various counters to do traffic monitoring. The next pointer of all the count actions need to be the same from where a complete new set of traffic filters is created in order to have a traffic treatment one would like to have. Maybe a farfetched idea, but still. Looks possible to me. However, when the DSMON-MIB is just in a probe, I am not sure how to use the filters and more precise the count actions of the DIFFSERV-MIB need to be set up than. What is the next pointer of the count actions?? These count actions (datapath elements) are not in the path of the traffic and neither can the traffic be delivered at the router core as the DIFFSERV-MIB does. Maybe the case where an RMON probe in the DIFFSERV capable router resides is a border case. But this is (I beleive) not to be expected the case always. Hope this all makes sense, (if not say so) Harrie > > Brian > >> > -----Original Message----- >> > From: Andrew Smith [mailto:ah_smith@acm.org] >> > Sent: Friday, November 02, 2001 11:12 PM >> > To: rmonmib@ietf.org >> > Cc: Diffserv >> > Subject: [Diffserv] RE: DEFVAL in dsmonAggGroupIndex - SMIC error >> > >> > >> > I've (still) got serious problems with this MIB, its >> > relationship to the >> > DiffServ MIB and the "aggregation group" concept. Haven't >> > spoken up recently >> > because I thought others would taken care of it by now. >> > >> > 1. You're duplicating functionality from the DiffServ MIB >> > here. If that's >> > fine with IESG then OK but it seems like a bad idea to me. People have >> > argued on the RMON list before that DSMON is meant for >> > probes, not switches >> > but I believe a large proportion of DSMON implementations >> > will end up inside >> > switches with consequent waste of resources. I do not think >> > there is a good >> > case to be made for optimising this MIB for the "standalone >> > probe" case. >> > >> > 2. You're inventing a new grouping concept with its own >> > number space for >> > something that the DiffServ conceptual management model, MIB >> > and PIB do >> > using their "data path" concept and which they have their own >> > numberspace >> > for. You should re-use that concept or else persuade DiffServ >> > to use your >> > concept but there is no excuse for having duplicate >> > mechanisms in MIBs that >> > are being developed/published at roughly the same time by >> > IETF (is this due >> > to OPS and TSV ADs not talking to each other enough? No >> > apologies for adding >> > Diffserv WG to this message). >> > >> > 3. You're overloading your dsmonAggGroupIndex numberspace with the >> > "convenience functionality" of letting the group index equal the DSCP. >> > There's no need for this and it cannot be useful unless you have some >> > mandated behaviour that relies on this 1:1 mapping e.g. a >> > default setting >> > for the table on power-up or initial state. Leaving it as an >> > option (see >> > "SHOULD" below) makes it useless in a multi-vendor world. >> > >> > Specifics: >> > >> > 4. "dsmonAggGroupIndex OBJECT-TYPE >> > SYNTAX DsmonAggGroupIndex >> > MAX-ACCESS read-write >> > STATUS current >> > DESCRIPTION >> > "The aggregation group which contains this DSCP >> > value. Upon >> > creation of a new sub-tree (set of 64 entries >> > with the same >> > dsmonAggControlIndex value) in this table, the >> > agent SHOULD >> > initialize all related instances of this object >> > to the value >> > zero. >> > >> > This object MUST NOT be modified if the >> > dsmonAggControlLocked object is equal to 'true'." >> > DEFVAL { 0 }" >> > >> > a) This description does not make sense (to me): >> > dsmonAggControlIndex does >> > not appear in this table so how is creation of a new sub-tree >> > related to >> > entries in this table? Please clarify this wording. Or is this a typo? >> > b) What's the point of the "SHOULD" directive here? >> > c) Define "related instances" more precisely. >> > d) You can't say that a read-write variable "MUST NOT" be modified (by >> > whom?) - you can define that if you try to do so then the >> > operation will >> > pass/fail etc. but you can't use a MIB to enforce what a >> > manager can/cannot >> > attempt (you might as well add "please" :-)). >> > e) I don't think you can rely on "0" as a special value of >> > DSCP here - use >> > something like -1 if you really need to use a DEFVAL. >> > >> > That's all on this particular issue, I guess I ought to read >> > the rest of the >> > MIB now ... >> > >> > Andrew Smith >> > >> > >> > -----Original Message----- >> > From: owner-mibs@ops.ietf.org >> > [mailto:owner-mibs@ops.ietf.org]On Behalf >> > Of Andy Bierman >> > Sent: Friday, November 02, 2001 8:31 AM >> > To: Harrie Hazewinkel >> > Cc: bwijnen@lucent.com; rmonmib@ietf.org; mibs@ops.ietf.org >> > Subject: DEFVAL in dsmonAggGroupIndex - SMIC error >> > >> > >> > At 06:33 PM 11/1/2001 -0800, Harrie Hazewinkel wrote: >> > >> > >> > >> > Now that I looked at this some more, I think the SMIC is wrong. >> > This DEFVAL should not be a syntax error. >> > >> > The dsmonAggGroupIndex object itself is read-write object >> > and not an INDEX in the table its defined in. The DEFVAL clause >> > indicates that the initial aggGroup value an agent should set for each >> > DSCP mapping. All DSCPs in the same group -- perfectly valid concept, >> > perfectly valid SMIv2 syntax. >> > >> > However, the dsmonAggGroupIndex object is also declared as one of the >> > INDEX components in the dsmonAggGroupEntry. SMIC is complaining about >> > the DEFVAL that is only meant to apply to original OBJECT-TYPE macro, >> > not a DEFVAL for the INDEX -- that doesn't even make sense. >> > >> > > --On Thursday, November 1, 2001 7:40 AM -0800 Andy Bierman >> > > wrote: >> > > >> > >> At 01:39 PM 11/1/2001 +0100, Wijnen, Bert (Bert) wrote: >> > >>> OK, 2 issues basically came out after your approval. >> > >>> >> > >>> - SMICng complains about having a DEFVAL for dsmonAggGroupIndex >> > >>> since this object is used as an index object as well. Andy >> > >>> did put it in since you insisted. I am discussing the matter >> > >>> with the SMIv2 doc editors >> > >>> - Frank Strauss (I asked him to check to see if his compiler >> > >>> would also complain about that indexing thing, which it did not, >> > >>> but then Juergen has now added a lvl 4 warning about it). >> > >>> Frank brought out that the OID could become too long based on >> > >>> some index definitions. So Andy has posted a new rev to address >> > >>> that >> > >> > > .... >> > >> > >> > >> The rules are too strict! >> > > >> > > I agree here. When a default value is written in a description >> > > it seems to be allowe, but when a DEFVAL is used it is >> > > not because of compilers complain. That sounds >> > > contradictionary to me. The DEFVAL-cluase is >> > > (IMHO) there to support more formally the >> > > semantics of the object, but it may neither >> > > create a conflict with the semantics provided in >> > > the description-clause. >> > > >> > > >> > > Maybe far fetched, but I can envision such a scenario. >> > > Someone can create some object in X-MIB with >> > > a read-create ACCESS and a DEFVAL seems appropriate. >> > > Later someone else in Y-MIB uses that object in an >> > > index, because it wants to extend information for >> > > that perticular object only. >> > > The only option (to keep compilers happy) will then >> > > be create/duplicate the object and provide the same >> > > semantics without DEFVAL. >> > > >> > > Hmm.... >> > >> > Someone already did that -- in DSMON-MIB ! >> > >> > >> > >> > >> > > My thoughts about it, >> > > >> > > >> > > Harrie Hazewinkel >> > >> > Andy >> > >> > >> > >> > >> > _______________________________________________ >> > diffserv mailing list >> > diffserv@ietf.org >> > https://www1.ietf.org/mailman/listinfo/diffserv >> > Archive: >> > http://www2.ietf.org/mail-archive/working-groups/diffserv/curr >> ent/maillist.html >> >> _______________________________________________ >> diffserv mailing list >> diffserv@ietf.org >> https://www1.ietf.org/mailman/listinfo/diffserv >> Archive: >> http://www2.ietf.org/mail-archive/working-groups/diffserv/current/mailli >> st.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 > > > _______________________________________________ > RMONMIB mailing list > RMONMIB@ietf.org > http://www1.ietf.org/mailman/listinfo/rmonmib > > _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Tue Nov 6 05:13:07 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05302 for ; Tue, 6 Nov 2001 05:12:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA21995 for diffserv-archive@odin.ietf.org; Tue, 6 Nov 2001 05:12:35 -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 EAA20960; Tue, 6 Nov 2001 04:59:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA20927 for ; Tue, 6 Nov 2001 04:58:58 -0500 (EST) Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04976; Tue, 6 Nov 2001 04:58:53 -0500 (EST) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id fA69vuZ16975; Tue, 6 Nov 2001 04:57:56 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h149-49-38-91.avaya.com [149.49.38.91]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id fA69vtD16961; Tue, 6 Nov 2001 04:57:56 -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] RE: Differences between DSMON-MIB and DIFFSERV-MIB Date: Tue, 6 Nov 2001 11:58:45 +0200 Message-ID: Thread-Topic: [Diffserv] RE: Differences between DSMON-MIB and DIFFSERV-MIB Thread-Index: AcFmpq7wIzR8SXhcTf+mKO8Hom5KTgAAJUDg From: "Romascanu, Dan (Dan)" To: , "Harrie Hazewinkel" Cc: , "Diffserv" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA20930 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 Andy, , > > The basic issue here is whether DSMON should invent a new concept > ("aggregation group") for something that does not exist in > the Diffserv > architecture or in any of the drafts that discuss management > of Diffserv. It > seems wrong to do so if there is already an existing concept > (a "data path") > that is a candidate for performing the necessary monitoring > actions. Your > message, Harrie, goes into the details of how we might or > might not re-use > existing objects but I'm trying to establish the general > concept first. > > "Data path" is not the same as "aggregation group" (neither > is "PHB"). As > currently defined in DSMON, an aggregation group can be > defined to include > traffic with assorted DSCPs totally orthogonally to the > Diffserv treatment > that nodes might give those DSCPs: that's great - it's as as > flexible as > anyone could want. But does it bare any relationship to the > things that > network managers want to see? Andy asserts that it does, I > would disagree. I > would argue that the things that people will want to train their DSMON > probes on are precisely the things that are a result of the Diffserv > configuration and that the manager (or the management tools, > to be precise) > should not have to convert from one model used for > configuration of the > network nodes into an orthogonal model used by the monitoring > probes. That's > just unnecessary work. > I would like to point to two separate issues here: - It seems to me that there might be cases when the aggregation concept is two little or two much from a monitoring tool point of view. It might be too little if the aggregation applies to a specific policy administrative domain, and packets that are monitored at a certain monitoring point are the result of them originating from such different domains. It may be two much because in some real life situations an operator may need (or may be forced to use because of the limitations of his monitoring probe) a coarser set of code points values (like default and 'all-but-default') - The other issue is that DiffServ MIB is designed to run in diffserv routers. It makes assumptions about the agent understanding how such routers work, and you need this understanding even in the read-only mode. One cannot make such assumptions about all RMON probes. > I'd also argue that, to turn Andy's example against him, > DSMON should be to > the Diffserv MIB as RMON is to the Ethernet MIB or RMON2 is to IP MIB > statistics: xxxMON should be a tool to take MIB objects and > "wrap them up" > with history samples, trending and traffic matrix mechanisms. > An xxxMON > module should not go off on its own in defining new > management models for > the xxx technology. > Actually you are making a point for the need of a DS-MON MIB. However, you miss the fact that the DS-MON MIB requires support for many objects whose purpose is to determine the functionality and health status of the router, queues, etc. which are not necessarily of interest for a network monitoring tool. When RMON showed up it cleaned out from the Ethernet MIB some objects which were considered not relevant for the monitoring of the network, but were otherwise very useful to debug the status of an Ethernet interface. > Until we can agree (or agree to disagree) on these > fundamentals, there's no > point diving into the details. > yes, there is a 'fundamental' issue here. The issue is in my opinion the difference between a MIB focused on device management, and a MIB focusing on network level monitoring. According to my operational experience, these two views are complementary, and are both needed. Regards, Dan > Andrew > > > _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/mailli st.html _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Tue Nov 6 08:20:06 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09211 for ; Tue, 6 Nov 2001 08:20:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA26610 for diffserv-archive@odin.ietf.org; Tue, 6 Nov 2001 07:45:06 -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 HAA26502; Tue, 6 Nov 2001 07:32: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 HAA26467 for ; Tue, 6 Nov 2001 07:32:10 -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 HAA07763; Tue, 6 Nov 2001 07:32:07 -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 NAA11724; Tue, 6 Nov 2001 13:31:31 +0100 Received: from dhcp22-51.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA18590 from ; Tue, 6 Nov 2001 13:31:28 +0100 Message-Id: <3BE7D491.7CBCC905@hursley.ibm.com> Date: Tue, 06 Nov 2001 13:16:17 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: "Romascanu, Dan (Dan)" Cc: ah_smith@pacbell.net, Harrie Hazewinkel , rmonmib@ietf.org, Diffserv Subject: Re: [Diffserv] RE: Differences between DSMON-MIB and DIFFSERV-MIB 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 snipping... "Romascanu, Dan (Dan)" wrote: > ... > I would like to point to two separate issues here: > > - It seems to me that there might be cases when the aggregation concept > is two little or two much from a monitoring tool point of view. It might > be too little if the aggregation applies to a specific policy > administrative domain, and packets that are monitored at a certain > monitoring point are the result of them originating from such different > domains. It may be two much because in some real life situations an > operator may need (or may be forced to use because of the limitations of > his monitoring probe) a coarser set of code points values (like default > and 'all-but-default') But the point is that this form of aggregation is pretty much orthogonal to the diffserv architecture. It's meaningless, in terms of diffserv, to add together the statistics of separate traffic aggregates (yes, the word "aggregate" already has a very specific meaning in diffserv, and it is different from the usage in DSMON.) The only case where it might make sense is for PHB groups. The DSMON "aggregates" *in any case* need to be renamed, to avoid confusion with diffserv traffic aggregates. Frankly I don't see the point. Nobody expects to deploy real diffserv networks with more than a few traffic classes (i.e. DSCPs) active. In any case, the theoretical maximum (64) is a small number. Why not just monitor DSCPs? (I agree that an "everything else" bucket is useful, at least for presentation.) > - The other issue is that DiffServ MIB is designed to run in diffserv > routers. It makes assumptions about the agent understanding how such > routers work, and you need this understanding even in the read-only > mode. One cannot make such assumptions about all RMON probes. Correct, that is a valid point: a pure probe can't be expected to have full knowledge of the diffserv configuration. Equally, it can't measure everything, for example it can't count packet drops, which is one of the basic metrics of a diffserv traffic aggregate. But why can't it use the same concept of traffic aggregates as the DSMIB, and count a subset of the same things? ... > > > > yes, there is a 'fundamental' issue here. The issue is in my opinion the > difference between a MIB focused on device management, and a MIB > focusing on network level monitoring. According to my operational > experience, these two views are complementary, and are both needed. No disagreement there. But they can be complementary without being inconsistent. Brian _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Tue Nov 6 08:21:20 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09338 for ; Tue, 6 Nov 2001 08:21:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA28471 for diffserv-archive@odin.ietf.org; Tue, 6 Nov 2001 08:21:22 -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 IAA27584; Tue, 6 Nov 2001 08:10:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA27467 for ; Tue, 6 Nov 2001 08:10: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 IAA08276; Tue, 6 Nov 2001 08:10:27 -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 HAA04774; Tue, 6 Nov 2001 07:45:57 -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 HAA04723; Tue, 6 Nov 2001 07:45:45 -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] RE: Differences between DSMON-MIB and DIFFSERV-MIB Date: Tue, 6 Nov 2001 14:46:52 +0200 Message-ID: Thread-Topic: [Diffserv] RE: Differences between DSMON-MIB and DIFFSERV-MIB Thread-Index: AcFmvyRtfInSWdneRVewhvPRfL9gVgAAF2Wg From: "Romascanu, Dan (Dan)" To: "Brian E Carpenter" Cc: , "Harrie Hazewinkel" , , "Diffserv" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA27470 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 So, would the following DS-MON MIB changes be satisfactory? - Rename the *DS-MON aggregation* to something else to avoid confusion with the *diffserv aggregates* - Support the *diffserv aggregates*, maybe by mapping the rename *DS-MON aggregates* into the *diffserv aggregates* If the answer is yes, we still need to hear the opinion of the DS-MON MIB author. I am just looking at it from the perspective of the implementation of DS-MON together with other RMON family protocols. Regards, Dan > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Tuesday, November 06, 2001 2:16 PM > To: Romascanu, Dan (Dan) > Cc: ah_smith@pacbell.net; Harrie Hazewinkel; > rmonmib@ietf.org; Diffserv > Subject: Re: [Diffserv] RE: Differences between DSMON-MIB and > DIFFSERV-MIB > > > snipping... > > "Romascanu, Dan (Dan)" wrote: > > > ... > > I would like to point to two separate issues here: > > > > - It seems to me that there might be cases when the > aggregation concept > > is two little or two much from a monitoring tool point of > view. It might > > be too little if the aggregation applies to a specific policy > > administrative domain, and packets that are monitored at a certain > > monitoring point are the result of them originating from > such different > > domains. It may be two much because in some real life situations an > > operator may need (or may be forced to use because of the > limitations of > > his monitoring probe) a coarser set of code points values > (like default > > and 'all-but-default') > > But the point is that this form of aggregation is pretty much > orthogonal to the diffserv architecture. It's meaningless, in terms > of diffserv, to add together the statistics of separate traffic > aggregates (yes, the word "aggregate" already has a very specific > meaning in diffserv, and it is different from the usage in DSMON.) > The only case where it might make sense is for PHB groups. > The DSMON "aggregates" *in any case* need to be renamed, to avoid > confusion with diffserv traffic aggregates. > > Frankly I don't see the point. Nobody expects to deploy real diffserv > networks with more than a few traffic classes (i.e. DSCPs) active. > In any case, the theoretical maximum (64) is a small number. Why not > just monitor DSCPs? (I agree that an "everything else" bucket > is useful, > at least for presentation.) > > > - The other issue is that DiffServ MIB is designed to run > in diffserv > > routers. It makes assumptions about the agent understanding how such > > routers work, and you need this understanding even in the read-only > > mode. One cannot make such assumptions about all RMON probes. > > Correct, that is a valid point: a pure probe can't be expected to > have full knowledge of the diffserv configuration. Equally, it > can't measure everything, for example it can't count packet drops, > which is one of the basic metrics of a diffserv traffic aggregate. > But why can't it use the same concept of traffic aggregates as > the DSMIB, and count a subset of the same things? > > ... > > > > > > > yes, there is a 'fundamental' issue here. The issue is in > my opinion the > > difference between a MIB focused on device management, and a MIB > > focusing on network level monitoring. According to my operational > > experience, these two views are complementary, and are both needed. > > No disagreement there. But they can be complementary without > being inconsistent. > > Brian > _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Tue Nov 6 09:47:13 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15177 for ; Tue, 6 Nov 2001 09:47:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA02723 for diffserv-archive@odin.ietf.org; Tue, 6 Nov 2001 09:47:13 -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 JAA01964; Tue, 6 Nov 2001 09:30:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA01933 for ; Tue, 6 Nov 2001 09:30:51 -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 JAA14308; Tue, 6 Nov 2001 09:30:47 -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 PAA17384; Tue, 6 Nov 2001 15:30:11 +0100 Received: from dhcp22-51.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA55116 from ; Tue, 6 Nov 2001 15:30:06 +0100 Message-Id: <3BE7EE93.3D60DA9D@hursley.ibm.com> Date: Tue, 06 Nov 2001 15:07:15 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: "Romascanu, Dan (Dan)" Cc: ah_smith@pacbell.net, Harrie Hazewinkel , rmonmib@ietf.org, Diffserv Subject: Re: [Diffserv] RE: Differences between DSMON-MIB and DIFFSERV-MIB 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 Dan, I think this is a good compromise approach, since I doubt if you want to start again :-) "Romascanu, Dan (Dan)" wrote: > > So, would the following DS-MON MIB changes be satisfactory? > > - Rename the *DS-MON aggregation* to something else to avoid confusion > with the *diffserv aggregates* Right, something like "DS-MON summary" since it summarizes data for a number of diffserv aggregates. > - Support the *diffserv aggregates*, maybe by mapping the rename *DS-MON > aggregates* into the *diffserv aggregates* This is easy. A diffserv aggregate is just all the traffic marked with the same DSCP on a given link in a given direction. (The formal definition is in the terminology section of RFC 2474.) So since DSMON is driven by DSCPs, you are already summing diffserv aggregates to create your aggregates/summaries. There's one subtlety here which is not yet in an RFC, the concept of an "ordered aggregate" where multiple PHBs within a PHB group are applied to the same traffic flow, requiring a packet ordering constraint. This is a case where summing the counters *does* make sense. draft-ietf-diffserv-new-terms-05.txt (-06.txt imminent) discusses this. > > If the answer is yes, we still need to hear the opinion of the DS-MON > MIB author. I am just looking at it from the perspective of the > implementation of DS-MON together with other RMON family protocols. Understood Regards Brian > > Regards, > > Dan > > > -----Original Message----- > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > Sent: Tuesday, November 06, 2001 2:16 PM > > To: Romascanu, Dan (Dan) > > Cc: ah_smith@pacbell.net; Harrie Hazewinkel; > > rmonmib@ietf.org; Diffserv > > Subject: Re: [Diffserv] RE: Differences between DSMON-MIB and > > DIFFSERV-MIB > > > > > > snipping... > > > > "Romascanu, Dan (Dan)" wrote: > > > > > ... > > > I would like to point to two separate issues here: > > > > > > - It seems to me that there might be cases when the > > aggregation concept > > > is two little or two much from a monitoring tool point of > > view. It might > > > be too little if the aggregation applies to a specific policy > > > administrative domain, and packets that are monitored at a certain > > > monitoring point are the result of them originating from > > such different > > > domains. It may be two much because in some real life situations an > > > operator may need (or may be forced to use because of the > > limitations of > > > his monitoring probe) a coarser set of code points values > > (like default > > > and 'all-but-default') > > > > But the point is that this form of aggregation is pretty much > > orthogonal to the diffserv architecture. It's meaningless, in terms > > of diffserv, to add together the statistics of separate traffic > > aggregates (yes, the word "aggregate" already has a very specific > > meaning in diffserv, and it is different from the usage in DSMON.) > > The only case where it might make sense is for PHB groups. > > The DSMON "aggregates" *in any case* need to be renamed, to avoid > > confusion with diffserv traffic aggregates. > > > > Frankly I don't see the point. Nobody expects to deploy real diffserv > > networks with more than a few traffic classes (i.e. DSCPs) active. > > In any case, the theoretical maximum (64) is a small number. Why not > > just monitor DSCPs? (I agree that an "everything else" bucket > > is useful, > > at least for presentation.) > > > > > - The other issue is that DiffServ MIB is designed to run > > in diffserv > > > routers. It makes assumptions about the agent understanding how such > > > routers work, and you need this understanding even in the read-only > > > mode. One cannot make such assumptions about all RMON probes. > > > > Correct, that is a valid point: a pure probe can't be expected to > > have full knowledge of the diffserv configuration. Equally, it > > can't measure everything, for example it can't count packet drops, > > which is one of the basic metrics of a diffserv traffic aggregate. > > But why can't it use the same concept of traffic aggregates as > > the DSMIB, and count a subset of the same things? > > > > ... > > > > > > > > > > yes, there is a 'fundamental' issue here. The issue is in > > my opinion the > > > difference between a MIB focused on device management, and a MIB > > > focusing on network level monitoring. According to my operational > > > experience, these two views are complementary, and are both needed. > > > > No disagreement there. But they can be complementary without > > being inconsistent. > > > > Brian > > -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 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://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Tue Nov 6 12:58:24 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24212 for ; Tue, 6 Nov 2001 12:58:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA09782 for diffserv-archive@odin.ietf.org; Tue, 6 Nov 2001 12:58: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 MAA08582; Tue, 6 Nov 2001 12:41: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 MAA08543 for ; Tue, 6 Nov 2001 12:40:50 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22767; Tue, 6 Nov 2001 12:40:48 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id fA6HeEr23649; Tue, 6 Nov 2001 09:40:14 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id fA6HeCs22436; Tue, 6 Nov 2001 09:40:12 -0800 (PST) Received: from PC2.cisco.com (sjc-vpn1-939.cisco.com [10.21.99.171]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id JAA02468; Tue, 6 Nov 2001 09:40:05 -0800 (PST) Message-Id: <4.3.2.7.2.20011106092252.01e98030@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 06 Nov 2001 09:38:07 -0800 To: From: Andy Bierman Subject: Re: [Diffserv] RE: Differences between DSMON-MIB and DIFFSERV-MIB Cc: "Harrie Hazewinkel" , , "Diffserv" In-Reply-To: References: <400290.1004999325@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 01:38 AM 11/6/2001 -0800, Andrew Smith wrote: >Harrie, > >The basic issue here is whether DSMON should invent a new concept >("aggregation group") for something that does not exist in the Diffserv >architecture or in any of the drafts that discuss management of Diffserv. It >seems wrong to do so if there is already an existing concept (a "data path") >that is a candidate for performing the necessary monitoring actions. Your >message, Harrie, goes into the details of how we might or might not re-use >existing objects but I'm trying to establish the general concept first. What if we thought of an aggregation group as aggregating "Counters" not "DSCPs". That's really what it is. From an RMON probe's POV, the DSCP value is just another observable attribute in the packet. I don't think the data flow through a forwarding device is relevant to RMON. An RMON probe (conceptually) is a device that observes all packets on an interface and collects high level statistics configured by an administrator. >"Data path" is not the same as "aggregation group" (neither is "PHB"). As >currently defined in DSMON, an aggregation group can be defined to include >traffic with assorted DSCPs totally orthogonally to the Diffserv treatment >that nodes might give those DSCPs: that's great - it's as as flexible as >anyone could want. But does it bare any relationship to the things that >network managers want to see? Andy asserts that it does, I would disagree. I >would argue that the things that people will want to train their DSMON >probes on are precisely the things that are a result of the Diffserv >configuration and that the manager (or the management tools, to be precise) >should not have to convert from one model used for configuration of the >network nodes into an orthogonal model used by the monitoring probes. That's >just unnecessary work. It's up to the administrator to configure which DSCPs are interesting to monitor, just like all the other observable packet attributes. Perhaps you are suggesting that a DSMON probe could get this configuration from a DS forwarding device? Which one? A probe can sit "on the wire" between (or near) several such devices. I agree automatic configuration is always nice to have, but it's not required in the first release of the MIB. >I'd also argue that, to turn Andy's example against him, DSMON should be to >the Diffserv MIB as RMON is to the Ethernet MIB or RMON2 is to IP MIB >statistics: xxxMON should be a tool to take MIB objects and "wrap them up" >with history samples, trending and traffic matrix mechanisms. An xxxMON >module should not go off on its own in defining new management models for >the xxx technology. I'd argue this is exactly what DSMON does. I took the existing RMON-2 features and extended them to do additional classification based on DSCP value. Application host and matrix, a TopN of protocol distribution, AL-matrix, etc. RMON only defines ways to aggregate its own statistics. I don't see how an administrator (as Dan pointed out, they already understand the concept of probe-gathered vs. device-gathered statistics) would confuse the purpose or semantic definitions in the DSMON-MIB with those in the DIFFSERV-MIB. >Until we can agree (or agree to disagree) on these fundamentals, there's no >point diving into the details. It shouldn't be that hard. You must have identified at least one to come up with your comments in the first place. >Andrew > Andy >-----Original Message----- >From: Harrie Hazewinkel [mailto:harrie@covalent.net] >Sent: Monday, November 05, 2001 10:29 PM >To: Brian E Carpenter; Romascanu, Dan (Dan) >Cc: Andrew Smith; rmonmib@ietf.org; Diffserv >Subject: Differences between DSMON-MIB and DIFFSERV-MIB > > >Hi, > >(Note I changed the subject) > >--On Monday, November 5, 2001 1:42 PM +0100 Brian E Carpenter > wrote: > > > Dan, > > > > "Romascanu, Dan (Dan)" wrote: > > ... > >> I think that the problem spaces of providing data for the protocol > >> management, and monitoring the network (by stand-alone or embedded > >> probes) are complementary sets of tools, which deserve each their > >> separate definition and MIB interface. > > > > That is why the diffserv MIB has two conformance levels, one for > > read-only (i.e. monitoring) and one for read-write (i.e. control). > > A priori, the diffserv MIB is what you need for complete monitoring > > of a diffserv router. > >IMHO, the two conformance levels are there to have a different >SNMP access which in perticular reflect the approach the >system gets configured. >The 'full compliance' makes it that a diffserv capable router >can be monitored and configured via SNMP. The 'read-only >compliance' is mainly to support toses diffserv capable routers >who do not do configuration via SNMP. It can indeed be used >for monitoring, but the system can be configured in other ways >than SNMP. > > > It certainly doesn't seem appropriate to > > construct a *different* virtual model of such a router for an RMON > > MIB; surely it should be a strict subset of the same model? > >The virtual model mainly creates the concept of the datapath and >its elements. Those datapaths and elements cause in a diffserv >capable router traffic treatment. Different treatment can be >given based on the way the traffic is filtered and goes through >the datapath elements. Traffic behavior can be altered/shaped >or just treated differently. > >RMON is just a probe sitting on the sideline looking at the >traffic. It does not do any traffic treatment or shaping. >Traffic streams are NOT altered. > > > Otherwise life will become very confusing for operational staff. > >This is maybe already caused by the existance of RMON. Like D.Romascanu >said; "The obvious example is that the RMON and RMON-2 MIBs from >RMON probes complement from a network operator point of view the >information that can be obtained by looking at MIB-II, Bridge MIB >and IP forwarding MIBs in the bridges and routers deployed in the >network." > >I beleive the models are different where DSMON-MIB is monitoring >a particular traffic pattern and the DIFFSERV-MIB is monitoring a >perticular datapath configuration (and if 'full compliant' also >configuration itself. > >A big difference is the end of a datapath configuration >is the router core. In DSMON-MIB monitoring is no router >core. Also the DIFFSERV-MIB has for each count action >a next datapath element which is not in the DSMON-MIB. > > > > > The diffserv MIB deconstructs the path for each traffic aggregate > > and maintains some counters deep down in the deconstructed elements > > of the path. You are going the opposite way in the DSMON MIB - you > > are synthesizing something that doesn't exist (the aggregation group), > > which may or may not map to the paths defined in the diffserv MIB. > >Indeed, this is a difference. > > > In practice I think that will force implementors to do extra work, > > and cost extra overhead. It would indeed seem more logical for > > the DSMON MIB to collect up the counters already defined by the > > diffserv MIB, but that means a different approach to aggregating > > the counters. > >I am not sure if I follow it completely; correct me if I am wrong. >What you are saying is that the counter which are combined with a >particular DSCP counting from as well the DSMON-MIB and the DIFFSERV-MIB >can be the same?? But where does the traffic gets delivered in case >of an DSMON situation with the DIFFSERV-MIB?? >The value zeroDotZero for a next pointer does not seem to be appropriate >if you just have a normal RMON probe. > >I beleive this will force also extra work to configure the system. >Maybe one will not have the same DSMON monitoring (filtering) as >one has traffic treatment. > >That would mean: > >A traffic filter that feeds the various counters to do traffic >monitoring. The next pointer of all the count actions need to be >the same from where a complete new set of traffic filters is >created in order to have a traffic treatment one would like to >have. Maybe a farfetched idea, but still. Looks possible to me. > >However, when the DSMON-MIB is just in a probe, I am not sure >how to use the filters and more precise the count actions of the >DIFFSERV-MIB need to be set up than. What is the next pointer >of the count actions?? These count actions (datapath elements) >are not in the path of the traffic and neither can the traffic >be delivered at the router core as the DIFFSERV-MIB does. > >Maybe the case where an RMON probe in the DIFFSERV capable router resides >is a border case. But this is (I beleive) not to be expected the >case always. > > >Hope this all makes sense, (if not say so) > >Harrie > > > > > > Brian > > > >> > -----Original Message----- > >> > From: Andrew Smith [mailto:ah_smith@acm.org] > >> > Sent: Friday, November 02, 2001 11:12 PM > >> > To: rmonmib@ietf.org > >> > Cc: Diffserv > >> > Subject: [Diffserv] RE: DEFVAL in dsmonAggGroupIndex - SMIC error > >> > > >> > > >> > I've (still) got serious problems with this MIB, its > >> > relationship to the > >> > DiffServ MIB and the "aggregation group" concept. Haven't > >> > spoken up recently > >> > because I thought others would taken care of it by now. > >> > > >> > 1. You're duplicating functionality from the DiffServ MIB > >> > here. If that's > >> > fine with IESG then OK but it seems like a bad idea to me. People have > >> > argued on the RMON list before that DSMON is meant for > >> > probes, not switches > >> > but I believe a large proportion of DSMON implementations > >> > will end up inside > >> > switches with consequent waste of resources. I do not think > >> > there is a good > >> > case to be made for optimising this MIB for the "standalone > >> > probe" case. > >> > > >> > 2. You're inventing a new grouping concept with its own > >> > number space for > >> > something that the DiffServ conceptual management model, MIB > >> > and PIB do > >> > using their "data path" concept and which they have their own > >> > numberspace > >> > for. You should re-use that concept or else persuade DiffServ > >> > to use your > >> > concept but there is no excuse for having duplicate > >> > mechanisms in MIBs that > >> > are being developed/published at roughly the same time by > >> > IETF (is this due > >> > to OPS and TSV ADs not talking to each other enough? No > >> > apologies for adding > >> > Diffserv WG to this message). > >> > > >> > 3. You're overloading your dsmonAggGroupIndex numberspace with the > >> > "convenience functionality" of letting the group index equal the DSCP. > >> > There's no need for this and it cannot be useful unless you have some > >> > mandated behaviour that relies on this 1:1 mapping e.g. a > >> > default setting > >> > for the table on power-up or initial state. Leaving it as an > >> > option (see > >> > "SHOULD" below) makes it useless in a multi-vendor world. > >> > > >> > Specifics: > >> > > >> > 4. "dsmonAggGroupIndex OBJECT-TYPE > >> > SYNTAX DsmonAggGroupIndex > >> > MAX-ACCESS read-write > >> > STATUS current > >> > DESCRIPTION > >> > "The aggregation group which contains this DSCP > >> > value. Upon > >> > creation of a new sub-tree (set of 64 entries > >> > with the same > >> > dsmonAggControlIndex value) in this table, the > >> > agent SHOULD > >> > initialize all related instances of this object > >> > to the value > >> > zero. > >> > > >> > This object MUST NOT be modified if the > >> > dsmonAggControlLocked object is equal to 'true'." > >> > DEFVAL { 0 }" > >> > > >> > a) This description does not make sense (to me): > >> > dsmonAggControlIndex does > >> > not appear in this table so how is creation of a new sub-tree > >> > related to > >> > entries in this table? Please clarify this wording. Or is this a typo? > >> > b) What's the point of the "SHOULD" directive here? > >> > c) Define "related instances" more precisely. > >> > d) You can't say that a read-write variable "MUST NOT" be modified (by > >> > whom?) - you can define that if you try to do so then the > >> > operation will > >> > pass/fail etc. but you can't use a MIB to enforce what a > >> > manager can/cannot > >> > attempt (you might as well add "please" :-)). > >> > e) I don't think you can rely on "0" as a special value of > >> > DSCP here - use > >> > something like -1 if you really need to use a DEFVAL. > >> > > >> > That's all on this particular issue, I guess I ought to read > >> > the rest of the > >> > MIB now ... > >> > > >> > Andrew Smith > >> > > >> > > >> > -----Original Message----- > >> > From: owner-mibs@ops.ietf.org > >> > [mailto:owner-mibs@ops.ietf.org]On Behalf > >> > Of Andy Bierman > >> > Sent: Friday, November 02, 2001 8:31 AM > >> > To: Harrie Hazewinkel > >> > Cc: bwijnen@lucent.com; rmonmib@ietf.org; mibs@ops.ietf.org > >> > Subject: DEFVAL in dsmonAggGroupIndex - SMIC error > >> > > >> > > >> > At 06:33 PM 11/1/2001 -0800, Harrie Hazewinkel wrote: > >> > > >> > > >> > > >> > Now that I looked at this some more, I think the SMIC is wrong. > >> > This DEFVAL should not be a syntax error. > >> > > >> > The dsmonAggGroupIndex object itself is read-write object > >> > and not an INDEX in the table its defined in. The DEFVAL clause > >> > indicates that the initial aggGroup value an agent should set for each > >> > DSCP mapping. All DSCPs in the same group -- perfectly valid concept, > >> > perfectly valid SMIv2 syntax. > >> > > >> > However, the dsmonAggGroupIndex object is also declared as one of the > >> > INDEX components in the dsmonAggGroupEntry. SMIC is complaining about > >> > the DEFVAL that is only meant to apply to original OBJECT-TYPE macro, > >> > not a DEFVAL for the INDEX -- that doesn't even make sense. > >> > > >> > > --On Thursday, November 1, 2001 7:40 AM -0800 Andy Bierman > >> > > wrote: > >> > > > >> > >> At 01:39 PM 11/1/2001 +0100, Wijnen, Bert (Bert) wrote: > >> > >>> OK, 2 issues basically came out after your approval. > >> > >>> > >> > >>> - SMICng complains about having a DEFVAL for dsmonAggGroupIndex > >> > >>> since this object is used as an index object as well. Andy > >> > >>> did put it in since you insisted. I am discussing the matter > >> > >>> with the SMIv2 doc editors > >> > >>> - Frank Strauss (I asked him to check to see if his compiler > >> > >>> would also complain about that indexing thing, which it did not, > >> > >>> but then Juergen has now added a lvl 4 warning about it). > >> > >>> Frank brought out that the OID could become too long based on > >> > >>> some index definitions. So Andy has posted a new rev to address > >> > >>> that > >> > > >> > > .... > >> > > >> > > >> > >> The rules are too strict! > >> > > > >> > > I agree here. When a default value is written in a description > >> > > it seems to be allowe, but when a DEFVAL is used it is > >> > > not because of compilers complain. That sounds > >> > > contradictionary to me. The DEFVAL-cluase is > >> > > (IMHO) there to support more formally the > >> > > semantics of the object, but it may neither > >> > > create a conflict with the semantics provided in > >> > > the description-clause. > >> > > > >> > > > >> > > Maybe far fetched, but I can envision such a scenario. > >> > > Someone can create some object in X-MIB with > >> > > a read-create ACCESS and a DEFVAL seems appropriate. > >> > > Later someone else in Y-MIB uses that object in an > >> > > index, because it wants to extend information for > >> > > that perticular object only. > >> > > The only option (to keep compilers happy) will then > >> > > be create/duplicate the object and provide the same > >> > > semantics without DEFVAL. > >> > > > >> > > Hmm.... > >> > > >> > Someone already did that -- in DSMON-MIB ! > >> > > >> > > >> > > >> > > >> > > My thoughts about it, > >> > > > >> > > > >> > > Harrie Hazewinkel > >> > > >> > Andy > >> > > >> > > >> > > >> > > >> > _______________________________________________ > >> > diffserv mailing list > >> > diffserv@ietf.org > >> > https://www1.ietf.org/mailman/listinfo/diffserv > >> > Archive: > >> > http://www2.ietf.org/mail-archive/working-groups/diffserv/curr > >> ent/maillist.html > >> > >> _______________________________________________ > >> diffserv mailing list > >> diffserv@ietf.org > >> https://www1.ietf.org/mailman/listinfo/diffserv > >> Archive: > >> http://www2.ietf.org/mail-archive/working-groups/diffserv/current/mailli > >> st.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 > > > > > > _______________________________________________ > > RMONMIB mailing list > > RMONMIB@ietf.org > > http://www1.ietf.org/mailman/listinfo/rmonmib > > > > > > > > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >https://www1.ietf.org/mailman/listinfo/diffserv >Archive: >http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Tue Nov 6 13:27:19 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25826 for ; Tue, 6 Nov 2001 13:27:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA11558 for diffserv-archive@odin.ietf.org; Tue, 6 Nov 2001 13:27:20 -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 NAA10776; Tue, 6 Nov 2001 13:13: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 NAA10705 for ; Tue, 6 Nov 2001 13:12:58 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24998; Tue, 6 Nov 2001 13:12:55 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fA6ICKB09603; Tue, 6 Nov 2001 10:12:20 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id fA6ICBE24480; Tue, 6 Nov 2001 10:12:11 -0800 (PST) Received: from PC2.cisco.com (sjc-vpn1-939.cisco.com [10.21.99.171]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id KAA29871; Tue, 6 Nov 2001 10:12:10 -0800 (PST) Message-Id: <4.3.2.7.2.20011106094808.00b7a830@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 06 Nov 2001 10:10:11 -0800 To: Brian E Carpenter From: Andy Bierman Subject: Re: [Diffserv] RE: Differences between DSMON-MIB and DIFFSERV-MIB Cc: "Romascanu, Dan (Dan)" , ah_smith@pacbell.net, Harrie Hazewinkel , rmonmib@ietf.org, Diffserv In-Reply-To: <3BE7D491.7CBCC905@hursley.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 01:16 PM 11/6/2001 +0100, Brian E Carpenter wrote: >snipping... > >"Romascanu, Dan (Dan)" wrote: > > >... > > I would like to point to two separate issues here: > > > > - It seems to me that there might be cases when the aggregation concept > > is two little or two much from a monitoring tool point of view. It might > > be too little if the aggregation applies to a specific policy > > administrative domain, and packets that are monitored at a certain > > monitoring point are the result of them originating from such different > > domains. It may be two much because in some real life situations an > > operator may need (or may be forced to use because of the limitations of > > his monitoring probe) a coarser set of code points values (like default > > and 'all-but-default') > >But the point is that this form of aggregation is pretty much >orthogonal to the diffserv architecture. It's meaningless, in terms >of diffserv, to add together the statistics of separate traffic >aggregates (yes, the word "aggregate" already has a very specific >meaning in diffserv, and it is different from the usage in DSMON.) >The only case where it might make sense is for PHB groups. >The DSMON "aggregates" *in any case* need to be renamed, to avoid >confusion with diffserv traffic aggregates. I agree the aggProfile groupings are only as meaningful as the administrator makes them. Whether the DSCP values grouped together should be, in terms of the actual DIFFSERV config, is totally unknown to the probe. DSCPs are just more numbers to a probe. >Frankly I don't see the point. Nobody expects to deploy real diffserv >networks with more than a few traffic classes (i.e. DSCPs) active. >In any case, the theoretical maximum (64) is a small number. Why not >just monitor DSCPs? (I agree that an "everything else" bucket is useful, >at least for presentation.) Actually, this is how I wanted the MIB to be, and how I originally wrote it. I would love it if aggregation groups were tossed and a simple Dscp INDEX was used instead. This is probably how all SW implementations will work anyway. I believe it was Andrew who originally said we needed to aggregate DSCP counters and other RMONMIB WG members agreed. An existence proof can be found with VLAN counters in switches, especially for 'backplane' counters. Let's say you pick an arbitrary small number of VLANs (or DSCPs) that can actually be counted at line rate at the same time, because every counter cost HW real estate (and therefore money). It's relatively easy for an administrator to figure out which VLANs (or DSCPs) need attention when debugging network problems, and direct the switch to collect statistics on just those values. > > - The other issue is that DiffServ MIB is designed to run in diffserv > > routers. It makes assumptions about the agent understanding how such > > routers work, and you need this understanding even in the read-only > > mode. One cannot make such assumptions about all RMON probes. > >Correct, that is a valid point: a pure probe can't be expected to >have full knowledge of the diffserv configuration. Equally, it >can't measure everything, for example it can't count packet drops, >which is one of the basic metrics of a diffserv traffic aggregate. >But why can't it use the same concept of traffic aggregates as >the DSMIB, and count a subset of the same things? RMON probes just listen on interfaces, many times attached to a hub or switch 'SPAN' (or mirror) port. They cannot tell if another device somewhere on the network dropped a packet. An administrator needs to get drop counts from the device that did the dropping. >... > > > > > > > yes, there is a 'fundamental' issue here. The issue is in my opinion the > > difference between a MIB focused on device management, and a MIB > > focusing on network level monitoring. According to my operational > > experience, these two views are complementary, and are both needed. > >No disagreement there. But they can be complementary without >being inconsistent. We don't really agree they are inconsistent. I don't think a model of the internal data path of a forwarding device is inconsistent with the remote monitoring model for counter aggregation. For the sake of argument, what changes to the DSMON-MIB do you think are needed to be complementary and consistent? > Brian Andy _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Tue Nov 6 14:09:10 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27696 for ; Tue, 6 Nov 2001 14:09:09 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA14350 for diffserv-archive@odin.ietf.org; Tue, 6 Nov 2001 14:09:12 -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 NAA13065; Tue, 6 Nov 2001 13:53: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 NAA13000 for ; Tue, 6 Nov 2001 13:53:01 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26808; Tue, 6 Nov 2001 13:52:55 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id fA6Io7x02147; Tue, 6 Nov 2001 10:50:09 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id fA6Io4I02029; Tue, 6 Nov 2001 10:50:05 -0800 (PST) Received: from PC2.cisco.com (sjc-vpn1-939.cisco.com [10.21.99.171]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id KAA01516; Tue, 6 Nov 2001 10:50:02 -0800 (PST) Message-Id: <4.3.2.7.2.20011106104255.01dd5a68@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 06 Nov 2001 10:48:02 -0800 To: "Romascanu, Dan (Dan)" From: Andy Bierman Subject: RE: [Diffserv] RE: Differences between DSMON-MIB and DIFFSERV-MIB Cc: "Brian E Carpenter" , , "Harrie Hazewinkel" , , "Diffserv" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org At 02:46 PM 11/6/2001 +0200, Romascanu, Dan (Dan) wrote: >So, would the following DS-MON MIB changes be satisfactory? > >- Rename the *DS-MON aggregation* to something else to avoid confusion >with the *diffserv aggregates* >- Support the *diffserv aggregates*, maybe by mapping the rename *DS-MON >aggregates* into the *diffserv aggregates* > >If the answer is yes, we still need to hear the opinion of the DS-MON >MIB author. I am just looking at it from the perspective of the >implementation of DS-MON together with other RMON family protocols. I understand edit #1, but not #2. Any clarifications are fine with me. I will spin the draft before the I-D cutoff, and rename things to make it clear the agent is aggregating counters, totally unrelated to the concept of a diffserv aggregate. >Regards, > >Dan Andy > > -----Original Message----- > > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > > Sent: Tuesday, November 06, 2001 2:16 PM > > To: Romascanu, Dan (Dan) > > Cc: ah_smith@pacbell.net; Harrie Hazewinkel; > > rmonmib@ietf.org; Diffserv > > Subject: Re: [Diffserv] RE: Differences between DSMON-MIB and > > DIFFSERV-MIB > > > > > > snipping... > > > > "Romascanu, Dan (Dan)" wrote: > > > > > ... > > > I would like to point to two separate issues here: > > > > > > - It seems to me that there might be cases when the > > aggregation concept > > > is two little or two much from a monitoring tool point of > > view. It might > > > be too little if the aggregation applies to a specific policy > > > administrative domain, and packets that are monitored at a certain > > > monitoring point are the result of them originating from > > such different > > > domains. It may be two much because in some real life situations an > > > operator may need (or may be forced to use because of the > > limitations of > > > his monitoring probe) a coarser set of code points values > > (like default > > > and 'all-but-default') > > > > But the point is that this form of aggregation is pretty much > > orthogonal to the diffserv architecture. It's meaningless, in terms > > of diffserv, to add together the statistics of separate traffic > > aggregates (yes, the word "aggregate" already has a very specific > > meaning in diffserv, and it is different from the usage in DSMON.) > > The only case where it might make sense is for PHB groups. > > The DSMON "aggregates" *in any case* need to be renamed, to avoid > > confusion with diffserv traffic aggregates. > > > > Frankly I don't see the point. Nobody expects to deploy real diffserv > > networks with more than a few traffic classes (i.e. DSCPs) active. > > In any case, the theoretical maximum (64) is a small number. Why not > > just monitor DSCPs? (I agree that an "everything else" bucket > > is useful, > > at least for presentation.) > > > > > - The other issue is that DiffServ MIB is designed to run > > in diffserv > > > routers. It makes assumptions about the agent understanding how such > > > routers work, and you need this understanding even in the read-only > > > mode. One cannot make such assumptions about all RMON probes. > > > > Correct, that is a valid point: a pure probe can't be expected to > > have full knowledge of the diffserv configuration. Equally, it > > can't measure everything, for example it can't count packet drops, > > which is one of the basic metrics of a diffserv traffic aggregate. > > But why can't it use the same concept of traffic aggregates as > > the DSMIB, and count a subset of the same things? > > > > ... > > > > > > > > > > yes, there is a 'fundamental' issue here. The issue is in > > my opinion the > > > difference between a MIB focused on device management, and a MIB > > > focusing on network level monitoring. According to my operational > > > experience, these two views are complementary, and are both needed. > > > > No disagreement there. But they can be complementary without > > being inconsistent. > > > > Brian > > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >https://www1.ietf.org/mailman/listinfo/diffserv >Archive: >http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Tue Nov 6 14:38:27 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29370 for ; Tue, 6 Nov 2001 14:38:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA15842 for diffserv-archive@odin.ietf.org; Tue, 6 Nov 2001 14:38: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 OAA14855; Tue, 6 Nov 2001 14:25:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14790 for ; Tue, 6 Nov 2001 14:25:17 -0500 (EST) Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28555; Tue, 6 Nov 2001 14:25:14 -0500 (EST) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id fA6JOIP25811; Tue, 6 Nov 2001 14:24:18 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h149-49-38-91.avaya.com [149.49.38.91]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id fA6JOHa25768; Tue, 6 Nov 2001 14:24:17 -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] RE: Differences between DSMON-MIB and DIFFSERV-MIB Date: Tue, 6 Nov 2001 21:25:08 +0200 Message-ID: Thread-Topic: [Diffserv] RE: Differences between DSMON-MIB and DIFFSERV-MIB Thread-Index: AcFm9ClgDLO+PCLpSCSfsT0KI2qrtgAA/+QA From: "Romascanu, Dan (Dan)" To: "Andy Bierman" Cc: "Brian E Carpenter" , , "Harrie Hazewinkel" , , "Diffserv" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA14793 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 > >So, would the following DS-MON MIB changes be satisfactory? > > > >- Rename the *DS-MON aggregation* to something else to avoid > confusion > >with the *diffserv aggregates* > >- Support the *diffserv aggregates*, maybe by mapping the > rename *DS-MON > >aggregates* into the *diffserv aggregates* > > > >If the answer is yes, we still need to hear the opinion of the DS-MON > >MIB author. I am just looking at it from the perspective of the > >implementation of DS-MON together with other RMON family protocols. > > > I understand edit #1, but not #2. > Any clarifications are fine with me. > I will spin the draft before the I-D cutoff, and rename things to > make it clear the agent is aggregating counters, totally unrelated to > the concept of a diffserv aggregate. > What I originally had in mind at #2 was somehow importing the path concept from the DiffServ MIB and providing a mapping table. I was probably superficial, a more attentive analysis seems to show that there is no one-to-one relations, at least when different devices run the probe and the router, and this connection needs to be left for the application. I would say that Andy's proposed edits at #1 are probably enough on what the DS-MON MIB is concerned. Regards. Dan _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Wed Nov 7 07:26:58 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02234 for ; Wed, 7 Nov 2001 07:26:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA15477 for diffserv-archive@odin.ietf.org; Wed, 7 Nov 2001 07:27: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 HAA14770; Wed, 7 Nov 2001 07:05:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA14673 for ; Wed, 7 Nov 2001 07:05:01 -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 HAA01268; Wed, 7 Nov 2001 07:04:57 -0500 (EST) Message-Id: <200111071204.HAA01268@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: diffserv@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 07 Nov 2001 07:04:57 -0500 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-new-terms-06.txt Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Differentiated Services Working Group of the IETF. Title : New Terminology for Diffserv Author(s) : D. Grossman Filename : draft-ietf-diffserv-new-terms-06.txt Pages : 9 Date : 06-Nov-01 This memo captures Diffserv working group agreements concerning new and improved terminology, and also provides minor technical clarifications. It is intended to update RFC 2474, RFC 2475 and RFC 2597. When RFCs 2474 and 2597 advance on the standards track, and RFC 2475 is updated, it is intended that the revisions in this memo will be incorporated, and that this memo will be obsoleted by the new RFCs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-new-terms-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-diffserv-new-terms-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-diffserv-new-terms-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011106142711.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-new-terms-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-new-terms-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011106142711.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Wed Nov 7 09:49:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09252 for ; Wed, 7 Nov 2001 09:49:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA19247 for diffserv-archive@odin.ietf.org; Wed, 7 Nov 2001 09:49:18 -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 JAA18468; Wed, 7 Nov 2001 09:30:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA18437 for ; Wed, 7 Nov 2001 09:30:41 -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 JAA08136 for ; Wed, 7 Nov 2001 09:30:36 -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 PAA17276; Wed, 7 Nov 2001 15:29:54 +0100 Received: from dhcp22-51.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA57570 from ; Wed, 7 Nov 2001 15:29:49 +0100 Message-Id: <3BE942FD.25B3B8E3@hursley.ibm.com> Date: Wed, 07 Nov 2001 15:19:41 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Diff Serv Cc: Kathleen Nichols Content-Type: multipart/mixed; boundary="------------9769E1A630B0ABC3D05B818B" Subject: [Diffserv] Informal WG last call for draft-ietf-diffserv-new-terms-06.txt Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. --------------9769E1A630B0ABC3D05B818B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit It is proposed to forward draft-ietf-diffserv-new-terms-06.txt for publication as an Informational RFC. This is an informal working group last call - please make any last comments on this document by Wednesday, November 21. N.B. This is an "informal" call because this is not a standards track document. Nevertheless, the clarification in Section 7 does refer to standards track issues. Brian Carpenter Kathie Nichols diffserv co-chairs -------- Original Message -------- Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-new-terms-06.txt Date: Wed, 07 Nov 2001 07:04:57 -0500 From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org To: IETF-Announce: ; CC: diffserv@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Differentiated Services Working Group of the IETF. Title : New Terminology for Diffserv Author(s) : D. Grossman Filename : draft-ietf-diffserv-new-terms-06.txt Pages : 9 Date : 06-Nov-01 This memo captures Diffserv working group agreements concerning new and improved terminology, and also provides minor technical clarifications. It is intended to update RFC 2474, RFC 2475 and RFC 2597. When RFCs 2474 and 2597 advance on the standards track, and RFC 2475 is updated, it is intended that the revisions in this memo will be incorporated, and that this memo will be obsoleted by the new RFCs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-new-terms-06.txt --------------9769E1A630B0ABC3D05B818B Content-Type: Message/External-body; name="draft-ietf-diffserv-new-terms-06.txt" Content-Disposition: inline; filename="draft-ietf-diffserv-new-terms-06.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <20011106142711.I-D@ietf.org> --------------9769E1A630B0ABC3D05B818B-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Wed Nov 7 10:34:19 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11956 for ; Wed, 7 Nov 2001 10:34:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA20979 for diffserv-archive@odin.ietf.org; Wed, 7 Nov 2001 10:34:22 -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 KAA20043; Wed, 7 Nov 2001 10:19: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 KAA20012 for ; Wed, 7 Nov 2001 10:19:11 -0500 (EST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10991 for ; Wed, 7 Nov 2001 10:19:08 -0500 (EST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id IAA24361 for ; Wed, 7 Nov 2001 08:19:09 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id IAA28627 for ; Wed, 7 Nov 2001 08:19:08 -0700 (MST)] Received: from dma.isg.mot.com (nrlab-08.dma.isg.mot.com [150.21.50.46]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id KAA14926 for ; Wed, 7 Nov 2001 10:19:06 -0500 (EST) Message-Id: <200111071519.KAA14926@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: diffserv@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 07 Nov 2001 10:19:06 -0500 From: Dan Grossman Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-new-terms-06.txt Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org As you have seen in your mailbox, a new revision of the new terms draft has been posted. The changes were clarfications requested by the chairs. Specifically, text was added to describe the relationship between SLS and service provisioning policy, and to better explain that RFC 1349 is obsoleted by RFC 2474. One or two words were also changed in the abstract, and a minor error there was corrected. There is also a minor issue that the chairs will raise with the IESG. During the first round of discussions on RFC 1349, it was pointed out that TOS bit processing is required in RFC 1812. As a result, by obsoleting TOS processing in RFC 791 and RFC 1349, RFC 2474 also implicitly obsoletes that part of RFC 1812. However, there has been no explicit IESG action to that effect. Dan _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Wed Nov 7 20:56:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27939 for ; Wed, 7 Nov 2001 20:56:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA07218 for diffserv-archive@odin.ietf.org; Wed, 7 Nov 2001 20:56:45 -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 UAA06440; Wed, 7 Nov 2001 20:30:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA06403 for ; Wed, 7 Nov 2001 20:30:48 -0500 (EST) Received: from robin.mail.pas.earthlink.net (robin.mail.pas.earthlink.net [207.217.120.65]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27637; Wed, 7 Nov 2001 20:30:45 -0500 (EST) Received: from user-1120fam.dsl.mindspring.com ([66.32.61.86] helo=ANDREWHOME) by robin.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 161e1m-00032J-00; Wed, 07 Nov 2001 17:30:46 -0800 From: "Andrew Smith" To: "Romascanu, Dan \(Dan\)" Cc: , "Diffserv" Subject: RE: [Diffserv] RE: Differences between DSMON-MIB and DIFFSERV-MIB Date: Wed, 7 Nov 2001 17:54:07 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Dan, That (#2) was roughly what I had in mind also. To take the two implementation cases separately: 1. Probe implemented standalone: no reason why the probe could not set up "datapaths" for the sole purpose of monitoring traffic. The "front-end" of the DSMON MIB could very well use the current Diffserv MIB. There is the benefit of commonality of setup by managers at the expense of additional complexity when compared to a dedicated MIB (that's nearly always true). So I believe that your concern about deciding on a mapping should be easily dealt with. 2. Probe implemented inside Diffserv switch/router: front-end of the DSMON MIB would beenfit from using the same MIB as the switch/router functions. Reduced complexity when compared to an additional DSMON-specific frint-end; same benefits as #1. Based on this analysis, I think the RMON WG should look seriously at what products its members intend to build and evaluate the tradeoffs above. I'm not intending to build any products using this MIB so I don't have a leg to stand on here .... at this point I'll shut up and let others argue this further if they want to. Andrew Smith -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Tuesday, November 06, 2001 11:25 AM To: Andy Bierman Cc: Brian E Carpenter; ah_smith@pacbell.net; Harrie Hazewinkel; rmonmib@ietf.org; Diffserv Subject: RE: [Diffserv] RE: Differences between DSMON-MIB and DIFFSERV-MIB > >So, would the following DS-MON MIB changes be satisfactory? > > > >- Rename the *DS-MON aggregation* to something else to avoid > confusion > >with the *diffserv aggregates* > >- Support the *diffserv aggregates*, maybe by mapping the > rename *DS-MON > >aggregates* into the *diffserv aggregates* > > > >If the answer is yes, we still need to hear the opinion of the DS-MON > >MIB author. I am just looking at it from the perspective of the > >implementation of DS-MON together with other RMON family protocols. > > > I understand edit #1, but not #2. > Any clarifications are fine with me. > I will spin the draft before the I-D cutoff, and rename things to > make it clear the agent is aggregating counters, totally unrelated to > the concept of a diffserv aggregate. > What I originally had in mind at #2 was somehow importing the path concept from the DiffServ MIB and providing a mapping table. I was probably superficial, a more attentive analysis seems to show that there is no one-to-one relations, at least when different devices run the probe and the router, and this connection needs to be left for the application. I would say that Andy's proposed edits at #1 are probably enough on what the DS-MON MIB is concerned. Regards. Dan _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Wed Nov 7 23:06:47 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02143 for ; Wed, 7 Nov 2001 23:06:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA10667 for diffserv-archive@odin.ietf.org; Wed, 7 Nov 2001 23:06:52 -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 WAA09774; Wed, 7 Nov 2001 22:44:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA09660 for ; Wed, 7 Nov 2001 22:40:00 -0500 (EST) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01673 for ; Wed, 7 Nov 2001 22:39:55 -0500 (EST) Received: from localhost (heard@localhost) by shell4.bayarea.net (8.9.3/8.9.3) with ESMTP id TAA04481; Wed, 7 Nov 2001 19:39:57 -0800 (envelope-from heard@pobox.com) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Wed, 7 Nov 2001 19:39:56 -0800 (PST) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: Diff Serv Subject: Re: [Diffserv] Informal WG last call for draft-ietf-diffserv-new-terms-06.txt In-Reply-To: <3BE942FD.25B3B8E3@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org On Wed, 7 Nov 2001, the diffserv co-chairs wrote: > It is proposed to forward draft-ietf-diffserv-new-terms-06.txt > for publication as an Informational RFC. This is an informal > working group last call - please make any last comments > on this document by Wednesday, November 21. > > N.B. This is an "informal" call because this is not a > standards track document. Nevertheless, the clarification > in Section 7 does refer to standards track issues. Please pardon a non-WG member for butting in, but I think I see a small problem. Section 7 says, in part: In addition, RFC 2474 obsoletes RFC 1349 by IESG action. For completeness, when RFC 2474 is updated, the sentence should read: "No attempt is made to maintain backwards compatibility with the "DTR/MBZ" or TOS bits of the IPv4 TOS octet, as defined in [RFC791] and [RFC1349]. This implies that TOS bit processing as described in sections 5.2.4.3 and 5.3.2 of [RFC1812] is also obsoleted by this memo. Also see [RFC2780]." The proposed update to RFC 2474 is not quite correct, because TOS processing is described in many places in RFC 1812 besides the cited sections 5.2.4.3 and 5.3.2. DiffServ also renders obsolete TOS processing as described in the (full-standard) Host Requirements documents (RFC 1122 and RFC 1123, particularly RFC 1122 Section 3.3.1.3). In view of these considerations, perhaps it would be better for the next-to-last sentence of the updated text to read: This implies that TOS bit processing as described in [RFC1122], [RFC1123], and [RFC1812] is also obsoleted by this memo. Mike _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Thu Nov 8 02:40:14 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20217 for ; Thu, 8 Nov 2001 02:40:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA24046 for diffserv-archive@odin.ietf.org; Thu, 8 Nov 2001 02:40: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 CAA23031; Thu, 8 Nov 2001 02:23: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 CAA22971 for ; Thu, 8 Nov 2001 02:23:10 -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 CAA19891; Thu, 8 Nov 2001 02:23:08 -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 CAA26856; Thu, 8 Nov 2001 02:21:54 -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 CAA26852; Thu, 8 Nov 2001 02:21:52 -0500 (EST) content-class: urn:content-classes:message Subject: RE: [Diffserv] RE: Differences between DSMON-MIB and DIFFSERV-MIB MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 8 Nov 2001 09:23:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Message-ID: Thread-Topic: [Diffserv] RE: Differences between DSMON-MIB and DIFFSERV-MIB Thread-Index: AcFn9Py/w9Gff3fARra6ACAyFv0mbQALNqkQ From: "Romascanu, Dan (Dan)" To: "Andrew Smith" Cc: , "Diffserv" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA22974 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 Andy, You probably need to explain me "MIB-wise" how the DS-MON MIB in a probe which is not a DiffServ router could use the data paths in the DiffServ MIB in case 1. I tried to go through this exercise, and could not solve the issue of one probe imports the data path information from the different DiffServ routers. This may be actually simpler for case 2, but here we differ because I do not think that the information provided by the DiffServ MIB is enough. I think that operators need the network DS-MON view, because it connects the DiffServ information on the wire to the network and application monitoring data, and aggregates it network-wise. This is different from the local information that can be obtained from each of the DiffServ routers. Regards, Dan > -----Original Message----- > From: Andrew Smith [mailto:ah_smith@acm.org] > Sent: Thursday, November 08, 2001 3:54 AM > To: Romascanu, Dan (Dan) > Cc: rmonmib@ietf.org; Diffserv > Subject: RE: [Diffserv] RE: Differences between DSMON-MIB and > DIFFSERV-MIB > > > Dan, > > That (#2) was roughly what I had in mind also. To take the two > implementation cases separately: > > 1. Probe implemented standalone: no reason why the probe > could not set up > "datapaths" for the sole purpose of monitoring traffic. The > "front-end" of > the DSMON MIB could very well use the current Diffserv MIB. > There is the > benefit of commonality of setup by managers at the expense of > additional > complexity when compared to a dedicated MIB (that's nearly > always true). So > I believe that your concern about deciding on a mapping > should be easily > dealt with. > > 2. Probe implemented inside Diffserv switch/router: front-end > of the DSMON > MIB would beenfit from using the same MIB as the > switch/router functions. > Reduced complexity when compared to an additional > DSMON-specific frint-end; > same benefits as #1. > > Based on this analysis, I think the RMON WG should look > seriously at what > products its members intend to build and evaluate the > tradeoffs above. I'm > not intending to build any products using this MIB so I don't > have a leg to > stand on here .... at this point I'll shut up and let others > argue this > further if they want to. > > Andrew Smith > > > > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Tuesday, November 06, 2001 11:25 AM > To: Andy Bierman > Cc: Brian E Carpenter; ah_smith@pacbell.net; Harrie Hazewinkel; > rmonmib@ietf.org; Diffserv > Subject: RE: [Diffserv] RE: Differences between DSMON-MIB and > DIFFSERV-MIB > > > > > >So, would the following DS-MON MIB changes be satisfactory? > > > > > >- Rename the *DS-MON aggregation* to something else to avoid > > confusion > > >with the *diffserv aggregates* > > >- Support the *diffserv aggregates*, maybe by mapping the > > rename *DS-MON > > >aggregates* into the *diffserv aggregates* > > > > > >If the answer is yes, we still need to hear the opinion of > the DS-MON > > >MIB author. I am just looking at it from the perspective of the > > >implementation of DS-MON together with other RMON family protocols. > > > > > > I understand edit #1, but not #2. > > Any clarifications are fine with me. > > I will spin the draft before the I-D cutoff, and rename things to > > make it clear the agent is aggregating counters, totally > unrelated to > > the concept of a diffserv aggregate. > > > What I originally had in mind at #2 was somehow importing the path > concept from the DiffServ MIB and providing a mapping table. I was > probably superficial, a more attentive analysis seems to show > that there > is no one-to-one relations, at least when different devices run the > probe and the router, and this connection needs to be left for the > application. I would say that Andy's proposed edits at #1 are probably > enough on what the DS-MON MIB is concerned. > > > Regards. > > Dan > > > _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Thu Nov 8 02:44:06 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20299 for ; Thu, 8 Nov 2001 02:44:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA24273 for diffserv-archive@odin.ietf.org; Thu, 8 Nov 2001 02: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 CAA23794; Thu, 8 Nov 2001 02:33:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA23766 for ; Thu, 8 Nov 2001 02:33:29 -0500 (EST) Received: from mailFA4.rediffmail.com (IDENT:qmailr@[202.54.124.149]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA20151 for ; Thu, 8 Nov 2001 02:33:27 -0500 (EST) Received: (qmail 30335 invoked by uid 510); 8 Nov 2001 07:33:53 -0000 Date: 8 Nov 2001 07:33:53 -0000 Message-ID: <20011108073353.30333.qmail@mailFA4.rediffmail.com> Received: from unknown (203.200.15.20) by rediffmail.com via HTTP; 08 Nov 2001 07:33:53 -0000 MIME-Version: 1.0 From: "Srinath . Pradeep" Reply-To: "Srinath . Pradeep" To: diffserv@ietf.org Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA23767 Subject: [Diffserv] Reg: Classifier 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 Hai *, In DiffServ how a packet is classified. Is it depending upon the packet header if yes then which field in the header to look for and how to preconfigure admission policy, on what basis. Plz help me out. Pradeep Srinath _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Thu Nov 8 03:00:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20495 for ; Thu, 8 Nov 2001 03:00:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA25233 for diffserv-archive@odin.ietf.org; Thu, 8 Nov 2001 03:01: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 CAA24578; Thu, 8 Nov 2001 02:49:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA24543 for ; Thu, 8 Nov 2001 02:49:20 -0500 (EST) Received: from robin.mail.pas.earthlink.net (robin.mail.pas.earthlink.net [207.217.120.65]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20375; Thu, 8 Nov 2001 02:49:18 -0500 (EST) Received: from user-1120fam.dsl.mindspring.com ([66.32.61.86] helo=ANDREWHOME) by robin.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 161jw6-0005qh-00; Wed, 07 Nov 2001 23:49:18 -0800 From: "Andrew Smith" To: "Romascanu, Dan \(Dan\)" Cc: , "Diffserv" Subject: RE: [Diffserv] RE: Differences between DSMON-MIB and DIFFSERV-MIB Date: Thu, 8 Nov 2001 00:12:39 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Dan, Not sure from where you get the "imports the data path information from the different DiffServ routers" idea: I'm just suggesting that a single management application is likely to be the source for both configuration info (for routers) and monitoring of that same configuration (by DSMON probes, standalone or embedded). I'm not suggesting that the instances of datapaths in the routers need to correspond to the instances datapaths in the probes. I am suggesting that the same set of "classifier elements" could be used in both. They may well feed into a different set of "counter elements": as Andy has pointed out, you may want to count in more, or less, detail in the probe than in the router, but it is likely that you'll want to classify in the same way. DSMON MIB currently defines its own MIB objects for classifiers, which is silly, and these are on DSCP only which is likely to be too limiting for anywhere except at the core of the network - the Diffserv architecture admits that the edges of a Diffserv domain are likely to be defined by multi-field classifiers so you are seriously limiting the use of DSMON if you do not acknowledge that fact (is this another result of attempting this work in a different WG? Sorry, broken record ....). Andrew -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Wednesday, November 07, 2001 11:23 PM To: Andrew Smith Cc: rmonmib@ietf.org; Diffserv Subject: RE: [Diffserv] RE: Differences between DSMON-MIB and DIFFSERV-MIB Andy, You probably need to explain me "MIB-wise" how the DS-MON MIB in a probe which is not a DiffServ router could use the data paths in the DiffServ MIB in case 1. I tried to go through this exercise, and could not solve the issue of one probe imports the data path information from the different DiffServ routers. This may be actually simpler for case 2, but here we differ because I do not think that the information provided by the DiffServ MIB is enough. I think that operators need the network DS-MON view, because it connects the DiffServ information on the wire to the network and application monitoring data, and aggregates it network-wise. This is different from the local information that can be obtained from each of the DiffServ routers. Regards, Dan > -----Original Message----- > From: Andrew Smith [mailto:ah_smith@acm.org] > Sent: Thursday, November 08, 2001 3:54 AM > To: Romascanu, Dan (Dan) > Cc: rmonmib@ietf.org; Diffserv > Subject: RE: [Diffserv] RE: Differences between DSMON-MIB and > DIFFSERV-MIB > > > Dan, > > That (#2) was roughly what I had in mind also. To take the two > implementation cases separately: > > 1. Probe implemented standalone: no reason why the probe > could not set up > "datapaths" for the sole purpose of monitoring traffic. The > "front-end" of > the DSMON MIB could very well use the current Diffserv MIB. > There is the > benefit of commonality of setup by managers at the expense of > additional > complexity when compared to a dedicated MIB (that's nearly > always true). So > I believe that your concern about deciding on a mapping > should be easily > dealt with. > > 2. Probe implemented inside Diffserv switch/router: front-end > of the DSMON > MIB would beenfit from using the same MIB as the > switch/router functions. > Reduced complexity when compared to an additional > DSMON-specific frint-end; > same benefits as #1. > > Based on this analysis, I think the RMON WG should look > seriously at what > products its members intend to build and evaluate the > tradeoffs above. I'm > not intending to build any products using this MIB so I don't > have a leg to > stand on here .... at this point I'll shut up and let others > argue this > further if they want to. > > Andrew Smith > > > > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Tuesday, November 06, 2001 11:25 AM > To: Andy Bierman > Cc: Brian E Carpenter; ah_smith@pacbell.net; Harrie Hazewinkel; > rmonmib@ietf.org; Diffserv > Subject: RE: [Diffserv] RE: Differences between DSMON-MIB and > DIFFSERV-MIB > > > > > >So, would the following DS-MON MIB changes be satisfactory? > > > > > >- Rename the *DS-MON aggregation* to something else to avoid > > confusion > > >with the *diffserv aggregates* > > >- Support the *diffserv aggregates*, maybe by mapping the > > rename *DS-MON > > >aggregates* into the *diffserv aggregates* > > > > > >If the answer is yes, we still need to hear the opinion of > the DS-MON > > >MIB author. I am just looking at it from the perspective of the > > >implementation of DS-MON together with other RMON family protocols. > > > > > > I understand edit #1, but not #2. > > Any clarifications are fine with me. > > I will spin the draft before the I-D cutoff, and rename things to > > make it clear the agent is aggregating counters, totally > unrelated to > > the concept of a diffserv aggregate. > > > What I originally had in mind at #2 was somehow importing the path > concept from the DiffServ MIB and providing a mapping table. I was > probably superficial, a more attentive analysis seems to show > that there > is no one-to-one relations, at least when different devices run the > probe and the router, and this connection needs to be left for the > application. I would say that Andy's proposed edits at #1 are probably > enough on what the DS-MON MIB is concerned. > > > Regards. > > Dan > > > _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Thu Nov 8 03:11:16 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20738 for ; Thu, 8 Nov 2001 03:11:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA26305 for diffserv-archive@odin.ietf.org; Thu, 8 Nov 2001 03:11:18 -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 DAA25479; Thu, 8 Nov 2001 03:01:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA25382 for ; Thu, 8 Nov 2001 03:01:22 -0500 (EST) Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20520; Thu, 8 Nov 2001 03:01:20 -0500 (EST) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id fA880MP05227; Thu, 8 Nov 2001 03:00:22 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h149-49-38-91.avaya.com [149.49.38.91]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id fA880LR05215; Thu, 8 Nov 2001 03:00:21 -0500 (EST) content-class: urn:content-classes:message Subject: RE: [Diffserv] RE: Differences between DSMON-MIB and DIFFSERV-MIB MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 8 Nov 2001 10:01:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Message-ID: Thread-Topic: [Diffserv] RE: Differences between DSMON-MIB and DIFFSERV-MIB Thread-Index: AcFoKd3S/AacY9MVQYCMGGJSs6UPZgAANqkg From: "Romascanu, Dan (Dan)" To: "Andrew Smith" Cc: , "Diffserv" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA25386 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 Andy, A network operator using DS-MON will probably use it in the context of the other RMON. This will allow to provide views that correspond to any combination of filters that a classifier may provide. The difference is that the information is based upon the information 'on-the-wire' and not on the specific implementation of a classifier in the device - which is local and may be limited to the capabilities of the specific device. Regards, Dan > I'm not suggesting that the instances of data paths in the > routers need to > correspond to the instances datapaths in the probes. I am > suggesting that > the same set of "classifier elements" could be used in both. > They may well > feed into a different set of "counter elements": as Andy has > pointed out, > you may want to count in more, or less, detail in the probe > than in the > router, but it is likely that you'll want to classify in the > same way. DSMON > MIB currently defines its own MIB objects for classifiers, > which is silly, > and these are on DSCP only which is likely to be too limiting > for anywhere > except at the core of the network - the Diffserv architecture > admits that > the edges of a Diffserv domain are likely to be defined by multi-field > classifiers so you are seriously limiting the use of DSMON if > you do not > acknowledge that fact (is this another result of attempting > this work in a > different WG? Sorry, broken record ....). >> _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Thu Nov 8 05:50:00 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22028 for ; Thu, 8 Nov 2001 05:50:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA00808 for diffserv-archive@odin.ietf.org; Thu, 8 Nov 2001 05:50:03 -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 FAA29891; Thu, 8 Nov 2001 05:29:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA29862 for ; Thu, 8 Nov 2001 05:29:30 -0500 (EST) Received: from mailweb18.rediffmail.com (IDENT:qmailr@[203.199.83.142]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA21855 for ; Thu, 8 Nov 2001 05:29:26 -0500 (EST) Received: (qmail 9539 invoked by uid 510); 8 Nov 2001 10:29:24 -0000 Date: 8 Nov 2001 10:29:24 -0000 Message-ID: <20011108102924.9538.qmail@mailweb18.rediffmail.com> Received: from unknown (203.200.15.20) by rediffmail.com via HTTP; 08 Nov 2001 10:29:24 -0000 MIME-Version: 1.0 From: "Srinath . Pradeep" Reply-To: "Srinath . Pradeep" To: diffserv@ietf.org Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA29863 Subject: [Diffserv] classifier Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 8bit hello *, In RFC 2745 (an architecture for diff serv) it is mentioned in 2.3.1 that classifiers must be configured by some management procedure in accordance with the appropriate TCA. Plz can any one ellaborate this. how this configuration is achieved pradeep srinath _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Thu Nov 8 12:13:50 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01082 for ; Thu, 8 Nov 2001 12:13:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA10145 for diffserv-archive@odin.ietf.org; Thu, 8 Nov 2001 12:13:53 -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 LAA08215; Thu, 8 Nov 2001 11:37: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 LAA08184 for ; Thu, 8 Nov 2001 11:37:13 -0500 (EST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00080 for ; Thu, 8 Nov 2001 11:37:10 -0500 (EST) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id JAA04744 for ; Thu, 8 Nov 2001 09:37:13 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id JAA17778 for ; Thu, 8 Nov 2001 09:27:41 -0700 (MST)] Received: from dma.isg.mot.com (nrlab-08.dma.isg.mot.com [150.21.50.46]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id LAA13059; Thu, 8 Nov 2001 11:37:00 -0500 (EST) Message-Id: <200111081637.LAA13059@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: "C. M. Heard" cc: Diff Serv Subject: Re: [Diffserv] Informal WG last call for draft-ietf-diffserv-new-terms-06.txt In-reply-to: Your message of "Wed, 07 Nov 2001 19:39:56 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 08 Nov 2001 11:36:58 -0500 From: Dan Grossman 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 > On Wed, 7 Nov 2001, the diffserv co-chairs wrote: > > > It is proposed to forward draft-ietf-diffserv-new-terms-06.txt > > for publication as an Informational RFC. This is an informal > > working group last call - please make any last comments > > on this document by Wednesday, November 21. > > > > N.B. This is an "informal" call because this is not a > > standards track document. Nevertheless, the clarification > > in Section 7 does refer to standards track issues. > > Please pardon a non-WG member for butting in, but I think I see a > small problem. Section 7 says, in part: > > In addition, RFC 2474 obsoletes RFC 1349 by IESG action. For > completeness, when RFC 2474 is updated, the sentence should read: > "No attempt is made to maintain backwards compatibility with the > "DTR/MBZ" or TOS bits of the IPv4 TOS octet, as defined in [RFC791] > and [RFC1349]. This implies that TOS bit processing as described > in sections 5.2.4.3 and 5.3.2 of [RFC1812] is also obsoleted by > this memo. Also see [RFC2780]." > > The proposed update to RFC 2474 is not quite correct, because TOS > processing is described in many places in RFC 1812 besides the > cited sections 5.2.4.3 and 5.3.2. DiffServ also renders obsolete TOS > processing as described in the (full-standard) Host Requirements > documents (RFC 1122 and RFC 1123, particularly RFC 1122 Section > 3.3.1.3). In view of these considerations, perhaps it would be > better for the next-to-last sentence of the updated text to read: > > This implies that TOS bit processing as described in [RFC1122], > [RFC1123], and [RFC1812] is also obsoleted by this memo. > Mike correctly points out that there are not one, but three big cans-o'-worms opened by this. For example, there's some error processing buried in RFC1812 concerning what a router's supposed to do when it doesn't have a route that matches the TOS specified in the packet. The Right Thing To Do, in my opinion, would be corrective surgery on RFC1122, RFC1123 and RFC1812. But Doing The Right Thing requires volunteers and probably opening more big cans-o'-worms than any of us have time or enthusiasm for. So, I'll suggest that we accept Mike's text, and when the chairs point out the issue to the IESG, that they also mention RFC1122 and RFC1123. > > > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html > _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Fri Nov 9 03:56:56 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04793 for ; Fri, 9 Nov 2001 03:56:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA08296 for diffserv-archive@odin.ietf.org; Fri, 9 Nov 2001 03:56:57 -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 DAA07360; Fri, 9 Nov 2001 03:36: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 DAA07329 for ; Fri, 9 Nov 2001 03:36:00 -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 DAA04441 for ; Fri, 9 Nov 2001 03:35:57 -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 JAA10062; Fri, 9 Nov 2001 09:35:28 +0100 Received: from dhcp22-51.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA46820 from ; Fri, 9 Nov 2001 09:35:27 +0100 Message-Id: <3BEB9549.CB075FFC@hursley.ibm.com> Date: Fri, 09 Nov 2001 09:35:21 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: "Srinath . Pradeep" Cc: diffserv@ietf.org Subject: Re: [Diffserv] classifier References: <20011108102924.9538.qmail@mailweb18.rediffmail.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 It's an "implementation detail". Today you would do it with the router's command line interface. Tomorrow you may do it with COPS, SNMCONF or any other method that a router vendor chooses to suppport. This sort of question would fit better on the diffserv-interest list. http://www.ietf.org/mailman/listinfo/diffserv-interest Brian "Srinath . Pradeep" wrote: > > hello *, > In RFC 2745 (an architecture for diff serv) > it is mentioned in 2.3.1 that classifiers must be > configured by some management procedure in accordance > with the appropriate TCA. > > Plz can any one ellaborate this. how this configuration > is achieved > > pradeep > srinath _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Fri Nov 9 07:04:05 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07093 for ; Fri, 9 Nov 2001 07:04:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA13679 for diffserv-archive@odin.ietf.org; Fri, 9 Nov 2001 07:04:06 -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 GAA12816; Fri, 9 Nov 2001 06:48:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA12791 for ; Fri, 9 Nov 2001 06:48:20 -0500 (EST) Received: from mailweb31.rediffmail.com (IDENT:qmailr@[203.199.83.151]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA06852 for ; Fri, 9 Nov 2001 06:48:18 -0500 (EST) Received: (qmail 23455 invoked by uid 510); 9 Nov 2001 11:48:32 -0000 Date: 9 Nov 2001 11:48:32 -0000 Message-ID: <20011109114832.23454.qmail@mailweb31.rediffmail.com> Received: from unknown (203.200.15.20) by rediffmail.com via HTTP; 09 Nov 2001 11:48:32 -0000 MIME-Version: 1.0 From: "Srinath . Pradeep" Reply-To: "Srinath . Pradeep" To: diffserv@ietf.org Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA12792 Subject: [Diffserv] Reg : Implementation of Classifier 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 Hai *, Where can i find the more information regarding the implementation of classifier. Classifier can be of 4 types : BA, MF, FreeForm and others like IEEE802.1P 802.1Q. This is not what is expected i want the implementation details, how r we going to achive the classification. Expect to get the reply soon. Thanks Pradeep Srinath _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Fri Nov 9 07:26:43 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07878 for ; Fri, 9 Nov 2001 07:26:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA14697 for diffserv-archive@odin.ietf.org; Fri, 9 Nov 2001 07:26:44 -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 HAA13899; Fri, 9 Nov 2001 07:09: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 HAA13876 for ; Fri, 9 Nov 2001 07:09: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 HAA07222; Fri, 9 Nov 2001 07:09:51 -0500 (EST) Message-Id: <200111091209.HAA07222@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: diffserv@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 09 Nov 2001 07:09:50 -0500 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-mib-16.txt Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Differentiated Services Working Group of the IETF. Title : Management Information Base for the Differentiated Services Architecture Author(s) : F. Baker, K. Chan, A. Smith Filename : draft-ietf-diffserv-mib-16.txt Pages : 127 Date : 08-Nov-01 This memo describes an SMIv2 MIB for a device implementing the Differentiated Services Architecture. It may be used both for monitoring and configuration of a router or switch capable of Differentiated Services functionality. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-mib-16.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-diffserv-mib-16.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-diffserv-mib-16.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011108144356.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-mib-16.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-mib-16.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011108144356.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Fri Nov 9 14:05:05 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23863 for ; Fri, 9 Nov 2001 14:05:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA26642 for diffserv-archive@odin.ietf.org; Fri, 9 Nov 2001 14:05: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 NAA25549; Fri, 9 Nov 2001 13:43:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25518 for ; Fri, 9 Nov 2001 13:43:02 -0500 (EST) Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22719 for ; Fri, 9 Nov 2001 13:42:59 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id fA9IfpS15830 for ; Fri, 9 Nov 2001 13:41:51 -0500 (EST) Received: from zcard00m.ca.nortel.com by zcars04e.ca.nortel.com; Fri, 9 Nov 2001 13:40:34 -0500 Received: from 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 WNFRWGLN; Fri, 9 Nov 2001 13:39:48 -0500 Received: from tweedy.NortelNetworks.com (dhcp229-100.engeast.baynetworks.com [192.32.229.100]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VW7FBW1F; Fri, 9 Nov 2001 13:39:47 -0500 Message-Id: <5.0.0.25.0.20011109133403.02ef9810@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 09 Nov 2001 13:38:41 -0500 To: diffserv@ietf.org From: "Kwok-Ho Chan" Cc: "Kwok-Ho Chan" In-Reply-To: <5.0.0.25.0.20011109130251.02458a30@zbl6c002.corpeast.bayne tworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Orig: Subject: [Diffserv] Re: Please Post draft-ietf-diffserv-pib-05.txt Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org DiffServ PIB-05 has been submitted to internet-drafts@ietf.org You can access the draft prior to IETF posting as follows. Please send any comments to the diffserv@ietf.org mailing list or myself as you see appropriate. Thanks! -- Kwok Ho Chan, Nortel Networks -- At 01:20 PM 11/9/01 -0500, you wrote: >Please post the Diff Serv PIB -05 located at: > >ftp://standards.nortelnetworks.com/diffserv/drafts/draft-ietf-diffserv-pib-05.txt > >This is work item in the DiffServ WG. > >Abstract: >The Differentiated Services Policy Information Base used with COPS-PR for >provisioning of devices capable of Differentiated Services functionality. > >Thank you very much! >-- Kwok Ho Chan -- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Sat Nov 10 01:34:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13088 for ; Sat, 10 Nov 2001 01:34:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA18579 for diffserv-archive@odin.ietf.org; Sat, 10 Nov 2001 01:34:18 -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 BAA17818; Sat, 10 Nov 2001 01:17:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA17787 for ; Sat, 10 Nov 2001 01:16:56 -0500 (EST) Received: from mailweb32.rediffmail.com (IDENT:qmailr@[203.199.83.152]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA10772 for ; Sat, 10 Nov 2001 01:16:53 -0500 (EST) Received: (qmail 17032 invoked by uid 510); 10 Nov 2001 06:16:48 -0000 Date: 10 Nov 2001 06:16:48 -0000 Message-ID: <20011110061648.17031.qmail@mailweb32.rediffmail.com> Received: from unknown (203.200.15.20) by rediffmail.com via HTTP; 10 Nov 2001 06:16:48 -0000 MIME-Version: 1.0 From: "Srinath . Pradeep" Reply-To: "Srinath . Pradeep" To: diffserv@ietf.org Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id BAA17788 Subject: [Diffserv] about marker and meter Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 8bit Hello *, In diffserv ,i have a doubt. How actually marking and metering is done. is there are any router commands to do this. is these activities occur inside the router. how we can know the packet is marked and metered. i think we have to check DSCP code point value. how to check thic value. is there are any inbuilt commands to do this. Thanks in advance pradeep srinath _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Sun Nov 11 18:31:30 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00625 for ; Sun, 11 Nov 2001 18:31:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA04982 for diffserv-archive@odin.ietf.org; Sun, 11 Nov 2001 18:31: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 SAA04117; Sun, 11 Nov 2001 18:02:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04087 for ; Sun, 11 Nov 2001 18:02:36 -0500 (EST) Received: from ISP-GO.FPT.VN (isp-go.fpt.vn [203.162.7.153]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00420 for ; Sun, 11 Nov 2001 18:02:28 -0500 (EST) Received: from isp-mail.FPT.VN ([203.162.7.147]) by ISP-GO.FPT.VN with Microsoft SMTPSVC(5.0.2195.3779); Mon, 12 Nov 2001 06:02:00 +0700 Received: from smtp.fpt.vn (isp-mta.fpt.vn [203.162.7.151]) by isp-mail.FPT.VN with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VXB48RAB; Mon, 12 Nov 2001 06:02:00 +0700 Received: from [203.162.61.215] by smtp.fpt.vn [203.162.7.151] Message-ID: <000301c16b06$338032e0$d73da2cb@nxlong24> Reply-To: "Nguyen Xuan Long" From: "Nguyen Xuan Long" To: "IETF DiffServ Group" Date: Sun, 11 Nov 2001 23:13:24 +0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-OriginalArrivalTime: 11 Nov 2001 23:02:00.0771 (UTC) FILETIME=[DEF4C930:01C16B04] Content-Transfer-Encoding: 7bit Subject: [Diffserv] DiffServ issues 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 Hello, Can you give me some advices? I am a newcommer in DiffServ group and I am preparing for my final project. I would like to know which (hot) problems, issues of DiffServ to direct my research. I really want to research into DiffServ, but I don't know which issues I should focus on to providing QoS Internet? Many thanhs for the help, Best Regard, Nguyen Xuan Long _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Mon Nov 12 02:13:06 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22215 for ; Mon, 12 Nov 2001 02:13:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA21618 for diffserv-archive@odin.ietf.org; Mon, 12 Nov 2001 02:13: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 BAA20853; Mon, 12 Nov 2001 01:54:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA20827 for ; Mon, 12 Nov 2001 01:54:25 -0500 (EST) Received: from samar.sasken.com (samar.sasken.com [164.164.56.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13364 for ; Mon, 12 Nov 2001 01:54:20 -0500 (EST) Received: from samar (localhost [127.0.0.1]) by samar.sasken.com (8.11.3/8.11.3) with SMTP id fAC6sBc19858 for ; Mon, 12 Nov 2001 12:24:11 +0530 (IST) Received: from localhost (chandras@localhost) by sunsv2.sasken.com (8.9.3/8.9.3) with ESMTP id MAA17489 for ; Mon, 12 Nov 2001 12:24:09 +0530 (IST) Date: Mon, 12 Nov 2001 12:24:09 +0530 (IST) From: Chandrashekhar S To: Subject: [Diffserv] DiffServ issues (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org I also want to know more information .. regarding what are the current issues.. in diffserv to research ...in order to provide better QOS ..in the internet ... regards, Chandra S Chandrashekhar SASKEN COMMUNICATION TECH CAMBRIDGE LAYOUT Bangalore : ph:5578300 extn:8058 ---------- Forwarded message ---------- Date: Sun, 11 Nov 2001 23:13:24 +0700 From: Nguyen Xuan Long To: IETF DiffServ Group Subject: [Diffserv] DiffServ issues Hello, Can you give me some advices? I am a newcommer in DiffServ group and I am preparing for my final project. I would like to know which (hot) problems, issues of DiffServ to direct my research. I really want to research into DiffServ, but I don't know which issues I should focus on to providing QoS Internet? Many thanhs for the help, Best Regard, Nguyen Xuan Long _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Mon Nov 12 03:37:08 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23122 for ; Mon, 12 Nov 2001 03:37:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA24404 for diffserv-archive@odin.ietf.org; Mon, 12 Nov 2001 03:37:09 -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 DAA23241; Mon, 12 Nov 2001 03:19: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 DAA23210 for ; Mon, 12 Nov 2001 03:19:42 -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 DAA22948 for ; Mon, 12 Nov 2001 03:19:39 -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 JAA15120; Mon, 12 Nov 2001 09:19:10 +0100 Received: from dhcp222-23.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA79106 from ; Mon, 12 Nov 2001 09:19:09 +0100 Message-Id: <3BEF85D9.9E8F1740@hursley.ibm.com> Date: Mon, 12 Nov 2001 09:18:33 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: "Srinath . Pradeep" Cc: diffserv@ietf.org Subject: Re: [Diffserv] about marker and meter References: <20011110061648.17031.qmail@mailweb32.rediffmail.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 Pradeep, This sort of implementation question really belongs on the diffserv implementation list. Please see http://www.atnf.csiro.au/news/exploders/dsimplementation.html Thanks Brian "Srinath . Pradeep" wrote: > > Hello *, > In diffserv ,i have a doubt. > How actually marking and metering is done. > is there are any router commands to do this. > is these activities occur inside the router. > how we can know the packet is marked and metered. > i think we have to check DSCP code point value. > how to check thic value. > is there are any inbuilt commands to do this. > > Thanks in advance > pradeep > srinath _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Mon Nov 12 04:03:10 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23570 for ; Mon, 12 Nov 2001 04:03:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA25901 for diffserv-archive@odin.ietf.org; Mon, 12 Nov 2001 04:02:05 -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 DAA25022; Mon, 12 Nov 2001 03:49:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA24988 for ; Mon, 12 Nov 2001 03:49:52 -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 DAA23269 for ; Mon, 12 Nov 2001 03:49:48 -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 JAA13074; Mon, 12 Nov 2001 09:49:20 +0100 Received: from dhcp222-23.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA44472 from ; Mon, 12 Nov 2001 09:49:18 +0100 Message-Id: <3BEF8CDF.7FF56CBA@hursley.ibm.com> Date: Mon, 12 Nov 2001 09:48:31 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Chandrashekhar S Cc: diffserv@ietf.org Subject: Re: [Diffserv] DiffServ issues (fwd) 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 Again - please use the diffserv-interest list for such queries.. Brian Chandrashekhar S wrote: > > I also want to know more information .. regarding what are the current > issues.. in diffserv to research ...in order to provide better QOS ..in > the internet ... > > regards, > Chandra > > S Chandrashekhar > SASKEN COMMUNICATION TECH > CAMBRIDGE LAYOUT > Bangalore : ph:5578300 extn:8058 > > ---------- Forwarded message ---------- > Date: Sun, 11 Nov 2001 23:13:24 +0700 > From: Nguyen Xuan Long > To: IETF DiffServ Group > Subject: [Diffserv] DiffServ issues > > Hello, > > Can you give me some advices? > > I am a newcommer in DiffServ group and I am preparing for my final project. > > I would like to know which (hot) problems, issues of DiffServ to direct my > research. I really want to research into DiffServ, but I don't know > which issues I should focus on to providing QoS Internet? > > Many thanhs for the help, > > Best Regard, > Nguyen Xuan Long _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Mon Nov 12 04:25:47 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23124 for ; Mon, 12 Nov 2001 03:37:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA24409 for diffserv-archive@odin.ietf.org; Mon, 12 Nov 2001 03:37: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 DAA23308; Mon, 12 Nov 2001 03:23:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA23275 for ; Mon, 12 Nov 2001 03:23:20 -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 DAA22972 for ; Mon, 12 Nov 2001 03:23:16 -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 JAA12586; Mon, 12 Nov 2001 09:22:48 +0100 Received: from dhcp222-23.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA29280 from ; Mon, 12 Nov 2001 09:22:47 +0100 Message-Id: <3BEF86AC.57782F3E@hursley.ibm.com> Date: Mon, 12 Nov 2001 09:22:04 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Nguyen Xuan Long Cc: IETF DiffServ Group Subject: Re: [Diffserv] DiffServ issues References: <000301c16b06$338032e0$d73da2cb@nxlong24> 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 Nguyen Xuan Long, This list is for the work of diffserv standardisation only. General queries should go to the diffserv-interest list (diffserv-interest@ietf.org) To Subscribe: diffserv-interest-request@ietf.org In Body: subscribe your_email_address Thanks Brian Nguyen Xuan Long wrote: > > Hello, > > Can you give me some advices? > > I am a newcommer in DiffServ group and I am preparing for my final project. > > I would like to know which (hot) problems, issues of DiffServ to direct my > research. I really want to research into DiffServ, but I don't know > which issues I should focus on to providing QoS Internet? > > Many thanhs for the help, > > Best Regard, > Nguyen Xuan Long _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Mon Nov 12 07:41:49 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26472 for ; Mon, 12 Nov 2001 07:41:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA01753 for diffserv-archive@odin.ietf.org; Mon, 12 Nov 2001 07:41:51 -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 HAA00386; Mon, 12 Nov 2001 07:03:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00350 for ; Mon, 12 Nov 2001 07:03:21 -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 HAA25275; Mon, 12 Nov 2001 07:03:18 -0500 (EST) Message-Id: <200111121203.HAA25275@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: diffserv@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 12 Nov 2001 07:03:18 -0500 Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-pib-05.txt Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Differentiated Services Working Group of the IETF. Title : Differentiated Services Quality of Service Policy Information Base Author(s) : M. Fine, K. McCloghrie et al. Filename : draft-ietf-diffserv-pib-05.txt Pages : 95 Date : 09-Nov-01 [SPPI] describes a structure for specifying policy information that can then be transmitted to a network device for the purpose of configuring policy at that device. The model underlying this structure is one of well-defined policy rule classes and instances of these classes residing in a virtual information store called the Policy Information Base (PIB). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-pib-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-diffserv-pib-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-diffserv-pib-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011109134428.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-diffserv-pib-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-diffserv-pib-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011109134428.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Mon Nov 12 11:51:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10913 for ; Mon, 12 Nov 2001 11:51:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA08881 for diffserv-archive@odin.ietf.org; Mon, 12 Nov 2001 11:51:45 -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 LAA07767; Mon, 12 Nov 2001 11:30:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07740 for ; Mon, 12 Nov 2001 11:30:19 -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 LAA09974 for ; Mon, 12 Nov 2001 11:30:16 -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 RAA13240 for ; Mon, 12 Nov 2001 17:29:48 +0100 Received: from dhcp22-51.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA61202 from ; Mon, 12 Nov 2001 17:29:47 +0100 Message-Id: <3BEFF7B3.FDA296EA@hursley.ibm.com> Date: Mon, 12 Nov 2001 17:24:19 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Diff Serv Content-Type: multipart/mixed; boundary="------------BB6BF826AF833C79BBA07CCE" Subject: [Diffserv] WG Last Call for draft-ietf-diffserv-pib-05.txt Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This is a multi-part message in MIME format. --------------BB6BF826AF833C79BBA07CCE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit It is proposed to forward draft-ietf-diffserv-pib-05.txt to the IESG for publication as a Proposed Standard. Any final working group comments should be sent to this list by November 26, 2001. Regards Brian Carpenter Kathie Nichols diffserv WG co-chairs -------- Original Message -------- Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-pib-05.txt Date: Mon, 12 Nov 2001 07:03:18 -0500 From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org To: IETF-Announce: ; CC: diffserv@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Differentiated Services Working Group of the IETF. Title : Differentiated Services Quality of Service Policy Information Base Author(s) : M. Fine, K. McCloghrie et al. Filename : draft-ietf-diffserv-pib-05.txt Pages : 95 Date : 09-Nov-01 [SPPI] describes a structure for specifying policy information that can then be transmitted to a network device for the purpose of configuring policy at that device. The model underlying this structure is one of well-defined policy rule classes and instances of these classes residing in a virtual information store called the Policy Information Base (PIB). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-pib-05.txt --------------BB6BF826AF833C79BBA07CCE Content-Type: Message/External-body; name="draft-ietf-diffserv-pib-05.txt" Content-Disposition: inline; filename="draft-ietf-diffserv-pib-05.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <20011109134428.I-D@ietf.org> --------------BB6BF826AF833C79BBA07CCE-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Mon Nov 12 11:54:12 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10985 for ; Mon, 12 Nov 2001 11:54:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA08965 for diffserv-archive@odin.ietf.org; Mon, 12 Nov 2001 11:54: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 LAA08130; Mon, 12 Nov 2001 11:36:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08073 for ; Mon, 12 Nov 2001 11:36:01 -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 LAA10233 for ; Mon, 12 Nov 2001 11:35:57 -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 RAA10074 for ; Mon, 12 Nov 2001 17:35:29 +0100 Received: from dhcp22-51.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA27392 from ; Mon, 12 Nov 2001 17:35:28 +0100 Message-Id: <3BEFF902.30D1BBD5@hursley.ibm.com> Date: Mon, 12 Nov 2001 17:29:54 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Diff Serv References: <3BEFF7B3.FDA296EA@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Re: WG Last Call for draft-ietf-diffserv-pib-05.txt Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Here are my own Last Call comments 1. There is no Abstract; this is required for the RFC version. 2. The ISOC Copyright text and the IETF intellectual property text are missing. Since there *is* a reference (section 12) to IPR claims, this text is needed. In relation to the latter, could somebody send the URLs for the relevant IPR claims? Thanks Brian Brian E Carpenter wrote: > > It is proposed to forward draft-ietf-diffserv-pib-05.txt > to the IESG for publication as a Proposed Standard. > > Any final working group comments should be sent > to this list by November 26, 2001. > > Regards > Brian Carpenter > Kathie Nichols > diffserv WG co-chairs > > -------- Original Message -------- > Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-pib-05.txt > Date: Mon, 12 Nov 2001 07:03:18 -0500 > From: Internet-Drafts@ietf.org > Reply-To: Internet-Drafts@ietf.org > To: IETF-Announce: ; > CC: diffserv@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Differentiated Services Working Group of the IETF. > > Title : Differentiated Services Quality of Service Policy > Information Base > Author(s) : M. Fine, K. McCloghrie et al. > Filename : draft-ietf-diffserv-pib-05.txt > Pages : 95 > Date : 09-Nov-01 > > [SPPI] describes a structure for specifying policy information that > can then be transmitted to a network device for the purpose of > configuring policy at that device. The model underlying this > structure is one of well-defined policy rule classes and instances > of these classes residing in a virtual information store called the > Policy Information Base (PIB). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-diffserv-pib-05.txt _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Mon Nov 12 12:15:41 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11671 for ; Mon, 12 Nov 2001 12:15:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA10988 for diffserv-archive@odin.ietf.org; Mon, 12 Nov 2001 12:15:44 -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 MAA10303; Mon, 12 Nov 2001 12:02:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10272 for ; Mon, 12 Nov 2001 12:02:31 -0500 (EST) Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11277 for ; Mon, 12 Nov 2001 12:02:27 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id fACH1LS00506 for ; Mon, 12 Nov 2001 12:01:21 -0500 (EST) Received: from zcard00m.ca.nortel.com by zcars04e.ca.nortel.com; Mon, 12 Nov 2001 12:01:49 -0500 Received: from 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 WNFR52Z5; Mon, 12 Nov 2001 12:00:57 -0500 Received: from tweedy.NortelNetworks.com (dhcp229-110.engeast.baynetworks.com [192.32.229.110]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VW7FBY2M; Mon, 12 Nov 2001 12:00:56 -0500 Message-Id: <5.0.0.25.0.20011112115554.02ebb4d0@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 12 Nov 2001 11:59:52 -0500 To: Brian E Carpenter From: "Kwok-Ho Chan" Subject: Re: [Diffserv] Re: WG Last Call for draft-ietf-diffserv-pib-05.txt Cc: Diff Serv In-Reply-To: <3BEFF902.30D1BBD5@hursley.ibm.com> References: <3BEFF7B3.FDA296EA@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Orig: Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Brian: I will add the additional text for items 1 and 2. Will let the IPR URLs be supplied by its owner. -- Kwok -- At 05:29 PM 11/12/01 +0100, Brian E Carpenter wrote: >Here are my own Last Call comments > >1. There is no Abstract; this is required for the RFC version. > >2. The ISOC Copyright text and the IETF intellectual property >text are missing. Since there *is* a reference (section 12) to >IPR claims, this text is needed. > >In relation to the latter, could somebody send the URLs for >the relevant IPR claims? > >Thanks > Brian > >Brian E Carpenter wrote: > > > > It is proposed to forward draft-ietf-diffserv-pib-05.txt > > to the IESG for publication as a Proposed Standard. > > > > Any final working group comments should be sent > > to this list by November 26, 2001. > > > > Regards > > Brian Carpenter > > Kathie Nichols > > diffserv WG co-chairs > > > > -------- Original Message -------- > > Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-pib-05.txt > > Date: Mon, 12 Nov 2001 07:03:18 -0500 > > From: Internet-Drafts@ietf.org > > Reply-To: Internet-Drafts@ietf.org > > To: IETF-Announce: ; > > CC: diffserv@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Differentiated Services Working Group > of the IETF. > > > > Title : Differentiated Services Quality of Service Policy > > Information Base > > Author(s) : M. Fine, K. McCloghrie et al. > > Filename : draft-ietf-diffserv-pib-05.txt > > Pages : 95 > > Date : 09-Nov-01 > > > > [SPPI] describes a structure for specifying policy information that > > can then be transmitted to a network device for the purpose of > > configuring policy at that device. The model underlying this > > structure is one of well-defined policy rule classes and instances > > of these classes residing in a virtual information store called the > > Policy Information Base (PIB). > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-diffserv-pib-05.txt > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >https://www1.ietf.org/mailman/listinfo/diffserv >Archive: >http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Wed Nov 14 01:57:02 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06233 for ; Wed, 14 Nov 2001 01:57:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA14886 for diffserv-archive@odin.ietf.org; Wed, 14 Nov 2001 01:57:04 -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 BAA13717; Wed, 14 Nov 2001 01:22: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 BAA13653 for ; Wed, 14 Nov 2001 01:22:12 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01712; Wed, 14 Nov 2001 01:22:10 -0500 (EST) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id fAE6Lfn12278; Tue, 13 Nov 2001 22:21:41 -0800 (PST) Received: from ANDREAWW2K ([128.107.131.45]) by mira-sjcm-2.cisco.com (Mirapoint) with SMTP id AAT55617; Tue, 13 Nov 2001 22:21:38 -0800 (PST) From: "Andrea Westerinen" To: , "Diffserv@Ietf. Org" Cc: "Policy@Ietf. Org" , "Bert Wijnen \(Bert\)" Subject: FW: [Diffserv] Informal WG last call for draft-ietf-diffserv-new-terms-06.txt Date: Tue, 13 Nov 2001 22:24:17 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) 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 Dan, I was asked to do a review of the "new-terms" draft wrt PolTerm. In general, there is good correspondence, but I have a few minor comments. 1. In Section 2, in the second paragraph, it would be helpful to reference the Policy Terminology RFC XXX (draft-ietf-policy-terminology-04.txt, waiting in the editor's queue) explicitly, since that supports your conclusions of SLAs being of a contractual nature. 2. The SLS definition in "new-terms" is a bit different (more restrictive) than the definition in PolTerm. The PolTerm definition tries to straddle the contractual versus service/conditioning aspects of an SLS. PolTerm states that an SLS ... Specifies handling of customer's traffic by a network provider. It is negotiated between a customer and the provider, and (for example) in a DiffServ environment, defines parameters such as specific Code Points and the Per-Hop-Behavior, profile characteristics and treatment of the traffic for those Code Points. An SLS is a specific SLA (a negotiated agreement) and its SLOs (the individual metrics and operational data to enforce) to guarantee quality of service for network traffic. It might be valuable to mention that the "new-terms" definition further restricts that specified in PolTerm, for the DiffServ environment. 3. In the last paragraph of Section 2, where you quote from the PolTerm RFC, could you make this a normative reference? 4. In the last sentence of Section 2, you say "Therefore, the relationship between an SLS and a service provisioning policy is that the latter is, in part, the set of rules that define the parameters and range of values that may be in the former." Would it be reasonable to say "... define and manage to the parameters and range of values ..."? The word "define" seems too restrictive. And, a few nits: 5. There are several weird quotation marks in the Status (``work in progress'' and ``1id-abstracts.txt''). 6. In Section 6, there are a few typos... 'Hence the imperitive was"SHOULD" rather than "SHALL"' - should be "imperative" and needs a space after "was" 'An egress DS-node at the edge of one DS-domain forwards packets an ingress DS-node at the edge of another DS domain.' - needs a "to" after "forwards packets" 7. Is there a reason for the last paragraph of Section 8 to look different than the previous RFC summaries? The grammar is written to correspond, but the missing ":" makes the paragraph difficult to read. Thanks for considering these. Andrea -----Original Message----- From: Brian E Carpenter [mailto:brian@hursley.ibm.com] Sent: Wednesday, November 07, 2001 3:20 PM To: Diff Serv Cc: Kathleen Nichols Subject: [Diffserv] Informal WG last call for draft-ietf-diffserv-new-terms-06.txt It is proposed to forward draft-ietf-diffserv-new-terms-06.txt for publication as an Informational RFC. This is an informal working group last call - please make any last comments on this document by Wednesday, November 21. N.B. This is an "informal" call because this is not a standards track document. Nevertheless, the clarification in Section 7 does refer to standards track issues. Brian Carpenter Kathie Nichols diffserv co-chairs -------- Original Message -------- Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-new-terms-06.txt Date: Wed, 07 Nov 2001 07:04:57 -0500 From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org To: IETF-Announce: ; CC: diffserv@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Differentiated Services Working Group of the IETF. Title : New Terminology for Diffserv Author(s) : D. Grossman Filename : draft-ietf-diffserv-new-terms-06.txt Pages : 9 Date : 06-Nov-01 This memo captures Diffserv working group agreements concerning new and improved terminology, and also provides minor technical clarifications. It is intended to update RFC 2474, RFC 2475 and RFC 2597. When RFCs 2474 and 2597 advance on the standards track, and RFC 2475 is updated, it is intended that the revisions in this memo will be incorporated, and that this memo will be obsoleted by the new RFCs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-new-terms-06.txt _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Wed Nov 14 11:34:39 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01982 for ; Wed, 14 Nov 2001 11:34:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA00174 for diffserv-archive@odin.ietf.org; Wed, 14 Nov 2001 11:34:43 -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 LAA28478; Wed, 14 Nov 2001 11:14:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28412 for ; Wed, 14 Nov 2001 11:14:29 -0500 (EST) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00636; Wed, 14 Nov 2001 11:14:25 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id fAEGDv607593; Wed, 14 Nov 2001 11:13:58 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Wed, 14 Nov 2001 17:13:52 +0100 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0DF1FF42@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Dan Grossman , Andrea Westerinen Cc: "Diffserv@Ietf. Org" , "Policy@Ietf. Org" , "Bert Wijnen (Bert)" Subject: RE: FW: [Diffserv] Informal WG last call for draft-ietf-diffserv -new-terms-06.txt Date: Wed, 14 Nov 2001 17:13:51 +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 Thanks Andrea for the detailed review And I see we have a discussion going with some agrrements comiung out already. Looks like we may expect one more revision. Bert > -----Original Message----- > From: Dan Grossman [mailto:dan@dma.isg.mot.com] > Sent: Wednesday, November 14, 2001 5:09 PM > To: Andrea Westerinen > Cc: Diffserv@Ietf. Org; Policy@Ietf. Org; Bert Wijnen (Bert) > Subject: Re: FW: [Diffserv] Informal WG last call for > draft-ietf-diffserv-new-terms-06.txt > > > Andrea, > Thanks for the careful review. > > Dan, I was asked to do a review of the "new-terms" draft > wrt PolTerm. In > > general, there is good correspondence, but I have a few > minor comments. > > > > 1. In Section 2, in the second paragraph, it would be > helpful to reference > > the Policy Terminology RFC XXX > (draft-ietf-policy-terminology-04.txt, > > waiting in the editor's queue) explicitly, since that supports your > > conclusions of SLAs being of a contractual nature. > > Agreed. > > > > > 2. The SLS definition in "new-terms" is a bit different > (more restrictive) > > than the definition in PolTerm. The PolTerm definition > tries to straddle > > the contractual versus service/conditioning aspects of an > SLS. PolTerm > > states that an SLS ... > > Specifies handling of customer's traffic by a network > > provider. It is negotiated between a customer and the > > provider, and (for example) in a DiffServ environment, > > defines parameters such as specific Code Points and the > > Per-Hop-Behavior, profile characteristics and treatment of > > the traffic for those Code Points. An SLS is a specific SLA > > (a negotiated agreement) and its SLOs (the individual > > metrics and operational data to enforce) to guarantee > > quality of service for network traffic. > > It might be valuable to mention that the "new-terms" > definition further > > restricts that specified in PolTerm, for the DiffServ environment. > > I'd be hesitant to alter the Diffserv definition, since this > was subject of a > great deal of working group debate. However, some words to > the effect that > you suggest would be appropriate. > > > > 3. In the last paragraph of Section 2, where you quote from > the PolTerm RFC, > > could you make this a normative reference? > > Ok. I'd lost track of the Polterm draft, and frankly forgot > to check the RFC > Editors queue for its status. The way this was done > reflected a concern that > this draft would get hung up behind the Polterm draft > indefinitely. Since the > Polterm draft is ahead, it makes perfect sense to make the > Polterm RFC > normative. > > > > > 4. In the last sentence of Section 2, you say "Therefore, > the relationship > > between an SLS and a service provisioning policy is that > the latter is, in > > part, the set of rules that define the parameters and range > of values that > > may be in the former." Would it be reasonable to say "... > define and manage > > to the parameters and range of values ..."? The word > "define" seems too > > restrictive. > > > I'm having problems parsing your proposed sentence. How can > a set of rules > "manage to" parameters and and a range of values? > > > And, a few nits: > > 5. There are several weird quotation marks in the Status (``work in > > progress'' and ``1id-abstracts.txt''). > There's some wierd character mappings in my HPUX workstation. > I'll move it > back to a windows platform and spot clean when this goes to > the RFC editor. > > > > > 6. In Section 6, there are a few typos... > > 'Hence the imperitive was"SHOULD" rather than "SHALL"' - should be > > "imperative" and needs a space after "was" > oops... > > > 'An egress DS-node at the edge of one DS-domain forwards > packets an ingress > > DS-node at the edge of another DS domain.' - needs a "to" > after "forwards > > packets" > > well spotted. > > > > 7. Is there a reason for the last paragraph of Section 8 to > look different > > than the previous RFC summaries? The grammar is written to > correspond, but > > the missing ":" makes the paragraph difficult to read. > > Will look into, thanks. > > > > Thanks for considering these. > > Thanks again for the review. > > Andrea > > > Dan > _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Wed Nov 14 11:39:47 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02324 for ; Wed, 14 Nov 2001 11:39:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA00262 for diffserv-archive@odin.ietf.org; Wed, 14 Nov 2001 11:39:50 -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 LAA28210; Wed, 14 Nov 2001 11:09: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 LAA28151 for ; Wed, 14 Nov 2001 11:09:13 -0500 (EST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00348; Wed, 14 Nov 2001 11:09:09 -0500 (EST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id JAA25659; Wed, 14 Nov 2001 09:09:10 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id JAA18287; Wed, 14 Nov 2001 09:09:09 -0700 (MST)] Received: from dma.isg.mot.com (nrlab-08.dma.isg.mot.com [150.21.50.46]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id LAA22715; Wed, 14 Nov 2001 11:09:09 -0500 (EST) Message-Id: <200111141609.LAA22715@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: "Andrea Westerinen" cc: "Diffserv@Ietf. Org" , "Policy@Ietf. Org" , "Bert Wijnen \(Bert\)" Subject: Re: FW: [Diffserv] Informal WG last call for draft-ietf-diffserv-new-terms-06.txt In-reply-to: Your message of "Tue, 13 Nov 2001 22:24:17 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Nov 2001 11:09:08 -0500 From: Dan Grossman 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 Andrea, Thanks for the careful review. > Dan, I was asked to do a review of the "new-terms" draft wrt PolTerm. In > general, there is good correspondence, but I have a few minor comments. > > 1. In Section 2, in the second paragraph, it would be helpful to reference > the Policy Terminology RFC XXX (draft-ietf-policy-terminology-04.txt, > waiting in the editor's queue) explicitly, since that supports your > conclusions of SLAs being of a contractual nature. Agreed. > > 2. The SLS definition in "new-terms" is a bit different (more restrictive) > than the definition in PolTerm. The PolTerm definition tries to straddle > the contractual versus service/conditioning aspects of an SLS. PolTerm > states that an SLS ... > Specifies handling of customer's traffic by a network > provider. It is negotiated between a customer and the > provider, and (for example) in a DiffServ environment, > defines parameters such as specific Code Points and the > Per-Hop-Behavior, profile characteristics and treatment of > the traffic for those Code Points. An SLS is a specific SLA > (a negotiated agreement) and its SLOs (the individual > metrics and operational data to enforce) to guarantee > quality of service for network traffic. > It might be valuable to mention that the "new-terms" definition further > restricts that specified in PolTerm, for the DiffServ environment. I'd be hesitant to alter the Diffserv definition, since this was subject of a great deal of working group debate. However, some words to the effect that you suggest would be appropriate. > > 3. In the last paragraph of Section 2, where you quote from the PolTerm RFC, > could you make this a normative reference? Ok. I'd lost track of the Polterm draft, and frankly forgot to check the RFC Editors queue for its status. The way this was done reflected a concern that this draft would get hung up behind the Polterm draft indefinitely. Since the Polterm draft is ahead, it makes perfect sense to make the Polterm RFC normative. > > 4. In the last sentence of Section 2, you say "Therefore, the relationship > between an SLS and a service provisioning policy is that the latter is, in > part, the set of rules that define the parameters and range of values that > may be in the former." Would it be reasonable to say "... define and manage > to the parameters and range of values ..."? The word "define" seems too > restrictive. > I'm having problems parsing your proposed sentence. How can a set of rules "manage to" parameters and and a range of values? > And, a few nits: > 5. There are several weird quotation marks in the Status (``work in > progress'' and ``1id-abstracts.txt''). There's some wierd character mappings in my HPUX workstation. I'll move it back to a windows platform and spot clean when this goes to the RFC editor. > > 6. In Section 6, there are a few typos... > 'Hence the imperitive was"SHOULD" rather than "SHALL"' - should be > "imperative" and needs a space after "was" oops... > 'An egress DS-node at the edge of one DS-domain forwards packets an ingress > DS-node at the edge of another DS domain.' - needs a "to" after "forwards > packets" well spotted. > > 7. Is there a reason for the last paragraph of Section 8 to look different > than the previous RFC summaries? The grammar is written to correspond, but > the missing ":" makes the paragraph difficult to read. Will look into, thanks. > > Thanks for considering these. Thanks again for the review. > Andrea > Dan _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Wed Nov 14 12:06:46 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04216 for ; Wed, 14 Nov 2001 12:06:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA02387 for diffserv-archive@odin.ietf.org; Wed, 14 Nov 2001 12:06:49 -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 LAA00717; Wed, 14 Nov 2001 11:48:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00686 for ; Wed, 14 Nov 2001 11:48:38 -0500 (EST) Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03089 for ; Wed, 14 Nov 2001 11:48:33 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id fAEGlJS07345 for ; Wed, 14 Nov 2001 11:47:19 -0500 (EST) Received: from zbl6c012.corpeast.baynetworks.com by zcars04e.ca.nortel.com; Wed, 14 Nov 2001 11:47:50 -0500 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id WMPW64KL; Wed, 14 Nov 2001 11:46:58 -0500 Received: from tweedy.NortelNetworks.com (dhcp229-110.engeast.baynetworks.com [192.32.229.110]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VW7FB6VK; Wed, 14 Nov 2001 11:46:58 -0500 Message-Id: <5.0.0.25.0.20011114114304.0233a320@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 14 Nov 2001 11:45:53 -0500 To: diffserv@ietf.org From: "Kwok-Ho Chan" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Orig: Subject: [Diffserv] Fwd: draft-ietf-rap-frameworkpib-06.txt submitted 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 FYI. This version of Framework PIB (06) is developed with and referenced by DiffServ PIB-05 draft. -- Kwok -- >X-Sender: khchan@zbl6c002.corpeast.baynetworks.com >X-Mailer: QUALCOMM Windows Eudora Version 5.0 >Date: Wed, 14 Nov 2001 11:31:37 -0500 >To: rap@ops.ietf.org >From: "Chan, Kwok-Ho [BL60:470:EXCH]" >Subject: draft-ietf-rap-frameworkpib-06.txt submitted >Cc: "Chan, Kwok-Ho [BL60:470:EXCH]" >X-Orig: > >The Framework PIB has been submitted to IETF. >Prior to IETF Announcement of its availability, it can be retrieved at: > >ftp://standards.nortelnetworks.com/rap/52nd_IETF/draft-ietf-rap-frameworkpib-06.txt > >Happy reading and please post any comments on the RAP mailing list. >-- Kwok -- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Wed Nov 14 17:29:13 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19575 for ; Wed, 14 Nov 2001 17:29:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA13280 for diffserv-archive@odin.ietf.org; Wed, 14 Nov 2001 17:29: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 QAA11209; Wed, 14 Nov 2001 16:51:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11147 for ; Wed, 14 Nov 2001 16:51:14 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18128; Wed, 14 Nov 2001 16:51:07 -0500 (EST) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id fAELobl02053; Wed, 14 Nov 2001 13:50:39 -0800 (PST) Received: from ANDREAWW2K ([128.107.131.45]) by mira-sjcm-2.cisco.com (Mirapoint) with SMTP id AAT74861; Wed, 14 Nov 2001 13:50:28 -0800 (PST) From: "Andrea Westerinen" To: "Dan Grossman" Cc: "Diffserv@Ietf. Org" , "Policy@Ietf. Org" , "Bert Wijnen \(Bert\)" Subject: RE: FW: [Diffserv] Informal WG last call for draft-ietf-diffserv-new-terms-06.txt Date: Wed, 14 Nov 2001 13:53:08 -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.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <200111141609.LAA22715@noah.dma.isg.mot.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 Pulling everything up here. It looks like #4 needs a bit more discussion - however, it is not a major issue for me. 1. PolTerm supports SLAs as contractual - Agreed to document this alignment. 2. Dan said, "I'd be hesitant to alter the Diffserv definition, since this was subject of a great deal of working group debate. However, some words to the effect that you suggest would be appropriate." - This is all that I was suggesting. I totally understand how painful these things can be - and I think that the definitions are aligned. PolTerm is just broader and this was intentional. 3. Normative reference to PolTerm - OK. 4. Service provisioning policy "defines and manages to parameters and range of values" in an SLS. Dan asked how rules can manage to parameters and ranges. - This really depends on your rules. For static "preconfiguration" rules, then all that you are doing is defining what you want, and making it so. In the more general case of provisioning rules, you might have "preconfiguration" rules, and other "runtime" rules that are invoked "if ." If/when something happens, then the actions of the other rules might manipulate the environment to maintain (ie, "manage to") the parameters and ranges, or switch to new parameters, or ignore parameters/ranges, etc. I was asking about whether we should generalize what a "provisioning rule" might do. 5-7. Nits and typos - Will be cleaned up. Andrea -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of Dan Grossman Sent: Wednesday, November 14, 2001 8:09 AM To: Andrea Westerinen Cc: Diffserv@Ietf. Org; Policy@Ietf. Org; Bert Wijnen (Bert) Subject: Re: FW: [Diffserv] Informal WG last call for draft-ietf-diffserv-new-terms-06.txt Andrea, Thanks for the careful review. > Dan, I was asked to do a review of the "new-terms" draft wrt PolTerm. In > general, there is good correspondence, but I have a few minor comments. > > 1. In Section 2, in the second paragraph, it would be helpful to reference > the Policy Terminology RFC XXX (draft-ietf-policy-terminology-04.txt, > waiting in the editor's queue) explicitly, since that supports your > conclusions of SLAs being of a contractual nature. Agreed. > > 2. The SLS definition in "new-terms" is a bit different (more restrictive) > than the definition in PolTerm. The PolTerm definition tries to straddle > the contractual versus service/conditioning aspects of an SLS. PolTerm > states that an SLS ... > Specifies handling of customer's traffic by a network > provider. It is negotiated between a customer and the > provider, and (for example) in a DiffServ environment, > defines parameters such as specific Code Points and the > Per-Hop-Behavior, profile characteristics and treatment of > the traffic for those Code Points. An SLS is a specific SLA > (a negotiated agreement) and its SLOs (the individual > metrics and operational data to enforce) to guarantee > quality of service for network traffic. > It might be valuable to mention that the "new-terms" definition further > restricts that specified in PolTerm, for the DiffServ environment. I'd be hesitant to alter the Diffserv definition, since this was subject of a great deal of working group debate. However, some words to the effect that you suggest would be appropriate. > > 3. In the last paragraph of Section 2, where you quote from the PolTerm RFC, > could you make this a normative reference? Ok. I'd lost track of the Polterm draft, and frankly forgot to check the RFC Editors queue for its status. The way this was done reflected a concern that this draft would get hung up behind the Polterm draft indefinitely. Since the Polterm draft is ahead, it makes perfect sense to make the Polterm RFC normative. > > 4. In the last sentence of Section 2, you say "Therefore, the relationship > between an SLS and a service provisioning policy is that the latter is, in > part, the set of rules that define the parameters and range of values that > may be in the former." Would it be reasonable to say "... define and manage > to the parameters and range of values ..."? The word "define" seems too > restrictive. > I'm having problems parsing your proposed sentence. How can a set of rules "manage to" parameters and and a range of values? > And, a few nits: > 5. There are several weird quotation marks in the Status (``work in > progress'' and ``1id-abstracts.txt''). There's some wierd character mappings in my HPUX workstation. I'll move it back to a windows platform and spot clean when this goes to the RFC editor. > > 6. In Section 6, there are a few typos... > 'Hence the imperitive was"SHOULD" rather than "SHALL"' - should be > "imperative" and needs a space after "was" oops... > 'An egress DS-node at the edge of one DS-domain forwards packets an ingress > DS-node at the edge of another DS domain.' - needs a "to" after "forwards > packets" well spotted. > > 7. Is there a reason for the last paragraph of Section 8 to look different > than the previous RFC summaries? The grammar is written to correspond, but > the missing ":" makes the paragraph difficult to read. Will look into, thanks. > > Thanks for considering these. Thanks again for the review. > Andrea > Dan _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Wed Nov 14 17:48:14 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20211 for ; Wed, 14 Nov 2001 17:48:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA14415 for diffserv-archive@odin.ietf.org; Wed, 14 Nov 2001 17:48:17 -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 RAA12945; Wed, 14 Nov 2001 17:22:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA12877 for ; Wed, 14 Nov 2001 17:22:52 -0500 (EST) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19436; Wed, 14 Nov 2001 17:22:46 -0500 (EST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate3.mot.com (motgate3 2.1) with ESMTP id PAA03002; Wed, 14 Nov 2001 15:13:38 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id PAA02417; Wed, 14 Nov 2001 15:22:46 -0700 (MST)] Received: from dma.isg.mot.com (nrlab-08.dma.isg.mot.com [150.21.50.46]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id RAA08649; Wed, 14 Nov 2001 17:22:10 -0500 (EST) Message-Id: <200111142222.RAA08649@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: "Andrea Westerinen" cc: "Diffserv@Ietf. Org" , "Policy@Ietf. Org" , "Bert Wijnen \(Bert\)" Subject: Re: FW: [Diffserv] Informal WG last call for draft-ietf-diffserv-new-terms-06.txt In-reply-to: Your message of "Wed, 14 Nov 2001 13:53:08 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Nov 2001 17:22:08 -0500 From: Dan Grossman 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 > Pulling everything up here. It looks like #4 needs a bit more discussion - > however, it is not a major issue for me. > > 4. Service provisioning policy "defines and manages to parameters and range > of values" in an SLS. Dan asked how rules can manage to parameters and > ranges. > - This really depends on your rules. For static "preconfiguration" rules, > then all that you are doing is defining what you want, and making it so. In > the more general case of provisioning rules, you might have > "preconfiguration" rules, and other "runtime" rules that are invoked "if > ." If/when something happens, then the actions of the > other rules might manipulate the environment to maintain (ie, "manage to") > the parameters and ranges, or switch to new parameters, or ignore > parameters/ranges, etc. I was asking about whether we should generalize > what a "provisioning rule" might do. Wow! I'm struggling with the implications of that. I'd assumed that to the extent that an SLS had dynamic ("runtime") elements, the new parameter/value tuples would be within the constraints of the same rules as the old SLS (that is, the rules are simple, static and non-dependent). In any event, this seems like a difficult construct to explain (both as sentence structure and as a concept). If we were to put something like this in, it would need some explanation. Otherwise, I'll be bombarded with the same newbie questions about this sentence until I'm 80. Is this important enough to provide more text around? Dan _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Thu Nov 15 08:55:31 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23303 for ; Thu, 15 Nov 2001 08:55:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA14982 for diffserv-archive@odin.ietf.org; Thu, 15 Nov 2001 08:55:32 -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 IAA14227; Thu, 15 Nov 2001 08:40:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA14150 for ; Thu, 15 Nov 2001 08:40:26 -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 IAA22509; Thu, 15 Nov 2001 08:40:24 -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 OAA16246; Thu, 15 Nov 2001 14:39:52 +0100 Received: from dhcp22-51.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA74726 from ; Thu, 15 Nov 2001 14:39:51 +0100 Message-Id: <3BF3C49D.A6FC5DB8@hursley.ibm.com> Date: Thu, 15 Nov 2001 14:35:25 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Dan Grossman Cc: Andrea Westerinen , "Diffserv@Ietf. Org" , "Policy@Ietf. Org" , "Bert Wijnen (Bert)" Subject: Re: FW: [Diffserv] Informal WG last call for draft-ietf-diffserv-new-terms-06.txt References: <200111142222.RAA08649@noah.dma.isg.mot.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 Given that new-terms will be Informational, I don't think we have to beat this to death- Dan could perhaps craft some disclaimer text. (Also, by the way, Informational RFCs don't have to worry about the difference between normative and non-normative references.) Brian Dan Grossman wrote: > > > Pulling everything up here. It looks like #4 needs a bit more discussion - > > however, it is not a major issue for me. > > > > > 4. Service provisioning policy "defines and manages to parameters and range > > of values" in an SLS. Dan asked how rules can manage to parameters and > > ranges. > > - This really depends on your rules. For static "preconfiguration" rules, > > then all that you are doing is defining what you want, and making it so. In > > the more general case of provisioning rules, you might have > > "preconfiguration" rules, and other "runtime" rules that are invoked "if > > ." If/when something happens, then the actions of the > > other rules might manipulate the environment to maintain (ie, "manage to") > > the parameters and ranges, or switch to new parameters, or ignore > > parameters/ranges, etc. I was asking about whether we should generalize > > what a "provisioning rule" might do. > > Wow! I'm struggling with the implications of that. I'd assumed that to the > extent that an SLS had dynamic ("runtime") elements, the new parameter/value > tuples would be within the constraints of the same rules as the old SLS (that > is, the rules are simple, static and non-dependent). > > In any event, this seems like a difficult construct to explain (both as > sentence structure and as a concept). If we were to put something like this > in, it would need some explanation. Otherwise, I'll be bombarded with the > same newbie questions about this sentence until I'm 80. Is this important > enough to provide more text around? > > Dan _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Thu Nov 15 10:28:48 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28026 for ; Thu, 15 Nov 2001 10:28:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA18466 for diffserv-archive@odin.ietf.org; Thu, 15 Nov 2001 10:28:49 -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 KAA17757; Thu, 15 Nov 2001 10:17: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 KAA17688 for ; Thu, 15 Nov 2001 10:17:12 -0500 (EST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27398; Thu, 15 Nov 2001 10:17:09 -0500 (EST) Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id fAFFGNp00837; Thu, 15 Nov 2001 10:16:23 -0500 (EST) Date: Thu, 15 Nov 2001 10:16:23 -0500 (EST) From: Scott Bradner Message-Id: <200111151516.fAFFGNp00837@newdev.harvard.edu> To: brian@hursley.ibm.com, dan@dma.isg.mot.com Subject: Re: FW: [Diffserv] Informal WG last call for draft-ietf-diffserv-new-terms-06.txt Cc: andreaw@cisco.com, bwijnen@lucent.com, diffserv@ietf.org, policy@ietf.org 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 Given that new-terms will be Informational, I don't think we have to > Given that new-terms will be Informational, I don't think we have to > the difference between normative and non-normative references.) see http://www.rfc-editor.org/policy.html in general and in specific about references Scott _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Thu Nov 15 10:38:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28663 for ; Thu, 15 Nov 2001 10:38:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA19648 for diffserv-archive@odin.ietf.org; Thu, 15 Nov 2001 10:38:20 -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 KAA18405; Thu, 15 Nov 2001 10:28:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18371 for ; Thu, 15 Nov 2001 10:28:04 -0500 (EST) Received: from mail2.orchestream.com (mail2.orchestream.com [195.153.64.126]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27978 for ; Thu, 15 Nov 2001 10:28:01 -0500 (EST) Received: from rimmer.orchestream.com (rimmer.orchestream.com) by mail2.orchestream.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Thu, 15 Nov 2001 15:30:18 +0000 Received: from s1000.orchestream.com (s1000.orchestream.com [192.168.0.16]) by rimmer.orchestream.com (8.9.3/8.9.3) with ESMTP id PAA22418 for ; Thu, 15 Nov 2001 15:21:22 GMT Received: by s1000.orchestream.com with Internet Mail Service (5.5.2653.19) id ; Thu, 15 Nov 2001 15:22:31 -0000 Message-ID: From: "Da Silva, Pedro" To: "'diffserv@ietf.org'" Date: Thu, 15 Nov 2001 15:22:25 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] diffserv-pib-05 comments [sic] 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 capability tables (e.g. qosIfMeteringCapsTable) have a UNIQUENESS clause that includes the capability spec itself (as well as the direction from the base class). This means that a user may specify more than one capability set in one given direction, which in turn entails more work for the entity managing and checking capabilities specs per se and capabilities specs against policies. Shouldn't the UNIQUENESS clause be restricted to the direction? Pedro _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Thu Nov 15 11:12:47 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00702 for ; Thu, 15 Nov 2001 11:12:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA21838 for diffserv-archive@odin.ietf.org; Thu, 15 Nov 2001 11:12:49 -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 LAA20870; Thu, 15 Nov 2001 11:02: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 LAA20804 for ; Thu, 15 Nov 2001 11:01:58 -0500 (EST) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29832; Thu, 15 Nov 2001 11:01:54 -0500 (EST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate3.mot.com (motgate3 2.1) with ESMTP id IAA17133; Thu, 15 Nov 2001 08:52:44 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id JAA13008; Thu, 15 Nov 2001 09:01:53 -0700 (MST)] Received: from dma.isg.mot.com (nrlab-08.dma.isg.mot.com [150.21.50.46]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id LAA05002; Thu, 15 Nov 2001 11:01:50 -0500 (EST) Message-Id: <200111151601.LAA05002@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: Brian E Carpenter cc: Andrea Westerinen , "Diffserv@Ietf. Org" , "Policy@Ietf. Org" , "Bert Wijnen (Bert)" Subject: Re: FW: [Diffserv] Informal WG last call for draft-ietf-diffserv-new-terms-06.txt In-reply-to: Your message of "Thu, 15 Nov 2001 14:35:25 EST." <3BF3C49D.A6FC5DB8@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 15 Nov 2001 11:01:49 -0500 From: Dan Grossman 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 > Given that new-terms will be Informational, I don't think we have to > beat this to death- Dan could perhaps craft some disclaimer text. My inclination at this point is to leave it as it is, unless Andrea can come up with a concise sentence or two that can be dropped in. I think that policy aware readers will understand that we don't intend to be restrictive, and non-policy aware readers won't be confused. > > (Also, by the way, Informational RFCs don't have to worry about > the difference between normative and non-normative references.) It appears that all the references are normative. > > Brian > Dan _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Thu Nov 15 11:18:12 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00997 for ; Thu, 15 Nov 2001 11:18:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA22099 for diffserv-archive@odin.ietf.org; Thu, 15 Nov 2001 11:18: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 LAA21277; Thu, 15 Nov 2001 11:07:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21192 for ; Thu, 15 Nov 2001 11:07:25 -0500 (EST) Received: from e22.nc.us.ibm.com (e22.nc.us.ibm.com [32.97.136.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00119; Thu, 15 Nov 2001 11:07:21 -0500 (EST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e22.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA17330; Thu, 15 Nov 2001 10:04:42 -0600 Received: from d04mc200.raleigh.ibm.com (d04mc200.raleigh.ibm.com [9.67.228.62]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fAFG7Kv132400; Thu, 15 Nov 2001 11:07:20 -0500 Subject: Re: [Policy] Re: FW: [Diffserv] Informal WG last call for draft-ietf-diffserv-new-terms-06.txt To: Scott Bradner Cc: andreaw@cisco.com, brian@hursley.ibm.com, bwijnen@lucent.com, dan@dma.isg.mot.com, diffserv@ietf.org, policy@ietf.org, policy-admin@ietf.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Robert Moore" Date: Thu, 15 Nov 2001 11:08:40 -0500 X-MIMETrack: Serialize by Router on D04MC200/04/M/IBM(Release 5.0.8 |June 18, 2001) at 11/15/2001 11:07:19 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Sorry, Scott, but I looked at the page you referred us to, and I still can't tell which of the following is the message I'm supposed to take away from it: A. No, Brian, that's not right - there *is* a distinction in an Informational RFC between normative and non-normative references. B. Yes, Brian, you're correct - there is no distinction in an Informational RFC between normative and non-normative references. C. Brian, it's more complicated than that. For some Informational RFCs, there is a distinction, and for others there isn't. For a particular Informational RFC, tells you whether it needs to distinguish between normative and non-normative references. [I have no idea how to fill in the here, by the way.] Can you say whether you meant A, B, or C, or even a D that hasn't occurred to me? Thanks. Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com Scott Bradner cc: andreaw@cisco.com, bwijnen@lucent.com, Sent by: diffserv@ietf.org, policy@ietf.org policy-admin@i Subject: [Policy] Re: FW: [Diffserv] Informal etf.org WG last call for draft-ietf-diffserv-new-terms-06.txt 11/15/01 10:16 AM Given that new-terms will be Informational, I don't think we have to > Given that new-terms will be Informational, I don't think we have to > the difference between normative and non-normative references.) see http://www.rfc-editor.org/policy.html in general and in specific about references Scott _______________________________________________ Policy mailing list Policy@ietf.org http://www1.ietf.org/mailman/listinfo/policy _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Thu Nov 15 11:30:32 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02020 for ; Thu, 15 Nov 2001 11:30:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA23640 for diffserv-archive@odin.ietf.org; Thu, 15 Nov 2001 11:30: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 LAA22208; Thu, 15 Nov 2001 11:18: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 LAA22136 for ; Thu, 15 Nov 2001 11:18:39 -0500 (EST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01054; Thu, 15 Nov 2001 11:18:34 -0500 (EST) Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id fAFGI8a00719; Thu, 15 Nov 2001 11:18:08 -0500 (EST) Date: Thu, 15 Nov 2001 11:18:08 -0500 (EST) From: Scott Bradner Message-Id: <200111151618.fAFGI8a00719@newdev.harvard.edu> To: remoore@us.ibm.com, sob@harvard.edu Subject: Re: [Policy] Re: FW: [Diffserv] Informal WG last call for draft-ietf-diffserv-new-terms-06.txt Cc: andreaw@cisco.com, brian@hursley.ibm.com, bwijnen@lucent.com, dan@dma.isg.mot.com, diffserv@ietf.org, policy-admin@ietf.org, policy@ietf.org 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 aim is to have all RFCs distinguish between normative and non-normative references Scott --- From remoore@us.ibm.com Thu Nov 15 11:07:44 2001 Subject: Re: [Policy] Re: FW: [Diffserv] Informal WG last call for draft-ietf-diffserv-new-terms-06.txt To: Scott Bradner Cc: andreaw@cisco.com, brian@hursley.ibm.com, bwijnen@lucent.com, dan@dma.isg.mot.com, diffserv@ietf.org, policy@ietf.org, policy-admin@ietf.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: "Robert Moore" Date: Thu, 15 Nov 2001 11:08:40 -0500 X-MIMETrack: Serialize by Router on D04MC200/04/M/IBM(Release 5.0.8 |June 18, 2001) at 11/15/2001 11:07:19 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sorry, Scott, but I looked at the page you referred us to, and I still can't tell which of the following is the message I'm supposed to take away from it: A. No, Brian, that's not right - there *is* a distinction in an Informational RFC between normative and non-normative references. B. Yes, Brian, you're correct - there is no distinction in an Informational RFC between normative and non-normative references. C. Brian, it's more complicated than that. For some Informational RFCs, there is a distinction, and for others there isn't. For a particular Informational RFC, tells you whether it needs to distinguish between normative and non-normative references. [I have no idea how to fill in the here, by the way.] Can you say whether you meant A, B, or C, or even a D that hasn't occurred to me? Thanks. Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com Scott Bradner cc: andreaw@cisco.com, bwijnen@lucent.com, Sent by: diffserv@ietf.org, policy@ietf.org policy-admin@i Subject: [Policy] Re: FW: [Diffserv] Informal etf.org WG last call for draft-ietf-diffserv-new-terms-06.txt 11/15/01 10:16 AM Given that new-terms will be Informational, I don't think we have to > Given that new-terms will be Informational, I don't think we have to > the difference between normative and non-normative references.) see http://www.rfc-editor.org/policy.html in general and in specific about references Scott _______________________________________________ Policy mailing list Policy@ietf.org http://www1.ietf.org/mailman/listinfo/policy _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Thu Nov 15 11:38:15 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02532 for ; Thu, 15 Nov 2001 11:38:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA24520 for diffserv-archive@odin.ietf.org; Thu, 15 Nov 2001 11:38:17 -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 LAA23543; Thu, 15 Nov 2001 11:29:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23512 for ; Thu, 15 Nov 2001 11:29:53 -0500 (EST) Received: from mail2.orchestream.com (mail2.orchestream.com [195.153.64.126]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01966 for ; Thu, 15 Nov 2001 11:29:48 -0500 (EST) Received: from rimmer.orchestream.com (rimmer.orchestream.com) by mail2.orchestream.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Thu, 15 Nov 2001 16:32:05 +0000 Received: from s1000.orchestream.com (s1000.orchestream.com [192.168.0.16]) by rimmer.orchestream.com (8.9.3/8.9.3) with ESMTP id QAA05496 for ; Thu, 15 Nov 2001 16:23:09 GMT Received: by s1000.orchestream.com with Internet Mail Service (5.5.2653.19) id ; Thu, 15 Nov 2001 16:24:17 -0000 Message-ID: From: "Da Silva, Pedro" To: Diff Serv Date: Thu, 15 Nov 2001 16:24:12 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] diffserv-pib-05 comments [sic] 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 capability tables (e.g. qosIfMeteringCapsTable) have a UNIQUENESS clause that includes the capability spec itself (as well as the direction from the base class). This means that a user may specify more than one capability set in one given direction, which in turn entails more work for the entity managing and checking capabilities specs per se and capabilities specs against policies. Shouldn't the UNIQUENESS clause be restricted to the direction? Pedro -----Original Message----- From: Kwok-Ho Chan [mailto:khchan@nortelnetworks.com] Sent: Monday, November 12, 2001 5:00 PM To: Brian E Carpenter Cc: Diff Serv Subject: Re: [Diffserv] Re: WG Last Call for draft-ietf-diffserv-pib-05.txt Brian: I will add the additional text for items 1 and 2. Will let the IPR URLs be supplied by its owner. -- Kwok -- At 05:29 PM 11/12/01 +0100, Brian E Carpenter wrote: >Here are my own Last Call comments > >1. There is no Abstract; this is required for the RFC version. > >2. The ISOC Copyright text and the IETF intellectual property >text are missing. Since there *is* a reference (section 12) to >IPR claims, this text is needed. > >In relation to the latter, could somebody send the URLs for >the relevant IPR claims? > >Thanks > Brian > >Brian E Carpenter wrote: > > > > It is proposed to forward draft-ietf-diffserv-pib-05.txt > > to the IESG for publication as a Proposed Standard. > > > > Any final working group comments should be sent > > to this list by November 26, 2001. > > > > Regards > > Brian Carpenter > > Kathie Nichols > > diffserv WG co-chairs > > > > -------- Original Message -------- > > Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-pib-05.txt > > Date: Mon, 12 Nov 2001 07:03:18 -0500 > > From: Internet-Drafts@ietf.org > > Reply-To: Internet-Drafts@ietf.org > > To: IETF-Announce: ; > > CC: diffserv@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Differentiated Services Working Group > of the IETF. > > > > Title : Differentiated Services Quality of Service Policy > > Information Base > > Author(s) : M. Fine, K. McCloghrie et al. > > Filename : draft-ietf-diffserv-pib-05.txt > > Pages : 95 > > Date : 09-Nov-01 > > > > [SPPI] describes a structure for specifying policy information that > > can then be transmitted to a network device for the purpose of > > configuring policy at that device. The model underlying this > > structure is one of well-defined policy rule classes and instances > > of these classes residing in a virtual information store called the > > Policy Information Base (PIB). > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-diffserv-pib-05.txt > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >https://www1.ietf.org/mailman/listinfo/diffserv >Archive: >http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist. html _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@ns.ietf.org Thu Nov 15 14:36:57 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14452 for ; Thu, 15 Nov 2001 14:36:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA02657 for diffserv-archive@odin.ietf.org; Thu, 15 Nov 2001 14:36:59 -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 OAA01700; Thu, 15 Nov 2001 14:18:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01669 for ; Thu, 15 Nov 2001 14:18:30 -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 OAA13096; Thu, 15 Nov 2001 14:18:24 -0500 (EST) Message-Id: <200111151918.OAA13096@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , diffserv@ietf.org From: The IESG Date: Thu, 15 Nov 2001 14:18:24 -0500 Subject: [Diffserv] Protocol Action: Management Information Base for the Differentiated Services Architecture to Proposed Standard Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org The IESG has approved the Internet-Draft 'Management Information Base for the Differentiated Services Architecture' as a Proposed Standard. In the same action, the IESG approved An Informal Management Model for Diffserv Routers for publication as an Informational RFC. These documents are the product of the Differentiated Services Working Group. The IESG contact persons are Allison Mankin and Scott Bradner. Technical Summary 'Management Information Base for the Differentiated Services Architecture' describes an SMIv2 MIB for devices implementing the Differentiated Services Architecture. It may be used both for monitoring and configuration of a router or switch capable of Differentiated Services functionality. This MIB is similar in design to what is described in the companion document "An Informal Management Model for Diffserv Routers", although it can be used to build functional data paths that the model would not well describe. The model conceptually describes ingress and egress interfaces of an n-port router, which may find some interfaces at a network edge and others facing into the network core. It describes the configuration and management of a Differentiated Services interface in terms of one or more Traffic Conditioning Block (TCB), each containing, arranged in the specified order, by definition, zero or more classifiers, meters, actions, algorithmic droppers, queues and schedulers. Traffic may be classified, and classified traffic may be metered. Each stream of traffic identified by a combination of classifiers and meters may have some set of actions performed on it; it may have dropping algorithms applied and it may ultimately be stored into a queue before being scheduled out to its next destination, either onto a link or to another TCB. At times, the treatment for a given packet must have any of those elements repeated. "An Informal Management Model for Diffserv Routers" models this by cascading multiple TCBs, while this MIB describes the policy by directly linking the functional data path elements. Working Group Summary There was significant discussion in the Working Group over a long time on these documents. The final documents reflect the consensus of the Working Group. Protocol Quality These documents were reviewed for the IESG by Scott Bradner and Harrie Hazewinkel. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@ns.ietf.org Thu Nov 15 15:31:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17993 for ; Thu, 15 Nov 2001 15:31:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA04637 for diffserv-archive@odin.ietf.org; Thu, 15 Nov 2001 15:31: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 PAA03464; Thu, 15 Nov 2001 15:05:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03436 for ; Thu, 15 Nov 2001 15:05:22 -0500 (EST) Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16241 for ; Thu, 15 Nov 2001 15:05:20 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id fAFK4DS09660 for ; Thu, 15 Nov 2001 15:04:13 -0500 (EST) Received: from zbl6c012.corpeast.baynetworks.com by zcars04e.ca.nortel.com; Thu, 15 Nov 2001 15:04:36 -0500 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id WMPW6WJH; Thu, 15 Nov 2001 15:03:41 -0500 Received: from tweedy.NortelNetworks.com (dhcp229-110.engeast.baynetworks.com [192.32.229.110]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VW7FB8ZL; Thu, 15 Nov 2001 15:03:42 -0500 Message-Id: <5.0.0.25.0.20011115144942.02854cc0@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 15 Nov 2001 15:02:33 -0500 To: "Da Silva, Pedro" From: "Kwok-Ho Chan" Subject: Re: [Diffserv] diffserv-pib-05 comments [sic] Cc: "'diffserv@ietf.org'" , "Kwok-Ho Chan" In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_18337273==_.ALT" X-Orig: 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 --=====================_18337273==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Pedro: Thank you for your comments. Please see response below. I believe you have sent the same comments again on the list. I will skip the duplicate. Please let me know if it is not duplicate. Thanks! -- Kwok -- At 03:22 PM 11/15/01 +0000, Da Silva, Pedro wrote: >The capability tables (e.g. qosIfMeteringCapsTable) have a UNIQUENESS clause >that includes the capability spec itself (as well as the direction from the >base class). This means that a user may specify more than one capability set >in one given direction, which in turn entails more work for the entity >managing and checking capabilities specs per se and capabilities specs >against policies. >Shouldn't the UNIQUENESS clause be restricted to the direction? No, I think the UNIQUENESS clause is correct as is. We do want to allow 2 or more entries in the qosIfMeteringCapsTable for the same direction, each one having different capabilities. This allows the device to have more than one different types of meter, may be for more than one kind of interface type. The specific data path using the different types of meter is specified by frwkIfCapSetTable entries provided by the Framework PIB -06 at http://www.ietf.org/internet-drafts/draft-ietf-rap-frameworkpib-06.txt I hope inspecting the qosIfMeteringCapsTable and frwkIfCapSetTable together will clarify the concerns you expressed. Please let me know if more explanation is needed. >Pedro > > >_______________________________________________ >diffserv mailing list >diffserv@ietf.org >https://www1.ietf.org/mailman/listinfo/diffserv >Archive: >http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html --=====================_18337273==_.ALT Content-Type: text/html; charset="us-ascii" Pedro:
Thank you for your comments.  Please see response below.
I believe you have sent the same comments again on the list.
I will skip the duplicate.  Please let me know if it is not duplicate.
Thanks!
-- Kwok --


At 03:22 PM 11/15/01 +0000, Da Silva, Pedro wrote:
The capability tables (e.g. qosIfMeteringCapsTable) have a UNIQUENESS clause
that includes the capability spec itself (as well as the direction from the
base class). This means that a user may specify more than one capability set
in one given direction, which in turn entails more work for the entity
managing and checking capabilities specs per se and capabilities specs
against policies.
Shouldn't the UNIQUENESS clause be restricted to the direction?

No, I think the UNIQUENESS clause is correct as is.  We do want to
allow 2 or more entries in the qosIfMeteringCapsTable for the same direction,
each one having different capabilities.  This allows the device to have more than
one different types of meter, may be for more than one kind of interface type.

The specific data path using the different types of meter is specified by
frwkIfCapSetTable entries provided by the Framework PIB -06 at
 http://www.ietf.org/internet-drafts/draft-ietf-rap-frameworkpib-06.txt

I hope inspecting the qosIfMeteringCapsTable and frwkIfCapSetTable together
will clarify the concerns you expressed.
Please let me know if more explanation is needed.


Pedro


_______________________________________________
diffserv mailing list
diffserv@ietf.org
https://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html
--=====================_18337273==_.ALT-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Fri Nov 16 06:37:37 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26190 for ; Fri, 16 Nov 2001 06:37:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA02692 for diffserv-archive@odin.ietf.org; Fri, 16 Nov 2001 06:37: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 GAA01728; Fri, 16 Nov 2001 06:03: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 GAA01707 for ; Fri, 16 Nov 2001 06:03:54 -0500 (EST) Received: from mail2.orchestream.com (mail2.orchestream.com [195.153.64.126]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25892 for ; Fri, 16 Nov 2001 06:03:49 -0500 (EST) Received: from rimmer.orchestream.com (rimmer.orchestream.com) by mail2.orchestream.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Fri, 16 Nov 2001 11:06:07 +0000 Received: from s1000.orchestream.com (s1000.orchestream.com [192.168.0.16]) by rimmer.orchestream.com (8.9.3/8.9.3) with ESMTP id KAA26698 for ; Fri, 16 Nov 2001 10:57:08 GMT Received: by s1000.orchestream.com with Internet Mail Service (5.5.2653.19) id ; Fri, 16 Nov 2001 10:58:19 -0000 Message-ID: From: "Da Silva, Pedro" To: "'diffserv@ietf.org'" Subject: RE: [Diffserv] diffserv-pib-05 comments [sic] Date: Fri, 16 Nov 2001 10:58:18 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C16E8D.991467E0" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C16E8D.991467E0 Content-Type: text/plain; charset="iso-8859-1" I thought the table was instantiated per interface type and not for all of the interfaces types, thus the confusion. Therefore it does make sense to have the caps specs in the uniqueness clause. Pedro -----Original Message----- From: Kwok-Ho Chan [mailto:khchan@nortelnetworks.com] Sent: Thursday, November 15, 2001 8:03 PM To: Da Silva, Pedro Cc: 'diffserv@ietf.org'; Kwok-Ho Chan Subject: Re: [Diffserv] diffserv-pib-05 comments [sic] Pedro: Thank you for your comments. Please see response below. I believe you have sent the same comments again on the list. I will skip the duplicate. Please let me know if it is not duplicate. Thanks! -- Kwok -- At 03:22 PM 11/15/01 +0000, Da Silva, Pedro wrote: The capability tables (e.g. qosIfMeteringCapsTable) have a UNIQUENESS clause that includes the capability spec itself (as well as the direction from the base class). This means that a user may specify more than one capability set in one given direction, which in turn entails more work for the entity managing and checking capabilities specs per se and capabilities specs against policies. Shouldn't the UNIQUENESS clause be restricted to the direction? No, I think the UNIQUENESS clause is correct as is. We do want to allow 2 or more entries in the qosIfMeteringCapsTable for the same direction, each one having different capabilities. This allows the device to have more than one different types of meter, may be for more than one kind of interface type. The specific data path using the different types of meter is specified by frwkIfCapSetTable entries provided by the Framework PIB -06 at http://www.ietf.org/internet-drafts/draft-ietf-rap-frameworkpib-06. txt I hope inspecting the qosIfMeteringCapsTable and frwkIfCapSetTable together will clarify the concerns you expressed. Please let me know if more explanation is needed. Pedro _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml ------_=_NextPart_001_01C16E8D.991467E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I=20 thought the table was instantiated per interface type and not for all = of the=20 interfaces types, thus the confusion.
Therefore it does make sense to have the = caps specs in=20 the uniqueness clause.
 
Pedro
-----Original Message-----
From: Kwok-Ho Chan=20 [mailto:khchan@nortelnetworks.com]
Sent: Thursday, November = 15, 2001=20 8:03 PM
To: Da Silva, Pedro
Cc: = 'diffserv@ietf.org';=20 Kwok-Ho Chan
Subject: Re: [Diffserv] diffserv-pib-05 = comments=20 [sic]

Pedro:
Thank you for your = comments.  Please=20 see response below.
I believe you have sent the same comments = again on the=20 list.
I will skip the duplicate.  Please let me know if it is = not=20 duplicate.
Thanks!
-- Kwok --


At 03:22 PM 11/15/01 = +0000, Da=20 Silva, Pedro wrote:
The capability tables = (e.g.=20 qosIfMeteringCapsTable) have a UNIQUENESS clause
that includes = the=20 capability spec itself (as well as the direction from the
base = class).=20 This means that a user may specify more than one capability = set
in one=20 given direction, which in turn entails more work for the = entity
managing=20 and checking capabilities specs per se and capabilities = specs
against=20 policies.
Shouldn't the UNIQUENESS clause be restricted to the=20 direction?

No, I think the UNIQUENESS clause is = correct as=20 is.  We do want to
allow 2 or more entries in the=20 qosIfMeteringCapsTable for the same direction,
each one having = different=20 capabilities.  This allows the device to have more than
one = different=20 types of meter, may be for more than one kind of interface = type.

The=20 specific data path using the different types of meter is specified=20 by
frwkIfCapSetTable entries provided by the Framework PIB -06=20 at
 http://www.ietf.org/internet-drafts/draft-ietf-rap-fr= ameworkpib-06.txt

I hope inspecting the=20 qosIfMeteringCapsTable and frwkIfCapSetTable together
will clarify = the=20 concerns you expressed.
Please let me know if more explanation is=20 needed.


Pedro


_________________________________________= ______
diffserv=20 mailing list
diffserv@ietf.org
https://www1.ietf.org/mailman/listinfo/diffservArchive:=20 http://www2.ietf.org/mail-archive/working-groups/diff= serv/current/maillist.html
------_=_NextPart_001_01C16E8D.991467E0-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Fri Nov 16 09:27:39 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02645 for ; Fri, 16 Nov 2001 09:27:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA06786 for diffserv-archive@odin.ietf.org; Fri, 16 Nov 2001 09:27: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 JAA06141; Fri, 16 Nov 2001 09:02: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 JAA06110 for ; Fri, 16 Nov 2001 09:02:50 -0500 (EST) Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01628 for ; Fri, 16 Nov 2001 09:02:46 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id fAGE1cS21907 for ; Fri, 16 Nov 2001 09:01:38 -0500 (EST) Received: from zbl6c012.corpeast.baynetworks.com by zcars04f.ca.nortel.com; Fri, 16 Nov 2001 09:02:11 -0500 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id WMPW6WYV; Fri, 16 Nov 2001 09:01:14 -0500 Received: from tweedy.NortelNetworks.com (dhcp229-110.engeast.baynetworks.com [192.32.229.110]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VW7FB9SK; Fri, 16 Nov 2001 09:01:16 -0500 Message-Id: <5.0.0.25.0.20011116085420.0287c510@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 16 Nov 2001 09:00:10 -0500 To: "Da Silva, Pedro" From: "Kwok-Ho Chan" Subject: RE: [Diffserv] diffserv-pib-05 comments [sic] Cc: "'diffserv@ietf.org'" In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_2908829==_.ALT" X-Orig: 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 --=====================_2908829==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Pedro: Thanks for raising the issue. If there is confusion, then I will improve the text. Please don't hesitate to raise any concerns. We need to fix them now before Last Call is done. Thanks! -- Kwok -- At 10:58 AM 11/16/01 +0000, Da Silva, Pedro wrote: >I thought the table was instantiated per interface type and not for all of >the interfaces types, thus the confusion. >Therefore it does make sense to have the caps specs in the uniqueness clause. > >Pedro >-----Original Message----- >From: Kwok-Ho Chan [mailto:khchan@nortelnetworks.com] >Sent: Thursday, November 15, 2001 8:03 PM >To: Da Silva, Pedro >Cc: 'diffserv@ietf.org'; Kwok-Ho Chan >Subject: Re: [Diffserv] diffserv-pib-05 comments [sic] > >Pedro: >Thank you for your comments. Please see response below. >I believe you have sent the same comments again on the list. >I will skip the duplicate. Please let me know if it is not duplicate. >Thanks! >-- Kwok -- > > > >At 03:22 PM 11/15/01 +0000, Da Silva, Pedro wrote: >>The capability tables (e.g. qosIfMeteringCapsTable) have a UNIQUENESS clause >>that includes the capability spec itself (as well as the direction from the >>base class). This means that a user may specify more than one capability set >>in one given direction, which in turn entails more work for the entity >>managing and checking capabilities specs per se and capabilities specs >>against policies. >>Shouldn't the UNIQUENESS clause be restricted to the direction? >No, I think the UNIQUENESS clause is correct as is. We do want to >allow 2 or more entries in the qosIfMeteringCapsTable for the same direction, >each one having different capabilities. This allows the device to have >more than >one different types of meter, may be for more than one kind of interface type. > >The specific data path using the different types of meter is specified by >frwkIfCapSetTable entries provided by the Framework PIB -06 at > http://www.ietf.org/internet-drafts/draft-ietf-rap-frameworkpib-06.txt > >I hope inspecting the qosIfMeteringCapsTable and frwkIfCapSetTable together >will clarify the concerns you expressed. >Please let me know if more explanation is needed. > > > >>Pedro >> >> >> >>_______________________________________________ >>diffserv mailing list >>diffserv@ietf.org >>https://www1.ietf.org/mailman/listinfo/diffserv >>Archive: >>http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html --=====================_2908829==_.ALT Content-Type: text/html; charset="us-ascii" Pedro:
Thanks for raising the issue.
If there is confusion, then I will improve the text.
Please don't hesitate to raise any concerns.
We need to fix them now before Last Call is done.
Thanks!
-- Kwok --

At 10:58 AM 11/16/01 +0000, Da Silva, Pedro wrote:
I thought the table was instantiated per interface type and not for all of the interfaces types, thus the confusion.
Therefore it does make sense to have the caps specs in the uniqueness clause.
 
Pedro
-----Original Message-----
From: Kwok-Ho Chan [mailto:khchan@nortelnetworks.com]
Sent: Thursday, November 15, 2001 8:03 PM
To: Da Silva, Pedro
Cc: 'diffserv@ietf.org'; Kwok-Ho Chan
Subject: Re: [Diffserv] diffserv-pib-05 comments [sic]
Pedro:
Thank you for your comments.  Please see response below.
I believe you have sent the same comments again on the list.
I will skip the duplicate.  Please let me know if it is not duplicate.
Thanks!
-- Kwok --



At 03:22 PM 11/15/01 +0000, Da Silva, Pedro wrote:
The capability tables (e.g. qosIfMeteringCapsTable) have a UNIQUENESS clause
that includes the capability spec itself (as well as the direction from the
base class). This means that a user may specify more than one capability set
in one given direction, which in turn entails more work for the entity
managing and checking capabilities specs per se and capabilities specs
against policies.
Shouldn't the UNIQUENESS clause be restricted to the direction?
No, I think the UNIQUENESS clause is correct as is.  We do want to
allow 2 or more entries in the qosIfMeteringCapsTable for the same direction,
each one having different capabilities.  This allows the device to have more than
one different types of meter, may be for more than one kind of interface type.

The specific data path using the different types of meter is specified by
frwkIfCapSetTable entries provided by the Framework PIB -06 at
 http://www.ietf.org/internet-drafts/draft-ietf-rap-frameworkpib-06.txt
I hope inspecting the qosIfMeteringCapsTable and frwkIfCapSetTable together
will clarify the concerns you expressed.
Please let me know if more explanation is needed.



Pedro



_______________________________________________
diffserv mailing list
diffserv@ietf.org
https://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html
--=====================_2908829==_.ALT-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Sat Nov 17 21:15:41 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02022 for ; Sat, 17 Nov 2001 21:15:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA00521 for diffserv-archive@odin.ietf.org; Sat, 17 Nov 2001 21:15:43 -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 UAA29508; Sat, 17 Nov 2001 20:53:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA29444 for ; Sat, 17 Nov 2001 20:53:26 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01774; Sat, 17 Nov 2001 20:53:24 -0500 (EST) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id fAI1qsW27060; Sat, 17 Nov 2001 17:52:54 -0800 (PST) Received: from ANDREAWW2K (andreaw-frame1.cisco.com [10.19.253.186]) by mira-sjcm-2.cisco.com (Mirapoint) with SMTP id AAU52255; Sat, 17 Nov 2001 17:52:51 -0800 (PST) From: "Andrea Westerinen" To: "Dan Grossman" Cc: "Diffserv@Ietf. Org" , "Policy@Ietf. Org" , "Bert Wijnen \(Bert\)" Subject: RE: FW: [Diffserv] Informal WG last call for draft-ietf-diffserv-new-terms-06.txt Date: Sat, 17 Nov 2001 17:55:31 -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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: 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 Focusing on #4. The text says ... "Therefore, the relationship between an SLS and a service provisioning policy is that the latter is, in part, the set of rules that define the parameters and range of values that may be in the former." My inclination at this point is to leave it as it is, unless Andrea can come up with a concise sentence or two that can be dropped in. I think that policy aware readers will understand that we don't intend to be restrictive, and non-policy aware readers won't be confused. Can we say "the set of rules that IMPLEMENT the parameters and range of values ..."? My problem is with the word DEFINES. Andrea -----Original Message----- From: Andrea Westerinen [mailto:andreaw@cisco.com] Sent: Wednesday, November 14, 2001 1:53 PM To: Dan Grossman Cc: Diffserv@Ietf. Org; Policy@Ietf. Org; Bert Wijnen (Bert) Subject: RE: FW: [Diffserv] Informal WG last call for draft-ietf-diffserv-new-terms-06.txt Pulling everything up here. It looks like #4 needs a bit more discussion - however, it is not a major issue for me. 1. PolTerm supports SLAs as contractual - Agreed to document this alignment. 2. Dan said, "I'd be hesitant to alter the Diffserv definition, since this was subject of a great deal of working group debate. However, some words to the effect that you suggest would be appropriate." - This is all that I was suggesting. I totally understand how painful these things can be - and I think that the definitions are aligned. PolTerm is just broader and this was intentional. 3. Normative reference to PolTerm - OK. 4. Service provisioning policy "defines and manages to parameters and range of values" in an SLS. Dan asked how rules can manage to parameters and ranges. - This really depends on your rules. For static "preconfiguration" rules, then all that you are doing is defining what you want, and making it so. In the more general case of provisioning rules, you might have "preconfiguration" rules, and other "runtime" rules that are invoked "if ." If/when something happens, then the actions of the other rules might manipulate the environment to maintain (ie, "manage to") the parameters and ranges, or switch to new parameters, or ignore parameters/ranges, etc. I was asking about whether we should generalize what a "provisioning rule" might do. 5-7. Nits and typos - Will be cleaned up. Andrea _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Sun Nov 18 18:02:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29569 for ; Sun, 18 Nov 2001 18:02:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA28936 for diffserv-archive@odin.ietf.org; Sun, 18 Nov 2001 18:02:22 -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 RAA27963; Sun, 18 Nov 2001 17:45:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27899 for ; Sun, 18 Nov 2001 17:45:29 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29392; Sun, 18 Nov 2001 17:45:23 -0500 (EST) Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id fAIMitE10179; Sun, 18 Nov 2001 14:44:55 -0800 (PST) Received: from SBRIM-W2K (sjc-vpn2-593.cisco.com [10.21.114.81]) by airborne.cisco.com (Mirapoint) with SMTP id AAF21412; Sun, 18 Nov 2001 14:44:50 -0800 (PST) Received: by SBRIM-W2K (sSMTP sendmail emulation); Sun, 18 Nov 2001 17:44:53 -0500 Date: Sun, 18 Nov 2001 17:44:53 -0500 From: Scott Brim To: Andrea Westerinen Cc: Dan Grossman , "Diffserv@Ietf. Org" , "Policy@Ietf. Org" , "Bert Wijnen (Bert)" Subject: Re: FW: [Diffserv] Informal WG last call for draft-ietf-diffserv-new-terms-06.txt Message-ID: <20011118174452.A1544@SBRIM-W2K> Mail-Followup-To: Scott Brim , Andrea Westerinen , Dan Grossman , "Diffserv@Ietf. Org" , "Policy@Ietf. Org" , "Bert Wijnen (Bert)" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from andreaw@cisco.com on Sat, Nov 17, 2001 at 05:55:31PM -0800 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 On Sat, Nov 17, 2001 05:55:31PM -0800, Andrea Westerinen wrote: > Focusing on #4. > > The text says ... "Therefore, the relationship between an SLS and a service > provisioning policy is that the latter is, in part, the set of rules that > define the parameters and range of values that may be in the former." > > My inclination at this point is to leave it as it is, unless Andrea > can come > up with a concise sentence or two that can be dropped in. I think that > policy > aware readers will understand that we don't intend to be restrictive, and > non-policy aware readers won't be confused. > > Can we say "the set of rules that IMPLEMENT the parameters and range of > values ..."? My problem is with the word DEFINES. "Implements" is worse because the rules have nothing to do with implementation (a standardization absolute). If you think "defines" crosses a boundary, I suggest "specifies". _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Sun Nov 18 22:00:49 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02228 for ; Sun, 18 Nov 2001 22:00:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA04177 for diffserv-archive@odin.ietf.org; Sun, 18 Nov 2001 22:00:52 -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 VAA03077; Sun, 18 Nov 2001 21:44:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA03014 for ; Sun, 18 Nov 2001 21:43:55 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02054; Sun, 18 Nov 2001 21:43:51 -0500 (EST) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id fAJ2hGH08561; Sun, 18 Nov 2001 18:43:16 -0800 (PST) Received: from ANDREAWW2K (andreaw-frame1.cisco.com [10.19.253.186]) by mira-sjcm-2.cisco.com (Mirapoint) with SMTP id AAU58462; Sun, 18 Nov 2001 18:43:15 -0800 (PST) From: "Andrea Westerinen" To: "Scott Brim" Cc: "Dan Grossman" , "Diffserv@Ietf. Org" , "Policy@Ietf. Org" , "Bert Wijnen \(Bert\)" Subject: RE: FW: [Diffserv] Informal WG last call for draft-ietf-diffserv-new-terms-06.txt Date: Sun, 18 Nov 2001 18:45:54 -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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <20011118174452.A1544@SBRIM-W2K> 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 But, my issue is with the word, "define" or "specify". IMHO, the SLS "defines" the values or behavior, and the rules "act on" or "realize" the definition. I didn't equate "implement" with "implementation", but I can see the problem with that word. Does "realize" make it better or worse ("... the set of rules that realize the parameters and range ...")? Andrea -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of Scott Brim Sent: Sunday, November 18, 2001 2:45 PM To: Andrea Westerinen Cc: Dan Grossman; Diffserv@Ietf. Org; Policy@Ietf. Org; Bert Wijnen (Bert) Subject: Re: FW: [Diffserv] Informal WG last call for draft-ietf-diffserv-new-terms-06.txt On Sat, Nov 17, 2001 05:55:31PM -0800, Andrea Westerinen wrote: > Focusing on #4. > > The text says ... "Therefore, the relationship between an SLS and a service > provisioning policy is that the latter is, in part, the set of rules that > define the parameters and range of values that may be in the former." > > My inclination at this point is to leave it as it is, unless Andrea > can come > up with a concise sentence or two that can be dropped in. I think that > policy > aware readers will understand that we don't intend to be restrictive, and > non-policy aware readers won't be confused. > > Can we say "the set of rules that IMPLEMENT the parameters and range of > values ..."? My problem is with the word DEFINES. "Implements" is worse because the rules have nothing to do with implementation (a standardization absolute). If you think "defines" crosses a boundary, I suggest "specifies". _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Sun Nov 18 23:22:00 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03792 for ; Sun, 18 Nov 2001 23:22:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA06454 for diffserv-archive@odin.ietf.org; Sun, 18 Nov 2001 23:22:04 -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 XAA05764; Sun, 18 Nov 2001 23:06:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA05737 for ; Sun, 18 Nov 2001 23:06:28 -0500 (EST) Received: from mailweb20.rediffmail.com (IDENT:qmailr@[203.199.83.144]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA03662 for ; Sun, 18 Nov 2001 23:06:23 -0500 (EST) Received: (qmail 28381 invoked by uid 510); 19 Nov 2001 04:06:55 -0000 Date: 19 Nov 2001 04:06:55 -0000 Message-ID: <20011119040655.28380.qmail@mailweb20.rediffmail.com> Received: from unknown (203.200.15.20) by rediffmail.com via HTTP; 19 Nov 2001 04:06:55 -0000 MIME-Version: 1.0 From: "Srinath . Pradeep" Reply-To: "Srinath . Pradeep" To: diffserv@ietf.org Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id XAA05738 Subject: [Diffserv] what i need? Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 8bit Hello .*; Goood morning, i have to implement a simple DiffServ. can i use a simple Network Simulator for this. Thanks in advance Pradeep _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Mon Nov 19 03:55:11 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22710 for ; Mon, 19 Nov 2001 03:55:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA22415 for diffserv-archive@odin.ietf.org; Mon, 19 Nov 2001 03:55:12 -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 DAA20999; Mon, 19 Nov 2001 03:34:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA20972 for ; Mon, 19 Nov 2001 03:33:58 -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 DAA22337 for ; Mon, 19 Nov 2001 03:33:56 -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 JAA04866; Mon, 19 Nov 2001 09:33:27 +0100 Received: from dhcp22-51.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA58784 from ; Mon, 19 Nov 2001 09:33:25 +0100 Message-Id: <3BF8C3F3.E08F5140@hursley.ibm.com> Date: Mon, 19 Nov 2001 09:33:55 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: "Srinath . Pradeep" Cc: diffserv@ietf.org Subject: Re: [Diffserv] what i need? References: <20011119040655.28380.qmail@mailweb20.rediffmail.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 Pradeep, This list is for the standardisation work of the diffserv working group. Please send implementation questions to the diffserv implementation list at http://www.atnf.csiro.au/news/exploders/dsimplementation.html Thanks Brian Carpenter diffserv WG co-chair "Srinath . Pradeep" wrote: > > Hello .*; > Goood morning, > i have to implement a simple DiffServ. > can i use a simple Network Simulator for this. > Thanks in advance > Pradeep _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Mon Nov 19 03:57:03 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22748 for ; Mon, 19 Nov 2001 03:57:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA22606 for diffserv-archive@odin.ietf.org; Mon, 19 Nov 2001 03:57:04 -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 DAA21405; Mon, 19 Nov 2001 03:45:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA21341 for ; Mon, 19 Nov 2001 03:45:02 -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 DAA22435; Mon, 19 Nov 2001 03:44:59 -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 JAA07332; Mon, 19 Nov 2001 09:44:27 +0100 Received: from dhcp22-51.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA45898 from ; Mon, 19 Nov 2001 09:44:25 +0100 Message-Id: <3BF8C67D.9FF00C46@hursley.ibm.com> Date: Mon, 19 Nov 2001 09:44:45 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Andrea Westerinen Cc: Scott Brim , Dan Grossman , "Diffserv@Ietf. Org" , "Policy@Ietf. Org" , "Bert Wijnen (Bert)" Subject: Re: FW: [Diffserv] Informal WG last call for draft-ietf-diffserv-new-terms-06.txt 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 The way we have taken to using the word "policy" in our technology is a bit strange - in normal English, "policy" is more abstract and general than a specific set of rules. Hence the problem, I think. How about "express" instead of "define"? Brian Andrea Westerinen wrote: > > But, my issue is with the word, "define" or "specify". IMHO, the SLS > "defines" the values or behavior, and the rules "act on" or "realize" the > definition. I didn't equate "implement" with "implementation", but I can > see the problem with that word. > > Does "realize" make it better or worse ("... the set of rules that realize > the parameters and range ...")? > > Andrea > > -----Original Message----- > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf > Of Scott Brim > Sent: Sunday, November 18, 2001 2:45 PM > To: Andrea Westerinen > Cc: Dan Grossman; Diffserv@Ietf. Org; Policy@Ietf. Org; Bert Wijnen > (Bert) > Subject: Re: FW: [Diffserv] Informal WG last call for > draft-ietf-diffserv-new-terms-06.txt > > On Sat, Nov 17, 2001 05:55:31PM -0800, Andrea Westerinen wrote: > > Focusing on #4. > > > > The text says ... "Therefore, the relationship between an SLS and a > service > > provisioning policy is that the latter is, in part, the set of rules that > > define the parameters and range of values that may be in the former." > > > > My inclination at this point is to leave it as it is, unless Andrea > > can come > > up with a concise sentence or two that can be dropped in. I think that > > policy > > aware readers will understand that we don't intend to be restrictive, and > > non-policy aware readers won't be confused. > > > > Can we say "the set of rules that IMPLEMENT the parameters and range of > > values ..."? My problem is with the word DEFINES. > > "Implements" is worse because the rules have nothing to do with > implementation (a standardization absolute). If you think "defines" > crosses a boundary, I suggest "specifies". > > _______________________________________________ _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Mon Nov 19 04:04:04 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22900 for ; Mon, 19 Nov 2001 04:04:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA23333 for diffserv-archive@odin.ietf.org; Mon, 19 Nov 2001 04:04:05 -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 DAA22095; Mon, 19 Nov 2001 03:52:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA22030 for ; Mon, 19 Nov 2001 03:52:19 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22652; Mon, 19 Nov 2001 03:52:13 -0500 (EST) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id fAJ8phE08479; Mon, 19 Nov 2001 00:51:43 -0800 (PST) Received: from ANDREAWW2K (andreaw-frame1.cisco.com [10.19.253.186]) by mira-sjcm-2.cisco.com (Mirapoint) with SMTP id AAU61230; Mon, 19 Nov 2001 00:51:41 -0800 (PST) From: "Andrea Westerinen" To: "Brian E Carpenter" Cc: "Scott Brim" , "Dan Grossman" , "Diffserv@Ietf. Org" , "Policy@Ietf. Org" , "Bert Wijnen \(Bert\)" Subject: RE: FW: [Diffserv] Informal WG last call for draft-ietf-diffserv-new-terms-06.txt Date: Mon, 19 Nov 2001 00:54:20 -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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <3BF8C67D.9FF00C46@hursley.ibm.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 "Express" is better. I am ok with that. Thanks. Andrea -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of Brian E Carpenter Sent: Monday, November 19, 2001 12:45 AM To: Andrea Westerinen Cc: Scott Brim; Dan Grossman; Diffserv@Ietf. Org; Policy@Ietf. Org; Bert Wijnen (Bert) Subject: Re: FW: [Diffserv] Informal WG last call for draft-ietf-diffserv-new-terms-06.txt The way we have taken to using the word "policy" in our technology is a bit strange - in normal English, "policy" is more abstract and general than a specific set of rules. Hence the problem, I think. How about "express" instead of "define"? Brian Andrea Westerinen wrote: > > But, my issue is with the word, "define" or "specify". IMHO, the SLS > "defines" the values or behavior, and the rules "act on" or "realize" the > definition. I didn't equate "implement" with "implementation", but I can > see the problem with that word. > > Does "realize" make it better or worse ("... the set of rules that realize > the parameters and range ...")? > > Andrea > > -----Original Message----- > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf > Of Scott Brim > Sent: Sunday, November 18, 2001 2:45 PM > To: Andrea Westerinen > Cc: Dan Grossman; Diffserv@Ietf. Org; Policy@Ietf. Org; Bert Wijnen > (Bert) > Subject: Re: FW: [Diffserv] Informal WG last call for > draft-ietf-diffserv-new-terms-06.txt > > On Sat, Nov 17, 2001 05:55:31PM -0800, Andrea Westerinen wrote: > > Focusing on #4. > > > > The text says ... "Therefore, the relationship between an SLS and a > service > > provisioning policy is that the latter is, in part, the set of rules that > > define the parameters and range of values that may be in the former." > > > > My inclination at this point is to leave it as it is, unless Andrea > > can come > > up with a concise sentence or two that can be dropped in. I think that > > policy > > aware readers will understand that we don't intend to be restrictive, and > > non-policy aware readers won't be confused. > > > > Can we say "the set of rules that IMPLEMENT the parameters and range of > > values ..."? My problem is with the word DEFINES. > > "Implements" is worse because the rules have nothing to do with > implementation (a standardization absolute). If you think "defines" > crosses a boundary, I suggest "specifies". > > _______________________________________________ _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Mon Nov 19 08:34:03 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27740 for ; Mon, 19 Nov 2001 08:34:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA00877 for diffserv-archive@odin.ietf.org; Mon, 19 Nov 2001 08:34:03 -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 IAA29741; Mon, 19 Nov 2001 08:18: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 IAA29710 for ; Mon, 19 Nov 2001 08:18:50 -0500 (EST) Received: from mail2.orchestream.com (mail2.orchestream.com [195.153.64.126]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26488 for ; Mon, 19 Nov 2001 08:18:49 -0500 (EST) Received: from rimmer.orchestream.com (rimmer.orchestream.com) by mail2.orchestream.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Mon, 19 Nov 2001 13:21:07 +0000 Received: from s1000.orchestream.com (s1000.orchestream.com [192.168.0.16]) by rimmer.orchestream.com (8.9.3/8.9.3) with ESMTP id NAA14079 for ; Mon, 19 Nov 2001 13:11:51 GMT Received: by s1000.orchestream.com with Internet Mail Service (5.5.2653.19) id ; Mon, 19 Nov 2001 13:13:12 -0000 Message-ID: From: "Da Silva, Pedro" To: "'diffserv@ietf.org'" Subject: RE: [Diffserv] diffserv-pib-05 comments [sic] Date: Mon, 19 Nov 2001 13:13:06 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C170FB.ED51D570" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C170FB.ED51D570 Content-Type: text/plain; charset="iso-8859-1" I do have a concern about how the DiffServ PIB fits in the Policy WG drafts-stds In the Policy WG we have [managed element]--[role]--[policy] relationships, where role is 'an administratively specified characteristic of a managed element'. QPIM goes further to say that 'The use of roles for mapping policy to network elements provides an efficient and simple method for compact and abstract policy definition. A given abstract policy may be mapped to a group of network elements without the need to specify configuration for each of those elements based on the capabilities of any one individual element.' On the other hand, in the DiffServ PIB we have [interface]--[userRole+capabilityName+direction]--[policy] The DS PIB has a policy selector that is more than just a role and includes what QPIM explicitly excludes, capability specs. So the semantics of roles are different between the two. And the concept of 'managed element' has been limited to being an interface in the DiffServ PIB whereas the Policy WG drafts-stds imply that it could be more than interfaces. There is no specific question, it's more of a 'what do you think?' question. Pedro -----Original Message----- From: Kwok-Ho Chan [mailto:khchan@nortelnetworks.com] Sent: Friday, November 16, 2001 2:00 PM To: Da Silva, Pedro Cc: 'diffserv@ietf.org' Subject: RE: [Diffserv] diffserv-pib-05 comments [sic] Pedro: Thanks for raising the issue. If there is confusion, then I will improve the text. Please don't hesitate to raise any concerns. We need to fix them now before Last Call is done. Thanks! -- Kwok -- At 10:58 AM 11/16/01 +0000, Da Silva, Pedro wrote: I thought the table was instantiated per interface type and not for all of the interfaces types, thus the confusion. Therefore it does make sense to have the caps specs in the uniqueness clause. Pedro -----Original Message----- From: Kwok-Ho Chan [ mailto:khchan@nortelnetworks.com ] Sent: Thursday, November 15, 2001 8:03 PM To: Da Silva, Pedro Cc: 'diffserv@ietf.org'; Kwok-Ho Chan Subject: Re: [Diffserv] diffserv-pib-05 comments [sic] Pedro: Thank you for your comments. Please see response below. I believe you have sent the same comments again on the list. I will skip the duplicate. Please let me know if it is not duplicate. Thanks! -- Kwok -- At 03:22 PM 11/15/01 +0000, Da Silva, Pedro wrote: The capability tables (e.g. qosIfMeteringCapsTable) have a UNIQUENESS clause that includes the capability spec itself (as well as the direction from the base class). This means that a user may specify more than one capability set in one given direction, which in turn entails more work for the entity managing and checking capabilities specs per se and capabilities specs against policies. Shouldn't the UNIQUENESS clause be restricted to the direction? No, I think the UNIQUENESS clause is correct as is. We do want to allow 2 or more entries in the qosIfMeteringCapsTable for the same direction, each one having different capabilities. This allows the device to have more than one different types of meter, may be for more than one kind of interface type. The specific data path using the different types of meter is specified by frwkIfCapSetTable entries provided by the Framework PIB -06 at http://www.ietf.org/internet-drafts/draft-ietf-rap-frameworkpib-06.txt I hope inspecting the qosIfMeteringCapsTable and frwkIfCapSetTable together will clarify the concerns you expressed. Please let me know if more explanation is needed. Pedro _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml ------_=_NextPart_001_01C170FB.ED51D570 Content-Type: text/html; charset="iso-8859-1"
I do have a concern about how the DiffServ PIB fits in the Policy WG drafts-stds
 
In the Policy WG we have [managed element]--[role]--[policy] relationships, where role is 'an administratively specified characteristic of a managed element'. QPIM goes further to say that 'The use of roles for mapping policy to network elements provides an efficient and simple method for compact and abstract policy definition. A given abstract policy may be mapped to a group of network elements without the need to specify configuration for each of those elements based on the capabilities of any one individual element.'
 
On the other hand, in the DiffServ PIB we have [interface]--[userRole+capabilityName+direction]--[policy]
The DS PIB has a policy selector that is more than just a role and includes what QPIM explicitly excludes, capability specs.
 
So the semantics of roles are different between the two. And the concept of 'managed element' has been limited to being an interface in the DiffServ PIB whereas the Policy WG drafts-stds imply that it could be more than interfaces.
 
There is no specific question, it's more of a 'what do you think?' question.
 
Pedro
 
 -----Original Message-----
From: Kwok-Ho Chan [mailto:khchan@nortelnetworks.com]
Sent: Friday, November 16, 2001 2:00 PM
To: Da Silva, Pedro
Cc: 'diffserv@ietf.org'
Subject: RE: [Diffserv] diffserv-pib-05 comments [sic]

Pedro:
Thanks for raising the issue.
If there is confusion, then I will improve the text.
Please don't hesitate to raise any concerns.
We need to fix them now before Last Call is done.
Thanks!
-- Kwok --

At 10:58 AM 11/16/01 +0000, Da Silva, Pedro wrote:
I thought the table was instantiated per interface type and not for all of the interfaces types, thus the confusion.
Therefore it does make sense to have the caps specs in the uniqueness clause.
 
Pedro
-----Original Message-----
From: Kwok-Ho Chan [mailto:khchan@nortelnetworks.com]
Sent: Thursday, November 15, 2001 8:03 PM
To: Da Silva, Pedro
Cc: 'diffserv@ietf.org'; Kwok-Ho Chan
Subject: Re: [Diffserv] diffserv-pib-05 comments [sic]
Pedro:
Thank you for your comments.  Please see response below.
I believe you have sent the same comments again on the list.
I will skip the duplicate.  Please let me know if it is not duplicate.
Thanks!
-- Kwok --



At 03:22 PM 11/15/01 +0000, Da Silva, Pedro wrote:
The capability tables (e.g. qosIfMeteringCapsTable) have a UNIQUENESS clause
that includes the capability spec itself (as well as the direction from the
base class). This means that a user may specify more than one capability set
in one given direction, which in turn entails more work for the entity
managing and checking capabilities specs per se and capabilities specs
against policies.
Shouldn't the UNIQUENESS clause be restricted to the direction?
No, I think the UNIQUENESS clause is correct as is.  We do want to
allow 2 or more entries in the qosIfMeteringCapsTable for the same direction,
each one having different capabilities.  This allows the device to have more than
one different types of meter, may be for more than one kind of interface type.

The specific data path using the different types of meter is specified by
frwkIfCapSetTable entries provided by the Framework PIB -06 at
 http://www.ietf.org/internet-drafts/draft-ietf-rap-frameworkpib-06.txt
I hope inspecting the qosIfMeteringCapsTable and frwkIfCapSetTable together
will clarify the concerns you expressed.
Please let me know if more explanation is needed.



Pedro



_______________________________________________
diffserv mailing list
diffserv@ietf.org
https://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html
------_=_NextPart_001_01C170FB.ED51D570-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Mon Nov 19 09:54:27 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02230 for ; Mon, 19 Nov 2001 09:54:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA04123 for diffserv-archive@odin.ietf.org; Mon, 19 Nov 2001 09:54:27 -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 JAA03520; Mon, 19 Nov 2001 09:41: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 JAA03489 for ; Mon, 19 Nov 2001 09:41:13 -0500 (EST) Received: from EXECDSL.COM (ns.execdsl.net [208.184.15.238]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01463 for ; Mon, 19 Nov 2001 09:41:12 -0500 (EST) Received: from [208.36.140.3] (HELO joel) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 2678370; Mon, 19 Nov 2001 09:41:14 -0500 Message-Id: <4.2.2.20011119093735.00cd9100@mail.stevecrocker.com> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 19 Nov 2001 09:40:59 -0500 To: "Da Silva, Pedro" , "'diffserv@ietf.org'" From: "Joel M. Halpern" Subject: RE: [Diffserv] diffserv-pib-05 comments [sic] In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org PIBs are a mechanism to describe policy. They can be thought of as a data model or as a policy implementation technology. Policy Framework work is an information model. As such, one expects some change of details when one maps between them. The QPIM/ / QDDIM work is carefully designed to be able to represent DiffServ requirements. The Diffserv PIB is carefully designed to represent not just the abstract policy needs, but the details of DiffServ delivery. The two are not identical, and are not expected to be identical./ The difference in "role" is the difference in the policy concept of role and the COPS implementation of role. The differences are actually very minor. Yours, Joel M. Halpern At 01:13 PM 11/19/01 +0000, Da Silva, Pedro wrote: >I do have a concern about how the DiffServ PIB fits in the Policy WG >drafts-stds > >In the Policy WG we have [managed element]--[role]--[policy] >relationships, where role is 'an administratively specified characteristic >of a managed element'. QPIM goes further to say that 'The use of roles for >mapping policy to network elements provides an efficient and simple method >for compact and abstract policy definition. A given abstract policy may be >mapped to a group of network elements without the need to specify >configuration for each of those elements based on the capabilities of any >one individual element.' > >On the other hand, in the DiffServ PIB we have >[interface]--[userRole+capabilityName+direction]--[policy] >The DS PIB has a policy selector that is more than just a role and >includes what QPIM explicitly excludes, capability specs. > >So the semantics of roles are different between the two. And the concept >of 'managed element' has been limited to being an interface in the >DiffServ PIB whereas the Policy WG drafts-stds imply that it could be more >than interfaces. > >There is no specific question, it's more of a 'what do you think?' question. > >Pedro > > -----Original Message----- >From: Kwok-Ho Chan [mailto:khchan@nortelnetworks.com] >Sent: Friday, November 16, 2001 2:00 PM >To: Da Silva, Pedro >Cc: 'diffserv@ietf.org' >Subject: RE: [Diffserv] diffserv-pib-05 comments [sic] >Pedro: >Thanks for raising the issue. >If there is confusion, then I will improve the text. >Please don't hesitate to raise any concerns. >We need to fix them now before Last Call is done. >Thanks! >-- Kwok -- > >At 10:58 AM 11/16/01 +0000, Da Silva, Pedro wrote: >>I thought the table was instantiated per interface type and not for all >>of the interfaces types, thus the confusion. >>Therefore it does make sense to have the caps specs in the uniqueness >>clause. >> >>Pedro >>-----Original Message----- >>From: Kwok-Ho Chan [mailto:khchan@nortelnetworks.com] >>Sent: Thursday, November 15, 2001 8:03 PM >>To: Da Silva, Pedro >>Cc: 'diffserv@ietf.org'; Kwok-Ho Chan >>Subject: Re: [Diffserv] diffserv-pib-05 comments [sic] >> >>Pedro: >>Thank you for your comments. Please see response below. >>I believe you have sent the same comments again on the list. >>I will skip the duplicate. Please let me know if it is not duplicate. >>Thanks! >>-- Kwok -- >> >> >> >> >> >>At 03:22 PM 11/15/01 +0000, Da Silva, Pedro wrote: >>>The capability tables (e.g. qosIfMeteringCapsTable) have a UNIQUENESS >>>clause >>>that includes the capability spec itself (as well as the direction from the >>>base class). This means that a user may specify more than one capability >>>set >>>in one given direction, which in turn entails more work for the entity >>>managing and checking capabilities specs per se and capabilities specs >>>against policies. >>>Shouldn't the UNIQUENESS clause be restricted to the direction? >>No, I think the UNIQUENESS clause is correct as is. We do want to >>allow 2 or more entries in the qosIfMeteringCapsTable for the same >>direction, >>each one having different capabilities. This allows the device to have >>more than >>one different types of meter, may be for more than one kind of interface >>type. >>The specific data path using the different types of meter is specified by >>frwkIfCapSetTable entries provided by the Framework PIB -06 at >> http://www.ietf.org/internet-drafts/draft-ietf-rap-frameworkpib-06.txt >> >>I hope inspecting the qosIfMeteringCapsTable and frwkIfCapSetTable together >>will clarify the concerns you expressed. >>Please let me know if more explanation is needed. >> >> >> >> >> >>>Pedro >>> >>> >>> >>> >>> >>>_______________________________________________ >>>diffserv mailing list >>>diffserv@ietf.org >>>https://www1.ietf.org/mailman/listinfo/diffserv >>>Archive: >>>http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Mon Nov 19 11:00:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06238 for ; Mon, 19 Nov 2001 11:00:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA06879 for diffserv-archive@odin.ietf.org; Mon, 19 Nov 2001 11:00: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 KAA06040; Mon, 19 Nov 2001 10:48:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05902 for ; Mon, 19 Nov 2001 10:48:25 -0500 (EST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05496; Mon, 19 Nov 2001 10:48:23 -0500 (EST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id IAA29876; Mon, 19 Nov 2001 08:48:09 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id IAA11253; Mon, 19 Nov 2001 08:48:09 -0700 (MST)] Received: from dma.isg.mot.com (nrlab-08.dma.isg.mot.com [150.21.50.46]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id KAA08931; Mon, 19 Nov 2001 10:48:06 -0500 (EST) Message-Id: <200111191548.KAA08931@noah.dma.isg.mot.com> X-Mailer: exmh version 1.6.7 5/3/96 To: "Andrea Westerinen" cc: "Brian E Carpenter" , "Scott Brim" , "Diffserv@Ietf. Org" , "Policy@Ietf. Org" , "Bert Wijnen \(Bert\)" Subject: Re: FW: [Diffserv] Informal WG last call for draft-ietf-diffserv-new-terms-06.txt In-reply-to: Your message of "Mon, 19 Nov 2001 00:54:20 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 19 Nov 2001 10:48:05 -0500 From: Dan Grossman 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 Express it will be. > "Express" is better. I am ok with that. > Thanks. > Andrea > > -----Original Message----- > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf > Of Brian E Carpenter > Sent: Monday, November 19, 2001 12:45 AM > To: Andrea Westerinen > Cc: Scott Brim; Dan Grossman; Diffserv@Ietf. Org; Policy@Ietf. Org; Bert > Wijnen (Bert) > Subject: Re: FW: [Diffserv] Informal WG last call for > draft-ietf-diffserv-new-terms-06.txt > > > The way we have taken to using the word "policy" in our technology is > a bit strange - in normal English, "policy" is more abstract and general > than a specific set of rules. Hence the problem, I think. > > How about "express" instead of "define"? > > Brian > > Andrea Westerinen wrote: > > > > But, my issue is with the word, "define" or "specify". IMHO, the SLS > > "defines" the values or behavior, and the rules "act on" or "realize" the > > definition. I didn't equate "implement" with "implementation", but I can > > see the problem with that word. > > > > Does "realize" make it better or worse ("... the set of rules that realize > > the parameters and range ...")? > > > > Andrea > > > > -----Original Message----- > > From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf > > Of Scott Brim > > Sent: Sunday, November 18, 2001 2:45 PM > > To: Andrea Westerinen > > Cc: Dan Grossman; Diffserv@Ietf. Org; Policy@Ietf. Org; Bert Wijnen > > (Bert) > > Subject: Re: FW: [Diffserv] Informal WG last call for > > draft-ietf-diffserv-new-terms-06.txt > > > > On Sat, Nov 17, 2001 05:55:31PM -0800, Andrea Westerinen wrote: > > > Focusing on #4. > > > > > > The text says ... "Therefore, the relationship between an SLS and a > > service > > > provisioning policy is that the latter is, in part, the set of rules > that > > > define the parameters and range of values that may be in the former." > > > > > > My inclination at this point is to leave it as it is, unless > Andrea > > > can come > > > up with a concise sentence or two that can be dropped in. I think that > > > policy > > > aware readers will understand that we don't intend to be restrictive, > and > > > non-policy aware readers won't be confused. > > > > > > Can we say "the set of rules that IMPLEMENT the parameters and range of > > > values ..."? My problem is with the word DEFINES. > > > > "Implements" is worse because the rules have nothing to do with > > implementation (a standardization absolute). If you think "defines" > > crosses a boundary, I suggest "specifies". > > > > _______________________________________________ > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h > tml > > _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@ns.ietf.org Tue Nov 20 08:16:26 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06753 for ; Tue, 20 Nov 2001 08:16:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA16583 for diffserv-archive@odin.ietf.org; Tue, 20 Nov 2001 08:16: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 HAA15621; Tue, 20 Nov 2001 07:52: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 HAA15593 for ; Tue, 20 Nov 2001 07:52:15 -0500 (EST) Received: from mail2.orchestream.com (mail2.orchestream.com [195.153.64.126]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05998 for ; Tue, 20 Nov 2001 07:52:10 -0500 (EST) Received: from rimmer.orchestream.com (rimmer.orchestream.com) by mail2.orchestream.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Tue, 20 Nov 2001 12:54:24 +0000 Received: from s1000.orchestream.com (s1000.orchestream.com [192.168.0.16]) by rimmer.orchestream.com (8.9.3/8.9.3) with ESMTP id IAA32612 for ; Tue, 20 Nov 2001 08:54:16 GMT Received: by s1000.orchestream.com with Internet Mail Service (5.5.2653.19) id ; Tue, 20 Nov 2001 12:46:32 -0000 Message-ID: From: "Da Silva, Pedro" To: "'diffserv@ietf.org'" Subject: RE: [Diffserv] diffserv-pib-05 comments [sic] Date: Tue, 20 Nov 2001 12:46:32 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Sure we're talking about different abstraction levels but the definition in the terminology draft specifically excludes any concretizations in data models (e.g. the one in the diffserv PIB) from having non-administratively assigned aspects to them ("Role(3): An administratively specified characteristic of a managed element"). I believe that the diffserv pib is a good example of roles that have non-administratively assigned elements being a Good Thing: I was wondering what the general feeling about relaxing the definition in the terminology draft is... cheers, Pedro -----Original Message----- From: Joel M. Halpern [mailto:joel@stevecrocker.com] Sent: Monday, November 19, 2001 2:41 PM To: Da Silva, Pedro; 'diffserv@ietf.org' Subject: RE: [Diffserv] diffserv-pib-05 comments [sic] PIBs are a mechanism to describe policy. They can be thought of as a data model or as a policy implementation technology. Policy Framework work is an information model. As such, one expects some change of details when one maps between them. The QPIM/ / QDDIM work is carefully designed to be able to represent DiffServ requirements. The Diffserv PIB is carefully designed to represent not just the abstract policy needs, but the details of DiffServ delivery. The two are not identical, and are not expected to be identical./ The difference in "role" is the difference in the policy concept of role and the COPS implementation of role. The differences are actually very minor. Yours, Joel M. Halpern At 01:13 PM 11/19/01 +0000, Da Silva, Pedro wrote: >I do have a concern about how the DiffServ PIB fits in the Policy WG >drafts-stds > >In the Policy WG we have [managed element]--[role]--[policy] >relationships, where role is 'an administratively specified characteristic >of a managed element'. QPIM goes further to say that 'The use of roles for >mapping policy to network elements provides an efficient and simple method >for compact and abstract policy definition. A given abstract policy may be >mapped to a group of network elements without the need to specify >configuration for each of those elements based on the capabilities of any >one individual element.' > >On the other hand, in the DiffServ PIB we have >[interface]--[userRole+capabilityName+direction]--[policy] >The DS PIB has a policy selector that is more than just a role and >includes what QPIM explicitly excludes, capability specs. > >So the semantics of roles are different between the two. And the concept >of 'managed element' has been limited to being an interface in the >DiffServ PIB whereas the Policy WG drafts-stds imply that it could be more >than interfaces. > >There is no specific question, it's more of a 'what do you think?' question. > >Pedro > > -----Original Message----- >From: Kwok-Ho Chan [mailto:khchan@nortelnetworks.com] >Sent: Friday, November 16, 2001 2:00 PM >To: Da Silva, Pedro >Cc: 'diffserv@ietf.org' >Subject: RE: [Diffserv] diffserv-pib-05 comments [sic] >Pedro: >Thanks for raising the issue. >If there is confusion, then I will improve the text. >Please don't hesitate to raise any concerns. >We need to fix them now before Last Call is done. >Thanks! >-- Kwok -- > >At 10:58 AM 11/16/01 +0000, Da Silva, Pedro wrote: >>I thought the table was instantiated per interface type and not for all >>of the interfaces types, thus the confusion. >>Therefore it does make sense to have the caps specs in the uniqueness >>clause. >> >>Pedro >>-----Original Message----- >>From: Kwok-Ho Chan [mailto:khchan@nortelnetworks.com] >>Sent: Thursday, November 15, 2001 8:03 PM >>To: Da Silva, Pedro >>Cc: 'diffserv@ietf.org'; Kwok-Ho Chan >>Subject: Re: [Diffserv] diffserv-pib-05 comments [sic] >> >>Pedro: >>Thank you for your comments. Please see response below. >>I believe you have sent the same comments again on the list. >>I will skip the duplicate. Please let me know if it is not duplicate. >>Thanks! >>-- Kwok -- >> >> >> >> >> >>At 03:22 PM 11/15/01 +0000, Da Silva, Pedro wrote: >>>The capability tables (e.g. qosIfMeteringCapsTable) have a UNIQUENESS >>>clause >>>that includes the capability spec itself (as well as the direction from the >>>base class). This means that a user may specify more than one capability >>>set >>>in one given direction, which in turn entails more work for the entity >>>managing and checking capabilities specs per se and capabilities specs >>>against policies. >>>Shouldn't the UNIQUENESS clause be restricted to the direction? >>No, I think the UNIQUENESS clause is correct as is. We do want to >>allow 2 or more entries in the qosIfMeteringCapsTable for the same >>direction, >>each one having different capabilities. This allows the device to have >>more than >>one different types of meter, may be for more than one kind of interface >>type. >>The specific data path using the different types of meter is specified by >>frwkIfCapSetTable entries provided by the Framework PIB -06 at >> http://www.ietf.org/internet-drafts/draft-ietf-rap-frameworkpib-06.txt >> >>I hope inspecting the qosIfMeteringCapsTable and frwkIfCapSetTable together >>will clarify the concerns you expressed. >>Please let me know if more explanation is needed. >> >> >> >> >> >>>Pedro >>> >>> >>> >>> >>> >>>_______________________________________________ >>>diffserv mailing list >>>diffserv@ietf.org >>>https://www1.ietf.org/mailman/listinfo/diffserv >>>Archive: >>>http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillis t.html _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@ns.ietf.org Tue Nov 20 10:01:00 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12736 for ; Tue, 20 Nov 2001 10:00:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA20695 for diffserv-archive@odin.ietf.org; Tue, 20 Nov 2001 10:01:02 -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 JAA19148; Tue, 20 Nov 2001 09:40: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 JAA19117 for ; Tue, 20 Nov 2001 09:40:50 -0500 (EST) Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11434 for ; Tue, 20 Nov 2001 09:40:47 -0500 (EST) Received: from JSCHNIZL-W2K1.cisco.com (rtp-vpn2-167.cisco.com [10.82.240.167]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id GAA01475; Tue, 20 Nov 2001 06:40:18 -0800 (PST) Message-Id: <4.3.2.7.2.20011120092546.0376df08@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 20 Nov 2001 09:39:36 -0500 To: "Da Silva, Pedro" From: John Schnizlein Subject: RE: [Diffserv] diffserv-pib-05 comments [sic] Cc: "'diffserv@ietf.org'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Since the objective of the policy terminology draft, now long past last call, was to document the broadest set of meanings with rough consensus, including aspects of "role" beyond those found necessary in the diffserv PIB is appropriate. Changing that is not a good idea. We simply disagree with your implication that this definition precludes the specific use of "role" in the diffserv PIB. John At 07:46 AM 11/20/2001, Da Silva, Pedro wrote: >Sure we're talking about different abstraction levels but the definition in >the terminology draft specifically excludes any concretizations in data >models (e.g. the one in the diffserv PIB) from having non-administratively >assigned aspects to them ("Role(3): An administratively specified >characteristic of a managed element"). >I believe that the diffserv pib is a good example of roles that have >non-administratively assigned elements being a Good Thing: I was wondering >what the general feeling about relaxing the definition in the terminology >draft is... _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@ns.ietf.org Tue Nov 20 11:04:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16674 for ; Tue, 20 Nov 2001 11:04:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA23679 for diffserv-archive@odin.ietf.org; Tue, 20 Nov 2001 11:04:21 -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 KAA22589; Tue, 20 Nov 2001 10:42:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22562 for ; Tue, 20 Nov 2001 10:42:54 -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 KAA15558 for ; Tue, 20 Nov 2001 10:42:50 -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 QAA10392; Tue, 20 Nov 2001 16:42:23 +0100 Received: from dhcp22-51.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA30140 from ; Tue, 20 Nov 2001 16:42:21 +0100 Message-Id: <3BFA7992.235B1C0B@hursley.ibm.com> Date: Tue, 20 Nov 2001 16:41:07 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: John Schnizlein Cc: "Da Silva, Pedro" , "'diffserv@ietf.org'" Subject: Re: [Diffserv] diffserv-pib-05 comments [sic] References: <4.3.2.7.2.20011120092546.0376df08@diablo.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit I see no consensus in this thread that we need to change the diffserv-pib, which is what we care about for *this* last call. Brian John Schnizlein wrote: > > Since the objective of the policy terminology draft, now long past > last call, was to document the broadest set of meanings with rough > consensus, including aspects of "role" beyond those found necessary > in the diffserv PIB is appropriate. Changing that is not a good idea. > > We simply disagree with your implication that this definition precludes > the specific use of "role" in the diffserv PIB. > > John > > At 07:46 AM 11/20/2001, Da Silva, Pedro wrote: > >Sure we're talking about different abstraction levels but the definition in > >the terminology draft specifically excludes any concretizations in data > >models (e.g. the one in the diffserv PIB) from having non-administratively > >assigned aspects to them ("Role(3): An administratively specified > >characteristic of a managed element"). > >I believe that the diffserv pib is a good example of roles that have > >non-administratively assigned elements being a Good Thing: I was wondering > >what the general feeling about relaxing the definition in the terminology > >draft is... _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@ns.ietf.org Tue Nov 20 11:56:57 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12734 for ; Tue, 20 Nov 2001 10:00:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA20700 for diffserv-archive@odin.ietf.org; Tue, 20 Nov 2001 10:01:02 -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 JAA19330; Tue, 20 Nov 2001 09:43: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 JAA19245 for ; Tue, 20 Nov 2001 09:43:04 -0500 (EST) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11658; Tue, 20 Nov 2001 09:42:59 -0500 (EST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id IAA34220; Tue, 20 Nov 2001 08:39:14 -0600 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.226.57]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fAKEg8s91426; Tue, 20 Nov 2001 09:42:08 -0500 Subject: RE: [Diffserv] diffserv-pib-05 comments [sic] To: "Da Silva, Pedro" Cc: "'diffserv@ietf.org'" , diffserv-admin@ietf.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Robert Moore" Date: Tue, 20 Nov 2001 09:43:42 -0500 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Build M9_05202001 Beta 2|May 20, 2001) at 11/20/2001 09:42:07 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org From the very beginning, capabilities have been included among the possible values of policy roles. Search, for example, on "Ethernet" in RFC 3060. I think that PolTerm is referring to the administrator's role(:-) in deciding to *use* "Ethernet" as a selector for associating policy rules with the resources to which they apply. Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com "Da Silva, Pedro" To: "'diffserv@ietf.org'" Subject: RE: [Diffserv] diffserv-pib-05 Sent by: comments [sic] diffserv-admin@i etf.org 11/20/01 07:46 AM Sure we're talking about different abstraction levels but the definition in the terminology draft specifically excludes any concretizations in data models (e.g. the one in the diffserv PIB) from having non-administratively assigned aspects to them ("Role(3): An administratively specified characteristic of a managed element"). I believe that the diffserv pib is a good example of roles that have non-administratively assigned elements being a Good Thing: I was wondering what the general feeling about relaxing the definition in the terminology draft is... cheers, Pedro -----Original Message----- From: Joel M. Halpern [mailto:joel@stevecrocker.com] Sent: Monday, November 19, 2001 2:41 PM To: Da Silva, Pedro; 'diffserv@ietf.org' Subject: RE: [Diffserv] diffserv-pib-05 comments [sic] PIBs are a mechanism to describe policy. They can be thought of as a data model or as a policy implementation technology. Policy Framework work is an information model. As such, one expects some change of details when one maps between them. The QPIM/ / QDDIM work is carefully designed to be able to represent DiffServ requirements. The Diffserv PIB is carefully designed to represent not just the abstract policy needs, but the details of DiffServ delivery. The two are not identical, and are not expected to be identical./ The difference in "role" is the difference in the policy concept of role and the COPS implementation of role. The differences are actually very minor. Yours, Joel M. Halpern At 01:13 PM 11/19/01 +0000, Da Silva, Pedro wrote: >I do have a concern about how the DiffServ PIB fits in the Policy WG >drafts-stds > >In the Policy WG we have [managed element]--[role]--[policy] >relationships, where role is 'an administratively specified characteristic >of a managed element'. QPIM goes further to say that 'The use of roles for >mapping policy to network elements provides an efficient and simple method >for compact and abstract policy definition. A given abstract policy may be >mapped to a group of network elements without the need to specify >configuration for each of those elements based on the capabilities of any >one individual element.' > >On the other hand, in the DiffServ PIB we have >[interface]--[userRole+capabilityName+direction]--[policy] >The DS PIB has a policy selector that is more than just a role and >includes what QPIM explicitly excludes, capability specs. > >So the semantics of roles are different between the two. And the concept >of 'managed element' has been limited to being an interface in the >DiffServ PIB whereas the Policy WG drafts-stds imply that it could be more >than interfaces. > >There is no specific question, it's more of a 'what do you think?' question. > >Pedro > > -----Original Message----- >From: Kwok-Ho Chan [mailto:khchan@nortelnetworks.com] >Sent: Friday, November 16, 2001 2:00 PM >To: Da Silva, Pedro >Cc: 'diffserv@ietf.org' >Subject: RE: [Diffserv] diffserv-pib-05 comments [sic] >Pedro: >Thanks for raising the issue. >If there is confusion, then I will improve the text. >Please don't hesitate to raise any concerns. >We need to fix them now before Last Call is done. >Thanks! >-- Kwok -- > >At 10:58 AM 11/16/01 +0000, Da Silva, Pedro wrote: >>I thought the table was instantiated per interface type and not for all >>of the interfaces types, thus the confusion. >>Therefore it does make sense to have the caps specs in the uniqueness >>clause. >> >>Pedro >>-----Original Message----- >>From: Kwok-Ho Chan [mailto:khchan@nortelnetworks.com] >>Sent: Thursday, November 15, 2001 8:03 PM >>To: Da Silva, Pedro >>Cc: 'diffserv@ietf.org'; Kwok-Ho Chan >>Subject: Re: [Diffserv] diffserv-pib-05 comments [sic] >> >>Pedro: >>Thank you for your comments. Please see response below. >>I believe you have sent the same comments again on the list. >>I will skip the duplicate. Please let me know if it is not duplicate. >>Thanks! >>-- Kwok -- >> >> >> >> >> >>At 03:22 PM 11/15/01 +0000, Da Silva, Pedro wrote: >>>The capability tables (e.g. qosIfMeteringCapsTable) have a UNIQUENESS >>>clause >>>that includes the capability spec itself (as well as the direction from the >>>base class). This means that a user may specify more than one capability >>>set >>>in one given direction, which in turn entails more work for the entity >>>managing and checking capabilities specs per se and capabilities specs >>>against policies. >>>Shouldn't the UNIQUENESS clause be restricted to the direction? >>No, I think the UNIQUENESS clause is correct as is. We do want to >>allow 2 or more entries in the qosIfMeteringCapsTable for the same >>direction, >>each one having different capabilities. This allows the device to have >>more than >>one different types of meter, may be for more than one kind of interface >>type. >>The specific data path using the different types of meter is specified by >>frwkIfCapSetTable entries provided by the Framework PIB -06 at >> http://www.ietf.org/internet-drafts/draft-ietf-rap-frameworkpib-06.txt >> >>I hope inspecting the qosIfMeteringCapsTable and frwkIfCapSetTable together >>will clarify the concerns you expressed. >>Please let me know if more explanation is needed. >> >> >> >> >> >>>Pedro >>> >>> >>> >>> >>> >>>_______________________________________________ >>>diffserv mailing list >>>diffserv@ietf.org >>>https://www1.ietf.org/mailman/listinfo/diffserv >>>Archive: >>>http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillis t.html _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.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://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@ns.ietf.org Tue Nov 20 14:16:06 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29903 for ; Tue, 20 Nov 2001 14:16:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA01771 for diffserv-archive@odin.ietf.org; Tue, 20 Nov 2001 14:16:09 -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 NAA00477; Tue, 20 Nov 2001 13:51: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 NAA00421 for ; Tue, 20 Nov 2001 13:51:49 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28339; Tue, 20 Nov 2001 13:51:44 -0500 (EST) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id fAKIpHE22781; Tue, 20 Nov 2001 10:51:17 -0800 (PST) Received: from ANDREAWW2K (andreaw-frame1.cisco.com [10.19.253.186]) by mira-sjcm-2.cisco.com (Mirapoint) with SMTP id AAV02846; Tue, 20 Nov 2001 10:51:12 -0800 (PST) From: "Andrea Westerinen" To: "Robert Moore" , "Da Silva, Pedro" Cc: , Subject: RE: [Diffserv] diffserv-pib-05 comments [sic] Date: Tue, 20 Nov 2001 10:53:48 -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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: 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 Bob and John stated the positions of PolTerm very well. PolTerm was meant to provide general definitions and assumed that they could be restricted in specific problem domains. Where usages did contradict, we worked with the teams to resolve the issues and come up with a consistent definition. So, PolTerm's "managed element" is any element that is managed (including interfaces). And, PolTerm's "administratively defined" is meant to convey anything of interest to an administrator - "Fast", "Slow", "Expensive", "Edge", "Ethernet", "VLAN capable", ... Andrea -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org]On Behalf Of Robert Moore Sent: Tuesday, November 20, 2001 6:44 AM To: Da Silva, Pedro Cc: 'diffserv@ietf.org'; diffserv-admin@ietf.org Subject: RE: [Diffserv] diffserv-pib-05 comments [sic] From the very beginning, capabilities have been included among the possible values of policy roles. Search, for example, on "Ethernet" in RFC 3060. I think that PolTerm is referring to the administrator's role(:-) in deciding to *use* "Ethernet" as a selector for associating policy rules with the resources to which they apply. Regards, Bob Bob Moore Advanced Design and Technology Application Integration Middleware Division IBM Software Group +1-919-254-4436 remoore@us.ibm.com "Da Silva, Pedro" To: "'diffserv@ietf.org'" Subject: RE: [Diffserv] diffserv-pib-05 Sent by: comments [sic] diffserv-admin@i etf.org 11/20/01 07:46 AM Sure we're talking about different abstraction levels but the definition in the terminology draft specifically excludes any concretizations in data models (e.g. the one in the diffserv PIB) from having non-administratively assigned aspects to them ("Role(3): An administratively specified characteristic of a managed element"). I believe that the diffserv pib is a good example of roles that have non-administratively assigned elements being a Good Thing: I was wondering what the general feeling about relaxing the definition in the terminology draft is... cheers, Pedro -----Original Message----- From: Joel M. Halpern [mailto:joel@stevecrocker.com] Sent: Monday, November 19, 2001 2:41 PM To: Da Silva, Pedro; 'diffserv@ietf.org' Subject: RE: [Diffserv] diffserv-pib-05 comments [sic] PIBs are a mechanism to describe policy. They can be thought of as a data model or as a policy implementation technology. Policy Framework work is an information model. As such, one expects some change of details when one maps between them. The QPIM/ / QDDIM work is carefully designed to be able to represent DiffServ requirements. The Diffserv PIB is carefully designed to represent not just the abstract policy needs, but the details of DiffServ delivery. The two are not identical, and are not expected to be identical./ The difference in "role" is the difference in the policy concept of role and the COPS implementation of role. The differences are actually very minor. Yours, Joel M. Halpern At 01:13 PM 11/19/01 +0000, Da Silva, Pedro wrote: >I do have a concern about how the DiffServ PIB fits in the Policy WG >drafts-stds > >In the Policy WG we have [managed element]--[role]--[policy] >relationships, where role is 'an administratively specified characteristic >of a managed element'. QPIM goes further to say that 'The use of roles for >mapping policy to network elements provides an efficient and simple method >for compact and abstract policy definition. A given abstract policy may be >mapped to a group of network elements without the need to specify >configuration for each of those elements based on the capabilities of any >one individual element.' > >On the other hand, in the DiffServ PIB we have >[interface]--[userRole+capabilityName+direction]--[policy] >The DS PIB has a policy selector that is more than just a role and >includes what QPIM explicitly excludes, capability specs. > >So the semantics of roles are different between the two. And the concept >of 'managed element' has been limited to being an interface in the >DiffServ PIB whereas the Policy WG drafts-stds imply that it could be more >than interfaces. > >There is no specific question, it's more of a 'what do you think?' question. > >Pedro > > -----Original Message----- >From: Kwok-Ho Chan [mailto:khchan@nortelnetworks.com] >Sent: Friday, November 16, 2001 2:00 PM >To: Da Silva, Pedro >Cc: 'diffserv@ietf.org' >Subject: RE: [Diffserv] diffserv-pib-05 comments [sic] >Pedro: >Thanks for raising the issue. >If there is confusion, then I will improve the text. >Please don't hesitate to raise any concerns. >We need to fix them now before Last Call is done. >Thanks! >-- Kwok -- > >At 10:58 AM 11/16/01 +0000, Da Silva, Pedro wrote: >>I thought the table was instantiated per interface type and not for all >>of the interfaces types, thus the confusion. >>Therefore it does make sense to have the caps specs in the uniqueness >>clause. >> >>Pedro >>-----Original Message----- >>From: Kwok-Ho Chan [mailto:khchan@nortelnetworks.com] >>Sent: Thursday, November 15, 2001 8:03 PM >>To: Da Silva, Pedro >>Cc: 'diffserv@ietf.org'; Kwok-Ho Chan >>Subject: Re: [Diffserv] diffserv-pib-05 comments [sic] >> >>Pedro: >>Thank you for your comments. Please see response below. >>I believe you have sent the same comments again on the list. >>I will skip the duplicate. Please let me know if it is not duplicate. >>Thanks! >>-- Kwok -- >> >> >> >> >> >>At 03:22 PM 11/15/01 +0000, Da Silva, Pedro wrote: >>>The capability tables (e.g. qosIfMeteringCapsTable) have a UNIQUENESS >>>clause >>>that includes the capability spec itself (as well as the direction from the >>>base class). This means that a user may specify more than one capability >>>set >>>in one given direction, which in turn entails more work for the entity >>>managing and checking capabilities specs per se and capabilities specs >>>against policies. >>>Shouldn't the UNIQUENESS clause be restricted to the direction? >>No, I think the UNIQUENESS clause is correct as is. We do want to >>allow 2 or more entries in the qosIfMeteringCapsTable for the same >>direction, >>each one having different capabilities. This allows the device to have >>more than >>one different types of meter, may be for more than one kind of interface >>type. >>The specific data path using the different types of meter is specified by >>frwkIfCapSetTable entries provided by the Framework PIB -06 at >> http://www.ietf.org/internet-drafts/draft-ietf-rap-frameworkpib-06.txt >> >>I hope inspecting the qosIfMeteringCapsTable and frwkIfCapSetTable together >>will clarify the concerns you expressed. >>Please let me know if more explanation is needed. >> >> >> >> >> >>>Pedro >>> >>> >>> >>> >>> >>>_______________________________________________ >>>diffserv mailing list >>>diffserv@ietf.org >>>https://www1.ietf.org/mailman/listinfo/diffserv >>>Archive: >>>http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillis t.html _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h tml _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Thu Nov 22 10:12:37 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15819 for ; Thu, 22 Nov 2001 10:12:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA24114 for diffserv-archive@odin.ietf.org; Thu, 22 Nov 2001 10:12:38 -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 JAA23076; Thu, 22 Nov 2001 09:47: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 JAA23047 for ; Thu, 22 Nov 2001 09:47: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 JAA15468 for ; Thu, 22 Nov 2001 09:47:10 -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 PAA09994 for ; Thu, 22 Nov 2001 15:46:40 +0100 Received: from dhcp23-10.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA81196 from ; Thu, 22 Nov 2001 15:46:40 +0100 Message-Id: <3BFD0FD3.C6BE9229@hursley.ibm.com> Date: Thu, 22 Nov 2001 15:46:43 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Diff Serv References: <3BE942FD.25B3B8E3@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Re: Informal WG last call for draft-ietf-diffserv-new-terms-06.txt Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Officially, this last call expired yesterday, and Dan has collected a few revisions. Unfortunately I have to add the following comment after my own deadline, because it only just came up: IANA was slightly confused by the IANA Considerations in RFC 2474, while reviewing draft-ietf-diffserv-efresolve-01.txt. RFC 2474 doesn't say explicitly that *only* standards track DSCP values are to be registered by IANA. Proposal: Add to the new-terms document: When RFC 2474 is revised, the following sentence should be added to Section 6, IANA Considerations: "IANA is requested to maintain a register of the DSCP values RECOMMENDED by Standards Action; EXP/LU values are not to be registered." Brian Brian E Carpenter wrote: > > It is proposed to forward draft-ietf-diffserv-new-terms-06.txt > for publication as an Informational RFC. This is an informal > working group last call - please make any last comments > on this document by Wednesday, November 21. > > N.B. This is an "informal" call because this is not a > standards track document. Nevertheless, the clarification > in Section 7 does refer to standards track issues. > > Brian Carpenter > Kathie Nichols > diffserv co-chairs > > -------- Original Message -------- > Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-new-terms-06.txt > Date: Wed, 07 Nov 2001 07:04:57 -0500 > From: Internet-Drafts@ietf.org > Reply-To: Internet-Drafts@ietf.org > To: IETF-Announce: ; > CC: diffserv@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Differentiated Services Working Group of the IETF. > > Title : New Terminology for Diffserv > Author(s) : D. Grossman > Filename : draft-ietf-diffserv-new-terms-06.txt > Pages : 9 > Date : 06-Nov-01 > > This memo captures Diffserv working group agreements concerning new > and improved terminology, and also provides minor technical > clarifications. It is intended to update RFC 2474, RFC 2475 and RFC > 2597. When RFCs 2474 and 2597 advance on the standards track, and > RFC 2475 is updated, it is intended that the revisions in this memo > will be incorporated, and that this memo will be obsoleted by the new > RFCs. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-diffserv-new-terms-06.txt _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Tue Nov 27 00:03:24 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26180 for ; Tue, 27 Nov 2001 00:03:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA10027 for diffserv-archive@odin.ietf.org; Tue, 27 Nov 2001 00:03: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 XAA08294; Mon, 26 Nov 2001 23:28:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA08269 for ; Mon, 26 Nov 2001 23:28:17 -0500 (EST) Received: from i2soft_web ([211.240.20.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA25002 for ; Mon, 26 Nov 2001 23:28:09 -0500 (EST) Received: by i2soft_web with MERCUR-SMTP/POP3/IMAP4-Server (v3.00.25 RI-0000000) for at Tue, 27 Nov 2001 13:30:15 +0900 From: "Yong-Seung Bae" To: "DiffServ Member" Date: Tue, 27 Nov 2001 13:27:34 +0900 Message-ID: <000001c176fb$d94a2b30$38a5fe81@dicao> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Diffserv] static provisioning & dynamic provisioning in diffserv region 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 I want to know details about static provisioning & dynamic provisioning in diffserv region If you have reference, If you know, then tell me about that. Thanks Best regards DICAO _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Tue Nov 27 00:17:06 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26610 for ; Tue, 27 Nov 2001 00:17:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA10670 for diffserv-archive@odin.ietf.org; Tue, 27 Nov 2001 00:17:08 -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 XAA09533; Mon, 26 Nov 2001 23:59: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 XAA09503 for ; Mon, 26 Nov 2001 23:59:28 -0500 (EST) Received: from ponyexpress.ee.columbia.edu (IDENT:root@ponyexpress.ee.columbia.edu [128.59.64.61]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26103 for ; Mon, 26 Nov 2001 23:59:22 -0500 (EST) Received: from SWEETPEA (sweetpea.comet.columbia.edu [128.59.65.202]) by ponyexpress.ee.columbia.edu (8.11.3/8.11.3) with SMTP id fAR4xJn03497; Mon, 26 Nov 2001 23:59:19 -0500 From: "Andrew T. Campbell" To: "'Yong-Seung Bae'" , "'DiffServ Member'" Cc: "Raymond Liao \(E-mail\)" , "Andrew Campbell \(E-mail\)" Subject: RE: [Diffserv] static provisioning & dynamic provisioning in diffserv region Date: Mon, 26 Nov 2001 23:56:01 -0500 Message-ID: <00ad01c176ff$d00103b0$ca413b80@SWEETPEA> 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 CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <000001c176fb$d94a2b30$38a5fe81@dicao> 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 Hello Yong-Seung: > -----Original Message----- > From: diffserv-admin@ietf.org > [mailto:diffserv-admin@ietf.org]On Behalf > Of Yong-Seung Bae > Sent: Monday, November 26, 2001 11:28 PM > To: DiffServ Member > Subject: [Diffserv] static provisioning & dynamic provisioning in > diffserv region > > > Hi > I want to know details about static provisioning & dynamic > provisioning > in diffserv region > If you have reference, If you know, then tell me about that. > Thanks > The CubaNet Project has studied dynamic edge provisioning for core IP networks and some market mechanisms for peering and provisioning, see: http://comet.columbia.edu/cubanet/ Also some pubs: http://comet.columbia.edu/cubanet/publications.html Liao, R.R.-F. and Campbell, A.T. "Dynamic Edge Provisioning for Core IP Networks" abstract(txt) and slide, 8th International Workshop on Quality of Service (IEEE/IFIP IWQOS 2000) , Pittsburgh, USA, June 2000. Semret, N., Liao, R.R.-F., Campbell, A.T. and Lazar, A.A. "Pricing, Provisioning and Peering: Dynamic Markets for Differentiated Internet Services and Implications for Network Interconnections", abstract(txt), JSAC Special Issue on Internet QoS, 2000. Semret, N., Liao, R.R.-F., Campbell, A.T. and Lazar, A.A. "Peering and Provisioning of Differentiated Internet Services", abstract(txt), IEEE INFOCOM 2000, Tel-Aviv, Isreal, March 2000. Semret, N., Liao, R.R.-F., Campbell, A.T. and Lazar, A.A. "Market Pricing of Differentiated Internet Services", abstract(txt), 7th International Workshop on Quality of Service (IEEE/IFIP IWQOS'99) , London, UK, June 1999. Best, --- Andrew http://comet.columbia.edu/~campbell > Best regards > DICAO > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: > http://www2.ietf.org/mail-archive/working-groups/diffserv/curr ent/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Tue Nov 27 06:39:08 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20439 for ; Tue, 27 Nov 2001 06:39:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA28246 for diffserv-archive@odin.ietf.org; Tue, 27 Nov 2001 06:39:05 -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 GAA27334; Tue, 27 Nov 2001 06:16:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27303 for ; Tue, 27 Nov 2001 06:16:25 -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 GAA19585 for ; Tue, 27 Nov 2001 06:16:23 -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 MAA13490 for ; Tue, 27 Nov 2001 12:15:53 +0100 Received: from dhcp22-47.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA51680 from ; Tue, 27 Nov 2001 12:15:51 +0100 Message-Id: <3C0375E8.72B8D6B9@hursley.ibm.com> Date: Tue, 27 Nov 2001 12:15:52 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Diff Serv References: <3BEFF7B3.FDA296EA@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Re: WG Last Call for draft-ietf-diffserv-pib-05.txt Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit This WG last call has concluded. I know that the authors have collected a few editorial comments, so there will be an editorial revision as soon as possible. None of the discussion showed a need for substantive change, so we have a WG consensus to forward this to the IESG. Brian Carpenter diffserv co-chair Brian E Carpenter wrote: > > It is proposed to forward draft-ietf-diffserv-pib-05.txt > to the IESG for publication as a Proposed Standard. > > Any final working group comments should be sent > to this list by November 26, 2001. > > Regards > Brian Carpenter > Kathie Nichols > diffserv WG co-chairs > > -------- Original Message -------- > Subject: [Diffserv] I-D ACTION:draft-ietf-diffserv-pib-05.txt > Date: Mon, 12 Nov 2001 07:03:18 -0500 > From: Internet-Drafts@ietf.org > Reply-To: Internet-Drafts@ietf.org > To: IETF-Announce: ; > CC: diffserv@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Differentiated Services Working Group of the IETF. > > Title : Differentiated Services Quality of Service Policy > Information Base > Author(s) : M. Fine, K. McCloghrie et al. > Filename : draft-ietf-diffserv-pib-05.txt > Pages : 95 > Date : 09-Nov-01 > > [SPPI] describes a structure for specifying policy information that > can then be transmitted to a network device for the purpose of > configuring policy at that device. The model underlying this > structure is one of well-defined policy rule classes and instances > of these classes residing in a virtual information store called the > Policy Information Base (PIB). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-diffserv-pib-05.txt > _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Wed Nov 28 06:11:37 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29895 for ; Wed, 28 Nov 2001 06:11:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA20735 for diffserv-archive@odin.ietf.org; Wed, 28 Nov 2001 06:11: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 FAA19282; Wed, 28 Nov 2001 05:56:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA19253 for ; Wed, 28 Nov 2001 05:56:36 -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 FAA28562; Wed, 28 Nov 2001 05:56:31 -0500 (EST) Message-Id: <200111281056.FAA28562@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: diffserv@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 28 Nov 2001 05:56:31 -0500 Subject: [Diffserv] I-D ACTION:draft-bless-diffserv-multicast-02.txt Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IP Multicast in Differentiated Services Networks Author(s) : R. Bless, K. Wehrle Filename : draft-bless-diffserv-multicast-02.txt Pages : 31 Date : 27-Nov-01 Besides providing basic building blocks for enabling different quality of service levels for unicast applications, the Differentiated Services (DiffServ) approach will also bring benefits for multicast applications which need quality of service support. For instance, a highly reliable multicast service can be provided based on the EF PHB [8]. However, current efforts mainly concentrate on unicast services, whereas provision and deployment of multicast services using Differentiated Services needs some clarification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bless-diffserv-multicast-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-bless-diffserv-multicast-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-bless-diffserv-multicast-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011127134848.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-bless-diffserv-multicast-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-bless-diffserv-multicast-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011127134848.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Wed Nov 28 14:38:32 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03620 for ; Wed, 28 Nov 2001 14:38:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA06858 for diffserv-archive@odin.ietf.org; Wed, 28 Nov 2001 14:38: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 OAA05953; Wed, 28 Nov 2001 14:22: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 OAA05924 for ; Wed, 28 Nov 2001 14:22:35 -0500 (EST) Received: from mailman.packetdesign.com (dns.packetdesign.com [65.192.41.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02286 for ; Wed, 28 Nov 2001 14:22:31 -0500 (EST) Received: from packetdesign.com (dhcp-168-0-13.packetdesign.com [192.168.0.13]) by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id fASJM3564212 for ; Wed, 28 Nov 2001 11:22:03 -0800 (PST) (envelope-from nichols@packetdesign.com) Message-ID: <3C05396E.FD3AEB35@packetdesign.com> Date: Wed, 28 Nov 2001 11:22:22 -0800 From: Kathleen Nichols X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 4.3-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: diffserv@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Diffserv] Diffserv at SLC and in future Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Content-Transfer-Encoding: 7bit Diffservers, We have decided not to hold a diffserv WG meeting at the Salt Lake City IETF. As you know, the two documents we had in WG Last Call have passed with minor comments. This means that the WG has effectively completed all its milestones. All our drafts except one are on the way to RFC publication. The differentiated services story isn't over, but this WG has essentially finished the job it was set up to do in early 1998. We do have two PDB drafts in progress that aren't yet ready to publish, draft-ietf-diffserv-pdb-ar-01.txt and draft-ietf-diffserv-pdb-bh-03.txt. Both need to have their experience sections filled in before they can be advanced to RFC, but they are still "alive" as documents and list discussion, particularly of experience, is still relevant. We note that the next revision of the Bulk Handling PDB draft is in Roland Bless's hands (to add experience) and, we believe, is expected in Jan or Feb or 02. Draft-ietf-diffserv-pdb-vw is dormant at this time since the co-authors did major revision of a PDB definition for circuit emulation. This may be resurrected with an experience section in the future. When PDB drafts are ready in terms of the guidelines in RFC 3086, they should be posted as drafts and discussed by email on this list. Another potential use of the diffserv list is to raise issues that are barriers to implementation and require further IETF action, but such should not be confused with general implementation questions, which should go to the ds-implmentation list. We (especially BC) will be quick to let you know if you have the wrong list! You may also be interested by draft-conta-diffserv-fl-classifier-01.txt. However, since the diffserv MIB already allows an IPv6 flow label as a classifier element, we probably do not need any additional standards action in this area. Regards Brian Carpenter Kathie Nichols diffserv WG co-chairs _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Wed Nov 28 16:23:50 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13486 for ; Wed, 28 Nov 2001 16:23:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA10752 for diffserv-archive@odin.ietf.org; Wed, 28 Nov 2001 16:23:54 -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 QAA09946; Wed, 28 Nov 2001 16:01:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09885 for ; Wed, 28 Nov 2001 16:00:59 -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 QAA11758 for ; Wed, 28 Nov 2001 16:00:54 -0500 (EST) Received: (qmail 17093 invoked by uid 104); 28 Nov 2001 20:59:59 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-1.00 (uvscan: v4.1.40/v4172. . Clean. Processed in 0.411771 secs); 28 Nov 2001 20:59:59 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by father.pmc-sierra.bc.ca with SMTP; 28 Nov 2001 20:59:59 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id fASKxwX10883 for ; Wed, 28 Nov 2001 12:59:58 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Wed, 28 Nov 2001 13:00:00 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE5CCB70@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: diffserv@ietf.org Subject: RE: [Diffserv] Diffserv at SLC and in future Date: Wed, 28 Nov 2001 12:59:55 -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, Does this mean that no new PDB draft could be put forward? Thanks, -Shahram > -----Original Message----- > From: Kathleen Nichols [mailto:nichols@packetdesign.com] > Sent: Wednesday, November 28, 2001 2:22 PM > To: diffserv@ietf.org > Subject: [Diffserv] Diffserv at SLC and in future > > > > Diffservers, > > We have decided not to hold a diffserv WG meeting at the > Salt Lake City IETF. > > As you know, the two documents we had in WG Last Call have passed > with minor comments. This means that the WG has effectively completed > all its milestones. All our drafts except one are on the way to > RFC publication. The differentiated services story isn't over, > but this WG has essentially finished the job it was set up to do > in early 1998. > > We do have two PDB drafts in progress that aren't yet > ready to publish, draft-ietf-diffserv-pdb-ar-01.txt and > draft-ietf-diffserv-pdb-bh-03.txt. Both need to have > their experience sections filled in before they can > be advanced to RFC, but they are still "alive" as > documents and list discussion, particularly of experience, > is still relevant. We note that the next revision of > the Bulk Handling PDB draft is in Roland Bless's hands (to > add experience) and, we believe, is expected in Jan or Feb or 02. > Draft-ietf-diffserv-pdb-vw is dormant at this time > since the co-authors did major revision of a > PDB definition for circuit emulation. This may be resurrected > with an experience section in the future. > > When PDB drafts are ready in terms of the guidelines in > RFC 3086, they should be posted as drafts and discussed by email > on this list. > > Another potential use of the diffserv list is to raise issues > that are barriers to implementation and require further IETF > action, but such should not be confused with general implementation > questions, which should go to the ds-implmentation list. We > (especially BC) will be quick to let you know if you have the > wrong list! > > You may also be interested by > draft-conta-diffserv-fl-classifier-01.txt. > However, since the diffserv MIB already allows an IPv6 flow label as > a classifier element, we probably do not need any additional standards > action in this area. > > Regards > Brian Carpenter > Kathie Nichols > diffserv WG co-chairs > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Wed Nov 28 20:50:21 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05645 for ; Wed, 28 Nov 2001 20:50:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA17715 for diffserv-archive@odin.ietf.org; Wed, 28 Nov 2001 20:50: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 UAA16633; Wed, 28 Nov 2001 20:24:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA16602 for ; Wed, 28 Nov 2001 20:24:16 -0500 (EST) Received: from mailman.packetdesign.com (dns.packetdesign.com [65.192.41.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03464 for ; Wed, 28 Nov 2001 20:24:08 -0500 (EST) Received: from packetdesign.com (dhcp-168-0-13.packetdesign.com [192.168.0.13]) by mailman.packetdesign.com (8.11.0/8.11.0) with ESMTP id fAT1NT576339; Wed, 28 Nov 2001 17:23:29 -0800 (PST) (envelope-from nichols@packetdesign.com) Message-ID: <3C058E25.12641CA7@packetdesign.com> Date: Wed, 28 Nov 2001 17:23:49 -0800 From: Kathleen Nichols X-Mailer: Mozilla 4.75 [en] (X11; U; FreeBSD 4.3-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Shahram Davari CC: diffserv@ietf.org Subject: Re: [Diffserv] Diffserv at SLC and in future References: <4B6D09F3B826D411A67300D0B706EFDE5CCB70@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 Davari wrote: > > Hi, > > Does this mean that no new PDB draft could be put forward? > > Thanks, > -Shahram > > > -----Original Message----- > > From: Kathleen Nichols [mailto:nichols@packetdesign.com] > > Sent: Wednesday, November 28, 2001 2:22 PM > > To: diffserv@ietf.org > > Subject: [Diffserv] Diffserv at SLC and in future > > > > ... > > When PDB drafts are ready in terms of the guidelines in > > RFC 3086, they should be posted as drafts and discussed by email > > on this list. > > I see that the above paragraph was too vague. It perhaps should have read "When these or any new PDB drafts..." So, the answer to your question is No. Rfc3086 was set up to allow for new PDBs whether there is a diffserv WG or not. Kathie _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@ns.ietf.org Thu Nov 29 17:46:57 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18808 for ; Thu, 29 Nov 2001 17:46:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA02409 for diffserv-archive@odin.ietf.org; Thu, 29 Nov 2001 17:46:54 -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 RAA01336; Thu, 29 Nov 2001 17:26:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA01305 for ; Thu, 29 Nov 2001 17:25:57 -0500 (EST) Received: from iraun2.uka.de (iraun2.uka.de [129.13.10.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17578 for ; Thu, 29 Nov 2001 17:25:53 -0500 (EST) Received: from irams1.ira.uka.de ([129.13.10.5]) by iraun2.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 169Zcu-000467-00 for ; Thu, 29 Nov 2001 23:25:52 +0100 Received: from i72pc127.tm.uni-karlsruhe.de ([141.3.70.78] helo=i72pc127.tm.uka.de ident=root) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 169Zct-0002i5-00 for ; Thu, 29 Nov 2001 23:25:51 +0100 Received: from i72pc127.tm.uka.de (localhost [127.0.0.1]) by i72pc127.tm.uka.de (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id fATMPpD07405 for ; Thu, 29 Nov 2001 23:25:51 +0100 Message-Id: <200111292225.fATMPpD07405@i72pc127.tm.uka.de> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev To: diffserv@ietf.org Subject: Re: [Diffserv] I-D ACTION:draft-bless-diffserv-multicast-02.txt In-Reply-To: Your message of "Wed, 28 Nov 2001 05:56:31 EST." <200111281056.FAA28562@ietf.org> References: <200111281056.FAA28562@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 29 Nov 2001 23:25:51 +0100 From: Roland Bless Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Hi, for those who are interested in the changes of draft-bless-diffserv-multicast-02.txt to the previous version. - we added a short section (sec. 4) about scalability issues - we added an appendix B with results from various simulation scenarios which show the described problems and the successful application of the proposed solution by using Limited Effort prior to any resource reservation. Best regards, Roland -- Roland Bless -- e-Mail: bless@tm.uka.de Institute of Telematics, University of Karlsruhe, Germany Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358 Phone: +49 721 608-6413 Fax: +49 721 388097 _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Fri Nov 30 09:35:00 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12952 for ; Fri, 30 Nov 2001 09:35:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA05141 for diffserv-archive@odin.ietf.org; Fri, 30 Nov 2001 09:35:03 -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 JAA04303; Fri, 30 Nov 2001 09:15: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 JAA04275 for ; Fri, 30 Nov 2001 09:15:44 -0500 (EST) Received: from ganesh.ctd.hctech.com ([202.54.64.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11996 for ; Fri, 30 Nov 2001 09:15:40 -0500 (EST) Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Nov 2001 19:53:12 +0530 Message-ID: From: "Kaliraj - CTD, Chennai." To: diffserv@ietf.org Date: Fri, 30 Nov 2001 19:43:16 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] differentiating EF and DF PHBs in MPLS domain. 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, if i am nOt mistaken, according to the mandatory EXP/PHB<->EXP mappings given in the draft "MPLS Support of Differentiated Services", the EXP field 000 is mapped to both EF and DF. then hOw dOz a diffServ-mpls-enabled node differentiate between packets belonging to these PHBs by just seeing the EXP field. please enlighten. thanX, raj. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Fri Nov 30 10:44:10 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16543 for ; Fri, 30 Nov 2001 10:44:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA07770 for diffserv-archive@odin.ietf.org; Fri, 30 Nov 2001 10:44:09 -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 KAA06775; Fri, 30 Nov 2001 10:26:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03447 for ; Fri, 30 Nov 2001 08:53:41 -0500 (EST) Received: from ganesh.ctd.hctech.com ([202.54.64.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10784 for ; Fri, 30 Nov 2001 08:53:37 -0500 (EST) Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Nov 2001 19:31:10 +0530 Message-ID: From: "Kaliraj - CTD, Chennai." To: diffserv@ietf.org Date: Fri, 30 Nov 2001 19:21:07 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Diffserv] differentiating EF and DF PHBs in MPLS domain. 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, if i am nOt mistaken, according to the mandatory EXP/PHB<->EXP mappings given in the draft "MPLS Support of Differentiated Services", the EXP field 000 is mapped to both EF and DF. then hOw dOz a diffServ-mpls-enabled node differentiate between packets belonging to these PHBs by just seeing the EXP field. please enlighten. thanX, raj. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Fri Nov 30 11:34:16 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19790 for ; Fri, 30 Nov 2001 11:34:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA10160 for diffserv-archive@odin.ietf.org; Fri, 30 Nov 2001 11:34:20 -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 LAA08700; Fri, 30 Nov 2001 11:06: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 LAA08669 for ; Fri, 30 Nov 2001 11:06:47 -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 LAA18172 for ; Fri, 30 Nov 2001 11:06:43 -0500 (EST) Received: (qmail 14072 invoked by uid 104); 30 Nov 2001 16:06:17 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-1.00 (uvscan: v4.1.40/v4173. . Clean. Processed in 0.423833 secs); 30 Nov 2001 16:06:17 -0000 Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120) by mother.pmc-sierra.bc.ca with SMTP; 30 Nov 2001 16:06:16 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id fAUG6GX14907; Fri, 30 Nov 2001 08:06:16 -0800 (PST) Received: by bby1exi01 with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Nov 2001 08:06:17 -0800 Message-ID: <4B6D09F3B826D411A67300D0B706EFDE5CCB85@nt-exch-yow.pmc-sierra.bc.ca> From: Shahram Davari To: "'Kaliraj - CTD, Chennai.'" , diffserv@ietf.org Subject: RE: [Diffserv] differentiating EF and DF PHBs in MPLS domain. Date: Fri, 30 Nov 2001 08:06:15 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: diffserv-admin@ietf.org Errors-To: diffserv-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Diffserv Discussion List X-BeenThere: diffserv@ietf.org Raj, The mapping that you described is recommended for L-LSPs. In L-LSPs, the signaling carries the PHB information, which is then used to bound a label to that PHB in every LSR along the LSP path. The LSR needs to look at both label and EXP to determine the PHB. Looking only at EXP is not enough in this case. The only case that looking at only the EXP is enough is the configured E-LSP case (if all LSPs are configured E-LSPs). Yours, -Shahram > -----Original Message----- > From: Kaliraj - CTD, Chennai. [mailto:kalirajv@ctd.hcltech.com] > Sent: Friday, November 30, 2001 8:51 AM > To: diffserv@ietf.org > Subject: [Diffserv] differentiating EF and DF PHBs in MPLS domain. > > > Hi all, > if i am nOt mistaken, according to the mandatory > EXP/PHB<->EXP mappings > given in the draft "MPLS Support of Differentiated Services", > the EXP field > 000 is mapped to both EF and DF. then hOw dOz a > diffServ-mpls-enabled node > differentiate between packets belonging to these PHBs by just > seeing the EXP > field. > > please enlighten. > thanX, > raj. > > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@optimus.ietf.org Fri Nov 30 12:14:44 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22226 for ; Fri, 30 Nov 2001 12:14:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA12579 for diffserv-archive@odin.ietf.org; Fri, 30 Nov 2001 12:14:44 -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 LAA10502; Fri, 30 Nov 2001 11:46: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 LAA10471 for ; Fri, 30 Nov 2001 11:46:42 -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 LAA20496 for ; Fri, 30 Nov 2001 11:46:37 -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 RAA10052; Fri, 30 Nov 2001 17:46:10 +0100 Received: from dhcp22-47.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA81070 from ; Fri, 30 Nov 2001 17:46:09 +0100 Message-Id: <3C07B7D1.F6E1F4DB@hursley.ibm.com> Date: Fri, 30 Nov 2001 17:46:09 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: "Kaliraj - CTD, Chennai." Cc: diffserv@ietf.org Subject: Re: [Diffserv] differentiating EF and DF PHBs in MPLS domain. 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 This is a question for the MPLS working group. This WG doesn't consider mappings to lower layers. Brian Carpente "Kaliraj - CTD, Chennai." wrote: > > Hi all, > > if i am nOt mistaken, according to the mandatory EXP/PHB<->EXP mappings > given in the draft "MPLS Support of Differentiated Services", the EXP field > 000 is mapped to both EF and DF. then hOw dOz a diffServ-mpls-enabled node > differentiate between packets belonging to these PHBs by just seeing the EXP > field. > > please enlighten. > thanX, > raj. _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From daemon@ns.ietf.org Fri Nov 30 14:49:22 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02045 for ; Fri, 30 Nov 2001 14:49:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA18058 for diffserv-archive@odin.ietf.org; Fri, 30 Nov 2001 14:49: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 OAA16896; Fri, 30 Nov 2001 14:29:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16728 for ; Fri, 30 Nov 2001 14:23:30 -0500 (EST) Received: from mailhub-2.iastate.edu (mailhub-2.iastate.edu [129.186.140.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29849 for ; Fri, 30 Nov 2001 14:23:13 -0500 (EST) Received: from STRIEGEL.iastate.edu (striegel.ee.iastate.edu [129.186.205.4]) by mailhub-2.iastate.edu (8.9.3/8.9.3) with ESMTP id NAA11623; Fri, 30 Nov 2001 13:23:07 -0600 Message-Id: <5.1.0.14.2.20011130125252.00aa1418@magico.mail.iastate.edu> X-Sender: magico@magico.mail.iastate.edu (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 30 Nov 2001 13:22:49 -0600 To: Roland Bless , diffserv@ietf.org From: Aaron D Striegel Subject: Re: [Diffserv] I-D ACTION:draft-bless-diffserv-multicast-02.txt In-Reply-To: <200111292225.fATMPpD07405@i72pc127.tm.uka.de> References: <200111281056.FAA28562@ietf.org> 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 Roland, Just a few comments on the draft that I am a bit concerned about: - The draft mentions that if IP multicast is considered to be scalable, therefore the approach is scalable. It seems to me that the per-group routing information and all of its associated timers/soft-state information essentially amounts to state information in the core. If the goal of DiffServ is to keep per-flow state information out of the core, IP multicast seems to violate this. This seems to steer away from the notion of a high-speed simple core router. What about an edge-based solution whereby the tree would be encapsulated in the packet? That would keep the core stateless but would come at the cost of additional bandwidth. Plus, if you keep the core stateless, you could essentially keep the core multicast protocol independent and free of any timers, soft-state, or protocol complexity beyond just simple data forwarding according to packet information, similar to the DSCP. - On the issue of further heterogeneity in multicast groups, would it be possible to have a node continue forwarding the join request (providing that IP Multicast was allowed in the core) towards the ingress router if PHB if of a better service class? This would be subject to the fact that such a request would have to be approved by the BB. For example, suppose a group exists with AF13 and AF12 codepoints. Suppose a new request comes in requesting AF11 service and the path to the ingress node (single source tree) coincides with part of the AF12 path to the ingress node. If such a path was promoted to AF11, the new receiver is receiving the QoS they asked for. If the portion of the tree stays AF12, the new receiver gets some but not all of the service they requested. Is this something to be concerned about? Also related to that, from our simulation studies it seems that if you do allow such a path to be promoted, it is possible to get out-of-order delivery for the flow (AF2x to AF1x). In addition, such prioritizing would have the problem of deciding which PHB is really best. For example, AF might actually be better than EF in a low loaded network with rate limitation on EF. Any thoughts on this? Aaron Aaron Striegel Dept. of Electrical & Computer Engineering Iowa State University E-mail: adstrieg@iastate.edu Webpage: http://www.public.iastate.edu/~magico _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html