Subject: [IPFIX] Common structure for IPFIX-MIB + IPFIX-CONFIG

From: Gerhard Muenz <[email-masked]>
Date: Wed, 17 Jun 2009 15:40:16 +0200

Benoit, Thomas, Paul, Andrew, Atsushi,

I've been thinking a little bit more about the way how OPs, SPs, Caches,
and EPs are linked together in the MIB and in the config model.

At the moment, the config model enables configurations in which a Cache
maintains records generated of packets observed at different
Observation Domains and/or selected by different Selection Processes.

Example:

OP1 -> SP1 -+
            +-> Cache -> EP
OP2 -> SP2 -+

However, packets of different OD or from different SPs MUST NOT be
accounted in the same record. Consequently, the Cache must implicitly
treat ODID and Selection Sequence ID as additional flow keys.

Is this acceptable?

Or should we inhibit such configurations and ensure by specification of
the config model that all packets entering a Cache come from the same OD
and have passed the identical Selection Processes?

If the answer to the second question is yes, we can change the model as
follows:

Instead of specifying where the output of an OP, SP, Cache goes,...

OP -> SP -> Cache -> EP

...we specify where the input comes from:

OP <- SP <- Cache <- EP

This means that we invert the direction of the references.

We can specify that SPs and Caches have a maximum of one input. This
ensures that packets entering the Cache come from a single SP, and
packets entering this SP come from a single OP.

Instead of OP, we can adopt ObservationPointGroup (as used in the MIB)
to specify a group of OPs belonging to the same OD.

Only for the EP, we allow multiple inputs from different Caches.

Hence, configurations like this are possible:

               +- Cache1 <-+
      +- SP1 <-+           |
OPG <-+        +- Cache2 <-+- EP
      |                    |
      +- SP2 <--- Cache3 <-+

The disadvantage is that the linkage is done in the reverse direction of
the actual "data flow".
The advantage is that we can quite easily realize the same linkage in
the MIB using indexes. The changes in the MIB would be relatively small.

If we decided to go this way, it should be done quickly such that we can
adapt the indexing in the MIB.

Regards,
Gerhard

-- 
Dipl.-Ing. Gerhard Münz
Chair for Network Architectures and Services (I8)
Department of Informatics
Technische Universität München
Boltzmannstr. 3, 85748 Garching bei München, Germany
Phone:  +49 89 289-18008       Fax: +49 89 289-18033
E-mail: [email-masked]    WWW: http://www.net.in.tum.de/~muenz

---

From: Andrew Johnson <[email-masked]>
Date: Wed, 17 Jun 2009 14:53:36 +0100

Hi Gerhard

The definition of an Observation Domain is:
   An Observation Domain is the largest set of Observation Points for
   which Flow information can be aggregated by a Metering Process.

By it's very definition a cache cannot monitor packets from different
Observation Domains and configuring it should be impossible, not
because of a limit of the configuration model, but because all
Observation Points available to a cache are defined to be part of the
same Observation Domain.

Cheers

Andrew

---

From: Gerhard Muenz <[email-masked]>
Date: Thu, 18 Jun 2009 09:38:21 +0200

Hi Andrew, all,

> Observation Points available to a cache are defined to be part of the

Thanks for pointing this out.

We define a Cache as part of one Monitoring Process. With the definition
of the Observation Domain, this excludes that packets of several ODs
enter the same Cache. I do not see any need to change this.

Currently, there is no such restriction for Selection Sequences.
Am I right that PSAMP Selection Sequence Report Interpretation,
Selection Sequence Statistics Report, etc. are to be used regardless of
whether Packet Reports or Flow Records are generated by the Metering
Process?
If yes, packets that have been selected by different Selection Sequences
must not be aggregated in the same Flow Records.

The changes I proposed enforce that the input of a Cache is restricted
to packets originating from one OD and selected by one Selection Sequence.

It is not possible (or would at least be very complicated) to achieve
the same restriction with the current config model using the YANG
formalism. We could only specify this in description clauses.

With the proposed changes, invalid configurations are not possible by
specification of the config model. (of course, the YANG module can be
augmented if somebody really wants to do strange things)

I would appreciate some more feedback on this.

Regards,
Gerhard

---

From: Andrew Johnson <[email-masked]>
Date: Thu, 18 Jun 2009 09:10:53 +0100

Hi Gerhard

> whether Packet Reports or Flow Records are generated by the Metering

They could be sent if the user wished them to be.  I guess it would be
a configurable option.

> must not be aggregated in the same Flow Records.

I don't see why not.  If the user configured it so then they wouldn't 
gain the same benefit from the Selection Sequence Statistics, but that 
doesn't mean that they don't have a valid configuration.

> to packets originating from one OD and selected by one Selection Sequence.

Surely you don't mean that.  The cache should accept the input from as 
many Selection Sequences as the user wants.  I can imagine why you thing 
forcing the SSID to be a key would be a good idea, but surely you don't 
mean you need a different cache for every Selection Sequence?

Cheers

Andrew

---

From: Gerhard Muenz <[email-masked]>
Date: Thu, 18 Jun 2009 10:25:16 +0200

Hi Andrew,

> They could be sent if the user wished them to be.  I guess it would be

Yes, it is a configurable option.

> doesn't mean that they don't have a valid configuration.

The reason is that counter values of mixed Flow Records are difficult to
interpret.

> mean you need a different cache for every Selection Sequence?

Actually, this was the plan to ensure that the counter values of the
Flow Records can be interpreted correctly.

If consensus is that we do not want to ensure this, then we only have to
differentiate packets and caches with respect to the ODID.

Gerhard