[IPFIX] Reference to draft-stewart-tsvwg-sctpstrrst-00.txt in our IPFIX document

Benoit Claise <bclaise@cisco.com> Thu, 20 November 2008 21:12 UTC

Return-Path: <ipfix-bounces@ietf.org>
X-Original-To: ipfix-archive@lists.ietf.org
Delivered-To: ietfarch-ipfix-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7411628C261; Thu, 20 Nov 2008 13:12:32 -0800 (PST)
X-Original-To: ipfix@core3.amsl.com
Delivered-To: ipfix@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 618A728C24E; Thu, 20 Nov 2008 13:12:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.926
X-Spam-Level:
X-Spam-Status: No, score=-0.926 tagged_above=-999 required=5 tests=[AWL=-0.563, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24, SARE_SUB_10CONS_WORD=0.639, SARE_SUB_6CONS_WORD=0.356]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QaUABPnCNSQz; Thu, 20 Nov 2008 13:12:30 -0800 (PST)
Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id D3D2B28C24D; Thu, 20 Nov 2008 13:12:29 -0800 (PST)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id mAKLCSB14192; Thu, 20 Nov 2008 22:12:28 +0100 (CET)
Received: from [10.61.88.43] (ams3-vpn-dhcp6188.cisco.com [10.61.88.43]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id mAKLCDG14067; Thu, 20 Nov 2008 22:12:13 +0100 (CET)
Message-ID: <4925D2AD.8060304@cisco.com>
Date: Thu, 20 Nov 2008 15:12:13 -0600
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: tsvwg@ietf.org
Cc: "ipfix@ietf.org" <ipfix@ietf.org>
Subject: [IPFIX] Reference to draft-stewart-tsvwg-sctpstrrst-00.txt in our IPFIX document
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPFIX WG discussion list <ipfix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ipfix>
List-Post: <mailto:ipfix@ietf.org>
List-Help: <mailto:ipfix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0736483188=="
Sender: ipfix-bounces@ietf.org
Errors-To: ipfix-bounces@ietf.org

Dear all,

With this email, we want to stress to importance of  
draft-stewart-tsvwg-sctpstrrst-00.txt 
<http://tools.ietf.org/html/draft-stewart-tsvwg-sctpstrrst-00.txt> for 
the IP Flow Information eXport (IPFIX) WG.

As you might know, the IFPIX protocol RFC5101 runs on the top of PR-SCTP.
We have developed a new draft: "IPFIX Export per SCTP Stream", 
http://tools.ietf.org/html/draft-ietf-ipfix-export-per-sctp-stream-01

     Abstract
     
        This document specifies an improvement to the PR-SCTP
        export specified in the IPFIX specifications in RFC5101 <http://tools.ietf.org/html/rfc5101>.
        This method offers several advantages such as the ability to
        calculate Data Record losses for PR-SCTP, immediate export of
        Template Withdrawal Messages, immediate reuse of Template IDs
        within an SCTP stream, and reduced demands on the Collecting
        Process.


In a nutshell, this draft specifies that we should export a Template 
Record and its associated Flow Records within a single stream so that we 
could deduce the loss per Template. Indeed, if multiple Tempate Records 
and associated  Flow Records are sent within a single stream and one 
IPFIX Message is lost, we don't know to which Template we should assign 
the loss. If we increase the number of Template Record during the live 
time of the IPFIX Device, we should increase the number of streams. 
Obviously, shutting down the association to increase the number of 
streams is not an option ;-)
So the feature we need from draft-stewart-tsvwg-sctpstrrst-00.txt is the 
addition of streams in an existing SCTP association.

The draft "IPFIX Export per SCTP Stream" passed the WGLC is a ready for 
the write-up but the normative reference to 
draft-stewart-tsvwg-sctpstrrst-00.txt blocks us.  Dan Romascanu, our OPS 
AD, suggested to describe a brief summary of the mechanism in our IPFIX 
draft, then to move the draft-stewart-tsvwg-sctpstrrst-00.txt reference 
from normative to informative.
That trick would help with our draft in the short term, even to produce 
a RFC. However, the longer term goal would be to have a RFC specifying 
the stream addition in an existing SCTP association. Once done,  it can 
be used as a normative reference.

Feedback?

Regards, Benoit.


_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix