Subject: [IPFIX] New work items: summary and next steps

From: Nevil Brownlee <[email-masked]>
Date: Wed, 8 Aug 2007 09:37:05 +1200

Hi all:

At our meeting in Chicago, we agreed to continue the discussion of  
possible
new WG work items on the mailing list until the end of last week.  This
note summarises the discussion to date, and makes a more definite  
proposal.

a) Fix the SCTP streams issues in the protocol, i.e. pull it out of
    RFC Editor Queue, make a new revision and run it through WGLC,  
IETF LC
    and IESG again.  There is strong consensus on this; the Protocol  
Draft
    authors have been working through the necessary changes.

    That work has also brought to light two other issues:
     - Padding, see slide 7 of
       http://www3.ietf.org/proceedings/07jul/slides/ipfix-13.pdf
     - Templates and TCP (discussed by Paul Aitken during the IPFIX
       testing presentation), this is mising from the 'TCP transport'
       section of the Draft

    These - of course - are not related to SCTP.  Nonetheless, they
    would require small changes, and making them would improve the
    Protocol RFC.
    =>  I'd like to see some discussion on the list about whether we
        should make them, or whether we should only make the
        SCTP-related changes.  (And I certainly don't want to see any
        proposals for further changes!)

b) SCTP per-stream draft.  Discussion centred on whether this should
    be Informational or experimental.  Since 'Reducuing Redundancy'
    is Informational, I believe that SCTP per-stream should be also.
    => Proposed: Adopt this for an Informational RFC, time: 3 months

c) File Format: General agreement that we need this, and that it should
    be a Standards Track RFC.  One interesting comment: "it's really a
    fourth transport for IPFIX."
    => Proposed: Adopt this for a Standards Track RFC, time: 3 months
         Note that those working on this draft will have to decide
         how best to handle "Extended Types."

d) Mediators: There was fairly strong support for this, including some
    from network operators.  However, the current draft is very broad
    in scope - maybe, for example, it could be split into an overview
    draft, and one or two other drafts addressing specific topics,
    e.g. aggregation and anonymisation.  If the WG is to work on this,
    we'll need a better definition of exactly what documents we are to
    work on.

e) Other possible items did not get much discussion.
    => Proposed: Individuals involved should continue to develop them
         further.

Summary:
--------

Right now:
    Implement (a), i.e. revise the protocol draft asap.

Short term [3 months]:
    Adopt as WG tasks proposed items (b) and (c) above.

Longer term [12~18 months]
    Adopt item (d) above.

Who's going to work on these?
-----------------------------

I need names for at least 3 people who'll agree to review the drafts
for (b), (c) and (d), before we can go any further with them.  If you're
prepared to do that, please email me to say which item(s) you'll
review for.

Cheers, Nevil

---------------------------------------------------------------------
  Nevil Brownlee                    Computer Science Department | ITS
  Phone: +64 9 373 7599 x88941             The University of Auckland
  FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand

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

---

From: Gerhard Muenz <[email-masked]>
Date: Wed, 08 Aug 2007 10:10:55 +0200

Nevil,

I'm missing a statement about the configuration draft.

Concerning the two additional issues in a):
- Padding: I do not see the necessity to change the specification.
  As it is now, exporters MUST set padding octets to zero, and
  collectors MAY check this or not (depending on if they consider
  non-zero padding as "malformed"). Anyway, the collector discards
  the padding, so the protocol works in any case.
- Template management in TCP: I always considered Template management
  in TCP and SCTP transport sessions to be the same. If this does not
  become clear in the current draft, I'm in favor of a small change
  here.

Regards,
Gerhard

Nevil Brownlee wrote:
> 
> Hi all:
> 
> At our meeting in Chicago, we agreed to continue the discussion of possible
> note summarises the discussion to date, and makes a more definite proposal.
> 
>    RFC Editor Queue, make a new revision and run it through WGLC, IETF LC
>    and IESG again.  There is strong consensus on this; the Protocol Draft

-- 
Dipl.-Ing. Gerhard Münz
Computer Networks and Internet
Wilhelm Schickard Institute for Computer Science
University of Tuebingen
Sand 13 (Room B309), D-72076 Tuebingen, Germany
Phone:  +49 7071 29-70534       Fax: +49 7071 29-5220
E-mail: [email-masked]
WWW:    http://net.informatik.uni-tuebingen.de/~muenz

---

From: Gerhard Muenz <[email-masked]>
Date: Wed, 08 Aug 2007 10:10:55 +0200

Nevil,

Regards,
Gerhard

---

From: Paul Aitken <[email-masked]>
Date: Wed, 08 Aug 2007 10:09:07 +0100

Gerhard,

>   the padding, so the protocol works in any case.

I disagree: it's not clear whether padding with non-zero valued octets 
constitutes a malformed message.

(Note I'm talking about set padding, rather than paddingOctets; everyone 
seems to agree that the Collecting Process should not check the values 
of any Information Elements, including paddingOctets. Rather, checking 
of values should be done by higher level processes which are using the 
data.)

So, if an Exporting Process doesn't take care to use zero-valued padding 
octets, then it may not be interoperable with a Collecting Process - 
depending how strictly that Collecting Process implements the zero 
padding rule.

>   become clear in the current draft, I'm in favor of a small change

Agreed.

-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.

---

From: Paul Aitken <[email-masked]>
Date: Wed, 08 Aug 2007 10:09:07 +0100

Gerhard,

Agreed.

---

From: Gerhard Muenz <[email-masked]>
Date: Wed, 08 Aug 2007 11:45:08 +0200

Paul,

> depending how strictly that Collecting Process implements the zero

I fully agree, and that is why the specs say that the Exporting Process
MUST use zero-valued padding. So, where is the problem?

---

From: Gerhard Muenz <[email-masked]>
Date: Wed, 08 Aug 2007 11:45:08 +0200

Paul,

---

From: Paul Aitken <[email-masked]>
Date: Wed, 08 Aug 2007 15:29:09 +0100

Gerhard,

> MUST use zero-valued padding. So, where is the problem?

The problem is that the specs don't make it clear what should happen if 
the EP *doesn't* use zero-valued padding.

Is it a malformed message that should be rejected? Should the SCTP 
association be shut down? It seems unnecessary. Ideally the Collecting 
Process should still accept the message, because the interpretation 
won't be any different.

---

From: Paul Aitken <[email-masked]>
Date: Wed, 08 Aug 2007 15:29:09 +0100

Gerhard,

---

From: Brian Trammell <[email-masked]>
Date: Wed, 8 Aug 2007 16:55:48 -0400

Paul and Gerhard,

To add to the opinion parade here, in keeping with the cardinal law  
of protocol design (be liberal in what you accept and conservative in  
what you send), I'd be opposed to requiring the CP to shut down the  
association on nonzero padding. There is an opportunity for clever CP  
implementors to detect and log (or possibly tag records on) messages  
with nonzero set padding (as they may be indicative of data  
corruption), but calling this a malformed message in every case seems  
a bit much. We may want to clarify and enumerate what malformed  
message _means_ (which, in my opinion, is any message in which the  
framing information does not allow successful decode) but I don't  
think nonzero set padding qualifies (because a CP can indeed decode a  
message with nonzero set padding; in fact it has to do _extra_ decode  
work in order to verify the set padding is zero.)

There is an argument that non-zero set padding can be used to detect  
incorrect framing of sets, but if we as a WG want to be able to  
detect such a case reliably, we'd need to have specified a zero  
trailer for _every_ set, not just those an EP wants to keep somehow  
aligned within a message. And we didn't do that.

Cheers,

Brian

On Aug 8, 2007, at 10:29 AM, Paul Aitken wrote:

> The problem is that the specs don't make it clear what should  
> happen if the EP *doesn't* use zero-valued padding.
>
> association be shut down? It seems unnecessary. Ideally the  
> Collecting Process should still accept the message, because the  
> interpretation won't be any different.
>
> -- 
> Paul Aitken

---

From: Brian Trammell <[email-masked]>
Date: Wed, 8 Aug 2007 16:55:48 -0400

Paul and Gerhard,

Cheers,

Brian

---

From: Paul Aitken <[email-masked]>
Date: Wed, 08 Aug 2007 22:09:58 +0100

Brian,

> To add to the opinion parade here, in keeping with the cardinal law of 
> protocol design (be liberal in what you accept and conservative in what 
> you send), I'd be opposed to requiring the CP to shut down the 
> with nonzero set padding (as they may be indicative of data corruption), 
> but calling this a malformed message in every case seems a bit much.

I completely agree.

> We may want to clarify and enumerate what malformed message _means_

I think we should have - but this will be yet another thing to add to 
the protocol draft when we get it back. Where will we draw the line?

> (which, 
> in my opinion, is any message in which the framing information does not 
> allow successful decode)

Agreed.

> but I don't think nonzero set padding qualifies 
> (because a CP can indeed decode a message with nonzero set padding; in 
> fact it has to do _extra_ decode work in order to verify the set padding 
> is zero.)

Yep.

So there should be a statement somewhere in the protocol draft that 
allows the CP to accept (and log) non-zero set padding without shutting 
down the association.

ie, a CP MUST NOT consider non-zero padding as constituting a malformed 
message.

> incorrect framing of sets, but if we as a WG want to be able to detect 
> such a case reliably, we'd need to have specified a zero trailer for 
> _every_ set, not just those an EP wants to keep somehow aligned within a 
> message. And we didn't do that.

---

From: Paul Aitken <[email-masked]>
Date: Wed, 08 Aug 2007 22:09:58 +0100

Brian,

I completely agree.

Agreed.

Yep.

---

From: Nevil Brownlee <[email-masked]>
Date: Thu, 9 Aug 2007 10:14:00 +1200

> I'm missing a statement about the configuration draft.

That's because, as far as I could see, no-one made any comments at
all about it on the list.  If it's to be a WG item, we need to have
several people expressing support - as a minimum, that means at
least 3 who'll agree to review the draft.

Discussion on this (and the other possible work items) is still open,
so once again I'm calling for comments or expression of support for
them on the list.

Cheers, Nevil

---

From: Nevil Brownlee <[email-masked]>
Date: Thu, 9 Aug 2007 10:14:00 +1200

Cheers, Nevil

---

From: Paul Aitken <[email-masked]>
Date: Wed, 08 Aug 2007 23:36:32 +0100

Nevil,

> so once again I'm calling for comments or expression of support for

I support this draft, and have reviewed it. I try to get my scribbles 
converted into an email ASAP.

---

From: Paul Aitken <[email-masked]>
Date: Wed, 08 Aug 2007 23:36:32 +0100

Nevil,

---

From: kobayashi atsushi <[email-masked]>
Date: Sun, 12 Aug 2007 13:49:41 +0900

Hi all,

snip
>     we'll need a better definition of exactly what documents we are to

I agree. Mediator draft could be split to the overview draft and several
topic drafts. The overview draft includes the requirement, the structure
of mediator and several use cases.

The other is further split to "protocol mediation" and some modification
techniques of measurement data, "anonymisation" and "aggregation".
The "protocol mediation" means relaying multiple collecting and exporting
IPFIX sessions. The "protocol mediation" draft could be done by extracting
the specific part from IPFIX Mediator draft. 

It is better that the specific topics drafts are generic, not related to
Mediator, as Gerhard mentioned following ML.
 Re: [IPFIX] *Proposed* new work items, take two

Especially, the aggregation part could be contemplated at first. 
Anyone support this item ?

> Who's going to work on these?

--- 
Atsushi KOBAYASHI  <[email-masked]>
NTT Information Sharing Platform Lab.
tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637

---

From: kobayashi atsushi <[email-masked]>
Date: Sun, 12 Aug 2007 13:49:41 +0900

Hi all,

snip

---

---

From: Benoit Claise <[email-masked]>
Date: Mon, 13 Aug 2007 17:52:36 +0200

Paul Aitken wrote:
> (Note I'm talking about set padding, rather than paddingOctets; 
> everyone seems to agree that the Collecting Process should not check 
> the values of any Information Elements, including paddingOctets. 
> Rather, checking of values should be done by higher level processes 
> which are using the data.)
>
> So, if an Exporting Process doesn't take care to use zero-valued 
> padding octets, then it may not be interoperable with a Collecting 
> Process - depending how strictly that Collecting Process implements 
> the zero padding rule.
>
>
For consistency reasons between TCP and SCTP, I'm also in favor of 
making this small change to the protocol draft.

Regards, Benoit.

---

From: Benoit Claise <[email-masked]>
Date: Mon, 13 Aug 2007 17:52:36 +0200

Regards, Benoit.

---

From: Andrew Johnson <[email-masked]>
Date: Tue, 14 Aug 2007 04:36:01 +0100

Hi Nevil

I support the configuration draft and am happy to review it.

Cheers

Andrew

---

From: Andrew Johnson <[email-masked]>
Date: Tue, 14 Aug 2007 04:36:01 +0100

Hi Nevil

Cheers

Andrew

---

From: Benoit Claise <[email-masked]>
Date: Fri, 17 Aug 2007 11:18:32 +0200

Dear all,
>        proposals for further changes!) 
A new version of the protocol has just been posted, including the above 
changes.
Brian, Paul, Elisa and I spent quite some time integrating all the changes.
Thanks to draft-trammell-ipfix-sctp-change-01.txt, the SCTP-related 
modifications were made easier.
Please review it. The best way to review the changes is 
http://tools.ietf.org/rfcdiff
I hope we will quickly put back the draft in the RFC-editor queue.

Regards, Benoit.

---

From: Benoit Claise <[email-masked]>
Date: Fri, 17 Aug 2007 11:18:32 +0200

Dear all,

Regards, Benoit.

---

From: Gerhard Muenz <[email-masked]>
Date: Mon, 20 Aug 2007 14:14:42 +0200

Hi Benoit, all,

Some comments/corrections/questions:

1. What is meant by "in order" in the following two phrases:
"Template Sets and Options Template Sets MUST be sent [...] in order."
"The Template Withdraw Message MUST be sent [...] in order."

2. There is one SCTP->TCP replacement missing in 10.4.3 Collecting Process:
"If the Collecting Process receives a Template Withdraw message for a	
Template Record it has not received before on this TCP connection,
it MUST reset the *TCP* association, discard the IPFIX Message, and	
SHOULD log the error as it does for malformed IPFIX Messages."

3. "SCTP Stream" or "SCTP stream"? Both writings appear in the document.

4. Does the following paragraph of 11.1 Applicability of TLS and DTLS
also need some small modification after relaxing the stream requirements?

   "When using DTLS over SCTP, the Exporting Process MUST ensure that
   each IPFIX Message is sent over the same SCTP Stream that would be
   used when sending the same IPFIX Message directly over SCTP. Note
   that DTLS may send its own control messages on stream 0 with full
   reliability; however, this will not interfere with the processing of
   stream 0 IPFIX Messages at the Collecting Process, because DTLS
   consumes its own control messages before passing IPFIX Messages up to
   the application layer."

For example, I do not understand the motivation for the first sentence
(any more). It made sense to point out that the stream-zero-restriction
still holds when DTLS is used.

5. Searching the mailing list for older comments on the draft, I found
the following message about "Sequence Number" which is still written in
different ways in the current version of the document. Also, the usage
descriptions for TCP and UDP do not mention that the SN is scoped per
Observation Domain ID. See:
http://www1.ietf.org/mail-archive/web/ipfix/current/msg03911.html
and the other messages in the thread.

Regards,
Gerhard

---

From: Gerhard Muenz <[email-masked]>
Date: Mon, 20 Aug 2007 14:14:42 +0200

Hi Benoit, all,

Regards,
Gerhard

---

From: Andreas Kind <[email-masked]>
Date: Tue, 21 Aug 2007 15:53:16 +0200

Nevil, Gerhard,

In general, I regard the work on data models for configuration 
important. I will look at the draft and post my comments asap.

Best regards -- Andreas
--------------------------------------
Andreas Kind <[email-masked]>
   IBM Zurich Research Laboratory
   Tel +41-44-724-8915 Fax +41-44-724-8955

---

From: Andreas Kind <[email-masked]>
Date: Tue, 21 Aug 2007 15:53:16 +0200

Nevil, Gerhard,

Best regards -- Andreas