Subject: Re: wildcard flowid in framework PIB?

From: Kwok Ho Chan <[email-masked]>
Date: Wed, 15 Jan 2003 15:55:17 -0500

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: [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.
>>>>>>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: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 15 Jan 2003 22:17:11 +0100

>>>>> Kwok Ho Chan writes:

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

[...]

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

WAIT

My reading here is that this is analog to Dscp and DscpOrAny. If this
is true, then we have the same problem in the filter definition of the
DIFFSERV-MIB. And if this is the same problem, then we should have a
similar way of addressing it. So perhaps we need to define FlowId and
FlowIdOrAny TCs similar to the Dscp and DscpOrAny TCs so we can use
the same solution everywhere.

If we agree that this would be the correct way to do things, then we
need to find out how to implement this with the current state of the
set of documents involved. Note that I have added Bert and Fred to the
To: list since I think they should be involved in handling this if my
interpretation of this situation is correct.

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>

---

From: Brian Williams <[email-masked]>
Date: Thu, 16 Jan 2003 10:32:33 +1100

Hi Kwok.
I find the terminology proposed in your update unclear:

In your explanation, you have:
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 appears clear enough. But then the acutal text change proposed is:

I think the text is unclear in two specific ways.

Firstly, (assuming my assumption is correct), it would be much clearer 
to use the IGNORED, rather than the term NOT-USED. To em, NOT-USED would 
be applicable if the field was optional, and you are checking if the 
field was specifically not provided. However, since the field is a part 
of the v6 header, it is not clear how NOT-USED applies.

The second part that is really unclear is how you should interpret:
"not any value of flow identifier in the IPv6 header will result in a 
filter match."

If you use the term IGNORED, then it is easy to explain that the field 
shall not be considered in the filter match.

Having made these comments on the current proposed text, I agree with 
the comments by Juergen below regarding the similarity to DSCP, and that 
a consistent approach should be sought.
/brian

---

From: Kwok Ho Chan <[email-masked]>
Date: Fri, 17 Jan 2003 13:16:21 -0500

(Please note I have added Brian Carpenter and Kathie Nicols to the CC list
as we are talking about possible impact to the DiffServ MIB.)

Hi Brian, Juergen, all:
I am using this E-Mail as reply to both of your E-Mails and keeping it
under one E-Mail thread (as they are related and should be considered
together for a solution).

First on the point of terminology, as raised by Brian Williams:
I agree that the term IGNORED is better than the term NOT-USED.
With IGNORED meaning the filter will ignore the flow identifier in the
IPv6 header during its filter processing.
With the following examples:
1. Packet FlowLabel = 0, Filter FlowId = 0, filter Satisfied.
     Notice Packet FlowLabel = 0 indicates the sending host is not using
     the IPv6 header's FlowLabel field.
2. Packet FlowLabel = ABC, Filter FlowId = ABC, filter Satisfied.
3. Packet FlowLabel = DEF, Filter FlowId = 0, FilterNegation = true, filter 
Satisfied.
     Notice this is Wildcard for cases when FlowLabel is used by the End Host.
     As Packet FlowLabel = 0, Filter FlowId = 0, FilterNegation = true, 
filter NotSatisfied.
4. Packet FlowLabel = "AnyValue", Filter FlowId = IGNORED.
     This instructs the filtering mechanism to not-use the Packet FlowLabel 
field
     as a filter criterion.
     The behavior is for the filtering mechanism to NOT based the event 
generation
     decision using the Packet FlowLabel field.
     I can see someone may use some wildcarding functionality to implement 
this.
     But that is implementation.  We need to capture the feature 
description, not
     jumping to the implementation conclusions.

As for the anolog to Dscp and DscpOrAny (defined in RFC 3289, DiffServ MIB)
point indicated by Juergen:
1. "Dscp"
     "Dscp" is used by the DiffServ MIB for marking action of the DSCP field.
     "Dscp" is NOT used by the Framework PIB.

     "FlowId"
     IMHO, this is out of scope for DiffServ MIB, unless we plan to use the 
DiffServ MIB
     to set IPv6 parameters in IPv6 End Hosts.  I think this should be part 
of IPv6 MIBs
     (which I have not find any RFCs or drafts that address this issue).
     This may be useful by IPv6 End Host (the only one that can set the IPv6
     Header FlowLabel field), but IMHO it is outside the scope of the 
Framework PIB.

2. "DscpOrAny"
     "DscpOrAny" is used by the DiffServ MIB for filter definition purposes.
     "DscpOrAny" is used by the Framework PIB for filter definition purposes.

     "FlowIdOrAny" or "FlowIdIgnored"
     Flavoring "FlowIdIgnored" based on above discussion.
     I think this can be used by both Framework PIB and DiffServ MIB.
     Should we define a "FlowIdIgnored" TC?
     If yes, where does it belong?

     At current time, we are addressing this issue in the Framework PIB 
context,
     hence the suggested change is for the Framework PIB only.
     Guidance is needed if this issue impacts other WGs or Areas.

I hope the information of this discussion help in coming to a better 
solution for
this issue.

Thanks!
-- Kwok --

At 10:32 AM 1/16/03 +1100, Brian Williams wrote:
>Firstly, (assuming my assumption is correct), it would be much clearer to 
>use the IGNORED, rather than the term NOT-USED. To em, NOT-USED would be 
>applicable if the field was optional, and you are checking if the field 
>was specifically not provided. However, since the field is a part of the 
>v6 header, it is not clear how NOT-USED applies.
>
>Having made these comments on the current proposed text, I agree with the 
>comments by Juergen below regarding the similarity to DSCP, and that a 
>consistent approach should be sought.
>/brian
>

---

From: Kwok Ho Chan <[email-masked]>
Date: Fri, 17 Jan 2003 14:53:57 -0500

Brian:
By "FlowId" I mean the TC definition for defining how to MARK the FlowID field.
As being different from the TC definition for filtering the FlowID field.
Using this analogy to the "Dscp" and "DscpOrAny" as Juergen raised.

The "FlowId" TC being out of scope for diffserv MIB because diffserv 
functionality
will not MARK the IPv6 Header FlowID field as the IPv6 draft indicates only End
Host can mark the IPv6 Header FlowID field.
Is this correct?

The TC definition for filtering the FlowID field will still be in scope for 
diffserv MIB,
as indicated in later discussion within the same E-Mail.

Please advise.
Thanks!
-- Kwok --

At 08:37 PM 1/17/03 +0100, Brian E Carpenter wrote:
>Kwok,
>
>The FlowID is certainly not out of scope for the diffserv MIB. It is
>one of the possible fields in a multifield classifier. We are very close
>to Last Call in the IPv6 WG on a proper definition of the FlowID, but
>the IPv6 WG will certainly not be specifiying how it is used in
>specific QOS solutions such as diffserv or intserv.
>
>The only issue for the diffserv MIB is whether we need to add a
>wildcard, and for that I am waiting until Fred is back on-line.
>
>    Brian
>
>Kwok Ho Chan wrote:
> >

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 17 Jan 2003 20:37:36 +0100

[ 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>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Kwok,

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 17 Jan 2003 23:07:16 +0100

Correct. The FlowID is immutable (unlike the DSCP). Are you saying the
MIB allows setting the FlowID? If so, that's a bug.

  Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment at the IBM Zurich Laboratory, Switzerland

---

From: Kwok Ho Chan <[email-masked]>
Date: Mon, 20 Jan 2003 12:29:33 -0500

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

>MIB allows setting the FlowID? If so, that's a bug.

The Diffserv MIB currently does not set the FlowID field in the IPv6 header.
It handles the filter that examine the FlowID field in the IPv6 header, 
IMHO the
correct functionality.

The response I provided in the E-Mail thread below is to indicate that 
Diffserv MIB,
Framework PIB, Diffserv PIB does not require the TC (suggested by Juergen)
for setting/marking of the FlowID field in the IPv6 header.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 21 Jan 2003 11:07:50 +0100

>>>>> Kwok Ho Chan writes:

Kwok> The response I provided in the E-Mail thread below is to
Kwok> indicate that Diffserv MIB, Framework PIB, Diffserv PIB does not
Kwok> require the TC (suggested by Juergen) for setting/marking of the
Kwok> FlowID field in the IPv6 header.

I never suggested to introduce these TCs to change something in a
packet. This is a mis-understanding on your side.

/js