Re: [Diffserv] FlowId and FlowIdOrAny

[Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>]

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