Subject: [IPFIX] draft-johnson-ipfix-mib-variable-export-00

From: "Rosomakho, Yaroslav" <[email-masked]>
Date: Mon, 22 Nov 2010 18:46:46 +0000

Hello!

First of all, I would like to note that this is a very important and
useful addition to IPFIX protocol.

There are a few notes, that I would like to make:

1. A very practical usage of SNMP counters is verification of accuracy of
metering and exporting processes. Comparison of flow and SNMP data is a
good way to tune sampling rate and sampling algorithm. I think this could
be highlighted in applicability section or in examples.

2. I think indexing approach should be reworked. If I understand proposed
indexing correctly, it requires that all indexes at the end of OID must
match information elements in flow. Take tcpConnectionTable/Entry
(RFC4022) as an example: there is no information element that would cover
tcpConnectionRemAddressType  so there is no way how we could bind an
information element with tcpConnectionLocalPort.  A solution would be to
have a negative offset for each index. Here is an example of proposed
structure of OID with three indexes with offsets:

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|         MIB OID IE          |         Field Length          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Index Count  |MIB Obj. ID Len|    MIB Object Identifier ...  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              ... MIB Object Identifier continued              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Offset 1              |0| Index Information Element 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Offset 2              |1| Index Information Element 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Enterprise Number                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|         Offset 3              |0| Index Information Element 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Offset = 0 means that a given index is exactly at the end of OID. Offset =
N means that a given IE is at N bytes from the end of the OID.

Best Regards,
Yaroslav

---

From: Andrew Johnson <[email-masked]>
Date: Tue, 23 Nov 2010 17:12:37 +0000

Dear Yaroslav

Thank you for your interest in the draft and your comments.

The Indexes are identified with the extended field specifier,
so can optionally be identified using another OID.  We are
looking to update the draft in the near future make this more
obvious.

In your suggestion below, you're basically proposing to make
the indexes that are identified optional?  The current feeling
is that the indexes must be identified in order to communicate
the full meaning of what is being exported.

You raise some interesting points / questions:

1. Does the value in the index have to be the actual value used
   for the index, or is the semantic what's important?

   e.g. the value used for tcpConnectionRemAddressType can be
   inferred using the ipVersion IE, but the values don't match.

2. The semantic behind both the tcpConnectionRemAddressType and
   tcpConnectionRemAddress can be communicated via the
   sourceIPv6Address IE, however how do you map that to two
   indexes?

3. When your simply associated extra information with a flow,
   you should be able to communicate how the OID was indexed
   using information from the flow, but if we want to export
   management information, then won't we need a way to transmit
   the value of an index?

   i.e., why not simply transmit the tcpConnectionRemAddressType,
   but how do we identify that?

regards

Andrew

On 22 Nov 2010, at 18:46, Rosomakho, Yaroslav wrote:

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

---

From: Benoit Claise <[email-masked]>
Date: Tue, 23 Nov 2010 18:20:53 +0100

Dear Yaroslav,

> looking to update the draft in the near future make this more
Indeed. In the mean time:
Figure K shows an index being an IPFIX IE
Figure L shows an index being an MIB OID

Regards, Benoit.