Subject: Re: [IPFIX] Re: [ipfix-protocol] IPFIX-INFO last call comment: Observation Domains, Templates, and Sessions

From: Gerhard Muenz <[email-masked]>
Date: Sun, 01 Oct 2006 17:30:00 +0200

Dear all,

So we are back to the same problem again concerning the double function
of OD ID as stated in:
http://www1.ietf.org/mail-archive/web/ipfix/current/msg03400.html

Last time, if I remember correctly, we more or less agreed on what is
written in the current draft version in order to avoid bigger changes.

Some remarks about the current discussion:

Andrew Johnson wrote:
> IPFIX INFO rev 12 the OD IDs were considered unique per Exporting
> Process.  That means that each Exporting Process could export
> using it's own set of Observation Domain IDs and that the number
> space is not common between them.
> 
> Now we don't use the OD ID as an Exporting Process Identifier.

We could actually use the Exporting Process ID in the IPFIX header
instead, but than we have to assigne unique exporter IDs on a device.

> In short, it is agreed that the EP of a connection cannot be
> identified with the mandatory information.  So Brain and I are
> suggesting that the OD ID is considered unique per connection
> session.

Then we should call it session ID.

> The alternative is to scope the Observation Domain ID to be
> entire IPFIX device.  This means that different Exporting
> Processes will have to negotiate (or be configured) to use the
> Observation Domains correctly.  Furthermore, since template IDs
> and other IEs are scoped to the OD ID, then if you wanted two
> Exporters to report on the same Observation Domain (with the
> same ID) then you would have to negotiate (or configure) use
> of Template IDs, flow IDs, common properties IDs, ...

This is maybe a stupid question: Can't we distinguish different
Exporting Processes on a single device based on the source port number?

> Part of the problem here is that the Observation Domain ID seems
> to be seen as something useful. Imagine two flows that had
> different common properties IDs.  You wouldn't expect that to
> be useful information without the options to explain what that
> ID means.  You can't even be assured that the two different IDs
> actually map to different properties.  The same is true for the
> Observation Domain IDs.
> 
> Originally the Observation Domain ID was called the Source ID.
> This only changed in version 12 of the INFO draft.  It's main
> purpose is and always has been (see NetFlow version 9) to be
> used to differentiate between templates seen on different Line
> Cards of a distributed system.
> 
> Let's examine the c7500 router from Cisco.  In this example
> we have a system of three line cards and we configure it to
> monitor flows that are egressing from a single interface on
> one of the Line Cards.
> 
> Now the interface being monitored is present on Line Card 3,
> however all the line cards and the Routing Processor could
> observe and generate flows that are destined for that Interface.
> That is because on a c7500 the output features are run on the
> input Line Card.
> 
> This means that the collector will see flow records from up
> to four different sources:
> 
>  +----------------------------------------------------------+
>  | Routing Processor                                        |
>  +----------------------------------------------------------+
>           |             |             |            |
>           |        +---------+   +---------+   +---------+
>           |        |  LC 1   |   |  LC 2   |   |  LC 3   |
>           |        +---------+   +---------+   +---------+
>           |             |             |            |
>           v             v             v            v
>  +----------------------------------------------------------+
>  | Collector                                                |
>  +----------------------------------------------------------+
> 
> The collector will see a single UDP "session" from a single
> Exporting Process, using 4 different source IDs (i.e. Observation
> Domain IDs).
> 
> It has been said that you need to know what Observation Domain
> a flow was observed in order to aggregate the information
> together.  In the above case a single flow that has been load
> balanced across interfaces on LCs 1 and 2 will generate two
> flow records from different Observation Domains.  Can you
> aggregate?  Of course you can!

I assume that the administrator has to know the configuration of the
monitoring device in this case. I think that we can suppose that this
context information is available to him.

> What is important is getting the right set of flow keys.  In
> this case the index of the output interface is important to
> the user, so that must be included in the flow.
> 
> If the Line Card that the flow was observed on is important
> then put it in the flow (element 141).

Agreed.

Regards,
Gerhard

_______________________________________________
IPFIX mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipfix

---

From: Gerhard Muenz <[email-masked]>
Date: Sun, 01 Oct 2006 17:30:00 +0200

Dear all,

Agreed.

Regards,
Gerhard

---

From: Paul Aitken <[email-masked]>
Date: Sun, 01 Oct 2006 17:13:00 +0100

Gerhard,

> instead, but than we have to assigne unique exporter IDs on a device.

Then these IDs probably have to be assigned manually, because exporters 
from different vendors which are running on the same IPFIX device can't 
be expected to communicate with one another to arrange their own unique IDs.

