Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mib-04

From: "Thomas Dietz" <[email-masked]>
Date: Fri, 31 Oct 2008 13:58:21 +0100

Dear Gerhard,

sorry for the late reply. See my comments inline...

-- 
Thomas Dietz                 E-mail: [email-masked]
NEC Europe Ltd.              Phone:  +49 6221 4342-128
NEC Laboratories Europe      Fax:    +49 6221 4342-155
Network Research Division
Kurfuersten-Anlage 36
69115 Heidelberg, Germany    http://www.nw.neclab.eu

NEC Europe Limited           Registered in England 2832014
Registered Office: NEC House, 1 Victoria Road, London W3 6BL

> -----Original Message-----
> From: ipfix-bouncesFrom [email-masked]  Fri Oct 31 05:59:06 2008
Content-class: urn:content-classes:message
Date: Fri, 31 Oct 2008 13:58:21 +0100
From: "Thomas Dietz" <[email-masked]>
To: "Gerhard Muenz" <[email-masked]>,
	<[email-masked]>
Cc: Nevil Brownlee <[email-masked]>,
	Juergen Quittek <[email-masked]>
Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mib-04
Sender: [email-masked]

This is a multipart message in MIME format.
Dear Gerhard,

sorry for the late reply. See my comments inline...

-- 
Thomas Dietz                 E-mail: [email-masked]
NEC Europe Ltd.              Phone:  +49 6221 4342-128
NEC Laboratories Europe      Fax:    +49 6221 4342-155
Network Research Division
Kurfuersten-Anlage 36
69115 Heidelberg, Germany    http://www.nw.neclab.eu

NEC Europe Limited           Registered in England 2832014
Registered Office: NEC House, 1 Victoria Road, London W3 6BL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Gerhard Muenz
> Sent: Freitag, 29. August 2008 11:28
> To: [email-masked]
> Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mib-04
> 
> 
> Dear all,
> 
> Please find comments on draft-ietf-ipfix-mib-04 below.
> 
> Currently, we have ipfixTransportSessionTable which does not provide
> any
> information about the role of the given device within the transport
> session. We do not know if the device is exporter or collector.
> 
> On the other hand, you define "directional" tables for the Templates:
> ipfixExportedTemplateTable
> ipfixExportedTemplateDefinitionTable
> ipfixCollectedTemplateTable
> ipfixCollectedTemplateDefinitionTable
> 
> Is there any specific reason?
> 

Yes there is... see below

> There are two alternatives which require fewer tables:
> 1) One could add an entry about the role of the device to the
> ipfixTransportSessionTable, for example in form of a field with values
> "exporter" and "collector". As the Templates are scoped to a given
> Transport Session, it is clear which Templates are exported and which
> Templates are collected. So we would have only three tables instead of
> five:
> ipfixTransportSessionTable
> ipfixTemplateTable
> ipfixTemplateDefinitionTable
> 

That the way we had it before, more or less. The problem is that a device
potentially can be a collector and an exporter at the same time. We could
collect a template with a Observation domain x and a template id y which is
not necessarily the same as the template with observation domain x and
template id y that we export. The template Ids are only unique at the
exporting device. The same is true for the observation domain ids. So having
one table for the templates (ipfixTemplateTable) und in consequence for the
template definitions (ipfixTemplateDefinitionTable) does not work.

> 2) Or, one could split the ipfixTransportSessionTable into:
> - ipfixOutgoingTransportSessionTable for Transport Sessions where the
> given device is exporter.
> - ipfixIncomingTransportSessionTable for Transport Sessions where the
> given device is collector.
> Again, we only need two tables for the Templates:
> ipfixTemplateTable
> ipfixTemplateDefinitionTable
> 

We could split the transport session table into 2 but for the reason
explained above we still cannot collapse the template and template
definition table into one. But I don't see the point why to split the
transport session table without gaining anything.

