From owner-rap@ops.ietf.org Wed Jan 15 15:57:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09777 for ; Wed, 15 Jan 2003 15:56:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18YucP-000C1G-00 for rap-data@psg.com; Wed, 15 Jan 2003 12:58:37 -0800 Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by psg.com with esmtp (Exim 3.36 #2) id 18YucM-000C0h-00 for rap@ops.ietf.org; Wed, 15 Jan 2003 12:58:34 -0800 Received: from zbl6c012.us.nortel.com (zbl6c012.us.nortel.com [132.245.205.62]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0FKvwM01635; Wed, 15 Jan 2003 15:57:59 -0500 (EST) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CY12QT3C; Wed, 15 Jan 2003 15:57:58 -0500 Received: from tweedy.NortelNetworks.com (TWEEDY [192.32.135.173]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CYB8DTBW; Wed, 15 Jan 2003 15:57:56 -0500 Message-Id: <5.2.0.9.0.20030115152727.022fa150@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 15 Jan 2003 15:55:17 -0500 To: rap@ops.ietf.org From: Kwok Ho Chan Subject: Re: wildcard flowid in framework PIB? Cc: Brian Williams , em.dumont@wanadoo.fr, "Kwok-Ho Chan" In-Reply-To: <3DCB2CCB.1060602@ericsson.com.au> References: <5.0.0.25.0.20021107183347.02532ea0@zbl6c002.corpeast.baynetworks.com> <5.0.0.25.0.20021107201344.024af3d0@zbl6c002.corpeast.baynetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-1.4 required=5.0 tests=IN_REP_TO,LINES_OF_YELLING,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_01_02 version=2.43 Sender: owner-rap@ops.ietf.org Precedence: bulk Hi all: I think we should call this "Not Used" FlowId condition in framework PIB. I think there have been some confusion on this topic and hence on the requested changes. The requested change is to have a way for the PDP to indicate to the PEP that the frwkIpFilterFlowId attribute of frwkIpFilterEntry should not be used for defining any filter match. This is different from the "Wildcard" match condition where "wildcard" means match all. (The "wildcard" case is covered by the case 3 below). We are doing final changes to the Framework PIB right before all text gets frozen into the RFC. To fix the "Not Used" case not realizable by the current Framework PIB, we propose to make the following changes to the Framework PIB: ----------------------------------------------------------------- Section 5 OLD: frwkIpFilterFlowId OBJECT-TYPE SYNTAX Unsigned32 (0..1048575) STATUS current DESCRIPTION "The flow identifier in an IPv6 header." ::= { frwkIpFilterEntry 7 } NEW: frwkIpFilterFlowId OBJECT-TYPE SYNTAX Unsigned32 (4294967295 | 0..1048575) STATUS current DESCRIPTION "The flow identifier in an IPv6 header. The value 4294967295 for this attribute MUST be interpreted as indication of this attribute NOT-USED, meaning not any value of flow identifier in the IPv6 header will result in a filter match. Notice this is different from a wildcard match, in which case all values of flow identifier in the IPv6 header will result in a filter match." ::= { frwkIpFilterEntry 7 } ------------------------------------------------------------------ SINCE WE ARE IN THE AUTHORS 48HR RFC EDITOR TIME PERIOD. IF WE DO NOT HEAR ANY OBJECTIONS TO THIS CHANGE WITHIN 36 HOURS, THEN WE ASSUME THIS CHANGE IS AGREED BY THE WG AND GOING AHEAD ON MAKING THIS CHANGE TO THE FRAMEWORK PIB RFC. Thanks! -- Kwok -- At 02:17 PM 11/8/02 +1100, Brian Williams wrote: >Hi Kwok. >I understood the use of setting the length to zero was for unsupported >attributes. If the intention is to use this for wildcards, then why is >there a distinct wildcard value indicated for the protocol and DSCP attributes? >/brian > >Kwok Ho Chan wrote: > >>Brian: >>Please see inline below. >>-- Kwok -- >> >>At 11:54 AM 11/8/02 +1100, Brian Williams wrote: >> >>>Hi Kwok. >>>I still am not clear how you would indicate a value to match all >>>FlowIDs, and hence the FlowId can be ignored. Please see further inline. >>>/brian >>> >>>Kwok Ho Chan wrote: >>> >>>>Brian, Emmanuel: >>>>We do not need wildcard for the frwkIpFilterFlowId attribute in the >>>>Framework PIB's frwkIpFilterEntry. >>>> >>>>The reasoning is as follows: >>> >>> >>> >>> >>>>> If an IPv6 node is not providing flow-specific treatment, it MUST >>>>> ignore the field when receiving or forwarding a packet. >>>I assume you are using this as the key point. What I am after is how you >>>tell the node that it is not doing flow-specific treatment, and >>>therefore the field can be ignored. That is, what do you send in the PIB >>>to tell the node that the FlowId is not used? This is not case 1, 2, or >>>3 below. >> >> >>The encoding of the frwkIpFilterFlowId attribute can have a length of >>zero, used to >>indicate the attribute is not used (please see COPS-PR RFC 3084). >>Hence this >>is used to indicate this attribute is not used as part of the filter >>definition and will >>not contribute to the filtering action, resulting in a "don't care" >>condition for >>frwkIpFilterFlowId, the meaning of a wildcard match for this attribute. >> >> >>>>the draft-ietf-ipv6-flow-label-03.txt draft indicate that there can be >>>>3 conditions >>>>for the Flow Label field of the IPv6 header: >>>>1. It contain the value of zero, meaning it is not used. >>>>2. It contain some specific value, with no defined syntax and semantics. >>>> Hence each value is unique on its own with no relationship to Flow >>>> Labels >>>> of containing another value. >>>>3. It contain some value other than zero. >>>> >>>>For the first 2 cases indicated above, the filter setup for them is >>>>trivial, just >>>>set the frwkIpFilterFlowId to zero or the specific value needed. >>> >>> >>>This is clear. >>> >>>>For the 3rd case, the filtering definition should use the >>>>frwkBaseFilterNegation >>>>set to true and frwkIpFilterFlowId set to zero. This will indicate a >>>>filter match >>>>for all Flow Label values other than zero. >>> >>> >>>This is also clear. >>> >>>>Please let me know if this does not resolve the question you have. >>>>Thanks! >>>>-- Kwok -- >>>> >>>> >>>>At 09:13 AM 11/8/02 +1100, Brian Williams wrote: >>>> >>>>>Hi Emmanuel. >>>>>Please see comments inline. >>>>>/brian >>>>> >>>>>Emmanuel Dumont wrote: >>>>> >>>>>>Hi Brian, >>>>>> >>>>>>Do you think a wildcard is needed for the FlowId attribute ? >>>>> >>>>>I consider that a wildcard would be needed for FlowId as much as for >>>>>the other attributes (eg DSCP). I think there would need to be an >>>>>explanation of why one is not provided. >>>>> >>>>>>Which one could you suggest ? >>>>> >>>>> >>>>>I would think a value of -1 (as used for DSCP) would be appropriate. >>>>> >>>>>>Kwok: is it an omission in the FR-PIB ? >>>>>>Maybe an IPv6 expert can help us to solve that question... >>>>>> >>>>>>Brian : Do you think that others wildcards are missing ? >>>>> >>>>> >>>>>This is the only one that I have identified is missing from the >>>>>filter. I have not done a careful check on anything else in the document. >>>>> >>>>>>Emmanuel Dumont >>>>>>---------------------------- >>>>>>France Telecom OCISI/DIeP (Guyancourt, France) >>>>>>Mail: em.dumont@wanadoo.fr / emmanuel.dumont@francetelecom.com >>>>>>---------------------------- >>>>>> >>>>>>-----Message d'origine----- >>>>>>De : owner-rap@ops.ietf.org [mailto:owner-rap@ops.ietf.org]De la part de >>>>>>Brian Williams >>>>>>Envoye : mercredi 6 novembre 2002 00:46 >>>>>>A : rap@ops.ietf.org >>>>>>Objet : wildcard flowid in framework PIB? >>>>>> >>>>>>Hi All. >>>>>>I have a question on the framework PIB. When I look at many of the >>>>>>filter attributes, there exist values that can be used as wildcards. >>>>>> >>>>>>The following are a few examples: >>>>>>- for source and destination addresses, a prefix length of 0 indicates a >>>>>>match of any address >>>>>>- for DSCP, a value of -1 will match all DSCP values >>>>>>- for port numbers, you can set the min and max to include all values >>>>>>- for protocol number, a value of 255 means match all >>>>>> >>>>>>However, for the FlowId, the range is specified as 0..1048575 which is >>>>>>the valid range of the 20 bit label. How is a wildcard FlowId indicated? >>>>>>/brian >>>>> > From owner-rap@ops.ietf.org Wed Jan 15 16:14:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10265 for ; Wed, 15 Jan 2003 16:14:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Yuuq-000CaG-00 for rap-data@psg.com; Wed, 15 Jan 2003 13:17:40 -0800 Received: from agitator.ibr.cs.tu-bs.de ([134.169.34.18]) by psg.com with esmtp (Exim 3.36 #2) id 18Yuuo-000CZk-00 for rap@ops.ietf.org; Wed, 15 Jan 2003 13:17:38 -0800 Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.6/8.12.6/Debian-6Woody) with ESMTP id h0FLHCn0021709 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Wed, 15 Jan 2003 22:17:12 +0100 Received: from hansa.ibr.cs.tu-bs.de (schoenw@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) with ESMTP id h0FLHCAa031824 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Wed, 15 Jan 2003 22:17:12 +0100 Received: (from schoenw@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) id h0FLHBxj031821; Wed, 15 Jan 2003 22:17:11 +0100 Date: Wed, 15 Jan 2003 22:17:11 +0100 Message-Id: <200301152117.h0FLHBxj031821@hansa.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: khchan@NortelNetworks.com, Bert Wijnen , Fred Baker CC: rap@ops.ietf.org, brian.williams@ericsson.com.au, em.dumont@wanadoo.fr, khchan@NortelNetworks.com In-reply-to: <5.2.0.9.0.20030115152727.022fa150@zbl6c002.corpeast.baynetworks.com> (message from Kwok Ho Chan on Wed, 15 Jan 2003 15:55:17 -0500) Subject: Re: wildcard flowid in framework PIB? References: <5.0.0.25.0.20021107183347.02532ea0@zbl6c002.corpeast.baynetworks.com> <5.0.0.25.0.20021107201344.024af3d0@zbl6c002.corpeast.baynetworks.com> <5.2.0.9.0.20030115152727.022fa150@zbl6c002.corpeast.baynetworks.com> X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_02_03 version=2.43 Sender: owner-rap@ops.ietf.org Precedence: bulk >>>>> Kwok Ho Chan writes: Kwok> Hi all: I think we should call this "Not Used" FlowId condition Kwok> in framework PIB. [...] Kwok> To fix the "Not Used" case not realizable by the current Kwok> Framework PIB, we propose to make the following changes to the Kwok> Framework PIB: WAIT My reading here is that this is analog to Dscp and DscpOrAny. If this is true, then we have the same problem in the filter definition of the DIFFSERV-MIB. And if this is the same problem, then we should have a similar way of addressing it. So perhaps we need to define FlowId and FlowIdOrAny TCs similar to the Dscp and DscpOrAny TCs so we can use the same solution everywhere. If we agree that this would be the correct way to do things, then we need to find out how to implement this with the current state of the set of documents involved. Note that I have added Bert and Fred to the To: list since I think they should be involved in handling this if my interpretation of this situation is correct. /js -- Juergen Schoenwaelder From owner-rap@ops.ietf.org Wed Jan 15 18:30:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14545 for ; Wed, 15 Jan 2003 18:30:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Yx1Y-000H67-00 for rap-data@psg.com; Wed, 15 Jan 2003 15:32:44 -0800 Received: from ish7.ericsson.com.au ([203.61.155.111]) by psg.com with esmtp (Exim 3.36 #2) id 18Yx1W-000H5t-00 for rap@ops.ietf.org; Wed, 15 Jan 2003 15:32:42 -0800 Received: from brsf10.epa.ericsson.se (brsf10 [146.11.8.4]) by ish7.ericsson.com.au (8.11.6+Sun/8.11.6) with ESMTP id h0FNUPG24793; Thu, 16 Jan 2003 10:30:25 +1100 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019.epa.ericsson.se [146.11.9.165]) by brsf10.epa.ericsson.se (8.11.6+Sun/8.11.6) with ESMTP id h0FNWX927727; Thu, 16 Jan 2003 10:32:33 +1100 (EST) Received: from ericsson.com.au (dhcp-239-121.epa.ericsson.se [146.11.239.121]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id C8QWN426; Thu, 16 Jan 2003 10:32:31 +1100 Message-ID: <3E25EF91.5090709@ericsson.com.au> Date: Thu, 16 Jan 2003 10:32:33 +1100 From: Brian Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: khchan@NortelNetworks.com CC: Juergen Schoenwaelder , Bert Wijnen , Fred Baker , rap@ops.ietf.org, em.dumont@wanadoo.fr Subject: Re: wildcard flowid in framework PIB? References: <5.0.0.25.0.20021107183347.02532ea0@zbl6c002.corpeast.baynetworks.com> <5.0.0.25.0.20021107201344.024af3d0@zbl6c002.corpeast.baynetworks.com> <5.2.0.9.0.20030115152727.022fa150@zbl6c002.corpeast.baynetworks.com> <200301152117.h0FLHBxj031821@hansa.ibr.cs.tu-bs.de> In-Reply-To: <200301152117.h0FLHBxj031821@hansa.ibr.cs.tu-bs.de> X-Enigmail-Version: 0.71.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-3.7 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,SPAM_PHRASE_01_02, USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Kwok. I find the terminology proposed in your update unclear: In your explanation, you have: The requested change is to have a way for the PDP to indicate to the PEP that the frwkIpFilterFlowId attribute of frwkIpFilterEntry should not be used for defining any filter match. This appears clear enough. But then the acutal text change proposed is: "The flow identifier in an IPv6 header. The value 4294967295 for this attribute MUST be interpreted as indication of this attribute NOT-USED, meaning not any value of flow identifier in the IPv6 header will result in a filter match. Notice this is different from a wildcard match, in which case all values of flow identifier in the IPv6 header will result in a filter match." I think the text is unclear in two specific ways. Firstly, (assuming my assumption is correct), it would be much clearer to use the IGNORED, rather than the term NOT-USED. To em, NOT-USED would be applicable if the field was optional, and you are checking if the field was specifically not provided. However, since the field is a part of the v6 header, it is not clear how NOT-USED applies. The second part that is really unclear is how you should interpret: "not any value of flow identifier in the IPv6 header will result in a filter match." If you use the term IGNORED, then it is easy to explain that the field shall not be considered in the filter match. Having made these comments on the current proposed text, I agree with the comments by Juergen below regarding the similarity to DSCP, and that a consistent approach should be sought. /brian Juergen Schoenwaelder wrote: >>>>>>Kwok Ho Chan writes: >>>>>> >>>>>> > >Kwok> Hi all: I think we should call this "Not Used" FlowId condition >Kwok> in framework PIB. > >[...] > >Kwok> To fix the "Not Used" case not realizable by the current >Kwok> Framework PIB, we propose to make the following changes to the >Kwok> Framework PIB: > >WAIT > >My reading here is that this is analog to Dscp and DscpOrAny. If this >is true, then we have the same problem in the filter definition of the >DIFFSERV-MIB. And if this is the same problem, then we should have a >similar way of addressing it. So perhaps we need to define FlowId and >FlowIdOrAny TCs similar to the Dscp and DscpOrAny TCs so we can use >the same solution everywhere. > >If we agree that this would be the correct way to do things, then we >need to find out how to implement this with the current state of the >set of documents involved. Note that I have added Bert and Fred to the >To: list since I think they should be involved in handling this if my >interpretation of this situation is correct. > >/js > > > From owner-rap@ops.ietf.org Fri Jan 17 13:19:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00802 for ; Fri, 17 Jan 2003 13:19:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Zb6d-0009XW-00 for rap-data@psg.com; Fri, 17 Jan 2003 10:20:39 -0800 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by psg.com with esmtp (Exim 3.36 #2) id 18Zb6Z-0009Vz-00 for rap@ops.ietf.org; Fri, 17 Jan 2003 10:20:35 -0800 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0HIJUJ18374; Fri, 17 Jan 2003 13:19:31 -0500 (EST) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CY12RDT6; Fri, 17 Jan 2003 13:19:30 -0500 Received: from tweedy.NortelNetworks.com (tweedy.engeast.baynetworks.com [192.32.135.173]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CYB8DVKA; Fri, 17 Jan 2003 13:19:28 -0500 Message-Id: <5.2.0.9.0.20030117100813.02fe1980@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 17 Jan 2003 13:16:21 -0500 To: Brian Williams From: Kwok Ho Chan Subject: Re: wildcard flowid in framework PIB? Cc: "Kwok-Ho Chan" , Juergen Schoenwaelder , Bert Wijnen , Fred Baker , rap@ops.ietf.org, em.dumont@wanadoo.fr, Brian E Carpenter , nichols@packetdesign.com In-Reply-To: <3E25EF91.5090709@ericsson.com.au> References: <200301152117.h0FLHBxj031821@hansa.ibr.cs.tu-bs.de> <5.0.0.25.0.20021107183347.02532ea0@zbl6c002.corpeast.baynetworks.com> <5.0.0.25.0.20021107201344.024af3d0@zbl6c002.corpeast.baynetworks.com> <5.2.0.9.0.20030115152727.022fa150@zbl6c002.corpeast.baynetworks.com> <200301152117.h0FLHBxj031821@hansa.ibr.cs.tu-bs.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02 version=2.43 Sender: owner-rap@ops.ietf.org Precedence: bulk (Please note I have added Brian Carpenter and Kathie Nicols to the CC list as we are talking about possible impact to the DiffServ MIB.) Hi Brian, Juergen, all: I am using this E-Mail as reply to both of your E-Mails and keeping it under one E-Mail thread (as they are related and should be considered together for a solution). First on the point of terminology, as raised by Brian Williams: I agree that the term IGNORED is better than the term NOT-USED. With IGNORED meaning the filter will ignore the flow identifier in the IPv6 header during its filter processing. With the following examples: 1. Packet FlowLabel = 0, Filter FlowId = 0, filter Satisfied. Notice Packet FlowLabel = 0 indicates the sending host is not using the IPv6 header's FlowLabel field. 2. Packet FlowLabel = ABC, Filter FlowId = ABC, filter Satisfied. 3. Packet FlowLabel = DEF, Filter FlowId = 0, FilterNegation = true, filter Satisfied. Notice this is Wildcard for cases when FlowLabel is used by the End Host. As Packet FlowLabel = 0, Filter FlowId = 0, FilterNegation = true, filter NotSatisfied. 4. Packet FlowLabel = "AnyValue", Filter FlowId = IGNORED. This instructs the filtering mechanism to not-use the Packet FlowLabel field as a filter criterion. The behavior is for the filtering mechanism to NOT based the event generation decision using the Packet FlowLabel field. I can see someone may use some wildcarding functionality to implement this. But that is implementation. We need to capture the feature description, not jumping to the implementation conclusions. As for the anolog to Dscp and DscpOrAny (defined in RFC 3289, DiffServ MIB) point indicated by Juergen: 1. "Dscp" "Dscp" is used by the DiffServ MIB for marking action of the DSCP field. "Dscp" is NOT used by the Framework PIB. "FlowId" IMHO, this is out of scope for DiffServ MIB, unless we plan to use the DiffServ MIB to set IPv6 parameters in IPv6 End Hosts. I think this should be part of IPv6 MIBs (which I have not find any RFCs or drafts that address this issue). This may be useful by IPv6 End Host (the only one that can set the IPv6 Header FlowLabel field), but IMHO it is outside the scope of the Framework PIB. 2. "DscpOrAny" "DscpOrAny" is used by the DiffServ MIB for filter definition purposes. "DscpOrAny" is used by the Framework PIB for filter definition purposes. "FlowIdOrAny" or "FlowIdIgnored" Flavoring "FlowIdIgnored" based on above discussion. I think this can be used by both Framework PIB and DiffServ MIB. Should we define a "FlowIdIgnored" TC? If yes, where does it belong? At current time, we are addressing this issue in the Framework PIB context, hence the suggested change is for the Framework PIB only. Guidance is needed if this issue impacts other WGs or Areas. I hope the information of this discussion help in coming to a better solution for this issue. Thanks! -- Kwok -- At 10:32 AM 1/16/03 +1100, Brian Williams wrote: >Hi Kwok. >I find the terminology proposed in your update unclear: > >In your explanation, you have: >The requested change is to have a way for the PDP to indicate to the PEP that >the frwkIpFilterFlowId attribute of frwkIpFilterEntry should not be used >for defining >any filter match. > >This appears clear enough. But then the acutal text change proposed is: > "The flow identifier in an IPv6 header. The value > 4294967295 for this attribute MUST be interpreted > as indication of this attribute NOT-USED, meaning > not any value of flow identifier in the IPv6 header will > result in a filter match. Notice this is different from > a wildcard match, in which case all values of flow > identifier in the IPv6 header will result in a filter match." > >I think the text is unclear in two specific ways. > >Firstly, (assuming my assumption is correct), it would be much clearer to >use the IGNORED, rather than the term NOT-USED. To em, NOT-USED would be >applicable if the field was optional, and you are checking if the field >was specifically not provided. However, since the field is a part of the >v6 header, it is not clear how NOT-USED applies. > >The second part that is really unclear is how you should interpret: >"not any value of flow identifier in the IPv6 header will result in a >filter match." > >If you use the term IGNORED, then it is easy to explain that the field >shall not be considered in the filter match. > >Having made these comments on the current proposed text, I agree with the >comments by Juergen below regarding the similarity to DSCP, and that a >consistent approach should be sought. >/brian > >Juergen Schoenwaelder wrote: > >>>>>>>Kwok Ho Chan writes: >>>>>>> >> >>Kwok> Hi all: I think we should call this "Not Used" FlowId condition >>Kwok> in framework PIB. >> >>[...] >> >>Kwok> To fix the "Not Used" case not realizable by the current >>Kwok> Framework PIB, we propose to make the following changes to the >>Kwok> Framework PIB: >> >>WAIT >> >>My reading here is that this is analog to Dscp and DscpOrAny. If this >>is true, then we have the same problem in the filter definition of the >>DIFFSERV-MIB. And if this is the same problem, then we should have a >>similar way of addressing it. So perhaps we need to define FlowId and >>FlowIdOrAny TCs similar to the Dscp and DscpOrAny TCs so we can use >>the same solution everywhere. >> >>If we agree that this would be the correct way to do things, then we >>need to find out how to implement this with the current state of the >>set of documents involved. Note that I have added Bert and Fred to the >>To: list since I think they should be involved in handling this if my >>interpretation of this situation is correct. >> >>/js >> >> > From owner-rap@ops.ietf.org Fri Jan 17 14:54:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03050 for ; Fri, 17 Jan 2003 14:54:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Zccj-000C6G-00 for rap-data@psg.com; Fri, 17 Jan 2003 11:57:53 -0800 Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by psg.com with esmtp (Exim 3.36 #2) id 18Zccf-000C4s-00 for rap@ops.ietf.org; Fri, 17 Jan 2003 11:57:49 -0800 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0HJuaS12990; Fri, 17 Jan 2003 14:56:36 -0500 (EST) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CY12R16M; Fri, 17 Jan 2003 14:56:35 -0500 Received: from tweedy.NortelNetworks.com (tweedy.engeast.baynetworks.com [192.32.135.173]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CYB8DVRB; Fri, 17 Jan 2003 14:56:34 -0500 Message-Id: <5.2.0.9.0.20030117144502.0429a7b0@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 17 Jan 2003 14:53:57 -0500 To: Brian E Carpenter From: Kwok Ho Chan Subject: Re: wildcard flowid in framework PIB? Cc: "Kwok-Ho Chan" , Brian Williams , Juergen Schoenwaelder , Bert Wijnen , Fred Baker , rap@ops.ietf.org, em.dumont@wanadoo.fr, nichols@packetdesign.com, Fred Baker In-Reply-To: <3E285B80.BF3296D8@hursley.ibm.com> References: <200301152117.h0FLHBxj031821@hansa.ibr.cs.tu-bs.de> <5.0.0.25.0.20021107183347.02532ea0@zbl6c002.corpeast.baynetworks.com> <5.0.0.25.0.20021107201344.024af3d0@zbl6c002.corpeast.baynetworks.com> <5.2.0.9.0.20030115152727.022fa150@zbl6c002.corpeast.baynetworks.com> <200301152117.h0FLHBxj031821@hansa.ibr.cs.tu-bs.de> <5.2.0.9.0.20030117100813.02fe1980@zbl6c002.corpeast.baynetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-rap@ops.ietf.org Precedence: bulk Brian: By "FlowId" I mean the TC definition for defining how to MARK the FlowID field. As being different from the TC definition for filtering the FlowID field. Using this analogy to the "Dscp" and "DscpOrAny" as Juergen raised. The "FlowId" TC being out of scope for diffserv MIB because diffserv functionality will not MARK the IPv6 Header FlowID field as the IPv6 draft indicates only End Host can mark the IPv6 Header FlowID field. Is this correct? The TC definition for filtering the FlowID field will still be in scope for diffserv MIB, as indicated in later discussion within the same E-Mail. Please advise. Thanks! -- Kwok -- At 08:37 PM 1/17/03 +0100, Brian E Carpenter wrote: >Kwok, > >The FlowID is certainly not out of scope for the diffserv MIB. It is >one of the possible fields in a multifield classifier. We are very close >to Last Call in the IPv6 WG on a proper definition of the FlowID, but >the IPv6 WG will certainly not be specifiying how it is used in >specific QOS solutions such as diffserv or intserv. > >The only issue for the diffserv MIB is whether we need to add a >wildcard, and for that I am waiting until Fred is back on-line. > > Brian > >Kwok Ho Chan wrote: > > > > (Please note I have added Brian Carpenter and Kathie Nicols to the CC list > > as we are talking about possible impact to the DiffServ MIB.) > > > > Hi Brian, Juergen, all: > > I am using this E-Mail as reply to both of your E-Mails and keeping it > > under one E-Mail thread (as they are related and should be considered > > together for a solution). > > > > First on the point of terminology, as raised by Brian Williams: > > I agree that the term IGNORED is better than the term NOT-USED. > > With IGNORED meaning the filter will ignore the flow identifier in the > > IPv6 header during its filter processing. > > With the following examples: > > 1. Packet FlowLabel = 0, Filter FlowId = 0, filter Satisfied. > > Notice Packet FlowLabel = 0 indicates the sending host is not using > > the IPv6 header's FlowLabel field. > > 2. Packet FlowLabel = ABC, Filter FlowId = ABC, filter Satisfied. > > 3. Packet FlowLabel = DEF, Filter FlowId = 0, FilterNegation = true, filter > > Satisfied. > > Notice this is Wildcard for cases when FlowLabel is used by the > End Host. > > As Packet FlowLabel = 0, Filter FlowId = 0, FilterNegation = true, > > filter NotSatisfied. > > 4. Packet FlowLabel = "AnyValue", Filter FlowId = IGNORED. > > This instructs the filtering mechanism to not-use the Packet FlowLabel > > field > > as a filter criterion. > > The behavior is for the filtering mechanism to NOT based the event > > generation > > decision using the Packet FlowLabel field. > > I can see someone may use some wildcarding functionality to implement > > this. > > But that is implementation. We need to capture the feature > > description, not > > jumping to the implementation conclusions. > > > > As for the anolog to Dscp and DscpOrAny (defined in RFC 3289, DiffServ MIB) > > point indicated by Juergen: > > 1. "Dscp" > > "Dscp" is used by the DiffServ MIB for marking action of the DSCP > field. > > "Dscp" is NOT used by the Framework PIB. > > > > "FlowId" > > IMHO, this is out of scope for DiffServ MIB, unless we plan to use the > > DiffServ MIB > > to set IPv6 parameters in IPv6 End Hosts. I think this should be part > > of IPv6 MIBs > > (which I have not find any RFCs or drafts that address this issue). > > This may be useful by IPv6 End Host (the only one that can set the > IPv6 > > Header FlowLabel field), but IMHO it is outside the scope of the > > Framework PIB. > > > > 2. "DscpOrAny" > > "DscpOrAny" is used by the DiffServ MIB for filter definition > purposes. > > "DscpOrAny" is used by the Framework PIB for filter definition > purposes. > > > > "FlowIdOrAny" or "FlowIdIgnored" > > Flavoring "FlowIdIgnored" based on above discussion. > > I think this can be used by both Framework PIB and DiffServ MIB. > > Should we define a "FlowIdIgnored" TC? > > If yes, where does it belong? > > > > At current time, we are addressing this issue in the Framework PIB > > context, > > hence the suggested change is for the Framework PIB only. > > Guidance is needed if this issue impacts other WGs or Areas. > > > > I hope the information of this discussion help in coming to a better > > solution for > > this issue. > > > > Thanks! > > -- Kwok -- > > > > At 10:32 AM 1/16/03 +1100, Brian Williams wrote: > > >Hi Kwok. > > >I find the terminology proposed in your update unclear: > > > > > >In your explanation, you have: > > >The requested change is to have a way for the PDP to indicate to the > PEP that > > >the frwkIpFilterFlowId attribute of frwkIpFilterEntry should not be used > > >for defining > > >any filter match. > > > > > >This appears clear enough. But then the acutal text change proposed is: > > > "The flow identifier in an IPv6 header. The value > > > 4294967295 for this attribute MUST be interpreted > > > as indication of this attribute NOT-USED, meaning > > > not any value of flow identifier in the IPv6 header will > > > result in a filter match. Notice this is different from > > > a wildcard match, in which case all values of flow > > > identifier in the IPv6 header will result in a filter match." > > > > > >I think the text is unclear in two specific ways. > > > > > >Firstly, (assuming my assumption is correct), it would be much clearer to > > >use the IGNORED, rather than the term NOT-USED. To em, NOT-USED would be > > >applicable if the field was optional, and you are checking if the field > > >was specifically not provided. However, since the field is a part of the > > >v6 header, it is not clear how NOT-USED applies. > > > > > >The second part that is really unclear is how you should interpret: > > >"not any value of flow identifier in the IPv6 header will result in a > > >filter match." > > > > > >If you use the term IGNORED, then it is easy to explain that the field > > >shall not be considered in the filter match. > > > > > >Having made these comments on the current proposed text, I agree with the > > >comments by Juergen below regarding the similarity to DSCP, and that a > > >consistent approach should be sought. > > >/brian > > > > > >Juergen Schoenwaelder wrote: > > > > > >>>>>>>Kwok Ho Chan writes: > > >>>>>>> > > >> > > >>Kwok> Hi all: I think we should call this "Not Used" FlowId condition > > >>Kwok> in framework PIB. > > >> > > >>[...] > > >> > > >>Kwok> To fix the "Not Used" case not realizable by the current > > >>Kwok> Framework PIB, we propose to make the following changes to the > > >>Kwok> Framework PIB: > > >> > > >>WAIT > > >> > > >>My reading here is that this is analog to Dscp and DscpOrAny. If this > > >>is true, then we have the same problem in the filter definition of the > > >>DIFFSERV-MIB. And if this is the same problem, then we should have a > > >>similar way of addressing it. So perhaps we need to define FlowId and > > >>FlowIdOrAny TCs similar to the Dscp and DscpOrAny TCs so we can use > > >>the same solution everywhere. > > >> > > >>If we agree that this would be the correct way to do things, then we > > >>need to find out how to implement this with the current state of the > > >>set of documents involved. Note that I have added Bert and Fred to the > > >>To: list since I think they should be involved in handling this if my > > >>interpretation of this situation is correct. > > >> > > >>/js From owner-rap@ops.ietf.org Fri Jan 17 15:13:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03433 for ; Fri, 17 Jan 2003 15:13:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Zcux-000ChI-00 for rap-data@psg.com; Fri, 17 Jan 2003 12:16:43 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 18Zcuu-000Ch6-00 for rap@ops.ietf.org; Fri, 17 Jan 2003 12:16:40 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18Zcuu-000Dhx-00 for rap@ops.ietf.org; Fri, 17 Jan 2003 12:16:40 -0800 Message-Id: <3E285B80.BF3296D8@hursley.ibm.com> Mime-Version: 1.0 References: <200301152117.h0FLHBxj031821@hansa.ibr.cs.tu-bs.de> <5.0.0.25.0.20021107183347.02532ea0@zbl6c002.corpeast.baynetworks.com> <5.0.0.25.0.20021107201344.024af3d0@zbl6c002.corpeast.baynetworks.com> <5.2.0.9.0.20030115152727.022fa150@zbl6c002.corpeast.baynetworks.com> <200301152117.h0FLHBxj031821@hansa.ibr.cs.tu-bs.de> <5.2.0.9.0.20030117100813.02fe1980@zbl6c002.corpeast.baynetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 17 Jan 2003 20:37:36 +0100 From: Brian E Carpenter To: Kwok Ho Chan Cc: Brian Williams , Juergen Schoenwaelder , Bert Wijnen , Fred Baker , rap@ops.ietf.org, em.dumont@wanadoo.fr, nichols@packetdesign.com, Fred Baker Subject: Re: wildcard flowid in framework PIB? X-Spam-Status: No, hits=-1.0 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO,SPAM_PHRASE_01_02 version=2.43 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Kwok, The FlowID is certainly not out of scope for the diffserv MIB. It is one of the possible fields in a multifield classifier. We are very close to Last Call in the IPv6 WG on a proper definition of the FlowID, but the IPv6 WG will certainly not be specifiying how it is used in specific QOS solutions such as diffserv or intserv. The only issue for the diffserv MIB is whether we need to add a wildcard, and for that I am waiting until Fred is back on-line. Brian Kwok Ho Chan wrote: > > (Please note I have added Brian Carpenter and Kathie Nicols to the CC list > as we are talking about possible impact to the DiffServ MIB.) > > Hi Brian, Juergen, all: > I am using this E-Mail as reply to both of your E-Mails and keeping it > under one E-Mail thread (as they are related and should be considered > together for a solution). > > First on the point of terminology, as raised by Brian Williams: > I agree that the term IGNORED is better than the term NOT-USED. > With IGNORED meaning the filter will ignore the flow identifier in the > IPv6 header during its filter processing. > With the following examples: > 1. Packet FlowLabel = 0, Filter FlowId = 0, filter Satisfied. > Notice Packet FlowLabel = 0 indicates the sending host is not using > the IPv6 header's FlowLabel field. > 2. Packet FlowLabel = ABC, Filter FlowId = ABC, filter Satisfied. > 3. Packet FlowLabel = DEF, Filter FlowId = 0, FilterNegation = true, filter > Satisfied. > Notice this is Wildcard for cases when FlowLabel is used by the End Host. > As Packet FlowLabel = 0, Filter FlowId = 0, FilterNegation = true, > filter NotSatisfied. > 4. Packet FlowLabel = "AnyValue", Filter FlowId = IGNORED. > This instructs the filtering mechanism to not-use the Packet FlowLabel > field > as a filter criterion. > The behavior is for the filtering mechanism to NOT based the event > generation > decision using the Packet FlowLabel field. > I can see someone may use some wildcarding functionality to implement > this. > But that is implementation. We need to capture the feature > description, not > jumping to the implementation conclusions. > > As for the anolog to Dscp and DscpOrAny (defined in RFC 3289, DiffServ MIB) > point indicated by Juergen: > 1. "Dscp" > "Dscp" is used by the DiffServ MIB for marking action of the DSCP field. > "Dscp" is NOT used by the Framework PIB. > > "FlowId" > IMHO, this is out of scope for DiffServ MIB, unless we plan to use the > DiffServ MIB > to set IPv6 parameters in IPv6 End Hosts. I think this should be part > of IPv6 MIBs > (which I have not find any RFCs or drafts that address this issue). > This may be useful by IPv6 End Host (the only one that can set the IPv6 > Header FlowLabel field), but IMHO it is outside the scope of the > Framework PIB. > > 2. "DscpOrAny" > "DscpOrAny" is used by the DiffServ MIB for filter definition purposes. > "DscpOrAny" is used by the Framework PIB for filter definition purposes. > > "FlowIdOrAny" or "FlowIdIgnored" > Flavoring "FlowIdIgnored" based on above discussion. > I think this can be used by both Framework PIB and DiffServ MIB. > Should we define a "FlowIdIgnored" TC? > If yes, where does it belong? > > At current time, we are addressing this issue in the Framework PIB > context, > hence the suggested change is for the Framework PIB only. > Guidance is needed if this issue impacts other WGs or Areas. > > I hope the information of this discussion help in coming to a better > solution for > this issue. > > Thanks! > -- Kwok -- > > At 10:32 AM 1/16/03 +1100, Brian Williams wrote: > >Hi Kwok. > >I find the terminology proposed in your update unclear: > > > >In your explanation, you have: > >The requested change is to have a way for the PDP to indicate to the PEP that > >the frwkIpFilterFlowId attribute of frwkIpFilterEntry should not be used > >for defining > >any filter match. > > > >This appears clear enough. But then the acutal text change proposed is: > > "The flow identifier in an IPv6 header. The value > > 4294967295 for this attribute MUST be interpreted > > as indication of this attribute NOT-USED, meaning > > not any value of flow identifier in the IPv6 header will > > result in a filter match. Notice this is different from > > a wildcard match, in which case all values of flow > > identifier in the IPv6 header will result in a filter match." > > > >I think the text is unclear in two specific ways. > > > >Firstly, (assuming my assumption is correct), it would be much clearer to > >use the IGNORED, rather than the term NOT-USED. To em, NOT-USED would be > >applicable if the field was optional, and you are checking if the field > >was specifically not provided. However, since the field is a part of the > >v6 header, it is not clear how NOT-USED applies. > > > >The second part that is really unclear is how you should interpret: > >"not any value of flow identifier in the IPv6 header will result in a > >filter match." > > > >If you use the term IGNORED, then it is easy to explain that the field > >shall not be considered in the filter match. > > > >Having made these comments on the current proposed text, I agree with the > >comments by Juergen below regarding the similarity to DSCP, and that a > >consistent approach should be sought. > >/brian > > > >Juergen Schoenwaelder wrote: > > > >>>>>>>Kwok Ho Chan writes: > >>>>>>> > >> > >>Kwok> Hi all: I think we should call this "Not Used" FlowId condition > >>Kwok> in framework PIB. > >> > >>[...] > >> > >>Kwok> To fix the "Not Used" case not realizable by the current > >>Kwok> Framework PIB, we propose to make the following changes to the > >>Kwok> Framework PIB: > >> > >>WAIT > >> > >>My reading here is that this is analog to Dscp and DscpOrAny. If this > >>is true, then we have the same problem in the filter definition of the > >>DIFFSERV-MIB. And if this is the same problem, then we should have a > >>similar way of addressing it. So perhaps we need to define FlowId and > >>FlowIdOrAny TCs similar to the Dscp and DscpOrAny TCs so we can use > >>the same solution everywhere. > >> > >>If we agree that this would be the correct way to do things, then we > >>need to find out how to implement this with the current state of the > >>set of documents involved. Note that I have added Bert and Fred to the > >>To: list since I think they should be involved in handling this if my > >>interpretation of this situation is correct. > >> > >>/js From owner-rap@ops.ietf.org Fri Jan 17 21:05:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09028 for ; Fri, 17 Jan 2003 21:05:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18ZiPb-000M6E-00 for rap-data@psg.com; Fri, 17 Jan 2003 18:08:43 -0800 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by psg.com with esmtp (Exim 3.36 #2) id 18ZiPY-000M4K-00 for rap@ops.ietf.org; Fri, 17 Jan 2003 18:08:40 -0800 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0I288S23579 for ; Fri, 17 Jan 2003 21:08:08 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Sat, 18 Jan 2003 03:08:06 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155AA9B3B@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Brian E Carpenter , Kwok Ho Chan Cc: Brian Williams , Juergen Schoenwaelder , Bert Wijnen , Fred Baker , rap@ops.ietf.org, em.dumont@wanadoo.fr, nichols@packetdesign.com Subject: RE: wildcard flowid in framework PIB? Date: Sat, 18 Jan 2003 03:07:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Status: No, hits=-0.1 required=5.0 tests=EXCHANGE_SERVER,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-rap@ops.ietf.org Precedence: bulk > > Correct. The FlowID is immutable (unlike the DSCP). Are you saying the > MIB allows setting the FlowID? If so, that's a bug. > No, I think the flowID in the MIB is settable, but it functions as the flowID on which one wants to filter or classify. So it is not changing the flowid in the protocol PDUs that pass by, but only comparing it to the SETable MIB value(s). And I do think that it makes sense to be able to have a wildcard for that, no? Bert From owner-rap@ops.ietf.org Fri Jan 17 21:54:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09871 for ; Fri, 17 Jan 2003 21:54:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18ZjAo-000Nkb-00 for rap-data@psg.com; Fri, 17 Jan 2003 18:57:30 -0800 Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com) by psg.com with esmtp (Exim 3.36 #2) id 18ZjAl-000NkO-00 for rap@ops.ietf.org; Fri, 17 Jan 2003 18:57:27 -0800 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0I2vO308485 for ; Fri, 17 Jan 2003 21:57:25 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Sat, 18 Jan 2003 03:57:24 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155AA9B41@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Kwok Ho Chan , Brian Williams Cc: Juergen Schoenwaelder , Bert Wijnen , Fred Baker , rap@ops.ietf.org, em.dumont@wanadoo.fr, Brian E Carpenter , nichols@packetdesign.com Subject: RE: wildcard flowid in framework PIB? Date: Sat, 18 Jan 2003 03:56:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Status: No, hits=-0.1 required=5.0 tests=EXCHANGE_SERVER,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.43 Sender: owner-rap@ops.ietf.org Precedence: bulk Inline Bert > -----Original Message----- > From: Kwok Ho Chan [mailto:khchan@NortelNetworks.com] > Sent: vrijdag 17 januari 2003 19:16 > To: Brian Williams > Cc: Kwok-Ho Chan; Juergen Schoenwaelder; Bert Wijnen; Fred Baker; > rap@ops.ietf.org; em.dumont@wanadoo.fr; Brian E Carpenter; > nichols@packetdesign.com > Subject: Re: wildcard flowid in framework PIB? > > > (Please note I have added Brian Carpenter and Kathie Nicols > to the CC list > as we are talking about possible impact to the DiffServ MIB.) > > Hi Brian, Juergen, all: > I am using this E-Mail as reply to both of your E-Mails and keeping it > under one E-Mail thread (as they are related and should be considered > together for a solution). > > First on the point of terminology, as raised by Brian Williams: > I agree that the term IGNORED is better than the term NOT-USED. Why do these terms have to be capitalized?? > With IGNORED meaning the filter will ignore the flow identifier in the > IPv6 header during its filter processing. So it basically also means any, right? So a TC named FlowIdOrAny seems to correctly capture the idea. > With the following examples: > 1. Packet FlowLabel = 0, Filter FlowId = 0, filter Satisfied. > Notice Packet FlowLabel = 0 indicates the sending host > is not using the IPv6 header's FlowLabel field. > 2. Packet FlowLabel = ABC, Filter FlowId = ABC, filter Satisfied. > 3. Packet FlowLabel = DEF, Filter FlowId = 0, FilterNegation = true, > filter Satisfied. > Notice this is Wildcard for cases when FlowLabel is used > by the End Host. > As Packet FlowLabel = 0, Filter FlowId = 0, FilterNegation = true, > filter NotSatisfied. So is the FilterNegation value not relevant in cases 1 and 2? > 4. Packet FlowLabel = "AnyValue", Filter FlowId = IGNORED. > This instructs the filtering mechanism to not-use the > Packet FlowLabel field as a filter criterion. > The behavior is for the filtering mechanism to NOT based > the event generation decision using the Packet FlowLabel field. > I can see someone may use some wildcarding functionality > to implement this. > But that is implementation. We need to capture the feature > description, not jumping to the implementation conclusions. > All the above is fine. And you are arguing that you need to add that special value to indicate "ignore the flowID" or "consider any flowID a match"... or that is what I understand. That is OK with me... and all I want is to see WG consensus on that as a first step. My second concern is that this requirement to sometimes use FlowID and at other times FlowIdOrAny, is a generic need and does not just apply to the framework PIB. So that suggest that we better have something like two TCs for it, so that people can re-use the definition and so that from now on we all know how to specify this (namely by using the TCs). In fact, this discussion has already revealed to me that even the old way you defined the flowID in both the framework PIB and in the diffserv MIB, that we SHOULD have created a TC for that, even before this whole discussion started. Now to the DIFFSERV MIB specifics > > As for the anolog to Dscp and DscpOrAny (defined in RFC 3289, > DiffServ MIB) point indicated by Juergen: > 1. "Dscp" > "Dscp" is used by the DiffServ MIB for marking action of > the DSCP field. "Dscp" is NOT used by the Framework PIB. > Correct, but that is irrelevant to the discussion What the DIFFSERV WG did, is define a TC that clearly specifies what a Dscp is and that definition can then be re-used by many MIB and PIB modules (if they need it of course). > "FlowId" IMHO, this is out of scope for DiffServ MIB, > unless we plan to use the DiffServ MIB to set IPv6 > parameters in IPv6 End Hosts. Kowk, when you define a TC like Dscp or FlowId, then that does not mean that they can only be used to SET a field in a protocol pdu. It can also be used in other ways. If you look at the diffserv MIB, then you will see that if we had defined a FlowId TC, then diffServMultiFieldClfrFlowId OBJECT-TYPE SYNTAX Unsigned32 (0..1048575) MAX-ACCESS read-create STATUS current DESCRIPTION "The flow identifier in an IPv6 header." ::= { diffServMultiFieldClfrEntry 8 } Would indeed have used that TC as the SYNTAX. And you could have shared it in your revision 9 of your internet draft. > I think this should be part of IPv6 MIBs (which I have > not find any RFCs or drafts that address this issue). > This may be useful by IPv6 End Host (the only one that > can set the IPv6 Header FlowLabel field), but IMHO it > is outside the scope of the Framework PIB. > We can argue indeed WHERE such a TC should be defined. In many cases in the IETF, we just defined them in whichever MIB (or PIB) document that first had a need and where we envisioned that it could be re-used by other MIB or PIB documents in the furture. > 2. "DscpOrAny" > "DscpOrAny" is used by the DiffServ MIB for filter definition > purposes. > "DscpOrAny" is used by the Framework PIB for filter > definition purposes. > Correct. And in the future, other MIB or PIB modules can use it for similar things too, or they can use it for other purposes. > "FlowIdOrAny" or "FlowIdIgnored" > Flavoring "FlowIdIgnored" based on above discussion. Flavoring ??? Do you mean that you prefer the name FlowIdIgnored ?? > I think this can be used by both Framework PIB and DiffServ MIB. > Should we define a "FlowIdIgnored" TC? > If yes, where does it belong? > I think FlowIdOrAny is the better name for a TC. The reason is, that the wildcard value does not always have to mean that the flowID is to be ignored. The TC would/should look as follows I think: FlowIdOrAny TECTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The flow identifier in an IPv6 header that may be used to discriminate traffic flows. The value of 4294967295 is used to indicate a wildcard, i.e. any value. " SYNTAX Unsigned32 (4294967295 | 0..1048575) In the case of the framework PIB, you would probably use it as follows frwkIpFilterFlowId OBJECT-TYPE SYNTAX FlowIdOrAny STATUS current DESCRIPTION "The wildcard or any-value of 4294967295 for this attribute MUST be interpreted as indication that any flow ID value in the IPv6 header will match. This results in the flow ID to be ignored for matching this filter entry." ::= { frwkIpFilterEntry 7 } If the Diffserv MIB needs needs a similar change, then they can use this TC. If not, then they can keep what they have now, or they could use (in the next revision) a new TC called FlowId which would look like: FlowId TECTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The flow identifier in an IPv6 header that may be used to discriminate traffic flows. " SYNTAX Unsigned32 (0..1048575) In the future, other MIB and PIB modules can then also re-use these TCs without causing confusion or risks for different definitions. > At current time, we are addressing this issue in the > Framework PIB context, hence the suggested change is for the > Framework PIB only. > Guidance is needed if this issue impacts other WGs or Areas. > Correct, you seem to want to fix this right now as a last minute change in a doc that is ready to become RFC (RFC-editor has issued 48-hour author call). For that we need consensus from the RAP WG. If the diffserv MIB needs a similar fix is a diffserv WG issue. I still think they do, but that is up to them, and it can be done at a later time when they rev their RFC anyway. By creating a TC now, we would pabve the way. The two TCs that I propose would probably best be done in a separate MIB module (so they can be used by both PIB and MIB modules, I believe that a MIB cannot import from a PIB... but a PIB can import from a MIB) Since that would result in too much of a delay, you could define the Unsigned 32 values in the PIB and we can then later at revision time replace it with a TC that we define in a separate MIB Module. > I hope the information of this discussion help in coming to a better > solution for this issue. > Hope my answers help as well Bert > Thanks! > -- Kwok -- > > > At 10:32 AM 1/16/03 +1100, Brian Williams wrote: > >Hi Kwok. > >I find the terminology proposed in your update unclear: > > > >In your explanation, you have: > >The requested change is to have a way for the PDP to > indicate to the PEP that > >the frwkIpFilterFlowId attribute of frwkIpFilterEntry should > not be used > >for defining > >any filter match. > > > >This appears clear enough. But then the acutal text change > proposed is: > > "The flow identifier in an IPv6 header. The value > > 4294967295 for this attribute MUST be interpreted > > as indication of this attribute NOT-USED, meaning > > not any value of flow identifier in the IPv6 header will > > result in a filter match. Notice this is different from > > a wildcard match, in which case all values of flow > > identifier in the IPv6 header will result in a > filter match." > > > >I think the text is unclear in two specific ways. > > > >Firstly, (assuming my assumption is correct), it would be > much clearer to > >use the IGNORED, rather than the term NOT-USED. To em, > NOT-USED would be > >applicable if the field was optional, and you are checking > if the field > >was specifically not provided. However, since the field is a > part of the > >v6 header, it is not clear how NOT-USED applies. > > > >The second part that is really unclear is how you should interpret: > >"not any value of flow identifier in the IPv6 header will > result in a > >filter match." > > > >If you use the term IGNORED, then it is easy to explain that > the field > >shall not be considered in the filter match. > > > >Having made these comments on the current proposed text, I > agree with the > >comments by Juergen below regarding the similarity to DSCP, > and that a > >consistent approach should be sought. > >/brian > > > >Juergen Schoenwaelder wrote: > > > >>>>>>>Kwok Ho Chan writes: > >>>>>>> > >> > >>Kwok> Hi all: I think we should call this "Not Used" FlowId > condition > >>Kwok> in framework PIB. > >> > >>[...] > >> > >>Kwok> To fix the "Not Used" case not realizable by the current > >>Kwok> Framework PIB, we propose to make the following changes to the > >>Kwok> Framework PIB: > >> > >>WAIT > >> > >>My reading here is that this is analog to Dscp and > DscpOrAny. If this > >>is true, then we have the same problem in the filter > definition of the > >>DIFFSERV-MIB. And if this is the same problem, then we should have a > >>similar way of addressing it. So perhaps we need to define > FlowId and > >>FlowIdOrAny TCs similar to the Dscp and DscpOrAny TCs so we can use > >>the same solution everywhere. > >> > >>If we agree that this would be the correct way to do things, then we > >>need to find out how to implement this with the current state of the > >>set of documents involved. Note that I have added Bert and > Fred to the > >>To: list since I think they should be involved in handling > this if my > >>interpretation of this situation is correct. > >> > >>/js > >> > >> > > > From owner-rap@ops.ietf.org Mon Jan 20 11:22:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23184 for ; Mon, 20 Jan 2003 11:22:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18aejL-000Ij1-00 for rap-data@psg.com; Mon, 20 Jan 2003 08:24:59 -0800 Received: from 12-224-149-107.client.attbi.com ([12.224.149.107] helo=x1-6-00-01-03-84-67-74 ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18aejI-000Iip-00 for rap@ops.ietf.org; Mon, 20 Jan 2003 08:24:56 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18aejH-0000vc-00 for rap@ops.ietf.org; Mon, 20 Jan 2003 08:24:55 -0800 Message-Id: <3E287E94.BF6D457E@hursley.ibm.com> Mime-Version: 1.0 References: <200301152117.h0FLHBxj031821@hansa.ibr.cs.tu-bs.de> <5.0.0.25.0.20021107183347.02532ea0@zbl6c002.corpeast.baynetworks.com> <5.0.0.25.0.20021107201344.024af3d0@zbl6c002.corpeast.baynetworks.com> <5.2.0.9.0.20030115152727.022fa150@zbl6c002.corpeast.baynetworks.com> <200301152117.h0FLHBxj031821@hansa.ibr.cs.tu-bs.de> <5.2.0.9.0.20030117100813.02fe1980@zbl6c002.corpeast.baynetworks.com> <5.2.0.9.0.20030117144502.0429a7b0@zbl6c002.corpeast.baynetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 17 Jan 2003 23:07:16 +0100 From: Brian E Carpenter To: Kwok Ho Chan Cc: Brian Williams , Juergen Schoenwaelder , Bert Wijnen , Fred Baker , rap@ops.ietf.org, em.dumont@wanadoo.fr, nichols@packetdesign.com Subject: Re: wildcard flowid in framework PIB? X-Spam-Status: No, hits=-1.3 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_01_02 version=2.43 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Correct. The FlowID is immutable (unlike the DSCP). Are you saying the MIB allows setting the FlowID? If so, that's a bug. Brian Kwok Ho Chan wrote: > > Brian: > By "FlowId" I mean the TC definition for defining how to MARK the FlowID field. > As being different from the TC definition for filtering the FlowID field. > Using this analogy to the "Dscp" and "DscpOrAny" as Juergen raised. > > The "FlowId" TC being out of scope for diffserv MIB because diffserv > functionality > will not MARK the IPv6 Header FlowID field as the IPv6 draft indicates only End > Host can mark the IPv6 Header FlowID field. > Is this correct? > > The TC definition for filtering the FlowID field will still be in scope for > diffserv MIB, > as indicated in later discussion within the same E-Mail. > > Please advise. > Thanks! > -- Kwok -- > > At 08:37 PM 1/17/03 +0100, Brian E Carpenter wrote: > >Kwok, > > > >The FlowID is certainly not out of scope for the diffserv MIB. It is > >one of the possible fields in a multifield classifier. We are very close > >to Last Call in the IPv6 WG on a proper definition of the FlowID, but > >the IPv6 WG will certainly not be specifiying how it is used in > >specific QOS solutions such as diffserv or intserv. > > > >The only issue for the diffserv MIB is whether we need to add a > >wildcard, and for that I am waiting until Fred is back on-line. > > > > Brian > > > >Kwok Ho Chan wrote: > > > > > > (Please note I have added Brian Carpenter and Kathie Nicols to the CC list > > > as we are talking about possible impact to the DiffServ MIB.) > > > > > > Hi Brian, Juergen, all: > > > I am using this E-Mail as reply to both of your E-Mails and keeping it > > > under one E-Mail thread (as they are related and should be considered > > > together for a solution). > > > > > > First on the point of terminology, as raised by Brian Williams: > > > I agree that the term IGNORED is better than the term NOT-USED. > > > With IGNORED meaning the filter will ignore the flow identifier in the > > > IPv6 header during its filter processing. > > > With the following examples: > > > 1. Packet FlowLabel = 0, Filter FlowId = 0, filter Satisfied. > > > Notice Packet FlowLabel = 0 indicates the sending host is not using > > > the IPv6 header's FlowLabel field. > > > 2. Packet FlowLabel = ABC, Filter FlowId = ABC, filter Satisfied. > > > 3. Packet FlowLabel = DEF, Filter FlowId = 0, FilterNegation = true, filter > > > Satisfied. > > > Notice this is Wildcard for cases when FlowLabel is used by the > > End Host. > > > As Packet FlowLabel = 0, Filter FlowId = 0, FilterNegation = true, > > > filter NotSatisfied. > > > 4. Packet FlowLabel = "AnyValue", Filter FlowId = IGNORED. > > > This instructs the filtering mechanism to not-use the Packet FlowLabel > > > field > > > as a filter criterion. > > > The behavior is for the filtering mechanism to NOT based the event > > > generation > > > decision using the Packet FlowLabel field. > > > I can see someone may use some wildcarding functionality to implement > > > this. > > > But that is implementation. We need to capture the feature > > > description, not > > > jumping to the implementation conclusions. > > > > > > As for the anolog to Dscp and DscpOrAny (defined in RFC 3289, DiffServ MIB) > > > point indicated by Juergen: > > > 1. "Dscp" > > > "Dscp" is used by the DiffServ MIB for marking action of the DSCP > > field. > > > "Dscp" is NOT used by the Framework PIB. > > > > > > "FlowId" > > > IMHO, this is out of scope for DiffServ MIB, unless we plan to use the > > > DiffServ MIB > > > to set IPv6 parameters in IPv6 End Hosts. I think this should be part > > > of IPv6 MIBs > > > (which I have not find any RFCs or drafts that address this issue). > > > This may be useful by IPv6 End Host (the only one that can set the > > IPv6 > > > Header FlowLabel field), but IMHO it is outside the scope of the > > > Framework PIB. > > > > > > 2. "DscpOrAny" > > > "DscpOrAny" is used by the DiffServ MIB for filter definition > > purposes. > > > "DscpOrAny" is used by the Framework PIB for filter definition > > purposes. > > > > > > "FlowIdOrAny" or "FlowIdIgnored" > > > Flavoring "FlowIdIgnored" based on above discussion. > > > I think this can be used by both Framework PIB and DiffServ MIB. > > > Should we define a "FlowIdIgnored" TC? > > > If yes, where does it belong? > > > > > > At current time, we are addressing this issue in the Framework PIB > > > context, > > > hence the suggested change is for the Framework PIB only. > > > Guidance is needed if this issue impacts other WGs or Areas. > > > > > > I hope the information of this discussion help in coming to a better > > > solution for > > > this issue. > > > > > > Thanks! > > > -- Kwok -- > > > > > > At 10:32 AM 1/16/03 +1100, Brian Williams wrote: > > > >Hi Kwok. > > > >I find the terminology proposed in your update unclear: > > > > > > > >In your explanation, you have: > > > >The requested change is to have a way for the PDP to indicate to the > > PEP that > > > >the frwkIpFilterFlowId attribute of frwkIpFilterEntry should not be used > > > >for defining > > > >any filter match. > > > > > > > >This appears clear enough. But then the acutal text change proposed is: > > > > "The flow identifier in an IPv6 header. The value > > > > 4294967295 for this attribute MUST be interpreted > > > > as indication of this attribute NOT-USED, meaning > > > > not any value of flow identifier in the IPv6 header will > > > > result in a filter match. Notice this is different from > > > > a wildcard match, in which case all values of flow > > > > identifier in the IPv6 header will result in a filter match." > > > > > > > >I think the text is unclear in two specific ways. > > > > > > > >Firstly, (assuming my assumption is correct), it would be much clearer to > > > >use the IGNORED, rather than the term NOT-USED. To em, NOT-USED would be > > > >applicable if the field was optional, and you are checking if the field > > > >was specifically not provided. However, since the field is a part of the > > > >v6 header, it is not clear how NOT-USED applies. > > > > > > > >The second part that is really unclear is how you should interpret: > > > >"not any value of flow identifier in the IPv6 header will result in a > > > >filter match." > > > > > > > >If you use the term IGNORED, then it is easy to explain that the field > > > >shall not be considered in the filter match. > > > > > > > >Having made these comments on the current proposed text, I agree with the > > > >comments by Juergen below regarding the similarity to DSCP, and that a > > > >consistent approach should be sought. > > > >/brian > > > > > > > >Juergen Schoenwaelder wrote: > > > > > > > >>>>>>>Kwok Ho Chan writes: > > > >>>>>>> > > > >> > > > >>Kwok> Hi all: I think we should call this "Not Used" FlowId condition > > > >>Kwok> in framework PIB. > > > >> > > > >>[...] > > > >> > > > >>Kwok> To fix the "Not Used" case not realizable by the current > > > >>Kwok> Framework PIB, we propose to make the following changes to the > > > >>Kwok> Framework PIB: > > > >> > > > >>WAIT > > > >> > > > >>My reading here is that this is analog to Dscp and DscpOrAny. If this > > > >>is true, then we have the same problem in the filter definition of the > > > >>DIFFSERV-MIB. And if this is the same problem, then we should have a > > > >>similar way of addressing it. So perhaps we need to define FlowId and > > > >>FlowIdOrAny TCs similar to the Dscp and DscpOrAny TCs so we can use > > > >>the same solution everywhere. > > > >> > > > >>If we agree that this would be the correct way to do things, then we > > > >>need to find out how to implement this with the current state of the > > > >>set of documents involved. Note that I have added Bert and Fred to the > > > >>To: list since I think they should be involved in handling this if my > > > >>interpretation of this situation is correct. > > > >> > > > >>/js -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland From owner-rap@ops.ietf.org Mon Jan 20 12:10:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24333 for ; Mon, 20 Jan 2003 12:10:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18afUU-000LNY-00 for rap-data@psg.com; Mon, 20 Jan 2003 09:13:42 -0800 Received: from 12-224-149-107.client.attbi.com ([12.224.149.107] helo=x1-6-00-01-03-84-67-74 ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18afUR-000LNM-00 for rap@ops.ietf.org; Mon, 20 Jan 2003 09:13:39 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18afUQ-00017x-00 for rap@ops.ietf.org; Mon, 20 Jan 2003 09:13:38 -0800 Message-Id: <5.2.0.9.2.20030120065700.03af1bc0@mira-sjcm-4.cisco.com> In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B155AA9B3B@nl0006exch001u.nl.l ucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Date: Mon, 20 Jan 2003 07:00:53 -0800 To: "Wijnen, Bert (Bert)" From: Fred Baker Subject: RE: wildcard flowid in framework PIB? Cc: Brian E Carpenter , Kwok Ho Chan , Brian Williams , Juergen Schoenwaelder , Bert Wijnen , rap@ops.ietf.org, em.dumont@wanadoo.fr, nichols@packetdesign.com X-Spam-Status: No, hits=-1.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RESENT_TO,SPAM_PHRASE_02_03 version=2.43 Sender: owner-rap@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] hmm. The field is diffServMultiFieldClfrFlowId OBJECT-TYPE SYNTAX Unsigned32 (0..1048575) MAX-ACCESS read-create STATUS current DESCRIPTION "The flow identifier in an IPv6 header." ::= { diffServMultiFieldClfrEntry 8 } It allows you to set the value compared against, which is to say "decide what packets to select"; nothing in the MIB permits you to change the packet other than the "set" action, and that sets the DSCP. I think I intended to have a boolean (a TruthValue) that allowed you to wildcard it, and have it default to being wildcarded (like all the other fields in the MFClassifier); however, I don't see the boolean in the MIB. oops. At 03:07 AM 1/18/2003 +0100, Wijnen, Bert (Bert) wrote: > > > > Correct. The FlowID is immutable (unlike the DSCP). Are you saying the > > MIB allows setting the FlowID? If so, that's a bug. > > >No, I think the flowID in the MIB is settable, but it functions as >the flowID on which one wants to filter or classify. So it is not changing >the flowid in the protocol PDUs that pass by, but only comparing it to >the SETable MIB value(s). And I do think that it makes sense to be >able to have a wildcard for that, no? > >Bert From owner-rap@ops.ietf.org Mon Jan 20 12:30:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24853 for ; Mon, 20 Jan 2003 12:30:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18afnK-000MUc-00 for rap-data@psg.com; Mon, 20 Jan 2003 09:33:10 -0800 Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by psg.com with esmtp (Exim 3.36 #2) id 18afnG-000MTH-00 for rap@ops.ietf.org; Mon, 20 Jan 2003 09:33:07 -0800 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars04e.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h0KHW9Q01255; Mon, 20 Jan 2003 12:32:10 -0500 (EST) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DJJGAY5K; Mon, 20 Jan 2003 12:32:08 -0500 Received: from tweedy.NortelNetworks.com (TWEEDY [192.32.135.173]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CYB8DW0T; Mon, 20 Jan 2003 12:32:07 -0500 Message-Id: <5.2.0.9.0.20030120122218.03272900@zbl6c002.corpeast.baynetworks.com> X-Sender: khchan@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 20 Jan 2003 12:29:33 -0500 To: Brian E Carpenter From: Kwok Ho Chan Subject: Re: wildcard flowid in framework PIB? Cc: "Kwok-Ho Chan" , Brian Williams , Juergen Schoenwaelder , Bert Wijnen , Fred Baker , rap@ops.ietf.org, em.dumont@wanadoo.fr, nichols@packetdesign.com In-Reply-To: <3E287E94.BF6D457E@hursley.ibm.com> References: <200301152117.h0FLHBxj031821@hansa.ibr.cs.tu-bs.de> <5.0.0.25.0.20021107183347.02532ea0@zbl6c002.corpeast.baynetworks.com> <5.0.0.25.0.20021107201344.024af3d0@zbl6c002.corpeast.baynetworks.com> <5.2.0.9.0.20030115152727.022fa150@zbl6c002.corpeast.baynetworks.com> <200301152117.h0FLHBxj031821@hansa.ibr.cs.tu-bs.de> <5.2.0.9.0.20030117100813.02fe1980@zbl6c002.corpeast.baynetworks.com> <5.2.0.9.0.20030117144502.0429a7b0@zbl6c002.corpeast.baynetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02 version=2.43 Sender: owner-rap@ops.ietf.org Precedence: bulk Brian: Please see response inline. -- Kwok -- At 11:07 PM 1/17/03 +0100, Brian E Carpenter wrote: >Correct. The FlowID is immutable (unlike the DSCP). Are you saying the >MIB allows setting the FlowID? If so, that's a bug. The Diffserv MIB currently does not set the FlowID field in the IPv6 header. It handles the filter that examine the FlowID field in the IPv6 header, IMHO the correct functionality. The response I provided in the E-Mail thread below is to indicate that Diffserv MIB, Framework PIB, Diffserv PIB does not require the TC (suggested by Juergen) for setting/marking of the FlowID field in the IPv6 header. > Brian > >Kwok Ho Chan wrote: > > > > Brian: > > By "FlowId" I mean the TC definition for defining how to MARK the > FlowID field. > > As being different from the TC definition for filtering the FlowID field. > > Using this analogy to the "Dscp" and "DscpOrAny" as Juergen raised. > > > > The "FlowId" TC being out of scope for diffserv MIB because diffserv > > functionality > > will not MARK the IPv6 Header FlowID field as the IPv6 draft indicates > only End > > Host can mark the IPv6 Header FlowID field. > > Is this correct? > > > > The TC definition for filtering the FlowID field will still be in scope for > > diffserv MIB, > > as indicated in later discussion within the same E-Mail. > > > > Please advise. > > Thanks! > > -- Kwok -- > > > > At 08:37 PM 1/17/03 +0100, Brian E Carpenter wrote: > > >Kwok, > > > > > >The FlowID is certainly not out of scope for the diffserv MIB. It is > > >one of the possible fields in a multifield classifier. We are very close > > >to Last Call in the IPv6 WG on a proper definition of the FlowID, but > > >the IPv6 WG will certainly not be specifiying how it is used in > > >specific QOS solutions such as diffserv or intserv. > > > > > >The only issue for the diffserv MIB is whether we need to add a > > >wildcard, and for that I am waiting until Fred is back on-line. > > > > > > Brian > > > > > >Kwok Ho Chan wrote: > > > > > > > > (Please note I have added Brian Carpenter and Kathie Nicols to the > CC list > > > > as we are talking about possible impact to the DiffServ MIB.) > > > > > > > > Hi Brian, Juergen, all: > > > > I am using this E-Mail as reply to both of your E-Mails and keeping it > > > > under one E-Mail thread (as they are related and should be considered > > > > together for a solution). > > > > > > > > First on the point of terminology, as raised by Brian Williams: > > > > I agree that the term IGNORED is better than the term NOT-USED. > > > > With IGNORED meaning the filter will ignore the flow identifier in the > > > > IPv6 header during its filter processing. > > > > With the following examples: > > > > 1. Packet FlowLabel = 0, Filter FlowId = 0, filter Satisfied. > > > > Notice Packet FlowLabel = 0 indicates the sending host is not > using > > > > the IPv6 header's FlowLabel field. > > > > 2. Packet FlowLabel = ABC, Filter FlowId = ABC, filter Satisfied. > > > > 3. Packet FlowLabel = DEF, Filter FlowId = 0, FilterNegation = > true, filter > > > > Satisfied. > > > > Notice this is Wildcard for cases when FlowLabel is used by the > > > End Host. > > > > As Packet FlowLabel = 0, Filter FlowId = 0, FilterNegation = true, > > > > filter NotSatisfied. > > > > 4. Packet FlowLabel = "AnyValue", Filter FlowId = IGNORED. > > > > This instructs the filtering mechanism to not-use the Packet > FlowLabel > > > > field > > > > as a filter criterion. > > > > The behavior is for the filtering mechanism to NOT based the event > > > > generation > > > > decision using the Packet FlowLabel field. > > > > I can see someone may use some wildcarding functionality to > implement > > > > this. > > > > But that is implementation. We need to capture the feature > > > > description, not > > > > jumping to the implementation conclusions. > > > > > > > > As for the anolog to Dscp and DscpOrAny (defined in RFC 3289, > DiffServ MIB) > > > > point indicated by Juergen: > > > > 1. "Dscp" > > > > "Dscp" is used by the DiffServ MIB for marking action of the DSCP > > > field. > > > > "Dscp" is NOT used by the Framework PIB. > > > > > > > > "FlowId" > > > > IMHO, this is out of scope for DiffServ MIB, unless we plan to > use the > > > > DiffServ MIB > > > > to set IPv6 parameters in IPv6 End Hosts. I think this should > be part > > > > of IPv6 MIBs > > > > (which I have not find any RFCs or drafts that address this > issue). > > > > This may be useful by IPv6 End Host (the only one that can set the > > > IPv6 > > > > Header FlowLabel field), but IMHO it is outside the scope of the > > > > Framework PIB. > > > > > > > > 2. "DscpOrAny" > > > > "DscpOrAny" is used by the DiffServ MIB for filter definition > > > purposes. > > > > "DscpOrAny" is used by the Framework PIB for filter definition > > > purposes. > > > > > > > > "FlowIdOrAny" or "FlowIdIgnored" > > > > Flavoring "FlowIdIgnored" based on above discussion. > > > > I think this can be used by both Framework PIB and DiffServ MIB. > > > > Should we define a "FlowIdIgnored" TC? > > > > If yes, where does it belong? > > > > > > > > At current time, we are addressing this issue in the Framework PIB > > > > context, > > > > hence the suggested change is for the Framework PIB only. > > > > Guidance is needed if this issue impacts other WGs or Areas. > > > > > > > > I hope the information of this discussion help in coming to a better > > > > solution for > > > > this issue. > > > > > > > > Thanks! > > > > -- Kwok -- > > > > > > > > At 10:32 AM 1/16/03 +1100, Brian Williams wrote: > > > > >Hi Kwok. > > > > >I find the terminology proposed in your update unclear: > > > > > > > > > >In your explanation, you have: > > > > >The requested change is to have a way for the PDP to indicate to the > > > PEP that > > > > >the frwkIpFilterFlowId attribute of frwkIpFilterEntry should not > be used > > > > >for defining > > > > >any filter match. > > > > > > > > > >This appears clear enough. But then the acutal text change > proposed is: > > > > > "The flow identifier in an IPv6 header. The value > > > > > 4294967295 for this attribute MUST be interpreted > > > > > as indication of this attribute NOT-USED, meaning > > > > > not any value of flow identifier in the IPv6 header will > > > > > result in a filter match. Notice this is different from > > > > > a wildcard match, in which case all values of flow > > > > > identifier in the IPv6 header will result in a filter > match." > > > > > > > > > >I think the text is unclear in two specific ways. > > > > > > > > > >Firstly, (assuming my assumption is correct), it would be much > clearer to > > > > >use the IGNORED, rather than the term NOT-USED. To em, NOT-USED > would be > > > > >applicable if the field was optional, and you are checking if the > field > > > > >was specifically not provided. However, since the field is a part > of the > > > > >v6 header, it is not clear how NOT-USED applies. > > > > > > > > > >The second part that is really unclear is how you should interpret: > > > > >"not any value of flow identifier in the IPv6 header will result in a > > > > >filter match." > > > > > > > > > >If you use the term IGNORED, then it is easy to explain that the field > > > > >shall not be considered in the filter match. > > > > > > > > > >Having made these comments on the current proposed text, I agree > with the > > > > >comments by Juergen below regarding the similarity to DSCP, and that a > > > > >consistent approach should be sought. > > > > >/brian > > > > > > > > > >Juergen Schoenwaelder wrote: > > > > > > > > > >>>>>>>Kwok Ho Chan writes: > > > > >>>>>>> > > > > >> > > > > >>Kwok> Hi all: I think we should call this "Not Used" FlowId condition > > > > >>Kwok> in framework PIB. > > > > >> > > > > >>[...] > > > > >> > > > > >>Kwok> To fix the "Not Used" case not realizable by the current > > > > >>Kwok> Framework PIB, we propose to make the following changes to the > > > > >>Kwok> Framework PIB: > > > > >> > > > > >>WAIT > > > > >> > > > > >>My reading here is that this is analog to Dscp and DscpOrAny. If this > > > > >>is true, then we have the same problem in the filter definition > of the > > > > >>DIFFSERV-MIB. And if this is the same problem, then we should have a > > > > >>similar way of addressing it. So perhaps we need to define FlowId and > > > > >>FlowIdOrAny TCs similar to the Dscp and DscpOrAny TCs so we can use > > > > >>the same solution everywhere. > > > > >> > > > > >>If we agree that this would be the correct way to do things, then we > > > > >>need to find out how to implement this with the current state of the > > > > >>set of documents involved. Note that I have added Bert and Fred > to the > > > > >>To: list since I think they should be involved in handling this if my > > > > >>interpretation of this situation is correct. > > > > >> > > > > >>/js > >-- >- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >Brian E Carpenter >Distinguished Engineer, Internet Standards & Technology, IBM >On assignment at the IBM Zurich Laboratory, Switzerland From owner-rap@ops.ietf.org Tue Jan 21 05:05:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24951 for ; Tue, 21 Jan 2003 05:05:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18avKV-000JfI-00 for rap-data@psg.com; Tue, 21 Jan 2003 02:08:27 -0800 Received: from agitator.ibr.cs.tu-bs.de ([134.169.34.18]) by psg.com with esmtp (Exim 3.36 #2) id 18avKR-000Jer-00 for rap@ops.ietf.org; Tue, 21 Jan 2003 02:08:23 -0800 Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.6/8.12.6/Debian-6Woody) with ESMTP id h0LA7qgQ001908 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Tue, 21 Jan 2003 11:07:52 +0100 Received: from hansa.ibr.cs.tu-bs.de (schoenw@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) with ESMTP id h0LA7qAa026609 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Tue, 21 Jan 2003 11:07:52 +0100 Received: (from schoenw@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) id h0LA7opY026606; Tue, 21 Jan 2003 11:07:50 +0100 Date: Tue, 21 Jan 2003 11:07:50 +0100 Message-Id: <200301211007.h0LA7opY026606@hansa.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: khchan@NortelNetworks.com CC: brian@hursley.ibm.com, khchan@NortelNetworks.com, brian.williams@ericsson.com.au, bwijnen@lucent.com, fred@cisco.com, rap@ops.ietf.org, em.dumont@wanadoo.fr, nichols@packetdesign.com In-reply-to: <5.2.0.9.0.20030120122218.03272900@zbl6c002.corpeast.baynetworks.com> (message from Kwok Ho Chan on Mon, 20 Jan 2003 12:29:33 -0500) Subject: Re: wildcard flowid in framework PIB? References: <200301152117.h0FLHBxj031821@hansa.ibr.cs.tu-bs.de> <5.0.0.25.0.20021107183347.02532ea0@zbl6c002.corpeast.baynetworks.com> <5.0.0.25.0.20021107201344.024af3d0@zbl6c002.corpeast.baynetworks.com> <5.2.0.9.0.20030115152727.022fa150@zbl6c002.corpeast.baynetworks.com> <200301152117.h0FLHBxj031821@hansa.ibr.cs.tu-bs.de> <5.2.0.9.0.20030117100813.02fe1980@zbl6c002.corpeast.baynetworks.com> <5.2.0.9.0.20030117144502.0429a7b0@zbl6c002.corpeast.baynetworks.com> <5.2.0.9.0.20030120122218.03272900@zbl6c002.corpeast.baynetworks.com> X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01 version=2.43 Sender: owner-rap@ops.ietf.org Precedence: bulk >>>>> Kwok Ho Chan writes: Kwok> The response I provided in the E-Mail thread below is to Kwok> indicate that Diffserv MIB, Framework PIB, Diffserv PIB does not Kwok> require the TC (suggested by Juergen) for setting/marking of the Kwok> FlowID field in the IPv6 header. I never suggested to introduce these TCs to change something in a packet. This is a mis-understanding on your side. /js -- Juergen Schoenwaelder From owner-rap@ops.ietf.org Tue Jan 21 05:17:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25040 for ; Tue, 21 Jan 2003 05:17:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18avWD-000K1R-00 for rap-data@psg.com; Tue, 21 Jan 2003 02:20:33 -0800 Received: from agitator.ibr.cs.tu-bs.de ([134.169.34.18]) by psg.com with esmtp (Exim 3.36 #2) id 18avW9-000K1B-00 for rap@ops.ietf.org; Tue, 21 Jan 2003 02:20:30 -0800 Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.6/8.12.6/Debian-6Woody) with ESMTP id h0LAK1gQ003392 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Tue, 21 Jan 2003 11:20:01 +0100 Received: from hansa.ibr.cs.tu-bs.de (schoenw@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) with ESMTP id h0LAK1Aa026746 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Tue, 21 Jan 2003 11:20:01 +0100 Received: (from schoenw@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) id h0LAK008026743; Tue, 21 Jan 2003 11:20:00 +0100 Date: Tue, 21 Jan 2003 11:20:00 +0100 Message-Id: <200301211020.h0LAK008026743@hansa.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: bwijnen@lucent.com CC: khchan@NortelNetworks.com, brian.williams@ericsson.com.au, bwijnen@lucent.com, fred@cisco.com, rap@ops.ietf.org, em.dumont@wanadoo.fr, brian@hursley.ibm.com, nichols@packetdesign.com In-reply-to: <7D5D48D2CAA3D84C813F5B154F43B155AA9B41@nl0006exch001u.nl.lucent.com> (bwijnen@lucent.com) Subject: Re: wildcard flowid in framework PIB? References: <7D5D48D2CAA3D84C813F5B154F43B155AA9B41@nl0006exch001u.nl.lucent.com> X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01 version=2.43 Sender: owner-rap@ops.ietf.org Precedence: bulk >>>>> Wijnen, Bert (Bert) writes: Bert> I think FlowIdOrAny is the better name for a TC. The reason is, Bert> that the wildcard value does not always have to mean that the Bert> flowID is to be ignored. Agreed. Bert> The TC would/should look as follows I think: [...] I would prefer to use -1 as a special value rather than using 4294967295. So what I would like to see defined are the following two TCs: FlowId TECTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The flow identifier in an IPv6 header that may be used to discriminate traffic flows." REFERENCE "RFC 2460" SYNTAX Unsigned32 (0..1048575) FlowIdOrAny TECTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The flow identifier in an IPv6 header that may be used to discriminate traffic flows. The value of -1 is used to indicate a wildcard, i.e. any value." REFERENCE "RFC 2460" SYNTAX Unsigned32 (-1 | 0..1048575) Open issues: - Is the flow identifier the same as the flow label? I guess so. If this is true, then we should probably use the TC names FlowLabel and FlowLableOrAny and also change the wordings in the description clause. - The name of the MIB modules which will contain these definitions. - Since Fred kind of said that the diffServMultiFieldClfrFlowId object should have had a wildcard, can we agree that this is actually a bug in RFC 3289 which will be fixed by using FlowIdOrAny in the next revision of the DIFFSERV-MIB? /js -- Juergen Schoenwaelder From owner-rap@ops.ietf.org Tue Jan 21 05:21:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25073 for ; Tue, 21 Jan 2003 05:21:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18ava9-000K86-00 for rap-data@psg.com; Tue, 21 Jan 2003 02:24:37 -0800 Received: from agitator.ibr.cs.tu-bs.de ([134.169.34.18]) by psg.com with esmtp (Exim 3.36 #2) id 18ava7-000K7o-00 for rap@ops.ietf.org; Tue, 21 Jan 2003 02:24:35 -0800 Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.6/8.12.6/Debian-6Woody) with ESMTP id h0LAONgQ004168 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Tue, 21 Jan 2003 11:24:23 +0100 Received: from hansa.ibr.cs.tu-bs.de (schoenw@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) with ESMTP id h0LAONAa026848 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Tue, 21 Jan 2003 11:24:23 +0100 Received: (from schoenw@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) id h0LAONtX026845; Tue, 21 Jan 2003 11:24:23 +0100 Date: Tue, 21 Jan 2003 11:24:23 +0100 Message-Id: <200301211024.h0LAONtX026845@hansa.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: bwijnen@lucent.com CC: rap@ops.ietf.org, diffserv@ietf.org In-reply-to: <7D5D48D2CAA3D84C813F5B154F43B155AA9B41@nl0006exch001u.nl.lucent.com> (bwijnen@lucent.com) Subject: FlowId and FlowIdOrAny References: <7D5D48D2CAA3D84C813F5B154F43B155AA9B41@nl0006exch001u.nl.lucent.com> X-Spam-Status: No, hits=-1.1 required=5.0 tests=IN_REP_TO,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_01_02 version=2.43 Sender: owner-rap@ops.ietf.org Precedence: bulk I changed the subject line and fixed the proposed TC. So here is where I think we are. I have also reduced the CC list and I have added the diffserv mailing list since diffserv folks should be in the loop I think. FlowId TECTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The flow identifier in an IPv6 header that may be used to discriminate traffic flows." REFERENCE "RFC 2460" SYNTAX Integer32 (0..1048575) FlowIdOrAny TECTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The flow identifier in an IPv6 header that may be used to discriminate traffic flows. The value of -1 is used to indicate a wildcard, i.e. any value." REFERENCE "RFC 2460" SYNTAX Integer32 (-1 | 0..1048575) Open issues: - Is the flow identifier the same as the flow label? I guess so. If this is true, then we should probably use the TC names FlowLabel and FlowLableOrAny and also change the wordings in the description clause. - The name of the MIB modules which will contain these definitions. - Since Fred kind of said that the diffServMultiFieldClfrFlowId object should have had a wildcard, can we agree that this is actually a bug in RFC 3289 which will be fixed by using FlowIdOrAny in the next revision of the DIFFSERV-MIB? /js -- Juergen Schoenwaelder From owner-rap@ops.ietf.org Tue Jan 21 07:07:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26577 for ; Tue, 21 Jan 2003 07:07:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18axEi-000Mav-00 for rap-data@psg.com; Tue, 21 Jan 2003 04:10:36 -0800 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by psg.com with esmtp (Exim 3.36 #2) id 18axEg-000MZc-00 for rap@ops.ietf.org; Tue, 21 Jan 2003 04:10:34 -0800 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0LCA0T24472 for ; Tue, 21 Jan 2003 07:10:01 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Jan 2003 13:10:00 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155BADE65@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Juergen Schoenwaelder , bwijnen@lucent.com Cc: rap@ops.ietf.org, diffserv@ietf.org Subject: RE: FlowId and FlowIdOrAny Date: Tue, 21 Jan 2003 13:09:45 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Status: No, hits=-0.4 required=5.0 tests=EXCHANGE_SERVER,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-rap@ops.ietf.org Precedence: bulk Ok, good, cause I was surprised to see a -1 in an Unsigned32. Now... if we do this, then this could still be used by the framework pib. However, for the diffserv-mib it would mean they must deprecate a current object and create a new one (switching from Unsigned to Integer32 causes a change on the wire!). The solution presented earlier could be considered as a bug fix and would not require the diffserv-MIB to deprecate the existing object Thanks, Bert > -----Original Message----- > From: Juergen Schoenwaelder [mailto:schoenw@ibr.cs.tu-bs.de] > Sent: dinsdag 21 januari 2003 11:24 > To: bwijnen@lucent.com > Cc: rap@ops.ietf.org; diffserv@ietf.org > Subject: FlowId and FlowIdOrAny > > > > I changed the subject line and fixed the proposed TC. So here is where > I think we are. I have also reduced the CC list and I have added the > diffserv mailing list since diffserv folks should be in the loop I > think. > > FlowId TECTUAL-CONVENTION > DISPLAY-HINT "d" > STATUS current > DESCRIPTION > "The flow identifier in an IPv6 header that may be used to > discriminate traffic flows." > REFERENCE > "RFC 2460" > SYNTAX Integer32 (0..1048575) > > FlowIdOrAny TECTUAL-CONVENTION > DISPLAY-HINT "d" > STATUS current > DESCRIPTION > "The flow identifier in an IPv6 header that may be used to > discriminate traffic flows. The value of -1 is used to > indicate a wildcard, i.e. any value." > REFERENCE > "RFC 2460" > SYNTAX Integer32 (-1 | 0..1048575) > > Open issues: > > - Is the flow identifier the same as the flow label? I guess so. If > this is true, then we should probably use the TC names FlowLabel > and FlowLableOrAny and also change the wordings in the description > clause. > > - The name of the MIB modules which will contain these definitions. > > - Since Fred kind of said that the diffServMultiFieldClfrFlowId > object should have had a wildcard, can we agree that this is > actually a bug in RFC 3289 which will be fixed by using FlowIdOrAny > in the next revision of the DIFFSERV-MIB? > > /js > > -- > Juergen Schoenwaelder From owner-rap@ops.ietf.org Tue Jan 21 07:37:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26979 for ; Tue, 21 Jan 2003 07:37:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18axhW-000NXr-00 for rap-data@psg.com; Tue, 21 Jan 2003 04:40:22 -0800 Received: from agitator.ibr.cs.tu-bs.de ([134.169.34.18]) by psg.com with esmtp (Exim 3.36 #2) id 18axhU-000NXa-00 for rap@ops.ietf.org; Tue, 21 Jan 2003 04:40:21 -0800 Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.6/8.12.6/Debian-6Woody) with ESMTP id h0LCdmgQ024811 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Tue, 21 Jan 2003 13:39:48 +0100 Received: from hansa.ibr.cs.tu-bs.de (schoenw@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) with ESMTP id h0LCdlAa029668 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Tue, 21 Jan 2003 13:39:47 +0100 Received: (from schoenw@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) id h0LCdh8T029652; Tue, 21 Jan 2003 13:39:43 +0100 Date: Tue, 21 Jan 2003 13:39:43 +0100 Message-Id: <200301211239.h0LCdh8T029652@hansa.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: bwijnen@lucent.com CC: bwijnen@lucent.com, rap@ops.ietf.org, diffserv@ietf.org In-reply-to: <7D5D48D2CAA3D84C813F5B154F43B155BADE65@nl0006exch001u.nl.lucent.com> (bwijnen@lucent.com) Subject: Re: FlowId and FlowIdOrAny References: <7D5D48D2CAA3D84C813F5B154F43B155BADE65@nl0006exch001u.nl.lucent.com> X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01 version=2.43 Sender: owner-rap@ops.ietf.org Precedence: bulk >>>>> Wijnen, Bert (Bert) writes: Bert> Now... if we do this, then this could still be used by the Bert> framework pib. However, for the diffserv-mib it would mean they Bert> must deprecate a current object and create a new one (switching Bert> from Unsigned to Integer32 causes a change on the wire!). Oops, I missed that part of the picture. So if there is concensus to change the range as a bug fix in the DIFFSERV0MIB without introducing a new object (which formally the SMIv2 would require to do), then using Unsigned32 makes some sense. Note that this will also most likely include the definition of a DEFVAL which is in fact the new value. However, if we decided that it is safer to use deprecate the filter obejct and introduce a new one, I prefer to use Integer32. BTW, this is what I found in the INTEGRATED-SERVICES-MIB: intSrvFlowFlowId OBJECT-TYPE SYNTAX INTEGER (0..16777215) MAX-ACCESS read-only STATUS current DESCRIPTION "The flow ID that this sender is using, if this is an IPv6 session." ::= { intSrvFlowEntry 11 } Note that this range is [0..2^24-1] while the other definitions under discussion use a range of [0..2^20-1]. Note that RFC 2460 says: : Flow Label 20-bit flow label. See section 6. /js -- Juergen Schoenwaelder From owner-rap@ops.ietf.org Tue Jan 21 10:21:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02197 for ; Tue, 21 Jan 2003 10:21:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18b0Fy-0003B3-00 for rap-data@psg.com; Tue, 21 Jan 2003 07:24:06 -0800 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by psg.com with esmtp (Exim 3.36 #2) id 18b0Fv-00039r-00 for rap@ops.ietf.org; Tue, 21 Jan 2003 07:24:03 -0800 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0LFNVg17961 for ; Tue, 21 Jan 2003 10:23:31 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Jan 2003 16:23:26 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155BADF67@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Brian E Carpenter , Juergen Schoenwaelder Cc: bwijnen@lucent.com, rap@ops.ietf.org, diffserv@ietf.org Subject: RE: [Diffserv] Re: FlowId and FlowIdOrAny Date: Tue, 21 Jan 2003 16:21:47 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Status: No, hits=-0.1 required=5.0 tests=EXCHANGE_SERVER,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-rap@ops.ietf.org Precedence: bulk OK, so if I understand you correctly, then the newly proposed TCs would also be useable for the Intserv MIB when they do a revision, right? And again that can then be considered a bug fix. So we now have a conflict in that if we make it Integer32, then diffserv MIB needs to deprecate and create a new object If we make it Unsigned32, then Intserv MIB needs to deprecate and create a new object. It then seems to me that making it Integer32 as suggested by Juergen then makes the most sense, since that seems to be then more consistent with how we have done this at other places (that is, used a -1 value to mean any). Comments? Thanks, Bert > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: dinsdag 21 januari 2003 15:18 > To: Juergen Schoenwaelder > Cc: bwijnen@lucent.com; rap@ops.ietf.org; diffserv@ietf.org > Subject: Re: [Diffserv] Re: FlowId and FlowIdOrAny > > > The flow label in IPv6 was 24 bits at one time. So that looks like > a minor obsolescence in the Intserv MIB. > > Brian > > Juergen Schoenwaelder wrote: > > > > >>>>> Wijnen, Bert (Bert) writes: > > > > Bert> Now... if we do this, then this could still be used by the > > Bert> framework pib. However, for the diffserv-mib it > would mean they > > Bert> must deprecate a current object and create a new one > (switching > > Bert> from Unsigned to Integer32 causes a change on the wire!). > > > > Oops, I missed that part of the picture. So if there is concensus to > > change the range as a bug fix in the DIFFSERV0MIB without > introducing > > a new object (which formally the SMIv2 would require to do), then > > using Unsigned32 makes some sense. Note that this will also most > > likely include the definition of a DEFVAL which is in fact the new > > value. However, if we decided that it is safer to use deprecate the > > filter obejct and introduce a new one, I prefer to use Integer32. > > > > BTW, this is what I found in the INTEGRATED-SERVICES-MIB: > > > > intSrvFlowFlowId OBJECT-TYPE > > SYNTAX INTEGER (0..16777215) > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The flow ID that this sender is using, if > > this is an IPv6 session." > > ::= { intSrvFlowEntry 11 } > > > > Note that this range is [0..2^24-1] while the other > definitions under > > discussion use a range of [0..2^20-1]. Note that RFC 2460 says: > > > > : Flow Label 20-bit flow label. See section 6. > > > > /js > > > > -- > > Juergen Schoenwaelder > > From owner-rap@ops.ietf.org Tue Jan 21 12:17:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05653 for ; Tue, 21 Jan 2003 12:17:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18b23s-00080h-00 for rap-data@psg.com; Tue, 21 Jan 2003 09:19:44 -0800 Received: from agitator.ibr.cs.tu-bs.de ([134.169.34.18]) by psg.com with esmtp (Exim 3.36 #2) id 18b23p-00080U-00 for rap@ops.ietf.org; Tue, 21 Jan 2003 09:19:42 -0800 Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.6/8.12.6/Debian-6Woody) with ESMTP id h0LHJMgQ005254 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Tue, 21 Jan 2003 18:19:22 +0100 Received: from hansa.ibr.cs.tu-bs.de (schoenw@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) with ESMTP id h0LHJLAa004975 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Tue, 21 Jan 2003 18:19:22 +0100 Received: (from schoenw@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) id h0LHJL8Q004972; Tue, 21 Jan 2003 18:19:21 +0100 Date: Tue, 21 Jan 2003 18:19:21 +0100 Message-Id: <200301211719.h0LHJL8Q004972@hansa.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: dan@dma.isg.mot.com CC: bwijnen@lucent.com, rap@ops.ietf.org, diffserv@ietf.org In-reply-to: <3E2D7686.F5E7AC92@dma.isg.mot.com> (message from Dan Grossman on Tue, 21 Jan 2003 11:34:14 -0500) Subject: Re: [Diffserv] FlowId and FlowIdOrAny References: <7D5D48D2CAA3D84C813F5B154F43B155AA9B41@nl0006exch001u.nl.lucent.com> <200301211024.h0LAONtX026845@hansa.ibr.cs.tu-bs.de> <3E2D7686.F5E7AC92@dma.isg.mot.com> X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01 version=2.43 Sender: owner-rap@ops.ietf.org Precedence: bulk >>>>> Dan Grossman writes: Dan> Um... since you're bringing the Diffserv folks into the middle of Dan> the conversation, would it be possible to clue us in as to what Dan> we're talking about? Thanks. I can try - not sure I have the details right though since I joined late in this as well. I think the core of the story is that the FRAMEWORK-PIB currently defined in draft-ietf-rap-frameworkpib-09.txt has the following definition (in a generic filter): frwkIpFilterFlowId OBJECT-TYPE SYNTAX Unsigned32 (0..1048575) STATUS current DESCRIPTION "The flow identifier in an IPv6 header." ::= { frwkIpFilterEntry 7 } Someone observed that this definition does not have a value to indicate that this specific attribute is to be ignored when matching packets. So it was suggested to change the definition. Note that this document is sitting in 48 hour RFC review. Some people observed this and checked the classifier definition in the DIFFSERV-MIB. The DIFFSERV-MIB says: diffServMultiFieldClfrFlowId OBJECT-TYPE SYNTAX Unsigned32 (0..1048575) MAX-ACCESS read-create STATUS current DESCRIPTION "The flow identifier in an IPv6 header." ::= { diffServMultiFieldClfrEntry 8 } It looks like this definition as well lacks a wildcard mechanism. Fred Baker already wrote that he had one in mind but somehow if never got into the mind. Note that the DIFFSERV-MIB is in RFC 3289 (Proposed Standard). Triggered by a query from Kwok, I checked the INTEGRATED-SERVICES-MIB which has this definition: intSrvFlowFlowId OBJECT-TYPE SYNTAX INTEGER (0..16777215) MAX-ACCESS read-only STATUS current DESCRIPTION "The flow ID that this sender is using, if this is an IPv6 session." ::= { intSrvFlowEntry 11 } This is published in RFC 2213 (Proposed Standard). It would be nice to have common TCs in place for flow labels (or are they called flow ids?) much in the same way we have common TCs for DSCPs. And this is how we got to where we are (as far as I understand the situation). While we can't put common definitions in place while the ID is in 48 hours review, we hopefully can figure out a plan how we can address this proliferation of different ways to represent flow lables when documents are revised. /js -- Juergen Schoenwaelder From owner-rap@ops.ietf.org Wed Jan 22 09:16:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25400 for ; Wed, 22 Jan 2003 09:16:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18bLjC-000GuM-00 for rap-data@psg.com; Wed, 22 Jan 2003 06:19:42 -0800 Received: from agitator.ibr.cs.tu-bs.de ([134.169.34.18]) by psg.com with esmtp (Exim 3.36 #2) id 18bLj7-000Gu9-00 for rap@ops.ietf.org; Wed, 22 Jan 2003 06:19:37 -0800 Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.6/8.12.6/Debian-6Woody) with ESMTP id h0MEJVgQ027229 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Wed, 22 Jan 2003 15:19:31 +0100 Received: from hansa.ibr.cs.tu-bs.de (schoenw@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) with ESMTP id h0MEJVAa022848 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Wed, 22 Jan 2003 15:19:31 +0100 Received: (from schoenw@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) id h0MEJSZG022843; Wed, 22 Jan 2003 15:19:28 +0100 Date: Wed, 22 Jan 2003 15:19:28 +0100 Message-Id: <200301221419.h0MEJSZG022843@hansa.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: rap@ops.ietf.org, diffserv@ietf.org In-reply-to: <200301211024.h0LAONtX026845@hansa.ibr.cs.tu-bs.de> (message from Juergen Schoenwaelder on Tue, 21 Jan 2003 11:24:23 +0100) Subject: Re: FlowId and FlowIdOrAny References: <7D5D48D2CAA3D84C813F5B154F43B155AA9B41@nl0006exch001u.nl.lucent.com> <200301211024.h0LAONtX026845@hansa.ibr.cs.tu-bs.de> X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,REFERENCES,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01 version=2.43 Sender: owner-rap@ops.ietf.org Precedence: bulk I found some more objects that seem to model a flow label. It turns out that MIB authors are really creative... draft-ietf-ipsp-ipsec-conf-mib-05.txt: ihfIPv6FlowLabel OBJECT-TYPE SYNTAX OCTET STRING (SIZE(3)) MAX-ACCESS read-create STATUS current DESCRIPTION "The IPv6 Flow Label that the packet must match against. This object is only used if ipv6FlowLabel is set in ihfType." ::= { ipHeaderFilterEntry 13 } They obviously have another mechanism to control whether the object participates in a match. draft-ietf-rmonmib-sspm-mib-06.txt: sspmSourceProfileFlowLabel OBJECT-TYPE SYNTAX Integer32 (0..1048575) -- 20-bit range (0 to 0xfffff) MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to specify the Flow Label in a IPv6 packet (RFC 2460) to force special handling by the IPv6 routers for non-default quality-of-service. This object is meaningful only when sspmSourceDestAddressType is ipv6(2). The value of this object defaults to zero if not set." DEFVAL { 0 } ::= { sspmSourceProfileEntry 7 } This object seems to actually control how the flow label looks like in packets coming from a synthetic traffic source. Note that these objects are called flow label rather than flowid and hence I did not find them the first time... /js -- Juergen Schoenwaelder From owner-rap@ops.ietf.org Wed Jan 22 11:50:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00610 for ; Wed, 22 Jan 2003 11:50:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18bO7i-000Lyp-00 for rap-data@psg.com; Wed, 22 Jan 2003 08:53:10 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18bO7f-000Lyd-00 for rap@ops.ietf.org; Wed, 22 Jan 2003 08:53:07 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18bO7e-0000GD-00 for rap@ops.ietf.org; Wed, 22 Jan 2003 08:53:06 -0800 Message-Id: <3E2D079C.7BA350C7@hursley.ibm.com> Mime-Version: 1.0 References: <5.2.0.9.2.20030120065700.03af1bc0@mira-sjcm-4.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 21 Jan 2003 09:41:00 +0100 From: Brian E Carpenter To: Fred Baker Cc: "Wijnen, Bert (Bert)" , Kwok Ho Chan , Brian Williams , Juergen Schoenwaelder , rap@ops.ietf.org, em.dumont@wanadoo.fr, nichols@packetdesign.com Subject: Diffserv MIB [was Re: wildcard flowid in framework PIB?] X-Spam-Status: No, hits=-0.7 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO,SPAM_PHRASE_02_03 version=2.43 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] I think we had a couple of other minor bugs that someone found in the MIB a few months back. So, do we need to spin RFC 3289? Brian Fred Baker wrote: > > hmm. The field is > > diffServMultiFieldClfrFlowId OBJECT-TYPE > SYNTAX Unsigned32 (0..1048575) > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The flow identifier in an IPv6 header." > ::= { diffServMultiFieldClfrEntry 8 } > > It allows you to set the value compared against, which is to say "decide > what packets to select"; nothing in the MIB permits you to change the > packet other than the "set" action, and that sets the DSCP. > > I think I intended to have a boolean (a TruthValue) that allowed you to > wildcard it, and have it default to being wildcarded (like all the other > fields in the MFClassifier); however, I don't see the boolean in the MIB. oops. > > At 03:07 AM 1/18/2003 +0100, Wijnen, Bert (Bert) wrote: > > > > > > Correct. The FlowID is immutable (unlike the DSCP). Are you saying the > > > MIB allows setting the FlowID? If so, that's a bug. > > > > >No, I think the flowID in the MIB is settable, but it functions as > >the flowID on which one wants to filter or classify. So it is not changing > >the flowid in the protocol PDUs that pass by, but only comparing it to > >the SETable MIB value(s). And I do think that it makes sense to be > >able to have a wildcard for that, no? > > > >Bert From owner-rap@ops.ietf.org Wed Jan 22 11:55:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00845 for ; Wed, 22 Jan 2003 11:55:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18bODQ-000MCQ-00 for rap-data@psg.com; Wed, 22 Jan 2003 08:59:04 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18bODN-000MCA-00 for rap@ops.ietf.org; Wed, 22 Jan 2003 08:59:02 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18bODM-0000HP-00 for rap@ops.ietf.org; Wed, 22 Jan 2003 08:59:00 -0800 Message-Id: <3E2D5689.F92C3392@hursley.ibm.com> Mime-Version: 1.0 References: <7D5D48D2CAA3D84C813F5B154F43B155BADE65@nl0006exch001u.nl.lucent.com> <200301211239.h0LCdh8T029652@hansa.ibr.cs.tu-bs.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 21 Jan 2003 15:17:45 +0100 From: Brian E Carpenter To: Juergen Schoenwaelder Cc: bwijnen@lucent.com, rap@ops.ietf.org, diffserv@ietf.org Subject: Re: [Diffserv] Re: FlowId and FlowIdOrAny X-Spam-Status: No, hits=-1.0 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO,SPAM_PHRASE_01_02 version=2.43 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] The flow label in IPv6 was 24 bits at one time. So that looks like a minor obsolescence in the Intserv MIB. Brian Juergen Schoenwaelder wrote: > > >>>>> Wijnen, Bert (Bert) writes: > > Bert> Now... if we do this, then this could still be used by the > Bert> framework pib. However, for the diffserv-mib it would mean they > Bert> must deprecate a current object and create a new one (switching > Bert> from Unsigned to Integer32 causes a change on the wire!). > > Oops, I missed that part of the picture. So if there is concensus to > change the range as a bug fix in the DIFFSERV0MIB without introducing > a new object (which formally the SMIv2 would require to do), then > using Unsigned32 makes some sense. Note that this will also most > likely include the definition of a DEFVAL which is in fact the new > value. However, if we decided that it is safer to use deprecate the > filter obejct and introduce a new one, I prefer to use Integer32. > > BTW, this is what I found in the INTEGRATED-SERVICES-MIB: > > intSrvFlowFlowId OBJECT-TYPE > SYNTAX INTEGER (0..16777215) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The flow ID that this sender is using, if > this is an IPv6 session." > ::= { intSrvFlowEntry 11 } > > Note that this range is [0..2^24-1] while the other definitions under > discussion use a range of [0..2^20-1]. Note that RFC 2460 says: > > : Flow Label 20-bit flow label. See section 6. > > /js > > -- > Juergen Schoenwaelder From owner-rap@ops.ietf.org Wed Jan 22 12:03:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01172 for ; Wed, 22 Jan 2003 12:03:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18bOL3-000MT0-00 for rap-data@psg.com; Wed, 22 Jan 2003 09:06:57 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18bOL0-000MSb-00 for rap@ops.ietf.org; Wed, 22 Jan 2003 09:06:54 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18bOKz-0000IZ-00 for rap@ops.ietf.org; Wed, 22 Jan 2003 09:06:53 -0800 Message-ID: <3E2D7686.F5E7AC92@dma.isg.mot.com> MIME-Version: 1.0 References: <7D5D48D2CAA3D84C813F5B154F43B155AA9B41@nl0006exch001u.nl.lucent.com> <200301211024.h0LAONtX026845@hansa.ibr.cs.tu-bs.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 21 Jan 2003 11:34:14 -0500 From: Dan Grossman To: Juergen Schoenwaelder CC: bwijnen@lucent.com, rap@ops.ietf.org, diffserv@ietf.org Subject: Re: [Diffserv] FlowId and FlowIdOrAny X-Spam-Status: No, hits=-2.0 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO, SPAM_PHRASE_03_05 version=2.43 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Um... since you're bringing the Diffserv folks into the middle of the conversation, would it be possible to clue us in as to what we're talking about? Thanks. Juergen Schoenwaelder wrote: > I changed the subject line and fixed the proposed TC. So here is where > I think we are. I have also reduced the CC list and I have added the > diffserv mailing list since diffserv folks should be in the loop I > think. > > FlowId TECTUAL-CONVENTION > DISPLAY-HINT "d" > STATUS current > DESCRIPTION > "The flow identifier in an IPv6 header that may be used to > discriminate traffic flows." > REFERENCE > "RFC 2460" > SYNTAX Integer32 (0..1048575) > > FlowIdOrAny TECTUAL-CONVENTION > DISPLAY-HINT "d" > STATUS current > DESCRIPTION > "The flow identifier in an IPv6 header that may be used to > discriminate traffic flows. The value of -1 is used to > indicate a wildcard, i.e. any value." > REFERENCE > "RFC 2460" > SYNTAX Integer32 (-1 | 0..1048575) > > Open issues: > > - Is the flow identifier the same as the flow label? I guess so. If > this is true, then we should probably use the TC names FlowLabel > and FlowLableOrAny and also change the wordings in the description > clause. > > - The name of the MIB modules which will contain these definitions. > > - Since Fred kind of said that the diffServMultiFieldClfrFlowId > object should have had a wildcard, can we agree that this is > actually a bug in RFC 3289 which will be fixed by using FlowIdOrAny > in the next revision of the DIFFSERV-MIB? > > /js > > -- > Juergen Schoenwaelder > > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html From owner-rap@ops.ietf.org Wed Jan 22 20:51:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13651 for ; Wed, 22 Jan 2003 20:51:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18bWYy-000HKQ-00 for rap-data@psg.com; Wed, 22 Jan 2003 17:53:52 -0800 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by psg.com with esmtp (Exim 3.36 #2) id 18bWYu-000HHY-00 for rap@ops.ietf.org; Wed, 22 Jan 2003 17:53:48 -0800 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0N1rGU09524 for ; Wed, 22 Jan 2003 20:53:16 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Jan 2003 02:53:15 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155BAE372@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Rap-wg (E-mail)" , Diffserv@ietf.org Subject: FW: FW: FlowId and FlowIdOrAny Date: Thu, 23 Jan 2003 02:51:55 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Status: No, hits=-0.2 required=5.0 tests=EXCHANGE_SERVER,OUTLOOK_FW_MSG,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-rap@ops.ietf.org Precedence: bulk I checked with authors and WG chair of SSPM MIB I have a request outstanding to author(s) of ipsec-conf-mib Thanks, Bert -----Original Message----- From: Andy Bierman [mailto:abierman@cisco.com] Sent: woensdag 22 januari 2003 23:15 To: Wijnen, Bert (Bert) Cc: Dan Romascanu (E-mail); Carl Kalbfleisch (E-mail); Bob Cole (E-mail) Subject: Re: FW: FlowId and FlowIdOrAny At 04:31 PM 1/22/2003 +0100, Wijnen, Bert (Bert) wrote: >Are you following RAP or DIFFSERV WG mailing lists? I am on the diffserv list. Thanks for bringing this to our attention. To be consistent with previous decisions related to the DSMON MIB, the RMONMIB WG would prefer it if the WG owning IPv6 flow standards would publish a MIB module containing the appropriate TCs, so we can import them into the SSPM MIB. thanks, Andy >We are discussing a common set of TCs to be used by multiple >MIB and PIB modules. > >If your not up to date, you may want to check the mailing lists >archives. Discussion was over teh last week or two. > >Thanks, >Bert >p.s. I know I have this doc in AD review.... but you may >want to check this part of it yet > >-----Original Message----- >From: Juergen Schoenwaelder [mailto:schoenw@ibr.cs.tu-bs.de] >Sent: woensdag 22 januari 2003 15:19 >To: rap@ops.ietf.org; diffserv@ietf.org >Subject: Re: FlowId and FlowIdOrAny > > > >I found some more objects that seem to model a flow label. It turns >out that MIB authors are really creative... > >draft-ietf-ipsp-ipsec-conf-mib-05.txt: > > ihfIPv6FlowLabel OBJECT-TYPE > SYNTAX OCTET STRING (SIZE(3)) > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The IPv6 Flow Label that the packet must match against. > This object is only used if ipv6FlowLabel is set in ihfType." > ::= { ipHeaderFilterEntry 13 } > > They obviously have another mechanism to control whether the > object participates in a match. > >draft-ietf-rmonmib-sspm-mib-06.txt: > > sspmSourceProfileFlowLabel OBJECT-TYPE > SYNTAX Integer32 (0..1048575) -- 20-bit range (0 to 0xfffff) > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "This object is used to specify the Flow Label in a IPv6 > packet (RFC 2460) to force special handling by the IPv6 routers for > non-default quality-of-service. > > This object is meaningful only when sspmSourceDestAddressType is > ipv6(2). The value of this object defaults to zero if not > set." > DEFVAL { 0 } > ::= { sspmSourceProfileEntry 7 } > > This object seems to actually control how the flow label looks like > in packets coming from a synthetic traffic source. > >Note that these objects are called flow label rather than flowid and >hence I did not find them the first time... > >/js > >-- >Juergen Schoenwaelder From owner-rap@ops.ietf.org Mon Jan 27 16:47:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28154 for ; Mon, 27 Jan 2003 16:47:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18dH8H-000AVe-00 for rap-data@psg.com; Mon, 27 Jan 2003 13:49:33 -0800 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by psg.com with esmtp (Exim 3.36 #1) id 18dH8E-000AVR-00 for rap@ops.ietf.org; Mon, 27 Jan 2003 13:49:30 -0800 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0RLnS600324 for ; Mon, 27 Jan 2003 16:49:28 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 27 Jan 2003 22:49:27 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155C82FA4@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Rap-wg (E-mail)" , Diffserv@ietf.org Subject: RE: FW: FlowId and FlowIdOrAny Date: Mon, 27 Jan 2003 22:49:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Status: No, hits=0.6 required=5.0 tests=EXCHANGE_SERVER,OUTLOOK_FW_MSG,SPAM_PHRASE_00_01 version=2.43 Sender: owner-rap@ops.ietf.org Precedence: bulk I am not hearing much progress. Appology for a long email posting. But I think it addresses all the issues and occurences of flowId or flowLabel (at least till someone tells me they found yet another one ;-)) The biggest problem exists for the RAP WG document for the framework PIB, cause it is in RFC 48-hour author call (for over a month already). The DIFFSERV PIB (also in RFC 38-hour author call for the same amount of time) of course cannot be published since it depends on the framework pib. The issue at hand is the question on how to specify that a flowID be ignored (wild-carded) for a filter. I think we've come to the conclusion that both the MIB and the PIB solutions need this. So we need a common solution. We've also found 3 other places where a flowID or a flowLabel (but the same thing is meant) is being used. That is in: - draft-ietf-ipsp-ipsec-conf-mib-05.txt which uses a 3-byte octet string and that seems wrong SYNTAX OCTET STRING (SIZE(3)) - draft-ietf-rmonmib-sspm-mib-06.txt which uses an Integer32: SYNTAX Integer32 (0..1048575) -- 20-bit range (0 to 0xfffff) - Integrated services MIB (RFC 2213) which uses INTEGER SYNTAX INTEGER (0..16777215) The Diffserv MIB (RFC3289) and the framework PIB were using an Unsigned 32, namely SYNTAX Unsigned32 (0..1048575) The framework PIB authors were suggesting a modification SYNTAX Unsigned32 (4294967295 | 0..1048575) So that the value 4294967295 would mean any (in other words one would ignore the flowID in when filtering). Fred (amin editor of the Diffserv MIB) wanted to add a boolean mib object to indicate if the flowID should be ignored when filtering. What I as OPS AD for the NM side see is that we have - too many different ways to represent a flowID or flowLabel. - there is currently no way to define a flowID or any - we need need a facility to specify flowIdOrAny. - we prefer to have one solution. - we have some docs that are still IDs and can easily be changed. - we have two docs that are difficult to change, namely the DIFSERV and the INTEGRATED SERVICES MIB. The difficulty is that if we change the encoding on the wire that we need to deprecate existing object and add a new one. If we keep the wire encoding the same, I think we can defend that it is a bug fix and the fact that some potential new values are now valid is acceptable; at least it would be less of a problem than having to deprecate an object and add a new one. - But even the two RFCs have different SYNTAX, so at least one of them needs to change if we want to specify flowID in a consistent way. So what do people want to do. My proposal is to do the following: - Someone creates a new ID that contains a small MIB module that contains two TCs: FlowId TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The flow identifier or flow Label in an IPv6 header that may be used to discriminate traffic flows. " SYNTAX Integer32 (0..1048575) FlowIdOrAny TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The flow identifier or flow lable in an IPv6 header that may be used to discriminate traffic flows. The value of -1 is used to indicate a wildcard, i.e. any value. " SYNTAX Integer32 (-1 | 0..1048575) We probably want to run this quickly by the IPv6 WG. What it would mean for the various documents is the following: - For the INTEGRATED-SERVICES-MIB (RFC2213), I see Fred as a co-author/editor..., whenever a new revision is done: - import the new FlowId TC - replace intSrvFlowFlowId OBJECT-TYPE SYNTAX INTEGER (0..16777215) with intSrvFlowFlowId OBJECT-TYPE SYNTAX FlowId I think we can consider this a BUG fix and allow this change that reduces the range of possible values. - by the way, I when I see intSrvFlowIfAddr, then probably we would want that to be done with the TCs from the INET-ADDRESS-MIB. I also wonder about the Port TC in that module - For the DIFFSERV-MIB (RFC3289), Fred is main editor, whenever a new revision is done, I think we need to: - import the new FlowIdOrAny TC - deprecate object diffServMultiFieldClfrFlowId - define a new object diffServMultiFieldClfrFlowLabel ?? or maybe diffServMultiFieldClfrFlowIdOrAny with syntax FlowIdOrAny - deprecate current MODULE-COMPLIANCEs, define a new one to remove ... FlowId and add ...FlowLable - For the draft-ietf-rap-frameworkpib-09.txt (or better the RFC-to-be) the final fix would be to make this change: - import FlowIdOrAny TC - replace frwkIpFilterFlowId OBJECT-TYPE SYNTAX Unsigned32 (0..1048575) with frwkIpFilterFlowId OBJECT-TYPE SYNTAX FlowIdOrAny - we can consider this as a last minute bug fix. If we agree that the final change may take too long, then we can make a temp fix: - replace frwkIpFilterFlowId OBJECT-TYPE SYNTAX Unsigned32 (0..1048575) with frwkIpFilterFlowId OBJECT-TYPE SYNTAX Integer32 (-1 | 0..1048575) DESCRIPTION "The flow identifier or flow lable in an IPv6 header that may be used to discriminate traffic flows. The value of -1 is used to indicate a wildcard, i.e. any value. " - whenever the RFC gets revised, then this can be replaced with the final fix, cause it does not change anything on the wire. - For draft-ietf-ipsp-ipsec-conf-mib-05.txt, main Editor Wes Hardaker, we can fix it as follows - import FlowId - replace ihfIPv6FlowLabel OBJECT-TYPE SYNTAX OCTET STRING (SIZE(3)) with ihfIPv6FlowLabel OBJECT-TYPE SYNTAX FlowId - this is still an ID, so the change is OK. Also, they use a BITS mask to indicate if the flowlabel must be ignored or not. So this works. It is a bit different than it is done in diffserv mib and framework pib, but at least it uses the same spec for FlowId. (or flowLabel) - for draft-ietf-rmonmib-sspm-mib-06.txt, not sure who is main editor it would mean - import FlowId - replace sspmSourceProfileFlowLabel OBJECT-TYPE SYNTAX Integer32 (0..1048575) -- 20-bit range (0 to 0xfffff) with sspmSourceProfileFlowLabel OBJECT-TYPE SYNTAX FlowId - this is still an ID, so the change is OK Thanks, Bert From owner-rap@ops.ietf.org Mon Jan 27 18:26:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00726 for ; Mon, 27 Jan 2003 18:26:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18dIgU-000Ezl-00 for rap-data@psg.com; Mon, 27 Jan 2003 15:28:58 -0800 Received: from roam.psg.com ([147.28.4.2]) by psg.com with esmtp (Exim 3.36 #1) id 18dIgS-000EzX-00 for rap@ops.ietf.org; Mon, 27 Jan 2003 15:28:57 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18dIgQ-00013n-00 for rap@ops.ietf.org; Mon, 27 Jan 2003 15:28:54 -0800 Message-Id: <200301272310.h0RNAfhK001845@lester.arraycomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 From: Branislav Meandzija To: "Wijnen, Bert (Bert)" , "Rap-wg (E-mail)" , Diffserv@ietf.org Subject: RE: [Diffserv] RE: FW: FlowId and FlowIdOrAny Date: Mon, 27 Jan 2003 15:10:17 -0800 X-Spam-Status: No, hits=0.2 required=5.0 tests=OUTLOOK_FW_MSG,RESENT_TO,SPAM_PHRASE_01_02 version=2.43 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA00726 [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Procedurally, very complex fix for something very simple but it seems the best possible one. Branislav > > My proposal is to do the following: > > - Someone creates a new ID that contains a small MIB module > that contains two TCs: > > FlowId TEXTUAL-CONVENTION > DISPLAY-HINT "d" > STATUS current > DESCRIPTION "The flow identifier or flow Label in an IPv6 > header that may be used to discriminate traffic > flows. > " > SYNTAX Integer32 (0..1048575) > > FlowIdOrAny TEXTUAL-CONVENTION > DISPLAY-HINT "d" > STATUS current > DESCRIPTION "The flow identifier or flow lable in an IPv6 > header that may be used to discriminate traffic > flows. The value of -1 is used to indicate a > wildcard, i.e. any value. > " > SYNTAX Integer32 (-1 | 0..1048575) From owner-rap@ops.ietf.org Tue Jan 28 07:44:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24179 for ; Tue, 28 Jan 2003 07:44:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18dV84-000KEi-00 for rap-data@psg.com; Tue, 28 Jan 2003 04:46:16 -0800 Received: from roam.psg.com ([147.28.4.2]) by psg.com with esmtp (Exim 3.36 #1) id 18dV7y-000KE8-00 for rap@ops.ietf.org; Tue, 28 Jan 2003 04:46:11 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18dV7q-0001eH-00 for rap@ops.ietf.org; Tue, 28 Jan 2003 04:46:02 -0800 Message-Id: <3E367A1D.C5CFC087@hursley.ibm.com> Mime-Version: 1.0 References: <7D5D48D2CAA3D84C813F5B154F43B155C82FA4@nl0006exch001u.nl.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 28 Jan 2003 13:39:57 +0100 From: Brian E Carpenter To: "Wijnen, Bert (Bert)" Cc: "Rap-wg (E-mail)" , Diffserv@ietf.org Subject: Re: [Diffserv] RE: FW: FlowId and FlowIdOrAny X-Spam-Status: No, hits=-1.1 required=5.0 tests=OUTLOOK_FW_MSG,QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.43 Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Bert, I'm not too distressed if we have to update the diffserv MIB; there isn't evidence of widespread deployment yet, so I think it's better to do it quickly. I agree that a common solution is desirable. The basic definition of the flow label still hasn't reached last call in the IPv6 WG (I am a co-author of that draft). So I don't think you could run your mini-MIB proposal past the WG "quickly", until the flow label has been through last call. Brian "Wijnen, Bert (Bert)" wrote: > > I am not hearing much progress. > > Appology for a long email posting. But I think it > addresses all the issues and occurences of flowId > or flowLabel (at least till someone tells me they > found yet another one ;-)) > > The biggest problem exists for the RAP WG document > for the framework PIB, cause it is in RFC 48-hour > author call (for over a month already). > > The DIFFSERV PIB (also in RFC 38-hour author call > for the same amount of time) of course cannot be > published since it depends on the framework pib. > > The issue at hand is the question on how to specify > that a flowID be ignored (wild-carded) for a filter. > I think we've come to the conclusion that both the > MIB and the PIB solutions need this. So we need > a common solution. > > We've also found 3 other places where a flowID > or a flowLabel (but the same thing is meant) is > being used. That is in: > > - draft-ietf-ipsp-ipsec-conf-mib-05.txt > which uses a 3-byte octet string and that seems wrong > SYNTAX OCTET STRING (SIZE(3)) > > - draft-ietf-rmonmib-sspm-mib-06.txt > which uses an Integer32: > SYNTAX Integer32 (0..1048575) -- 20-bit range (0 to 0xfffff) > > - Integrated services MIB (RFC 2213) > which uses INTEGER > SYNTAX INTEGER (0..16777215) > > The Diffserv MIB (RFC3289) and the framework PIB were > using an Unsigned 32, namely > SYNTAX Unsigned32 (0..1048575) > > The framework PIB authors were suggesting a modification > SYNTAX Unsigned32 (4294967295 | 0..1048575) > So that the value 4294967295 would mean any (in other words > one would ignore the flowID in when filtering). > > Fred (amin editor of the Diffserv MIB) wanted to add a > boolean mib object to indicate if the flowID should be > ignored when filtering. > > What I as OPS AD for the NM side see is that we have > - too many different ways to represent a flowID or flowLabel. > - there is currently no way to define a flowID or any > - we need need a facility to specify flowIdOrAny. > - we prefer to have one solution. > - we have some docs that are still IDs and can easily > be changed. > - we have two docs that are difficult to change, namely > the DIFSERV and the INTEGRATED SERVICES MIB. > The difficulty is that if we change the encoding on the > wire that we need to deprecate existing object and add > a new one. If we keep the wire encoding the same, I think > we can defend that it is a bug fix and the fact that some > potential new values are now valid is acceptable; at least > it would be less of a problem than having to deprecate > an object and add a new one. > - But even the two RFCs have different SYNTAX, so at least > one of them needs to change if we want to specify > flowID in a consistent way. > > So what do people want to do. > > My proposal is to do the following: > > - Someone creates a new ID that contains a small MIB module > that contains two TCs: > > FlowId TEXTUAL-CONVENTION > DISPLAY-HINT "d" > STATUS current > DESCRIPTION "The flow identifier or flow Label in an IPv6 > header that may be used to discriminate traffic > flows. > " > SYNTAX Integer32 (0..1048575) > > FlowIdOrAny TEXTUAL-CONVENTION > DISPLAY-HINT "d" > STATUS current > DESCRIPTION "The flow identifier or flow lable in an IPv6 > header that may be used to discriminate traffic > flows. The value of -1 is used to indicate a > wildcard, i.e. any value. > " > SYNTAX Integer32 (-1 | 0..1048575) > > We probably want to run this quickly by the IPv6 WG. > > What it would mean for the various documents is the following: > > - For the INTEGRATED-SERVICES-MIB (RFC2213), I see Fred as a > co-author/editor..., whenever a new revision is done: > - import the new FlowId TC > - replace > intSrvFlowFlowId OBJECT-TYPE > SYNTAX INTEGER (0..16777215) > with > intSrvFlowFlowId OBJECT-TYPE > SYNTAX FlowId > I think we can consider this a BUG fix and allow this change > that reduces the range of possible values. > - by the way, I when I see intSrvFlowIfAddr, then probably > we would want that to be done with the TCs from the > INET-ADDRESS-MIB. I also wonder about the Port TC in that > module > > - For the DIFFSERV-MIB (RFC3289), Fred is main editor, whenever > a new revision is done, I think we need to: > - import the new FlowIdOrAny TC > - deprecate object diffServMultiFieldClfrFlowId > - define a new object diffServMultiFieldClfrFlowLabel ?? > or maybe diffServMultiFieldClfrFlowIdOrAny > with syntax FlowIdOrAny > - deprecate current MODULE-COMPLIANCEs, define a new one > to remove ... FlowId and add ...FlowLable > > - For the draft-ietf-rap-frameworkpib-09.txt (or better the > RFC-to-be) the final fix would be to make this change: > - import FlowIdOrAny TC > - replace > frwkIpFilterFlowId OBJECT-TYPE > SYNTAX Unsigned32 (0..1048575) > with > frwkIpFilterFlowId OBJECT-TYPE > SYNTAX FlowIdOrAny > - we can consider this as a last minute bug fix. > If we agree that the final change may take too long, then we > can make a temp fix: > - replace > frwkIpFilterFlowId OBJECT-TYPE > SYNTAX Unsigned32 (0..1048575) > with > frwkIpFilterFlowId OBJECT-TYPE > SYNTAX Integer32 (-1 | 0..1048575) > DESCRIPTION "The flow identifier or flow lable in an IPv6 > header that may be used to discriminate traffic > flows. The value of -1 is used to indicate a > wildcard, i.e. any value. > " > - whenever the RFC gets revised, then this can be replaced > with the final fix, cause it does not change anything on the wire. > > - For draft-ietf-ipsp-ipsec-conf-mib-05.txt, main Editor > Wes Hardaker, we can fix it as follows > - import FlowId > - replace > ihfIPv6FlowLabel OBJECT-TYPE > SYNTAX OCTET STRING (SIZE(3)) > with > ihfIPv6FlowLabel OBJECT-TYPE > SYNTAX FlowId > - this is still an ID, so the change is OK. > Also, they use a BITS mask to indicate if the flowlabel > must be ignored or not. So this works. It is a bit different > than it is done in diffserv mib and framework pib, but at least > it uses the same spec for FlowId. (or flowLabel) > > - for draft-ietf-rmonmib-sspm-mib-06.txt, not sure who is main editor > it would mean > - import FlowId > - replace > sspmSourceProfileFlowLabel OBJECT-TYPE > SYNTAX Integer32 (0..1048575) -- 20-bit range (0 to 0xfffff) > with > sspmSourceProfileFlowLabel OBJECT-TYPE > SYNTAX FlowId > - this is still an ID, so the change is OK > > Thanks, > Bert > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland From owner-rap@ops.ietf.org Thu Jan 30 16:33:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11017 for ; Thu, 30 Jan 2003 16:33:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18eMJW-000Ll0-00 for rap-data@psg.com; Thu, 30 Jan 2003 13:33:38 -0800 Received: from hermes.py.intel.com ([146.152.216.3]) by psg.com with esmtp (Exim 3.36 #1) id 18eMJT-000Lko-00 for rap@ops.ietf.org; Thu, 30 Jan 2003 13:33:36 -0800 Received: from petasus.py.intel.com (petasus.py.intel.com [146.152.221.4]) by hermes.py.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h0ULTvl27026 for ; Thu, 30 Jan 2003 21:29:57 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus.py.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h0ULWQl00544 for ; Thu, 30 Jan 2003 21:32:26 GMT Received: from FMSMSX017.fm.intel.com ([132.233.42.196]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003013013312924578 ; Thu, 30 Jan 2003 13:31:29 -0800 Received: by fmsmsx017.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 30 Jan 2003 13:33:31 -0800 Message-ID: <65D5A07B5098D511BDDA0002A508E64F0B3494AD@orsmsx110.jf.intel.com> From: "Sahita, Ravi" To: "'Wijnen, Bert (Bert)'" , "Rap-wg (E-mail)" Subject: RE: [Diffserv] RE: FW: FlowId and FlowIdOrAny Date: Thu, 30 Jan 2003 13:33:30 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Status: No, hits=0.6 required=5.0 tests=EXCHANGE_SERVER,OUTLOOK_FW_MSG,SPAM_PHRASE_00_01 version=2.43 Sender: owner-rap@ops.ietf.org Precedence: bulk Bert, Of the choices you provided, I am tending towards this resolution for the frwkIpFilterFlowId object. When the TCs are eventually put in a different ID and RFC'ed, we can update the type for this object. Ravi frwkIpFilterFlowId OBJECT-TYPE SYNTAX Integer32 (-1 | 0..1048575) DESCRIPTION "The flow identifier or flow label in an IPv6 header that may be used to discriminate traffic flows. The value of -1 for this attribute MUST imply that any flow label value in the IPv6 header will match, resulting in the flow label field of the IPv6 header being ignored for matching this filter entry." | -----Original Message----- | From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] | Sent: Monday, January 27, 2003 1:49 PM | To: Rap-wg (E-mail); Diffserv@ietf.org | Subject: [Diffserv] RE: FW: FlowId and FlowIdOrAny | | | I am not hearing much progress. | | Appology for a long email posting. But I think it | addresses all the issues and occurences of flowId | or flowLabel (at least till someone tells me they | found yet another one ;-)) | | The biggest problem exists for the RAP WG document | for the framework PIB, cause it is in RFC 48-hour | author call (for over a month already). | | The DIFFSERV PIB (also in RFC 38-hour author call | for the same amount of time) of course cannot be | published since it depends on the framework pib. | | The issue at hand is the question on how to specify | that a flowID be ignored (wild-carded) for a filter. | I think we've come to the conclusion that both the | MIB and the PIB solutions need this. So we need | a common solution. | | We've also found 3 other places where a flowID | or a flowLabel (but the same thing is meant) is | being used. That is in: | | - draft-ietf-ipsp-ipsec-conf-mib-05.txt | which uses a 3-byte octet string and that seems wrong | SYNTAX OCTET STRING (SIZE(3)) | | - draft-ietf-rmonmib-sspm-mib-06.txt | which uses an Integer32: | SYNTAX Integer32 (0..1048575) -- 20-bit range (0 to 0xfffff) | | - Integrated services MIB (RFC 2213) | which uses INTEGER | SYNTAX INTEGER (0..16777215) | | The Diffserv MIB (RFC3289) and the framework PIB were | using an Unsigned 32, namely | SYNTAX Unsigned32 (0..1048575) | | The framework PIB authors were suggesting a modification | SYNTAX Unsigned32 (4294967295 | 0..1048575) | So that the value 4294967295 would mean any (in other words | one would ignore the flowID in when filtering). | | Fred (amin editor of the Diffserv MIB) wanted to add a | boolean mib object to indicate if the flowID should be | ignored when filtering. | | What I as OPS AD for the NM side see is that we have | - too many different ways to represent a flowID or flowLabel. | - there is currently no way to define a flowID or any | - we need need a facility to specify flowIdOrAny. | - we prefer to have one solution. | - we have some docs that are still IDs and can easily | be changed. | - we have two docs that are difficult to change, namely | the DIFSERV and the INTEGRATED SERVICES MIB. | The difficulty is that if we change the encoding on the | wire that we need to deprecate existing object and add | a new one. If we keep the wire encoding the same, I think | we can defend that it is a bug fix and the fact that some | potential new values are now valid is acceptable; at least | it would be less of a problem than having to deprecate | an object and add a new one. | - But even the two RFCs have different SYNTAX, so at least | one of them needs to change if we want to specify | flowID in a consistent way. | | So what do people want to do. | | My proposal is to do the following: | | - Someone creates a new ID that contains a small MIB module | that contains two TCs: | | FlowId TEXTUAL-CONVENTION | DISPLAY-HINT "d" | STATUS current | DESCRIPTION "The flow identifier or flow Label in an IPv6 | header that may be used to discriminate traffic | flows. | " | SYNTAX Integer32 (0..1048575) | | FlowIdOrAny TEXTUAL-CONVENTION | DISPLAY-HINT "d" | STATUS current | DESCRIPTION "The flow identifier or flow lable in an IPv6 | header that may be used to discriminate traffic | flows. The value of -1 is used to indicate a | wildcard, i.e. any value. | " | SYNTAX Integer32 (-1 | 0..1048575) | | We probably want to run this quickly by the IPv6 WG. | | What it would mean for the various documents is the following: | | - For the INTEGRATED-SERVICES-MIB (RFC2213), I see Fred as a | co-author/editor..., whenever a new revision is done: | - import the new FlowId TC | - replace | intSrvFlowFlowId OBJECT-TYPE | SYNTAX INTEGER (0..16777215) | with | intSrvFlowFlowId OBJECT-TYPE | SYNTAX FlowId | I think we can consider this a BUG fix and allow this change | that reduces the range of possible values. | - by the way, I when I see intSrvFlowIfAddr, then probably | we would want that to be done with the TCs from the | INET-ADDRESS-MIB. I also wonder about the Port TC in that | module | | - For the DIFFSERV-MIB (RFC3289), Fred is main editor, whenever | a new revision is done, I think we need to: | - import the new FlowIdOrAny TC | - deprecate object diffServMultiFieldClfrFlowId | - define a new object diffServMultiFieldClfrFlowLabel ?? | or maybe diffServMultiFieldClfrFlowIdOrAny | with syntax FlowIdOrAny | - deprecate current MODULE-COMPLIANCEs, define a new one | to remove ... FlowId and add ...FlowLable | | - For the draft-ietf-rap-frameworkpib-09.txt (or better the | RFC-to-be) the final fix would be to make this change: | - import FlowIdOrAny TC | - replace | frwkIpFilterFlowId OBJECT-TYPE | SYNTAX Unsigned32 (0..1048575) | with | frwkIpFilterFlowId OBJECT-TYPE | SYNTAX FlowIdOrAny | - we can consider this as a last minute bug fix. | If we agree that the final change may take too long, then we | can make a temp fix: | - replace | frwkIpFilterFlowId OBJECT-TYPE | SYNTAX Unsigned32 (0..1048575) | with | frwkIpFilterFlowId OBJECT-TYPE | SYNTAX Integer32 (-1 | 0..1048575) | DESCRIPTION "The flow identifier or flow lable in an IPv6 | header that may be used to discriminate traffic | flows. The value of -1 is used to indicate a | wildcard, i.e. any value. | " | - whenever the RFC gets revised, then this can be replaced | with the final fix, cause it does not change anything on | the wire. | | - For draft-ietf-ipsp-ipsec-conf-mib-05.txt, main Editor | Wes Hardaker, we can fix it as follows | - import FlowId | - replace | ihfIPv6FlowLabel OBJECT-TYPE | SYNTAX OCTET STRING (SIZE(3)) | with | ihfIPv6FlowLabel OBJECT-TYPE | SYNTAX FlowId | - this is still an ID, so the change is OK. | Also, they use a BITS mask to indicate if the flowlabel | must be ignored or not. So this works. It is a bit different | than it is done in diffserv mib and framework pib, but at least | it uses the same spec for FlowId. (or flowLabel) | | - for draft-ietf-rmonmib-sspm-mib-06.txt, not sure who is main editor | it would mean | - import FlowId | - replace | sspmSourceProfileFlowLabel OBJECT-TYPE | SYNTAX Integer32 (0..1048575) -- 20-bit range | (0 to 0xfffff) | with | sspmSourceProfileFlowLabel OBJECT-TYPE | SYNTAX FlowId | - this is still an ID, so the change is OK | | | Thanks, | Bert | _______________________________________________ | diffserv mailing list | diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv | Archive: | http://www.ietf.org/mail-archive/working-groups/diffserv/curre nt/maillist.html From owner-rap@ops.ietf.org Thu Jan 30 17:11:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11816 for ; Thu, 30 Jan 2003 17:11:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18eMwz-000NTt-00 for rap-data@psg.com; Thu, 30 Jan 2003 14:14:25 -0800 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by psg.com with esmtp (Exim 3.36 #1) id 18eMww-000NTh-00 for rap@ops.ietf.org; Thu, 30 Jan 2003 14:14:22 -0800 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id h0UMEKO19662 for ; Thu, 30 Jan 2003 17:14:20 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 30 Jan 2003 23:14:19 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155C8393F@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Sahita, Ravi" , "'Wijnen, Bert (Bert)'" , "Rap-wg (E-mail)" Subject: RE: [Diffserv] RE: FW: FlowId and FlowIdOrAny Date: Thu, 30 Jan 2003 23:14:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Status: No, hits=-0.2 required=5.0 tests=EXCHANGE_SERVER,OUTLOOK_FW_MSG,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-rap@ops.ietf.org Precedence: bulk Right, that seems an approach by which your RFC does not have to get held up for too long (well, at least not too much longer than has already happened). Not sure if you saw this, but I have also posted the mail on FlowLabel and FlowLabelOrAny on the mibs@ops.ietf.mailing list, so that we get dicsussion from other MIB folk as well. ANd I posted it to the authors of the other documents that were mentioned. All seems to be fine except for one question. And that is: if the range is indeed the correct one. Let me try and drive to consensus on that on the mibs mailing list. Pls do join in in the discussion there when you see fit. Thanks, Bert > -----Original Message----- > From: Sahita, Ravi [mailto:ravi.sahita@intel.com] > Sent: donderdag 30 januari 2003 22:34 > To: 'Wijnen, Bert (Bert)'; Rap-wg (E-mail) > Subject: RE: [Diffserv] RE: FW: FlowId and FlowIdOrAny > > > Bert, > > Of the choices you provided, I am tending towards this resolution > for the frwkIpFilterFlowId object. When the TCs are eventually put > in a different ID and RFC'ed, we can update the type for this object. > > Ravi > > frwkIpFilterFlowId OBJECT-TYPE > SYNTAX Integer32 (-1 | 0..1048575) > DESCRIPTION > "The flow identifier or flow label in an IPv6 header > that may be used to discriminate traffic flows. > The value of -1 for this attribute MUST imply that > any flow label value in the IPv6 header will match, > resulting in the flow label field of the IPv6 header > being ignored for matching this filter entry." > > > > | -----Original Message----- > | From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > | Sent: Monday, January 27, 2003 1:49 PM > | To: Rap-wg (E-mail); Diffserv@ietf.org > | Subject: [Diffserv] RE: FW: FlowId and FlowIdOrAny > | > | > | I am not hearing much progress. > | > | Appology for a long email posting. But I think it > | addresses all the issues and occurences of flowId > | or flowLabel (at least till someone tells me they > | found yet another one ;-)) > | > | The biggest problem exists for the RAP WG document > | for the framework PIB, cause it is in RFC 48-hour > | author call (for over a month already). > | > | The DIFFSERV PIB (also in RFC 38-hour author call > | for the same amount of time) of course cannot be > | published since it depends on the framework pib. > | > | The issue at hand is the question on how to specify > | that a flowID be ignored (wild-carded) for a filter. > | I think we've come to the conclusion that both the > | MIB and the PIB solutions need this. So we need > | a common solution. > | > | We've also found 3 other places where a flowID > | or a flowLabel (but the same thing is meant) is > | being used. That is in: > | > | - draft-ietf-ipsp-ipsec-conf-mib-05.txt > | which uses a 3-byte octet string and that seems wrong > | SYNTAX OCTET STRING (SIZE(3)) > | > | - draft-ietf-rmonmib-sspm-mib-06.txt > | which uses an Integer32: > | SYNTAX Integer32 (0..1048575) -- 20-bit range (0 to 0xfffff) > | > | - Integrated services MIB (RFC 2213) > | which uses INTEGER > | SYNTAX INTEGER (0..16777215) > | > | The Diffserv MIB (RFC3289) and the framework PIB were > | using an Unsigned 32, namely > | SYNTAX Unsigned32 (0..1048575) > | > | The framework PIB authors were suggesting a modification > | SYNTAX Unsigned32 (4294967295 | 0..1048575) > | So that the value 4294967295 would mean any (in other words > | one would ignore the flowID in when filtering). > | > | Fred (amin editor of the Diffserv MIB) wanted to add a > | boolean mib object to indicate if the flowID should be > | ignored when filtering. > | > | What I as OPS AD for the NM side see is that we have > | - too many different ways to represent a flowID or flowLabel. > | - there is currently no way to define a flowID or any > | - we need need a facility to specify flowIdOrAny. > | - we prefer to have one solution. > | - we have some docs that are still IDs and can easily > | be changed. > | - we have two docs that are difficult to change, namely > | the DIFSERV and the INTEGRATED SERVICES MIB. > | The difficulty is that if we change the encoding on the > | wire that we need to deprecate existing object and add > | a new one. If we keep the wire encoding the same, I think > | we can defend that it is a bug fix and the fact that some > | potential new values are now valid is acceptable; at least > | it would be less of a problem than having to deprecate > | an object and add a new one. > | - But even the two RFCs have different SYNTAX, so at least > | one of them needs to change if we want to specify > | flowID in a consistent way. > | > | So what do people want to do. > | > | My proposal is to do the following: > | > | - Someone creates a new ID that contains a small MIB module > | that contains two TCs: > | > | FlowId TEXTUAL-CONVENTION > | DISPLAY-HINT "d" > | STATUS current > | DESCRIPTION "The flow identifier or flow Label in an IPv6 > | header that may be used to discriminate traffic > | flows. > | " > | SYNTAX Integer32 (0..1048575) > | > | FlowIdOrAny TEXTUAL-CONVENTION > | DISPLAY-HINT "d" > | STATUS current > | DESCRIPTION "The flow identifier or flow lable in an IPv6 > | header that may be used to discriminate traffic > | flows. The value of -1 is used to indicate a > | wildcard, i.e. any value. > | " > | SYNTAX Integer32 (-1 | 0..1048575) > | > | We probably want to run this quickly by the IPv6 WG. > | > | What it would mean for the various documents is the following: > | > | - For the INTEGRATED-SERVICES-MIB (RFC2213), I see Fred as a > | co-author/editor..., whenever a new revision is done: > | - import the new FlowId TC > | - replace > | intSrvFlowFlowId OBJECT-TYPE > | SYNTAX INTEGER (0..16777215) > | with > | intSrvFlowFlowId OBJECT-TYPE > | SYNTAX FlowId > | I think we can consider this a BUG fix and allow this change > | that reduces the range of possible values. > | - by the way, I when I see intSrvFlowIfAddr, then probably > | we would want that to be done with the TCs from the > | INET-ADDRESS-MIB. I also wonder about the Port TC in that > | module > | > | - For the DIFFSERV-MIB (RFC3289), Fred is main editor, whenever > | a new revision is done, I think we need to: > | - import the new FlowIdOrAny TC > | - deprecate object diffServMultiFieldClfrFlowId > | - define a new object diffServMultiFieldClfrFlowLabel ?? > | or maybe diffServMultiFieldClfrFlowIdOrAny > | with syntax FlowIdOrAny > | - deprecate current MODULE-COMPLIANCEs, define a new one > | to remove ... FlowId and add ...FlowLable > | > | - For the draft-ietf-rap-frameworkpib-09.txt (or better the > | RFC-to-be) the final fix would be to make this change: > | - import FlowIdOrAny TC > | - replace > | frwkIpFilterFlowId OBJECT-TYPE > | SYNTAX Unsigned32 (0..1048575) > | with > | frwkIpFilterFlowId OBJECT-TYPE > | SYNTAX FlowIdOrAny > | - we can consider this as a last minute bug fix. > | If we agree that the final change may take too long, then we > | can make a temp fix: > | - replace > | frwkIpFilterFlowId OBJECT-TYPE > | SYNTAX Unsigned32 (0..1048575) > | with > | frwkIpFilterFlowId OBJECT-TYPE > | SYNTAX Integer32 (-1 | 0..1048575) > | DESCRIPTION "The flow identifier or flow lable in an IPv6 > | header that may be used to > discriminate traffic > | flows. The value of -1 is used to indicate a > | wildcard, i.e. any value. > | " > | - whenever the RFC gets revised, then this can be replaced > | with the final fix, cause it does not change anything on > | the wire. > | > | - For draft-ietf-ipsp-ipsec-conf-mib-05.txt, main Editor > | Wes Hardaker, we can fix it as follows > | - import FlowId > | - replace > | ihfIPv6FlowLabel OBJECT-TYPE > | SYNTAX OCTET STRING (SIZE(3)) > | with > | ihfIPv6FlowLabel OBJECT-TYPE > | SYNTAX FlowId > | - this is still an ID, so the change is OK. > | Also, they use a BITS mask to indicate if the flowlabel > | must be ignored or not. So this works. It is a bit different > | than it is done in diffserv mib and framework pib, but at least > | it uses the same spec for FlowId. (or flowLabel) > | > | - for draft-ietf-rmonmib-sspm-mib-06.txt, not sure who is > main editor > | it would mean > | - import FlowId > | - replace > | sspmSourceProfileFlowLabel OBJECT-TYPE > | SYNTAX Integer32 (0..1048575) -- 20-bit range > | (0 to 0xfffff) > | with > | sspmSourceProfileFlowLabel OBJECT-TYPE > | SYNTAX FlowId > | - this is still an ID, so the change is OK > | > | > | Thanks, > | Bert > | _______________________________________________ > | diffserv mailing list > | diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv > | Archive: > | http://www.ietf.org/mail-archive/working-groups/diffserv/curre > nt/maillist.html >