[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FW: FW: FlowId and FlowIdOrAny
Just in case any of you has a comment or concern
Thanks,
Bert
-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: maandag 27 januari 2003 22:49
To: Rap-wg (E-mail); Diffserv@ietf.org
Subject: 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