[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: wildcard flowid in framework PIB?

Hi all:
I think we should call this "Not Used" FlowId condition in framework PIB.

I think there have been some confusion on this topic and hence on
the requested changes.

The requested change is to have a way for the PDP to indicate to the PEP that
the frwkIpFilterFlowId attribute of frwkIpFilterEntry should not be used for defining
any filter match. This is different from the "Wildcard" match condition where "wildcard"
means match all. (The "wildcard" case is covered by the case 3 below).

We are doing final changes to the Framework PIB right before all text gets frozen into
the RFC.

To fix the "Not Used" case not realizable by the current Framework PIB, we propose
to make the following changes to the Framework PIB:

-----------------------------------------------------------------
Section 5

OLD:
frwkIpFilterFlowId OBJECT-TYPE
SYNTAX Unsigned32 (0..1048575)
STATUS current
DESCRIPTION
"The flow identifier in an IPv6 header."
::= { frwkIpFilterEntry 7 }

NEW:
frwkIpFilterFlowId OBJECT-TYPE
SYNTAX Unsigned32 (4294967295 | 0..1048575)
STATUS current
DESCRIPTION
"The flow identifier in an IPv6 header. The value
4294967295 for this attribute MUST be interpreted
as indication of this attribute NOT-USED, meaning
not any value of flow identifier in the IPv6 header will
result in a filter match. Notice this is different from
a wildcard match, in which case all values of flow
identifier in the IPv6 header will result in a filter match."
::= { frwkIpFilterEntry 7 }
------------------------------------------------------------------

SINCE WE ARE IN THE AUTHORS 48HR RFC EDITOR TIME PERIOD.
IF WE DO NOT HEAR ANY OBJECTIONS TO THIS CHANGE WITHIN 36 HOURS,
THEN WE ASSUME THIS CHANGE IS AGREED BY THE WG AND GOING AHEAD
ON MAKING THIS CHANGE TO THE FRAMEWORK PIB RFC.

Thanks!
-- Kwok --


At 02:17 PM 11/8/02 +1100, Brian Williams wrote:
Hi Kwok.
I understood the use of setting the length to zero was for unsupported attributes. If the intention is to use this for wildcards, then why is there a distinct wildcard value indicated for the protocol and DSCP attributes?
/brian

Kwok Ho Chan wrote:

Brian:
Please see inline below.
-- Kwok --

At 11:54 AM 11/8/02 +1100, Brian Williams wrote:
Hi Kwok.
I still am not clear how you would indicate a value to match all FlowIDs, and hence the FlowId can be ignored. Please see further inline.
/brian

Kwok Ho Chan wrote:

Brian, Emmanuel:
We do not need wildcard for the frwkIpFilterFlowId attribute in the
Framework PIB's frwkIpFilterEntry.

The reasoning is as follows:


<snip>


   If an IPv6 node is not providing flow-specific treatment, it MUST
   ignore the field when receiving or forwarding a packet.
I assume you are using this as the key point. What I am after is how you tell the node that it is not doing flow-specific treatment, and therefore the field can be ignored. That is, what do you send in the PIB to tell the node that the FlowId is not used? This is not case 1, 2, or 3 below.

The encoding of the frwkIpFilterFlowId attribute can have a length of zero, used to
indicate the attribute is not used (please see COPS-PR RFC 3084).
Hence this
is used to indicate this attribute is not used as part of the filter definition and will
not contribute to the filtering action, resulting in a "don't care" condition for
frwkIpFilterFlowId, the meaning of a wildcard match for this attribute.


the draft-ietf-ipv6-flow-label-03.txt draft indicate that there can be 3 conditions
for the Flow Label field of the IPv6 header:
1. It contain the value of zero, meaning it is not used.
2. It contain some specific value, with no defined syntax and semantics.
Hence each value is unique on its own with no relationship to Flow Labels
of containing another value.
3. It contain some value other than zero.

For the first 2 cases indicated above, the filter setup for them is trivial, just
set the frwkIpFilterFlowId to zero or the specific value needed.

This is clear.
For the 3rd case, the filtering definition should use the frwkBaseFilterNegation
set to true and frwkIpFilterFlowId set to zero. This will indicate a filter match
for all Flow Label values other than zero.

This is also clear.


Please let me know if this does not resolve the question you have.
Thanks!
-- Kwok --


At 09:13 AM 11/8/02 +1100, Brian Williams wrote:


Hi Emmanuel.
Please see comments inline.
/brian

Emmanuel Dumont wrote:


Hi Brian,

Do you think a wildcard is needed for the FlowId attribute ?
I consider that a wildcard would be needed for FlowId as much as for the other attributes (eg DSCP). I think there would need to be an explanation of why one is not provided.

Which one could you suggest ?


I would think a value of -1 (as used for DSCP) would be appropriate.


Kwok: is it an omission in the FR-PIB ?
Maybe an IPv6 expert can help us to solve that question...

Brian : Do you think that others wildcards are missing ?

This is the only one that I have identified is missing from the filter. I have not done a careful check on anything else in the document.

Emmanuel Dumont
----------------------------
France Telecom OCISI/DIeP (Guyancourt, France)
Mail: em.dumont@wanadoo.fr / emmanuel.dumont@francetelecom.com
----------------------------

-----Message d'origine-----
De : owner-rap@ops.ietf.org [mailto:owner-rap@ops.ietf.org]De la part de
Brian Williams
Envoye : mercredi 6 novembre 2002 00:46
A : rap@ops.ietf.org
Objet : wildcard flowid in framework PIB?

Hi All.
I have a question on the framework PIB. When I look at many of the
filter attributes, there exist values that can be used as wildcards.

The following are a few examples:
- for source and destination addresses, a prefix length of 0 indicates a
match of any address
- for DSCP, a value of -1 will match all DSCP values
- for port numbers, you can set the min and max to include all values
- for protocol number, a value of 255 means match all

However, for the FlowId, the range is specified as 0..1048575 which is
the valid range of the 20 bit label. How is a wildcard FlowId indicated?
/brian