Re: RE: FW: FlowId and FlowIdOrAny

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
> [email protected]
> 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
_______________________________________________
diffserv mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html