Subject: RE: [ipfix-req] Remote sampling and middle boxes

From: Ganesh Sadasivan <[email-masked]>
Date: Tue, 12 Feb 2002 17:21:14 -0800

Hi  Peter,
 See inline.

> 1. sFlow <http://www.sflow.org> sends packet samples to a remote
collector
> for aggregation. IPFIX would be a good way of exporting data from the
> aggregator. sFlow is supported across the Foundry Networks product
line.

Agreed. But the current discussions focuses only on the export between
primary exporter (which is tightly coupled with observation domain and
its associated observation points) and the collector (or in your case
the
aggregator). From aggregator one may adopt same IPFIX protocol to
send the records to secondary aggregator. But this is not currently
in scope.
The actions to get the packet samples also comes under metering.
Another point is that packet samples are out-of-scope for this WG.
I had raised this same issue a while ago and this is the reply I got.
Don't know if this plan has changed.

> 2. The PSAMP http://www.research.att.com/~duffield/psamp/ group are
> proposing to remotely export packet sampling. Again a remote
aggregator of
> PSAMP data might want to export aggregates using IPFIX.
> 3. Juniper sampled mirroring can remotely forward samples.
>
> I assume that in each of these cases the IPFIX exporter is acting as a

> "middle box."

I am  not sure I agree with this.

>
> Another situation would be a middle box that bridges netflow, LFAP or
any
> other existing flow record into IPFIX flow records.

I thought the plan was to come with a single export protocol that
everyone
conforms to.
Thanks
Ganesh

>
> Finally, a middle box aggregating IPFIX data from multiple IPFIX
sources may
> want to re-export aggregates (possibly removing duplicate flows).
>
> I was looking through the drafts and it wasn't apparent to me how a
middle
> box would export flows on behalf of other devices (indicating the true

> source of the data, and the scope of aggregation).
>
> Presumably one would need to add an entry in 5.1 in the Data Model:
>
> 5.1.x MEASUREMENT ORIGIN
> The IP address associated with the original measurement point. This
may be
> the same address as the exporter, or it may refer to a remote device
that
> provided the data. If flows are aggregated across multiple sources
this
> could be a list of origins. (FLOWS and FLOW_LABEL are scoped to each
> MEASUREMENT ORIGIN.
>
> A corresponding adjustement to the Architecture document would also be

> required, perhaps showing that collectors can also export IPFIX.
>
> Peter
> ----------------------
> Peter Phaal
> InMon Corp.

--
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: "Peter Phaal" <[email-masked]>
Date: Tue, 12 Feb 2002 17:25:03 -0800

> I thought the plan was to come with a single export protocol that

Even if everyone adopted IPFIX, there would still be legacy equipment
exporting flows in other formats. It would be nice to simply bridge them
into IPFIX, rather than have every application support every flow export
format.

Peter
----------------------
Peter Phaal
InMon Corp.

[email-masked]