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

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 2 Feb 2003 14:21:47 +0200

The -1 value is not needed in SSPM MIB. The object sspmSourceProfileFlowLabel has a MAX-ACCESS read-create, and one MUST specify a meaningful flow id value to be carried by the packet. 

Dan

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> 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
> 
> 
> Right, that seems an approach by which your RFC does not have 
> to get held up for too long (well, at least not too much longer 
> than has already happened). 
> Not sure if you saw this, but I have also posted the mail
> on FlowLabel and FlowLabelOrAny on the [email-masked]
> list, so that we get dicsussion from other MIB folk as well.
> ANd I posted it to the authors of the other documents that 
> were mentioned.
> 
> 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.
> 
> Thanks,
> Bert 
> 
> > -----Original Message-----
> > From: Sahita, Ravi [mailto:[email-masked]]
> > Sent: donderdag 30 januari 2003 22:34
> > To: 'Wijnen, Bert (Bert)'; Rap-wg (E-mail)
> > Subject: RE: [Diffserv] RE: FW: FlowId and FlowIdOrAny
> > 
> > 
> > Bert,
> > 
> > Of the choices you provided, I am tending towards this resolution 
> > for the frwkIpFilterFlowId object. When the TCs are eventually put 
> > in a different ID and RFC'ed, we can update the type for 
> this object.
> > 
> > Ravi
> > 
> > frwkIpFilterFlowId OBJECT-TYPE
> >    SYNTAX        Integer32 (-1 | 0..1048575)
> >    DESCRIPTION
> >    "The flow identifier or flow label in an IPv6 header 
> >     that may be used to discriminate traffic flows.
> >     The value of -1 for this attribute MUST imply that 
> >     any flow label value in the IPv6 header will match, 
> >     resulting in the flow label field of the IPv6 header 
> >     being ignored for matching this filter entry."
> > 
> > 
> > 
> > | -----Original Message-----
> > | From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
> > | Sent: Monday, January 27, 2003 1:49 PM
> > | To: Rap-wg (E-mail); [email-masked]
> > | Subject: [Diffserv] RE: FW: FlowId and FlowIdOrAny
> > | 
> > | 
> > | 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 
> > | _______________________________________________
> > | diffserv mailing list
> > | [email-masked] https://www1.ietf.org/mailman/listinfo/diffserv
> > | Archive: 
> > | http://www.ietf.org/mail-archive/working-groups/diffserv/curre
> > nt/maillist.html
> > 
> 
>

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Mon, 3 Feb 2003 10:48:23 +0100

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.

Thanks,
Bert 

> From: Romascanu, Dan (Dan) [mailto:[email-masked]]
> Sent: zondag 2 februari 2003 13:22
> To: Wijnen, Bert (Bert); Sahita, Ravi; Rap-wg (E-mail)
> The -1 value is not needed in SSPM MIB. The object 
> sspmSourceProfileFlowLabel has a MAX-ACCESS read-create, and 
> one MUST specify a meaningful flow id value to be carried by 
> the packet. 
> 
> Dan
> 
> 
> > > | [email-masked] 
https://www1.ietf.org/mailman/listinfo/diffserv

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 3 Feb 2003 13:39:42 +0200

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

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. 

Dan

> Sent: Monday, February 03, 2003 11:48 AM
> To: Romascanu, Dan (Dan); Wijnen, Bert (Bert); Sahita, Ravi; 
> Rap-wg (E-mail)

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Mon, 3 Feb 2003 12:54:11 +0100

Inline

> Sent: maandag 3 februari 2003 12:40
> The last mail from Ravi seems to require resolution for the 
> object frwkIpFilterFlowId, which has a -1 value. 
> 
Yep, but that is in a place where they want to express
FlowLabelOrAny, and so the -1 represents the "any".

> 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. 
> 
That is what I thought also, but someone questioned it, and
in some existing MIB modules, they seem to have used a larger
range already. So I guess we want to get a definitive answer
from some IPv6 experts. I will follow up on that.

Bert