> Reducing the number of tables is certainly not a design goal for MIBs.
> However, I think that it is more logical to have the information of the
> device role (exporter and collector) together with the data about the
> Transport Session.
> 
> > 5.3.  The Template Tables
> >
> >    There are two Template tables, the Exported Template
> >    (ipfixExportedTemplateTable) table and the Collected Template
> table
> >    (ipfixCollectedTemplateTable).  Those Template tables list all
> >    Templates (including Option Templates) that are sent (by an
> Exporter)
> >    or received (by a Collector).  The (Option) Templates are unique
> per
> >    Transport Session and Observation Domain, thus the table is
> indexed
> >    by the Transport Session Index (ipfixTransportSessionIndex) and
> the
> >    Observation Domain Id (ipfixExportedObservationDomainId or
> >    ipfixCollectedObservationDomainId).  It contains the Set Id and an
> 
> I propose to list the indices in a clearer way one below the other:
> 
>     The (Option) Templates are unique per
>     Transport Session and Observation Domain, thus the table is indexed
>     by the following indices:
>     - Transport Session Index (ipfixTransportSessionIndex)
>     - Observation Domain Id (ipfixExportedObservationDomainId or
>       ipfixCollectedObservationDomainId).
> 
> With two indices, explaining them in the text may still be ok. But you
> have much longer lists of indices for the other Tables.
> 

I will try to do that where applicable.

> >    Access Time denoting the time when the (Option) Template was last
> >    sent or received.
> >
> >    To resume the above example the Exporter may want to export the a
> 
> remove "the" or "a"
> 
> >    Template and an Option Template for each Transport Session defined
> >    above.  This leads to the following Template Table defining
> Template
> >    and Option Template:
> >
> >     ipfixExportedTemplateTable (3)
> >     |
> >     +- ipfixExportedTemplateEntry (1)
> >        |
> >        +- index (5)
> >        |  +- index (3)
> >        |     + index (257)
> 
> It is difficult to deduce the meaning of the indices. Maybe add in
> brackets which index refers to what:
> 
>         +- index (5) (ipfixTransportSessionIndex)
>         |  +- index (3) (ipfixExportedObservationDomainId)
>         |     + index (257) (ipfixExportedTemplateId)
> 
> 

Good idea, I will add this.

> >        |     | +- ipfixExportedObservationDomainId (1) = 3
> >        |     | +- ipfixExportedTemplateId (2) = 257
> >        |     | +- ipfixExportedTemplateSetId (3) = 2
> >        |     | +- ipfixExportedTemplateAccessTime (4)
> >        |     |                             = 2008-7-1,12:49:11.2,+2:0
> >        |     |
> >        |     + index (264)
> >        |       +- ipfixExportedObservationDomainId (1) = 3
> >        |       +- ipfixExportedTemplateId (2) = 264
> >        |       +- ipfixExportedTemplateSetId (3) = 3
> >        |       +- ipfixExportedTemplateAccessTime (4)
> >        .                                   = 2008-7-1,12:47:04.8,+2:0
> >        .
> >        .
> >        .
> >        +- index (11)
> >           +- index (3)
> >              + index (273)
> >              | +- ipfixExportedObservationDomainId (1) = 3
> >              | +- ipfixExportedTemplateId (2) = 273
> >              | +- ipfixExportedTemplateSetId (3) = 2
> >              | +- ipfixExportedTemplateAccessTime (4)
> >              |                             = 2008-7-1,12:49:11.2,+2:0
> >              |
> >              + index (289)
> >                +- ipfixExportedObservationDomainId (1) = 3
> >                +- ipfixExportedTemplateId (2) = 289
> >                +- ipfixExportedTemplateSetId (3) = 3
> >                +- ipfixExportedTemplateAccessTime (4)
> >                                            = 2008-7-1,12:47:04.8,+2:0
> >
> >    We assume that the Collector with index 5 in the Transport Session
> >    table of the Exporter has stored the connection to the Exporter
> with
> >    the Transport Session index of 17 then its Template table would
> look
> >    as follows:
> 
> The sentence is confusing. The Transport Session tables does not
> contain
> any entry called Collector, only
> ipfixTransportSessionDestinationAddress
> and ipfixTransportSessionDestinationPort.
> 
> Maybe:
> We assume that the Transport Session that is stored with index 5 in the
> Transport Session table of the Exporter is stored with index 17 in the
> Transport Session table of the (corresponding) Collector. Then, the
> Template table would look as follows:
> 

