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