Re: [Diffserv] FlowId and FlowIdOrAny
Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de> Tue, 21 January 2003 17:37 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 MAA06341
for <diffserv-archive@odin.ietf.org>; Tue, 21 Jan 2003 12:37:28 -0500 (EST)
Received: (from mailnull@localhost)
by www1.ietf.org (8.11.6/8.11.6) id h0LHt6l03059
for diffserv-archive@odin.ietf.org; Tue, 21 Jan 2003 12:55:06 -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 h0LHe8J02106;
Tue, 21 Jan 2003 12:40:08 -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 h0LHYIJ01169
for <diffserv@optimus.ietf.org>; Tue, 21 Jan 2003 12:34:18 -0500
Received: from agitator.ibr.cs.tu-bs.de (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05615
for <diffserv@ietf.org>; Tue, 21 Jan 2003 12:16:09 -0500 (EST)
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 <schoenw@ibr.cs.tu-bs.de>
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>
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>
>>>>> 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 <http://www.informatik.uni-osnabrueck.de/schoenw/> _______________________________________________ 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