[EME] NUTSS -- Addressing Transition

Christian Vogt <christian.vogt@nomadiclab.com> Wed, 13 June 2007 14:57 UTC

Return-path: <eme-bounces@irtf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyUI9-0005Ma-Bw; Wed, 13 Jun 2007 10:57:49 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyUI8-0005ML-L7 for eme@irtf.org; Wed, 13 Jun 2007 10:57:48 -0400
Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyUHv-0004bH-GG for eme@irtf.org; Wed, 13 Jun 2007 10:57:48 -0400
Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 09E46212E84; Wed, 13 Jun 2007 17:57:34 +0300 (EEST)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id C5549212D85; Wed, 13 Jun 2007 17:57:33 +0300 (EEST)
Message-ID: <467005E0.3000102@nomadiclab.com>
Date: Wed, 13 Jun 2007 17:57:36 +0300
From: Christian Vogt <christian.vogt@nomadiclab.com>
User-Agent: Thunderbird 1.5.0.12 (X11/20070604)
MIME-Version: 1.0
To: francis@cs.cornell.edu
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Cc: eme@irtf.org
Subject: [EME] NUTSS -- Addressing Transition
X-BeenThere: eme@irtf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: end-middle-end research group <eme.irtf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/eme>, <mailto:eme-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/eme>
List-Post: <mailto:eme@irtf.org>
List-Help: <mailto:eme-request@irtf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/eme>, <mailto:eme-request@irtf.org?subject=subscribe>
Errors-To: eme-bounces@irtf.org

Hello Paul,

in your NUTSS proposal [1], you describe a two-tiered architecture of
middleboxes in which, if I understand it correctly, one tier is in
charge of negotiating and admitting paths between host pairs, and the
other enforces that only authorized hosts can use a particular path.

  [1] draft-irtf-eme-francis-nutss-design-00.txt

Now, the way this is specified in the draft seems to require support on
both sides of the connection.  I was wondering whether you assume a
universal middlebox infrastructure?  What would happen if host A wants
to communicate to host B, and there exists a middlebox in charge of A,
but none in charge of B?  And, probably more importantly, what would
happen if B tries to establish a connection with A?

Even though transition is not one of the EME research group's primary
goals at this point, I think it is important to support scenarios where
one side of the connection is legacy, or even /design/ the architecture
under the assumption that there will always be legacy sites on the
Internet.  For otherwise, I would agree with Teemu (see his earlier
email on this list) that a clean-slate approach such as DONA, which also
avoids the shortfalls of DNS as a look-up mechanism, would be as
feasible to deploy and hence possibly more appropriate.

This is not at all to say that I don't appreciate the work of EME and
proposals like NUTSS.  But the focus of such work should, IMO, be more
oriented to the existing Internet architecture -- which means that
transition is an important thing to be considered from the very
beginning.  In the special case of NUTSS, I think this should be achievable.

Kind regards,
- Christian



_______________________________________________
EME mailing list
EME@irtf.org
https://www1.ietf.org/mailman/listinfo/eme