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

From: "Thomas Dietz" <[email-masked]>
Date: Mon, 3 Nov 2008 16:16:32 +0100

Dear Gerhard,

Looks like I am editing this draft for such a long time that I don't see the
obvious. You are absolutely right when you say we can join these two tables.
I tried to address all your remaining issues and will submit a new version
in a few minutes.

Best Regards,

Thomas

-- 
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: Gerhard Muenz [mailto:[email-masked]]
> Sent: Freitag, 31. Oktober 2008 18:00
> To: Thomas Dietz
> Cc: [email-masked]
> Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mib-04
> 
> 
> Thomas,
> 
> Thomas Dietz wrote:
> > sorry for the late reply. See my comments inline...
> 
> >> 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.
> 
> 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
> > 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.
> 
> 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.
> 
> >> 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.
> 
> 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.
> 
> >> 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, ...
> 
> 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.
> 
> >> 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???
> 
> 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.
> 
> >>>    (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.
> 
> "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

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

---

From: "Thomas Dietz" <[email-masked]>
Date: Mon, 3 Nov 2008 16:16:32 +0100

Dear Gerhard,

Best Regards,

Thomas