Subject: Re: [ipfix-info] new version of IPFIX info model

From: "Thomas Dietz" <[email-masked]>
Date: Fri, 16 Sep 2005 10:49:20 +0200

Jürgen, Lutz,

I guess the wording is a bit missleading. An Observation Domain can be a
scope, so maybe it should read

    An identifier of a Flow that is unique within an observation
    domain. This Information Element differs different flows when
    the flow details like IP Address, Protocol or Port are not of
    intrest or these flow details are exported in a different
    template.

I hope this is clearer and still matches your suggestion Lutz.

Regards,

Thomas

On Fri, 2005-09-16 at 09:58 +0200, Juergen Quittek wrote:
> Lutz,
> 
> As far as I understand you want to change the scope if the flowID
> from "per Exporting Process" to "per Observation Domain".
> Thus an Exporting Process reporting on more than one observation
> domain could re-use a flowID value in different Observation Domains.
> Correct?
> 
> Thanks,
> 
>     Juergen
> 
> --On 9/15/2005 2:36 PM +0200 Lutz Mark wrote:
> 
> >
> >
> > Dear all,
> >
> > I'd like to change the description of the FlowID I.E. (148)
> >
> > old:
> >    An identifier of a Flow that is locally unique to an Exporting
> >    Process.  Typically, this Information Element is used for limiting
> >    the scope of other Information Elements.
> >
> > new:
> >    An identifier of a Flow that is unique within an observation
> >    domain and its scope.
> >    Typically, this Information Element is used to differ
> >    different flows when the flow details are irrelevant or
> >    the flow details are exported in a different template.
> >
> > One motivation for the IE was our per-packet-export draft,
> > which we have extended since that time.
> >
> > Best regards,
> > Lutz
> >
> >
> > --
> > Help        mailto:[email-masked] and say "help" in message body
> > Unsubscribe mailto:[email-masked] and say
> > "unsubscribe ipfix" in message body
> > Archive     http://ipfix.doit.wisc.edu/archive/
> 
> 
> 
> --
> Help        mailto:[email-masked] and say "help" in message body
> Unsubscribe mailto:[email-masked] and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/

---

From: Lutz Mark <[email-masked]>
Date: Fri, 16 Sep 2005 11:42:15 +0200

Hi Thomas and Juergen,

> I hope this is clearer and still matches your suggestion Lutz.

thank you this sounds better. In addition i wondered if it makes
sense to make the flowid unique only within its scope. If the scope
for example ist the template. This allows the use of 2^32 FlowIDs
per template.

In my understanding the default scope of each exported IPFIX-data
is the observation domain. One can further limit the scope via
option records.

Best Regards,
Lutz

---

From: Paul Aitken <[email-masked]>
Date: Fri, 16 Sep 2005 11:34:02 +0100

Lutz,

Whatever the definition is, I'm wondering what happens when you 
eventually run out of FlowIDs?

ie, how can a FlowID be removed from an old flow and be allocated to a 
new flow?

Do FlowIDs have a certain lifetime inside which they cannot be reused? 
Or is there a clue that the FlowID is no longer in use or no longer 
valid? Or can we send a clue, ie a FlowID withdrawal message?

Or perhaps information sent using scope = FlowID only applies to the 
most recently exported flow which contained that FlowID. But what if the 
exported flow was lost in transit (UDP) or is sent *after* the scoped 
info (different SCTP channel)?

Cheers.
-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.

---

From: Lutz Mark <[email-masked]>
Date: Fri, 16 Sep 2005 13:42:12 +0200

Hi Paul,

I think at this time we only need the definion.

> info (different SCTP channel)?

good points. In our per-packet-export draft we suggested to
handle the flowID management similar to the IPFIX template
management. Maybe we can pick up this issue in the
ipfix implementation guidelines?

Best regards,
Lutz

---

From: Paul Aitken <[email-masked]>
Date: Fri, 16 Sep 2005 13:30:33 +0100

Lutz,

> I think at this time we only need the definion.

Perhaps so - but even when we're defining the object, we must have some
idea how it will be used.

> In our per-packet-export draft we suggested to handle the flowID 
> management similar to the IPFIX template management.

Well, firstly you're probably going to need a lot less template ID's
than flow ID's (unless you export unique templates for each flow!).

That's reflected in the fact the the template IDs are 16 bit numbers,
while the flow IDs are 32 bits.

Secondly, exhaustion of the available template IDs was envisaged some
time ago, so now we have the template withdrawal message which allows
template IDs to be reused. But there's no such mechanism for flow IDs.

Just to put the issue in perspective: if you're allocating an ID to each
flow, then at just 1000 flows/sec, 2^32 IDs will be consumed in 49.7
days. Or, any more than 136 flows/sec means you'll consume your 2^32 IDs
in one year.

> Maybe we can pick up this issue in the ipfix implementation 
> guidelines?

Rather, if there's to be a similar mechanism for re-using flow IDs (or
IDs in general) then it needs to be written in to the protocol draft. It
cannot be left for each individual implimentor to decide on their own
scheme.

Cheers.

---

From: Elisa Boschi <[email-masked]>
Date: Fri, 16 Sep 2005 14:45:53 +0200

Paul, Lutz,

>
>> Maybe we can pick up this issue in the ipfix implementation guidelines?
>
>
I would rather propose to describe the mechanism in the
per-packet-export draft. It is there, that we have used the Flow IDs
first. No mention of FlowIDs appears in the protocol draft...

cheers,
Elisa

---

From: Robert Lowe <[email-masked]>
Date: Fri, 16 Sep 2005 11:47:17 -0500

Just a couple of phrasing suggestions/corrections... provided this
change is to find its way into some draft.

-Robert

>>     domain. This Information Element differs different flows when
                                         ^^^^^^^^^^^^^^^^^
distinguishes between different
(is used to distinguish between different)

-OR-

differentiates separate, distinct
(is used to differentiate separate, distinct)

>>     intrest or these flow details are exported in a different
        ^^^^^^^
interest,

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 21 Sep 2005 22:30:55 +0200

Dear Lutz and all,

I would like to come to a conclusion.
Here is what I currently have.  I am not sure whether or not
this description reflects the outcome of our discussion well.

5.1.7.  flowId

   Description:
      An identifier of a Flow that is unique within an Observation
      Domain.  This Information Element can be used to distinguish
      between different Flows if Flow Keys such as IP addresses and
      port numbers are not reported or reported in separate records.
   Abstract Data Type: unsigned32
   Data Type Semantics: identifier
   ElementId: 148
   Status: current

Please have a look at it and comment.

Thanks,

    Juergen
-- 
Juergen Quittek        [email-masked]       Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de