From architecture-discuss-bounces@ietf.org Thu Dec 01 17:03:05 2005 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 1EhwW9-000700-16; Thu, 01 Dec 2005 17:03:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhwW6-0006yt-UU for architecture-discuss@megatron.ietf.org; Thu, 01 Dec 2005 17:03:03 -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 RAA21881 for ; Thu, 1 Dec 2005 17:02:16 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ehwqc-0008Lx-FK for architecture-discuss@ietf.org; Thu, 01 Dec 2005 17:24:18 -0500 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB1LqaE12937; Thu, 1 Dec 2005 13:52:36 -0800 (PST) Message-ID: <438F711F.2010504@isi.edu> Date: Thu, 01 Dec 2005 13:54:39 -0800 From: Joe Touch User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dcrocker@bbiw.net Subject: Re: [arch-d] NIC Offload Affect References: <936A4045C332714F975800409DE0924001616CE9@tayexc14.americas.cpqcorp.net> <4383D652.1070503@dcrocker.net> In-Reply-To: <4383D652.1070503@dcrocker.net> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: architecture-discuss@ietf.org, "Bound, Jim" 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dave Crocker wrote: > > > >> on processors etc. what I am concerned about is 4 years from now >> 100GbE. will our architecture sustain what it needs to on a host or >> embedded software system. So when we add shims and new layers and new >> processing that has to be called out from the stack that has performance >> cost. Keeping the deering hourglass and the middle not bulging is I >> think very important. > > I suspect that the on-/off-board question merely makes it easier to > think of issues to focus on. So it's not so much that it creates > special problems, but perhaps it gets us thinking about thinks with some > better focus. Two observations: - weren't we worried about this back with 100Mbps? (and didn't this take care of itself?) - on/offboard processing is a pendulum that swings every 5 years or so; the problem is that off-board processing is a win only if the processor there is as fast (or faster) than the CPU, and CPUs leverage commodity development easier Bandwidth faster than the end system can use ends up being used for trunks until the end system catches up. As to getting data into the endsystem, it ends up needing to look more like a network itself (see the NetStation and Desktop Area Network research of the early 1990's). Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDj3EfE5f5cImnZrsRApJAAJsHVWaasNBiaOSu0GRPUHCd4mHxtACfQyrj xdpi9W7ImhpjpKSLuDPXMG0= =XsF/ -----END PGP SIGNATURE----- _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Dec 07 17:50:06 2005 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 1Ek86w-0000Jq-IZ; Wed, 07 Dec 2005 17:50:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek86v-0000Jd-3B for architecture-discuss@megatron.ietf.org; Wed, 07 Dec 2005 17:50:05 -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 RAA12865 for ; Wed, 7 Dec 2005 17:49:11 -0500 (EST) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ek8Sd-0004JD-JW for architecture-discuss@ietf.org; Wed, 07 Dec 2005 18:12:36 -0500 Received: from stl-av-01.boeing.com ([192.76.190.6]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id OAA06141 for ; Wed, 7 Dec 2005 14:49:44 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id jB7MnhC14653 for ; Wed, 7 Dec 2005 16:49:43 -0600 (CST) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Dec 2005 14:49:35 -0800 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 Date: Wed, 7 Dec 2005 14:49:33 -0800 Message-ID: <474EEBD229DF754FB83D256004D02108BBCAD1@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: Valid and Invalid Internet architectures and approaches thread-index: AcX7gH61C9twB5ihRR6iRmkRiDUnyg== From: "Fleischman, Eric" To: X-OriginalArrivalTime: 07 Dec 2005 22:49:35.0213 (UTC) FILETIME=[7ED3E9D0:01C5FB80] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable Subject: [arch-d] Valid and Invalid Internet architectures and approaches 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 Friends, Several months ago I stumbled upon a middlebox implementation that I believe is a classic example of being a "misbehaving middlebox", despite the fact that the approach is blessed by RFC 2401 and 2401bis (i.e., IETF standards).=20 I created an array of technical arguments for this characterization, including the fact that the approach simply doesn't operationally work because it explicitly segments the network for which an onerous unicast work-around exists but no multicast work-around exists. Thus, it effectively "breaks" IP with no current remedy at all. This operational argument didn't resonate with the RFC 2401bis editor but my architectural arguments did somewhat.=20 Thus, in order to build up better support for that line of reasoning, in the hopes that 2401bis may hopefully support a more viable design, I engaged many of you through two generic queries to the IETF mail list ("Question about the normative nature of IETF RFCs" and "Correct middlebox behavior"). The responses I received from these queries didn't result in consistent replies, leading me to conclude that the IETF no longer has a group consensus about these issues. Concerned about this possibility, I spent much of the recent Vancouver IETF talking with long-term IETF members about whether the Internet and the TCP/IP protocol suite currently has an architecture or not. The consistent (or, rather, unanimous) response was that it does not. Specifically, whereas we could assert underlying architectural principals upon which IP and the Internet were built as recently as eight years ago, and thereby identify "good" and "bad" approaches, the current "Wild West" evolution since then (e.g., convergence with SS#7 telephony and video networks; widespread middlebox deployments; an inability to distinguish between middleboxes, host, and router functionality; tunneling of various sorts without viable network management mechanisms; etc.) has resulted in an ad hoc creation lacking unifying constructs. Without such a foundation, I was told, how can we therefore talk about "good" or "bad" or "misbehaving"? So I asked them, if we indeed don't have any common foundation anymore, then what confidence do we have that our current system will continue to remain viable over time? Nobody provided me with any reassurance. Some pointed to GENI Project or other research activities as perhaps re-establishing a foundation to which the Internet could migrate over time. However, no answer was believable by a long-term operational guy like me. I can't imagine that our community really has thrown up its hands and embraced dissonance and brownian motion. But unless we can articulate an architecture, I do not understand how we can evolve the Internet in a rational fashion. We could perhaps hope that "local self interest" is ultimately maximized when approaches that benefit the majority are chosen. However, this is not always true and "benefits to the majority" is not something that can really be determined without an architectural foundation. Needless to say, I ultimately lost my argument with the 2401bis editor. However, I would hate to learn that I may someday also lose the Internet. Can you provide me with any hope that this will not happen? --Eric _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Dec 07 18:02:27 2005 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 1Ek8It-0003GX-5i; Wed, 07 Dec 2005 18:02:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek8Ir-0003GK-Q6 for architecture-discuss@megatron.ietf.org; Wed, 07 Dec 2005 18:02:25 -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 SAA14080 for ; Wed, 7 Dec 2005 18:01:32 -0500 (EST) Received: from rwcrmhc14.comcast.net ([216.148.227.154] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ek8ed-0004hz-Uy for architecture-discuss@ietf.org; Wed, 07 Dec 2005 18:24:57 -0500 Received: from [172.16.0.148] (adsl-71-130-5-137.dsl.snfc21.pacbell.net[71.130.5.137]) by comcast.net (rwcrmhc14) with SMTP id <20051207230204014007svrbe>; Wed, 7 Dec 2005 23:02:07 +0000 In-Reply-To: <474EEBD229DF754FB83D256004D02108BBCAD1@XCH-NW-6V1.nw.nos.boeing.com> References: <474EEBD229DF754FB83D256004D02108BBCAD1@XCH-NW-6V1.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3A43928D-0C23-418D-9E20-3711E7415B65@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches Date: Wed, 7 Dec 2005 15:02:05 -0800 To: "Fleischman, Eric" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 Dec 7, 2005, at 2:49 PM, Fleischman, Eric wrote: > I can't imagine that our community really has thrown up its hands and > embraced dissonance and brownian motion. Eric, This has been clearly and repeatedly stated. The usual situation is that we have conflicting technologies to achieve some goal and we choose to "let a thousand flowers bloom" or "let the market decide". Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Dec 07 19:36:24 2005 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 1Ek9lo-0004R4-Ds; Wed, 07 Dec 2005 19:36:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek9ln-0004Qr-4x for architecture-discuss@megatron.ietf.org; Wed, 07 Dec 2005 19:36:23 -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 TAA01432 for ; Wed, 7 Dec 2005 19:35:31 -0500 (EST) Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkA7Y-0001uz-2g for architecture-discuss@ietf.org; Wed, 07 Dec 2005 19:58:55 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 10EE286ADD; Wed, 7 Dec 2005 19:36:11 -0500 (EST) To: architecture-discuss@ietf.org Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches Message-Id: <20051208003611.10EE286ADD@mercury.lcs.mit.edu> Date: Wed, 7 Dec 2005 19:36:11 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org > From: Tony Li > The usual situation is that we have conflicting technologies to > achieve some goal and we choose to "let a thousand flowers bloom" or > "let the market decide". Tony, this does not necessarily lead to architectural decay, any more than having two different editors or C compilers for an operating system harms the architecture of that operating system. Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Dec 07 20:04:04 2005 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 1EkACa-0002YH-Av; Wed, 07 Dec 2005 20:04:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkACZ-0002Xs-IS for architecture-discuss@megatron.ietf.org; Wed, 07 Dec 2005 20:04:03 -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 UAA04576 for ; Wed, 7 Dec 2005 20:03:11 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkAYM-0002o3-CJ for architecture-discuss@ietf.org; Wed, 07 Dec 2005 20:26:35 -0500 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB80vjr20543; Wed, 7 Dec 2005 16:57:45 -0800 (PST) Message-ID: <4397858B.6010501@isi.edu> Date: Wed, 07 Dec 2005 16:59:55 -0800 From: Joe Touch User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Noel Chiappa Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches References: <20051208003611.10EE286ADD@mercury.lcs.mit.edu> In-Reply-To: <20051208003611.10EE286ADD@mercury.lcs.mit.edu> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Noel Chiappa wrote: > > From: Tony Li > > > The usual situation is that we have conflicting technologies to > > achieve some goal and we choose to "let a thousand flowers bloom" or > > "let the market decide". Like when IEEE approved two competing - and interfering - technologies for 802.11? (DS, FH) What results is fun if you like market competition, and horrible if you like interoperability (the cornerstone of the _Inter_net). All that means is we'll all have to wait _until_ the market decides, which delays everybody just so a few capitalists can have fun. ;-) Sometimes it's more productive to declare some mutations "bugs" rather than "new uses", and move on. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDl4WLE5f5cImnZrsRAvoyAJwLq45KFSwXz2nQqtvek2zyKPaDKACgoLxd jgy4BTqdCVEybWUiJdiMe8A= =A903 -----END PGP SIGNATURE----- _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Dec 07 20:04:06 2005 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 1EkACc-0002Yl-Jv; Wed, 07 Dec 2005 20:04:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkACb-0002Yg-7b for architecture-discuss@megatron.ietf.org; Wed, 07 Dec 2005 20:04:05 -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 UAA04579 for ; Wed, 7 Dec 2005 20:03:12 -0500 (EST) Received: from smtp-out1.oct.nac.net ([209.123.233.211]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EkAYO-0002o6-Nu for architecture-discuss@ietf.org; Wed, 07 Dec 2005 20:26:37 -0500 Received: (qmail 45419 invoked from network); 8 Dec 2005 01:04:01 -0000 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out1.oct.nac.net with SMTP; 8 Dec 2005 01:04:01 -0000 Received: (qmail 24459 invoked from network); 7 Dec 2005 20:04:00 -0500 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.81) by mail1.oct.nac.net with SMTP; 7 Dec 2005 20:04:00 -0500 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id jB7MgoY03775; Wed, 7 Dec 2005 17:42:50 -0500 Date: Wed, 7 Dec 2005 17:42:50 -0500 (EST) From: George Gross To: "Fleischman, Eric" Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches In-Reply-To: <474EEBD229DF754FB83D256004D02108BBCAD1@XCH-NW-6V1.nw.nos.boeing.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 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 Eric, On Wed, 7 Dec 2005, Fleischman, Eric wrote: > Friends, > > Several months ago I stumbled upon a middlebox implementation that I > believe is a classic example of being a "misbehaving middlebox", despite > the fact that the approach is blessed by RFC 2401 and 2401bis (i.e., > IETF standards). > > I created an array of technical arguments for this characterization, > including the fact that the approach simply doesn't operationally work > because it explicitly segments the network for which an onerous unicast > work-around exists but no multicast work-around exists. Thus, it > effectively "breaks" IP with no current remedy at all. This operational > argument didn't resonate with the RFC 2401bis editor but my > architectural arguments did somewhat. I am highly familiar with the RFC2401-bis text for multicast, as I contributed some of the text for it ;o) I am also a co-author for the MSEC IPsec extensions draft. So I'd appreciate hearing more about your middlebox problem, either on or off this list as you see fit.... BTW section 5 of the msec-ipsec-extensions draft elaborates on IPsec multicast interactions with NAT at length.... yes, it is a swamp ;o( > > Thus, in order to build up better support for that line of reasoning, in > the hopes that 2401bis may hopefully support a more viable design, I > engaged many of you through two generic queries to the IETF mail list > ("Question about the normative nature of IETF RFCs" and "Correct > middlebox behavior"). The responses I received from these queries didn't > result in consistent replies, leading me to conclude that the IETF no > longer has a group consensus about these issues. There is alot of inertia (read prior investment) in existing RFC2401 and RFC2401-bis products. The only IETF activity that I've seen having a shot at sidestepping the inherent limitations of IPsec is the HIP effort. But it appears to me that shim6 is going to eclipse HIP. > > Concerned about this possibility, I spent much of the recent Vancouver > IETF talking with long-term IETF members about whether the Internet and > the TCP/IP protocol suite currently has an architecture or not. The > consistent (or, rather, unanimous) response was that it does not. > Specifically, whereas we could assert underlying architectural > principals upon which IP and the Internet were built as recently as > eight years ago, and thereby identify "good" and "bad" approaches, the > current "Wild West" evolution since then (e.g., convergence with SS#7 > telephony and video networks; widespread middlebox deployments; an > inability to distinguish between middleboxes, host, and router > functionality; tunneling of various sorts without viable network > management mechanisms; etc.) has resulted in an ad hoc creation lacking > unifying constructs. Without such a foundation, I was told, how can we > therefore talk about "good" or "bad" or "misbehaving"? So I asked them, > if we indeed don't have any common foundation anymore, then what > confidence do we have that our current system will continue to remain > viable over time? Nobody provided me with any reassurance. Some pointed > to GENI Project or other research activities as perhaps re-establishing > a foundation to which the Internet could migrate over time. However, no > answer was believable by a long-term operational guy like me. > > I can't imagine that our community really has thrown up its hands and > embraced dissonance and brownian motion. But unless we can articulate an > architecture, I do not understand how we can evolve the Internet in a > rational fashion. We could perhaps hope that "local self interest" is > ultimately maximized when approaches that benefit the majority are > chosen. However, this is not always true and "benefits to the majority" > is not something that can really be determined without an architectural > foundation. these days, $$$ talks louder than the Internet architects ;o( I observe that unlike a decade ago, the Internet has many competing players and cabels. their interests are not altruistic and they are locally optimized. Consequently, there is no effective method (other than $$$) that I've seen yet that could ratify and deploy a unified next-gen Internet architecture at the IP layer. The only technical avenue I see is to use IP as a virtual link layer under HIP or a cousin of HIP, and combine it with a (fill-in the blank) killer app that is a catylst for rapid adoption. Eric, got a killer app handy? hth, George > > Needless to say, I ultimately lost my argument with the 2401bis editor. > However, I would hate to learn that I may someday also lose the > Internet. Can you provide me with any hope that this will not happen? > > --Eric > > > > _______________________________________________ > 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 Dec 07 21:59:18 2005 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 1EkC06-0003SJ-P8; Wed, 07 Dec 2005 21:59:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkC05-0003SE-DS for architecture-discuss@megatron.ietf.org; Wed, 07 Dec 2005 21:59:17 -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 VAA14042 for ; Wed, 7 Dec 2005 21:58:24 -0500 (EST) Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkCLt-00061e-FB for architecture-discuss@ietf.org; Wed, 07 Dec 2005 22:21:50 -0500 Received: from [172.16.0.148] (adsl-71-130-5-137.dsl.snfc21.pacbell.net[71.130.5.137]) by comcast.net (sccrmhc13) with SMTP id <20051208025855013002q14le>; Thu, 8 Dec 2005 02:58:56 +0000 In-Reply-To: <20051208003611.10EE286ADD@mercury.lcs.mit.edu> References: <20051208003611.10EE286ADD@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4D431704-FB04-4A1C-90D5-ED9C5DF176DC@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches Date: Wed, 7 Dec 2005 18:58:54 -0800 To: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 >> The usual situation is that we have conflicting technologies to >> achieve some goal and we choose to "let a thousand flowers bloom" or >> "let the market decide". > > Tony, this does not necessarily lead to architectural decay, any > more than > having two different editors or C compilers for an operating system > harms > the architecture of that operating system. A fine and fair point. If indecision is restricted to upper layers, then there is certainly no issue. I just don't think that we exercised that amount of careful discretion. Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Dec 07 22:08:16 2005 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 1EkC8m-0005rc-Rr; Wed, 07 Dec 2005 22:08:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkC8l-0005rU-3g for architecture-discuss@megatron.ietf.org; Wed, 07 Dec 2005 22:08:15 -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 WAA14775 for ; Wed, 7 Dec 2005 22:07:22 -0500 (EST) Received: from sokol.elan.net ([216.151.192.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkCUY-0006IH-OM for architecture-discuss@ietf.org; Wed, 07 Dec 2005 22:30:48 -0500 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id jB838Bk8017690; Wed, 7 Dec 2005 19:08:11 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id jB838A0w017687; Wed, 7 Dec 2005 19:08:11 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Wed, 7 Dec 2005 19:08:10 -0800 (PST) From: "william(at)elan.net" To: Noel Chiappa Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches In-Reply-To: <20051208003611.10EE286ADD@mercury.lcs.mit.edu> Message-ID: References: <20051208003611.10EE286ADD@mercury.lcs.mit.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 Wed, 7 Dec 2005, Noel Chiappa wrote: > > From: Tony Li > > > The usual situation is that we have conflicting technologies to > > achieve some goal and we choose to "let a thousand flowers bloom" or > > "let the market decide". > > Tony, this does not necessarily lead to architectural decay, any more than > having two different editors or C compilers for an operating system harms > the architecture of that operating system. I don't agree that its valid comparison. The reason why having two C compilers works is because there is a standard C language. Two editors is is more of a correct comparison if we're talking about editors that save their data and produce output in different formats, i.e. editors provide comparable functionality to "edit" a text, but are not inter-operatable otherwise (and personally I DO NOT like this situation at all, while I'm ok with different editors I'm advocate for common format i.e. OpenDoc). -- William Leibzon Elan Networks william@elan.net _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Dec 07 22:54:28 2005 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 1EkCrU-0007Se-28; Wed, 07 Dec 2005 22:54:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkCrS-0007SX-2y for architecture-discuss@megatron.ietf.org; Wed, 07 Dec 2005 22:54:26 -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 WAA18441 for ; Wed, 7 Dec 2005 22:53:33 -0500 (EST) Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkDDG-0007af-Jh for architecture-discuss@ietf.org; Wed, 07 Dec 2005 23:16:59 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 402B186AED; Wed, 7 Dec 2005 22:54:14 -0500 (EST) To: architecture-discuss@ietf.org Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches Message-Id: <20051208035414.402B186AED@mercury.lcs.mit.edu> Date: Wed, 7 Dec 2005 22:54:14 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org > From: Joe Touch > Like when IEEE approved two competing - and interfering - > technologies for 802.11? > What results is fun if you like market competition, and horrible > if you like interoperability (the cornerstone of the _Inter_net). Having two different non-interoperable choices for one component can be a problem, but it's not an *architectural* problem. (And it's only a problem when its a thing where you want to have wide-scale intercommunication. For things like IGP's, it doesn't seem to have been a problem to have several.) Architecture is the fundamental framework one operates in, so it includes things like what namespaces you have, and what their properties are; it also includes how the overall system is divided up into sub-systems (i.e. where the module boundaries are), and what their interactions are (i.e. what the interfaces look like). The kind of architectural problems the Internet has been seeing happen when we want to expand what the overall system will do (either in functionality, or whatever), and the basic framework won't do that thing easily, and instead of rethinking the entire framework at some suitable point, we make some small tweak just to do one specific thing - or, worse yet, break some systemic assumption, and do a kludge. The problem has been that that architectural reworking is painful, and expensive in the short run, and the local-tweaks/kludges approaches *look* less expensive - because they are, *in the short run*. All of which is a completely different kettle of fish from the problems caused by two choices for the protocol to do X. > All that means is we'll all have to wait _until_ the market decides, > which delays everybody just so a few capitalists can have fun. ;-) It turns out to be economically advantageous to company X to lock customers into proprietary solution P, as opposed to using generic, open solution G (might be a protocol, might be an OS, might be a kind of CPU). The customers eventually wake up and decide that G is better for them. So there's always this tension, and how long it takes to go away depends in part on the overall costs of having {P0 ... PN} instead of G. For end-end communication protocols, having {P0 ... PN} limits the pool of people you can communicate with, so there's a big incentive to migrate to G. For access protocols/technologies (your 802.11 example, IGP's), the cost is less (and there are sometimes benefits, too), so multiple choices will persist. Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Dec 08 11:55:00 2005 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 1EkP2q-0004OU-7Z; Thu, 08 Dec 2005 11:55:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkP2o-0004Nb-6L for architecture-discuss@megatron.ietf.org; Thu, 08 Dec 2005 11:54:58 -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 LAA09599 for ; Thu, 8 Dec 2005 11:54:04 -0500 (EST) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkP2m-0007vc-HO for architecture-discuss@ietf.org; Thu, 08 Dec 2005 11:54:59 -0500 Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id KAA16239; Thu, 8 Dec 2005 10:54:34 -0600 (CST) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id jB8GsYx28789; Thu, 8 Dec 2005 08:54:34 -0800 (PST) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Dec 2005 08:54:22 -0800 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, 8 Dec 2005 08:54:22 -0800 Message-ID: <474EEBD229DF754FB83D256004D02108BBCAD7@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: [arch-d] Valid and Invalid Internet architectures and approaches thread-index: AcX7q0nkp+ze7/aYSuWEhmDsyHjekgAaZecQ From: "Fleischman, Eric" To: "Noel Chiappa" , X-OriginalArrivalTime: 08 Dec 2005 16:54:22.0633 (UTC) FILETIME=[09F40990:01C5FC18] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu]=20 >The kind of architectural problems the Internet has been=20 >seeing happen when we want to expand what the overall=20 >system will do (either in functionality, or whatever),=20 >and the basic framework won't do that thing easily,=20 >and instead of rethinking the entire framework at some=20 >suitable point, we make some small tweak just to do one=20 >specific thing - or, worse yet, break some systemic=20 >assumption, and do a kludge. Noel's paragraph summarizes my view before I began my recent queries. What got me started on this vector was the discovery that when I identified a feature in RFC 2401 and 2401bis that demonstrably causes irreparable harm to IP and the Internet with no beneficial side affects (that I could discern, at least) did not result in the correction of that bug but rather in the continuance of the damaging approach because it was being increasingly deployed.=20 Noel's writing assumes that we commonly have shared philosophical perspectives/beliefs and a common goal of nuturing the Internet. My many conversations with long-term IETF attendees at the Vancouver IETF indicated that many of our number no longer believe this to be the case. Many identified the substantial attendence of telephony people (yeah, I used to be one too -- back in the 80s) with their conflicting technical viewpoints as being the turning point for us. I believe, by contrast, that our turning point occurred when we failed to act upon Steve Deering's warnings by permitting the IP layer of the hourglass to grow fat.=20 Regardless, where do we go from here? _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Dec 08 12:24:59 2005 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 1EkPVr-0006gv-Nb; Thu, 08 Dec 2005 12:24:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkPVq-0006gh-Ox for architecture-discuss@megatron.ietf.org; Thu, 08 Dec 2005 12:24:58 -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 MAA13579 for ; Thu, 8 Dec 2005 12:24:05 -0500 (EST) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkPVr-0000rO-Bo for architecture-discuss@ietf.org; Thu, 08 Dec 2005 12:25:00 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id jB8HOk075614; Thu, 8 Dec 2005 09:24:46 -0800 (PST) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id jB8HOf598367; Thu, 8 Dec 2005 09:24:41 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200512081724.jB8HOf598367@merlot.juniper.net> To: "Fleischman, Eric" Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches In-Reply-To: Your message of "Thu, 08 Dec 2005 08:54:22 PST." <474EEBD229DF754FB83D256004D02108BBCAD7@XCH-NW-6V1.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11716.1134062681.1@juniper.net> Date: Thu, 08 Dec 2005 09:24:41 -0800 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org Eric, > From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu] > >The kind of architectural problems the Internet has been > >seeing happen when we want to expand what the overall > >system will do (either in functionality, or whatever), > >and the basic framework won't do that thing easily, > >and instead of rethinking the entire framework at some > >suitable point, we make some small tweak just to do one > >specific thing - or, worse yet, break some systemic > >assumption, and do a kludge. > > Noel's paragraph summarizes my view before I began my recent queries. > What got me started on this vector was the discovery that when I > identified a feature in RFC 2401 and 2401bis that demonstrably causes > irreparable harm to IP and the Internet with no beneficial side affects > (that I could discern, at least) did not result in the correction of > that bug but rather in the continuance of the damaging approach because > it was being increasingly deployed. > > Noel's writing assumes that we commonly have shared philosophical > perspectives/beliefs and a common goal of nuturing the Internet. My many > conversations with long-term IETF attendees at the Vancouver IETF > indicated that many of our number no longer believe this to be the case. > Many identified the substantial attendence of telephony people (yeah, I > used to be one too -- back in the 80s) with their conflicting technical > viewpoints as being the turning point for us. I believe, by contrast, > that our turning point occurred when we failed to act upon Steve > Deering's warnings by permitting the IP layer of the hourglass to grow > fat. > > Regardless, where do we go from here? To quote from Don Quixote the proof of the pudding is in the eating, to which I add that the proof of the pudding is *not* in the debates about the pudding. With this in mind I suggest we go to where the market demands. Yes, one could argue that market demands could yield less than optimal outcomes. But have we seen any other mechanism that consistenly produces more optimal outcomes ? And after all, what is "optimal" in the first place ? Yakov. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Dec 08 12:49:05 2005 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 1EkPtB-0000Eo-Dp; Thu, 08 Dec 2005 12:49:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkPt9-0000Ei-Sa for architecture-discuss@megatron.ietf.org; Thu, 08 Dec 2005 12:49:04 -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 MAA16605 for ; Thu, 8 Dec 2005 12:48:10 -0500 (EST) Received: from sccrmhc13.comcast.net ([63.240.77.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkPt8-0001tk-Pv for architecture-discuss@ietf.org; Thu, 08 Dec 2005 12:49:05 -0500 Received: from [172.16.0.148] (adsl-71-130-5-137.dsl.snfc21.pacbell.net[71.130.5.137]) by comcast.net (sccrmhc13) with SMTP id <20051208174845013002q5bpe>; Thu, 8 Dec 2005 17:48:46 +0000 In-Reply-To: <200512081724.jB8HOf598367@merlot.juniper.net> References: <200512081724.jB8HOf598367@merlot.juniper.net> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <605C9835-36A3-4219-8170-56D50DF20EFC@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches Date: Thu, 8 Dec 2005 09:48:41 -0800 To: Yakov Rekhter X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: "Fleischman, Eric" , 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: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org > With this in mind I suggest we go to where the market demands. Yes, > one could argue that market demands could yield less than optimal > outcomes. But have we seen any other mechanism that consistenly > produces more optimal outcomes ? And after all, what is "optimal" > in the first place ? Yakov, I know full well your feeling about a market driven approach as opposed to centralized planning and for the most part, I share them. However, there are certain things that a market is not likely to do. I'd submit that exercising discretion, wisdom, and restraint are not likely outcomes. Instead, a market is more likely to exploit the infrastructure and the process in whatever way is possible, regardless of the side-effects. A market is wholly unlikely to provide a focused effort in a particular new area, as we have seen from the creation of the Internet itself. In fact, as you well know, markets are going to only devote their research dollars to those topics that can be monetized in the relatively short term. Markets never act for the common good. We have seen from the economic side of the world that wholly open and unregulated market dynamics can lead to some unattractive results, such as the trusts. As you well know, what happened there was that external regulation intervened to limit the behavior of the market. What I'm suggesting then, is that for the Internet architecture to continue to survive and not decay into utter entropy, there needs to be some level of technological oversight that both provides leadership to drive us in the right direction and ensure that we avoid pitfalls. Yes, there is a considerable amount of care needed to create the right level of oversight, without over controlling. 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 Dec 08 13:02:01 2005 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 1EkQ5h-0003NU-GG; Thu, 08 Dec 2005 13:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkQ5d-0003Ku-5S for architecture-discuss@megatron.ietf.org; Thu, 08 Dec 2005 13:02:00 -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 NAA18370 for ; Thu, 8 Dec 2005 13:00:52 -0500 (EST) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkQ5P-0002PU-76 for architecture-discuss@ietf.org; Thu, 08 Dec 2005 13:01:47 -0500 Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id KAA00093; Thu, 8 Dec 2005 10:01:23 -0800 (PST) Received: from XCH-NWBH-10.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id jB8I1MC13938; Thu, 8 Dec 2005 12:01:22 -0600 (CST) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-10.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Dec 2005 10:01:22 -0800 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, 8 Dec 2005 10:01:21 -0800 Message-ID: <474EEBD229DF754FB83D256004D02108BBCAD8@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: [arch-d] Valid and Invalid Internet architectures and approaches thread-index: AcX8HOsQ8f9jMLBjSwqhbz2w3WKD5wAAR+HA From: "Fleischman, Eric" To: "Yakov Rekhter" X-OriginalArrivalTime: 08 Dec 2005 18:01:22.0015 (UTC) FILETIME=[65B10EF0:01C5FC21] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable 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: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org From: Yakov Rekhter [mailto:yakov@juniper.net]=20 >With this in mind I suggest we go to where the market=20 >demands. Yes, one could argue that market demands could=20 >yield less than optimal outcomes. But have we seen any=20 >other mechanism that consistenly produces more optimal=20 >outcomes? And after all, what is "optimal" in the first=20 >place? Excellent points, Yakov. However, how far should we take this argument? Would you say, for example, that we should remove all design constraints that were historically placed upon defining interoperable IP product offerings? Is the IETF primarily a marketing arm within the "market demands"-based world?=20 Or perhaps the truth you have just articulated needs to be counter-balanced by another truth that the market relies upon technically sound products and the role of our community is to foster that soundness? Aren't sound products ultimately a function of good design and good design based upon a viable architectural foundation? _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Dec 08 13:07:35 2005 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 1EkQB5-0004da-GP; Thu, 08 Dec 2005 13:07:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkQB3-0004c7-VQ for architecture-discuss@megatron.ietf.org; Thu, 08 Dec 2005 13:07:34 -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 NAA18978 for ; Thu, 8 Dec 2005 13:06:32 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkQAw-0002cH-So for architecture-discuss@ietf.org; Thu, 08 Dec 2005 13:07:28 -0500 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB8GxFr03247; Thu, 8 Dec 2005 08:59:15 -0800 (PST) Message-ID: <4398660D.4060409@isi.edu> Date: Thu, 08 Dec 2005 08:57:49 -0800 From: Joe Touch User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Noel Chiappa Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches References: <20051208035414.402B186AED@mercury.lcs.mit.edu> In-Reply-To: <20051208035414.402B186AED@mercury.lcs.mit.edu> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Noel Chiappa wrote: > > From: Joe Touch > > > Like when IEEE approved two competing - and interfering - > > technologies for 802.11? > > What results is fun if you like market competition, and horrible > > if you like interoperability (the cornerstone of the _Inter_net). > > Having two different non-interoperable choices for one component can be > a problem, but it's not an *architectural* problem. Not *necessarily* an architectural problem. However, we've allowed a number of choices which are non-interoperable with the (at the time) existing architecture - such as NATs. Whenever we have such choices, we do need to understand whether they alter the existing architecture. The problem isn't that such cases aren't made - some of us made them at the time, and continue to do so. The problem is that immediacy and commercial ubiquity is substituted for architectural considerations. I wish RFCs had manditory Architectural Considerations sections; sadly, they have manditory 'just-about-everything-else' sections instead. > > All that means is we'll all have to wait _until_ the market decides, > > which delays everybody just so a few capitalists can have fun. ;-) > > It turns out to be economically advantageous to company X to lock > customers into proprietary solution P, as opposed to using generic, > open solution G (might be a protocol, might be an OS, might be a kind > of CPU). The customers eventually wake up and decide that G is better > for them. So there's always this tension, and how long it takes to go > away depends in part on the overall costs of having {P0 ... PN} instead > of G. Market tension with proprietary solutions are fine. When those solutions are proffered as architectural extensions - in the absence or even despite conflicting architectural analysis - then we're in trouble. Like we are now. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDmGYNE5f5cImnZrsRAv4mAKCf6qZHD1Lp6WGqTReyjjiqFBb3iwCgjZN5 7oX1cF77OnGbjNh2ee6GeFA= =9Jzx -----END PGP SIGNATURE----- _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Dec 08 13:59:27 2005 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 1EkQzH-0002yW-Nk; Thu, 08 Dec 2005 13:59:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkQzG-0002uV-TH for architecture-discuss@megatron.ietf.org; Thu, 08 Dec 2005 13:59:27 -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 NAA24669 for ; Thu, 8 Dec 2005 13:58:29 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkQzD-0004Jt-94 for architecture-discuss@ietf.org; Thu, 08 Dec 2005 13:59:24 -0500 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB8HxUr03696; Thu, 8 Dec 2005 09:59:30 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.13.4/8.13.4/Submit) id jB8HxUIa006041; Thu, 8 Dec 2005 09:59:30 -0800 (PST) (envelope-from faber) Date: Thu, 8 Dec 2005 09:59:30 -0800 From: Ted Faber To: Noel Chiappa Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches Message-ID: <20051208175930.GC36688@hut.isi.edu> References: <20051208035414.402B186AED@mercury.lcs.mit.edu> Mime-Version: 1.0 In-Reply-To: <20051208035414.402B186AED@mercury.lcs.mit.edu> User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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="===============1301793322==" Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org --===============1301793322== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vEao7xgI/oilGqZ+" Content-Disposition: inline --vEao7xgI/oilGqZ+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 07, 2005 at 10:54:14PM -0500, Noel Chiappa wrote: > > From: Joe Touch >=20 > > Like when IEEE approved two competing - and interfering - > > technologies for 802.11? > > What results is fun if you like market competition, and horrible > > if you like interoperability (the cornerstone of the _Inter_net). >=20 > Having two different non-interoperable choices for one component can be > a problem, but it's not an *architectural* problem. (And it's only a > problem when its a thing where you want to have wide-scale > intercommunication. For things like IGP's, it doesn't seem to have been > a problem to have several.) >=20 > Architecture is the fundamental framework one operates in, so it > includes things like what namespaces you have, and what their > properties are; it also includes how the overall system is divided up > into sub-systems (i.e. where the module boundaries are), and what their > interactions are (i.e. what the interfaces look like). [more stuff I agree with snipped.] One of the things an architecture does define is those sets of things that elements of the system do have to agree on. You allude to interfaces, but one could easily talk about network packet formats (or the equivalent). It's difficult to imagine a system that is architected but where all components are open to multiple non-interoperable choices. IMHO, an architecture needs to keep that set of things small - so that one can keep track of them - and architects need to defend that small set. But I doubt we disagree on this. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --vEao7xgI/oilGqZ+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDmHSCaUz3f+Zf+XsRAu6MAKDwpha4eQsNgagPZb0j2L3nKKIQzwCglePM pWKQdCcUlzGfZn/0iqsUpVc= =RjVz -----END PGP SIGNATURE----- --vEao7xgI/oilGqZ+-- --===============1301793322== 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 --===============1301793322==-- From architecture-discuss-bounces@ietf.org Thu Dec 08 15:07:35 2005 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 1EkS3D-0003RW-Ku; Thu, 08 Dec 2005 15:07:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkS3B-0003Qf-71 for architecture-discuss@megatron.ietf.org; Thu, 08 Dec 2005 15:07:34 -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 PAA04962 for ; Thu, 8 Dec 2005 15:06:30 -0500 (EST) Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkS32-0007eB-TA for architecture-discuss@ietf.org; Thu, 08 Dec 2005 15:07:26 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 7B556872D8; Thu, 8 Dec 2005 15:07:10 -0500 (EST) To: architecture-discuss@ietf.org Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches Message-Id: <20051208200710.7B556872D8@mercury.lcs.mit.edu> Date: Thu, 8 Dec 2005 15:07:10 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org > From: Ted Faber > One of the things an architecture does define is those sets of things > that elements of the system do have to agree on. You allude to > interfaces, but one could easily talk about network packet formats (or > the equivalent). Minor rant (not really related to your basic point): packet formats are about as significant to *achitecture* as the order of arguments in a system call interface is to an OS's architecture - i.e. not very. When I spoke of interfaces, I was speaking in a very generic sense (e.g. one in which the interface to the internet layer is defined in only slightly more detail than "provides unreliable datagram service throughout the entire internetwork"). Tangentially related point (which I will use immediately below): there are two kinds of diagram one can draw of a distributed system. In the first, one draws separate boxes for computers A and B, and smaller boxes within each of them for the local instance of subsystem X (e.g. the internet layer). This is a level of detail which I claim is wholly inappropriate for (most) thinking about architectural issues. The other kind of diagram is the one where HTTP is a box above TCP which is a box above IP - and that's the kind that is useful in architectural thinking. > It's difficult to imagine a system that is architected but where all > components are open to multiple non-interoperable choices. All, no. But first you need to qualify two different kinds of "non-interoperable", and that refers back to the point I made above: in a distributed system, subsystem X is divided (necessarily) into lots of components, one in each computer which is "part of" X. In one kind of "non-interoperable", you have two different designs of subsystem X (call them Xa and Xb), and all the Xa sub-boxes (Xa0 .. XaN) can only talk to other Xa sub-boxes. However, entities which want to use X can use either Xa or Xb, and Xa and Xb are "interoperable" - i.e. clients can seamlessly use either. (For example, a lot of protocols that use crypto stuff treat algorithms this way.) In the other (worse) kind of "non-interoperable", the semantics of Xa and Xb are sufficiently different that clients can't easily switch from one to the other. Having made that point, to return to your point, the more open the architecture is to allowing different designs for the X functionality, the better off you are. Yes, a more difficult trick to pull off, but wise. (Some systems, e.g. Nimrod, explicitly had an architecture in which there were a number of defined subsystems - in the sense of "this box does this, and this is what is needs for data, and you get back that" - whose operation was *not* part of the specification, precisely to maximize flexibility - not to mention the chance of screwing something up! :-) > IMHO, an architecture needs to keep that set of things small - so that > one can keep track of them - and architects need to defend that small > set. Precisely. One of the goals of Nimrod was: "Minimize the size of the 'core' system which must be implemented on a system wide basis. Such minimization maximizes the flexibility, and thus the lifetime of the architecture." _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Dec 08 15:18:43 2005 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 1EkSDy-0006W0-R2; Thu, 08 Dec 2005 15:18:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkSDx-0006GF-8F for architecture-discuss@megatron.ietf.org; Thu, 08 Dec 2005 15:18:41 -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 PAA06184 for ; Thu, 8 Dec 2005 15:17:40 -0500 (EST) Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkSDs-00083G-7o for architecture-discuss@ietf.org; Thu, 08 Dec 2005 15:18:36 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 01360872D8; Thu, 8 Dec 2005 15:18:23 -0500 (EST) To: architecture-discuss@ietf.org Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches Message-Id: <20051208201823.01360872D8@mercury.lcs.mit.edu> Date: Thu, 8 Dec 2005 15:18:23 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org [Arck. Somehow that got truncated. Here's the last section, complete...] > IMHO, an architecture needs to keep that set of things small - so that > one can keep track of them - and architects need to defend that small > set. Precisely. One of the goals of Nimrod was: "Minimize the size of the 'core' system which must be implemented on a system wide basis. Such minimization maximizes the flexibility, and thus the lifetime of the architecture." which says basically the same thing, albeit in a different way. (Hmm, really ought to put that "architectural goals of Nimrod" material online...) > But I doubt we disagree on this. Exactement. Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Dec 08 15:22:16 2005 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 1EkSHQ-0007ZH-5I; Thu, 08 Dec 2005 15:22:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkSHO-0007YC-6c for architecture-discuss@megatron.ietf.org; Thu, 08 Dec 2005 15:22:14 -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 PAA06627 for ; Thu, 8 Dec 2005 15:21:13 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkSHI-0008Dg-0N for architecture-discuss@ietf.org; Thu, 08 Dec 2005 15:22:09 -0500 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB8J1Ur01266; Thu, 8 Dec 2005 11:01:30 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.13.4/8.13.4/Submit) id jB8J1Hd6070972; Thu, 8 Dec 2005 11:01:17 -0800 (PST) (envelope-from faber) Date: Thu, 8 Dec 2005 11:01:17 -0800 From: Ted Faber To: "Fleischman, Eric" Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches Message-ID: <20051208190117.GA70110@hut.isi.edu> References: <474EEBD229DF754FB83D256004D02108BBCAD7@XCH-NW-6V1.nw.nos.boeing.com> Mime-Version: 1.0 In-Reply-To: <474EEBD229DF754FB83D256004D02108BBCAD7@XCH-NW-6V1.nw.nos.boeing.com> User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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: , Content-Type: multipart/mixed; boundary="===============0056409282==" Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org --===============0056409282== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nFreZHaLTZJo0R7j" Content-Disposition: inline --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 08, 2005 at 08:54:22AM -0800, Fleischman, Eric wrote: > Noel's paragraph summarizes my view before I began my recent queries. > What got me started on this vector was the discovery that when I > identified a feature in RFC 2401 and 2401bis that demonstrably causes > irreparable harm to IP and the Internet with no beneficial side affects [...] Any chance of a pointer to the problem, or will I not be sleeping tonight? --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --nFreZHaLTZJo0R7j Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDmIL9aUz3f+Zf+XsRAtR7AJ9WKR0JAcbj4L/aClD/Zfe+DR4/QgCgyvLm yVe9VMJFH+kambSsgNo41lU= =TV/h -----END PGP SIGNATURE----- --nFreZHaLTZJo0R7j-- --===============0056409282== 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 --===============0056409282==-- From architecture-discuss-bounces@ietf.org Thu Dec 08 18:04:38 2005 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 1EkUoY-0006xb-9S; Thu, 08 Dec 2005 18:04:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkUoW-0006vh-4H for architecture-discuss@megatron.ietf.org; Thu, 08 Dec 2005 18:04:36 -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 SAA03517 for ; Thu, 8 Dec 2005 18:03:35 -0500 (EST) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkUoP-0000p5-IE for architecture-discuss@ietf.org; Thu, 08 Dec 2005 18:04:33 -0500 Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id PAA26778; Thu, 8 Dec 2005 15:03:55 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id jB8N3sB02001; Thu, 8 Dec 2005 15:03:55 -0800 (PST) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Dec 2005 15:03:50 -0800 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, 8 Dec 2005 15:03:50 -0800 Message-ID: <474EEBD229DF754FB83D256004D02108BBCAE3@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: [arch-d] Valid and Invalid Internet architectures and approaches thread-index: AcX8NUufVEHn2+RfRIC4LLWPlESkMgAFLouA From: "Fleischman, Eric" To: "Ted Faber" X-OriginalArrivalTime: 08 Dec 2005 23:03:50.0917 (UTC) FILETIME=[A747BB50:01C5FC4B] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable 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: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org The Bump in the Wire (BITW) security gateway approach for IPsec in tunnel mode. In RFC 2401, it was described loosely enough that the implementation need not segment the network. However, in 2401bis they "cleaned up" the language such that a BITW middlebox was specified to decrement the encapsulated (Red) TTL value as though it were a router. By so doing, it segments the network. Cisco has devised a product (Cisco Dynamic Multipoint VPN) to overcome this for unicast for Cisco-routers by establishing redundant mGRE tunnels between the otherwise segmented routers. However, there is no work around for multicast, though Beau Williamson of Cisco is reportedly working on a Cisco-proprietary solution, that may perhaps be added to their IOS someday. However, it is a really trivial fix to get BITW gateways to work properly (i.e., middleboxes should not decrement the TTL just as RFC 3234 implies) but I was unable to convince the 2401bis editor to make that change. -----Original Message----- From: Ted Faber [mailto:faber@ISI.EDU]=20 Sent: Thursday, December 08, 2005 11:01 AM To: Fleischman, Eric Cc: Noel Chiappa; architecture-discuss@ietf.org Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches On Thu, Dec 08, 2005 at 08:54:22AM -0800, Fleischman, Eric wrote: > Noel's paragraph summarizes my view before I began my recent queries.=20 > What got me started on this vector was the discovery that when I=20 > identified a feature in RFC 2401 and 2401bis that demonstrably causes=20 > irreparable harm to IP and the Internet with no beneficial side=20 > affects [...] Any chance of a pointer to the problem, or will I not be sleeping tonight? --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Dec 08 18:50:37 2005 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 1EkVX3-0007bY-6S; Thu, 08 Dec 2005 18:50:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkVWz-0007b9-IL for architecture-discuss@megatron.ietf.org; Thu, 08 Dec 2005 18:50: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 SAA07928 for ; Thu, 8 Dec 2005 18:49:31 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkVWw-0002Kx-Cw for architecture-discuss@ietf.org; Thu, 08 Dec 2005 18:50:30 -0500 Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jB8Mm8r13573; Thu, 8 Dec 2005 14:48:08 -0800 (PST) Received: (from faber@localhost) by hut.isi.edu (8.13.4/8.13.4/Submit) id jB8Mm8PX070283; Thu, 8 Dec 2005 14:48:08 -0800 (PST) (envelope-from faber) Date: Thu, 8 Dec 2005 14:48:08 -0800 From: Ted Faber To: Noel Chiappa Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches Message-ID: <20051208224808.GF22920@hut.isi.edu> References: <20051208200710.7B556872D8@mercury.lcs.mit.edu> Mime-Version: 1.0 In-Reply-To: <20051208200710.7B556872D8@mercury.lcs.mit.edu> User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: faber@hut.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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="===============1164618608==" Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org --===============1164618608== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+ts6NCQ4mrNQIV8p" Content-Disposition: inline --+ts6NCQ4mrNQIV8p Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 08, 2005 at 03:07:10PM -0500, Noel Chiappa wrote: > > From: Ted Faber >=20 > > One of the things an architecture does define is those sets of thin= gs > > that elements of the system do have to agree on. You allude to > > interfaces, but one could easily talk about network packet formats = (or > > the equivalent). >=20 > Minor rant (not really related to your basic point): packet formats are a= bout > as significant to *achitecture* as the order of arguments in a system call > interface is to an OS's architecture - i.e. not very. When I spoke of > interfaces, I was speaking in a very generic sense (e.g. one in which the > interface to the internet layer is defined in only slightly more detail t= han > "provides unreliable datagram service throughout the entire internetwork"= ). It *is* a tangent, and most of the time I even agree with it, but there are some features of packet header layout and design that are architectural issues. And I think that goes for syscall design, too. The primary example I'm thinking of is in extensibility of those headers/interfaces. The extension headers in IPv6 are an indication that the network protocol may have to be expanded and provides a mechanism. Many OSes have syscalls that have similar flexible mechanisms for passing variable numbers and types of paraneters to teh system, knowing that the syscall interface to a given feature today may not be the interface to that service in the future. The headers can also be a reflection of the system designers' view of the world and more importantly of the view that the system will hold. The world has at most 2^32 things I want to talk to, for example. :-) But, that's really a small tangent. In general, whether the checksum's a CRC or IP checksum, or whether bytes are one order or the other are details, not architectural issues. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --+ts6NCQ4mrNQIV8p Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDmLgoaUz3f+Zf+XsRAiXwAJ98QFJX2t4xsEvuIKx2NJiEJGMTeACeI/Pl E+4jJiEvFRchfJGD+khi+ps= =HMPN -----END PGP SIGNATURE----- --+ts6NCQ4mrNQIV8p-- --===============1164618608== 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 --===============1164618608==-- From architecture-discuss-bounces@ietf.org Mon Dec 12 18:33:19 2005 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 1ElxAV-0007Ul-Jz; Mon, 12 Dec 2005 18:33:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElxAU-0007UI-4x for architecture-discuss@megatron.ietf.org; Mon, 12 Dec 2005 18:33:18 -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 SAA13748 for ; Mon, 12 Dec 2005 18:32:20 -0500 (EST) Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ElxBM-00031B-9w for architecture-discuss@ietf.org; Mon, 12 Dec 2005 18:34:13 -0500 Received: from [10.0.1.4] (pool-71-106-231-31.lsanca.dsl-w.verizon.net [71.106.231.31]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jBCNWiW05431; Mon, 12 Dec 2005 15:32:44 -0800 (PST) Date: Mon, 12 Dec 2005 15:32:43 -0800 From: Aaron Falk To: Noel Chiappa , architecture-discuss@ietf.org Subject: Re: [arch-d] Valid and Invalid Internet architectures and approaches Message-ID: In-Reply-To: <20051208035414.402B186AED@mercury.lcs.mit.edu> References: <20051208035414.402B186AED@mercury.lcs.mit.edu> X-Mailer: Mulberry/4.0.4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: falk@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit 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 --On December 7, 2005 10:54:14 PM -0500 Noel Chiappa wrote: > > Having two different non-interoperable choices for one component can be > a problem, but it's not an *architectural* problem. (And it's only a > problem when its a thing where you want to have wide-scale > intercommunication. For things like IGP's, it doesn't seem to have been > a problem to have several.) Diversity is a bigger problem when it comes in a "spanning layer", like IP (see section 2.2.1 of [1]) since these layers are intended to enable interoperation. For other layers, the cost of 'let a 1000 flowers bloom' is less. --aaron [1] NewArch Final Report _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss