Re: [OFF-PATH-BOF] SIP, naming, APIs and control

Melinda Shore <> Thu, 13 July 2006 18:12 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1G15g1-0001mG-Nz; Thu, 13 Jul 2006 14:12:41 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1G15g0-0001j4-B8 for; Thu, 13 Jul 2006 14:12:40 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1G15fy-0003Fb-1b for; Thu, 13 Jul 2006 14:12:40 -0400
Received: from ([]) by with ESMTP; 13 Jul 2006 14:12:38 -0400
X-IronPort-AV: i="4.06,238,1149480000"; d="scan'208"; a="92680391:sNHT25888188"
Received: from ( []) by ( with ESMTP id k6DICb1S010017; Thu, 13 Jul 2006 14:12:37 -0400
Received: from ( []) by (8.12.10/8.12.6) with ESMTP id k6DICb7t018440; Thu, 13 Jul 2006 14:12:37 -0400 (EDT)
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Jul 2006 14:12:37 -0400
Received: from ([]) by ([]) via Exchange Front-End Server ([]) with Microsoft Exchange Server HTTP-DAV ; Thu, 13 Jul 2006 18:12:37 +0000
User-Agent: Microsoft-Entourage/
Date: Thu, 13 Jul 2006 14:12:36 -0400
Subject: Re: [OFF-PATH-BOF] SIP, naming, APIs and control
From: Melinda Shore <>
To: Teemu Koponen <koponen@ICSI.Berkeley.EDU>, <>
Message-ID: <>
Thread-Topic: [OFF-PATH-BOF] SIP, naming, APIs and control
Thread-Index: Acamp+sOKaKWkBKbEduQ3AAKleNSdA==
In-Reply-To: <CA038C2C-5AD9-440E-889D-F86FBE678B55@ICSI.Berkeley.EDU>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 13 Jul 2006 18:12:37.0304 (UTC) FILETIME=[EBD5BB80:01C6A6A7]
DKIM-Signature: a=rsa-sha1; q=dns; l=2546; t=1152814357; x=1153678357; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;;; z=From:Melinda=20Shore=20<> |Subject:Re=3A=20[OFF-PATH-BOF]=20SIP, =20naming, =20APIs=20and=20control |To:Teemu=20Koponen=20<koponen@ICSI.Berkeley.EDU>,=20<>;; b=aB8uGeJMo0rKtuZzgZ/WSmhTup8j/63u3j+KCKAYfwlptCDhrT+GlY4WO2vesOuBTKWs8gMG WCSHoeBYHDZRBABPmniMsO0tDEJdf0UG05bpwUP1t9Evra/9OEa29yXb;
Authentication-Results:;; dkim=pass ( sig from verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "BOF: Path-decoupled Signaling for Data" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

On 7/13/06 1:35 PM, "Teemu Koponen" <koponen@ICSI.Berkeley.EDU> wrote:
> o) Mixing the needs to persistently identify an end-point for machines
> and for users was distracting.  I do not think hierarchical names
> should remain the sole option to consider. Flat names are rather
> attractive option indeed to identify end-points for machines. In fact,
> I think one should support both.

I think it's probably early to bog down in deployment issues, but
I do think it's worth mentioning deployment issues *un*related to
compatibility issues and I think this is one of them, for two

1) flat namespaces are just plain hard to manage, and
2) I'm not sure where Paul or anybody else stands on this
   but I've been laboring in these particular fields for a
   few years now and from my perspective the really hard problems
   relate to topology and "findability."  It's much harder to
   find your way around a flat namespace.

> The fundamental aspect I still do not understand is that how the
> decoupling of signaling and data paths helps at all. It strikes to be
> problem roaming only for me. (I think Bob Briscoe asked this without
> getting a decent answer.) I'm not sure whether I heard the word in
> some comment, but I think the group name misses a single word:
> control. This all is about getting the control back to the end-points
> and not that much about decoupling the paths.

When I first brought the proposal for on-path middlebox communication
to the IETF I described it as "topology insensitive," and I think that's
still the desired outcome.  However, what we've found over the past
few years is that on-path middlebox signaling is nearly impossible to deploy
in all but the most constrained networks.  I agree that focusing on
the question of whether or not the signaling is on-path or off-path
is largely orthogonal to the work that needs to be done, but by
now we know an awful lot about how to do both on-path and off-path
control/request/communications but not how to solve the extremely
difficult problems introduced by even modest topological complexity.
My opinion is that ultimately it's the path-decoupled stuff (I
guess "off-path" is kind of misleading in this context) that's going
to be *actually* useful in real networks, but obviously there's
not yet any consensus about this and some further discussion is
undoubtedly necessary.

But it is my feeling that the "control" aspect has kind of been done
to death and is well beyond the research stage.


OFF-PATH-BOF mailing list