Re: [nbs] NBS and TCP connection identification

Christian Vogt <christian.vogt@ericsson.com> Mon, 04 October 2010 22:29 UTC

Return-Path: <christian.vogt@ericsson.com>
X-Original-To: nbs@core3.amsl.com
Delivered-To: nbs@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 131503A6B95 for <nbs@core3.amsl.com>; Mon, 4 Oct 2010 15:29:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.956
X-Spam-Level:
X-Spam-Status: No, score=-102.956 tagged_above=-999 required=5 tests=[AWL=-0.357, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 iz0aiZrRsd9U for <nbs@core3.amsl.com>; Mon, 4 Oct 2010 15:29:53 -0700 (PDT)
Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 00B093A6EB3 for <nbs@ietf.org>; Mon, 4 Oct 2010 15:29:52 -0700 (PDT)
Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id o94MUmZw006353 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Oct 2010 17:30:48 -0500
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.2.166]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Mon, 4 Oct 2010 18:30:48 -0400
From: Christian Vogt <christian.vogt@ericsson.com>
To: Erik Nordmark <erik.nordmark@oracle.com>
Date: Mon, 4 Oct 2010 18:30:45 -0400
Thread-Topic: [nbs] NBS and TCP connection identification
Thread-Index: ActkE8pEf9puOydISaGCFzCMHtQMfA==
Message-ID: <0AEEB537-CAF7-4A14-9BCA-2EE5480CB0B5@ericsson.com>
References: <4C97D9A8.2050001@oracle.com> <ACE9611A-9107-46EC-ADD2-56E553DC1C3A@ericsson.com> <4C9826D0.2060703@oracle.com> <1285067950.2068.59.camel@bit> <4C98D525.1030808@oracle.com> <1285148838.2211.60.camel@bit> <4C9A38A1.9060307@oracle.com> <1285251552.2225.109.camel@bit> <4CA60E4B.9050803@oracle.com>
In-Reply-To: <4CA60E4B.9050803@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "nbs@ietf.org" <nbs@ietf.org>
Subject: Re: [nbs] NBS and TCP connection identification
X-BeenThere: nbs@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Name based sockets discussion list <nbs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nbs>, <mailto:nbs-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nbs>
List-Post: <mailto:nbs@ietf.org>
List-Help: <mailto:nbs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nbs>, <mailto:nbs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Oct 2010 22:29:55 -0000

Erik Nordmark wrote:

> It is pretty clear to me that if we want some form of id/locator 
> separation architecture, then some things will change. We definitely 
> have to be cognizant of this and understand the tradeoffs, but starting 
> off with "we can't change X" for any value of X isn't likely to be a 
> good approach.


Erik:

You are right.  We should be clear on what will change, and what does not have to change.

And I think the plan is fairly simple:  Operating system vendors will take on the burden, since they will need to add name-based sockets to their operating systems.  But they will be incentivized:  Name-based sockets will simplify application development, which has always been an objective of operating system vendors.

Once operating systems support name-based sockets, we are good.  Of course, we want applications to adopt the new API -- and they eventually will because this will make the life of application developers simpler.  But there is no time pressure.

Finally, we won't change routers, neither will be require new infrastructure.

- Christian