Gerhard Muenz | 2 Jan 21:01 2011
Picon

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


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).

(Continue reading)

Brian Trammell | 5 Jan 09:41 2011
Picon
Picon

[IPFIX] recordings of Beijing IPFIX meeting

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 Claise | 6 Jan 14:12 2011
Picon

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

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?

Regards, Benoit.
>>> - The description of "ieEnterpriseNumber" leafs says: "If omitted or
>>>     zero, the Information Element is registered in the IANA registry of
>>>     IPFIX Information Elements." Why not define a default value of "0"
>>>     here (perhaps in a special typedef)?
>> I'm not sure whether 0 is a valid enterprise number.
>>
>>
>> In http://www.iana.org/assignments/enterprise-numbers , we have:
>>
>> Decimal
>> | Organization
>> | | Contact
>> | | | Email
>> | | | |
>> 0
>>     Reserved
(Continue reading)

Brian Trammell | 6 Jan 14:27 2011
Picon
Picon

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

Hi, Benoit, all,

PEN zero is taken to be a default value meaning "in the IANA registry" in RFC 5610, section 3.8, and in the
definition of IE 346 privateEnterpriseNumber at
http://www.iana.org/assignments/ipfix/ipfix.xhtml. "Or 0" should be retained to remained consistent.

Best regards,

Brian

On Jan 6, 2011, at 2:12 PM, Benoit Claise wrote:

> 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?
> 
> Regards, Benoit.
>>>> - The description of "ieEnterpriseNumber" leafs says: "If omitted or
>>>>    zero, the Information Element is registered in the IANA registry of
>>>>    IPFIX Information Elements." Why not define a default value of "0"
>>>>    here (perhaps in a special typedef)?
>>> I'm not sure whether 0 is a valid enterprise number.
(Continue reading)

Benoit Claise | 6 Jan 14:45 2011
Picon

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

Hi Brian,

Thanks for the clarification.
So as Lada mentioned, 0 should be the default value.

Regards, Benoit.
> Hi, Benoit, all,
>
> PEN zero is taken to be a default value meaning "in the IANA registry" in RFC 5610, section 3.8, and in the
definition of IE 346 privateEnterpriseNumber at
http://www.iana.org/assignments/ipfix/ipfix.xhtml. "Or 0" should be retained to remained consistent.
>
> Best regards,
>
> Brian
>
>
> On Jan 6, 2011, at 2:12 PM, Benoit Claise wrote:
>
>> 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?
(Continue reading)

Paul Aitken | 6 Jan 17:25 2011
Picon

Re: [IPFIX] [Sender: ipfix-bounces <at> ietf.org] Re: review of YANG module ietf-ipfix-psamp <at> 2010-10-25 - ieEnterpriseNumber

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?
>
(Continue reading)

Benoit Claise | 6 Jan 17:27 2011
Picon

Re: [IPFIX] [Sender: ipfix-bounces <at> ietf.org] Re: review of YANG module ietf-ipfix-psamp <at> 2010-10-25 - ieEnterpriseNumber

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."
>>
(Continue reading)

Nevil Brownlee | 6 Jan 22:31 2011
Picon
Picon

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
(Continue reading)

lorenzo.peluso | 7 Jan 15:20 2011
Picon

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

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:
(Continue reading)

田红成 | 7 Jan 19:59 2011
Picon

[IPFIX] one problem on IPFIX

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.
 
I am looking forward to hearing from you. Thank you very much!
 
 
best ragards
 ------
Hongcheng Tian
Network Architecture Lab, Network Center,Tsinghua University
Mobile:   +86 13370195827
Add:       Room 1227B, Zijing Building 15, Tsinghua University, 100084 Beijing, China
Email:    tianhc08 <at> mails.tsinghua.edu.cn
_______________________________________________
IPFIX mailing list
IPFIX <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

Gmane