Subject: Re: [IPFIX] [Fwd: I-D ACTION:draft-trammell-ipfix-sctp-change-00.txt]

From: Gerhard Muenz <[email-masked]>
Date: Fri, 15 Jun 2007 18:45:03 +0200

Elisa, Brian,

Maybe it makes sense to also relax Paragraph 9 of Section 8 by removing
the last two sentences:

   The Template Withdraw Message MUST not be sent until sufficient time
   has elapsed to allow the Collecting Process to receive and process
   the last Data Record using this Template information. This time MUST
   be configurable.  A suitable default value is 5 seconds after the
   last Data Record has been sent.

Sending Templates and data over the same SCTP stream, we can ensure that
the message ordering is maintained, so there is no need to wait for
delayed data records.

Regards,
Gerhard

Boschi, Elisa wrote:
> 
> 
> Dear all,
> 
> find below the proposed errata Brian mentioned in his past email. We
> agree that the current specification on the usage of SCTP streams for
> IPFIX is not efficient, and the restriction of sending templates on
> stream zero unnecessary. We propose to update the protocol specification
> by simply relaxing those constraints via this errata and believe that
> this is a fast and effective way to solve the problem. 
> 
> We'd appreciate comments on both the idea of solving the stream
> selection problem this way, and on the specifics of how it is addressed
> in this draft...
> 
> Thanks,
> Elisa
> 
> 
> -------- Original Message --------
> Subject: I-D ACTION:draft-trammell-ipfix-sctp-change-00.txt
> Date: Fri, 25 May 2007 15:50:02 -0400
> From: [email-masked]
> Reply-To: [email-masked]
> To: [email-masked]
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
> 
>         Title           : IP Flow Information Export (IPFIX) SCTP Stream
> Restriction Change
>         Author(s)       : B. Trammell, E. Boschi
>         Filename        : draft-trammell-ipfix-sctp-change-00.txt
>         Pages           : 10
>         Date            : 2007-5-25
>        
>    The IPFIX protocol mandates the use of PR-SCTP as transport protocol.
>    The document specifies the transmission of Templates over SCTP stream
>    zero with reliable delivery and the transmission of Data Records over
>    separate streams.  This constraint is unnecessary.  This document
>    relaxes all restrictions on the use of SCTP streams within IPFIX,
>    allowing IPFIX implementations to use SCTP streams as most
>    appropriate for their respective applications.
> 
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-trammell-ipfix-sctp-change-00.txt
> 
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the
> username "anonymous" and a password of your e-mail address. After
> logging in, type "cd internet-drafts" and then
> "get draft-trammell-ipfix-sctp-change-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
>         [email-masked].
> In the body type:
>         "FILE /internet-drafts/draft-trammell-ipfix-sctp-change-00.txt".
>        
> NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ipfix

-- 
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
_______________________________________________
IPFIX mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipfix

---

From: Gerhard Muenz <[email-masked]>
Date: Fri, 15 Jun 2007 18:45:03 +0200

Elisa, Brian,

Regards,
Gerhard

---

From: Brian Trammell <[email-masked]>
Date: Thu, 21 Jun 2007 11:16:05 -0400

Gerhard,

As I see it, while the removal of stream restrictions may have a
tangential impact on template management and template reuse, it does not
necessarily remove this restriction in every case.

Notionally, an EP has a general responsibility to ensure that it exports
a set of message streams that a CP can decode. This means that not only
should it attempt to ensure that a template is not withdrawn before the
CP is done with it, but neither should it reuse a template ID until it
believes the CP has processed the withdrawal. So we need something like
this paragraph, and the following paragraph:

   The Template ID from a withdrawn Template MUST NOT be reused until
   sufficient time has elapsed to allow for the Collecting Process to
   receive and process the Template withdraw message.

With the stream restriction change, we're _not_ saying that templates
have to appear on the same stream as their data (that's the per-stream
draft), so the EP still has the general responsibility to handle timing
of template management.

That said, I do agree that the last two sentences of paragraph 9 don't
really seem to follow from the rest of the document - the EP has a
general responsibility but we can't really enforce anything beyond that,
and introducing yet another timer here seems a clumsy way to try.

But, I don't really see how to wedge this change into the sctp-change
document as presently structured, because it doesn't follow from the
purpose of that document, which is to fix the interaction between IPFIX
and SCTP so that streams can be used as they should be in an
interoperable. I'd prefer to avoid making this document a general errata
document for IPFIX, because then we'll be right back where we started
with respect to never finishing the protocol. I _really_ don't want to
do that without strong WG consensus.

Regards,

Brian

---

From: Brian Trammell <[email-masked]>
Date: Thu, 21 Jun 2007 11:16:05 -0400

Gerhard,

Regards,

Brian