[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Diffserv] RE: FW: FlowId and FlowIdOrAny
[ 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>-owner@ops.ietf.org 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:
>
> 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/current/maillist.html
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter
Distinguished Engineer, Internet Standards & Technology, IBM
On assignment at the IBM Zurich Laboratory, Switzerland