From architecture-discuss-bounces@ietf.org Wed Feb 15 11:19:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9PNB-0006Se-JG; Wed, 15 Feb 2006 11:19:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9PN9-0006NS-Hm for architecture-discuss@megatron.ietf.org; Wed, 15 Feb 2006 11:19:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29126 for ; Wed, 15 Feb 2006 11:17:33 -0500 (EST) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9Pb8-0002Wq-1i for architecture-discuss@ietf.org; Wed, 15 Feb 2006 11:33:50 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id DC2EC89938 for ; Wed, 15 Feb 2006 18:19:03 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 8E49389937 for ; Wed, 15 Feb 2006 18:19:03 +0200 (EET) Message-ID: <43F3548D.6030804@piuha.net> Date: Wed, 15 Feb 2006 18:19:25 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: architecture-discuss@ietf.org Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches References: <6.2.3.4.2.20060131132315.0681a460@mail.jefsey.com> In-Reply-To: <6.2.3.4.2.20060131132315.0681a460@mail.jefsey.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org Trying to summarize this old thread... I think we concluded the following: o Good architecture does not necessarily imply that we have exactly one solution for each individual component problem. However, for some parts of the stack having multiple solutions is easier than for others. For instance, there are many wireless link layers, and this diversity has generally been a good thing. For IP, this is more problematic, because it should be the layer that allows interneworking. Similar problems apply to any end-to-end protocol, though there might be a smaller population of users. Question: are there differences in the different parts of the IP layer, or do we expect it to provide the same universal service? For instance, today we can (most of the time) rely on getting the basic communication service, but finding a peer that supports a multihoming IP extension is very unlikely. Note that this isn't just a question of what new functions we should require IP to have. Its also about whether the old functions should continue to exist. In Eric's example there was a specific case where an existing function, multicast, no longer worked. Similarly, NATs have limited our ability to act both as servers as clients. o Minimization, and the waist of the IP hourglass. We seem to agree on that the core functionality needs to be small in order to maxime the ability to support the architecture in different systems and over time; minimality provides flexibility. Many people feel that we have lost the focus on the narrow waist. (Or are, say, IP layer extensions mostly additional functionality on top, and not a true part of the waist? See also above about the universal service.) o Striking the right balance between market driven development and architectural oversight is needed. But it is hard. o Architectural redesign is painful, and expensive in the short run. Local-tweaks look less expensive, because they are cheap in the short run. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Feb 15 11:51:34 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9PsL-0007d1-7u; Wed, 15 Feb 2006 11:51:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9PsJ-0007bs-GW for architecture-discuss@megatron.ietf.org; Wed, 15 Feb 2006 11:51:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10366 for ; Wed, 15 Feb 2006 11:49:44 -0500 (EST) Received: from rwcrmhc12.comcast.net ([216.148.227.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9Q6I-0006se-GN for architecture-discuss@ietf.org; Wed, 15 Feb 2006 12:06:00 -0500 Received: from s73602 (s73602.china.huawei.com[192.35.166.32]) by comcast.net (rwcrmhc12) with SMTP id <20060215165116m1200pv5a3e>; Wed, 15 Feb 2006 16:51:17 +0000 Message-ID: <025c01c6324f$d267eff0$0500a8c0@china.huawei.com> From: "Spencer Dawkins" To: References: <6.2.3.4.2.20060131132315.0681a460@mail.jefsey.com> <43F3548D.6030804@piuha.net> Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches Date: Wed, 15 Feb 2006 10:49:32 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org Hi, Jari, > Similarly, NATs have limited our ability to > act both as servers as clients. If I'm reading http://www1.ietf.org/mail-archive/web/sip/current/msg12820.html and the related thread correctly, it's also worth mentioning that NAT keepalives for VoIP look like a huge amount of overhead and are creating ugliness (well, of course you have to modify all of the implementations of any protocol that wants to keep its NAT bindings active, to switch on the keepalive packets correctly). This was pretty easy to ignore in a seriously client-server world (especially one where interesting servers were not behind NATs), but is now a lot harder to ignore in a peer-to-peer world (oh, you wanted to receive phone calls, too?)... Thanks, Spencer _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Feb 15 12:08:08 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Q8O-0005JY-D4; Wed, 15 Feb 2006 12:08:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Q8N-0005JP-Ec for architecture-discuss@megatron.ietf.org; Wed, 15 Feb 2006 12:08:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12591 for ; Wed, 15 Feb 2006 12:06:20 -0500 (EST) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9QMP-0007uk-U3 for architecture-discuss@ietf.org; Wed, 15 Feb 2006 12:22:39 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 60FA389938; Wed, 15 Feb 2006 19:07:56 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 17B4089937; Wed, 15 Feb 2006 19:07:56 +0200 (EET) Message-ID: <43F36001.2050109@piuha.net> Date: Wed, 15 Feb 2006 19:08:17 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Spencer Dawkins Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches References: <6.2.3.4.2.20060131132315.0681a460@mail.jefsey.com> <43F3548D.6030804@piuha.net> <025c01c6324f$d267eff0$0500a8c0@china.huawei.com> In-Reply-To: <025c01c6324f$d267eff0$0500a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org Spencer Dawkins wrote: > it's also worth mentioning that NAT keepalives for VoIP look like a > huge amount of overhead and are creating ugliness (well, of course you > have to modify all of the implementations of any protocol that wants > to keep its NAT bindings active, to switch on the keepalive packets > correctly). Indeed. And if you count what percentage of capacity this can take in a wireless network, you'll be surprised. Of course, this can probably be optimized somehow, the complexity can be hidden in a common protocol component, but still, it is one of the ugliest and most troublesome parts of the current network, IMHO. Its worth noting that there's no fundamental reason why this is so broken. Even if you were to accept the concept of a NAT (or a stateful firewall, for that matter; the problems are similar), an architectected design could have avoided keepalives in various ways. --Jari _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Feb 15 12:20:48 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9QDS-0007GZ-2P; Wed, 15 Feb 2006 12:13:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9QDQ-0007GE-K6 for architecture-discuss@megatron.ietf.org; Wed, 15 Feb 2006 12:13:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13167 for ; Wed, 15 Feb 2006 12:11:34 -0500 (EST) From: iain.campbell@symbian.com Received: from smtp01.symbian.com ([206.165.101.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9QRP-000899-8u for architecture-discuss@ietf.org; Wed, 15 Feb 2006 12:27:52 -0500 Received: from ([10.16.58.138]) by smtp01.symbian.com with ESMTP id KP-GCN69.15632601; Wed, 15 Feb 2006 17:12:42 0000 To: architecture-discuss@ietf.org Message-ID: Date: Wed, 15 Feb 2006 17:12:41 +0000 X-MIMETrack: Serialize by Router on LONMAILHUB02/LON/H/Symbian(Release 6.53HF119 | November 19, 2004) at 15/02/2006 17:12:41 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.5 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [arch-d] Iain Campbell/UK/Symbian is out of the office. X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org I will be out of the office starting 10/02/2006 and will not return until 20/02/2006. SMS or phone me if it's really urgent. ----------------------------------------- Don't miss out on your chance to...Do more with Symbian. Make sure you visit the Symbian Stand, B20, at 3GSM 2006, 13-16 February, Barcelona, Spain. ********************************************************************** Symbian Software Ltd is a company registered in England and Wales with registered number 4190020 and registered office at 2-6 Boundary Row, Southwark, London, SE1 8HP, UK. This message is intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify postmaster@symbian.com and delete the message and any attachments accompanying it immediately. Neither Symbian nor any of its Affiliates accepts liability for any corruption, interception, amendment, tampering or viruses occurring to this message in transit or for any message sent by its employees which is not in compliance with Symbian corporate policy. ********************************************************************** _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Feb 15 12:29:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9QTQ-0001oj-SU; Wed, 15 Feb 2006 12:29:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9QTP-0001oe-VE for architecture-discuss@megatron.ietf.org; Wed, 15 Feb 2006 12:29:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14858 for ; Wed, 15 Feb 2006 12:28:05 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9QhR-0000Ny-Al for architecture-discuss@ietf.org; Wed, 15 Feb 2006 12:44:23 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 15 Feb 2006 12:28:23 -0500 X-IronPort-AV: i="4.02,117,1139202000"; d="scan'208"; a="82466843:sNHT947277016" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k1FHS3Pa020457; Wed, 15 Feb 2006 12:28:20 -0500 (EST) Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Feb 2006 12:28:08 -0500 Received: from 10.21.121.50 ([10.21.121.50]) by xmb-rtp-205.amer.cisco.com ([64.102.31.59]) via Exchange Front-End Server email.cisco.com ([171.70.151.174]) with Microsoft Exchange Server HTTP-DAV ; Wed, 15 Feb 2006 17:28:07 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Wed, 15 Feb 2006 12:28:07 -0500 Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches From: Melinda Shore To: Jari Arkko , Spencer Dawkins Message-ID: Thread-Topic: [arch-d] Valid and Invalid Internet architectures and approaches Thread-Index: AcYyVS8SbWKNlp5IEdqqlQAKleNSdA== In-Reply-To: <43F36001.2050109@piuha.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 15 Feb 2006 17:28:08.0731 (UTC) FILETIME=[301ACEB0:01C63255] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org On 2/15/06 12:08 PM, "Jari Arkko" wrote: > Its worth noting that there's no fundamental reason why this is > so broken. Even if you were to accept the concept of a NAT (or > a stateful firewall, for that matter; the problems are similar), an > architectected design could have avoided keepalives in various > ways. We do have a handful of ways to communicate what we want directly to the NAT (RSIP, midcom, NSIS). It's hard to deploy, however, since they all assume that you've got capable NATs and, in the case of midcom and rsip, that you know where they are. They do not, however, require the use of keepalives or other behavior that's intended to influence the NAT by side-effect. What's happening instead is that applications people dealing with NAT traversal problems are putting together a set of procedures for inferring things about the behavior of NATs in your networks and where the application endpoints are in relation to the NATs. It's an unfortunate development in light of its nasty architecture, nasty messaging, and nasty security properties, but I suspect it was inevitable given deployment difficulties and various political problems. The firewall traversal problem is actually substantially different, and there's good reason to be concerned that some of the NAT traversal mechanisms under discussion are being adapted to solve firewall traversal. Because they work by side-effect rather than explicit request, they're effectively outsourcing border security policy enforcement to the application. Melinda _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Feb 15 13:01:14 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Qxm-0000oS-BA; Wed, 15 Feb 2006 13:01:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Qxk-0000oN-Vw for architecture-discuss@megatron.ietf.org; Wed, 15 Feb 2006 13:01:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18512 for ; Wed, 15 Feb 2006 12:59:26 -0500 (EST) From: john.loughney@nokia.com Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9RBo-00021P-QR for architecture-discuss@ietf.org; Wed, 15 Feb 2006 13:15:45 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k1FI0lfq021164; Wed, 15 Feb 2006 20:00:47 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Feb 2006 20:01:10 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Feb 2006 20:01:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Valid and Invalid Internet architectures and approaches Date: Wed, 15 Feb 2006 20:01:09 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01869C2A@esebe100.NOE.Nokia.com> In-Reply-To: <025c01c6324f$d267eff0$0500a8c0@china.huawei.com> Thread-Topic: [arch-d] Valid and Invalid Internet architectures and approaches Thread-Index: AcYyUHolO6sBgUt+Q2OL90byCTBctAACOoIw To: , X-OriginalArrivalTime: 15 Feb 2006 18:01:09.0619 (UTC) FILETIME=[CCCE5430:01C63259] X-Spam-Score: 0.3 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org Spencer, Jari, NAT signaling isn't just about signaling overhead, it's also about battery capacity. Depending upon how frequently you send keep-alives, you can really eat into battery capacity. Wireless is great, as long as you don't need to be plugged into a power outlet! Also, usage patterns are different. As an informal test for some other stuff I'm doing, I'm keeping track of my family's phone usage. My wife has the record, so far she has not turned off her phone for 179 days and counting (she has had to charge it a few times, though). If you imagine needing to run keep-alives=20 in order to be able to receive calls or message, that would be a lot of=20 keep-alives. John >-----Original Message----- >From: architecture-discuss-bounces@ietf.org=20 >[mailto:architecture-discuss-bounces@ietf.org] On Behalf Of=20 >ext Spencer Dawkins >Sent: 15 February, 2006 18:50 >To: architecture-discuss@ietf.org >Subject: Re: [arch-d] Valid and Invalid Internet architectures=20 >and approaches > >Hi, Jari, > >> Similarly, NATs have limited our ability to act both as servers as=20 >> clients. > >If I'm reading >http://www1.ietf.org/mail-archive/web/sip/current/msg12820.html > and the related thread correctly, it's also worth mentioning=20 >that NAT keepalives for VoIP look like a huge amount of=20 >overhead and are creating ugliness (well, of course you have=20 >to modify all of the implementations of any protocol that=20 >wants to keep its NAT bindings active, to switch on the=20 >keepalive packets correctly). > >This was pretty easy to ignore in a seriously client-server=20 >world (especially one where interesting servers were not=20 >behind NATs), but is now a lot harder to ignore in a=20 >peer-to-peer world (oh, you wanted to receive phone calls, too?)... > >Thanks, > >Spencer=20 > > > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www1.ietf.org/mailman/listinfo/architecture-discuss > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Feb 15 14:21:30 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9SDS-0006bl-OJ; Wed, 15 Feb 2006 14:21:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9SDR-0006aV-9p for architecture-discuss@megatron.ietf.org; Wed, 15 Feb 2006 14:21:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24869 for ; Wed, 15 Feb 2006 14:19:42 -0500 (EST) Received: from sccrmhc13.comcast.net ([204.127.200.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9SRT-00057b-UQ for architecture-discuss@ietf.org; Wed, 15 Feb 2006 14:36:02 -0500 Received: from [192.168.1.6] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc13) with ESMTP id <20060215192116013004e1lpe>; Wed, 15 Feb 2006 19:21:17 +0000 Message-ID: <43F37F7E.2020308@tony.li> Date: Wed, 15 Feb 2006 11:22:38 -0800 From: Tony Li User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Jari Arkko Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches References: <6.2.3.4.2.20060131132315.0681a460@mail.jefsey.com> <43F3548D.6030804@piuha.net> In-Reply-To: <43F3548D.6030804@piuha.net> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org Jari, Thanks for summarizing. > Question: are there differences in the different parts of the > IP layer, or do we expect it to provide the same universal > service? For instance, today we can (most of the time) > rely on getting the basic communication service, but finding > a peer that supports a multihoming IP extension is very > unlikely. Note that this isn't just a question of what new > functions we should require IP to have. Its also about whether > the old functions should continue to exist. In Eric's example > there was a specific case where an existing function, multicast, > no longer worked. Similarly, NATs have limited our ability to > act both as servers as clients. As with any good architecture, we need to have a very clear definition of what we expect a minimal implementation to provide. That minimum level of functionality defines the baseline of the architecture and so is key to defining the basic capabilities throughout the network. Any function that we feel should be pervasive (e.g., multihoming) should be intrinsic, not an optional extension. This is a bug in our current approach in that we have not only left out multihoming (and renumbering, etc.) but we have also failed to state what a minimal implementation truly is today. > o Minimization, and the waist of the IP hourglass. We seem to agree > on that the core functionality needs to be small in order to maxime > the ability to support the architecture in different systems and > over time; minimality provides flexibility. > > Many people feel that we have lost the focus on the narrow waist. > (Or are, say, IP layer extensions mostly additional functionality > on top, and not a true part of the waist? See also above about > the universal service.) This is just another way of complaining about the existence of MPLS. In truth, what we should be focusing on at the architectural level is to how IP should support connection-oriented services, complete with explicit path establishment. The fact that IPv4 cannot support this led to the creation of an alternative in the waist of the hourglass. Now, purists may claim that you don't ever want to support those services, but this does nothing for those folks who feel that they need/want them. Regards, Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Feb 16 00:21:06 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9bZi-0001wi-QG; Thu, 16 Feb 2006 00:21:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9bYX-00014H-Td for architecture-discuss@megatron.ietf.org; Thu, 16 Feb 2006 00:19:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13302 for ; Wed, 15 Feb 2006 23:25:48 -0500 (EST) From: john.loughney@nokia.com Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9axt-0002R7-KM for architecture-discuss@ietf.org; Wed, 15 Feb 2006 23:42:03 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k1G4Pn2r012009; Thu, 16 Feb 2006 06:25:49 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Feb 2006 06:25:44 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Feb 2006 06:25:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Valid and Invalid Internet architectures and approaches Date: Thu, 16 Feb 2006 06:25:43 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D01869C31@esebe100.NOE.Nokia.com> In-Reply-To: Thread-Topic: [arch-d] Valid and Invalid Internet architectures and approaches Thread-Index: AcYyVS8SbWKNlp5IEdqqlQAKleNSdAAW3POw To: , , X-OriginalArrivalTime: 16 Feb 2006 04:25:44.0748 (UTC) FILETIME=[0DB936C0:01C632B1] X-Spam-Score: 0.3 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org Hi Melinda & Jari, Things are also complicated by the fact that different protocols have different NAT traversal techniques, leading to the potential layering of different keep-alive solutions when running SIP over IPsec over MIP, for example (that is somewhat overkill, but I've been in some meetings where use cases that would require this functionality has been bandied about). Since NATs are non- transparent, it's impossible to really know how to traverse them before you try. I also agree with Melinda's comment on firewalls. John >-----Original Message----- >From: architecture-discuss-bounces@ietf.org=20 >[mailto:architecture-discuss-bounces@ietf.org] On Behalf Of=20 >ext Melinda Shore >Sent: 15 February, 2006 19:28 >To: Jari Arkko; Spencer Dawkins >Cc: architecture-discuss@ietf.org >Subject: Re: [arch-d] Valid and Invalid Internet architectures=20 >and approaches > >On 2/15/06 12:08 PM, "Jari Arkko" wrote: >> Its worth noting that there's no fundamental reason why this is so=20 >> broken. Even if you were to accept the concept of a NAT (or=20 >a stateful=20 >> firewall, for that matter; the problems are similar), an=20 >> architectected design could have avoided keepalives in various ways. > >We do have a handful of ways to communicate what we want=20 >directly to the NAT (RSIP, midcom, NSIS). It's hard to=20 >deploy, however, since they all assume that you've got capable=20 >NATs and, in the case of midcom and rsip, that you know where=20 >they are. They do not, however, require the use of keepalives=20 >or other behavior that's intended to influence the NAT by side-effect. > >What's happening instead is that applications people dealing=20 >with NAT traversal problems are putting together a set of=20 >procedures for inferring things about the behavior of NATs in=20 >your networks and where the application endpoints are in=20 >relation to the NATs. >It's an unfortunate development in light of its nasty=20 >architecture, nasty messaging, and nasty security properties,=20 >but I suspect it was inevitable given deployment difficulties=20 >and various political problems. > >The firewall traversal problem is actually substantially=20 >different, and there's good reason to be concerned that some=20 >of the NAT traversal mechanisms under discussion are being=20 >adapted to solve firewall traversal. Because they work by=20 >side-effect rather than explicit request, they're effectively=20 >outsourcing border security policy enforcement to the application. > >Melinda > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www1.ietf.org/mailman/listinfo/architecture-discuss > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Feb 17 10:39:48 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA728-0004pn-VU; Fri, 17 Feb 2006 09:56:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA6vh-0001Br-2q for architecture-discuss@megatron.ietf.org; Fri, 17 Feb 2006 09:49:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01640 for ; Fri, 17 Feb 2006 09:01:20 -0500 (EST) Received: from bj44-205.i.netease.com ([202.108.44.205] helo=163.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FA12p-0006bH-OD for architecture-discuss@ietf.org; Fri, 17 Feb 2006 03:32:59 -0500 Received: from swan18dbebf954 (unknown [211.69.207.226]) by smtp2 (Coremail) with SMTP id XMAWAO6F9UMdBBcA.39268S2; Fri, 17 Feb 2006 16:14:42 +0800 (CST) Message-ID: <000e01c6339a$af0701d0$3b62a8c0@swan18dbebf954> From: "Tian Chen" To: "Tony Li" References: <6.2.3.4.2.20060131132315.0681a460@mail.jefsey.com><43F3548D.6030804@piuha.net> <43F37F7E.2020308@tony.li> Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches Date: Fri, 17 Feb 2006 16:18:03 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.5 (++++) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1886784433==" Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org --===============1886784433== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlRvbnkgTGkiIDx0b255Lmxp QHRvbnkubGk+DQpUbzogIkphcmkgQXJra28iIDxqYXJpLmFya2tvQHBpdWhhLm5ldD4NCkNjOiA8 YXJjaGl0ZWN0dXJlLWRpc2N1c3NAaWV0Zi5vcmc+DQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkg MTYsIDIwMDYgMzoyMiBBTQ0KU3ViamVjdDogUmU6IFthcmNoLWRdIFZhbGlkIGFuZCBJbnZhbGlk IEludGVybmV0IGFyY2hpdGVjdHVyZXMgYW5kIGFwcHJvYWNoZXMNCg0KDQo+IA0KPiANCj4gSmFy aSwNCj4gDQo+IFRoYW5rcyBmb3Igc3VtbWFyaXppbmcuDQo+IA0KPj4gUXVlc3Rpb246IGFyZSB0 aGVyZSBkaWZmZXJlbmNlcyBpbiB0aGUgZGlmZmVyZW50IHBhcnRzIG9mIHRoZQ0KPj4gSVAgbGF5 ZXIsIG9yIGRvIHdlIGV4cGVjdCBpdCB0byBwcm92aWRlIHRoZSBzYW1lIHVuaXZlcnNhbA0KPj4g c2VydmljZT8gRm9yIGluc3RhbmNlLCB0b2RheSB3ZSBjYW4gKG1vc3Qgb2YgdGhlIHRpbWUpDQo+ PiByZWx5IG9uIGdldHRpbmcgdGhlIGJhc2ljIGNvbW11bmljYXRpb24gc2VydmljZSwgYnV0IGZp bmRpbmcNCj4+IGEgcGVlciB0aGF0IHN1cHBvcnRzIGEgbXVsdGlob21pbmcgSVAgZXh0ZW5zaW9u IGlzIHZlcnkNCj4+IHVubGlrZWx5LiBOb3RlIHRoYXQgdGhpcyBpc24ndCBqdXN0IGEgcXVlc3Rp b24gb2Ygd2hhdCBuZXcNCj4+IGZ1bmN0aW9ucyB3ZSBzaG91bGQgcmVxdWlyZSBJUCB0byBoYXZl LiBJdHMgYWxzbyBhYm91dCB3aGV0aGVyDQo+PiB0aGUgb2xkIGZ1bmN0aW9ucyBzaG91bGQgY29u dGludWUgdG8gZXhpc3QuIEluIEVyaWMncyBleGFtcGxlDQo+PiB0aGVyZSB3YXMgYSBzcGVjaWZp YyBjYXNlIHdoZXJlIGFuIGV4aXN0aW5nIGZ1bmN0aW9uLCBtdWx0aWNhc3QsDQo+PiBubyBsb25n ZXIgd29ya2VkLiBTaW1pbGFybHksIE5BVHMgaGF2ZSBsaW1pdGVkIG91ciBhYmlsaXR5IHRvDQo+ PiBhY3QgYm90aCBhcyBzZXJ2ZXJzIGFzIGNsaWVudHMuDQo+IA0KPiBBcyB3aXRoIGFueSBnb29k IGFyY2hpdGVjdHVyZSwgd2UgbmVlZCB0byBoYXZlIGEgdmVyeSBjbGVhciBkZWZpbml0aW9uDQo+ IG9mIHdoYXQgd2UgZXhwZWN0IGEgbWluaW1hbCBpbXBsZW1lbnRhdGlvbiB0byBwcm92aWRlLiAg VGhhdCBtaW5pbXVtDQo+IGxldmVsIG9mIGZ1bmN0aW9uYWxpdHkgZGVmaW5lcyB0aGUgYmFzZWxp bmUgb2YgdGhlIGFyY2hpdGVjdHVyZSBhbmQgc28NCj4gaXMga2V5IHRvIGRlZmluaW5nIHRoZSBi YXNpYyBjYXBhYmlsaXRpZXMgdGhyb3VnaG91dCB0aGUgbmV0d29yay4gIEFueQ0KPiBmdW5jdGlv biB0aGF0IHdlIGZlZWwgc2hvdWxkIGJlIHBlcnZhc2l2ZSAoZS5nLiwgbXVsdGlob21pbmcpIHNo b3VsZCBiZQ0KPiBpbnRyaW5zaWMsIG5vdCBhbiBvcHRpb25hbCBleHRlbnNpb24uICBUaGlzIGlz IGEgYnVnIGluIG91ciBjdXJyZW50DQo+IGFwcHJvYWNoIGluIHRoYXQgd2UgaGF2ZSBub3Qgb25s eSBsZWZ0IG91dCBtdWx0aWhvbWluZyAoYW5kIHJlbnVtYmVyaW5nLA0KPiBldGMuKSBidXQgd2Ug aGF2ZSBhbHNvIGZhaWxlZCB0byBzdGF0ZSB3aGF0IGEgbWluaW1hbCBpbXBsZW1lbnRhdGlvbg0K PiB0cnVseSBpcyB0b2RheS4NCg0KSU1ITywgbWluaW1hbCBpbXBsZW1lbnRhdGlvbiBvZiBvdXIg Y3VycmVudCBhcHByb2FjaCBpcyBqdXN0IGFuZCBzaG91bGQgYmUgYQ0KImJhc2ljIGNvbW11bmlj YXRpb24gc2VydmljZSIuICBJIGRvbid0IHRoaW5rIHRoaXMgaXMgYSBidWcuIElmIHNvbWUgbm9k ZXMgbmVlZCBuZXcgZnVuY3Rpb25zIA0KKGUuZy4sIG11bHRpaG9taW5nLG1vYmlsaXR5LCBpZGVu dGlmaWNhdGlvbiksICAgdGhleSBjb3VsZCBmYXQgdGhlaXIgb3duIHdhaXN0cyBvZiB0aGUgSVAg aG91cmdsYXNzIHdpdGggDQpzcGVjaWFsIGJhZ3MoZS5nLlNISU0sTUlQLEhJUCBlLnQuYyksICAg YW5kIHRoZXNlIGFyZSB0aGUgY29zdCAqbXVzdCogYmUgcGFpZGVkIGZvciB0aGVpcg0KbmV3IGZ1 bmN0aW9ucy4gV2hpbGUgb3RoZXIgc3RhdGljIG5vZGVzIGNvdWxkIHN0aWxsIG1haW50YWluIHRo ZWlyIHRoaW4tc2ltcGxlIElQIHdhaXN0IA0Kd2l0aG91dCBiZWluZyBib3RoZXJlZC4gKFRob3Nl ICBub2RlcyBjb3VsZCBjb21tdW5pY2F0ZSB3aXRoIGVhY2ggb3RoZXIgaW4gc29tZSANCk1JUCBz aW1pbGFyIG1lY2hhbm5pc20gaW4gdGhlIGNvc3Qgb2YgYmFuZHdpZHRoL2VmZmljaWVuY3kpLiBT byBpZiB0aGVyZSBpcyAiZmVhdHVyZSBjYW5jZXIiLA0Kb25seSB3aG8gY2FycmllZCBiYWdzIGRp ZS4NCg0KQnkga2VlcGluZyBiYWNrd2FyZCBjb21waXRpYmxpdHksIFNISU02K0NHQShvciBvdGhl ciBzaW1pbGFyIGFwcHJvYWNoZXMpIHdvdWxkIGJlIGF0IGxlYXN0IA0KYSBtaWRkbGUtdGVybSBz b2x1dGlvbiB0byBhcmNoaXRlY3V0cmUgaXNzdWVzIGFuZCBlbWVyZ2VudCBpbmR1c3RpYWwgbmVl ZHMuIEFzIFBla2thIE5pa2thbmRlciBzYWlkLCANCmNvdWxkIHdlIGRlc2lnbiBhIHdheSB0b3dh cmRzIGNvbnZlcmdpbmcgc29sdXRpb25zPyAgSW5zdGVhZCBvZiBsZXQgbWFueSBkaXN0aW5jdCBh cHByb2FjaGVzIGdyb3cgDQp1cCBmb3IgZWFjaCBmdWNudGlvbiwgdGh1cyBtYXkgcHJldmVudCAg dGhvc2UgYmFncyBmcm9tIGJlaW5nICJmZWF0dXJlIGNhbmNlciIsb3IgYXQgbGVhc3QgbWFrZSBu b2RlcyANCmxpdmUgbG9uZ2VyIDopDQoNCkkgYWdyZWUgd2l0aCB5b3UgdGhhdCBpbiB0aGUgbG9u Zy1ydW4gdGhlIGNvbW11bml0eSBtYXkgbmVlZCBhIG5ldyBhcmNoaXRlY3R1cmUsIGFuZCAiYW55 IGZ1bmN0aW9uIA0KdGhhdCB3ZSBmZWVsIHNob3VsZCBiZSBwZXJ2YXNpdmUgc2hvdWxkIGJlIGlu dHJpbnNpYywgbm90IGFuIG9wdGlvbmFsIGV4dGVuc2lvbiIuICBJIHN1Z2dlc3Qgd2UgZG8gbWlk ZGxlLXRlcm0gDQpzb2x1dGlvbiBhbmQgbG9uZy1ydW4gIGFyY2hpdGVjdHVyZSBpbiBwYXJhbGxl bC4gQnV0IGJvdGggc2hvdWxkIGJlIGJhY2t3YXJkIGNvbXBpdGlibGUgYXQgbGVhc3Qgd2l0aCAN CmNvbW1vbiBzdGF0aWMgSVBWNiBub2Rlcy4NCg== --===============1886784433== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============1886784433==-- From architecture-discuss-bounces@ietf.org Fri Feb 17 13:07:09 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAA0b-0000mH-4b; Fri, 17 Feb 2006 13:07:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAA0Y-0000lr-Uq for architecture-discuss@megatron.ietf.org; Fri, 17 Feb 2006 13:07:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17953 for ; Fri, 17 Feb 2006 13:05:19 -0500 (EST) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAAEy-0008IB-98 for architecture-discuss@ietf.org; Fri, 17 Feb 2006 13:22:04 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52) id 1FAA0R-00055e-A7; Fri, 17 Feb 2006 10:06:59 -0800 Message-Id: <6.2.3.4.2.20060217175004.05a981f0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Fri, 17 Feb 2006 19:06:55 +0100 To: "Tian Chen" , "Tony Li" From: "JFC (Jefsey) Morfin" Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches In-Reply-To: <000e01c6339a$af0701d0$3b62a8c0@swan18dbebf954> References: <6.2.3.4.2.20060131132315.0681a460@mail.jefsey.com> <43F3548D.6030804@piuha.net> <43F37F7E.2020308@tony.li> <000e01c6339a$af0701d0$3b62a8c0@swan18dbebf954> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-69A1786E X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org At 09:18 17/02/2006, Tian Chen wrote: >I agree with you that in the long-run the community may need a new >architecture, and "any function that we feel should be pervasive >should be intrinsic, not an optional extension". I suggest we do >middle-term solution and long-run architecture in parallel. But >both should be backward compitible at least with common static IPV6 nodes. %100 agree. But this calls for an architectural model of the ways (plural) to use that KISS basic solutions to build as many externets (independent external netwok look-alike within the same digital ecosystem) as people need. Parallel, converging or transitionning. IMHO this calls for a user-centric (minimum granularity) multi-technology architecture based upon a structured stable address geography, independent from technologies. This is what I said I expected from this mailing list. However the simplification makes many things currently embedded into the protocol stack to be supported at an 8th level interoperation layer. This means that eventually the applications may stay compatible (and new ones to be more powerful) transparently to the lower layers reshuffling. So transition is OK and hybrid network level solutions are able to be easily welcome. I expect service continuity, multilingualisation, spaces of exchanges, trust and services, mobility, security, etc. to be supported that way. I think we should therefore not discuss (existing) protocols but functions. Like talking of word processing on a PC rather than Word, Open Office, etc. There may be different releases, solutions, etc. The network should be independent to its inteoperation system. Question is (previous mail) to indentify the features that interoperation system needs and see how IP support them (and how other protocols we may have to use in parallel use them - in particular in Space [which is a way to say sure sending, FEC etc. included] with applications everywhere). jfc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Feb 17 13:15:31 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAA8h-0005GF-Rs; Fri, 17 Feb 2006 13:15:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAA8f-0005G0-S8 for architecture-discuss@megatron.ietf.org; Fri, 17 Feb 2006 13:15:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18464 for ; Fri, 17 Feb 2006 13:13:42 -0500 (EST) Received: from sccrmhc14.comcast.net ([204.127.200.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAAN5-00009j-8y for architecture-discuss@ietf.org; Fri, 17 Feb 2006 13:30:27 -0500 Received: from [192.168.1.6] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc14) with ESMTP id <2006021718150001400cnud8e>; Fri, 17 Feb 2006 18:15:15 +0000 Message-ID: <43F612F2.5070801@tony.li> Date: Fri, 17 Feb 2006 10:16:18 -0800 From: Tony Li User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Tian Chen Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches References: <6.2.3.4.2.20060131132315.0681a460@mail.jefsey.com><43F3548D.6030804@piuha.net> <43F37F7E.2020308@tony.li> <000e01c6339a$af0701d0$3b62a8c0@swan18dbebf954> In-Reply-To: <000e01c6339a$af0701d0$3b62a8c0@swan18dbebf954> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org Tian, > IMHO, minimal implementation of our current approach is just and should be a > "basic communication service". I don't think this is a bug. If some nodes need new functions > (e.g., multihoming,mobility, identification), they could fat their own waists of the IP hourglass with > special bags(e.g.SHIM,MIP,HIP e.t.c), and these are the cost *must* be paided for their > new functions. While other static nodes could still maintain their thin-simple IP waist > without being bothered. (Those nodes could communicate with each other in some > MIP similar mechannism in the cost of bandwidth/efficiency). So if there is "feature cancer", > only who carried bags die. Well, that's certainly a self-consistent point of view, but it begs the question as to whether we can ever make any architectural changes. In fact, if the only possible additions are by bags on the side, then I'd argue that the only functions being added are features and not intrinsic to the architecture. Thus, the question really comes down to whether or not we feel we need architectural changes. > By keeping backward compitiblity, SHIM6+CGA(or other similar approaches) would be at least > a middle-term solution to architecutre issues and emergent industial needs. As Pekka Nikkander said, > could we design a way towards converging solutions? Instead of let many distinct approaches grow > up for each fucntion, thus may prevent those bags from being "feature cancer",or at least make nodes > live longer :) > > I agree with you that in the long-run the community may need a new architecture, and "any function > that we feel should be pervasive should be intrinsic, not an optional extension". I suggest we do middle-term > solution and long-run architecture in parallel. But both should be backward compitible at least with > common static IPV6 nodes. It's an interesting thought, but so far we seem to have a strongly allergic reaction to the thought of architectural changes in mid-flight in the name of preserving the 'installed base' [sic] of v6 implementations. IMHO, this is a fatal limitation that hobbles the evolution of the network. Consider the number of in-flight changes made to v4 that quickly were adopted as intrinsic portions of the architecture (e.g., subnetting, CIDR, DiffServ). This seems to leave us in a position where we have passed the point of accepting any substantive architectural changes. This makes the discussion (and indeed, the entire mailing list) rather moot. Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Feb 17 16:58:38 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FADcc-0006Ue-CE; Fri, 17 Feb 2006 16:58:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FADca-0006UQ-Ui for architecture-discuss@megatron.ietf.org; Fri, 17 Feb 2006 16:58:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17407 for ; Fri, 17 Feb 2006 16:56:47 -0500 (EST) Received: from e1.ny.us.ibm.com ([32.97.182.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FADr5-000519-IO for architecture-discuss@ietf.org; Fri, 17 Feb 2006 17:13:36 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k1HLwQBd004477 for ; Fri, 17 Feb 2006 16:58:26 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k1HLwQGK227766 for ; Fri, 17 Feb 2006 16:58:26 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k1HLwQH0020541 for ; Fri, 17 Feb 2006 16:58:26 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-76-156-8.mts.ibm.com [9.76.156.8]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k1HLwPXM020514; Fri, 17 Feb 2006 16:58:25 -0500 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id k1HLwOIn006725; Fri, 17 Feb 2006 16:58:24 -0500 Message-Id: <200602172158.k1HLwOIn006725@cichlid.raleigh.ibm.com> To: Tony Li Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches In-Reply-To: Message from Tony Li of "Fri, 17 Feb 2006 10:16:18 PST." <43F612F2.5070801@tony.li> Date: Fri, 17 Feb 2006 16:58:24 -0500 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org > It's an interesting thought, but so far we seem to have a strongly > allergic reaction to the thought of architectural changes in mid-flight > in the name of preserving the 'installed base' [sic] of v6 > implementations. This is simply being pragmatic. One simply can't do fork-lift upgrades that have significant cost and flag days. No one is willing to do this. (This is a general statement and has nothing to do with IPv6 per se. And while one can argue there is little "installed base" of IPv6 at one level, at another level there is --- in the sense of products in the pipeline, etc. That is "installed base" because you can't turn it off or pull it out of the pipeline, etc.) The fact is we have a system today that people use/depend on. Talking about "architectural change" in the abstract isn't useful. You need to talk about a specific point you want to get to (i.e., a new protocol), that has compelling value once there, and a credible transition plan on how to get from here to there. That is the simple reality of trying to make changes to infrastructure. > IMHO, this is a fatal limitation that hobbles the evolution of the > network. Consider the number of in-flight changes made to v4 that > quickly were adopted as intrinsic portions of the architecture > (e.g., subnetting, CIDR, DiffServ). But they were possible because there was a credible transition strategy for how to deploy, that did not require unworkable flag days and fork lift upgrades. It has nothing to do with being an architectural change (or not). (And Diffserv is an architectural change?) > This seems to leave us in a position where we have passed the point of > accepting any substantive architectural changes. I don't agre with this conclusion. But IMO, it's not terribly useful to talk about architecture in an abstract sense. Architecture is a bit like art -- you know good architecture when you see it, but it's really hard to define. It has to do with how a big complex system (protocol suite) is componentized into separate, managable pieces, where the parts fit together cleanly and with good abstract interfaces, there is an overall simplicity and coherency, and so forth. > This makes the discussion (and indeed, the entire mailing list) > rather moot. Perhaps. I too get frustrated with abstract discussions about architecture, as I don't see what it will lead to. Thomas _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Feb 17 17:24:30 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAE1e-0005WT-Oz; Fri, 17 Feb 2006 17:24:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAE1d-0005US-B1 for architecture-discuss@megatron.ietf.org; Fri, 17 Feb 2006 17:24:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19719 for ; Fri, 17 Feb 2006 17:22:40 -0500 (EST) Received: from aharp.ittns.northwestern.edu ([129.105.153.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAEG9-0006BN-7H for architecture-discuss@ietf.org; Fri, 17 Feb 2006 17:39:29 -0500 Received: by aharp.ittns.northwestern.edu (smtpd, from userid 1001) id 25CDF136C82; Fri, 17 Feb 2006 16:24:20 -0600 (CST) Date: Fri, 17 Feb 2006 16:24:20 -0600 From: John Kristoff To: architecture-discuss@ietf.org Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches Message-ID: <20060217222420.GA22629@aharp> References: <43F612F2.5070801@tony.li> <200602172158.k1HLwOIn006725@cichlid.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200602172158.k1HLwOIn006725@cichlid.raleigh.ibm.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org On Fri, Feb 17, 2006 at 04:58:24PM -0500, Thomas Narten wrote: > > IMHO, this is a fatal limitation that hobbles the evolution of the > > network. Consider the number of in-flight changes made to v4 that > > quickly were adopted as intrinsic portions of the architecture > > (e.g., subnetting, CIDR, DiffServ). > > But they were possible because there was a credible transition > strategy for how to deploy, that did not require unworkable flag days > and fork lift upgrades. It has nothing to do with being an > architectural change (or not). (And Diffserv is an architectural > change?) Or quickly adopted for that matter? :-) John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Feb 17 23:07:46 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAJNp-00086U-S2; Fri, 17 Feb 2006 23:07:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAJNl-00084C-BM for architecture-discuss@megatron.ietf.org; Fri, 17 Feb 2006 23:07:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17971 for ; Fri, 17 Feb 2006 23:05:51 -0500 (EST) Received: from sccrmhc14.comcast.net ([63.240.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAJcJ-0005Aa-5C for architecture-discuss@ietf.org; Fri, 17 Feb 2006 23:22:43 -0500 Received: from [192.168.1.6] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc14) with ESMTP id <2006021804071401400e3cene>; Sat, 18 Feb 2006 04:07:29 +0000 Message-ID: <43F69DC1.5040805@tony.li> Date: Fri, 17 Feb 2006 20:08:33 -0800 From: Tony Li User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Thomas Narten Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches References: <200602172158.k1HLwOIn006725@cichlid.raleigh.ibm.com> In-Reply-To: <200602172158.k1HLwOIn006725@cichlid.raleigh.ibm.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org Thomas, Architectural proposals have been lofted. They were specific, had clear migration plans, and the discussion was shut down with the usual "v6 has already shipped" dogma. Specific topics were: - GSE (more generally locator/identifier splits) - locator agile transport protocols Without these types of capabilities, the architecture is stuck supporting multihoming and mobility with kludges such as NAT, SHIM6 (NAT in the host), and various forms of tunneling. To truly move forward, we first need to have consensus on the following: - We have a problem. - The current crop of solutions are unsatisfactory. - We are willing to make changes. Until then, we have the status quo. Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Feb 17 23:23:11 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAJcl-0006AP-Mg; Fri, 17 Feb 2006 23:23:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAJck-0006AK-2X for architecture-discuss@megatron.ietf.org; Fri, 17 Feb 2006 23:23:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18757 for ; Fri, 17 Feb 2006 23:21:20 -0500 (EST) Received: from sa.vix.com ([204.152.187.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAJrG-0005ZO-Mh for architecture-discuss@ietf.org; Fri, 17 Feb 2006 23:38:13 -0500 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 66D2011427 for ; Sat, 18 Feb 2006 04:22:58 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: architecture-discuss@ietf.org Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches In-Reply-To: Your message of "Fri, 17 Feb 2006 20:08:33 PST." <43F69DC1.5040805@tony.li> References: <200602172158.k1HLwOIn006725@cichlid.raleigh.ibm.com> <43F69DC1.5040805@tony.li> Date: Sat, 18 Feb 2006 04:22:58 +0000 Message-Id: <20060218042258.66D2011427@sa.vix.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org # To truly move forward, we first need to have consensus on the following: # # - We have a problem. # - The current crop of solutions are unsatisfactory. # - We are willing to make changes. # # Until then, we have the status quo. since a reality tv show just occurred in my office about this, i'll share it. the sysadmins here (isc) just came into my office and said "so what do you want to do about ipv6 address space in amsterdam?" we're going to open a "mirror site" there this year, with the usual diverse transit and peering and so on. i was asked "can we carve a /48 out of our ipv6 /32?" and i said "only if you're going to cut it in half and only advertise the bottom /33 from california". i don't, you see, want to advertise both a cutout AND a covering route unless i have a backbone, and i don't have a backbone to amsterdam, and i don't wish to pretend i do (using tunnels). they said "no, we can't do that" (for various reasons). i was asked "should we just get address space from each of our transits there, and multihome all of our hosts?" i said "if you're willing to have five or ten addresses per interface, and deal with the fact that the little itty bitty SYN and ACK packets will come to you via diverse transit, but all of your big gigantic FTP and WWW packets will go out via a single default route, sure." they said "no, we can't do that" (for various reasons). so, for now, isc-amsterdam will not speak ipv6. which is a pity, since we've got compelling content that the R&E community _loves_. i'm waiting to see how the current ARIN PPML discussion around "IPv6 PI space for multihomers" comes out. perhaps we'll get a /32 or /48 or /64 or whatever, and burn a slot in every routing table on the internet just to make ourselves reachable. (for isc, it's not about provider lock-in, it's about making it work at all.) in other words, i'm in favour of tony's first two assertions: # - We have a problem. # - The current crop of solutions are unsatisfactory. # - We are willing to make changes. i cannot, alas, speak for the third one. (the rest of you could, though.) note that some time after we solve this for amsterdam, we'll have to deal with chicago by the same means (whatever those are). an architecture that leads even technically advanced early adopters toward nondeployment seems "somewhat flawed" or at least "wanting more". _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Feb 17 23:25:25 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAJev-0006bT-JW; Fri, 17 Feb 2006 23:25:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAJeu-0006aj-Ho for architecture-discuss@megatron.ietf.org; Fri, 17 Feb 2006 23:25:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18850 for ; Fri, 17 Feb 2006 23:23:34 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAJtS-0005cH-87 for architecture-discuss@ietf.org; Fri, 17 Feb 2006 23:40:27 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 17 Feb 2006 20:25:15 -0800 X-IronPort-AV: i="4.02,126,1139212800"; d="scan'208"; a="256312483:sNHT31403256" Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k1I4PBZC024021; Fri, 17 Feb 2006 20:25:11 -0800 (PST) Received: from [10.32.244.221] (stealth-10-32-244-221.cisco.com [10.32.244.221]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k1I4S9w6026117; Fri, 17 Feb 2006 20:28:09 -0800 In-Reply-To: <43F69DC1.5040805@tony.li> References: <200602172158.k1HLwOIn006725@cichlid.raleigh.ibm.com> <43F69DC1.5040805@tony.li> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches Date: Fri, 17 Feb 2006 20:25:08 -0800 To: Tony Li X-Mailer: Apple Mail (2.746.2) DKIM-Signature: a=rsa-sha1; q=dns; l=822; t=1140236889; x=1140669089; c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20[arch-d]=20Valid=20and=20Invalid=20Internet=20architectures=20an d=20approaches |To:Tony=20Li=20; X=v=3Dmtcc.com=3B=20h=3D0gWNlcpU/vIxo5EaF7E925OaXMo=3D; b=IQq15Glk61q6IkwMPqlqfhk7VdVcTLuYRq6PUE1HnuZfqbAL2TOp6sBVBctYlpO9GvdIDNc/ BxMEd9Ut/kUOYDl7mxsWSKKHcFn5MKLM02wOy8jKxrSZpK5wY+bZJvQcBpxw87Xr2lsesVuQYDi xbEOo1Ga+rlI4CYtuKTAsllQ=; Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org very much agree. On Feb 17, 2006, at 8:08 PM, Tony Li wrote: > Architectural proposals have been lofted. They were specific, had > clear > migration plans, and the discussion was shut down with the usual > "v6 has > already shipped" dogma. Specific topics were: > > - GSE (more generally locator/identifier splits) > - locator agile transport protocols > > Without these types of capabilities, the architecture is stuck > supporting multihoming and mobility with kludges such as NAT, SHIM6 > (NAT > in the host), and various forms of tunneling. > > To truly move forward, we first need to have consensus on the > following: > > - We have a problem. > - The current crop of solutions are unsatisfactory. > - We are willing to make changes. > > Until then, we have the status quo. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Feb 17 23:56:23 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAK8t-0003ij-4I; Fri, 17 Feb 2006 23:56:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAK8r-0003id-Ps for architecture-discuss@megatron.ietf.org; Fri, 17 Feb 2006 23:56:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19900 for ; Fri, 17 Feb 2006 23:54:32 -0500 (EST) Received: from pop-gadwall.atl.sa.earthlink.net ([207.69.195.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAKNM-0006lj-OI for architecture-discuss@ietf.org; Sat, 18 Feb 2006 00:11:25 -0500 Received: from h-64-105-34-218.snvacaid.dynamic.covad.net ([64.105.34.218] helo=oemcomputer) by pop-gadwall.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1FAGMt-00036G-00 for architecture-discuss@ietf.org; Fri, 17 Feb 2006 19:54:35 -0500 Message-ID: <001e01c63426$1bc477e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <200602172158.k1HLwOIn006725@cichlid.raleigh.ibm.com> Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches Date: Fri, 17 Feb 2006 16:56:09 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org Hi - > From: "Thomas Narten" > To: "Tony Li" > Cc: > Sent: Friday, February 17, 2006 1:58 PM > Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches ... > > This makes the discussion (and indeed, the entire mailing list) > > rather moot. > > Perhaps. I too get frustrated with abstract discussions about > architecture, as I don't see what it will lead to. ... Getting even more abstact... Architectural change could also be a change to our understanding of, and how we talk about, what we already have. It may even be useful to have multiple architectural perspectives, just as classical physics continues to be useful for describing some things, even though when we also employ quantum physics every day. Which perspectives are used can impact whether a particular problem's solution seems simple or complicated, central or peripheral. Randy _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Feb 18 04:34:10 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAOTh-0007mB-Uv; Sat, 18 Feb 2006 04:34:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAOTd-0007m5-UQ for architecture-discuss@megatron.ietf.org; Sat, 18 Feb 2006 04:34:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03365 for ; Sat, 18 Feb 2006 04:32:16 -0500 (EST) Received: from zz-9-193-a8.bta.net.cn ([202.108.9.193] helo=163.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FAOi9-0008QV-06 for architecture-discuss@ietf.org; Sat, 18 Feb 2006 04:49:11 -0500 Received: from swan18dbebf954 (unknown [211.69.207.226]) by smtp14 (Coremail) with SMTP id C8D1APvp9kOP7eQA.11586S2; Sat, 18 Feb 2006 17:33:50 +0800 (CST) Message-ID: <008001c6346e$795972f0$3b62a8c0@swan18dbebf954> From: "Tian Chen" To: "Tony Li" , "Thomas Narten" References: <200602172158.k1HLwOIn006725@cichlid.raleigh.ibm.com> <43F69DC1.5040805@tony.li> Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches Date: Sat, 18 Feb 2006 17:34:04 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.5 (++++) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2093989730==" Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org --===============2093989730== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 ICJUb255IExpIiB3cm90ZQ0KPiANCj4gDQo+IFRob21hcywNCj4gDQo+IEFyY2hpdGVjdHVyYWwg cHJvcG9zYWxzIGhhdmUgYmVlbiBsb2Z0ZWQuICBUaGV5IHdlcmUgc3BlY2lmaWMsIGhhZCBjbGVh cg0KPiBtaWdyYXRpb24gcGxhbnMsIGFuZCB0aGUgZGlzY3Vzc2lvbiB3YXMgc2h1dCBkb3duIHdp dGggdGhlIHVzdWFsICJ2NiBoYXMNCj4gYWxyZWFkeSBzaGlwcGVkIiBkb2dtYS4gIFNwZWNpZmlj IHRvcGljcyB3ZXJlOg0KPiANCj4gLSBHU0UgKG1vcmUgZ2VuZXJhbGx5IGxvY2F0b3IvaWRlbnRp ZmllciBzcGxpdHMpDQo+IC0gbG9jYXRvciBhZ2lsZSB0cmFuc3BvcnQgcHJvdG9jb2xzDQo+IA0K PiBXaXRob3V0IHRoZXNlIHR5cGVzIG9mIGNhcGFiaWxpdGllcywgdGhlIGFyY2hpdGVjdHVyZSBp cyBzdHVjaw0KPiBzdXBwb3J0aW5nIG11bHRpaG9taW5nIGFuZCBtb2JpbGl0eSB3aXRoIGtsdWRn ZXMgc3VjaCBhcyBOQVQsIFNISU02IChOQVQNCj4gaW4gdGhlIGhvc3QpLCBhbmQgdmFyaW91cyBm b3JtcyBvZiB0dW5uZWxpbmcuDQo+IA0KPiBUbyB0cnVseSBtb3ZlIGZvcndhcmQsIHdlIGZpcnN0 IG5lZWQgdG8gaGF2ZSBjb25zZW5zdXMgb24gdGhlIGZvbGxvd2luZzoNCj4gDQo+IC0gV2UgaGF2 ZSBhIHByb2JsZW0uDQo+IC0gVGhlIGN1cnJlbnQgY3JvcCBvZiBzb2x1dGlvbnMgYXJlIHVuc2F0 aXNmYWN0b3J5Lg0KPiAtIFdlIGFyZSB3aWxsaW5nIHRvIG1ha2UgY2hhbmdlcy4NCg0KSSdtIGFs c28gaW4gZmF2b3VyIG9mIHRvbnkncyBmaXJzdCB0d28gYXNzZXJ0aW9ucywgYW5kIG5vdCBzcGVh ayBmb3IgdGhlIHRoaXJkIG9uZS4NClllcywgY3VycmVudCBJUHY2ICBhcmNoaXRlY3R1cmUgaXMg InNvbWV3aGF0IGZsYXdlZCIuIExldCBtZSBtYWtlIGEgY29tcGFyaXNpb24uDQpIZShJUHY2ICkg aXMgIGFscmVhZHkgYW4gaW5mYW50IG5vdywgbm90IGFuIGVtYnJ5bzsgd2UganVzdCBjYW4ndCBy ZXR1cm4gaGltIGJhY2sgdG8gdGhlDQp1dGVydXMgYW5kIHJlLXByZWduYW50IGFub3Rob3IgYmV0 dGVyIG9uZSwgYmVjYXVzZSBoZSBpcyBhbHJlYWR5IGJlIHJlY29nbml6ZWQgYnkgdGhlIHB1Ymxp Yy4NCkFuZCwgSVB2NCBpcyBydW5uaW5nIG91dCwgdGltZSBpcyB1cCwgdGhlIHRvcmNoIGhhdmUg dG8gYmUgcGFzc2VkIHRvIHRoaXMgbmV3IGdlbmVyYXRpb24gb2YgSVAgDQooZXZlbiBoZSBpcyBz b21ld2hhdCBmbGF3ZWQpIC4gV2hhdCB3ZSBjb3VsZCBkbyBub3cgaXMgbWFrZSBzb21lIHJlbWVk aWVzKG9yIGtsdWRnZSxiYWcsIA0KY2FuY2VyLCB3aGF0IGV2ZXIgeW91IHdhbnQgdG8gY2FsbCAp IHRvIGhlbHAgdGhpcyBiYWJ5IGZhY2luZyBuZXcgY2hhbGxlbmdlcywgYW5kIHN0YXJ0IHByb2R1 Y2UgDQphIHN1Y2Nlc3Nvci4gVGhhdCdzIHdoeSBJIHN1Z2dlc3QgIndlIGRvIG1pZGRsZS10ZXJt IHNvbHV0aW9uIGFuZCBsb25nLXJ1biAgYXJjaGl0ZWN0dXJlIGluIHBhcmFsbGVsIi4NCk1heWJl IHdlIGNvdWxkIGJyaW5nIHRoZSBHU0UgYmFjayBhcyBhIGNhbmRpZGF0ZSBpbiBsb25nLXJ1biAg YXJjaGl0ZWN0dXJlIGRpc2N1c3Npb24uIGFuZCBhbHNvIEkgDQpjb3VsZCBoYXZlIGEgY2hhbmNl IHRvIGJvb3N0IChTSElNK0NHQStNSVAgc2ltaWxhciByZW5kZXp2b3VzIG1lY2hhbmlzbSkgaW4g YSBtaWRkbGUtdGVybSANCnNvbHV0aW9uIGRpc2N1c3Npb24uDQoNCklNSE8sIHRoZSBtb3N0IHBy b2JlbG0gb2YgY3VycmVudCBhcmNoaXRlY3R1cmUgaXMgbm90ICJzdXBwb3J0aW5nIG11bHRpaG9t aW5nIGFuZCBtb2JpbGl0eSANCndpdGgga2x1ZGdlcyIgb3IgbGFjayBvZiBpZGVudGl0eS4gSWYg d2UgcmVhbGx5IGFiYW5kb24gdGhlIGN1cnJlbnQgIG9uZSAoQXJjaCAxKSBhbmQgYWRvcHQgYSAN CnRvdGFsbHkgbmV3IGFyY2hpdGVjdHVyYWwgcHJvcG9zYWwgKEFyY2ggMikgd2hpY2ggY291bGQg cGVyZmVjdGx5IGNhdGVyIHRvIGFsbCBvZiB0aG9zZSBuZWVkcywgDQp3aGF0ICpzaG91bGQqIHdl IGRvIGlmICBhbm90aGVyIGNyaXRpY2FsIG5ldyByZXF1aXJlbWVudCBzdWRkZW5seSBjYW1lIG91 dD8gIFlldCBhbm90aGVyIHdob2xlIGFuZA0KcXVpY2sgbW92ZSB0byBBcmNoIDMuLi51bnRpbCBB cmNoIE4/IG9yLCBhZGQga2x1ZGdlIGFuZCBiYWdzIHRvIEFyY2ggMj8gIFNvIEkgdGhpbmsgdGhl IG5leHQgbmV3IA0KYXJjaGl0ZWN0dXJlICptdXN0KiBiZSAiRm9yd2FyZCBjb21wYXRpYmxlIiAo b3IgbW9kdWxhcml0eT8pLiAgSWYgYSBhcmNoaXRlY3R1cmUgaXMgYm9ybiB0byANCmNvcGUgd2l0 aCBjaGFuZ2VzLCB0aGVuIGEgQXJjaGl0ZWN0dXJhbCAgQ2hhbmdlIHdvbid0IGJlIHNvIHBhaW5m dWwgYW5kIHVuYWNjZXB0YWJsZSBhbnltb3JlLg0KDQpJbiBteSBwZXJmZWN0IHdvcmxkLCBhcmNo aXRlY3R1cmUgWCBpcyB0aGVyZS4gTGF5ZXIncyBob3Jpem9uYWwgaW50ZXJmYWNlcyBhcmUgb3Jn YW5pemVkIGluIGEgDQpDT00vQ09NKyAgc2ltaWxpYXIgc3R5bGUuIFdoZW4gMiBwZW9wbGUgd2Fu dCB0byBjb25uZWN0LCB0aGVpciBjb3JyZXNwb25kIGxheWVycyBkbyAqY2FwYWJpbGl0eQ0Kc2V0 IGV4Y2hhbmdlKiAgZmlyc3QgKHNvdW5kcyBsaWtlIFF1ZXJ5SW50ZXJmYWNlKTogd2hvIGNvdWxk IG1vYmlsZSwgd2hvIGhhdmUgaWRlbnRpdHksZS50LmMuIEFzIHNvb24NCmFzIGEgYmFzaWMgY29t bW9uIGFncmVlbWVudCBhY2hpZXZlZCwgcGxhbmUgdGFrZSBvZmYuIFdoYXQncyBtb3JlLCBMYXll cidzIHZlcnRpY2FsICBpbnRlcmZhY2VzIGFyZSANCm9yZ2FuaXplZCBpbiAgYSBXSU5ET1dTIE9T IG5ldHdvcmstZHJpdmVyLXN0YWNrIHNpbWlsYXIgc3R5bGUsIHdoaWNoIGFscmVhZHkgZm9yZXNl ZSBtYW55IG5ldyANCmFkZGlvbmFsIElQIHdhaXN0cyBhbmQgd2lsbGluZyB0byBtYW5hZ2UgdGhl bS4gVGh1cyBpbiAyMDM2IHdoZW4gSSBhbSBsdXJraW5nIGluIElFVEYncw0KIG5ld2VyLWFyY2hp dGVjdHVyZS1kaXNjdXNzIG1haWxsaXN0LCBJICBmb3Igc3VyZSB3b24ndCBzZWUgdGhpczoNCg0K QTogSGV5LCB5b3UgY2FuJ3QgZG8gdGhhdCBhcmNoaXRlY3R1cmFsIGNoYW5nZS4gVGhpcyB3b3Vs ZCBub3QgYmUgYmFja3dhcmQgY29tcGF0aWJsZSB3aXRoICBvdXIgZXhzaXRpbmcgDQogICAgIElQ djggIHN5c3RlbXMuDQpCOiBUaGUgb25seSByZWFzb24gdGhhdCB3aHkgd2Ugd29uJ3QgY2hhbmdl IHRoZSBhcmNoaXRlY3R1cmUgaXMgYmVjYXVzZSBpdCBjaGFuZ2UgdGhlIGFyY2hpdGVjdHVyZQ0K DQoNCg== --===============2093989730== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============2093989730==-- From architecture-discuss-bounces@ietf.org Sat Feb 18 04:45:37 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAOen-0006oe-0b; Sat, 18 Feb 2006 04:45:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAOel-0006no-2V for architecture-discuss@megatron.ietf.org; Sat, 18 Feb 2006 04:45:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04098 for ; Sat, 18 Feb 2006 04:43:45 -0500 (EST) Received: from zz-9-193-a8.bta.net.cn ([202.108.9.193] helo=163.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FAOtK-0003xI-Vl for architecture-discuss@ietf.org; Sat, 18 Feb 2006 05:00:40 -0500 Received: from swan18dbebf954 (unknown [211.69.207.226]) by smtp14 (Coremail) with SMTP id OUAAAbHs9kN_Z+cA.18266S2; Sat, 18 Feb 2006 17:45:25 +0800 (CST) Message-ID: <00a601c63470$177171d0$3b62a8c0@swan18dbebf954> From: "Tian Chen" To: "Tony Li" , "Thomas Narten" References: <200602172158.k1HLwOIn006725@cichlid.raleigh.ibm.com> Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches Date: Sat, 18 Feb 2006 17:45:41 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.4 (+++) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1898613943==" Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org --===============1898613943== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 DQoiVGhvbWFzIE5hcnRlbiIgIHdyb3RlDQo+IA0KPiBJIGRvbid0IGFncmUgd2l0aCB0aGlzIGNv bmNsdXNpb24uIEJ1dCBJTU8sIGl0J3Mgbm90IHRlcnJpYmx5IHVzZWZ1bA0KPiB0byB0YWxrIGFi b3V0IGFyY2hpdGVjdHVyZSBpbiBhbiBhYnN0cmFjdCBzZW5zZS4gQXJjaGl0ZWN0dXJlIGlzIGEg Yml0DQo+IGxpa2UgYXJ0IC0tIHlvdSBrbm93IGdvb2QgYXJjaGl0ZWN0dXJlIHdoZW4geW91IHNl ZSBpdCwgYnV0IGl0J3MNCj4gcmVhbGx5IGhhcmQgdG8gZGVmaW5lLiBJdCBoYXMgdG8gZG8gd2l0 aCBob3cgYSBiaWcgY29tcGxleCBzeXN0ZW0NCj4gKHByb3RvY29sIHN1aXRlKSBpcyBjb21wb25l bnRpemVkIGludG8gc2VwYXJhdGUsIG1hbmFnYWJsZSBwaWVjZXMsDQo+IHdoZXJlIHRoZSBwYXJ0 cyBmaXQgdG9nZXRoZXIgY2xlYW5seSBhbmQgd2l0aCBnb29kIGFic3RyYWN0DQo+IGludGVyZmFj ZXMsIHRoZXJlIGlzIGFuIG92ZXJhbGwgc2ltcGxpY2l0eSBhbmQgY29oZXJlbmN5LCBhbmQgc28N Cj4gZm9ydGguDQoNCkkgZGlzYWdyZWUgd2l0aCB5b3UgaW4gdGhpcyBwb2ludC4geW91IGNhbid0 ICJrbm93IGdvb2QgYXJjaGl0ZWN0dXJlIHdoZW4NCiB5b3Ugc2VlIGl0ICIsIHJlbWViZXIgT1NJ IDctbGF5ZXIgbW9kZWw/IEl0IGxvc3QgdG8gSVAgYXJjaGl0ZWN0dXJlLCB3aGVyZQ0Kd2UgYXJl IHNwZWFraW5nIG5vdy4gSWYgYSBhcmNoaXRlY3R1cmUgaXMgZmluYWxseSBhY2NlcHRlZCBieSB0 aGUgbWFqb3JpdHkNCm9mIHRoZSBkYXRhLWNvbW11bmljYXRpb24gY29tbXVuaXR5LCB0aGVuIGl0 IGlzIGEgZ29vZCBhcmNoaXRlY3R1cmUgOikNCiANCj4+IFRoaXMgbWFrZXMgdGhlIGRpc2N1c3Np b24gKGFuZCBpbmRlZWQsIHRoZSBlbnRpcmUgbWFpbGluZyBsaXN0KQ0KPj4gcmF0aGVyIG1vb3Qu DQo+IA0KPiBQZXJoYXBzLiBJIHRvbyBnZXQgZnJ1c3RyYXRlZCB3aXRoIGFic3RyYWN0IGRpc2N1 c3Npb25zIGFib3V0DQo+IGFyY2hpdGVjdHVyZSwgYXMgSSBkb24ndCBzZWUgd2hhdCBpdCB3aWxs IGxlYWQgdG8uDQo+IA0KDQpTb21lb25lIHNob3VsZCBwdXQgdGhpcyBtYWlsIGxpc3QgZm9yd2Fy ZC4gSWYgdGhpbmdzIHN0aWxsIGdvZXMgbGlrZSAiWW91IE1VU1QhIg0KIk5vLCB5b3UgY2FuJ3Qi IG92ZXIgYW5kIG92ZXIsIHRoZXJlIHdvdWxkIGJlIG5vIG91dHB1dC4NCg== --===============1898613943== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss --===============1898613943==-- From architecture-discuss-bounces@ietf.org Sat Feb 18 06:53:31 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAQeZ-0003Tn-FY; Sat, 18 Feb 2006 06:53:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAQeV-0003Tc-Bu for architecture-discuss@megatron.ietf.org; Sat, 18 Feb 2006 06:53:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10987 for ; Sat, 18 Feb 2006 06:51:39 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAQt8-0007kt-EJ for architecture-discuss@ietf.org; Sat, 18 Feb 2006 07:08:34 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 18 Feb 2006 03:53:19 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,126,1139212800"; d="scan'208"; a="22171189:sNHT23404360" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k1IBrFLN015882; Sat, 18 Feb 2006 06:53:15 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 18 Feb 2006 06:53:15 -0500 Received: from [10.86.242.12] ([10.86.242.12]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 18 Feb 2006 06:53:14 -0500 Message-ID: <43F70AAA.9010903@cisco.com> Date: Sat, 18 Feb 2006 06:53:14 -0500 From: Scott W Brim User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051201 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Thomas Narten Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches References: <200602172158.k1HLwOIn006725@cichlid.raleigh.ibm.com> In-Reply-To: <200602172158.k1HLwOIn006725@cichlid.raleigh.ibm.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Feb 2006 11:53:15.0030 (UTC) FILETIME=[E6909B60:01C63481] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org On 02/17/2006 16:58 PM, Thomas Narten allegedly wrote: > But they were possible because there was a credible transition > strategy for how to deploy, that did not require unworkable flag days > and fork lift upgrades. It has nothing to do with being an > architectural change (or not). (And Diffserv is an architectural > change?) Architectural changes can be made by deploying first in islands, with interworking and tunneling, and then letting the islands grow. The problem here is Tony's third point ... On 02/17/2006 23:08 PM, Tony Li allegedly wrote: > - We have a problem. > - The current crop of solutions are unsatisfactory. > - We are willing to make changes. ... and that the Internet now runs on money. Why would someone want to deploy a small island with interworking (and loss of capability, increased complexity and operational costs) when the issues are competition and the bottom line for the next quarter? You need either higher motivation or lower cost. The only thing that seems like it's going to increase motivation is more pain for all of us -- carrots aren't working. How can we lower overall cost of deploying something risky? _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Feb 18 13:00:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAWNB-0007QR-8B; Sat, 18 Feb 2006 12:59:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAWNA-0007QM-5i for architecture-discuss@ietf.org; Sat, 18 Feb 2006 12:59:56 -0500 Received: from sccrmhc13.comcast.net ([204.127.200.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAWN9-0004dL-UN for architecture-discuss@ietf.org; Sat, 18 Feb 2006 12:59:56 -0500 Received: from s73602 (c-24-1-104-165.hsd1.tx.comcast.net[24.1.104.165]) by comcast.net (sccrmhc13) with SMTP id <20060218175955013001g81fe>; Sat, 18 Feb 2006 17:59:55 +0000 Message-ID: <082f01c634b4$e524f540$66087c0a@china.huawei.com> From: "Spencer Dawkins" To: References: <200602172158.k1HLwOIn006725@cichlid.raleigh.ibm.com> <43F70AAA.9010903@cisco.com> Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches Date: Sat, 18 Feb 2006 11:58:16 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org From: "Scott W Brim" > Architectural changes can be made by deploying first in islands, with > interworking and tunneling, and then letting the islands grow. The > problem here is Tony's third point ... > > On 02/17/2006 23:08 PM, Tony Li allegedly wrote: >> - We have a problem. >> - The current crop of solutions are unsatisfactory. >> - We are willing to make changes. > > ... and that the Internet now runs on money. Why would someone want to > deploy a small island with interworking (and loss of capability, > increased complexity and operational costs) when the issues are > competition and the bottom line for the next quarter? You need either > higher motivation or lower cost. The only thing that seems like it's > going to increase motivation is more pain for all of us -- carrots > aren't working. How can we lower overall cost of deploying something > risky? I've been following the discussion in SIP on the overhead to keep NAT bindings alive (thread starts at http://www1.ietf.org/mail-archive/web/sip/current/msg12806.html). The highlight is whether we need/don't need to have two protocols (in this case, one text-based and one binary) running over the same transport mapping to (1) keep NAT bindings alive and (2) actually do anything useful (in this case, SIP). The best guess (since NAT functionality isn't standardized) is that SIP endpoints behind a NAT would work best if they sent keepalives every 15 seconds, in order to make sure that they can make/receive something like one call per hour). There is also some commentary on what the effect of actual productive work being a small minority of total work is on proxy costs, etc. Of course, we note that multiplexing keepalive signalling for one application with that application doesn't actually keep any NAT bindings refreshed for anything else, so anything else that needs SIPpish NAT traversal characteristics either duplicates the NAT binding refresh signaling or becomes part of SIP... So I'm worried that neither carrots or sticks are providing sufficient motivation for change... how much more pain is needed? Apparently, more than we might have guessed intuitively! Thanks, Spencer _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Feb 18 21:45:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAeZC-00008A-T0; Sat, 18 Feb 2006 21:44:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAeZB-000080-UI for architecture-discuss@ietf.org; Sat, 18 Feb 2006 21:44:53 -0500 Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAeZB-00057g-N7 for architecture-discuss@ietf.org; Sat, 18 Feb 2006 21:44:53 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52) id 1FAeZ2-0006HZ-8M; Sat, 18 Feb 2006 18:44:44 -0800 Message-Id: <6.2.3.4.2.20060218231421.048d01e0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Sat, 18 Feb 2006 23:40:59 +0100 To: "Tian Chen" ,"Tony Li" , "Thomas Narten" From: "JFC (Jefsey) Morfin" Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches In-Reply-To: <00a601c63470$177171d0$3b62a8c0@swan18dbebf954> References: <200602172158.k1HLwOIn006725@cichlid.raleigh.ibm.com> <00a601c63470$177171d0$3b62a8c0@swan18dbebf954> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-35412FCE X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 10:45 18/02/2006, Tian Chen wrote: >I disagree with you in this point. you can't "know good architecture when > you see it ", remeber OSI 7-layer model? It lost to IP architecture, where >we are speaking now. If a architecture is finally accepted by the majority >of the data-communication community, then it is a good architecture I saw three of them and I hope to see one or two more. Each brought some feed-back teaching about reality. Being an architect without understanding where you build for is useless. There is no "good" architecture. There are ways of addressing needs in a context. For that one must to understand the context and the needs. The big lack of the Internet culture is to lack a model. ENS (from Tymnet experience), OSI (from ITU analysis), were models. IETF has the RFC 1958: a set of recipes also based on experience. It is great because it tells how to build in the IP vision. But it does not say much about the framework where we build. It is typical that this prospective debate is based on existing protocols and solution. This is not innovative, but progressive. This may share in the response, even to support it in adding smart patches over smart patches. But it cannot scale. IPv6, NATs, etc. are discussed, not routing, adressing, naming, signaling, transport, interoperability, interintelligiblity, infrastructure, structure/metastructure/multilingualisation, universalisation vs internationalisation, brainware, interoperating system, mobility, identity, authentication, store and forward/retrieve, layers, OPES and ONES, end to end, brain to brain, inculturation, basic/value added/extended services, innovation support, test beds, transitions, hybridism and convergence, authority, polylogue, architexts, networked languages, interlinks, access engines, network value, globality, operation management, economical model, etc. etc. If the debate is not at that level it is an Internet maintenance and tuning IETF debate, not an IAB debate. jfc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Feb 19 07:54:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAo5C-0006dZ-5q; Sun, 19 Feb 2006 07:54:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAo5A-0006dL-SY for architecture-discuss@ietf.org; Sun, 19 Feb 2006 07:54:32 -0500 Received: from web31812.mail.mud.yahoo.com ([68.142.207.75]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FAo58-0002hs-Gf for architecture-discuss@ietf.org; Sun, 19 Feb 2006 07:54:32 -0500 Received: (qmail 47151 invoked by uid 60001); 19 Feb 2006 12:54:29 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=dshhD9N/4BoeUO4WEY+0zQzuCKo7HaeobKTrc/a3k53QYpju1NKh/IqwpyL3/tjbPdJpVFaQ9I1V4upi0KaHbfVbF3UAZxT9BsL9+27GSeciuWCyG5K1XpxwtFW3OJU9wF/+KalGn3HLfE9EkYftLDRszHyKiDV8V7COS08W7sw= ; Message-ID: <20060219125429.47149.qmail@web31812.mail.mud.yahoo.com> Received: from [68.48.216.32] by web31812.mail.mud.yahoo.com via HTTP; Sun, 19 Feb 2006 04:54:29 PST Date: Sun, 19 Feb 2006 04:54:29 -0800 (PST) From: David Barak Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches To: architecture-discuss@ietf.org In-Reply-To: <43F70AAA.9010903@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org --- Scott W Brim wrote: > On 02/17/2006 23:08 PM, Tony Li allegedly wrote: > > - We have a problem. > > - The current crop of solutions are > unsatisfactory. > > - We are willing to make changes. > > ... and that the Internet now runs on money. Why > would someone want to > deploy a small island with interworking (and loss of > capability, > increased complexity and operational costs) when the > issues are > competition and the bottom line for the next > quarter? You need either > higher motivation or lower cost. The only thing > that seems like it's > going to increase motivation is more pain for all of > us -- carrots > aren't working. How can we lower overall cost of > deploying something risky? The motivation for deploying something new could also be enhanced value-add services - you don't have to lower costs if you can raise prices. But I agree with your salient point, which is that there does have to be a motivating factor to entice people to deploy the islands of new-style architecture. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Feb 20 04:48:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB7ee-0003h3-TE; Mon, 20 Feb 2006 04:48:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB7ed-0003gs-Sc for architecture-discuss@ietf.org; Mon, 20 Feb 2006 04:48:27 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FB7eZ-0000Zu-El for architecture-discuss@ietf.org; Mon, 20 Feb 2006 04:48:27 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 1B16F341F8 for ; Mon, 20 Feb 2006 04:48:23 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Feb 2006 04:48:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Valid and Invalid Internet architectures and approaches Date: Mon, 20 Feb 2006 04:48:21 -0500 Message-ID: <936A4045C332714F975800409DE0924001D222F3@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Valid and Invalid Internet architectures and approaches Thread-Index: AcY1U7Y78SMMe8zIRBm0xAo4kUSs5QArad1w From: "Bound, Jim" To: X-OriginalArrivalTime: 20 Feb 2006 09:48:22.0759 (UTC) FILETIME=[C9A64770:01C63602] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I 100% agree with every statement by Thomas Narten. I have no comment good or bad on others. The key is what can be done and what will the market absorb and accept as change that the IETF can do here. Clearly other forces alter the virtual 5 layer IP Reference Model and of late specifically the applications layer using services planes to get around what is not working well today. One example is QoS and now if you listen you also hear about Quality of Experience (QoE). No one really cares what is said on this list out of this list it influences nothing, it affects nothing, and nothing will change. Get out of denial I say to my self the IETF still has not figured out it is only a Standards Development Organization once we realize that, act like that, then maybe we can develop a set of specifications that truly affect the layering model of the IP Reference Model. No one is going to support a fork lift in this SDO or in the market it will NOT HAPPEN. Thomas's bottom line I paraphrase it here. IETF is now just another bozo (an important bozo but still a bozo) on the bus to NGN and so is ITU/IEEE and many consortias like WIMAX, W3C, GGF, etc. etc.=20 NB: Paul V. - The DNS v6 comments I think are a different thread not relative to the current architecture list discussion with due respect. I think it important, but possibly a different thread, you should start? /jim _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Feb 20 06:34:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB9JS-0002p6-0N; Mon, 20 Feb 2006 06:34:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB9JQ-0002or-JX for architecture-discuss@ietf.org; Mon, 20 Feb 2006 06:34:40 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FB9JO-0003rY-2l for architecture-discuss@ietf.org; Mon, 20 Feb 2006 06:34:40 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id C2A638993D; Mon, 20 Feb 2006 13:34:36 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 507D88993C; Mon, 20 Feb 2006 13:34:36 +0200 (EET) Message-ID: <43F9A960.5090702@piuha.net> Date: Mon, 20 Feb 2006 13:34:56 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tony Li Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches References: <200602172158.k1HLwOIn006725@cichlid.raleigh.ibm.com> <43F69DC1.5040805@tony.li> In-Reply-To: <43F69DC1.5040805@tony.li> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Tony, >Architectural proposals have been lofted. They were specific, had clear >migration plans, and the discussion was shut down with the usual "v6 has >already shipped" dogma. Specific topics were: > > - GSE (more generally locator/identifier splits) > - locator agile transport protocols > >Without these types of capabilities, the architecture is stuck >supporting multihoming and mobility with kludges such as NAT, SHIM6 (NAT >in the host), and various forms of tunneling. > >To truly move forward, we first need to have consensus on the following: > > - We have a problem. > - The current crop of solutions are unsatisfactory. > - We are willing to make changes. > > I agree that we have real-world problems and problems (or at least limitations and unnecessary weight) in current solutions. I think there is willingness in the IETF community to make changes. But as Thomas noted, it would be useful to get to the specifics: o I cannot speak about the events around GSE adoption in the IPv6 work, because I was not involved. But I would not assume that GSE or other proposals like that are today dismissed merely because the IETF has already shipped something. For instance, there was a discussion of a significant GSE security issue on this list some months ago. I do not know if such issues are fatal or if they can be fixed. My quick assessment is that its not trivial. The larger point is that while people believe in (I think) the locator-identifier split, the details do matter. And it would be easier to be in favor of proposals if they were complete. Not to pick just on GSE, there are issues in other approaches, too. HIP has issues with referrals, Shim6 is hard to deploy because you probably want something on the v4 side too, etc. And when you add everything that you wanted, what started out as a simple and clean proposal may look very different at the end. o I said that I believe the IETF has willingness for chance. But it is not enough for the IETF to do something, we also have to get the real world motivated enough to follow. (For instance, we already have a locator agile transport protocol. It is being used, but only in specific applications, not in general Internet use by millions of end-users. And we have technology to provide enough addresses to everyone, but while it is widely implemented, it isn't as widely turned on as we'd like.) The problem with motivation is that the rewards and costs associated with technology choices do not always map onto a single entity. The SIP application programmer feels pain, but the guy who decided to employ a NAT may be happy because it was easy for him. Or maybe both of them are happy, because they got their things up and running, and the end-user is paying for the bandwidth usage. Or we have tragedy of the commons. --Jari _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Feb 20 19:22:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBLIh-00015A-Nw; Mon, 20 Feb 2006 19:22:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBLIh-000155-By for architecture-discuss@ietf.org; Mon, 20 Feb 2006 19:22:43 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBLIh-0002gU-2D for architecture-discuss@ietf.org; Mon, 20 Feb 2006 19:22:43 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id B188886AEF; Mon, 20 Feb 2006 19:22:42 -0500 (EST) To: architecture-discuss@ietf.org Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches Message-Id: <20060221002242.B188886AEF@mercury.lcs.mit.edu> Date: Mon, 20 Feb 2006 19:22:42 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: Tony Li > To truly move forward, we first need to have consensus on the following: > - We have a problem. > - The current crop of solutions are unsatisfactory. > - We are willing to make changes. > Until then, we have the status quo. I've been pondering your message for a while now, trying to put together a considered reponse. (I had some responses to individual points, but I'll send them off separately.) I guess my bottom line is that your goal is admirable, but also utterly infeasible. The Internet community in general, and the IETF in particular, (both groups which necessarily operate on rough consensus) are groups which are simply utterly incapable of agreeing on a radical long-term vision - which is what any substantial (i.e. worthwhile) change to the architecture amounts to. The reason is simple: the more radical the proposed change, the less likely you are to get agreement on it, because: i) very few people have the depth of understanding to truly appreciate the long-term benefits of such changes; ii) now that the Internet is a very large going operation, people are unwilling to take what they perceive as risky moves, such as a major change. In short, the only thing people can agree to is the most modest of steps - and by definition, one cannot do interesting architectural innovation in miniscule steps. A classic example of this is afforded by our own history, to wit, the IPv6 selection decision. IPv6 was proudly proclaimed by its 'architect' to be (and I don't have time to search for his exact words, but this is the sense of them) "the IPv4 architecture, which is just fine, re-engineered to be better done". (I use the scare quotes around 'architect' advisedly, since the person is question is really more of a principal engineer, as his own words indicate.) In other words, given the perfect opportunity to choose an improved path architecturally, the IETF community decided on... the lowest common denominator - and the status quo, to boot! One does not create great new architecture in this way. I see several possibilities for producing interesting new architecture (for part or more of the stack), but none of them involve the IETF. One possibility is that a consortium of large ISP's will get together and decide to replace the ramshackle Destination-Vector IPvN routing architecture we current have with something a little less Mesolithic. They will operate it among themselves, and eventually it will spread. Another possibility is that some closed community (one person suggested the US DoD) will decide that they need mission-specific capabilities that IPvN cannot be tweaked to prode, and they will go off to do so - but it's rather uncertain that this will spread (just as basically all commercial jets are not supersonic). However, the only possibility I see of the entire world progressing to something more advanced is for some revolutionary new technology (I have no idea what - maybe tachyon quantum pipes, or something) to come along and blow the exiting IPv4 Internet out of the water, just as IPv4 blew the telephone system out of the water. That the world will struggle along endlessly with embarassingly bad technology, no matter than superior alternatives have long existed, is made plain by our experience with Windows. As a professional computer scientist, I am driven to the most profound shame and embarassment by Windows. There's a quotation which crystallized this feeling for me: "I guess it would be personally offensive to me to have the public at large think that my profession is so inept and so unaware that we would [create a monstrous disaster waiting to happen] without knowing what will happen." -- 'Condominium', John D. McDonald We've had computer science technology since circa 1970 that would have prevented the vast majority of virus and worm problems, problems which have caused billions of dollars of lost time and money, have made a large share of the PC's in the world havens for thieves, con-artists and villains of all sorts, from the merely revolting to the truly deeply dangerous, and are finally slowly undermining people's very willingness to use the network. Yet an archaic design, one which was obviously prone to these problems, was quite wittingly propogated for a variety of excuses (of which the "it will be too complicated to configure" was the most specious, since not even *I* can figure out how to configure the latest Microsoft bloatware for my friends, when it fails to work for them). But I digress.... The important point for us that despite the documented existence of superior stuff, still this stuff has a stranglehold on the world's computer-using population, with no signs that it will be uprooted and discarded lock, stock and barrel any time soon. So too it is, and will be, with the rather crappy network we're now stuck with. Because, sad to say, bad as we know it is, it's still much better than even worse examples from other spheres, e.g. Windows. A bunch of local addressing domains glued together with NAT may be ugly as sin, brittle as hell operationally, etc, etc, but that's the future of networking, until some mammals come along and do in this brontosaurus of a network. When one of the top universities in the world is doing routing research on... (wait for it...) how to build overlay networks on top of the existing packet-level routing, you're know you're totally hosed. Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Feb 20 20:20:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBMCo-0002GJ-Gj; Mon, 20 Feb 2006 20:20:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBMCn-0002GE-J1 for architecture-discuss@ietf.org; Mon, 20 Feb 2006 20:20:41 -0500 Received: from sccrmhc14.comcast.net ([63.240.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBMCm-0004ft-Cg for architecture-discuss@ietf.org; Mon, 20 Feb 2006 20:20:41 -0500 Received: from [192.168.1.6] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc14) with ESMTP id <2006022101203701400e8ed5e>; Tue, 21 Feb 2006 01:20:39 +0000 Message-ID: <43FA6ADD.4010206@tony.li> Date: Mon, 20 Feb 2006 17:20:29 -0800 From: Tony Li User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Noel Chiappa Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches References: <20060221002242.B188886AEF@mercury.lcs.mit.edu> In-Reply-To: <20060221002242.B188886AEF@mercury.lcs.mit.edu> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Noel, > I guess my bottom line is that your goal is admirable, but also utterly > infeasible. The Internet community in general, and the IETF in particular, > (both groups which necessarily operate on rough consensus) are groups which > are simply utterly incapable of agreeing on a radical long-term vision - > which is what any substantial (i.e. worthwhile) change to the architecture > amounts to. Call me naive, but I'm still hopeful that some incarnation of the IAB can exert enough leadership to drive this process. I agree with you completely, that without some form of leadership, getting wide consensus is exceedingly unlikely and would require some crash-and-burn type of catastrophe before the pain level would be high enough to motivate change. However, in my Cleaver-based universe, it would still be possible for the IAB to recognize the problems ahead, convene something like ROAD again, and drive towards a better solution. I suspect that you, and most others will probably view this as absolutely Quixotic. I accept that. Until a better alternative process becomes apparent, I'm far too stubborn to stop tilting at the windmills in front of me. From my perspective, the Internet is in serious architectural trouble and it is our responsibility to do whatever we can to articulate and address the issues. Furthermore, to capitulate to the status quo and support the plan du jour would simply be the height of professional negligence and irresponsibility. Thus, I am compelled remain the loyal opposition, Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Feb 20 20:37:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBMT1-0002ds-HZ; Mon, 20 Feb 2006 20:37:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBMSz-0002dm-UT for architecture-discuss@ietf.org; Mon, 20 Feb 2006 20:37:25 -0500 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBMSy-00057B-JH for architecture-discuss@ietf.org; Mon, 20 Feb 2006 20:37:25 -0500 Received: from [127.0.0.1] (boreas.isi.edu [128.9.160.161]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k1L1aks03187; Mon, 20 Feb 2006 17:36:46 -0800 (PST) Message-ID: <43FA6EAE.7020102@isi.edu> Date: Mon, 20 Feb 2006 17:36:46 -0800 From: Venkata Pingali User-Agent: Thunderbird 1.4 (Macintosh/20050908) MIME-Version: 1.0 To: Tony Li , architecture-discuss@ietf.org Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches References: <20060221002242.B188886AEF@mercury.lcs.mit.edu> <43FA6ADD.4010206@tony.li> In-Reply-To: <43FA6ADD.4010206@tony.li> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: pingali@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Noel Chiappa X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Tony Li wrote: > Noel, > > >> I guess my bottom line is that your goal is admirable, but also utterly >> infeasible. The Internet community in general, and the IETF in particular, >> (both groups which necessarily operate on rough consensus) are groups which >> are simply utterly incapable of agreeing on a radical long-term vision - >> which is what any substantial (i.e. worthwhile) change to the architecture >> amounts to. >> > > Call me naive, but I'm still hopeful that some incarnation of the IAB > can exert enough leadership to drive this process. I agree with you > completely, that without some form of leadership, getting wide consensus > is exceedingly unlikely and would require some crash-and-burn type of > catastrophe before the pain level would be high enough to motivate change. > There is atleast one ongoing large NSF-driven effort: GENI (http://www.geni.net and http://www.nsf.gov/cise/geni/) and FIND (http://find.isi.edu). They both are in early stages but they come close to the organization/consortium driven model of change. -Venkata _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Feb 20 22:37:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBOL8-0005Xt-Pp; Mon, 20 Feb 2006 22:37:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBOL6-0005X3-QI for architecture-discuss@ietf.org; Mon, 20 Feb 2006 22:37:24 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBOL6-0008Ee-Dr for architecture-discuss@ietf.org; Mon, 20 Feb 2006 22:37:24 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id BC4B1E0435; Mon, 20 Feb 2006 22:37:24 -0500 (EST) Date: Mon, 20 Feb 2006 22:37:24 -0500 From: John Leslie To: Noel Chiappa Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches Message-ID: <20060221033724.GA94025@verdi> References: <20060221002242.B188886AEF@mercury.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060221002242.B188886AEF@mercury.lcs.mit.edu> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Noel Chiappa wrote: >> From: Tony Li > )) Architectural proposals have been lofted. They were specific, had clear )) migration plans, and the discussion was shut down with the usual "v6 has )) already shipped" dogma. Specific topics were: )) )) - GSE (more generally locator/identifier splits) )) - locator agile transport protocols )) )) Without these types of capabilities, the architecture is stuck )) supporting multihoming and mobility with kludges such as NAT, SHIM6 (NAT )) in the host), and various forms of tunneling. )) >> To truly move forward, we first need to have consensus on the following: >> - We have a problem. >> - The current crop of solutions are unsatisfactory. >> - We are willing to make changes. >> Until then, we have the status quo. > > I guess my bottom line is that your goal is admirable, but also utterly > infeasible. I don't think Tony was expecting the entire IETF to reach consensus. > The reason is simple: the more radical the proposed change, the less > likely you are to get agreement on it, because: > i) very few people have the depth of understanding to truly appreciate > the long-term benefits of such changes; > ii) now that the Internet is a very large going operation, people are > unwilling to take what they perceive as risky moves, such as a > major change. Um... We have quite a few people capable of the needed depth of understanding; but they're rather busy, and very apt to lose focus. People aren't really all that risk-averse, but they recognize that lumping too many changes together tends to exponentially increase the inertia to stay with the known. > In short, the only thing people can agree to is the most modest of steps - > and by definition, one cannot do interesting architectural innovation in > minuscule steps. I almost agree. Modest steps are far more likely to see widespread adoption. Interesting architectural innovation is more about looking at things differently than about the size of each step taken. For example, there's nothing particularly wrong with IPv4 as a transport mechanism for static endpoints over a stable infrastructure. Where we get into trouble is thinking that IPv4 addresses can be the one-size that fits-all. With 20/20 hindsight, it's obvious that TCP always deserved a separate endpoint address space than IP. Unfortunately, there's no "modest" step we can take to change that. :^( But in a world filled with NAT devices (which everybody expects to replace anyway within five years), we could start thinking in terms of decoupling the actual end-device address space from the IPv[46] address space the NAT uses to talk to the "backbone". Five years is "really fast" for adopting significant changes in the world of Internet. > A classic example of this is afforded by our own history, to wit, the > IPv6 selection decision... IPv6 had a perfect opportunity to decouple device addresses from transport addresses (and has even made some steps in that direction). Unfortunately, nobody sees this possibility as an incentive to adopt IPv6. > In other words, given the perfect opportunity to choose an improved path > architecturally, the IETF community decided on... the lowest common > denominator - and the status quo, to boot! Hardly surprising. Unless folks could see IPv6 as a "drop-in" replacement, they'd never consider it at all. > One does not create great new architecture in this way. To tell truth, I'm not terribly interested in creating "great new architecture" unless folks will use it. I see several large-economy-size messes looming: 1) Mobility will need a concept of physical location and a metric for "closer". 2) Congestion management needs an actual measure of congestion. 3) A wide range of Identity assurance options need widespread deployment. (This does not mean all traffic needs Identity assurance!) > I see several possibilities for producing interesting new architecture > (for part or more of the stack), but none of them involve the IETF. > > One possibility is that a consortium of large ISP's will get together > and decide to replace the ramshackle Destination-Vector IPvN routing > architecture we current have with something a little less Mesolithic. > They will operate it among themselves, and eventually it will spread. This seems unlikely. Large ISPs are far more interested in stealing each others' customers than in cooperating to improve the customer experience. > Another possibility is that some closed community (one person suggested > the US DoD) will decide that they need mission-specific capabilities > that IPvN cannot be tweaked to prode, and they will go off to do so - > but it's rather uncertain that this will spread (just as basically all > commercial jets are not supersonic). This will indeed happen. So far, it seems unlikely to spread much. > However, the only possibility I see of the entire world progressing to > something more advanced is for some revolutionary new technology (I > have no idea what - maybe tachyon quantum pipes, or something) to > come along and blow the exiting IPv4 Internet out of the water, just > as IPv4 blew the telephone system out of the water. It is possible to imagine congestion-free infrastructure, which would improve many things; but still leave us limited to the speed of light. Alas, the economics don't seem to be rewarding congestion-free... > That the world will struggle along endlessly with embarassingly bad > technology, no matter than superior alternatives have long existed, > is made plain by our experience with Windows. I won't descend into Windows-bashing. I do, however, think we're making real progress towards free Operating Systems which could run on a sufficient variety of hardware. Anyone want to bet what changes will follow the dissemination of Negroponte's $100 laptops? > So too it is, and will be, with the rather crappy network we're now > stuck with... A lot of the crappiness comes from poor congestion management and inappropriate aggregation. These could be fixed without discarding IPv4. Crappiness also comes from the nearly total lack of assurance of identity. This could be fixed at the TCP level, and implemented in the free Operating Systems at least -- I believe browser companies like Mozilla and Opera would be delighted to make use of it. > A bunch of local addressing domains glued together with NAT may be > ugly as sin, brittle as hell operationally, etc, etc, but that's the > future of networking, until some mammals come along and do in this > brontosaurus of a network. Please don't forget that the value of a network increases at least in proportion to the square of the number of nodes. However painful it may be to co-exist with Internet-as-we-know-it, it will be to our benefit to do so. -- John Leslie _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Feb 21 10:31:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBZTb-0004gh-R1; Tue, 21 Feb 2006 10:30:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBZTb-0004gc-EL for architecture-discuss@ietf.org; Tue, 21 Feb 2006 10:30:55 -0500 Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBZTa-0008JB-7w for architecture-discuss@ietf.org; Tue, 21 Feb 2006 10:30:55 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52) id 1FBZTX-0007CN-E1; Tue, 21 Feb 2006 07:30:51 -0800 Message-Id: <6.2.3.4.2.20060221151148.085a1ae0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Tue, 21 Feb 2006 15:23:50 +0100 To: John Leslie From: "JFC (Jefsey) Morfin" Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches In-Reply-To: <20060221033724.GA94025@verdi> References: <20060221002242.B188886AEF@mercury.lcs.mit.edu> <20060221033724.GA94025@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed; x-avg-checked=avg-ok-9566D83 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 04:37 21/02/2006, John Leslie wrote: >Please don't forget that the value of a network increases at least >in proportion to the square of the number of nodes. However painful >it may be to co-exist with Internet-as-we-know-it, it will be to our >benefit to do so. Dear John, I read with interest your comment. However you consider the proper approach and how people can work on it, you come back to some specifics of the current ill shaped architecture. The explanation might be the paragraph I quote. I think this is a fondemental architectural error. As a network catalyst and analyst my formula is sigma(n.log(n)-µ.n^2) (franglish http://jefsey.com/netvalue.pdf). It induces a totally different and pragmatic vision of the digital ecosystem networking architectures and economical value. The architecture must permit to enlarge the sigma area and decrease the µ. jfc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Feb 22 03:50:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBphU-0003tg-8z; Wed, 22 Feb 2006 03:50:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBphS-0003tb-Pt for architecture-discuss@ietf.org; Wed, 22 Feb 2006 03:50:18 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBphR-0007sN-Br for architecture-discuss@ietf.org; Wed, 22 Feb 2006 03:50:18 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 5844F212C59; Wed, 22 Feb 2006 10:50:16 +0200 (EET) Received: from [IPv6:::1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id DC50C212C44; Wed, 22 Feb 2006 10:50:15 +0200 (EET) In-Reply-To: <6.2.3.4.2.20060221151148.085a1ae0@mail.jefsey.com> References: <20060221002242.B188886AEF@mercury.lcs.mit.edu> <20060221033724.GA94025@verdi> <6.2.3.4.2.20060221151148.085a1ae0@mail.jefsey.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Pekka Nikander Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches Date: Wed, 22 Feb 2006 10:50:14 +0200 To: JFC (Jefsey) Morfin X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > As a network catalyst and analyst my formula is sigma(n.log(n)-=20 > =B5.n^2) (franglish http://jefsey.com/netvalue.pdf). It induces a =20 > totally different and pragmatic vision of the digital ecosystem =20 > networking architectures and economical value. The architecture =20 > must permit to enlarge the sigma area and decrease the =B5. Nice observation. Looking at the graph in 3D tells quite a lot. A =20 reasonable value for =B5, given the size of the Internet, seems to be =20= in the order of 10^-5 ... 10^-6 or so. However, I think that formula misses the fact that the negative =20 effects are usually caused by a small minority of network users, and =20 I don't think their number grows linearly with the size of the =20 network, at least no longer. Hence, to me it feels like =B5.n^2 is =20 wrong, and should have much smaller exponent than 2, maybe almost as =20 small as 1. Or some other growth factor, maybe combinding linear =20 growth and an S-curve. Then the picture becomes totally different. Anyway, I appreciate the basic idea of dividing the network value =20 into a positive networking effect and a negative networking effect, =20 depending in different ways on the size of the network. That also =20 manages to partially explain why closed networks (aka white listing) =20 are so effective. Now, if you managed to tie this into the natural human trust =20 behaviour (cf. e.g. Axelrod or, in less quantitative terms, Robin =20 Dunbar), that might be really something fundamental. --Pekka _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Feb 22 08:18:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBtsv-0002kF-OX; Wed, 22 Feb 2006 08:18:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBtsu-0002kA-Ux for architecture-discuss@ietf.org; Wed, 22 Feb 2006 08:18:24 -0500 Received: from e2.ny.us.ibm.com ([32.97.182.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBtsu-00023Q-Hc for architecture-discuss@ietf.org; Wed, 22 Feb 2006 08:18:24 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k1MDIN80003470 for ; Wed, 22 Feb 2006 08:18:23 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k1MDIN7X214150 for ; Wed, 22 Feb 2006 08:18:23 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k1MDINVB010154 for ; Wed, 22 Feb 2006 08:18:23 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-65-228-101.mts.ibm.com [9.65.228.101]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k1MDIMS4010111; Wed, 22 Feb 2006 08:18:23 -0500 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id k1MDIMTG030558; Wed, 22 Feb 2006 08:18:22 -0500 Message-Id: <200602221318.k1MDIMTG030558@cichlid.raleigh.ibm.com> To: Tony Li Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches In-Reply-To: Message from Tony Li of "Mon, 20 Feb 2006 17:20:29 PST." <43FA6ADD.4010206@tony.li> Date: Wed, 22 Feb 2006 08:18:22 -0500 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Tony, > Call me naive, but I'm still hopeful that some incarnation of the IAB > can exert enough leadership to drive this process. Actually, I don't think the IAB is the right place for this to happen, at least not to get it going. The first step is to get a small design team together that can articulate the problem, explain why the existing approaches (e.g., shim6) don't meet the requirements and articulate a rough outline of an alternate approach that addresses the stated requirements. Once there is some sort of consensus within the team, do expanding scope consensus building in which more people are drawn in, their input accepted, etc. Over time, if the process is working, you start building critical mass support for an approach. One of the keys here though is drawing in people from a broad cross-section of the community (not just more of those that already "believe"), since the others are the people that will bring alternate perspectives (e.g., from transport, applications, etc.) and will also be critical (in the end) in terms of getting broader community concensus for an approach. The reason I am not advocating having the IAB drive this is that ultimately, these efforts are most successful when driven by those who see the need and have an interest. Sure, at some point the IAB should get involved, but having it drive the effort initially is not necessarily the best approach in practice (and smacks of a too-common IETF problem of "we need to fix this, but somebody else is responsible for doing the actual work"). IMO, your earlier note is the right place to start: > To truly move forward, we first need to have consensus on the following: > - We have a problem. > - The current crop of solutions are unsatisfactory. > - We are willing to make changes. The first place to start is with items 1 & 2 above. I believe folk are willing to make changes (and I am certainly willing to consider them), provided there is agreement on 1 & 2. Oh, and there is one more item above that shouldn't be forgotten: - there is a critical mass of people willing to do the work of developing a solution Thomas _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Feb 22 09:02:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBuZI-0005iO-Cb; Wed, 22 Feb 2006 09:02:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBuZH-0005iA-6x for architecture-discuss@ietf.org; Wed, 22 Feb 2006 09:02:11 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBuZG-0004NY-PO for architecture-discuss@ietf.org; Wed, 22 Feb 2006 09:02:11 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 7F2FD212C59; Wed, 22 Feb 2006 16:02:09 +0200 (EET) Received: from [IPv6:::1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id E3D83212C44; Wed, 22 Feb 2006 16:02:08 +0200 (EET) In-Reply-To: <200602221318.k1MDIMTG030558@cichlid.raleigh.ibm.com> References: <200602221318.k1MDIMTG030558@cichlid.raleigh.ibm.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches Date: Wed, 22 Feb 2006 16:02:07 +0200 To: Tony Li X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Thomas Narten , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Tony, >> Call me naive, but I'm still hopeful that some incarnation of the IAB >> can exert enough leadership to drive this process. > > Actually, I don't think the IAB is the right place for this to happen, > at least not to get it going. Seeing the situation from inside, I agree with Thomas. I have been trying to get _something_ like this going for some time now in the IAB, and while many people are _very_ positive, I don't see any practical way of getting the IAB to lead this. At least not the present one; the situation may well change as people get circulated. On the other hand, the IAB might well oversee or "sponsor" such activity, but that would be an IAB decision, not mine. And there are certainly people in the IAB who might be willing to participate, either in the beginning or at some later phase. > The first step is to get a small design team together that can > articulate the problem, explain why the existing approaches (e.g., > shim6) don't meet the requirements and articulate a rough outline of > an alternate approach that addresses the stated requirements. This is almost exactly the same advice that I have heard. However, my problem here is that I have no idea who would be the right people to start with. I am just too loosely connected to the people in the IETF. Due to human group dynamics, the initial team should have no more than at most 7 members. A larger group works differently, and no so efficiently, especially in the beginning. I might otherwise be willing to lead such a team, but people have told me so many times that my ability to actually lead groups is dismal. Apparently, I have even difficulties to work in groups that are based on strong consensus. Hence, I would sincerely favour someone else taking the lead. --Pekka Nikander _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Feb 22 11:02:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBwS9-0002kX-AP; Wed, 22 Feb 2006 11:02:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBwS7-0002k6-Iz for architecture-discuss@ietf.org; Wed, 22 Feb 2006 11:02:55 -0500 Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBwS5-0001LQ-Ru for architecture-discuss@ietf.org; Wed, 22 Feb 2006 11:02:55 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52) id 1FBwS3-0000PZ-5N; Wed, 22 Feb 2006 08:02:52 -0800 Message-Id: <6.2.3.4.2.20060222160046.0752a760@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Wed, 22 Feb 2006 16:05:52 +0100 To: Pekka Nikander ,Tony Li From: "JFC (Jefsey) Morfin" Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches In-Reply-To: References: <200602221318.k1MDIMTG030558@cichlid.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-5B5E6DBD X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Thomas Narten , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I read somewhere an excellent paragraph from David Clark, explaining exactly that. Architecture innovation can only result from a team with a leader and a few partners. I would like to find this paragraph back I just perused. I felt the experience in it was very important. This is this kind of contributions which are fundamental to a debate like this one. I am not sure the IAB is good for that. I am certain the IETF is not. But this is not a reason why they could not help and foster the debate. And they should become very useful later on to permit interoperability (even if sometimes it is worse to obtain interoperability than to develop a new concept :-)) jfc At 15:02 22/02/2006, Pekka Nikander wrote: >Tony, > >>>Call me naive, but I'm still hopeful that some incarnation of the IAB >>>can exert enough leadership to drive this process. >> >>Actually, I don't think the IAB is the right place for this to happen, >>at least not to get it going. > >Seeing the situation from inside, I agree with Thomas. I have been >trying to get _something_ like this going for some time now in the >IAB, and while many people are _very_ positive, I don't see any >practical way of getting the IAB to lead this. At least not the >present one; the situation may well change as people get circulated. >On the other hand, the IAB might well oversee or "sponsor" such >activity, but that would be an IAB decision, not mine. And there are >certainly people in the IAB who might be willing to participate, >either in the beginning or at some later phase. > >>The first step is to get a small design team together that can >>articulate the problem, explain why the existing approaches (e.g., >>shim6) don't meet the requirements and articulate a rough outline of >>an alternate approach that addresses the stated requirements. > >This is almost exactly the same advice that I have heard. However, >my problem here is that I have no idea who would be the right people >to start with. I am just too loosely connected to the people in the >IETF. Due to human group dynamics, the initial team should have no >more than at most 7 members. A larger group works differently, and >no so efficiently, especially in the beginning. > >I might otherwise be willing to lead such a team, but people have >told me so many times that my ability to actually lead groups is >dismal. Apparently, I have even difficulties to work in groups that >are based on strong consensus. Hence, I would sincerely favour >someone else taking the lead. > >--Pekka Nikander > > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www1.ietf.org/mailman/listinfo/architecture-discuss > > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Feb 22 11:02:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBwRz-0002ir-2G; Wed, 22 Feb 2006 11:02:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBwRy-0002il-8X for architecture-discuss@ietf.org; Wed, 22 Feb 2006 11:02:46 -0500 Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBwRw-0001L7-VZ for architecture-discuss@ietf.org; Wed, 22 Feb 2006 11:02:46 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52) id 1FBwRv-0000PZ-Mw; Wed, 22 Feb 2006 08:02:44 -0800 Message-Id: <6.2.3.4.2.20060222153414.041ce8e0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Wed, 22 Feb 2006 15:59:36 +0100 To: Pekka Nikander From: "JFC (Jefsey) Morfin" Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches In-Reply-To: References: <20060221002242.B188886AEF@mercury.lcs.mit.edu> <20060221033724.GA94025@verdi> <6.2.3.4.2.20060221151148.085a1ae0@mail.jefsey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed; x-avg-checked=avg-ok-5B5E6DBD X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Nice observations too. You are correct. My approach is purely mechanic. It results from the observation that the historic evolution of societal networking is related to human density. The target was to understand the rules of the digital ecosystem (hardware/software, communication and information). If you add the usage of the digital ecosystem (what I said I am interested in on this list), i.e. the services to the users (the brainware), you are right. But I am not a mathematician enough to get into this. What I know is that we then switch from externets (external networks look alike, defined by their external features) to what I name SETS (spaces of exchanges, trust and services) defined by their internal features (referents) and extended by the users trust I quantify through the share of their personal context (their personalisation of the common referent). This is what I am interested in when I battle against RFC 3066 Bis, by nature the first feature of a human relational space is the language and its common attributes. Constraing their support (and what they do for languages will affect/lead what they do with all the other externets and SETS characteristics) will block the development of the whole architecture. At 09:50 22/02/2006, Pekka Nikander wrote: >>As a network catalyst and analyst my formula is sigma(n.log(n)- >>µ.n^2) (franglish http://jefsey.com/netvalue.pdf). It induces a >>totally different and pragmatic vision of the digital ecosystem >>networking architectures and economical value. The architecture >>must permit to enlarge the sigma area and decrease the µ. > >Nice observation. Looking at the graph in 3D tells quite a lot. A >reasonable value for µ, given the size of the Internet, seems to be >in the order of 10^-5 ... 10^-6 or so. What is interesting is to see how the global value may increase through externet/sets number and become less dependant from µ. Giving operators and innovation more flexibility, keeping obsoleting architectures of interest and permitting harmonious introduction of new technologies. An error for example is to consider that a new technology MUST support all the services. >However, I think that formula misses the fact that the negative >effects are usually caused by a small minority of network users, and >I don't think their number grows linearly with the size of the >network, at least no longer. Hence, to me it feels like µ.n^2 is >wrong, and should have much smaller exponent than 2, maybe almost as >small as 1. Or some other growth factor, maybe combinding linear >growth and an S-curve. Then the picture becomes totally different. Accepted. But may be it is more than 2. 2 is normal mechanical polylogue impact (without considering attenuation). What when you have a Google black hole (retaining people on its site), ad-spam (the banners are real spam). >Anyway, I appreciate the basic idea of dividing the network value >into a positive networking effect and a negative networking effect, >depending in different ways on the size of the network. That also >manages to partially explain why closed networks (aka white listing) >are so effective. > >Now, if you managed to tie this into the natural human trust >behaviour (cf. e.g. Axelrod or, in less quantitative terms, Robin >Dunbar), that might be really something fundamental. I am just a network users consultant trying to get the best from what I find. If you have knowledge in that areas, may be could you point a good URL to get to know them? Thank you. jfc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Feb 22 11:02:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBwS9-0002kX-AP; Wed, 22 Feb 2006 11:02:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBwS7-0002k6-Iz for architecture-discuss@ietf.org; Wed, 22 Feb 2006 11:02:55 -0500 Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBwS5-0001LQ-Ru for architecture-discuss@ietf.org; Wed, 22 Feb 2006 11:02:55 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52) id 1FBwS3-0000PZ-5N; Wed, 22 Feb 2006 08:02:52 -0800 Message-Id: <6.2.3.4.2.20060222160046.0752a760@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Wed, 22 Feb 2006 16:05:52 +0100 To: Pekka Nikander ,Tony Li From: "JFC (Jefsey) Morfin" Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches In-Reply-To: References: <200602221318.k1MDIMTG030558@cichlid.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-5B5E6DBD X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Thomas Narten , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I read somewhere an excellent paragraph from David Clark, explaining exactly that. Architecture innovation can only result from a team with a leader and a few partners. I would like to find this paragraph back I just perused. I felt the experience in it was very important. This is this kind of contributions which are fundamental to a debate like this one. I am not sure the IAB is good for that. I am certain the IETF is not. But this is not a reason why they could not help and foster the debate. And they should become very useful later on to permit interoperability (even if sometimes it is worse to obtain interoperability than to develop a new concept :-)) jfc At 15:02 22/02/2006, Pekka Nikander wrote: >Tony, > >>>Call me naive, but I'm still hopeful that some incarnation of the IAB >>>can exert enough leadership to drive this process. >> >>Actually, I don't think the IAB is the right place for this to happen, >>at least not to get it going. > >Seeing the situation from inside, I agree with Thomas. I have been >trying to get _something_ like this going for some time now in the >IAB, and while many people are _very_ positive, I don't see any >practical way of getting the IAB to lead this. At least not the >present one; the situation may well change as people get circulated. >On the other hand, the IAB might well oversee or "sponsor" such >activity, but that would be an IAB decision, not mine. And there are >certainly people in the IAB who might be willing to participate, >either in the beginning or at some later phase. > >>The first step is to get a small design team together that can >>articulate the problem, explain why the existing approaches (e.g., >>shim6) don't meet the requirements and articulate a rough outline of >>an alternate approach that addresses the stated requirements. > >This is almost exactly the same advice that I have heard. However, >my problem here is that I have no idea who would be the right people >to start with. I am just too loosely connected to the people in the >IETF. Due to human group dynamics, the initial team should have no >more than at most 7 members. A larger group works differently, and >no so efficiently, especially in the beginning. > >I might otherwise be willing to lead such a team, but people have >told me so many times that my ability to actually lead groups is >dismal. Apparently, I have even difficulties to work in groups that >are based on strong consensus. Hence, I would sincerely favour >someone else taking the lead. > >--Pekka Nikander > > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www1.ietf.org/mailman/listinfo/architecture-discuss > > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Feb 22 11:02:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBwRz-0002ir-2G; Wed, 22 Feb 2006 11:02:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBwRy-0002il-8X for architecture-discuss@ietf.org; Wed, 22 Feb 2006 11:02:46 -0500 Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBwRw-0001L7-VZ for architecture-discuss@ietf.org; Wed, 22 Feb 2006 11:02:46 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52) id 1FBwRv-0000PZ-Mw; Wed, 22 Feb 2006 08:02:44 -0800 Message-Id: <6.2.3.4.2.20060222153414.041ce8e0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Wed, 22 Feb 2006 15:59:36 +0100 To: Pekka Nikander From: "JFC (Jefsey) Morfin" Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches In-Reply-To: References: <20060221002242.B188886AEF@mercury.lcs.mit.edu> <20060221033724.GA94025@verdi> <6.2.3.4.2.20060221151148.085a1ae0@mail.jefsey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed; x-avg-checked=avg-ok-5B5E6DBD X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Nice observations too. You are correct. My approach is purely mechanic. It results from the observation that the historic evolution of societal networking is related to human density. The target was to understand the rules of the digital ecosystem (hardware/software, communication and information). If you add the usage of the digital ecosystem (what I said I am interested in on this list), i.e. the services to the users (the brainware), you are right. But I am not a mathematician enough to get into this. What I know is that we then switch from externets (external networks look alike, defined by their external features) to what I name SETS (spaces of exchanges, trust and services) defined by their internal features (referents) and extended by the users trust I quantify through the share of their personal context (their personalisation of the common referent). This is what I am interested in when I battle against RFC 3066 Bis, by nature the first feature of a human relational space is the language and its common attributes. Constraing their support (and what they do for languages will affect/lead what they do with all the other externets and SETS characteristics) will block the development of the whole architecture. At 09:50 22/02/2006, Pekka Nikander wrote: >>As a network catalyst and analyst my formula is sigma(n.log(n)- >>µ.n^2) (franglish http://jefsey.com/netvalue.pdf). It induces a >>totally different and pragmatic vision of the digital ecosystem >>networking architectures and economical value. The architecture >>must permit to enlarge the sigma area and decrease the µ. > >Nice observation. Looking at the graph in 3D tells quite a lot. A >reasonable value for µ, given the size of the Internet, seems to be >in the order of 10^-5 ... 10^-6 or so. What is interesting is to see how the global value may increase through externet/sets number and become less dependant from µ. Giving operators and innovation more flexibility, keeping obsoleting architectures of interest and permitting harmonious introduction of new technologies. An error for example is to consider that a new technology MUST support all the services. >However, I think that formula misses the fact that the negative >effects are usually caused by a small minority of network users, and >I don't think their number grows linearly with the size of the >network, at least no longer. Hence, to me it feels like µ.n^2 is >wrong, and should have much smaller exponent than 2, maybe almost as >small as 1. Or some other growth factor, maybe combinding linear >growth and an S-curve. Then the picture becomes totally different. Accepted. But may be it is more than 2. 2 is normal mechanical polylogue impact (without considering attenuation). What when you have a Google black hole (retaining people on its site), ad-spam (the banners are real spam). >Anyway, I appreciate the basic idea of dividing the network value >into a positive networking effect and a negative networking effect, >depending in different ways on the size of the network. That also >manages to partially explain why closed networks (aka white listing) >are so effective. > >Now, if you managed to tie this into the natural human trust >behaviour (cf. e.g. Axelrod or, in less quantitative terms, Robin >Dunbar), that might be really something fundamental. I am just a network users consultant trying to get the best from what I find. If you have knowledge in that areas, may be could you point a good URL to get to know them? Thank you. jfc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Feb 22 15:17:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC0QB-0000Hr-5B; Wed, 22 Feb 2006 15:17:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC0Q9-0000Hf-GT for architecture-discuss@ietf.org; Wed, 22 Feb 2006 15:17:09 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC0Q6-0004RF-5u for architecture-discuss@ietf.org; Wed, 22 Feb 2006 15:17:09 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 22 Feb 2006 12:17:06 -0800 Received: from cisco.com (vaf-lnx1.cisco.com [171.71.142.83]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k1MKH5Vb006790; Wed, 22 Feb 2006 12:17:05 -0800 (PST) Received: from vaf-lnx1.cisco.com (vaf-lnx1 [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id k1MKFZlh017928; Wed, 22 Feb 2006 12:15:35 -0800 Received: (from vaf@localhost) by vaf-lnx1.cisco.com (8.12.11/8.12.11/Submit) id k1MKFZIL017926; Wed, 22 Feb 2006 12:15:35 -0800 X-Authentication-Warning: vaf-lnx1.cisco.com: vaf set sender to vaf@cisco.com using -f Date: Wed, 22 Feb 2006 12:15:35 -0800 From: Vince Fuller To: Tony Li Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches Message-ID: <20060222201535.GA17819@vaf-lnx1.cisco.com> References: <20060221002242.B188886AEF@mercury.lcs.mit.edu> <43FA6ADD.4010206@tony.li> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43FA6ADD.4010206@tony.li> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Noel Chiappa , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Sir Don: > Call me naive, but I'm still hopeful that some incarnation of the IAB > can exert enough leadership to drive this process. I agree with you > completely, that without some form of leadership, getting wide consensus > is exceedingly unlikely and would require some crash-and-burn type of > catastrophe before the pain level would be high enough to motivate change. > > However, in my Cleaver-based universe, it would still be possible for > the IAB to recognize the problems ahead, convene something like ROAD > again, and drive towards a better solution. > > I suspect that you, and most others will probably view this as > absolutely Quixotic. I accept that. Until a better alternative process > becomes apparent, I'm far too stubborn to stop tilting at the windmills > in front of me. From my perspective, the Internet is in serious > architectural trouble and it is our responsibility to do whatever we can > to articulate and address the issues. Furthermore, to capitulate to the > status quo and support the plan du jour would simply be the height of > professional negligence and irresponsibility. > > Thus, I am compelled remain the loyal opposition, I'd be happy if the IAB/IESG would just not actively oppose or discourage work along these lines. And I'd be ecstatic if they'd lend some degree of sponsorship, perhaps in the context of a workshop or an experiment. No time-consuming, proactive leadership is really needed, just acknowledgement and a little bit of cooperation; I'm guessing that we, the curmudgeons of the community, could rustle up support for such work from at least equipment vendors and service providers if there were some assurance that it wouldn't all be wasted motion. Getting back to your original point: > To truly move forward, we first need to have consensus on the following: > > - We have a problem. > - The current crop of solutions are unsatisfactory. > - We are willing to make changes. There has certainly been vociferous support for statements #1 and #2 among the operational community, with the implication that #3 is unavoidable if we really want a scalable solution. Sadly, some with egos heavily invested in the "current crop of solutions" don't want to hear of it. #3 tends to be met with outright hostility, particularly when the discussion strays toward the heresy of changing enshrined packet formats or protocol semantics... --Sancho (but I think I'm a bit taller and don't speak much Spanish... ;-) _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Feb 22 18:50:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC3kK-0008O1-GD; Wed, 22 Feb 2006 18:50:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC3kJ-0008No-5t for architecture-discuss@ietf.org; Wed, 22 Feb 2006 18:50:11 -0500 Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC3kI-00022L-T5 for architecture-discuss@ietf.org; Wed, 22 Feb 2006 18:50:11 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52) id 1FC3kH-000469-W3; Wed, 22 Feb 2006 15:50:10 -0800 Message-Id: <6.2.3.4.2.20060222230158.060287c0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Wed, 22 Feb 2006 23:25:47 +0100 To: Vince Fuller From: "JFC (Jefsey) Morfin" Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches In-Reply-To: <20060222201535.GA17819@vaf-lnx1.cisco.com> References: <20060221002242.B188886AEF@mercury.lcs.mit.edu> <43FA6ADD.4010206@tony.li> <20060222201535.GA17819@vaf-lnx1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-5B5E6DBD X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Dear Vince, very refreshing. 100% with you on this. Just a question: why would this mailing list not be the IETF/IAB sponsoring you wait for? In my area (user layers convergence) I do not need any ego's OK (I just need to prevent them to harm me, what is not that easy) but I certainly need to exchanges, ideas, suggestions, etc. I miss that because as you say, there is no "WG-Curmud". What prevent us to use the hosting of this mailing list to organise it? Look at the current exchanges, it looks like most are gone, but your "curmudgeons" (Il like the term :-)) Is that not what in a way Leslie expected? jfc At 21:15 22/02/2006, Vince Fuller wrote: >Sir Don: > > > Call me naive, but I'm still hopeful that some incarnation of the IAB > > can exert enough leadership to drive this process. I agree with you > > completely, that without some form of leadership, getting wide consensus > > is exceedingly unlikely and would require some crash-and-burn type of > > catastrophe before the pain level would be high enough to motivate change. > > > > However, in my Cleaver-based universe, it would still be possible for > > the IAB to recognize the problems ahead, convene something like ROAD > > again, and drive towards a better solution. > > > > I suspect that you, and most others will probably view this as > > absolutely Quixotic. I accept that. Until a better alternative process > > becomes apparent, I'm far too stubborn to stop tilting at the windmills > > in front of me. From my perspective, the Internet is in serious > > architectural trouble and it is our responsibility to do whatever we can > > to articulate and address the issues. Furthermore, to capitulate to the > > status quo and support the plan du jour would simply be the height of > > professional negligence and irresponsibility. > > > > Thus, I am compelled remain the loyal opposition, > >I'd be happy if the IAB/IESG would just not actively oppose or discourage >work along these lines. And I'd be ecstatic if they'd lend some degree of >sponsorship, perhaps in the context of a workshop or an experiment. No >time-consuming, proactive leadership is really needed, just acknowledgement >and a little bit of cooperation; I'm guessing that we, the curmudgeons of >the community, could rustle up support for such work from at least equipment >vendors and service providers if there were some assurance that it wouldn't >all be wasted motion. > >Getting back to your original point: > > > To truly move forward, we first need to have consensus on the following: > > > > - We have a problem. > > - The current crop of solutions are unsatisfactory. > > - We are willing to make changes. > >There has certainly been vociferous support for statements #1 and #2 among >the operational community, with the implication that #3 is unavoidable if we >really want a scalable solution. Sadly, some with egos heavily invested in >the "current crop of solutions" don't want to hear of it. #3 tends to be met >with outright hostility, particularly when the discussion strays toward the >heresy of changing enshrined packet formats or protocol semantics... > > --Sancho > (but I think I'm a bit taller and don't speak much Spanish... ;-) > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Feb 22 20:18:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC57Q-0007jU-Eh; Wed, 22 Feb 2006 20:18:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC57P-0007jI-CP for architecture-discuss@ietf.org; Wed, 22 Feb 2006 20:18:07 -0500 Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC57O-0005qh-6j for architecture-discuss@ietf.org; Wed, 22 Feb 2006 20:18:07 -0500 Received: from [192.168.1.6] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc11) with ESMTP id <2006022301180401100kqhake>; Thu, 23 Feb 2006 01:18:05 +0000 Message-ID: <43FD0D41.3030403@tony.li> Date: Wed, 22 Feb 2006 17:17:53 -0800 From: Tony Li User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Thomas Narten Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches References: <200602221318.k1MDIMTG030558@cichlid.raleigh.ibm.com> In-Reply-To: <200602221318.k1MDIMTG030558@cichlid.raleigh.ibm.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Thomas, > Actually, I don't think the IAB is the right place for this to happen, > at least not to get it going. Just to be crystal clear: I am *not* suggesting that the IAB actually be the work force for this. I *am* asking that the IAB clearly articulate its openness to accept and standardize architectural changes to v6 at this point. > The first step is to get a small design team together ... Before that can happen, the design team members need to know that their work can possibly succeed. Right now, no one is willing to invest in this because the outcome seems preordained. Only the IAB is really in a position to reverse this. Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Feb 22 21:55:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC6dy-0005FE-2r; Wed, 22 Feb 2006 21:55:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC6dw-0005F9-FV for architecture-discuss@ietf.org; Wed, 22 Feb 2006 21:55:48 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC6dv-00010i-80 for architecture-discuss@ietf.org; Wed, 22 Feb 2006 21:55:48 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id 4203BE0434; Wed, 22 Feb 2006 21:55:47 -0500 (EST) Date: Wed, 22 Feb 2006 21:55:47 -0500 From: John Leslie To: Tony Li Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches Message-ID: <20060223025547.GG94025@verdi> References: <200602221318.k1MDIMTG030558@cichlid.raleigh.ibm.com> <43FD0D41.3030403@tony.li> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43FD0D41.3030403@tony.li> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Thomas Narten , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Tony Li wrote: > Thomas, > >> Actually, I don't think the IAB is the right place for this to happen, >> at least not to get it going. > > Just to be crystal clear: I am *not* suggesting that the IAB actually be > the work force for this. I *am* asking that the IAB clearly articulate > its openness to accept and standardize architectural changes to v6 at > this point. This is a bit much to ask. I think it entirely reasonable to ask IAB to endorse a statement of the problem (which BTW we don't have yet, IMHO). It is not reasonable to ask IAB to diddle with the specifications of IPv6. In fact, I'd say it's premature to assume that a solution _can_ be found within the framework of IPv6. >> The first step is to get a small design team together ... I don't agree. I think we need a statement of the problem first. Given a statement of the problem, next should come a statement of design goals. (IMHO.) Then it would be appropriate to have one or more design teams. > Before that can happen, the design team members need to know that their > work can possibly succeed. I don't think we can guarantee much there... > Right now, no one is willing to invest in this because the outcome > seems preordained. With respect to IPv6, that may be true. > Only the IAB is really in a position to reverse this. I can't speak for them, but were I an IAB member I wouldn't feel as if the IAB was "in a position to reverse" much of anything about IPv6. They can raise architectural questions; to a very limited degree they can hear appeals and send issues back to IESG for reconsideration. They _cannot_ take any management role with an existing IETF WG. If we come up with a good architectural solution, the existing IPv6 WG might choose to incorporate it. Or they might not. IMHO, IPv6 is seeing a slow enough rate of adoption that it's quite possible that a brand-new IPv7 could overtake it. ;^) -- John Leslie _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Feb 23 09:55:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCHsJ-0005Hf-HR; Thu, 23 Feb 2006 09:55:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCHsH-0005HW-NK for architecture-discuss@ietf.org; Thu, 23 Feb 2006 09:55:21 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCHsG-0005Xj-B2 for architecture-discuss@ietf.org; Thu, 23 Feb 2006 09:55:21 -0500 Received: from jurassic.eng.sun.com ([129.146.58.166]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k1NEtJSD009113; Thu, 23 Feb 2006 07:55:19 -0700 (MST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k1NEtDAq264110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 23 Feb 2006 06:55:17 -0800 (PST) Message-ID: <43FDCC9C.5030407@sun.com> Date: Thu, 23 Feb 2006 06:54:20 -0800 From: Erik Nordmark User-Agent: Thunderbird 1.5 (X11/20060113) MIME-Version: 1.0 To: Tony Li Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches References: <200602172158.k1HLwOIn006725@cichlid.raleigh.ibm.com> <43F69DC1.5040805@tony.li> In-Reply-To: <43F69DC1.5040805@tony.li> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Thomas Narten , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Tony Li wrote: > Thomas, > > Architectural proposals have been lofted. They were specific, had clear > migration plans, and the discussion was shut down with the usual "v6 has > already shipped" dogma. Specific topics were: > > - GSE (more generally locator/identifier splits) > - locator agile transport protocols I agree that these are the most important infrastructure problems that needs more work. > Without these types of capabilities, the architecture is stuck > supporting multihoming and mobility with kludges such as NAT, SHIM6 (NAT > in the host), and various forms of tunneling. I'm far from sure that tunnel and "architected NAT" are kludges; what matters the most is that the applications get sane behavior from the layers below, and that routing can scale. > To truly move forward, we first need to have consensus on the following: > > - We have a problem. > - The current crop of solutions are unsatisfactory. > - We are willing to make changes. > > Until then, we have the status quo. I suspect that many people are in the state of "it would be nice if we (or somebody else) could solve the identifier/locator split", but once we move into more details than that, it's harder to get any form of consensus. For instance, so folks might view it as a requirement that the applications (and the APIs they use to access the network) can't change. Others might view that we can't require changes to routers. A third group of people might not want to see any mandatory changes to host IP stacks, because that's too hard to deploy. If we take the union of those "requirements", then clearly nothing can change. One way to untangle that is encourage parallel efforts that can make their own choices of what the wish to pick as their constraints. Even if we can get past that part, and have one or more proposals for a better architecture, it is far from clear to me that anybody wants to "pay" the cost of the changes; I don't expect that will find some free lunch here, because if there was one we'd most like would have already found it. Thus spending cycles on this set of problems is high risk. Getting the IAB to somehow endorse that folks explore solutions to this set of problems can't hurt, but I'm not sure it will help very much either. Erik _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Feb 25 10:05:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD0yc-0005Da-H7; Sat, 25 Feb 2006 10:04:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCP6Z-0004EG-NY for architecture-discuss@ietf.org; Thu, 23 Feb 2006 17:38:35 -0500 Received: from eastrmmtao04.cox.net ([68.230.240.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCP6Z-00087k-ET for architecture-discuss@ietf.org; Thu, 23 Feb 2006 17:38:35 -0500 Received: from [10.30.20.240] (really [70.174.17.170]) by eastrmmtao04.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20060223223823.VSBR19943.eastrmmtao04.cox.net@[10.30.20.240]> for ; Thu, 23 Feb 2006 17:38:23 -0500 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: <4BE79D4E-DD30-43B3-AE51-7B811A94F79D@extremenetworks.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: architecture-discuss@ietf.org From: RJ Atkinson Date: Thu, 23 Feb 2006 17:38:34 -0500 X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 1.6 (+) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 X-Mailman-Approved-At: Sat, 25 Feb 2006 10:04:53 -0500 Subject: [arch-d] (no subject) X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Earlier Thomas Narton wrote: % The first step is to get a small design team together that can % articulate the problem, explain why the existing approaches (e.g., % shim6) don't meet the requirements and articulate a rough outline of % an alternate approach that addresses the stated requirements. Once % there is some sort of consensus within the team, do expanding scope % consensus building in which more people are drawn in, their input % accepted, etc. Over time, if the process is working, you start % building critical mass support for an approach. One of the keys here % though is drawing in people from a broad cross-section of the % community (not just more of those that already "believe"), since the % others are the people that will bring alternate perspectives (e.g., % from transport, applications, etc.) and will also be critical (in the % end) in terms of getting broader community concensus for an approach. With roughly 2 exceptions, the IRTF NSRG membership believed that there were real problems that existing approaches could not solve and agreed on an alternate architecture that addressed the stated requirements. That architecture was similar to the O'Dell proposals, variously known as 8+8 or GSE. However, the NSRG was operating under a "unanimous consent" model, rather than under the usual "rough consensus" model, for some reason. This is one of several reasons that a more complete NSRG report never materialised. Previously, Mike O'Dell and others (collectively, they constituted an informal "design team") outlined the problem and an alternate architecture at the (now infamous) GSE shootout. After that meeting, an alleged description of the outcome of the meeting was drafted. Unfortunately, that draft mainly indicated that the authors of that draft had not understood what had actually been proposed by O'Dell. So please forgive me for saying that the approach you outline above WAS tried on this topic AND met with artificial barriers to progress. So I think that Tony is right -- without some official sanction, progress within IETF/IRTF on a new architecture is unlikely to happen. People have been burned, some more than once, on this topic, so are reluctant to waste time tilting at windmills again. Research on this topic does crop up in the public literature occasionally. % The reason I am not advocating having the IAB drive this is that % ultimately, these efforts are most successful when driven by those who % see the need and have an interest. Sure, at some point the IAB should % get involved, but having it drive the effort initially is not % necessarily the best approach in practice (and smacks of a too-common % IETF problem of "we need to fix this, but somebody else is responsible % for doing the actual work"). I have not heard anyone suggest that the IAB "drive this". I have heard several people suggest that the IAB formally approve a project so that participants have at least a level playing field to work with. This should include the serious possibility of changes to IPv6 and related protocols (e.g. Transport-layer pseudo-header checksum calculations) if the sponsored group produces results indicating such changes are required. There are several forms that formal approval might take. One possibility would be to create an IRTF New Architecture RG, possibly with Li and Chiappa as co-chairs. In the interest of progress, such an RG should probably start with a closed membership, then move to a semi-open membership (analogous to the IRTF RMRG), while having a fully open "-interest" mailing list all along. I am sure that other possibilities for official approval of such a project also exist. I continue to do individual research relating to this topic. I see some others doing research relating to this topic. Absent some concrete reason to believe the political landscape has become much more level than in the past, most researchers in this area don't see any point in bringing the results of that research to the IETF or IRTF organisations. Yours, Ran rja@extremenetworks.com _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Feb 25 18:35:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD8wR-0002B8-Ue; Sat, 25 Feb 2006 18:35:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FD8wQ-0002AH-Bh for architecture-discuss@ietf.org; Sat, 25 Feb 2006 18:35:10 -0500 Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FD8wP-0000lL-58 for architecture-discuss@ietf.org; Sat, 25 Feb 2006 18:35:10 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52) id 1FD8wN-000086-Lt; Sat, 25 Feb 2006 15:35:08 -0800 Message-Id: <6.2.3.4.2.20060225171720.05df2dd0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Sun, 26 Feb 2006 00:34:59 +0100 To: RJ Atkinson ,architecture-discuss@ietf.org From: "JFC (Jefsey) Morfin" Subject: Re: [arch-d] (no subject) In-Reply-To: <4BE79D4E-DD30-43B3-AE51-7B811A94F79D@extremenetworks.com> References: <4BE79D4E-DD30-43B3-AE51-7B811A94F79D@extremenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-334E3637 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 23:38 23/02/2006, RJ Atkinson wrote: >the IRTF NSRG membership believed that >there were real problems that existing approaches could not solve >and agreed on an alternate architecture that addressed the stated >requirements. That architecture was similar to the O'Dell proposals, >variously known as 8+8 or GSE. > >However, the NSRG was operating under a "unanimous consent" model, >rather than under the usual "rough consensus" model, for some reason. >This is one of several reasons that a more complete NSRG report never >materialised. I understand a contention exists. But is there a possiblity to read a description of that proposed architecture the IRTF considered favorably? >I continue to do individual research relating to this topic. >I see some others doing research relating to this topic. >Absent some concrete reason to believe the political landscape >has become much more level than in the past, most researchers >in this area don't see any point in bringing the results of that >research to the IETF or IRTF organisations. The political landscape: 1. has changed: this list was created by the IAB 2. there is need to exchange propositions and thinking. Individual thinkers will never suceed to change a billions machines and users system without some structured support. IGF can be a future possibility. This should not prevent documenting the IETF and IRTF. To the contrary I feel we can now put them in competition to listen propositions seriously? jfc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Feb 27 17:00:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDqQ7-00042x-2p; Mon, 27 Feb 2006 17:00:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDqQ5-00042k-Aw for architecture-discuss@ietf.org; Mon, 27 Feb 2006 17:00:41 -0500 Received: from dsl092-066-146.bos1.dsl.speakeasy.net ([66.92.66.146] helo=alva.home) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDqQ3-0007oU-UQ for architecture-discuss@ietf.org; Mon, 27 Feb 2006 17:00:41 -0500 Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1FDqPn-0004MS-00; Mon, 27 Feb 2006 17:00:23 -0500 From: Tim Shepard To: Tony Li Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches In-reply-to: Your message of Wed, 22 Feb 2006 17:17:53 -0800. <43FD0D41.3030403@tony.li> Date: Mon, 27 Feb 2006 17:00:15 -0500 Message-Id: X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: Thomas Narten , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org (I'm behind on e-mail reading, and I'm responding to a message from 5 days ago.) Tony Li said: > Thomas, > > > Actually, I don't think the IAB is the right place for this to happen, > > at least not to get it going. > > Just to be crystal clear: I am *not* suggesting that the IAB actually be > the work force for this. I *am* asking that the IAB clearly articulate > its openness to accept and standardize architectural changes to v6 at > this point. I think that is asking for *way* too much. Whether or not any architectural changes are going to be accepted and standardized depends on what those changes are and what the consequences would be. If/when any such changes are proposed, the community will evaluate them and decide. The IAB is merely part of that community. The problem is that figuring out what is going to be the right thing to do is (at this point, at least) a matter of research. And opinions will vary. There's nothing stopping anyone from investigating new architectures, writing protocol specifications, writing papers discussing the ideas, building prototype implementations, and teaching others about their work. The IAB holds no veto over what research can happen in network architecture, design, and implementation. And if the IAB or IESG were to make any statement that some particular proposal will not proceed within the IETF process, that is not an irreversible decision. For example, the folk working on HIP were told at the London IETF that HIP could not proceed within the IETF as its advocates wished. They kept on working on it anyway (and IMHO have made a valuable contribution to the field of network architecture). I wish HIP were not the only such example in the last 5 years. It would be nice if there were a number of architected, designed, implemented, and (experementally) deployed worked examples demonstrating alternative ways of doing things. Running code that can be read alongside protocol specifications and architecture documents is very valuable. > > The first step is to get a small design team together ... > > Before that can happen, the design team members need to know that their > work can possibly succeed. Right now, no one is willing to invest in > this because the outcome seems preordained. Only the IAB is really in a > position to reverse this. > > Tony I disagree. Anybody can reverse this if they are willing to invest effort into seeing an idea along. HIP got to where it is today through slow recruitment (over 7 years) into an expanding community of fans through hallway conversations at IETF meetings and other venues. The IAB has, AFAIK, no power to regulate what people talk about in the hallways of IETF meetings, nor in the larger networking research community. If you want to move an idea within the IETF community, I suggest (1) write it down as clearly as you can (anyone can publish an internet draft on anything), and (2) recruit fans of the idea, and (3) to your hallway conversations at IETF meetings (and to the larger networking research community), bring open-source prototype implementations that you can demo and let other people read and test drive. The IAB and IESG are in charge of the IETF process. They do not control the fate of ideas. The community does. I hope this is helpful. -Tim Shepard shep@alum.mit.edu _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Feb 27 19:17:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDsYL-0008G9-5S; Mon, 27 Feb 2006 19:17:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDsV4-0006R8-N5 for architecture-discuss@ietf.org; Mon, 27 Feb 2006 19:13:58 -0500 Received: from sccrmhc13.comcast.net ([204.127.200.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDsPQ-0001EK-9i for architecture-discuss@ietf.org; Mon, 27 Feb 2006 19:08:09 -0500 Received: from [192.168.1.6] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc13) with ESMTP id <20060227235307013001h5l3e>; Mon, 27 Feb 2006 23:53:07 +0000 Message-ID: <44039116.5000306@tony.li> Date: Mon, 27 Feb 2006 15:53:58 -0800 From: Tony Li User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Tim Shepard Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches References: In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Thomas Narten , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org >> Just to be crystal clear: I am *not* suggesting that the IAB actually be >> the work force for this. I *am* asking that the IAB clearly articulate >> its openness to accept and standardize architectural changes to v6 at >> this point. > > I think that is asking for *way* too much. Whether or not any > architectural changes are going to be accepted and standardized > depends on what those changes are and what the consequences would be. > If/when any such changes are proposed, the community will evaluate > them and decide. The IAB is merely part of that community. Clearly, I'm failing badly at being crystal clear. ;-) I certainly have no expectation that any future technology would circumvent the usual development of rough consensus. Again, what I asked for is 'openness' -- the opportunity to be heard, to do the work and have it considered without bias and prejudice. As Ran has already detailed, previous efforts have run aground on the reef of partisan animosity before and foundered long before they were allowed to even germinate, much less blossom. Without some indication that the process is now open to renewed efforts, the assumption by many in the community seems to be that similar efforts will meet with a similar fate. To remedy this, the IAB could issue a relatively simple document that clearly articulates - that there are continued concerns about the v6 architecture in the areas of mobility, multihoming, renumbering and routing - that the IAB would like to see further investigation into the issues and possible architectural improvements - that any such improvements that met with rough consensus could be incorporated into v6 and be fully endorsed by the IAB as first-class components of the architecture Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Feb 28 00:54:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDxou-0000jy-Vw; Tue, 28 Feb 2006 00:54:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDxot-0000ho-Jm for architecture-discuss@ietf.org; Tue, 28 Feb 2006 00:54:47 -0500 Received: from [80.86.78.228] (helo=smtp.testbed.se) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDxos-0006E8-3Z for architecture-discuss@ietf.org; Tue, 28 Feb 2006 00:54:47 -0500 Received: from 53.254.dhcp.conference.apricot.net ([169.223.254.53]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.43) id 1FDxol-0005D8-Jm; Tue, 28 Feb 2006 06:54:44 +0100 Message-ID: <4403E593.2040608@pi.se> Date: Tue, 28 Feb 2006 06:54:27 +0100 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tony Li , architecture-discuss@ietf.org Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches References: <44039116.5000306@tony.li> In-Reply-To: <44039116.5000306@tony.li> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Tony, speaking not on behalf of the the IAB, but as an IAB-member, I don't see why we can't start discussing changes to the IPv6 architecture. As I see it I think that the IAB is very open to that type of discussion. It might be that the IAB has not shown the type of leadership needed here but there is no reason that it can't happen. Especially considering that you and others have pretty clearly pointed out some of the architectural problems. In fact IAB has pointed at three major areas where we need focus, IPv6, Internet architecture and "bad traffic". What you are proposing aligns very well at least with the first two. I agree that IAB needs to articulate its position on this. /Loa Tony Li wrote: >>>Just to be crystal clear: I am *not* suggesting that the IAB actually be >>>the work force for this. I *am* asking that the IAB clearly articulate >>>its openness to accept and standardize architectural changes to v6 at >>>this point. >> >>I think that is asking for *way* too much. Whether or not any >>architectural changes are going to be accepted and standardized >>depends on what those changes are and what the consequences would be. >>If/when any such changes are proposed, the community will evaluate >>them and decide. The IAB is merely part of that community. > > > > Clearly, I'm failing badly at being crystal clear. ;-) > > I certainly have no expectation that any future technology would > circumvent the usual development of rough consensus. Again, what I > asked for is 'openness' -- the opportunity to be heard, to do the work > and have it considered without bias and prejudice. As Ran has already > detailed, previous efforts have run aground on the reef of partisan > animosity before and foundered long before they were allowed to even > germinate, much less blossom. > > Without some indication that the process is now open to renewed efforts, > the assumption by many in the community seems to be that similar efforts > will meet with a similar fate. To remedy this, the IAB could issue a > relatively simple document that clearly articulates > > - that there are continued concerns about the v6 architecture > in the areas of mobility, multihoming, renumbering and routing > - that the IAB would like to see further investigation into the > issues and possible architectural improvements > - that any such improvements that met with rough consensus could > be incorporated into v6 and be fully endorsed > by the IAB as first-class components of the architecture > > > Tony > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss > -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Feb 28 01:47:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDydr-0000g4-Sc; Tue, 28 Feb 2006 01:47:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDydr-0000fz-3a for architecture-discuss@ietf.org; Tue, 28 Feb 2006 01:47:27 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDydm-0007xQ-S5 for architecture-discuss@ietf.org; Tue, 28 Feb 2006 01:47:27 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 64B0E342C1 for ; Tue, 28 Feb 2006 01:47:22 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Feb 2006 01:47:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Feb 2006 01:47:20 -0500 Message-ID: <936A4045C332714F975800409DE0924001DEF45E@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What Problems are We Solving for the Internet Architecture Thread-Index: AcY8K48FH+tIaQnhTeOaDrFttZVsVAABAQ4g From: "Bound, Jim" To: X-OriginalArrivalTime: 28 Feb 2006 06:47:22.0390 (UTC) FILETIME=[D3AB7B60:01C63C32] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Subject: [arch-d] What Problems are We Solving for the Internet Architecture X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I suggest we make a productive list of what problems need solving and then discuss and get input on the priority of those problems, a list of high level views on solutions, the probability of implementation, and how a transition would be developed to take us there. Also keep suggestions within the bounds of an SDO, which is what the IETF is and its charter, mission, and objective. Example: Problem: Transport Layer needs to provide in the market failover to new IP address, but not tear down the IP session association. TCP/UDP do not provide session layer failover to multiple IP addresses. SCTP does permit this behavior. How do we deprecate TCP/UDP so SCTP can become the dominant NGN for the Transport Layer, is there anything the IETF can do? (Ignoring DCCP for this example). Priority Questions: - Important to SHIM6, HIP, and Mobile IP. Are these priorities and are they building shims around TCP/UDP. - Would this help with network location vs. identification of node/device/sensor - Is there a security advantage to supporting as dominant SCTP Transport Layer context. - Does it work for both IPv4 and IPv6. - What customers in the market would find this useful for IETF to work on this as SDO. - What enhancements could be made to SCTP for QoS Statistics Gathering, Security, etc. Implementation Questions: - What are the ramifications to current installed base networks and applications? - What could be done with APIs? Transition Questions: - Is a transition from TCP/UDP required? - If yes what would be the needs of such a transition? - What would be the engineering costs of such a transition? - How disruptive would the transition be to those using the specifications from the IETF for their Internet Architecture? - Who are the non IETF stakeholders? This is the type of discussion that is required in some format as opposed to just a stream of consciousness. /jim =20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Feb 28 17:17:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FED9p-0003Tn-5V; Tue, 28 Feb 2006 17:17:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FED9o-0003Ti-2G for architecture-discuss@ietf.org; Tue, 28 Feb 2006 17:17:24 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FED9n-0001ro-EZ for architecture-discuss@ietf.org; Tue, 28 Feb 2006 17:17:24 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 28 Feb 2006 14:17:05 -0800 X-IronPort-AV: i="4.02,154,1139212800"; d="scan'208"; a="410991183:sNHT1818412288" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k1SMH0Vb004618; Tue, 28 Feb 2006 14:17:05 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 28 Feb 2006 14:16:59 -0800 Received: from [10.32.244.220] ([10.32.244.220]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 28 Feb 2006 14:16:59 -0800 In-Reply-To: <936A4045C332714F975800409DE0924001DEF45E@tayexc14.americas.cpqcorp.net> References: <936A4045C332714F975800409DE0924001DEF45E@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [arch-d] What Problems are We Solving for the Internet Architecture Date: Tue, 28 Feb 2006 14:16:56 -0800 To: "Bound, Jim" X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 28 Feb 2006 22:16:59.0241 (UTC) FILETIME=[B1438590:01C63CB4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Feb 27, 2006, at 10:47 PM, Bound, Jim wrote: > I suggest we make a productive list of what problems need solving > and then discuss and get input on the priority of those problems, a > list of high level views on solutions, the probability of > implementation, and how a transition would be developed to take us > there. Also keep suggestions within the bounds of an SDO, which is > what the IETF is and its charter, mission, and objective. > > Example: > > Problem: Transport Layer needs to provide in the market failover to > new IP address, but not tear down the IP session association. TCP/ > UDP do not provide session layer failover to multiple IP > addresses. SCTP does permit this behavior. How do we deprecate > TCP/UDP so SCTP can become the dominant NGN for the Transport > Layer, is there anything the IETF can do? (Ignoring DCCP for this > example). This particular problem is IMHO not well stated. STCP is designed for a different problem than TCP. It is designed basically to support transaction processing in what is sometimes called a TCP-friendly manner, where a transaction might be as short as a few hundred bytes or as long as a few tens of thousands. TCP was designed as a class four transport supporting a single synchronized exchange, and in its testing has historically been used where there is one thing that someone wants to do, such as move a file or support an echoplex exchange. I would argue that we want to see SCTP deployment, but the matter of IP Address replacement can be handled either by deployment of SCTP for the single-serial-session purposes, or TCP could sprout the capability. The architectural question is really, I think, to complete the separation between the internet and transport layers, so that a transport layer session is not tied to a single address pair. In TCP, we could simply copy the SCTP approach, which has the session tied to a single address pair at any given time, or we could have each TCP- speaker simply announce to the other the various addresses it might use, and one the announcement has been reliably received, have it assume that segments might arrive from any of the peer's announced addresses to any one of this system's addresses, but using the same port pair and other TCB state. In that case, the peer is able to spread his traffic on all address pairs if it suits him, or change them at a whim, because instead of the TCP session having one address/ port-pair tuple that identifies it, it has m*n identifiers that are mutual aliases, all equally valid at any given time. > Priority Questions: > > - Important to SHIM6, HIP, and Mobile IP. Are these priorities and > are they building shims around TCP/UDP. Personally, I think each of these has its place operationally and yet is also something of a kluge and overkill. That, to me, is the single biggest reason that the marketplace hasn't necessarily adopted them or is driving these solutions. If TCP and SCTP can announce an alternate address like I described above, now add the concept that they could withdraw an announced address. Mobile handover just got fixed - at least the easy case in which there is a multiple RTT overlap during which the moving endpoint can send a message that announces the new address and withdraws the old one. The problem is of course that the datagram is unreliable; the moving endpoint would want to send it from its "old" address, the one its peer knows, and at least on a retransmission would want to send it to each of the announced addresses of its peer. That still doesn't address the case in which the "old" address simply stops working (the mobile device turns a corner and simultaneously loses the "old" and starts acquisition of the "new"). So there may also be a requirement for a way for an entirely new session from what would appear to be an unknown party to identify and authenticate itself, produce the TCP/SCTP state that it knows, and pick up where it had previously left off. That would require some concept of a session identifier... See RFC 2103. Say "Locator/Endpoint Identifier split" (RFC 1992)... but it goes beyond Nimrod routing; while the Locator is a network layer address, the Endpoint Identifier is a session layer concept, and what we're really saying is that we need some form of session management layer that lives *above* the transport. Note I didn't say "the ISO Session Layer" - please God, no - but something that lives in about that place and securely manages sessions. By the way, if I wrote a I-D named "we actually need a session management layer", how would I identify it? Is that draft-baker-arch- *-??.txt? > - Would this help with network location vs. identification of node/ > device/sensor I think so. That said, I'm not entirely convinced that the Endpoint ID needs to be numeric. The Nimrod architecture discusses a binary value (the EID) and an ASCII value (the Endpoint Label or EL). What I think is actually necessary is a globally unique thingamajig that can be used to identify the system one wants to talk with, and it could be a network layer address (as in IP Mobility), an ASCII or Unicode name, or something else. That value of it being "something else" is that one avoids the overloadings implicit in re-using something that was actually designed for something else. However, using a network layer address has the elegance of providing a defined way to find the thing, and using a DNS name has the elegance of already having a way to look things up. If we do "something else", we have to add that new thing to the mechanisms by which we do things, and do so in an elegant way. That might be hard. > - Is there a security advantage to supporting as dominant SCTP > Transport Layer context. I think that's the wrong question. SCTP and TCP (and UDP if you include the methods by which the relevant application uses it) are implementations of the transport concept, not "the transport". > - Does it work for both IPv4 and IPv6. The guy Nimrod is named for is fairly disgusted with IPv6 because it didn't address this problem and in its addressing architecture didn't leave him room to do a next generation routing architecture. If you really want to address it, I *think* it can be done without re- defining the IPv6 address, but be prepared for that question to come up. > - What customers in the market would find this useful for IETF to > work on this as SDO. I have heard from various ISPs that they would like to see this addressed. Many of those ISPs also tell me that I can deploy any routing protocol I like as long as it is BGP. So take that with an appropriate dosage of salt. I have also heard from various enterprise customers that they have problems that this kind of thing might be a solution to. I haven't heard them say that this is the solution they are looking for, however; they usually come in with a marketing pitch from one competitor or another and ask us what we think about it, as opposed to saying "what I would really like to do is solve problem" or "I need a solution that looks kinda sorta like ". So while this is IMHO a useful class of solution, I haven't got a trivially obvious way to tie it to a customer-felt problem. The latter really helps... > - What enhancements could be made to SCTP for QoS Statistics > Gathering, Security, etc. I believe that you actually will benefit from putting those in separate architectural entities. Let me give you an example. If you look at the TCP state machine, a fair bit of it is there to support graceful close - the concept that we would like to close the pipe, but not before making sure that all traffic has made it through the pipe in both directions. There is complexity there, and a bug (the TIME_WAIT issue) that TCP implementations have to fix. The Xerox Sequenced Packet Protocol is much simpler, and relegates graceful close to the higher layer, but provides a standard mechanism to accomplish it. Basically, each peer tells the other using a tag that it has sent its last packet, and acknowledges receipt of that tag with another tagged message. When a peer has announced to its peer that it is done and the peer has acknowledged that, and it has received the "FIN" tag from the peer and sent its acknowledge, it sets a timer, and when the timer pops it clears the shared state. By moving graceful close tot he next higher layer but providing a mechanism in SPP for the client to use, the entire problem is simplified and made to work well. There are two kinds of transport layer security: securing the data in the channel, and securing the channel. These might be TLS and IPsec in our environment, or there might be other solutions. Statistics is the province of a statistical entity, I should think, but probably has support in the instrumented entity. > Implementation Questions: > > - What are the ramifications to current installed base networks and > applications? I think you have to assume that there will be a long coexistence period. People will switch from a to b as vendor software enables them to and as they are motivated to turn it on. Think in terms of successful solutions being ones that result in tangible monetary benefits both to the end user and the the providers of the services. > - What could be done with APIs? A lot. Can't comment further without more detail on what they are APIs from and to. > Transition Questions: > > - Is a transition from TCP/UDP required? I think not, but there is an enhancement to TCP that is required, and I would suggest that migrating from UDP to SCTP has value. > - If yes what would be the needs of such a transition? > > - What would be the engineering costs of such a transition? > > - How disruptive would the transition be to those using the > specifications from the IETF for their Internet Architecture? > > - Who are the non IETF stakeholders? > > This is the type of discussion that is required in some format as > opposed to just a stream of consciousness. Yes. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Feb 28 17:35:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEDRX-0007V5-EX; Tue, 28 Feb 2006 17:35:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEDRW-0007Ut-3Z for architecture-discuss@ietf.org; Tue, 28 Feb 2006 17:35:42 -0500 Received: from pop-knobcone.atl.sa.earthlink.net ([207.69.195.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEDRU-00035g-Sj for architecture-discuss@ietf.org; Tue, 28 Feb 2006 17:35:42 -0500 Received: from h-64-105-34-111.snvacaid.dynamic.covad.net ([64.105.34.111] helo=oemcomputer) by pop-knobcone.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1FEDRU-0001NS-00 for architecture-discuss@ietf.org; Tue, 28 Feb 2006 17:35:40 -0500 Message-ID: <007f01c63cb7$93853460$6401a8c0@oemcomputer> From: "Randy Presuhn" To: References: <936A4045C332714F975800409DE0924001DEF45E@tayexc14.americas.cpqcorp.net> Subject: Re: [arch-d] What Problems are We Solving for the InternetArchitecture Date: Tue, 28 Feb 2006 14:37:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Hi - > From: "Fred Baker" > To: "Bound, Jim" > Cc: > Sent: Tuesday, February 28, 2006 2:16 PM > Subject: Re: [arch-d] What Problems are We Solving for the InternetArchitecture ... > Say "Locator/Endpoint Identifier split" (RFC 1992)... but it goes > beyond Nimrod routing; while the Locator is a network layer address, > the Endpoint Identifier is a session layer concept, and what we're > really saying is that we need some form of session management layer > that lives *above* the transport. Note I didn't say "the ISO Session > Layer" - please God, no - but something that lives in about that > place and securely manages sessions. ... Agreed. It certainly shifts the perspective on problems like multihoming and mobility, and would be good to look at in the light of experience with SCTP and HIP. I'd love to see more work along this line. Randy _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Feb 28 23:27:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEIwH-0002tM-UM; Tue, 28 Feb 2006 23:27:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEIwF-0002oE-Pt for architecture-discuss@ietf.org; Tue, 28 Feb 2006 23:27:47 -0500 Received: from palrel12.hp.com ([156.153.255.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEIw5-00031U-Ve for architecture-discuss@ietf.org; Tue, 28 Feb 2006 23:27:47 -0500 Received: from cacexg11.americas.cpqcorp.net (cacexg11.americas.cpqcorp.net [16.92.1.67]) by palrel12.hp.com (Postfix) with ESMTP id 0137338D22; Tue, 28 Feb 2006 20:27:36 -0800 (PST) Received: from cacexb11.americas.cpqcorp.net ([16.92.1.48]) by cacexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Feb 2006 20:26:37 -0800 Received: from tayexb11.americas.cpqcorp.net ([16.103.130.93]) by cacexb11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Feb 2006 20:26:38 -0800 Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexb11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Feb 2006 23:26:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] What Problems are We Solving for the InternetArchitecture Date: Tue, 28 Feb 2006 23:26:34 -0500 Message-ID: <936A4045C332714F975800409DE0924001DEFA89@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] What Problems are We Solving for the InternetArchitecture Thread-Index: AcY8tMirm8WlwBjBSTWLivaL83eUYgAL3VgA From: "Bound, Jim" To: "Fred Baker" X-OriginalArrivalTime: 01 Mar 2006 04:26:36.0629 (UTC) FILETIME=[54046050:01C63CE8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 96e0f8497f38c15fbfc8f6f315bcdecb Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Responses in line. This was really off the top of my head for content (less than 2 minutes) main point is we need some form of framework to identify and depict what problems we want to solve as template. =20 > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com]=20 > Sent: Tuesday, February 28, 2006 5:17 PM > To: Bound, Jim > Cc: architecture-discuss@ietf.org > Subject: Re: [arch-d] What Problems are We Solving for the=20 > InternetArchitecture >=20 > On Feb 27, 2006, at 10:47 PM, Bound, Jim wrote: > > I suggest we make a productive list of what problems need solving =20 > > and then discuss and get input on the priority of those=20 > problems, a =20 > > list of high level views on solutions, the probability of =20 > > implementation, and how a transition would be developed to take us =20 > > there. Also keep suggestions within the bounds of an SDO, which is =20 > > what the IETF is and its charter, mission, and objective. > > > > Example: > > > > Problem: Transport Layer needs to provide in the market=20 > failover to =20 > > new IP address, but not tear down the IP session association. TCP/=20 > > UDP do not provide session layer failover to multiple IP =20 > > addresses. SCTP does permit this behavior. How do we deprecate =20 > > TCP/UDP so SCTP can become the dominant NGN for the Transport =20 > > Layer, is there anything the IETF can do? (Ignoring DCCP for this =20 > > example). >=20 > This particular problem is IMHO not well stated. STCP is=20 SCTP :-) > designed for =20 > a different problem than TCP. My practical day job experience with customers running SCTP is not congruent with your input, but good discussion. For this problem statement the proposition is that tearing down transport connections can be avoided with SCTP and not with TCP to add to what I stated. > It is designed basically to support =20 > transaction processing in what is sometimes called a TCP-friendly =20 > manner, where a transaction might be as short as a few hundred bytes =20 > or as long as a few tens of thousands. TCP was designed as a class =20 > four transport supporting a single synchronized exchange, and in its =20 > testing has historically been used where there is one thing that =20 > someone wants to do, such as move a file or support an echoplex =20 > exchange. SCTP incorporated all of TCP at least in implementations I have seen and test results from it just extends the capability of the transport layer you reference. =20 NB: Randy Stewart are you on this list ?????????? Ping Ping :--) >=20 > I would argue that we want to see SCTP deployment, but the matter of =20 > IP Address replacement can be handled either by deployment of SCTP =20 > for the single-serial-session purposes, or TCP could sprout the =20 > capability. I cannot understand your point here, sorry. This is not this specific problem space presented. The objective first is to create implementation deployment model and verification that we can move to independent IP associations under SCTP association as first step. Add/Delete of additional addresses is supported by SCTP. >=20 > The architectural question is really, I think, to complete the =20 > separation between the internet and transport layers, so that a =20 > transport layer session is not tied to a single address pair.=20 Agree. > In TCP, =20 > we could simply copy the SCTP approach, which has the session=20 > tied to =20 > a single address pair at any given time, or we could have each TCP-=20 > speaker simply announce to the other the various addresses it might =20 > use, and one the announcement has been reliably received, have it =20 > assume that segments might arrive from any of the peer's announced =20 > addresses to any one of this system's addresses, but using the same =20 > port pair and other TCB state. In that case, the peer is able to =20 > spread his traffic on all address pairs if it suits him, or change =20 > them at a whim, because instead of the TCP session having one=20 > address/=20 > port-pair tuple that identifies it, it has m*n identifiers that are =20 > mutual aliases, all equally valid at any given time. True, but I believe SCTP is already done and can be used and adding this to TCP is not worth the engineering cost or effort as I see it right now. >=20 > > Priority Questions: > > > > - Important to SHIM6, HIP, and Mobile IP. Are these priorities and =20 > > are they building shims around TCP/UDP. >=20 > Personally, I think each of these has its place operationally=20 > and yet =20 > is also something of a kluge and overkill. That, to me, is=20 > the single =20 > biggest reason that the marketplace hasn't necessarily adopted them =20 > or is driving these solutions. I agree except for Mobile IP that is happening now for both IPv4 and IPv6. >=20 > If TCP and SCTP can announce an alternate address like I described =20 > above, now add the concept that they could withdraw an announced =20 > address. Mobile handover just got fixed - at least the easy case in =20 > which there is a multiple RTT overlap during which the moving =20 > endpoint can send a message that announces the new address and =20 > withdraws the old one. The problem is of course that the datagram is =20 > unreliable; the moving endpoint would want to send it from its "old" =20 > address, the one its peer knows, and at least on a retransmission =20 > would want to send it to each of the announced addresses of=20 > its peer. =20 I am not concerned today with the handover I believe current groups like DNS and mobopts have very good handle on this and I am more concerened about routing optimizations when the node/device/sensor arrives at new link and the management of that process. =20 But I agree a new transport model with single session association would permit us to reevaluate handovers. > That still doesn't address the case in which the "old"=20 > address simply =20 > stops working (the mobile device turns a corner and simultaneously =20 > loses the "old" and starts acquisition of the "new"). So there may =20 > also be a requirement for a way for an entirely new session=20 > from what =20 > would appear to be an unknown party to identify and authenticate =20 > itself, produce the TCP/SCTP state that it knows, and pick up where =20 > it had previously left off. That would require some concept of a =20 > session identifier... See RFC 2103. Yes or simply give up and rebind which is what will happen in practice today. >=20 > Say "Locator/Endpoint Identifier split" (RFC 1992)... but it goes =20 > beyond Nimrod routing; while the Locator is a network layer address, =20 > the Endpoint Identifier is a session layer concept, and what we're =20 > really saying is that we need some form of session management layer =20 > that lives *above* the transport. Note I didn't say "the ISO Session =20 > Layer" - please God, no - but something that lives in about that =20 > place and securely manages sessions. Agree and strongly agree with 'please God no OSI session et al'. >=20 > By the way, if I wrote a I-D named "we actually need a session =20 > management layer", how would I identify it? Is that draft-baker-arch-=20 > *-??.txt? Question is still premature for my brain. >=20 > > - Would this help with network location vs. identification of node/=20 > > device/sensor >=20 > I think so. That said, I'm not entirely convinced that the Endpoint =20 > ID needs to be numeric. Agree. > The Nimrod architecture discusses a binary =20 > value (the EID) and an ASCII value (the Endpoint Label or=20 > EL). What I =20 > think is actually necessary is a globally unique thingamajig=20 > that can =20 > be used to identify the system one wants to talk with, and it could =20 > be a network layer address (as in IP Mobility), an ASCII or Unicode =20 > name, or something else. That value of it being "something else" is =20 > that one avoids the overloadings implicit in re-using something that =20 > was actually designed for something else. However, using a network =20 > layer address has the elegance of providing a defined way to=20 > find the =20 > thing, and using a DNS name has the elegance of already having a way =20 > to look things up. If we do "something else", we have to add=20 > that new =20 > thing to the mechanisms by which we do things, and do so in an =20 > elegant way. That might be hard. Very hard. >=20 > > - Is there a security advantage to supporting as dominant SCTP =20 > > Transport Layer context. >=20 > I think that's the wrong question. SCTP and TCP (and UDP if you =20 > include the methods by which the relevant application uses it) are =20 > implementations of the transport concept, not "the transport". Thought was if we can enhance the security of transport layer as we have network layer with IPsec to the one session from SCTP main association that provides another door for bad guys to break through as the door for the network layer. The other transport associations under the main association can reuse the security set up (most of the cost for performance) and the keys etc etc. Very rough idea but has had some brain storm discussion within some security focused forums as a note under needs for multilevel security. >=20 > > - Does it work for both IPv4 and IPv6. >=20 > The guy Nimrod is named for is fairly disgusted with IPv6 because it =20 > didn't address this problem and in its addressing=20 > architecture didn't =20 > leave him room to do a next generation routing architecture. If you =20 > really want to address it, I *think* it can be done without re-=20 > defining the IPv6 address, but be prepared for that question=20 > to come up. Cannot comment on the past. My view is the IP adddress should only be the locator and new abstraction is required for identifier. IP layer or IP address is not the place to solve the problem is my view. >=20 > > - What customers in the market would find this useful for IETF to =20 > > work on this as SDO. >=20 > I have heard from various ISPs that they would like to see this =20 > addressed. Many of those ISPs also tell me that I can deploy any =20 > routing protocol I like as long as it is BGP. So take that with an =20 > appropriate dosage of salt. I have also heard from various=20 > enterprise =20 > customers that they have problems that this kind of thing might be a =20 > solution to. I haven't heard them say that this is the solution they =20 > are looking for, however; they usually come in with a=20 > marketing pitch =20 > from one competitor or another and ask us what we think about it, as =20 > opposed to saying "what I would really like to do is solve =20 > problem" or "I need a solution that looks kinda sorta like ". =20 > So while this is IMHO a useful class of solution, I haven't got a =20 > trivially obvious way to tie it to a customer-felt problem. The =20 > latter really helps... My customers are seeing/complaining about the identification for many reasons Mobility, Net+RFIDs, and the Network Providers for other reasons we have discussed previously. Also there is the security benefit. >=20 > > - What enhancements could be made to SCTP for QoS Statistics =20 > > Gathering, Security, etc. >=20 > I believe that you actually will benefit from putting those in =20 > separate architectural entities. Could be but many upstart router vendors are figuring ways to determine traffic QoS from stats and in some very elegant ways I am sure your aware of and just thinking can we extend SCTP for inter/intra routing communcations also that clients could be enhanced to assist with QoS feedback. >=20 > Let me give you an example. If you look at the TCP state machine, a =20 > fair bit of it is there to support graceful close - the concept that =20 > we would like to close the pipe, but not before making sure that all =20 > traffic has made it through the pipe in both directions. There is =20 > complexity there, and a bug (the TIME_WAIT issue) that TCP =20 > implementations have to fix. The Xerox Sequenced Packet Protocol is =20 > much simpler, and relegates graceful close to the higher layer, but =20 > provides a standard mechanism to accomplish it. Basically, each peer =20 > tells the other using a tag that it has sent its last packet, and =20 > acknowledges receipt of that tag with another tagged message. When a =20 > peer has announced to its peer that it is done and the peer has =20 > acknowledged that, and it has received the "FIN" tag from the peer =20 > and sent its acknowledge, it sets a timer, and when the timer=20 > pops it =20 > clears the shared state. By moving graceful close tot he next higher =20 > layer but providing a mechanism in SPP for the client to use, the =20 > entire problem is simplified and made to work well. Yep. The idea I relate above is to report back there is a problem to the router in some form. >=20 > There are two kinds of transport layer security: securing the=20 > data in =20 > the channel, and securing the channel. These might be TLS and IPsec =20 > in our environment, or there might be other solutions. Statistics is =20 > the province of a statistical entity, I should think, but probably =20 > has support in the instrumented entity. Agree strongly with last sentence. >=20 > > Implementation Questions: > > > > - What are the ramifications to current installed base=20 > networks and =20 > > applications? >=20 > I think you have to assume that there will be a long coexistence =20 > period. People will switch from a to b as vendor software enables =20 > them to and as they are motivated to turn it on. Think in terms of =20 > successful solutions being ones that result in tangible monetary =20 > benefits both to the end user and the the providers of the services. Agree. >=20 > > - What could be done with APIs? >=20 > A lot. Can't comment further without more detail on what they are =20 > APIs from and to. Yep. >=20 > > Transition Questions: > > > > - Is a transition from TCP/UDP required? >=20 > I think not, but there is an enhancement to TCP that is=20 > required, and =20 > I would suggest that migrating from UDP to SCTP has value. Yes but still believe TCP needs to die over time. >=20 > > - If yes what would be the needs of such a transition? > > > > - What would be the engineering costs of such a transition? > > > > - How disruptive would the transition be to those using the =20 > > specifications from the IETF for their Internet Architecture? > > > > - Who are the non IETF stakeholders? > > > > This is the type of discussion that is required in some format as =20 > > opposed to just a stream of consciousness. >=20 > Yes. Yep if we can just talk like this and keep focus we can at a minimum identify a work item for next steps is my thinking. Thanks /jim >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Feb 28 23:29:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEIy7-0003dF-AO; Tue, 28 Feb 2006 23:29:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEIy6-0003YO-63 for architecture-discuss@ietf.org; Tue, 28 Feb 2006 23:29:42 -0500 Received: from ccerelbas04.cce.hp.com ([161.114.21.107]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEIxv-000340-B2 for architecture-discuss@ietf.org; Tue, 28 Feb 2006 23:29:42 -0500 Received: from cceexg11.americas.cpqcorp.net (cceexg11.americas.cpqcorp.net [16.81.1.59]) by ccerelbas04.cce.hp.com (Postfix) with ESMTP id E89E3344A7; Tue, 28 Feb 2006 22:29:30 -0600 (CST) Received: from cceexb12.americas.cpqcorp.net ([16.81.1.32]) by cceexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Feb 2006 22:29:30 -0600 Received: from tayexb12.americas.cpqcorp.net ([16.103.130.102]) by cceexb12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Feb 2006 22:29:30 -0600 Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexb12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Feb 2006 23:29:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] What Problems are We Solving for the InternetArchitecture Date: Tue, 28 Feb 2006 23:29:27 -0500 Message-ID: <936A4045C332714F975800409DE0924001DEFA8B@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] What Problems are We Solving for the InternetArchitecture Thread-Index: AcY8tMirm8WlwBjBSTWLivaL83eUYgAL3VgAAAEbzcA= From: "Bound, Jim" To: "Bound, Jim" , "Fred Baker" X-OriginalArrivalTime: 01 Mar 2006 04:29:28.0958 (UTC) FILETIME=[BABBB1E0:01C63CE8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 354d6627469d0be959806e15912c47f1 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org whoops below not "DNS" but DNA (for groups working on handover issues). /jim=20 > -----Original Message----- > From: Bound, Jim=20 > Sent: Tuesday, February 28, 2006 11:27 PM > To: 'Fred Baker' > Cc: architecture-discuss@ietf.org > Subject: RE: [arch-d] What Problems are We Solving for the=20 > InternetArchitecture >=20 > Responses in line. This was really off the top of my head=20 > for content (less than 2 minutes) main point is we need some=20 > form of framework to identify and depict what problems we=20 > want to solve as template. =20 >=20 > > -----Original Message----- > > From: Fred Baker [mailto:fred@cisco.com]=20 > > Sent: Tuesday, February 28, 2006 5:17 PM > > To: Bound, Jim > > Cc: architecture-discuss@ietf.org > > Subject: Re: [arch-d] What Problems are We Solving for the=20 > > InternetArchitecture > >=20 > > On Feb 27, 2006, at 10:47 PM, Bound, Jim wrote: > > > I suggest we make a productive list of what problems need=20 > solving =20 > > > and then discuss and get input on the priority of those=20 > > problems, a =20 > > > list of high level views on solutions, the probability of =20 > > > implementation, and how a transition would be developed=20 > to take us =20 > > > there. Also keep suggestions within the bounds of an SDO,=20 > which is =20 > > > what the IETF is and its charter, mission, and objective. > > > > > > Example: > > > > > > Problem: Transport Layer needs to provide in the market=20 > > failover to =20 > > > new IP address, but not tear down the IP session=20 > association. TCP/=20 > > > UDP do not provide session layer failover to multiple IP =20 > > > addresses. SCTP does permit this behavior. How do we deprecate =20 > > > TCP/UDP so SCTP can become the dominant NGN for the Transport =20 > > > Layer, is there anything the IETF can do? (Ignoring DCCP=20 > for this =20 > > > example). > >=20 > > This particular problem is IMHO not well stated. STCP is=20 > SCTP :-) > > designed for =20 > > a different problem than TCP. >=20 > My practical day job experience with customers running SCTP=20 > is not congruent with your input, but good discussion. For=20 > this problem statement the proposition is that tearing down=20 > transport connections can be avoided with SCTP and not with=20 > TCP to add to what I stated. >=20 > > It is designed basically to support =20 > > transaction processing in what is sometimes called a TCP-friendly =20 > > manner, where a transaction might be as short as a few=20 > hundred bytes =20 > > or as long as a few tens of thousands. TCP was designed as a class =20 > > four transport supporting a single synchronized exchange,=20 > and in its =20 > > testing has historically been used where there is one thing that =20 > > someone wants to do, such as move a file or support an echoplex =20 > > exchange. >=20 > SCTP incorporated all of TCP at least in implementations I=20 > have seen and test results from it just extends the=20 > capability of the transport layer you reference. =20 >=20 > NB: Randy Stewart are you on this list ?????????? Ping Ping :--) >=20 > >=20 > > I would argue that we want to see SCTP deployment, but the=20 > matter of =20 > > IP Address replacement can be handled either by deployment of SCTP =20 > > for the single-serial-session purposes, or TCP could sprout the =20 > > capability. >=20 > I cannot understand your point here, sorry. This is not this=20 > specific problem space presented. The objective first is to=20 > create implementation deployment model and verification that=20 > we can move to independent IP associations under SCTP=20 > association as first step. Add/Delete of additional addresses=20 > is supported by SCTP. >=20 > >=20 > > The architectural question is really, I think, to complete the =20 > > separation between the internet and transport layers, so that a =20 > > transport layer session is not tied to a single address pair.=20 >=20 > Agree. >=20 > > In TCP, =20 > > we could simply copy the SCTP approach, which has the session=20 > > tied to =20 > > a single address pair at any given time, or we could have each TCP-=20 > > speaker simply announce to the other the various addresses=20 > it might =20 > > use, and one the announcement has been reliably received, have it =20 > > assume that segments might arrive from any of the peer's announced =20 > > addresses to any one of this system's addresses, but using=20 > the same =20 > > port pair and other TCB state. In that case, the peer is able to =20 > > spread his traffic on all address pairs if it suits him, or change =20 > > them at a whim, because instead of the TCP session having one=20 > > address/=20 > > port-pair tuple that identifies it, it has m*n identifiers=20 > that are =20 > > mutual aliases, all equally valid at any given time. >=20 > True, but I believe SCTP is already done and can be used and=20 > adding this to TCP is not worth the engineering cost or=20 > effort as I see it right now. >=20 > >=20 > > > Priority Questions: > > > > > > - Important to SHIM6, HIP, and Mobile IP. Are these=20 > priorities and =20 > > > are they building shims around TCP/UDP. > >=20 > > Personally, I think each of these has its place operationally=20 > > and yet =20 > > is also something of a kluge and overkill. That, to me, is=20 > > the single =20 > > biggest reason that the marketplace hasn't necessarily=20 > adopted them =20 > > or is driving these solutions. >=20 > I agree except for Mobile IP that is happening now for both=20 > IPv4 and IPv6. >=20 > >=20 > > If TCP and SCTP can announce an alternate address like I described =20 > > above, now add the concept that they could withdraw an announced =20 > > address. Mobile handover just got fixed - at least the easy=20 > case in =20 > > which there is a multiple RTT overlap during which the moving =20 > > endpoint can send a message that announces the new address and =20 > > withdraws the old one. The problem is of course that the=20 > datagram is =20 > > unreliable; the moving endpoint would want to send it from=20 > its "old" =20 > > address, the one its peer knows, and at least on a retransmission =20 > > would want to send it to each of the announced addresses of=20 > > its peer. =20 >=20 > I am not concerned today with the handover I believe current=20 > groups like DNS and mobopts have very good handle on this and=20 > I am more concerened about routing optimizations when the=20 > node/device/sensor arrives at new link and the management of=20 > that process. =20 >=20 > But I agree a new transport model with single session=20 > association would permit us to reevaluate handovers. >=20 > > That still doesn't address the case in which the "old"=20 > > address simply =20 > > stops working (the mobile device turns a corner and simultaneously =20 > > loses the "old" and starts acquisition of the "new"). So there may =20 > > also be a requirement for a way for an entirely new session=20 > > from what =20 > > would appear to be an unknown party to identify and authenticate =20 > > itself, produce the TCP/SCTP state that it knows, and pick=20 > up where =20 > > it had previously left off. That would require some concept of a =20 > > session identifier... See RFC 2103. >=20 > Yes or simply give up and rebind which is what will happen in=20 > practice today. >=20 > >=20 > > Say "Locator/Endpoint Identifier split" (RFC 1992)... but it goes =20 > > beyond Nimrod routing; while the Locator is a network layer=20 > address, =20 > > the Endpoint Identifier is a session layer concept, and what we're =20 > > really saying is that we need some form of session=20 > management layer =20 > > that lives *above* the transport. Note I didn't say "the=20 > ISO Session =20 > > Layer" - please God, no - but something that lives in about that =20 > > place and securely manages sessions. >=20 > Agree and strongly agree with 'please God no OSI session et al'. >=20 > >=20 > > By the way, if I wrote a I-D named "we actually need a session =20 > > management layer", how would I identify it? Is that=20 > draft-baker-arch-=20 > > *-??.txt? >=20 > Question is still premature for my brain. >=20 > >=20 > > > - Would this help with network location vs.=20 > identification of node/=20 > > > device/sensor > >=20 > > I think so. That said, I'm not entirely convinced that the=20 > Endpoint =20 > > ID needs to be numeric. >=20 > Agree. >=20 > > The Nimrod architecture discusses a binary =20 > > value (the EID) and an ASCII value (the Endpoint Label or=20 > > EL). What I =20 > > think is actually necessary is a globally unique thingamajig=20 > > that can =20 > > be used to identify the system one wants to talk with, and=20 > it could =20 > > be a network layer address (as in IP Mobility), an ASCII or=20 > Unicode =20 > > name, or something else. That value of it being "something=20 > else" is =20 > > that one avoids the overloadings implicit in re-using=20 > something that =20 > > was actually designed for something else. However, using a network =20 > > layer address has the elegance of providing a defined way to=20 > > find the =20 > > thing, and using a DNS name has the elegance of already=20 > having a way =20 > > to look things up. If we do "something else", we have to add=20 > > that new =20 > > thing to the mechanisms by which we do things, and do so in an =20 > > elegant way. That might be hard. >=20 > Very hard. >=20 > >=20 > > > - Is there a security advantage to supporting as dominant SCTP =20 > > > Transport Layer context. > >=20 > > I think that's the wrong question. SCTP and TCP (and UDP if you =20 > > include the methods by which the relevant application uses it) are =20 > > implementations of the transport concept, not "the transport". >=20 > Thought was if we can enhance the security of transport layer=20 > as we have network layer with IPsec to the one session from=20 > SCTP main association that provides another door for bad guys=20 > to break through as the door for the network layer. The=20 > other transport associations under the main association can=20 > reuse the security set up (most of the cost for performance)=20 > and the keys etc etc. Very rough idea but has had some brain=20 > storm discussion within some security focused forums as a=20 > note under needs for multilevel security. >=20 > >=20 > > > - Does it work for both IPv4 and IPv6. > >=20 > > The guy Nimrod is named for is fairly disgusted with IPv6=20 > because it =20 > > didn't address this problem and in its addressing=20 > > architecture didn't =20 > > leave him room to do a next generation routing=20 > architecture. If you =20 > > really want to address it, I *think* it can be done without re-=20 > > defining the IPv6 address, but be prepared for that question=20 > > to come up. >=20 > Cannot comment on the past. >=20 > My view is the IP adddress should only be the locator and new=20 > abstraction is required for identifier. IP layer or IP=20 > address is not the place to solve the problem is my view. >=20 > >=20 > > > - What customers in the market would find this useful for=20 > IETF to =20 > > > work on this as SDO. > >=20 > > I have heard from various ISPs that they would like to see this =20 > > addressed. Many of those ISPs also tell me that I can deploy any =20 > > routing protocol I like as long as it is BGP. So take that with an =20 > > appropriate dosage of salt. I have also heard from various=20 > > enterprise =20 > > customers that they have problems that this kind of thing=20 > might be a =20 > > solution to. I haven't heard them say that this is the=20 > solution they =20 > > are looking for, however; they usually come in with a=20 > > marketing pitch =20 > > from one competitor or another and ask us what we think=20 > about it, as =20 > > opposed to saying "what I would really like to do is solve =20 > > problem" or "I need a solution that looks kinda sorta like=20 > ". =20 > > So while this is IMHO a useful class of solution, I haven't got a =20 > > trivially obvious way to tie it to a customer-felt problem. The =20 > > latter really helps... >=20 > My customers are seeing/complaining about the identification=20 > for many reasons Mobility, Net+RFIDs, and the Network=20 > Providers for other reasons we have discussed previously.=20 > Also there is the security benefit. >=20 > >=20 > > > - What enhancements could be made to SCTP for QoS Statistics =20 > > > Gathering, Security, etc. > >=20 > > I believe that you actually will benefit from putting those in =20 > > separate architectural entities. >=20 > Could be but many upstart router vendors are figuring ways to=20 > determine traffic QoS from stats and in some very elegant=20 > ways I am sure your aware of and just thinking can we extend=20 > SCTP for inter/intra routing communcations also that clients=20 > could be enhanced to assist with QoS feedback. >=20 > >=20 > > Let me give you an example. If you look at the TCP state=20 > machine, a =20 > > fair bit of it is there to support graceful close - the=20 > concept that =20 > > we would like to close the pipe, but not before making sure=20 > that all =20 > > traffic has made it through the pipe in both directions. There is =20 > > complexity there, and a bug (the TIME_WAIT issue) that TCP =20 > > implementations have to fix. The Xerox Sequenced Packet=20 > Protocol is =20 > > much simpler, and relegates graceful close to the higher=20 > layer, but =20 > > provides a standard mechanism to accomplish it. Basically,=20 > each peer =20 > > tells the other using a tag that it has sent its last packet, and =20 > > acknowledges receipt of that tag with another tagged=20 > message. When a =20 > > peer has announced to its peer that it is done and the peer has =20 > > acknowledged that, and it has received the "FIN" tag from the peer =20 > > and sent its acknowledge, it sets a timer, and when the timer=20 > > pops it =20 > > clears the shared state. By moving graceful close tot he=20 > next higher =20 > > layer but providing a mechanism in SPP for the client to use, the =20 > > entire problem is simplified and made to work well. >=20 > Yep. The idea I relate above is to report back there is a=20 > problem to the router in some form. >=20 > >=20 > > There are two kinds of transport layer security: securing the=20 > > data in =20 > > the channel, and securing the channel. These might be TLS=20 > and IPsec =20 > > in our environment, or there might be other solutions.=20 > Statistics is =20 > > the province of a statistical entity, I should think, but probably =20 > > has support in the instrumented entity. >=20 > Agree strongly with last sentence. >=20 > >=20 > > > Implementation Questions: > > > > > > - What are the ramifications to current installed base=20 > > networks and =20 > > > applications? > >=20 > > I think you have to assume that there will be a long coexistence =20 > > period. People will switch from a to b as vendor software enables =20 > > them to and as they are motivated to turn it on. Think in terms of =20 > > successful solutions being ones that result in tangible monetary =20 > > benefits both to the end user and the the providers of the services. >=20 > Agree. >=20 > >=20 > > > - What could be done with APIs? > >=20 > > A lot. Can't comment further without more detail on what they are =20 > > APIs from and to. >=20 > Yep. >=20 > >=20 > > > Transition Questions: > > > > > > - Is a transition from TCP/UDP required? > >=20 > > I think not, but there is an enhancement to TCP that is=20 > > required, and =20 > > I would suggest that migrating from UDP to SCTP has value. >=20 > Yes but still believe TCP needs to die over time. >=20 > >=20 > > > - If yes what would be the needs of such a transition? > > > > > > - What would be the engineering costs of such a transition? > > > > > > - How disruptive would the transition be to those using the =20 > > > specifications from the IETF for their Internet Architecture? > > > > > > - Who are the non IETF stakeholders? > > > > > > This is the type of discussion that is required in some=20 > format as =20 > > > opposed to just a stream of consciousness. > >=20 > > Yes. >=20 > Yep if we can just talk like this and keep focus we can at a=20 > minimum identify a work item for next steps is my thinking. >=20 > Thanks > /jim > >=20 > > _______________________________________________ > > Architecture-discuss mailing list > > Architecture-discuss@ietf.org > > https://www1.ietf.org/mailman/listinfo/architecture-discuss > >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss