Re: [tae] The internet architecture

"Hallam-Baker, Phillip" <pbaker@verisign.com> Thu, 04 December 2008 22:11 UTC

Return-Path: <tae-bounces@ietf.org>
X-Original-To: tae-archive@ietf.org
Delivered-To: ietfarch-tae-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16DA128C0E6; Thu, 4 Dec 2008 14:11:49 -0800 (PST)
X-Original-To: tae@core3.amsl.com
Delivered-To: tae@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 547F33A6951; Thu, 4 Dec 2008 11:59:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.258
X-Spam-Level:
X-Spam-Status: No, score=-6.258 tagged_above=-999 required=5 tests=[AWL=0.340, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 FH+g-tFoQSCP; Thu, 4 Dec 2008 11:59:34 -0800 (PST)
Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by core3.amsl.com (Postfix) with ESMTP id 3C0BE3A68FA; Thu, 4 Dec 2008 11:59:34 -0800 (PST)
Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id mB4JcXaw011494; Thu, 4 Dec 2008 11:38:33 -0800
Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Dec 2008 11:59:27 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 4 Dec 2008 11:58:13 -0800
Message-ID: <2788466ED3E31C418E9ACC5C316615572FFBEF@mou1wnexmb09.vcorp.ad.vrsn.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: The internet architecture
Thread-Index: AclWPYfu98wfuG9rSmiYn+IrZvPWBAADRvuP
References: <C15AE32B-E564-4C93-86FF-40EF203E673A@mpi-sws.org> <49382030.5020704@network-heretics.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: "Keith Moore" <moore@network-heretics.com>, "Bryan Ford" <brynosaurus@gmail.com>
X-OriginalArrivalTime: 04 Dec 2008 19:59:27.0701 (UTC) FILETIME=[D02DF050:01C9564A]
X-Mailman-Approved-At: Thu, 04 Dec 2008 14:11:47 -0800
Cc: tae@ietf.org, ietf@ietf.org
Subject: Re: [tae] The internet architecture
X-BeenThere: tae@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Transport Architecture Evolution <tae.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tae>, <mailto:tae-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/tae>
List-Post: <mailto:tae@ietf.org>
List-Help: <mailto:tae-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tae>, <mailto:tae-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1566696829=="
Sender: tae-bounces@ietf.org
Errors-To: tae-bounces@ietf.org

I am trying to parse this claim.

Are you saying that the DNS is fragile and raw IP relatively robust? 

If so I can show you mountains of evidence to show that you are completely wrong.


-----Original Message-----
From: ietf-bounces@ietf.org on behalf of Keith Moore
Sent: Thu 12/4/2008 1:23 PM
To: Bryan Ford
Cc: tae@ietf.org; ietf@ietf.org
Subject: Re: The internet architecture
 
Bryan Ford wrote:

> To throw in my quick $.02 (and perhaps invite more discussion :) ), I
> think we absolutely need to migrate both networking APIs and transport
> layer protocols themselves toward a model where an "endpoint" is an
> opaque (to the transport/application) variable-length string of some
> kind, and the transport/application shouldn't even care much if any what
> exactly the string is.  The string could potentially be a DNS name, a
> dotted IPv4 address, a colonificated IPv6 address, a hex-encoded HIP
> cryptographic host identifier, a UIA personal name, ...  And sure, the
> semantics of these different kinds of "endpoint strings" will vary
> depending on what they actually are, and for network management purposes
> they won't all be equivalent or interchangeable, but for purposes of
> normal transport and application protocol operation - i.e., "gimme a
> TCP-like connection to the endpoint named 'X'", why should transports
> and applications need to care?  

Sigh.  Maybe this is unfair, but it seems to me that people keep wanting
to take (relatively) straightforward, bulletproof interfaces and replace
them with fragile ones that depend on extra layers of indirection, and
additional services that (a) can fail, (b) don't share fate with the
endpoints and (c) are likely to be very sensitive to configuration
errors, all for the sake of some notion of architectural purity.

I won't claim that you can't do it, or that it's a fundamentally bad
idea on its face.  I *will* claim that it's a fundamentally bad idea if
you don't do very careful engineering on it to make sure that the
resulting system is as reliable was it would be without the extra layer
of indirection - and that includes accounting for the ability of people
to misconfigure things.

> Just think how much easier the IPv4 to IPv6 transition would have been if nothing above the IP layer cared
> exactly what an IP address looks like or how big it is.

It wouldn't have made much difference at all, partly because due to
other warts in the IPv6 architecture (like the desire to push the cost
of multihoming to all endpoints rather than the core [*]), applications
have even more need to deal directly with addresses in IPv6 than they do
in IPv4 - even in a pure IPv6 world.

The other reason it wouldn't have made much difference is because
transitioning applications to IPv6 is actually much easier than
transitioning networks.

Keith

[*] Not that I blame the routing guys for wanting to move the cost of
multihoming out of the core.  But pushing those costs onto hosts and
applications was moving those costs even further away from those who
benefit from multihoming, than was the case in IPv4.


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

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