Re: [IPFIX] Comments on draft-akhter-opsawg-perfmon-ipfix-02

Hi Jan,

Thank-you for the review. Please find my comments below. We Hendrik and I will be publishing -03 shortly. 

-----Original Message-----
From: Jan Novak (janovak) 
Sent: Tuesday, May 22, 2012 4:58 AM
To: Aamer Akhter (aakhter); [email protected]; [email protected]
Cc: Al Morton; [email protected]
Subject: Comments on draft-akhter-opsawg-perfmon-ipfix-02

Hi Amer,

I have reviewed your draft draft-akhter-opsawg-perfmon-ipfix-02.txt.

There seems to be a lot of text overlap with your methodology document - section 1,3, 4 could probably be abbreviated or omitted leaving the document just with raw IPFIX IE specifications or just add the IE specification as sub-sections or a new section into the first document ?? 

AA> I agree that there is overlap, but it was retained for readability. But I see your point regarding keeping the focus on the IEs in the IPFIX version of the draft.  Will strip some of the detail in the IPFIX version.

Section 2 uses definitions from RFC5610 - I think those you use there are defined in RFC5102 as DataTypeSemantic, units and range while
RFC5610 specifies how this information should be exported - here you are defining the IE itself so you should use the definitions from RFC5102

AA> I think I had used RFC5610 as it seemed to be a bit more specific about it (eg rangeBegin and rangeEnd  rather than just range). But we are fine either way depending on feedback.

Also the methodology documents already speaks in terms of IPFIX IEs while you are trying to specify some performance metrics - the methodology could have names and an exact definitions of the metric and then a reference which IE represents the particular metric

AA> will update the methodology doc with exact definitions and reference the IEs. 

RFC5102 section 2.1 specifies a template for IEs with a MUST so the MUST entries should be literally followed in your IEs spec
- namely name, elementID, description, dataType and status.

RFC5102 section 2.1 specifies MAY entries for the template - like DataTypeSemantic, units, name - might be preferable to follow the naming as well

You interchanged ElementId with name - ElementId should be the numerical ID of the particular IE, while name of the IE is actually missing

AA> Jan, can you look again? I see name (eg. perfPacketExpected) and Element ID (eg. TBDperfPacketExpected). The TBDperfPacketExpected is actually a place holder for the IANA defined value. Is there still a problem?

Instead of using Observation Point - wouldn't be the scope of the element appropriate ?? Or if not then scope should be actually added - are the metrics (like perfPacketLoss) applicable to all the traffic seen by the UUT (or more specifically passing through the Observation
Point) or to just individual flows ?? This should also be part of the particular metric definition.

AA> We're open to adding scope (as defined as which set of packets would this be applicable to). Would you agree that this is more of a methodology item than a IE item?

Will your IEs be enterprise IEs or IANA ones ??

AA> The idea is to ask for IANA allocation.

Section 4.1.2 - Units packets ??

AA> fixed

Section 4.1.3 - there is a mis-match between the definition and the range
- it should be limited to 0 - 100 + a value when the rate is unknown This definition is also missing in section 4.1.3 of your methodology

AA> there is a discussion going on regarding how to represent the unknown. 
AA> For the moment, I'll mark the high end as 0x64 (100d). But there also needs to be agreement on how to represent float16, or we go directly to float32.

Sections 4.3.1, 4.3.2 - the values are just numbers/ids so units shouldn't be octets but "none" ??

AA> agree. Copy-paste errors.

The IPFIX guys here have had few discussions regarding IE definitions explosions with all the needs like this - have you thought using RFC6313 now (structured data) ??

AA> only in the case of the unknown-- which has been purposely left out of this document as there is another doc working on that. Is there a specific set of IEs that would be suited to structured data?

I am not sure I would use RFC2321 as a reference work :-).

AA> someone checked :-)

huic-ipfix-sipfix is not a work in progress - the ID expired 3 years ago.

AA> This was merely to acknowledge prior work. I can take it out if needed.

ie-doctors is a WG doc version 2 now - draft-ietf-ipfix-ie-doctors-02.txt

AA> hopefully the xml tool will resolve this.

pmol-metrics-framework is RFC 6390

AA> removed from ipfix draft, fixed in methodology draft.

The document would benefit from running it through spell checker.

AA> thanks and done :-)

Rgds, Jan

The climate of Edinburgh is such that the weak succumb young .... 
and the strong envy them.
                                 Dr. Johnson

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