Good point again here.

> 
> > 5.4.  The Template Definition Tables
> >
> >    As with the Template tables there are two Template Definition
> tables,
> >    the Exported Template Definition table
> >    (ipfixExportedTemplateDefinitionTable) and the Collected Template
> >    Definition table (ipfixCollectedTemplateDefinitionTable).  Those
> >    tables list all the Information Elements contained in a Template
> or
> >    Option Template.  Therefore it has the same indexes as the
> >    corresponding Template table plus the Template Id.  Its own index
> >    denotes the order of the Information Element inside the Template
> if
> >    necessary.  Besides the Information Element Id and the length of
> the
> >    encoded value the table contains flags for each Information
> Element.
> >    The flags indicate if the Information Element is used for scoping
> or
> >    as a Flow key.
> 
> What about enterprise-specific IEs? Don't we need an enterprise number
> entry?
> 

Wow, you are right! Nobody noticed that before. It's a quick fix that I'll
do.

> > 5.5.  The Export Table
> >
> >    On Exporters, the Export table (ipfixExportTable) can be used to
> >    support features like failover, load-balancing, duplicate export
> to
> >    several Collectors etc.  The table has 5 indexes that link an
> entry
> >    with the Metering Process table (ipfixMeteringProcessCacheId, see
> >    below), the Exported Template table
> (ipfixExportedObservationDomainId
> >    and ipfixExportedTemplateId) and the Transport Session table
> >    (ipfixTransportSessionIndex).  Those entries with the same
> 
> Is there a reason for not ordering the indexes as they appear in the
> MIB?
> 

No, but I shifted the forward and backward but it seems that I forgot to
correct it in the text.

> >    ipfixExportIndex, the same ipfixMeteringProcessCacheId and the
> same
> >    ipfixExportedObservationDomainId define a Transport Session group.
> >    This also The member type for each group member describes its
> 
> remove "This also"
> 
> >    functionality.
> 
> Why is a Transport Session group restricted to the output of a single
> cache?

Because that's what a transport session group is for. Export from a single
cache to different destinations in different configurations.
Primary/Secondary for failover, in Parallel, ...

> 
> >    If the Exporter does not use Transport Session grouping then each
> >    ipfixExportIndex contains a single ipfixMeteringProcessCacheId and
> 
> ipfixTransportSessionIndex?

I can add that, but Transport Session implies ipfixTransportSessionIndex

> 
> >    thus a singe Transport Session and this session MUST have the
> member
> 
> single
> 
> >    type primary(1).
> 
> >    To continue the example we assume that the Exporter uses the 2
> 
> two
> 
> >    connections shown in the examples above as the primary export for
> a
> >    session protected by a secondary backup connection.  The Exporter
> >    then has the following entries in the ipfixExportTable:
> >
> >     ipfixExportTable (3)
> >     |
> >     +- ipfixExportEntry (1)
> >        |
> >        +- index (7)
> >        |  +- index (9)
> >        |     +- index (3)
> >        |        +- index (257)
> >        |        |  +- index (5)
> >        |        |     +- ipfixExportIndex (1) = 7
> >        |        |     +- ipfixExportMemberType (2) = 1 (primary)
> >        |        |
> >        |        +- index (273)
> >        |           +- index (11)
> >        |              +- ipfixExportIndex (1) = 7
> >        |              +- ipfixExportMemberType (2) = 2 (secondary)
> >        |
> >        +- index (8)
> >           +- index (9)
> >              +- index (3)
> >                 +- index (264)
> >                 |  +- index (5)
> >                 |     +- ipfixExportIndex (1) = 8
> >                 |     +- ipfixExportMemberType (2) = 2 (secondary)
> >                 +- index (289)
> >                    +- index (11)
> >                       +- ipfixExportIndex (1) = 7
> 
> 8?
> 
> >                       +- ipfixExportMemberType (2) = 1 (primary)
> 
> Can you explain this example?
> 
> There are two Metering Processes? And the output is sent to different
> primary collectors? And in case of a failure, each collector serves as
> backup for the other?

Absolutely right. So what do I need to explain??? Sure that configuration
may not be really useful but you have the possibility to do it.

