Re: UDP encaps for SCTP and SCCP

Michael Tüxen <Michael.Tuexen@lurchi.franken.de> Wed, 19 May 2010 06:05 UTC

Return-Path: <Michael.Tuexen@lurchi.franken.de>
X-Original-To: tsvwg@core3.amsl.com
Delivered-To: tsvwg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 344123A689E; Tue, 18 May 2010 23:05:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.55
X-Spam-Level: ****
X-Spam-Status: No, score=4.55 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HOST_MISMATCH_COM=0.311, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033]
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 HgUso-1eqgcq; Tue, 18 May 2010 23:05:10 -0700 (PDT)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id B575E3A67EC; Tue, 18 May 2010 23:05:09 -0700 (PDT)
Received: from [192.168.20.2] (tmo-108-56.customers.d1-online.com [80.187.108.56]) by mail-n.franken.de (Postfix) with ESMTP id 8A7611C0B4607; Wed, 19 May 2010 08:04:31 +0200 (CEST)
Subject: Re: UDP encaps for SCTP and SCCP
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset="us-ascii"
From: Michael Tüxen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <F969C7A1-3ED7-4C93-B30A-27E513985932@nokia.com>
Date: Wed, 19 May 2010 08:04:36 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <CC0338F4-5622-4FEB-9460-51D1CEBC8EA8@lurchi.franken.de>
References: <9693C831-4EE4-4FC5-84A2-083DA16C1CD6@nokia.com> <F969C7A1-3ED7-4C93-B30A-27E513985932@nokia.com>
To: Lars Eggert <lars.eggert@nokia.com>
X-Mailer: Apple Mail (2.1078)
Cc: DCCP working group <dccp@ietf.org>, TSV Area <tsv-area@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 May 2010 06:05:11 -0000

On May 18, 2010, at 9:37 AM, Lars Eggert wrote:

> Hi,
> 
> the discussion has touched on lots of things related to UDP encaps, but I haven't seen anything I'd call consensus on the question below. I'd therefore like to ask folks to specifically state which option they support:
> 
> (1) do one SCTP-specific and one DCCP-specific UDP encaps
> (2) do one generic UDP encaps that can be used with both
> (3) do neither (don't do any sort of UDP encaps for SCTP and DCCP)
I vote for (1) since I do not see that a (real) generic solution is
possible.

Best regards
Michael
> 
> Thanks,
> Lars
> 
> On 2010-4-22, at 12:57, Eggert Lars (Nokia-NRC/Espoo) wrote:
>> Hi,
>> 
>> as most of you probably know, there are two different proposals for how to encapsulate SCTP and DCCP inside UDP.
>> 
>> One approach proposes two protocol-specific encapsulation schemes (described in draft-tuexen-sctp-udp-encaps and draft-ietf-dccp-udpencap).
>> 
>> The second approach proposes a generic encapsulation scheme that can be applied to both SCTP and DCCP (draft-manner-tsvwg-gut).
>> 
>> As a community, we do need to come to consensus on which of these two approaches we want to follow when it comes to UDP encapsulation of SCTP and DCCP. I believe it would be very confusing if we were to standardize both approaches.
>> 
>> I'd hence like to ask folks to read the three documents and post their views to the tsvwg@ietf.org list. I'm personally especially interested in hearing from folks who aren't on the author lists of the documents, but obviously, the authors expert opinions do matter.
>> 
>> Thanks,
>> Lars
>> 
>> PS: I'm pushing on this topic, because UDP encapsulation is the last remaining work item in the DCCP working group before it can close...
>