From architecture-discuss-bounces@ietf.org Wed Nov 02 00:01:55 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 1EXAl1-0006WQ-1T; Wed, 02 Nov 2005 00:01:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXAkx-0006Vi-IR for architecture-discuss@megatron.ietf.org; Wed, 02 Nov 2005 00:01: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 AAA10474 for ; Wed, 2 Nov 2005 00:01:30 -0500 (EST) Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXAzU-0005Pr-8z for architecture-discuss@ietf.org; Wed, 02 Nov 2005 00:16:52 -0500 Received: from [172.20.101.216] ([::ffff:128.107.248.220]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Wed, 02 Nov 2005 00:01:35 -0500 id 01588024.4368482F.0000224D Message-ID: <4368482B.2020808@thinkingcat.com> Date: Wed, 02 Nov 2005 00:01:31 -0500 From: Leslie Daigle User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tony Li Subject: Re: [Architecture-discuss] Re: Sources of architectural change References: <20051027122404.F31AA86AEE@mercury.lcs.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Cc: architecture-discuss@ietf.org, 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: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org Jumping in mid-thread: Tony Li wrote: > The creation of this mailing list is certainly one possible step. It > can be viewed as being open to actually discussing change. > Alternately, it can be viewed as simply a rat hole to absorb dissent. > It's not clear which it is, and only the actions of the IAB over time > will tell. I certainly hope the mailing list will be constructive in discussion (possibilities of) change. But I think that has a lot more to do with its charter and the participation on it than, necessarily, the IAB's actions. There are IAB members on this list, to participate. But, [Harald wrote:] > But those who expect *fundamental* change to be *started* within *any* > established organization understand neither organizations nor human nature. Consistent with Harald's point, I'll say that the IAB is not going to hand down stone tablets -- and not just because of Kobe (an incident some of us are too new to the IETF to have witnessed firsthand). The IAB is (here and in all its efforts, IMO) trying to gather data from the community and reflect it back, to help us all make more architecturally sound choices. That is *not* a question of "architecture by popular vote"; rather it is a process of synthesis and argumentation as part of the community. Can that provide enough guidance and backstop against flagrant local optimization in design choices? Don't know -- but it's the best we've got so far. Leslie. > > We all have one common and overriding goal: the continued and ongoing > growth of the Internet. Growth requires change and, as you note, > organizations tend to resist change. Thus, if the IETF is not careful, > it is well positioned to inhibit the growth of the Internet and thus > become self-defeating. As stewards of the IETF, we must continue be > watchful of this trap and encourage innovation, even when it opposes > the status quo and political forces within the organization. That is > our responsibility to one another and to each and every Internet user, > past, present and future. > > Respectfully yours, > Tony > > > _______________________________________________ > 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 Nov 02 00:17: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 1EXB0J-00079q-BW; Wed, 02 Nov 2005 00:17:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXB0H-00078U-Qq for architecture-discuss@megatron.ietf.org; Wed, 02 Nov 2005 00:17: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 AAA11167 for ; Wed, 2 Nov 2005 00:17:20 -0500 (EST) Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXBEn-0005xF-HL for architecture-discuss@ietf.org; Wed, 02 Nov 2005 00:32:42 -0500 Received: from [192.168.1.5] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc11) with SMTP id <2005110205170801100r7910e>; Wed, 2 Nov 2005 05:17:24 +0000 In-Reply-To: <4368482B.2020808@thinkingcat.com> References: <20051027122404.F31AA86AEE@mercury.lcs.mit.edu> <4368482B.2020808@thinkingcat.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <33C7305E-DCCB-4094-B8BD-1F3BDEFFBC63@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Architecture-discuss] Re: Sources of architectural change Date: Tue, 1 Nov 2005 21:17:06 -0800 To: Leslie Daigle X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: architecture-discuss@ietf.org, 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: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org > The IAB is (here and in all its efforts, IMO) trying to gather data > from the community and reflect it back, to help us all make more > architecturally sound choices. That is *not* a question of > "architecture by popular vote"; rather it is a process of synthesis > and argumentation as part of the community. Leslie, Well, let me ask the very pragmatic question then: what would it take to get draft-ietf-ipngwg-gseaddr-00 reconsidered? Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 02 01:09:40 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 1EXBoZ-0001S5-U7; Wed, 02 Nov 2005 01:09:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXBoU-0001MQ-Uo for architecture-discuss@megatron.ietf.org; Wed, 02 Nov 2005 01:09: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 BAA13507 for ; Wed, 2 Nov 2005 01:09:12 -0500 (EST) Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXC31-0008Lb-AF for architecture-discuss@ietf.org; Wed, 02 Nov 2005 01:24:35 -0500 Received: from [172.20.101.216] ([::ffff:207.47.24.2]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Wed, 02 Nov 2005 01:09:17 -0500 id 01588029.4368580D.00002F38 Message-ID: <4368580A.4040607@thinkingcat.com> Date: Wed, 02 Nov 2005 01:09:14 -0500 From: Leslie Daigle User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tony Li Subject: Re: [Architecture-discuss] Re: Sources of architectural change References: <20051027122404.F31AA86AEE@mercury.lcs.mit.edu> <4368482B.2020808@thinkingcat.com> <33C7305E-DCCB-4094-B8BD-1F3BDEFFBC63@tony.li> In-Reply-To: <33C7305E-DCCB-4094-B8BD-1F3BDEFFBC63@tony.li> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: architecture-discuss@ietf.org, 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: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org Tony, I'm not going to answer your specific question, as it's not mine to answer. But, to address the more general issue based on the bits of my message you quoted -- the IAB is trying to gather data and reflect it back in this case. So far, as someone who *wasn't* involved in the original set of design discussions, I have to say it seems like there is a fair bit of community unease about the outcome, but I couldn't begin to form my own technical conclusion on the question. Useful things that the IAB might do/help cause to happen (hey, there are plenty of bright minds in this community who don't happen to be on the IAB at this instant): . document more clearly why the general 8+8/GSE approach may appear to be interesting but is not actually a better answer to the issues that are now facing the Internet - OR - . document what has been lost in the discussion along the way (as circumstances changed?), with a view to leading the community to rethink a revisit. And a very unuseful thing, to be avoided: . simply stirring up an old discussion and undermining valid current work. Particularly those of us who weren't involved in the original discussion have to tread somewhat carefully to avoid the latter situation. Leslie. Tony Li wrote: >> The IAB is (here and in all its efforts, IMO) trying to gather data >> from the community and reflect it back, to help us all make more >> architecturally sound choices. That is *not* a question of >> "architecture by popular vote"; rather it is a process of synthesis >> and argumentation as part of the community. > > > > Leslie, > > Well, let me ask the very pragmatic question then: what would it take > to get > draft-ietf-ipngwg-gseaddr-00 reconsidered? > > Tony > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 02 01:55:50 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 1EXCXG-0000Vj-7r; Wed, 02 Nov 2005 01:55:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXCXE-0000PW-73 for architecture-discuss@megatron.ietf.org; Wed, 02 Nov 2005 01:55:48 -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 BAA15703 for ; Wed, 2 Nov 2005 01:55:23 -0500 (EST) Received: from sccrmhc14.comcast.net ([63.240.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXClh-0001ga-HU for architecture-discuss@ietf.org; Wed, 02 Nov 2005 02:10:46 -0500 Received: from [192.168.1.5] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc14) with SMTP id <2005110206550201400ekh4ue>; Wed, 2 Nov 2005 06:55:17 +0000 In-Reply-To: <4368580A.4040607@thinkingcat.com> References: <20051027122404.F31AA86AEE@mercury.lcs.mit.edu> <4368482B.2020808@thinkingcat.com> <33C7305E-DCCB-4094-B8BD-1F3BDEFFBC63@tony.li> <4368580A.4040607@thinkingcat.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Architecture-discuss] Re: Sources of architectural change Date: Tue, 1 Nov 2005 22:55:00 -0800 To: Leslie Daigle X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: architecture-discuss@ietf.org, 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: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org > I'm not going to answer your specific question, as it's > not mine to answer. Whose is it then? I confess that I'm very unclear on the process in this situation. > Useful things that the IAB might do/help cause to happen (hey, > there are plenty of bright minds in this community who don't > happen to be on the IAB at this instant): > > . document more clearly why the general 8+8/GSE > approach may appear to be interesting but is not > actually a better answer to the issues that are > now facing the Internet > > - OR - > > . document what has been lost in the discussion along > the way (as circumstances changed?), with a view > to leading the community to rethink a revisit. I would welcome the IAB's input on either of the above. My recollection was that the original proposal was met with a counter-draft that was unpublished, somewhat questionable, and was used to justify terminating all discussion of the alternatives. While I understand the caution necessary in re-opening past work, there is a significant segment of the community that felt quite railroaded when this first occurred. In the intervening time, the architecture has not evolved good alternatives to fulfill the vision of GSE, and so it looks to some like the process left useful technology on the floor for no good reason. If nothing else, the execution of the process created a silent schism in the community that remains unhealed. Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 02 05:30:39 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 1EXFt9-0004Ig-1D; Wed, 02 Nov 2005 05:30:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXFt7-0004Ho-7n for architecture-discuss@megatron.ietf.org; Wed, 02 Nov 2005 05:30: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 FAA25366 for ; Wed, 2 Nov 2005 05:30:16 -0500 (EST) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXG7g-0001rS-Jl for architecture-discuss@ietf.org; Wed, 02 Nov 2005 05:45:41 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2E4622596C3; Wed, 2 Nov 2005 11:29:44 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30912-05; Wed, 2 Nov 2005 11:29:40 +0100 (CET) Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 38F7A2596BE; Wed, 2 Nov 2005 11:29:40 +0100 (CET) Date: Wed, 02 Nov 2005 11:31:13 +0100 From: Harald Tveit Alvestrand To: Tony Li , Leslie Daigle Message-ID: <6FD12FDCBB470881DF31DCEC@svartdal.hjemme.alvestrand.no> In-Reply-To: References: <20051027122404.F31AA86AEE@mercury.lcs.mit.edu> <4368482B.2020808@thinkingcat.com> <33C7305E-DCCB-4094-B8BD-1F3BDEFFBC63@tony.li> <4368580A.4040607@thinkingcat.com> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: architecture-discuss@ietf.org, Noel Chiappa Subject: [Architecture-discuss] 8+8 history (Re: Sources of architectural change) 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 Since this is ancient history for most of us, some rehashing may be in order, at least about what the history was.... --On tirsdag, november 01, 2005 22:55:00 -0800 Tony Li wrote: > My recollection was that the original proposal was met with a > counter-draft that was unpublished, somewhat questionable, and > was used to justify terminating all discussion of the alternatives. One of my regrets is that at the time this discussion occured, I thought that I was too inexperienced in the area to contribute, so I did not do anything to contribute.... The GSE proposal was first written up in draft-odell-8+8, published October 1996 (and the only draft ever published with a plus sign in the filename, I believe) and later in draft-ietf-ipngwg-gseaddr, dated February 1997. The first isn't even available from bgp.potaroo.net; the second is. The IPNG WG seemed to achieve "rough consensus" that GSE was not a viable approach; the arguments against GSE were summarized in the draft draft-ietf-ipngwg-esd-analysis. At some later time, this draft was proposed for publication. This was in the Bad Days Before Tracker, so I'm operating strictly from memory, both with dates and conclusions... my memory says that the IESG questioned the justification for some of the claims in the draft regarding the percieved security weaknesses of GSE and sent it back to the WG; it never returned. Version -05 of that draft has a date of October 1999; version -00 had a date of March 1997, and was written as *accepting* ESD, so while the end result was probably a termination of discussion, the process did take 2.5 years to get that far. WRT what it would take to bring it back: At the current stage of IPv6, it seems to me that it would take someone working through how to allow one subnet in a classical IPv6 network to use 8+8 while the rest of the world didn't..... apparently nobody's seriously suggested that in Multi6.... I don't know if it's workable..... Harald _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 02 05:56:15 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 1EXGHv-0006RS-1n; Wed, 02 Nov 2005 05:56:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXGHt-0006RN-5N for architecture-discuss@megatron.ietf.org; Wed, 02 Nov 2005 05:56: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 FAA26934 for ; Wed, 2 Nov 2005 05:55:52 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXGWR-0003K6-RX for architecture-discuss@ietf.org; Wed, 02 Nov 2005 06:11:17 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id jA2AtdS12908; Wed, 2 Nov 2005 11:55:40 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id jA2Atdbg054869; Wed, 2 Nov 2005 11:55:39 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200511021055.jA2Atdbg054869@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Harald Tveit Alvestrand Subject: Re: [Architecture-discuss] 8+8 history (Re: Sources of architectural change) In-reply-to: Your message of Wed, 02 Nov 2005 11:31:13 +0100. <6FD12FDCBB470881DF31DCEC@svartdal.hjemme.alvestrand.no> Date: Wed, 02 Nov 2005 11:55:39 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: architecture-discuss@ietf.org, 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: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org In your previous mail you wrote: The IPNG WG seemed to achieve "rough consensus" that GSE was not a viable => this was done at the interim meeting at Palo Alto February 1997. approach; the arguments against GSE were summarized in the draft draft-ietf-ipngwg-esd-analysis. At some later time, this draft was proposed for publication. => the last time I asked why it was not published the answer was some authors were not convinced the draft was really about the Mike O'Dell's proposal (BTW this is a serious reason to drop it). Regards Francis.Dupont@enst-bretagne.fr PS: IMHO the proposal (the real one or the one described in the ESD analysis) had a serious security problem as most two-space systems before HIP... _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 02 06:49: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 1EXH71-0001Ze-QZ; Wed, 02 Nov 2005 06:49:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXH6z-0001Xq-1h for architecture-discuss@megatron.ietf.org; Wed, 02 Nov 2005 06:49:01 -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 GAA29426 for ; Wed, 2 Nov 2005 06:48:39 -0500 (EST) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXHLY-0005aH-8U for architecture-discuss@ietf.org; Wed, 02 Nov 2005 07:04:05 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 78F862596C3; Wed, 2 Nov 2005 12:48:06 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32631-10; Wed, 2 Nov 2005 12:48:03 +0100 (CET) Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0BD072596B7; Wed, 2 Nov 2005 12:48:03 +0100 (CET) Date: Wed, 02 Nov 2005 12:49:37 +0100 From: Harald Tveit Alvestrand To: Francis Dupont Subject: Re: [Architecture-discuss] 8+8 history (Re: Sources of architectural change) Message-ID: In-Reply-To: <200511021055.jA2Atdbg054869@givry.rennes.enst-bretagne.fr> References: <200511021055.jA2Atdbg054869@givry.rennes.enst-bretagne.fr> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: architecture-discuss@ietf.org, 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: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org --On onsdag, november 02, 2005 11:55:39 +0100 Francis Dupont wrote: > PS: IMHO the proposal (the real one or the one described in the ESD > analysis) had a serious security problem as most two-space systems > before HIP... you've seen my occasional rant that placing the source address in the IP packet was an architectural mistake, among other things because it led people to place trust in something inherently untrustworthy....? _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 02 08:21:39 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 1EXIRv-0008Q6-Bm; Wed, 02 Nov 2005 08:14:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXIRs-0008LD-Jx for architecture-discuss@megatron.ietf.org; Wed, 02 Nov 2005 08:14:40 -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 IAA05267 for ; Wed, 2 Nov 2005 08:14:18 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXIgT-0000fi-GQ for architecture-discuss@ietf.org; Wed, 02 Nov 2005 08:29:45 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id jA2DEFw24050; Wed, 2 Nov 2005 14:14:15 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id jA2DEEBD055667; Wed, 2 Nov 2005 14:14:15 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200511021314.jA2DEEBD055667@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Harald Tveit Alvestrand Subject: Re: [Architecture-discuss] 8+8 history (Re: Sources of architectural change) In-reply-to: Your message of Wed, 02 Nov 2005 12:49:37 +0100. Date: Wed, 02 Nov 2005 14:14:14 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: architecture-discuss@ietf.org, 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: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org In your previous mail you wrote: > PS: IMHO the proposal (the real one or the one described in the ESD > analysis) had a serious security problem as most two-space systems > before HIP... you've seen my occasional rant that placing the source address in the IP packet was an architectural mistake, among other things because it led people to place trust in something inherently untrustworthy....? => two-space systems try to solve this issue by splitting the address into a locator and an identifier. Unfortunately it makes the binding between the locator and the identifier a new point to attack. This is why some two-space proposals were rejected in the past even one can think they were better. I am afraid this is what happened with 8+8. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 02 09:23: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 1EXJW4-0006p0-7x; Wed, 02 Nov 2005 09:23:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXJW2-0006ns-PO for architecture-discuss@megatron.ietf.org; Wed, 02 Nov 2005 09:23:02 -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 JAA08773 for ; Wed, 2 Nov 2005 09:22:39 -0500 (EST) Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXJkb-0003Zy-Vz for architecture-discuss@ietf.org; Wed, 02 Nov 2005 09:38:08 -0500 Received: from [192.168.1.5] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc11) with SMTP id <2005110214223601100r9fmfe>; Wed, 2 Nov 2005 14:22:46 +0000 In-Reply-To: <6FD12FDCBB470881DF31DCEC@svartdal.hjemme.alvestrand.no> References: <20051027122404.F31AA86AEE@mercury.lcs.mit.edu> <4368482B.2020808@thinkingcat.com> <33C7305E-DCCB-4094-B8BD-1F3BDEFFBC63@tony.li> <4368580A.4040607@thinkingcat.com> <6FD12FDCBB470881DF31DCEC@svartdal.hjemme.alvestrand.no> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4F300850-1672-4CC9-96E3-84B1D9CC8282@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Date: Wed, 2 Nov 2005 06:22:13 -0800 To: Harald Tveit Alvestrand X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: architecture-discuss@ietf.org, Noel Chiappa Subject: [Architecture-discuss] Re: 8+8 history (Re: Sources of architectural change) 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 > WRT what it would take to bring it back: At the current stage of > IPv6, it seems to me that it would take someone working through how > to allow one subnet in a classical IPv6 network to use 8+8 while > the rest of the world didn't..... apparently nobody's seriously > suggested that in Multi6.... I don't know if it's workable..... Harald, What ends up going in the TCP pseudo-header? Ok, you could have an e2e option that negotiates GSE, but that's just gross beyond belief. There are also huge implications for address allocation... Sigh. The only problem with making architectural changes is that they change 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 Wed Nov 02 09:40:13 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 1EXJmf-0000Ju-CK; Wed, 02 Nov 2005 09:40:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXJmd-0000Jp-C3 for architecture-discuss@megatron.ietf.org; Wed, 02 Nov 2005 09:40:11 -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 JAA09667 for ; Wed, 2 Nov 2005 09:39:50 -0500 (EST) Received: from krusty.pcisys.net ([216.229.32.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXK1E-0004AO-3H for architecture-discuss@ietf.org; Wed, 02 Nov 2005 09:55:17 -0500 Received: from corallusannulat.ophidian.com (ca2-206-53-16-253.cos.pcisys.net [206.53.16.253]) (authenticated bits=0) by krusty.pcisys.net (8.13.3/8.13.3) with ESMTP id jA2Edqqx025611 for ; Wed, 2 Nov 2005 07:39:55 -0700 (MST) Message-Id: <4.3.1.2.20051102073045.00b75630@pop3.mailpci.net> X-Sender: ophidian-eag@pop3.mailpci.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 02 Nov 2005 07:37:05 -0700 To: architecture-discuss@ietf.org From: "Edward A. Gardner" Subject: Re: [Architecture-discuss] 8+8 history (Re: Sources of architectural change) In-Reply-To: <6FD12FDCBB470881DF31DCEC@svartdal.hjemme.alvestrand.no> References: <20051027122404.F31AA86AEE@mercury.lcs.mit.edu> <4368482B.2020808@thinkingcat.com> <33C7305E-DCCB-4094-B8BD-1F3BDEFFBC63@tony.li> <4368580A.4040607@thinkingcat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 03:31 02-11-2005, Harald Tveit Alvestrand wrote: >Since this is ancient history for most of us, some rehashing may be in >order, at least about what the history was.... Not only is it ancient history, many/most of us lurkers have no idea what draft-ietf-ipngwg-gseaddr proposed or is about and have no idea what the rest of you are talking about. And as all the tombstones say, it wasn't an archival document. If rehashing that decision is important to this discussion list, would someone please post a technical summary of that proposal or a pointer to one? If rehashing that decision isn't relevant or constructive, maybe we can proceed on to something that is? Ed Gardner _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 02 10:04:32 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 1EXKAC-0005dk-8H; Wed, 02 Nov 2005 10:04:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXKAA-0005dT-Bw for architecture-discuss@megatron.ietf.org; Wed, 02 Nov 2005 10:04:30 -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 KAA11326 for ; Wed, 2 Nov 2005 10:04:09 -0500 (EST) Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXKOj-0005RK-0E for architecture-discuss@ietf.org; Wed, 02 Nov 2005 10:19:36 -0500 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id E8A4B84018; Wed, 2 Nov 2005 16:04:16 +0100 (CET) Received: from [163.117.139.76] (unknown [163.117.139.76]) by smtp02.uc3m.es (Postfix) with ESMTP id B39D883F59; Wed, 2 Nov 2005 16:04:15 +0100 (CET) In-Reply-To: <6FD12FDCBB470881DF31DCEC@svartdal.hjemme.alvestrand.no> References: <20051027122404.F31AA86AEE@mercury.lcs.mit.edu> <4368482B.2020808@thinkingcat.com> <33C7305E-DCCB-4094-B8BD-1F3BDEFFBC63@tony.li> <4368580A.4040607@thinkingcat.com> <6FD12FDCBB470881DF31DCEC@svartdal.hjemme.alvestrand.no> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <6d7cdc4730eb9519affd78413058c261@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [Architecture-discuss] 8+8 history (Re: Sources of architectural change) Date: Wed, 2 Nov 2005 16:04:43 +0100 To: Harald Tveit Alvestrand X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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 El 02/11/2005, a las 11:31, Harald Tveit Alvestrand escribi=F3: > > WRT what it would take to bring it back: At the current stage of IPv6,=20= > it seems to me that it would take someone working through how to allow=20= > one subnet in a classical IPv6 network to use 8+8 while the rest of=20 > the world didn't..... apparently nobody's seriously suggested that in=20= > Multi6.... I don't know if it's workable..... > GSE or something in those lines was the subject of many discussions in=20= the multi6 wg. even today, there are still some discussions about allowing site=20 routers to write the prefix part of the addresses on the fly. Personally, i like the approach and the benefits that it provides, but=20= personally, i don't know how to make it work from a security p.o.v. As i see it, or you involve the hosts in the security mechanisms (i.e.=20= e2e security of the available prefixes) which would break the initial=20 idea of having the hosts unaware of the prefix set available, or you=20 build the security in the exit routers, which has at least, a lot of=20 complexity, since a state related to a given communication is injected=20= in a middlebox, which implies or single point of failure or a protocol=20= for coordination of this state between the exit routers, and this has=20 additional complexity... personally, i think that if a gse like approach was not followed in the=20= multi6/shim approach was because security issues or in other words,=20 that the result of gse when you apply all the security mechanisms that=20= are needed is not as attractive regards, marcelo > Harald > > > > > > > > > _______________________________________________ > 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 Nov 02 10:09:15 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 1EXKEl-0006UN-In; Wed, 02 Nov 2005 10:09:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXKEi-0006Tu-LH for architecture-discuss@megatron.ietf.org; Wed, 02 Nov 2005 10:09:12 -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 KAA11504 for ; Wed, 2 Nov 2005 10:08:52 -0500 (EST) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXKTJ-0005bc-MZ for architecture-discuss@ietf.org; Wed, 02 Nov 2005 10:24:18 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EXKEg-0006r3-2Z; Wed, 02 Nov 2005 07:09:10 -0800 Message-Id: <6.2.3.4.2.20051102154554.04495310@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Wed, 02 Nov 2005 16:09:03 +0100 To: Tony Li From: "JFC (Jefsey) Morfin" Subject: Re: [Architecture-discuss] Re: 8+8 history (Re: Sources of architectural change) In-Reply-To: <4F300850-1672-4CC9-96E3-84B1D9CC8282@tony.li> References: <20051027122404.F31AA86AEE@mercury.lcs.mit.edu> <4368482B.2020808@thinkingcat.com> <33C7305E-DCCB-4094-B8BD-1F3BDEFFBC63@tony.li> <4368580A.4040607@thinkingcat.com> <6FD12FDCBB470881DF31DCEC@svartdal.hjemme.alvestrand.no> <4F300850-1672-4CC9-96E3-84B1D9CC8282@tony.li> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: 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: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org Tony, I perused the GSE proposition (I discovered under http://www.free.net/Docs/IETF/draft-ietf-ipngwg-gseaddr-00.txt ). (I take this occasion to repeat my plea: that it is netiquette to give the URL of the quoted documents, including Drafts). It seems to be a way to allocate aggregated addresses (by non discussed Registries of two global spaces) in order to best take advantage from them. No objection, but it seems a 00 Draft. Would it not be more an ASO BCP and an usage architecture proposition? I do not see reasons why IPv6 addresses could not be allocated that way in the ITU /3 block (however I prefer the concatenation of routing, addressing and interfacing global spaces)? Anyway, I would qualify this of "accidental" (not essential) rather than of "architectural" since no one ever claimed that IP addresses should all follow the same model. jfc At 15:22 02/11/2005, Tony Li wrote: >>WRT what it would take to bring it back: At the current stage of >>IPv6, it seems to me that it would take someone working through how >>to allow one subnet in a classical IPv6 network to use 8+8 while >>the rest of the world didn't..... apparently nobody's seriously >>suggested that in Multi6.... I don't know if it's workable..... > > >Harald, > >What ends up going in the TCP pseudo-header? > >Ok, you could have an e2e option that negotiates GSE, but that's just >gross beyond belief. There are >also huge implications for address allocation... > >Sigh. The only problem with making architectural changes is that >they change the architecture. ;-) > >Tony > > > >_______________________________________________ >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 Nov 02 10:13: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 1EXKIw-0003lp-Vq; Wed, 02 Nov 2005 10:13:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXKIv-0003lW-Ug for architecture-discuss@megatron.ietf.org; Wed, 02 Nov 2005 10:13: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 KAA11785 for ; Wed, 2 Nov 2005 10:13:13 -0500 (EST) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXKXW-0005wY-Ul for architecture-discuss@ietf.org; Wed, 02 Nov 2005 10:28:40 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 974FB2596C7; Wed, 2 Nov 2005 16:12:39 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05263-09; Wed, 2 Nov 2005 16:12:34 +0100 (CET) Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 14AAA2596CB; Wed, 2 Nov 2005 16:12:34 +0100 (CET) Date: Wed, 02 Nov 2005 16:14:08 +0100 From: Harald Tveit Alvestrand To: Tony Li Message-ID: <04F62EE55B5A451DBE302396@svartdal.hjemme.alvestrand.no> In-Reply-To: <4F300850-1672-4CC9-96E3-84B1D9CC8282@tony.li> References: <20051027122404.F31AA86AEE@mercury.lcs.mit.edu> <4368482B.2020808@thinkingcat.com> <33C7305E-DCCB-4094-B8BD-1F3BDEFFBC63@tony.li> <4368580A.4040607@thinkingcat.com> <6FD12FDCBB470881DF31DCEC@svartdal.hjemme.alvestrand.no> <4F300850-1672-4CC9-96E3-84B1D9CC8282@tony.li> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: architecture-discuss@ietf.org, Noel Chiappa Subject: [Architecture-discuss] Re: 8+8 history (Re: Sources of architectural change) 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 onsdag, november 02, 2005 06:22:13 -0800 Tony Li wrote: >> WRT what it would take to bring it back: At the current stage of >> IPv6, it seems to me that it would take someone working through how >> to allow one subnet in a classical IPv6 network to use 8+8 while >> the rest of the world didn't..... apparently nobody's seriously >> suggested that in Multi6.... I don't know if it's workable..... > > > Harald, > > What ends up going in the TCP pseudo-header? That's the part where I think it may not be workable...otoh, this is exactly the same set of issues that Multi6 is facing (for some of its ideas). I also believe that the extent of the TCP pseudo-header was one of those things that turned out to be a mistake in retrospect, when it seems to be too late to change.... > Ok, you could have an e2e option that negotiates GSE, but that's just > gross beyond belief. There are > also huge implications for address allocation... > > Sigh. The only problem with making architectural changes is that they > change the architecture. ;-) :-) _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 02 10:23: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 1EXKSf-0000z5-KU; Wed, 02 Nov 2005 10:23:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXKSe-0000ym-0o for architecture-discuss@megatron.ietf.org; Wed, 02 Nov 2005 10:23: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 KAA12503 for ; Wed, 2 Nov 2005 10:23:15 -0500 (EST) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXKhE-0006Vb-QA for architecture-discuss@ietf.org; Wed, 02 Nov 2005 10:38:42 -0500 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id B387389872; Wed, 2 Nov 2005 17:23:20 +0200 (EET) Message-ID: <4368D96C.8020907@piuha.net> Date: Wed, 02 Nov 2005 17:21:16 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Edward A. Gardner" Subject: Re: [Architecture-discuss] 8+8 history (Re: Sources of architectural change) References: <20051027122404.F31AA86AEE@mercury.lcs.mit.edu> <4368482B.2020808@thinkingcat.com> <33C7305E-DCCB-4094-B8BD-1F3BDEFFBC63@tony.li> <4368580A.4040607@thinkingcat.com> <4.3.1.2.20051102073045.00b75630@pop3.mailpci.net> In-Reply-To: <4.3.1.2.20051102073045.00b75630@pop3.mailpci.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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 Edward A. Gardner wrote: > If rehashing that decision isn't relevant or constructive, maybe we > can proceed on to something that is? Meta-comment: we went from discussion of architectural issues (e.g. mobility and multihoming) to process questions (how can IAB do architecture) and then to ancient history (design decisions of IPv6). Lets go back to the issues... (but I have nothing against people bringing up GSE as a proposal to solve today's problems). --Jari _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 02 10:32: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 1EXKbj-0005i4-8M; Wed, 02 Nov 2005 10:32:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXKbg-0005hz-Uw for architecture-discuss@megatron.ietf.org; Wed, 02 Nov 2005 10:32:57 -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 KAA13470 for ; Wed, 2 Nov 2005 10:32:36 -0500 (EST) Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXKqI-00078h-3l for architecture-discuss@ietf.org; Wed, 02 Nov 2005 10:48:03 -0500 Received: from [192.168.1.5] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc11) with SMTP id <2005110215322401100rpc1ke>; Wed, 2 Nov 2005 15:32:37 +0000 In-Reply-To: <04F62EE55B5A451DBE302396@svartdal.hjemme.alvestrand.no> References: <20051027122404.F31AA86AEE@mercury.lcs.mit.edu> <4368482B.2020808@thinkingcat.com> <33C7305E-DCCB-4094-B8BD-1F3BDEFFBC63@tony.li> <4368580A.4040607@thinkingcat.com> <6FD12FDCBB470881DF31DCEC@svartdal.hjemme.alvestrand.no> <4F300850-1672-4CC9-96E3-84B1D9CC8282@tony.li> <04F62EE55B5A451DBE302396@svartdal.hjemme.alvestrand.no> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <71D25A96-26F0-4E25-9E9B-D2D74EBCBFA8@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Date: Wed, 2 Nov 2005 07:32:01 -0800 To: Harald Tveit Alvestrand X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: architecture-discuss@ietf.org, Noel Chiappa Subject: [Architecture-discuss] Re: 8+8 history (Re: Sources of architectural change) 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 also believe that the extent of the TCP pseudo-header was one of > those things that turned out to be a mistake in retrospect, when it > seems to be too late to change.... Seems? Or 'is'? Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 02 10:42:48 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 1EXKlD-0003XN-Vn; Wed, 02 Nov 2005 10:42:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXKlC-0003XC-6m for architecture-discuss@megatron.ietf.org; Wed, 02 Nov 2005 10:42:46 -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 KAA14063 for ; Wed, 2 Nov 2005 10:42:25 -0500 (EST) Received: from sccrmhc13.comcast.net ([63.240.77.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXKzn-0007gP-Ah for architecture-discuss@ietf.org; Wed, 02 Nov 2005 10:57:52 -0500 Received: from [192.168.1.5] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc13) with SMTP id <200511021541280130049ggge>; Wed, 2 Nov 2005 15:41:39 +0000 In-Reply-To: <6.2.3.4.2.20051102154554.04495310@mail.jefsey.com> References: <20051027122404.F31AA86AEE@mercury.lcs.mit.edu> <4368482B.2020808@thinkingcat.com> <33C7305E-DCCB-4094-B8BD-1F3BDEFFBC63@tony.li> <4368580A.4040607@thinkingcat.com> <6FD12FDCBB470881DF31DCEC@svartdal.hjemme.alvestrand.no> <4F300850-1672-4CC9-96E3-84B1D9CC8282@tony.li> <6.2.3.4.2.20051102154554.04495310@mail.jefsey.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <05C8A2EA-1B8D-45F6-AD81-EB7632CCAA18@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Architecture-discuss] Re: 8+8 history (Re: Sources of architectural change) Date: Wed, 2 Nov 2005 07:41:24 -0800 To: JFC (Jefsey) Morfin X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 > I perused the GSE proposition (I discovered under http:// > www.free.net/Docs/IETF/draft-ietf-ipngwg-gseaddr-00.txt ). (I take > this occasion to repeat my plea: that it is netiquette to give the > URL of the quoted documents, including Drafts). Whoops, thanks. > It seems to be a way to allocate aggregated addresses (by non > discussed Registries of two global spaces) in order to best take > advantage from them. No objection, but it seems a 00 Draft. Would > it not be more an ASO BCP and an usage architecture proposition? > > I do not see reasons why IPv6 addresses could not be allocated that > way in the ITU /3 block (however I prefer the concatenation of > routing, addressing and interfacing global spaces)? > > Anyway, I would qualify this of "accidental" (not essential) rather > than of "architectural" since no one ever claimed that IP addresses > should all follow the same model. There is much more to it than that. Basically, GSE was the last and best effort to create an architecture that separated the address into both a 'locator' (where is the host) and 'identifier' (the ESD in the draft). The TCP pseudo-header would only be computed across the identifier and the locator would be free to change. Security would not cover the locator and security associations would only be between ESDs. The locator/identifier architecture simplifies the architecture because it allows both mobility and multi-homing to become natural and pervasive. For mobility, the host is now free to change its locator at will. For multi-homing, the same end-host can now be reachable via multiple locators. Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 02 10:44:52 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 1EXKnE-00046n-Ah; Wed, 02 Nov 2005 10:44:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXKnC-00046O-Io for architecture-discuss@megatron.ietf.org; Wed, 02 Nov 2005 10:44:50 -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 KAA14159 for ; Wed, 2 Nov 2005 10:44:29 -0500 (EST) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXL1n-0007lh-S5 for architecture-discuss@ietf.org; Wed, 02 Nov 2005 10:59:57 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5CFC72596D1; Wed, 2 Nov 2005 16:43:56 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06476-04; Wed, 2 Nov 2005 16:43:52 +0100 (CET) Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id CA4C12596CA; Wed, 2 Nov 2005 16:43:52 +0100 (CET) Date: Wed, 02 Nov 2005 16:45:27 +0100 From: Harald Tveit Alvestrand To: Tony Li Message-ID: In-Reply-To: <71D25A96-26F0-4E25-9E9B-D2D74EBCBFA8@tony.li> References: <20051027122404.F31AA86AEE@mercury.lcs.mit.edu> <4368482B.2020808@thinkingcat.com> <33C7305E-DCCB-4094-B8BD-1F3BDEFFBC63@tony.li> <4368580A.4040607@thinkingcat.com> <6FD12FDCBB470881DF31DCEC@svartdal.hjemme.alvestrand.no> <4F300850-1672-4CC9-96E3-84B1D9CC8282@tony.li> <04F62EE55B5A451DBE302396@svartdal.hjemme.alvestrand.no> <71D25A96-26F0-4E25-9E9B-D2D74EBCBFA8@tony.li> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: architecture-discuss@ietf.org, Noel Chiappa Subject: [Architecture-discuss] Re: 8+8 history (Re: Sources of architectural change) 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 onsdag, november 02, 2005 07:32:01 -0800 Tony Li wrote: >> I also believe that the extent of the TCP pseudo-header was one of >> those things that turned out to be a mistake in retrospect, when it >> seems to be too late to change.... > > > Seems? Or 'is'? I'm fond of not making completely definite statements, but in this case, it's hard to imagine the change :-) if we REALLY want to change it, it's probably simpler to do so by changing the protocol number for TCP..... TCPng, anyone? (ducks) _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 02 10:57:13 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 1EXKzB-0004qU-R8; Wed, 02 Nov 2005 10:57:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXKzA-0004qP-L0 for architecture-discuss@megatron.ietf.org; Wed, 02 Nov 2005 10:57:12 -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 KAA14844 for ; Wed, 2 Nov 2005 10:56:48 -0500 (EST) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXLDj-0008Fc-0k for architecture-discuss@ietf.org; Wed, 02 Nov 2005 11:12:16 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7BCD92596CB; Wed, 2 Nov 2005 16:56:15 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06769-04; Wed, 2 Nov 2005 16:56:12 +0100 (CET) Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 07F0C2596CA; Wed, 2 Nov 2005 16:56:12 +0100 (CET) Date: Wed, 02 Nov 2005 16:57:47 +0100 From: Harald Tveit Alvestrand To: "Bound, Jim" , Tony Li , Noel Chiappa Message-ID: <0F97656ED87FF9F54551250E@svartdal.hjemme.alvestrand.no> In-Reply-To: <936A4045C332714F975800409DE0924001388523@tayexc14.americas.cpqcorp.net> References: <936A4045C332714F975800409DE0924001388523@tayexc14.americas.cpqc orp.net> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: architecture-discuss@ietf.org Subject: [Architecture-discuss] QoS guarantees (RE: Mobility and multi-homing) 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 torsdag, oktober 27, 2005 19:02:13 -0400 "Bound, Jim" wrote: > Can guranteed QoS be achieved end-to-end and we have so many views on > this and the current work and results from Diff and Int serve are not > good enough by themselves, what is the answer? Branching discussions is so much fun :-) my opinion, which is not worth much: Guarantee is an illusion. No matter how much you pay for "guaranteed bandwidth", I'm not going to issue guarantees against a dinosaur-killer asteroid landing on my NOC 10 years from now. The question we SHOULD be asking is whether diffserv and/or intserv gives us the tools we need to do: a) let the net-provider state to the customer what he can expect from the network (at an appropriate level of confidence) b) let the customer state to the net-provider what he wants from the network (and the level of confidence he needs) c) let the net-provider(s) keep track of what they have promised in the aggregate, and know whether or not he's able to deliver on his promises at any given time. Note that a) and b) can occur in any order, including ababababab.... that's called "negotiation".... and I'm sure that some people will claim that the answer to c) is "MPLS", whereas others will say "if the answer is MPLS, you have misunderstood the question"..... _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 02 11:12: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 1EXLDV-0003ou-AW; Wed, 02 Nov 2005 11:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXLDT-0003og-SI for architecture-discuss@megatron.ietf.org; Wed, 02 Nov 2005 11:11:59 -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 LAA15681 for ; Wed, 2 Nov 2005 11:11:38 -0500 (EST) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXLS5-0000I2-8K for architecture-discuss@ietf.org; Wed, 02 Nov 2005 11:27:06 -0500 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 8A25489863; Wed, 2 Nov 2005 18:11:49 +0200 (EET) Message-ID: <4368E4C8.3050308@piuha.net> Date: Wed, 02 Nov 2005 18:09:44 +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: [Architecture-discuss] Re: 8+8 history (Re: Sources of architectural change) References: <20051027122404.F31AA86AEE@mercury.lcs.mit.edu> <4368482B.2020808@thinkingcat.com> <33C7305E-DCCB-4094-B8BD-1F3BDEFFBC63@tony.li> <4368580A.4040607@thinkingcat.com> <6FD12FDCBB470881DF31DCEC@svartdal.hjemme.alvestrand.no> <4F300850-1672-4CC9-96E3-84B1D9CC8282@tony.li> <6.2.3.4.2.20051102154554.04495310@mail.jefsey.com> <05C8A2EA-1B8D-45F6-AD81-EB7632CCAA18@tony.li> In-Reply-To: <05C8A2EA-1B8D-45F6-AD81-EB7632CCAA18@tony.li> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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 Tony Li wrote: > There is much more to it than that. Basically, GSE was the last and > best effort to create an architecture that separated > the address into both a 'locator' (where is the host) and > 'identifier' (the ESD in the draft). I think some modern architectures such as HIP appear to do a more thorough job and consider the whole problem. (Or at least a larger problem, I think HIP NAT support needs improvement.) > Security would not cover the locator and security associations would > only be between ESDs. There's a lot more to security than allowing IPsec SAs to work over communications in such architectures. Marcelo pointed to some issues in his mail; you'd probably want to avoid other people hijacking your communications etc. I wanted to see if GSE had dealt with these issues, but here's what the security consideration section from the GSE draft says: >17. Security Considerations > > More than can be imagined. > --Jari _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 02 11:48:33 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 1EXLmr-0001II-QH; Wed, 02 Nov 2005 11:48:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXLmq-0001Hx-CL for architecture-discuss@megatron.ietf.org; Wed, 02 Nov 2005 11:48:32 -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 LAA18946 for ; Wed, 2 Nov 2005 11:48:11 -0500 (EST) Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXM1S-0002SV-63 for architecture-discuss@ietf.org; Wed, 02 Nov 2005 12:03:39 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 0663C872E4; Wed, 2 Nov 2005 11:48:21 -0500 (EST) To: architecture-discuss@ietf.org Message-Id: <20051102164821.0663C872E4@mercury.lcs.mit.edu> Date: Wed, 2 Nov 2005 11:48:21 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: jnc@mercury.lcs.mit.edu Subject: [Architecture-discuss] Re: 8+8 history (Re: Sources of architectural change) 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: Harald Tveit Alvestrand > The GSE proposal One of the unfortunate things about Mike's GSE document (as opposed to Dave Clark's 8+8 message to the IPng mailing list, which started the whole ball rolling) was that it (unfortunately) mixed together two separate ideas: - i) separation of location and identity, and - ii) automatic addition of "high-order" location information *at the site boundary* as the packets left the site The second, while interesting, resulted in the first not being given the distinct appraisal that it really deserved. > what it would take to bring it back: At the current stage of IPv6, it > seems to me that it would take someone working through how to allow one > subnet in a classical IPv6 network to use 8+8 while the rest of the > world didn't..... apparently nobody's seriously suggested that in > Multi6.... I don't know if it's workable..... Alas, at this point, I'm not sure it's viable. Here's the problem: 8+8 (in all its variants, including GSE - the two are *not* synonomous) assumed that the TCP checksum included only the "identity" part. That way, if the location-identity binding changed, it wouldn't complicate the checksum computation. (Having done an "add a location namespace to TCP-4" proposal in some detail for the NSRG, I can tell you that it gets pretty tricky.) To really get the full benefit of 8+8, you'd have to go back and change the TCPv6 checksum definition. This is unlikely to happen. So you're stuck with either an option to change the TCP checksum behaviour (see paren comment above) - which results in a lot more complexity, and an inability to make the extended features available to non-upgraded hosts. The *right* thing would have been to have considered location/identity separation as an *architectural* issue, and left the *engineering* issues of how to *secure* that binding until later - initial implementations could have, e.g., *locked* the binding to be that in the SYN packet (for TCP; other protocols the same). However, the basic mechanism (the binding table, the checksums, etc) would have been there, ready and waiting, when we did work out the engineering. (This, by the way, is exactly what we did with subnets - the host mechanism was added in RFC1122 before it was fully worked out how we were going to use it.) Water under the bridge now, alas... Although it remains a useful lesson for architects: work out basic concepts, add basic mechanisms, and *deliberately* leave the engineering details for later. If you can't do that, you're not doing architecture. (TCP retransmission is a great example of this: the details of the algorithms have changed completely, but the basic mechanisms, because they were fundamental, easily absorbed them.) [I put this part out of order, down here, so that this less valuable re-hasing of the past can be skipped by those who don't care.] > The IPNG WG seemed to achieve "rough consensus" that GSE was not a > viable approach; the arguments against GSE were summarized in the draft > draft-ietf-ipngwg-esd-analysis. > At some later time, this draft was proposed for publication. > .. the IESG questioned the justification for some of the claims in the > draft regarding the percieved security weaknesses of GSE and sent it > back to the WG; it never returned. As I recall (again, operating from memory, I haven't bothered to re-read the draft, or try and find my marked-up paper copy :-), a number of us heavily criticized the analysis as biased, and technically unsound, and the whole thing (proposal and analysis) just went into abeyance: the proposal because it was clearly not going to succeed, and the analysis because there was no point if the proposal was abandoned. To the best of my memory, I felt that the analysis was deeply flawed, and wound up coming down against *all* identity/location separation schemes on the basis of the problems with *this particular one*. Yes, of course when you have two different names, the binding between them is a point of attack. However, that's not sufficient reason to dismiss it. I felt such a conclusion was *especially* completely unreasonable because the then-contemporary MIPv6 concept (as I gleefully pointed out) did *exactly that* - separate identity and location! But the group which did the analysis (many of whom also worked on MIPv6, which just deepened the irony - or unfairness, depending on the mood in which one viewed the situation) didn't seem to take notice of that. All of which led me personally to conclude that it was a "hatchet job" - i.e. the outcome was determined before the analysis started. Those on the other side will no doubt feel I'm being unfair to them, but, as the lawyers say, "the document speaks for itself" - particularly the earlier versions. The later versions may have fixed some of the more egregious errors, but by then it was moot. Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 02 12:03: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 1EXM18-0000x9-Gj; Wed, 02 Nov 2005 12:03:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXM16-0000w9-QF for architecture-discuss@megatron.ietf.org; Wed, 02 Nov 2005 12:03: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 MAA21269 for ; Wed, 2 Nov 2005 12:02:55 -0500 (EST) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXMFi-0003cP-Qz for architecture-discuss@ietf.org; Wed, 02 Nov 2005 12:18:24 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EXM0v-0003aR-RC; Wed, 02 Nov 2005 09:03:06 -0800 Message-Id: <6.2.3.4.2.20051102173901.0448d850@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Wed, 02 Nov 2005 17:52:46 +0100 To: Tony Li From: "JFC (Jefsey) Morfin" Subject: Re: [Architecture-discuss] Re: 8+8 history (Re: Sources of architectural change) In-Reply-To: <05C8A2EA-1B8D-45F6-AD81-EB7632CCAA18@tony.li> References: <20051027122404.F31AA86AEE@mercury.lcs.mit.edu> <4368482B.2020808@thinkingcat.com> <33C7305E-DCCB-4094-B8BD-1F3BDEFFBC63@tony.li> <4368580A.4040607@thinkingcat.com> <6FD12FDCBB470881DF31DCEC@svartdal.hjemme.alvestrand.no> <4F300850-1672-4CC9-96E3-84B1D9CC8282@tony.li> <6.2.3.4.2.20051102154554.04495310@mail.jefsey.com> <05C8A2EA-1B8D-45F6-AD81-EB7632CCAA18@tony.li> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: e1e48a527f609d1be2bc8d8a70eb76cb 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 16:41 02/11/2005, Tony Li wrote: >There is much more to it than that. Basically, GSE was the last and >best effort to create an architecture that separated >the address into both a 'locator' (where is the host) and >'identifier' (the ESD in the draft). The TCP pseudo-header would >only be computed across the identifier and the locator would be free >to change. No problem with that. But you can imagine doing that easily today as a convention in a numbering plan. Not to confuse the words, I use routing/addressing/identification. The only information of interest for the network is routing. The rest of the address can be mangled by the ISP and restored when back. >Security would not cover the locator and security associations would >only be between ESDs. > >The locator/identifier architecture simplifies the architecture >because it allows both mobility and multi-homing to become >natural and pervasive. For mobility, the host is now free to change >its locator at will. For multi-homing, the same end-host can >now be reachable via multiple locators. We are entirely in agreement. This is the way mobilephones work? What I mean in saying it is accidental is that if you have 10 internet exchanges on Wimax in an area you can build such a system without asking anything to anyone between them. If it works you can install 100 more, etc. You can this way become the final world IP plan. You have changed nothing in the Internet architecture. You have just chosen your own usage architecture and disregarded many RFCs without any use to you. A simpler, more secure, etc. system which scaled. If an idea is good, it will eventually become used. With delays as many other ideas will have been verified on the market before. HIP seems obviously a good idea: at least it seems to correct these delaying ideas. But do we need it? jfc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 02 12:26:21 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 1EXMNR-0008NW-9P; Wed, 02 Nov 2005 12:26:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXMNP-0008Me-JR for architecture-discuss@megatron.ietf.org; Wed, 02 Nov 2005 12:26: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 MAA23261 for ; Wed, 2 Nov 2005 12:25:58 -0500 (EST) Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXMc1-000549-ML for architecture-discuss@ietf.org; Wed, 02 Nov 2005 12:41:27 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id jA2HQ9aF015325; Wed, 2 Nov 2005 09:26:09 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) id jA2HQ4IY015322; Wed, 2 Nov 2005 09:26:04 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 2 Nov 2005 09:26:04 -0800 From: David Meyer To: Jari Arkko Subject: Re: [Architecture-discuss] Re: 8+8 history (Re: Sources of architectural change) Message-ID: <20051102172604.GA15294@1-4-5.net> References: <4368482B.2020808@thinkingcat.com> <33C7305E-DCCB-4094-B8BD-1F3BDEFFBC63@tony.li> <4368580A.4040607@thinkingcat.com> <6FD12FDCBB470881DF31DCEC@svartdal.hjemme.alvestrand.no> <4F300850-1672-4CC9-96E3-84B1D9CC8282@tony.li> <6.2.3.4.2.20051102154554.04495310@mail.jefsey.com> <05C8A2EA-1B8D-45F6-AD81-EB7632CCAA18@tony.li> <4368E4C8.3050308@piuha.net> Mime-Version: 1.0 In-Reply-To: <4368E4C8.3050308@piuha.net> User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV. X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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="===============0597311621==" Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org --===============0597311621== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Q68bSM7Ycu6FN28Q" Content-Disposition: inline --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 02, 2005 at 06:09:44PM +0200, Jari Arkko wrote: > Tony Li wrote: >=20 > >There is much more to it than that. Basically, GSE was the last and =20 > >best effort to create an architecture that separated > >the address into both a 'locator' (where is the host) and =20 > >'identifier' (the ESD in the draft).=20 >=20 > I think some modern architectures such as HIP appear > to do a more thorough job and consider the whole problem. (Or at > least a larger problem, I think HIP NAT support needs improvement.) >=20 > >Security would not cover the locator and security associations would =20 > >only be between ESDs. >=20 > There's a lot more to security than allowing IPsec SAs to work over > communications in such architectures. Marcelo pointed to some > issues in his mail; you'd probably want to avoid other people hijacking > your communications etc. >=20 > I wanted to see if GSE had dealt with these issues, but here's what > the security consideration section from the GSE draft says: >=20 > >17. Security Considerations > > > > More than can be imagined. Please review http://www3.ietf.org/proceedings/99nov/I-D/draft-ietf-ipngwg-esd-analysis= -05.txt and http://www.cs.columbia.edu/~smb/papers/esd-secure.txt Dave --Q68bSM7Ycu6FN28Q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFDaPasORgD1qCZ2KcRAofhAJ9VLvI2yaFncEVDzpemQ6bzj6WuXACdGidC BDfVdoAYupQcQdSMPn8kYo4= =S+wM -----END PGP SIGNATURE----- --Q68bSM7Ycu6FN28Q-- --===============0597311621== 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 --===============0597311621==-- From architecture-discuss-bounces@ietf.org Wed Nov 02 12:40:20 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 1EXMax-0004sD-Uy; Wed, 02 Nov 2005 12:40:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXMar-0004rf-Bj for architecture-discuss@megatron.ietf.org; Wed, 02 Nov 2005 12:40: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 MAA24293 for ; Wed, 2 Nov 2005 12:39:51 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXMpT-0005ui-8B for architecture-discuss@ietf.org; Wed, 02 Nov 2005 12:55:20 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id jA2HdTx13686; Wed, 2 Nov 2005 19:39:29 +0200 Date: Wed, 2 Nov 2005 19:39:28 +0200 (EET) From: Pekka Savola To: Harald Tveit Alvestrand Subject: Re: [Architecture-discuss] QoS guarantees (RE: Mobility and multi-homing) In-Reply-To: <0F97656ED87FF9F54551250E@svartdal.hjemme.alvestrand.no> Message-ID: References: <936A4045C332714F975800409DE0924001388523@tayexc14.americas.cpqc orp.net> <0F97656ED87FF9F54551250E@svartdal.hjemme.alvestrand.no> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: architecture-discuss@ietf.org, Noel Chiappa , "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 On Wed, 2 Nov 2005, Harald Tveit Alvestrand wrote: > --On torsdag, oktober 27, 2005 19:02:13 -0400 "Bound, Jim" > wrote: >> Can guranteed QoS be achieved end-to-end and we have so many views on >> this and the current work and results from Diff and Int serve are not >> good enough by themselves, what is the answer? .... > my opinion, which is not worth much: > > Guarantee is an illusion. No matter how much you pay for "guaranteed > bandwidth", I'm not going to issue guarantees against a dinosaur-killer > asteroid landing on my NOC 10 years from now. If folks really want this, I'd start off by answering the question: What's in it [guaranteed e2e QoS] for me? [substituting 'me' for all the ISPs in the end-to-end path] Now, getting on my operator soap box... It should be pretty evident that e2e guaranteed QoS is basically a non-starter as long as it isn't tied to a money routing protocol. IMHO, the path-coupled signalling (nsis) that the IETF has been working on has very limited applicability (first hop router or internal enterprise network only). That's way too much (slow path, only, accounting, etc.) processing for routers, on each hop. A saner approach would be a complete path-decoupling, where dedicated boxes would be contacted for negotiating guarantees (and those boxes would propagate QoS configs on the required routers as needed). > a) let the net-provider state to the customer what he can expect from the > network (at an appropriate level of confidence) .... d) let the user easy determination which applications at which times (s)he would like to get a good guarantee -- and which ones the user doesn't care all that much about. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 02 13:38:12 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 1EXNUy-0007xK-5q; Wed, 02 Nov 2005 13:38:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXNUu-0007sn-JY for architecture-discuss@megatron.ietf.org; Wed, 02 Nov 2005 13:38: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 NAA29648 for ; Wed, 2 Nov 2005 13:37:46 -0500 (EST) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXNjX-0000it-ST for architecture-discuss@ietf.org; Wed, 02 Nov 2005 13:53:16 -0500 Received: from gihm3.apnic.net (dhcp18.potaroo.net [203.10.60.18]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id jA2IbUXt044894; Thu, 3 Nov 2005 05:37:32 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20051103052359.02c57828@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Thu, 03 Nov 2005 05:37:26 +1100 To: Harald Tveit Alvestrand , Tony Li , Leslie Daigle From: Geoff Huston Subject: Re: [Architecture-discuss] 8+8 history (Re: Sources of architectural change) In-Reply-To: <6FD12FDCBB470881DF31DCEC@svartdal.hjemme.alvestrand.no> References: <20051027122404.F31AA86AEE@mercury.lcs.mit.edu> <4368482B.2020808@thinkingcat.com> <33C7305E-DCCB-4094-B8BD-1F3BDEFFBC63@tony.li> <4368580A.4040607@thinkingcat.com> <6FD12FDCBB470881DF31DCEC@svartdal.hjemme.alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: architecture-discuss@ietf.org, 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: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org > >The first isn't even available from bgp.potaroo.net; the second is. It is now - thanks for letting me know http://draft-odell-8.potaroo.net/ >The IPNG WG seemed to achieve "rough consensus" that GSE was not a viable >approach; the arguments against GSE were summarized in the draft >draft-ietf-ipngwg-esd-analysis. > >At some later time, this draft was proposed for publication. > >This was in the Bad Days Before Tracker, so I'm operating strictly from >memory, both with dates and conclusions... my memory says that the IESG >questioned the justification for some of the claims in the draft regarding >the percieved security weaknesses of GSE and sent it back to the WG; it >never returned. > >Version -05 of that draft has a date of October 1999; version -00 had a >date of March 1997, and was written as *accepting* ESD, so while the end >result was probably a termination of discussion, the process did take 2.5 >years to get that far. > >WRT what it would take to bring it back: At the current stage of IPv6, it >seems to me that it would take someone working through how to allow one >subnet in a classical IPv6 network to use 8+8 while the rest of the world >didn't..... apparently nobody's seriously suggested that in Multi6.... I >don't know if it's workable..... To be best of my recollection this did not resurface in the multi6 effort - although its true to say that most forms of rewriting parts of the packet header by some form of foreign agent were reviewed in multi6. The issues of knowing (and being able to reliably detect) the difference between a 'friendly and helpful" rewrite and a "hostile effort at session hijack" remained significant issues with the foreign agent rewrite approaches. Like Harald my recollection of this in 1999 was that there was a similar concern over 8+8. Certainly this is once more an active topic, in that the issues here appear to be a rather tough trade-off between control of the security issues in a host-based approach to this topic (such as shim6) and a site/ locale-based approach to this topic (such as gse approaches). Among the detritus of unfinished work there was an effort by myself and Margaret Wasserman to write up the multi6 proposals - an early draft is in an appendix of http://smakd.potaroo.net/ietf/all-ids/draft-huston-multi6-architectures-00.txt-76090.txt. As I recall someone else volunteered at a multi6wg meeting to take on this as a separate draft - but no further progress was made Geoff _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 02 14:18:07 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 1EXO7b-0002ok-Lr; Wed, 02 Nov 2005 14:18:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXO7Z-0002o5-Di for architecture-discuss@megatron.ietf.org; Wed, 02 Nov 2005 14:18: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 OAA02590 for ; Wed, 2 Nov 2005 14:17:43 -0500 (EST) Received: from [63.240.77.82] (helo=sccrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXOMC-0002TQ-H0 for architecture-discuss@ietf.org; Wed, 02 Nov 2005 14:33:13 -0500 Received: from [192.168.1.5] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc12) with SMTP id <2005110219172901200dsrr4e>; Wed, 2 Nov 2005 19:17:50 +0000 In-Reply-To: References: <20051027122404.F31AA86AEE@mercury.lcs.mit.edu> <4368482B.2020808@thinkingcat.com> <33C7305E-DCCB-4094-B8BD-1F3BDEFFBC63@tony.li> <4368580A.4040607@thinkingcat.com> <6FD12FDCBB470881DF31DCEC@svartdal.hjemme.alvestrand.no> <4F300850-1672-4CC9-96E3-84B1D9CC8282@tony.li> <04F62EE55B5A451DBE302396@svartdal.hjemme.alvestrand.no> <71D25A96-26F0-4E25-9E9B-D2D74EBCBFA8@tony.li> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1EEFC22F-E185-46AD-9837-C7AE456DA281@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Date: Wed, 2 Nov 2005 11:17:28 -0800 To: Harald Tveit Alvestrand X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: architecture-discuss@ietf.org, Noel Chiappa Subject: [arch-d] Re: 8+8 history (Re: Sources of architectural change) 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'm fond of not making completely definite statements, but in this > case, it's hard to imagine the change :-) > > if we REALLY want to change it, it's probably simpler to do so by > changing the protocol number for TCP..... TCPng, anyone? Harald, I have to look at this as simply another indication that we're not ready to make architectural changes. Shifting to a new protocol number is largely not helpful. It implies that to truly introduce GSE, we have to renumber *all* of the transports and have backwards compatibility built into all of them. How is this simpler than changing the version number in the IP header? Regards, Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 02 14:52:33 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 1EXOev-0000Xz-6f; Wed, 02 Nov 2005 14:52:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXOet-0000Va-Cx for architecture-discuss@megatron.ietf.org; Wed, 02 Nov 2005 14:52: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 OAA04961 for ; Wed, 2 Nov 2005 14:52:09 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXOtV-0003qm-OL for architecture-discuss@ietf.org; Wed, 02 Nov 2005 15:07:40 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 02 Nov 2005 11:52:18 -0800 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jA2JqETH003790; Wed, 2 Nov 2005 11:52:15 -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 SMTP id jA2K1kAg010444; Wed, 2 Nov 2005 12:01:46 -0800 In-Reply-To: <0F97656ED87FF9F54551250E@svartdal.hjemme.alvestrand.no> References: <936A4045C332714F975800409DE0924001388523@tayexc14.americas.cpqc orp.net> <0F97656ED87FF9F54551250E@svartdal.hjemme.alvestrand.no> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <58F8C14C-C451-4A5A-A088-1013FFA659E1@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Date: Wed, 2 Nov 2005 11:52:13 -0800 To: Harald Tveit Alvestrand X-Mailer: Apple Mail (2.746.2) DKIM-Signature: a=rsa-sha1; q=dns; l=3113; t=1130961706; x=1131393906; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:Re=3A=20[Architecture-discuss]=20QoS=20guarantees=20(RE=3A=20Mobility=20 and=20multi-homing)| From:Fred=20Baker=20| Date:Wed,=202=20Nov=202005=2011=3A52=3A13=20-0800| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=H+Q6lc9sw9u9UJ+V79xQEH9l9jldZjYphGxL0ATutpKog0wTFNS1OeK6j5UDjU6vJV7/A7aY DuR5nbrV9WYCFUxq2pC5A/MuqYy/ETuexW8OwQ91J3zD9+g2M3E1edPyEfa8tQ1rVSDiA2ck0F0 scGE1Ri1oRJx7R+yiD/rOrMg= 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: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Cc: architecture-discuss@ietf.org, Noel Chiappa , "Bound, Jim" Subject: [arch-d] Re: [Architecture-discuss] QoS guarantees (RE: Mobility and multi-homing) 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 If you sell an SLA that mentions bandwidth, and AFAIK most ISPs do, I think you'll agree that the SLA is not against dinosaur-killing asteroids. It is about the service you will deliver to a specified customer during a finite period of time at a cost under normal conditions. I'd really suggest that if we want to have this discussion, we don't branch into put-downs and hyperbole. It doesn't help. You have two levels of guarantees under discussion here. One is the base SLA - "you pay me $$$ and I will deliver ". That is the state of play today. Those who are discussing integrated services negotiation at a finer level are discussion something related-but-different. "Given that you are delivering , I intend to use part of it for a real-time service that doesn't adapt or has at most limited ability to adapt to the network, and you have agreed to support up to of that on my behalf. If I add an additional session with characteristics, would I still be within ?" The "guarantee" relates to the network's ability to deliver a service to an inelastic application within a larger SLA at a time, and presumably at a cost or within a budget paid in another way. Where this becomes important is places where congestion does in fact set in, as opposed to places where effectively-infinite bandwidth is the rule. Within ISPs located within the better-funded parts of the world, and to a less extent between those ISPs, we deploy sufficient bandwidth that there isn't a lot of question. Ditto on LANs, which is to say "within campuses". Effectively-infinite bandwidth has yet to make it to relatively large parts of the world, however, and that includes access networks like the one attached to the other end of my house. Something that affects that is services offered to a user, especially when they have different privilege levels. That is the place of discussions like ieprep is having. On Nov 2, 2005, at 7:57 AM, Harald Tveit Alvestrand wrote: > > > --On torsdag, oktober 27, 2005 19:02:13 -0400 "Bound, Jim" > wrote: > >> Can guranteed QoS be achieved end-to-end and we have so many views on >> this and the current work and results from Diff and Int serve are not >> good enough by themselves, what is the answer? > > Branching discussions is so much fun :-) > > my opinion, which is not worth much: > > Guarantee is an illusion. No matter how much you pay for > "guaranteed bandwidth", I'm not going to issue guarantees against a > dinosaur-killer asteroid landing on my NOC 10 years from now. > > The question we SHOULD be asking is whether diffserv and/or intserv > gives us the tools we need to do: > > a) let the net-provider state to the customer what he can expect > from the network (at an appropriate level of confidence) > > b) let the customer state to the net-provider what he wants from > the network (and the level of confidence he needs) > > c) let the net-provider(s) keep track of what they have promised in > the aggregate, and know whether or not he's able to deliver on his > promises at any given time. > > Note that a) and b) can occur in any order, including > ababababab.... that's called "negotiation".... and I'm sure that > some people will claim that the answer to c) is "MPLS", whereas > others will say "if the answer is MPLS, you have misunderstood the > question"..... > > > > > > > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss -------------------------------------------------------------- "Don't worry about the world coming to an end today. It's already tomorrow in Australia." (Charles Schulz ) _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 02 15:49:12 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 1EXPXk-0003Qo-5d; Wed, 02 Nov 2005 15:49:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXPXh-0003Pt-Rk for architecture-discuss@megatron.ietf.org; Wed, 02 Nov 2005 15:49: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 PAA07438 for ; Wed, 2 Nov 2005 15:48:47 -0500 (EST) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXPmM-00068m-Lp for architecture-discuss@ietf.org; Wed, 02 Nov 2005 16:04:19 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 773662596DE; Wed, 2 Nov 2005 21:48:16 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14045-07; Wed, 2 Nov 2005 21:48:11 +0100 (CET) Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 24A382596CA; Wed, 2 Nov 2005 21:48:09 +0100 (CET) Date: Wed, 02 Nov 2005 21:33:52 +0100 From: Harald Tveit Alvestrand To: Fred Baker Message-ID: <2088DA895CF0824F8877A708@B50854F0A9192E8EC6CDA126> X-Mailer: Mulberry/4.0.3 (Win32) MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: architecture-discuss@ietf.org, Noel Chiappa , "Bound, Jim" Subject: [arch-d] Re: [Architecture-discuss] QoS guarantees (RE: Mobility and multi-homing) 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="===============0924660836==" Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org --===============0924660836== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========A8FA7EDCECF78C48572B==========" --==========A8FA7EDCECF78C48572B========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable --On 2. november 2005 11:52 -0800 Fred Baker wrote: > If you sell an SLA that mentions bandwidth, and AFAIK most ISPs do, I > think you'll agree that the SLA is not against dinosaur-killing > asteroids. It is about the service you will deliver to a specified > customer during a finite period of time at a cost under normal > conditions. I'd really suggest that if we want to have this discussion, > we don't branch into put-downs and hyperbole. It doesn't help. wasn't intending to be hyperbolic - just pointing out that the word=20 "guarantee" shouldn't be read as "absolute certainty", but "reasonable=20 reassurance" - that might be so obvious by now that I'm beating in open=20 doors; not an useful exercise.... > You have two levels of guarantees under discussion here. One is the base > SLA - "you pay me $$$ and I will deliver attributes>". That is the state of play today. Those who are discussing > integrated services negotiation at a finer level are discussion > something related-but-different. "Given that you are delivering , I > intend to use part of it for a real-time service that doesn't adapt or > has at most limited ability to adapt to the network, and you have agreed > to support up to of that on my behalf. If I add an additional > session with characteristics, would I still be within > ?" The "guarantee" relates to the network's ability to deliver a > service to an inelastic application within a larger SLA at a time, and > presumably at a cost or within a budget paid in another way. I think we're on the same page...... in addition, the supercomputer guys=20 and the HD video guys seem to be pushing the amount of traffic offered to=20 levels where "effectively infinite" isn't so infinite any more..... --==========A8FA7EDCECF78C48572B========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) iD8DBQFDaSKwOMj+2+WY0F4RAq3wAJ9r9aksMKUS6o171lGfSD0hmfmPVwCeNtCA fZvuMzZjitHS1Wm3k4TSYfM= =lo70 -----END PGP SIGNATURE----- --==========A8FA7EDCECF78C48572B==========-- --===============0924660836== 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 --===============0924660836==-- From architecture-discuss-bounces@ietf.org Wed Nov 02 17:50:22 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 1EXRR0-0000Hf-Sz; Wed, 02 Nov 2005 17:50:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXRQz-0000GQ-Vc for architecture-discuss@megatron.ietf.org; Wed, 02 Nov 2005 17:50:22 -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 RAA13375 for ; Wed, 2 Nov 2005 17:50:00 -0500 (EST) Received: from prue.eim.surrey.ac.uk ([131.227.76.5] ident=exim) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXRff-0002qW-07 for architecture-discuss@ietf.org; Wed, 02 Nov 2005 18:05:32 -0500 Received: from argos.ee.surrey.ac.uk ([131.227.89.15] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 1EXRQU-0004A1-00; Wed, 02 Nov 2005 22:49:50 +0000 Date: Wed, 2 Nov 2005 22:49:47 +0000 (GMT) From: Lloyd Wood X-X-Sender: eep1lw@argos.ee.surrey.ac.uk To: "Edward A. Gardner" In-Reply-To: <4.3.1.2.20051102073045.00b75630@pop3.mailpci.net> Message-ID: References: <20051027122404.F31AA86AEE@mercury.lcs.mit.edu> <4368482B.2020808@thinkingcat.com> <33C7305E-DCCB-4094-B8BD-1F3BDEFFBC63@tony.li> <4368580A.4040607@thinkingcat.com> <4.3.1.2.20051102073045.00b75630@pop3.mailpci.net> Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanner: exiscan *1EXRQU-0004A1-00*AA9h0z9p.Yk* (SECM, UniS) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: architecture-discuss@ietf.org Subject: [arch-d] Re: [Architecture-discuss] 8+8 history (Re: Sources of architectural change) 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, 2 Nov 2005, Edward A. Gardner wrote: > At 03:31 02-11-2005, Harald Tveit Alvestrand wrote: > >Since this is ancient history for most of us, some rehashing may be in > >order, at least about what the history was.... > > Not only is it ancient history, many/most of us lurkers have no idea what > draft-ietf-ipngwg-gseaddr proposed or is about and have no idea what the > rest of you are talking about. http://www.watersprings.org/pub/id/draft-odell-8%2B8-00.txt http://www.watersprings.org/pub/id/draft-ietf-ipngwg-gseaddr-00.txt http://www.watersprings.org/pub/id/draft-ietf-ipngwg-esd-analysis-00.txt through to http://www.watersprings.org/pub/id/draft-ietf-ipngwg-esd-analysis-05.txt Watersprings is a useful tool. Get up to speed. L. > And as all the tombstones say, it wasn't an > archival document. > > If rehashing that decision is important to this discussion list, would > someone please post a technical summary of that proposal or a pointer to one? > > If rehashing that decision isn't relevant or constructive, maybe we can > proceed on to something that is? > > Ed Gardner _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 04 10:13: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 1EY3Fw-0006pu-3e; Fri, 04 Nov 2005 10:13:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY3Fu-0006pp-6I for architecture-discuss@megatron.ietf.org; Fri, 04 Nov 2005 10:13: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 KAA25032 for ; Fri, 4 Nov 2005 10:13:02 -0500 (EST) Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EY3Ur-0001Bw-36 for architecture-discuss@ietf.org; Fri, 04 Nov 2005 10:28:57 -0500 Received: from i2kc07-ukbr.domain1.systemhost.net ([193.113.197.14]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 4 Nov 2005 15:13:10 +0000 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by i2kc07-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 4 Nov 2005 15:13:09 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 4 Nov 2005 15:13:09 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1131117188698; Fri, 4 Nov 2005 15:13:08 +0000 Received: from mut.jungle.bt.co.uk ([10.86.8.114]) by bagheera.jungle.bt.co.uk (8.12.8/8.12.8) with ESMTP id jA4FD5Dr015127; Fri, 4 Nov 2005 15:13:07 GMT Message-Id: <5.2.1.1.2.20051104144743.045b9cc8@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 04 Nov 2005 14:55:14 +0000 To: Leslie Daigle From: Bob Briscoe Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 04 Nov 2005 15:13:09.0206 (UTC) FILETIME=[43DD1F60:01C5E152] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: architecture-discuss@ietf.org Subject: [arch-d] Re: [Architecture-discuss] Overall open architectural issues 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 Leslie, I would have thought a useful starting agenda would be the output (particularly the initial requirements white paper) of the DARPA NewArch project. I wasn't involved directly myself, but my future comms architecture group in BT was addressing many of these issues in parallel to NewArch and still is. On the issue of "dealing with bad traffic" in Pekka's starting list, the following draft was recently posted to the tsvwg list for Vancouver: Re-ECN: Adding Accountability for Causing Congestion to TCP/IP Other file formats: It doesn't discriminate bad from good (so the evil bit of RFC3514 is available for other uses ;) but it aims to ensure bad can't cause any more congestion than good in the long run (at the user level, as well as the flow level and packet level). It has weaknesses which are largely due to the limited space available in the IPv4 header for making it incrementally deployable. It is based on a more secure scheme referred to within the I-D, which was intended as a longer-term solution as it uses multiple header bits so would require widespread support from v6 routers. Bob ____________________________________________________________________________ Notice: This contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of BT plc. ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 08 13:26:34 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 1EZYB0-0006As-1v; Tue, 08 Nov 2005 13:26:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZYAz-0006Ad-36 for architecture-discuss@megatron.ietf.org; Tue, 08 Nov 2005 13:26:33 -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 NAA24041 for ; Tue, 8 Nov 2005 13:26:06 -0500 (EST) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZYQp-0003xl-Fm for architecture-discuss@ietf.org; Tue, 08 Nov 2005 13:42:56 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 5558E212C2D for ; Tue, 8 Nov 2005 20:26:12 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: <00F90D66-5019-4F73-8858-E1BF7DF94A1B@nomadiclab.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: architecture-discuss@ietf.org From: Pekka Nikander Date: Tue, 8 Nov 2005 10:26:09 -0800 X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: 7bit Subject: [arch-d] IP virtualisation: Summary and take 2 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 This is my personal, admittedly biased summary of the IP virtualisation discussion so far. My apologies that I started the discussion but haven't replied anything until now, but I got a day job override around the same time Leslie forwarded the initial messages. The discussion so far seems to have circulated around tunnelling, without really getting to what I consider a more pressing problem: what are the real reasons why people do use tunnelling; or, to put it differently, what are the requirements that drive people to virtualise IP with tunnelling. In other words, in a way we have been rehashing the discussion at the Internet Area mailing list -- probably because of only partially overlapping audience. Hence, I would urge people to (re)read the INT area discussion before rebashing tunnelling any more, see e.g. the following: My original posting at INT area (note that my thoughts have since evolved): http://www1.ietf.org/mail-archive/web/int-area/current/msg00005.html Tony's good summary of how tunnelling is a means of virtualisation: http://www1.ietf.org/mail-archive/web/int-area/current/msg00008.html My mid-discussion summary: http://www1.ietf.org/mail-archive/web/int-area/current/msg00027.html Tony's excellent questioning of my summary: http://www1.ietf.org/mail-archive/web/int-area/current/msg00029.html Brian's note about an alternative, shimming: http://www1.ietf.org/mail-archive/web/int-area/current/msg00072.html There were also other good posts by many people, including Joe Touch and Jim Bound and many others; the quality of discussion was IMHO very high. I've picked above those that I think are most important from the point of view of trying to get this discussion forward. If you are interested in seeing how to really use tunnelling in a good way, I also encourage you to read Joe's mails, e.g. http://www1.ietf.org/mail-archive/web/int-area/current/msg00028.html http://www1.ietf.org/mail-archive/web/int-area/current/msg00035.html http://www1.ietf.org/mail-archive/web/int-area/current/msg00037.html http://www1.ietf.org/mail-archive/web/int-area/current/msg00080.html The summary of the INT area discussion, and this discussion here so far, is that tunnelling is a fine tool for many purposes, including but not limited to IP virtualisation. However, at the same time, there are also a number of concerns, some of which are more technical in nature (e.g. MTU, overhead) and some of which are more architectural (e.g. IP addresses no longer represent end-points, tunnelling allows transparency at the core, tunnelling can be used to circumvent firewall policies). Now, trying to go forward, the reason why I took this topic up in the first place was that I would like to better understand the various sets of semantics that various groups of users expect from IP. The fact that we use tunnelling to virtualise IP seems to indicate that different user groups want different semantics, and that the current global IP service does not fulfil these semantical needs. Let me try to take a simplistic attempt to describe a couple of scenarios: 1. A home user An individual home user is interested in a) general connectivity for web browsing and other similar needs b) connectivity with her social tribe, i.e. friends etc c) connectivity to the services at her job Of these, c) may benefit from IP virtualisation. Indeed, if the user uses IPsec VPN for connecting to her employer's intranet, her computer may have a virtual interface corresponding to this VPN connection. What makes this scenario tricky, from the current architecture point of view, is the desire to keep at least the domains a) and c) clearly separate, and the separate security requirements pertaining to them. 2. Distributed corporate intranet Typically, users of a corporate intranet currently use mainly the intranet, accessing the Internet through an application level gateway, or at least a packet filtering firewall. A good question is whether it would be better to describe the situation in terms of two virtual networks, 1) the corporate intranet and 2) the public internet, with separate types of firewalling towards each of them, and with string separation between them. --- Based on the two simplistic examples above, I think it is fair to state that there seems to be a need for having simultaneous but clearly separated connectivity with multiple disjoint IP networks. Is the requirement really that simple? Now, putting aside that the requirement can be (and is being) solved with tunnelling, would there be alternative ways of doing this? Are Unique Local IPv6 Unicast Addresses (RFC 4193) another way to achieve the goal? If not, what else is needed? --Pekka Nikander _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 10 12:27:23 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 1EaGCp-0001p6-JB; Thu, 10 Nov 2005 12:27:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaGCo-0001os-4x for architecture-discuss@megatron.ietf.org; Thu, 10 Nov 2005 12:27:22 -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 MAA19951 for ; Thu, 10 Nov 2005 12:26:51 -0500 (EST) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaGT2-00018Y-7E for architecture-discuss@ietf.org; Thu, 10 Nov 2005 12:44:08 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 910F3212C2D for ; Thu, 10 Nov 2005 19:27:02 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: <6FD4CFA5-B16E-43D8-AA5C-74BBB2B4F7AF@nomadiclab.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: architecture-discuss@ietf.org From: Pekka Nikander Date: Thu, 10 Nov 2005 09:26:55 -0800 X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: 7bit Subject: [arch-d] Mobility and multi-homing: Summary and going forward 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 This is my biased summary of the Mobility and Multi-homing discussion so far, with some suggestions of moving forward in the end. It looks like that this particular threat diverged quite fast from its original topic, to other useful -- but different -- topics. I am ignoring the other topics here. I was able to find five distinct subtopics that seemed to be relevant: 1. Noel stated that if the architecture isn't rich enough, we end up with feature-cancer. Jari stated that mobility does not involve just a single solution but a set of separable pieces. 2. From an architectural point of view, it is clear that supporting mobility and multi-homing must take place above the traditional "deliver packet from this interface to that interface" IP service. Noel stated that the best suggestion so far has been the NSRG concept of designing a new name space, somewhere above the traditional IP service. 3. According to Noel, in a perfect world, a shim approach might be better, but given the current state, bundling with new transports may be easier. 4. There are different operational environments, and we need to pay attention to deployment in these different environments. 5. The topic can be expanded to consider also other aspects of mobility and multi-homing, such as service mobility within a server farm, or denial-of-service protection. In the following, I ignore topics #4 and #5, not because they are not important but because I consider #4 orthogonal to the other discussion and #5 as a pure research issue for the time being, with little direct engineering consequences. However, I do think that as time passes more generic concepts (like service mobility) will become more important and we need to keep them in mind in this discussion. The problem: Lack of richness in the architecture, or missing name spaces ======================================================================== = Noel noted that when the underlying architecture isn't rich enough, in namespaces, mechanisms, etc, the approaches to add functionality that would require them will not be nice (ugly "bags on the side"). In my opinion, another way of stating the same (in this particular case) is that if we are missing a layer of indirection, any attempt to add the functionality without adding a name space will end up using one of the existing name spaces for multiple semantically different purposes, make the solutions, in some sense, ugly. There are a number of questions that need to be answered in order to understand what kind of name space should be added to the architecture. Hence, my conclusion here is that we should focus a little bit more on understanding what are the right questions. At the IAB list, some people recently asked whether we have a good set of mobility requirements, and the answer is apparently "no". Related to this, Jari made the comment that to him it seems more important to break down the problem into separable pieces. While I sympathetic and certainly can see how certain pieces of the problem (like attachment detection or path exploration) can and should be seen as separate issues, I am not sure if the core problem (need for a new layer of indirection) can be split into subpieces. The solution and its nature: a new name space, shim or not ========================================================== It seems to be clear that mobility and multi-homing support has to happen above the "deliver a packet from this interface to that interface" layer, or what has traditionally been considered as the core of the IP. At this point we need to be careful, as today's IP has package that is not really that much interface-to-interface in nature any more; IPsec is a prime example, in my opinion. Noel stated his opinion that the NSRG concept of designing a new namespace, and deploying it one application and/or transport layer at a time, was the best one. Personally, I am a little worried about this approach, as it seems to require changing all transports and applications. Noel continued to state that in a perfect world he would he'd go for a shim, but in real world he'd be more inclined to bundle it with transports. I have a different opinion here. I see two concrete possibilities of going forward in a shim-like way. One is HIP, perhaps first deploying HIP with IP addresses as ULIDs just in order to make early deployment easier, and then later on proceeding to use HITs as ULIDs. The danger of such two-step approach is, of course, that we may fail to do the second step, and that would be bad. The other alternative transition mechanism would be to start using CGA, or something like CGA, to associate a public key or other similar identifiers with ULID IPv6 addresses. From a semantic point of view the ULID would stand as a proxy for the public key, the public key (or other identifier) being the real end-point identifier. Under this layer we could then run shim6 with mobility extensions, HIP, or some hybrid of them. In any case, the goal of any transition mechanism like this would be to gradually move into an architecture that does have a new name space and a new layer of indirection. --Pekka Nikander _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Nov 10 21:59:56 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 1EaP8u-0000Ge-K4; Thu, 10 Nov 2005 21:59:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaP8s-0000GO-QK for architecture-discuss@megatron.ietf.org; Thu, 10 Nov 2005 21:59:55 -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 VAA05851 for ; Thu, 10 Nov 2005 21:59:26 -0500 (EST) From: john.loughney@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaPPC-0005Da-A4 for architecture-discuss@ietf.org; Thu, 10 Nov 2005 22:16:47 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jAB2tJGf012497; Fri, 11 Nov 2005 04:55:25 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Nov 2005 04:59:49 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Nov 2005 04:59:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 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] Mobility and multi-homing: Summary and going forward Date: Fri, 11 Nov 2005 04:59:40 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D015CB46C@esebe100.NOE.Nokia.com> Thread-Topic: [arch-d] Mobility and multi-homing: Summary and going forward Thread-Index: AcXmHFhhgcNgBRlAQzyjPmqeLsto8AATxhbg To: , X-OriginalArrivalTime: 11 Nov 2005 02:59:49.0900 (UTC) FILETIME=[FB2014C0:01C5E66B] X-Spam-Score: 0.3 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 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 Pekka, I actually would like to see Applicability Statements for HIP, MIP(v4/v6), MONAMI, SHIM6, mSCTP, NETLMM, etc. I actually think that we need to do a bit of thinking of how each piece might live within the Internet, how you perform address selection=20 when an application wants to get a new IP address (does it use the HIP or MIP stack on it), etc. etc. I'd like to see some quick diagrams of the stack calls; see what happens when we have address agility - within a single interface and across different interfaces. =20 John >-----Original Message----- >From: architecture-discuss-bounces@ietf.org=20 >[mailto:architecture-discuss-bounces@ietf.org] On Behalf Of=20 >ext Pekka Nikander >Sent: 10 November, 2005 19:27 >To: architecture-discuss@ietf.org >Subject: [arch-d] Mobility and multi-homing: Summary and going forward > >This is my biased summary of the Mobility and Multi-homing=20 >discussion so far, with some suggestions of moving forward in the end. > >It looks like that this particular threat diverged quite fast from =20 >its original topic, to other useful -- but different -- topics. I =20 >am ignoring the other topics here. > >I was able to find five distinct subtopics that seemed to be relevant: > > 1. Noel stated that if the architecture isn't rich enough, > we end up with feature-cancer. Jari stated that mobility > does not involve just a single solution but a set of separable > pieces. > > 2. From an architectural point of view, it is clear that supporting > mobility and multi-homing must take place above the traditional > "deliver packet from this interface to that interface"=20 >IP service. > Noel stated that the best suggestion so far has been the NSRG > concept of designing a new name space, somewhere above the > traditional IP service. > > 3. According to Noel, in a perfect world, a shim approach might > be better, but given the current state, bundling with new > transports may be easier. > > 4. There are different operational environments, and we need to > pay attention to deployment in these different environments. > > 5. The topic can be expanded to consider also other aspects of > mobility and multi-homing, such as service mobility within a > server farm, or denial-of-service protection. > >In the following, I ignore topics #4 and #5, not because they=20 >are not important but because I consider #4 orthogonal to the=20 >other discussion and #5 as a pure research issue for the time=20 >being, with little direct engineering consequences. However,=20 >I do think that as time passes more generic concepts (like=20 >service mobility) will become more important and we need to=20 >keep them in mind in this discussion. > >The problem: Lack of richness in the architecture, or missing=20 >name spaces=20 >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=3D=3D=3D=3D=3D=3D=3D=3D=3D >=3D > >Noel noted that when the underlying architecture isn't rich=20 >enough, in namespaces, mechanisms, etc, the approaches to add=20 >functionality =20 >that would require them will not be nice (ugly "bags on the side"). =20 >In my opinion, another way of stating the same (in this particular >case) is that if we are missing a layer of indirection, any=20 >attempt to add the functionality without adding a name space=20 >will end up using one of the existing name spaces for multiple=20 >semantically different purposes, make the solutions, in some=20 >sense, ugly. > >There are a number of questions that need to be answered in=20 >order to understand what kind of name space should be added to=20 >the architecture. Hence, my conclusion here is that we should=20 >focus a little bit more on understanding what are the right=20 >questions. At the IAB list, some people recently asked=20 >whether we have a good set of mobility requirements, and the=20 >answer is apparently "no". > >Related to this, Jari made the comment that to him it seems=20 >more important to break down the problem into separable=20 >pieces. While I sympathetic and certainly can see how certain=20 >pieces of the problem (like attachment detection or path=20 >exploration) can and should be seen as separate issues, I am=20 >not sure if the core problem (need for a new layer of=20 >indirection) can be split into subpieces. > >The solution and its nature: a new name space, shim or not=20 >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > >It seems to be clear that mobility and multi-homing support=20 >has to happen above the "deliver a packet from this interface=20 >to that interface" layer, or what has traditionally been=20 >considered as the core of the IP. At this point we need to be=20 >careful, as today's IP has package that is not really that=20 >much interface-to-interface in nature any more; IPsec is a=20 >prime example, in my opinion. > >Noel stated his opinion that the NSRG concept of designing a=20 >new namespace, and deploying it one application and/or=20 >transport layer at a time, was the best one. Personally, I am=20 >a little worried about this approach, as it seems to require=20 >changing all transports and =20 >applications. Noel continued to state that in a perfect world he =20 >would he'd go for a shim, but in real world he'd be more=20 >inclined to bundle it with transports. > >I have a different opinion here. I see two concrete=20 >possibilities of going forward in a shim-like way. One is=20 >HIP, perhaps first deploying HIP with IP addresses as ULIDs=20 >just in order to make early deployment easier, and then later=20 >on proceeding to use HITs as ULIDs. The danger of such=20 >two-step approach is, of course, that we may fail to do the=20 >second step, and that would be bad. > >The other alternative transition mechanism would be to start=20 >using CGA, or something like CGA, to associate a public key or=20 >other similar identifiers with ULID IPv6 addresses. From a=20 >semantic point of view the ULID would stand as a proxy for the=20 >public key, the public key (or other identifier) being the=20 >real end-point identifier. Under this layer we could then run=20 >shim6 with mobility extensions, HIP, or some hybrid of them. > >In any case, the goal of any transition mechanism like this=20 >would be to gradually move into an architecture that does have=20 >a new name space and a new layer of indirection. > >--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 Fri Nov 11 00:29: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 1EaRTB-00009W-7h; Fri, 11 Nov 2005 00:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaRT9-00007M-2r for architecture-discuss@megatron.ietf.org; Fri, 11 Nov 2005 00:28:59 -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 AAA14425 for ; Fri, 11 Nov 2005 00:28:29 -0500 (EST) Received: from sokol.elan.net ([216.151.192.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaRjV-0000kQ-CB for architecture-discuss@ietf.org; Fri, 11 Nov 2005 00:45:53 -0500 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id jAB5Sipu004996; Thu, 10 Nov 2005 21:28:44 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id jAB5Sehk004993; Thu, 10 Nov 2005 21:28:40 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Thu, 10 Nov 2005 21:28:40 -0800 (PST) From: "william(at)elan.net" To: john.loughney@nokia.com Subject: RE: [arch-d] Mobility and multi-homing: Summary and going forward In-Reply-To: <1AA39B75171A7144A73216AED1D7478D015CB46C@esebe100.NOE.Nokia.com> Message-ID: References: <1AA39B75171A7144A73216AED1D7478D015CB46C@esebe100.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: pekka.nikander@nomadiclab.com, 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 Fri, 11 Nov 2005 john.loughney@nokia.com wrote: > Pekka, > > I actually would like to see Applicability Statements for HIP, > MIP(v4/v6), > MONAMI, SHIM6, mSCTP, NETLMM, etc. > > I actually think that we need to do a bit of thinking of how each piece > might live within the Internet, how you perform address selection > when an application wants to get a new IP address (does it use the > HIP or MIP stack on it), etc. etc. Particularly interesting would be diagram of how all the above can (or can not) work together; and if some of them can not be used together explanation as to why not and which of the technologies are exclusive of the other ones. P.S. Personally I think we need to evaluate ASAP if we really need another layer in between IP and TCP/UDP and if it is needed then design it in appropriate way with "base" layer protocol and additional specification that use this layer (instead of designing several protocols that each introduce new layers "close" to each other). -- 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 Fri Nov 11 00:40:25 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 1EaReD-00026w-5K; Fri, 11 Nov 2005 00:40:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaReB-00026o-IG for architecture-discuss@megatron.ietf.org; Fri, 11 Nov 2005 00:40: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 AAA14838 for ; Fri, 11 Nov 2005 00:39:54 -0500 (EST) From: john.loughney@nokia.com Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaRuW-0000zU-NO for architecture-discuss@ietf.org; Fri, 11 Nov 2005 00:57:18 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jAB5eCAS007035; Fri, 11 Nov 2005 07:40:13 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Nov 2005 07:40:03 +0200 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Nov 2005 07:40:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 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] Mobility and multi-homing: Summary and going forward Date: Fri, 11 Nov 2005 07:40:04 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D015CB479@esebe100.NOE.Nokia.com> Thread-Topic: [arch-d] Mobility and multi-homing: Summary and going forward Thread-Index: AcXmgPXLNrAW/46lTQmOT7mWe89Y/AAAJcGQ To: X-OriginalArrivalTime: 11 Nov 2005 05:40:02.0546 (UTC) FILETIME=[5CB57520:01C5E682] X-Spam-Score: 0.3 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Cc: pekka.nikander@nomadiclab.com, 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 William, >> I actually would like to see Applicability Statements for HIP,=20 >> MIP(v4/v6), MONAMI, SHIM6, mSCTP, NETLMM, etc. >> >> I actually think that we need to do a bit of thinking of how each=20 >> piece might live within the Internet, how you perform address=20 >> selection when an application wants to get a new IP address (does it=20 >> use the HIP or MIP stack on it), etc. etc. > >Particularly interesting would be diagram of how all the above=20 >can (or can not) work together; and if some of them can not be=20 >used together explanation as to why not and which of the=20 >technologies are exclusive of the other ones. That's kind of what I was getting at. Depending upon what is needed, one could see making a socket (or socket-like) call that would start 'simple' IP, MIP, HIP, whatever ... and understanding which type of IP 'service' you wanted. That's why I somewhat think this could be considered an address selection issue - do you want a MIP address, HIP address, SHIM address ... Life with IPv6 already brings this up, as a 1-to-1 relationship IP address to an interface doesn't hold. >P.S. Personally I think we need to evaluate ASAP if we really=20 >need another layer in between IP and TCP/UDP and if it is=20 >needed then design it in appropriate way with "base" layer=20 >protocol and additional specification that use this layer=20 >(instead of designing several protocols that each introduce=20 >new layers "close" to each other). At the shim6 meeting in Paris, Christian Huitema pointed out that while we like to think that TCP & IP are separate layers, that's not how people implement them. I think that any 'layer' between transport & IP might be a separate layer on paper, but won't be in implementation. John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 11 00:53:53 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 1EaRrE-0007Ox-OS; Fri, 11 Nov 2005 00:53:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaRrD-0007MJ-0I for architecture-discuss@megatron.ietf.org; Fri, 11 Nov 2005 00:53:51 -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 AAA15317 for ; Fri, 11 Nov 2005 00:53:21 -0500 (EST) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaS7Y-0001Em-6L for architecture-discuss@ietf.org; Fri, 11 Nov 2005 01:10:45 -0500 Received: from gihm3.apnic.net (kahuna.telstra.net [203.50.0.6]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id jAB5qcXv016384; Fri, 11 Nov 2005 16:52:42 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20051111164407.02a83858@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 11 Nov 2005 16:52:35 +1100 To: john.loughney@nokia.com, From: Geoff Huston Subject: RE: [arch-d] Mobility and multi-homing: Summary and going forward In-Reply-To: <1AA39B75171A7144A73216AED1D7478D015CB479@esebe100.NOE.Noki a.com> References: <1AA39B75171A7144A73216AED1D7478D015CB479@esebe100.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: pekka.nikander@nomadiclab.com, 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 the shim6 meeting in Paris, Christian Huitema pointed out that >while we like to think that TCP & IP are separate layers, that's >not how people implement them. I think that any 'layer' between >transport & IP might be a separate layer on paper, but won't be >in implementation. well ... yes and no. When you talk about the design of algorithms and associated protocols, then our tools to transform the space to conceptually manageable proportions typically rely on partitioning - and in this case the layered protocol model serves as a useful partitioning tool in terms of where and how data structures are organized and where and how the procedures that work off these data structures are organised. From this perspective there are certain obvious differences between the data structures associated with a transport session and those associated with the IP layer, for example. From my perspective I would see the interactions with a stack as more akin to a vertical API conceptualization, again as an abstraction to help partition the overall space in a productive manner. Of course, yes these are conceptual models rather than implementation imperatives. But at times seeing the entire space without this form of conceptual structure just gets overwhemlingly confusing - at least it does for me! Geoff _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 11 02:59:31 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 1EaTop-0000fl-Ia; Fri, 11 Nov 2005 02:59:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaToo-0000fg-DA for architecture-discuss@megatron.ietf.org; Fri, 11 Nov 2005 02:59:30 -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 CAA21427 for ; Fri, 11 Nov 2005 02:59:02 -0500 (EST) Received: from [209.226.87.3] (helo=IPOfCard1.guest-tek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaU5A-0004ZC-Dj for Architecture-discuss@ietf.org; Fri, 11 Nov 2005 03:16:26 -0500 Received: from ken2-vmware.hongo.wide.ad.jp (localhost.localdomain [127.0.0.1]) by IPOfCard1.guest-tek.com (8.11.6/8.11.6) with ESMTP id jAB7xIi04783 for ; Fri, 11 Nov 2005 00:59:19 -0700 Received: from localhost (localhost [127.0.0.1]) by ken2-vmware.hongo.wide.ad.jp (8.12.11/8.12.11) with SMTP id jAB7xEmF002780; Thu, 10 Nov 2005 23:59:14 -0800 (PST) (envelope-from kengo@nagahashi.org) Date: Thu, 10 Nov 2005 23:59:13 -0800 From: Nagahashi Kengo To: rrg@psg.com, Architecture-discuss@ietf.org Message-Id: <20051110235913.4d72dcc8.kengo@nagahashi.org> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-unknown-freebsd4.10) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: Subject: [arch-d] routing and addressing hierarchy 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 Folks, Due to several suggestions(thanks Avri), I would post both lists. Background: we've presented crisp-wg about routing registry enabled crisp framework which is XML based query/responce protocol. A major discussing point is that routing registry is somewhat different with others; address and domain are already published as rfc. The reason is that address and domain perform clear hierarchy on the other hand, routing is not. we would really know this argument is true or not from the view point of architecture. cheers. -kengo _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 11 06:48: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 1EaXOd-000140-C5; Fri, 11 Nov 2005 06:48:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaXOb-00013Y-11 for architecture-discuss@megatron.ietf.org; Fri, 11 Nov 2005 06:48: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 GAA02845 for ; Fri, 11 Nov 2005 06:48:11 -0500 (EST) Received: from web31809.mail.mud.yahoo.com ([68.142.207.72]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EaXez-00020G-Jb for architecture-discuss@ietf.org; Fri, 11 Nov 2005 07:05:39 -0500 Received: (qmail 14615 invoked by uid 60001); 11 Nov 2005 11:48:30 -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=vnU/XIfcwC4Ko+Ey7aGfmeKD7AG7SxiFj3luV/ivyZD+F2qrfN4E8zQx1WuO3YAayV+UF3urr4uARH2aLFVVjgJZq8jCCGezswEsCinEEjgt9xJMXuEfv9ifdmJlYdfLbWU58no1SOXUZW6Id1OqAu5avJTYhIl55AQBax90hSg= ; Message-ID: <20051111114830.14613.qmail@web31809.mail.mud.yahoo.com> Received: from [68.48.216.32] by web31809.mail.mud.yahoo.com via HTTP; Fri, 11 Nov 2005 03:48:30 PST Date: Fri, 11 Nov 2005 03:48:30 -0800 (PST) From: David Barak Subject: RE: [arch-d] Mobility and multi-homing: Summary and going forward To: architecture-discuss@ietf.org In-Reply-To: <1AA39B75171A7144A73216AED1D7478D015CB479@esebe100.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 8bit 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 --- john.loughney@nokia.com wrote: > At the shim6 meeting in Paris, Christian Huitema > pointed out that > while we like to think that TCP & IP are separate > layers, that's > not how people implement them. I don't think I agree with this statement: there are a lot of protocols which ride on IP and not TCP, and the implementations don't have any "secret" TCP in the mix. Perhaps what he meant to say is that nobody implements TCP without IP - that's correct, but the converse isn't. > I think that any > 'layer' between > transport & IP might be a separate layer on paper, > but won't be > in implementation. If there was a benefit to the existence of the layer, you can reasonably expect that people will find a way to use it. However, it would need to really BE a discrete layer: one of the big problems (IMO) with IPv6 is the lack of respect for layer boundaries. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 11 07:17:26 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 1EaXqQ-0000pL-42; Fri, 11 Nov 2005 07:17:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaXqO-0000pF-G0 for architecture-discuss@megatron.ietf.org; Fri, 11 Nov 2005 07:17: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 HAA04937 for ; Fri, 11 Nov 2005 07:16:54 -0500 (EST) Received: from sokol.elan.net ([216.151.192.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaY6m-0002xb-VA for architecture-discuss@ietf.org; Fri, 11 Nov 2005 07:34:22 -0500 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id jABCHHxI008241; Fri, 11 Nov 2005 04:17:17 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id jABCHGCl008237; Fri, 11 Nov 2005 04:17:16 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Fri, 11 Nov 2005 04:17:16 -0800 (PST) From: "william(at)elan.net" To: David Barak Subject: RE: [arch-d] Mobility and multi-homing: Summary and going forward In-Reply-To: <20051111114830.14613.qmail@web31809.mail.mud.yahoo.com> Message-ID: References: <20051111114830.14613.qmail@web31809.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 Fri, 11 Nov 2005, David Barak wrote: >> I think that any 'layer' between transport & IP might be a separate >> layer on paper, but won't be in implementation. That really does not matter. If they have device that only does HTTP they may well implement both TCP/IP & HTTP in one unified code (in fact some people did if I'm not mistaken). > If there was a benefit to the existence of the layer, > you can reasonably expect that people will find a way > to use it. However, it would need to really BE a discrete layer: So what you're saying is that for adding new layer (as opposed to modifications or additional to either IP or TCP), there needs to be application that relies exclusively on this layer and builds up on top of it (i.e. OSPF vs BGP). This is a fair view and perhaps we need to look at how MIP, HIP, SHIM, etc feet into it. However even if separate application using layer is not immediatly found, layer-like separation may be still be good to have so new layer could be used very differently (or entirely bypassed) by upper layers in certain cases, for example I have still have hard time imagining how shim6 or hip could/would be used with multicasting. > one of the big problems (IMO) with > IPv6 is the lack of respect for layer boundaries. How so? What in IPv6 makes it so different layer-wise compared to IPv4? -- 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 Fri Nov 11 09:33:13 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 1EaZxp-0000oK-Db; Fri, 11 Nov 2005 09:33:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaZxo-0000o6-Dc for architecture-discuss@megatron.ietf.org; Fri, 11 Nov 2005 09:33:12 -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 JAA09238 for ; Fri, 11 Nov 2005 09:32:43 -0500 (EST) Received: from web31810.mail.mud.yahoo.com ([68.142.207.73]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EaaDp-0005Zb-JA for architecture-discuss@ietf.org; Fri, 11 Nov 2005 09:49:46 -0500 Received: (qmail 61527 invoked by uid 60001); 11 Nov 2005 14:32:36 -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=MFe1+LAYL+1hCVfHuvsJmeS1YmRv237XOVVofUFEqmfqLZywUOSNHIuZ4VLmCq40m696x2jrwaOmIHR9qNspdvXM/XrKwex+CCp8f4j00LAe+qEGzBQiPCpFpjPQfbbk4nfYyN73k7b/FD0npB/798EXqHXVftpjHJb1XaEB90o= ; Message-ID: <20051111143236.61523.qmail@web31810.mail.mud.yahoo.com> Received: from [68.48.216.32] by web31810.mail.mud.yahoo.com via HTTP; Fri, 11 Nov 2005 06:32:36 PST Date: Fri, 11 Nov 2005 06:32:36 -0800 (PST) From: David Barak Subject: RE: [arch-d] Mobility and multi-homing: Summary and going forward To: architecture-discuss@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 8bit 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 --- "william(at)elan.net" wrote: > > one of the big problems (IMO) with > > IPv6 is the lack of respect for layer boundaries. > > How so? What in IPv6 makes it so different > layer-wise compared to IPv4? The whole reason for a /64 being a "host" address is to incorporate MAC information into the IPv6 address: that bridges L2 and L3. IPv6 has absorbed several other protocols (DHCP, IPSec, GRE) in an attempt to be all things to all people. The whole Shim6 discussion boils down to using host-based rather than network-based failover mechanisa, and so a useful scaling property of the current Internet is lost (that hosts don't need routing information). I've long believed that strict separation of functions leads to greater long-term stability and flexibility - I'd like to be able to slip IPv6 into the protocol stack instead of v4, and still run the same upper-level stuff over it (that IS the layered model, after all...) David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com __________________________________ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 11 10:40: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 1Eab0i-0002Fq-A4; Fri, 11 Nov 2005 10:40:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eab0g-0002Fd-Rw for architecture-discuss@megatron.ietf.org; Fri, 11 Nov 2005 10:40: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 KAA13890 for ; Fri, 11 Nov 2005 10:39:45 -0500 (EST) Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EabH7-0000at-C6 for architecture-discuss@ietf.org; Fri, 11 Nov 2005 10:57:14 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id BC56C584; Fri, 11 Nov 2005 10:39:57 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 11 Nov 2005 10:39:57 -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] Mobility and multi-homing: Summary and going forward Date: Fri, 11 Nov 2005 10:39:56 -0500 Message-ID: <936A4045C332714F975800409DE09240014D9099@tayexc14.americas.cpqcorp.net> Thread-Topic: [arch-d] Mobility and multi-homing: Summary and going forward Thread-Index: AcXmgPXLNrAW/46lTQmOT7mWe89Y/AAAJcGQABT6YsA= From: "Bound, Jim" To: , X-OriginalArrivalTime: 11 Nov 2005 15:39:57.0565 (UTC) FILETIME=[2B697AD0:01C5E6D6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable Cc: pekka.nikander@nomadiclab.com, 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 =20 > At the shim6 meeting in Paris, Christian Huitema pointed out that > while we like to think that TCP & IP are separate layers, that's > not how people implement them. I think that any 'layer' between > transport & IP might be a separate layer on paper, but won't be > in implementation. I did not agree with this comment then nor do I now. I have implemented a lot of stacks and the transport is always called (referenced if you prefer) after the IP layer processing. The entire Internet reference protocol architecture are virtual layers. There is one even above the transport virtual layer and typically the interface to what is known as user space though that is evolving too. So if we are to speak of needing a new layer above IP but before transport processing then that will be a new virtual layer. Also realize that what we do not want to do is create a bottlneck making the middle virtual layers fat and slow either. /jim _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 11 11:02:55 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 1EabMd-0007AK-4V; Fri, 11 Nov 2005 11:02:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EabMb-00078j-CA for architecture-discuss@megatron.ietf.org; Fri, 11 Nov 2005 11:02: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 LAA15311 for ; Fri, 11 Nov 2005 11:02:24 -0500 (EST) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eabd1-0001XN-MZ for architecture-discuss@ietf.org; Fri, 11 Nov 2005 11:19:53 -0500 Received: from gihm3.apnic.net (kahuna.telstra.net [203.50.0.6]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id jABG2bXt033390; Sat, 12 Nov 2005 03:02:39 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20051112025741.02ac4ca0@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Sat, 12 Nov 2005 03:02:09 +1100 To: David Barak , architecture-discuss@ietf.org From: Geoff Huston Subject: RE: [arch-d] Mobility and multi-homing: Summary and going forward In-Reply-To: <20051111143236.61523.qmail@web31810.mail.mud.yahoo.com> References: <20051111143236.61523.qmail@web31810.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 >The whole Shim6 discussion boils down to using >host-based rather than network-based failover >mechanisa, and so a useful scaling property of the >current Internet is lost (that hosts don't need >routing information). I have to make the comment that this is not the case - shim6 exploits multiple router advertisements with multiple prefixes in order to gain host knowledge of available address prefixes, but does not rely on the propagation of routing information to individual hosts. I 'd gently suggest that you may want to read through the shim6 working drafts before advancing such perspectives on this particular approach to multi-homing and the more general area of advancing identity / locator semantic distinctions. regards, Geoff _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 11 12:41:12 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 1Eactk-0006up-1N; Fri, 11 Nov 2005 12:41:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eacti-0006uL-6F for architecture-discuss@megatron.ietf.org; Fri, 11 Nov 2005 12:41: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 MAA22665 for ; Fri, 11 Nov 2005 12:40:40 -0500 (EST) Received: from mint.apnic.net ([202.12.29.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EadAA-00063v-ID for Architecture-discuss@ietf.org; Fri, 11 Nov 2005 12:58:11 -0500 Received: from asmtp.apnic.net (pp104-240.bctel.ca [209.52.104.240]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id B566ED5F31; Sat, 12 Nov 2005 03:33:53 +1000 (EST) Date: Fri, 11 Nov 2005 17:40:12 +0000 From: George Michaelson To: Nagahashi Kengo Subject: Re: [arch-d] routing and addressing hierarchy Message-ID: <20051111174012.2732c491@garlique> In-Reply-To: <20051110235913.4d72dcc8.kengo@nagahashi.org> References: <20051110235913.4d72dcc8.kengo@nagahashi.org> X-Mailer: Sylpheed-Claws 1.9.100 (GTK+ 2.8.6; i386--netbsdelf) X-Fruit-Of-The-Month-Club: persimmon Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit Cc: Architecture-discuss@ietf.org, rrg@psg.com 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 Thu, 10 Nov 2005 23:59:13 -0800 Nagahashi Kengo wrote: > Folks, > > Due to several suggestions(thanks Avri), I would post both lists. > > Background: we've presented crisp-wg about routing registry > enabled crisp framework which is XML based query/responce protocol. > > A major discussing point is that routing registry > is somewhat different with others; address and domain > are already published as rfc. The reason is that > address and domain perform clear hierarchy on the other > hand, routing is not. > > we would really know this argument is true or not from > the view point of architecture. Nagahashi-San, my view is that this is not an Internet Architecture issue, this is an *organizational* issue: the ISPs do not show a desire to use a hierarchy of IRR to coordinate their route announces in registry form: they are happy with a loose mesh. So this is not an internet architecture issue, its about organization in the policy/operations space for the global routing community. I think there is *considerable* merit in having XML specification of the routing information, to permit XML tokenized data to be used by people and I wish to make sure people understand this is of wider benefit to the community. This is distinct from the operational, organizational aspects of your draft. If you separate these observations on national routing hierarchies, how to tier and inter-relate registries from the idea of having an XML representation of routing, I think that will be useful. Your community (the JP IRR working group) has been presenting on coordinated IRR at NANOG, and IETF, and regional RIR meetings for some time now, over 4 years to my knowledge. In that time, you have received much feedback from the north american and european community that they do NOT wish to see national, mandated registry schemes, or coordinated regional hierarchies: the operators do not wish to follow this model. I think you have to reflect on what this means for your proposals. If CRISP receives guidance from the AD that there is applicability for your work in our WG, I am sure we will accept it and work on it. cheers, and thankyou for bringing this into the wider discussion by your presentation at the plenary: I think this was a good thing to do. -George > > cheers. > > -kengo > > > > > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss > -- George Michaelson | APNIC Email: ggm@apnic.net | PO Box 2131 Milton Phone: +61 7 3858 3150 | QLD 4064 Australia Fax: +61 7 3858 3199 | http://www.apnic.net _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 11 23:17:49 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 1Eampp-00083F-C4; Fri, 11 Nov 2005 23:17:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eampn-000817-D2 for architecture-discuss@megatron.ietf.org; Fri, 11 Nov 2005 23:17:47 -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 XAA08830 for ; Fri, 11 Nov 2005 23:17:15 -0500 (EST) Received: from sa.vix.com ([204.152.187.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ean6F-0001hg-Kp for architecture-discuss@ietf.org; Fri, 11 Nov 2005 23:34:48 -0500 Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 4AB4411425 for ; Sat, 12 Nov 2005 04:17:08 +0000 (UTC) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: architecture-discuss@ietf.org Subject: Re: [arch-d] Mobility and multi-homing: Summary and going forward MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Date: Sat, 12 Nov 2005 04:17:08 +0000 Message-Id: <20051112041708.4AB4411425@sa.vix.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451 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 seems that a goodly portion of the historical record on this has been lost, or perhaps just not passed on by father to son. here are some of the comments i made when IPv6's original "rapid renumbering" requirement was thrown out as a way to make it more (cough) rapidly deployable. it gives me no pride or pleasure to have been right in my various predictions. i'm only sending these again so that those of you who weren't involved in 1996 can have some context as you unearth all these supposedly-dead issues. had we stuck with A6/DNAME, we'd be ~done by now. instead, we're ~starting ~over. (4 msgs) --=-=-= Content-Type: message/rfc822 Content-Disposition: attachment; filename=1730 Content-Description: forwarded message 1 To: namedroppers@ops.ietf.org Subject: Re: FW: AAAA/A6 In-Reply-To: Message from itojun@iijlab.net of "Thu, 22 Mar 2001 08:44:56 +0900." <16934.985218296@coconut.itojun.org> Date: Thu, 22 Mar 2001 05:58:39 -0800 From: Paul A Vixie X-Evolution: 0000009f-0000 MIME-Version: 1.0 A6 wasn't originated by the DNS community, it was a response to the IPv6 community's desire to push their rapid/continuous renumbering requirement into DNS rather than having to invent new support protocols in IPv6 itself. Therefore if the IPv6 community withdraws its rapid/continuous renumbering requirement then the DNS community will absolutely withdraw its A6 proposal. I do not consider this likely, and moreover, while I'm not a direct participant in the IPv6 community, I think that rapid/continuous renumbering is the only thing that makes IPv6 worth deploying. > - name server with good backend database > (in this case AAAA and A6 management costs are requal) For any given network this may or may not be the case. Sounds like for the IIJLab network it is the case. But I know of hundreds of networks for whom it is NOT the case (starting with most of PAIX's customers.) Good backend databases, or even... > - good perl script with AAAA (easy enough, deployable now) ...good perl scripts, are not universally applicable or scalable, and will not lead to transit-provider fluidity. Some of the stickiness of a network to its transit provider has to do with the cost of renumbering. And at the moment, multihoming is hellishly expensive since it requires portable address space which most networks don't have the resources to qualify for. > i believe our network is already large enough, and i'm happy with AAAA. in contrast, i believe that IPv6 is not worth its deployment cost, not even in a testbed, unless we deploy (or test) the rapid/continuous renumbering features. if you don't believe me, find a member of the GPRS community and ask *them*. or anyone in the mobile data community. or anyone whose network touches PAIX or Equinix or similar for the majority purpose of selecting their transit providers based on price and quality and without regard to renumbering cost. --=-=-= Content-Type: message/rfc822 Content-Disposition: attachment; filename=1731 Content-Description: forwarded message 2 Return-Path: owner-namedroppers@ops.ietf.org Delivery-Date: Sat Apr 28 13:54:09 2001 Received: from ground0.paix.net (ground0.paix.net [128.177.247.242]) by redpaul.mfnx.net (8.9.3/8.9.1) via ESMTP id NAA49401 for ; Sat, 28 Apr 2001 13:54:09 -0700 (PDT) env-from (owner-namedroppers@ops.ietf.org) Received: from isrv3.isc.org (isrv3-i.isc.org [204.152.184.87]) by ground0.paix.net (8.9.3/8.9.1) via ESMTP id NAA69543 for ; Sat, 28 Apr 2001 13:54:09 -0700 (PDT) env-from (owner-namedroppers@ops.ietf.org) Received: from psg.com (psg.com [147.28.0.62]) by isrv3.isc.org (8.11.2/8.9.1) via ESMTP id f3SKs2o01752; Sat, 28 Apr 2001 13:54:02 -0700 (PDT) env-from (owner-namedroppers@ops.ietf.org) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14tbTw-0009ht-00 for namedroppers-data@psg.com; Sat, 28 Apr 2001 13:38:20 -0700 Received: from [63.112.78.94] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14tbTt-0009hd-00 for namedroppers@ops.ietf.org; Sat, 28 Apr 2001 13:38:18 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 14tbTo-0000Fn-00 for namedroppers@ops.ietf.org; Sat, 28 Apr 2001 13:38:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii To: namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing References: <2604.988394701@brandenburg.cs.mu.OZ.AU> From: Paul Vixie Date: 28 Apr 2001 10:57:35 -0700 In-Reply-To: Robert Elz's message of "27 Apr 2001 23:42:07 -0700" Message-ID: Lines: 41 X-Mailer: Gnus v5.7/Emacs 20.4 X-DCC-MAPS-Metrics: ernie.mail-abuse.org 667; IP=148 env_From=131 From=107 Subject=25 Message-ID=6 Received=5 Body=5 Fuz1=5 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-Evolution: 000000a3-0000 Content-Transfer-Encoding: 7bit > Yes, there are a few A6 RR's out in the wild - but aside from demonstrating > that the world hasn't ended because of that, those don't prove much, > either way. Nor will proof of that kind be available without a lot more operational deployment. It sounds like you're not planning to wait for proof of that kind, but rather, get in a room with some like minded others and simply decide whether A6 is worth deploying or whether it really does suffer from all the woes which have been attributed to it and if so whether they add up to something fatal or not. Which means IPv6's "quick renumbering" requirement is back on the table. And since quick renumbering was used to sell the fast path IPv6 is on, I assume that we can now listen to Tony Li's "too little, too soon" complaint and just pull back from IPv6-as-specified and try to come up with something that's going to solve more of the problems we DO and WILL have, and fewer of the problems we MIGHT or COULD have? No? You mean that stuff isn't back on the table, and we're going ahead with IPv6 regardless of whether or not it has quick renumbering capabilities? If so, I will accuse the various directorates of "bait and switch" tactics used to ram their limited vision through various debates with no actual intent to follow through on any of their "campaign promises." Which would make this whole thing a lot like the RSA/DSA problem DNSSEC has. Are we still considering rearranging the IPv6 packet format to put destination address first? After all if the whole thing's still so experimental that we don't know what features it has or how we will deliver them, let's see the WHOLE laundry list. (I don't think IPv6 could stand that kind of scrutiny, but then, neither could IPv4 if it were proposed today.) Hint to whoever is in charge: the time to debate A6's merits at this level was: before it got put on the standards track, before a lot of code got written, and before a lot of operational deployment was put into various long and expensive pipelines. -- Paul Vixie President, PAIX.Net Inc. (MFNX.O) to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. --=-=-= Content-Type: message/rfc822 Content-Disposition: attachment; filename=1732 Content-Description: forwarded message 3 Return-Path: owner-namedroppers@ops.ietf.org Delivery-Date: Tue Aug 7 15:24:46 2001 Return-Path: Received: from isrv3.isc.org (isrv3.isc.org [204.152.184.30]) by as.vix.com (8.11.3/8.11.3) with ESMTP id f77MOkH69310 for ; Tue, 7 Aug 2001 15:24:46 -0700 (PDT) (envelope-from owner-namedroppers@ops.ietf.org) Received: from psg.com (psg.com [147.28.0.62]) by isrv3.isc.org (8.11.2/8.9.1) via ESMTP id f77MOi909089; Tue, 7 Aug 2001 15:24:44 -0700 (PDT) env-from (owner-namedroppers@ops.ietf.org) Received: from lserv by psg.com with local (Exim 3.31 #1) id 15UF8X-000E60-00 for namedroppers-data@psg.com; Tue, 07 Aug 2001 15:15:41 -0700 Received: from host217-33-136-119.ietf.ignite.net ([217.33.136.119] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.31 #1) id 15UF8W-000E5u-00 for namedroppers@ops.ietf.org; Tue, 07 Aug 2001 15:15:40 -0700 Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15UF8V-0000IA-00 for namedroppers@ops.ietf.org; Tue, 07 Aug 2001 23:15:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: <200108071748.f77HmHH64664@as.vix.com> To: Jun-ichiro itojun Hagino cc: Alexis Yushin , James Aldridge , Jim Bound , Matt Crawford , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: Message from Jun-ichiro itojun Hagino of "Wed, 08 Aug 2001 01:20:00 +0900." <20010807162000.AC56F7BA@starfruit.itojun.org> Date: Tue, 07 Aug 2001 10:48:17 -0700 From: Paul A Vixie Sender: owner-namedroppers@ops.ietf.org Precedence: bulk X-DCC-MAPS-Metrics: isrv3.isc.org 671; IP=486 env_From=485 From=many Subject=63 Message-ID=5 Received=5 Body=5 Fuz1=5 X-Evolution: 000000a8-0000 Content-Transfer-Encoding: 7bit > i have a major concern with AAAA synthesis - which is, it is unclear > as to who needs to AAAA synthesis. the concern is mentioned > in my draft. > > - you can't guarantee every first-hop DNS server to do AAAA synthesis. > - if anyone does not, AAAA queries go into non-first-hop DNS servers > by recurse (imagine when pre-BIND9/non-BIND name server is used > as the first-hop name server). > > therefore, AAAA synthesis basically asks everyone to run AAAA and A6 > in parallel, which raises a lot of concerns (query delays if you query > both, database maintenance cost if you maintain both in zone, no-sign > if you synthesize, and a lot of others). i would much rather deal with those problems, since they are solvable, then to deal with non-renumberable 128 bit addresses, since they simply lead to NAT. i cannot emphasize strongly enough that vast numbers of transit-consumers who lack the various powers needed to own portable address space will NOT deploy globally addressable IPv6 space if it simply means that they will become even more captive of their ipv6-transit providers than they are of their ipv4-transit providers today. the gprs and other mobile data providers are mostly going to be able to own portable address space so they don't care about this issue. but for "the enterprise" this is a real problem. if ipv6 is no easier to renumber than ipv4, then we're going to see large scale NAT. much larger scale NAT than we see today. being a captive customer of some transit provider when you only have an ipv4 /24 or even a /20 that you have to renumber if you change providers has difficulty N. being a captive customer of some transit provider when you have an ipv6 /64 to renumber if you change providers has difficulty N*(2^44). if NAT is used then the difficulty in either case is a constant, and for that matter, it's the same constant. so, "let's standardize both and let the market decide." but right now i'm hearing three camps trying to kill A6: implementors who consider bitstring, A6, and DNAME "too hard to do" transit providers who like the idea of captive ipv6 /64 customers transit customers who have enough power to own their own ipv6 blocks who in this mix is representing the interests of the average MIS manager? (and who do you think is going to drive the ipv6 economy, anyhow?) this debate borders on "simply unbelievable." to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. --=-=-= Content-Type: message/rfc822 Content-Disposition: attachment; filename=1733 Content-Description: forwarded message 4 From: Paul Vixie To: v6ops@ops.ietf.org Subject: Re: renumbering In-Reply-To: Message from Jun-ichiro itojun Hagino of "Wed, 18 Sep 2002 05:33:13 +0900." <20020917203313.99C317BA@starfruit.itojun.org> X-Mailer: mh-e 6.0; nmh 1.0.4; Emacs 21.2 Date: Tue, 17 Sep 2002 20:45:10 +0000 X-Evolution: 000000ab-0000 MIME-Version: 1.0 > i have renumbered my home (/48) more than a couple of times without > any problem. yes, it may not extend naturally to enterprise network > where # of nodes are 10^4, but anyway, > - IPv6 address autoconfiguration > - multiple IPv6 address per interface > - source/destination address selection > makes renumbering so much easier than IPv4 case. you just need to be > careful about DNS TTL and RA address/prefix lifetime. there's no question that it's easier than the ipv4 case. congrats are in order on that point. however, at size 10**4 and above, renumbering of this kind will be expensive. and at size 10**5 and above, it will be constant/overlapping. my point was, that's a big reason why folks will ask "why not just use NAT?" now i'm thinking, please don't make NAT any harder than it already is. --=-=-= 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 --=-=-=-- From architecture-discuss-bounces@ietf.org Sat Nov 12 15:58:21 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 1Eb2S5-0007n5-K1; Sat, 12 Nov 2005 15:58:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eb2S1-0007mc-Nr for architecture-discuss@megatron.ietf.org; Sat, 12 Nov 2005 15:58: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 PAA23719 for ; Sat, 12 Nov 2005 15:57:48 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eb2ih-0005GS-R1 for architecture-discuss@ietf.org; Sat, 12 Nov 2005 16:15:33 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 12 Nov 2005 12:58:07 -0800 X-IronPort-AV: i="3.97,322,1125903600"; d="scan'208"; a="229695636:sNHT22099936" Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jACKw0lq024623; Sat, 12 Nov 2005 12:58:01 -0800 (PST) Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id jACKw2n8002246; Sat, 12 Nov 2005 12:58:02 -0800 Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id jACKw0vk002242; Sat, 12 Nov 2005 12:58:00 -0800 Date: Sat, 12 Nov 2005 12:58:00 -0800 Message-Id: <200511122058.jACKw0vk002242@dino-lnx.cisco.com> From: Dino Farinacci To: Jim.Bound@hp.com In-reply-to: <936A4045C332714F975800409DE09240014D9099@tayexc14.americas.cpqcorp.net> (Jim.Bound@hp.com) Subject: Re: [arch-d] Mobility and multi-homing: Summary and going forward References: <936A4045C332714F975800409DE09240014D9099@tayexc14.americas.cpqcorp.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: architecture-discuss@ietf.org, pekka.nikander@nomadiclab.com 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 >> So if we are to speak of needing a new layer above IP but before >> transport processing then that will be a new virtual layer. >> >> Also realize that what we do not want to do is create a bottlneck making >> the middle virtual layers fat and slow either. In the spirit of modularity, you could implement the shim in one of the following OS process models (ignore kernel versus user space for now): (1) As a library called from the TCP/UDP process in both ingress and egress directions. (2) As a library called from the IP process in both ingress and egress directions. (3) As a separte process where on egress from TCP/UDP and ingress from IP, would use an IPC mechanism. As well as the separate shim process being an egress to both TCP/UDP and IP (for each packet direction). (4) A library which is shared by both the TCP/UDP and IP processes. It would be real nice if (3) could be avoided. And would be nice if the shim6 working group would decide if this is a transport function or an network layer function so (4) could be avoided. So what do people think, can this be implemented as (1) or (2)? Dino _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Nov 12 20:53:40 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 1Eb73s-0005WP-Nw; Sat, 12 Nov 2005 20:53:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eb73r-0005WF-2T for architecture-discuss@megatron.ietf.org; Sat, 12 Nov 2005 20:53:39 -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 UAA05386 for ; Sat, 12 Nov 2005 20:53:08 -0500 (EST) Received: from web31805.mail.mud.yahoo.com ([68.142.207.68]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Eb7KZ-00070R-KZ for architecture-discuss@ietf.org; Sat, 12 Nov 2005 21:10:57 -0500 Received: (qmail 14351 invoked by uid 60001); 13 Nov 2005 01:53:28 -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=VSXnfGpiYMgeXZqXpqwSfOfusSIGn6qNbTkxz3rkayoaZ0rpj6pnmLXxR+MIKpiKVte2sekdAsnbn1kZPDWv+2W3ZK1y+GyX7BLap1rQl5u6hBqrv+VD4DIVRiR52Mswq8ABG64gUCiQ8p2T+J5p7onPLi4Y0Fk+UtNwPmB4/kc= ; Message-ID: <20051113015328.14349.qmail@web31805.mail.mud.yahoo.com> Received: from [68.48.216.32] by web31805.mail.mud.yahoo.com via HTTP; Sat, 12 Nov 2005 17:53:28 PST Date: Sat, 12 Nov 2005 17:53:28 -0800 (PST) From: David Barak Subject: RE: [arch-d] Mobility and multi-homing: Summary and going forward To: Geoff Huston , architecture-discuss@ietf.org In-Reply-To: <6.2.0.14.2.20051112025741.02ac4ca0@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 8bit 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 --- Geoff Huston wrote: > > >The whole Shim6 discussion boils down to using > >host-based rather than network-based failover > >mechanisa, and so a useful scaling property of the > >current Internet is lost (that hosts don't need > >routing information). > > > I have to make the comment that this is not the > case - shim6 exploits > multiple router advertisements with multiple > prefixes in order to gain host > knowledge of available address prefixes, but does > not rely on the > propagation of routing information to individual > hosts. I 'd gently suggest > that you may want to read through the shim6 working > drafts before advancing > such perspectives on this particular approach to > multi-homing and the more > general area of advancing identity / locator > semantic distinctions. I re-read the drafts, and while "routing information" was not the proper choice of words, I stand by my assertion that Shim6 is a host-based, rather than network-based, failover mechanism. State information is maintained in a host to address network failures, rather than these events being transparent to the hosts, as they are currently. >From draft-ietf-shim6-applicability-00: "State information relating to the multi-homing of two endpoints exchanging unicast traffic is retained on the endpoints themselves, rather than in the network." In fact, looking at RFC 4177, pretty much all of the multi-homing options other than "routing" imply that hosts must maintain a significant amount of information about network state. That these approaches are more complex (for the host) than the current approaches is indisputable. Whether or not this complexity is worth it is a matter of opinion. I would assert that locational information belongs at layer 3 (and to a lesser/more limited extent, below that), while identity information should belong to higher layers. My original complaint was that too many functions were being crammed into IPv6, and that the benefits of the layered approach were being lost. -David Barak- -Fully RFC 1925 Compliant- __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Nov 12 22:41:47 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 1Eb8kV-0005z2-Ln; Sat, 12 Nov 2005 22:41:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eb8kV-0005yx-7e for architecture-discuss@megatron.ietf.org; Sat, 12 Nov 2005 22:41:47 -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 WAA09451 for ; Sat, 12 Nov 2005 22:41:17 -0500 (EST) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eb91F-0002HY-GB for architecture-discuss@ietf.org; Sat, 12 Nov 2005 22:59:06 -0500 Received: from gihm3.apnic.net (dhcp22.potaroo.net [203.10.60.22]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id jAD3faXt004135; Sun, 13 Nov 2005 14:41:36 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20051113143921.02e59838@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Sun, 13 Nov 2005 14:41:34 +1100 To: David Barak , architecture-discuss@ietf.org From: Geoff Huston Subject: RE: [arch-d] Mobility and multi-homing: Summary and going forward In-Reply-To: <20051113015328.14349.qmail@web31805.mail.mud.yahoo.com> References: <6.2.0.14.2.20051112025741.02ac4ca0@localhost> <20051113015328.14349.qmail@web31805.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 At 12:53 PM 13/11/2005, David Barak wrote: >--- Geoff Huston wrote: > > > > > >The whole Shim6 discussion boils down to using > > >host-based rather than network-based failover > > >mechanisa, and so a useful scaling property of the > > >current Internet is lost (that hosts don't need > > >routing information). > > > > > > I have to make the comment that this is not the > > case - shim6 exploits > > multiple router advertisements with multiple > > prefixes in order to gain host > > knowledge of available address prefixes, but does > > not rely on the > > propagation of routing information to individual > > hosts. I 'd gently suggest > > that you may want to read through the shim6 working > > drafts before advancing > > such perspectives on this particular approach to > > multi-homing and the more > > general area of advancing identity / locator > > semantic distinctions. > >I re-read the drafts, and while "routing information" >was not the proper choice of words, I stand by my >assertion that Shim6 is a host-based, rather than >network-based, failover mechanism. Absolutely! That's they way it was designed, coincidentally. :-) Regards, Geoff _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Nov 12 23:11: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 1Eb9DL-00043z-3Q; Sat, 12 Nov 2005 23:11:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eb9DJ-00043u-Ex for architecture-discuss@megatron.ietf.org; Sat, 12 Nov 2005 23:11:33 -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 XAA10690 for ; Sat, 12 Nov 2005 23:11:03 -0500 (EST) Received: from sokol.elan.net ([216.151.192.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eb9U3-0003Kl-3G for architecture-discuss@ietf.org; Sat, 12 Nov 2005 23:28:52 -0500 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id jAD4AgAH028446; Sat, 12 Nov 2005 20:10:42 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id jAD4Ag4p028443; Sat, 12 Nov 2005 20:10:42 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Sat, 12 Nov 2005 20:10:42 -0800 (PST) From: "william(at)elan.net" To: Geoff Huston Subject: RE: [arch-d] Mobility and multi-homing: Summary and going forward In-Reply-To: <6.2.0.14.2.20051113143921.02e59838@kahuna.telstra.net> Message-ID: References: <6.2.0.14.2.20051112025741.02ac4ca0@localhost> <20051113015328.14349.qmail@web31805.mail.mud.yahoo.com> <6.2.0.14.2.20051113143921.02e59838@kahuna.telstra.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 > Absolutely! That's they way it was designed, coincidentally. :-) Trouble is that IPv6 most interesting feature is that it can provide for large number of internet-connected hosts, that means number of hosts would increase quite a bit and so per-host multi-homing ends up being quite expensive to maintain. If any such type of multi-homing is to exist and be widely used (especially in enterprise and businesses) it would have to allow for easy network-wide setup & configuration and without a need to renumber when you change providers. So, I see the result of current effort is that those businesses would not actually do per-host multi-homing [even though that is what protocol would specify] but would use intermediate gateway device. All local hosts on their network instead of having global ipv6 address would use some type of shim6 host id and this network device would translate between those host ids and real IPv6 addresses as well as maintain proper dns configuration for such lan. Unless I'm mistaken such setup is called NAT! So the result is that you'd now have special protocol that would allow to use NAT not only for outgoing traffic load-balancing (current NAT gateways can already translate into more then one address pool) but also for incoming traffic multi-homing. So if you want to introduce and greatly increase use of NAT in IPv6 (as compared to IPv4), please by all means continue with shim6! -- 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 Sat Nov 12 23:25: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 1Eb9QL-000689-53; Sat, 12 Nov 2005 23:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eb9QK-00067z-AK for architecture-discuss@megatron.ietf.org; Sat, 12 Nov 2005 23:25: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 XAA11119 for ; Sat, 12 Nov 2005 23:24:30 -0500 (EST) Received: from sokol.elan.net ([216.151.192.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eb9h5-0003nI-6x for architecture-discuss@ietf.org; Sat, 12 Nov 2005 23:42:19 -0500 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id jAD4OtUU028564; Sat, 12 Nov 2005 20:24:55 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id jAD4OqOc028561; Sat, 12 Nov 2005 20:24:52 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Sat, 12 Nov 2005 20:24:52 -0800 (PST) From: "william(at)elan.net" To: Geoff Huston Subject: RE: [arch-d] Mobility and multi-homing: Summary and going forward In-Reply-To: Message-ID: References: <6.2.0.14.2.20051112025741.02ac4ca0@localhost> <20051113015328.14349.qmail@web31805.mail.mud.yahoo.com> <6.2.0.14.2.20051113143921.02e59838@kahuna.telstra.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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 Sat, 12 Nov 2005, william(at)elan.net wrote: > So, I see the result of current effort is that those businesses would > not actually do per-host multi-homing [even though that is what protocol > would specify] but would use intermediate gateway device. All local > hosts on their network instead of having global ipv6 address would use > some type of shim6 host id and this network device would translate > between those host ids and real IPv6 addresses as well as maintain > proper dns configuration for such lan. Unless I'm mistaken such > setup is called NAT! So the result is that you'd now have special > protocol that would allow to use NAT not only for outgoing traffic > load-balancing (current NAT gateways can already translate into more > then one address pool) but also for incoming traffic multi-homing. > > So if you want to introduce and greatly increase use of NAT in IPv6 > (as compared to IPv4), please by all means continue with shim6! BTW - I'm not at all saying such shim6 multi-homed NATed lan is bad idea (it may well be that wonderful application that makes ipv6 tick and useful to the point that everyone would quickly abandon v4 :), but this really would mean new layer for the Internet TCP/IP network and we better bet prepared and do proper architecture and modeling for such design. -- 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 Mon Nov 14 23:17:30 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 1EbsGA-0000hB-LF; Mon, 14 Nov 2005 23:17:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbsG8-0000h6-K8 for architecture-discuss@megatron.ietf.org; Mon, 14 Nov 2005 23:17: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 XAA27433 for ; Mon, 14 Nov 2005 23:16:55 -0500 (EST) Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbsXH-0004lS-8q for architecture-discuss@ietf.org; Mon, 14 Nov 2005 23:35:12 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id 2CC732F1; Mon, 14 Nov 2005 23:17:02 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 14 Nov 2005 23:17:02 -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] Mobility and multi-homing: Summary and going forward Date: Mon, 14 Nov 2005 23:17:00 -0500 Message-ID: <936A4045C332714F975800409DE0924001536F00@tayexc14.americas.cpqcorp.net> Thread-Topic: [arch-d] Mobility and multi-homing: Summary and going forward Thread-Index: AcXny88cMoabKdsVQR+MDF9pmULi3ABzvBlg From: "Bound, Jim" To: "Dino Farinacci" X-OriginalArrivalTime: 15 Nov 2005 04:17:02.0028 (UTC) FILETIME=[6DBDB8C0:01C5E99B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable Cc: architecture-discuss@ietf.org, pekka.nikander@nomadiclab.com 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 =20 > >> So if we are to speak of needing a new layer above IP but before > >> transport processing then that will be a new virtual layer. > >>=20 > >> Also realize that what we do not want to do is create a=20 > bottlneck making > >> the middle virtual layers fat and slow either. >=20 > In the spirit of modularity, you could implement the shim=20 > in one of the > following OS process models (ignore kernel versus user=20 > space for now): >=20 > (1) As a library called from the TCP/UDP process in both=20 > ingress and egress > directions. I think work will need to be done closer to IP thus just tcp/udp library will choke the transport for threading (trying to ignore kernel vs user space). >=20 > (2) As a library called from the IP process in both=20 > ingress and egress > directions. As much as I don't like the steve deering mid-life-bulge of the hour glass model I think this is most optimal. We could just write it in assembly instruction and go back to a real programming language :--). But open to more of this kind of good talk. >=20 > (3) As a separte process where on egress from TCP/UDP and=20 > ingress from IP, > would use an IPC mechanism. As well as the separate=20 > shim process being > an egress to both TCP/UDP and IP (for each packet direction). Ouch agree with Dino below. >=20 > (4) A library which is shared by both the TCP/UDP and IP=20 > processes. This will create major lock contention and/or additional data structures thus adding more space for a virtual layer and cannot see the time advantage for execution except in the most optimal case after set up. >=20 > It would be real nice if (3) could be avoided. And would=20 > be nice if > the shim6 working group would decide if this is a=20 > transport function or > an network layer function so (4) could be avoided. I agree this is work to be hard core nailed down in shim6 and with other comments above. >=20 > So what do people think, can this be implemented as (1) or (2)? Today I like 2. /jim >=20 > Dino > =20 > =20 >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Nov 14 23:42:12 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 1Ebse4-0008Uz-2j; Mon, 14 Nov 2005 23:42:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebse2-0008Up-FO for architecture-discuss@megatron.ietf.org; Mon, 14 Nov 2005 23:42: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 XAA28513 for ; Mon, 14 Nov 2005 23:41:37 -0500 (EST) Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbsvC-0005Og-Gw for architecture-discuss@ietf.org; Mon, 14 Nov 2005 23:59:55 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id D9017374; Mon, 14 Nov 2005 23:42:00 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 14 Nov 2005 23:42:00 -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] Mobility and multi-homing: Summary and going forward Date: Mon, 14 Nov 2005 23:41:59 -0500 Message-ID: <936A4045C332714F975800409DE0924001536F1A@tayexc14.americas.cpqcorp.net> Thread-Topic: [arch-d] Mobility and multi-homing: Summary and going forward Thread-Index: AcXny88cMoabKdsVQR+MDF9pmULi3ABzvBlgAAEAMiA= From: "Bound, Jim" To: "Bound, Jim" , "Dino Farinacci" X-OriginalArrivalTime: 15 Nov 2005 04:42:00.0737 (UTC) FILETIME=[EB0A9110:01C5E99E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: quoted-printable Cc: pekka.nikander@nomadiclab.com, 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 Correction below. I don't want to contribute to the mid-life-bulge of the hour glass. I actually believe totally in Steve's explanation of the hour glass model and affect. But I see no choice today. sorry, /jim=20 > -----Original Message----- > From: architecture-discuss-bounces@ietf.org=20 > [mailto:architecture-discuss-bounces@ietf.org] On Behalf Of Bound, Jim > Sent: Monday, November 14, 2005 11:17 PM > To: Dino Farinacci > Cc: architecture-discuss@ietf.org; pekka.nikander@nomadiclab.com > Subject: RE: [arch-d] Mobility and multi-homing: Summary and=20 > going forward >=20 > =20 > > >> So if we are to speak of needing a new layer above IP but before > > >> transport processing then that will be a new virtual layer. > > >>=20 > > >> Also realize that what we do not want to do is create a=20 > > bottlneck making > > >> the middle virtual layers fat and slow either. > >=20 > > In the spirit of modularity, you could implement the shim=20 > > in one of the > > following OS process models (ignore kernel versus user=20 > > space for now): > >=20 > > (1) As a library called from the TCP/UDP process in both=20 > > ingress and egress > > directions. >=20 > I think work will need to be done closer to IP thus just=20 > tcp/udp library > will choke the transport for threading (trying to ignore=20 > kernel vs user > space). >=20 > >=20 > > (2) As a library called from the IP process in both=20 > > ingress and egress > > directions. >=20 > As much as I don't like the steve deering mid-life-bulge of the hour > glass model I think this is most optimal. We could just write it in > assembly instruction and go back to a real programming language :--). > But open to more of this kind of good talk. >=20 > >=20 > > (3) As a separte process where on egress from TCP/UDP and=20 > > ingress from IP, > > would use an IPC mechanism. As well as the separate=20 > > shim process being > > an egress to both TCP/UDP and IP (for each packet=20 > direction). >=20 > Ouch agree with Dino below. >=20 > >=20 > > (4) A library which is shared by both the TCP/UDP and IP=20 > > processes. >=20 > This will create major lock contention and/or additional data=20 > structures > thus adding more space for a virtual layer and cannot see the time > advantage for execution except in the most optimal case after set up. >=20 > >=20 > > It would be real nice if (3) could be avoided. And would=20 > > be nice if > > the shim6 working group would decide if this is a=20 > > transport function or > > an network layer function so (4) could be avoided. >=20 > I agree this is work to be hard core nailed down in shim6 and=20 > with other > comments above. >=20 > >=20 > > So what do people think, can this be implemented as (1) or (2)? >=20 > Today I like 2. >=20 > /jim > >=20 > > Dino > > =20 > > =20 > >=20 >=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 Nov 15 00:31:03 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 1EbtPL-00071a-2O; Tue, 15 Nov 2005 00:31:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbtPK-0006zS-1N for architecture-discuss@megatron.ietf.org; Tue, 15 Nov 2005 00:31:02 -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 AAA00961 for ; Tue, 15 Nov 2005 00:30:28 -0500 (EST) Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbtgT-0006xH-GT for architecture-discuss@ietf.org; Tue, 15 Nov 2005 00:48:46 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id F2D9C393 for ; Tue, 15 Nov 2005 00:30:47 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 15 Nov 2005 00:30:47 -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, 15 Nov 2005 00:30:46 -0500 Message-ID: <936A4045C332714F975800409DE0924001536F27@tayexc14.americas.cpqcorp.net> Thread-Topic: NIC Offload Affect Thread-Index: AcXppbr2LFtTbQrAQkCN4Hyuw4Wasw== From: "Bound, Jim" To: X-OriginalArrivalTime: 15 Nov 2005 05:30:47.0859 (UTC) FILETIME=[BBBDF030:01C5E9A5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: quoted-printable Subject: [arch-d] NIC Offload Affect 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 If we should add new architecture components when thinking of implementation and time to market do we consider that NICs will offload the IP stack from current OS IP stacks for some use cases and already in process. I believe for 10GbE OS stacks can keep up but when 100GbE happens that will be different. Optimal IP stack code base has a different slant, and that can affect the deployment of any architecture too. Or it can be ignored? Just food for thought up in the sky looking down. /jim _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 15 00:45:49 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 1Ebtdd-00031A-H7; Tue, 15 Nov 2005 00:45:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebtdc-00030S-5F for architecture-discuss@megatron.ietf.org; Tue, 15 Nov 2005 00:45:48 -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 AAA01712 for ; Tue, 15 Nov 2005 00:45:15 -0500 (EST) Received: from sccrmhc14.comcast.net ([63.240.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ebtuk-0007Oi-1k for architecture-discuss@ietf.org; Tue, 15 Nov 2005 01:03:33 -0500 Received: from [192.168.0.2] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc14) with SMTP id <2005111505451901400ln5m6e>; Tue, 15 Nov 2005 05:45:25 +0000 In-Reply-To: <936A4045C332714F975800409DE0924001536F27@tayexc14.americas.cpqcorp.net> References: <936A4045C332714F975800409DE0924001536F27@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: <2A42E67A-D3EF-4FA9-A885-D4C3C9C36513@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [arch-d] NIC Offload Affect Date: Mon, 14 Nov 2005 21:45:18 -0800 To: "Bound, Jim" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) 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 > If we should add new architecture components when thinking of > implementation and time to market do we consider that NICs will > offload > the IP stack from current OS IP stacks for some use cases and > already in > process. I believe for 10GbE OS stacks can keep up but when 100GbE > happens that will be different. Optimal IP stack code base has a > different slant, and that can affect the deployment of any > architecture > too. Or it can be ignored? Just food for thought up in the sky > looking > down. In a distant previous life, I spent some time hacking the CMU TCP stack for VMS to work with a vendor's TCP accelerator board because everyone 'knew' that general purpose CPUs could never, ever keep up with 10Mb/s. ;-) While I'm painfully aware that general purpose silicon is reaching a technology asymptote, I would strongly suggest that we work hard to NOT optimize around a particular generation of technology and open ourselves to the thought that whatever we do, our grandchildren will have to implement the result on their latest and greatest Mr. Fusion powered, LOX cooled, hyper-processor. Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 15 12:00:57 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 1Ec4Az-0002IG-5h; Tue, 15 Nov 2005 12:00:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec4Ax-0002F7-F2 for architecture-discuss@megatron.ietf.org; Tue, 15 Nov 2005 12:00:55 -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 MAA08322 for ; Tue, 15 Nov 2005 12:00:20 -0500 (EST) Received: from e4.ny.us.ibm.com ([32.97.182.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec4SB-0002u8-2u for architecture-discuss@ietf.org; Tue, 15 Nov 2005 12:18:44 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id jAFH0cxt013628 for ; Tue, 15 Nov 2005 12:00:38 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jAFH0c4F102480 for ; Tue, 15 Nov 2005 12:00:38 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.13.3) with ESMTP id jAFH0b4o010582 for ; Tue, 15 Nov 2005 12:00:38 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-65-245-127.mts.ibm.com [9.65.245.127]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id jAFH0beO010507; Tue, 15 Nov 2005 12:00:37 -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 jAFH0ahc016315; Tue, 15 Nov 2005 12:00:36 -0500 Message-Id: <200511151700.jAFH0ahc016315@cichlid.raleigh.ibm.com> To: David Barak Subject: Re: [arch-d] Mobility and multi-homing: Summary and going forward In-Reply-To: Message from David Barak of "Fri, 11 Nov 2005 06:32:36 PST." <20051111143236.61523.qmail@web31810.mail.mud.yahoo.com> Date: Tue, 15 Nov 2005 12:00:36 -0500 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 David Barak writes: > The whole reason for a /64 being a "host" address is to incorporate > MAC information into the IPv6 address: that bridges L2 and L3. While true at one level, there is no architectural motivation here or any real bridging of L2 and L3. It just so happens that MAC addrs had desirable properties that stateless address autoconf needed. That is, the motivation was to allow direct inclusion of an IEEE EUI-64 Identifier into an address created via Stateless Addrconf. The assumption was that IEEE EUI-64 Identifiers would be a widely-available and globally unique. And indeed, there are L2 technologies today that include an IEEE identifier, but don't use them as link-layer addrs. Stateless addr conf assumes that the Interface Identifier part of the address will be unique with high probability so that it doesn't have to worry (much) about creating duplicate addresses. Hence, it only detects (via DAD) duplicate addreses and makes no attempt to generate alternative addresses in the case of a duplicate. I might agree with your assertion if IPv6 did away with ND and simply extracted the L2 address from an IPv6 address when doing address resolution. But that is not done. > IPv6 has absorbed several other protocols (DHCP, IPSec, GRE) in an > attempt to be all things to all people. Um, this is a hard one to swallow. DHCP is not "absorbed" by IPv6. It's pretty much standalone, just like in IPv4. And last I checked, IPSec is pretty much the same in IPv4 and IPv6 (modulo differences in address size). Finally, remind me, what part of IPv6 uses (much less mandates) the use of GRE? Thomas _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 15 12:08:36 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 1Ec4IO-0004zU-22; Tue, 15 Nov 2005 12:08:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec4IM-0004yT-53 for architecture-discuss@megatron.ietf.org; Tue, 15 Nov 2005 12:08: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 MAA09508 for ; Tue, 15 Nov 2005 12:08:00 -0500 (EST) Received: from e32.co.us.ibm.com ([32.97.110.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ec4ZQ-0003P4-Oi for architecture-discuss@ietf.org; Tue, 15 Nov 2005 12:26:13 -0500 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id jAFH8AiK007123 for ; Tue, 15 Nov 2005 12:08:10 -0500 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jAFH7w7i052142 for ; Tue, 15 Nov 2005 10:07:58 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id jAFH8Ami004957 for ; Tue, 15 Nov 2005 10:08:10 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-65-245-127.mts.ibm.com [9.65.245.127]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id jAFH89JP004903; Tue, 15 Nov 2005 10:08:09 -0700 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 jAFH845h016378; Tue, 15 Nov 2005 12:08:08 -0500 Message-Id: <200511151708.jAFH845h016378@cichlid.raleigh.ibm.com> To: Paul Vixie Subject: Re: [arch-d] Mobility and multi-homing: Summary and going forward In-Reply-To: Message from Paul Vixie of "Sat, 12 Nov 2005 04:17:08 GMT." <20051112041708.4AB4411425@sa.vix.com> Date: Tue, 15 Nov 2005 12:08:04 -0500 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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 Paul. > it seems that a goodly portion of the historical record on this has > been lost, or perhaps just not passed on by father to son. here are > some of the comments i made when IPv6's original "rapid renumbering" > requirement was thrown out as a way to make it more (cough) rapidly > deployable. You've made this assertion before. But if we're going to talk about the historical record, can you remind me of where the "rapid renumbering" requirement actually comes from, and who actually made it? RFC 1752 (The Recommendation for the IP Next Generation Protocol) doesn't seem to list it as a requirement. Does IPv6 make renumbering easier? Almost certainly. Does it make it trivial or painless? Certainly not. How much easier is renumbering in IPv6 compared to IPv4? Hard to say, since we have little experience. Moreover, the pain of renumbering certainly varies depending on what it is you are renumbering. I'd say that renumbering end hosts is easier in IPv6 than IPv4. But just how much is a tad subjective... Is it easier to renumber the network infrastructure in IPv6, e.g., routers? This is less clear. I'd again say yes, because being able to run both an old and new prefix in parallel while transitioning works better in IPv6 than IPv4. (Having IP stacks support multiple addresses is something that IPv6 certainly does better archtecturally -- it's designed in - compared with IPv4, where its support is ad-hoc and not uniform.) But certainly it's not free or painless, and there are few automated tools for renumbering an IPv6 infrastructure, at least not yet. > it gives me no pride or pleasure to have been right in my various > predictions. i'm only sending these again so that those of you who > weren't involved in 1996 can have some context as you unearth all > these supposedly-dead issues. had we stuck with A6/DNAME, we'd be > ~done by now. instead, we're ~starting ~over. If you are suggesting that all that is needed to make renumbering easy in IPv6 as something like A6/DNAME, I disagree. While having A6/DNAME might help some, it is by no means sufficient. The hard part of renumbering is not the DNS, but actually renumbering the infrastructure and getting everyone to stop using the old addresses in favor of the new ones. I don't know of any way to do that "rapidly". Sure, getting applications to switch to new addresses is something the DNS can help with, but unless you want to break caching (by using very short RR TTLs) the idea of doing a "rapid update" in DNS is a non-starter. And once you've accepted that renumbering is not an instantaneous event, but involves an overlap/transition period where both the old and new addresses work for a period of days or weeks, the need for A6 becomes much less apparent. IIRC, one of the original arguments for why A6 wasn't really that compelling was that at least some of its benefits could be achieved via better DNS config file tools. For example, allowing AAAA RRs to be specified as being composed of components (rather than a complete address), one of which was the network prefix would simplify the task of updating config files, in that updating the DNS when renumbering would consist of just updating a single prefix as opposed to updating every AAAA entry via global substitute. Thomas _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 16 10:59:49 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 1EcPhN-0000rz-BW; Wed, 16 Nov 2005 10:59:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcPhL-0000qx-Qk for architecture-discuss@megatron.ietf.org; Wed, 16 Nov 2005 10:59:47 -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 KAA05868 for ; Wed, 16 Nov 2005 10:59:14 -0500 (EST) Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcPyn-0006P4-79 for architecture-discuss@ietf.org; Wed, 16 Nov 2005 11:17:50 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id B278A200031F for ; Wed, 16 Nov 2005 10:59:33 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Nov 2005 10:59: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: Wed, 16 Nov 2005 10:59:21 -0500 Message-ID: <936A4045C332714F975800409DE09240015375A3@tayexc14.americas.cpqcorp.net> Thread-Topic: GENI Project and NSF Barriers Ontology Thread-Index: AcXqxrUP91NwASW3RpWX07UA3UW7fQ== From: "Bound, Jim" To: X-OriginalArrivalTime: 16 Nov 2005 15:59:22.0352 (UTC) FILETIME=[B5BE9F00:01C5EAC6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: quoted-printable Subject: [arch-d] GENI Project and NSF Barriers Ontology 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 Should we be talking with or getting participation from the GENI project (one key member is Dave Clark) as input to architecture discussion, and the analysis done by NSF on current Barriers to network evolution. Note this is being discussed in other technical forums besides the IETF concerned with the Internet for future deployment and NGNs. At some point we may want to consider liaison relationships with those other forums. /jim _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 16 11:07:09 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 1EcPoT-0004wU-OE; Wed, 16 Nov 2005 11: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 1EcPoS-0004wN-DJ for architecture-discuss@megatron.ietf.org; Wed, 16 Nov 2005 11: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 LAA06449 for ; Wed, 16 Nov 2005 11:06:33 -0500 (EST) Received: from tracy.its.yale.edu ([130.132.252.242]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcQ5s-0006iG-Dz for architecture-discuss@ietf.org; Wed, 16 Nov 2005 11:25:09 -0500 Received: from tracy.its.yale.edu (tracy.its.yale.edu [127.0.0.1]) by tracy.its.yale.edu (8.13.1/8.13.1) with ESMTP id jAGG6Uui006950; Wed, 16 Nov 2005 11:06:30 -0500 Received: from localhost (jgeorge@localhost) by tracy.its.yale.edu (8.13.1/8.13.1/Submit) with ESMTP id jAGG6UMl006947; Wed, 16 Nov 2005 11:06:30 -0500 X-Authentication-Warning: tracy.its.yale.edu: jgeorge owned process doing -bs Date: Wed, 16 Nov 2005 11:06:30 -0500 (EST) From: Jeremy George X-X-Sender: jgeorge@tracy.its.yale.edu To: "Bound, Jim" Subject: Re: [arch-d] GENI Project and NSF Barriers Ontology In-Reply-To: <936A4045C332714F975800409DE09240015375A3@tayexc14.americas.cpqcorp.net> Message-ID: References: <936A4045C332714F975800409DE09240015375A3@tayexc14.americas.cpqcorp.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 Reply-To: Jeremy George 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 In this regard a suggestion from a lurker is the final technical report of the DARPA NewArch project available here: http://www.isi.edu/newarch/ - Jeremy On Wed, 16 Nov 2005, Bound, Jim wrote: > Date: Wed, 16 Nov 2005 10:59:21 -0500 > From: "Bound, Jim" > To: architecture-discuss@ietf.org > Subject: [arch-d] GENI Project and NSF Barriers Ontology > > Should we be talking with or getting participation from the GENI project > (one key member is Dave Clark) as input to architecture discussion, and > the analysis done by NSF on current Barriers to network evolution. Note > this is being discussed in other technical forums besides the IETF > concerned with the Internet for future deployment and NGNs. At some > point we may want to consider liaison relationships with those other > forums. > > /jim > > _______________________________________________ > 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 Nov 18 14:09:02 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 1EdBba-00027W-3R; Fri, 18 Nov 2005 14:09:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdBbY-00027O-9n for architecture-discuss@megatron.ietf.org; Fri, 18 Nov 2005 14:09: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 OAA04866 for ; Fri, 18 Nov 2005 14:08:25 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdBtR-0000sc-0C for architecture-discuss@ietf.org; Fri, 18 Nov 2005 14:27:30 -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 jAIJ7hE29785; Fri, 18 Nov 2005 11:07:43 -0800 (PST) Message-ID: <437E2680.1030400@isi.edu> Date: Fri, 18 Nov 2005 11:07:44 -0800 From: Joe Touch User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: architecture-discuss@ietf.org Subject: Re: [arch-d] GENI Project and NSF Barriers Ontology References: <936A4045C332714F975800409DE09240015375A3@tayexc14.americas.cpqcorp.net> In-Reply-To: <936A4045C332714F975800409DE09240015375A3@tayexc14.americas.cpqcorp.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: e5ba305d0e64821bf3d8bc5d3bb07228 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bound, Jim wrote: > Should we be talking with or getting participation from the GENI project > (one key member is Dave Clark) as input to architecture discussion, and > the analysis done by NSF on current Barriers to network evolution. Neither FIND nor GENI are projects. FIND (Future Internet Design) is one of four components of the upcoming NeTS program call for proposals (due end Nov), and is aimed at architecture research. GENI is a large, proposed testbed initiative program on which to test architectures, not an architecture research effort per se. In both cases, analysis was done by individuals who are probably already lurking on this list. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDfiaAE5f5cImnZrsRAoO2AJ9ikfwDUThgxJlXtz94vBMDGN7z+gCg8USB BjbRBAI+dH6RqzagrlbZL7I= =nASc -----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 Fri Nov 18 14:49:02 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 1EdCEH-0001aP-V0; Fri, 18 Nov 2005 14:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdCEG-0001X1-7W for architecture-discuss@megatron.ietf.org; Fri, 18 Nov 2005 14:49: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 OAA06771 for ; Fri, 18 Nov 2005 14:48:24 -0500 (EST) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdCW9-0001oC-Db for architecture-discuss@ietf.org; Fri, 18 Nov 2005 15:07:30 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EdCE1-0001Oo-KN; Fri, 18 Nov 2005 11:48:46 -0800 Message-Id: <6.2.3.4.2.20051118203918.052f0730@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Fri, 18 Nov 2005 20:48:26 +0100 To: Joe Touch , architecture-discuss@ietf.org From: "JFC (Jefsey) Morfin" Subject: Re: [arch-d] GENI Project and NSF Barriers Ontology In-Reply-To: <437E2680.1030400@isi.edu> References: <936A4045C332714F975800409DE09240015375A3@tayexc14.americas.cpqcorp.net> <437E2680.1030400@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: 1ac7cc0a4cd376402b85bc1961a86ac2 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 At 20:07 18/11/2005, Joe Touch wrote: >Neither FIND nor GENI are projects. > >FIND (Future Internet Design) is one of four components of the upcoming >NeTS program call for proposals (due end Nov), and is aimed at >architecture research. Joe, could you please provide an URL where this NeTS program is authoritatively decribed? 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 Fri Nov 18 16:09:11 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 1EdDTr-0001pa-9p; Fri, 18 Nov 2005 16:09:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdDTp-0001pV-IF for architecture-discuss@megatron.ietf.org; Fri, 18 Nov 2005 16:09:09 -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 QAA10805 for ; Fri, 18 Nov 2005 16:08:33 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdDlj-0003y4-98 for architecture-discuss@ietf.org; Fri, 18 Nov 2005 16:27:40 -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 jAIL85E05626; Fri, 18 Nov 2005 13:08:05 -0800 (PST) Message-ID: <437E42B7.1050202@isi.edu> Date: Fri, 18 Nov 2005 13:08:07 -0800 From: Joe Touch User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "JFC (Jefsey) Morfin" Subject: Re: [arch-d] GENI Project and NSF Barriers Ontology References: <936A4045C332714F975800409DE09240015375A3@tayexc14.americas.cpqcorp.net> <437E2680.1030400@isi.edu> <6.2.3.4.2.20051118203918.052f0730@mail.jefsey.com> In-Reply-To: <6.2.3.4.2.20051118203918.052f0730@mail.jefsey.com> 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.3 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 NeTS: http://www.nsf.gov/funding/pgm_summ.jsp?pims_id=12765 (FIND is inside NeTS) - ---- GENI: http://www.nsf.gov/cise/geni/ Joe JFC (Jefsey) Morfin wrote: > At 20:07 18/11/2005, Joe Touch wrote: > >> Neither FIND nor GENI are projects. >> >> FIND (Future Internet Design) is one of four components of the upcoming >> NeTS program call for proposals (due end Nov), and is aimed at >> architecture research. > > > Joe, > could you please provide an URL where this NeTS program is > authoritatively decribed? > thank you. > jfc > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDfkK2E5f5cImnZrsRAsO4AKCdQUmJZO/yL5AGfw3E8oyPkZk6uwCg5A4l Vy46vm2dZgVSA6rX6nqJRkM= =EBHI -----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 Fri Nov 18 19:43:20 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 1EdGp6-0002HH-6R; Fri, 18 Nov 2005 19:43:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdGp4-0002HC-PS for architecture-discuss@megatron.ietf.org; Fri, 18 Nov 2005 19:43: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 TAA25043 for ; Fri, 18 Nov 2005 19:42:43 -0500 (EST) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdH6y-0001yy-Ja for architecture-discuss@ietf.org; Fri, 18 Nov 2005 20:01:51 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EdGos-0004LH-5F; Fri, 18 Nov 2005 16:43:06 -0800 Message-Id: <6.2.3.4.2.20051119011353.051b1780@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Sat, 19 Nov 2005 01:42:58 +0100 To: Joe Touch From: "JFC (Jefsey) Morfin" Subject: Re: [arch-d] GENI Project and NSF Barriers Ontology In-Reply-To: <437E42B7.1050202@isi.edu> References: <936A4045C332714F975800409DE09240015375A3@tayexc14.americas.cpqcorp.net> <437E2680.1030400@isi.edu> <6.2.3.4.2.20051118203918.052f0730@mail.jefsey.com> <437E42B7.1050202@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: 7655788c23eb79e336f5f8ba8bce7906 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 22:08 18/11/2005, Joe Touch wrote: >NeTS: >http://www.nsf.gov/funding/pgm_summ.jsp?pims_id=12765 >(FIND is inside NeTS) > >GENI: >http://www.nsf.gov/cise/geni/ Thank you. Such projects are US oriented. There also are European, Chinese, etc. projects. Plus the ITU. Plus now the open use efforts which may result from direct responses to the IGF's demands. How do you see the IAB and IETF in this context? How would this fit with RFC 3935 wich relates the IETF to the current Internet and to its core values, which are a mix of ethic and technical orientations other projects do not refer to. For example, do you think that we should investigate an evolution of the current architecture or a new architecture and then the transition? all the best jfc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 22 17:58: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 1Eeh5x-0004SF-2k; Tue, 22 Nov 2005 17:58:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eeh5w-0004SA-A8 for architecture-discuss@megatron.ietf.org; Tue, 22 Nov 2005 17:58: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 RAA24777 for ; Tue, 22 Nov 2005 17:57:57 -0500 (EST) Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EehOe-0002Dk-VJ for architecture-discuss@ietf.org; Tue, 22 Nov 2005 18:17:58 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jAMMwT85005503; Wed, 23 Nov 2005 00:58:30 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Nov 2005 00:58:25 +0200 Received: from [172.19.69.51] ([172.19.69.51]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 23 Nov 2005 00:58:25 +0200 In-Reply-To: <2A42E67A-D3EF-4FA9-A885-D4C3C9C36513@tony.li> References: <936A4045C332714F975800409DE0924001536F27@tayexc14.americas.cpqcorp.net> <2A42E67A-D3EF-4FA9-A885-D4C3C9C36513@tony.li> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6C47BFE2-76CD-40AA-B349-A72C9C0FCBFE@nokia.com> Content-Transfer-Encoding: 7bit From: Bob Hinden Subject: Re: [arch-d] NIC Offload Affect Date: Tue, 22 Nov 2005 14:58:36 -0800 To: Tony Li X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 22 Nov 2005 22:58:25.0819 (UTC) FILETIME=[3EE5B6B0:01C5EFB8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 > In a distant previous life, I spent some time hacking the CMU TCP > stack for > VMS to work with a vendor's TCP accelerator board because everyone > 'knew' > that general purpose CPUs could never, ever keep up with 10Mb/s. ;-) > > While I'm painfully aware that general purpose silicon is reaching > a technology > asymptote, I would strongly suggest that we work hard to NOT > optimize around > a particular generation of technology and open ourselves to the > thought that > whatever we do, our grandchildren will have to implement the result > on their > latest and greatest Mr. Fusion powered, LOX cooled, hyper-processor. I agree. Further, from one of my previous lives, the bottleneck was efficiently moving the data to user space, not the actual protocol processing. Moving the protocol processing outboard tends to make this harder as it moves the control further away from where it is needed. Bob _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Nov 22 20:16:56 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 1Eej9q-0004G6-1n; Tue, 22 Nov 2005 20:10:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eej9n-0004Bu-8y for architecture-discuss@megatron.ietf.org; Tue, 22 Nov 2005 20:10: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 UAA11651 for ; Tue, 22 Nov 2005 20:10:03 -0500 (EST) Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EejSX-0002Kb-8t for architecture-discuss@ietf.org; Tue, 22 Nov 2005 20:30:06 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 61DAD3417C; Tue, 22 Nov 2005 20:10:33 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 22 Nov 2005 20:10:31 -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] NIC Offload Affect Date: Tue, 22 Nov 2005 20:10:30 -0500 Message-ID: <936A4045C332714F975800409DE0924001616CE9@tayexc14.americas.cpqcorp.net> Thread-Topic: [arch-d] NIC Offload Affect Thread-Index: AcXvuHAaOErEbI51R9OG6p5T1/gYjQAEYE/A From: "Bound, Jim" To: "Bob Hinden" , "Tony Li" X-OriginalArrivalTime: 23 Nov 2005 01:10:31.0666 (UTC) FILETIME=[B311FD20:01C5EFCA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 just so all know I threw this out for thought only. I have many views on this topic and also there are new models being developed to improve host ip stack kernel processing avoidance of copy and placing data directly 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. /jim > -----Original Message----- > From: architecture-discuss-bounces@ietf.org=20 > [mailto:architecture-discuss-bounces@ietf.org] On Behalf Of Bob Hinden > Sent: Tuesday, November 22, 2005 5:59 PM > To: Tony Li > Cc: architecture-discuss@ietf.org > Subject: Re: [arch-d] NIC Offload Affect >=20 >=20 > > In a distant previous life, I spent some time hacking the CMU TCP =20 > > stack for > > VMS to work with a vendor's TCP accelerator board because everyone =20 > > 'knew' > > that general purpose CPUs could never, ever keep up with=20 > 10Mb/s. ;-) > > > > While I'm painfully aware that general purpose silicon is reaching =20 > > a technology > > asymptote, I would strongly suggest that we work hard to NOT =20 > > optimize around > > a particular generation of technology and open ourselves to the =20 > > thought that > > whatever we do, our grandchildren will have to implement=20 > the result =20 > > on their > > latest and greatest Mr. Fusion powered, LOX cooled, hyper-processor. >=20 > I agree. >=20 > Further, from one of my previous lives, the bottleneck was =20 > efficiently moving the data to user space, not the actual protocol =20 > processing. Moving the protocol processing outboard tends to make =20 > this harder as it moves the control further away from where it is =20 > needed. >=20 > Bob >=20 >=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 Nov 22 21:39:49 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 1EekY1-0002PG-II; Tue, 22 Nov 2005 21:39:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EekXz-0002OG-Je for architecture-discuss@megatron.ietf.org; Tue, 22 Nov 2005 21:39:48 -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 VAA25908 for ; Tue, 22 Nov 2005 21:39:07 -0500 (EST) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eekqh-000085-H9 for architecture-discuss@ietf.org; Tue, 22 Nov 2005 21:59:12 -0500 Received: from [192.168.0.3] (adsl-71-131-27-1.dsl.sntc01.pacbell.net [71.131.27.1]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id jAN2dvSE011090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Nov 2005 18:39:57 -0800 Message-ID: <4383D652.1070503@dcrocker.net> Date: Tue, 22 Nov 2005 18:39:14 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 1.4 (Windows/20050908) MIME-Version: 1.0 To: "Bound, Jim" Subject: Re: [arch-d] NIC Offload Affect References: <936A4045C332714F975800409DE0924001616CE9@tayexc14.americas.cpqcorp.net> In-Reply-To: <936A4045C332714F975800409DE0924001616CE9@tayexc14.americas.cpqcorp.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: dhc@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net 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 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. Bob H's comments about memory processing vs. protocol processing is a good example. Have there been serious host processing efficiency proposals that purport to do better? I suspect the issue with a shim layer is going to be per-packet additional overhead, versus per "host-pair" or "per-session" or the like. Are there specific problems already expected? d/ -- Dave Crocker Brandenburg InternetWorking _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 23 12:33: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 1EeyUP-0005LR-5E; Wed, 23 Nov 2005 12:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeyUL-0005Ki-FC for architecture-discuss@megatron.ietf.org; Wed, 23 Nov 2005 12:32:59 -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 MAA01292 for ; Wed, 23 Nov 2005 12:32:18 -0500 (EST) Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeynE-0007mA-8a for architecture-discuss@ietf.org; Wed, 23 Nov 2005 12:52:29 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id E170434064; Wed, 23 Nov 2005 13:14:52 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Nov 2005 12:32:43 -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] NIC Offload Affect Date: Wed, 23 Nov 2005 12:32:41 -0500 Message-ID: <936A4045C332714F975800409DE0924001616ED8@tayexc14.americas.cpqcorp.net> Thread-Topic: [arch-d] NIC Offload Affect Thread-Index: AcXv1ySzM0O91+UsT426Ttrsl3ytCAAe/NpA From: "Bound, Jim" To: X-OriginalArrivalTime: 23 Nov 2005 17:32:43.0089 (UTC) FILETIME=[E8EF8410:01C5F053] X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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 yes there is work in research area and I just sent mail about one that may be interesting here being prepared for IEEE but not sure its in the public domain yet. will come back on that. Just in case I agree with Tony we don't want to limit our ideas/views/vision because of IP stacks or any implementation but just keep it in mind. I think considering shim affect is important not saying it should be precluded. another emerging use of the architecture will be ad hoc nets for example radios don't have time to do congestion control between each other "today" because of energy capability. also on bob's model our RDMA group is dealing with some of that currently and how IO and memory can be optimized by architecture decisions is important I think to the vision equation if we can develop such an equation. /jim=20 > -----Original Message----- > From: Dave Crocker [mailto:dhc@dcrocker.net]=20 > Sent: Tuesday, November 22, 2005 9:39 PM > To: Bound, Jim > Cc: Bob Hinden; Tony Li; architecture-discuss@ietf.org > Subject: Re: [arch-d] NIC Offload Affect >=20 >=20 >=20 >=20 > > 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=20 > layers and new > > processing that has to be called out from the stack that=20 > has performance > > cost. Keeping the deering hourglass and the middle not bulging is I > > think very important. >=20 > I suspect that the on-/off-board question merely makes it=20 > easier to think of=20 > issues to focus on. So it's not so much that it creates=20 > special problems,=20 > but perhaps it gets us thinking about thinks with some better focus. >=20 > Bob H's comments about memory processing vs. protocol=20 > processing is a good=20 > example. Have there been serious host processing efficiency=20 > proposals that=20 > purport to do better? >=20 > I suspect the issue with a shim layer is going to be=20 > per-packet additional=20 > overhead, versus per "host-pair" or "per-session" or the like. >=20 > Are there specific problems already expected? >=20 > d/ > --=20 >=20 > Dave Crocker > Brandenburg InternetWorking > >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 25 03:58:52 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 1EfZPv-0001mN-Ut; Fri, 25 Nov 2005 03:58:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfZPu-0001lN-4a for architecture-discuss@megatron.ietf.org; Fri, 25 Nov 2005 03:58:50 -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 DAA28293 for ; Fri, 25 Nov 2005 03:58:07 -0500 (EST) Received: from mtagate3.uk.ibm.com ([195.212.29.136]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfZix-0005KW-LT for architecture-discuss@ietf.org; Fri, 25 Nov 2005 04:18:40 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate3.uk.ibm.com (8.12.10/8.12.10) with ESMTP id jAP8wgbf262930 for ; Fri, 25 Nov 2005 08:58:44 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jAP8wAa1163004 for ; Fri, 25 Nov 2005 08:58:10 GMT Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id jAP8w8WW030818 for ; Fri, 25 Nov 2005 08:58:09 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av02.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id jAP8w82b030797; Fri, 25 Nov 2005 08:58:08 GMT Received: from zurich.ibm.com (sig-9-146-217-123.de.ibm.com [9.146.217.123]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA78696; Fri, 25 Nov 2005 09:58:07 +0100 Message-ID: <4386D21D.4030507@zurich.ibm.com> Date: Fri, 25 Nov 2005 09:58:05 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Geoff Huston Subject: Re: [arch-d] Mobility and multi-homing: Summary and going forward References: <6.2.0.14.2.20051112025741.02ac4ca0@localhost> <20051113015328.14349.qmail@web31805.mail.mud.yahoo.com> <6.2.0.14.2.20051113143921.02e59838@kahuna.telstra.net> In-Reply-To: <6.2.0.14.2.20051113143921.02e59838@kahuna.telstra.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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 Catching up late... Geoff Huston wrote: > At 12:53 PM 13/11/2005, David Barak wrote: ... >> I re-read the drafts, and while "routing information" >> was not the proper choice of words, I stand by my >> assertion that Shim6 is a host-based, rather than >> network-based, failover mechanism. > > > > Absolutely! That's they way it was designed, coincidentally. :-) Indeed, and it was designed to *not* need routing information. But as has been discussed in recent weeks on shim6, an entirely possible complement to basic shim6 is to have the routing system appropriately update address selection preferences in hosts - that is how shim6 can be made to respond to routing changes, without needing any knowledge of routing. Dino Farinacci wrote: ... > > (3) As a separte process where on egress from TCP/UDP and ingress from IP, > would use an IPC mechanism. As well as the separate shim process being > an egress to both TCP/UDP and IP (for each packet direction). > > (4) A library which is shared by both the TCP/UDP and IP processes. > > It would be real nice if (3) could be avoided. And would be nice if > the shim6 working group would decide if this is a transport function or > an network layer function so (4) could be avoided. The shim by construction preserves the upper layer identifier (a.k.a. address) used by the transport protocol, so there is no doubt that it's below transport. OTOH I do expect there will be an enhanced API whereby a transport that needs to can interact with the shim; SCTP needs that for sure. But that is not case (4) and doesn't require case (3). I see no reason why the shim can't be in line with IP packet processing. Brian _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 25 04:07:45 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 1EfZYX-0005JB-0l; Fri, 25 Nov 2005 04: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 1EfZYV-0005IA-NK for architecture-discuss@megatron.ietf.org; Fri, 25 Nov 2005 04: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 EAA28957 for ; Fri, 25 Nov 2005 04:07:02 -0500 (EST) Received: from mtagate3.uk.ibm.com ([195.212.29.136]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfZrj-0005cC-5B for Architecture-discuss@ietf.org; Fri, 25 Nov 2005 04:27:36 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate3.uk.ibm.com (8.12.10/8.12.10) with ESMTP id jAP97Mbf222562 for ; Fri, 25 Nov 2005 09:07:25 GMT Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jAP96oa1165024 for ; Fri, 25 Nov 2005 09:06:50 GMT Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id jAP96o0r032470 for ; Fri, 25 Nov 2005 09:06:50 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id jAP96nwn032455; Fri, 25 Nov 2005 09:06:49 GMT Received: from zurich.ibm.com (sig-9-146-217-123.de.ibm.com [9.146.217.123]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA49376; Fri, 25 Nov 2005 10:06:47 +0100 Message-ID: <4386D426.8000401@zurich.ibm.com> Date: Fri, 25 Nov 2005 10:06:46 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Nagahashi Kengo Subject: Re: [arch-d] routing and addressing hierarchy References: <20051110235913.4d72dcc8.kengo@nagahashi.org> In-Reply-To: <20051110235913.4d72dcc8.kengo@nagahashi.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: Architecture-discuss@ietf.org, rrg@psg.com 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 Nagahashi Kengo wrote: > Folks, > > Due to several suggestions(thanks Avri), I would post both lists. > > Background: we've presented crisp-wg about routing registry > enabled crisp framework which is XML based query/responce protocol. > > A major discussing point is that routing registry > is somewhat different with others; address and domain > are already published as rfc. The reason is that > address and domain perform clear hierarchy on the other > hand, routing is not. > > we would really know this argument is true or not from > the view point of architecture. It seems to me that until some dramatic breakthrough occurs in routing theory, by definition the global (BGP) routing information is flat and not hierarchical. That doesn't mean it can't be represented in XML; but it will look different. I assume you are aware of RFC 2622. Brian _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Nov 25 05:42:30 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 1Efb2E-0008Va-S8; Fri, 25 Nov 2005 05:42:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efb2C-0008VT-3L for architecture-discuss@megatron.ietf.org; Fri, 25 Nov 2005 05:42:30 -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 FAA08936 for ; Fri, 25 Nov 2005 05:41:46 -0500 (EST) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfbLL-0000hZ-Gz for Architecture-discuss@ietf.org; Fri, 25 Nov 2005 06:02:18 -0500 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1Efb1p-0005v4-5l; Fri, 25 Nov 2005 02:42:05 -0800 Message-Id: <6.2.3.4.2.20051125113853.04ba57e0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Fri, 25 Nov 2005 11:42:00 +0100 To: Brian E Carpenter , Nagahashi Kengo From: "JFC (Jefsey) Morfin" Subject: Re: [arch-d] routing and addressing hierarchy In-Reply-To: <4386D426.8000401@zurich.ibm.com> References: <20051110235913.4d72dcc8.kengo@nagahashi.org> <4386D426.8000401@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Architecture-discuss@ietf.org, rrg@psg.com 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 10:06 25/11/2005, Brian E Carpenter wrote: >Nagahashi Kengo wrote: >>Folks, >>Due to several suggestions(thanks Avri), I would post both lists. >>Background: we've presented crisp-wg about routing registry enabled >>crisp framework which is XML based query/responce protocol. >>A major discussing point is that routing registry >>is somewhat different with others; address and domain >>are already published as rfc. The reason is that >>address and domain perform clear hierarchy on the other >>hand, routing is not. >>we would really know this argument is true or not from >>the view point of architecture. > >It seems to me that until some dramatic breakthrough occurs in >routing theory, I understand the purpose of this very list is to discuss such very breakthroughs. I am not excited about XML except for study and demoing. Do you have an URL on your work? jfc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Nov 30 15:12:44 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 1EhYJo-0007ng-MZ; Wed, 30 Nov 2005 15:12:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhYJn-0007nV-IN for architecture-discuss@megatron.ietf.org; Wed, 30 Nov 2005 15:12: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 PAA06867 for ; Wed, 30 Nov 2005 15:11:56 -0500 (EST) Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhYe7-0001F4-NB for architecture-discuss@ietf.org; Wed, 30 Nov 2005 15:33:44 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id E6E27342C0 for ; Wed, 30 Nov 2005 15:12:28 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 30 Nov 2005 15:12:29 -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] NIC Offload Affect Date: Wed, 30 Nov 2005 15:12:28 -0500 Message-ID: <936A4045C332714F975800409DE092400168818B@tayexc14.americas.cpqcorp.net> Thread-Topic: RE: [arch-d] NIC Offload Affect Thread-Index: AcXv1ySzM0O91+UsT426Ttrsl3ytCAAe9X9QAAhrJDAAEa09AADsjBKwAAowJ+AAUqcfEAABnfmw From: "Bound, Jim" To: X-OriginalArrivalTime: 30 Nov 2005 20:12:29.0622 (UTC) FILETIME=[63D89D60:01C5F5EA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable 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 Folks, per request from Dave Crocker, over week ago, as example alternative to hardware NIC offload. I just had to verify paper was public it is now. Evaluating Network Processing Efficiency with Processor Partitioning and Asynchronous I/O Tim Brechtz, G. (John) Janakiraman, Brian Lynnx, Vikram Saletore, and Yoshio Turner (Hewlett Packard Laboratories, Intel Corporation, and University of Waterloo) http://www.hpl.hp.com/research/dca/system/papers/hpl-2005-211.pdf /jim =20 =20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss