Subject: Re: [IPFIX] Review: draft-ietf-ipfix-structured-data-02.txt

From: Benoit Claise <[email-masked]>
Date: Wed, 06 Oct 2010 09:35:18 +0200

Brian,

Thanks for your review. Reply in line.
> Hi, all,
>
> Here are the high points of my review of structured-data -03. Apologies for the short lead-time before today's meeting; I'll make the most important points at the mike today.
>
> Short, short version, I think we're getting there, but the specification still needs work.
>
> On Jul 27, 2010, at 10:31 AM, Gerhard Muenz wrote:
>
>> Dear Benoit, all,
>>
>> Here is my review of draft-ietf-ipfix-structured-data-02. It mainly
>> consists of suggestions and comments regarding the comprehensibility and
>> language.
>>
>> There is one suggestion about the specification itself. I think that it
>> would be easier to understand if the meaning of the semantic of
>> subTemplateList and subTemplateMultiList would be the same, namely that
>> it specifies the semantic among the Data Records. At the moment, the
>> draft specifies (although not very clearly) that the semantic refers to
>> goups of Data Records associated to different Templates in the case of
>> the subTemplateMultiList. I do not see a use-case for this. Also, no
>> useful example is provided. On the contrary, it is always said that the
>> semantic of subTemplateMultiList is not sufficient.
> Agreed with Gerhard on this point, and this would be the most important comment in my own review. Semantics, as I understand them, bind to the set of _values_ within a list structure. The value in a subTemplateMultiList are the records (each of which, indeed, may be associated with a different Template). Binding semantics to templates breaks this clean design. Section 5.6 almost seems like a paean to why SubTemplateMultiList sucks, which if you're applying semantics at the template level, not the record level, it seems to.
>
> I see the primary use of subTemplateMultiList as semantically identical to subTemplateList, allowing the usage of different templates representing semantically similar but situationally different data (e.g., mixing v4 and v6 flows) within the same List. Here, Templates are (as in IPFIX itself) an encoding mechanism, not a semantic one.
>
> Given this confusion, I've not reviewed the rest of the subTemplateMultiList-relevant content. I would strongly suggest a statement up front of the universality of semantics - applying to list values in all cases - and a statement up front that subTemplateMultiList is a convenience for allowing different encoding of semantically similar information.
We've been addressing this comment based on our post IPFIX meeting with 
Brian, Gerhard, Paul, Benoit. A separate email will be sent.
> Second comment: the document is in places somewhat implementation-specific, but presents these implementation specific things as essential parts of the problem. The most glaring of these is the recommendation to use three-byte encoding for all varlen fields (Section 5.1, Page 26). It might be useful to note that certain lazy-evaluating exporters might do this, so that collectors won't assume they'll never see such inefficient things FF 00 01 as a length (i.e., a three byte encoding of "1") -- but if they're 5101-compliant, this won't cause any problems. :)
We think the length of structured data isn't known ahead of time.
It's not that exporters are lazy, but performance can also be a concern
if the length needs to be computed ahead of time or the content needs to
be copied back and forth to use 1 or 3 byte encoding based on length.
Hence the recommendation, its not a MUST. So, exporters can choose to do
otherwise.

> I have some other "high-level" applicability concerns - it should be clear than IPFIX is still mostly useful in situations where _most_ things fit into the outer template, and SDIEs are used for additional sub-record-level structure. A guideline I'd like to see here: if you ever export a template just containing one subTemplateList, you should be exporting a Set instead. If you're ever exporting a template just containing one subTemplateMultiList, what you want is a Message. IPFIX records that are _just_ used as the root of a depth-first traversal of a semantic tree should be exported using something like XML instead.

We understand where you come from. However, here is a valid use case: 
let's say that the subTemplateList is supposed to export more than one 
instance (the normal case), but actually there is only one (this is an 
exception). In this case, we don't want to change the exporter code just 
for this exception. On the top of that, it's interesting to convey that 
there is only one instance, which can be done with the subTemplateList 
encoding.
> Editorial: I would suggest reworking the illustrations in section 4.5. I'll talk about basicList here but this applies generally. Figures C and D are not particularly useful, they just illustrate how varlen works. In addition, by overloading the term "basicList Content", they risk being confusing. At the same time, Figures A and B make basicList look like alignment poison. However, the alignment-brokenness of varlen encoding and the alignment-brokenness of semantic tagging cancel each other out. So combining these would make things more easily understandable, and certainly prettier:
>
>        0                   1                   2                   3
>        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
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |      255      |      Length (0 to 65535)      |   Semantic    |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |        IE Number              |          Content          . . .
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>

