RE: [Diffserv] RE: FW: FlowId and FlowIdOrAny

The last mail from Ravi seems to require resolution for the object =
frwkIpFilterFlowId, which has a -1 value.=20

The range should be OK, at least according to my text book on IPv6. The =
field itself has 20 bit, and the value zero must be set by host or =
routers that do not support this functionality.=20

Dan

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email protected]]
> Sent: Monday, February 03, 2003 11:48 AM
> To: Romascanu, Dan (Dan); Wijnen, Bert (Bert); Sahita, Ravi;=20
> Rap-wg (E-mail)
> Subject: RE: [Diffserv] RE: FW: FlowId and FlowIdOrAny
>=20
>=20
> So Dan, you would use the one intended as FlowLabel (which does
> not include the -1 value). The -1 value is for cases of
> FlowLableOrAny. I was worried more about the question if the
> range 0..1048575 is the correct range for FlowLabels.
>=20
> Thanks,
> Bert=20
>=20
> > -----Original Message-----
> > From: Romascanu, Dan (Dan) [mailto:[email protected]]
> > Sent: zondag 2 februari 2003 13:22
> > To: Wijnen, Bert (Bert); Sahita, Ravi; Rap-wg (E-mail)
> > Subject: RE: [Diffserv] RE: FW: FlowId and FlowIdOrAny
> >=20
> >=20
> > The -1 value is not needed in SSPM MIB. The object=20
> > sspmSourceProfileFlowLabel has a MAX-ACCESS read-create, and=20
> > one MUST specify a meaningful flow id value to be carried by=20
> > the packet.=20
> >=20
> > Dan
> >=20
> >=20
> > > -----Original Message-----
> > > From: Wijnen, Bert (Bert) [mailto:[email protected]]
> > > Sent: Friday, January 31, 2003 12:14 AM
> > > To: Sahita, Ravi; 'Wijnen, Bert (Bert)'; Rap-wg (E-mail)
> > > Subject: RE: [Diffserv] RE: FW: FlowId and FlowIdOrAny
> > >=20
> > >=20
> > > Right, that seems an approach by which your RFC does not have=20
> > > to get held up for too long (well, at least not too much longer=20
> > > than has already happened).=20
> > > Not sure if you saw this, but I have also posted the mail
> > > on FlowLabel and FlowLabelOrAny on the [email protected]
> > > list, so that we get dicsussion from other MIB folk as well.
> > > ANd I posted it to the authors of the other documents that=20
> > > were mentioned.
> > >=20
> > > All seems to be fine except for one question.
> > > And that is: if the range is indeed the correct one.
> > > Let me try and drive to consensus on that on the mibs mailing
> > > list. Pls do join in in the discussion there when you see fit.
> > >=20
> > > Thanks,
> > > Bert=20
> > >=20
> > > > -----Original Message-----
> > > > From: Sahita, Ravi [mailto:[email protected]]
> > > > Sent: donderdag 30 januari 2003 22:34
> > > > To: 'Wijnen, Bert (Bert)'; Rap-wg (E-mail)
> > > > Subject: RE: [Diffserv] RE: FW: FlowId and FlowIdOrAny
> > > >=20
> > > >=20
> > > > Bert,
> > > >=20
> > > > Of the choices you provided, I am tending towards this=20
> resolution=20
> > > > for the frwkIpFilterFlowId object. When the TCs are=20
> > eventually put=20
> > > > in a different ID and RFC'ed, we can update the type for=20
> > > this object.
> > > >=20
> > > > Ravi
> > > >=20
> > > > frwkIpFilterFlowId OBJECT-TYPE
> > > >    SYNTAX        Integer32 (-1 | 0..1048575)
> > > >    DESCRIPTION
> > > >    "The flow identifier or flow label in an IPv6 header=20
> > > >     that may be used to discriminate traffic flows.
> > > >     The value of -1 for this attribute MUST imply that=20
> > > >     any flow label value in the IPv6 header will match,=20
> > > >     resulting in the flow label field of the IPv6 header=20
> > > >     being ignored for matching this filter entry."
> > > >=20
> > > >=20
> > > >=20
> > > > | -----Original Message-----
> > > > | From: Wijnen, Bert (Bert) [mailto:[email protected]]=20
> > > > | Sent: Monday, January 27, 2003 1:49 PM
> > > > | To: Rap-wg (E-mail); [email protected]
> > > > | Subject: [Diffserv] RE: FW: FlowId and FlowIdOrAny
> > > > |=20
> > > > |=20
> > > > | I am not hearing much progress.
> > > > |=20
> > > > | Appology for a long email posting. But I think it=20
> > > > | addresses all the issues and occurences of flowId
> > > > | or flowLabel (at least till someone tells me they
> > > > | found yet another one ;-))
> > > > |=20
> > > > | 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).
> > > > |=20
> > > > | 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.
> > > > |=20
> > > > | 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.
> > > > |=20
> > > > | We've also found 3 other places where a flowID=20
> > > > | or a flowLabel (but the same thing is meant) is
> > > > | being used. That is in:
> > > > |=20
> > > > |  - draft-ietf-ipsp-ipsec-conf-mib-05.txt
> > > > |    which uses a 3-byte octet string and that seems wrong=20
> > > > |       SYNTAX  OCTET STRING (SIZE(3))
> > > > |=20
> > > > |  - draft-ietf-rmonmib-sspm-mib-06.txt
> > > > |    which uses an Integer32:
> > > > |       SYNTAX  Integer32 (0..1048575) -- 20-bit range (0=20
> > > to 0xfffff)
> > > > |=20
> > > > |  - Integrated services MIB (RFC 2213)
> > > > |    which uses INTEGER
> > > > |       SYNTAX  INTEGER (0..16777215)
> > > > |=20
> > > > | The Diffserv MIB (RFC3289) and the framework PIB were
> > > > | using an Unsigned 32, namely
> > > > |       SYNTAX  Unsigned32 (0..1048575)
> > > > |=20
> > > > | 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).
> > > > |=20
> > > > | Fred (amin editor of the Diffserv MIB) wanted to add a=20
> > > > | boolean mib object to indicate if the flowID should be
> > > > | ignored when filtering.
> > > > |=20
> > > > | 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.=20
> > > > | - 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=20
> > > > |   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.
> > > > |=20
> > > > | So what do people want to do.
> > > > |=20
> > > > | My proposal is to do the following:
> > > > |=20
> > > > | - Someone creates a new ID that contains a small MIB module
> > > > |   that contains two TCs:
> > > > |=20
> > > > |   FlowId            TEXTUAL-CONVENTION
> > > > |       DISPLAY-HINT "d"
> > > > |       STATUS        current
> > > > |       DESCRIPTION  "The flow identifier or flow Label=20
> in an IPv6
> > > > |                     header that may be used to=20
> > > discriminate traffic
> > > > |                     flows.
> > > > |                    "
> > > > |       SYNTAX        Integer32 (0..1048575)
> > > > |=20
> > > > |   FlowIdOrAny       TEXTUAL-CONVENTION
> > > > |       DISPLAY-HINT "d"
> > > > |       STATUS        current
> > > > |       DESCRIPTION  "The flow identifier or flow lable=20
> > in an IPv6=20
> > > > |                     header that may be used to=20
> > > discriminate traffic
> > > > |                     flows.  The value of -1 is used to=20
> > indicate a
> > > > |                     wildcard, i.e. any value.
> > > > |                    "
> > > > |       SYNTAX        Integer32 (-1 | 0..1048575)
> > > > |=20
> > > > | We probably want to run this quickly by the IPv6 WG.
> > > > |=20
> > > > | What it would mean for the various documents is the following:
> > > > |=20
> > > > | - For the INTEGRATED-SERVICES-MIB (RFC2213), I see Fred as a=20
> > > > |   co-author/editor..., whenever a new revision is done:
> > > > |    - import the new FlowId TC
> > > > |    - replace=20
> > > > |            intSrvFlowFlowId OBJECT-TYPE
> > > > |            SYNTAX      INTEGER (0..16777215)
> > > > |      with=20
> > > > |            intSrvFlowFlowId OBJECT-TYPE
> > > > |            SYNTAX      FlowId=20
> > > > |      I think we can consider this a BUG fix and allow=20
> > 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
> > > > |=20
> > > > | - For the DIFFSERV-MIB (RFC3289), Fred is main=20
> 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
> > > > |=20
> > > > | - 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=20
> > > > |          frwkIpFilterFlowId OBJECT-TYPE
> > > > |          SYNTAX         Unsigned32 (0..1048575)
> > > > |      with=20
> > > > |          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=20
> > > > |          frwkIpFilterFlowId OBJECT-TYPE
> > > > |          SYNTAX         Unsigned32 (0..1048575)
> > > > |      with=20
> > > > |          frwkIpFilterFlowId OBJECT-TYPE
> > > > |          SYNTAX        Integer32 (-1 | 0..1048575)
> > > > |          DESCRIPTION  "The flow identifier or flow lable=20
> > > in an IPv6=20
> > > > |                        header that may be used to=20
> > > > discriminate traffic
> > > > |                        flows.  The value of -1 is used to=20
> > > 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=20
> > > > | the wire.
> > > > |=20
> > > > | - 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=20
> > > > |            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=20
> > different
> > > > |      than it is done in diffserv mib and framework pib,=20
> > > but at least
> > > > |      it uses the same spec for FlowId. (or flowLabel)
> > > > |=20
> > > > | - for draft-ietf-rmonmib-sspm-mib-06.txt, not sure who is=20
> > > > main editor
> > > > |   it would mean
> > > > |    - import FlowId
> > > > |    - replace
> > > > |         sspmSourceProfileFlowLabel OBJECT-TYPE
> > > > |         SYNTAX      Integer32 (0..1048575)  -- 20-bit range=20
> > > > | (0 to 0xfffff)
> > > > |      with
> > > > |         sspmSourceProfileFlowLabel OBJECT-TYPE
> > > > |         SYNTAX      FlowId
> > > > |    - this is still an ID, so the change is OK
> > > > |=20
> > > > |=20
> > > > | Thanks,
> > > > | Bert=20
> > > > | _______________________________________________
> > > > | diffserv mailing list
> > > > | [email protected]=20
> https://www1.ietf.org/mailman/listinfo/diffserv
> > > | Archive:=20
> > > | http://www.ietf.org/mail-archive/working-groups/diffserv/curre
> > > nt/maillist.html
> > >=20
> >=20
> >=20
>=20