Re: [IPFIX] review of YANG module ietf-ipfix-psamp <at> 2010-10-25

Gerhard Muenz <muenz <at> net.in.tum.de>
2011-01-02 20:01:53 GMT

Hi Lada,
>>> My main concern is the size of the module. I believe that splitting the
>>> data model into smaller coherent modules makes it more understandable
>>> and manageable - also in terms of the standardisation process. It
>>> seems that the present module could relatively easily be divided into
>>> two modules, one describing the collector subsystem and the other
>>> dealing with the remaining functionality. As a matter of fact, flow
>>> collectors are in most cases implemented in a separate device, so
>>> their configuration won't be mixed with configurations of the other
>>> parts. This change would also remove one level of containment in the
>>> schema, at a very reasonable price of adding one more namespace.
>>
>> With the upcoming IPFIX mediators, we will have devices implementing
>> Collecting Processes, Intermediate Processes, and Exporting Processes.
>> Therefore, I think that keeping the configuration data of all IPFIX
>> processes in one module makes sense.
>
> All functions could be combined anyway, even if they are defined in
> different modules, by advertising all modules that apply in the hello
> message rather than having just one module and using various
> combinations of features. By way of analogy, entire router configuration
> could also be specified in one module and various routing protocols
> selected by means of features - I just don't think this is the right
> approach.
There are groupings which are used in Exporter and Collector
configurations (e.g. TransportSession, TransportLayerSecurity).

[IPFIX] recordings of Beijing IPFIX meeting

Brian Trammell <trammell <at> tik.ee.ethz.ch>
2011-01-05 08:41:47 GMT

Greetings, all,
Does anyone have audio from the IETF79 IPFIX meeting? The files seem to be missing from the archives at
http://79archive.dyndns.org/ietf79/ -- IPFIX was channel 4 on Wednesday morning, but Channel 4
doesn't seem to be available on Wednesday at all.
Best regards,
Brian
_______________________________________________
IPFIX mailing list
IPFIX <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

Benoit,
I agree with Brian: the value zero should be retained.
For two reasons:
1. This isn't actually an IANA EnterpriseNumber. It's actually an IPFIX
ieEnterpriseNumber which builds on the IANA EnterpriseNumber by adding
the extra definition for 0.
2. There should be a way to export "in the IANA registry" without
requiring a new template - which would be necessary if the
ieEnterpriseNumber must be omitted.
Cheers,
P.
> Dear all,
>
> OLD:
> "If omitted or zero, the Information Element is registered in the IANA
> registry of
> IPFIX Information Elements."
>
> NEW:
> "If omitted, the Information Element is registered in the IANA registry of
> IPFIX Information Elements."
>
> What is the problem with the simple solution?
>

Paul,
> Benoit,
>
> I agree with Brian: the value zero should be retained.
>
> For two reasons:
>
> 1. This isn't actually an IANA EnterpriseNumber. It's actually an
> IPFIX ieEnterpriseNumber which builds on the IANA EnterpriseNumber by
> adding the extra definition for 0.
>
> 2. There should be a way to export "in the IANA registry" without
> requiring a new template - which would be necessary if the
> ieEnterpriseNumber must be omitted.
I'm convinced now
Regards, Benoit
>
> Cheers,
> P.
>
>
>
>> Dear all,
>>
>> OLD:
>> "If omitted or zero, the Information Element is registered in the IANA
>> registry of
>> IPFIX Information Elements."
>>

Re: [IPFIX] Shepherd review of draft-ietf-ipfix-flow-selection-tech

Hi Lorenzo:
I haven't seen any response to my earlier emails (copied below).
Did you receive them? Can you please make the changes I've detailed
and publish a new revision sometime soon? I'd like to get the
shepherd document completed so that I can submit this draft to
IESG well before the Prague IETF meeting!
Cheers, Nevil
On 14/12/10 12:48 PM, Nevil Brownlee wrote:
>
> Hi Lorenzo et al:
>
> As part of writing a shepherd document I have to read your draft
> carefully, and check it for ID-nits. I've done that, and I find
> quite a few things that need to be fixed, as follows:
>
> s7, p15: List of new IEs
> 5102 clearly says that IE names start with a lower-case letter.
> Also, none of the existing IEs use an underscore character.
> How about using fsMeterUnmeasPacketCount, as per 5102?
>
> s7, p14
> You say "Some elements have
> been associated with a pair of timestamps, which are referred to as
> Tfirst and Tlast (instead of element_nameTfirst, element_nameTlast).
> Does that mean that you both the TFirst and Tlast timestamps are
> also needed as IEs? Or are they something that will only be used

Re: [IPFIX] Shepherd review of draft-ietf-ipfix-flow-selection-tech

<lorenzo.peluso <at> unina.it>
2011-01-07 14:20:41 GMT

Hi Nevil,
sorry for the very late answer. We are actively working on a new
revision of the draft. We are going to publish the new revision
tomorrow.
Cheers,
Lorenzo.
Quoting Nevil Brownlee <n.brownlee <at> auckland.ac.nz>:
>
> Hi Lorenzo:
>
> I haven't seen any response to my earlier emails (copied below).
> Did you receive them? Can you please make the changes I've detailed
> and publish a new revision sometime soon? I'd like to get the
> shepherd document completed so that I can submit this draft to
> IESG well before the Prague IETF meeting!
>
> Cheers, Nevil
>
>
> On 14/12/10 12:48 PM, Nevil Brownlee wrote:
>>
>> Hi Lorenzo et al:
>>
>> As part of writing a shepherd document I have to read your draft
>> carefully, and check it for ID-nits. I've done that, and I find
>> quite a few things that need to be fixed, as follows:

[IPFIX] one problem on IPFIX

田红成 <tianhc08 <at> mails.tsinghua.edu.cn>
2011-01-07 18:59:55 GMT

Dear Sir/Madam,

I am a Ph.D. student of Professor Jun Bi from Tsinghua
University, Beijing, China. I am very glad to read RFCs on IPFIX ,
from which I have learned much. Thank for your great contribution.I would
like to ask one question about IPFIX.

(1)As we all know, sampling
does not provide a 100% accurate result. If the flow is
defined as five tuples (source address, destination address, protocol number,
source port, destination port), I don't know whether there
exists theoretical analysis or experiment results on the relation
between packet sampling probability and the percentage that flows are
sampled.