Subject: wildcard flowid in framework PIB?

From: Brian Williams <[email-masked]>
Date: Wed, 06 Nov 2002 10:46:23 +1100

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

---

From: "Emmanuel Dumont" <[email-masked]>
Date: Wed, 6 Nov 2002 05:07:58 +0100

Hi Brian,

Do you think a wildcard is needed for the FlowId attribute ?
Which one could you suggest ?
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 ?

Emmanuel Dumont
----------------------------
France Telecom OCISI/DIeP (Guyancourt, France)
Mail: [email-masked] / [email-masked]
----------------------------

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]]De la part de
Brian Williams
Envoye : mercredi 6 novembre 2002 00:46
A : [email-masked]
Objet : wildcard flowid in framework PIB?

Hi All.

---

From: Brian Williams <[email-masked]>
Date: Fri, 08 Nov 2002 09:13:06 +1100

Hi Emmanuel.
Please see comments inline.
/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.

>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.

---

From: Kwok Ho Chan <[email-masked]>
Date: Thu, 07 Nov 2002 19:03:07 -0500

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

The reasoning is as follows:

Please first see
   http://www.ietf.org/internet-drafts/draft-ietf-ipv6-flow-label-03.txt
which I have quote the following from bottom of its section 3:

>    The Flow Label value set by the source MUST be delivered unchanged to
>    the destination node(s).
>
>    IPv6 nodes MUST NOT assume mathematical or other non-standardized
>    properties of the Flow Label values assigned by source nodes. Router
>    performance SHOULD NOT be dependent on the distribution of the Flow
>    Label values. Especially, the Flow Label bits alone make poor
>    material for a hash key.
>
>
>
>Rajahalme, et al.         Expires: March 2003                   [Page 3]
>
>INTERNET-DRAFT     draft-ietf-ipv6-flow-label-03.txt      September 2002
>
>
>    If an IPv6 node is not providing flow-specific treatment, it MUST
>    ignore the field when receiving or forwarding a packet.

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.

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.

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:
>other attributes (eg DSCP). I think there would need to be an explanation 
>of why one is not provided.
>
>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

---

From: Brian Williams <[email-masked]>
Date: Fri, 08 Nov 2002 11:54:29 +1100

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

> The reasoning is as follows:

<snip>

>>    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 draft-ietf-ipv6-flow-label-03.txt draft indicate that there can be 
> 3 conditions

This is clear.

> for all Flow Label values other than zero.

This is also clear.

>> 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 
>> 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

---

From: Kwok Ho Chan <[email-masked]>
Date: Thu, 07 Nov 2002 20:30:24 -0500

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:
>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.

---

From: Brian Williams <[email-masked]>
Date: Fri, 08 Nov 2002 14:17:31 +1100

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:

>> 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
>>> the draft-ietf-ipv6-flow-label-03.txt draft indicate that there can 
>>> be 3 conditions
>>> set to true and frwkIpFilterFlowId set to zero.  This will indicate 
>>> a filter match
>>>> 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.
>>>>

---

From: Freek Dijkstra <[email-masked]>
Date: Wed, 06 Nov 2002 11:19:32 +0100

On 06-11-2002 05:07, Emmanuel Dumont <[email-masked]> wrote:

> [...]

I haven't looked into this much detail of the FR-PIB, but I have to note
that the current draft of the Access Bind PIB [1] does require that each

Is it possible for PRI's to use a value of <null> instead of 0, -1, etc to
indicate a wildcard?

[1] draft-ietf-rap-access-bind-02.txt, a new version was submitted but is
not pubblished

---

From: Freek Dijkstra <[email-masked]>
Date: Sat, 09 Nov 2002 13:54:42 +0100

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]

> there a distinct wildcard value indicated for the protocol and DSCP

Well, at first sight I would say that they are same. After all, they mean
the same: ignore this header field. In fact, the distinction between
numerical wildcards (0, -1, etc,) and NULL wildcards has confused me.

However, in draft-ietf-rap-access-bind-02.txt (and all previous versions)
implicitly assumes that you can specify both a NULL and a numberical
wildcard. They have a very different meaning:

Allow me to use an example by Walter Weiss. Take for example these two
frwkIpFilter filters, which will match all packets, regardsless of the port
number of the source address.

Filter1:
 frwkIpFilterDstL4PortMin = <null>
 frwkIpFilterDstL4PortMax = <null>

Filter1:
 frwkIpFilterDstL4PortMin = 1
 frwkIpFilterDstL4PortMax = 65535

However, the access bind PIB specifies a signaling protocol, and for the
second filter, an event will be sent each time a new unique port number is
detected. For the first filter, the port number is ignored in determining if
an event must be sent.

Regards,
Freek Dijkstra