Subject: RE: FW: FlowId and FlowIdOrAny

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Mon, 27 Jan 2003 22:49:25 +0100

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 28 Jan 2003 13:39:57 +0100

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

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:
> _______________________________________________
> diffserv mailing list
> [email-masked]
> 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