Re: wildcard flowid in framework PIB?

[Kwok Ho Chan <khchan@NortelNetworks.com>]

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:
> >
> > (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:
> > >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:
> > >         "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."
> > >
> > >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
> > >
> > >Juergen Schoenwaelder wrote:
> > >
> > >>>>>>>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