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

Melinda Shore <mshore@cisco.com> Thu, 13 July 2006 18:12 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G15g1-0001mG-Nz; Thu, 13 Jul 2006 14:12:41 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G15g0-0001j4-B8 for off-path-bof@ietf.org; Thu, 13 Jul 2006 14:12:40 -0400
Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G15fy-0003Fb-1b for off-path-bof@ietf.org; Thu, 13 Jul 2006 14:12:40 -0400
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com 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 rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6DICb1S010017; Thu, 13 Jul 2006 14:12:37 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6DICb7t018440; Thu, 13 Jul 2006 14:12:37 -0400 (EDT)
Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Jul 2006 14:12:37 -0400
Received: from 10.86.115.66 ([10.86.115.66]) by xmb-rtp-205.amer.cisco.com ([64.102.31.59]) via Exchange Front-End Server email.cisco.com ([64.102.31.21]) with Microsoft Exchange Server HTTP-DAV ; Thu, 13 Jul 2006 18:12:37 +0000
User-Agent: Microsoft-Entourage/11.2.3.060209
Date: Thu, 13 Jul 2006 14:12:36 -0400
Subject: Re: [OFF-PATH-BOF] SIP, naming, APIs and control
From: Melinda Shore <mshore@cisco.com>
To: Teemu Koponen <koponen@ICSI.Berkeley.EDU>, <off-path-bof@ietf.org>
Message-ID: <C0DC0554.10CA3%mshore@cisco.com>
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; d=cisco.com; i=mshore@cisco.com; z=From:Melinda=20Shore=20<mshore@cisco.com> |Subject:Re=3A=20[OFF-PATH-BOF]=20SIP, =20naming, =20APIs=20and=20control |To:Teemu=20Koponen=20<koponen@ICSI.Berkeley.EDU>,=20<off-path-bof@ietf.org>; X=v=3Dcisco.com=3B=20h=3DX1X521665gjuB0ybUPJheZZiEaE=3D; b=aB8uGeJMo0rKtuZzgZ/WSmhTup8j/63u3j+KCKAYfwlptCDhrT+GlY4WO2vesOuBTKWs8gMG WCSHoeBYHDZRBABPmniMsO0tDEJdf0UG05bpwUP1t9Evra/9OEa29yXb;
Authentication-Results: rtp-dkim-1.cisco.com; header.From=mshore@cisco.com; dkim=pass ( sig from cisco.com verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
Cc:
X-BeenThere: off-path-bof@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "BOF: Path-decoupled Signaling for Data" <off-path-bof.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/off-path-bof>, <mailto:off-path-bof-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/off-path-bof>
List-Post: <mailto:off-path-bof@ietf.org>
List-Help: <mailto:off-path-bof-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/off-path-bof>, <mailto:off-path-bof-request@ietf.org?subject=subscribe>
Errors-To: off-path-bof-bounces@ietf.org

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
reasons:

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.

Melinda

_______________________________________________
OFF-PATH-BOF mailing list
OFF-PATH-BOF@ietf.org
https://www1.ietf.org/mailman/listinfo/off-path-bof