Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness - summary and proposals

From: Andrew Johnson <[email-masked]>
Date: Thu, 15 Jun 2006 23:10:57 +0100

Hello all

Paul and I sat down in a room discussed this, and the complicated
implications of it, for most of the day.  We finally reached an
agreement and I'd like to summarise our discussion here.  Note
that most of the arguments presented here have been presented
by various people on the list.

The question was a simple one, should the Observation Domain ID
be considered unique per Exporting Process or per IPFIX Device.
In the end we agreed that it should be unique per Exporting
Process.

CASE 1: Observation Domain Unique by Device
===========================================
So let us consider the case of a Linux box running two seperate
monitoring /exporting applications.  Since the box is considered
a single IPFIX device with multiple Metering and Exporting
Processes, if the observation domain ID was unique per device,
both Exporting Processes should export using the same Observation
Domain ID.

This will involve some administrative process to co-ordinate, such
as:
 1. Some magic process to co-ordinate all the Exporting Processes
 2. Manual configuration
 3. Some fixed scheme that works out an ID as some hash of some
    identifiers of the Observation Domain.

Now some other IDs are considered to be unique within the
observation domain.  These IDs will now require to be
administered via the same process so that they can be properly
shared between Exporting Processes operating within the same
Observation Domain.

Alternatively we will have to redefine them to be unique per
Exporting Process, but that will mean that if we have a
distributed Exporting Process operating on several Line Cards
(and each Line Card is considered a separate OD) then the EP
will have to co-ordinate these IDs across Line Cards.

Unless we redefine these IDs to be unique across Observation
Domains and Exporting Processes, which is what we have today
if the Observation Domain ID is considered unique per
Exporting Process.

So what do all these complications and changes gain us?
We can match the Observation Domains of flows sent from the
same device, but different EPs.  This still isn't enough
to match duplicate observations, we'll also need to match
on all the key fields and perhaps some timestamps.  Even
then is it sufficient?  Different sampling and filtering
rules could result in different MPs having different
observations at the same Observation Point!  It is clear
we are a long way from defining de-duplication rules for a
general case.

Furthermore, if the two Exporting Processes are exporting
using different source IP addresses, then how can the
collector know they are from the same device?  Are we
going to force all Exporting Processes on a device to
export with the same IP address, or in the case of SCTP,
set of IP addresses?

In fact, perhaps two different IPFIX devices are being
used to monitor the same information.  Either through
passive probes or some sort of remote monitoring
application or perhaps because they are simply a
seconds stage aggregation.  Now changing the odId
scope has gained us nothing and we still can't match
the Observation Domains.

CASE 2: Observation Domain Unique by Exporting Process
======================================================
Perhaps knowing something about the observation domain
will be of use to your collector though.  Would a better
way to solve this be to have each collector export an
option identifying information about each observation
domain?

Note that we already have:
 149  sourceId -> observationDomainId
 300  observationPointId

Perhaps using these, and some way of uniquely identifying a
device then we can build up a true picture of what the
Observation Domain is and we can find matches on the
Observation Domains regardless of whether the reports are
from different Exporting Process or IPFIX devices.
Aggregators will even be able to aggregate the information
to identify the superset of Observation Points that make up
their Observation Domain.

OUR CONCLUSIONS
===============
Changing the scope of the Observation Domain ID will add
complexity to the protocol and generate other problems
that will need to be solved.

It won't really solve any problems as we can expect to
want to match observation domains from different IPFIX
devices.

Identifying matching domains from different Exporting
Processes may be useful, but there are other ways to
do it that will scale to matching ODs across different
IPFIX devices.

The Observation Domain ID should remain unique within
the Exporting Process.

regards

Andrew

--
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: Juergen Quittek <[email-masked]>
Date: Fri, 16 Jun 2006 08:57:21 +0200

Hi Andrew,

--On 15.06.2006 23:10 Uhr +0100 Andrew Johnson wrote:

 [...]

> The Observation Domain ID should remain unique within

Would you be fine with stating that it SHOULD be unique per IPFIX Device?

Thanks,

    Juergen

---

From: Andrew Johnson <[email-masked]>
Date: Fri, 16 Jun 2006 11:00:54 +0100

> Would you be fine with stating that it SHOULD be unique per IPFIX Device?

I don't think this change adds anything to the protocol, especially
as a collector cannot rely on the IPFIX device implementing this
recommendation.

