Re: wildcard flowid in framework PIB?

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

  Brian

Kwok Ho Chan wrote:
> 
> 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

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