Well, this is more of an aesthetic change. The figures today clearly 
illustrate encoding w/ and without enterprise number, 1 and 3 byte 
encoding.
If we try to combine figures we may be losing some info - esp, that 1 or 
3 byte encoding can be used.
While working on the examples, we realized that the 1 or 3 bytes 
encoding could be a source of confusion for the readers who are not 
completely familiar with IPFIX.

However, we took care of the "content" issue

0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (< 255)| basicList Encoding ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... continuing as needed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure C: Variable-Length basicList Encoding (Length < 255 octets)

0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 255 | Length (0 to 65535) | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... basicList Encoding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure D: Variable-Length basicList Encoding (Length 0 to 65535 octets)

> (While I recall commenting on this a long time ago, I rescind my much-earlier "but isn't this technically independent from valen encoding?" I cannot think of a realistic example where you'd do this ->  it just buys you the pain of not having structured data while forcing you to pay for it.)
>
> Other specific points (copied from Gerhard's review)
>
>>>      6. Template Management
>>>
>>>       This section introduces some more specific Template Management and
>> _m_anagement
done.
>>>       Template Withdrawal Message-related specifications compared to the
>>>       IPFIX protocol specification [RFC5101].
>>>
>>>       First of all, the Template ID uniqueness is unchanged compared to
>>>       [RFC5101]; the uniqueness is local to the Transport Session and
>>>       Observation Domain that generated the Template ID.  In other
>>>       words, the Set ID used to export the Template Record does not
>>>       influence the Template ID uniqueness.
>>>
>>>       While [RFC5101] mentions that: "If an Information Element is
>>>       required more than once in a Template, the different occurrences
>>>       of this Information Element SHOULD follow the logical order of
>>>       their treatments by the Metering Process.", this rule MAY not be
>>>       followed for the Structured Data Information Elements.
> While technically 2119-correct, the English here is a little confusing. Suggest:
>
> "...this rule MAY be ignored within Structured Data Information Elements"
Done.
> This raises another point: there are now three ways to get multiple information elements into a Template: directly (in which case treatment-order is the only way to intepret), indirectly by a SDIE (in which case semantics rule; question: does "undefined" basicList default to allOf in treatment order?), directly with an SDIE (in subTemplateList/subTemplateMultiList, a Template containing multiple IEs directly still has those IEs interpreted as in treatment order, because the semantics apply only to the relationship among list members, not among IEs within list members).
>
> It would be nice to see this addressed somewhere.
There are two big different cases in our view
1. The implementations that don't support IPFIX structured data -> they 
can only rely on RFC5101.
2. The implementations that do support IPFIX structured data
     2.1 "undefined"

    "If the structured data contains the "undefined" structured data
    type semantic, the Collecting Process MAY attempt to draw its own
    conclusion in terms of the semantic contained in the Data Record."
    The typical example is an IPFIX Mediator that receives RFC5101 but
    wants to send IPFIX structured data

     2.2.something different that "undefined"

      Hopefully this is clearly defined ;-)

Note: the semantic of  subTemplateMultiList will also be clarified. See 
our next email.
>>>       As specified in [RFC5101], Templates that are not used anymore
>>>       SHOULD be deleted.  Before reusing a Template ID, the Template
>>>       MUST be deleted.  In order to delete an allocated Template, the
>>>       Template is withdrawn through the use of a Template Withdrawal
>>>       Message.
>> You might clarify that deleting a Template implies that it may not be
>> used within subTemplateList and subTemplateMultiList any more.
>
Corrected.

As specified in [RFC5101], Templates that are not used anymore SHOULD be 
deleted. _Deleting a Template implies that it may not be used within 
subTemplateList and subTemplateMultiList any more_. Before reusing a 
Template ID, the Template MUST be deleted. In order to delete an 
allocated Template, the Template is withdrawn through the use of a 
Template Withdrawal Message.

Thanks for your feedback.

Regards, Benoit
> More to follow on the list, I'm sure; just wanted to make sure I got these points out before today's meeting.
>
> Regards,
>
> Brian
>
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 8 Oct 2010 18:57:44 -0400

Hi Benoit, 
comments inline...

> Hence the recommendation, its not a MUST. So, exporters can choose to do

I think showing it with the 3-byte encoding is actually good, including and especially for a case of the length being smaller than 255 bytes.  It's a good way to remind implementors they will see this, and will likely appear in practice. (when I encode a IPFIX data, I don't want to put an if() statement in checking for greater than 255 then use 3 bytes - I'll ALWAYS use 3-byte encoding... and it's not laziness, it's less code to get wrong)

> We understand where you come from. However, here is a valid use case: let's say that the subTemplateList is supposed to export more than one instance (the normal case), but actually there is only one (this is an exception). In this case, we don’t want to change the exporter code just for this exception. On the top of that, it's interesting to convey that there is only one instance, which can be done with the subTemplateList encoding.

I don't think Brian's talking about the case of an exporter only encoding one list entry for a specific Data Record - I think he means when someone creates a new Template and all it has in it is a single subTemplate*List IE, with no other IEs.  You wouldn't need to do that, because an IPFIX Set effectively is a subTemplateList (because all data records in it are the "list" entries and follow the same template), and an IPFIX Message is a subTemplateMultiList (because each Set is an entry in the "list" and identifies its Template).  Right?

Having said that, subTemplate*List provide something new which Set and Message don't: the semantic indicator.

>> Editorial: I would suggest reworking the illustrations in section 4.5. I'll talk about basicList here but this applies generally. Figures C and D are not particularly useful, they just illustrate how varlen works. In addition, by overloading the term "basicList Content", they risk being confusing. At the same time, Figures A and B make basicList look like alignment poison. However, the alignment-brokenness of varlen encoding and the alignment-brokenness of semantic tagging cancel each other out. So combining these would make things more easily understandable, and certainly prettier
> Well, this is more of an aesthetic change. The figures today clearly illustrate encoding w/ and without enterprise number, 1 and 3 byte encoding. 
> If we try to combine figures we may be losing some info - esp, that 1 or 3 byte encoding can be used. 
> While working on the examples, we realized that the 1 or 3 bytes encoding could be a source of confusion for the readers who are not completely familiar with IPFIX.

Ironically, when I read the draft the first time I thought exactly what Brian's saying: alignment poison.  I was shocked there was a 1-byte "semantic" field, and was thinking how crazy it was to have this field for something so esoteric, and was thinking how there needs to be a basicBasicList.  Then once I saw the examples of the messages and how it fit in the alignment, I realized the error of my ways, and am now thinking how great this semantic field is. :)
(Well, I still think it's weird, but I'll comment on that in a separate email)

-hadriel

---

From: Benoit Claise <[email-masked]>
Date: Mon, 11 Oct 2010 10:06:10 +0200

Hadriel,

Thanks for reading the draft.
Just one quick comment inline.
> Having said that, subTemplate*List provide something new which Set and Message don't: the semantic indicator.
Exactly. The semantic is the reason why someone might be tempted to have 
the exact example you mentioned.

Regards, Benoit.

---

From: Gerhard Muenz <[email-masked]>
Date: Wed, 27 Oct 2010 13:25:34 +0200

Benoit,

On 29.09.2010 10:09, Benoit Claise wrote:
>>>      The Exporter SHOULD NOT check all semantically meaningless 
>>>      combinations before exporting the Data Record. 
>> I do not understand.
>> SHOULD NOT => SHOULD
>> or
>> SHOULD NOT => "does not have to"
> does not have to.
> In IPFIX structured data, we can express some complex (or stupid)
> semantic. It's not the responsibility of the  exporter to check if what
> is encoded makes sense from a semantic point of view.

I do not see this comment addressed because "SHOULD NOT" still appears
in -03.
Are you actually talking about the Exporting Process and not the
Exporter? Then, you might want to replace "Exporter" as well.

Regards,
Gerhard

---

From: Benoit Claise <[email-masked]>
Date: Wed, 27 Oct 2010 14:28:13 +0200

Hi Gerhard,

Thanks for the follow up.
Changed in my temp version from:

To

    The Exporting Process doesn't have to check all semantically
    meaningless combinations before exporting the Data Record.

Regards, Benoit.

---

From: Gerhard Muenz <[email-masked]>
Date: Thu, 28 Oct 2010 09:13:02 +0200

Hi Benoit,

Fine. With this, all my comments have been addressed.

Unfortunately, I do not have the time to proofread the entire document 
again.

Regards,
Gerhard

-- 
Dr.-Ing. Gerhard Münz
Chair for Network Architectures and Services (I8)
Technische Universität München - Department of Computer Science
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

---

From: Benoit Claise <[email-masked]>
Date: Thu, 28 Oct 2010 09:21:48 +0200

Thanks for your update Gerhard.

Regards, Benoit.