Then, as a user, it would be unclear to me why I have to assign unique 
IDs to all my exporters when really I don't care about exporters at all.

What I do care about are:

   a) what data were observed?
      - which is conveyed in template and data records, and

   b) where that data was observed
      - which may be somewhat conveyed by the OD ID, but see below.

What I (as a user) don't care about is which particular exporter sent 
that information to me. Though the way things stand today, the CP 
certainly does need to know which exporter sent the info so it can deal 
with IDs that are scoped to that exporter.

> Then we should call it session ID.

No; "session ID" implies an identifier for the session. Whereas the OD 
ID being unique per session is quite different; it means that this OD ID 
only has any meaning in the context of this session, and the same OD ID 
on another session means something else. But it does not identify the 
session; the source address and port do that.

> Exporting Processes on a single device based on the source port number?

Nope. Suppose one IPFIX device with two exporters, and suppose each 
exporter has two export sessions. So ports 1001, 1002, 1003 and 1004 are 
in use. Which port belongs to which exporter? -> you don't know.

> context information is available to him.

I'd hope that the administrator always has a good understanding of the 
configuration of the monitoring device. Unless we move to automatic / 
self configuration...

>>then put it in the flow (element 141).

Then we're agreed that instead of mapping the OD ID directly to an OD 
(eg, ID 0x0102 = linecard 2, ID 0x0203 = eth 3), that this information 
should be encoded in the flow if it's important? (Even using the 
reducing-redundancy technique for multiple flows.)

Then the OD ID is just an ID that helps us to differentiate templates 
that have the same template IDs but pertain to different domains. Right?

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

---

From: Paul Aitken <[email-masked]>
Date: Sun, 01 Oct 2006 17:13:00 +0100

Gerhard,

---

From: Brian Trammell <[email-masked]>
Date: Mon, 2 Oct 2006 09:32:48 -0400

On Oct 1, 2006, at 12:13 PM, Paul Aitken wrote:

> Then we're agreed that instead of mapping the OD ID directly to an  
> OD (eg, ID 0x0102 = linecard 2, ID 0x0203 = eth 3), that this  
> information should be encoded in the flow if it's important? (Even  
> using the reducing-redundancy technique for multiple flows.)
>
> Then the OD ID is just an ID that helps us to differentiate  
> templates that have the same template IDs but pertain to different  
> domains. Right?

That's my view of it, with a couple of caveats:

1. to "differentiate templates" I'd add "differentiate scoped  
options" (because odId is also the root of all other scopes,  
especially cpId as in reducing-redundancy).

