Subject: RE: wildcard flowid in framework PIB?

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Sat, 18 Jan 2003 03:56:25 +0100

Inline

Bert 

> -----Original Message-----
> From: Kwok Ho Chan [mailto:[email-masked]]
> Sent: vrijdag 17 januari 2003 19:16
> To: Brian Williams
> Cc: Kwok-Ho Chan; Juergen Schoenwaelder; Bert Wijnen; Fred Baker;
> [email-masked]; [email-masked]; Brian E Carpenter;
> [email-masked]
> Subject: Re: wildcard flowid in framework PIB?
> 
> 
> (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.

Why do these terms have to be capitalized??

> With IGNORED meaning the filter will ignore the flow identifier in the
> IPv6 header during its filter processing.

So it basically also means any, right? 
So a TC named FlowIdOrAny seems to correctly capture the idea.

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

So is the FilterNegation value not relevant in cases 1 and 2?

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

All the above is fine. And you are arguing that you need to
add that special value to indicate "ignore the flowID" or
"consider any flowID a match"... or that is what I understand.

That is OK with me... and all I want is to see WG consensus on 
that as a first step.

My second concern is that this requirement to sometimes use FlowID
and at other times FlowIdOrAny, is a generic need and does not just
apply to the framework PIB. So that suggest that we better have
something like two TCs for it, so that people can re-use the
definition and so that from now on we all know how to specify 
this (namely by using the TCs).

In fact, this discussion has already revealed to me that even
the old way you defined the flowID in both the framework PIB
and in the diffserv MIB, that we SHOULD have created a TC for
that, even before this whole discussion started.

Now to the DIFFSERV MIB specifics

> 
> 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.
> 
Correct, but that is irrelevant to the discussion
What the DIFFSERV WG did, is define a TC that clearly specifies
what a Dscp is and that definition can then be re-used by many 
MIB and PIB modules (if they need it of course).

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

Kowk, when you define a TC like Dscp or FlowId, then that does not
mean that they can only be used to SET a field in a protocol pdu.
It can also be used in other ways. If you look at the diffserv
MIB, then you will see that if we had defined a FlowId TC, then
  diffServMultiFieldClfrFlowId OBJECT-TYPE
      SYNTAX         Unsigned32 (0..1048575)
      MAX-ACCESS     read-create
      STATUS         current
      DESCRIPTION
         "The flow identifier in an IPv6 header."
      ::= { diffServMultiFieldClfrEntry 8 }
Would indeed have used that TC as the SYNTAX.
And you could have shared it in your revision 9 of your 
internet draft.

>      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.
> 
We can argue indeed WHERE such a TC should be defined.
In many cases in the IETF, we just defined them in whichever 
MIB (or PIB) document that first had a need and where we envisioned
that it could be re-used by other MIB or PIB documents in the 
furture.

> 2. "DscpOrAny"
>      "DscpOrAny" is used by the DiffServ MIB for filter definition 
>       purposes.
>      "DscpOrAny" is used by the Framework PIB for filter 
>       definition purposes.
> 
Correct. And in the future, other MIB or PIB modules can use it for
similar things too, or they can use it for other purposes.

>      "FlowIdOrAny" or "FlowIdIgnored"
>      Flavoring "FlowIdIgnored" based on above discussion.

Flavoring ??? Do you mean that you prefer the name FlowIdIgnored ??

>      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?
> 
I think FlowIdOrAny is the better name for a TC.
The reason is, that the wildcard value does not always have to
mean that the flowID is to be ignored.

The TC would/should look as follows I think:

  FlowIdOrAny TECTUAL-CONVENTION
      DISPLAY-HINT "d"
      STATUS       current
      DESCRIPTION "The flow identifier in an IPv6 header that may be
                   used to discriminate traffic flows. The value of
                   4294967295 is used to indicate a wildcard, i.e.
                   any value.
                  "
      SYNTAX       Unsigned32 (4294967295 | 0..1048575)

In the case of the framework PIB, you would probably use it as follows

   frwkIpFilterFlowId OBJECT-TYPE
       SYNTAX         FlowIdOrAny
       STATUS         current
       DESCRIPTION
          "The wildcard or any-value of 4294967295 for this attribute
           MUST be interpreted as indication that any flow ID value
           in the IPv6 header will match. This results in the flow ID
           to be ignored for matching this filter entry."
       ::= { frwkIpFilterEntry 7 }

If the Diffserv MIB needs needs a similar change, then they can use
this TC. If not, then they can keep what they have now, or they could
use (in the next revision) a new TC called FlowId which would look
like:

  FlowId TECTUAL-CONVENTION
      DISPLAY-HINT "d"
      STATUS       current
      DESCRIPTION "The flow identifier in an IPv6 header that may be
                   used to discriminate traffic flows.
                  "
      SYNTAX       Unsigned32 (0..1048575)

In the future, other MIB and PIB modules can then also re-use these
TCs without causing confusion or risks for different definitions.

>      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.
> 
Correct, you seem to want to fix this right now as a last minute change
in a doc that is ready to become RFC (RFC-editor has issued 48-hour
author call). For that we need consensus from the RAP WG.

If the diffserv MIB needs a similar fix is a diffserv WG issue.
I still think they do, but that is up to them, and it can be done
at a later time when they rev their RFC anyway.
By creating a TC now, we would pabve the way.

The two TCs that I propose would probably best be done in a separate
MIB module (so they can be used by both PIB and MIB modules, I believe
that a MIB cannot import from a PIB... but a PIB can import from a MIB)

Since that would result in too much of a delay, you could define
the Unsigned 32 values in the PIB and we can then later at revision
time replace it with a TC that we define in a separate MIB Module.

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

Hope my answers help as well

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

---

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

>>>>> Wijnen, Bert (Bert) writes:

Bert> I think FlowIdOrAny is the better name for a TC.  The reason is,
Bert> that the wildcard value does not always have to mean that the
Bert> flowID is to be ignored.

Agreed.

Bert> The TC would/should look as follows I think:

[...]

I would prefer to use -1 as a special value rather than using
4294967295. So what I would like to see defined are the following
two TCs:

  FlowId TECTUAL-CONVENTION
      DISPLAY-HINT "d"
      STATUS       current
      DESCRIPTION 
	"The flow identifier in an IPv6 header that may be used to
	 discriminate traffic flows."
      REFERENCE
	"RFC 2460"
      SYNTAX       Unsigned32 (0..1048575)

  FlowIdOrAny TECTUAL-CONVENTION
      DISPLAY-HINT "d"
      STATUS       current
      DESCRIPTION 
	"The flow identifier in an IPv6 header that may be used to
	 discriminate traffic flows. The value of -1 is used to
	 indicate a wildcard, i.e. any value."
      REFERENCE
	"RFC 2460"
      SYNTAX       Unsigned32 (-1 | 0..1048575)

Open issues:

- Is the flow identifier the same as the flow label? I guess so. If
  this is true, then we should probably use the TC names FlowLabel
  and FlowLableOrAny and also change the wordings in the description
  clause.

- The name of the MIB modules which will contain these definitions.

- Since Fred kind of said that the diffServMultiFieldClfrFlowId
  object should have had a wildcard, can we agree that this is 
  actually a bug in RFC 3289 which will be fixed by using FlowIdOrAny
  in the next revision of the DIFFSERV-MIB?

/js

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

---

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

I changed the subject line and fixed the proposed TC. So here is where
I think we are. I have also reduced the CC list and I have added the
diffserv mailing list since diffserv folks should be in the loop I
think.

  FlowId TECTUAL-CONVENTION
      DISPLAY-HINT "d"
      STATUS       current
      DESCRIPTION 
	"The flow identifier in an IPv6 header that may be used to
	 discriminate traffic flows."
      REFERENCE
	"RFC 2460"
      SYNTAX       Integer32 (0..1048575)

      SYNTAX       Integer32 (-1 | 0..1048575)

Open issues:

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 21 Jan 2003 18:19:21 +0100

>>>>> Dan Grossman writes:

Dan> Um... since you're bringing the Diffserv folks into the middle of
Dan> the conversation, would it be possible to clue us in as to what
Dan> we're talking about?  Thanks.

I can try - not sure I have the details right though since I joined
late in this as well.

I think the core of the story is that the FRAMEWORK-PIB currently
defined in draft-ietf-rap-frameworkpib-09.txt has the following
definition (in a generic filter):

Someone observed that this definition does not have a value to
indicate that this specific attribute is to be ignored when matching
packets. So it was suggested to change the definition. Note that
this document is sitting in 48 hour RFC review.

Some people observed this and checked the classifier definition in the
DIFFSERV-MIB. The DIFFSERV-MIB says:

It looks like this definition as well lacks a wildcard mechanism. Fred
Baker already wrote that he had one in mind but somehow if never got
into the mind. Note that the DIFFSERV-MIB is in RFC 3289 (Proposed
Standard).

Triggered by a query from Kwok, I checked the INTEGRATED-SERVICES-MIB
which has this definition:

    intSrvFlowFlowId OBJECT-TYPE
        SYNTAX      INTEGER (0..16777215)
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
           "The flow ID that  this  sender  is  using,  if
           this  is  an IPv6 session."
       ::= { intSrvFlowEntry 11 }

This is published in RFC 2213 (Proposed Standard).

It would be nice to have common TCs in place for flow labels (or are
they called flow ids?) much in the same way we have common TCs for
DSCPs. And this is how we got to where we are (as far as I understand
the situation).

While we can't put common definitions in place while the ID is in 48
hours review, we hopefully can figure out a plan how we can address
this proliferation of different ways to represent flow lables when
documents are revised.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 22 Jan 2003 15:19:28 +0100

I found some more objects that seem to model a flow label. It turns
out that MIB authors are really creative...

draft-ietf-ipsp-ipsec-conf-mib-05.txt:

  ihfIPv6FlowLabel OBJECT-TYPE
      SYNTAX      OCTET STRING (SIZE(3))
      MAX-ACCESS  read-create
      STATUS      current
      DESCRIPTION
          "The IPv6 Flow Label that the packet must match against.
          This object is only used if ipv6FlowLabel is set in ihfType."
      ::= { ipHeaderFilterEntry 13 }

  They obviously have another mechanism to control whether the
  object participates in a match.

draft-ietf-rmonmib-sspm-mib-06.txt:

   sspmSourceProfileFlowLabel OBJECT-TYPE
       SYNTAX      Integer32 (0..1048575)     -- 20-bit range (0 to 0xfffff)
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "This object is  used to specify the Flow Label  in a IPv6
            packet (RFC 2460) to force special handling by the IPv6 routers for
            non-default quality-of-service.

            This object is meaningful only when sspmSourceDestAddressType is
            ipv6(2).  The value of this object defaults to zero if not
            set."
       DEFVAL { 0 }
       ::= { sspmSourceProfileEntry 7 }

  This object seems to actually control how the flow label looks like
  in packets coming from a synthetic traffic source.

Note that these objects are called flow label rather than flowid and
hence I did not find them the first time...

/js

---

From: Dan Grossman <[email-masked]>
Date: Tue, 21 Jan 2003 11:34:14 -0500

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

Um... since you're bringing the Diffserv folks into the middle of the conversation, would
it be possible to clue us in as to what we're talking about?
Thanks.

Juergen Schoenwaelder wrote:

> _______________________________________________
> diffserv mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/diffserv
> Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html