Subject: Re: [ipfix] IPFIX Requirement presentation

From: Simon Leinen <[email-masked]>
Date: 06 Jan 2002 13:56:25 +0100

>>>>> "gs" == Ganesh Sadasivan <[email-masked]> writes:
>    I want to bring up this point which I had raised on the
>    requirement spec. at the WG meeting.
>    It is from slide 5 on requirements where the flow definition has
>    been changed to include "incoming or outgoing interface" as a
>    MUST.

The corresponding part of the requirements draft
(ietf-ipfix-requirements-00) reads:

  3.1. Interfaces
  
     The measuring device MUST be able to separate flows by the incoming
     interface or by the outgoing interface or by both of them.

Note that this says "MUST be able to separate", not "MUST separate".
Therefore I think your reasoning below doesn't apply:

>    There are cases like a SP is interested in getting all the
>    packest that go between 2 ASs. This does not have any strict
>    relevance to interface. An AS can be sourced by Multiple
>    interfaces in a router. Similar would be case if somebody
>    considers to define a flow based on other packet fields like
>    src/dst IP etc. In the general scheme of flow defintion ,I do not
>    see why there should be a restriction to include the interfaces
>    as a MUST. Claiming this as "most of the apps need the interfaces
>    today" is not a valid argument as this model is used to serve for
>    future apps. too.  Therefore I request the WG to consider
>    removing this restriction.

It is probably the case for *every* flow attribute that one can always
come up with a sensible application that doesn't care about it.  So it
makes looks reasonable to make all flow attributes optional, in the
sense that when an application isn't interested in them, the exporter
doesn't have to send them in order to avoid waste of resources.  This
could be a requirement for the Flow Information Export protocol.

But it also makes sense to make the *ability* of reporting certain
attributes mandatory, so that applications can rely on them being
available from all IPFIX compliant exporters.

Personally I find the input and output interface sufficiently
important to make their support mandatory.  In particular the input
interface is essential when one wants to do analysis of large-scale
routing asymmetries.  Input and output interfaces are also extremely
useful when one collects flows at different points in the networks and
wants to avoid counting the same flows twice.  And the input interface
cannot be derived from the source address and routing information, as
can/must be done with e.g. the "source netmask", "upstream AS" or
"source AS".

Regards,
-- 
Simon Leinen				       [email-masked]
SWITCH				   http://www.switch.ch/misc/leinen/

	       Computers hate being anthropomorphized.

--
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: "K.C. Norseth" <[email-masked]>
Date: Mon, 7 Jan 2002 22:30:57 -0700

In the case of an etxternal probe where there is only one interface and the
probe is hooked to a mirrored port or bridge, the place where the probe is
connected, ther is no incomoing or outgoing interface. What would the
interface be that would satisfy MUST?

K.C.

---

From: Ganesh Sadasivan <[email-masked]>
Date: Tue, 08 Jan 2002 12:48:09 -0800

What appears to be more appropriate to me here is to associate flows with
an observation point rather than with an interface. The observation point
could be one of a full system, a set of interfaces, a logical interface or even

a sub-interface depending on how granular the measuring device can get upto.
Ganesh

---

From: Benoit Claise <[email-masked]>
Date: Sat, 12 Jan 2002 00:23:45 +0100

K.C.

> interface be that would satisfy MUST?

In that case, you separate the flows automatically per interface, as there is
only one interface.
So I should say that you are automatically compliant with the following
paragraph:
3.1. Interfaces
   The measuring device MUST be able to separate flows by the incoming
   interface or by the outgoing interface or by both of them.

Now, whether you report the interface or not is something else. We agree it
doesn't make sense here to export the value!
In both cases (reporting or not the interface), you are compliant with the
following paragraph, as long as your IPFIX implementation on the probe allows you
to report the interface:
5.1. Information Model
   The information model for a flow measurement report is the list of
   attributes of a flow to be contained in the report (including the
   semantics of the attributes).
   This section lists attributes a measuring device MUST or MAY be able
   to report. This does not imply that a report MUST contain all
   REQUIRED attributes, but that it MUST be possible to configure the
   device in a way that all of the REQUIRED attributes are contained in
   a report for each measured flow.
    ...
  The measuring device MUST be able to report the following attributes
   for each measured flow:
    ...
     18. unique identifier of the observation point
    ...

Regards, Benoit