2. we may want to allow implementors to allow operators to shoot  
themselves in the foot with odId, if they're sure they know what  
they're doing, as follows: A. the EP implementation MAY allow the  
user to configure odIDs manually, B. the CP implementation MAY allow  
the user to do something with the odID (such as storing it with the  
flow); however C. if not specifically configured in this way, the CP  
MUST NOT store the odID (much as it doesn't store the tID now).

Regards,

Brian

---

From: Brian Trammell <[email-masked]>
Date: Mon, 2 Oct 2006 09:32:48 -0400

Regards,

Brian

---

From: Paul Aitken <[email-masked]>
Date: Mon, 02 Oct 2006 14:44:10 +0100

Brian,

>> (eg, ID 0x0102 = linecard 2, ID 0x0203 = eth 3), that this  
> 1. to "differentiate templates" I'd add "differentiate scoped  options" 
> (because odId is also the root of all other scopes,  especially cpId as 
> in reducing-redundancy).

Agreed.

> they're doing, as follows: A. the EP implementation MAY allow the  user 
> to configure odIDs manually, B. the CP implementation MAY allow  the 
> user to do something with the odID (such as storing it with the  flow); 
> however C. if not specifically configured in this way, the CP  MUST NOT 
> store the odID (much as it doesn't store the tID now).

Why would you store the OD ID with the flow data?

Firstly, we just agreed that it's not going to tell you anything useful 
about the data. It only helps you figure out which templates (including 
options, ACK) to use to decode the data, and presumably you've already 
done that part.

Secondly, the OD ID will be completely out of context. By your own 
arguments, it's only valid within the scope of an export session. Making 
it available outwith that session is just meaningless.

If the OD ID only helps us to scope templates (including options) then 
that's *all* we must do with it. It mustn't be stored in or with the 
flow data *as if* it has some other meaning.

OTOH if it does have some other meaning (eg, 0x0102 maps to "linecard 
2") then it would make sense to store it with the flow data. But that's 
saying that OD IDs are configured per device, and is contrary to the 
idea that the OD ID is unique within the export session.

---

From: Paul Aitken <[email-masked]>
Date: Mon, 02 Oct 2006 14:44:10 +0100

Brian,

Agreed.

---

From: Brian Trammell <[email-masked]>
Date: Mon, 2 Oct 2006 10:02:39 -0400

On Oct 2, 2006, at 9:44 AM, Paul Aitken wrote:

> Brian,
>
>>> Then we're agreed that instead of mapping the OD ID directly to  
>>> an  OD (eg, ID 0x0102 = linecard 2, ID 0x0203 = eth 3), that  
>>> this  information should be encoded in the flow if it's  
>>> important? (Even  using the reducing-redundancy technique for  
>>> multiple flows.)
>>>
>>> templates that have the same template IDs but pertain to  
>>> different  domains. Right?
>> user to configure odIDs manually, B. the CP implementation MAY  
>> allow  the user to do something with the odID (such as storing it  
>> with the  flow); however C. if not specifically configured in this  
>> way, the CP  MUST NOT store the odID (much as it doesn't store the  
>> tID now).
>

The only reason to do so is if you know 1. it was manually assigned  
and 2. is stable (I'm thinking about a specific use case I have  
here). But, you're right; if we really need this, we have more than  
enough in the way of information elements with _actual meaning_ to do  
the same thing.

(Complete aside, it would be really nice to have a way to scope a  
value to a message. Perhaps a zero-length IE whose presence as scope  
means the option applies to the entire message?)

> Firstly, we just agreed that it's not going to tell you anything  
> useful about the data. It only helps you figure out which templates  
> (including options, ACK) to use to decode the data, and presumably  
> you've already done that part.
>
> arguments, it's only valid within the scope of an export session.  
> Making it available outwith that session is just meaningless.
>
> If the OD ID only helps us to scope templates (including options)  
> then that's *all* we must do with it. It mustn't be stored in or  
> with the flow data *as if* it has some other meaning.

These are all excellent points, so I'm going to go ahead and declare  
myself convinced. Strike caveat 2.

Cheers,

Brian

---

From: Brian Trammell <[email-masked]>
Date: Mon, 2 Oct 2006 10:02:39 -0400

Cheers,

Brian

---

From: Paul Aitken <[email-masked]>
Date: Mon, 02 Oct 2006 15:17:19 +0100

Brian,

> The only reason to do so is if you know 1. it was manually assigned  and 
> 2. is stable (I'm thinking about a specific use case I have  here).

Then you're attributing a device-wide meaning to an exporter session 
specific ID. Or looked at another way, you're unnecessarily overloading 
the OD ID.

> But, you're right; if we really need this, we have more than  enough in the 
> way of information elements with _actual meaning_ to do  the same thing.

Agreed. If the OD ID can be attributed with some information, then put 
that info in the flow data. If it's duplicated for every flow, then use 
the techniques in the reducing-redundancy draft.

> (Complete aside, it would be really nice to have a way to scope a  value 
> to a message. Perhaps a zero-length IE whose presence as scope  means 
> the option applies to the entire message?)

I did recently ask whether a) it's valid to send a zero-length IE 
(though as data, not as scope) and b) what it means.

Seems that it's valid, and probably means that the implimentation is 
broken ;-)

>> then that's *all* we must do with it. It mustn't be stored in or  with 
>> the flow data *as if* it has some other meaning.
> 
> 

:-)

---

From: Paul Aitken <[email-masked]>
Date: Mon, 02 Oct 2006 15:17:19 +0100

Brian,

:-)

---

From: Brian Trammell <[email-masked]>
Date: Mon, 2 Oct 2006 11:37:58 -0400

On Oct 2, 2006, at 10:17 AM, Paul Aitken wrote:

>> value to a message. Perhaps a zero-length IE whose presence as  
>> scope  means the option applies to the entire message?)
>
> Seems that it's valid, and probably means that the implimentation  
> is broken ;-)

Indeed, there is no restriction on (or mention of) this in the  
protocol or the implementation guidelines. There should at least be a  
mention, I think, to avoid confusion.

The two most reasonable possibilities (at least from the limited  
point of view of the use cases I have for them :) ) seem to be:

1. allow zero-length IEs to be used as scope only; the meaning of the  
scope would be part of the IE definition; note that I can at the  
moment think of only two meaningful scopes, message and session.

2. forbid zero-length IEs at all; message and session scope could  
then be implemented using special IEs whose content would be ignored.

Thoughts?

- Brian

---

From: Brian Trammell <[email-masked]>
Date: Mon, 2 Oct 2006 11:37:58 -0400

