[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Diffserv] RE: FW: FlowId and FlowIdOrAny
Inline
> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
> Sent: maandag 3 februari 2003 12:40
> To: Wijnen, Bert (Bert); Sahita, Ravi; Rap-wg (E-mail)
> Subject: 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.
>
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
> Dan
>
> > -----Original Message-----
> > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> > Sent: Monday, February 03, 2003 11:48 AM
> > To: Romascanu, Dan (Dan); Wijnen, Bert (Bert); Sahita, Ravi;
> > Rap-wg (E-mail)
> > Subject: RE: [Diffserv] RE: FW: FlowId and FlowIdOrAny
> >
> >
> > 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
> >
> > > -----Original Message-----
> > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
> > > 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
> > >
> > >
> > > 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:bwijnen@lucent.com]
> > > > 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 mibs@ops.ietf.mailing
> > > > 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:ravi.sahita@intel.com]
> > > > > 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:bwijnen@lucent.com]
> > > > > | Sent: Monday, January 27, 2003 1:49 PM
> > > > > | To: Rap-wg (E-mail); Diffserv@ietf.org
> > > > > | 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
> > > > > | diffserv@ietf.org
> > https://www1.ietf.org/mailman/listinfo/diffserv
> > > > | Archive:
> > > > | http://www.ietf.org/mail-archive/working-groups/diffserv/curre
> > > > nt/maillist.html
> > > >
> > >
> > >
> >
>