> 
> > 5.6.  The Metering Process Table
> >
> >    The Metering Process as defined in [RFC5101] consists of a set of
> >    function.  Maintaining the Flow Records is one of them.  This
> >    function is responsible for passing the Flow Records to the
> Exporting
> >    Process but also for detecting Flow expiration.  The Flow Records
> 
> "but also" => "and also"
> 
> >    that are maintained by the Metering Process can be grouped by the
> >    Observation Points they are observed.  The instance that maintains
> >    such a group of Flow Records is a kind of cache.  For this reason
> the
> >    Metering Process table (ipfixMeteringProcessTable) is grouped by
> >    cache IDs (ipfixMeteringProcessCacheId).  Each cache can be
> >    maintained by a separate instance of the Metering Process which is
> >    represented by the Metering Process ID (ipfixMeteringProcessId).
> To
> >    specify the Observation Point(s) where the Flow Records are
> gathered
> >    the ipfixObservationPointGroupReference may contain the an
> 
> "the" or "an"?
> 
> >    ipfixObservationPointGroupId from the Observation Point table
> >    (ipfixObservationPointTable) described in the next section.  If an
> >    Observation Point cannot be given the
> 
> What do you mean by "cannot be given"?

If you think of a concentrator that merges things you may not be able to
specify a observation domain. Then you cannot tell the observation point is
this or that.

Regards,

Thomas

> 
> >    ipfixObservationPointGroupReference MUST be zero(0).  The timeouts
> >    (ipfixMeteringProcessCacheActiveTimeout and
> >    ipfixMeteringProcessCacheInactiveTimeout) specify when Flow
> Records
> >    are passed to the Exporting Process.
> >
> >     ipfixMeteringProcessTable(8)
> >     |
> >     +- ipfixMeteringProcessEntry(1)
> >        |
> >        +- index(9)
> >           +- ipfixMeteringProcessCacheId(1) = 9
> >           +- ipfixMeteringProcessId(2) = 287
> >           +- ipfixObservationPointGroupReference(3) = 17
> >           +- ipfixMeteringProcessCacheActiveTimeout(4) = 100
> >           +- ipfixMeteringProcessCacheInactiveTimeout(5) = 100
> 
> Regards,
> Gerhard
> 
> --
> Dipl.-Ing. Gerhard Münz
> Computer Networks and Internet
> Wilhelm Schickard Institute for Computer Science
> University of Tuebingen
> Sand 13 (Room B309), D-72076 Tuebingen, Germany
> Phone:  +49 7071 29-70534       Fax: +49 7071 29-5220
> E-mail: [email-masked]
> WWW:    http://net.informatik.uni-tuebingen.de/~muenz

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

---

From: Gerhard Muenz <[email-masked]>
Date: Fri, 31 Oct 2008 18:00:03 +0100

Thomas,

> That the way we had it before, more or less. 

No, it is not the same as you had before. In the previous version, the
entries in the Transport Session table did not include any information
about at which endpoint of the Transport Session the device is located.
That's why it could not work.

I propose to add a column to the Transport Session table that says
"collector endpoint" or "exporter endpoint".

> The problem is that a device

There should not be a problem with the additional column I propose
because the Transport Session entry provides the necessary separation
between "exporter" and "collector".

The ipfixTemplateTable has the following indexes:

           ipfixTransportSessionIndex,
           ipfixObservationDomainId

and the ipfixTemplateDefinitionTable has:

           ipfixTransportSessionIndex,
           ipfixObservationDomainId,
           ipfixTemplateId

In both tables, ipfixTransportSessionIndex is index. So, as far as I
understand, this means that there is no problem to use identical values
for ODID and the same Template ID for different Transport Sessions.

And there is another disadvantage with your proposal:
It is not possible to know from the Transport Session table if the
device is Exporter or Collector for a given Transport Session.
You must first search the ipfixExportedTemplateTable and the
ipfixCollectedTemplateTable to know that.
If there are no Templates received or exported at all, you will never
know. In this case, the only solution is too match the IP addresses of
the Transport Session table with known IP addresses of the device. I do
not think that this is a good solution.

With the proposed column, you get the information directly.