Thoughts?

- Brian

---

From: Paul Aitken <[email-masked]>
Date: Mon, 02 Oct 2006 17:50:26 +0100

Brian,

> Indeed, there is no restriction on (or mention of) this in the  protocol 
> or the implementation guidelines. There should at least be a  mention, I 
> think, to avoid confusion.
> 
> The two most reasonable possibilities (at least from the limited  point 
> of view of the use cases I have for them :) ) seem to be:
> 
> scope would be part of the IE definition; note that I can at the  moment 
> think of only two meaningful scopes, message and session.

If you want scope then you should be using options. Or more generally 
(as has been suggested before) we should have defined data and options 
templates to be one and the same thing, with the possibility of scope 
length = 0.

> 2. forbid zero-length IEs at all; message and session scope could  then 
> be implemented using special IEs whose content would be ignored.

I don't see any reason to forbid zero-length IEs. Granted, they're 
unusual and not particularly useful - but there's nothing actually wrong 
with sending them. Hopefully collectors are robust enough to deal with them!

If you want to embed scope info into data records, then let's do it 
properly with new IEs designed for the purpose. Or design a new data set 
with a different header. But let's not mandate tricksy solutions!

---

From: Paul Aitken <[email-masked]>
Date: Mon, 02 Oct 2006 17:50:26 +0100

Brian,

---

From: Andrew Johnson <[email-masked]>
Date: Tue, 03 Oct 2006 11:25:08 +0100

Hi

reply inline.

> instead, but than we have to assigne unique exporter IDs on a device.

Unique Exporting Process IDs are not really expected to be
difficult to assign as every process gets a unique ID from the
OS.  However everyone would have to agree to use that as the ID.

> Then we should call it session ID.

Each session could use several OD IDs.  The collector can
differentiate between sessions already, what it can't do is
tell which session belongs to which Exporting Process.  So
a session restart means that all the IDs that are considered
unique per Exporting Process become confusable.

> Exporting Processes on a single device based on the source port number?

No, this is the main problem.  The port numbers tell us that these
are different sessions.  If we have two Exporting Processes using
ports 1000 and 2000 and we have a link failure, when the sessions
are re-established using ports 3000 and 4000, we can't tell how
these map to the old port numbers.

[SNIP]
> context information is available to him.

My point is that different vendors will use the OD to mean different
things.  The administrator will hopefully know how, but at the moment
we can't have generic rules about how to interpret the OD ID as it
has no real meaning.

regards

Andrew

---

From: Andrew Johnson <[email-masked]>
Date: Tue, 03 Oct 2006 11:25:08 +0100

Hi

reply inline.

[SNIP]

regards

Andrew

---

From: Lutz Mark <[email-masked]>
Date: Mon, 09 Oct 2006 16:38:30 +0200

Andrew,

>>> If we have two software programs, from two different vendors, running
>>> on a linux based router.  Both these programs are monitoring flows
>>> and exporting using IPFIX.  They are exporting to the same collector
>>> from the same Observation Domain.
>>>
>>> As far as the collector is concerned, these are two sessions from
>>> the same IPFIX device.  There is no way of telling different Exporting
>>> Processes apart.  If a network problem caused both sessions to restart
>>> simultaneously, the collector has no way to know how the two old
>>> sessions map to the new ones.
>>
>> In your example the two programs should use different OD IDs.
>> Then the mapping works.
> 
> What mapping are you referring to?

If the two programs export flow records using different
OD IDs but keeping them constant on restarts. e.g. prog A
use OD ID 1 and prog B use OD ID 2, then the collector can
assign data sent before to data send after the session restart,
because the OD IDs are the same. In addition the collector can differ
data from the two programs, because the OD IDs are different.

> This isn't really a big change, we already mandate that we resend
> all the template and option data if the session restarts.  It's
> already assumed that the collector shouldn't retain certain info
> between sessions, it's just not explicit in the protocol.
> 
> I really don't see this as practical.

Of course not. But I don't see the motivation to do so.

TemplateIDs and common properties IDs are unique
per Exporting Process and Observation Domain.
The Exporting Process may change TIDs and CPIDs
assignments when a session restarts if these
IDs are only valid within the session. There is
no need to negotiate these values with other processes.

> actually map to different properties.  The same is true for the

At least the Observation Domain IDs can be useful
for the collector to group incoming data. See above.

Best regards,
Lutz

---

From: Lutz Mark <[email-masked]>
Date: Mon, 09 Oct 2006 16:38:30 +0200

Andrew,

Best regards,
Lutz