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

Teemu Koponen <koponen@ICSI.Berkeley.EDU> Thu, 13 July 2006 18:59 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G16Pa-0007eN-Jj; Thu, 13 Jul 2006 14:59:46 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G16PZ-0007eD-14 for off-path-bof@ietf.org; Thu, 13 Jul 2006 14:59:45 -0400
Received: from nf-out-0910.google.com ([64.233.182.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G16PX-000821-OJ for off-path-bof@ietf.org; Thu, 13 Jul 2006 14:59:45 -0400
Received: by nf-out-0910.google.com with SMTP id l24so17101nfc for <off-path-bof@ietf.org>; Thu, 13 Jul 2006 11:59:42 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer:sender; b=YzNCxjr59wuourBcDPw+ZT9xBxbtm+JclcAP6F7DDZKHEcOp6qH9jnYTwP7o58aXwSfgxvWw99GBgFMbLCeNTRlukHHaaHVEBIFjBxzq+4guKLBuc2tEUs21dmry8gjf/djXkOYEqbS6d8VRVxsu6QxZQIXo1gJ+KvWXG3eAd8A=
Received: by 10.78.166.7 with SMTP id o7mr1121853hue; Thu, 13 Jul 2006 11:59:42 -0700 (PDT)
Received: from ?132.219.13.202? ( [132.219.13.202]) by mx.gmail.com with ESMTP id 20sm601344huf.2006.07.13.11.59.41; Thu, 13 Jul 2006 11:59:42 -0700 (PDT)
In-Reply-To: <C0DC0554.10CA3%mshore@cisco.com>
References: <C0DC0554.10CA3%mshore@cisco.com>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <DDEC28E4-2EFE-473A-8456-0633B55AABAA@ICSI.Berkeley.EDU>
Content-Transfer-Encoding: 7bit
From: Teemu Koponen <koponen@ICSI.Berkeley.EDU>
Subject: Re: [OFF-PATH-BOF] SIP, naming, APIs and control
Date: Thu, 13 Jul 2006 11:59:38 -0700
To: Melinda Shore <mshore@cisco.com>
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Cc: off-path-bof@ietf.org
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 Jul 13, 2006, at 11:12, Melinda Shore wrote:

> 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 believe everyone agrees on this; requiring middleboxes to be on the  
path complicates deployment. However, when questioning the point of  
decoupling signaling and data paths, I all the time assumed this  
combined data and signaling path to be different from a path routers  
give you. Is this what you mean or do you opt for three different  
paths: a router given, signaling, and data path?

> control/request/communications but not how to solve the extremely
> difficult problems introduced by even modest topological complexity.

Could you elaborate these difficult problems?

Teemu

--




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