> transport session table without gaining anything.

You are right that this does not work. The reason is that we would need
different sets of indexes for incoming and outgoing Templates in the
ipfixTemplateTable:
- ipfixIncomingTransportSessionIndex and ipfixObservationDomainId for
incoming, and
- ipfixOutgoingTransportSessionIndex and ipfixObservationDomainId for
outgoing.

> Primary/Secondary for failover, in Parallel, ...

Ok.

When I asked the question, I thought that there was a one-to-one mapping
between an entry in the Export table and an Exporting Process. But this
is not the case.

> Absolutely right. So what do I need to explain??? 

You need to explain what I had to guess from the context because it was
not clear.

In the example appear ipfixMeteringProcessCacheId values and nobody
knows where From [email-masked]  Fri Oct 31 10:01:14 2008
Date: Fri, 31 Oct 2008 18:00:03 +0100
From: Gerhard Muenz <[email-masked]>
To: Thomas Dietz <[email-masked]>
Cc: [email-masked]
Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mib-04
Sender: [email-masked]

Thomas,

>> ipfixTemplateDefinitionTable
they come from. I had to guess that there are two Metering
Processes. This should be explained somewhere.

> specify a observation domain. Then you cannot tell the observation point is

"cannot be given" leaves open why the Observation Point cannot be
identified, and I wondered what the reasons could be.

If you think of information that is not available, then consider:
"If the Observations Points are unknown, the
ipfixObservationPointGroupReference MUST be zero(0)."
or
"If the Observations Points are unspecified, the
ipfixObservationPointGroupReference MUST be zero(0)."

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

> That the way we had it before, more or less. 

No, it is not the same as you had before. In the previous version, the
entries in the Transport Session table did not include any information
about at which endpoint of the Transport Session the device is located.
That's why it could not work.

I propose to add a column to the Transport Session table that says
"collector endpoint" or "exporter endpoint".

> The problem is that a device

There should not be a problem with the additional column I propose
because the Transport Session entry provides the necessary separation
between "exporter" and "collector".

The ipfixTemplateTable has the following indexes:

           ipfixTransportSessionIndex,
           ipfixObservationDomainId

and the ipfixTemplateDefinitionTable has:

           ipfixTransportSessionIndex,
           ipfixObservationDomainId,
           ipfixTemplateId

In both tables, ipfixTransportSessionIndex is index. So, as far as I
understand, this means that there is no problem to use identical values
for ODID and the same Template ID for different Transport Sessions.

And there is another disadvantage with your proposal:
It is not possible to know from the Transport Session table if the
device is Exporter or Collector for a given Transport Session.
You must first search the ipfixExportedTemplateTable and the
ipfixCollectedTemplateTable to know that.
If there are no Templates received or exported at all, you will never
know. In this case, the only solution is too match the IP addresses of
the Transport Session table with known IP addresses of the device. I do
not think that this is a good solution.

With the proposed column, you get the information directly.

> transport session table without gaining anything.

You are right that this does not work. The reason is that we would need
different sets of indexes for incoming and outgoing Templates in the
ipfixTemplateTable:
- ipfixIncomingTransportSessionIndex and ipfixObservationDomainId for
incoming, and
- ipfixOutgoingTransportSessionIndex and ipfixObservationDomainId for
outgoing.

> Primary/Secondary for failover, in Parallel, ...

Ok.

When I asked the question, I thought that there was a one-to-one mapping
between an entry in the Export table and an Exporting Process. But this
is not the case.

> Absolutely right. So what do I need to explain??? 

You need to explain what I had to guess from the context because it was
not clear.

In the example appear ipfixMeteringProcessCacheId values and nobody
knows where they come from. I had to guess that there are two Metering
Processes. This should be explained somewhere.

> specify a observation domain. Then you cannot tell the observation point is

"cannot be given" leaves open why the Observation Point cannot be
identified, and I wondered what the reasons could be.

If you think of information that is not available, then consider:
"If the Observations Points are unknown, the
ipfixObservationPointGroupReference MUST be zero(0)."
or
"If the Observations Points are unspecified, the
ipfixObservationPointGroupReference MUST be zero(0)."

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