Re: [Diffserv] RE: FW: FlowId and FlowIdOrAny
Brian E Carpenter <brian@hursley.ibm.com> Tue, 28 January 2003 12:52 UTC
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24321 for <diffserv-archive@odin.ietf.org>; Tue, 28 Jan 2003 07:52:35 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0SDDWD17869 for diffserv-archive@odin.ietf.org; Tue, 28 Jan 2003 08:13:32 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SD4sJ16876; Tue, 28 Jan 2003 08:04:54 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SCwhJ16658 for <diffserv@optimus.ietf.org>; Tue, 28 Jan 2003 07:58:43 -0500
Received: from d12lmsgate-2.de.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23779 for <Diffserv@ietf.org>; Tue, 28 Jan 2003 07:37:13 -0500 (EST)
Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id h0SCegXf072710; Tue, 28 Jan 2003 13:40:43 +0100
Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id h0SCefnr138850; Tue, 28 Jan 2003 13:40:42 +0100
Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA26724 from <brian@hursley.ibm.com>; Tue, 28 Jan 2003 13:40:40 +0100
Message-Id: <3E367A1D.C5CFC087@hursley.ibm.com>
Date: Tue, 28 Jan 2003 13:39:57 +0100
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fr,de
Mime-Version: 1.0
To: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
Cc: "Rap-wg (E-mail)" <rap@ops.ietf.org>, Diffserv@ietf.org
Subject: Re: [Diffserv] RE: FW: FlowId and FlowIdOrAny
References: <7D5D48D2CAA3D84C813F5B154F43B155C82FA4@nl0006exch001u.nl.lucent.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: diffserv-admin@ietf.org
Errors-To: diffserv-admin@ietf.org
X-BeenThere: diffserv@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/diffserv>, <mailto:diffserv-request@ietf.org?subject=unsubscribe>
List-Id: Diffserv Discussion List <diffserv.ietf.org>
List-Post: <mailto:diffserv@ietf.org>
List-Help: <mailto:diffserv-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/diffserv>, <mailto:diffserv-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Bert, I'm not too distressed if we have to update the diffserv MIB; there isn't evidence of widespread deployment yet, so I think it's better to do it quickly. I agree that a common solution is desirable. The basic definition of the flow label still hasn't reached last call in the IPv6 WG (I am a co-author of that draft). So I don't think you could run your mini-MIB proposal past the WG "quickly", until the flow label has been through last call. Brian "Wijnen, Bert (Bert)" wrote: > > I am not hearing much progress. > > Appology for a long email posting. But I think it > addresses all the issues and occurences of flowId > or flowLabel (at least till someone tells me they > found yet another one ;-)) > > The biggest problem exists for the RAP WG document > for the framework PIB, cause it is in RFC 48-hour > author call (for over a month already). > > The DIFFSERV PIB (also in RFC 38-hour author call > for the same amount of time) of course cannot be > published since it depends on the framework pib. > > The issue at hand is the question on how to specify > that a flowID be ignored (wild-carded) for a filter. > I think we've come to the conclusion that both the > MIB and the PIB solutions need this. So we need > a common solution. > > We've also found 3 other places where a flowID > or a flowLabel (but the same thing is meant) is > being used. That is in: > > - draft-ietf-ipsp-ipsec-conf-mib-05.txt > which uses a 3-byte octet string and that seems wrong > SYNTAX OCTET STRING (SIZE(3)) > > - draft-ietf-rmonmib-sspm-mib-06.txt > which uses an Integer32: > SYNTAX Integer32 (0..1048575) -- 20-bit range (0 to 0xfffff) > > - Integrated services MIB (RFC 2213) > which uses INTEGER > SYNTAX INTEGER (0..16777215) > > The Diffserv MIB (RFC3289) and the framework PIB were > using an Unsigned 32, namely > SYNTAX Unsigned32 (0..1048575) > > The framework PIB authors were suggesting a modification > SYNTAX Unsigned32 (4294967295 | 0..1048575) > So that the value 4294967295 would mean any (in other words > one would ignore the flowID in when filtering). > > Fred (amin editor of the Diffserv MIB) wanted to add a > boolean mib object to indicate if the flowID should be > ignored when filtering. > > What I as OPS AD for the NM side see is that we have > - too many different ways to represent a flowID or flowLabel. > - there is currently no way to define a flowID or any > - we need need a facility to specify flowIdOrAny. > - we prefer to have one solution. > - we have some docs that are still IDs and can easily > be changed. > - we have two docs that are difficult to change, namely > the DIFSERV and the INTEGRATED SERVICES MIB. > The difficulty is that if we change the encoding on the > wire that we need to deprecate existing object and add > a new one. If we keep the wire encoding the same, I think > we can defend that it is a bug fix and the fact that some > potential new values are now valid is acceptable; at least > it would be less of a problem than having to deprecate > an object and add a new one. > - But even the two RFCs have different SYNTAX, so at least > one of them needs to change if we want to specify > flowID in a consistent way. > > So what do people want to do. > > My proposal is to do the following: > > - Someone creates a new ID that contains a small MIB module > that contains two TCs: > > FlowId TEXTUAL-CONVENTION > DISPLAY-HINT "d" > STATUS current > DESCRIPTION "The flow identifier or flow Label in an IPv6 > header that may be used to discriminate traffic > flows. > " > SYNTAX Integer32 (0..1048575) > > FlowIdOrAny TEXTUAL-CONVENTION > DISPLAY-HINT "d" > STATUS current > DESCRIPTION "The flow identifier or flow lable in an IPv6 > header that may be used to discriminate traffic > flows. The value of -1 is used to indicate a > wildcard, i.e. any value. > " > SYNTAX Integer32 (-1 | 0..1048575) > > We probably want to run this quickly by the IPv6 WG. > > What it would mean for the various documents is the following: > > - For the INTEGRATED-SERVICES-MIB (RFC2213), I see Fred as a > co-author/editor..., whenever a new revision is done: > - import the new FlowId TC > - replace > intSrvFlowFlowId OBJECT-TYPE > SYNTAX INTEGER (0..16777215) > with > intSrvFlowFlowId OBJECT-TYPE > SYNTAX FlowId > I think we can consider this a BUG fix and allow this change > that reduces the range of possible values. > - by the way, I when I see intSrvFlowIfAddr, then probably > we would want that to be done with the TCs from the > INET-ADDRESS-MIB. I also wonder about the Port TC in that > module > > - For the DIFFSERV-MIB (RFC3289), Fred is main editor, whenever > a new revision is done, I think we need to: > - import the new FlowIdOrAny TC > - deprecate object diffServMultiFieldClfrFlowId > - define a new object diffServMultiFieldClfrFlowLabel ?? > or maybe diffServMultiFieldClfrFlowIdOrAny > with syntax FlowIdOrAny > - deprecate current MODULE-COMPLIANCEs, define a new one > to remove ... FlowId and add ...FlowLable > > - For the draft-ietf-rap-frameworkpib-09.txt (or better the > RFC-to-be) the final fix would be to make this change: > - import FlowIdOrAny TC > - replace > frwkIpFilterFlowId OBJECT-TYPE > SYNTAX Unsigned32 (0..1048575) > with > frwkIpFilterFlowId OBJECT-TYPE > SYNTAX FlowIdOrAny > - we can consider this as a last minute bug fix. > If we agree that the final change may take too long, then we > can make a temp fix: > - replace > frwkIpFilterFlowId OBJECT-TYPE > SYNTAX Unsigned32 (0..1048575) > with > frwkIpFilterFlowId OBJECT-TYPE > SYNTAX Integer32 (-1 | 0..1048575) > DESCRIPTION "The flow identifier or flow lable in an IPv6 > header that may be used to discriminate traffic > flows. The value of -1 is used to indicate a > wildcard, i.e. any value. > " > - whenever the RFC gets revised, then this can be replaced > with the final fix, cause it does not change anything on the wire. > > - For draft-ietf-ipsp-ipsec-conf-mib-05.txt, main Editor > Wes Hardaker, we can fix it as follows > - import FlowId > - replace > ihfIPv6FlowLabel OBJECT-TYPE > SYNTAX OCTET STRING (SIZE(3)) > with > ihfIPv6FlowLabel OBJECT-TYPE > SYNTAX FlowId > - this is still an ID, so the change is OK. > Also, they use a BITS mask to indicate if the flowlabel > must be ignored or not. So this works. It is a bit different > than it is done in diffserv mib and framework pib, but at least > it uses the same spec for FlowId. (or flowLabel) > > - for draft-ietf-rmonmib-sspm-mib-06.txt, not sure who is main editor > it would mean > - import FlowId > - replace > sspmSourceProfileFlowLabel OBJECT-TYPE > SYNTAX Integer32 (0..1048575) -- 20-bit range (0 to 0xfffff) > with > sspmSourceProfileFlowLabel OBJECT-TYPE > SYNTAX FlowId > - this is still an ID, so the change is OK > > Thanks, > Bert > _______________________________________________ > diffserv mailing list > diffserv@ietf.org > https://www1.ietf.org/mailman/listinfo/diffserv > Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html
- [Diffserv] FlowId and FlowIdOrAny Juergen Schoenwaelder
- [Diffserv] RE: FlowId and FlowIdOrAny Wijnen, Bert (Bert)
- [Diffserv] Re: FlowId and FlowIdOrAny Juergen Schoenwaelder
- Re: [Diffserv] Re: FlowId and FlowIdOrAny Brian E Carpenter
- RE: [Diffserv] Re: FlowId and FlowIdOrAny Wijnen, Bert (Bert)
- Re: [Diffserv] FlowId and FlowIdOrAny Dan Grossman
- Re: [Diffserv] FlowId and FlowIdOrAny Juergen Schoenwaelder
- [Diffserv] Re: FlowId and FlowIdOrAny Juergen Schoenwaelder
- [Diffserv] FW: FW: FlowId and FlowIdOrAny Wijnen, Bert (Bert)
- [Diffserv] RE: FW: FlowId and FlowIdOrAny Wijnen, Bert (Bert)
- RE: [Diffserv] RE: FW: FlowId and FlowIdOrAny Branislav Meandzija
- Re: [Diffserv] RE: FW: FlowId and FlowIdOrAny Brian E Carpenter
- [Diffserv] FlowId and FlowIdOrAny Wijnen, Bert (Bert)
- Re: [Diffserv] FlowId and FlowIdOrAny Brian E Carpenter