RE: [Diffserv] Re: FlowId and FlowIdOrAny

"Wijnen, Bert (Bert)" <bwijnen@lucent.com> Tue, 21 January 2003 15:34 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 KAA02627 for <diffserv-archive@odin.ietf.org>; Tue, 21 Jan 2003 10:34:18 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0LFpqT25928 for diffserv-archive@odin.ietf.org; Tue, 21 Jan 2003 10:51:52 -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 h0LFiLJ25403; Tue, 21 Jan 2003 10:44:21 -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 h0LFcCJ25169 for <diffserv@optimus.ietf.org>; Tue, 21 Jan 2003 10:38:12 -0500
Received: from auemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02169 for <diffserv@ietf.org>; Tue, 21 Jan 2003 10:20:05 -0500 (EST)
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 h0LFNSg17848 for <diffserv@ietf.org>; Tue, 21 Jan 2003 10:23:28 -0500 (EST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id <YJ267HPM>; Tue, 21 Jan 2003 16:23:26 +0100
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155BADF67@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: Brian E Carpenter <brian@hursley.ibm.com>, Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>
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
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>

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    
> <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