In other words, is anyone on the list still insisting on the change?

I would prefer to not have the change, however if it is wanted I
don't object.

Andrew

---

From: Benoit Claise <[email-masked]>
Date: Fri, 16 Jun 2006 16:00:35 +0200

> In other words, is anyone on the list still insisting on the change?
Yes, I insist.

It would be more convenient for a router (I don't want to speak about 
the special devices) to assign the Observation Domain based on Line Card 
ID: one solution is the ENTITY-MIB to make sure it's unique.
This is why I like the proposal from Juergen "It is RECOMMENDED that an 
Observation Domain IDs is also unique per IPFIX device. "

Let's take this example: One sysadmin configures line card 1 with 
observation domain 1, while a second sysadmin configures line card 2 
with the same observation domain Id 1. If each observation domain 
exports using its own exporting process with the identical source IP 
address, how would the collector differentiate the template IDs? 
[IPFIX-PROTO] says:

           Collecting Processes SHOULD use the 
           combination of the Exporter (exporterIPv4Address, 
           exporterIPv6Address, or exportingProcessId) and the 
           Observation Domain ID field to separate different export 
           streams originating from the same Exporting Process.

If the Observation Domain Id is RECOMMENDED to be unique per device, ...
    - we don't have to deal with the notion of uniqueness per session 
(in this case 2 sessions)
    - we don't have the issue to clearly identify the Exporting Process 
on an IPFIX device with an exportingProcessId (in this case 2 exporting 
processes) as the management of this exportingProcessId  is not described.
    - we don't have to describe in IPFIX what the Observation Domain is 
(in this case 2 different line card)
... in order to know that the flow records comes from two different line 
cards.
BTW, the case of "One sysadmin configures line card 1 with observation 
domain 1, while a second sysadmin configures line card 2 with the same 
observation domain Id 1" would not be possible.

Regards, Benoit.

---

From: Andrew Johnson <[email-masked]>
Date: Fri, 16 Jun 2006 15:21:39 +0100

Hi Benoit

I recognise that having the observation domain unique per device is a
useful convention and by all means we can recommend it.

I think below you have highlighted a large problem.  I will deal with
this in a separate mail with a change of subject.  Then the rest of
the mailing list might read it :).

Andrew

>           Collecting Processes SHOULD use the           combination of 
> the Exporter (exporterIPv4Address,           exporterIPv6Address, or 
> exportingProcessId) and the           Observation Domain ID field to 
> separate different export           streams originating from the same 
> Exporting Process.
> 
>    - we don't have to deal with the notion of uniqueness per session (in 
> this case 2 sessions)

---

From: Andrew Johnson <[email-masked]>
Date: Fri, 16 Jun 2006 15:46:52 +0100

> address, how would the collector differentiate the template IDs? 

OK, so let's assume that your two processes are exporting using the
same IP address, however since they are different processes they
will use a different UDP source port.

Let's also consider a second example at the same time.  Imagine
a second exporting process on line card 1.  It will export for the
same observation domain (coincidently or because we have used the
recommendation).  Again, these processes are exporting using the
same source IP address, but different UDP source ports.

> separate different export           streams originating from the same 

OK, so in your example, the two processes have the same IP address and
the same odIds.  The collector can't tell the difference, which is
bad!

Your proposal of odIds which are unique per device solves this issue
by giving your two processes different odIds.  Great, but in my example
the two processes are operating from the same OD.  The collector still
can't differentiate between them.

The problem is that the IP address alone is not sufficient to
differentiate between Exporting Processes.  For that to work we would
have to insist that each Exporting Process in a device MUST export with
a unique IP address.

I think that a collector must also use the source port from the transport
protocol to differentiate between Exporting Processes.

Brian has conveniently highlighted another problem.  SCTP allows a
connection to be maintained across a set of IP addresses.  SCTP will
send the complete set of IP addresses currently in use no matter which
IP address it is using at the moment.  So the collecting process will
have to be a bit cleverer at identifying that the IP address of an
Exporting Process is from the set of IP addresses it could be using.

regards

Andrew

---

From: Paul Aitken <[email-masked]>
Date: Tue, 20 Jun 2006 13:58:33 +0100

Andrew,

> differentiate between Exporting Processes.

Yes, that's definitely a problem.

> I think that a collector must also use the source port from the
> transport protocol to differentiate between Exporting Processes.

That would work. Can you propose some text for the drafts?

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