From architecture-discuss-bounces@ietf.org Fri Dec 01 00:31:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq0z9-0003gs-Lk; Fri, 01 Dec 2006 00:30:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq0z8-0003gb-3q for architecture-discuss@ietf.org; Fri, 01 Dec 2006 00:30:54 -0500 Received: from outbound-mail.lax.untd.com ([64.136.28.164]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gq0z6-0002lu-ME for architecture-discuss@ietf.org; Fri, 01 Dec 2006 00:30:54 -0500 Received: from webmail40.lax.untd.com (webmail40.lax.untd.com [10.131.27.180]) by smtpout06.lax.untd.com with SMTP id AABCY9RQ4A2NTJQ2 for (sender ); Thu, 30 Nov 2006 21:30:02 -0800 (PST) X-UNTD-OriginStamp: AcganUYbgVGZ0C6nm/9IPatablCmMCeK0dM53ELczdMbn+kBzMMV0g== Received: (from fergdawg@netzero.net) by webmail40.lax.untd.com (jqueuemail) id L8GWU7DY; Thu, 30 Nov 2006 21:29:16 PST Received: from [24.23.201.115] by webmail40.lax.untd.com with HTTP: Fri, 1 Dec 2006 05:28:27 GMT X-Originating-IP: [24.23.201.115] Mime-Version: 1.0 From: "Fergie" Date: Fri, 1 Dec 2006 05:28:27 GMT To: jnc@mercury.lcs.mit.edu Subject: Re: [arch-d] Some notes about HIP and SHIM6 (was Re: On identifiers: w hat is virtual and what...) X-Mailer: Webmail Version 4.0 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain Message-Id: <20061130.212916.19739.1583840@webmail40.lax.untd.com> X-ContentStamp: 15:7:1242669328 X-MAIL-INFO: 14d995a818dc95dcdcb5d9f85948014949ede1f94928995939759d355cadad95c531d1a8 X-UNTD-Peer-Info: 10.131.27.180|webmail40.lax.untd.com|webmail40.lax.untd.com|fergdawg@netzero.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- jnc@mercury.lcs.mit.edu (Noel Chiappa) wrote: >Yes and no, I think - but I kind of phased out on the finer details of = HIP >and SHIM6, so the following comments may not be accurate, and I'd >appreciate any corrections to possibly mistaken impressions. > >My impression is that although to an initial glance (if you consider a = few >"how do I do thing X" cases) they do look like they provide similar >capabilities (as you point out), I think that perhaps at a deeper level= >HIP is more powerful, architecturally. The reason is simple: HIP brings= an >extra namespace to bear, and at an architectural level that's very >powerful. [snip] Not meaning to sound facetious or anything, but I wonder if we happen to be using the term "overloaded" a little too liberally to have a useful dialogue? What is overloaded? I mean, Noe, we all have used that term in many, many instances and perhaps it is time we revisit what what that might actually mean. I know I would certainly benefit form that discussion -- first and foremost -- before we launch into where "jacking up" and GSE (for example) may dissect/cross the issue(s) of overloading the terms of "routing" and "addressing" w.r.t v6. The reason I mention this at all is that this happens to be the topic at hand. :-) I'll leave my personal opinion(s) out of it for the moment, only so that we can at least agree on terminology(ies). Cheers, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.1 (Build 1557) wj8DBQFFb71eq1pz9mNUZTMRAsM0AJ9fnuhjqwRlpWUQQddvO90SzfaHXgCggT3F WJ8zzi3fg4292X6eAtsqsGY=3D =3Djj0L -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/ _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Dec 01 03:38:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq3tM-0002Dv-Ab; Fri, 01 Dec 2006 03:37:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq3tK-0002Dm-U2 for architecture-discuss@ietf.org; Fri, 01 Dec 2006 03:37:06 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gq3tJ-0002TW-6a for architecture-discuss@ietf.org; Fri, 01 Dec 2006 03:37:06 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 3C5CA213048; Fri, 1 Dec 2006 10:36:55 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 036C8212FD0; Fri, 1 Dec 2006 10:36:55 +0200 (EET) In-Reply-To: <20061201043954.24BBC86AFF@mercury.lcs.mit.edu> References: <20061201043954.24BBC86AFF@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [arch-d] Some notes about HIP and SHIM6 (was Re: On identifiers: what is virtual and what...) Date: Fri, 1 Dec 2006 10:36:52 +0200 To: Noel Chiappa , Geoff Huston X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Geoff, Noel, and all, When I was saying that SHIM6 is a watered down version of HIP, I was mostly speaking from an architectural and long-term point of view. I'm trying to clarify that below, replying to your messages. Geoff Huston spoke wisely: > My personal view is that there is a significant difference between > a host-level approach and a transport session level approach that > you seem to have missed in your note. I find myself in strong > disagreement with your perspective of SHIM6 as some kind of diluted > or compromised version of HIP. I can easily understand your point of view and appreciate that you disagree with me, though I don't quite understand what you mean with a "host-level" vs. "transport session level" approach. Would you care to clarify? However, overall, I think that perhaps we could agree to disagree here, hopefully understanding that we looking at these two artefacts (HIP and SHIM6) from very different points of view. There *are* differences between HIP and SHIM6. Some of the differences appear very significant from a short-term operational point of view. If I understand you correctly (please correct if I'm reading you wrong), that's what you consider most important. Indeed, from that point of view SHIM6 can really be considered as a better- engineered protocol (and not a watered down version), since it addresses some operational aspects that HIPpers are just slowly copying from SHIM6, and, perhaps most importantly, SHIM6 does not mandate any changes into the DNS data or require any new infrastructure while HIP does. However, my point of view was and still is architectural and long- term. From that point of view, I stand behind my words. I can try to explain my point even more rigourously if needed, but I said already most of what I wanted to say in http://www1.ietf.org/mail- archive/web/architecture-discuss/current/msg00837.html > Frankly, [...], there is much involved here. To expect any > particular approach to get it all right first time is asking too > much. HIP and SHIM6 are examples of trying to understand what these > concepts look like in code and in protocol stacks. They bed down > these otherwise abstract discussions with some experience with > implementation and the harsh realities of deployment in the network. I couldn't agree more. > For you that may well be band aid. I'm calling it band aid since it is all relatively short-term to me. I once thought that HIP would be a long-term solution, but no longer do. I think that proves your point above: you cannot get all right the first time. :-) > For me its part of the scientific investigatory process of devising > an hypothesis, and then testing this hypothesis, and then looking > very hard to make sure that the hypothesis remains intact. Yes, indeed! Any ideas need to be tested. With HIP we are getting there now, hopefully, and I've understood that the first SHIM6 implementations are getting ready as well. > As far as I can see, we [...] still have much to learn here. That's the whole point of having this discussion, at least to me. To learn what I'm missing and understanding badly, and also slowly learning to see the things with other people's eyes. Yes, I know I appear sometimes quite arrogant and perhaps even elitist. My apologies for that. One reason behind is my still- persisting frustration... --- Andrew McGregor once wrote: >> .. what HIP and SHIM6 both give you is the ability to assert that >> something accessible at location A is also accessible at locations B >> through ... >> .. but the core of what the protocols provide is very similar. On 1 Dec 2006, at 06:39, Noel Chiappa wrote: > Yes and no, I think - but I kind of phased out on the finer details > of HIP and SHIM6, so the following comments may not be accurate, > and I'd appreciate any corrections to possibly mistaken impressions. > > My impression is that although to an initial glance (if you > consider a few "how do I do thing X" cases) they do look like they > provide similar capabilities (as you point out), I think that > perhaps at a deeper level HIP is more powerful, architecturally. > The reason is simple: HIP brings an extra namespace to bear, and at > an architectural level that's very powerful. From the 10000 feet point of view, I think that is exactly right. HIP was designed with a new name space very much in mind, from the beginning. SHIM6 started from functional requirements, and the a new name space was not there, rather the reverse. However, with the introduction of CGA-based SHIM6 ULIDs, you can kind- of retrofit a new name space into SHIM6. I have to admit not having read the latest versions of the specs, but my impression is that the value of such possibility is still not appreciated and there's been relatively little thought about that. But I may be wrong. Hence, while in theory HIP is architecturally more powerful due to the new name space, in reality you apparently can do the same things with SHIM6. Perhaps not that elegantly than with HIP (that is, if HIP can be considered elegant :-), but still. > Also, SHIM6 overloads one more meaning onto an existing namespace > (IPv6 addresses), and, architecturally speaking, that's always > bad. Yes, yes, I know, the idea is that there will be two separate > namespaces that just happen > to share a syntax. But so does HIP with its backwards compatibility mode. That's the whole point with the ORCHID draft: to allow existing applications to work unmodified, by overloading the IPv6 syntax. > However... we all know that anytime there is the possibility of > kludging something (in this case, by treating a name from sub-space > A as if it were a name from sub-space B), someone somewhere will do > it, as a "quick hack" to solve some problem they have, and then > you're in the soup. Only with a complete separate namespace is > there no possibility of hacks that entangle (and strangle) a design. Indeed. However, in this particular case I think that the value of backwards compatibility may exceed the drawbacks. In any case, there is also an attempt to define a new API that could be used with any shim-like approach, including SHIM6 and HIP. So, to summarise, at the grass roots level HIP and SHIM6 are closer to each other today than many people may think or would like to admit. I think that is quite natural: implementation wise, the differences are relatively small, at least if you implement also CGAs for SHIM6. For example, it looks like that the first SHIM6 implementations will be based on existing HIP ones. --Pekka Nikander _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Dec 01 04:40:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq4qQ-0003sT-4j; Fri, 01 Dec 2006 04:38:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq4qP-0003sC-FC for architecture-discuss@ietf.org; Fri, 01 Dec 2006 04:38:09 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gq4qN-0004LX-VG for architecture-discuss@ietf.org; Fri, 01 Dec 2006 04:38:09 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id AE311213048 for ; Fri, 1 Dec 2006 11:37:59 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 7665A212FD0 for ; Fri, 1 Dec 2006 11:37:59 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: architecture-discuss@ietf.org From: Pekka Nikander Date: Fri, 1 Dec 2006 11:37:56 +0200 X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Subject: [arch-d] A straw man analysis of why send-receive packet paradigm is unsustainable X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org [This is _really_ long term. If you are not interested in 10+ years things, don't bother reading.] It is a well established view that smart ends and a dumb, open, neutral network are good, for a number of well-known reasons. Herein I present a claim that if we want to retain that approach, we will have to give up the current send-receive packet paradigm, sooner or later. While there are ample experimental evidence for my claim, I will skip that and focus on a techno-economic analysis. The current Internet is based on what I call the send-receive packet paradigm. That is, the fundamental primitives in the network are "send" and "receive", on the packet level. More importantly, what is built in into this paradigm is the idea that anyone can send anything to anybody, and the network will do its best to get that through. While that is very simple and well known, let me dissect it a little bit: 1. The paradigm implies that any packet sent is delivered, or at least tried to get delivered. 2. The paradigm implies that the sender is free to select the receiver. Sender's consent. 3. The paradigm implies that the receiver need to process, at least minimally, any traffic sent to it by any sender. Of those, the last one appears to be the most important one. Think about it! The fundamental reason why I claim, below, that the current paradigm is unsustainable, in the longer run, is the following: Sending packets is cheaper than receiving and processing them I think that the claim could probably be based on physics, entropy, and energy, but I won't go into that; I'm not an expert there. Instead, let's consider two well known examples: spam and DDoS. Sending spam costs the sender relatively little, even if they are not using zombie farms. They basically create a single message, and send it repeatedly, often even allowing the network to replicate it. Receiving, on the other hand, is expensive. The receiver must decide, somehow, whether the received message is spam and should be ignored, or not. To make the decision, quite a lot of processing is needed, if not by the machines, then by the user. In a DDoS attack, sending is even cheaper to the attacker due to utilising zombie farms. The receiver pays heavily, both on legitimate traffic lost due to congestion and on even minimally processing those attack packets that actually reach the attacked system. More importantly, however, if we consider the packet level we can see the same pattern as in the spam case. The attacker doesn't need to spend much energy in generating packet contents; in many cases the packets can contain whatever garbage. On the other hand, the receiver needs to spend at least some energy in deciding whether the received packet is legitimate or not. That leads to the following corollary: Receiving packets is expensive because of the associated decision process Note that it is possible to send mindlessly, without needing to make any decisions at the packet level. The malicious send can make all the decisions in advance. The implication is clear: The original, open, neutral end-to-end network based on the send-receive packet paradigm is unsustainable in the face of large amounts of malicious players. Note that this is fundamental. It is impossible to allow anyone to send any packets to anyone, without some people being able to abuse it in a way or another. Conversely, if we want to also in the more distant future have a network that is built on the core values of the original Internet, we need to give up its fundamental technical foundation, the send-receive packet paradigm. I think what's above is enough for a single message. I'll leave the wider implications and options for action to another message. --Pekka Nikander _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Dec 01 05:32:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq5fk-0003yn-Mx; Fri, 01 Dec 2006 05:31:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq5fJ-0003Hy-7n for architecture-discuss@ietf.org; Fri, 01 Dec 2006 05:30:45 -0500 Received: from [203.167.203.10] (helo=enso.acheron.indranet.co.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gq5fH-0004xl-KM for architecture-discuss@ietf.org; Fri, 01 Dec 2006 05:30:45 -0500 Received: from [127.0.0.1] (IDENT:root@enso.acheron.indranet.co.nz [192.168.1.1]) by enso.acheron.indranet.co.nz (8.9.3-20030919/8.9.3) with ESMTP id XAA29918; Fri, 1 Dec 2006 23:30:40 +1300 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <40A1808B-29A6-4F94-BC6B-84F1F64DD156@indranet.co.nz> Content-Transfer-Encoding: 7bit From: Andrew McGregor Subject: Re: [arch-d] A straw man analysis of why send-receive packet paradigm is unsustainable Date: Fri, 1 Dec 2006 23:31:33 +1300 To: Pekka Nikander X-Mailer: Apple Mail (2.752.2) 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: , Errors-To: architecture-discuss-bounces@ietf.org On 01/12/2006, at 10:37 PM, Pekka Nikander wrote: > The fundamental reason why I claim, below, that the current > paradigm is unsustainable, in the longer run, is the following: > > Sending packets is cheaper than receiving and processing them > > I think that the claim could probably be based on physics, entropy, > and energy, but I won't go into that; I'm not an expert there. It's a very simple argument: Transmission of a packet *increases* the entropy of the network. Reception *decreases* the entropy of the network. The second law of thermodynamics (the same one that prohibits perpetual motion machines) guarantees that the latter operation is more expensive than the former. TANSTAAFL. Practical considerations imply that the actual cost of reception is many times higher than in transmission; in wireless systems, it can be millions of times higher. QED. Andrew _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Dec 01 05:37:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq5kB-00078B-8n; Fri, 01 Dec 2006 05:35:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq5kA-000784-51 for architecture-discuss@ietf.org; Fri, 01 Dec 2006 05:35:46 -0500 Received: from [131.228.20.170] (helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gq5k8-0006k7-MX for architecture-discuss@ietf.org; Fri, 01 Dec 2006 05:35:46 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id kB1AZ1Nc027783; Fri, 1 Dec 2006 12:35:38 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 12:35:24 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 12:35:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] A straw man analysis of why send-receive packet paradigmis unsustainable Date: Fri, 1 Dec 2006 12:35:22 +0200 Message-ID: In-Reply-To: <40A1808B-29A6-4F94-BC6B-84F1F64DD156@indranet.co.nz> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] A straw man analysis of why send-receive packet paradigmis unsustainable Thread-Index: AccVM+8f4SSBqqhwTiW/zAbHTDyuBwAAGESQ From: To: , X-OriginalArrivalTime: 01 Dec 2006 10:35:22.0484 (UTC) FILETIME=[67A72B40:01C71534] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Andrew=20 >Practical considerations imply that the actual cost of=20 >reception is many times higher than in transmission; in=20 >wireless systems, it can be millions of times higher. Actually, with some wireless radios, transmiting is more expensive (from a power consumption point of view) than receiving. John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Dec 01 05:39:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq5mE-00087t-Bc; Fri, 01 Dec 2006 05:37:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq5mC-00087N-S9 for architecture-discuss@ietf.org; Fri, 01 Dec 2006 05:37:52 -0500 Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gq5mB-0007AC-EQ for architecture-discuss@ietf.org; Fri, 01 Dec 2006 05:37:52 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.13.8/8.13.8) with ESMTP id kB1AbmOS047564 for ; Fri, 1 Dec 2006 10:37:48 GMT Received: from d12av01.megacenter.de.ibm.com (d12av01.megacenter.de.ibm.com [9.149.165.212]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kB1AblCo2736250 for ; Fri, 1 Dec 2006 11:37:47 +0100 Received: from d12av01.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av01.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kB1AblN4012025 for ; Fri, 1 Dec 2006 11:37:47 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av01.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kB1AbkbC011992; Fri, 1 Dec 2006 11:37:46 +0100 Received: from zurich.ibm.com ([9.4.210.199]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA122448; Fri, 1 Dec 2006 11:37:45 +0100 Message-ID: <457005FB.3080104@zurich.ibm.com> Date: Fri, 01 Dec 2006 11:37:47 +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: Noel Chiappa Subject: Re: [arch-d] Some notes about HIP and SHIM6 (was Re: On identifiers: what is virtual and what...) References: <20061201043954.24BBC86AFF@mercury.lcs.mit.edu> In-Reply-To: <20061201043954.24BBC86AFF@mercury.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > Also, SHIM6 overloads one more meaning onto an existing namespace (IPv6 > addresses), I think of it a little differently. SHIM6 recognizes the fact that IP addresses are already viewed from "above" as stack identifiers and from "below" as stack locators. It makes use of that existing overloading to decouple the two views. > and, architecturally speaking, that's always bad. Yes, yes, I > know, the idea is that there will be two separate namespaces that just happen > to share a syntax. Well, SHIM6 really preserves a single namespace but treats it as having two surfaces. > However... we all know that anytime there is the > possibility of kludging something (in this case, by treating a name from > sub-space A as if it were a name from sub-space B), someone somewhere will do > it, as a "quick hack" to solve some problem they have, and then you're in the > soup. Only with a complete separate namespace is there no possibility of > hacks that entangle (and strangle) a design. Correct. But the problem we have is the existing upper layer legacy, which I believe is much harder to change than we Layer 3 geeks tend to believe. So we come up with things like SHIM6 or ORCHID (draft-laganier-ipv6-khi). Brian _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Dec 01 08:51:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq8mI-0006te-AR; Fri, 01 Dec 2006 08:50:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq8mG-0006oJ-9E for architecture-discuss@ietf.org; Fri, 01 Dec 2006 08:50:08 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gq8mC-0003KH-MK for architecture-discuss@ietf.org; Fri, 01 Dec 2006 08:50:08 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 01 Dec 2006 05:50:04 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id kB1Do3wL007269; Fri, 1 Dec 2006 05:50:03 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kB1DnhP3012209; Fri, 1 Dec 2006 05:49:59 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 08:49:57 -0500 Received: from [10.86.240.29] ([10.86.240.29]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 08:49:56 -0500 Message-ID: <45703339.1000804@employees.org> Date: Fri, 01 Dec 2006 08:50:49 -0500 From: Scott W Brim Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.8) Gecko/20061025 Thunderbird/1.5.0.8 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Pekka Nikander Subject: Re: [arch-d] A straw man analysis of why send-receive packet paradigm is unsustainable References: In-Reply-To: X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Dec 2006 13:49:56.0944 (UTC) FILETIME=[962C6500:01C7154F] Authentication-Results: sj-dkim-8; header.From=swb@employees.org; dkim=neutral X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On 12/01/2006 04:37 AM, Pekka Nikander wrote: > Receiving packets is expensive because of the associated decision > process ... > The implication is clear: The original, open, neutral end-to-end > network based on the send-receive packet paradigm is unsustainable in > the face of large amounts of malicious players. The EME RG could help here. In theory, it can push some of the cost of receiving packets (I agree with you btw) into a setup phase, with establishment of trust etc. Scott _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Dec 01 09:05:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq90K-0000Bl-CL; Fri, 01 Dec 2006 09:04:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq90J-00007l-1v for architecture-discuss@ietf.org; Fri, 01 Dec 2006 09:04:39 -0500 Received: from [63.247.74.123] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gq90H-0005Jl-EN for architecture-discuss@ietf.org; Fri, 01 Dec 2006 09:04:39 -0500 Received: from eurolab.net2.nerim.net ([213.41.175.161] helo=asus) by montage.altserver.com with esmtpa (Exim 4.52) id 1Gq90D-0006eF-76 for architecture-discuss@ietf.org; Fri, 01 Dec 2006 06:04:34 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 01 Dec 2006 15:04:24 +0100 To: Pekka Nikander , architecture-discuss@ietf.org From: Jefsey_Morfin Subject: Re: [arch-d] A straw man analysis of why send-receive packet paradigm is unsustainable In-Reply-To: References: MIME-Version: 1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.5 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd 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: , Content-Type: multipart/mixed; boundary="===============1477449018==" Errors-To: architecture-discuss-bounces@ietf.org Message-Id: --===============1477449018== Content-Type: multipart/alternative; boundary="----MTwhuzmxvaddnapauqusofrpyqzgrhcumw" ------MTwhuzmxvaddnapauqusofrpyqzgrhcumw Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-798C7B5D At last! Welcome to virtual circuit switching and to retrieve function! The most important e-Human Right is to NOT receive. But you must give up some other paradigms too. 1) the "dumb" network is not dumb, it is cramed with routing intelligence. Get rid of it. Split routing from transport. 2) end to end is nice, as is plug to plug, but the real interest in networking is brain to brain/cpu. Stop mixing the two. 3) change the RFC 3935 core value and use "distributed" rather than "decentralised" and adopt "user centric" 4) do not focus on the internode protocol but start from the network operating system 5) the root server system Now, I am not sure at all that all this is for 10+ years from now. This was the way it worked internationally 30 years from now, and the way you can manage today _at_usage_level_. The digital ecosystem is not a monolith. You can implement a store-retrieve email and culture based upon SMTP, etc. You can read IP in a second degree way to use it differently. jfc At 10:37 01/12/2006, Pekka Nikander wrote: >[This is _really_ long term. If you are not interested in 10+ years >things, don't bother reading.] > >It is a well established view that smart ends and a dumb, open, >neutral network are good, for a number of well-known reasons. Herein >I present a claim that if we want to retain that approach, we will >have to give up the current send-receive packet paradigm, sooner or >later. While there are ample experimental evidence for my claim, I >will skip that and focus on a techno-economic analysis. > > >The current Internet is based on what I call the send-receive packet >paradigm. That is, the fundamental primitives in the network are >"send" and "receive", on the packet level. More importantly, what is >built in into this paradigm is the idea that anyone can send anything >to anybody, and the network will do its best to get that through. >While that is very simple and well known, let me dissect it a little >bit: > >1. The paradigm implies that any packet sent is delivered, or at >least tried to get delivered. > >2. The paradigm implies that the sender is free to select the >receiver. Sender's consent. > >3. The paradigm implies that the receiver need to process, at least >minimally, any traffic sent to it by any sender. > >Of those, the last one appears to be the most important one. Think >about it! > > >The fundamental reason why I claim, below, that the current paradigm >is unsustainable, in the longer run, is the following: > > Sending packets is cheaper than receiving and processing them > >I think that the claim could probably be based on physics, entropy, >and energy, but I won't go into that; I'm not an expert there. >Instead, let's consider two well known examples: spam and DDoS. > >Sending spam costs the sender relatively little, even if they are not >using zombie farms. They basically create a single message, and send >it repeatedly, often even allowing the network to replicate it. >Receiving, on the other hand, is expensive. The receiver must >decide, somehow, whether the received message is spam and should be >ignored, or not. To make the decision, quite a lot of processing is >needed, if not by the machines, then by the user. > >In a DDoS attack, sending is even cheaper to the attacker due to >utilising zombie farms. The receiver pays heavily, both on >legitimate traffic lost due to congestion and on even minimally >processing those attack packets that actually reach the attacked >system. More importantly, however, if we consider the packet level >we can see the same pattern as in the spam case. The attacker >doesn't need to spend much energy in generating packet contents; in >many cases the packets can contain whatever garbage. On the other >hand, the receiver needs to spend at least some energy in deciding >whether the received packet is legitimate or not. > >That leads to the following corollary: > > Receiving packets is expensive because of the associated decision >process > >Note that it is possible to send mindlessly, without needing to make >any decisions at the packet level. The malicious send can make all >the decisions in advance. > > >The implication is clear: The original, open, neutral end-to-end >network based on the send-receive packet paradigm is unsustainable in >the face of large amounts of malicious players. > >Note that this is fundamental. It is impossible to allow anyone to >send any packets to anyone, without some people being able to abuse >it in a way or another. Conversely, if we want to also in the more >distant future have a network that is built on the core values of the >original Internet, we need to give up its fundamental technical >foundation, the send-receive packet paradigm. > > >I think what's above is enough for a single message. I'll leave the >wider implications and options for action to another message. > >--Pekka Nikander > > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www1.ietf.org/mailman/listinfo/architecture-discuss > > ------MTwhuzmxvaddnapauqusofrpyqzgrhcumw Content-Type: text/html At last! Welcome to virtual circuit switching and to retrieve function!
The most important e-Human Right is to NOT receive.

But you must give up some other paradigms too.

1) the "dumb" network is not dumb, it is cramed with routing
intelligence. Get rid of it. Split routing from transport.
2) end to end is nice, as is plug to plug, but the real interest in
networking is brain to brain/cpu. Stop mixing the two.
3) change the RFC 3935 core value and use "distributed" rather than
"decentralised" and adopt "user centric"
4) do not focus on the internode protocol but start from the network
operating system
5) the root server system

Now, I am not sure at all that all this is for 10+ years from now.
This was the way it worked internationally 30 years from now, and the
way you can manage today _at_usage_level_. The digital ecosystem is
not a monolith. You can implement a store-retrieve email and culture
based upon SMTP, etc. You can read IP in a second degree way to use
it differently.
jfc

At 10:37 01/12/2006, Pekka Nikander wrote:

>[This is _really_ long term.  If you are not interested in 10+ years
>things, don't bother reading.]
>
>It is a well established view that smart ends and a dumb, open,
>neutral network are good, for a number of well-known reasons.  Herein
>I present a claim that if we want to retain that approach, we will
>have to give up the current send-receive packet paradigm, sooner or
>later.  While there are ample experimental evidence for my claim, I
>will skip that and focus on a techno-economic analysis.
>
>
>The current Internet is based on what I call the send-receive packet
>paradigm.  That is, the fundamental primitives in the network are
>"send" and "receive", on the packet level.  More importantly, what is
>built in into this paradigm is the idea that anyone can send anything
>to anybody, and the network will do its best to get that through.
>While that is very simple and well known, let me dissect it a little
>bit:
>
>1. The paradigm implies that any packet sent is delivered, or at
>least tried to get delivered.
>
>2. The paradigm implies that the sender is free to select the
>receiver.  Sender's consent.
>
>3. The paradigm implies that the receiver need to process, at least
>minimally, any traffic sent to it by any sender.
>
>Of those, the last one appears to be the most important one.  Think
>about it!
>
>
>The fundamental reason why I claim, below, that the current paradigm
>is unsustainable, in the longer run, is the following:
>
>    Sending packets is cheaper than receiving and processing them
>
>I think that the claim could probably be based on physics, entropy,
>and energy, but I won't go into that; I'm not an expert there.
>Instead, let's consider two well known examples: spam and DDoS.
>
>Sending spam costs the sender relatively little, even if they are not
>using zombie farms.  They basically create a single message, and send
>it repeatedly, often even allowing the network to replicate it.
>Receiving, on the other hand, is expensive.  The receiver must
>decide, somehow, whether the received message is spam and should be
>ignored, or not.  To make the decision, quite a lot of processing is
>needed, if not by the machines, then by the user.
>
>In a DDoS attack, sending is even cheaper to the attacker due to
>utilising zombie farms.  The receiver pays heavily, both on
>legitimate traffic lost due to congestion and on even minimally
>processing those attack packets that actually reach the attacked
>system.  More importantly, however, if we consider the packet level
>we can see the same pattern as in the spam case.  The attacker
>doesn't need to spend much energy in generating packet contents; in
>many cases the packets can contain whatever garbage.  On the other
>hand, the receiver needs to spend at least some energy in deciding
>whether the received packet is legitimate or not.
>
>That leads to the following corollary:
>
>    Receiving packets is expensive because of the associated decision
>process
>
>Note that it is possible to send mindlessly, without needing to make
>any decisions at the packet level.  The malicious send can make all
>the decisions in advance.
>
>
>The implication is clear:  The original, open, neutral end-to-end
>network based on the send-receive packet paradigm is unsustainable in
>the face of large amounts of malicious players.
>
>Note that this is fundamental.  It is impossible to allow anyone to
>send any packets to anyone, without some people being able to abuse
>it in a way or another.  Conversely, if we want to also in the more
>distant future have a network that is built on the core values of the
>original Internet, we need to give up its fundamental technical
>foundation, the send-receive packet paradigm.
>
>
>I think what's above is enough for a single message.  I'll leave the
>wider implications and options for action to another message.
>
>--Pekka Nikander
>
>
>_______________________________________________
>Architecture-discuss mailing list
>Architecture-discuss@ietf.org
>https://www1.ietf.org/mailman/listinfo/architecture-discuss
>
>

------MTwhuzmxvaddnapauqusofrpyqzgrhcumw-- --===============1477449018== 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 --===============1477449018==-- From architecture-discuss-bounces@ietf.org Fri Dec 01 09:56:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq9nC-0006lo-9R; Fri, 01 Dec 2006 09:55:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gq9nB-0006jK-CG for architecture-discuss@ietf.org; Fri, 01 Dec 2006 09:55:09 -0500 Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gq9n6-0006gv-3p for architecture-discuss@ietf.org; Fri, 01 Dec 2006 09:55:09 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id A3FCA34091; Fri, 1 Dec 2006 09:55:03 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 09:55:03 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] transport layer identifier evolutiion to support multihoming Date: Fri, 1 Dec 2006 09:55:02 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC01038ADF@tayexc14.americas.cpqcorp.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] transport layer identifier evolutiion to support multihoming Thread-Index: AccVAkgOMqql1rJxQymAXeZKfwSqQwAVRFhw From: "Bound, Jim" To: "John Day" , "John Leslie" X-OriginalArrivalTime: 01 Dec 2006 14:55:03.0018 (UTC) FILETIME=[AE5FFCA0:01C71558] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org John, > Jim, I am terrible sorry if you were offended by my choice of=20 > language. It was not intended as elitist or insulting in the least.=20 > I think you are reading far too much into it. As we talked offline I will accept that I overreacted and you did not mean how I took it (taking my moral inventory in a sense which elitistism permits in my view). As I said offline and will share here I a doing my best to live in this new politically correct world and as best I can to keep my responses in form to a U.S. Mid-West News Caster void of emotion and be teflon to my own biases when raised. I much liked the old days when we could kick and scream and I recall one mail a long time ago where one said "YYY person you ignorant XXXX" from the old U.S. Saturday Night Live skits. But those days are gone and I accept that and to be honest this today seems more productive for IETF cyberspace conversations. =20 >=20 > I have worked (and am working) in more than one of=20 > terminology with respect to this work. And I was merely=20 > recognizing that. There was no value judgement in it=20 > whatsoever. As for preferring to call them endpoint=20 > identifiers. If you look at how the use of source and=20 > destination port-ids arise in this class of protocols, i.e.=20 > not only transport but also data link. (They are basically=20 > the same thing.) >=20 > Working from first principles (consider just two machines=20 > trying to communicate), you find that the reason they first=20 > appear is to distinguish multiple flows on the line. Since=20 > either end may initiate a connection, it is not feasible for=20 > just one end to assign the connection-id. If they did, there=20 > would always be the chance of collisions. Since both sides=20 > already had a port-id that their local IPC was using to=20 > distinguish the flow locally. The convention has been to=20 > concatenate them as the connection-id. >=20 > So the reason, I refer to the field as a connection-id is=20 > that is its function in the protocol. Each port-id can be=20 > seen as a local-identifier of an endpoint. >=20 > Does that explain it? Yes completely though I am not clear both ends need the same connection-id. My reasons for end-point-id was it also implies the packet has been delivered and not being routed further and how does that play into our model for analysis too? Best, /jim =20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Dec 01 10:14:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqA5D-000319-NE; Fri, 01 Dec 2006 10:13:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqA5D-000314-6k for architecture-discuss@ietf.org; Fri, 01 Dec 2006 10:13:47 -0500 Received: from sccrmhc15.comcast.net ([204.127.200.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqA5B-0001uI-Tq for architecture-discuss@ietf.org; Fri, 01 Dec 2006 10:13:47 -0500 Received: from [10.0.1.43] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (sccrmhc15) with ESMTP id <2006120115134501500b4lvde>; Fri, 1 Dec 2006 15:13:45 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <816DD9299957E547B5D758D7F977D6DC01038ADF@tayexc14.americas.cpqcorp.net> References: <816DD9299957E547B5D758D7F977D6DC01038ADF@tayexc14.americas.cpqcorp.net> Date: Fri, 1 Dec 2006 10:13:24 -0500 To: "Bound, Jim" , "John Day" , "John Leslie" From: John Day Subject: RE: [arch-d] transport layer identifier evolutiion to support multihoming Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 9:55 -0500 2006/12/01, Bound, Jim wrote: >John, > >> Jim, I am terrible sorry if you were offended by my choice of >> language. It was not intended as elitist or insulting in the least. >> I think you are reading far too much into it. > >As we talked offline I will accept that I overreacted and you did not >mean how I took it (taking my moral inventory in a sense which >elitistism permits in my view). As I said offline and will share here I >a doing my best to live in this new politically correct world and as >best I can to keep my responses in form to a U.S. Mid-West News Caster >void of emotion and be teflon to my own biases when raised. I much >liked the old days when we could kick and scream and I recall one mail a >long time ago where one said "YYY person you ignorant XXXX" from the old >U.S. Saturday Night Live skits. But those days are gone and I accept >that and to be honest this today seems more productive for IETF >cyberspace conversations. >s ;-) I know what you mean! lol. But that doesn't mean we can't give each other a bit of bad time once in awhile. I expect it! ;-) Just so you know, I am doing as much the same as you, but trying to keep it light. > > >> I have worked (and am working) in more than one of >> terminology with respect to this work. And I was merely >> recognizing that. There was no value judgement in it >> whatsoever. As for preferring to call them endpoint >> identifiers. If you look at how the use of source and >> destination port-ids arise in this class of protocols, i.e. >> not only transport but also data link. (They are basically >> the same thing.) >> >> Working from first principles (consider just two machines >> trying to communicate), you find that the reason they first >> appear is to distinguish multiple flows on the line. Since >> either end may initiate a connection, it is not feasible for >> just one end to assign the connection-id. If they did, there >> would always be the chance of collisions. Since both sides >> already had a port-id that their local IPC was using to >> distinguish the flow locally. The convention has been to >> concatenate them as the connection-id. >> >> So the reason, I refer to the field as a connection-id is >> that is its function in the protocol. Each port-id can be >> seen as a local-identifier of an endpoint. >> >> Does that explain it? > >Yes completely though I am not clear both ends need the same >connection-id. Well, once you have multiple sources. If one end were choosing the conn-id, then the other end could end up with collisions from different sources and it would have to do more work to keep them disambiguated. He could, but using two local-ids known to be unambiguous in their local context ensures that together they are unambiguous in both contexts. (And probably the biggest reason, is it is the traditional way to solve the problem from long before it was used in TCP. ;-)) >My reasons for end-point-id was it also implies the packet has been >delivered and not being routed further and how does that play into our >model for analysis too? Yes, okay. But strictly speaking, the protocol in which conn-id/endpoint-id occurred never knew it was routed. Another important property of this class of protocols which I think needs to be preserved and isn't by SCTP is that all of their functionality is dedicated to a single instance, a single connection. There need not be any cross connection shared state. Whether you do this in actual implementation is your choice, but you don't have to. It turns out that this focus/isolation has some very nice properties when you start putting things together. Later, I have some real work that must get done! John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Dec 01 12:39:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqCKl-0003CG-VG; Fri, 01 Dec 2006 12:37:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqCKk-00036l-SM for architecture-discuss@ietf.org; Fri, 01 Dec 2006 12:37:58 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqCKi-00023I-1L for architecture-discuss@ietf.org; Fri, 01 Dec 2006 12:37:58 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 735E5872F6; Fri, 1 Dec 2006 12:37:50 -0500 (EST) To: architecture-discuss@ietf.org Subject: Re: [arch-d] Some notes about HIP and SHIM6 (was Re: On identifiers: what is virtual and what...) Message-Id: <20061201173750.735E5872F6@mercury.lcs.mit.edu> Date: Fri, 1 Dec 2006 12:37:50 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org [Sorry this is a bit out of order, it's been sitting in my editor buffer, waiting till I had time to complete it. I think the point about NAT's is still very apt.] > From: Pekka Nikander > the purpose of HIP is to establish a new, cryptographic name space into > the stack .. > .. those are all just consequences of the architectural change. > Architecturally speaking, they are all made easy by providing a new > secure layer of indirection. > Hence, given its purpose, I would consider HIP architectural and not > just engineering. A new name space is a new name space, and that is > something architectural. Absolutely. Anytime you're adding a general-purpose namespace (and bindings thereto), that's definitely architectural. Another way to tell it's architectural is that it's not intended to support just a single feature (e.g. mobility or multi-homing); rather, it provides a very general, fundamental capability that lots of different things can be built upon. > somewhere between the internetworking and transport layers. And that's an interesting choice, given the previous discussion here. It really does name a "stack" (whatever that means :-). Not perhaps the best choice, given a blank slate, but when you're constrained to be modifying an existing architecture, sometimes you have to take what you can get. > .. the way the new name space is embedded into the stack for backwards > compatibility is certainly engineering; depending on your point of > view, it can be considered either as very clever engineering or as an > utterly ugly kludge. Well, sometimes you don't have any choice... > better-engineered NAT traversal Oh Lord, there's something we really need, too. NAT's are going to be with us a long time, and anything we can do to make crossing them less kludged is a Really Good Thing. Too bad this goal has received so little attention... And no, "just get rid of all the NAT boxes" is NOT a viable strategy for dealing with them - as people keep pointing out, they are so incredibly popular because they are the only things out there that meet a *variety* of real needs, most of which we aren't really meeting yet, even with our latest designs. Expanding on this a bit, I see HIP as potentially part of an alternative strategy for how to evolve a large, in-service architecture. I am frankly dubious about fork-lift upgrades, where one replaces an entire layer with something else. I think a much better strategy is a "piece-by-piece" one, where one tries to deploy some (hopefully well-architected) new pieces that, while each stands on its own, both in terms of functionality to give you some new capability, as well as cost/benefit, *together* add up to a coherent new whole. (By "well-architected" I mean in the sense that "the measure of a good architecture is not how well it does the things you knew up front you wanted it to do, but how well it does the things you never had any idea it would be called on to do", as one of my favourite aphorisms goes.) Yes, such things will always be a bit of a "bag on the side", but if well-done, they can be a piece of a better replacement. E.g. if we get HIP widely deployed, it will slowly leach the "end-end naming" part of IPvN addresses off to a new namespace, and that will make NAT box traversal (which is where I started this thought) much easier. At that point, it's feasible to e.g. start trying to morph IPv4 addresses into scope-local forwarding tags, with yet another new namespace being used for end-end routing-names, and routing stuff. This leads to my most far-reaching (grandiose? :-) vision, in which the new routing-names I mentioned above would be part of a replacement internework layer (eventually totally obsoleting IPv4 addresses). I view MPLS, currently yet-another Bag-on-the-Side (BotS), as something that could be integrated into that new internetwork layer, one that (among many other new capabilities) recognizes and can manipulate traffic aggregates, and make better use of the current actual fabric (e.g. lamda-switching). But it's going to be a long road, with many smaller paving-stones to be put down, before that happens. > my personal opinion is that alone both HIP and SHIM6 are still just > band aid, buying more time for the current architecture. Perhaps > better-than-usual band aid, due to having at least some threads of > architecture instead of being completely kludgy, but still band aid. Only if one doesn't actively consider them as part of a larger picture, as I did above. I don't see them as that closely equivalent, mind, because HIP does introduce a new namespace, and that can be a key piece of an "architecture evolution" plan. > I consider it more likely that the results the NSF and FP7 funded > research will mature before the IETF community gets to the stage I'm dubious about these academic projects really producing something that is, in itself, viable as a replacement. The issues of interoperability, and the cost/benefit issues that drive the success of things in the Real World, have to be factored in at a higher level that research efforts (which really have different goals) are really able to do. > While in theory they could allow more radical changes of the underlying > parts of the stack, that would require more drastic changes than either > of the approaches currently support. Well, exactly how drastic the lower-layer redoing will be is still open; it hasn't really gotten a lot of thought. Even attempts to, e.g., deploy a second copy of IPv6 (to allow reuse of existing hardware/code) below an end-end IPv6 turn out to be pretty difficult, though. > Again, I am not too hopeful about the IETF community ever getting there. Well, we'll see. Things are heading for trouble, and if the IETF can't get with it, the affected parties (e.g. ISP's) will simply find some other forum in which to tackle the problem. Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Dec 01 12:45:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqCRg-00088C-CS; Fri, 01 Dec 2006 12:45:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqCRg-000887-2K for architecture-discuss@ietf.org; Fri, 01 Dec 2006 12:45:08 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqCRa-0004C8-PF for architecture-discuss@ietf.org; Fri, 01 Dec 2006 12:45:08 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 85F983414B; Fri, 1 Dec 2006 12:45:02 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 12:45:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Some notes about HIP and SHIM6 (was Re: On identifiers:what is virtual and what...) Date: Fri, 1 Dec 2006 12:45:00 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC01038C97@tayexc14.americas.cpqcorp.net> In-Reply-To: <20061201043954.24BBC86AFF@mercury.lcs.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Some notes about HIP and SHIM6 (was Re: On identifiers:what is virtual and what...) Thread-Index: AccVAtN6sMjSaeuKRQ2lCHWEjTk6jwAbXCew From: "Bound, Jim" To: "Noel Chiappa" , X-OriginalArrivalTime: 01 Dec 2006 17:45:02.0330 (UTC) FILETIME=[6DA37DA0:01C71570] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I believe Noel has the two correct and HIPs strength. I would suggest the finer grain details of the transport communications in SHIM6 and from implementation view are easier to identify and ship faster. /jim=20 > -----Original Message----- > From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu]=20 > Sent: Thursday, November 30, 2006 11:40 PM > To: architecture-discuss@ietf.org > Cc: jnc@mercury.lcs.mit.edu > Subject: Re: [arch-d] Some notes about HIP and SHIM6 (was Re:=20 > On identifiers:what is virtual and what...) >=20 > > From: Andrew McGregor >=20 > > .. what HIP and SHIM6 both give you is the ability to=20 > assert that > > something accessible at location A is also accessible=20 > at locations B > > through ... > > .. but the core of what the protocols provide is very similar. >=20 > Yes and no, I think - but I kind of phased out on the finer=20 > details of HIP and SHIM6, so the following comments may not=20 > be accurate, and I'd appreciate any corrections to possibly=20 > mistaken impressions. >=20 > My impression is that although to an initial glance (if you=20 > consider a few "how do I do thing X" cases) they do look like=20 > they provide similar capabilities (as you point out), I think=20 > that perhaps at a deeper level HIP is more powerful,=20 > architecturally. The reason is simple: HIP brings an extra=20 > namespace to bear, and at an architectural level that's very powerful. >=20 > Also, SHIM6 overloads one more meaning onto an existing=20 > namespace (IPv6 addresses), and, architecturally speaking,=20 > that's always bad. Yes, yes, I know, the idea is that there=20 > will be two separate namespaces that just happen to share a=20 > syntax. However... we all know that anytime there is the=20 > possibility of kludging something (in this case, by treating=20 > a name from sub-space A as if it were a name from sub-space=20 > B), someone somewhere will do it, as a "quick hack" to solve=20 > some problem they have, and then you're in the soup. Only=20 > with a complete separate namespace is there no possibility of=20 > hacks that entangle (and strangle) a design. >=20 > Noel >=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 Fri Dec 01 12:50:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqCWW-0001Mg-Hs; Fri, 01 Dec 2006 12:50:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqCWV-0001LR-7x for architecture-discuss@ietf.org; Fri, 01 Dec 2006 12:50:07 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqCWP-0005oB-GU for architecture-discuss@ietf.org; Fri, 01 Dec 2006 12:50:07 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 56DF234163; Fri, 1 Dec 2006 12:50:01 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 12:50:01 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Some notes about HIP and SHIM6 (was Re: On identifiers:what is virtual and what...) Date: Fri, 1 Dec 2006 12:49:58 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC01038CA1@tayexc14.americas.cpqcorp.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Some notes about HIP and SHIM6 (was Re: On identifiers:what is virtual and what...) Thread-Index: AccVJBSmYKNha00ITIuYUDCkCenhUwATM8Nw From: "Bound, Jim" To: "Pekka Nikander" , "Noel Chiappa" , "Geoff Huston" X-OriginalArrivalTime: 01 Dec 2006 17:50:01.0123 (UTC) FILETIME=[1FBBAF30:01C71571] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Well stated and I agree with most below. My view and support of SHIM6 is that it can adapt to new architecture models and further to HIP and the name space and actually could be an additional SHIM6 set of specs. I feel SHIM6 is the IETF energy vehicle to address this part of a change to the architecture model for transport. /jim=20 > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Sent: Friday, December 01, 2006 3:37 AM > To: Noel Chiappa; Geoff Huston > Cc: architecture-discuss@ietf.org > Subject: Re: [arch-d] Some notes about HIP and SHIM6 (was Re:=20 > On identifiers:what is virtual and what...) >=20 > Geoff, Noel, and all, >=20 > When I was saying that SHIM6 is a watered down version of HIP, I was =20 > mostly speaking from an architectural and long-term point of view. =20 > I'm trying to clarify that below, replying to your messages. >=20 > Geoff Huston spoke wisely: > > My personal view is that there is a significant difference=20 > between =20 > > a host-level approach and a transport session level=20 > approach that you=20 > > seem to have missed in your note. I find myself in strong=20 > > disagreement with your perspective of SHIM6 as some kind of=20 > diluted or =20 > > compromised version of HIP. >=20 > I can easily understand your point of view and appreciate=20 > that you disagree with me, though I don't quite understand=20 > what you mean with a "host-level" vs. "transport session=20 > level" approach. Would you care to clarify? >=20 > However, overall, I think that perhaps we could agree to=20 > disagree here, hopefully understanding that we looking at=20 > these two artefacts (HIP and SHIM6) from very different=20 > points of view. >=20 > There *are* differences between HIP and SHIM6. Some of the=20 > differences appear very significant from a short-term=20 > operational point of view. If I understand you correctly=20 > (please correct if I'm reading you wrong), that's what you=20 > consider most important. Indeed, from that point of view=20 > SHIM6 can really be considered as a better- engineered=20 > protocol (and not a watered down version), since it addresses=20 > some operational aspects that HIPpers are just slowly copying=20 > from SHIM6, and, perhaps most importantly, SHIM6 does not=20 > mandate any changes into the DNS data or require any new=20 > infrastructure while HIP does. >=20 > However, my point of view was and still is architectural and=20 > long- term. From that point of view, I stand behind my=20 > words. I can try to explain my point even more rigourously=20 > if needed, but I said already most of what I wanted to say in=20 > http://www1.ietf.org/mail-=20 > archive/web/architecture-discuss/current/msg00837.html >=20 > > Frankly, [...], there is much involved here. To expect any=20 > particular=20 > > approach to get it all right first time is asking too much. HIP and=20 > > SHIM6 are examples of trying to understand what these concepts look=20 > > like in code and in protocol stacks. They bed down these otherwise=20 > > abstract discussions with some experience with=20 > implementation and the=20 > > harsh realities of deployment in the network. >=20 > I couldn't agree more. >=20 > > For you that may well be band aid. >=20 > I'm calling it band aid since it is all relatively short-term=20 > to me. =20 > I once thought that HIP would be a long-term solution, but no=20 > longer do. I think that proves your point above: you cannot=20 > get all right the first time. :-) >=20 > > For me its part of the scientific investigatory process of=20 > devising an=20 > > hypothesis, and then testing this hypothesis, and then looking very=20 > > hard to make sure that the hypothesis remains intact. >=20 > Yes, indeed! Any ideas need to be tested. With HIP we are=20 > getting there now, hopefully, and I've understood that the=20 > first SHIM6 implementations are getting ready as well. >=20 > > As far as I can see, we [...] still have much to learn here. >=20 > That's the whole point of having this discussion, at least to=20 > me. To learn what I'm missing and understanding badly, and=20 > also slowly learning to see the things with other people's eyes. >=20 > Yes, I know I appear sometimes quite arrogant and perhaps=20 > even elitist. My apologies for that. One reason behind is=20 > my still- persisting frustration... >=20 > --- >=20 > Andrew McGregor once wrote: > >> .. what HIP and SHIM6 both give you is the ability to assert that=20 > >> something accessible at location A is also accessible at=20 > locations B=20 > >> through ... > >> .. but the core of what the protocols provide is very similar. >=20 > On 1 Dec 2006, at 06:39, Noel Chiappa wrote: > > Yes and no, I think - but I kind of phased out on the finer=20 > details of=20 > > HIP and SHIM6, so the following comments may not be=20 > accurate, and I'd=20 > > appreciate any corrections to possibly mistaken impressions. > > > > My impression is that although to an initial glance (if you=20 > consider a=20 > > few "how do I do thing X" cases) they do look like they provide=20 > > similar capabilities (as you point out), I think that perhaps at a=20 > > deeper level HIP is more powerful, architecturally. > > The reason is simple: HIP brings an extra namespace to=20 > bear, and at an=20 > > architectural level that's very powerful. >=20 > From the 10000 feet point of view, I think that is exactly right. =20 > HIP was designed with a new name space very much in mind,=20 > from the beginning. SHIM6 started from functional=20 > requirements, and the a new name space was not there, rather=20 > the reverse. >=20 > However, with the introduction of CGA-based SHIM6 ULIDs, you=20 > can kind- of retrofit a new name space into SHIM6. I have to=20 > admit not having read the latest versions of the specs, but=20 > my impression is that the value of such possibility is still=20 > not appreciated and there's been relatively little thought=20 > about that. But I may be wrong. >=20 > Hence, while in theory HIP is architecturally more powerful=20 > due to the new name space, in reality you apparently can do=20 > the same things with SHIM6. Perhaps not that elegantly than=20 > with HIP (that is, if HIP can be considered elegant :-), but still. >=20 > > Also, SHIM6 overloads one more meaning onto an existing namespace > > (IPv6 addresses), and, architecturally speaking, that's=20 > always bad. =20 > > Yes, yes, I know, the idea is that there will be two separate=20 > > namespaces that just happen to share a syntax. >=20 > But so does HIP with its backwards compatibility mode. =20 > That's the whole point with the ORCHID draft: to allow=20 > existing applications to work unmodified, by overloading the=20 > IPv6 syntax. >=20 > > However... we all know that anytime there is the possibility of=20 > > kludging something (in this case, by treating a name from=20 > sub-space A=20 > > as if it were a name from sub-space B), someone somewhere=20 > will do it,=20 > > as a "quick hack" to solve some problem they have, and then=20 > you're in=20 > > the soup. Only with a complete separate namespace is there no=20 > > possibility of hacks that entangle (and strangle) a design. >=20 > Indeed. However, in this particular case I think that the=20 > value of backwards compatibility may exceed the drawbacks. =20 > In any case, there is also an attempt to define a new API=20 > that could be used with any shim-like approach, including=20 > SHIM6 and HIP. >=20 > So, to summarise, at the grass roots level HIP and SHIM6 are=20 > closer to each other today than many people may think or=20 > would like to admit. I think that is quite natural:=20 > implementation wise, the differences are relatively small, at=20 > least if you implement also CGAs for SHIM6. For example, it=20 > looks like that the first SHIM6 implementations will be based=20 > on existing HIP ones. >=20 > --Pekka Nikander >=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 Fri Dec 01 14:50:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqENV-0005be-HY; Fri, 01 Dec 2006 14:48:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqENU-0005bX-Hd for architecture-discuss@ietf.org; Fri, 01 Dec 2006 14:48:56 -0500 Received: from web58703.mail.re1.yahoo.com ([66.196.100.125]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GqENT-00085l-8L for architecture-discuss@ietf.org; Fri, 01 Dec 2006 14:48:56 -0500 Received: (qmail 96810 invoked by uid 60001); 1 Dec 2006 19:48:55 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=rI2sGlo1hHx36el5uMFU6giD3p9aXC30u+hZG2R60L81aWr1fToYG/82xQ91Nw4NCQ3buCXdA2CxXm+bHkoCim0uRmYZEtHel6C0xRfnhf26LzXEu7Mw8jnWjTXw/h8qcrC7P9nnJe+crM4NoiefvwVHS3bysw4ASYSgL2nq93s=; X-YMail-OSG: 9mmXPTQVM1n_zwkXWS6f1byxi_kyTD9YVVHFvPhJ Received: from [24.114.255.3] by web58703.mail.re1.yahoo.com via HTTP; Fri, 01 Dec 2006 11:48:54 PST Date: Fri, 1 Dec 2006 11:48:54 -0800 (PST) From: Peter Sherbin Subject: Re: [arch-d] On identifiers: what is virtual and what is global (wasRe: thou... To: John Day , David Conrad , "Bound, Jim" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <81684.96797.qm@web58703.mail.re1.yahoo.com> X-Spam-Score: 1.8 (+) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > Not quite. That only goes as far as natural history. Science finds > the smallest number of concepts that describe One would describe concepts via definitions and assumptions... and... you win ;) Mental aerobics help for sure but let's get practical. >If yes, by what mechanism? > > I think we need a model. Do we make it Information RFC? Who starts the first draft? Where is it deposited for comments / editing? Thx, Peter --- John Day wrote: > At 10:12 -0800 2006/11/30, Peter Sherbin wrote: > > > Although right after that he refers to it as a route service. > >IMO for him both terms bear the same meaning. > > > >> What node hierarchy? > > > >Arrangements inside the node that are independent of and transparent > >to routing. > > Huh? Hierarchy within the system? > > > > >> This is science. Our goal is to find the minimal set of concepts > >> that encompass the whole problem.. The attitude that most systems > >> are not multihomed... > > > >OK, science describes via definitions and assumptions. That most > >systems are not > >multihomed is an assumption, where system = node performing an > >individual task. > >Nodes are aggregated in private networks. Most private networks are > >(or will be) > >multihomed. > > Not quite. That only goes as far as natural history. Science finds > the smallest number of concepts that describe the widest range of > phenomena and from which predictions can be made. > > As to your definitions, why set your sights so low? You are trying > to make simplifying assumptions before you even know if it is > necessary. As I pointed out last night, this assumption that most > systems are not multihomed is what got us n this mess to start with. > Shall we continue it? > > >A question to all: are we ready to start documenting architectural > >requirements and > >assumptions? If yes, by what mechanism? > > I think we need a model. > > John > ____________________________________________________________________________________ Cheap talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. http://voice.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 Dec 01 15:45:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqFEt-0007uT-Ol; Fri, 01 Dec 2006 15:44:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqFEs-0007uO-Jz for architecture-discuss@ietf.org; Fri, 01 Dec 2006 15:44:06 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqFEq-0002kC-Bt for architecture-discuss@ietf.org; Fri, 01 Dec 2006 15:44:06 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 53929872D7; Fri, 1 Dec 2006 15:44:02 -0500 (EST) To: architecture-discuss@ietf.org Subject: Re: [arch-d] Some notes about HIP and SHIM6 (was Re: On identifiers: w hat is virtual and what...) Message-Id: <20061201204402.53929872D7@mercury.lcs.mit.edu> Date: Fri, 1 Dec 2006 15:44:02 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: "Fergie" > I wonder if we happen to be using the term "overloaded" a little too > liberally to have a useful dialogue? > What is overloaded? ... perhaps it is time we revisit what what that > might actually mean. OK, here's my take. I feel that it does have a pretty specific, defined meaning (and it's not identical to the general English meaning of "overload", alas; just as "force" to an engineer means a vector, not a general concept). My sense is that system architects have taken the term, pretty directly, from the computer language people. There, an operator/etc is said to be "overloaded" if it is, in isolation, ambiguous, and one needs to consider the context to know what it means. A classic example is the "*" operator in C, which might mean either "multiply", or "indirect through pointer". (Just for extra grins, in C one used to be able to say "a = *p" and "a =* p", and they meant totally different things! So that "a=*p" really was formally ambiguous.) The extension to the system architectural world is pretty straightforward. So, to me an identifier is "overloaded" if it can be used for a variety of entirely different purposes; e.g. an IPvN address can either identify an entity at one end of an end-end communication (as it does in the TCP, specifically in the checksum), or it can identify a thing (interface, in the usual case) that the system of routers will deliver a packet to. Use of IPv6 addresses to serve two different functions, in SHIM6, is overloading (in the technical sense) of IPv6 addresses. Etc, etc. Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Dec 02 03:47:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqQUT-0002v0-0X; Sat, 02 Dec 2006 03:44:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqQUR-0002uu-GD for architecture-discuss@ietf.org; Sat, 02 Dec 2006 03:44:55 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqQUO-0005Bo-Tu for architecture-discuss@ietf.org; Sat, 02 Dec 2006 03:44:55 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 6BD8A2130BD; Sat, 2 Dec 2006 10:44:36 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 0FF48212DB0; Sat, 2 Dec 2006 10:44:36 +0200 (EET) In-Reply-To: <45703339.1000804@employees.org> References: <45703339.1000804@employees.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [arch-d] A straw man analysis of why send-receive packet paradigm is unsustainable Date: Sat, 2 Dec 2006 10:44:33 +0200 To: Scott W Brim X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On 12/01/2006 04:37 AM, Pekka Nikander wrote: >> Receiving packets is expensive because of the associated decision >> process > > ... > >> The implication is clear: The original, open, neutral end-to-end >> network based on the send-receive packet paradigm is unsustainable in >> the face of large amounts of malicious players. On 1 Dec 2006, at 15:50, Scott W Brim wrote: > The EME RG could help here. In theory, it can push some of the cost > of receiving packets (I agree with you btw) into a setup phase, with > establishment of trust etc. Maybe. Interestingly, if you look at the current set of still- evolving EME requirements, you'll notice that something like Hi3 would relatively beautifully fulfil most of them. More generally, to me it looks like that the EME security requirements will be easier to reach if we adapt a new cryptographic name space, such as in HIP or SHIM6 with CGAs. But, if we do so, we will give up some of our core values in order to stay within the current paradigm. By taking the EME/Hi3/overlay/... route, we retain the basic send-receive packet paradigm while giving up some parts of the idea of an dumb, open, neutral network. At minimum, the network is no more dumb as it has the ability to heavily filter traffic. Nor it is any more open or neutral as some traffic will be allowed and other not. The overall issue is very hard to swallow. I'm sure I'll need to repeat the point umpteen times before it starts to sink in general in this community. Basically, we have two choices: 1. Give up some of our core values, or 2. Give up the send-receive packet paradigm. In my opinion, our almost "holy" long-term challenge is to find a new paradigm that will be able to sustain as much as possible of our core values: http://www.isoc.org/pubpolpillar/principles.shtml Consider especially the bullets #3, #6, and #7 on the above ISOC page. Any approach that injects discriminative intelligence into the network will have difficulties in sustaining at least those three of the values. Finding a new paradigm is, well, hard. Furthermore, once one is found, most people will fight bitterly against it, in the same way the bellheads fought (and are still fighting :-) against the send- receive packet paradigm. How long it took for the packet paradigm to get accepted as main stream? Something like 30 years? (1961 to 1992?) That all said, I also happen to think that in the short/medium term something like HIP or SHIM6+CGA is most probably the right way to go. As I've written already, if properly adopted, something like that will give the current paradigm some 10-20 years more time. It will help us to build the needed new functionality at the transport and up. And, as a very important short-term benefit, it will buy us more flexibility to the routing and addressing system. I think Noel was able to put this very nicely in http://www1.ietf.org/mail-archive/web/architecture-discuss/current/ msg00881.html > Expanding on this a bit, I see HIP as potentially part of an > alternative strategy for how to evolve a large, in-service > architecture. I am frankly dubious about fork-lift upgrades, where > one replaces an entire layer with something else. I think a much > better strategy is a "piece-by-piece" one, where one tries to > deploy some (hopefully well-architected) new pieces that, while > each stands on its own, both in terms of functionality to give you > some new capability, as well as cost/benefit, *together* add up to > a coherent new whole. What I'd like to see would be some kind of "requirements" (gasp) or goals, from two very different points of view: 1. What do the apps and users need? The EME requirement list seems like a reasonably good start. 2. What can be done at the routing and addressing side if the forwarding addresses are freed from their application/transport level identity function, making the whole addressing system much more flexible than it is today. Such "requirement" lists would help us to see what is missing from the current HIP and/or SHIM6+CGA approaches. Given the time we've spent on HIP and SHIM6+CGA (HIP was conceived in 1999, the base ideas which later became CGA and SHIM6 around 2001 if not earlier), I'd be very dubious if we decided to start from scratch in our short/middle term approach. --Pekka Nikander _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Dec 02 19:20:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gqf4K-0001g4-Ct; Sat, 02 Dec 2006 19:18:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gqf4J-0001fo-6G for architecture-discuss@ietf.org; Sat, 02 Dec 2006 19:18:55 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gqf4H-0001on-Np for architecture-discuss@ietf.org; Sat, 02 Dec 2006 19:18:55 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id EFDF64ACA9; Sat, 2 Dec 2006 19:18:50 -0500 (EST) Date: Sat, 2 Dec 2006 19:18:50 -0500 From: John Leslie To: Pekka Nikander Subject: Re: [arch-d] A straw man analysis of why send-receive packet paradigm is unsustainable Message-ID: <20061203001850.GA16503@verdi> References: <45703339.1000804@employees.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Pekka Nikander wrote: > On 1 Dec 2006, at 15:50, Scott W Brim wrote: > >> The EME RG could help here. In theory, it can push some of the cost >> of receiving packets (I agree with you btw) into a setup phase, with >> establishment of trust etc. > > Maybe. Interestingly, if you look at the current set of still- > evolving EME requirements, you'll notice that something like Hi3 > would relatively beautifully fulfil most of them. More generally, to > me it looks like that the EME security requirements will be easier to > reach if we adapt a new cryptographic name space, such as in HIP or > SHIM6 with CGAs. > > But, if we do so, we will give up some of our core values in order to > stay within the current paradigm. By taking the EME/Hi3/overlay/... > route, we retain the basic send-receive packet paradigm while giving > up some parts of the idea of an dumb, open, neutral network. At > minimum, the network is no more dumb as it has the ability to heavily > filter traffic. Nor it is any more open or neutral as some traffic > will be allowed and other not. Frankly, I don't think we ever _had_ a "dumb, open, neutral" network. But we were perhaps "close enough," and that is what I would prefer to get from my upstreams and supply to my customers. > The overall issue is very hard to swallow. I'm sure I'll need to > repeat the point umpteen times before it starts to sink in general in > this community. Basically, we have two choices: > > 1. Give up some of our core values, or Which, for example? > 2. Give up the send-receive packet paradigm. I don't think packet transport is going away. What does Pekka think we _will_ lose? > In my opinion, our almost "holy" long-term challenge is to find a new > paradigm that will be able to sustain as much as possible of our core > values: http://www.isoc.org/pubpolpillar/principles.shtml > > Consider especially the bullets #3, #6, and #7 on the above ISOC > page. I think Pekka means: ] ] (3) The genius of the Internet is that its decentralized architecture ] maximizes individual users' power to choose (or create) and use ] the hardware, software, and services that best meet their needs, ] and if the Internet is to continue to be a platform for innovation ] and creativity, its open, decentralized nature must be preserved. ] ] (6) The social, political, and economic benefits of the Internet are ] substantially diminished by excessively restrictive governmental ] or private controls on computer hardware or software, ] telecommunications infrastructure, or Internet content. ] ] (7) Rewarding and productive use of the Internet depends on the ] ability to trust critical services. > Any approach that injects discriminative intelligence into the network > will have difficulties in sustaining at least those three of the values. Clearly, NATs and firewalls do violence to "openness". For the most part, I consider these to be _at_ the edge, and thus "not my problem". Governments _will_ try to control things -- it's their very nature. We have traditionally looked upon this as the censorship problem -- indistinguishable from "damage" and needing to be "routed around". Private controls are a newer issue. As the "big telcos" have discovered a market, they have largely succeeded in effectively monopolizing the "broadband" market. There is a real danger that these near-monopolies will make government controls more effective. What "critical services" need to be "trusted", and what we mean by "trusted" are pretty open questions... > Finding a new paradigm is, well, hard. Furthermore, once one is > found, most people will fight bitterly against it, I basically agree. Thus, I'm not inclined to look for solutions from "new paradigms". > That all said, I also happen to think that in the short/medium term > something like HIP or SHIM6+CGA is most probably the right way to > go. Neither of these, of course, should be our concern: we should be talking architecture. (There are plenty of other lists where folks can discuss band-aids!) But I must confess to being increasingly irritated by well-intentioned folks discussing the merits of different brands of band-aids on this list. > I think Noel was able to put this very nicely in > http://www1.ietf.org/mail-archive/web/architecture-discuss/current/ > msg00881.html Noel is a good fellow. And, frankly, his discussion of the merits of different brands of band-aids is very good -- better than I could have done. But that discussion still belongs elsewhere: which brands are offered for sale won't be decided here, and the marketplace won't seek our advice on which to buy. >> Expanding on this a bit, I see HIP as potentially part of an >> alternative strategy... No thank you. (Well, not now anyway...) However, speaking for myself only, I'd be happy to see a number of alternatives for identifying hosts being actively developed. I think we'd be poorly advised to (try to) limit the format of host names. > What I'd like to see would be some kind of "requirements" (gasp) or > goals, from two very different points of view: > > 1. What do the apps and users need? The EME requirement list seems > like a reasonably good start. Actually, it seems like a perfectly _dreadful_ start for developing an architecture. I'm willing to stipulate that this is, no doubt, what user say today that they want. An architecture, however, must look to enable _future_ wants. (In particular, use of the term "middlebox" suggests placement of entirely inappropriate intelligence within the routing infrastructure.) > 2. What can be done at the routing and addressing side if the > forwarding addresses are freed from their application/transport level > identity function, making the whole addressing system much more > flexible than it is today. The important point is what responsibilities can be _removed_ from the routing infrastructure. Especially when we hear worries about "meltdown", we should keep lower layers "as simple as possible". > Such "requirement" lists would help us to see what is missing from > the current HIP and/or SHIM6+CGA approaches. We already know what's missing form them: consideration of the overall evolving of an Internet architechure. (Not to criticize them: it wasn't their job.) > Given the time we've spent on HIP and SHIM6+CGA (HIP was conceived > in 1999, the base ideas which later became CGA and SHIM6 around 2001 > if not earlier), I'd be very dubious if we decided to start from > scratch in our short/middle term approach. Wasn't there another list started to talk about immediate steps? -- John Leslie _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Dec 03 18:25:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr0gG-0002OT-OY; Sun, 03 Dec 2006 18:23:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr0gF-0002ON-Tr for architecture-discuss@ietf.org; Sun, 03 Dec 2006 18:23:31 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gr0gA-0001LS-Jz for architecture-discuss@ietf.org; Sun, 03 Dec 2006 18:23:31 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 82CA13405C; Sun, 3 Dec 2006 18:23:26 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 3 Dec 2006 18:23:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] transport layer identifier evolution to support multihoming Date: Sun, 3 Dec 2006 18:23:02 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC01039059@tayexc14.americas.cpqcorp.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] transport layer identifier evolution to support multihoming Thread-Index: AccVW03FC/bbMPZ3TsqrTuo5IhgF6AAzJYSw From: "Bound, Jim" To: "John Day" , "John Leslie" X-OriginalArrivalTime: 03 Dec 2006 23:23:25.0831 (UTC) FILETIME=[084B6170:01C71732] X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > ;-) I know what you mean! lol. But that doesn't mean we=20 > can't give each other a bit of bad time once in awhile. I=20 > expect it! ;-) Just so you know, I am doing as much the same=20 > as you, but trying to keep it light. Agree we are human after all :--) > >Yes completely though I am not clear both ends need the same=20 > >connection-id. >=20 > Well, once you have multiple sources. If one end were=20 > choosing the conn-id, then the other end could end up with=20 > collisions from different sources and it would have to do=20 > more work to keep them disambiguated. He could, but using=20 > two local-ids known to be unambiguous in their local context=20 > ensures that together they are unambiguous in both contexts. Good point but I believe the two ends are mutually exclusive and should not overlap in the name space that would support such as we discuss here. >=20 > (And probably the biggest reason, is it is the traditional=20 > way to solve the problem from long before it was used in TCP. ;-)) That is probably the key reason I would let go if the world will get connection-id don't want to add the cost of re-education for sure. >=20 > >My reasons for end-point-id was it also implies the packet has been=20 > >delivered and not being routed further and how does that=20 > play into our=20 > >model for analysis too? >=20 > Yes, okay. But strictly speaking, the protocol in which=20 > conn-id/endpoint-id occurred never knew it was routedFrom architecture-discuss-bounces@ietf.org Sun Dec 03 18:25:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr0gG-0002OT-OY; Sun, 03 Dec 2006 18:23:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr0gF-0002ON-Tr for architecture-discuss@ietf.org; Sun, 03 Dec 2006 18:23:31 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gr0gA-0001LS-Jz for architecture-discuss@ietf.org; Sun, 03 Dec 2006 18:23:31 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 82CA13405C; Sun, 3 Dec 2006 18:23:26 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 3 Dec 2006 18:23:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] transport layer identifier evolution to support multihoming Date: Sun, 3 Dec 2006 18:23:02 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC01039059@tayexc14.americas.cpqcorp.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] transport layer identifier evolution to support multihoming Thread-Index: AccVW03FC/bbMPZ3TsqrTuo5IhgF6AAzJYSw From: "Bound, Jim" To: "John Day" , "John Leslie" X-OriginalArrivalTime: 03 Dec 2006 23:23:25.0831 (UTC) FILETIME=[084B6170:01C71732] X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > ;-) I know what you mean! lol. But that doesn't mean we=20 > can't give each other a bit of bad time once in awhile. I=20 > expect it! ;-) Just so you know, I am doing as much the same=20 > as you, but trying to keep it light. Agree we are human after all :--) > >Yes completely though I am not clear both ends need the same=20 > >connection-id. >=20 > Well, once you have multiple sources. If one end were=20 > choosing the conn-id, then the other end could end up with=20 > collisions from different sources and it would have to do=20 > more work to keep them disambiguated. He could, but using=20 > two local-ids known to be unambiguous in their local context=20 > ensures that together they are unambiguous in both contexts. Good point but I believe the two ends are mutually exclusive and should not overlap in the name space that would support such as we discuss here. >=20 > (And probably the biggest reason, is it is the traditional=20 > way to solve the problem from long before it was used in TCP. ;-)) That is probably the key reason I would let go if the world will get connection-id don't want to add the cost of re-education for sure. >=20 > >My reasons for end-point-id was it also implies the packet has been=20 > >delivered and not being routed further and how does that=20 > play into our=20 > >model for analysis too? >=20 > Yes, okay. But strictly speaking, the protocol in which=20 > conn-id/endpoint-id occurred never knew it was routedFrom architecture-discuss-bounces@ietf.org Sun Dec 03 18:25:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr0gG-0002OT-OY; Sun, 03 Dec 2006 18:23:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr0gF-0002ON-Tr for architecture-discuss@ietf.org; Sun, 03 Dec 2006 18:23:31 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gr0gA-0001LS-Jz for architecture-discuss@ietf.org; Sun, 03 Dec 2006 18:23:31 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 82CA13405C; Sun, 3 Dec 2006 18:23:26 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 3 Dec 2006 18:23:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] transport layer identifier evolution to support multihoming Date: Sun, 3 Dec 2006 18:23:02 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC01039059@tayexc14.americas.cpqcorp.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] transport layer identifier evolution to support multihoming Thread-Index: AccVW03FC/bbMPZ3TsqrTuo5IhgF6AAzJYSw From: "Bound, Jim" To: "John Day" , "John Leslie" X-OriginalArrivalTime: 03 Dec 2006 23:23:25.0831 (UTC) FILETIME=[084B6170:01C71732] X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > ;-) I know what you mean! lol. But that doesn't mean we=20 > can't give each other a bit of bad time once in awhile. I=20 > expect it! ;-) Just so you know, I am doing as much the same=20 > as you, but trying to keep it light. Agree we are human after all :--) > >Yes completely though I am not clear both ends need the same=20 > >connection-id. >=20 > Well, once you have multiple sources. If one end were=20 > choosing the conn-id, then the other end could end up with=20 > collisions from different sources and it would have to do=20 > more work to keep them disambiguated. He could, but using=20 > two local-ids known to be unambiguous in their local context=20 > ensures that together they are unambiguous in both contexts. Good point but I believe the two ends are mutually exclusive and should not overlap in the name space that would support such as we discuss here. >=20 > (And probably the biggest reason, is it is the traditional=20 > way to solve the problem from long before it was used in TCP. ;-)) That is probably the key reason I would let go if the world will get connection-id don't want to add the cost of re-education for sure. >=20 > >My reasons for end-point-id was it also implies the packet has been=20 > >delivered and not being routed further and how does that=20 > play into our=20 > >model for analysis too? >=20 > Yes, okay. But strictly speaking, the protocol in which=20 > conn-id/endpoint-id occurred never knew it was routed. True it could have been on the same machine under a guest OS via XEN or VMWARE and this is influencing my name too (which I now take back) the transport connection IDs are also important to the upper applications (which I don't suggest we dive into) and the instances of virtualization, clusters, and other forms distributed computing at the services layers evolving will need to alter the physical space that handle the connections and I am thinking can we avoid migrating transport identifiers as doing this with the complete tcp (one example) state today is quite complex. A transport identifier would be far easier to either change or migrate (hand waving here for now clearly) when it is not associated with location coordinates for network path. The win here for this discussion and hopeful outcome is far beyond just the routing core the IAB reported and caused us to begin here (well it was kind a going on before I know). >=20 > Another important property of this class of protocols which I=20 > think needs to be preserved and isn't by SCTP is that all of=20 > their functionality is dedicated to a single instance, a=20 > single connection.=20 Yes SCTP kept that property but an option could enhance where your going and no chance with TCP. > There need not be any cross connection shared state. Whether=20 > you do this in actual implementation is your choice, but you=20 > don't have to. Agree. >=20 > It turns out that this focus/isolation has some very nice=20 > properties when you start putting things together. Agree. >=20 > Later, I have some real work that must get done! Can fully and completely understand I am trying hard to keep up here it is important discussion. /jim > John >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Dec 03 18:25:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr0g8-0002OG-I3; Sun, 03 Dec 2006 18:23:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr0g7-0002O6-H1 for architecture-discuss@ietf.org; Sun, 03 Dec 2006 18:23:23 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gr0g2-0001Ib-7g for architecture-discuss@ietf.org; Sun, 03 Dec 2006 18:23:23 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 277323405C; Sun, 3 Dec 2006 18:23:18 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 3 Dec 2006 18:23:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Some notes about HIP and SHIM6 (was Re: On identifiers:w hat is virtual and what...) Date: Sun, 3 Dec 2006 18:22:36 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC01039054@tayexc14.americas.cpqcorp.net> In-Reply-To: <20061201204402.53929872D7@mercury.lcs.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Some notes about HIP and SHIM6 (was Re: On identifiers:w hat is virtual and what...) Thread-Index: AccViY3Gh75O40u0RA+gWnHS+HGnewAoaykg From: "Bound, Jim" To: "Noel Chiappa" , X-OriginalArrivalTime: 03 Dec 2006 23:23:17.0518 (UTC) FILETIME=[0356EAE0:01C71732] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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: =20 > Another important property of this class of protocols which I=20 > think needs to be preserved and isn't by SCTP is that all of=20 > their functionality is dedicated to a single instance, a=20 > single connection.=20 Yes SCTP kept that property but an option could enhance where your going and no chance with TCP. > There need not be any cross connection shared state. Whether=20 > you do this in actual implementation is your choice, but you=20 > don't have to. Agree. >=20 > It turns out that this focus/isolation has some very nice=20 > properties when you start putting things together. Agree. >=20 > Later, I have some real work that must get done! Can fully and completely understand I am trying hard to keep up here it is important discussion. /jim > John >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Dec 03 18:25:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr0g8-0002OG-I3; Sun, 03 Dec 2006 18:23:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr0g7-0002O6-H1 for architecture-discuss@ietf.org; Sun, 03 Dec 2006 18:23:23 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gr0g2-0001Ib-7g for architecture-discuss@ietf.org; Sun, 03 Dec 2006 18:23:23 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 277323405C; Sun, 3 Dec 2006 18:23:18 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 3 Dec 2006 18:23:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Some notes about HIP and SHIM6 (was Re: On identifiers:w hat is virtual and what...) Date: Sun, 3 Dec 2006 18:22:36 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC01039054@tayexc14.americas.cpqcorp.net> In-Reply-To: <20061201204402.53929872D7@mercury.lcs.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Some notes about HIP and SHIM6 (was Re: On identifiers:w hat is virtual and what...) Thread-Index: AccViY3Gh75O40u0RA+gWnHS+HGnewAoaykg From: "Bound, Jim" To: "Noel Chiappa" , X-OriginalArrivalTime: 03 Dec 2006 23:23:17.0518 (UTC) FILETIME=[0356EAE0:01C71732] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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: =20 > Another important property of this class of protocols which I=20 > think needs to be preserved and isn't by SCTP is that all of=20 > their functionality is dedicated to a single instance, a=20 > single connection.=20 Yes SCTP kept that property but an option could enhance where your going and no chance with TCP. > There need not be any cross connection shared state. Whether=20 > you do this in actual implementation is your choice, but you=20 > don't have to. Agree. >=20 > It turns out that this focus/isolation has some very nice=20 > properties when you start putting things together. Agree. >=20 > Later, I have some real work that must get done! Can fully and completely understand I am trying hard to keep up here it is important discussion. /jim > John >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Dec 03 18:25:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr0g8-0002OG-I3; Sun, 03 Dec 2006 18:23:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr0g7-0002O6-H1 for architecture-discuss@ietf.org; Sun, 03 Dec 2006 18:23:23 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gr0g2-0001Ib-7g for architecture-discuss@ietf.org; Sun, 03 Dec 2006 18:23:23 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 277323405C; Sun, 3 Dec 2006 18:23:18 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 3 Dec 2006 18:23:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Some notes about HIP and SHIM6 (was Re: On identifiers:w hat is virtual and what...) Date: Sun, 3 Dec 2006 18:22:36 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC01039054@tayexc14.americas.cpqcorp.net> In-Reply-To: <20061201204402.53929872D7@mercury.lcs.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Some notes about HIP and SHIM6 (was Re: On identifiers:w hat is virtual and what...) Thread-Index: AccViY3Gh75O40u0RA+gWnHS+HGnewAoaykg From: "Bound, Jim" To: "Noel Chiappa" , X-OriginalArrivalTime: 03 Dec 2006 23:23:17.0518 (UTC) FILETIME=[0356EAE0:01C71732] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Interesting and well articulated. My conern is that for us to get to the end state for a model to build architecture can we expedite this process by not overloading the identifier? Right now I think not overloading identifier is a fast path for us? /jim=20 > -----Original Message----- > From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu]=20 > Sent: Friday, December 01, 2006 3:44 PM > To: architecture-discuss@ietf.org > Cc: jnc@mercury.lcs.mit.edu > Subject: Re: [arch-d] Some notes about HIP and SHIM6 (was Re:=20 > On identifiers:w hat is virtual and what...) >=20 > > From: "Fergie" >=20 > > I wonder if we happen to be using the term "overloaded"=20 > a little too > > liberally to have a useful dialogue? > > What is overloaded? ... perhaps it is time we revisit=20 > what what that > > might actually mean. >=20 > OK, here's my take. I feel that it does have a pretty=20 > specific, defined meaning (and it's not identical to the=20 > general English meaning of "overload", alas; just as "force"=20 > to an engineer means a vector, not a general concept). > My sense is that system architects have taken the term,=20 > pretty directly, from the computer language people. >=20 > There, an operator/etc is said to be "overloaded" if it is,=20 > in isolation, ambiguous, and one needs to consider the=20 > context to know what it means. A classic example is the "*"=20 > operator in C, which might mean either "multiply", or=20 > "indirect through pointer". (Just for extra grins, in C one=20 > used to be able to say "a =3D *p" and "a =3D* p", and they meant=20 > totally different things! So that "a=3D*p" really was formally=20 > ambiguous.) >=20 > The extension to the system architectural world is pretty=20 > straightforward. > So, to me an identifier is "overloaded" if it can be used for=20 > a variety of entirely different purposes; e.g. an IPvN=20 > address can either identify an entity at one end of an=20 > end-end communication (as it does in the TCP, specifically in=20 > the checksum), or it can identify a thing (interface, in the=20 > usual case) that the system of routers will deliver a packet=20 > to. Use of IPv6 addresses to serve two different functions,=20 > in SHIM6, is overloading (in the technical sense) of IPv6=20 > addresses. Etc, etc. >=20 > Noel >=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 Sun Dec 03 18:25:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr0g8-0002OB-Bk; Sun, 03 Dec 2006 18:23:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr0g6-0002O1-VP for architecture-discuss@ietf.org; Sun, 03 Dec 2006 18:23:22 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gr0g1-0001IW-N4 for architecture-discuss@ietf.org; Sun, 03 Dec 2006 18:23:22 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 6863B34042; Sun, 3 Dec 2006 18:23:17 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1e-discuss>, List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Interesting and well articulated. My conern is that for us to get to the end state for a model to build architecture can we expedite this process by not overloading the identifier? Right now I think not overloading identifier is a fast path for us? /jim=20 > -----Original Message----- > From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu]=20 > Sent: Friday, December 01, 2006 3:44 PM > To: architecture-discuss@ietf.org > Cc: jnc@mercury.lcs.mit.edu > Subject: Re: [arch-d] Some notes about HIP and SHIM6 (was Re:=20 > On identifiers:w hat is virtual and what...) >=20 > > From: "Fergie" >=20 > > I wonder if we happen to be using the term "overloaded"=20 > a little too > > liberally to have a useful dialogue? > > What is overloaded? ... perhaps it is time we revisit=20 > what what that > > might actually mean. >=20 > OK, here's my take. I feel that it does have a pretty=20 > specific, defined meaning (and it's not identical to the=20 > general English meaning of "overload", alas; just as "force"=20 > to an engineer means a vector, not a general concept). > My sense is that system architects have taken the term,=20 > pretty directly, from the computer language people. >=20 > There, an operator/etc is said to be "overloaded" if it is,=20 > in isolation, ambiguous, and one needs to consider the=20 > context to know what it means. A classic example is the "*"=20 > operator in C, which might mean either "multiply", or=20 > "indirect through pointer". (Just for extra grins, in C one=20 > used to be able to say "a =3D *p" and "a =3D* p", and they meant=20 > totally different things! So that "a=3D*p" really was formally=20 > ambiguous.) >=20 > The extension to the system architectural world is pretty=20 > straightforward. > So, to me an identifier is "overloaded" if it can be used for=20 > a variety of entirely different purposes; e.g. an IPvN=20 > address can either identify an entity at one end of an=20 > end-end communication (as it does in the TCP, specifically in=20 > the checksum), or it can identify a thing (interface, in the=20 > usual case) that the system of routers will deliver a packet=20 > to. Use of IPv6 addresses to serve two different functions,=20 > in SHIM6, is overloading (in the technical sense) of IPv6=20 > addresses. Etc, etc. >=20 > Noel >=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 Sun Dec 03 18:25:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr0g8-0002OB-Bk; Sun, 03 Dec 2006 18:23:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr0g6-0002O1-VP for architecture-discuss@ietf.org; Sun, 03 Dec 2006 18:23:22 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gr0g1-0001IW-N4 for architecture-discuss@ietf.org; Sun, 03 Dec 2006 18:23:22 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 6863B34042; Sun, 3 Dec 2006 18:23:17 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1e-discuss>, List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Interesting and well articulated. My conern is that for us to get to the end state for a model to build architecture can we expedite this process by not overloading the identifier? Right now I think not overloading identifier is a fast path for us? /jim=20 > -----Original Message----- > From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu]=20 > Sent: Friday, December 01, 2006 3:44 PM > To: architecture-discuss@ietf.org > Cc: jnc@mercury.lcs.mit.edu > Subject: Re: [arch-d] Some notes about HIP and SHIM6 (was Re:=20 > On identifiers:w hat is virtual and what...) >=20 > > From: "Fergie" >=20 > > I wonder if we happen to be using the term "overloaded"=20 > a little too > > liberally to have a useful dialogue? > > What is overloaded? ... perhaps it is time we revisit=20 > what what that > > might actually mean. >=20 > OK, here's my take. I feel that it does have a pretty=20 > specific, defined meaning (and it's not identical to the=20 > general English meaning of "overload", alas; just as "force"=20 > to an engineer means a vector, not a general concept). > My sense is that system architects have taken the term,=20 > pretty directly, from the computer language people. >=20 > There, an operator/etc is said to be "overloaded" if it is,=20 > in isolation, ambiguous, and one needs to consider the=20 > context to know what it means. A classic example is the "*"=20 > operator in C, which might mean either "multiply", or=20 > "indirect through pointer". (Just for extra grins, in C one=20 > used to be able to say "a =3D *p" and "a =3D* p", and they meant=20 > totally different things! So that "a=3D*p" really was formally=20 > ambiguous.) >=20 > The extension to the system architectural world is pretty=20 > straightforward. > So, to me an identifier is "overloaded" if it can be used for=20 > a variety of entirely different purposes; e.g. an IPvN=20 > address can either identify an entity at one end of an=20 > end-end communication (as it does in the TCP, specifically in=20 > the checksum), or it can identify a thing (interface, in the=20 > usual case) that the system of routers will deliver a packet=20 > to. Use of IPv6 addresses to serve two different functions,=20 > in SHIM6, is overloading (in the technical sense) of IPv6=20 > addresses. Etc, etc. >=20 > Noel >=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 Sun Dec 03 18:25:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr0g8-0002OB-Bk; Sun, 03 Dec 2006 18:23:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr0g6-0002O1-VP for architecture-discuss@ietf.org; Sun, 03 Dec 2006 18:23:22 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gr0g1-0001IW-N4 for architecture-discuss@ietf.org; Sun, 03 Dec 2006 18:23:22 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 6863B34042; Sun, 3 Dec 2006 18:23:17 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 3 Dec 2006 18:23:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Some notes about HIP and SHIM6 (was Re: On identifiers:what is virtual and what...) Date: Sun, 3 Dec 2006 18:22:33 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC01039053@tayexc14.americas.cpqcorp.net> In-Reply-To: <20061201173750.735E5872F6@mercury.lcs.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Some notes about HIP and SHIM6 (was Re: On identifiers:what is virtual and what...) Thread-Index: AccVb62YGSKPRmevSgmbrJcnzjfgqQAujF5Q From: "Bound, Jim" To: "Noel Chiappa" , X-OriginalArrivalTime: 03 Dec 2006 23:23:16.0768 (UTC) FILETIME=[02E47A00:01C71732] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Agree with all of Noels points and thoughts in this thread response and for NAT we might want to look at the NAP work in v6ops as suggestion in process now. But the below I want to stress again. > > I consider it more likely that the results the NSF and=20 > FP7 funded > > research will mature before the IETF community gets to the stage >=20 > I'm dubious about these academic projects really producing=20 > something that is, in itself, viable as a replacement. The=20 > issues of interoperability, and the cost/benefit issues that=20 > drive the success of things in the Real World, have to be=20 > factored in at a higher level that research efforts (which=20 > really have different goals) are really able to do. I feel the same way. I have to track this work and have come to the same conclusion. Well stated. > Well, exactly how drastic the lower-layer redoing will be is=20 > still open; it hasn't really gotten a lot of thought. Even=20 > attempts to, e.g., deploy a second copy of IPv6 (to allow=20 > reuse of existing hardware/code) below an end-end IPv6 turn=20 > out to be pretty difficult, though. >=20 > > Again, I am not too hopeful about the IETF community=20 > ever getting there. >=20 > Well, we'll see. Things are heading for trouble, and if the=20 > IETF can't get with it, the affected parties (e.g. ISP's)=20 > will simply find some other forum in which to tackle the problem. I fully agree and very healthy warning to us IMHO. I am tracking the work in IPsphere, DARPA projects, EU research projects, etc. If we do not solve the essential problem of routing for billions of devices and sensors, and being seamless mobile (meaning their location changes in relation to provider prefix space) over some "core" Internet (not Intranet) network model it will be taken out of the IETF hands. I will not venture to postulate how but the market will find a way to not melt down. /jim /jim _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss 830); Sun, 3 Dec 2006 18:23:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Some notes about HIP and SHIM6 (was Re: On identifiers:what is virtual and what...) Date: Sun, 3 Dec 2006 18:22:33 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC01039053@tayexc14.americas.cpqcorp.net> In-Reply-To: <20061201173750.735E5872F6@mercury.lcs.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Some notes about HIP and SHIM6 (was Re: On identifiers:what is virtual and what...) Thread-Index: AccVb62YGSKPRmevSgmbrJcnzjfgqQAujF5Q From: "Bound, Jim" To: "Noel Chiappa" , X-OriginalArrivalTime: 03 Dec 2006 23:23:16.0768 (UTC) FILETIME=[02E47A00:01C71732] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Agree with all of Noels points and thoughts in this thread response and for NAT we might want to look at the NAP work in v6ops as suggestion in process now. But the below I want to stress again. > > I consider it more likely that the results the NSF and=20 > FP7 funded > > research will mature before the IETF community gets to the stage >=20 > I'm dubious about these academic projects really producing=20 > something that is, in itself, viable as a replacement. The=20 > issues of interoperability, and the cost/benefit issues that=20 > drive the success of things in the Real World, have to be=20 > factored in at a higher level that research efforts (which=20 > really have different goals) are really able to do. I feel the same way. I have to track this work and have come to the same conclusion. Well stated. > Well, exactly how drastic the lower-layer redoing will be is=20 > still open; it hasn't really gotten a lot of thought. Even=20 > attempts to, e.g., deploy a second copy of IPv6 (to allow=20 > reuse of existing hardware/code) below an end-end IPv6 turn=20 > out to be pretty difficult, though. >=20 > > Again, I am not too hopeful about the IETF community=20 > ever getting there. >=20 > Well, we'll see. Things are heading for trouble, and if the=20 > IETF can't get with it, the affected parties (e.g. ISP's)=20 > will simply find some other forum in which to tackle the problem. I fully agree and very healthy warning to us IMHO. I am tracking the work in IPsphere, DARPA projects, EU research projects, etc. If we do not solve the essential problem of routing for billions of devices and sensors, and being seamless mobile (meaning their location changes in relation to provider prefix space) over some "core" Internet (not Intranet) network model it will be taken out of the IETF hands. I will not venture to postulate how but the market will find a way to not melt down. /jim /jim _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss 830); Sun, 3 Dec 2006 18:23:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Some notes about HIP and SHIM6 (was Re: On identifiers:what is virtual and what...) Date: Sun, 3 Dec 2006 18:22:33 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC01039053@tayexc14.americas.cpqcorp.net> In-Reply-To: <20061201173750.735E5872F6@mercury.lcs.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Some notes about HIP and SHIM6 (was Re: On identifiers:what is virtual and what...) Thread-Index: AccVb62YGSKPRmevSgmbrJcnzjfgqQAujF5Q From: "Bound, Jim" To: "Noel Chiappa" , X-OriginalArrivalTime: 03 Dec 2006 23:23:16.0768 (UTC) FILETIME=[02E47A00:01C71732] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Agree with all of Noels points and thoughts in this thread response and for NAT we might want to look at the NAP work in v6ops as suggestion in process now. But the below I want to stress again. > > I consider it more likely that the results the NSF and=20 > FP7 funded > > research will mature before the IETF community gets to the stage >=20 > I'm dubious about these academic projects really producing=20 > something that is, in itself, viable as a replacement. The=20 > issues of interoperability, and the cost/benefit issues that=20 > drive the success of things in the Real World, have to be=20 > factored in at a higher level that research efforts (which=20 > really have different goals) are really able to do. I feel the same way. I have to track this work and have come to the same conclusion. Well stated. > Well, exactly how drastic the lower-layer redoing will be is=20 > still open; it hasn't really gotten a lot of thought. Even=20 > attempts to, e.g., deploy a second copy of IPv6 (to allow=20 > reuse of existing hardware/code) below an end-end IPv6 turn=20 > out to be pretty difficult, though. >=20 > > Again, I am not too hopeful about the IETF community=20 > ever getting there. >=20 > Well, we'll see. Things are heading for trouble, and if the=20 > IETF can't get with it, the affected parties (e.g. ISP's)=20 > will simply find some other forum in which to tackle the problem. I fully agree and very healthy warning to us IMHO. I am tracking the work in IPsphere, DARPA projects, EU research projects, etc. If we do not solve the essential problem of routing for billions of devices and sensors, and being seamless mobile (meaning their location changes in relation to provider prefix space) over some "core" Internet (not Intranet) network model it will be taken out of the IETF hands. I will not venture to postulate how but the market will find a way to not melt down. /jim /jim _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Dec 03 21:40:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr3it-00041t-4o; Sun, 03 Dec 2006 21:38:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr3ir-00041o-M3 for architecture-discuss@ietf.org; Sun, 03 Dec 2006 21:38:25 -0500 Received: from web58708.mail.re1.yahoo.com ([66.196.100.185]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gr3iq-000371-AJ for architecture-discuss@ietf.org; Sun, 03 Dec 2006 21:38:25 -0500 Received: (qmail 25552 invoked by uid 60001); 4 Dec 2006 02:38:07 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=YBv9fRjpszJ3vhL49SfE8WfYYDuLzEdZW3cccQrxjpIN6Zrt7pqWGngWgi3eVtZ/Ix0zhoXNfyBNW9Syeg1zopPpYA4LqgH+atFk/WtJNNQSOWdIExMq8TG5m2VUKpXMuzX++izShbZwRpZ+V4Jl8Hh8DpI7VWdd7gsfBCH43Qc=; X-YMail-OSG: aESl1IIVM1nlorKToRRBoOBQE0CKUYLP5yDspGCx Received: from [74.111.124.141] by web58708.mail.re1.yahoo.com via HTTP; Sun, 03 Dec 2006 18:38:06 PST Date: Sun, 3 Dec 2006 18:38:06 -0800 (PST) From: Peter Sherbin Subject: Re: [arch-d] A straw man analysis of why send-receive packet paradigm is unsustainable To: Pekka Nikander , architecture-discuss@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <57456.24148.qm@web58708.mail.re1.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > network based on the send-receive packet paradigm is unsustainable in > the face of large amounts of malicious players. What if nodes are protected so an outsider can not make them zombie. This leaves a sender with only a single uplink to send. If a sender pays for each sent packet she would send only when her need justifies associated costs. Because there are many senders a receiver would still get a large number of packets. To minimize decision costs a receiver must be able to set "unwanted sender" criteria to automatically discard packets from such senders. >anyone can send anything to anybody, and the network will do its best to get that through Here is how the paradigm should work economically (=physically=logically): Bob sends to Alice holiday greetings of 100KB for which he pays e.g. 0.0001 dollars Alice sends to Bob a movie present of 3GB and she pays 3.00 dollars Slowly but surely providers are moving towards the usage based charges. For now they bill total GB of upload + download. This unjustly penalizes heavy downloaders. Nevertheless usage based pricing is a way to go. Thanks, Peter --- Pekka Nikander wrote: > [This is _really_ long term. If you are not interested in 10+ years > things, don't bother reading.] > > It is a well established view that smart ends and a dumb, open, > neutral network are good, for a number of well-known reasons. Herein > I present a claim that if we want to retain that approach, we will > have to give up the current send-receive packet paradigm, sooner or > later. While there are ample experimental evidence for my claim, I > will skip that and focus on a techno-economic analysis. > > > The current Internet is based on what I call the send-receive packet > paradigm. That is, the fundamental primitives in the network are > "send" and "receive", on the packet level. More importantly, what is > built in into this paradigm is the idea that anyone can send anything > to anybody, and the network will do its best to get that through. > While that is very simple and well known, let me dissect it a little > bit: > > 1. The paradigm implies that any packet sent is delivered, or at > least tried to get delivered. > > 2. The paradigm implies that the sender is free to select the > receiver. Sender's consent. > > 3. The paradigm implies that the receiver need to process, at least > minimally, any traffic sent to it by any sender. > > Of those, the last one appears to be the most important one. Think > about it! > > > The fundamental reason why I claim, below, that the current paradigm > is unsustainable, in the longer run, is the following: > > Sending packets is cheaper than receiving and processing them > > I think that the claim could probably be based on physics, entropy, > and energy, but I won't go into that; I'm not an expert there. > Instead, let's consider two well known examples: spam and DDoS. > > Sending spam costs the sender relatively little, even if they are not > using zombie farms. They basically create a single message, and send > it repeatedly, often even allowing the network to replicate it. > Receiving, on the other hand, is expensive. The receiver must > decide, somehow, whether the received message is spam and should be > ignored, or not. To make the decision, quite a lot of processing is > needed, if not by the machines, then by the user. > > In a DDoS attack, sending is even cheaper to the attacker due to > utilising zombie farms. The receiver pays heavily, both on > legitimate traffic lost due to congestion and on even minimally > processing those attack packets that actually reach the attacked > system. More importantly, however, if we consider the packet level > we can see the same pattern as in the spam case. The attacker > doesn't need to spend much energy in generating packet contents; in > many cases the packets can contain whatever garbage. On the other > hand, the receiver needs to spend at least some energy in deciding > whether the received packet is legitimate or not. > > That leads to the following corollary: > > Receiving packets is expensive because of the associated decision > process > > Note that it is possible to send mindlessly, without needing to make > any decisions at the packet level. The malicious send can make all > the decisions in advance. > > > The implication is clear: The original, open, neutral end-to-end > network based on the send-receive packet paradigm is unsustainable in > the face of large amounts of malicious players. > > Note that this is fundamental. It is impossible to allow anyone to > send any packets to anyone, without some people being able to abuse > it in a way or another. Conversely, if we want to also in the more > distant future have a network that is built on the core values of the > original Internet, we need to give up its fundamental technical > foundation, the send-receive packet paradigm. > > > I think what's above is enough for a single message. I'll leave the > wider implications and options for action to another message. > > --Pekka Nikander > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Dec 03 21:47:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr3rA-00086F-Ta; Sun, 03 Dec 2006 21:47:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr3r6-0007z8-Um for architecture-discuss@ietf.org; Sun, 03 Dec 2006 21:46:56 -0500 Received: from web58714.mail.re1.yahoo.com ([66.196.100.191]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gr3r5-0004XF-Mv for architecture-discuss@ietf.org; Sun, 03 Dec 2006 21:46:56 -0500 Received: (qmail 48795 invoked by uid 60001); 4 Dec 2006 02:46:55 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=R2WAYuFVTvEYRxjtGuBZEsZR1dPvuCkWNeY9JLVZi3zEXpHEMJ+NySRKVWBp0JexFJ+hPpnwMOk7CN2DcbIctw5MGV6+/b6Thr90ysxOOBZeKmtyQNUtvMFwH358dxQAL0D193jQCHMq1NLFaWEHPhnqyVu7TYNJe9lb0R3c4A0=; X-YMail-OSG: wjgZLW4VM1l_CJm5jI8jxSkgTMxz6X3V6DZs.DO0XeTbLxNeAw.cW9CMVRRqjwOegeaaEmJG5OHzP3KNqVMnnRJYf5IGAD5w4b2e2u6Rdw1HOOCC2AK4fn4po2YBaM8XvRZ2GU2b.RTfnw-- Received: from [74.111.124.141] by web58714.mail.re1.yahoo.com via HTTP; Sun, 03 Dec 2006 18:46:55 PST Date: Sun, 3 Dec 2006 18:46:55 -0800 (PST) From: Peter Sherbin Subject: Re: [arch-d] A straw man analysis of why send-receive packet paradigm is unsustainable To: Andrew McGregor , Pekka Nikander In-Reply-To: <40A1808B-29A6-4F94-BC6B-84F1F64DD156@indranet.co.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <581693.48211.qm@web58714.mail.re1.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > Transmission of a packet *increases* the entropy of the network. > > Reception *decreases* the entropy of the network. Network entropy applies to its physical elements only. I.e. wires and nodes get warm while working. Bits oder does not change by itself as long as the strength of the pulse is preserved. As somebody rightly noted data has no mass. Thanks, Peter --- Andrew McGregor wrote: > > On 01/12/2006, at 10:37 PM, Pekka Nikander wrote: > > > The fundamental reason why I claim, below, that the current > > paradigm is unsustainable, in the longer run, is the following: > > > > Sending packets is cheaper than receiving and processing them > > > > I think that the claim could probably be based on physics, entropy, > > and energy, but I won't go into that; I'm not an expert there. > > It's a very simple argument: > > Transmission of a packet *increases* the entropy of the network. > > Reception *decreases* the entropy of the network. > > The second law of thermodynamics (the same one that prohibits > perpetual motion machines) guarantees that the latter operation is > more expensive than the former. TANSTAAFL. > > Practical considerations imply that the actual cost of reception is > many times higher than in transmission; in wireless systems, it can > be millions of times higher. > > QED. > > Andrew > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss > ____________________________________________________________________________________ Want to start your own business? Learn how on Yahoo! Small Business. http://smallbusiness.yahoo.com/r-index _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Dec 03 21:47:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr3ri-0000jN-6C; Sun, 03 Dec 2006 21:47:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr3rg-0000j6-Bg for architecture-discuss@ietf.org; Sun, 03 Dec 2006 21:47:32 -0500 Received: from [203.167.203.10] (helo=enso.acheron.indranet.co.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gr3rd-0004ae-Ne for architecture-discuss@ietf.org; Sun, 03 Dec 2006 21:47:32 -0500 Received: from [127.0.0.1] (IDENT:root@enso.acheron.indranet.co.nz [192.168.1.1]) by enso.acheron.indranet.co.nz (8.9.3-20030919/8.9.3) with ESMTP id PAA13569; Mon, 4 Dec 2006 15:47:15 +1300 In-Reply-To: <57456.24148.qm@web58708.mail.re1.yahoo.com> References: <57456.24148.qm@web58708.mail.re1.yahoo.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew McGregor Subject: Re: [arch-d] A straw man analysis of why send-receive packet paradigm is unsustainable Date: Mon, 4 Dec 2006 15:48:21 +1300 To: Peter Sherbin X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Pekka Nikander , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On 04/12/2006, at 3:38 PM, Peter Sherbin wrote: > > Slowly but surely providers are moving towards the usage based > charges. For now they > bill total GB of upload + download. This unjustly penalizes heavy > downloaders. > Nevertheless usage based pricing is a way to go. > Living in a country where this is presently the norm and we are moving away from it, this is NOT the way to go. Why? What happens if your machine does get taken over as part of a botnet or whatever, and it sends flat out for six weeks until you get your bill and notice? How about a bill for $40,000.00? And the ISP will ignore your plea that the machine was virus infected... because after all, it did send the traffic, and that was the deal. This is only the way things are going because the telcos got into the internet. It isn't how things should be. I don't want to be monitoring my net usage by the byte, and having to check every day that something hasn't happened. That reduces the utility of the network by a major fraction, IMO. Andrew _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Dec 03 23:23:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr5K9-0005j1-KO; Sun, 03 Dec 2006 23:21:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr5K7-0005i1-Pv for architecture-discuss@ietf.org; Sun, 03 Dec 2006 23:20:59 -0500 Received: from web58709.mail.re1.yahoo.com ([66.196.100.186]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gr5K6-0000gV-Ia for architecture-discuss@ietf.org; Sun, 03 Dec 2006 23:20:59 -0500 Received: (qmail 21171 invoked by uid 60001); 4 Dec 2006 04:20:53 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=WWsDsISIhov1b/oxSQkKrVO7BgRiwpSe9N0XM0VFBU2bJ1YIDltCNDwGZbcVfZbcGF9k4cjR8/OXYxg+0uDJ3hE8imUc6dQvm50nyeXb6EyAYwM0b99wkwc11VIanJIKjcdv3l+egbmOwA85MlzKdyc/OumFR5SkYKqMZkuCsck=; X-YMail-OSG: 6CSvZVcVM1njaG4k2LfsnXGYnNIhQDHRLsmJglEQWlApUWX9qbUIzxVPc0ykHVbbX7AX6Jlux_yC5W7qwjujDnV9ADOB1jNG6gxTqf.e805WanDXfD0o_FoeU.vPD47geYf2hixmuJi1MAE5ybeehQYmC66PydxPlV0i0Oo3WGvM.LkNl7u0kzfecC4- Received: from [74.111.124.141] by web58709.mail.re1.yahoo.com via HTTP; Sun, 03 Dec 2006 20:20:53 PST Date: Sun, 3 Dec 2006 20:20:53 -0800 (PST) From: Peter Sherbin Subject: Re: [arch-d] A straw man analysis of why send-receive packet paradigm is unsustainable To: Andrew McGregor In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <312248.17498.qm@web58709.mail.re1.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Pekka Nikander , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org This is a plain evidence of the Internet beign marketed while the product is unsafe. On the other side there is an opportunity to sell security. > your bill and notice? How about a bill for $40,000.00? And the ISP > will ignore your plea that the machine was virus infected... because > after all, it did send the traffic, and that was the deal. That was not the deal if I can not control my machine. I should keep ISP responsible for letting the thief into my premises. > I don't want to be monitoring my net usage by the byte, and having to check every day that something hasn't happened. And I do. For ISP money is in bits sent by users. Thanks, Peter --- Andrew McGregor wrote: > > On 04/12/2006, at 3:38 PM, Peter Sherbin wrote: > > > > > Slowly but surely providers are moving towards the usage based > > charges. For now they > > bill total GB of upload + download. This unjustly penalizes heavy > > downloaders. > > Nevertheless usage based pricing is a way to go. > > > > Living in a country where this is presently the norm and we are > moving away from it, this is NOT the way to go. > > Why? What happens if your machine does get taken over as part of a > botnet or whatever, and it sends flat out for six weeks until you get > your bill and notice? How about a bill for $40,000.00? And the ISP > will ignore your plea that the machine was virus infected... because > after all, it did send the traffic, and that was the deal. > > This is only the way things are going because the telcos got into the > internet. It isn't how things should be. I don't want to be > monitoring my net usage by the byte, and having to check every day > that something hasn't happened. That reduces the utility of the > network by a major fraction, IMO. > > Andrew > ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Dec 04 03:40:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr9LE-00077j-TY; Mon, 04 Dec 2006 03:38:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gr9LE-00077T-0K for architecture-discuss@ietf.org; Mon, 04 Dec 2006 03:38:24 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gr9LC-00062z-A1 for architecture-discuss@ietf.org; Mon, 04 Dec 2006 03:38:23 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id B8F82213110 for ; Mon, 4 Dec 2006 10:38:03 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 4E8C42130C1 for ; Mon, 4 Dec 2006 10:38:03 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <9E9194B1-3AAD-492E-ADCD-73092A237C77@nomadiclab.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: architecture-discuss@ietf.org From: Pekka Nikander Date: Mon, 4 Dec 2006 10:38:00 +0200 X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Subject: [arch-d] A summary of Pekka's position so far X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I've been one of the more vocal people on this discussion, apparently presenting opinions that may appear self-contradicting to some people. I've posted almost 30 messages, and altogether there's been some 450 messages during the last month. Hence, a summary may help. As I have a position that clearly differs from what some other people have, I try to summarise only my position. Executive summary ----------------- First and foremost, I think that we need to work on BOTH a short/ medium term solution AND on the longer term solution space in parallel, both tasks continuously learning from each other. Form the short/medium term point of view, I think something along the lines of HIP and/or SHIM6+CGA would help with a large number of current problems, including the scalability of the routing system and dealing with middle boxes; see below. From the longer term point of view, I'm afraid that we will need to look at completely new paradigms, leaving back, at minimum, some of our *assumptions* about the send-receive packet *semantics*. As a second point, I have made a number of architectural observations, related to naming, flat name spaces, and mobility and multi-homing; see the end of this message. Of those, I think the one on mobility and multi-homing is the most important one, as it apparently appears counter-intuitive to many people. Personally, I have a very good feeling that we've managed to start this discussion. So far the discussion has ranged far and widely, and I believe such wider mental exploration is still needed. However, simultaneously, it starts to look like to me that we may be able to identify some more focused threads amongst them all. HIP / SHIM6 remedies --------------------- Adding a new name space according to the HIP or SHIM6+CGA principles would help with at least the following issues, and probably more ---------------------------------- +---------------------------------------+ Issue | Why HIP / SHIM6+CGA may help | ================================== +=======================================+ Scalability of the routing system | Separation of addressing from naming, | | allowing more flexible addressing | ---------------------------------- +---------------------------------------+ Mobility and Multi-homing | A new natural layer of indirection | ---------------------------------- +---------------------------------------+ NAT, IPv4/v6 interop, etc. | A name space above IPv4/v6 addresses | ---------------------------------- +---------------------------------------+ Some forms of bad traffic | Cryptographic names allowing better | | control on what to receive | ---------------------------------- +---------------------------------------+ Sub-network naming and mobility | Ability to delegate & thereby | | aggregate* names | ---------------------------------- +---------------------------------------+ Flexible application naming | Ability to delegate & aggregate | ---------------------------------- +---------------------------------------+ *) Note that the name aggregation (via delegation) as implementable with HIP / SHIM6+CGA is very different from current address aggregation. In detail, my main points so far have been the following ones. 1. Need for working towards BOTH a short/medium term AND long term solutions ------------------------------------------------------------------------ ---- The systems theoretic observation that the IETF, as an organisation, may be addicted to short-term solutions. There is nothing evil or even bad implied by this observation; I merely tried to state what I think seeing. See http://www1.ietf.org/mail-archive/web/architecture-discuss/ current/msg00443.html If that observation is true, the corollary is that we will need to work very consciously at two different tracks at the same time: 1. One track aiming for a short/medium term "good band aid" solution. Time span: 3-8 years. 2. One track aiming for a long term "fundamental" solution. Time span: 10+ years. See http://www1.ietf.org/mail-archive/web/architecture-discuss/ current/msg00461.html In working on the different solutions, we need to understand that parts of the network evolve at different rates: See http://www1.ietf.org/mail-archive/web/architecture-discuss/ current/msg00479.html and http://www1.ietf.org/mail-archive/web/architecture-discuss/ current/msg00797.html And finally, I made a fundamental observation w.r.t our current thinking and systems: the techno-economic reality is that the way the Internet used to work will never again come back. See http://www1.ietf.org/mail-archive/web/architecture-discuss/ current/msg00873.html 2. Identifier/locator split a la HIP/SHIM6+CGA would be good short/ medium term solution ------------------------------------------------------------------------ -------------- Some background reasoning why the addressing and routing systems are interrelated: http://www1.ietf.org/mail-archive/web/architecture-discuss/current/ msg00662.html Why some kind of an identifier/locator split (like HIP or SHIM6) would help in the short/medium term problem: http://www1.ietf.org/mail-archive/web/architecture-discuss/current/ msg00837.html http://www1.ietf.org/mail-archive/web/architecture-discuss/current/ msg00872.html 3. Observations related mostly to the long term solution space -------------------------------------------------------------- A. What naming layers there should be: http://www1.ietf.org/mail- archive/web/architecture-discuss/current/msg00657.html B. Thoughts about flat identifier spaces and their scalability: http://www1.ietf.org/mail-archive/web/architecture-discuss/current/ msg00779.html C. Mobility and multi-homing are essentially similar from an architectural PoV: http://www1.ietf.org/mail-archive/web/architecture- discuss/current/msg00712.html D. What we should be identifying, both from a long term and shorter term PoV: http://www1.ietf.org/mail-archive/web/architecture-discuss/ current/msg00841.html _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Dec 04 10:06:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrFNq-00063L-ST; Mon, 04 Dec 2006 10:05:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrFNp-00063B-8W for architecture-discuss@ietf.org; Mon, 04 Dec 2006 10:05:29 -0500 Received: from web58715.mail.re1.yahoo.com ([66.196.100.214]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GrFNm-0001Jc-Mx for architecture-discuss@ietf.org; Mon, 04 Dec 2006 10:05:29 -0500 Received: (qmail 78738 invoked by uid 60001); 4 Dec 2006 15:05:26 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=Boo2FWftRXvNlTWFfG994jAXNHMp+Ba0RNfIvu/K6FKw2GpgxdisFuUKa9zwPT1EIp2VvR+7os8JTwDPrJ1erEVV96sflc8isYOfRSueqB/3OigxdMZYCVGVo36XB15dpb0h4W1gpqTeJv148Vb/ZdHdaM50QHeGcVUnU4TBDgI=; X-YMail-OSG: PMyVsLwVM1mGWdP2HI1dyB8N1vvNsHE0qU2MJB6Kl5Of.T0CTw56A4XoRfO1l0NyUw-- Received: from [207.107.50.100] by web58715.mail.re1.yahoo.com via HTTP; Mon, 04 Dec 2006 07:05:26 PST Date: Mon, 4 Dec 2006 07:05:26 -0800 (PST) From: Peter Sherbin Subject: Re: [arch-d] A straw man analysis of why send-receive packet paradigm is unsustainable To: John Leslie , Pekka Nikander In-Reply-To: <20061203001850.GA16503@verdi> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <537396.78670.qm@web58715.mail.re1.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > Private controls are a newer issue. As the "big telcos" have > discovered a market, they have largely succeeded in effectively > monopolizing the "broadband" market. There is a real danger that > these near-monopolies will make government controls more effective. Current distribution of IP addresses depends on "big telcos". Current architecture works sort of: IETF: Here is the Internet that let you communicate via a pre-determined hierarchy EU: What do I need? IETF: You need addresses and connection. EU: Where do I get them? IETF: You get them from your provider usually for a fee. EU: Can I change my provider and keep addresses? IETF: No! PROVIDER: I love that! EU: I hate it! But I need the Internet... To mitigate the above here are Principles of a Flexible Architecture: 1. Communicating entities = applications 2. Application name = any 3. Application address = Node's name 4. Node's name = unique, e.g. MAC 5. Node's address = Interface name 6. Interface name = unique IPvN 7. Interface address = IPvN+ASN 8. ASN hierarchy = Local, Metro, Regional, NE Hemisphere, NW Hemisphere, SE Hemisphere, SW Hemisphere, Planet, Star, Galaxy, Cluster 9. Local, Metro, Regional ASN could be mobile, ASN above Regional must have static geophysical coordinates 10. Interface hierarchy = interface, node, subnet, network Thank you, Peter --- John Leslie wrote: > Pekka Nikander wrote: > > On 1 Dec 2006, at 15:50, Scott W Brim wrote: > > > >> The EME RG could help here. In theory, it can push some of the cost > >> of receiving packets (I agree with you btw) into a setup phase, with > >> establishment of trust etc. > > > > Maybe. Interestingly, if you look at the current set of still- > > evolving EME requirements, you'll notice that something like Hi3 > > would relatively beautifully fulfil most of them. More generally, to > > me it looks like that the EME security requirements will be easier to > > reach if we adapt a new cryptographic name space, such as in HIP or > > SHIM6 with CGAs. > > > > But, if we do so, we will give up some of our core values in order to > > stay within the current paradigm. By taking the EME/Hi3/overlay/... > > route, we retain the basic send-receive packet paradigm while giving > > up some parts of the idea of an dumb, open, neutral network. At > > minimum, the network is no more dumb as it has the ability to heavily > > filter traffic. Nor it is any more open or neutral as some traffic > > will be allowed and other not. > > Frankly, I don't think we ever _had_ a "dumb, open, neutral" network. > But we were perhaps "close enough," and that is what I would prefer to > get from my upstreams and supply to my customers. > > > The overall issue is very hard to swallow. I'm sure I'll need to > > repeat the point umpteen times before it starts to sink in general in > > this community. Basically, we have two choices: > > > > 1. Give up some of our core values, or > > Which, for example? > > > 2. Give up the send-receive packet paradigm. > > I don't think packet transport is going away. What does Pekka think > we _will_ lose? > > > In my opinion, our almost "holy" long-term challenge is to find a new > > paradigm that will be able to sustain as much as possible of our core > > values: http://www.isoc.org/pubpolpillar/principles.shtml > > > > Consider especially the bullets #3, #6, and #7 on the above ISOC > > page. > > I think Pekka means: > ] > ] (3) The genius of the Internet is that its decentralized architecture > ] maximizes individual users' power to choose (or create) and use > ] the hardware, software, and services that best meet their needs, > ] and if the Internet is to continue to be a platform for innovation > ] and creativity, its open, decentralized nature must be preserved. > ] > ] (6) The social, political, and economic benefits of the Internet are > ] substantially diminished by excessively restrictive governmental > ] or private controls on computer hardware or software, > ] telecommunications infrastructure, or Internet content. > ] > ] (7) Rewarding and productive use of the Internet depends on the > ] ability to trust critical services. > > > Any approach that injects discriminative intelligence into the network > > will have difficulties in sustaining at least those three of the values. > > Clearly, NATs and firewalls do violence to "openness". For the most > part, I consider these to be _at_ the edge, and thus "not my problem". > > Governments _will_ try to control things -- it's their very nature. > We have traditionally looked upon this as the censorship problem -- > indistinguishable from "damage" and needing to be "routed around". > > Private controls are a newer issue. As the "big telcos" have > discovered a market, they have largely succeeded in effectively > monopolizing the "broadband" market. There is a real danger that > these near-monopolies will make government controls more effective. > > What "critical services" need to be "trusted", and what we mean > by "trusted" are pretty open questions... > > > Finding a new paradigm is, well, hard. Furthermore, once one is > > found, most people will fight bitterly against it, > > I basically agree. Thus, I'm not inclined to look for solutions > from "new paradigms". > > > That all said, I also happen to think that in the short/medium term > > something like HIP or SHIM6+CGA is most probably the right way to > > go. > > Neither of these, of course, should be our concern: we should be > talking architecture. (There are plenty of other lists where folks > can discuss band-aids!) But I must confess to being increasingly > irritated by well-intentioned folks discussing the merits of > different brands of band-aids on this list. > > > I think Noel was able to put this very nicely in > > http://www1.ietf.org/mail-archive/web/architecture-discuss/current/ > > msg00881.html > > Noel is a good fellow. And, frankly, his discussion of the merits > of different brands of band-aids is very good -- better than I could > have done. But that discussion still belongs elsewhere: which brands > are offered for sale won't be decided here, and the marketplace won't > seek our advice on which to buy. > > >> Expanding on this a bit, I see HIP as potentially part of an > >> alternative strategy... > > No thank you. (Well, not now anyway...) > > However, speaking for myself only, I'd be happy to see a number of > alternatives for identifying hosts being actively developed. I think > we'd be poorly advised to (try to) limit the format of host names. > > > What I'd like to see would be some kind of "requirements" (gasp) or > > goals, from two very different points of view: > > > > 1. What do the apps and users need? The EME requirement list seems > > like a reasonably good start. > > Actually, it seems like a perfectly _dreadful_ start for developing > an architecture. I'm willing to stipulate that this is, no doubt, what > user say today that they want. An architecture, however, must look to > enable _future_ wants. > > (In particular, use of the term "middlebox" suggests placement of > entirely inappropriate intelligence within the routing infrastructure.) > > > 2. What can be done at the routing and addressing side if the > > forwarding addresses are freed from their application/transport level > > identity function, making the whole addressing system much more > > flexible than it is today. > > The important point is what responsibilities can be _removed_ from > the routing infrastructure. Especially when we hear worries about > "meltdown", we should keep lower layers "as simple as possible". > > > Such "requirement" lists would help us to see what is missing from > > the current HIP and/or SHIM6+CGA approaches. > > We already know what's missing form them: consideration of the > overall evolving of an Internet architechure. > > (Not to criticize them: it wasn't their job.) > > > Given the time we've spent on HIP and SHIM6+CGA (HIP was conceived > > in 1999, the base ideas which later became CGA and SHIM6 around 2001 > > if not earlier), I'd be very dubious if we decided to start from > > scratch in our short/middle term approach. > > Wasn't there another list started to talk about immediate steps? > > -- > John Leslie > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss > ____________________________________________________________________________________ Yahoo! Music Unlimited Access over 1 million songs. http://music.yahoo.com/unlimited _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Dec 04 10:35:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrFpl-0005fr-8V; Mon, 04 Dec 2006 10:34:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrFpj-0005fh-Px for architecture-discuss@ietf.org; Mon, 04 Dec 2006 10:34:19 -0500 Received: from alnrmhc12.comcast.net ([204.127.225.92]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrFph-00056o-Hf for architecture-discuss@ietf.org; Mon, 04 Dec 2006 10:34:19 -0500 Received: from [10.0.1.12] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (alnrmhc12) with ESMTP id <20061204153354b1200t2bmoe>; Mon, 4 Dec 2006 15:34:14 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <537396.78670.qm@web58715.mail.re1.yahoo.com> References: <537396.78670.qm@web58715.mail.re1.yahoo.com> Date: Mon, 4 Dec 2006 10:27:07 -0500 To: Peter Sherbin , John Leslie , Pekka Nikander From: John Day Subject: Re: [arch-d] A straw man analysis of why send-receive packet paradigm is unsustainable Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.6 (/) 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: , Errors-To: architecture-discuss-bounces@ietf.org At 7:05 -0800 2006/12/04, Peter Sherbin wrote: > > Private controls are a newer issue. As the "big telcos" have >> discovered a market, they have largely succeeded in effectively >> monopolizing the "broadband" market. There is a real danger that >> these near-monopolies will make government controls more effective. > >Current distribution of IP addresses depends on "big telcos". >Current architecture >works sort of: >IETF: Here is the Internet that let you communicate via a >pre-determined hierarchy >EU: What do I need? >IETF: You need addresses and connection. >EU: Where do I get them? >IETF: You get them from your provider usually for a fee. >EU: Can I change my provider and keep addresses? >IETF: No! >PROVIDER: I love that! >EU: I hate it! But I need the Internet... This was a conscious choice by the IETF and one of the ground rules for the IPng. There were proposals at the time to avoid this. But the experts know best. >To mitigate the above here are Principles of a Flexible Architecture: >1. Communicating entities = applications >2. Application name = any >3. Application address = Node's name >4. Node's name = unique, e.g. MAC Interface name. Not node name. MAC and IP address are the same thing. Why both? >5. Node's address = Interface name This is the root of the problem. >6. Interface name = unique IPvN >7. Interface address = IPvN+ASN Which protocol carries this? >8. ASN hierarchy = Local, Metro, Regional, NE Hemisphere, NW Hemisphere, SE >Hemisphere, SW Hemisphere, Planet, Star, Galaxy, Cluster Just a fun nit: 4 *hemi*spheres! ;-) >9. Local, Metro, Regional ASN could be mobile, ASN above Regional >must have static >geophysical coordinates >10. Interface hierarchy = interface, node, subnet, network All in all, this seems to be the status quo. As near as I can tell a node and an interface are synonyms. Take care, John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Dec 04 11:03:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrGH3-0004vg-Gd; Mon, 04 Dec 2006 11:02:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrGH2-0004vR-DM for architecture-discuss@ietf.org; Mon, 04 Dec 2006 11:02:32 -0500 Received: from imo-d03.mx.aol.com ([205.188.157.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrGH1-0000yM-3z for architecture-discuss@ietf.org; Mon, 04 Dec 2006 11:02:32 -0500 Received: from HeinerHummel@aol.com by imo-d03.mx.aol.com (mail_out_v38_r7.6.) id r.c62.7277342 (48624); Mon, 4 Dec 2006 11:02:19 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Mon, 4 Dec 2006 11:02:17 EST Subject: Re: [arch-d] A straw man analysis of why send-receive packet paradigm is unsu... To: pesherb@yahoo.com, john@jlc.net, pekka.nikander@nomadiclab.com MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5009 X-Spam-Flag: NO X-Spam-Score: 0.3 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 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="===============1822633372==" Errors-To: architecture-discuss-bounces@ietf.org --===============1822633372== Content-Type: multipart/alternative; boundary="-----------------------------1165248137" -------------------------------1165248137 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 In einer eMail vom 04.12.2006 16:07:15 Westeurop=E4ische Normalzeit schreibt= =20 pesherb@yahoo.com: 8. ASN hierarchy =3D Local, Metro, Regional, NE Hemisphere, NW Hemisphere,=20= SE Hemisphere, SW Hemisphere, Planet, Star, Galaxy, Cluster Right !!! And in order to avoid a too huge hierarchy for most of the time, =20= a=20 dynamic hierarchy should be applied, where the hierarchical levels climb =20 according to the needs that stem from growing:=20 Every personal computer needs some defragmentation from time to time. It =20 improves the internal data organization without changing the services in =20 principle.=20 In the same way the envisioned internet of the future may undertake from =20 time to time (maybe by 5 years time steps, or upon specific demand) a reshap= e of =20 its hierarchy. Assumed it is due to oversized hierarchical networks those =20 may be split while creating a next upper network-node i.e. a dynamically ris= ing =20 hierarchy.... =20 Such the actual hierarchy is all the time just (fairly) fitting. And also:=20 No further fundamental redesign is needed (not even after ten or more such =20 reshape actions :-) =20 =20 =20 Heiner =20 =20 -------------------------------1165248137 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
In einer eMail vom 04.12.2006 16:07:15 Westeurop=E4ische Normalzeit sch= reibt=20 pesherb@yahoo.com:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>8. ASN=20 hierarchy =3D Local, Metro, Regional, NE Hemisphere, NW Hemisphere,=20 SE
Hemisphere, SW Hemisphere, Planet, Star, Galaxy,=20 Cluster
Right !!! And in order to avoid a too huge hierarchy for most of the ti= me,=20 a dynamic hierarchy should be applied, where the hierarchical levels climb=20 according to the needs that stem from growing:
Every personal computer needs some defragmentation from time to time. I= t=20 improves the internal data organization without changing the services in=20 principle.
In the same way the envisioned internet of the future may undertake fro= m=20 time to time (maybe by 5 years time steps, or upon specific demand) a reshap= e of=20 its hierarchy. Assumed it is due to oversized hierarchical networks tho= se=20 may be split while creating a next upper network-node i.e. a dynamically ris= ing=20 hierarchy....
 
Such the actual hierarchy is all the time just (fairly) fitting. A= nd=20 also: No further fundamental redesign is needed (not even after ten or more=20= such=20 reshape actions :-)
 
 
 
Heiner
 
 
-------------------------------1165248137-- --===============1822633372== 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 --===============1822633372==-- From architecture-discuss-bounces@ietf.org Mon Dec 04 11:15:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrGSJ-0000iX-SO; Mon, 04 Dec 2006 11:14:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrGSI-0000d7-0z for architecture-discuss@ietf.org; Mon, 04 Dec 2006 11:14:10 -0500 Received: from web58703.mail.re1.yahoo.com ([66.196.100.125]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GrGSF-0003Un-LU for architecture-discuss@ietf.org; Mon, 04 Dec 2006 11:14:10 -0500 Received: (qmail 3236 invoked by uid 60001); 4 Dec 2006 16:14:07 -0000 Message-ID: <20061204161407.3234.qmail@web58703.mail.re1.yahoo.com> DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=4ZhLdW7fS8ILN9PjJTURLMWVzBNFyXNrj57H9H+rtEoH0BKIZY36Q2e9CH8e1kOo6u2rTU3uWIEnvBBxrNTM2h3bwcFVJfncbuu32E1AAMMr1D8boeMAdysn/ULkPA5B7ziTj3NvzcvK9F3+AK4+3ebEXtxOyq1VZa51b8AKiqw=; X-YMail-OSG: C9Q8hnQVM1kWVrEnOyFmF08aC.c0gkZnQnY9QxZu0EpL2KRN.WNKq3.1uueY6NJ74.YwJ4KKc4xzacyQzTku.rt1opMt00YjlapGQ2SiKS.gTZMw5htrdt_K956sXYTqMT3LCvJ1zSafeJjx5iI6Cg1k64R8fuRmPg-- Received: from [207.107.50.100] by web58703.mail.re1.yahoo.com via HTTP; Mon, 04 Dec 2006 08:14:07 PST Date: Mon, 4 Dec 2006 08:14:07 -0800 (PST) From: Peter Sherbin Subject: Re: [arch-d] A straw man analysis of why send-receive packet paradigm is unsustainable To: John Day , John Leslie , Pekka Nikander In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > >4. Node's name = unique, e.g. MAC > > Interface name. Not node name. > MAC and IP address are the same thing. Why both? IEEE designed MAC identifies a node. IETF designed IP address identifies an interface. One node may have several interfaces. > >6. Interface name = unique IPvN > >7. Interface address = IPvN+ASN > > Which protocol carries this? A new one that needs to be designed. > >8. ASN hierarchy = Local, Metro, Regional, NE Hemisphere, NW Hemisphere, SE > >Hemisphere, SW Hemisphere, Planet, Star, Galaxy, Cluster > > Just a fun nit: 4 *hemi*spheres! ;-) A quartersphere indeed, thank you :) > All in all, this seems to be the status quo. As near as I can tell a > node and an interface are synonyms. A big enough node carries several interfaces. Each interface is node's address that could be used in different communication contexts. Network and ASN are two independent worlds that intersect only when the packet needs to travel between AS. Thanks, Peter --- John Day wrote: > At 7:05 -0800 2006/12/04, Peter Sherbin wrote: > > > Private controls are a newer issue. As the "big telcos" have > >> discovered a market, they have largely succeeded in effectively > >> monopolizing the "broadband" market. There is a real danger that > >> these near-monopolies will make government controls more effective. > > > >Current distribution of IP addresses depends on "big telcos". > >Current architecture > >works sort of: > >IETF: Here is the Internet that let you communicate via a > >pre-determined hierarchy > >EU: What do I need? > >IETF: You need addresses and connection. > >EU: Where do I get them? > >IETF: You get them from your provider usually for a fee. > >EU: Can I change my provider and keep addresses? > >IETF: No! > >PROVIDER: I love that! > >EU: I hate it! But I need the Internet... > > This was a conscious choice by the IETF and one of the ground rules > for the IPng. There were proposals at the time to avoid this. But > the experts know best. > > >To mitigate the above here are Principles of a Flexible Architecture: > >1. Communicating entities = applications > >2. Application name = any > >3. Application address = Node's name > >4. Node's name = unique, e.g. MAC > > Interface name. Not node name. > > MAC and IP address are the same thing. Why both? > > >5. Node's address = Interface name > > This is the root of the problem. > > >6. Interface name = unique IPvN > >7. Interface address = IPvN+ASN > > Which protocol carries this? > > >8. ASN hierarchy = Local, Metro, Regional, NE Hemisphere, NW Hemisphere, SE > >Hemisphere, SW Hemisphere, Planet, Star, Galaxy, Cluster > > Just a fun nit: 4 *hemi*spheres! ;-) > > >9. Local, Metro, Regional ASN could be mobile, ASN above Regional > >must have static > >geophysical coordinates > >10. Interface hierarchy = interface, node, subnet, network > > All in all, this seems to be the status quo. As near as I can tell a > node and an interface are synonyms. > > Take care, > John > ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Dec 04 11:32:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrGjN-0002Xe-F7; Mon, 04 Dec 2006 11:31:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrGjM-0002XQ-D6 for architecture-discuss@ietf.org; Mon, 04 Dec 2006 11:31:48 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrGjI-0005at-AC for architecture-discuss@ietf.org; Mon, 04 Dec 2006 11:31:48 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 04 Dec 2006 08:31:43 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kB4GVhiO016584; Mon, 4 Dec 2006 08:31:43 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB4GVhiq002200; Mon, 4 Dec 2006 08:31:43 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Dec 2006 08:31:43 -0800 Received: from [10.32.244.221] ([10.32.244.221]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Dec 2006 08:31:43 -0800 In-Reply-To: <20061204161407.3234.qmail@web58703.mail.re1.yahoo.com> References: <20061204161407.3234.qmail@web58703.mail.re1.yahoo.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <28077652-709E-4530-B153-4088D2D92F43@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [arch-d] A straw man analysis of why send-receive packet paradigm is unsustainable Date: Mon, 4 Dec 2006 08:31:41 -0800 To: Peter Sherbin X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 04 Dec 2006 16:31:43.0148 (UTC) FILETIME=[AEC2D6C0:01C717C1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=338; t=1165249903; x=1166113903; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[arch-d]=20A=20straw=20man=20analysis=20of=20why=20se nd-receive=20packet=20paradigm=20is=20unsustainable |Sender:=20; bh=othC5lUfPPPOkH6/0jm6mHTm3z+Fp2PYgsk+qsNAR7Q=; b=aQKXqYE61JRYhK0JO3hjJ/jjiKGZxxOQJact7EygwwIpTs1CFRZj52+/UoRHV+CDnOyj8JkN sOYMKeHHgY3Vprd/KSQ29A95qVBbkiN+GdhIYrFS2AkzJhzRSeGP8Nuu; Authentication-Results: sj-dkim-2; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Pekka Nikander , architecture-discuss@ietf.org, John Day X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Dec 4, 2006, at 8:14 AM, Peter Sherbin wrote: > IEEE designed MAC identifies a node. actually, no. The IEEE-defined MAC Address is stored in a rom on the interface card and is intended to be applied to the interface. The system can of course do anything it wants, but generally a MAC Address identifies an interface. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Dec 04 11:34:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrGka-00048L-Av; Mon, 04 Dec 2006 11:33:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrGkZ-00045F-0V for architecture-discuss@ietf.org; Mon, 04 Dec 2006 11:33:03 -0500 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 1GrGkX-0005ik-N0 for architecture-discuss@ietf.org; Mon, 04 Dec 2006 11:33:02 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 04 Dec 2006 08:33:02 -0800 X-IronPort-AV: i="4.09,494,1157353200"; d="scan'208"; a="351484941:sNHT42922696" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id kB4GX1f8024331; Mon, 4 Dec 2006 08:33:01 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kB4GX0is003342; Mon, 4 Dec 2006 08:33:01 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Dec 2006 08:33:00 -0800 Received: from [10.32.244.221] ([10.32.244.221]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Dec 2006 08:33:00 -0800 In-Reply-To: <57456.24148.qm@web58708.mail.re1.yahoo.com> References: <57456.24148.qm@web58708.mail.re1.yahoo.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [arch-d] A straw man analysis of why send-receive packet paradigm is unsustainable Date: Mon, 4 Dec 2006 08:32:59 -0800 To: Peter Sherbin X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 04 Dec 2006 16:33:00.0310 (UTC) FILETIME=[DCC0D360:01C717C1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=448; t=1165249981; x=1166113981; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[arch-d]=20A=20straw=20man=20analysis=20of=20why=20se nd-receive=20packet=20paradigm=20is=20unsustainable |Sender:=20; bh=uPZAS2nccSg/Ou6ahFT9CYT2qQdU3V0KsoTE9DFQsW4=; b=s2pHiCDXDckiKOVNk/yYCFeQi7wkgCr7QHbjYaDuw2secoCmzOqoAWe2jHT2w/HZ3lp4v9R6 /saFrZ52FoJq80o0Ty5qHcuWmoI5sPLiinNzPzaBD05U4zVG+8oYdeVP; Authentication-Results: sj-dkim-4; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Pekka Nikander , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Dec 3, 2006, at 6:38 PM, Peter Sherbin wrote: > What if nodes are protected so an outsider can not make them zombie? That's the theory behind a firewall. The problem is, so I'm told, that some 80% of attacks are from behind the firewall, very possibly from a system directly connected electrically to the target of the attack. At the end of the day, the system receiving the potential attack is responsible for its own defense. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Dec 04 12:47:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrHu6-0000oS-Tr; Mon, 04 Dec 2006 12:46:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrHu5-0000oN-9V for architecture-discuss@ietf.org; Mon, 04 Dec 2006 12:46:57 -0500 Received: from sokol.elan.net ([216.151.192.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrHu3-0008Jb-TD for architecture-discuss@ietf.org; Mon, 04 Dec 2006 12:46:57 -0500 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id kB4HklQX011115; Mon, 4 Dec 2006 09:46:47 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id kB4Hkk6X011111; Mon, 4 Dec 2006 09:46:46 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Mon, 4 Dec 2006 09:46:46 -0800 (PST) From: "william(at)elan.net" To: Fred Baker Subject: Re: [arch-d] A straw man analysis of why send-receive packet paradigm is unsustainable In-Reply-To: <28077652-709E-4530-B153-4088D2D92F43@cisco.com> Message-ID: References: <20061204161407.3234.qmail@web58703.mail.re1.yahoo.com> <28077652-709E-4530-B153-4088D2D92F43@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Pekka Nikander , architecture-discuss@ietf.org, John Day X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Mon, 4 Dec 2006, Fred Baker wrote: > On Dec 4, 2006, at 8:14 AM, Peter Sherbin wrote: > >> IEEE designed MAC identifies a node. > > actually, no. The IEEE-defined MAC Address is stored in a rom on the > interface card and is intended to be applied to the interface. > The system can of course do anything it wants, but generally a MAC > Address identifies an interface. Could you define what "an interface" is? [it seems to have different meaning depending on who is talking here...] BTW - In my view MAC address is unique id of the network card itself designed to avoid collisions when multiple cards are put on the same L2 network segment and its made globally unique so that people did not have to program the cards every time they are used. L2 routing on the other hand need not be based on MAC address although traditionally it has been [nor does this routing even need to be globally similar - it is only necessary that it work locally]. Now we can try to apply parallels to L3 ip routing for current or future work on IPv? protocol(s). However one thing to note is that it may not necessarily help in solving problem with increase in global routing table. But I actually said before (like many others) that it would be great if we could do everything based entirely ASN routing - that does reduce the global routing table a bit, but unfortunately it does not actually reduce the proportions for long-term - i.e. if we just cut table size and its increase by 1/2 (or some other linear fraction), does it solve the problem when the increase seems to be defined by exponential curve? [its probably not exponential, but it certainly does not seem linear...] But it might help in shorter term (10-20 years) and should be considered as it maybe enough until we have better techniques and data from new research efforts (such as GENI which is supposed to allow for global routing research, it has not even started in serious way yet and probably 10+ years before results from it find it way to to IETF engineering). -- 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 Dec 04 12:55:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrI21-0007p1-Gr; Mon, 04 Dec 2006 12:55:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrI20-0007kD-0P for architecture-discuss@ietf.org; Mon, 04 Dec 2006 12:55:08 -0500 Received: from alnrmhc12.comcast.net ([206.18.177.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrI1w-0000l1-Oi for architecture-discuss@ietf.org; Mon, 04 Dec 2006 12:55:07 -0500 Received: from [10.0.1.12] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (alnrmhc12) with ESMTP id <20061204175503b1200t2mp2e>; Mon, 4 Dec 2006 17:55:04 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <20061204161407.3234.qmail@web58703.mail.re1.yahoo.com> References: <20061204161407.3234.qmail@web58703.mail.re1.yahoo.com> Date: Mon, 4 Dec 2006 12:51:43 -0500 To: Peter Sherbin , John Day , John Leslie , Pekka Nikander From: John Day Subject: Re: [arch-d] A straw man analysis of why send-receive packet paradigm is unsustainable Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 8:14 -0800 2006/12/04, Peter Sherbin wrote: > > >4. Node's name = unique, e.g. MAC >> >> Interface name. Not node name. >> MAC and IP address are the same thing. Why both? > >IEEE designed MAC identifies a node. IETF designed IP address identifies an >interface. One node may have several interfaces. See Fred Baker's comment. I agree with Fred. It has always been an interface. > >> >6. Interface name = unique IPvN >> >7. Interface address = IPvN+ASN >> >> Which protocol carries this? > >A new one that needs to be designed. Interesting. > >> >8. ASN hierarchy = Local, Metro, Regional, NE Hemisphere, NW Hemisphere, SE >> >Hemisphere, SW Hemisphere, Planet, Star, Galaxy, Cluster >> >> Just a fun nit: 4 *hemi*spheres! ;-) > >A quartersphere indeed, thank you :) I believe they would be quadraspheres! ;-) > >> All in all, this seems to be the status quo. As near as I can tell a >> node and an interface are synonyms. > >A big enough node carries several interfaces. Each interface is >node's address that >could be used in different communication contexts. Network and ASN are two >independent worlds that intersect only when the packet needs to >travel between AS. You keep saying that a node can have several interfaces and I agree. But when you then do is quite the opposite. ASNs were a kludge. Give some thought to what they should have been. I think you are converging. Take another look at 1498. Take care, John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Dec 04 13:40:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrIif-0001UG-C2; Mon, 04 Dec 2006 13:39:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrIid-0001St-Sg for architecture-discuss@ietf.org; Mon, 04 Dec 2006 13:39:11 -0500 Received: from web58703.mail.re1.yahoo.com ([66.196.100.125]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GrIic-0006wH-Iv for architecture-discuss@ietf.org; Mon, 04 Dec 2006 13:39:11 -0500 Received: (qmail 59590 invoked by uid 60001); 4 Dec 2006 18:39:10 -0000 Message-ID: <20061204183910.59588.qmail@web58703.mail.re1.yahoo.com> DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=SijVbp2o8PI0oTcopcffnCZGaLZ8Bhbf4pRV+hxUUEad9UASar/urFkv5drl6mf24EKl228P66u0uveT9AMEF1tg0zo6l273yDpJHBOFPFdfsZpZtP7OyqQKbojhWrhrww0Yj4hS64PZNlrWPMhxKY9hJmX0XwyRZm4UMmTpSkI=; X-YMail-OSG: P5GAQ9YVM1n4_in7yQx3nLCqJykykdVnOaaAb6yB9xZy8NZZLKnuQmTKStude1nzBA-- Received: from [207.107.50.100] by web58703.mail.re1.yahoo.com via HTTP; Mon, 04 Dec 2006 10:39:10 PST Date: Mon, 4 Dec 2006 10:39:10 -0800 (PST) From: Peter Sherbin Subject: Re: [arch-d] A straw man analysis of why send-receive packet paradigm is unsustainable To: Fred Baker In-Reply-To: <28077652-709E-4530-B153-4088D2D92F43@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Pekka Nikander , architecture-discuss@ietf.org, John Day X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > but generally a MAC Address identifies an interface. What was the reason/need then in creating IP addresses? Thanks, Peter --- Fred Baker wrote: > > On Dec 4, 2006, at 8:14 AM, Peter Sherbin wrote: > > > IEEE designed MAC identifies a node. > > actually, no. The IEEE-defined MAC Address is stored in a rom on the > interface card and is intended to be applied to the interface. The > system can of course do anything it wants, but generally a MAC > Address identifies an interface. > ____________________________________________________________________________________ Cheap talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. http://voice.yahoo.com _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Dec 04 13:55:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrIxT-0005UO-Pu; Mon, 04 Dec 2006 13:54:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrIxS-0005UI-KW for architecture-discuss@ietf.org; Mon, 04 Dec 2006 13:54:30 -0500 Received: from web58702.mail.re1.yahoo.com ([66.196.100.124]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GrIx7-0000zX-F5 for architecture-discuss@ietf.org; Mon, 04 Dec 2006 13:54:30 -0500 Received: (qmail 21390 invoked by uid 60001); 4 Dec 2006 18:54:09 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=mwqBCPfbbDg+6In4pXpVFU1ubIOmiGSha5nsjptqRUXwkg0TXb/S5utu7f7jz4IKKqPdOn+g2pZQ+QCHuZzka/bB39ygik7JAHRvmFZLSEx08tEEgs3N88baiG1subKhm7m6IoZCq18yn9CI/Kfmfb6tLgyR/60UImvW505RC2g=; X-YMail-OSG: Vmmt.vMVM1l081o24_zSQa7VBQKt42EcPpltvZVOuBGdyMDc5gt.NSnlDnGeY5D21Te5d7_VxY7zSGNv0lgr_HKGjjNUaJZGdJGhkuDYQTzy8aIezWWecOPzD_ZI1euw.r3LCF139g0V4ETQ8.OvqQ_WN1PPnWd2AV0SoE39auCZnwqx3PN1u4z662o- Received: from [207.107.50.100] by web58702.mail.re1.yahoo.com via HTTP; Mon, 04 Dec 2006 10:54:09 PST Date: Mon, 4 Dec 2006 10:54:09 -0800 (PST) From: Peter Sherbin Subject: Re: [arch-d] A straw man analysis of why send-receive packet paradigm is unsustainable To: Fred Baker In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <291427.19619.qm@web58702.mail.re1.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Pekka Nikander , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > attack. At the end of the day, the system receiving the potential > attack is responsible for its own defense. This is fine. All I need is a system that is protectable with a reasonable amount of effort from/by an average non-programmer who just wants to run an application. Thanks, Peter --- Fred Baker wrote: > On Dec 3, 2006, at 6:38 PM, Peter Sherbin wrote: > > What if nodes are protected so an outsider can not make them zombie? > > That's the theory behind a firewall. The problem is, so I'm told, > that some 80% of attacks are from behind the firewall, very possibly > from a system directly connected electrically to the target of the > attack. At the end of the day, the system receiving the potential > attack is responsible for its own defense. > ____________________________________________________________________________________ Yahoo! Music Unlimited Access over 1 million songs. http://music.yahoo.com/unlimited _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Dec 04 14:04:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrJ6W-0004Da-4v; Mon, 04 Dec 2006 14:03:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrJ6U-0004DQ-TA for architecture-discuss@ietf.org; Mon, 04 Dec 2006 14:03:50 -0500 Received: from web58710.mail.re1.yahoo.com ([66.196.100.187]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GrJ6S-0002f0-Jk for architecture-discuss@ietf.org; Mon, 04 Dec 2006 14:03:50 -0500 Received: (qmail 55496 invoked by uid 60001); 4 Dec 2006 19:03:48 -0000 Message-ID: <20061204190348.55494.qmail@web58710.mail.re1.yahoo.com> DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=532tQbWoDRH0xmEtx0OaIoTnBZhrUYiXq3uCxjBnR9cWkDe54QkVo6O34nUJj7rYtJQFVNKtjZIxRZsmME3oKrBWHP4T3EwTmVlW2g7DujGKNV9Mb9MIhDdv/pXpkBn6SF8dUq/muyITdWlqFDXyuyVXhsQbqYxhJyiJ7cImzJ8=; X-YMail-OSG: zfGZQyMVM1l0YDGBQ3sY1I2XIxMTZ5jfEd5oVXEboZyxRVNePhKCNAhDbcSS_fZ45OyAlpg1cS3a8AWb2DFBmplHYAvEm_nTh9C2BQX7we2ANYSrPoQowDN7yMjJiVJQ_RtTKcpRuNkDH3XrB73J_MroOuZNeVDTAY1tQ2NDGiqxorJw7IfxI.OFETE- Received: from [207.107.50.100] by web58710.mail.re1.yahoo.com via HTTP; Mon, 04 Dec 2006 11:03:48 PST Date: Mon, 4 Dec 2006 11:03:48 -0800 (PST) From: Peter Sherbin Subject: Re: [arch-d] A straw man analysis of why send-receive packet paradigm is unsustainable To: John Day , John Leslie , Pekka Nikander In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > I think you are converging. What is your idea of a scalable architecture? Could you please define it in one or two sentences? Thanks, Peter --- John Day wrote: > At 8:14 -0800 2006/12/04, Peter Sherbin wrote: > > > >4. Node's name = unique, e.g. MAC > >> > >> Interface name. Not node name. > >> MAC and IP address are the same thing. Why both? > > > >IEEE designed MAC identifies a node. IETF designed IP address identifies an > >interface. One node may have several interfaces. > > See Fred Baker's comment. I agree with Fred. It has always been an interface. > > > > >> >6. Interface name = unique IPvN > >> >7. Interface address = IPvN+ASN > >> > >> Which protocol carries this? > > > >A new one that needs to be designed. > > Interesting. > > > > >> >8. ASN hierarchy = Local, Metro, Regional, NE Hemisphere, NW Hemisphere, SE > >> >Hemisphere, SW Hemisphere, Planet, Star, Galaxy, Cluster > >> > >> Just a fun nit: 4 *hemi*spheres! ;-) > > > >A quartersphere indeed, thank you :) > > I believe they would be quadraspheres! ;-) > > > > >> All in all, this seems to be the status quo. As near as I can tell a > >> node and an interface are synonyms. > > > >A big enough node carries several interfaces. Each interface is > >node's address that > >could be used in different communication contexts. Network and ASN are two > >independent worlds that intersect only when the packet needs to > >travel between AS. > > You keep saying that a node can have several interfaces and I agree. > But when you then do is quite the opposite. ASNs were a kludge. > Give some thought to what they should have been. > > I think you are converging. Take another look at 1498. > > Take care, > John > ____________________________________________________________________________________ Have a burning question? Go to www.Answers.yahoo.com and get answers from real people who know. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Dec 04 14:05:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrJ7u-00077p-1A; Mon, 04 Dec 2006 14:05:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrJ7r-0006sn-BH for architecture-discuss@ietf.org; Mon, 04 Dec 2006 14:05:15 -0500 Received: from rwcrmhc11.comcast.net ([216.148.227.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrJ7q-0002oQ-38 for architecture-discuss@ietf.org; Mon, 04 Dec 2006 14:05:15 -0500 Received: from [10.0.1.12] (failure[24.34.102.194]) by comcast.net (rwcrmhc11) with ESMTP id <20061204190512m1100smcb8e>; Mon, 4 Dec 2006 19:05:13 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <20061204183910.59588.qmail@web58703.mail.re1.yahoo.com> References: <20061204183910.59588.qmail@web58703.mail.re1.yahoo.com> Date: Mon, 4 Dec 2006 14:03:47 -0500 To: Peter Sherbin , Fred Baker From: John Day Subject: Re: [arch-d] A straw man analysis of why send-receive packet paradigm is unsustainable Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.6 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Pekka Nikander , architecture-discuss@ietf.org, John Day X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 10:39 -0800 2006/12/04, Peter Sherbin wrote: > > but generally a MAC Address identifies an interface. > >What was the reason/need then in creating IP addresses? Interesting question, isn't it? Well, MAC addresses are flat and IP addresses weren't suppose to be but really were until CIDR came along 15 years later. IP addresses were suppose to be the addresses of "gateways" which turned out to be routers. So they went back to naming switch interfaces. MAC addresses were in IEEE and IP addresses were in the DoD. It has always been odd that a data link address had more scope than a network layer address. Or as I said before, that an *Internet* address named a *subnet* point of attachment. But we really don't worry about that as long as the implementation works, right? If the implementation works, it must be right. Apparently very few people had enough OS experience to realize that we had made a mistake with ARPANet host addresses until Saltzer's paper came along, even though we had been talking about since the Tinker AFB IMP in '72. (Okay, yes, I am being a little facetious but only a little. And you do have to allow for the fact that we were figuring all this out as we went. We didn't have a complete theory of networking that we were building to. Sometimes what we thought the relation between things was when we first created them turned out not to be quite what we thought it was a few years later.) We were going to fix it with IPng, but by then everyone was so attached to naming the interface and there were probably only 25 people who knew why we shouldn't, and of course to air all the dirty laundry CLNP did distinguish point of attachments and node addresses. So that was one more reason not to. Gosh, I don't know maybe we don't need IP and we just need this new protocol you were talking about. ;-) Take care, John _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Dec 04 14:13:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrJFg-0004EU-BY; Mon, 04 Dec 2006 14:13:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrJFe-0004EM-Uj for architecture-discuss@ietf.org; Mon, 04 Dec 2006 14:13:18 -0500 Received: from web31815.mail.mud.yahoo.com ([68.142.206.168]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GrJFU-0004DJ-Ai for architecture-discuss@ietf.org; Mon, 04 Dec 2006 14:13:18 -0500 Received: (qmail 40172 invoked by uid 60001); 4 Dec 2006 19:13:07 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=j+6eArgy3ZC8/WrAFR3C3dA2aAMcMnFp3/vg3l+7zPuyq8ndoOUlkNvu2D1C/5Z6aaOsyT7fmKCb32TrA5SNsIAgkvHq7VxX3qxTsPvZx7GeOE20tNY//cLJWBskUNbRYfMs98DoNrjtXvzzePq73NGwt0ksWxNby7NM8ZIZzhY=; X-YMail-OSG: 1dR.XpEVM1kqUdtflHF_ADa8stk.aY0yXUjWcU8kxqdaWHLqQ4Pb0OySzVggLyPQE.YAmZnJnW1VQZmebwp_QexUYlBItFdaH5pvFBcu07ZWhEyPYXGS6.rm7VR4lDtXtRAJe6d11iZkbSc- Received: from [162.130.197.18] by web31815.mail.mud.yahoo.com via HTTP; Mon, 04 Dec 2006 11:13:07 PST Date: Mon, 4 Dec 2006 11:13:07 -0800 (PST) From: David Barak Subject: Re: [arch-d] A straw man analysis of why send-receive packet paradigm is unsustainable To: Peter Sherbin , architecture-discuss@ietf.org In-Reply-To: <20061204183910.59588.qmail@web58703.mail.re1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <571573.39761.qm@web31815.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org --- Peter Sherbin wrote: > > but generally a MAC Address identifies an > interface. > > What was the reason/need then in creating IP > addresses? Logical addressing - MAC is to provide a unique physical hardware address, IP is to provide aggregatible logical groups of addresses, and to hide the MAC information from distant subnets (for which it is not relevant). -David David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Dec 04 14:27:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrJTL-0006Gm-9y; Mon, 04 Dec 2006 14:27:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrJTJ-0006Cl-B2 for architecture-discuss@ietf.org; Mon, 04 Dec 2006 14:27:25 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrJTG-0007xE-SO for architecture-discuss@ietf.org; Mon, 04 Dec 2006 14:27:25 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 04 Dec 2006 11:27:19 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kB4JRI7F023399; Mon, 4 Dec 2006 11:27:18 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kB4JRAWg015689; Mon, 4 Dec 2006 11:27:18 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Dec 2006 11:27:16 -0800 Received: from [10.32.244.221] ([10.32.244.221]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Dec 2006 11:27:14 -0800 In-Reply-To: <20061204183910.59588.qmail@web58703.mail.re1.yahoo.com> References: <20061204183910.59588.qmail@web58703.mail.re1.yahoo.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <20D3CEC3-7E28-4B20-8B75-7E8EF557F662@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [arch-d] A straw man analysis of why send-receive packet paradigm is unsustainable Date: Mon, 4 Dec 2006 11:27:13 -0800 To: Peter Sherbin X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 04 Dec 2006 19:27:14.0911 (UTC) FILETIME=[342E56F0:01C717DA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=346; t=1165260438; x=1166124438; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[arch-d]=20A=20straw=20man=20analysis=20of=20why=20se nd-receive=20packet=20paradigm=20is=20unsustainable |Sender:=20; bh=gDUw57R+9LsP75jJT4qN01jN23lyU/7+Z2Wz///uSE8=; b=DbHC+aK18H7T2aY4MMW4kQlKNWTLftF/9V9YOfvcSY4PXia12l/zm9O5ybCMjl6JAXF3URkq TUnAUnXfbUa8PiJFxYkoiKO+eo+/GW6ZvWrsiNTJFS60mqq5yIruHR7E; Authentication-Results: sj-dkim-1; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Pekka Nikander , architecture-discuss@ietf.org, John Day X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Dec 4, 2006, at 10:39 AM, Peter Sherbin wrote: >> but generally a MAC Address identifies an interface. > > What was the reason/need then in creating IP addresses? Tell me this: what kinds of interfaces do we use in the Internet? Is every single interface an IEEE 802.3 interface? What other kinds of interfaces are supported? _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Dec 04 15:12:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrK93-0005NB-Kg; Mon, 04 Dec 2006 15:10:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrK92-0005N5-JJ for architecture-discuss@ietf.org; Mon, 04 Dec 2006 15:10:32 -0500 Received: from web58710.mail.re1.yahoo.com ([66.196.100.187]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GrK90-0005ez-AT for architecture-discuss@ietf.org; Mon, 04 Dec 2006 15:10:32 -0500 Received: (qmail 80627 invoked by uid 60001); 4 Dec 2006 20:10:30 -0000 Message-ID: <20061204201030.80625.qmail@web58710.mail.re1.yahoo.com> DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=SR/5/l0jCmnJr76Q5LXylBFgyqoS/2mLAMRMM4EMdinJPUSGZL09BXARAbDuWfAcBJ6DytVPJqeMVp30CQ79zdAHxnBO37n/tqiv9ld/wRaIFk9wZw0zGcgdbjbBBnSla8u1FrdpMKXg5tfAJ3J/KuRFGjfojsUdVm0oZiRkOp8=; X-YMail-OSG: sYTBmDAVM1mheJJ4F9wTi1VdO1aIW0mRuHt0mO0hRTlXpGM1.SxZgo_HnO.U3I8AH4S6eGZfMvqIyTLCTAZ8tlv.oo2K94PULv7AKuaTu1ZaZaajDc.YJrW7xgraRCjALCaA92rzK8jXowszo2CKYTMLjcbHM9eIbC1G6obRHagA9xIlrz4FFeUIZLk- Received: from [207.107.50.100] by web58710.mail.re1.yahoo.com via HTTP; Mon, 04 Dec 2006 12:10:29 PST Date: Mon, 4 Dec 2006 12:10:29 -0800 (PST) From: Peter Sherbin Subject: Re: [arch-d] A straw man analysis of why send-receive packet paradigm is unsustainable To: Fred Baker In-Reply-To: <20D3CEC3-7E28-4B20-8B75-7E8EF557F662@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Pekka Nikander , architecture-discuss@ietf.org, John Day X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > every single interface an IEEE 802.3 interface? What other kinds of > interfaces are supported? 802.5, 802.6, 802.11? For the Internet does it matter what goes on at Layer 2? A situation with 1+ interfaces per node is common e.g. router with interface 1 facing LAN and interface 2 facing WAN. Or a PC with a LAN card and a wireless LAN card. Interfaces are different when the node is the same. Outside applications may use interfaces 1 and 2 to talk to different applications within same node. Node seems just a housing for applications. Does it make a concept of a node irrelevant to networking? Thanks, Peter --- Fred Baker wrote: > > On Dec 4, 2006, at 10:39 AM, Peter Sherbin wrote: > > >> but generally a MAC Address identifies an interface. > > > > What was the reason/need then in creating IP addresses? > > Tell me this: what kinds of interfaces do we use in the Internet? Is > every single interface an IEEE 802.3 interface? What other kinds of > interfaces are supported? > ____________________________________________________________________________________ Yahoo! Music Unlimited Access over 1 million songs. http://music.yahoo.com/unlimited _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Dec 04 15:22:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrKKM-0005Bg-GB; Mon, 04 Dec 2006 15:22:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrKKL-0005Bb-Ab for architecture-discuss@ietf.org; Mon, 04 Dec 2006 15:22:13 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrKKK-0007gn-0Z for architecture-discuss@ietf.org; Mon, 04 Dec 2006 15:22:13 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 04 Dec 2006 12:22:10 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id kB4KMAtS000663; Mon, 4 Dec 2006 12:22:10 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kB4KLxWK001076; Mon, 4 Dec 2006 12:22:09 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Dec 2006 12:22:07 -0800 Received: from [10.32.244.221] ([10.32.244.221]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Dec 2006 12:22:07 -0800 In-Reply-To: <20061204201030.80625.qmail@web58710.mail.re1.yahoo.com> References: <20061204201030.80625.qmail@web58710.mail.re1.yahoo.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [arch-d] A straw man analysis of why send-receive packet paradigm is unsustainable Date: Mon, 4 Dec 2006 12:22:04 -0800 To: Peter Sherbin X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 04 Dec 2006 20:22:07.0668 (UTC) FILETIME=[DED12F40:01C717E1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=777; t=1165263730; x=1166127730; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[arch-d]=20A=20straw=20man=20analysis=20of=20why=20se nd-receive=20packet=20paradigm=20is=20unsustainable |Sender:=20; bh=ouJS7ZRNsRB9JKBIm9mMyOzjNnYPm3RAF/st9twz9GM=; b=pbAt2MTpvrb7yiXo0IZzKFEpBCvOJ04peRFnMQ6mXFia5DZsdQSFWI4NnWNbFDZ3rWTCODhL mWn2PumH7JuAU7SjhB6Ya8SkpUTVS4kMUK+wev46NICcAtltQCcGLN2N; Authentication-Results: sj-dkim-4; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Pekka Nikander , architecture-discuss@ietf.org, John Day X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Dec 4, 2006, at 12:10 PM, Peter Sherbin wrote: > 802.5, 802.6, 802.11? For the Internet does it matter what goes on > at Layer 2? no, it doesn't, because we have an IP address rather than a layer 2 address. To answer your question, that's specifically *why* we have an IP address. We need something that is *not* the lower layer address that we can use regardless of the type of lower layer in use. > On Dec 4, 2006, at 10:39 AM, Peter Sherbin wrote: >>> but generally a MAC Address identifies an interface. >> >> What was the reason/need then in creating IP addresses? > > Tell me this: what kinds of interfaces do we use in the Internet? Is > every single interface an IEEE 802.3 interface? What other kinds of > interfaces are supported? _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Dec 04 18:12:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrMxo-0004z6-5V; Mon, 04 Dec 2006 18:11:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrMxm-0004yn-Tl for architecture-discuss@ietf.org; Mon, 04 Dec 2006 18:11:06 -0500 Received: from smtp1.nodak.edu ([134.129.111.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrMxm-0002j7-4n for architecture-discuss@ietf.org; Mon, 04 Dec 2006 18:11:06 -0500 Received: from [134.129.95.120] (netmender.cc.ndsu.NoDak.edu [134.129.95.120]) (authenticated bits=0) by smtp1.NoDak.edu (8.13.1/8.13.1) with ESMTP id kB4NB5P6022151 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 4 Dec 2006 17:11:05 -0600 Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <71F6867B-BB26-4A7D-9480-D8189BB32DB3@ndsu.edu> To: architecture-discuss@ietf.org From: Bruce Curtis Date: Mon, 4 Dec 2006 17:11:04 -0600 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 4bb0e9e1ca9d18125bc841b2d8d77e24 Subject: [arch-d] It's about Information 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="===============1262754116==" Errors-To: architecture-discuss-bounces@ietf.org --===============1262754116== Content-Type: multipart/alternative; boundary=Apple-Mail-35-135586915 --Apple-Mail-35-135586915 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed This may be obvious to everyone since I haven't seen much discussion about this model but it helped me understand the issues. In the IPv4 multihoming model the information about multiple paths from host A to host Z is in the routing table of the core routers in the Internet. ISP 1 ---------------- I --------------------------------- ISP 7 | n | A -- ISP 2 ------- t ------------------------ ISP 8 -- Z | e | ISP 3 --------------- r --------------------------------- ISP 9 n e t If we change the model and take the information about multiple paths out of the core routers and give each host a different IP number for each of it's ISPs, then to preserve some of the properties of the old model we still need to have the multiple path information available to the network somehow. ISP 1 ---------------- I --------------------------------- ISP 7 | n | A,B,C -- ISP 2 ------- t ------------------------ ISP 8 -- X,Y,Z | e | ISP 3 --------------- r --------------------------------- ISP 9 n e t If we imagine a time in the future where every host has 100 Mbps connection to the Internet like some homes in Japan today and we have networks that support Jumbo frames it's easier to consider the possibility that we put the required information in every packet from host A,B,C to host X,Y,Z. That is, we put all of the destination addresses X,Y,Z in the packet as well as the source addresses A,B,C. So basically we take the information about multiple paths out of the routing tables where it doesn't scale and put the multiple path info in each packet, which should scale right along with the speed of the router. If we put this information in each packet then the new model has several properties that the old model has. For example: Traffic engineering can be done at any point in the path. Anti-Spoof checking can be done at the interface between the customer and ISP. If a link is down between any ISP and host X,Y,Z the internet can reroute the packet to one of the other addresses for X,Y,Z. The more I thought about it the more sense this model made to me and it helped me understand many of the other proposed alternatives as attempts to optimize this model and remove some of the information from the packet. Also it made it clearer to me that the discussion about locator/ID split has more to do with trying to preserve a single address representation to current and future software and that it was the multiple locators and not the locator/ID split that helps solve the routing portion of the multihoming problem. To further understand the possibilities I realized that IPv6 did not provide the means to include all of these addresses but IPv6 does have a method of being extended to include such addresses, extension headers. Actually putting the multiple destination addresses in extension headers might not be too much different from the current hop-by-hop extension headers. (And there would have to be something in the standard to avoid loops in the case of a link failure, something that marks an address as already having failed, but again that might not be too different from the hop-by-hop extension headers.) Considering the extension headers helped me move one step closer to the real world and also to envision at least one optimization. To me it seems that the natural point to discover the multiple paths from host A,B,C to host X,Y,X is at the host A,B,C, through DNS lookup etc. It seems that shim6 is already capable of handling that information so I think it makes sense for the end host to put the X,Y,Z destination addresses in the packet. However I can see two possibilities for where in the network the multiple source addresses are placed in the packet. Members of the "I hate middleboxes club" could have their hosts fill in the multiple source addresses. However members of the "I only want my hosts to have one IP address" club could design their network to have a middle box at the interface to their ISPs and have the middelbox add the multiple source addresses. The middle box would also have to do the right magic to route an inbound packet with the multiple destination addresses to the end host with the single IP address but it could do so without having to maintain state for every connection through the middlebox. (Middleboxes with flow-based architecture that are required to maintain state are one of my main objections to middleboxes.) Anyway the model of putting enough information in the packet would seem to support at least two options for the end network, allowing some choice for the end network. And if implemented with extension headers it might be partially backwards compatible with what is implemented today, it wouldn't break anything, but hosts/networks that did not support the new model wouldn't benefit from all of the redundancy of multihoming. There has been talk on the list about not wanting to overload identifiers but it has been helpful to me to think of unique unchanging IDs for hosts in terms of the above model. If we add another IP number to each host so we have host A,B,C,D and host W,X,Y,Z but D and W have no associated ISPs things still work. It is about the same case as if D and W did have an associated ISP but the links to those ISPs were down. IPs D and W could even be assigned based on GPS location or something similar if they where still guaranteed to be unique. The identifiers are overloaded but it might be workable as an interim solution, something similar to shim6. Another possible optimization could be to strip off the multiple source addresses at the interface between the customer and the ISP and just leave the one that is associated with that ISP. But then the receiving host wouldn't automatically know all of the return addresses of the sending host. Sorry if this was obvious to everyone but I thought the idea of putting all of the required info in the packets should at least be floated and shot down and hopefully the shooting down and discussion would be useful in the long run. To me considering the extreme case was helpful in understanding the problem and in classifying some of the proposed alternatives. --- Bruce Curtis bruce.curtis@ndsu.edu Certified NetAnalyst II 701-231-8527 North Dakota State University --Apple-Mail-35-135586915 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

=A0 This may be obvious to = everyone since I haven't seen much discussion about this model but it = helped me understand the issues.

=A0 In the IPv4 multihoming = model the information about multiple paths from host A to host Z is in = the routing table of the core routers in the Internet.
=A0 =A0=A0= =A0=A0 =A0=A0 =A0

=A0 =A0 =A0=A0 =A0ISP 1 =A0 = ---------------- =A0 =A0=A0 =A0I=A0 =A0---------------------------------=A0= =A0ISP 7
=A0 =A0 =A0=A0 =A0=A0 =A0| =A0 =A0=A0 =A0=A0 =A0=A0 = =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0n=A0 =A0 =A0=A0= =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 = =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0|
=A0=A0 =A0=A0 =A0=A0 = =A0A=A0 =A0--=A0 ISP 2 =A0-------=A0 =A0 =A0=A0 =A0t=A0 = =A0------------------------=A0 ISP 8=A0 --=A0 Z
=A0 =A0 =A0=A0 = =A0=A0 =A0| =A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 = =A0=A0 =A0=A0 =A0=A0 =A0e=A0 =A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0= =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 = =A0|
=A0 =A0=A0 =A0=A0 =A0ISP 3 =A0 ---------------=A0 =A0 =A0=A0= =A0r=A0 ---------------------------------=A0 =A0ISP 9
=A0 =A0 = =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0= =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0n
=A0 =A0 =A0=A0 =A0=A0 =A0=A0 = =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0= =A0=A0 =A0e
=A0 =A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 = =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 = =A0t

=A0 If = we change the model and take the information about multiple paths out of = the core routers and give each host a different IP number for each of = it's ISPs, then to preserve some of the properties of the old model we = still need=A0 to have the multiple path information available to the = network somehow.


=A0=A0=A0=A0 =A0=A0 =A0ISP = 1 =A0 ---------------- =A0 =A0=A0 =A0I=A0 = =A0---------------------------------=A0 =A0ISP 7
=A0 =A0 =A0=A0 =A0=A0= =A0| =A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 = =A0=A0 =A0=A0 =A0n=A0 =A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0= =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 = =A0|
=A0 =A0A,B,C=A0 =A0--=A0 ISP 2 =A0-------=A0 =A0 =A0=A0 = =A0t=A0 =A0------------------------=A0 ISP 8=A0 --=A0 X,Y,Z
=A0 = =A0 =A0=A0 =A0=A0 =A0| =A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0= =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0e=A0 =A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0= =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 = =A0=A0 =A0|
=A0 =A0=A0 =A0=A0 =A0ISP 3 =A0 ---------------=A0 = =A0 =A0=A0 =A0r=A0 ---------------------------------=A0 =A0ISP = 9
=A0 =A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0= =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0n
=A0 =A0 = =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0= =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0e
=A0 =A0 =A0=A0 =A0=A0 =A0=A0 = =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0= =A0=A0 =A0t

=A0= If we imagine a time in the future where every host has 100 Mbps = connection to the Internet like some homes in Japan today and we have = networks that support Jumbo frames it's easier to consider the = possibility that we put the required information in every packet from = host A,B,C to host X,Y,Z.=A0 That is, we put all of the destination = addresses X,Y,Z in the packet as well as the source addresses = A,B,C.=A0=A0
=A0 So basically we take the information about = multiple paths out of the routing tables where it doesn't scale and put = the multiple path info in each packet, which should scale right along = with the speed of the router.

=A0 If we put this = information in each packet then the new model has several properties = that the old model has.=A0 For example:

=A0 =A0=A0 =A0=A0 =A0Traffic = engineering can be done at any point in the path.
=A0 =A0=A0 = =A0=A0 =A0
=A0=A0 =A0=A0 =A0=A0 =A0Anti-Spoof checking can be = done at the interface between the customer and ISP.

=A0=A0 =A0=A0 =A0=A0 =A0If = a link is down between any ISP and host X,Y,Z the internet can reroute = the packet
=A0=A0 =A0=A0 =A0=A0 =A0to one of the other = addresses for X,Y,Z.

=A0 The more I thought = about it the more sense this model made to me and it helped me = understand many of the other proposed alternatives as attempts to = optimize this model and remove some of the information from the = packet.

=A0 = Also it made it clearer to me that the discussion about locator/ID split = has more to do with trying to preserve a single address representation = to current and future software and that it was the multiple locators and = not the locator/ID split that helps solve the routing portion of the = multihoming problem.

=A0 To further understand = the possibilities I realized that IPv6 did not provide the means to = include all of these addresses but IPv6 does have a method of being = extended to include such addresses, extension headers.=A0 Actually = putting the multiple destination addresses in extension headers might = not be too much different from the current hop-by-hop extension = headers.=A0 =A0(And there would have to be something in the standard to = avoid loops in the case of a link failure, something that marks an = address as already having failed, but again that might not be too = different from the hop-by-hop extension headers.)

=A0 Considering the = extension headers helped me move one step closer to the real world and = also to envision at least=A0 one optimization.=A0 To me it seems that = the natural point to discover the multiple paths from host A,B,C to host = X,Y,X is at the host A,B,C, through DNS lookup etc.=A0 It seems that = shim6 is already capable of handling that information so I think it = makes sense for the end host to put the X,Y,Z destination addresses in = the packet.=A0 However I can see two possibilities for where in the = network the multiple source addresses are placed in the packet.=A0 = Members of the "I hate middleboxes club" could have their hosts fill in = the multiple source addresses.=A0 However members of the "I only want my = hosts to have one IP address" club could design their network to have a = middle box at the interface to their ISPs and have the middelbox add the = multiple source addresses.=A0 The middle box would also have to do the = right magic to route an inbound packet with the multiple destination = addresses to the end host with the single IP address but it could do so = without having to maintain state for every connection through the = middlebox.=A0 (Middleboxes with flow-based architecture that are = required to maintain state are one of my main objections to = middleboxes.)=A0 Anyway the model of putting enough information in the = packet=A0 would seem to support at least two=A0 options for the end = network, allowing some choice for the end network. =A0And if implemented = with extension headers it might be partially backwards compatible with = what is implemented today, it wouldn't break anything, but = hosts/networks that did not support the new model wouldn't benefit from = all of the redundancy of multihoming.

=A0 There has been talk on = the list about not wanting to overload identifiers but it has been = helpful to me to think of unique unchanging IDs for hosts in terms of = the above model.=A0 If we add another IP number to each host so we have = host A,B,C,D and host W,X,Y,Z but D and W have no associated ISPs things = still work.=A0 It is about the same case as=A0 if D and W did have an = associated ISP but the links to those ISPs were down.=A0 IPs D and W = could even be assigned based on GPS location or something similar if = they where still guaranteed to be unique.=A0 The identifiers are = overloaded but it might be workable as an interim solution, something = similar to shim6.

=A0 Another possible = optimization could be to strip off the multiple source addresses at the = interface between the customer and the ISP and just leave the one that = is associated with that ISP.=A0 But then the receiving host wouldn't = automatically know all of the return addresses of the sending = host.
=A0=A0
=A0 Sorry if this was obvious to everyone = but I thought the idea of putting all of the required info in the = packets should at least be floated and shot down and hopefully the = shooting down and discussion would be useful in the long run.=A0 To me = considering the extreme case was helpful in understanding the problem = and in classifying some of the proposed alternatives.



---

Bruce Curtis =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = bruce.curtis@ndsu.edu

=

Certified NetAnalyst II=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 701-231-8527

North Dakota State = University =A0 =A0 =A0 =A0

=

= --Apple-Mail-35-135586915-- --===============1262754116== 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 --===============1262754116==-- From architecture-discuss-bounces@ietf.org Tue Dec 05 00:19:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrSfy-0006B9-Jl; Tue, 05 Dec 2006 00:17:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrSfx-0006B0-Hv for architecture-discuss@ietf.org; Tue, 05 Dec 2006 00:17:05 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrSfw-0001DL-9s for architecture-discuss@ietf.org; Tue, 05 Dec 2006 00:17:05 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id CA52387303; Tue, 5 Dec 2006 00:17:01 -0500 (EST) To: architecture-discuss@ietf.org Subject: Re: [arch-d] A straw man analysis of why send-receive packet paradigm is unsustainable Message-Id: <20061205051701.CA52387303@mercury.lcs.mit.edu> Date: Tue, 5 Dec 2006 00:17:01 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.6 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: John Day >> generally a MAC Address identifies an interface. >> What was the reason/need then in creating IP addresses? > MAC addresses are flat Exactly. Also, remember that globally unique MAC addresses (the 48-bit thingys) are about a decade younger than IPv4 addresses; they didn't exist as an option when IPv4 was done. > IP addresses weren't suppose to be but really were until CIDR came > along 15 years later. Ah, no. IP addresses always had two levels of hierarchy (net # and "rest"), and very quickly (see IEN-82, from February 1979), were hacked to have three levels of hierarchy (net #, subnet # and host). > IP addresses were suppose to be the addresses of "gateways" which > turned out to be routers. Huh? They could name routers (well, router interfaces), but they were always intended to name destination hosts (well, their network interfaces). In what sense were they the "addresses" (whatever you mean by That Word) of gateways? > MAC addresses were in IEEE and IP addresses were in the DoD. But not at the same time... > It has always been odd that ... an *Internet* address named a *subnet* > point of attachment. I'm not sure I completely understand why this is odd. If I understand correctly what your point is, you'd rather see something where the internetwork-level name is for a particular physical network, and then some other name indicates which interface on that particular physical network is desired? But that's basically what an IP address has, if you look at it right. The "net #" part (include the subnet # as well, if there is one) names the physical network. The "rest" field names a SNPA. For efficiency reasons, the two are concatenated together into a single field, but logically they are separate - and in fact, the entity at the other end doesn't have much use for one without the other, and is happy to use them as a package. Yes, there are times when it's useful to be able to just name a physical network, and no SNPA's (e.g. in a routing update), but you just leave those bits zero in that case. Now, again for efficiency reasons, the rest field has a limited length. So, on some networks (e.g. 1822 - in fact, all actual extant networks at the time IPv4 was designed, other than X.25) which have short enough SNPA names, you can actually stick a real SNPA in there; in others (e.g. Ethernet) you have to shoehorn 10 pounds into a 5-pound sack, and as a result you have this mapping layer, ARP, etc. But the fact that usually you need both names (physical network, plus SNPA) to do anything, plus the fact that most times, you don't have any use for one without the other, makes it IMO not unreasonable to concatenate them into a single syntactic entity. Or am I completely missing your point? Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Dec 05 10:27:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrcAb-00021B-SO; Tue, 05 Dec 2006 10:25:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrcAa-000212-IP for architecture-discuss@ietf.org; Tue, 05 Dec 2006 10:25:20 -0500 Received: from mtagate6.de.ibm.com ([195.212.29.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrcAY-0002QV-4f for architecture-discuss@ietf.org; Tue, 05 Dec 2006 10:25:20 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate6.de.ibm.com (8.13.8/8.13.8) with ESMTP id kB5FPG6G291042 for ; Tue, 5 Dec 2006 15:25:16 GMT Received: from d12av01.megacenter.de.ibm.com (d12av01.megacenter.de.ibm.com [9.149.165.212]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kB5FPFIj2232436 for ; Tue, 5 Dec 2006 16:25:15 +0100 Received: from d12av01.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av01.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kB5FPFYF026587 for ; Tue, 5 Dec 2006 16:25:15 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av01.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kB5FPFu8026583; Tue, 5 Dec 2006 16:25:15 +0100 Received: from zurich.ibm.com ([9.4.210.199]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA29808; Tue, 5 Dec 2006 16:25:14 +0100 Message-ID: <45758F59.3050308@zurich.ibm.com> Date: Tue, 05 Dec 2006 16:25:13 +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: Bruce Curtis Subject: Re: [arch-d] It's about Information References: <71F6867B-BB26-4A7D-9480-D8189BB32DB3@ndsu.edu> In-Reply-To: <71F6867B-BB26-4A7D-9480-D8189BB32DB3@ndsu.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Bruce Curtis wrote: ... > So basically we take the information about multiple paths out of the > routing tables where it doesn't scale and put the multiple path info in > each packet, which should scale right along with the speed of the router. That is essentially what shim6 does, except that it only sends the multiple locator-addresses when it needs to. The price of not putting the full set of locators in every packet is the need to create state at both ends to manage the locator set. Brian _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Dec 05 10:51:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrcZV-00065p-AG; Tue, 05 Dec 2006 10:51:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GrcZU-00065k-Fv for architecture-discuss@ietf.org; Tue, 05 Dec 2006 10:51:04 -0500 Received: from sccrmhc15.comcast.net ([204.127.200.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GrcZP-00068z-H8 for architecture-discuss@ietf.org; Tue, 05 Dec 2006 10:51:04 -0500 Received: from [10.0.1.12] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (sccrmhc15) with ESMTP id <2006120515505501500b2k0ne>; Tue, 5 Dec 2006 15:50:59 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <20061205051701.CA52387303@mercury.lcs.mit.edu> References: <20061205051701.CA52387303@mercury.lcs.mit.edu> Date: Tue, 5 Dec 2006 10:50:50 -0500 To: jnc@mercury.lcs.mit.edu (Noel Chiappa), architecture-discuss@ietf.org From: John Day Subject: Re: [arch-d] A straw man analysis of why send-receive packet paradigm is unsustainable Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.6 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org At 0:17 -0500 2006/12/05, Noel Chiappa wrote: > > From: John Day > > >> generally a MAC Address identifies an interface. > > >> What was the reason/need then in creating IP addresses? > > > MAC addresses are flat > >Exactly. > >Also, remember that globally unique MAC addresses (the 48-bit thingys) are >about a decade younger than IPv4 addresses; they didn't exist as an option >when IPv4 was done. Well, only sort of. MAC addresses from IEEE did not exist. But Ethernet did. > > > IP addresses weren't suppose to be but really were until CIDR came > > along 15 years later. > >Ah, no. IP addresses always had two levels of hierarchy (net # and "rest"), >and very quickly (see IEN-82, from February 1979), were hacked to have three >levels of hierarchy (net #, subnet # and host). Yea, but the hierarchy was really applicable "within an organization," not across organizations. And very quickly Class B and C addresses were being handed out as "network" addresses without regard to what *network, i.e. Class A or B, they were in. Thus destroying any usefulness of the hierarchy. > > > IP addresses were suppose to be the addresses of "gateways" which > > turned out to be routers. > >Huh? They could name routers (well, router interfaces), but they were always >intended to name destination hosts (well, their network interfaces). In what >sense were they the "addresses" (whatever you mean by That Word) of gateways? You are right, I mis-spoke. I was thinking about how early on IP was supposedly running at level higher than say IMP addressing, but that sort of disappeared as that role was taken on by MAC addresses and IP addresses moved down a level in some sense. > > > MAC addresses were in IEEE and IP addresses were in the DoD. > >But not at the same time... Not initially, but they did overlap. ;-) > > > > It has always been odd that ... an *Internet* address named a *subnet* > > point of attachment. > >I'm not sure I completely understand why this is odd. If I understand >correctly what your point is, you'd rather see something where the >internetwork-level name is for a particular physical network, and then some >other name indicates which interface on that particular physical network is >desired? > >But that's basically what an IP address has, if you look at it right. The >"net #" part (include the subnet # as well, if there is one) names the >physical network. The "rest" field names a SNPA. For efficiency reasons, the >two are concatenated together into a single field, but logically they are >separate - and in fact, the entity at the other end doesn't have much use >for one without the other, and is happy to use them as a package. > >Yes, there are times when it's useful to be able to just name a physical >network, and no SNPA's (e.g. in a routing update), but you just leave those >bits zero in that case. > >Now, again for efficiency reasons, the rest field has a limited length. So, >on some networks (e.g. 1822 - in fact, all actual extant networks at the time >IPv4 was designed, other than X.25) which have short enough SNPA names, you >can actually stick a real SNPA in there; in others (e.g. Ethernet) you have >to shoehorn 10 pounds into a 5-pound sack, and as a result you have this >mapping layer, ARP, etc. > >But the fact that usually you need both names (physical network, plus SNPA) >to do anything, plus the fact that most times, you don't have any use for one >without the other, makes it IMO not unreasonable to concatenate them into a >single syntactic entity. > >Or am I completely missing your point? I think you are missing my point but I won't swear to it! My point was that IP addresses are points of attachment and not node addresses in the sense of 1498. Take care, john _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Dec 06 19:36:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs7Dz-0005Te-8l; Wed, 06 Dec 2006 19:34:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gs7Dy-0005PU-1v for architecture-discuss@ietf.org; Wed, 06 Dec 2006 19:34:54 -0500 Received: from smtp1.nodak.edu ([134.129.111.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gs7Dw-0002mX-Lx for architecture-discuss@ietf.org; Wed, 06 Dec 2006 19:34:54 -0500 Received: from [134.129.95.120] (netmender.cc.ndsu.NoDak.edu [134.129.95.120]) (authenticated bits=0) by smtp1.NoDak.edu (8.13.1/8.13.1) with ESMTP id kB70YqGN030278 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 6 Dec 2006 18:34:52 -0600 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <45758F59.3050308@zurich.ibm.com> References: <71F6867B-BB26-4A7D-9480-D8189BB32DB3@ndsu.edu> <45758F59.3050308@zurich.ibm.com> Message-Id: <8C4792D2-E5B0-4CB9-AFB7-8D9AF7E1BC62@ndsu.edu> From: Bruce Curtis Subject: Re: [arch-d] It's about Information Date: Wed, 6 Dec 2006 18:34:51 -0600 To: architecture-discuss@ietf.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede 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="===============0106935447==" Errors-To: architecture-discuss-bounces@ietf.org --===============0106935447== Content-Type: multipart/alternative; boundary=Apple-Mail-48-313414010 --Apple-Mail-48-313414010 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Dec 5, 2006, at 9:25 AM, Brian E Carpenter wrote: > Bruce Curtis wrote: > ... >> So basically we take the information about multiple paths out >> of the routing tables where it doesn't scale and put the multiple >> path info in each packet, which should scale right along with the >> speed of the router. > > That is essentially what shim6 does, except that it only sends the > multiple locator-addresses when it needs to. The price of not putting > the full set of locators in every packet is the need to create state > at both ends to manage the locator set. > > Brian Right, and one of the complaints about shim6 is that decisions about which of the multiple paths are used is moved from somewhere in the network (most commonly at the customer ISP interface) to the end host. If the info were in each packet the decision could be made in the network again. Also I don't think that shim6 includes the multiple source addresses in the packets which led to the complaint that implementing anti-spoofing was then difficult or impossible. Or that shim6 had to do extra work to put the correct source address in the packet so that anti-spoofing still worked the old way. But again this complaint was probably about wanting to do traffic engineering for load balancing at the customer ISP interface also. I understood some of the complaints about shim6 and other proposals better when I compared them to the model where all the address info is in each packet. --- Bruce Curtis bruce.curtis@ndsu.edu Certified NetAnalyst II 701-231-8527 North Dakota State University --Apple-Mail-48-313414010 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Dec 5, 2006, at = 9:25 AM, Brian E Carpenter wrote:

Bruce Curtis wrote:
=A0 So basically we take the = information about multiple paths out of=A0 the routing tables where it = doesn't scale and put the multiple path=A0 info in each packet, which = should scale right along with the speed of=A0 the router.
=

That is essentially what shim6 does, except that it = only sends the
multiple locator-addresses when = it needs to. The price of not putting
the full = set of locators in every packet is the need to create state
at both ends to manage the locator set.

=A0=A0 Brian
=
=A0 Right, and one of the complaints about = shim6 is that decisions about which of the multiple paths are used is = moved from somewhere in the network (most commonly at the customer ISP = interface) to the end host.=A0 If the info were in each packet the = decision could be made in the network again.

=A0 Also I don't think that = shim6 includes the multiple source addresses in the packets which led to = the complaint that implementing anti-spoofing was then difficult or = impossible.=A0 Or that shim6 had to do extra work to put the correct = source address in the packet so that anti-spoofing still worked the old = way.=A0 But again this complaint was probably about wanting to do = traffic engineering for load balancing at the customer ISP interface = also.

=A0 I = understood some of the complaints about shim6 and other proposals better = when I compared them to the model where all the address info is in each = packet.=A0=A0


---

Bruce Curtis =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 bruce.curtis@ndsu.edu

=

Certified NetAnalyst II=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 701-231-8527

North Dakota State = University =A0 =A0 =A0 =A0

=

= --Apple-Mail-48-313414010-- --===============0106935447== 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 --===============0106935447==-- From architecture-discuss-bounces@ietf.org Thu Dec 07 03:21:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsETc-0008Qv-VP; Thu, 07 Dec 2006 03:19:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsETb-0008Qj-F3 for architecture-discuss@ietf.org; Thu, 07 Dec 2006 03:19:31 -0500 Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsETZ-0005S9-U8 for architecture-discuss@ietf.org; Thu, 07 Dec 2006 03:19:31 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.13.8/8.13.8) with ESMTP id kB78JSgk085650 for ; Thu, 7 Dec 2006 08:19:28 GMT Received: from d12av03.megacenter.de.ibm.com (d12av03.megacenter.de.ibm.com [9.149.165.213]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kB78JSfG3067980 for ; Thu, 7 Dec 2006 09:19:28 +0100 Received: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av03.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kB78JS6V016219 for ; Thu, 7 Dec 2006 09:19:28 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av03.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kB78JSpW016208; Thu, 7 Dec 2006 09:19:28 +0100 Received: from zurich.ibm.com (dyn-9-159-130-87.ge.ch.ibm.com [9.159.130.87]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA100478; Thu, 7 Dec 2006 09:19:27 +0100 Message-ID: <4577CE90.1020800@zurich.ibm.com> Date: Thu, 07 Dec 2006 09:19:28 +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: Bruce Curtis Subject: Re: [arch-d] It's about Information References: <71F6867B-BB26-4A7D-9480-D8189BB32DB3@ndsu.edu> <45758F59.3050308@zurich.ibm.com> <8C4792D2-E5B0-4CB9-AFB7-8D9AF7E1BC62@ndsu.edu> In-Reply-To: <8C4792D2-E5B0-4CB9-AFB7-8D9AF7E1BC62@ndsu.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Bruce Curtis wrote: > > On Dec 5, 2006, at 9:25 AM, Brian E Carpenter wrote: > >> Bruce Curtis wrote: >> ... >> >>> So basically we take the information about multiple paths out of >>> the routing tables where it doesn't scale and put the multiple path >>> info in each packet, which should scale right along with the speed >>> of the router. >> >> >> That is essentially what shim6 does, except that it only sends the >> multiple locator-addresses when it needs to. The price of not putting >> the full set of locators in every packet is the need to create state >> at both ends to manage the locator set. >> >> Brian > > > Right, and one of the complaints about shim6 is that decisions about > which of the multiple paths are used is moved from somewhere in the > network (most commonly at the customer ISP interface) to the end host. > If the info were in each packet the decision could be made in the > network again. Yes. But then, some stakeholders might prefer the decision to be taken by the host; that would allow a host to perform arbitrage between ISPs, in the economic interest of the host. > > Also I don't think that shim6 includes the multiple source addresses > in the packets which led to the complaint that implementing > anti-spoofing was then difficult or impossible. Or that shim6 had to > do extra work to put the correct source address in the packet so that > anti-spoofing still worked the old way. But again this complaint was > probably about wanting to do traffic engineering for load balancing at > the customer ISP interface also. Well, the tricky issue for shim6 is exit router selection - if ingress filtering or RPF checks are in place, sending a packet via the wrong exit router is catastrophic. > I understood some of the complaints about shim6 and other proposals > better when I compared them to the model where all the address info is > in each packet. Yes, it's an interesting way to think about things, I agree. Brian > > > --- > Bruce Curtis bruce.curtis@ndsu.edu > Certified NetAnalyst II 701-231-8527 > North Dakota State University > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Thu Dec 07 03:42:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsEpf-0002fq-Hq; Thu, 07 Dec 2006 03:42:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsEpe-0002fV-9s for architecture-discuss@ietf.org; Thu, 07 Dec 2006 03:42:18 -0500 Received: from outbound-mail.lax.untd.com ([64.136.28.164]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GsEpZ-0000pb-US for architecture-discuss@ietf.org; Thu, 07 Dec 2006 03:42:18 -0500 Received: from webmail11.lax.untd.com (webmail11.lax.untd.com [10.131.27.151]) by smtpout05.lax.untd.com with SMTP id AABCZRW9CALN4A3A for (sender ); Thu, 7 Dec 2006 00:42:10 -0800 (PST) X-UNTD-OriginStamp: AcganUYbgVGZ0C6nm/9IPatablCmMCeKxzMOXoR03KFTljmnw6aRrQ== Received: (from fergdawg@netzero.net) by webmail11.lax.untd.com (jqueuemail) id L8YP9PMS; Thu, 07 Dec 2006 00:41:36 PST Received: from [24.23.201.115] by webmail11.lax.untd.com with HTTP: Thu, 7 Dec 2006 08:41:24 GMT X-Originating-IP: [24.23.201.115] Mime-Version: 1.0 From: "Fergie" Date: Thu, 7 Dec 2006 08:41:24 GMT To: brc@zurich.ibm.com Subject: Re: [arch-d] It's about Information X-Mailer: Webmail Version 4.0 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain Message-Id: <20061207.004136.2671.1625820@webmail11.lax.untd.com> X-ContentStamp: 12:6:1655027206 X-MAIL-INFO: 3ee51571e5bdf015bd0c15490c69d4fd19c421909041104185e09d4de4e4d9f5c959b4c051e074e98015e115bd0c25712d150d35d1ddf9a5d4ddd4d484d1347df4214d4dc1f5454db0b47d20e10931a11d1ddde43950f9 X-UNTD-Peer-Info: 10.131.27.151|webmail11.lax.untd.com|webmail11.lax.untd.com|fergdawg@netzero.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- Brian E Carpenter wrote: >> Also I don't think that shim6 includes the multiple source address= es = >> in the packets which led to the complaint that implementing = >> anti-spoofing was then difficult or impossible. Or that shim6 had to= = >> do extra work to put the correct source address in the packet so that= = >> anti-spoofing still worked the old way. But again this complaint was= = >> probably about wanting to do traffic engineering for load balancing = at = >> the customer ISP interface also. > >Well, the tricky issue for shim6 is exit router selection - if ingress >filtering or RPF checks are in place, sending a packet via the wrong >exit router is catastrophic. > Speaking as one of the authors of BCP 38, yes, it is indeed tricky. And perhaps, as folks may eventually decide, unacceptable. Having said that, I would also encourage folks to check-in on = SAVA: http://www.nrc.tsinghua.edu.cn/mailman/listinfo/sava =2E..where thoughts(very few thus far) on source address verification in v6 is encouraged. :-) - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.1 (Build 1557) wj8DBQFFd9Ouq1pz9mNUZTMRAiQwAKCufj8/wfFuM/PWXWkUPOJNc+dOswCfQ7g4 JYeBIIo71HYUaor9ky3Z5ZM=3D =3D8JaC -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/ _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Dec 07 07:07:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsI0O-000597-6C; Thu, 07 Dec 2006 07:05:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsI0N-00057I-20 for architecture-discuss@ietf.org; Thu, 07 Dec 2006 07:05:35 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsI0G-00054w-Pe for architecture-discuss@ietf.org; Thu, 07 Dec 2006 07:05:35 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 758AC34069; Thu, 7 Dec 2006 07:05:28 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Dec 2006 07:05:28 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [arch-d] A straw man analysis of why send-receive packetparadigm is unsustainable Date: Thu, 7 Dec 2006 07:05:26 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC010B606F@tayexc14.americas.cpqcorp.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] A straw man analysis of why send-receive packetparadigm is unsustainable Thread-Index: AccX1zKcIJi2TzUPQGuYC7GRTGRCDACHzNHw From: "Bound, Jim" To: "John Day" , "Peter Sherbin" , "Fred Baker" X-OriginalArrivalTime: 07 Dec 2006 12:05:28.0314 (UTC) FILETIME=[FC41DDA0:01C719F7] X-Spam-Score: 0.6 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Pekka Nikander , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > At 10:39 -0800 2006/12/04, Peter Sherbin wrote: > > > but generally a MAC Address identifies an interface. > > > >What was the reason/need then in creating IP addresses? >=20 > Interesting question, isn't it? IEEE was not working on the Internet and MAC addresses were owned by that organization. THey also identified the NIC which is different than layer 3 in a model and definitely for implementation, and I agree with what was done completely. The trick is to adjust it now. We also thought 32bits were enough. I also agree with the IP subnet model. >=20 > But we really don't worry about that as long as the=20 > implementation works, right? If the implementation works, it=20 > must be right. Once a standard is accepted widely in the market by paying customers that is exactly what happens yes. >=20 > Apparently very few people had enough OS experience to=20 > realize that we had made a mistake with ARPANet host=20 > addresses until Saltzer's paper came along, even though we=20 > had been talking about since the Tinker AFB IMP in '72. I still do not think it was a mistake it was required at the time the proof is the success of the Internet today. Billions of dollars flowing and users all in cyberspace that is a good thing. Dreams of architecture are nice but reality is unless the market adopts them they were purely an academic exercise, which is not a bad thing. > We were going to fix it with IPng, but by then everyone was=20 > so attached to naming the interface and there were probably=20 > only 25 people who knew why we shouldn't, and of course to=20 > air all the dirty laundry CLNP did distinguish point of=20 > attachments and node addresses.=20 > So that was one more reason not to. Not quite. We had no intention of fixing it with IPng and the resulting consensus objective was to do as little harm to the current IPvN as possible and all proposals had to provide a transition plan (possibly today our term "jack-up"). =20 All please see RFC 1752 for the record. CLNP never worked ever as widely as IP, and I agree the IP layer should be connectionless and what we do here for the future should remain connectionless. This had many and healthy debates I was integral them as you know. Best, /jim _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Dec 07 07:07:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsI0n-0006Gy-Vd; Thu, 07 Dec 2006 07:06:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsI0n-0006Gs-8S for architecture-discuss@ietf.org; Thu, 07 Dec 2006 07:06:01 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsI0f-0005Cj-0L for architecture-discuss@ietf.org; Thu, 07 Dec 2006 07:06:01 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id D857A340D3; Thu, 7 Dec 2006 07:05:52 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Dec 2006 07:05:52 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [arch-d] A straw man analysis of why send-receive packet paradigmis unsustainable Date: Thu, 7 Dec 2006 07:05:51 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC010B6070@tayexc14.americas.cpqcorp.net> In-Reply-To: <571573.39761.qm@web31815.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] A straw man analysis of why send-receive packet paradigmis unsustainable Thread-Index: AccX2FyFvsGHvbaDR+CY3rg1xwf3MwCH6mig From: "Bound, Jim" To: "David Barak" , "Peter Sherbin" , X-OriginalArrivalTime: 07 Dec 2006 12:05:52.0689 (UTC) FILETIME=[0AC93210:01C719F8] 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: , Errors-To: architecture-discuss-bounces@ietf.org Well stated. /jim=20 > -----Original Message----- > From: David Barak [mailto:thegameiam@yahoo.com]=20 > Sent: Monday, December 04, 2006 2:13 PM > To: Peter Sherbin; architecture-discuss@ietf.org > Subject: Re: [arch-d] A straw man analysis of why=20 > send-receive packet paradigmis unsustainable >=20 >=20 > --- Peter Sherbin wrote: >=20 > > > but generally a MAC Address identifies an > > interface. > >=20 > > What was the reason/need then in creating IP addresses? >=20 > Logical addressing - MAC is to provide a unique physical=20 > hardware address, IP is to provide aggregatible logical=20 > groups of addresses, and to hide the MAC information from=20 > distant subnets (for which it is not relevant). >=20 > -David >=20 > David Barak > Need Geek Rock? Try The Franchise:=20 > http://www.listentothefranchise.com >=20 >=20 > =20 > ______________________________________________________________ > ______________________ > Do you Yahoo!? > Everyone is raving about the all-new Yahoo! Mail beta. > http://new.mail.yahoo.com >=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 Thu Dec 07 07:07:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsI1l-0006bB-UP; Thu, 07 Dec 2006 07:07:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsI1k-0006aD-PH for architecture-discuss@ietf.org; Thu, 07 Dec 2006 07:07:00 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsI1f-0005JD-Hx for architecture-discuss@ietf.org; Thu, 07 Dec 2006 07:07:00 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 67CC834034; Thu, 7 Dec 2006 07:06:55 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Dec 2006 07:06:55 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [arch-d] A straw man analysis of why send-receive packet paradigmis unsustainable Date: Thu, 7 Dec 2006 07:06:54 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC010B6071@tayexc14.americas.cpqcorp.net> In-Reply-To: <20D3CEC3-7E28-4B20-8B75-7E8EF557F662@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] A straw man analysis of why send-receive packet paradigmis unsustainable Thread-Index: AccX2lcfbyZ622e/TUqcUEfT/yGT+wCHbpvw From: "Bound, Jim" To: "Fred Baker" , "Peter Sherbin" X-OriginalArrivalTime: 07 Dec 2006 12:06:55.0293 (UTC) FILETIME=[3019CED0:01C719F8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Pekka Nikander , architecture-discuss@ietf.org, John Day X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Yep WiFi, WIMAX, ATM, X.25, SDLC......................... /jim=20 > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com]=20 > Sent: Monday, December 04, 2006 2:27 PM > To: Peter Sherbin > Cc: Pekka Nikander; architecture-discuss@ietf.org; John Day > Subject: Re: [arch-d] A straw man analysis of why=20 > send-receive packet paradigmis unsustainable >=20 >=20 > On Dec 4, 2006, at 10:39 AM, Peter Sherbin wrote: >=20 > >> but generally a MAC Address identifies an interface. > > > > What was the reason/need then in creating IP addresses? >=20 > Tell me this: what kinds of interfaces do we use in the=20 > Internet? Is every single interface an IEEE 802.3 interface?=20 > What other kinds of interfaces are supported? >=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 Thu Dec 07 07:16:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsIAU-00023p-Pf; Thu, 07 Dec 2006 07:16:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsIAT-00023h-UT for architecture-discuss@ietf.org; Thu, 07 Dec 2006 07:16:01 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsIAP-0006rq-5V for architecture-discuss@ietf.org; Thu, 07 Dec 2006 07:16:01 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id EFBB734085; Thu, 7 Dec 2006 07:15:56 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Dec 2006 07:15:56 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [arch-d] It's about Information Date: Thu, 7 Dec 2006 07:15:55 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC010B6078@tayexc14.americas.cpqcorp.net> In-Reply-To: <71F6867B-BB26-4A7D-9480-D8189BB32DB3@ndsu.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] It's about Information Thread-Index: AccX+aavbiueVdQ+QWC/7RhuGAla6AB/5RlQ From: "Bound, Jim" To: "Bruce Curtis" , X-OriginalArrivalTime: 07 Dec 2006 12:15:56.0837 (UTC) FILETIME=[72E2DD50:01C719F9] X-Spam-Score: 0.1 (/) X-Scan-Signature: 4863a9796402a44fdb52482f353618fe 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: , Content-Type: multipart/mixed; boundary="===============1813795418==" Errors-To: architecture-discuss-bounces@ietf.org This is a multi-part message in MIME format. --===============1813795418== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C719F9.728A7D4A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C719F9.728A7D4A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I like this thinking model. Why is this not a form or source address routing with a lot of other addded value using locators. I also believe that GPS information can add great value to routing and doing some research on that concept for ad hoc nets but have assumed no way could we ever get a standard done to use it? =20 /jim ________________________________ From: Bruce Curtis [mailto:bruce.curtis@ndsu.edu]=20 Sent: Monday, December 04, 2006 6:11 PM To: architecture-discuss@ietf.org Subject: [arch-d] It's about Information =09 =09 This may be obvious to everyone since I haven't seen much discussion about this model but it helped me understand the issues.=20 In the IPv4 multihoming model the information about multiple paths from host A to host Z is in the routing table of the core routers in the Internet. =20 ISP 1 ---------------- I --------------------------------- ISP 7 | n | A -- ISP 2 ------- t ------------------------ ISP 8 -- Z | e | ISP 3 --------------- r --------------------------------- ISP 9 n e t If we change the model and take the information about multiple paths out of the core routers and give each host a different IP number for each of it's ISPs, then to preserve some of the properties of the old model we still need to have the multiple path information available to the network somehow. ISP 1 ---------------- I --------------------------------- ISP 7=20 | n | A,B,C -- ISP 2 ------- t ------------------------ ISP 8 -- X,Y,Z | e | ISP 3 --------------- r --------------------------------- ISP 9 n e t If we imagine a time in the future where every host has 100 Mbps connection to the Internet like some homes in Japan today and we have networks that support Jumbo frames it's easier to consider the possibility that we put the required information in every packet from host A,B,C to host X,Y,Z. That is, we put all of the destination addresses X,Y,Z in the packet as well as the source addresses A,B,C. =20 So basically we take the information about multiple paths out of the routing tables where it doesn't scale and put the multiple path info in each packet, which should scale right along with the speed of the router. If we put this information in each packet then the new model has several properties that the old model has. For example: Traffic engineering can be done at any point in the path. =20 Anti-Spoof checking can be done at the interface between the customer and ISP. If a link is down between any ISP and host X,Y,Z the internet can reroute the packet to one of the other addresses for X,Y,Z. The more I thought about it the more sense this model made to me and it helped me understand many of the other proposed alternatives as attempts to optimize this model and remove some of the information from the packet. Also it made it clearer to me that the discussion about locator/ID split has more to do with trying to preserve a single address representation to current and future software and that it was the multiple locators and not the locator/ID split that helps solve the routing portion of the multihoming problem. To further understand the possibilities I realized that IPv6 did not provide the means to include all of these addresses but IPv6 does have a method of being extended to include such addresses, extension headers. Actually putting the multiple destination addresses in extension headers might not be too much different from the current hop-by-hop extension headers. (And there would have to be something in the standard to avoid loops in the case of a link failure, something that marks an address as already having failed, but again that might not be too different from the hop-by-hop extension headers.) Considering the extension headers helped me move one step closer to the real world and also to envision at least one optimization. To me it seems that the natural point to discover the multiple paths from host A,B,C to host X,Y,X is at the host A,B,C, through DNS lookup etc. It seems that shim6 is already capable of handling that information so I think it makes sense for the end host to put the X,Y,Z destination addresses in the packet. However I can see two possibilities for where in the network the multiple source addresses are placed in the packet. Members of the "I hate middleboxes club" could have their hosts fill in the multiple source addresses. However members of the "I only want my hosts to have one IP address" club could design their network to have a middle box at the interface to their ISPs and have the middelbox add the multiple source addresses. The middle box would also have to do the right magic to route an inbound packet with the multiple destination addresses to the end host with the single IP address but it could do so without having to maintain state for every connection through the middlebox. (Middleboxes with flow-based architecture that are required to maintain state are one of my main objections to middleboxes.) Anyway the model of putting enough information in the packet would seem to support at least two options for the end network, allowing some choice for the end network. And if implemented with extension headers it might be partially backwards compatible with what is implemented today, it wouldn't break anything, but hosts/networks that did not support the new model wouldn't benefit from all of the redundancy of multihoming. There has been talk on the list about not wanting to overload identifiers but it has been helpful to me to think of unique unchanging IDs for hosts in terms of the above model. If we add another IP number to each host so we have host A,B,C,D and host W,X,Y,Z but D and W have no associated ISPs things still work. It is about the same case as if D and W did have an associated ISP but the links to those ISPs were down. IPs D and W could even be assigned based on GPS location or something similar if they where still guaranteed to be unique. The identifiers are overloaded but it might be workable as an interim solution, something similar to shim6. Another possible optimization could be to strip off the multiple source addresses at the interface between the customer and the ISP and just leave the one that is associated with that ISP. But then the receiving host wouldn't automatically know all of the return addresses of the sending host. =20 Sorry if this was obvious to everyone but I thought the idea of putting all of the required info in the packets should at least be floated and shot down and hopefully the shooting down and discussion would be useful in the long run. To me considering the extreme case was helpful in understanding the problem and in classifying some of the proposed alternatives. =09 =09 =09 =09 =09 --- Bruce Curtis bruce.curtis@ndsu.edu Certified NetAnalyst II 701-231-8527 North Dakota State University =20 ------_=_NextPart_001_01C719F9.728A7D4A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I like this thinking model.  Why is this = not a form or=20 source address routing with a lot of other addded value using = locators.  I=20 also believe that GPS information can add great value to routing and = doing some=20 research on that concept for ad hoc nets but have assumed no way could = we ever=20 get a standard done to use it?
 
/jim

From: Bruce Curtis=20 [mailto:bruce.curtis@ndsu.edu]
Sent: Monday, December 04, = 2006 6:11=20 PM
To: architecture-discuss@ietf.org
Subject: = [arch-d]=20 It's about Information


  This may be = obvious to=20 everyone since I haven't seen much discussion about this model but it = helped=20 me understand the issues.

  In the IPv4 multihoming model the information about = multiple paths=20 from host A to host Z is in the routing table of the core routers in = the=20 Internet.
            

        ISP 1   ---------------- =  =20     I  =  --------------------------------- =20  ISP 7
           |   =   =20                =   =20              n  =  =20                =   =20                =   =20              |
          A  =  --  ISP 2=20  -------        t =20  ------------------------  ISP 8  --  Z
           |   =   =20                =   =20              e  =  =20                =   =20                =   =20              |
         ISP 3   = --------------- =20       r  = --------------------------------- =20  ISP 9
                =                =   =20                =  n
                =                =   =20                =  e
                =                =   =20                =  t

  If we change the model and take the information about = multiple=20 paths out of the core routers and give each host a different IP number = for=20 each of it's ISPs, then to preserve some of the properties of the old = model we=20 still need  to have the multiple path information available to = the=20 network somehow.


         ISP 1   = ----------------=20       I =20  ---------------------------------   ISP 7
           |   =   =20                =   =20              n  =  =20                =   =20                =   =20              |
   A,B,C   --  ISP 2  -------  =  =20     t   ------------------------  ISP = 8 =20 --  X,Y,Z
           |   =   =20                =   =20              e  =  =20                =   =20                =   =20              |
         ISP 3   = --------------- =20       r  = --------------------------------- =20  ISP 9
                =                =   =20                =  n
                =                =   =20                =  e
                =                =   =20                =  t

  If we imagine a time in the future where every host has = 100 Mbps=20 connection to the Internet like some homes in Japan today and we have = networks=20 that support Jumbo frames it's easier to consider the possibility that = we put=20 the required information in every packet from host A,B,C to host = X,Y,Z. =20 That is, we put all of the destination addresses X,Y,Z in the packet = as well=20 as the source addresses A,B,C.  
  So basically we take the information about multiple paths = out of=20 the routing tables where it doesn't scale and put the multiple path = info in=20 each packet, which should scale right along with the speed of the=20 router.

  If we put this information in each packet then the new = model has=20 several properties that the old model has.  For example:

         Traffic engineering can be = done at=20 any point in the path.
         
          Anti-Spoof checking = can be=20 done at the interface between the customer and ISP.

          If a link is down = between=20 any ISP and host X,Y,Z the internet can reroute the packet
          to one of the other=20 addresses for X,Y,Z.

  The more I thought about it the more sense this model made = to me=20 and it helped me understand many of the other proposed alternatives as = attempts to optimize this model and remove some of the information = from the=20 packet.

  Also it made it clearer to me that the discussion about = locator/ID=20 split has more to do with trying to preserve a single address = representation=20 to current and future software and that it was the multiple locators = and not=20 the locator/ID split that helps solve the routing portion of the = multihoming=20 problem.

  To further understand the possibilities I realized that = IPv6 did=20 not provide the means to include all of these addresses but IPv6 does = have a=20 method of being extended to include such addresses, extension = headers. =20 Actually putting the multiple destination addresses in extension = headers might=20 not be too much different from the current hop-by-hop extension = headers. =20  (And there would have to be something in the standard to avoid = loops in=20 the case of a link failure, something that marks an address as already = having=20 failed, but again that might not be too different from the hop-by-hop=20 extension headers.)

  Considering the extension headers helped me move one step = closer=20 to the real world and also to envision at least  one = optimization. =20 To me it seems that the natural point to discover the multiple paths = from host=20 A,B,C to host X,Y,X is at the host A,B,C, through DNS lookup = etc.  It=20 seems that shim6 is already capable of handling that information so I = think it=20 makes sense for the end host to put the X,Y,Z destination addresses in = the=20 packet.  However I can see two possibilities for where in the = network the=20 multiple source addresses are placed in the packet.  Members of = the "I=20 hate middleboxes club" could have their hosts fill in the multiple = source=20 addresses.  However members of the "I only want my hosts to have = one IP=20 address" club could design their network to have a middle box at the = interface=20 to their ISPs and have the middelbox add the multiple source = addresses. =20 The middle box would also have to do the right magic to route an = inbound=20 packet with the multiple destination addresses to the end host with = the single=20 IP address but it could do so without having to maintain state for = every=20 connection through the middlebox.  (Middleboxes with flow-based=20 architecture that are required to maintain state are one of my main = objections=20 to middleboxes.)  Anyway the model of putting enough information = in the=20 packet  would seem to support at least two  options for the = end=20 network, allowing some choice for the end network.  And if = implemented=20 with extension headers it might be partially backwards compatible with = what is=20 implemented today, it wouldn't break anything, but hosts/networks that = did not=20 support the new model wouldn't benefit from all of the redundancy of=20 multihoming.

  There has been talk on the list about not wanting to = overload=20 identifiers but it has been helpful to me to think of unique = unchanging IDs=20 for hosts in terms of the above model.  If we add another IP = number to=20 each host so we have host A,B,C,D and host W,X,Y,Z but D and W have no = associated ISPs things still work.  It is about the same case = as  if=20 D and W did have an associated ISP but the links to those ISPs were=20 down.  IPs D and W could even be assigned based on GPS location = or=20 something similar if they where still guaranteed to be unique.  = The=20 identifiers are overloaded but it might be workable as an interim = solution,=20 something similar to shim6.

  Another possible optimization could be to strip off the = multiple=20 source addresses at the interface between the customer and the ISP and = just=20 leave the one that is associated with that ISP.  But then the = receiving=20 host wouldn't automatically know all of the return addresses of the = sending=20 host.
  
  Sorry if this was obvious to everyone but I thought the = idea of=20 putting all of the required info in the packets should at least be = floated and=20 shot down and hopefully the shooting down and discussion would be = useful in=20 the long run.  To me considering the extreme case was helpful in=20 understanding the problem and in classifying some of the proposed=20 alternatives.


---

Bruce Curtis   =    =20                   bruce.curtis@ndsu.edu

Certified NetAnalyst II            =  =20   701-231-8527

North Dakota State University      =20 =  


------_=_NextPart_001_01C719F9.728A7D4A-- --===============1813795418== 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 --===============1813795418==-- From architecture-discuss-bounces@ietf.org Thu Dec 07 12:55:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsNQm-0004y0-T6; Thu, 07 Dec 2006 12:53:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsNQl-0004xu-DV for architecture-discuss@ietf.org; Thu, 07 Dec 2006 12:53:11 -0500 Received: from smtp1.nodak.edu ([134.129.111.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsNQj-0000HE-QE for architecture-discuss@ietf.org; Thu, 07 Dec 2006 12:53:11 -0500 Received: from [134.129.95.120] (netmender.cc.ndsu.NoDak.edu [134.129.95.120]) (authenticated bits=0) by smtp1.NoDak.edu (8.13.1/8.13.1) with ESMTP id kB7Hr91s028355 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 7 Dec 2006 11:53:09 -0600 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <4577CE90.1020800@zurich.ibm.com> References: <71F6867B-BB26-4A7D-9480-D8189BB32DB3@ndsu.edu> <45758F59.3050308@zurich.ibm.com> <8C4792D2-E5B0-4CB9-AFB7-8D9AF7E1BC62@ndsu.edu> <4577CE90.1020800@zurich.ibm.com> Message-Id: <0A6F0E00-1CA2-49E8-A2AD-A3B5D3A1FC8B@ndsu.edu> From: Bruce Curtis Subject: Re: [arch-d] It's about Information Date: Thu, 7 Dec 2006 11:53:07 -0600 To: architecture-discuss@ietf.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.5 (/) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 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="===============0310211237==" Errors-To: architecture-discuss-bounces@ietf.org --===============0310211237== Content-Type: multipart/alternative; boundary=Apple-Mail-15-375710716 --Apple-Mail-15-375710716 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Dec 7, 2006, at 2:19 AM, Brian E Carpenter wrote: > Bruce Curtis wrote: >> On Dec 5, 2006, at 9:25 AM, Brian E Carpenter wrote: >>> Bruce Curtis wrote: >>> ... >>> >>>> So basically we take the information about multiple paths out >>>> of the routing tables where it doesn't scale and put the >>>> multiple path info in each packet, which should scale right >>>> along with the speed of the router. >>> >>> >>> That is essentially what shim6 does, except that it only sends the >>> multiple locator-addresses when it needs to. The price of not >>> putting >>> the full set of locators in every packet is the need to create state >>> at both ends to manage the locator set. >>> >>> Brian >> Right, and one of the complaints about shim6 is that decisions >> about which of the multiple paths are used is moved from somewhere >> in the network (most commonly at the customer ISP interface) to >> the end host. If the info were in each packet the decision could >> be made in the network again. > > Yes. But then, some stakeholders might prefer the decision to be taken > by the host; that would allow a host to perform arbitrage between > ISPs, > in the economic interest of the host. Right but the model with all the info in the packet allows either option, in one person's network they can let the host chose the path and the packets flow as they may and in another person's network they can have intelligent boxes at the customer ISP interface to do load balancing or traffic engineering. > >> Also I don't think that shim6 includes the multiple source >> addresses in the packets which led to the complaint that >> implementing anti-spoofing was then difficult or impossible. Or >> that shim6 had to do extra work to put the correct source address >> in the packet so that anti-spoofing still worked the old way. >> But again this complaint was probably about wanting to do traffic >> engineering for load balancing at the customer ISP interface also. > > Well, the tricky issue for shim6 is exit router selection - if ingress > filtering or RPF checks are in place, sending a packet via the wrong > exit router is catastrophic. Right, but if all of the address info was in the packet we could envision an RPF check that succeeds as long as only one of the multiple source addresses was correct. Also it would be easier for the ISP to implement the RPF check if they chose to, they wouldn't need to know the customers other possible locators, they would only have to check the list of source addresses to see if one of them matched that ISPs address range. >> I understood some of the complaints about shim6 and other >> proposals better when I compared them to the model where all the >> address info is in each packet. > > Yes, it's an interesting way to think about things, I agree. > > Brian I'm glad others find it useful for the discussion. >> --- >> Bruce Curtis bruce.curtis@ndsu.edu >> Certified NetAnalyst II 701-231-8527 >> North Dakota State University >> --------------------------------------------------------------------- >> --- >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www1.ietf.org/mailman/listinfo/architecture-discuss > --- Bruce Curtis bruce.curtis@ndsu.edu Certified NetAnalyst II 701-231-8527 North Dakota State University --Apple-Mail-15-375710716 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Dec 7, 2006, at = 2:19 AM, Brian E Carpenter wrote:

Bruce Curtis wrote:
On Dec 5, 2006, at 9:25 AM, = Brian E Carpenter wrote:
Bruce Curtis wrote:

=
=A0 So basically we take the = information about multiple paths out=A0 of=A0 the routing tables where it = doesn't scale and put the multiple=A0= path=A0 info in = each packet, which should scale right along with the=A0 speed of=A0 the router.
=


That is = essentially what shim6 does, except that it only sends the
multiple locator-addresses when it needs to. The = price of not putting
the full set of locators in = every packet is the need to create state
at both = ends to manage the locator set.

=A0=A0 Brian
=
=A0 Right, and one of the = complaints about shim6 is that decisions=A0 about which of the multiple = paths are used is moved from somewhere in=A0 the network (most commonly at = the customer ISP interface) to the end=A0 host.=A0 If the info were in each = packet the decision could be made in=A0 the network again.
=

Yes. But then, some stakeholders might prefer the = decision to be taken
by the host; that would = allow a host to perform arbitrage between ISPs,
in the economic interest of the = host.

=A0= Right but the model with all the info in the packet allows either = option, in one person's network they can let the host chose the path and = the packets flow as they may and in another person's network they can = have intelligent boxes at the customer ISP interface to do load = balancing or traffic engineering.


=
=A0 Also I don't think that shim6 = includes the multiple source=A0 = addresses in the packets which led to the complaint that = implementing=A0 = anti-spoofing was then difficult or impossible.=A0 Or that shim6 had to=A0 do extra work to put the = correct source address in the packet so that=A0 anti-spoofing still worked = the old way.=A0 But again = this complaint was=A0 = probably about wanting to do traffic engineering for load = balancing=A0 at the = customer ISP interface also.

Well, the = tricky issue for shim6 is exit router selection - if ingress
filtering or RPF checks are in place, sending a = packet via the wrong
exit router is = catastrophic.

=A0 Right, but if all of = the address info was in the packet we could envision an RPF check that = succeeds as long as only one of the multiple source addresses was = correct.=A0 Also it would be easier for the ISP to implement the RPF = check if they chose to, they wouldn't need to know the customers other = possible locators, they would only have to check the list of source = addresses to see if one of them matched that ISPs address = range.

=A0=A0I = understood some of the complaints about shim6 and other=A0 proposals better when I = compared them to the model where all the=A0 address info is in each = packet.
Yes, it's an interesting way to = think about things, I agree.

=A0=A0 = Brian

=A0 I'm glad others find it = useful for the discussion.

=
---
Bruce Curtis =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 bruce.curtis@ndsu.edu
Certified NetAnalyst II=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = 701-231-8527
North Dakota State = University
Architecture-discuss mailing list
=

=


---

Bruce Curtis =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 bruce.curtis@ndsu.edu

=

Certified NetAnalyst II=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 701-231-8527

North Dakota State = University =A0 =A0 =A0 =A0

=

= --Apple-Mail-15-375710716-- --===============0310211237== 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 --===============0310211237==-- From architecture-discuss-bounces@ietf.org Thu Dec 07 13:12:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsNhn-0003bX-F1; Thu, 07 Dec 2006 13:10:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsNhm-0003bS-HF for architecture-discuss@ietf.org; Thu, 07 Dec 2006 13:10:46 -0500 Received: from smtp1.nodak.edu ([134.129.111.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsNhi-0003oh-B0 for architecture-discuss@ietf.org; Thu, 07 Dec 2006 13:10:46 -0500 Received: from [134.129.95.120] (netmender.cc.ndsu.NoDak.edu [134.129.95.120]) (authenticated bits=0) by smtp1.NoDak.edu (8.13.1/8.13.1) with ESMTP id kB7IAf7Z030777 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 7 Dec 2006 12:10:41 -0600 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <816DD9299957E547B5D758D7F977D6DC010B6078@tayexc14.americas.cpqcorp.net> References: <816DD9299957E547B5D758D7F977D6DC010B6078@tayexc14.americas.cpqcorp.net> Message-Id: From: Bruce Curtis Subject: Re: [arch-d] It's about Information Date: Thu, 7 Dec 2006 12:10:40 -0600 To: architecture-discuss@ietf.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 6e8a3b85ef670172081194f0b0f68e6f 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="===============0406926338==" Errors-To: architecture-discuss-bounces@ietf.org --===============0406926338== Content-Type: multipart/alternative; boundary=Apple-Mail-16-376763667 --Apple-Mail-16-376763667 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Dec 7, 2006, at 6:15 AM, Bound, Jim wrote: > I like this thinking model. Why is this not a form or source > address routing with a lot of other addded value using locators. The way I thought about the model all of the routing was still based on the multiple destination addresses and the source addresses would just be used for anti-spoof RPF checking. But if the source info is in every packet lots of other options I hadn't considered are possible with this model as well. > I also believe that GPS information can add great value to routing > and doing some research on that concept for ad hoc nets but have > assumed no way could we ever get a standard done to use it? > > /jim > I know there have been proposals about having the addresses or locators based on location or GPS and it solved some routing problems but I think the ISPs had some objections. When I was thinking through how things would work with this model I was thinking of the GPS info as more of an ID than a locator. Sometimes when there is a problem host it would be nice to have it's location info, but there are privacy issues and perhaps other downsides as well. But one way to use the same model but turn my thinking on it's head is to consider the GPS info as the primary locator and the other multiple locators as ISP specific locators. The question that comes to mind is if that would lessen the ISP objections to the GPS based address model. I'm not an ISP so the answer doesn't come naturally to me, I'll have to think about if for a while. > From: Bruce Curtis [mailto:bruce.curtis@ndsu.edu] > Sent: Monday, December 04, 2006 6:11 PM > To: architecture-discuss@ietf.org > Subject: [arch-d] It's about Information > > > This may be obvious to everyone since I haven't seen much > discussion about this model but it helped me understand the issues. > > In the IPv4 multihoming model the information about multiple > paths from host A to host Z is in the routing table of the core > routers in the Internet. > > > ISP 1 ---------------- I > --------------------------------- ISP 7 > | > n | > A -- ISP 2 ------- t > ------------------------ ISP 8 -- Z > | > e | > ISP 3 --------------- r > --------------------------------- ISP 9 > n > e > t > > If we change the model and take the information about multiple > paths out of the core routers and give each host a different IP > number for each of it's ISPs, then to preserve some of the > properties of the old model we still need to have the multiple > path information available to the network somehow. > > > ISP 1 ---------------- I > --------------------------------- ISP 7 > | > n | > A,B,C -- ISP 2 ------- t ------------------------ > ISP 8 -- X,Y,Z > | > e | > ISP 3 --------------- r > --------------------------------- ISP 9 > n > e > t > > If we imagine a time in the future where every host has 100 Mbps > connection to the Internet like some homes in Japan today and we > have networks that support Jumbo frames it's easier to consider the > possibility that we put the required information in every packet > from host A,B,C to host X,Y,Z. That is, we put all of the > destination addresses X,Y,Z in the packet as well as the source > addresses A,B,C. > So basically we take the information about multiple paths out of > the routing tables where it doesn't scale and put the multiple path > info in each packet, which should scale right along with the speed > of the router. > > If we put this information in each packet then the new model has > several properties that the old model has. For example: > > Traffic engineering can be done at any point in the path. > > Anti-Spoof checking can be done at the interface between > the customer and ISP. > > If a link is down between any ISP and host X,Y,Z the > internet can reroute the packet > to one of the other addresses for X,Y,Z. > > The more I thought about it the more sense this model made to me > and it helped me understand many of the other proposed alternatives > as attempts to optimize this model and remove some of the > information from the packet. > > Also it made it clearer to me that the discussion about locator/ > ID split has more to do with trying to preserve a single address > representation to current and future software and that it was the > multiple locators and not the locator/ID split that helps solve the > routing portion of the multihoming problem. > > To further understand the possibilities I realized that IPv6 did > not provide the means to include all of these addresses but IPv6 > does have a method of being extended to include such addresses, > extension headers. Actually putting the multiple destination > addresses in extension headers might not be too much different from > the current hop-by-hop extension headers. (And there would have > to be something in the standard to avoid loops in the case of a > link failure, something that marks an address as already having > failed, but again that might not be too different from the hop-by- > hop extension headers.) > > Considering the extension headers helped me move one step closer > to the real world and also to envision at least one optimization. > To me it seems that the natural point to discover the multiple > paths from host A,B,C to host X,Y,X is at the host A,B,C, through > DNS lookup etc. It seems that shim6 is already capable of handling > that information so I think it makes sense for the end host to put > the X,Y,Z destination addresses in the packet. However I can see > two possibilities for where in the network the multiple source > addresses are placed in the packet. Members of the "I hate > middleboxes club" could have their hosts fill in the multiple > source addresses. However members of the "I only want my hosts to > have one IP address" club could design their network to have a > middle box at the interface to their ISPs and have the middelbox > add the multiple source addresses. The middle box would also have > to do the right magic to route an inbound packet with the multiple > destination addresses to the end host with the single IP address > but it could do so without having to maintain state for every > connection through the middlebox. (Middleboxes with flow-based > architecture that are required to maintain state are one of my main > objections to middleboxes.) Anyway the model of putting enough > information in the packet would seem to support at least two > options for the end network, allowing some choice for the end > network. And if implemented with extension headers it might be > partially backwards compatible with what is implemented today, it > wouldn't break anything, but hosts/networks that did not support > the new model wouldn't benefit from all of the redundancy of > multihoming. > > There has been talk on the list about not wanting to overload > identifiers but it has been helpful to me to think of unique > unchanging IDs for hosts in terms of the above model. If we add > another IP number to each host so we have host A,B,C,D and host > W,X,Y,Z but D and W have no associated ISPs things still work. It > is about the same case as if D and W did have an associated ISP > but the links to those ISPs were down. IPs D and W could even be > assigned based on GPS location or something similar if they where > still guaranteed to be unique. The identifiers are overloaded but > it might be workable as an interim solution, something similar to > shim6. > > Another possible optimization could be to strip off the multiple > source addresses at the interface between the customer and the ISP > and just leave the one that is associated with that ISP. But then > the receiving host wouldn't automatically know all of the return > addresses of the sending host. > > Sorry if this was obvious to everyone but I thought the idea of > putting all of the required info in the packets should at least be > floated and shot down and hopefully the shooting down and > discussion would be useful in the long run. To me considering the > extreme case was helpful in understanding the problem and in > classifying some of the proposed alternatives. > > > --- > Bruce Curtis bruce.curtis@ndsu.edu > Certified NetAnalyst II 701-231-8527 > North Dakota State University > --- Bruce Curtis bruce.curtis@ndsu.edu Certified NetAnalyst II 701-231-8527 North Dakota State University --Apple-Mail-16-376763667 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Dec 7, 2006, at = 6:15 AM, Bound, Jim wrote:

I like this thinking model.=A0= Why is this not a form or source address routing with a lot of other = addded value using = locators.=A0

=A0 The way I thought about = the model all of the routing was still based on the multiple destination = addresses and the source addresses would just be used for anti-spoof RPF = checking.=A0 But if the source info is in every packet lots of other = options I hadn't considered are possible with this model as = well.

I also believe that GPS information can = add great value to routing and doing some research on that concept for = ad hoc nets but have assumed no way could we ever get a standard done to = use it?
=A0
/jim


=A0 I know there have been = proposals about having the addresses or locators based on location or = GPS and it solved some routing problems but I think the ISPs had some = objections.

=A0= =A0When I was thinking through how things would work with this model I = was thinking of the GPS info as more of an ID than a locator.=A0 = =A0Sometimes when there is a problem host it would be nice to have it's = location info, but there are privacy issues and perhaps other downsides = as well.

=A0 = =A0But one way to use the same model but turn my thinking on it's head = is to consider the GPS info as the primary locator and the other = multiple locators as ISP specific locators.=A0 The question that comes = to mind is if that would lessen the ISP objections to the GPS based = address model.=A0 I'm not an ISP so the answer doesn't come naturally to = me, I'll have to think about if for a while.


=
From: Bruce Curtis [mailto:bruce.curtis@ndsu.edu] =
Sent: Monday, December 04, 2006 6:11 PM
To: architecture-discuss@ietf.or= g
Subject: [arch-d] It's about = Information


=A0 This may be obvious to = everyone since I haven't seen much discussion about this model but it = helped me understand the issues.

=A0 In the IPv4 = multihoming model the information about multiple paths from host A to = host Z is in the routing table of the core routers in the = Internet.
=A0 =A0=A0 =A0=A0 =A0=A0 =A0

=A0 =A0 =A0=A0 =A0ISP 1 =A0= ---------------- =A0 =A0=A0 =A0I=A0 = =A0---------------------------------=A0 =A0ISP 7
=A0 =A0 = =A0=A0 =A0=A0 =A0| =A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 = =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0n=A0 =A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 = =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 = =A0=A0 =A0=A0 =A0|
=A0=A0 =A0=A0 =A0=A0 =A0A=A0 =A0--=A0 ISP = 2 =A0-------=A0 =A0 =A0=A0 =A0t=A0 =A0------------------------=A0 = ISP 8=A0 --=A0 Z
=A0 =A0 =A0=A0 =A0=A0 =A0| =A0 =A0=A0 =A0=A0= =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0e=A0 = =A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 = =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0|
=A0 = =A0=A0 =A0=A0 =A0ISP 3 =A0 ---------------=A0 =A0 =A0=A0 =A0r=A0 = ---------------------------------=A0 =A0ISP 9
=A0 =A0 =A0=A0= =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0= =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0n
=A0 =A0 =A0=A0 =A0=A0 =A0=A0= =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0= =A0=A0 =A0=A0 =A0e
=A0 =A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0= =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 = =A0t

=A0 = If we change the model and take the information about multiple paths = out of the core routers and give each host a different IP number for = each of it's ISPs, then to preserve some of the properties of the old = model we still need=A0 to have the multiple path information available = to the network somehow.


=A0=A0=A0=A0 =A0=A0 =A0ISP = 1 =A0 ---------------- =A0 =A0=A0 =A0I=A0 = =A0---------------------------------=A0 =A0ISP 7
=A0 =A0 =A0=A0 =A0=A0= =A0| =A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0= =A0=A0 =A0=A0 =A0n=A0 =A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 = =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 = =A0|
=A0 =A0A,B,C=A0 =A0--=A0 ISP 2 =A0-------=A0 =A0 =A0=A0= =A0t=A0 =A0------------------------=A0 ISP 8=A0 --=A0 X,Y,Z
=
=A0 =A0 =A0=A0 =A0=A0 =A0| =A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 = =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0e=A0 =A0 =A0=A0 =A0=A0 = =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 = =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0|
=A0 =A0=A0 =A0=A0 =A0ISP 3 = =A0 ---------------=A0 =A0 =A0=A0 =A0r=A0 = ---------------------------------=A0 =A0ISP 9
=A0 =A0 =A0=A0= =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0= =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0n
=A0 =A0 =A0=A0 =A0=A0 =A0=A0= =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0= =A0=A0 =A0=A0 =A0e
=A0 =A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0= =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 = =A0t

=A0 = If we imagine a time in the future where every host has 100 Mbps = connection to the Internet like some homes in Japan today and we have = networks that support Jumbo frames it's easier to consider the = possibility that we put the required information in every packet from = host A,B,C to host X,Y,Z.=A0 That is, we put all of the destination = addresses X,Y,Z in the packet as well as the source addresses = A,B,C.=A0=A0
=A0 So basically we take the information about = multiple paths out of the routing tables where it doesn't scale and = put the multiple path info in each packet, which should scale right = along with the speed of the router.

=A0 If we put this = information in each packet then the new model has several properties = that the old model has.=A0 For example:

=A0 =A0=A0 =A0=A0 = =A0Traffic engineering can be done at any point in the path.
=
=A0 =A0=A0 =A0=A0 =A0
=A0=A0 =A0=A0 =A0=A0 =A0Anti-Spoof = checking can be done at the interface between the customer and = ISP.

=A0=A0= =A0=A0 =A0=A0 =A0If a link is down between any ISP and host X,Y,Z the = internet can reroute the packet
=A0=A0 =A0=A0 =A0=A0 =A0to = one of the other addresses for X,Y,Z.

=A0 The more I thought = about it the more sense this model made to me and it helped me = understand many of the other proposed alternatives as attempts to = optimize this model and remove some of the information from the = packet.

=A0= Also it made it clearer to me that the discussion about locator/ID = split has more to do with trying to preserve a single address = representation to current and future software and that it was the = multiple locators and not the locator/ID split that helps solve the = routing portion of the multihoming problem.

=A0 To further understand = the possibilities I realized that IPv6 did not provide the means to = include all of these addresses but IPv6 does have a method of being = extended to include such addresses, extension headers.=A0 Actually = putting the multiple destination addresses in extension headers might = not be too much different from the current hop-by-hop extension = headers.=A0 =A0(And there would have to be something in the standard = to avoid loops in the case of a link failure, something that marks an = address as already having failed, but again that might not be too = different from the hop-by-hop extension headers.)

=A0 Considering the = extension headers helped me move one step closer to the real world and = also to envision at least=A0 one optimization.=A0 To me it seems that = the natural point to discover the multiple paths from host A,B,C to = host X,Y,X is at the host A,B,C, through DNS lookup etc.=A0 It seems = that shim6 is already capable of handling that information so I think it = makes sense for the end host to put the X,Y,Z destination addresses in = the packet.=A0 However I can see two possibilities for where in the = network the multiple source addresses are placed in the packet.=A0 = Members of the "I hate middleboxes club" could have their hosts fill = in the multiple source addresses.=A0 However members of the "I only = want my hosts to have one IP address" club could design their network = to have a middle box at the interface to their ISPs and have the = middelbox add the multiple source addresses.=A0 The middle box would = also have to do the right magic to route an inbound packet with the = multiple destination addresses to the end host with the single IP = address but it could do so without having to maintain state for every = connection through the middlebox.=A0 (Middleboxes with flow-based = architecture that are required to maintain state are one of my main = objections to middleboxes.)=A0 Anyway the model of putting enough = information in the packet=A0 would seem to support at least two=A0 = options for the end network, allowing some choice for the end network. = =A0And if implemented with extension headers it might be partially = backwards compatible with what is implemented today, it wouldn't break = anything, but hosts/networks that did not support the new model = wouldn't benefit from all of the redundancy of multihoming.
=

=A0 There has = been talk on the list about not wanting to overload identifiers but it = has been helpful to me to think of unique unchanging IDs for hosts in = terms of the above model.=A0 If we add another IP number to each host = so we have host A,B,C,D and host W,X,Y,Z but D and W have no = associated ISPs things still work.=A0 It is about the same case as=A0 if = D and W did have an associated ISP but the links to those ISPs were = down.=A0 IPs D and W could even be assigned based on GPS location or = something similar if they where still guaranteed to be unique.=A0 The = identifiers are overloaded but it might be workable as an interim = solution, something similar to shim6.

=A0 Another possible = optimization could be to strip off the multiple source addresses at = the interface between the customer and the ISP and just leave the one = that is associated with that ISP.=A0 But then the receiving host = wouldn't automatically know all of the return addresses of the sending = host.
=A0=A0
=A0 Sorry if this was obvious to everyone = but I thought the idea of putting all of the required info in the = packets should at least be floated and shot down and hopefully the = shooting down and discussion would be useful in the long run.=A0 To me = considering the extreme case was helpful in understanding the problem = and in classifying some of the proposed alternatives.


---
Bruce Curtis =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 bruce.curtis@ndsu.edu
Certified NetAnalyst II=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 = 701-231-8527
North = Dakota State University =A0 =A0 =A0 = =A0



---

Bruce Curtis =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = bruce.curtis@ndsu.edu

=

Certified NetAnalyst II=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 701-231-8527

North Dakota State = University =A0 =A0 =A0 =A0

=

= --Apple-Mail-16-376763667-- --===============0406926338== 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 --===============0406926338==-- From architecture-discuss-bounces@ietf.org Thu Dec 07 13:37:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsO7f-0000p3-EB; Thu, 07 Dec 2006 13:37:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsNrD-0002BX-PX for architecture-discuss@ietf.org; Thu, 07 Dec 2006 13:20:31 -0500 Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsNrC-00053g-0o for architecture-discuss@ietf.org; Thu, 07 Dec 2006 13:20:31 -0500 Received: from [192.168.0.101] (c-24-6-155-154.hsd1.ca.comcast.net[24.6.155.154]) by comcast.net (sccrmhc11) with SMTP id <20061207182024011003ev7ie>; Thu, 7 Dec 2006 18:20:29 +0000 In-Reply-To: References: <816DD9299957E547B5D758D7F977D6DC010B6078@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <904691F9-4631-499F-816E-64A720E55822@comcast.net> From: Tony Li Subject: Re: [arch-d] It's about Information Date: Thu, 7 Dec 2006 10:20:35 -0800 To: Bruce Curtis X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 X-Mailman-Approved-At: Thu, 07 Dec 2006 13:37:29 -0500 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="===============0273646967==" Errors-To: architecture-discuss-bounces@ietf.org --===============0273646967== Content-Type: multipart/alternative; boundary=Apple-Mail-1-377358001 --Apple-Mail-1-377358001 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Dec 7, 2006, at 10:10 AM, Bruce Curtis wrote: > > On Dec 7, 2006, at 6:15 AM, Bound, Jim wrote: > >> I like this thinking model. Why is this not a form or source >> address routing with a lot of other addded value using locators. > > The way I thought about the model all of the routing was still > based on the multiple destination addresses and the source > addresses would just be used for anti-spoof RPF checking. But if > the source info is in every packet lots of other options I hadn't > considered are possible with this model as well. I think that there's an important distinction here: it's vital to the upper layers that packets contain a source identifier. However, the inclusion of a source locator is not clearly necessary. Tony --Apple-Mail-1-377358001 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Dec 7, 2006, at = 10:10 AM, Bruce Curtis wrote:

On Dec 7, 2006, at 6:15 AM, Bound, Jim = wrote:

I like this thinking model.=A0 Why is this not a form or = source address routing with a lot of other addded value using = locators.=A0

=A0 The way I thought about = the model all of the routing was still based on the multiple destination = addresses and the source addresses would just be used for anti-spoof RPF = checking.=A0 But if the source info is in every packet lots of other = options I hadn't considered are possible with this model as = well.


I think that = there's an important distinction here: it's vital to the upper layers = that packets contain a source identifier.=A0 However, the inclusion of a = source locator is not clearly necessary.

Tony


= --Apple-Mail-1-377358001-- --===============0273646967== 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 --===============0273646967==-- From architecture-discuss-bounces@ietf.org Thu Dec 07 14:03:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsOVJ-0005dE-Mq; Thu, 07 Dec 2006 14:01:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsOVI-0005d1-Vn for architecture-discuss@ietf.org; Thu, 07 Dec 2006 14:01:56 -0500 Received: from smtp1.nodak.edu ([134.129.111.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsOVG-0003jV-AM for architecture-discuss@ietf.org; Thu, 07 Dec 2006 14:01:56 -0500 Received: from [134.129.95.120] (netmender.cc.ndsu.NoDak.edu [134.129.95.120]) (authenticated bits=0) by smtp1.NoDak.edu (8.13.1/8.13.1) with ESMTP id kB7J1omB005780 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 7 Dec 2006 13:01:50 -0600 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <904691F9-4631-499F-816E-64A720E55822@comcast.net> References: <816DD9299957E547B5D758D7F977D6DC010B6078@tayexc14.americas.cpqcorp.net> <904691F9-4631-499F-816E-64A720E55822@comcast.net> Message-Id: From: Bruce Curtis Subject: Re: [arch-d] It's about Information Date: Thu, 7 Dec 2006 13:01:49 -0600 To: architecture-discuss@ietf.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f 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="===============0836750360==" Errors-To: architecture-discuss-bounces@ietf.org --===============0836750360== Content-Type: multipart/alternative; boundary=Apple-Mail-17-379832264 --Apple-Mail-17-379832264 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Dec 7, 2006, at 12:20 PM, Tony Li wrote: > > On Dec 7, 2006, at 10:10 AM, Bruce Curtis wrote: >> >> On Dec 7, 2006, at 6:15 AM, Bound, Jim wrote: >> >>> I like this thinking model. Why is this not a form or source >>> address routing with a lot of other addded value using locators. >> >> The way I thought about the model all of the routing was still >> based on the multiple destination addresses and the source >> addresses would just be used for anti-spoof RPF checking. But if >> the source info is in every packet lots of other options I hadn't >> considered are possible with this model as well. > > > I think that there's an important distinction here: it's vital to > the upper layers that packets contain a source identifier. > However, the inclusion of a source locator is not clearly necessary. > > Tony It's vital to the stacks on the end hosts that the packets contain a source identifier. If we imagine an example that is sort of the opposite extreme of the model I was thinking of I can see your point that inclusion of the source locator in the packet is not necessary at all for the network to deliver the packet. However having the source locator in the packet has been handy for anti-spoof RPF checks and there are lots of standards that depend on having the source locator in the packet. PMTU Discovery and all of the ICMP error reports depend on having the source locator in the packet so that they know where to send the error info to. If it were possible for the router to look up the locator info based on the identifier then the ICMP error reports wouldn't be an issue, but if the lookup were expensive it could lead to possible DoS attacks. Multicast also depends heavily on the source locator for RPF checking, but multicast is already maintaining state so I guess if the source locator info is in some early packets and the router caches the source identifier to be associated with the state created then it might not be necessary for the later packets to contain a source locator. But that could potentially lead to some scaling issues for the multicast RPF check if the check was done against a cache of source identifiers rather than comparing the source locator to the routing table. --- Bruce Curtis bruce.curtis@ndsu.edu Certified NetAnalyst II 701-231-8527 North Dakota State University --Apple-Mail-17-379832264 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Dec 7, 2006, at = 12:20 PM, Tony Li wrote:


On Dec 7, 2006, at 10:10 AM, Bruce Curtis = wrote:

On Dec 7, 2006, at = 6:15 AM, Bound, Jim wrote:

I like this thinking model.=A0= Why is this not a form or source address routing with a lot of other = addded value using = locators.=A0

=A0 The way I thought about = the model all of the routing was still based on the multiple destination = addresses and the source addresses would just be used for anti-spoof RPF = checking.=A0 But if the source info is in every packet lots of other = options I hadn't considered are possible with this model as = well.


I think that = there's an important distinction here: it's vital to the upper layers = that packets contain a source identifier.=A0 However, the inclusion of a = source locator is not clearly necessary.

Tony

=A0 It's vital to the stacks on the end hosts that the packets = contain a source identifier.=A0 If we imagine an example that is sort of = the opposite extreme of the model I was thinking of I can see your point = that inclusion of the source locator in the packet is not necessary at = all for the network to deliver the packet.=A0 However having the source = locator in the packet has been handy for anti-spoof RPF checks and there = are lots of standards that depend on having the source locator in the = packet.=A0 PMTU Discovery and all of the ICMP error reports depend on = having the source locator in the packet so that they know where to send = the error info to.=A0 If it were possible for the router to look up the = locator info based on the identifier then the ICMP error reports = wouldn't be an issue, but if the lookup were expensive it could lead to = possible DoS attacks.=A0 Multicast also depends heavily on the source = locator for RPF checking, but multicast is already maintaining state so = I guess if the source locator info is in some early packets and the = router caches the source identifier to be associated with the state = created then it might not be necessary for the later packets to contain = a source locator.=A0 But that could potentially lead to some scaling = issues for the multicast RPF check if the check was done against a cache = of source identifiers rather than comparing the source locator to the = routing table.



---

Bruce Curtis =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = bruce.curtis@ndsu.edu

=

Certified NetAnalyst II=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 701-231-8527

North Dakota State = University =A0 =A0 =A0 =A0

=

= --Apple-Mail-17-379832264-- --===============0836750360== 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 --===============0836750360==-- From architecture-discuss-bounces@ietf.org Thu Dec 07 14:06:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsOZn-0006lA-GY; Thu, 07 Dec 2006 14:06:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsOZm-0006ip-1v; Thu, 07 Dec 2006 14:06:34 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsOZi-0004Ly-Lw; Thu, 07 Dec 2006 14:06:34 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id kB7J6UrT014067; Thu, 7 Dec 2006 11:06:30 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id kB7J6Obu014066; Thu, 7 Dec 2006 11:06:24 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 7 Dec 2006 11:06:24 -0800 From: David Meyer To: architecture-discuss@ietf.org, routingworkshop@lists.i1b.org, ram@iab.org, v6ops@ops.ietf.org Message-ID: <20061207190624.GA13988@1-4-5.net> Mime-Version: 1.0 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: 97adf591118a232206bdb5a27b217034 Cc: iab@ietf.org, iesg@ietf.org Subject: [arch-d] mailing lists and follow-ons to the IAB Routing & Addressing workshop 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="===============1747044905==" Errors-To: architecture-discuss-bounces@ietf.org --===============1747044905== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="a8Wt8u1KmwUX3Y2C" Content-Disposition: inline --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Folks, There's been a lot of discussion of what the follow-on's to the workshop might be on various lists. What I'm hoping we can do is consolidate that discussion on ram@iab.org. The I* will be using ram@iab.org for discussion going forward, so please subscribe if you are interested.=20 =09 thnx, --dmm --a8Wt8u1KmwUX3Y2C Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFeGYwORgD1qCZ2KcRAoBTAKCRbBrD57uKgHbXGVdJ4eDoVlmrCQCghm45 LARkLGQgj1378XWa9l8QFCo= =SI+m -----END PGP SIGNATURE----- --a8Wt8u1KmwUX3Y2C-- --===============1747044905== 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 --===============1747044905==-- From architecture-discuss-bounces@ietf.org Thu Dec 07 14:25:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsOqr-0006o2-36; Thu, 07 Dec 2006 14:24:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsOqp-0006np-MH for architecture-discuss@ietf.org; Thu, 07 Dec 2006 14:24:11 -0500 Received: from iceblock01.troposnetworks.com ([12.108.168.187] helo=iceblock01.tropos.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GsOqo-0006NK-3G for architecture-discuss@ietf.org; Thu, 07 Dec 2006 14:24:11 -0500 Received: (qmail 19075 invoked from network); 7 Dec 2006 19:24:01 -0000 Received: from ca-bay-exch-01.tropos.com (192.168.1.49) by iceblock01.tropos.com with SMTP; 7 Dec 2006 19:24:01 -0000 Received: from LIPC ([192.168.1.75]) by ca-bay-exch-01.tropos.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Dec 2006 11:24:00 -0800 From: "Tony Li" To: "'Bruce Curtis'" , Subject: RE: [arch-d] It's about Information Date: Thu, 7 Dec 2006 11:23:57 -0800 Message-ID: <001301c71a35$3df1e3c0$4b01a8c0@tropos.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 thread-index: AccaMkYXraNTZQENR4OVSXH+5tbEjwAAXbxA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: X-OriginalArrivalTime: 07 Dec 2006 19:24:00.0851 (UTC) FILETIME=[3FC06230:01C71A35] X-Antivirus: Scanned by Tropos Antivirus 1.0.4 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tony.li@tony.li 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="===============1458146220==" Errors-To: architecture-discuss-bounces@ietf.org This is a multi-part message in MIME format. --===============1458146220== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01C719F2.2FCEA3C0" This is a multi-part message in MIME format. ------=_NextPart_000_0014_01C719F2.2FCEA3C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: Bruce Curtis [mailto:bruce.curtis@ndsu.edu] If we imagine an example that is sort of the opposite extreme of the model I was thinking of I can see your point that inclusion of the source locator in the packet is not necessary at all for the network to deliver the packet. However having the source locator in the packet has been handy for anti-spoof RPF checks and there are lots of standards that depend on having the source locator in the packet. I think that's there's a huge separation between "handy" and "required". As we're positing new architecture, I think that we should be very clear in separating the two. I agree that having a source locator has been handy for RPF checks, but is that the only way? If the identifier space is structured, then filtering on the identifier might be tractable. And again, as we're positing new architecture anyway, compliance to existing standards doesn't seem like it is strictly "required". In fact, if it is, it would seem challenging to make any forward progress. PMTU Discovery and all of the ICMP error reports depend on having the source locator in the packet so that they know where to send the error info to. If it were possible for the router to look up the locator info based on the identifier then the ICMP error reports wouldn't be an issue, but if the lookup were expensive it could lead to possible DoS attacks. Agreed. However, ICMP error reports are already rate limited. Whatever mechanism there is for identifier to locator mapping (if any) needs to be robust against attacks regardless of this possible abuse vector. Multicast also depends heavily on the source locator for RPF checking, but multicast is already maintaining state so guess if the source locator info is in some early packets and the router caches the source identifier to be associated with the state created then it might not be necessary for the later packets to contain a source locator. With multicast, as always, things are reversed. Then the question becomes whether the destination locator provides any value. Tony ------=_NextPart_000_0014_01C719F2.2FCEA3C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 

From: Bruce Curtis=20 [mailto:bruce.curtis@ndsu.edu]  
 
 If we = imagine an=20 example that is sort of the opposite extreme of the model I was = thinking of I=20 can see your point that inclusion of the source locator in the packet = is not=20 necessary at all for the network to deliver the packet. However having = the=20 source locator in the packet has been handy for anti-spoof RPF checks = and=20 there are lots of standards that depend on having the source locator = in the=20 packet. 
 
I = think that's=20 there's a huge separation between "handy" and "required".  As we're = positing new architecture, I think that we should be very clear in = separating=20 the two.  I agree that having a source locator has been handy for = RPF=20 checks, but is that the only way?  If the identifier space is = structured,=20 then filtering on the identifier might be tractable.  And again, as = we're=20 positing new architecture anyway, compliance to existing standards = doesn't seem=20 like it is strictly "required".  In fact, if it is, it would seem=20 challenging to make any forward progress.
 
  PMTU Discovery and all of the = ICMP=20 error reports depend on having the source locator in the packet so = that they=20 know where to send the error info to. If it were possible for the = router to=20 look up the locator info based on the identifier then the ICMP error = reports=20 wouldn't be an issue, but if the lookup were expensive it could lead = to=20 possible DoS attacks.  
 
Agreed. =20 However, ICMP error reports are already rate limited.  Whatever = mechanism=20 there is for identifier to locator mapping (if any) needs to be robust = against=20 attacks regardless of this possible abuse vector.
 
 Multicast also depends heavily = on the=20 source locator for RPF checking, but multicast is already maintaining = state=20 so  guess if the = source=20 locator info is in some early packets and the router caches the source = identifier to be associated with the state created then it might not = be=20 necessary for the later packets to contain a source = locator.  
 
With multicast,=20 as always, things are reversed.  Then the question becomes whether = the=20 destination locator provides any value.
 
Tony
 
------=_NextPart_000_0014_01C719F2.2FCEA3C0-- --===============1458146220== 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 --===============1458146220==-- From architecture-discuss-bounces@ietf.org Thu Dec 07 14:54:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsPJ4-000357-R6; Thu, 07 Dec 2006 14:53:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsPJ2-00034z-Tf for architecture-discuss@ietf.org; Thu, 07 Dec 2006 14:53:20 -0500 Received: from mx2.grc.nasa.gov ([128.156.11.69]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GsPJ1-0002kP-C2 for architecture-discuss@ietf.org; Thu, 07 Dec 2006 14:53:20 -0500 Received: from lombok-fi.grc.nasa.gov (seraph.grc.nasa.gov [128.156.10.10]) by mx2.grc.nasa.gov (Postfix) with ESMTP id 372EAC2DE for ; Thu, 7 Dec 2006 14:53:16 -0500 (EST) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id kB7JrFqa020545; Thu, 7 Dec 2006 14:53:15 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id kB7JrFGa020096; Thu, 7 Dec 2006 14:53:15 -0500 (EST) Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.nasa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id uuoZXXaDhkQQ; Thu, 7 Dec 2006 14:53:15 -0500 (EST) Received: from drpepper.grc.nasa.gov (gr2134391.grc.nasa.gov [139.88.44.123])by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.7/8.13.7) with ESMTP id kB7JrBHH020066;Thu, 7 Dec 2006 14:53:11 -0500 (EST) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501)id 9F0B44FDFB; Thu, 7 Dec 2006 14:51:44 -0500 (EST) Date: Thu, 7 Dec 2006 14:51:44 -0500 From: Wesley Eddy To: Bruce Curtis Subject: Re: [arch-d] It's about Information Message-ID: <20061207195144.GA29183@grc.nasa.gov> References: <904691F9-4631-499F-816E-64A720E55822@comcast.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1i X-imss-version: 2.045 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:2 M:2 S:2 R:2 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: weddy@grc.nasa.gov List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Thu, Dec 07, 2006 at 01:01:49PM -0600, Bruce Curtis wrote: > > It's vital to the stacks on the end hosts that the packets contain > a source identifier. If we imagine an example that is sort of the > opposite extreme of the model I was thinking of I can see your point > that inclusion of the source locator in the packet is not necessary > at all for the network to deliver the packet. However having the > source locator in the packet has been handy for anti-spoof RPF checks > and there are lots of standards that depend on having the source > locator in the packet. PMTU Discovery and all of the ICMP error > reports depend on having the source locator in the packet so that > they know where to send the error info to. If it were possible for > the router to look up the locator info based on the identifier then > the ICMP error reports wouldn't be an issue, but if the lookup were > expensive it could lead to possible DoS attacks. Multicast also > depends heavily on the source locator for RPF checking, but multicast > is already maintaining state so I guess if the source locator info is > in some early packets and the router caches the source identifier to > be associated with the state created then it might not be necessary > for the later packets to contain a source locator. But that could > potentially lead to some scaling issues for the multicast RPF check > if the check was done against a cache of source identifiers rather > than comparing the source locator to the routing table. > A separate topic for this list might be whether we can simply deprecate non-local ICMP error reporting. The local functions like ND, MLD, etc. are useful, but for non-local signaling ICMP is fairly poor. PLPMTUD is a significant step in this direction. We should ask what part ICMP plays in the architecture in reality, and if that differs from the part it was originally intended to play or the part we think it should play. The recent discussions in TCPM in San Diego and on the TCPM mailing list may be interesting to people. -- Wesley M. Eddy Verizon Federal Network Systems _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Dec 07 15:11:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsPZv-0000fP-0q; Thu, 07 Dec 2006 15:10:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsPZt-0000cZ-Pi; Thu, 07 Dec 2006 15:10:45 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsPYs-0004fE-7i; Thu, 07 Dec 2006 15:09:43 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id A0BDF872C0; Thu, 7 Dec 2006 15:09:41 -0500 (EST) To: architecture-discuss@ietf.org, ram@iab.org, routingworkshop@lists.i1b.org, v6ops@ops.ietf.org Subject: Re: [arch-d] mailing lists and follow-ons to the IAB Routing & Addressing workshop Message-Id: <20061207200941.A0BDF872C0@mercury.lcs.mit.edu> Date: Thu, 7 Dec 2006 15:09:41 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: iab@ietf.org, iesg@ietf.org, jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: David Meyer > discussion of what the follow-on's to the workshop might be on various > lists. What I'm hoping we can do is consolidate that discussion on > ram@iab.org. I would take a slightly different view, and think there is (non-overlapping) role for both (and I hope the various I* bodies won't take offense at me for differing a bit with this plan; I really do have everyone's best interests at heart here.) First, this is a big problem, and there are a number of different technical areas; with a single forum, it might get kind of Babel-like. Second, and more important I think, I find that in any wide-ranging discussion like this, the routing stuff (which is usually the hardest problem) gets the short end of the stick. (I have my opinions on why that happens, but I'll leave them be for now.) And, I hope I don't need to point out, it was coming problems with the routing which have led to this. IMNSHO, it's really unacceptable to work on this problem and not give a key role to consideration of how the routing is going to work. And to make sure the routing is going to work, we have to dive into the muck and tackle the routing technical issues in some detail, to make sure it all really works. So we have to drive pretty quickly to considering the technical details of how the routing is going to work, I think. And that's something the people who seem to have energy available to discuss things have been fairly loathe to do, despite some not-so-subtle prods from me. So I think keeping the RAM list focused on just the routing stuff is really pretty critical; it's clear that that's a really substantial discussion. Discussion of other related topics there (e.g. separation of location and identity) would just distract from that, and that's where A-D list would be useful. I feel that discussion of such issues as end-end naming, whether we have to use the "jack-up" model (in which end-hosts remain totally unmodified), etc, etc, really ought to be kept on A-D, to keep RAM clear for these routing issues. To keep this from getting too long, I'll send out a separate message in a couple of hours (just on RAM) giving a little more detail on the points I think RAM needs to work on, and how I think it can best make progress on them. Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Dec 07 15:14:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsPdD-0003ve-Ll; Thu, 07 Dec 2006 15:14:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsPdC-0003so-8U for architecture-discuss@ietf.org; Thu, 07 Dec 2006 15:14:10 -0500 Received: from smtp1.nodak.edu ([134.129.111.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsPdA-0005KI-N3 for architecture-discuss@ietf.org; Thu, 07 Dec 2006 15:14:10 -0500 Received: from [134.129.95.120] (netmender.cc.ndsu.NoDak.edu [134.129.95.120]) (authenticated bits=0) by smtp1.NoDak.edu (8.13.1/8.13.1) with ESMTP id kB7KE8e0018391 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 7 Dec 2006 14:14:08 -0600 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <001301c71a35$3df1e3c0$4b01a8c0@tropos.com> References: <001301c71a35$3df1e3c0$4b01a8c0@tropos.com> Message-Id: From: Bruce Curtis Subject: Re: [arch-d] It's about Information Date: Thu, 7 Dec 2006 14:14:07 -0600 To: architecture-discuss@ietf.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 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="===============1701615944==" Errors-To: architecture-discuss-bounces@ietf.org --===============1701615944== Content-Type: multipart/alternative; boundary=Apple-Mail-21-384170069 --Apple-Mail-21-384170069 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Dec 7, 2006, at 1:23 PM, Tony Li wrote: > > > From: Bruce Curtis [mailto:bruce.curtis@ndsu.edu] > > If we imagine an example that is sort of the opposite extreme of > the model I was thinking of I can see your point that inclusion of > the source locator in the packet is not necessary at all for the > network to deliver the packet. However having the source locator in > the packet has been handy for anti-spoof RPF checks and there are > lots of standards that depend on having the source locator in the > packet. > > I think that's there's a huge separation between "handy" and > "required". As we're positing new architecture, I think that we > should be very clear in separating the two. Yes. I'm guilty at times of thinking too much in terms of the old architecture, the discussion on this list has been very interesting and has helped my thoughts to be less bound by the old architecture. > I agree that having a source locator has been handy for RPF checks, > but is that the only way? If the identifier space is structured, > then filtering on the identifier might be tractable. Someone on the list mentioned RPF checks by AS as a possibility. I can see that if the identifier were required to contain the AS or something similar that might work. But on my campus it has been very handy to just enable the RPF checking on every subnet. That contains any spoofing as close to the source as possible. I can see where it is likely possible to include enough structure in the identifier to identify the ISP customer but it might be more challenging to have it include info about each of my subnets, and if we do then isn't the identifier becoming closer to a locator again? > And again, as we're positing new architecture anyway, compliance to > existing standards doesn't seem like it is strictly "required". In > fact, if it is, it would seem challenging to make any forward > progress. Right, protocols, or even "existing code" would probably have been a better choice of words but in either case your point that changes are required is true. > Multicast also depends heavily on the source locator for RPF > checking, but multicast is already maintaining state so guess if > the source locator info is in some early packets and the router > caches the source identifier to be associated with the state > created then it might not be necessary for the later packets to > contain a source locator. > > With multicast, as always, things are reversed. Then the question > becomes whether the destination locator provides any value. > > Tony Hmm, good point. As long as there is a destination identifier and the packet is somehow marked as multicast I can't think of a requirement for the destination locator. Perhaps a destination locator or something similar might be handy for scope issues? But then again that might be better handled by structure in the destination identifier? --- Bruce Curtis bruce.curtis@ndsu.edu Certified NetAnalyst II 701-231-8527 North Dakota State University --Apple-Mail-21-384170069 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Dec 7, 2006, at = 1:23 PM, Tony Li wrote:

=A0

=
From: Bruce = Curtis [mailto:bruce.curtis@ndsu.edu]=A0= =A0
=A0
 If we imagine = an example that is sort of the opposite extreme of the model I was = thinking of I can see your point that inclusion of the source locator = in the packet is not necessary at all for the network to deliver the = packet. However having the source locator in the packet has been handy = for anti-spoof RPF checks and there are lots of standards that depend = on having the source locator in the packet.=A0
=A0
I think that's there's a = huge separation between "handy" and "required".=A0 As we're positing new = architecture, I think that we should be very clear in separating the = two.=A0

=A0 Yes.=A0 I'm guilty at times = of thinking too much in terms of the old architecture, the discussion on = this list has been very interesting and has helped my thoughts to be = less bound by the old architecture.

I agree that having a source locator has = been handy for RPF checks, but is that the only way?=A0 If the = identifier space is structured, then filtering on the identifier might = be tractable.=A0

=A0 Someone on the list = mentioned RPF checks by AS as a possibility.=A0 I can see that if the = identifier were required to contain the AS or something similar that = might work.=A0 But on my campus it has been very handy to just enable = the RPF checking on every subnet. That contains any spoofing as close to = the source as possible.=A0 I can see where it is likely possible to = include enough structure in the identifier to identify the ISP customer = but it might be more challenging to have it include info about each of = my subnets, and if we do then isn't the identifier becoming closer to a = locator again?

And again, as we're positing new architecture anyway, = compliance to existing standards doesn't seem like it is strictly = "required".=A0 In fact, if it is, it would seem challenging to make any = forward progress.

=A0 Right, protocols, or = even "existing code" would probably have been a better choice of words = but in either case your point that changes are required is = true.

=A0Multicast also depends heavily on = the source locator for RPF checking, but multicast is already = maintaining state so=A0=A0gues= s if the source locator info is in some early packets and the router = caches the source identifier to be associated with the state created = then it might not be necessary for the later packets to contain a = source locator.=A0=A0
=A0
With multicast, as always, things are reversed.=A0 Then the = question becomes whether the destination locator provides any = value.
=A0
Tony

=A0 Hmm, = good point.=A0 As long as there is a destination identifier and the = packet is somehow marked as multicast I can't think of a requirement for = the destination locator.=A0 Perhaps a destination locator or something = similar might be handy for scope issues? =A0 =A0But then again that = might be better handled by structure in the destination = identifier?


---

Bruce Curtis =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 bruce.curtis@ndsu.edu

=

Certified NetAnalyst II=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 701-231-8527

North Dakota State = University =A0 =A0 =A0 =A0

=

= --Apple-Mail-21-384170069-- --===============1701615944== 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 --===============1701615944==-- From architecture-discuss-bounces@ietf.org Thu Dec 07 15:53:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsQEh-00053w-IC; Thu, 07 Dec 2006 15:52:55 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsQEg-00053T-9a for architecture-discuss@ietf.org; Thu, 07 Dec 2006 15:52:54 -0500 Received: from rwcrmhc11.comcast.net ([204.127.192.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GsQEe-0002mH-Le for architecture-discuss@ietf.org; Thu, 07 Dec 2006 15:52:54 -0500 Received: from [10.0.1.15] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (rwcrmhc11) with ESMTP id <20061207205243m11005q9noe>; Thu, 7 Dec 2006 20:52:49 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <001301c71a35$3df1e3c0$4b01a8c0@tropos.com> References: <001301c71a35$3df1e3c0$4b01a8c0@tropos.com> Date: Thu, 7 Dec 2006 15:48:48 -0500 To: tony.li@tony.li, "'Bruce Curtis'" , From: John Day Subject: RE: [arch-d] It's about Information X-Spam-Score: 0.1 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 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: , Content-Type: multipart/mixed; boundary="===============0591609421==" Errors-To: architecture-discuss-bounces@ietf.org --===============0591609421== Content-Type: multipart/alternative; boundary="============_-1046597728==_ma============" --============_-1046597728==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" In a complete architecture, addresses are internal to what we call the network layer. No one else needs to be aware of them. John At 11:23 -0800 2006/12/07, Tony Li wrote: > > >From: Bruce Curtis [mailto:bruce.curtis@ndsu.edu] > >If we imagine an example that is sort of the opposite extreme of the >model I was thinking of I can see your point that inclusion of the >source locator in the packet is not necessary at all for the network >to deliver the packet. However having the source locator in the >packet has been handy for anti-spoof RPF checks and there are lots >of standards that depend on having the source locator in the packet. > > >I think that's there's a huge separation between "handy" and >"required". As we're positing new architecture, I think that we >should be very clear in separating the two. I agree that having a >source locator has been handy for RPF checks, but is that the only >way? If the identifier space is structured, then filtering on the >identifier might be tractable. And again, as we're positing new >architecture anyway, compliance to existing standards doesn't seem >like it is strictly "required". In fact, if it is, it would seem >challenging to make any forward progress. > > > PMTU Discovery and all of the ICMP error reports depend on having >the source locator in the packet so that they know where to send the >error info to. If it were possible for the router to look up the >locator info based on the identifier then the ICMP error reports >wouldn't be an issue, but if the lookup were expensive it could lead >to possible DoS attacks. > > >Agreed. However, ICMP error reports are already rate limited. >Whatever mechanism there is for identifier to locator mapping (if >any) needs to be robust against attacks regardless of this possible >abuse vector. > > > Multicast also depends heavily on the source locator for RPF >checking, but multicast is already maintaining state so guess if >the source locator info is in some early packets and the router >caches the source identifier to be associated with the state created >then it might not be necessary for the later packets to contain a >source locator. > > >With multicast, as always, things are reversed. Then the question >becomes whether the destination locator provides any value. > >Tony > > >_______________________________________________ >Architecture-discuss mailing list >Architecture-discuss@ietf.org >https://www1.ietf.org/mailman/listinfo/architecture-discuss --============_-1046597728==_ma============ Content-Type: text/html; charset="us-ascii" RE: [arch-d] It's about Information
In a complete architecture, addresses are internal to what we call the network layer.  No one else needs to be aware of them.

John

At 11:23 -0800 2006/12/07, Tony Li wrote:
 

From: Bruce Curtis [mailto:bruce.curtis@ndsu.edu]  
 
If we imagine an example that is sort of the opposite extreme of the model I was thinking of I can see your point that inclusion of the source locator in the packet is not necessary at all for the network to deliver the packet. However having the source locator in the packet has been handy for anti-spoof RPF checks and there are lots of standards that depend on having the source locator in the packet. 
 
I think that's there's a huge separation between "handy" and "required".  As we're positing new architecture, I think that we should be very clear in separating the two.  I agree that having a source locator has been handy for RPF checks, but is that the only way?  If the identifier space is structured, then filtering on the identifier might be tractable.  And again, as we're positing new architecture anyway, compliance to existing standards doesn't seem like it is strictly "required".  In fact, if it is, it would seem challenging to make any forward progress.
 
  PMTU Discovery and all of the ICMP error reports depend on having the source locator in the packet so that they know where to send the error info to. If it were possible for the router to look up the locator info based on the identifier then the ICMP error reports wouldn't be an issue, but if the lookup were expensive it could lead to possible DoS attacks.  
 
Agreed.  However, ICMP error reports are already rate limited.  Whatever mechanism there is for identifier to locator mapping (if any) needs to be robust against attacks regardless of this possible abuse vector.
 
 Multicast also depends heavily on the source locator for RPF checking, but multicast is already maintaining state so  guess if the source locator info is in some early packets and the router caches the source identifier to be associated with the state created then it might not be necessary for the later packets to contain a source locator.  
 
With multicast, as always, things are reversed.  Then the question becomes whether the destination locator provides any value.
 
Tony
 

_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@ietf.org
https://www1.ietf.org/mailman/listinfo/architecture-discuss

--============_-1046597728==_ma============-- --===============0591609421== 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 --===============0591609421==-- From architecture-discuss-bounces@ietf.org Thu Dec 07 16:06:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsQRE-0004F3-4G; Thu, 07 Dec 2006 16:05:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsQRC-0004EH-4h; Thu, 07 Dec 2006 16:05:50 -0500 Received: from imo-m23.mx.aol.com ([64.12.137.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsQRA-0005Hm-Se; Thu, 07 Dec 2006 16:05:50 -0500 Received: from HeinerHummel@aol.com by imo-m23.mx.aol.com (mail_out_v38_r7.6.) id 9.c79.743b8b4 (41809); Thu, 7 Dec 2006 16:05:38 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Thu, 7 Dec 2006 16:05:35 EST Subject: Re: [RAM] Re: [arch-d] mailing lists and follow-ons to the IAB Routing & Addr... To: jnc@mercury.lcs.mit.edu, architecture-discuss@ietf.org, ram@iab.org, routingworkshop@lists.i1b.org, v6ops@ops.ietf.org MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5009 X-Spam-Flag: NO X-Spam-Score: 0.3 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: iab@ietf.org, iesg@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="===============0774490814==" Errors-To: architecture-discuss-bounces@ietf.org --===============0774490814== Content-Type: multipart/alternative; boundary="-----------------------------1165525535" -------------------------------1165525535 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Noel wrote: IMNSHO, it's really unacceptable to work on this problem and not give a key role to consideration of how the routing is going to work. And to make sure the routing is going to work, we have to dive into the muck and tackle the routing technical issues in some detail, to make sure it all really works. So we have to drive pretty quickly to considering the technical details of how the routing is going to work, I think. And that's something the people who seem to have energy available to discuss things have been fairly loathe to do, despite some not-so-subtle prods from me. I totally agree. How can addressing be discussed without envisioning a routing scheme that fits for the future ?!! Maybe in preparation for such a discussion we should discuss how bad current IETF-routing is. I am sure other technologies (robotics, navigation systems,..) have surpassed internet routing by far. The IETF is still dependent on such a primitive TTL-mechanism which hasn't been improved substantially by getting a new name in IPv6. With RPF-checks you can not defeat the DoS attacks, but you can prevent multipath routing and realtime traffic control. With BGP...(stop, I might be told without BGP this email wouldn't make its way out). Heiner -------------------------------1165525535 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Noel wrote:
IMNSHO, it's really unacceptable to work on this pro= blem=20 and not give a key
role to consideration of how the routing is going to w= ork.=20 And to make sure
the routing is going to work, we have to dive into the m= uck=20 and tackle the
routing technical issues in some detail, to make sure it a= ll=20 really works. So
we have to drive pretty quickly to considering the techn= ical=20 details of how
the routing is going to work, I think. And that's somethin= g=20 the people who
seem to have energy available to discuss things have been=20 fairly loathe to do,
despite some not-so-subtle prods from me.
 
I totally agree. How can addressing be discussed without envisioni= ng=20 a  routing scheme that fits for the future ?!! 
Maybe in preparation for such a  discussion we should discuss= how=20 bad current IETF-routing is. I am sure other technologies (robotics, navigat= ion=20 systems,..) have surpassed internet routing by far. The IETF is still depend= ent=20 on such a primitive TTL-mechanism which hasn't been improved substantially&n= bsp;=20 by getting a new name in IPv6.
With RPF-checks you can not defeat the DoS attacks, but you=20 can prevent multipath
routing and realtime traffic control.  With BGP...(stop, I might b= e=20 told without BGP this email wouldn't make its way out). 
 
Heiner
 
 
 
 
 
 
 
 

 
 -------------------------------1165525535-- --===============0774490814== 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 --===============0774490814==-- From architecture-discuss-bounces@ietf.org Thu Dec 07 16:14:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsQYH-0007SD-NR; Thu, 07 Dec 2006 16:13:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsQYG-0007Rz-Ty; Thu, 07 Dec 2006 16:13:08 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsQYF-0006Mr-GT; Thu, 07 Dec 2006 16:13:08 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id kB7LD6BM018392; Thu, 7 Dec 2006 13:13:06 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id kB7LD6V2018391; Thu, 7 Dec 2006 13:13:06 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 7 Dec 2006 13:13:06 -0800 From: David Meyer To: Noel Chiappa Subject: Re: [arch-d] mailing lists and follow-ons to the IAB Routing & Addressing workshop Message-ID: <20061207211306.GA18311@1-4-5.net> References: <20061207200941.A0BDF872C0@mercury.lcs.mit.edu> Mime-Version: 1.0 In-Reply-To: <20061207200941.A0BDF872C0@mercury.lcs.mit.edu> 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: f66b12316365a3fe519e75911daf28a8 Cc: iab@ietf.org, architecture-discuss@ietf.org, routingworkshop@lists.i1b.org, iesg@ietf.org, ram@iab.org, v6ops@ops.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="===============1420466809==" Errors-To: architecture-discuss-bounces@ietf.org --===============1420466809== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k+w/mQv8wyuph6w0" Content-Disposition: inline --k+w/mQv8wyuph6w0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 07, 2006 at 03:09:41PM -0500, Noel Chiappa wrote: > > From: David Meyer >=20 > > discussion of what the follow-on's to the workshop might be on vari= ous > > lists. What I'm hoping we can do is consolidate that discussion on > > ram@iab.org. >=20 > I would take a slightly different view, and think there is (non-overlappi= ng) > role for both (and I hope the various I* bodies won't take offense at me = for > differing a bit with this plan; I really do have everyone's best interest= s at > heart here.) >=20 >=20 > First, this is a big problem, and there are a number of different technic= al > areas; with a single forum, it might get kind of Babel-like. Second, and = more > important I think, I find that in any wide-ranging discussion like this, = the > routing stuff (which is usually the hardest problem) gets the short end of > the stick. (I have my opinions on why that happens, but I'll leave them be > for now.) And, I hope I don't need to point out, it was coming problems w= ith > the routing which have led to this. >=20 > IMNSHO, it's really unacceptable to work on this problem and not give a k= ey > role to consideration of how the routing is going to work. And to make su= re > the routing is going to work, we have to dive into the muck and tackle the > routing technical issues in some detail, to make sure it all really works= . So > we have to drive pretty quickly to considering the technical details of h= ow > the routing is going to work, I think. And that's something the people who > seem to have energy available to discuss things have been fairly loathe t= o do, > despite some not-so-subtle prods from me. >=20 >=20 > So I think keeping the RAM list focused on just the routing stuff is real= ly > pretty critical; it's clear that that's a really substantial discussion. > Discussion of other related topics there (e.g. separation of location and > identity) would just distract from that, and that's where A-D list would = be > useful. >=20 > I feel that discussion of such issues as end-end naming, whether we have = to > use the "jack-up" model (in which end-hosts remain totally unmodified), e= tc, > etc, really ought to be kept on A-D, to keep RAM clear for these routing > issues. >=20 > To keep this from getting too long, I'll send out a separate message in a > couple of hours (just on RAM) giving a little more detail on the points I > think RAM needs to work on, and how I think it can best make progress on = them. Thanks Noel. No disagreement on my part. --dmm =09 =09 --k+w/mQv8wyuph6w0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFeIPiORgD1qCZ2KcRAlzmAJ9HwQyvyxeC/c5oAz+iYVoT+a4kcgCfeIZu Lv1b9m1siumv0fZcK1msiQ4= =sRIW -----END PGP SIGNATURE----- --k+w/mQv8wyuph6w0-- --===============1420466809== 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 --===============1420466809==-- From architecture-discuss-bounces@ietf.org Thu Dec 07 16:44:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsR1v-0008G4-Sj; Thu, 07 Dec 2006 16:43:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsR1u-0008FD-Od for architecture-discuss@ietf.org; Thu, 07 Dec 2006 16:43:46 -0500 Received: from webmail.troposnetworks.com ([12.108.168.187] helo=iceblock01.tropos.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GsR1s-0002aC-Pp for architecture-discuss@ietf.org; Thu, 07 Dec 2006 16:43:46 -0500 Received: (qmail 9695 invoked from network); 7 Dec 2006 21:43:44 -0000 Received: from ca-bay-exch-01.tropos.com (192.168.1.49) by iceblock01.tropos.com with SMTP; 7 Dec 2006 21:43:44 -0000 Received: from LIPC ([192.168.1.75]) by ca-bay-exch-01.tropos.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Dec 2006 13:43:43 -0800 From: "Tony Li" To: "'Bruce Curtis'" , Subject: RE: [arch-d] It's about Information Date: Thu, 7 Dec 2006 13:43:40 -0800 Message-ID: <002d01c71a48$c2a74ca0$4b01a8c0@tropos.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 thread-index: AccaPEWEDIuqFMJoSTq917Vfa12i4AAC2blQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: X-OriginalArrivalTime: 07 Dec 2006 21:43:43.0561 (UTC) FILETIME=[C43C6B90:01C71A48] X-Antivirus: Scanned by Tropos Antivirus 1.0.4 X-Spam-Score: 0.1 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tony.li@tony.li 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="===============2144493711==" Errors-To: architecture-discuss-bounces@ietf.org This is a multi-part message in MIME format. --===============2144493711== Content-Type: multipart/alternative; boundary="----=_NextPart_000_002E_01C71A05.B4840CA0" This is a multi-part message in MIME format. ------=_NextPart_000_002E_01C71A05.B4840CA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I agree that having a source locator has been handy for RPF checks, but is that the only way? If the identifier space is structured, then filtering on the identifier might be tractable. Someone on the list mentioned RPF checks by AS as a possibility. I can see that if the identifier were required to contain the AS or something similar that might work. But on my campus it has been very handy to just enable the RPF checking on every subnet. That contains any spoofing as close to the source as possible. I can see where it is likely possible to include enough structure in the identifier to identify the ISP customer but it might be more challenging to have it include info about each of my subnets, and if we do then isn't the identifier becoming closer to a locator again? I can see at least two possible directions here: The 'identifier' can be opaque. If your particular site requires sufficient scale, then you may choose to add more structure to your particular identifier space. We could also generalize the locator to be hierarchical. Thus, the locator would have a global portion and then be hierarchically allocated, with as much depth as is required and appropriate. The challenges with this are that at any level, the bit boundaries between locator levels are not fixed, so equipment needs to be more flexible. Further, we would be attempting to fit arbitrary levels of hierarchy into a fixed field. The latter seems cleaner to my mind. Multicast also depends heavily on the source locator for RPF checking, but multicast is already maintaining state so guess if the source locator info is in some early packets and the router caches the source identifier to be associated with the state created then it might not be necessary for the later packets to contain a source locator. With multicast, as always, things are reversed. Then the question becomes whether the destination locator provides any value. Hmm, good point. As long as there is a destination identifier and the packet is somehow marked as multicast I can't think of a requirement for the destination locator. Perhaps a destination locator or something similar might be handy for scope issues? But then again that might be better handled by structure in the destination identifier? Exactly. Tony ------=_NextPart_000_002E_01C71A05.B4840CA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 

I agree that=20 having a source locator has been handy for RPF checks, but is that the = only=20 way? If the identifier space is structured, then filtering on the = identifier=20 might be tractable.

Someone on the list mentioned RPF checks by AS as a possibility. = I can=20 see that if the identifier were required to contain the AS or = something=20 similar that might work. But on my campus it has been very handy to = just=20 enable the RPF checking on every subnet. That contains any spoofing as = close=20 to the source as possible. I can see where it is likely possible to = include=20 enough structure in the identifier to identify the ISP customer but it = might=20 be more challenging to have it include info about each of my subnets, = and if=20 we do then isn't the identifier becoming closer to a locator = again? 
 
I can=20 see at least two possible directions here:
 
The=20 'identifier' can be opaque.  If your particular site requires = sufficient=20 scale, then you may choose to add more structure to your particular = identifier=20 space.
 
We=20 could also generalize the locator to be hierarchical.  Thus, the = locator=20 would have a global portion and then be hierarchically allocated, with = as much=20 depth as is required and appropriate.  The challenges with this are = that at=20 any level, the bit boundaries between locator levels are not fixed, so = equipment=20 needs to be more flexible.  Further, we would be attempting to fit=20 arbitrary levels of hierarchy into a fixed field.
 
The=20 latter seems cleaner to my mind.
Multicast also depends heavily on = the source=20 locator for RPF checking, but multicast is already maintaining state = so=20 guess if the source locator = info is in=20 some early packets and the router caches the source identifier to be = associated with the state created then it might not be necessary for = the=20 later packets to contain a source locator.
With=20 multicast, as always, things are reversed. Then the question becomes = whether=20 the destination locator provides any = value.
Hmm, good point. As long as there is a destination identifier and = the=20 packet is somehow marked as multicast I can't think of a requirement = for the=20 destination locator. Perhaps a destination locator or something = similar might=20 be handy for scope issues? But then again that might be better handled = by=20 structure in the destination identifier? 
 
Exactly.
 
Tony
 
------=_NextPart_000_002E_01C71A05.B4840CA0-- --===============2144493711== 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 --===============2144493711==-- From architecture-discuss-bounces@ietf.org Thu Dec 07 18:40:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsSpY-0000jG-VM; Thu, 07 Dec 2006 18:39:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsSpY-0000j6-Dk for architecture-discuss@ietf.org; Thu, 07 Dec 2006 18:39:08 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsSpW-0004z6-2S for architecture-discuss@ietf.org; Thu, 07 Dec 2006 18:39:08 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id 1B04C4AC73; Thu, 7 Dec 2006 18:39:02 -0500 (EST) Date: Thu, 7 Dec 2006 18:39:02 -0500 From: John Leslie To: Noel Chiappa Subject: Re: [RAM] Re: [arch-d] mailing lists and follow-ons to the IAB Routing & Addressing workshop Message-ID: <20061207233902.GA67571@verdi> References: <20061207200941.A0BDF872C0@mercury.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061207200941.A0BDF872C0@mercury.lcs.mit.edu> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: architecture-discuss@ietf.org, ram@iab.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Noel Chiappa wrote: >> From: David Meyer > >> discussion of what the follow-on's to the workshop might be on various >> lists. What I'm hoping we can do is consolidate that discussion on >> ram@iab.org. It _will prove difficult to keep general architecture separate from routing table growth. I agree with David that keeping a complete (enough) record of the discussion on the RAM list is a reasonable request. This will probably result in a fair amount of cross-posting. :^( > I would take a slightly different view, and think there is > (non-overlapping) role for both (and I hope the various I* bodies won't > take offense at me for differing a bit with this plan; I really do have > everyone's best interests at heart here.) It's important to consider the stated purpose of the RAM list: ] ] This list serves as a technical discussion forum for all members of the ] IETF community that are interested in continued discussion of the ] analysis of and potential solutions to the continued growth in the size ] and dynamics of the Internet's default free zone routing table. We need, IMHO, to respect that. > First, this is a big problem, and there are a number of different > technical areas; with a single forum, it might get kind of Babel-like. A very definite risk! > Second, and more important I think, I find that in any wide-ranging > discussion like this, the routing stuff (which is usually the hardest > problem) gets the short end of the stick. (I have my opinions on why > that happens, but I'll leave them be for now.) And, I hope I don't > need to point out, it was coming problems with the routing which have > led to this. I don't mind stating my opinion why: too few folks understand routing, while too many insist on talking about it. > IMNSHO, it's really unacceptable to work on this problem and not give > a key role to consideration of how the routing is going to work. Agreed. > And to make sure the routing is going to work, we have to dive into > the muck and tackle the routing technical issues in some detail, > to make sure it all really works. Agreed. This is perhaps _too_ hard on a fully open list... > So we have to drive pretty quickly to considering the technical details > of how the routing is going to work, I think. And that's something the > people who seem to have energy available to discuss things have been > fairly loathe to do, despite some not-so-subtle prods from me. As any rational expert should be, IMHO, until s/he is assured of protection from "feature creep". > So I think keeping the RAM list focused on just the routing stuff is > really pretty critical; it's clear that that's a really substantial > discussion. I agree that discussing routing details is currently more appropriate for RAM than [arch-d]. I am even willing to (try to) help Noel discuss it there. But I don't think it a good idea to try to limit that list to routing discussion. > Discussion of other related topics there (e.g. separation of location > and identity) would just distract from that, and that's where A-D list > would be useful. IMHO, _some_ separation of location from identity will be necessary in order to make routing scale acceptably. It seems unwise to call such discussion out-of-scope. > I feel that discussion of such issues as end-end naming, whether we > have to use the "jack-up" model (in which end-hosts remain totally > unmodified), etc, etc, really ought to be kept on A-D, to keep RAM > clear for these routing issues. End-to-end naming probably belongs on [arch-d]. "Jack-up" is likely necessary for short-term fixes. It too should be in-scope for discussion on RAM. > To keep this from getting too long, I'll send out a separate message > in a couple of hours (just on RAM) giving a little more detail on the > points I think RAM needs to work on, and how I think it can best make > progress on them. Sounds like a good idea to start discussion! -- John Leslie _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Dec 07 22:49:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsWiS-0006b9-PP; Thu, 07 Dec 2006 22:48:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsWiR-0006az-C2 for architecture-discuss@ietf.org; Thu, 07 Dec 2006 22:48:03 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsWiM-0004GO-G7 for architecture-discuss@ietf.org; Thu, 07 Dec 2006 22:48:03 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id EECCD3405B; Thu, 7 Dec 2006 22:48:00 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Dec 2006 22:47:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [arch-d] It's about Information Date: Thu, 7 Dec 2006 22:47:51 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC010B67C0@tayexc14.americas.cpqcorp.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] It's about Information Thread-Index: AccaKzAkU87NoYXoQC+mgMTVSY2KtwAUGmhg From: "Bound, Jim" To: "Bruce Curtis" , X-OriginalArrivalTime: 08 Dec 2006 03:47:53.0115 (UTC) FILETIME=[A395C6B0:01C71A7B] X-Spam-Score: 0.1 (/) X-Scan-Signature: 5655aae64318292c42757ebeb53e54ce 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: , Content-Type: multipart/mixed; boundary="===============2094587564==" Errors-To: architecture-discuss-bounces@ietf.org This is a multi-part message in MIME format. --===============2094587564== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C71A7B.A336C073" This is a multi-part message in MIME format. ------_=_NextPart_001_01C71A7B.A336C073 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Good brainstorming on GPS. =20 thanks /jim ________________________________ From: Bruce Curtis [mailto:bruce.curtis@ndsu.edu]=20 Sent: Thursday, December 07, 2006 1:11 PM To: architecture-discuss@ietf.org Subject: Re: [arch-d] It's about Information =09 =09 On Dec 7, 2006, at 6:15 AM, Bound, Jim wrote: I like this thinking model. Why is this not a form or source address routing with a lot of other addded value using locators.=20 =09 The way I thought about the model all of the routing was still based on the multiple destination addresses and the source addresses would just be used for anti-spoof RPF checking. But if the source info is in every packet lots of other options I hadn't considered are possible with this model as well. I also believe that GPS information can add great value to routing and doing some research on that concept for ad hoc nets but have assumed no way could we ever get a standard done to use it? =20 /jim I know there have been proposals about having the addresses or locators based on location or GPS and it solved some routing problems but I think the ISPs had some objections. When I was thinking through how things would work with this model I was thinking of the GPS info as more of an ID than a locator. Sometimes when there is a problem host it would be nice to have it's location info, but there are privacy issues and perhaps other downsides as well. But one way to use the same model but turn my thinking on it's head is to consider the GPS info as the primary locator and the other multiple locators as ISP specific locators. The question that comes to mind is if that would lessen the ISP objections to the GPS based address model. I'm not an ISP so the answer doesn't come naturally to me, I'll have to think about if for a while. ________________________________ From: Bruce Curtis [mailto:bruce.curtis@ndsu.edu]=20 Sent: Monday, December 04, 2006 6:11 PM To: architecture-discuss@ietf.org Subject: [arch-d] It's about Information =09 =09 This may be obvious to everyone since I haven't seen much discussion about this model but it helped me understand the issues.=20 In the IPv4 multihoming model the information about multiple paths from host A to host Z is in the routing table of the core routers in the Internet. =20 ISP 1 ---------------- I --------------------------------- ISP 7 | n | A -- ISP 2 ------- t ------------------------ ISP 8 -- Z | e | ISP 3 --------------- r --------------------------------- ISP 9 =09 n =09 e =09 t If we change the model and take the information about multiple paths out of the core routers and give each host a different IP number for each of it's ISPs, then to preserve some of the properties of the old model we still need to have the multiple path information available to the network somehow. ISP 1 ---------------- I --------------------------------- ISP 7=20 | n | A,B,C -- ISP 2 ------- t ------------------------ ISP 8 -- X,Y,Z | e | ISP 3 --------------- r --------------------------------- ISP 9 =09 n =09 e =09 t If we imagine a time in the future where every host has 100 Mbps connection to the Internet like some homes in Japan today and we have networks that support Jumbo frames it's easier to consider the possibility that we put the required information in every packet from host A,B,C to host X,Y,Z. That is, we put all of the destination addresses X,Y,Z in the packet as well as the source addresses A,B,C. =20 So basically we take the information about multiple paths out of the routing tables where it doesn't scale and put the multiple path info in each packet, which should scale right along with the speed of the router. If we put this information in each packet then the new model has several properties that the old model has. For example: Traffic engineering can be done at any point in the path. =20 Anti-Spoof checking can be done at the interface between the customer and ISP. If a link is down between any ISP and host X,Y,Z the internet can reroute the packet to one of the other addresses for X,Y,Z. The more I thought about it the more sense this model made to me and it helped me understand many of the other proposed alternatives as attempts to optimize this model and remove some of the information from the packet. Also it made it clearer to me that the discussion about locator/ID split has more to do with trying to preserve a single address representation to current and future software and that it was the multiple locators and not the locator/ID split that helps solve the routing portion of the multihoming problem. To further understand the possibilities I realized that IPv6 did not provide the means to include all of these addresses but IPv6 does have a method of being extended to include such addresses, extension headers. Actually putting the multiple destination addresses in extension headers might not be too much different from the current hop-by-hop extension headers. (And there would have to be something in the standard to avoid loops in the case of a link failure, something that marks an address as already having failed, but again that might not be too different from the hop-by-hop extension headers.) Considering the extension headers helped me move one step closer to the real world and also to envision at least one optimization. To me it seems that the natural point to discover the multiple paths from host A,B,C to host X,Y,X is at the host A,B,C, through DNS lookup etc. It seems that shim6 is already capable of handling that information so I think it makes sense for the end host to put the X,Y,Z destination addresses in the packet. However I can see two possibilities for where in the network the multiple source addresses are placed in the packet. Members of the "I hate middleboxes club" could have their hosts fill in the multiple source addresses. However members of the "I only want my hosts to have one IP address" club could design their network to have a middle box at the interface to their ISPs and have the middelbox add the multiple source addresses. The middle box would also have to do the right magic to route an inbound packet with the multiple destination addresses to the end host with the single IP address but it could do so without having to maintain state for every connection through the middlebox. (Middleboxes with flow-based architecture that are required to maintain state are one of my main objections to middleboxes.) Anyway the model of putting enough information in the packet would seem to support at least two options for the end network, allowing some choice for the end network. And if implemented with extension headers it might be partially backwards compatible with what is implemented today, it wouldn't break anything, but hosts/networks that did not support the new model wouldn't benefit from all of the redundancy of multihoming. There has been talk on the list about not wanting to overload identifiers but it has been helpful to me to think of unique unchanging IDs for hosts in terms of the above model. If we add another IP number to each host so we have host A,B,C,D and host W,X,Y,Z but D and W have no associated ISPs things still work. It is about the same case as if D and W did have an associated ISP but the links to those ISPs were down. IPs D and W could even be assigned based on GPS location or something similar if they where still guaranteed to be unique. The identifiers are overloaded but it might be workable as an interim solution, something similar to shim6. Another possible optimization could be to strip off the multiple source addresses at the interface between the customer and the ISP and just leave the one that is associated with that ISP. But then the receiving host wouldn't automatically know all of the return addresses of the sending host. =20 Sorry if this was obvious to everyone but I thought the idea of putting all of the required info in the packets should at least be floated and shot down and hopefully the shooting down and discussion would be useful in the long run. To me considering the extreme case was helpful in understanding the problem and in classifying some of the proposed alternatives. =09 --- Bruce Curtis bruce.curtis@ndsu.edu Certified NetAnalyst II 701-231-8527 North Dakota State University =20 =09 =09 --- Bruce Curtis bruce.curtis@ndsu.edu Certified NetAnalyst II 701-231-8527 North Dakota State University =20 ------_=_NextPart_001_01C71A7B.A336C073 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Good brainstorming on GPS.
 
thanks
/jim

From: Bruce Curtis=20 [mailto:bruce.curtis@ndsu.edu]
Sent: Thursday, December 07, = 2006=20 1:11 PM
To: architecture-discuss@ietf.org
Subject: = Re:=20 [arch-d] It's about Information


On Dec 7, 2006, at 6:15 AM, Bound, Jim wrote:
I like this thinking model.  Why is = this not a=20 form or source address routing with a lot of other addded value = using=20 locators. 

  The way I thought about the model all of the routing was = still=20 based on the multiple destination addresses and the source addresses = would=20 just be used for anti-spoof RPF checking.  But if the source info = is in=20 every packet lots of other options I hadn't considered are possible = with this=20 model as well.

I also believe that GPS information can add = great value=20 to routing and doing some research on that concept for ad hoc nets = but have=20 assumed no way could we ever get a standard done to use=20 it?
 
/jim


  I know there = have been=20 proposals about having the addresses or locators based on location or = GPS and=20 it solved some routing problems but I think the ISPs had some=20 objections.

   When I was thinking through how things would work = with this=20 model I was thinking of the GPS info as more of an ID than a = locator. =20  Sometimes when there is a problem host it would be nice to have = it's=20 location info, but there are privacy issues and perhaps other = downsides as=20 well.

   But one way to use the same model but turn my = thinking on=20 it's head is to consider the GPS info as the primary locator and the = other=20 multiple locators as ISP specific locators.  The question that = comes to=20 mind is if that would lessen the ISP objections to the GPS based = address=20 model.  I'm not an ISP so the answer doesn't come naturally to = me, I'll=20 have to think about if for a while.


From: Bruce Curtis [mailto:bruce.curtis@ndsu.edu]=20
Sent: Monday, December 04, 2006 6:11 PM
To: = architecture-discuss@ietf.o= rg
Subject:=20 [arch-d] It's about Information


  This may be = obvious to=20 everyone since I haven't seen much discussion about this model but = it=20 helped me understand the issues.=20

  In the IPv4 multihoming model the information about = multiple=20 paths from host A to host Z is in the routing table of the core = routers in=20 the Internet.
            

        ISP 1   = ----------------  =20     I  =  --------------------------------- =20  ISP 7
           |   =   =20               =20               =20  n             =   =20               =20               =20        |
          A  =  -- =20 ISP 2  -------        t =20  ------------------------  ISP 8  --  Z
           |   =   =20               =20               =20  e             =   =20               =20               =20        |
         ISP 3  =20 ---------------        r =20 ---------------------------------   ISP 9
             =   =20               =20               =20     n
             =   =20               =20               =20     e
             =   =20               =20               =20     t

  If we change the model and take the information about = multiple=20 paths out of the core routers and give each host a different IP = number for=20 each of it's ISPs, then to preserve some of the properties of the = old=20 model we still need  to have the multiple path information = available=20 to the network somehow.


         ISP 1  =20 ----------------       I =20  ---------------------------------   ISP 7=20
           |   =   =20               =20               =20  n             =   =20               =20               =20        |
   A,B,C   --  ISP 2 =  ------- =20       t  =  ------------------------  ISP=20 8  --  X,Y,Z
           |   =   =20               =20               =20  e             =   =20               =20               =20        |
         ISP 3  =20 ---------------        r =20 ---------------------------------   ISP 9
             =   =20               =20               =20     n
             =   =20               =20               =20     e
             =   =20               =20               =20     t

  If we imagine a time in the future where every host = has 100=20 Mbps connection to the Internet like some homes in Japan today and = we have=20 networks that support Jumbo frames it's easier to consider the = possibility=20 that we put the required information in every packet from host = A,B,C to=20 host X,Y,Z.  That is, we put all of the destination addresses = X,Y,Z=20 in the packet as well as the source addresses = A,B,C.  
  So basically we take the information about multiple = paths out=20 of the routing tables where it doesn't scale and put the multiple = path=20 info in each packet, which should scale right along with the speed = of the=20 router.

  If we put this information in each packet then the new = model=20 has several properties that the old model has.  For = example:

         Traffic engineering = can be=20 done at any point in the path.
         
          Anti-Spoof = checking can=20 be done at the interface between the customer and ISP.

          If a link is = down=20 between any ISP and host X,Y,Z the internet can reroute the = packet
          to one of the = other=20 addresses for X,Y,Z.

  The more I thought about it the more sense this model = made to=20 me and it helped me understand many of the other proposed = alternatives as=20 attempts to optimize this model and remove some of the information = from=20 the packet.

  Also it made it clearer to me that the discussion = about=20 locator/ID split has more to do with trying to preserve a single = address=20 representation to current and future software and that it was the = multiple=20 locators and not the locator/ID split that helps solve the routing = portion=20 of the multihoming problem.

  To further understand the possibilities I realized = that IPv6=20 did not provide the means to include all of these addresses but = IPv6 does=20 have a method of being extended to include such addresses, = extension=20 headers.  Actually putting the multiple destination addresses = in=20 extension headers might not be too much different from the current = hop-by-hop extension headers.   (And there would have to = be=20 something in the standard to avoid loops in the case of a link = failure,=20 something that marks an address as already having failed, but = again that=20 might not be too different from the hop-by-hop extension = headers.)

  Considering the extension headers helped me move one = step=20 closer to the real world and also to envision at least  one=20 optimization.  To me it seems that the natural point to = discover the=20 multiple paths from host A,B,C to host X,Y,X is at the host A,B,C, = through=20 DNS lookup etc.  It seems that shim6 is already capable of = handling=20 that information so I think it makes sense for the end host to put = the=20 X,Y,Z destination addresses in the packet.  However I can see = two=20 possibilities for where in the network the multiple source = addresses are=20 placed in the packet.  Members of the "I hate middleboxes = club" could=20 have their hosts fill in the multiple source addresses.  = However=20 members of the "I only want my hosts to have one IP address" club = could=20 design their network to have a middle box at the interface to = their ISPs=20 and have the middelbox add the multiple source addresses.  = The middle=20 box would also have to do the right magic to route an inbound = packet with=20 the multiple destination addresses to the end host with the single = IP=20 address but it could do so without having to maintain state for = every=20 connection through the middlebox.  (Middleboxes with = flow-based=20 architecture that are required to maintain state are one of my = main=20 objections to middleboxes.)  Anyway the model of putting = enough=20 information in the packet  would seem to support at least = two =20 options for the end network, allowing some choice for the end = network.=20  And if implemented with extension headers it might be = partially=20 backwards compatible with what is implemented today, it wouldn't = break=20 anything, but hosts/networks that did not support the new model = wouldn't=20 benefit from all of the redundancy of multihoming.

  There has been talk on the list about not wanting to = overload=20 identifiers but it has been helpful to me to think of unique = unchanging=20 IDs for hosts in terms of the above model.  If we add another = IP=20 number to each host so we have host A,B,C,D and host W,X,Y,Z but D = and W=20 have no associated ISPs things still work.  It is about the = same case=20 as  if D and W did have an associated ISP but the links to = those ISPs=20 were down.  IPs D and W could even be assigned based on GPS = location=20 or something similar if they where still guaranteed to be = unique. =20 The identifiers are overloaded but it might be workable as an = interim=20 solution, something similar to shim6.

  Another possible optimization could be to strip off = the=20 multiple source addresses at the interface between the customer = and the=20 ISP and just leave the one that is associated with that ISP.  = But=20 then the receiving host wouldn't automatically know all of the = return=20 addresses of the sending host.
  
  Sorry if this was obvious to everyone but I thought = the idea=20 of putting all of the required info in the packets should at least = be=20 floated and shot down and hopefully the shooting down and = discussion would=20 be useful in the long run.  To me considering the extreme = case was=20 helpful in understanding the problem and in classifying some of = the=20 proposed alternatives.

---
Bruce Curtis   =    =20                   bruce.curtis@ndsu.edu
Certified NetAnalyst II          =    =20   701-231-8527
North Dakota State University =    =20  =20 =  



---

Bruce Curtis   =    =20                   bruce.curtis@ndsu.edu

Certified NetAnalyst II            =  =20   701-231-8527

North Dakota State University      =20  


------_=_NextPart_001_01C71A7B.A336C073-- --===============2094587564== 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 --===============2094587564==-- From architecture-discuss-bounces@ietf.org Thu Dec 07 22:56:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsWqC-0001D2-Dw; Thu, 07 Dec 2006 22:56:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsWqB-0001Cu-FE for architecture-discuss@ietf.org; Thu, 07 Dec 2006 22:56:03 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsWq6-0005jv-72 for architecture-discuss@ietf.org; Thu, 07 Dec 2006 22:56:03 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id A46DC34021; Thu, 7 Dec 2006 22:55:58 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Dec 2006 22:55:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] It's about Information Date: Thu, 7 Dec 2006 22:55:56 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC010B67C2@tayexc14.americas.cpqcorp.net> In-Reply-To: <904691F9-4631-499F-816E-64A720E55822@comcast.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] It's about Information Thread-Index: AccaLu+9xVhOMySrTI2Vl03dG9jsZQATNNzA From: "Bound, Jim" To: "Tony Li" , "Bruce Curtis" X-OriginalArrivalTime: 08 Dec 2006 03:55:57.0700 (UTC) FILETIME=[C46B9440:01C71A7C] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I agree in principle with Tony below when I said source routing I was being lazy. I mean't a means as Bruce suggested using an extenion or hop-by-hop to hold locators and the variants Bruce has suggested. I am getting convinced from others we really need to permit the source to be tool for routing path optimizations at points on the network, and remove from needs for security and transport layer. But if we were able to do that some questions we need to answer: 1. make sure none use src ever for Ipsec make it a MUST of course if we find an identifier for transport connection-id associations we might not even need the IP address for IPsec including dst address. 2. the src address is the way the node responds to its peer in most cases today whatever we do best if we do not add performance hit for lookups for dst address except at initial handshake, unless some update to an identifier above changes the connection-id state then thats ok and assume there would be valid reason for the user to take the performance hit. 3. others I am sure. Just brainstorming. /jim=20 > -----Original Message----- > From: Tony Li [mailto:li.tony@comcast.net]=20 > Sent: Thursday, December 07, 2006 1:21 PM > To: Bruce Curtis > Cc: architecture-discuss@ietf.org > Subject: Re: [arch-d] It's about Information >=20 >=20 > On Dec 7, 2006, at 10:10 AM, Bruce Curtis wrote: >=20 >=20 > On Dec 7, 2006, at 6:15 AM, Bound, Jim wrote: >=20 >=20 > I like this thinking model. Why is this not a=20 > form or source address routing with a lot of other addded=20 > value using locators.=20 > =09 >=20 >=20 > The way I thought about the model all of the routing=20 > was still based on the multiple destination addresses and the=20 > source addresses would just be used for anti-spoof RPF=20 > checking. But if the source info is in every packet lots of=20 > other options I hadn't considered are possible with this=20 > model as well. >=20 >=20 >=20 > I think that there's an important distinction here: it's=20 > vital to the upper layers that packets contain a source=20 > identifier. However, the inclusion of a source locator is=20 > not clearly necessary. >=20 > Tony >=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 Thu Dec 07 22:56:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsWqm-0001Mc-Pz; Thu, 07 Dec 2006 22:56:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsWql-0001Kj-8D for architecture-discuss@ietf.org; Thu, 07 Dec 2006 22:56:39 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsWqf-0005pC-Ow for architecture-discuss@ietf.org; Thu, 07 Dec 2006 22:56:39 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 8206E3405B; Thu, 7 Dec 2006 22:56:39 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Dec 2006 22:56:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [arch-d] It's about Information Date: Thu, 7 Dec 2006 22:56:32 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC010B67C3@tayexc14.americas.cpqcorp.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] It's about Information Thread-Index: AccaMm40D3NODvbATmyi+oI4K60lmgASlzug From: "Bound, Jim" To: "Bruce Curtis" , X-OriginalArrivalTime: 08 Dec 2006 03:56:33.0386 (UTC) FILETIME=[D9B0D4A0:01C71A7C] X-Spam-Score: 0.1 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 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: , Content-Type: multipart/mixed; boundary="===============0768698862==" Errors-To: architecture-discuss-bounces@ietf.org This is a multi-part message in MIME format. --===============0768698862== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C71A7C.D9721B1F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C71A7C.D9721B1F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I again agree with Tony. If we did it right locator would not be required at all. =20 /jim ________________________________ From: Bruce Curtis [mailto:bruce.curtis@ndsu.edu]=20 Sent: Thursday, December 07, 2006 2:02 PM To: architecture-discuss@ietf.org Subject: Re: [arch-d] It's about Information =09 =09 On Dec 7, 2006, at 12:20 PM, Tony Li wrote: On Dec 7, 2006, at 10:10 AM, Bruce Curtis wrote: On Dec 7, 2006, at 6:15 AM, Bound, Jim wrote: I like this thinking model. Why is this not a form or source address routing with a lot of other addded value using locators.=20 =09 The way I thought about the model all of the routing was still based on the multiple destination addresses and the source addresses would just be used for anti-spoof RPF checking. But if the source info is in every packet lots of other options I hadn't considered are possible with this model as well. I think that there's an important distinction here: it's vital to the upper layers that packets contain a source identifier. However, the inclusion of a source locator is not clearly necessary. Tony It's vital to the stacks on the end hosts that the packets contain a source identifier. If we imagine an example that is sort of the opposite extreme of the model I was thinking of I can see your point that inclusion of the source locator in the packet is not necessary at all for the network to deliver the packet. However having the source locator in the packet has been handy for anti-spoof RPF checks and there are lots of standards that depend on having the source locator in the packet. PMTU Discovery and all of the ICMP error reports depend on having the source locator in the packet so that they know where to send the error info to. If it were possible for the router to look up the locator info based on the identifier then the ICMP error reports wouldn't be an issue, but if the lookup were expensive it could lead to possible DoS attacks. Multicast also depends heavily on the source locator for RPF checking, but multicast is already maintaining state so I guess if the source locator info is in some early packets and the router caches the source identifier to be associated with the state created then it might not be necessary for the later packets to contain a source locator. But that could potentially lead to some scaling issues for the multicast RPF check if the check was done against a cache of source identifiers rather than comparing the source locator to the routing table. =09 =09 --- Bruce Curtis bruce.curtis@ndsu.edu Certified NetAnalyst II 701-231-8527 North Dakota State University =20 ------_=_NextPart_001_01C71A7C.D9721B1F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I again agree with Tony.   If we did = it right=20 locator would not be required at all.
 
/jim

From: Bruce Curtis=20 [mailto:bruce.curtis@ndsu.edu]
Sent: Thursday, December 07, = 2006=20 2:02 PM
To: architecture-discuss@ietf.org
Subject: = Re:=20 [arch-d] It's about Information


On Dec 7, 2006, at 12:20 PM, Tony Li wrote:

On Dec 7, 2006, at 10:10 AM, Bruce Curtis wrote:

On Dec 7, 2006, at 6:15 AM, Bound, Jim wrote:
I like this thinking model.  Why = is this not a=20 form or source address routing with a lot of other addded value = using=20 locators. 

  The way I thought about the model all of the routing = was still=20 based on the multiple destination addresses and the source = addresses would=20 just be used for anti-spoof RPF checking.  But if the source = info is=20 in every packet lots of other options I hadn't considered are = possible=20 with this model as well.


I think that there's an important distinction here: it's vital = to the=20 upper layers that packets contain a source identifier.  = However, the=20 inclusion of a source locator is not clearly necessary.

Tony

  It's vital to the stacks on the end hosts that the packets = contain=20 a source identifier.  If we imagine an example that is sort of = the=20 opposite extreme of the model I was thinking of I can see your point = that=20 inclusion of the source locator in the packet is not necessary at all = for the=20 network to deliver the packet.  However having the source locator = in the=20 packet has been handy for anti-spoof RPF checks and there are lots of=20 standards that depend on having the source locator in the = packet.  PMTU=20 Discovery and all of the ICMP error reports depend on having the = source=20 locator in the packet so that they know where to send the error info = to. =20 If it were possible for the router to look up the locator info based = on the=20 identifier then the ICMP error reports wouldn't be an issue, but if = the lookup=20 were expensive it could lead to possible DoS attacks.  Multicast = also=20 depends heavily on the source locator for RPF checking, but multicast = is=20 already maintaining state so I guess if the source locator info is in = some=20 early packets and the router caches the source identifier to be = associated=20 with the state created then it might not be necessary for the later = packets to=20 contain a source locator.  But that could potentially lead to = some=20 scaling issues for the multicast RPF check if the check was done = against a=20 cache of source identifiers rather than comparing the source locator = to the=20 routing table.



---

Bruce Curtis   =    =20                   bruce.curtis@ndsu.edu

Certified NetAnalyst II            =  =20   701-231-8527

North Dakota State University      =20  


------_=_NextPart_001_01C71A7C.D9721B1F-- --===============0768698862== 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 --===============0768698862==-- From architecture-discuss-bounces@ietf.org Thu Dec 07 23:00:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsWtZ-0002tJ-TL; Thu, 07 Dec 2006 22:59:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsWtY-0002tA-4M for architecture-discuss@ietf.org; Thu, 07 Dec 2006 22:59:32 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsWtS-0006ee-Qt for architecture-discuss@ietf.org; Thu, 07 Dec 2006 22:59:32 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id C550A3404C; Thu, 7 Dec 2006 22:59:29 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Dec 2006 22:59:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] It's about Information Date: Thu, 7 Dec 2006 22:59:23 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC010B67C5@tayexc14.americas.cpqcorp.net> In-Reply-To: <20061207195144.GA29183@grc.nasa.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] It's about Information Thread-Index: AccaOX41zRexeUqWSgK0eZZ3F4OJLQAQ5s+Q From: "Bound, Jim" To: , "Bruce Curtis" X-OriginalArrivalTime: 08 Dec 2006 03:59:25.0399 (UTC) FILETIME=[4037EE70:01C71A7D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org question: is your vision for example moving ND messages (sorry the last one I actually wrote code for) functions to a layer above IP? thx /jim=20 > -----Original Message----- > From: Wesley Eddy [mailto:weddy@grc.nasa.gov]=20 > Sent: Thursday, December 07, 2006 2:52 PM > To: Bruce Curtis > Cc: architecture-discuss@ietf.org > Subject: Re: [arch-d] It's about Information >=20 > On Thu, Dec 07, 2006 at 01:01:49PM -0600, Bruce Curtis wrote: > >=20 > > It's vital to the stacks on the end hosts that the=20 > packets contain a=20 > > source identifier. If we imagine an example that is sort of the=20 > > opposite extreme of the model I was thinking of I can see=20 > your point=20 > > that inclusion of the source locator in the packet is not=20 > necessary at=20 > > all for the network to deliver the packet. However having=20 > the source=20 > > locator in the packet has been handy for anti-spoof RPF checks and=20 > > there are lots of standards that depend on having the=20 > source locator=20 > > in the packet. PMTU Discovery and all of the ICMP error reports=20 > > depend on having the source locator in the packet so that they know=20 > > where to send the error info to. If it were possible for=20 > the router=20 > > to look up the locator info based on the identifier then the ICMP=20 > > error reports wouldn't be an issue, but if the lookup were=20 > expensive=20 > > it could lead to possible DoS attacks. Multicast also=20 > depends heavily=20 > > on the source locator for RPF checking, but multicast is already=20 > > maintaining state so I guess if the source locator info is in some=20 > > early packets and the router caches the source identifier to be=20 > > associated with the state created then it might not be=20 > necessary for=20 > > the later packets to contain a source locator. But that could=20 > > potentially lead to some scaling issues for the multicast=20 > RPF check if=20 > > the check was done against a cache of source identifiers=20 > rather than=20 > > comparing the source locator to the routing table. > >=20 >=20 > A separate topic for this list might be whether we can simply=20 > deprecate non-local ICMP error reporting. The local=20 > functions like ND, MLD, etc. > are useful, but for non-local signaling ICMP is fairly poor. =20 > PLPMTUD is a significant step in this direction. We should=20 > ask what part ICMP plays in the architecture in reality, and=20 > if that differs from the part it was originally intended to=20 > play or the part we think it should play. >=20 > The recent discussions in TCPM in San Diego and on the TCPM=20 > mailing list may be interesting to people. >=20 > -- > Wesley M. Eddy > Verizon Federal Network Systems >=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 Thu Dec 07 23:02:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsWwH-0003V2-Qs; Thu, 07 Dec 2006 23:02:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsWwG-0003Uo-BL; Thu, 07 Dec 2006 23:02:20 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsWwB-0007uJ-13; Thu, 07 Dec 2006 23:02:20 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 7DE2C34097; Thu, 7 Dec 2006 23:02:22 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Dec 2006 23:02:14 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RAM] Re: [arch-d] mailing lists and follow-ons to the IAB Routing &Addressing workshop Date: Thu, 7 Dec 2006 23:02:12 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC010B67C9@tayexc14.americas.cpqcorp.net> In-Reply-To: <20061207200941.A0BDF872C0@mercury.lcs.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Re: [arch-d] mailing lists and follow-ons to the IAB Routing &Addressing workshop Thread-Index: AccaO9hNojdXo/YWTUe0K17wnMkqqwAQZRyw From: "Bound, Jim" To: "Noel Chiappa" , , , , X-OriginalArrivalTime: 08 Dec 2006 04:02:14.0411 (UTC) FILETIME=[A4F51DB0:01C71A7D] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: iab@ietf.org, iesg@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I think Noel makes good sense here but suggest one caveat. When and if identifiers and naming appears as imperative to any architecture we have to take time to delve into them not just put them on hold and that will take us away from just routing a bit but only for routing not transport and I fear if we don't do that we may not see bug in the routing architecture of future analysis and development in RAM. /jim=20 > -----Original Message----- > From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu]=20 > Sent: Thursday, December 07, 2006 3:10 PM > To: architecture-discuss@ietf.org; ram@iab.org;=20 > routingworkshop@lists.i1b.org; v6ops@ops.ietf.org > Cc: iab@ietf.org; iesg@ietf.org; jnc@mercury.lcs.mit.edu > Subject: [RAM] Re: [arch-d] mailing lists and follow-ons to=20 > the IAB Routing &Addressing workshop >=20 > > From: David Meyer >=20 > > discussion of what the follow-on's to the workshop=20 > might be on various > > lists. What I'm hoping we can do is consolidate that=20 > discussion on > > ram@iab.org. >=20 > I would take a slightly different view, and think there is=20 > (non-overlapping) role for both (and I hope the various I*=20 > bodies won't take offense at me for differing a bit with this=20 > plan; I really do have everyone's best interests at heart here.) >=20 >=20 > First, this is a big problem, and there are a number of=20 > different technical areas; with a single forum, it might get=20 > kind of Babel-like. Second, and more important I think, I=20 > find that in any wide-ranging discussion like this, the=20 > routing stuff (which is usually the hardest problem) gets the=20 > short end of the stick. (I have my opinions on why that=20 > happens, but I'll leave them be for now.) And, I hope I don't=20 > need to point out, it was coming problems with the routing=20 > which have led to this. >=20 > IMNSHO, it's really unacceptable to work on this problem and=20 > not give a key role to consideration of how the routing is=20 > going to work. And to make sure the routing is going to work,=20 > we have to dive into the muck and tackle the routing=20 > technical issues in some detail, to make sure it all really=20 > works. So we have to drive pretty quickly to considering the=20 > technical details of how the routing is going to work, I=20 > think. And that's something the people who seem to have=20 > energy available to discuss things have been fairly loathe to=20 > do, despite some not-so-subtle prods from me. >=20 >=20 > So I think keeping the RAM list focused on just the routing=20 > stuff is really pretty critical; it's clear that that's a=20 > really substantial discussion. > Discussion of other related topics there (e.g. separation of=20 > location and > identity) would just distract from that, and that's where A-D=20 > list would be useful. >=20 > I feel that discussion of such issues as end-end naming,=20 > whether we have to use the "jack-up" model (in which=20 > end-hosts remain totally unmodified), etc, etc, really ought=20 > to be kept on A-D, to keep RAM clear for these routing issues. >=20 > To keep this from getting too long, I'll send out a separate=20 > message in a couple of hours (just on RAM) giving a little=20 > more detail on the points I think RAM needs to work on, and=20 > how I think it can best make progress on them. >=20 > Noel >=20 > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Dec 08 07:54:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsfDA-0007zO-Lh; Fri, 08 Dec 2006 07:52:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsfD9-0007yx-Jm for architecture-discuss@ietf.org; Fri, 08 Dec 2006 07:52:19 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsfD3-0006Kl-WC for architecture-discuss@ietf.org; Fri, 08 Dec 2006 07:52:19 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id E5578110F2E; Fri, 8 Dec 2006 13:52:10 +0100 (CET) Received: from [163.117.203.209] (unknown [163.117.203.209]) by smtp01.uc3m.es (Postfix) with ESMTP id 62DDB110ED3; Fri, 8 Dec 2006 13:52:07 +0100 (CET) In-Reply-To: <71F6867B-BB26-4A7D-9480-D8189BB32DB3@ndsu.edu> References: <71F6867B-BB26-4A7D-9480-D8189BB32DB3@ndsu.edu> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <6259c5f84a362e648b8985c03afc8356@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [arch-d] It's about Information Date: Fri, 8 Dec 2006 13:52:08 +0100 To: Bruce Curtis X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Hi Bruce, El 05/12/2006, a las 0:11, Bruce Curtis escribi=F3: > > =A0 If we imagine a time in the future where every host has 100 Mbps=20= > connection to the Internet like some homes in Japan today and we have=20= > networks that support Jumbo frames it's easier to consider the=20 > possibility that we put the required information in every packet from=20= > host A,B,C to host X,Y,Z.=A0 That is, we put all of the destination=20 > addresses X,Y,Z in the packet as well as the source addresses A,B,C.=A0=A0= > =A0 So basically we take the information about multiple paths out of = the=20 > routing tables where it doesn't scale and put the multiple path info=20= > in each packet, which should scale right along with the speed of the=20= > router. > > =A0 If we put this information in each packet then the new model has=20= > several properties that the old model has.=A0 For example: > > =A0 =A0=A0 =A0=A0 =A0Traffic engineering can be done at any point in = the path. > =A0 =A0=A0 =A0=A0 =A0 > =A0=A0 =A0=A0 =A0=A0 =A0Anti-Spoof checking can be done at the = interface between the=20 > customer and ISP. > > =A0=A0 =A0=A0 =A0=A0 =A0If a link is down between any ISP and host = X,Y,Z the=20 > internet can reroute the packet > =A0=A0 =A0=A0 =A0=A0 =A0to one of the other addresses for X,Y,Z. > > =A0 The more I thought about it the more sense this model made to me = and=20 > it helped me understand many of the other proposed alternatives as=20 > attempts to optimize this model and remove some of the information=20 > from the packet. > > =A0 Also it made it clearer to me that the discussion about locator/ID=20= > split has more to do with trying to preserve a single address=20 > representation to current and future software and that it was the=20 > multiple locators and not the locator/ID split that helps solve the=20 > routing portion of the multihoming problem. > > =A0 To further understand the possibilities I realized that IPv6 did = not=20 > provide the means to include all of these addresses but IPv6 does have=20= > a method of being extended to include such addresses, extension=20 > headers. i think that a difficulty with this is that you not only need to=20 include the alternative locator information, but also provide the means=20= to secure the binding between the identifier and the alternative=20 locators in order to prevent redirection attacks. This could be done=20 adding security information in the packet itself, but this is quite=20 much more information than just the locators. The other option would be=20= to verify the binding from a third trusted party, but in this case,=20 what is the point of including the alternative locator information in=20 te first place? (you could obtain it from the third trusted party) Regards, marcelo PS: you can check=20 http://www.watersprings.org/pub/id/draft-bagnulo-multi6-mhexthdr-00.txt=20= if you are interested in a broken version of a similar idea that=20 completelly missed all the security problems :-) _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Dec 08 09:10:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsgPS-0004nv-2z; Fri, 08 Dec 2006 09:09:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsgPQ-0004ng-Qq for architecture-discuss@ietf.org; Fri, 08 Dec 2006 09:09:04 -0500 Received: from rwcrmhc13.comcast.net ([216.148.227.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsgPO-0006kQ-BR for architecture-discuss@ietf.org; Fri, 08 Dec 2006 09:09:04 -0500 Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com[72.190.0.23]) by comcast.net (rwcrmhc13) with SMTP id <20061208140901m1300befd4e>; Fri, 8 Dec 2006 14:09:01 +0000 Message-ID: <104001c71ad1$fb2017e0$6701a8c0@china.huawei.com> From: "Spencer Dawkins" To: References: <71F6867B-BB26-4A7D-9480-D8189BB32DB3@ndsu.edu> <45758F59.3050308@zurich.ibm.com><8C4792D2-E5B0-4CB9-AFB7-8D9AF7E1BC62@ndsu.edu><4577CE90.1020800@zurich.ibm.com> <0A6F0E00-1CA2-49E8-A2AD-A3B5D3A1FC8B@ndsu.edu> Subject: Re: [arch-d] It's about Information Date: Fri, 8 Dec 2006 08:05:56 -0600 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.1 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 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="===============0327927837==" Errors-To: architecture-discuss-bounces@ietf.org This is a multi-part message in MIME format. --===============0327927837== Content-Type: multipart/alternative; boundary="----=_NextPart_000_103D_01C71A9F.B01F44F0" This is a multi-part message in MIME format. ------=_NextPart_000_103D_01C71A9F.B01F44F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Bruce, ("cough") but wouldn't ingress filtering based on one address in the set = of addresses being topologically correct just encourage source address = spoofers to be more careful about the addresses they spoof with?=20 Thanks, Spencer From: Bruce Curtis=20 Right but the model with all the info in the packet allows either = option, in one person's network they can let the host chose the path and = the packets flow as they may and in another person's network they can = have intelligent boxes at the customer ISP interface to do load = balancing or traffic engineering. Also I don't think that shim6 includes the multiple source = addresses in the packets which led to the complaint that implementing = anti-spoofing was then difficult or impossible. Or that shim6 had to = do extra work to put the correct source address in the packet so that = anti-spoofing still worked the old way. But again this complaint was = probably about wanting to do traffic engineering for load balancing at = the customer ISP interface also. Well, the tricky issue for shim6 is exit router selection - if = ingress filtering or RPF checks are in place, sending a packet via the wrong exit router is catastrophic. Right, but if all of the address info was in the packet we could = envision an RPF check that succeeds as long as only one of the multiple = source addresses was correct. Also it would be easier for the ISP to = implement the RPF check if they chose to, they wouldn't need to know the = customers other possible locators, they would only have to check the = list of source addresses to see if one of them matched that ISPs address = range. ------=_NextPart_000_103D_01C71A9F.B01F44F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi, Bruce,
 
("cough") but wouldn't ingress = filtering based on=20 one address in the set of addresses being topologically = correct just=20 encourage source address spoofers to be more careful about the = addresses=20 they spoof with?
 
Thanks,
 
Spencer
 
  Right but the model with all the info in the packet allows = either=20 option, in one person's network they can let the host chose the path = and the=20 packets flow as they may and in another person's network they can have = intelligent boxes at the customer ISP interface to do load balancing = or=20 traffic engineering.


 =20 Also I don't think that shim6 includes the multiple = source  addresses in the = packets which=20 led to the complaint that implementing  anti-spoofing was then = difficult=20 or impossible.  Or = that=20 shim6 had to  do = extra work=20 to put the correct source address in the packet so that  anti-spoofing still = worked the=20 old way.  But = again this=20 complaint was  = probably=20 about wanting to do traffic engineering for load balancing  at the customer ISP = interface=20 also.

Well, the tricky issue for shim6 is exit = router=20 selection - if ingress
filtering or RPF checks are in place, = sending a=20 packet via the wrong
exit router is = catastrophic.

  Right, but if all of the address info was in the packet we = could=20 envision an RPF check that succeeds as long as only one of the = multiple source=20 addresses was correct.  Also it would be easier for the ISP to = implement=20 the RPF check if they chose to, they wouldn't need to know the = customers other=20 possible locators, they would only have to check the list of source = addresses=20 to see if one of them matched that ISPs address=20 range.
------=_NextPart_000_103D_01C71A9F.B01F44F0-- --===============0327927837== 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 --===============0327927837==-- From architecture-discuss-bounces@ietf.org Fri Dec 08 09:14:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsgUh-0007dv-1I; Fri, 08 Dec 2006 09:14:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsgUd-0007aO-KR for architecture-discuss@ietf.org; Fri, 08 Dec 2006 09:14:27 -0500 Received: from rwcrmhc13.comcast.net ([204.127.192.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsgTX-0007fG-S9 for architecture-discuss@ietf.org; Fri, 08 Dec 2006 09:13:21 -0500 Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com[72.190.0.23]) by comcast.net (rwcrmhc13) with SMTP id <20061208141319m1300bcdi5e>; Fri, 8 Dec 2006 14:13:19 +0000 Message-ID: <109a01c71ad2$94cc4da0$6701a8c0@china.huawei.com> From: "Spencer Dawkins" To: References: <904691F9-4631-499F-816E-64A720E55822@comcast.net> <20061207195144.GA29183@grc.nasa.gov> Subject: Re: [arch-d] It's about Information Date: Fri, 8 Dec 2006 08:10:14 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I wasn't Present At The Creation, but my understanding of ICMP says this would be a good thing to think about early in the discussion. Between ICMP uses that just don't work (source quench) and ICMP uses that don't work because of too-careful firewalling, etc. we can't rely on ICMP for much, once we leave the local network. Thanks, Spencer > A separate topic for this list might be whether we can simply deprecate > non-local ICMP error reporting. The local functions like ND, MLD, etc. > are useful, but for non-local signaling ICMP is fairly poor. PLPMTUD > is a significant step in this direction. We should ask what part ICMP > plays in the architecture in reality, and if that differs from the part > it was originally intended to play or the part we think it should play. > > The recent discussions in TCPM in San Diego and on the TCPM mailing list > may be interesting to people. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Dec 08 11:21:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsiSb-0007KO-9Y; Fri, 08 Dec 2006 11:20:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsiSa-0007JR-By for architecture-discuss@ietf.org; Fri, 08 Dec 2006 11:20:28 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsiSY-0004pn-3s for architecture-discuss@ietf.org; Fri, 08 Dec 2006 11:20:28 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id C08BE86ADB; Fri, 8 Dec 2006 11:20:23 -0500 (EST) To: architecture-discuss@ietf.org Subject: Re: [arch-d] It's about Information Message-Id: <20061208162023.C08BE86ADB@mercury.lcs.mit.edu> Date: Fri, 8 Dec 2006 11:20:23 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: Bruce Curtis > If we imagine a time in the future where every host has 100 Mbps > connection to the Internet like some homes in Japan today and we have > networks that upport Jumbo frames Without taking a position on the specific point under discussion, let me push (again) this particular aspect: in thinking of architecture, try to imagine it on the hardware of 10 (or more, for networking stuff) years out. If what you imagine is impossible, or completely uneconomic, on today's hardware, OK, you have to rethink a bit. However, try to design for tomorrow's constraints, not today's. (In processors, this conceptual mistake used to show up in address spaces that were too small. And don't we all wish the IPv4 header had "wasted" 2 bytes more overhead, been 2 more bytes longer, to have source and destination address length fields? Etc, etc, etc.) > That is, we put all of the destination addresses X,Y,Z in the packet as > well as the source addresses A,B,C. So basically we take the > information about multiple paths Minor nit: even if you only have one address on each each end, you can still have multiple paths. This point is one I particularly notice because people try and specify paths using addresses (which is not what's happening here, I know), and it really doesn't work well. If you want to control paths, control them directly, don't try and do it indirectly via addresses. > out of the routing tables where it doesn't scale and put the multiple > path info in each packet What's happening with the multiple addresses is that you're taking some of the cost of supporting multihoming and moving it out of the routing, and moving it elsewhere in the system. [And from a different message...] > I know there have been proposals about having the addresses or locators > based on location or GPS and it solved some routing problems .. > .. I was thinking of the GPS info as more of an ID than a locator. > Sometimes when there is a problem host it would be nice to have it's > location info, but there are privacy issues .. as well. Yup. > But one way to use the same model but turn my thinking on it's head is > to consider the GPS info as the primary locator and the other multiple > locators as ISP specific locators. Umm, I'm going to call you on your terminology here. We have mostly been using "locator" to mean "a name that tells you were you are in the network". Your geographical location tells you nothing about your connectivity to the network, or the relationship in the network connectivity (aka "topology") to any entity you might want to exchange packets. So, I object to calling (or thinking of) any GPS-derived name a "locator". Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Dec 08 11:55:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsizt-0003kn-6H; Fri, 08 Dec 2006 11:54:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsizr-0003kh-Sb for architecture-discuss@ietf.org; Fri, 08 Dec 2006 11:54:51 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gsizp-0001XI-Kl for architecture-discuss@ietf.org; Fri, 08 Dec 2006 11:54:51 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 0CD0C86ADB; Fri, 8 Dec 2006 11:54:49 -0500 (EST) To: architecture-discuss@ietf.org Message-Id: <20061208165449.0CD0C86ADB@mercury.lcs.mit.edu> Date: Fri, 8 Dec 2006 11:54:49 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: jnc@mercury.lcs.mit.edu Subject: [arch-d] Major practical decision X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org So, this high-level conversation has been interesting and educational, but I'd like to ask a more "brass-tacks" question. In doing so, I'm basically recognizing that while it's nice to theorize with a blank sheet of paper, when it comes to specifying bits you have practical constraints. I get the sense that it is now generally accepted that widespread multi-homing has to be handled by use of multiple routing-names, and identity/location separation. However, it's not clear to me that a new end-end naming layer (e.g. SHIM6 or HIP) is really a viable solution, because of the amount of legacy equipment out there. (And a top of the hatly hat to David Conrad for first raising this issue.) I.e. if your site is multi-homed, and you've deployed HIP/whatever, that's not much use if many of the people trying to talk to you haven't. David's contention was that because of this we may be forced to convert the current IPvN addresses into end-end names, "jack up" the internetwork layer, and insert a new layer underneath, and deploy some sort of mapping system to map from IPvN "addresses" to some new routing-name namespace. I think that's a really good argument - that this is the only solution that's viable in a short time-frame. However, I'm very interested to hear what everyone else thinks on this point. (I note that it's always better to deploy something designed to a purpose, and it would be better to name end-end entities out of a new namespace designed for that purpose, but alas, we may be stuck.) I ask this because jack-up assumes a new routing-name namespace, which has implications for the routing: it immediately lands us with what seems to me, after a moderate look, to be a fairly hard problem in that part of the system - although one more soluble than routing PI addresses, before anyone says anything! So, what's it to be: jack-up (i.e. insertion of a new internetworking layer), or new end-end names (i.e. insertion of a new end-end naming layer)? Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Dec 08 13:03:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsk3Q-0006tL-75; Fri, 08 Dec 2006 13:02:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsk3O-0006sh-Lk for architecture-discuss@ietf.org; Fri, 08 Dec 2006 13:02:34 -0500 Received: from wr-out-0506.google.com ([64.233.184.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gsk3N-0002WG-Ea for architecture-discuss@ietf.org; Fri, 08 Dec 2006 13:02:34 -0500 Received: by wr-out-0506.google.com with SMTP id i7so1087122wra for ; Fri, 08 Dec 2006 10:02:33 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=ljegLCSmNSv1XAko3RK2hHOfud648pzy3dX19j/VHfHslWqSYJ5uD6nTYJ9EKYjxcm7k0DB5aAvwItAJqcK1SvxlAsyr7cBMTRMv47lbAS6Uo6hnJts7rO9eJ1Ip0eQlOiQAyHfZLV5qV8uJdXiTuYl2MKFdvoGvgiXag5TDfAE= Received: by 10.90.50.1 with SMTP id x1mr4457598agx.1165600950109; Fri, 08 Dec 2006 10:02:30 -0800 (PST) Received: by 10.90.69.2 with HTTP; Fri, 8 Dec 2006 10:02:30 -0800 (PST) Message-ID: <84a612dd0612081002r75d4914apa2aaad6c449f0832@mail.gmail.com> Date: Fri, 8 Dec 2006 18:02:30 +0000 From: "Mark Handley" To: "Noel Chiappa" Subject: Re: [arch-d] Major practical decision In-Reply-To: <20061208165449.0CD0C86ADB@mercury.lcs.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061208165449.0CD0C86ADB@mercury.lcs.mit.edu> X-Google-Sender-Auth: 5d347b7cb7dfc0c6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Felipe Huici , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On 12/8/06, Noel Chiappa wrote: > So, what's it to be: jack-up (i.e. insertion of a new internetworking layer), > or new end-end names (i.e. insertion of a new end-end naming layer)? I'm not sure these are the only possibilities. We've been playing with the idea of using edge-to-edge tunnelling to construct an infrastructure for defending against DDoS attacks. An unpublished paper is here if you're interested: http://nrg.cs.ucl.ac.uk/mjh/tmp/e2etun.pdf Anyway, this sort of edge-to-edge tunnelling doesn't require any end-host changes, but does permit multiple routing names (in this case, the decapsulator addresses) for each end-host IP address, and it should be incrementally deployable. I hadn't intended it as a multi-homing architecture, but it might work OK. In any event, it's an example of an architecture that isn't quite either of the two you listed above. - Mark _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Dec 08 13:20:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GskJv-0004RJ-6x; Fri, 08 Dec 2006 13:19:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GskJu-0004NU-8m for architecture-discuss@ietf.org; Fri, 08 Dec 2006 13:19:38 -0500 Received: from smtp1.nodak.edu ([134.129.111.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GskJq-0004ED-Kp for architecture-discuss@ietf.org; Fri, 08 Dec 2006 13:19:38 -0500 Received: from [134.129.95.120] (netmender.cc.ndsu.NoDak.edu [134.129.95.120]) (authenticated bits=0) by smtp1.NoDak.edu (8.13.1/8.13.1) with ESMTP id kB8IJXYj021421 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 8 Dec 2006 12:19:34 -0600 In-Reply-To: <104001c71ad1$fb2017e0$6701a8c0@china.huawei.com> References: <71F6867B-BB26-4A7D-9480-D8189BB32DB3@ndsu.edu> <45758F59.3050308@zurich.ibm.com><8C4792D2-E5B0-4CB9-AFB7-8D9AF7E1BC62@ndsu.edu><4577CE90.1020800@zurich.ibm.com> <0A6F0E00-1CA2-49E8-A2AD-A3B5D3A1FC8B@ndsu.edu> <104001c71ad1$fb2017e0$6701a8c0@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Message-Id: <5932C19B-EB10-4D7C-A825-5B6AFDF0F4F5@ndsu.edu> From: Bruce Curtis Subject: Re: [arch-d] It's about Information Date: Fri, 8 Dec 2006 12:19:33 -0600 To: architecture-discuss@ietf.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 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="===============1254836400==" Errors-To: architecture-discuss-bounces@ietf.org --===============1254836400== Content-Type: multipart/alternative; boundary=Apple-Mail-33-463695781 --Apple-Mail-33-463695781 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Dec 8, 2006, at 8:05 AM, Spencer Dawkins wrote: > Hi, Bruce, > > ("cough") but wouldn't ingress filtering based on one address in > the set of addresses being topologically correct just encourage > source address spoofers to be more careful about the addresses they > spoof with? > > Thanks, > > Spencer Well basically address spoofers could only totally spoof the source locators that don't match the initial path the packet took from the customer to the ISP. One of the source locators would have to be correct. The additional source locators would make tracking the attack back slightly more difficult than today. The attacker could use lots of randomly chosen source locators in the packets but then after looking at a few packets it should become obvious which one never changes and is the real source locator. If the attacker chose to put for example 5 source locators in each packet and never changed them it would not be obvious which one indicated the real path the packet took from customer to ISP, but it would be limited to 5 possibilities. One method around the problem would be for ISPs to mark the packet in some way to indicate which source locator passed an anti-spoof test. Or along the lines of some other discussion in the group, if the source locators don't provide value past the customer ISP interface they could be deleted from the packet at the point they pass an anti- spoof test. > From: Bruce Curtis > > > Right but the model with all the info in the packet allows either > option, in one person's network they can let the host chose the > path and the packets flow as they may and in another person's > network they can have intelligent boxes at the customer ISP > interface to do load balancing or traffic engineering. > >> >>> Also I don't think that shim6 includes the multiple source >>> addresses in the packets which led to the complaint that >>> implementing anti-spoofing was then difficult or impossible. Or >>> that shim6 had to do extra work to put the correct source >>> address in the packet so that anti-spoofing still worked the old >>> way. But again this complaint was probably about wanting to do >>> traffic engineering for load balancing at the customer ISP >>> interface also. >> >> Well, the tricky issue for shim6 is exit router selection - if >> ingress >> filtering or RPF checks are in place, sending a packet via the wrong >> exit router is catastrophic. > > Right, but if all of the address info was in the packet we could > envision an RPF check that succeeds as long as only one of the > multiple source addresses was correct. Also it would be easier for > the ISP to implement the RPF check if they chose to, they wouldn't > need to know the customers other possible locators, they would only > have to check the list of source addresses to see if one of them > matched that ISPs address range. > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss --- Bruce Curtis bruce.curtis@ndsu.edu Certified NetAnalyst II 701-231-8527 North Dakota State University --Apple-Mail-33-463695781 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Dec 8, 2006, at = 8:05 AM, Spencer Dawkins wrote:

=
Hi, Bruce,
=A0
("cough") but wouldn't ingress filtering based on one address = in the set of addresses being topologically correct=A0just = encourage=A0source address spoofers to be more careful about the = addresses they spoof with?
=A0
Thanks,
=A0
Spencer

=A0 Well basically address = spoofers could only totally spoof the source locators that don't match = the initial path the=A0 packet took from the customer to the ISP.=A0 One = of the source locators would have to be correct.

=A0 =A0The additional = source locators would make tracking the attack back slightly more = difficult than today.=A0 The attacker could use lots of randomly chosen = source locators in the packets=A0 but then after looking at a few = packets it should become obvious which one never changes and is the real = source locator.=A0 If the attacker chose to put for example 5 source = locators in each packet and never changed them it would not be obvious = which one indicated the real path the packet took from customer to ISP, = but it would be limited to 5 possibilities.=A0 One method around the = problem would be for ISPs to mark the packet in some way to indicate = which source locator passed an anti-spoof test.

=A0 =A0Or along the lines = of some other discussion in the group, if the source locators don't = provide value past the customer ISP interface they could be deleted from = the packet at the point they pass an anti-spoof = test.


=A0
=
=A0 Right but the model with all the info in the packet allows = either option, in one person's network they can let the host chose the = path and the packets flow as they may and in another person's network = they can have intelligent boxes at the customer ISP interface to do = load balancing or traffic engineering.


=A0 Also I don't = think that shim6 includes the multiple source=A0 addresses in the packets = which led to the complaint that implementing=A0 anti-spoofing was then = difficult or impossible.=A0 = Or that shim6 had to=A0= do extra work to put the correct source address in the = packet so that=A0 = anti-spoofing still worked the old way.=A0 But again this = complaint was=A0 probably = about wanting to do traffic engineering for load balancing=A0 at the customer ISP interface = also.

Well, the tricky = issue for shim6 is exit router selection - if ingress
filtering or RPF checks are in place, sending a = packet via the wrong
exit router is = catastrophic.

=A0 Right, but if all of = the address info was in the packet we could envision an RPF check that = succeeds as long as only one of the multiple source addresses was = correct.=A0 Also it would be easier for the ISP to implement the RPF = check if they chose to, they wouldn't need to know the customers other = possible locators, they would only have to check the list of source = addresses to see if one of them matched that ISPs address = range.
Architecture-discuss mailing list
=


---

Bruce Curtis =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 bruce.curtis@ndsu.edu

=

Certified NetAnalyst II=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 701-231-8527

North Dakota State = University =A0 =A0 =A0 =A0

=

= --Apple-Mail-33-463695781-- --===============1254836400== 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 --===============1254836400==-- From architecture-discuss-bounces@ietf.org Fri Dec 08 14:06:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsl2B-0004Wr-8V; Fri, 08 Dec 2006 14:05:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsl2A-0004Wh-3u for architecture-discuss@ietf.org; Fri, 08 Dec 2006 14:05:22 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gsl28-0001UH-FF for architecture-discuss@ietf.org; Fri, 08 Dec 2006 14:05:22 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 39D191110FB; Fri, 8 Dec 2006 20:05:19 +0100 (CET) Received: from [163.117.203.209] (unknown [163.117.203.209]) by smtp01.uc3m.es (Postfix) with ESMTP id EC31811109E; Fri, 8 Dec 2006 20:05:18 +0100 (CET) In-Reply-To: <20061208165449.0CD0C86ADB@mercury.lcs.mit.edu> References: <20061208165449.0CD0C86ADB@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <9b16c35b67d026b6c2a0165e82c97b57@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [arch-d] Major practical decision Date: Fri, 8 Dec 2006 20:05:20 +0100 To: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Hi Noel, El 08/12/2006, a las 17:54, Noel Chiappa escribi=F3: > So, this high-level conversation has been interesting and educational,=20= > but > I'd like to ask a more "brass-tacks" question. In doing so, I'm=20 > basically > recognizing that while it's nice to theorize with a blank sheet of=20 > paper, > when it comes to specifying bits you have practical constraints. > > > I get the sense that it is now generally accepted that widespread > multi-homing has to be handled by use of multiple routing-names, and > identity/location separation. > > However, it's not clear to me that a new end-end naming layer (e.g.=20 > SHIM6 or > HIP) is really a viable solution, because of the amount of legacy=20 > equipment > out there. (And a top of the hatly hat to David Conrad for first=20 > raising this > issue.) I.e. if your site is multi-homed, and you've deployed=20 > HIP/whatever, > that's not much use if many of the people trying to talk to you=20 > haven't. > yes, these approaches need that the peer supports the protocol (either=20= the end node itself or some form or proxy) > David's contention was that because of this we may be forced to=20 > convert the > current IPvN addresses into end-end names, "jack up" the internetwork=20= > layer, > and insert a new layer underneath, and deploy some sort of mapping=20 > system to > map from IPvN "addresses" to some new routing-name namespace. > > I think that's a really good argument - that this is the only solution=20= > that's > viable in a short time-frame. However, I'm very interested to hear = what > everyone else thinks on this point. i am not following what kind of approach could provide multihoming support (preserving=20 established communications) without requiring support from both peers=20 of the communications? (by peers i mean either the end nodes themselves=20= or devices on the edge next to each peer that perform the multihoming=20 functions for them) If we do actually manage to define a solution that _only_ requires=20 modifications to the multihomed site and does not requires=20 modifications to the peers that it is communicating with (nor the the=20 network outside the multihomed site) this would be indeed a really nice=20= feature, because only those who actually get the multihoming benefits=20 have to pay the costs of supporting the multihoming support tools,=20 which is very nice, but i am not sure i have ever seen a proposal that=20= does this.... could you expand? regards, marcelo > > (I note that it's always better to deploy something designed to a=20 > purpose, and > it would be better to name end-end entities out of a new namespace=20 > designed > for that purpose, but alas, we may be stuck.) > > > I ask this because jack-up assumes a new routing-name namespace, which=20= > has > implications for the routing: it immediately lands us with what seems=20= > to me, > after a moderate look, to be a fairly hard problem in that part of the=20= > system > - although one more soluble than routing PI addresses, before anyone=20= > says > anything! > > So, what's it to be: jack-up (i.e. insertion of a new internetworking=20= > layer), > or new end-end names (i.e. insertion of a new end-end naming layer)? > > Noel > > _______________________________________________ > 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 Dec 08 14:09:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsl5g-0006hC-1U; Fri, 08 Dec 2006 14:09:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsl5e-0006gt-Mz for architecture-discuss@ietf.org; Fri, 08 Dec 2006 14:08:58 -0500 Received: from smtp1.nodak.edu ([134.129.111.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gsl5e-0001ur-1A for architecture-discuss@ietf.org; Fri, 08 Dec 2006 14:08:58 -0500 Received: from [134.129.95.120] (netmender.cc.ndsu.NoDak.edu [134.129.95.120]) (authenticated bits=0) by smtp1.NoDak.edu (8.13.1/8.13.1) with ESMTP id kB8J8vv2027940 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 8 Dec 2006 13:08:57 -0600 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <20061208162023.C08BE86ADB@mercury.lcs.mit.edu> References: <20061208162023.C08BE86ADB@mercury.lcs.mit.edu> Message-Id: <5FA17976-E248-4AC8-A34B-A87AF66F5E9B@ndsu.edu> From: Bruce Curtis Subject: Re: [arch-d] It's about Information Date: Fri, 8 Dec 2006 13:08:56 -0600 To: architecture-discuss@ietf.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 2d133cc328f58695161c98bb4f4dc213 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="===============0895840052==" Errors-To: architecture-discuss-bounces@ietf.org --===============0895840052== Content-Type: multipart/alternative; boundary=Apple-Mail-34-466658908 --Apple-Mail-34-466658908 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Dec 8, 2006, at 10:20 AM, Noel Chiappa wrote: >> That is, we put all of the destination addresses X,Y,Z in the >> packet as >> well as the source addresses A,B,C. So basically we take the >> information about multiple paths > > Minor nit: even if you only have one address on each each end, you > can still > have multiple paths. True. I'm guilty of thinking of this model in terms of the multi-homing issue because that's the problem that led me to think of the model. And one of the issues was that ISPs objected to some proposals because they could not do traffic engineering in the way they can with the old model. If I restate the old model end users have control over the path packets take in the first hop when leaving their site and can influence which path packets enter their network on the last hop. ISPs generally have control over the paths within each ISP network and between ISPs that the packet takes. It is a bit more complicated than that but that seems to be the most common case. > This point is one I particularly notice because people try and > specify paths > using addresses (which is not what's happening here, I know), and > it really > doesn't work well. If you want to control paths, control them > directly, don't > try and do it indirectly via addresses. And with a new model with multiple locators per site people will be even more tempted to use locators to specify paths. In essence one of the big issues is about control, that is, who controls the path the packet takes. The ISPs have a stake but end users also might have preferences. If the new architecture gives end users a way to specify the full path I could see ISPs requesting features in the packet such as a "Allow the ISP to change the requested path" bit. >> out of the routing tables where it doesn't scale and put the multiple >> path info in each packet > > What's happening with the multiple addresses is that you're taking > some of > the cost of supporting multihoming and moving it out of the > routing, and > moving it elsewhere in the system. Right. > [And from a different message...] > > >> I know there have been proposals about having the addresses or >> locators >> based on location or GPS and it solved some routing problems .. >> .. I was thinking of the GPS info as more of an ID than a locator. >> Sometimes when there is a problem host it would be nice to have it's >> location info, but there are privacy issues .. as well. > > Yup. > >> But one way to use the same model but turn my thinking on it's >> head is >> to consider the GPS info as the primary locator and the other >> multiple >> locators as ISP specific locators. > > Umm, I'm going to call you on your terminology here. We have mostly > been using > "locator" to mean "a name that tells you were you are in the > network". Your > geographical location tells you nothing about your connectivity to the > network, or the relationship in the network connectivity (aka > "topology") to > any entity you might want to exchange packets. So, I object to > calling (or > thinking of) any GPS-derived name a "locator". > > Noel I admit to having not looked at it for a while but there were proposals to lay out IPv6 addresses geographically and in that proposal IPv6 addresses have geographical hierarchy which kind of led me down the path of using the wrong terminology. If I think "network locator" rather than the the short hand "locator" I can see your point. Sorry about that. I haven't thought through the particular example above but it occurred to me while responding to another post on the list so I threw it out there for other folks more knowledgeable about ISP issues to comment on. I guess what I was trying to imagine was if having multiple locators plus the GPS info in the packet would allow us to think of a model where the GPS info really is sort of a locator not on the real network but on a virtual or logical network. Just trying to think of a model that would have some of the advantages of a logical network with geographically hierarchy but that really ran on a network based on locators that reflect the real network topology. One thing that comes to mind is that if the GPS info about the source is in the packet then perhaps that could be used for anti- spoofing checking rather than the source locator. --- Bruce Curtis bruce.curtis@ndsu.edu Certified NetAnalyst II 701-231-8527 North Dakota State University --Apple-Mail-34-466658908 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Dec 8, 2006, at = 10:20 AM, Noel Chiappa wrote:

That is, we put all of the = destination addresses X,Y,Z in the packet as
well as the source addresses A,B,C. So basically we = take the
information about multiple = paths
Minor nit: even if you only have = one address on each each end, you can still
have = multiple paths.

=A0 =A0True.=A0 I'm guilty of = thinking of this model in terms=A0 of the multi-homing issue because = that's the problem that led me to think of the model.=A0 And one of the = issues was that ISPs objected to some proposals because they could not = do traffic engineering in the way they can with the old = model.

=A0 = =A0If I restate the old model end users have control over the path = packets take in the first hop when leaving their site and can influence = which path packets enter their network on the last hop.=A0 ISPs = generally have control over the paths within each ISP network and = between ISPs that the packet takes.

=A0 It is a bit more = complicated than that but that seems to be the most common = case.

This = point is one I particularly notice because people try and specify = paths
using addresses (which is not = what's happening here, I know), and it really
doesn't work well. If you want to control paths, = control them directly, don't
try and do it = indirectly via addresses.

=A0 And with a new model = with multiple locators per site people will be even more tempted to use = locators to specify paths.

=A0 In essence one of the big = issues is about control, that is, who controls the path the packet = takes.=A0 The ISPs have a stake but end users also might have = preferences. =A0 =A0

=A0 If the new architecture = gives end users a way to specify the full path I could see ISPs = requesting features in the packet such as a "Allow the ISP to change the = requested path" bit.


out of the = routing tables where it doesn't scale and put the multiple
path info in each packet

What's = happening with the multiple addresses is that you're taking some = of
the cost of supporting multihoming and moving = it out of the routing, and
moving it = elsewhere in the system.

=A0 = Right.

[And = from a different message...]


=
I know there have been = proposals about having the addresses or locators
based on location or GPS and it solved some routing = problems ..
.. I was thinking of the GPS = info as more of an ID than a locator.
location info, but there are = privacy issues .. as well.


=
But one way to use the same = model but turn my thinking on it's head is
to = consider the GPS info as the primary locator and the other = multiple
locators as ISP specific = locators.

Umm, I'm going to call you on = your terminology here. We have mostly been using
"locator" to mean "a name that tells you were you = are in the network".=A0 = Your
geographical location tells you = nothing about your connectivity to the
network, = or the relationship in the network connectivity (aka "topology") = to
any entity you might want to exchange packets. = So, I object to calling (or
thinking of) = any GPS-derived name a "locator".

= Noel

=A0 I admit to having not looked = at it for a while but there were proposals to lay out IPv6 addresses = geographically=A0 and in that proposal IPv6 addresses have geographical = hierarchy which kind of led me down the path of using the wrong = terminology.

=A0 If = I think "network locator" rather than the the short hand "locator" I can = see your point.=A0 Sorry about that.

=A0 I haven't thought = through the particular example above but it occurred to me while = responding to another post on the list so I threw it out there for other = folks more knowledgeable about ISP issues to comment on.

=A0 I guess what I was = trying to imagine was if having multiple locators plus the GPS info in = the packet would allow us to think of a model where the GPS info really = is sort of a locator not on the real network but on a virtual or logical = network.=A0 Just trying to think of a model that would have some of the = advantages of a logical network with geographically hierarchy but that = really ran on a network based on locators that reflect the real network = topology.

=A0 = One thing that comes to mind is that if the GPS info about the source is = in the packet then perhaps that could be used for anti-spoofing checking = rather than the source locator.


---

Bruce Curtis =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 bruce.curtis@ndsu.edu

=

Certified NetAnalyst II=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 701-231-8527

North Dakota State = University =A0 =A0 =A0 =A0

=

= --Apple-Mail-34-466658908-- --===============0895840052== 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 --===============0895840052==-- From architecture-discuss-bounces@ietf.org Fri Dec 08 14:34:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GslTh-0006oC-FW; Fri, 08 Dec 2006 14:33:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GslTg-0006o7-Ct for architecture-discuss@ietf.org; Fri, 08 Dec 2006 14:33:48 -0500 Received: from smtp1.nodak.edu ([134.129.111.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GslTa-0005gp-VN for architecture-discuss@ietf.org; Fri, 08 Dec 2006 14:33:48 -0500 Received: from [134.129.95.120] (netmender.cc.ndsu.NoDak.edu [134.129.95.120]) (authenticated bits=0) by smtp1.NoDak.edu (8.13.1/8.13.1) with ESMTP id kB8JXggw031944 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 8 Dec 2006 13:33:42 -0600 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <6259c5f84a362e648b8985c03afc8356@it.uc3m.es> References: <71F6867B-BB26-4A7D-9480-D8189BB32DB3@ndsu.edu> <6259c5f84a362e648b8985c03afc8356@it.uc3m.es> Message-Id: <992FB962-1761-4B0B-861E-7F9CF1C69806@ndsu.edu> From: Bruce Curtis Subject: Re: [arch-d] It's about Information Date: Fri, 8 Dec 2006 13:33:41 -0600 To: architecture-discuss@ietf.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 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="===============0420643908==" Errors-To: architecture-discuss-bounces@ietf.org --===============0420643908== Content-Type: multipart/alternative; boundary=Apple-Mail-35-468144271 --Apple-Mail-35-468144271 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed On Dec 8, 2006, at 6:52 AM, marcelo bagnulo braun wrote: > Hi Bruce, > > El 05/12/2006, a las 0:11, Bruce Curtis escribi=F3: > >> >> >> To further understand the possibilities I realized that IPv6 did =20= >> not provide the means to include all of these addresses but IPv6 =20 >> does have a method of being extended to include such addresses, =20 >> extension headers. > > i think that a difficulty with this is that you not only need to =20 > include the alternative locator information, but also provide the =20 > means to secure the binding between the identifier and the =20 > alternative locators in order to prevent redirection attacks. This =20 > could be done adding security information in the packet itself, but =20= > this is quite much more information than just the locators. The =20 > other option would be to verify the binding from a third trusted =20 > party, but in this case, what is the point of including the =20 > alternative locator information in te first place? (you could =20 > obtain it from the third trusted party) > > Regards, marcelo > > PS: you can check http://www.watersprings.org/pub/id/draft-bagnulo-=20 > multi6-mhexthdr-00.txt if you are interested in a broken version of =20= > a similar idea that completelly missed all the security problems :-) I guess I'm also still missing the security problems with multiple =20= destination locators. Can you give an example? I do see that with multiple source locators an attacker could use =20 it's real source locator plus an additional spoofed source locator to =20= try to highjack a session. --- Bruce Curtis bruce.curtis@ndsu.edu Certified NetAnalyst II 701-231-8527 North Dakota State University --Apple-Mail-35-468144271 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Dec 8, 2006, at = 6:52 AM, marcelo bagnulo braun wrote:

Hi Bruce,

El 05/12/2006, a las 0:11, Bruce = Curtis escribi=F3:


=A0 To further understand the possibilities I = realized that IPv6 did not provide the means to include all of these = addresses but IPv6 does have a method of being extended to include such = addresses, extension headers.

i think that = a difficulty with this is that you not only need to include the = alternative locator information, but also provide the means to secure = the binding between the identifier and the alternative locators in order = to prevent redirection attacks. This could be done adding security = information in the packet itself, but this is quite much more = information than just the locators. The other option would be to verify = the binding from a third trusted party, but in this case, what is the = point of including the alternative locator information in te first = place? (you could obtain it from the third trusted party)

Regards, = marcelo

PS: you can check http://www.watersprings.org/pub/id/draft-bagnulo-multi6-mhexthdr-00= .txt if you are interested in a broken version of a similar idea = that completelly missed all the security problems :-)
=
=A0 I guess I'm also still missing the = security problems with multiple destination locators.=A0 Can you give an = example?

=A0 = I do see that with multiple source locators an attacker could use it's = real source locator plus an additional spoofed source locator to try to = highjack a session.


---

Bruce Curtis =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 bruce.curtis@ndsu.edu

=

Certified NetAnalyst II=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 701-231-8527

North Dakota State = University =A0 =A0 =A0 =A0

=

= --Apple-Mail-35-468144271-- --===============0420643908== 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 --===============0420643908==-- From architecture-discuss-bounces@ietf.org Fri Dec 08 14:53:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GslmE-0007KS-DB; Fri, 08 Dec 2006 14:52:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GslmD-0007KN-H0 for architecture-discuss@ietf.org; Fri, 08 Dec 2006 14:52:57 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GslmA-0008RM-QY for architecture-discuss@ietf.org; Fri, 08 Dec 2006 14:52:57 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id D6CD7111330; Fri, 8 Dec 2006 20:52:53 +0100 (CET) Received: from [163.117.203.209] (unknown [163.117.203.209]) by smtp01.uc3m.es (Postfix) with ESMTP id 51994111322; Fri, 8 Dec 2006 20:52:53 +0100 (CET) In-Reply-To: <992FB962-1761-4B0B-861E-7F9CF1C69806@ndsu.edu> References: <71F6867B-BB26-4A7D-9480-D8189BB32DB3@ndsu.edu> <6259c5f84a362e648b8985c03afc8356@it.uc3m.es> <992FB962-1761-4B0B-861E-7F9CF1C69806@ndsu.edu> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <2f9ec3d01667c5dda45e723a805f6437@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [arch-d] It's about Information Date: Fri, 8 Dec 2006 20:52:55 +0100 To: Bruce Curtis X-Mailer: Apple Mail (2.624) 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: , Errors-To: architecture-discuss-bounces@ietf.org El 08/12/2006, a las 20:33, Bruce Curtis escribi=F3: > > =A0 I guess I'm also still missing the security problems with multiple=20= > destination locators.=A0 Can you give an example? > see rfc 4218 for an analysis to threats in multihoming with multiple=20 addresses and see rfc4225 for an analysis of the threats in the=20 mobility environment regards, marcelo > =A0 I do see that with multiple source locators an attacker could use=20= > it's real source locator plus an additional spoofed source locator to=20= > try to highjack a session. > > > --- > Bruce Curtis =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = bruce.curtis@ndsu.edu > Certified NetAnalyst II=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 701-231-8527 > North Dakota State University =A0 =A0 > > _______________________________________________ > 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 Dec 08 15:51:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsmgO-0004A6-4A; Fri, 08 Dec 2006 15:51:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsmgL-000477-PO for architecture-discuss@ietf.org; Fri, 08 Dec 2006 15:50:57 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsmgI-0000Wg-PH for architecture-discuss@ietf.org; Fri, 08 Dec 2006 15:50:57 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 3EFE1111203; Fri, 8 Dec 2006 21:50:54 +0100 (CET) Received: from [163.117.203.209] (unknown [163.117.203.209]) by smtp01.uc3m.es (Postfix) with ESMTP id E75B11111B9; Fri, 8 Dec 2006 21:50:53 +0100 (CET) In-Reply-To: <2f9ec3d01667c5dda45e723a805f6437@it.uc3m.es> References: <71F6867B-BB26-4A7D-9480-D8189BB32DB3@ndsu.edu> <6259c5f84a362e648b8985c03afc8356@it.uc3m.es> <992FB962-1761-4B0B-861E-7F9CF1C69806@ndsu.edu> <2f9ec3d01667c5dda45e723a805f6437@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <165d43dbd9c24c4a7fd7d96148cf516d@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [arch-d] It's about Information Date: Fri, 8 Dec 2006 21:50:53 +0100 To: Bruce Curtis X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org El 08/12/2006, a las 20:52, marcelo bagnulo braun escribi=F3: > > El 08/12/2006, a las 20:33, Bruce Curtis escribi=F3: > >> >> =A0 I guess I'm also still missing the security problems with = multiple=20 >> destination locators.=A0 Can you give an example? >> > > see rfc 4218 for an analysis to threats in multihoming with multiple=20= > addresses and see rfc4225 for an analysis of the threats in the=20 > mobility environment > to be more explicit suppose that node A has multiple locators and node b is sending packets=20= to node a i think that the critical issue here is how does the node b learns (and=20= verifies) all the addresses of node a. If no proper protection is=20 provided, this can result in redirection attacks. Besides, in this case, not only node b is using the multiple locator=20 information, but also intermediate routers are using it. i am not sure=20= how much verification need to make these other parties (routers) that=20 are acutally using the multiple address informtion in order not to=20 introduce new vulnerabilities. I don't think that the threats are so=20 big as in the case of the actual peer of the communication (node b in=20 this case) though regards, marcelo > regards, marcelo > > >> =A0 I do see that with multiple source locators an attacker could use=20= >> it's real source locator plus an additional spoofed source locator to=20= >> try to highjack a session. >> >> >> --- >> Bruce Curtis =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = bruce.curtis@ndsu.edu >> Certified NetAnalyst II=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 701-231-8527 >> North Dakota State University =A0 =A0 >> >> _______________________________________________ >> 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 > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Dec 08 23:46:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsu4M-0007he-MF; Fri, 08 Dec 2006 23:44:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsu4K-0007hZ-SN for architecture-discuss@ietf.org; Fri, 08 Dec 2006 23:44:12 -0500 Received: from sccrmhc14.comcast.net ([63.240.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gsu4J-0004oD-Md for architecture-discuss@ietf.org; Fri, 08 Dec 2006 23:44:12 -0500 Received: from [192.168.0.101] (c-24-6-155-154.hsd1.ca.comcast.net[24.6.155.154]) by comcast.net (sccrmhc14) with SMTP id <2006120904440501400q2q87e>; Sat, 9 Dec 2006 04:44:11 +0000 In-Reply-To: <20061208165449.0CD0C86ADB@mercury.lcs.mit.edu> References: <20061208165449.0CD0C86ADB@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <04266164-ABE2-4FDE-B9CF-947D1CC457A0@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [arch-d] Major practical decision Date: Fri, 8 Dec 2006 20:44:21 -0800 To: Noel Chiappa X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > So, what's it to be: jack-up (i.e. insertion of a new > internetworking layer), > or new end-end names (i.e. insertion of a new end-end naming layer)? My $.02: We're supposed to be architecting a fix for the Internet that should last for the foreseeable future. Not just the next 10 or 20 years, but the next 100 or so. The jack-up model is somewhat less clean and inevitably introduces suboptimalities at the interface between the layers. Thus, I'm in favor of replacing the namespace. Regards, Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Dec 09 03:42:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsxk5-0003xd-Nw; Sat, 09 Dec 2006 03:39:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsxk4-0003xY-CB for architecture-discuss@ietf.org; Sat, 09 Dec 2006 03:39:32 -0500 Received: from imo-d23.mx.aol.com ([205.188.139.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gsxk2-0003Hq-3c for architecture-discuss@ietf.org; Sat, 09 Dec 2006 03:39:32 -0500 Received: from HeinerHummel@aol.com by imo-d23.mx.aol.com (mail_out_v38_r7.6.) id i.d25.1f20ac8 (30737); Sat, 9 Dec 2006 03:39:23 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Sat, 9 Dec 2006 03:39:21 EST Subject: Re: [arch-d] Major practical decision To: tony.li@tony.li, jnc@mercury.lcs.mit.edu MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5009 X-Spam-Flag: NO X-Spam-Score: 0.3 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 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="===============1568555910==" Errors-To: architecture-discuss-bounces@ietf.org --===============1568555910== Content-Type: multipart/alternative; boundary="-----------------------------1165653561" -------------------------------1165653561 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 There is no alternative to hierarchical routing and also: there is no need =20 for flat routing. Heiner Why should a router in Europe be informed if some router (not bike) tips =20 over in China?! =20 =20 =20 In einer eMail vom 09.12.2006 05:47:09 Westeurop=E4ische Normalzeit schreibt= =20 tony.li@tony.li: > So, what's it to be: jack-up (i.e. insertion of a new =20 > internetworking layer), > or new end-end names (i.e. insertion of a new end-end naming layer)? My $.02: We're supposed to be architecting a fix for the Internet that should =20 last for the foreseeable future. Not just the next 10 or 20 years, =20 but the next 100 or so. The jack-up model is somewhat less clean and =20 inevitably introduces suboptimalities at the interface between the =20 layers. Thus, I'm in favor of replacing the namespace. Regards, Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss -------------------------------1165653561 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
There is no alternative to hierarchical routing and also: there is no n= eed=20 for flat routing.
Heiner
Why should a router in Europe be informed if some router (not bike) tip= s=20 over in China?!
 
 
 
In einer eMail vom 09.12.2006 05:47:09 Westeurop=E4ische Normalzeit sch= reibt=20 tony.li@tony.li:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>> So,=20 what's it to be: jack-up (i.e. insertion of a new 
>=20 internetworking layer),
> or new end-end names (i.e. insertion of a=20= new=20 end-end naming layer)?


My $.02:

We're supposed to be=20 architecting a fix for the Internet that should 
last for the=20 foreseeable future.  Not just the next 10 or 20 years, 
but=20= the=20 next 100 or so.  The jack-up model is somewhat less clean and =20
inevitably introduces suboptimalities at the interface between the&nbs= p;=20
layers.  Thus, I'm in favor of replacing the=20 namespace.

Regards,
Tony


____________________________= ___________________
Architecture-discuss=20 mailing=20 list
Architecture-discuss@ietf.org
https://www1.ietf.org/mailman/lis= tinfo/architecture-discuss
 
-------------------------------1165653561-- --===============1568555910== 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 --===============1568555910==-- From architecture-discuss-bounces@ietf.org Sat Dec 09 06:33:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gt0Pa-0001tE-Gw; Sat, 09 Dec 2006 06:30:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gt0PZ-0001t8-Kd for architecture-discuss@ietf.org; Sat, 09 Dec 2006 06:30:33 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gt0PS-0008OO-Gw for architecture-discuss@ietf.org; Sat, 09 Dec 2006 06:30:33 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id BE74434027; Sat, 9 Dec 2006 06:30:27 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 9 Dec 2006 06:30:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Major practical decision Date: Sat, 9 Dec 2006 06:30:24 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC010F2A0C@tayexc14.americas.cpqcorp.net> In-Reply-To: <20061208165449.0CD0C86ADB@mercury.lcs.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Major practical decision Thread-Index: Acca6bzm6zOSDIUiQF6HAo3CgMt0EAAmuXMg From: "Bound, Jim" To: "Noel Chiappa" , X-OriginalArrivalTime: 09 Dec 2006 11:30:25.0931 (UTC) FILETIME=[6BF72DB0:01C71B85] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > I get the sense that it is now generally accepted that=20 > widespread multi-homing has to be handled by use of multiple=20 > routing-names, and identity/location separation. We need to crisply define and obtain consensus on Routing-Names. >=20 > However, it's not clear to me that a new end-end naming layer=20 > (e.g. SHIM6 or > HIP) is really a viable solution, because of the amount of=20 > legacy equipment out there. (And a top of the hatly hat to=20 > David Conrad for first raising this > issue.) I.e. if your site is multi-homed, and you've deployed=20 > HIP/whatever, that's not much use if many of the people=20 > trying to talk to you haven't. This is a deployment issue yes but not an insurmountable one the industry is capable of adapting such as the application move today to SOA. But, more importantly at this point in the architecture discussion I believe it must remain on the table as a viable option. >=20 > David's contention was that because of this we may be forced=20 > to convert the current IPvN addresses into end-end names,=20 > "jack up" the internetwork layer, and insert a new layer=20 > underneath, and deploy some sort of mapping system to map=20 > from IPvN "addresses" to some new routing-name namespace. These are three efforts that can happen regarding our work to define an architecture in parallel, I don't see that as a problem. >=20 > I think that's a really good argument - that this is the only=20 > solution that's viable in a short time-frame. However, I'm=20 > very interested to hear what everyone else thinks on this point. I think we must define short and long term before one can answer this question. >=20 > (I note that it's always better to deploy something designed=20 > to a purpose, and it would be better to name end-end entities=20 > out of a new namespace designed for that purpose, but alas,=20 > we may be stuck.) This is my view currently we should move to a new namespace for end-to-end entities. >=20 >=20 > I ask this because jack-up assumes a new routing-name=20 > namespace, which has implications for the routing: it=20 > immediately lands us with what seems to me, after a moderate=20 > look, to be a fairly hard problem in that part of the system > - although one more soluble than routing PI addresses, before=20 > anyone says anything! >=20 > So, what's it to be: jack-up (i.e. insertion of a new=20 > internetworking layer), or new end-end names (i.e. insertion=20 > of a new end-end naming layer)? I think for now we have to pursue these multiple paths. /jim >=20 > Noel >=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 Sat Dec 09 06:36:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gt0VF-0002qc-Oh; Sat, 09 Dec 2006 06:36:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gt0VE-0002qX-RF for architecture-discuss@ietf.org; Sat, 09 Dec 2006 06:36:24 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gt0V9-0000kj-DN for architecture-discuss@ietf.org; Sat, 09 Dec 2006 06:36:24 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 852F3340EC; Sat, 9 Dec 2006 06:36:19 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 9 Dec 2006 06:36:18 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Major practical decision Date: Sat, 9 Dec 2006 06:36:17 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC010F2A0D@tayexc14.americas.cpqcorp.net> In-Reply-To: <04266164-ABE2-4FDE-B9CF-947D1CC457A0@tony.li> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Major practical decision Thread-Index: AccbTQhjstVAPBqzQnaQh7mdIliu3AAOPSYw From: "Bound, Jim" To: "Tony Li" , "Noel Chiappa" X-OriginalArrivalTime: 09 Dec 2006 11:36:18.0940 (UTC) FILETIME=[3E6013C0:01C71B86] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I don't think we can develop a solution that will last 100 years. 30 years maybe. I beleive something else will break the system that has nothing to do with the namespace decision or IP layer. This is not to say we should not replace the namespace but to attempt to provide an architecture that can be implemented by engineers that lasts 100 years seems a bit impossible to me. /jim=20 > -----Original Message----- > From: Tony Li [mailto:tony.li@tony.li]=20 > Sent: Friday, December 08, 2006 11:44 PM > To: Noel Chiappa > Cc: architecture-discuss@ietf.org > Subject: Re: [arch-d] Major practical decision >=20 >=20 > > So, what's it to be: jack-up (i.e. insertion of a new=20 > internetworking=20 > > layer), or new end-end names (i.e. insertion of a new=20 > end-end naming=20 > > layer)? >=20 >=20 > My $.02: >=20 > We're supposed to be architecting a fix for the Internet that=20 > should last for the foreseeable future. Not just the next 10=20 > or 20 years, but the next 100 or so. The jack-up model is=20 > somewhat less clean and inevitably introduces suboptimalities=20 > at the interface between the layers. Thus, I'm in favor of=20 > replacing the namespace. >=20 > Regards, > Tony >=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 Sat Dec 09 06:37:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gt0W7-0002zV-LO; Sat, 09 Dec 2006 06:37:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gt0W6-0002zP-50 for architecture-discuss@ietf.org; Sat, 09 Dec 2006 06:37:18 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gt0Vz-00012z-8Q for architecture-discuss@ietf.org; Sat, 09 Dec 2006 06:37:18 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 225DA34148; Sat, 9 Dec 2006 06:37:11 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 9 Dec 2006 06:37:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [arch-d] Major practical decision Date: Sat, 9 Dec 2006 06:37:09 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC010F2A0E@tayexc14.americas.cpqcorp.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Major practical decision Thread-Index: Accbbg7a8K1av9QdR6q9/YHYS+cERwAGDeVg From: "Bound, Jim" To: , , X-OriginalArrivalTime: 09 Dec 2006 11:37:10.0490 (UTC) FILETIME=[5D19FBA0:01C71B86] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c 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="===============0662024000==" Errors-To: architecture-discuss-bounces@ietf.org This is a multi-part message in MIME format. --===============0662024000== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C71B86.5CBB9900" This is a multi-part message in MIME format. ------_=_NextPart_001_01C71B86.5CBB9900 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Interesting is anyone proposing an alternative to hierarchical routing = if so I would like to hear that logic? /jim ________________________________ From: HeinerHummel@aol.com [mailto:HeinerHummel@aol.com]=20 Sent: Saturday, December 09, 2006 3:39 AM To: tony.li@tony.li; jnc@mercury.lcs.mit.edu Cc: architecture-discuss@ietf.org Subject: Re: [arch-d] Major practical decision =09 =09 =09 There is no alternative to hierarchical routing and also: there is no = need for flat routing. Heiner Why should a router in Europe be informed if some router (not bike) = tips over in China?! =20 =20 =20 In einer eMail vom 09.12.2006 05:47:09 Westeurop=E4ische Normalzeit = schreibt tony.li@tony.li: > So, what's it to be: jack-up (i.e. insertion of a new =20 > internetworking layer), > or new end-end names (i.e. insertion of a new end-end naming layer)? =09 =09 My $.02: =09 We're supposed to be architecting a fix for the Internet that should =20 last for the foreseeable future. Not just the next 10 or 20 years, =20 but the next 100 or so. The jack-up model is somewhat less clean and = inevitably introduces suboptimalities at the interface between the =20 layers. Thus, I'm in favor of replacing the namespace. =09 Regards, Tony =09 =09 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss =09 =20 ------_=_NextPart_001_01C71B86.5CBB9900 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Interesting = is anyone=20 proposing an alternative to hierarchical routing if so I would like to = hear that=20 logic?
/jim

From: HeinerHummel@aol.com=20 [mailto:HeinerHummel@aol.com]
Sent: Saturday, December 09, = 2006=20 3:39 AM
To: tony.li@tony.li; = jnc@mercury.lcs.mit.edu
Cc:=20 architecture-discuss@ietf.org
Subject: Re: [arch-d] Major = practical=20 decision

There is no alternative to hierarchical routing and also: there = is no=20 need for flat routing.
Heiner
Why should a router in Europe be informed if some router (not = bike) tips=20 over in China?!
 
 
 
In einer eMail vom 09.12.2006 05:47:09 Westeurop=E4ische = Normalzeit=20 schreibt tony.li@tony.li:
> So, what's = it to be:=20 jack-up (i.e. insertion of a new 
> internetworking=20 layer),
> or new end-end names (i.e. insertion of a new = end-end naming=20 layer)?


My $.02:

We're supposed to be architecting = a fix=20 for the Internet that should 
last for the foreseeable=20 future.  Not just the next 10 or 20 years, 
but the = next 100=20 or so.  The jack-up model is somewhat less clean and =20
inevitably introduces suboptimalities at the interface between = the =20
layers.  Thus, I'm in favor of replacing the=20 = namespace.

Regards,
Tony


___________________________= ____________________
Architecture-discuss=20 mailing=20 = list
Architecture-discuss@ietf.org
https://www1.ietf.org/mailman/li= stinfo/architecture-discuss
 
------_=_NextPart_001_01C71B86.5CBB9900-- --===============0662024000== 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 --===============0662024000==-- From architecture-discuss-bounces@ietf.org Sat Dec 09 07:44:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gt1Wy-0004s5-3I; Sat, 09 Dec 2006 07:42:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gt1Wx-0004s0-5Z for architecture-discuss@ietf.org; Sat, 09 Dec 2006 07:42:15 -0500 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gt1Wv-0005sF-Sr for architecture-discuss@ietf.org; Sat, 09 Dec 2006 07:42:15 -0500 Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 5848745; Sat, 09 Dec 2006 07:42:13 -0500 In-Reply-To: <816DD9299957E547B5D758D7F977D6DC010F2A0D@tayexc14.americas.cpqcorp.net> References: <816DD9299957E547B5D758D7F977D6DC010F2A0D@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <06AA60AE-0B22-43A3-BB81-38B4ABE453F2@multicasttech.com> Content-Transfer-Encoding: 7bit From: Marshall Eubanks Subject: Re: [arch-d] Major practical decision Date: Sat, 9 Dec 2006 07:42:11 -0500 To: "Bound, Jim" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: Noel Chiappa , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On Dec 9, 2006, at 6:36 AM, Bound, Jim wrote: > I don't think we can develop a solution that will last 100 years. 30 > years maybe. I beleive something else will break the system that has > nothing to do with the namespace decision or IP layer. This is not to > say we should not replace the namespace but to attempt to provide an > architecture that can be implemented by engineers that lasts 100 years > seems a bit impossible to me. I see extra-terrestrial routing in all seriousness as a major issue for the next 100 years (maybe not the next 20 years, but certainly the next 100). Adopting the 100 year rule would imply that there should be a DTN component to the current work, and also probably that we should worry about relativistic synchronization effects, which seems to be a little premature. I am sure that others can come up with likely or possible new issues with a 100 year time horizon. While it might be interesting to enumerate them, I am not sure it would be fruitful to incorporate them in the current work. Regards Marshall > > /jim > >> -----Original Message----- >> From: Tony Li [mailto:tony.li@tony.li] >> Sent: Friday, December 08, 2006 11:44 PM >> To: Noel Chiappa >> Cc: architecture-discuss@ietf.org >> Subject: Re: [arch-d] Major practical decision >> >> >>> So, what's it to be: jack-up (i.e. insertion of a new >> internetworking >>> layer), or new end-end names (i.e. insertion of a new >> end-end naming >>> layer)? >> >> >> My $.02: >> >> We're supposed to be architecting a fix for the Internet that >> should last for the foreseeable future. Not just the next 10 >> or 20 years, but the next 100 or so. The jack-up model is >> somewhat less clean and inevitably introduces suboptimalities >> at the interface between the layers. Thus, I'm in favor of >> replacing the namespace. >> >> Regards, >> 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 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Dec 09 08:59:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gt2i2-0004Ad-SV; Sat, 09 Dec 2006 08:57:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gt2i1-0004AY-B4 for architecture-discuss@ietf.org; Sat, 09 Dec 2006 08:57:45 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gt2hz-0007I9-Qu for architecture-discuss@ietf.org; Sat, 09 Dec 2006 08:57:45 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 1F2B8213126; Sat, 9 Dec 2006 15:57:40 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id BC4B0213119; Sat, 9 Dec 2006 15:57:39 +0200 (EET) In-Reply-To: <84a612dd0612081002r75d4914apa2aaad6c449f0832@mail.gmail.com> References: <20061208165449.0CD0C86ADB@mercury.lcs.mit.edu> <84a612dd0612081002r75d4914apa2aaad6c449f0832@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [arch-d] Major practical decision Date: Sat, 9 Dec 2006 15:57:37 +0200 To: Mark Handley X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Noel Chiappa , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Mark, On 12/8/06, Noel Chiappa wrote: >> So, what's it to be: jack-up (i.e. insertion of a new >> internetworking layer), or new end-end names (i.e. insertion of a >> new end-end naming layer)? On 8 Dec 2006, at 20:02, Mark Handley wrote: > I'm not sure these are the only possibilities. > > We've been playing with the idea of using edge-to-edge tunnelling > to construct an infrastructure for defending against DDoS > attacks. ... > > Anyway, this sort of edge-to-edge tunnelling doesn't require any > end-host changes, but does permit multiple routing names (in this > case, the decapsulator addresses) for each end-host IP address, and > it should be incrementally deployable. I hadn't intended it as a > multi-homing architecture, but it might work OK. > > In any event, it's an example of an architecture that isn't quite > either of the two you listed above. Hmm. I'm not that sure. What you seem to suggest looks like another, more implementation related dimension to me. Basically, what I understand Noel saying is that we either must add a layer above the current IP layer or one below it. This can be, of course, be implemented at various points in the network: at end- hosts, at edge routers, somewhere at the first ISP closest to the end site, or in the core. Or some combination of those. To me, that looks like another, basically orthogonal dimension, which is more implementation related than where-in-the-stack to insert the new layer. For example, I could imagine a solution that would be initially implemented in many laptops, in big boxes used by many major corporations, and by some advanced ISPs, and then gradually, over a longer term, by all hosts. Hence, what you seem to propose looks like an implementation strategy to me. Related to your paper, I think that in the long term an architecture that allows keeping the routing names (locators) as relative secrets provides some pretty effective protection against DDoS. Furthermore, if you use overlay routing instead of resolution to initially map the location-independent identifiers into locators, you can allow the responding (server) host or site to make the decision whether to reveal its locators to the initiator (client). [That's the approach we proposed to be used in Host Identity Indirection Infrastructure (Hi3).] --Pekka Nikander _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Dec 09 09:19:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gt32p-000278-OJ; Sat, 09 Dec 2006 09:19:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gt32o-00026x-SP for architecture-discuss@ietf.org; Sat, 09 Dec 2006 09:19:14 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gt32n-0003Pl-Cm for architecture-discuss@ietf.org; Sat, 09 Dec 2006 09:19:14 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 7D6C5213126; Sat, 9 Dec 2006 16:19:12 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 240A9213119; Sat, 9 Dec 2006 16:19:12 +0200 (EET) In-Reply-To: <20061208165449.0CD0C86ADB@mercury.lcs.mit.edu> References: <20061208165449.0CD0C86ADB@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [arch-d] Major practical decision Date: Sat, 9 Dec 2006 16:19:09 +0200 To: Noel Chiappa X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org On 8 Dec 2006, at 18:54, Noel Chiappa wrote: > However, it's not clear to me that a new end-end naming layer (e.g. > SHIM6 or > HIP) is really a viable solution, because of the amount of legacy > equipment > out there. (And a top of the hatly hat to David Conrad for first > raising this > issue.) I.e. if your site is multi-homed, and you've deployed HIP/ > whatever, > that's not much use if many of the people trying to talk to you > haven't. What I think we need is a gradual, proxy based solution approach, as alleged e.g. by Marcelo Bagnulo. Let's consider briefly what's behind that proposal. When deploying a new naming layer, we will have four kinds of situations: legacy- legacy, new-new, legacy-new and new-legacy. Legacy-legacy and new- new are, in general, not very interesting from an architectural point of view, even though there will be numerous engineering and security concerns there. This leads to the following straw man analysis: A. Legacy (site/host) connecting to a new (site/host) A.a New (site/host) still providing legacy connectivity by publishing a legacy address This is provided by both HIP and SHIM6, with the difference that SHIM6 is oblivious whether the peer supports SHIM6 when the initial connection is made. With HIP, the choice must be currently made during initial contact, but there's been discussions about delayed HIP state set-up. A.b New (site/host) being reachable only with the new connectivity (no published legacy address) A.b.a New identifiers being routable in the legacy system This is the interesting case, IMHO. If the new identifiers can be embedded into the legacy addressing system (e.g. as suggested in draft-laganier-ipv6-khi-05.txt), it may be possible to make them routable. For example, the prefix could be routed to one or a few sites in the core network, providing a service that would encapsulate the legacy traffic (along a similar way Mark Handley et al suggested in their e2efa paper) and provide connectivity to the new "world". Any site adopting the new system could then, independently, provide the same encapsulation service locally, for those hosts that don't implement it natively. A.b.b New identifiers not routable in the legacy system This seems to lead to a situation where the legacy hosts are not able to communicate with new systems that do not provide legacy connectivity. This may be a desirable end state, providing the remaining legacy sites an incentive to upgrade. B. New (site/host) connecting to a legacy (site/host) B.a New (site/host) being able to directly connect with to legacy addresses Again, this is provided by both HIP and SHIM6. B.b New (site/host) not being able to directly connect with legacy systems B.b.a "Reverse" proxy service Under certain not-so-simple circumstances we could imagine a proxy service that would provide any interested legacy systems a "presence" in the new system. That is, any legacy host/site could register with the proxy service, the proxy service would allocate it an ID in the new system, and allow new sites/hosts connect to the legacy one through it. I'm sure there are options I'm not listing above, but I must go now. --Pekka Nikander _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Dec 09 10:58:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gt4ZI-0007NK-RZ; Sat, 09 Dec 2006 10:56:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gt4ZG-0007N9-Vj for architecture-discuss@ietf.org; Sat, 09 Dec 2006 10:56:50 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gt4ZF-00059t-NP for architecture-discuss@ietf.org; Sat, 09 Dec 2006 10:56:50 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 4299286AE6; Sat, 9 Dec 2006 10:56:47 -0500 (EST) To: architecture-discuss@ietf.org Subject: Re: [arch-d] Major practical decision Message-Id: <20061209155647.4299286AE6@mercury.lcs.mit.edu> Date: Sat, 9 Dec 2006 10:56:47 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: f.huici@cs.ucl.ac.uk, jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: "Mark Handley" >> So, what's it to be: jack-up (i.e. insertion of a new internetworking >> layer), or new end-end names (i.e. insertion of a new end-end naming >> layer)? > I'm not sure these are the only possibilities. > We've been playing with the idea of using edge-to-edge tunnelling to > construct an infrastructure for defending against DDoS attacks. > .. > this sort of edge-to-edge tunnelling doesn't require any end-host > changes .. and it should be incrementally deployable. > In any event, it's an example of an architecture that isn't quite > either of the two you listed above. I think Pekka's recent reply (9 Dec 2006 15:57:37 +0200) says roughly what I would have said (but a great deal more elegantly - I wouldn't have thought to decompose it into separate axes, naming and implementation). I don't have time to carefully read your paper (too much email here I need to answer :-), but from the 10-minute look I took, at a high level it seems to be more or less exactly a "jack-up" scheme (which is my term for a scheme in which a new set of names are added at a layer below the existing internetworking layer, and those new names are mostly what is used for forwarding traffic). You have two logically separate namespaces, and map from one to the other, and in the middle of the network you wrap packets with names from one namespace inside packets with names from another namespace. (You call it "tunneling", but to me tunneling implies a point-point thing, with the creation of some state at each end of the tunnel, and this scheme doesn't really have that. It's just a straight wrapping.) This exchange did provoke the following analysis, which all might find useful. Here's the key point: *** Architecturally, separation of location and identity necessarily implies *** creation of a second namespace - one is used for location, and one for *** identity. (The namespace might, confusingly, have the same syntax as the first [as in MIP6, SHIM6, and your scheme], and, yet more confusingly, even be allocated via the same delegation hierarchy. However, it remains that case that one cannot use a name from one space in exactly the same way that one uses a name from the other space, so they are indeed separate.) So, if one accepts that we need to separate location and identity, one is basically also accepting that we need a second namespace. (If someone thinks they can have one without the other, try thinking about it some more! :-) So the only question, architecturally speaking, is "do the new names take over the location role, or the identity role"? In designs like HIP, the new names take over the identity. In all jack-up schemes, the new names (mostly) take over the location role. (I say "mostly" because in most jack-up schemes there is usually a vestigial "location" role left with the original names. In other words, because the goal is usually to avoid modifying hosts, at some point the packet is unwrapped, and once that happens, the original internetworking "address", which is now mostly "identity", resumes its role of identifying an interface, and where that interface is. Any forwarding decisions that are taken based on it are only in a scope fairly local to the destination, though.) So I would claim that, at an architectural level, the question is indeed "jack-up (i.e. insertion of a new internetworking layer), or new end-end names (i.e. insertion of a new end-end naming layer)". There are many possible implementation variants within each, of course, but fundamentally one of these two things is happening. Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Dec 09 11:17:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gt4rx-0004Mz-F4; Sat, 09 Dec 2006 11:16:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gt4rv-0004Mt-Sw for architecture-discuss@ietf.org; Sat, 09 Dec 2006 11:16:07 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gt4rt-0003ep-GX for architecture-discuss@ietf.org; Sat, 09 Dec 2006 11:16:07 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id A8A2786AE6; Sat, 9 Dec 2006 11:16:03 -0500 (EST) To: architecture-discuss@ietf.org Subject: RE: [arch-d] Major practical decision Message-Id: <20061209161603.A8A2786AE6@mercury.lcs.mit.edu> Date: Sat, 9 Dec 2006 11:16:03 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: "Bound, Jim" >> I get the sense that it is now generally accepted that widespread >> multi-homing has to be handled by use of multiple routing-names, and >> identity/location separation. > We need to crisply define and obtain consensus on Routing-Names. Routing-names are, very simply, the names for things which the path-selection (routing) uses. End of definition! :-) So from my perception there's not really a lot, at a fundamental level, to obtain consensus on. I think it's obvious that you have to have path-selection, and in turn that it has to use some sort of names. So the fact that we have to have them, and a lot about their basic properties, are necessarily defined for us right there. Yes, there are issues of detailed syntax etc, but I think those should be put off *until we know more about how the routing is going to work*. Once we've done that, we can turn to transforming generic A.p.1 kind of notation into specific bit patterns, etc. >> we may be forced to convert the current IPvN addresses into end-end >> names, "jack up" the internetwork layer, and insert a new layer >> underneath, and deploy some sort of mapping system to map from IPvN >> "addresses" to some new routing-name namespace. > These are three efforts that can happen regarding our work to define an > architecture in parallel Sorry, I'm not sure I understand your comment. First, are you saying that you think the jack-up path is the way to go? Because further down you say that you prefer a new end-end namespace ("my view currently we should move to a new namespace for end-to-end entities"), which is the other path. Or are you saying take both: jack-up short term, new end-end names long-term? Second, if I decompose 'jack-up' into separate engineering elements, I'm not sure I see three pieces. I come up with: 1 - Decide what the new lower layer packet routing-name format is going to be. 2 - Figure out how the routing is going to work. 3 - Decide what the new lower layer packet format is going to be. 4 - Depending on the previous one, we may need to design an encapsulation. 5 - Design and plan deployment of the mapping database. Some are fairly simple (1, 3 and 4), but others are pretty significant. And of course 3 depends on 1 (as in, can't start 3 until 1 is done), and 4 depends on 3. Finally, are you suggesting that we do detailed designs on all possible alternatives (e.g. one or more jack-up systems, etc), and only pick one once more detailed designs are in hand? I'm rather concerned that that would spread us too thin, and we'd be better off trying to decide on one (or maybe two) to persue up front. However, that's just my opinion; luckily, I don't have to make that sort of call anymore! :-) >> [possibly] this is the only solution that's viable in a short >> time-frame. > I think we must define short and long term before one can answer this > question. Short-term = (roughly) before the Internet routing tables melt down. :-) Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Dec 09 11:40:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gt5EZ-0003KA-NF; Sat, 09 Dec 2006 11:39:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gt5EY-0003K5-OY for architecture-discuss@ietf.org; Sat, 09 Dec 2006 11:39:30 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gt5EX-000133-Ga for architecture-discuss@ietf.org; Sat, 09 Dec 2006 11:39:30 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 216A686AE6; Sat, 9 Dec 2006 11:39:29 -0500 (EST) To: architecture-discuss@ietf.org Subject: Re: [arch-d] Major practical decision Message-Id: <20061209163929.216A686AE6@mercury.lcs.mit.edu> Date: Sat, 9 Dec 2006 11:39:29 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: marcelo bagnulo braun Good questions! I think the problem is that it seems that people tend to either think about i) how to do multi-homing, or ii) how to deploy something to prevent routing meltdown (e.g. jack-up), and don't always think "how does the design do both"! So it's not immediately clear to me, for example, exactly how jack-up/mapping schemes support multihoming. Yeah, the box that does mapping/wrapping could know (from the mapping table) that IPvN address range X.1-X.n is multi-homed because it maps to three different new routing-names, A.p, B.q and C.r, and there's some mechanism (probably not in the routing itself) to make sure that whichever one it picks is currently functional (i.e. not unreachable because while A is reachable, the A<->A.p link has gone down, and the routing has aggregated all A.* announcements to A by the time they get to this mapping box). But, yeah, people thinking about one side of this (multi-homing, or routing meltdown) need to pay attention to how their stuff does the other side.a > what kind of approach could provide multihoming support (preserving > established communications) Oooh, there's multi-homing and there's multihoming! Keeping existing connections up is probably harder than allowing new connections to succeed. When you say "preserving established communications", did you mean "keep existing connection up", or what? > without requiring support from both peers of the communications? (by > peers i mean either the end nodes themselves With enough thrust, pigs can fly. The question is, do you want them to fly?! So I'm sure that with enough mechanism we could probably make this work. However, do we want the additional complexity (and also, potentially, overhead) to make it work - is this an important enough goal? > If we do actually manage to define a solution that _only_ requires > modifications to the multihomed site and does not requires > modifications to the peers that it is communicating with (nor the the > network outside the multihomed site) this would be indeed a really nice > feature Ditto... E.g. we sort of have this now, it's called PI-addresses, but the overhead is not reasonable. > because only those who actually get the multihoming benefits have to > pay the costs of supporting the multihoming support tools, which is > very nice Well, presumably the other party gets some benefit too. I mean, if you're trying to get to Google, or a news site, or an e-business site, and you can because they are multi-homed, you get the benefit too, not just the site you're going to. > i am not sure i have ever seen a proposal that does this.... Good point. > could you expand? Sigh. The more I read this morning, the more I think we need to stop doing this by email, and put 20 people together in a room for a couple of days, and repeat that several times, with breaks of a couple of weeks in between, for comment/recuperation. There is just too much ground to cover, and too much to say about most parts of it... Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Dec 09 13:08:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gt6aN-00059f-1J; Sat, 09 Dec 2006 13:06:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gt6aL-00059X-Qy for architecture-discuss@ietf.org; Sat, 09 Dec 2006 13:06:05 -0500 Received: from sccrmhc14.comcast.net ([63.240.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gt6aJ-00021f-KN for architecture-discuss@ietf.org; Sat, 09 Dec 2006 13:06:05 -0500 Received: from [192.168.0.101] (c-24-6-155-154.hsd1.ca.comcast.net[24.6.155.154]) by comcast.net (sccrmhc14) with SMTP id <2006120918055501400q3fuue>; Sat, 9 Dec 2006 18:05:56 +0000 In-Reply-To: <816DD9299957E547B5D758D7F977D6DC010F2A0D@tayexc14.americas.cpqcorp.net> References: <816DD9299957E547B5D758D7F977D6DC010F2A0D@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [arch-d] Major practical decision Date: Sat, 9 Dec 2006 10:06:13 -0800 To: "Bound, Jim" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Noel Chiappa , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > I don't think we can develop a solution that will last 100 years. 30 > years maybe. I beleive something else will break the system that has > nothing to do with the namespace decision or IP layer. This is not to > say we should not replace the namespace but to attempt to provide an > architecture that can be implemented by engineers that lasts 100 years > seems a bit impossible to me. Perhaps. Let me make the point differently: whatever we do at this point should be the best possible solution that we can come up with. The cost of deployment of even 'short-term' solutions is incredibly high, and is paid by people all over the world. A short-term kludge is not a responsible solution to our problems. We have the opportunity now to affect a long-term architectural change and we should give it our best effort. If we do well, our solution will far outlive us. Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Dec 09 14:10:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gt7Yg-000097-Ef; Sat, 09 Dec 2006 14:08:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gt7Yf-00008n-CR for architecture-discuss@ietf.org; Sat, 09 Dec 2006 14:08:25 -0500 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gt7Yd-0006sA-Uq for architecture-discuss@ietf.org; Sat, 09 Dec 2006 14:08:25 -0500 Received: from 199.13.wireless.icannsaopaulo.br (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id kB9J1XSv004864; Sat, 9 Dec 2006 11:01:40 -0800 (PST) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by 199.13.wireless.icannsaopaulo.br (PGP Universal service); Sat, 09 Dec 2006 17:08:02 -0200 X-PGP-Universal: processed; by 199.13.wireless.icannsaopaulo.br on Sat, 09 Dec 2006 17:08:02 -0200 In-Reply-To: <20061209163929.216A686AE6@mercury.lcs.mit.edu> References: <20061209163929.216A686AE6@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <0D917389-A8E9-4F0B-8569-D20A8D5044CD@virtualized.org> From: David Conrad Subject: Re: [arch-d] Major practical decision Date: Sat, 9 Dec 2006 17:07:54 -0200 To: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Noel, On Dec 9, 2006, at 2:39 PM, Noel Chiappa wrote: > So it's not immediately clear to me, for example, exactly how jack- > up/mapping > schemes support multihoming. Yeah, the box that does mapping/ > wrapping could > know (from the mapping table) that IPvN address range X.1-X.n is > multi-homed > because it maps to three different new routing-names, A.p, B.q and > C.r, Right. > and > there's some mechanism (probably not in the routing itself) to make > sure that > whichever one it picks is currently functional (i.e. not > unreachable because > while A is reachable, the A<->A.p link has gone down, and the > routing has > aggregated all A.* announcements to A by the time they get to this > mapping > box). One of the reasons I think a tunneling approach is the right way to go is that it allows for in-flight re-routing to occur. That is, when the packet reaches a point where the unreachability of the final destination can be determined, the router at which the unreachability was discovered _could_ (isn't required) de-encapsulate, check the mapping for the destination identifier for an alternative destination locator, and if one exists, forward it on. Such in-flight re-routing could be quite helpful for mobility. Of course, prior to the re-routing, an ICMP-type message would be sent to tell the source mapping device that the destination was unreachable so the re-routing would only need to be done for those packets that were in-flight before the ICMP-type message made it back to the source. > But, yeah, people thinking about one side of this (multi-homing, or > routing > meltdown) need to pay attention to how their stuff does the other > side.a Yep. >> what kind of approach could provide multihoming support (preserving >> established communications) > > Oooh, there's multi-homing and there's multihoming! Keeping existing > connections up is probably harder than allowing new connections to > succeed. Not really. Since connections are established on the identifier, the locators used in end-to-end transmission of packets is irrelevant. An advantage of the identifier/locator split is that connections can be maintained when transitions occur between one locator to another. >> without requiring support from both peers of the communications? (by >> peers i mean either the end nodes themselves > > With enough thrust, pigs can fly. The question is, do you want them > to fly?! > So I'm sure that with enough mechanism we could probably make this > work. > However, do we want the additional complexity (and also, potentially, > overhead) to make it work - is this an important enough goal? With the model I'm thinking of, there would be NO additional complexity in the end hosts nor (if you don't care about the re- routing I mentioned above) in the routers. Whatever complexity there is would be at the point of mapping. > Sigh. The more I read this morning, the more I think we need to > stop doing > this by email, and put 20 people together in a room for a couple of > days, and > repeat that several times, with breaks of a couple of weeks in > between, for > comment/recuperation. 20 is probably too many... Rgds, -drc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Dec 09 15:25:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gt8j5-0006XO-LV; Sat, 09 Dec 2006 15:23:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gt8j4-0006XB-Nq for architecture-discuss@ietf.org; Sat, 09 Dec 2006 15:23:14 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gt8j3-0003Hc-8t for architecture-discuss@ietf.org; Sat, 09 Dec 2006 15:23:14 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 49EE9111244; Sat, 9 Dec 2006 21:23:08 +0100 (CET) Received: from [163.117.203.209] (unknown [163.117.203.209]) by smtp01.uc3m.es (Postfix) with ESMTP id 8E047111366; Sat, 9 Dec 2006 21:23:07 +0100 (CET) In-Reply-To: <0D917389-A8E9-4F0B-8569-D20A8D5044CD@virtualized.org> References: <20061209163929.216A686AE6@mercury.lcs.mit.edu> <0D917389-A8E9-4F0B-8569-D20A8D5044CD@virtualized.org> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <121fd274017de9e61550cf58bb93856e@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [arch-d] Major practical decision Date: Sat, 9 Dec 2006 21:23:11 +0100 To: David Conrad X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: Noel Chiappa , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Hi David, El 09/12/2006, a las 20:07, David Conrad escribi=F3: >> With enough thrust, pigs can fly. The question is, do you want them=20= >> to fly?! >> So I'm sure that with enough mechanism we could probably make this=20 >> work. >> However, do we want the additional complexity (and also, potentially, >> overhead) to make it work - is this an important enough goal? > > With the model I'm thinking of, there would be NO additional=20 > complexity in the end hosts nor (if you don't care about the=20 > re-routing I mentioned above) in the routers. Whatever complexity=20 > there is would be at the point of mapping. > i am not sure i understand what you have in mind, but the peer that is=20= communicating with host within the multihomed site will need to know=20 the identifier and all the locators, so it can encapsulate with all the=20= different locators, right? If this is the case, the peer (or some box=20 near the peer) needs to support whatever protocol are used to securely=20= exchange the identifier and locator set. This box needs to be deployed,=20= hence, we need support outside the multihomed site, right? Regards, marcelo >> Sigh. The more I read this morning, the more I think we need to stop=20= >> doing >> this by email, and put 20 people together in a room for a couple of=20= >> days, and >> repeat that several times, with breaks of a couple of weeks in=20 >> between, for >> comment/recuperation. > > 20 is probably too many... > > Rgds, > -drc > > > _______________________________________________ > 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 Sat Dec 09 16:18:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gt9aD-00071Q-Cq; Sat, 09 Dec 2006 16:18:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gt9aB-00071K-Sd for architecture-discuss@ietf.org; Sat, 09 Dec 2006 16:18:07 -0500 Received: from imo-m16.mx.aol.com ([64.12.138.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gt9aA-0004o3-Il for architecture-discuss@ietf.org; Sat, 09 Dec 2006 16:18:07 -0500 Received: from HeinerHummel@aol.com by imo-m16.mx.aol.com (mail_out_v38_r7.6.) id w.cd4.3e5d2d0 (48600); Sat, 9 Dec 2006 16:18:00 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Sat, 9 Dec 2006 16:17:57 EST Subject: Re: [arch-d] Major practical decision To: Jim.Bound@hp.com, tony.li@tony.li, jnc@mercury.lcs.mit.edu MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5009 X-Spam-Flag: NO X-Spam-Score: 0.3 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 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="===============0284971518==" Errors-To: architecture-discuss-bounces@ietf.org --===============0284971518== Content-Type: multipart/alternative; boundary="-----------------------------1165699077" -------------------------------1165699077 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 =20 Jim, my point is, that flat routing produces a huge amount of message =20 dissemination (upon changes) as to inform routers which shouldn't need tha= t=20 information because it shouldn't affect their routing decisions. Hierarchy=20= would=20 confine that. Heiner =20 In einer eMail vom 09.12.2006 12:37:38 Westeurop=E4ische Normalzeit schreibt= =20 Jim.Bound@hp.com: Interesting is anyone proposing an alternative to hierarchical routing if s= o=20 I would like to hear that logic? /jim =20 ____________________________________ From: HeinerHummel@aol.com [mailto:HeinerHummel@aol.com]=20 Sent: Saturday, December 09, 2006 3:39 AM To: tony.li@tony.li; jnc@mercury.lcs.mit.edu Cc: architecture-discuss@ietf.org Subject: Re: [arch-d] Major practical decision There is no alternative to hierarchical routing and also: there is no need=20 for flat routing. Heiner Why should a router in Europe be informed if some router (not bike) tips=20 over in China?! =20 =20 =20 In einer eMail vom 09.12.2006 05:47:09 Westeurop=E4ische Normalzeit schreib= t=20 tony.li@tony.li: > So, what's it to be: jack-up (i.e. insertion of a new =20 > internetworking layer), > or new end-end names (i.e. insertion of a new end-end naming layer)? My $.02: We're supposed to be architecting a fix for the Internet that should =20 last for the foreseeable future. Not just the next 10 or 20 years, =20 but the next 100 or so. The jack-up model is somewhat less clean and =20 inevitably introduces suboptimalities at the interface between the =20 layers. Thus, I'm in favor of replacing the namespace. Regards, Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss -------------------------------1165699077 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Jim, my point is, that flat routing produces a huge amount of message=20 dissemination (upon changes) as to inform routers which shouldn't=20 need  that information because it shouldn't affect their routing decisi= ons.=20 Hierarchy would confine that.
Heiner
 
In einer eMail vom 09.12.2006 12:37:38 Westeurop=E4ische Normalzeit sch= reibt=20 Jim.Bound@hp.com:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>
Interesting i= s anyone=20 proposing an alternative to hierarchical routing if so I would like to hea= r=20 that logic?
/jim
From: HeinerHummel@aol.com=20 [mailto:HeinerHummel@aol.com]
Sent: Saturday, December 09, 20= 06=20 3:39 AM
To: tony.li@tony.li; jnc@mercury.lcs.mit.edu
Cc:= =20 architecture-discuss@ietf.org
Subject: Re: [arch-d] Major=20 practical decision

There is no alternative to hierarchical routing and also: there is=20= no=20 need for flat routing.
Heiner
Why should a router in Europe be informed if some router (not bike)= =20 tips over in China?!
 
 
 
In einer eMail vom 09.12.2006 05:47:09 Westeurop=E4ische Normalzeit= =20 schreibt tony.li@tony.li:
> So, what's i= t to be:=20 jack-up (i.e. insertion of a new 
> internetworking=20 layer),
> or new end-end names (i.e. insertion of a new end-end=20 naming layer)?


My $.02:

We're supposed to be=20 architecting a fix for the Internet that should 
last for the= =20 foreseeable future.  Not just the next 10 or 20 years, 
= but=20 the next 100 or so.  The jack-up model is somewhat less clean=20 and 
inevitably introduces suboptimalities at the interface=20 between the 
layers.  Thus, I'm in favor of replacing th= e=20 namespace.

Regards,
Tony


________________________= _______________________
Architecture-discuss=20 mailing=20 list
Architecture-discuss@ietf.org
https://www1.ietf.org/mailman= /listinfo/architecture-discuss
 
 
-------------------------------1165699077-- --===============0284971518== 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 --===============0284971518==-- From architecture-discuss-bounces@ietf.org Sat Dec 09 16:39:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gt9ta-0005IK-3M; Sat, 09 Dec 2006 16:38:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gt9tY-0005Fc-5x for architecture-discuss@ietf.org; Sat, 09 Dec 2006 16:38:08 -0500 Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gt9tR-0008TW-RQ for architecture-discuss@ietf.org; Sat, 09 Dec 2006 16:38:08 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id 455923400B; Sat, 9 Dec 2006 16:37:59 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 9 Dec 2006 16:37:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Major practical decision Date: Sat, 9 Dec 2006 16:37:57 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC010F2A58@tayexc14.americas.cpqcorp.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Major practical decision Thread-Index: AccbmmA9aSeFmTZoSz6WGgjImItRcwAP2MHg From: "Bound, Jim" To: "Pekka Nikander" , "Mark Handley" X-OriginalArrivalTime: 09 Dec 2006 21:37:59.0151 (UTC) FILETIME=[4BC71FF0:01C71BDA] X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: Noel Chiappa , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org My understanding is adding a layer is jack-up and that is for RAM. Not this list? This is to discuss not jack-up? Yes or No. Also we should adhere to what is IETF per IRTF and I agree Internet inter-planetary type work should have some core structure that lasts 100 years but that is IRTF work IMHO, thus we need to walk that fence between IRTF and IETF most likely. =20 /jim=20 > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Sent: Saturday, December 09, 2006 8:58 AM > To: Mark Handley > Cc: Noel Chiappa; architecture-discuss@ietf.org > Subject: Re: [arch-d] Major practical decision >=20 > Mark, >=20 > On 12/8/06, Noel Chiappa wrote: > >> So, what's it to be: jack-up (i.e. insertion of a new=20 > internetworking=20 > >> layer), or new end-end names (i.e. insertion of a new=20 > end-end naming=20 > >> layer)? >=20 > On 8 Dec 2006, at 20:02, Mark Handley wrote: > > I'm not sure these are the only possibilities. > > > > We've been playing with the idea of using edge-to-edge=20 > tunnelling to=20 > > construct an infrastructure for defending against DDoS attacks. ... > > > > Anyway, this sort of edge-to-edge tunnelling doesn't require any=20 > > end-host changes, but does permit multiple routing names (in this=20 > > case, the decapsulator addresses) for each end-host IP=20 > address, and it=20 > > should be incrementally deployable. I hadn't intended it as a=20 > > multi-homing architecture, but it might work OK. > > > > In any event, it's an example of an architecture that isn't quite=20 > > either of the two you listed above. >=20 > Hmm. I'm not that sure. What you seem to suggest looks like=20 > another, more implementation related dimension to me. >=20 > Basically, what I understand Noel saying is that we either=20 > must add a layer above the current IP layer or one below it. =20 > This can be, of course, be implemented at various points in=20 > the network: at end- hosts, at edge routers, somewhere at the=20 > first ISP closest to the end site, or in the core. Or some=20 > combination of those. To me, that looks like another,=20 > basically orthogonal dimension, which is more implementation=20 > related than where-in-the-stack to insert the new layer. For=20 > example, I could imagine a solution that would be initially=20 > implemented in many laptops, in big boxes used by many major=20 > corporations, and by some advanced ISPs, and then gradually,=20 > over a longer term, by all hosts. >=20 > Hence, what you seem to propose looks like an implementation=20 > strategy to me. >=20 > Related to your paper, I think that in the long term an=20 > architecture that allows keeping the routing names (locators)=20 > as relative secrets provides some pretty effective protection=20 > against DDoS. Furthermore, if you use overlay routing=20 > instead of resolution to initially map the=20 > location-independent identifiers into locators, you can allow=20 > the responding (server) host or site to make the decision=20 > whether to reveal its locators to the initiator (client). =20 > [That's the approach we proposed to be used in Host Identity=20 > Indirection Infrastructure (Hi3).] >=20 > --Pekka Nikander >=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 Sat Dec 09 16:56:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtABA-0002iX-VI; Sat, 09 Dec 2006 16:56:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtAB9-0002g9-Bf for architecture-discuss@ietf.org; Sat, 09 Dec 2006 16:56:19 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtAB4-0003RK-1N for architecture-discuss@ietf.org; Sat, 09 Dec 2006 16:56:19 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id B887B34027; Sat, 9 Dec 2006 16:56:13 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 9 Dec 2006 16:56:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Major practical decision Date: Sat, 9 Dec 2006 16:56:12 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC010F2A5A@tayexc14.americas.cpqcorp.net> In-Reply-To: <20061209161603.A8A2786AE6@mercury.lcs.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Major practical decision Thread-Index: AccbrYBDSsznxKySRN+1eqIy9M2bbAALTcDA From: "Bound, Jim" To: "Noel Chiappa" , X-OriginalArrivalTime: 09 Dec 2006 21:56:13.0509 (UTC) FILETIME=[D810E750:01C71BDC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > >> I get the sense that it is now generally accepted that=20 > widespread > >> multi-homing has to be handled by use of multiple=20 > routing-names, and > >> identity/location separation. >=20 > > We need to crisply define and obtain consensus on Routing-Names. >=20 > Routing-names are, very simply, the names for things which=20 > the path-selection (routing) uses. End of definition! :-) I prefer then at this point routing-name-space otherwise no different to me than an address. But name-apace to me is a more appropriate architecture term for this work. >=20 > So from my perception there's not really a lot, at a=20 > fundamental level, to obtain consensus on. I think it's=20 > obvious that you have to have path-selection, and in turn=20 > that it has to use some sort of names. So the fact that we=20 > have to have them, and a lot about their basic properties,=20 > are necessarily defined for us right there. I am fine with the above definition with namespace suffix of "space" so lets get that done besides from memory on a mail list in some way. Do we need a draft for terminology? >=20 > Yes, there are issues of detailed syntax etc, but I think=20 > those should be put off *until we know more about how the=20 > routing is going to work*. Once we've done that, we can turn=20 > to transforming generic A.p.1 kind of notation into specific=20 > bit patterns, etc. Yes, but a problem statement draft and initial terminology would be good. >=20 >=20 > >> we may be forced to convert the current IPvN addresses=20 > into end-end > >> names, "jack up" the internetwork layer, and insert a new layer > >> underneath, and deploy some sort of mapping system to=20 > map from IPvN > >> "addresses" to some new routing-name namespace. >=20 > > These are three efforts that can happen regarding our=20 > work to define an > > architecture in parallel >=20 > Sorry, I'm not sure I understand your comment. #1 what is the architecture of the routing-name-space? #2 what is the transition to use #1 above with current IPvN addresses. #3 what are the operational abstractions and requirements for a new layer. That is the three and all can be done in parallel by three different design teams all sharing and communicating of course. >=20 > First, are you saying that you think the jack-up path is the=20 > way to go? Not for new architecture work on this list. > Because further down you say that you prefer a new end-end=20 > namespace ("my view currently we should move to a new=20 > namespace for end-to-end entities"), which is the other path. I will respond below but I am saying separate entirely transport from all other layers in the new architecture and that requires a new end-to-end name space and operational changes similar to SHIM6 and HIP. Minus the CGA which I can not support at least for real implementation in the market. I don't consider this jack-up nor a routing problem thus not one of my three above. =20 > Or are you saying take both: jack-up short term, new end-end=20 > names long-term? >=20 > Second, if I decompose 'jack-up' into separate engineering=20 > elements, I'm not sure I see three pieces. I come up with: >=20 > 1 - Decide what the new lower layer packet routing-name=20 > format is going to be. My #1 above. > 2 - Figure out how the routing is going to work. My #2 above. > 3 - Decide what the new lower layer packet format is going to be. Same as my #1. > 4 - Depending on the previous one, we may need to design an=20 > encapsulation. Same as my #1. > 5 - Design and plan deployment of the mapping database. New task #4 when my #1 and #2 are done. >=20 > Some are fairly simple (1, 3 and 4), but others are pretty=20 > significant. And of course 3 depends on 1 (as in, can't start=20 > 3 until 1 is done), and 4 depends on 3. Hmmm will respond as we evolve here I think the dependencies may be more interrelated. >=20 > Finally, are you suggesting that we do detailed designs on=20 > all possible alternatives (e.g. one or more jack-up systems,=20 > etc), and only pick one once more detailed designs are in=20 > hand? I'm rather concerned that that would spread us too=20 > thin, and we'd be better off trying to decide on one (or maybe > two) to persue up front. However, that's just my opinion;=20 > luckily, I don't have to make that sort of call anymore! :-) One focus but to move our pace that 3 parallel design teams could be at work. >=20 >=20 > >> [possibly] this is the only solution that's viable in a short > >> time-frame. >=20 > > I think we must define short and long term before one=20 > can answer this > > question. >=20 > Short-term =3D (roughly) before the Internet routing tables=20 > melt down. :-) So short term is 5-7 years ? Long Term =3D=3D Short-Term+ /jim >=20 > Noel >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Dec 09 17:00:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtAEj-00042U-Pt; Sat, 09 Dec 2006 17:00:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtAEi-00042P-Iu for architecture-discuss@ietf.org; Sat, 09 Dec 2006 17:00:00 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtAEd-0004Ml-Bu for architecture-discuss@ietf.org; Sat, 09 Dec 2006 17:00:00 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 3DE9134027; Sat, 9 Dec 2006 16:59:55 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 9 Dec 2006 16:59:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Major practical decision Date: Sat, 9 Dec 2006 16:59:44 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC010F2A5B@tayexc14.americas.cpqcorp.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Major practical decision Thread-Index: AccbvK4TjFd2RIfVQIKFTNudVbMjiQAIFBwQ From: "Bound, Jim" To: "Tony Li" X-OriginalArrivalTime: 09 Dec 2006 21:59:55.0020 (UTC) FILETIME=[5C18CCC0:01C71BDD] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Noel Chiappa , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > > I don't think we can develop a solution that will last 100=20 > years. 30=20 > > years maybe. I beleive something else will break the=20 > system that has=20 > > nothing to do with the namespace decision or IP layer. =20 > This is not to=20 > > say we should not replace the namespace but to attempt to=20 > provide an=20 > > architecture that can be implemented by engineers that=20 > lasts 100 years=20 > > seems a bit impossible to me. >=20 >=20 > Perhaps. Let me make the point differently: whatever we do at this =20 > point should be the best possible solution that we can come=20 > up with. =20 > The cost of deployment of even 'short-term' solutions is=20 > incredibly high, and is paid by people all over the world. A=20 > short-term kludge is not a responsible solution to our=20 > problems. We have the opportunity now to affect a long-term=20 > architectural change and we should give it our best effort. =20 > If we do well, our solution will far outlive us. That would be a good goal and if we adopt this then any jack-up to assist the potential melt-down should not be part of this thread discussion or architecture work I deduce as I think that is within the 5-7 year range, and I do not believe we can come up with something that reaches the market of this nature in 5-7 years, given the rules of engagement above. /jim _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Dec 09 17:02:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtAGj-0004h5-KV; Sat, 09 Dec 2006 17:02:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtAGi-0004gz-7j for architecture-discuss@ietf.org; Sat, 09 Dec 2006 17:02:04 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtAGb-0004xJ-Pc for architecture-discuss@ietf.org; Sat, 09 Dec 2006 17:02:04 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id A445C34017; Sat, 9 Dec 2006 17:01:57 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 9 Dec 2006 17:01:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [arch-d] Major practical decision Date: Sat, 9 Dec 2006 17:01:56 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC010F2A5C@tayexc14.americas.cpqcorp.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Major practical decision Thread-Index: Accb14TQfTWxaLquSJOgvrTA+Rg5FQABe3ew From: "Bound, Jim" To: , , X-OriginalArrivalTime: 09 Dec 2006 22:01:57.0563 (UTC) FILETIME=[A52360B0:01C71BDD] X-Spam-Score: 0.1 (/) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 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="===============1207817570==" Errors-To: architecture-discuss-bounces@ietf.org This is a multi-part message in MIME format. --===============1207817570== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C71BDD.A4A6FC20" This is a multi-part message in MIME format. ------_=_NextPart_001_01C71BDD.A4A6FC20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Heiner, I actually agreed with you but was checking if any were = proposing an alternative and said it generically to not limit any = response to flat routing. =20 thanks /jim ________________________________ From: HeinerHummel@aol.com [mailto:HeinerHummel@aol.com]=20 Sent: Saturday, December 09, 2006 4:18 PM To: Bound, Jim; tony.li@tony.li; jnc@mercury.lcs.mit.edu Cc: architecture-discuss@ietf.org Subject: Re: [arch-d] Major practical decision =09 =09 =09 Jim, my point is, that flat routing produces a huge amount of message = dissemination (upon changes) as to inform routers which shouldn't need = that information because it shouldn't affect their routing decisions. = Hierarchy would confine that. Heiner =20 In einer eMail vom 09.12.2006 12:37:38 Westeurop=E4ische Normalzeit = schreibt Jim.Bound@hp.com: =09 Interesting is anyone proposing an alternative to hierarchical routing = if so I would like to hear that logic? /jim ________________________________ From: HeinerHummel@aol.com [mailto:HeinerHummel@aol.com]=20 Sent: Saturday, December 09, 2006 3:39 AM To: tony.li@tony.li; jnc@mercury.lcs.mit.edu Cc: architecture-discuss@ietf.org Subject: Re: [arch-d] Major practical decision =09 =09 =09 There is no alternative to hierarchical routing and also: there is no = need for flat routing. Heiner Why should a router in Europe be informed if some router (not bike) = tips over in China?! =20 =20 =20 In einer eMail vom 09.12.2006 05:47:09 Westeurop=E4ische Normalzeit = schreibt tony.li@tony.li: > So, what's it to be: jack-up (i.e. insertion of a new =20 > internetworking layer), > or new end-end names (i.e. insertion of a new end-end naming = layer)? =09 =09 My $.02: =09 We're supposed to be architecting a fix for the Internet that should = =20 last for the foreseeable future. Not just the next 10 or 20 years, = but the next 100 or so. The jack-up model is somewhat less clean = and =20 inevitably introduces suboptimalities at the interface between the =20 layers. Thus, I'm in favor of replacing the namespace. =09 Regards, Tony =09 =09 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss =09 =20 =20 ------_=_NextPart_001_01C71BDD.A4A6FC20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Heiner, I = actually agreed=20 with you but was checking if any were proposing an alternative and = said it=20 generically to not limit any response to flat routing.
 
thanks
/jim

From: HeinerHummel@aol.com=20 [mailto:HeinerHummel@aol.com]
Sent: Saturday, December 09, = 2006=20 4:18 PM
To: Bound, Jim; tony.li@tony.li;=20 jnc@mercury.lcs.mit.edu
Cc:=20 architecture-discuss@ietf.org
Subject: Re: [arch-d] Major = practical=20 decision

Jim, my point is, that flat routing produces a huge amount of = message=20 dissemination (upon changes) as to inform routers which = shouldn't=20 need  that information because it shouldn't affect their routing=20 decisions. Hierarchy would confine that.
Heiner
 
In einer eMail vom 09.12.2006 12:37:38 Westeurop=E4ische = Normalzeit=20 schreibt Jim.Bound@hp.com:
Interesting is anyone=20 proposing an alternative to hierarchical routing if so I would like = to hear=20 that logic?
/jim

From: HeinerHummel@aol.com=20 [mailto:HeinerHummel@aol.com]
Sent: Saturday, December = 09, 2006=20 3:39 AM
To: tony.li@tony.li;=20 jnc@mercury.lcs.mit.edu
Cc:=20 architecture-discuss@ietf.org
Subject: Re: [arch-d] = Major=20 practical decision

There is no alternative to hierarchical routing and also: = there is no=20 need for flat routing.
Heiner
Why should a router in Europe be informed if some router (not = bike)=20 tips over in China?!
 
 
 
In einer eMail vom 09.12.2006 05:47:09 Westeurop=E4ische = Normalzeit=20 schreibt tony.li@tony.li:
> So, = what's it to=20 be: jack-up (i.e. insertion of a new 
> = internetworking=20 layer),
> or new end-end names (i.e. insertion of a new = end-end=20 naming layer)?


My $.02:

We're supposed to be=20 architecting a fix for the Internet that should 
last = for the=20 foreseeable future.  Not just the next 10 or 20 = years, =20
but the next 100 or so.  The jack-up model is somewhat = less=20 clean and 
inevitably introduces suboptimalities at the = interface between the 
layers.  Thus, I'm in favor = of=20 replacing the=20 = namespace.

Regards,
Tony


___________________________= ____________________
Architecture-discuss=20 mailing=20 = list
Architecture-discuss@ietf.org
https://www1.ietf.org/mailman/li= stinfo/architecture-discuss
 
 
------_=_NextPart_001_01C71BDD.A4A6FC20-- --===============1207817570== 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 --===============1207817570==-- From architecture-discuss-bounces@ietf.org Sat Dec 09 17:15:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtASp-000091-7u; Sat, 09 Dec 2006 17:14:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtASo-00008n-6a for architecture-discuss@ietf.org; Sat, 09 Dec 2006 17:14:34 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtASm-00085d-FO for architecture-discuss@ietf.org; Sat, 09 Dec 2006 17:14:34 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id EE34C86AE9; Sat, 9 Dec 2006 17:14:31 -0500 (EST) To: architecture-discuss@ietf.org Subject: RE: [arch-d] Major practical decision Message-Id: <20061209221431.EE34C86AE9@mercury.lcs.mit.edu> Date: Sat, 9 Dec 2006 17:14:31 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: "Bound, Jim" > My understanding is adding a layer is jack-up Well, jack-up adds a layer, but so does the other alternative. As I said in my reply to Mark, separation of location and identity implies the creation of a second namespace (even if they are syntactically identical, as in SHIM6), to allow separation of those two functions - and to subsequently allow bindings from one kind of name to the other (which is how you provide support for all sorts of things, like mobility and multihoming). Inevitably, you wind up structuring the new names as part of a layer, or sub-layer (whatever/however you want to describe it). (People may not think they are creating a new layer, but really, they are.) The key point is that the location names go with the lower of the two, and the identity names going with the higher layer. The big question is: "What do the exising IPvN addresses become?" If they turn into identity, you wind up with a jack-up design, you add a new lower layer and the new namespace is the lower-layer locators; if they turn into locators, the new-namespace becomes identity, and you wind up with SHIM6, HIP, etc, etc. > and that is for RAM. Not this list? Well, not really (but there is a stronger tie to routing for jack-up). If we go with jack-up, that means deploying a new namespace for routing-names, and there are consequences during the deployment (particularly during the early deployment phases, where I think the problems are the worst) for the routing, which has to handle (basically) two separate routing-name-spaces for a while. There isn't the same immediate tie-in with routing for a new end-end namespace (e.g. HIP), but even down that road, the growth of the routing tables may still be too large to handle, and so perhaps there's work to be done there too. So my concept was for RAM to try and focus on the routing issues, particularly the implications for the routing of deploying jack-up, but really I suspect both paths have routing issues. > This is to discuss not jack-up? Yes or No. The question of whether we add a new end-end namespace, or a new routing-names namespace (which is really the same question as whether the existing IPvN addresses become identity or location) isn't really a routing issue. Whatever we do, there's going to be one namespace for routing-names, and the routing's going to have to do path selection. So the decision between deploying a "new" (" "'s since SHIM6, HIP, etc are already here) end-end namespace, and going with jack-up instead, really doesn't have a major routing component*; so I reckon this list is a good place to consider that question. (* Unless, of course, people thinking about routing decide that the routing implications of one path or the other are too horrible to contemplate, and we really need to pick option X.) Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Dec 09 19:28:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtCWl-0006yD-IQ; Sat, 09 Dec 2006 19:26:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtCWj-0006y6-UW for architecture-discuss@ietf.org; Sat, 09 Dec 2006 19:26:45 -0500 Received: from sccrmhc13.comcast.net ([204.127.200.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtCWh-0003P4-HA for architecture-discuss@ietf.org; Sat, 09 Dec 2006 19:26:45 -0500 Received: from [192.168.0.101] (c-24-6-155-154.hsd1.ca.comcast.net[24.6.155.154]) by comcast.net (sccrmhc13) with SMTP id <20061210002642013008sfnde>; Sun, 10 Dec 2006 00:26:42 +0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Tony Li Subject: Re: [arch-d] Major practical decision Date: Sat, 9 Dec 2006 16:27:00 -0800 To: HeinerHummel@aol.com X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: architecture-discuss@ietf.org, jnc@mercury.lcs.mit.edu, Jim.Bound@hp.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: , Content-Type: multipart/mixed; boundary="===============0847298438==" Errors-To: architecture-discuss-bounces@ietf.org --===============0847298438== Content-Type: multipart/alternative; boundary=Apple-Mail-1-572143701 --Apple-Mail-1-572143701 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Heiner, If it was unclear, I was in no way advocating abandoning hierarchical =20= abstraction. In fact, I think I'm one of the larger cheerleaders for abstraction =20 of routing names, and for applying it in multiple layers. Long ago, =20 back when we were discussing CIDR, I proposed that we create another =20 level of abstraction by allocating prefixes at the continental level =20 (say a /4) and then allowing registries to delegate out of that. The =20= thought being that we would get another useful abstraction boundary =20 at continental interconnects. This got shot down, sadly. Tony On Dec 9, 2006, at 1:17 PM, HeinerHummel@aol.com wrote: > Jim, my point is, that flat routing produces a huge amount of =20 > message dissemination (upon changes) as to inform routers which =20 > shouldn't need that information because it shouldn't affect their =20 > routing decisions. Hierarchy would confine that. > Heiner > > In einer eMail vom 09.12.2006 12:37:38 Westeurop=E4ische Normalzeit =20= > schreibt Jim.Bound@hp.com: > Interesting is anyone proposing an alternative to hierarchical =20 > routing if so I would like to hear that logic? > /jim > > From: HeinerHummel@aol.com [mailto:HeinerHummel@aol.com] > Sent: Saturday, December 09, 2006 3:39 AM > To: tony.li@tony.li; jnc@mercury.lcs.mit.edu > Cc: architecture-discuss@ietf.org > Subject: Re: [arch-d] Major practical decision > > There is no alternative to hierarchical routing and also: there is =20 > no need for flat routing. > Heiner > Why should a router in Europe be informed if some router (not bike) =20= > tips over in China?! > > > > In einer eMail vom 09.12.2006 05:47:09 Westeurop=E4ische Normalzeit =20= > schreibt tony.li@tony.li: > > So, what's it to be: jack-up (i.e. insertion of a new > > internetworking layer), > > or new end-end names (i.e. insertion of a new end-end naming layer)? > > > My $.02: > > We're supposed to be architecting a fix for the Internet that should > last for the foreseeable future. Not just the next 10 or 20 years, > but the next 100 or so. The jack-up model is somewhat less clean and > inevitably introduces suboptimalities at the interface between the > layers. Thus, I'm in favor of replacing the namespace. > > Regards, > Tony > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss > > --Apple-Mail-1-572143701 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

Heiner,

If it was unclear, I was in = no way advocating abandoning hierarchical abstraction.

In fact, I think I'm one of = the larger cheerleaders for abstraction of routing names, and for = applying it in multiple layers.=A0 Long ago, back when we were = discussing CIDR, I proposed that we create another level of abstraction = by allocating prefixes at the continental level (say a /4) and then = allowing registries to delegate out of that.=A0 The thought being that = we would get another useful abstraction boundary at continental = interconnects.=A0 This got shot down, sadly.

Tony


On Dec 9, = 2006, at 1:17 PM, HeinerHummel@aol.com = wrote:

Jim, my point is, that flat routing = produces a huge amount of message dissemination (upon changes)=A0as to = inform=A0routers which shouldn't need=A0 that information because it = shouldn't affect their routing decisions. Hierarchy would confine = that.
Heiner
=A0
In einer eMail = vom 09.12.2006 12:37:38 Westeurop=E4ische Normalzeit schreibt Jim.Bound@hp.com:
Interesting is anyone proposing an = alternative to hierarchical routing if so I would like to hear that = logic?
/jim

=
From: = HeinerHummel@aol.com [mailto:HeinerHummel@aol.com] =
Sent: Saturday, December 09, 2006 3:39 AM
To: = tony.li@tony.li; jnc@mercury.lcs.mit.edu
= Cc: architecture-discuss@ietf.or= g
Subject: Re: [arch-d] Major practical = decision

=
There is no alternative to hierarchical routing and also: = there is no need for flat routing.
Heiner
=
Why should a router in Europe be informed if some router (not bike) = tips over in China?!
=A0
=A0
=
=A0
In einer eMail vom 09.12.2006 05:47:09 = Westeurop=E4ische Normalzeit schreibt tony.li@tony.li:
=
> So, what's it to be: jack-up (i.e. insertion = of a new=A0
> internetworking layer),
> or new = end-end names (i.e. insertion of a new end-end naming = layer)?


My $.02:

We're supposed to be = architecting a fix for the Internet that should=A0
last for the = foreseeable future.=A0 Not just the next 10 or 20 years,=A0
but = the next 100 or so.=A0 The jack-up model is somewhat less clean = and=A0
inevitably introduces suboptimalities at the interface = between the=A0
layers.=A0 Thus, I'm in favor of replacing the = namespace.

Regards,
Tony


____________________________= ___________________
Architecture-discuss mailing = list
Architecture-discuss@ietf.or= g
https://www1.ietf.org/mailman/listinfo/architecture-discuss
=
=A0
=
=A0

= --Apple-Mail-1-572143701-- --===============0847298438== 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 --===============0847298438==-- From architecture-discuss-bounces@ietf.org Sat Dec 09 19:34:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtCdk-0000TR-2v; Sat, 09 Dec 2006 19:34:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtCdi-0000RQ-KK for architecture-discuss@ietf.org; Sat, 09 Dec 2006 19:33:58 -0500 Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtCdg-0004ol-DV for architecture-discuss@ietf.org; Sat, 09 Dec 2006 19:33:58 -0500 Received: from [192.168.0.101] (c-24-6-155-154.hsd1.ca.comcast.net[24.6.155.154]) by comcast.net (sccrmhc11) with SMTP id <2006121000335201100pm8jde>; Sun, 10 Dec 2006 00:33:56 +0000 In-Reply-To: <20061209221431.EE34C86AE9@mercury.lcs.mit.edu> References: <20061209221431.EE34C86AE9@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [arch-d] Major practical decision Date: Sat, 9 Dec 2006 16:34:10 -0800 To: Noel Chiappa X-Mailer: Apple Mail (2.752.3) 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: , Errors-To: architecture-discuss-bounces@ietf.org > Inevitably, you wind up structuring the new names as part of a > layer, or > sub-layer (whatever/however you want to describe it). (People may > not think > they are creating a new layer, but really, they are.) The key point > is that > the location names go with the lower of the two, and the identity > names going > with the higher layer. Certainly conceptually I agree. However, I'm concerned that when other folks approach adding a layer, they will want to invoke another header and tunnel everything. While I'm a big fan of tunneling (see RFC 1701 ;-), I don't see tunneling as a first-class architectural solution. It adds non-trivial overhead and creates subsidiary issues like MTU and ICMP problems that don't live up to our standards for architectural cleanliness. Hi ho, Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Dec 10 03:36:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtK8M-0003Gw-30; Sun, 10 Dec 2006 03:34:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtK8L-0003Gr-1U for architecture-discuss@ietf.org; Sun, 10 Dec 2006 03:34:05 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtK8J-0007Tp-FY for architecture-discuss@ietf.org; Sun, 10 Dec 2006 03:34:05 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 81DFC213129; Sun, 10 Dec 2006 10:33:50 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 1E96721311D; Sun, 10 Dec 2006 10:33:50 +0200 (EET) In-Reply-To: <0D917389-A8E9-4F0B-8569-D20A8D5044CD@virtualized.org> References: <20061209163929.216A686AE6@mercury.lcs.mit.edu> <0D917389-A8E9-4F0B-8569-D20A8D5044CD@virtualized.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7CB1051B-058D-4F6B-BD89-74C82990A568@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [arch-d] Major practical decision Date: Sun, 10 Dec 2006 10:33:48 +0200 To: David Conrad X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: Noel Chiappa , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > One of the reasons I think a tunneling approach is the right way to > go is that it allows for in-flight re-routing to occur. That is, > when the packet reaches a point where the unreachability of the > final destination can be determined, the router at which the > unreachability was discovered _could_ (isn't required) de- > encapsulate, check the mapping for the destination identifier for > an alternative destination locator, and if one exists, forward it on. If I understand you correctly, what you are saying is the following: 1. Consider packets that have two nested headers, the outer one carrying a locator and the inner one an identifier. 2. The identifiers have global scope in the sense that any "router at which the unreachability [is] discovered" can resolve the identifier to another locator. 2a. In order to map the identifier into a locator at any point of the network, a global infrastructure for doing the mapping is needed. The current IP routing system is one particular example of such an global infrastructure (I'm disregarding the well known limitations of the IP system here). Note that this model has been applied already at different points in the network in its non-tunnelling and tunnelling forms, cf. e.g. MPLS. Hence, as an architectural pattern it is not new. Most variations can be found on how the infrastructure works. Now, the problem with this model is security. The basic attack scenario is a DDoS attacker using the re-routing mechanism to disperse attack traffic through as many points as possible. In general, either the re-routing point must somehow gain assurance that the re-routing in question is legitimate or the packets must somehow be self-authenticating, legitimising the re-routing. The typical mechanisms today utilise encapsulation only within one security domain (cf. MPLS) or explicitly create some minimal state at the re- routing point. Finally, I would consider such construction tunnelling only if the inner and outer header have the same syntax and the locators and identifiers are drawn from a single name space (or, at least, from syntactically similar names spaces, if you prefer Noel's stricter name space definition). If the headers or identifiers are genuinely different, it's not tunnelling but layering, IMHO. > Such in-flight re-routing could be quite helpful for mobility. Indeed. Well known examples of that include Mobile IP Home Agent, HIP rendezvous server and SPINAT, and the Previous Access Router in Fast MIP. Each of them does the thing slightly differently, though. Typically, in these examples the packet and the infra does not contain all of the required state, but only some of it. Some state is explicitly created at the re-routing point. > Of course, prior to the re-routing, an ICMP-type message would be > sent to tell the source mapping device that the destination was > unreachable so the re-routing would only need to be done for those > packets that were in-flight before the ICMP-type message made it > back to the source. This has even worse potential security problems, as you should be able to figure out with a few minutes of pondering. [I don't currently know any way to solve this security problem without having, somewhere, some state that includes the the identity of the re- routing point.] >> Oooh, there's multi-homing and there's multihoming! Keeping existing >> connections up is probably harder than allowing new connections to >> succeed. > > Not really. Since connections are established on the identifier, > the locators used in end-to-end transmission of packets is > irrelevant. An advantage of the identifier/locator split is that > connections can be maintained when transitions occur between one > locator to another. I concur. Getting the required signalling right, efficient, and secure, is not that trivial though. But by now we've done that a few times, in a few different ways. > With the model I'm thinking of, there would be NO additional > complexity in the end hosts nor (if you don't care about the re- > routing I mentioned above) in the routers. Whatever complexity > there is would be at the point of mapping. I'd be very sceptical. If we had no security problems to deal with, I might agree. However, given that we must plan for a large fraction of the net users trying to use any existing mechanisms, and combinations thereof, for their own benefit, disregarding the common good, things get a lot deal more complex. In the end of the day, we basically need more state that we would otherwise need, and secure enough means for setting up that state. --Pekka Nikander _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Dec 10 04:17:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtKnR-0008Oq-9Q; Sun, 10 Dec 2006 04:16:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtKnQ-0008Oc-8P for architecture-discuss@ietf.org; Sun, 10 Dec 2006 04:16:32 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtKnO-0005la-Kj for architecture-discuss@ietf.org; Sun, 10 Dec 2006 04:16:32 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 893CF213129; Sun, 10 Dec 2006 11:16:29 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 3943821311D; Sun, 10 Dec 2006 11:16:29 +0200 (EET) In-Reply-To: <20061209221431.EE34C86AE9@mercury.lcs.mit.edu> References: <20061209221431.EE34C86AE9@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [arch-d] Major practical decision Date: Sun, 10 Dec 2006 11:16:26 +0200 To: Noel Chiappa X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > Inevitably, you wind up structuring the new names as part of a > layer, or sub-layer (whatever/however you want to describe it). > (People may not think they are creating a new layer, but really, > they are.) The key point is that the location names go with the > lower of the two, and the identity names going > with the higher layer. Very well stated. > The big question is: "What do the exising IPvN addresses become?" > If they turn into identity, you wind up with a jack-up design, you > add a new lower layer and the new namespace is the lower-layer > locators; if they turn into locators, the new-namespace becomes > identity, and you wind up with SHIM6, HIP, etc, etc. Right. When answering this, IMHO it is important to keep two partly-distinct sets of questions in mind: 1. Architectural and technical. This is what we have most looked at so far. 2. Economic and deployment. This is at least as important. > If we go with jack-up, that means deploying a new namespace for > routing-names, and there are consequences during the deployment > (particularly during the early deployment phases, where I think the > problems are the worst) for the routing, which has to handle > (basically) two separate routing-name-spaces for a while. Which makes me to worry if we could get going with the jack-up model in the first place. What would be the deployment scenario? Would the costs and benefits fall largely to the same parties; or, alternatively, are there existing business relationships that allow the costs to be distributed to those that benefit? > There isn't the same immediate tie-in with routing for a new end- > end namespace (e.g. HIP), but even down that road, the growth of > the routing tables may still be too large to handle, and so perhaps > there's work to be done there too. Stating what I think is essentially the same point but differently, if we pick the way of a new layer above, we will need to work hard to reap the potential routing benefits from introducing the new end-end namespace. That is, a new end-end name space allows more freedom to routing as it allows more agile routing names, but it is far from clear how to utilise that freedom. Furthermore, the new layer-above may also allow different regions of the network to use different routing schemes; such regions could be connected by what would be, from today's point of view, kind-of architected NAT boxes. (Not quite that simple in practise but that should give the idea.) But again, there're lots of remaining work on a more detailed level. (I think I mostly agree with the rest of your message. In any case, I don't have anything to add to it.) --Pekka Nikander _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Dec 10 08:23:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtOdE-0000jp-G8; Sun, 10 Dec 2006 08:22:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtOdC-0000jf-QB for architecture-discuss@ietf.org; Sun, 10 Dec 2006 08:22:14 -0500 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtOdB-0001Pe-9J for architecture-discuss@ietf.org; Sun, 10 Dec 2006 08:22:14 -0500 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 2D03311145E; Sun, 10 Dec 2006 14:22:12 +0100 (CET) Received: from [163.117.203.209] (unknown [163.117.203.209]) by smtp01.uc3m.es (Postfix) with ESMTP id 11AC1111462; Sun, 10 Dec 2006 14:22:05 +0100 (CET) In-Reply-To: <20061209163929.216A686AE6@mercury.lcs.mit.edu> References: <20061209163929.216A686AE6@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <1d23e46f2752f493afed8005d2515e4e@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [arch-d] Major practical decision Date: Sun, 10 Dec 2006 14:22:11 +0100 To: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org El 09/12/2006, a las 17:39, Noel Chiappa escribi=F3: >> From: marcelo bagnulo braun > > Good questions! > > I think the problem is that it seems that people tend to either think=20= > about > i) how to do multi-homing, or ii) how to deploy something to prevent=20= > routing > meltdown (e.g. jack-up), and don't always think "how does the design=20= > do both"! > > So it's not immediately clear to me, for example, exactly how=20 > jack-up/mapping > schemes support multihoming. Yeah, the box that does mapping/wrapping=20= > could > know (from the mapping table) that IPvN address range X.1-X.n is=20 > multi-homed > because it maps to three different new routing-names, A.p, B.q and=20 > C.r, and > there's some mechanism (probably not in the routing itself) to make=20 > sure that > whichever one it picks is currently functional (i.e. not unreachable=20= > because > while A is reachable, the A<->A.p link has gone down, and the routing=20= > has > aggregated all A.* announcements to A by the time they get to this=20 > mapping > box). > > But, yeah, people thinking about one side of this (multi-homing, or=20 > routing > meltdown) need to pay attention to how their stuff does the other=20 > side.a > > >> what kind of approach could provide multihoming support (preserving >> established communications) > > Oooh, there's multi-homing and there's multihoming! Keeping existing > connections up is probably harder than allowing new connections to=20 > succeed. > When you say "preserving established communications", did you mean=20 > "keep > existing connection up", or what? > yes, that is what i meant. I mean, this is really difficult problem with multihoming, i think I can indeed think of mechanisms that would allow initiating new=20 communications after an outage has affected one of the paths, that does=20= not requires modifications to any device outside the multihomed site. otoh, i cannot think of any solution that does not require=20 modification/configuration to any device outside the multihomed site=20 and does keep exisiting connections up through an outage.... >> without requiring support from both peers of the communications? (by >> peers i mean either the end nodes themselves > > With enough thrust, pigs can fly. not this one afaict.... if you want to keep existing connections up through outages and not use=20= PI, you will need support in the non multihomed peer AFAICT > The question is, do you want them to fly?! > So I'm sure that with enough mechanism we could probably make this=20 > work. > However, do we want the additional complexity (and also, potentially, > overhead) to make it work - is this an important enough goal? very important question indeed what capabilities are we trying to support? there is a very big difference in the solutions that try to keep=20 existing connections up through outages and just allow initiate new=20 communications after an outage... i think Fred's suggestion of defining what are the goals of a solution=20= is really needed in order to understand what are we trying to=20 achieve... > >> If we do actually manage to define a solution that _only_ requires >> modifications to the multihomed site and does not requires >> modifications to the peers that it is communicating with (nor the the >> network outside the multihomed site) this would be indeed a really=20 >> nice >> feature > > Ditto... E.g. we sort of have this now, it's called PI-addresses, but=20= > the > overhead is not reasonable. > right, i was thinking in a new solution (any new solution) >> because only those who actually get the multihoming benefits have to >> pay the costs of supporting the multihoming support tools, which is >> very nice > > Well, presumably the other party gets some benefit too. I mean, if=20 > you're > trying to get to Google, or a news site, or an e-business site, and=20 > you can > because they are multi-homed, you get the benefit too, not just the=20 > site > you're going to. > >> i am not sure i have ever seen a proposal that does this.... > > Good point. > > >> could you expand? > > Sigh. The more I read this morning, the more I think we need to stop=20= > doing > this by email, and put 20 people together in a room for a couple of=20 > days, and > repeat that several times, with breaks of a couple of weeks in=20 > between, for > comment/recuperation. what about an interim meeting for this? interim meeting are nice because only very interested people attend... regards, marcelo > > There is just too much ground to cover, and too much to say about most=20= > parts > of it... > > > Noel > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Dec 11 07:02:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtjpf-0007Oa-LQ; Mon, 11 Dec 2006 07:00:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtjpd-0007OP-P7 for architecture-discuss@ietf.org; Mon, 11 Dec 2006 07:00:29 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtjpY-0003q2-84 for architecture-discuss@ietf.org; Mon, 11 Dec 2006 07:00:29 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id C1EC434070; Mon, 11 Dec 2006 07:00:25 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Dec 2006 07:00:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Major practical decision Date: Mon, 11 Dec 2006 07:00:19 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC010F2B0F@tayexc14.americas.cpqcorp.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Major practical decision Thread-Index: AccbnSqWFYaYdydAR4y2PyOdDlHnPABfpj6A From: "Bound, Jim" To: "Pekka Nikander" , "Noel Chiappa" X-OriginalArrivalTime: 11 Dec 2006 12:00:21.0683 (UTC) FILETIME=[EF24B030:01C71D1B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I believe we must separate transport end-to-end as one problem space and routing as another problem space completely thus I am not sure I agree or do not agree with the below but this is clearly not baked or agreed within this discussion so we must keep going. /jim=20 > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Sent: Saturday, December 09, 2006 9:19 AM > To: Noel Chiappa > Cc: architecture-discuss@ietf.org > Subject: Re: [arch-d] Major practical decision >=20 > On 8 Dec 2006, at 18:54, Noel Chiappa wrote: > > However, it's not clear to me that a new end-end naming=20 > layer (e.g. =20 > > SHIM6 or > > HIP) is really a viable solution, because of the amount of legacy=20 > > equipment out there. (And a top of the hatly hat to David=20 > Conrad for=20 > > first raising this > > issue.) I.e. if your site is multi-homed, and you've deployed HIP/=20 > > whatever, that's not much use if many of the people trying=20 > to talk to=20 > > you haven't. >=20 > What I think we need is a gradual, proxy based solution=20 > approach, as alleged e.g. by Marcelo Bagnulo. >=20 > Let's consider briefly what's behind that proposal. When=20 > deploying a new naming layer, we will have four kinds of=20 > situations: legacy- legacy, new-new, legacy-new and=20 > new-legacy. Legacy-legacy and new- new are, in general, not=20 > very interesting from an architectural point of view, even=20 > though there will be numerous engineering and security concerns there. >=20 > This leads to the following straw man analysis: >=20 > A. Legacy (site/host) connecting to a new (site/host) >=20 > A.a New (site/host) still providing legacy connectivity by=20 > publishing a legacy address >=20 > This is provided by both HIP and SHIM6, with the difference that > SHIM6 is oblivious whether the peer supports SHIM6 when the=20 > initial connection is made. With HIP, the choice must be=20 > currently made during initial contact, but there's been=20 > discussions about delayed HIP state set-up. >=20 > A.b New (site/host) being reachable only with the new=20 > connectivity (no published legacy address) >=20 > A.b.a New identifiers being routable in the legacy system >=20 > This is the interesting case, IMHO. If the new identifiers=20 > can be embedded into the legacy addressing system (e.g. as=20 > suggested in draft-laganier-ipv6-khi-05.txt), it may be=20 > possible to make them routable. For example, the prefix=20 > could be routed to one or a few sites in the core network,=20 > providing a service that would encapsulate the legacy traffic=20 > (along a similar way Mark Handley et al suggested in their=20 > e2efa paper) and provide connectivity to the new "world". >=20 > Any site adopting the new system could then, independently,=20 > provide the same encapsulation service locally, for those=20 > hosts that don't implement it natively. >=20 > A.b.b New identifiers not routable in the legacy system >=20 > This seems to lead to a situation where the legacy hosts are=20 > not able to communicate with new systems that do not provide=20 > legacy connectivity. This may be a desirable end state,=20 > providing the remaining legacy sites an incentive to upgrade. >=20 >=20 > B. New (site/host) connecting to a legacy (site/host) >=20 > B.a New (site/host) being able to directly connect with to=20 > legacy addresses >=20 > Again, this is provided by both HIP and SHIM6. >=20 > B.b New (site/host) not being able to directly connect with=20 > legacy systems >=20 > B.b.a "Reverse" proxy service >=20 > Under certain not-so-simple circumstances we could imagine a=20 > proxy service that would provide any interested legacy=20 > systems a "presence" =20 > in the new system. That is, any legacy host/site could=20 > register with the proxy service, the proxy service would=20 > allocate it an ID in the new system, and allow new=20 > sites/hosts connect to the legacy one through it. >=20 > I'm sure there are options I'm not listing above, but I must go now. >=20 > --Pekka Nikander >=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 Mon Dec 11 07:04:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtjtQ-0000RP-64; Mon, 11 Dec 2006 07:04:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtjtO-0000RK-TG for architecture-discuss@ietf.org; Mon, 11 Dec 2006 07:04:22 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtjtJ-0004gT-Ml for architecture-discuss@ietf.org; Mon, 11 Dec 2006 07:04:22 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id E8F7A34112; Mon, 11 Dec 2006 07:04:48 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Dec 2006 07:04:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Major practical decision Date: Mon, 11 Dec 2006 07:04:15 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC010F2B13@tayexc14.americas.cpqcorp.net> In-Reply-To: <0D917389-A8E9-4F0B-8569-D20A8D5044CD@virtualized.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Major practical decision Thread-Index: AccbxdWqdOZhDl3HRV+A1Q8DJtVDPgBVkzMQ From: "Bound, Jim" To: "David Conrad" , "Noel Chiappa" X-OriginalArrivalTime: 11 Dec 2006 12:04:17.0291 (UTC) FILETIME=[7B939DB0:01C71D1C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org =20 =20 > One of the reasons I think a tunneling approach is the right=20 > way to go is that it allows for in-flight re-routing to=20 > occur. That is, when the packet reaches a point where the=20 > unreachability of the final destination can be determined,=20 > the router at which the unreachability was discovered _could_=20 > (isn't required) de-encapsulate, check the mapping for the=20 > destination identifier for an alternative destination=20 > locator, and if one exists, forward it on. >=20 > Such in-flight re-routing could be quite helpful for mobility. I do not think mobility is a special case for this work and it is solved through current IETF work in multiple working groups now not our concern here?=20 Still thinking about the rest of your response. Best, /jim=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Dec 11 07:10:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtjyV-0002E8-9i; Mon, 11 Dec 2006 07:09:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtjyT-0002E2-Om for architecture-discuss@ietf.org; Mon, 11 Dec 2006 07:09:37 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtjyO-0005aP-IL for architecture-discuss@ietf.org; Mon, 11 Dec 2006 07:09:37 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 276B73407D; Mon, 11 Dec 2006 07:09:38 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Dec 2006 07:09:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Major practical decision Date: Mon, 11 Dec 2006 07:09:30 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC010F2B17@tayexc14.americas.cpqcorp.net> In-Reply-To: <20061209221431.EE34C86AE9@mercury.lcs.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Major practical decision Thread-Index: Accb32iDiJSDJTqcTzSeb4vtVIwzEgBPW9ww From: "Bound, Jim" To: "Noel Chiappa" , X-OriginalArrivalTime: 11 Dec 2006 12:09:32.0289 (UTC) FILETIME=[37547F10:01C71D1D] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org =20 > The question of whether we add a new end-end namespace, or a=20 > new routing-names namespace (which is really the same=20 > question as whether the existing IPvN addresses become=20 > identity or location) isn't really a routing issue. Whatever=20 > we do, there's going to be one namespace for routing-names,=20 > and the routing's going to have to do path selection. I think we need two new name spaces. How we do *new* routing and how we do *new* end-to-end semantics I think are separate tasks. The transition will require jack-up but eventually the jack-up should not be required in either case. Where we can use existing tools to help is probably a wise excercise depending on our time-to-market resolution to IAB concerns. /jim _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Dec 11 07:14:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtk2T-0004Yc-FU; Mon, 11 Dec 2006 07:13:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtk2S-0004Xn-ME for architecture-discuss@ietf.org; Mon, 11 Dec 2006 07:13:44 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gtk2N-0006Ie-9m for architecture-discuss@ietf.org; Mon, 11 Dec 2006 07:13:44 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id C43C73400E; Mon, 11 Dec 2006 07:13:45 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Dec 2006 07:13:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [arch-d] Major practical decision Date: Mon, 11 Dec 2006 07:13:37 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC010F2B19@tayexc14.americas.cpqcorp.net> In-Reply-To: <7CB1051B-058D-4F6B-BD89-74C82990A568@nomadiclab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Major practical decision Thread-Index: AcccNmYIEPy3ZpoJR/SDS8QoRkkrXQA5xYSQ From: "Bound, Jim" To: "Pekka Nikander" , "David Conrad" X-OriginalArrivalTime: 11 Dec 2006 12:13:38.0928 (UTC) FILETIME=[CA569F00:01C71D1D] X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: Noel Chiappa , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Just for the record I do not agree with the security issues Marcelo and Pekka consistently state at the SHIM6, HIP, or transport layer in general and we have agreed to disagree on SHIM6. But for this all important routing exercise et al I suggest we not cloud the first incantation of a routing analysis with security until we have something more concrete to debate regarding the security and we hear all ideas and thoughts to develop a "model", and then determine the insecure inherent parts of that model. /jim > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Sent: Sunday, December 10, 2006 3:34 AM > To: David Conrad > Cc: Noel Chiappa; architecture-discuss@ietf.org > Subject: Re: [arch-d] Major practical decision >=20 > > One of the reasons I think a tunneling approach is the=20 > right way to go=20 > > is that it allows for in-flight re-routing to occur. That is, when=20 > > the packet reaches a point where the unreachability of the final=20 > > destination can be determined, the router at which the=20 > unreachability=20 > > was discovered _could_ (isn't required) de- encapsulate, check the=20 > > mapping for the destination identifier for an alternative=20 > destination=20 > > locator, and if one exists, forward it on. >=20 > If I understand you correctly, what you are saying is the following: >=20 > 1. Consider packets that have two nested headers, the outer=20 > one carrying a locator and the inner one an identifier. >=20 > 2. The identifiers have global scope in the sense that any=20 > "router at which the unreachability [is] discovered" can=20 > resolve the identifier to another locator. >=20 > 2a. In order to map the identifier into a locator at any=20 > point of the =20 > network, a global infrastructure for doing the mapping is needed. =20 > The current IP routing system is one particular example of=20 > such an global infrastructure (I'm disregarding the well=20 > known limitations of the IP system here). >=20 > Note that this model has been applied already at different=20 > points in the network in its non-tunnelling and tunnelling=20 > forms, cf. e.g. =20 > MPLS. Hence, as an architectural pattern it is not new. =20 > Most variations can be found on how the infrastructure works. >=20 > Now, the problem with this model is security. The basic=20 > attack scenario is a DDoS attacker using the re-routing=20 > mechanism to disperse attack traffic through as many points=20 > as possible. In general, either the re-routing point must=20 > somehow gain assurance that the re-routing in question is=20 > legitimate or the packets must somehow be=20 > self-authenticating, legitimising the re-routing. The=20 > typical mechanisms today utilise encapsulation only within=20 > one security domain (cf. MPLS) or explicitly create some=20 > minimal state at the re- routing point. >=20 > Finally, I would consider such construction tunnelling only=20 > if the inner and outer header have the same syntax and the=20 > locators and identifiers are drawn from a single name space=20 > (or, at least, from syntactically similar names spaces, if=20 > you prefer Noel's stricter name space definition). If the=20 > headers or identifiers are genuinely different, it's not=20 > tunnelling but layering, IMHO. >=20 > > Such in-flight re-routing could be quite helpful for mobility. >=20 > Indeed. Well known examples of that include Mobile IP Home=20 > Agent, HIP rendezvous server and SPINAT, and the Previous=20 > Access Router in =20 > Fast MIP. Each of them does the thing slightly differently,=20 > though. =20 > Typically, in these examples the packet and the infra does=20 > not contain all of the required state, but only some of it. =20 > Some state is explicitly created at the re-routing point. >=20 > > Of course, prior to the re-routing, an ICMP-type message=20 > would be sent=20 > > to tell the source mapping device that the destination was=20 > unreachable=20 > > so the re-routing would only need to be done for those packets that=20 > > were in-flight before the ICMP-type message made it back to the=20 > > source. >=20 > This has even worse potential security problems, as you=20 > should be able to figure out with a few minutes of pondering.=20 > [I don't currently know any way to solve this security=20 > problem without having, somewhere, some state that includes=20 > the the identity of the re- routing point.] >=20 > >> Oooh, there's multi-homing and there's multihoming!=20 > Keeping existing=20 > >> connections up is probably harder than allowing new connections to=20 > >> succeed. > > > > Not really. Since connections are established on the=20 > identifier, the=20 > > locators used in end-to-end transmission of packets is=20 > irrelevant. An=20 > > advantage of the identifier/locator split is that=20 > connections can be=20 > > maintained when transitions occur between one locator to another. >=20 > I concur. Getting the required signalling right, efficient,=20 > and secure, is not that trivial though. But by now we've=20 > done that a few times, in a few different ways. >=20 > > With the model I'm thinking of, there would be NO additional=20 > > complexity in the end hosts nor (if you don't care about the re-=20 > > routing I mentioned above) in the routers. Whatever=20 > complexity there=20 > > is would be at the point of mapping. >=20 > I'd be very sceptical. If we had no security problems to=20 > deal with, I might agree. However, given that we must plan=20 > for a large fraction of the net users trying to use any=20 > existing mechanisms, and combinations thereof, for their own=20 > benefit, disregarding the common good, things get a lot deal=20 > more complex. In the end of the day, we basically need more=20 > state that we would otherwise need, and secure enough means=20 > for setting up that state. >=20 > --Pekka Nikander >=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 Mon Dec 11 10:00:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtmct-0008PJ-TL; Mon, 11 Dec 2006 09:59:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtAUE-0000La-Li; Sat, 09 Dec 2006 17:16:02 -0500 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtAUD-0008Hm-5U; Sat, 09 Dec 2006 17:16:02 -0500 Received: from 199.13.wireless.icannsaopaulo.br (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id kB9M9LSv005182; Sat, 9 Dec 2006 14:09:29 -0800 (PST) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by 199.13.wireless.icannsaopaulo.br (PGP Universal service); Sat, 09 Dec 2006 20:15:51 -0200 X-PGP-Universal: processed; by 199.13.wireless.icannsaopaulo.br on Sat, 09 Dec 2006 20:15:51 -0200 In-Reply-To: <121fd274017de9e61550cf58bb93856e@it.uc3m.es> References: <20061209163929.216A686AE6@mercury.lcs.mit.edu> <0D917389-A8E9-4F0B-8569-D20A8D5044CD@virtualized.org> <121fd274017de9e61550cf58bb93856e@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <61FBE837-2CE1-41F3-AA01-4BCC1C657F52@virtualized.org> From: David Conrad Subject: Re: [arch-d] Major practical decision Date: Sat, 9 Dec 2006 20:15:39 -0200 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 X-Mailman-Approved-At: Mon, 11 Dec 2006 09:59:31 -0500 Cc: ram@iab.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org [I've redirected this to ram@iab.org, bcc'ing arch-d since this is talking more about an implementation model than a theoretical model. I've gathered the feeling is that discussion about what Noel calls the "jack up" approach such as this should occur on ram instead of arch-d.] Marcelo, Just to be clear, my focus has been to try to come up with a model that would minimize the number of changes that would need to be made to deployed systems as I believe this significantly improves the chances that stuff will actually get deployed. While I would love to see a clean-sheet architecture, I'll admit to being a bit too cynical to believe it would ever get deployed. On Dec 9, 2006, at 6:23 PM, marcelo bagnulo braun wrote: > i am not sure i understand what you have in mind, but the peer that > is communicating with host within the multihomed site will need to > know the identifier and all the locators, so it can encapsulate > with all the different locators, right? No. The source "host" would only need to know about the identifier of the destination "host" (discoverable via DNS as normal). The multiple locators would be bound to the identifier later. I think it is actually fairly important that the "host" _not_ know about locators as the alternative is a layering violation that ends up causing a lot of problems in the end. In the model I've argued for, the mapping from identifier to locator would occur at the "edge" (where the "edge" could be anywhere from the source device to the first hop router to the ISP/end site boundary). At this mapping device/"edge" router, the packet would be encapsulated with the destination address being one of the set of locators associated with the identifier. At the destination mapping device/"edge" router, the packet would be de-encapsulated and forwarded on to the destination identifier. > If this is the case, the peer (or some box near the peer) needs to > support whatever protocol are used to securely exchange the > identifier and locator set. Yes, in the sense that the mapping needs to be propagated somehow, either some push mechanism (e.g., a flooding protocol or as a BGP attribute or whatever) or a pull mechanism (e.g., something like the DNS). If you use the DNS, you could have something like: ; dest identifier RR dst locator pref 1.2.3.4.5.6.7.8.9.a.b.c.d.e.f.0.loc.arpa. IN LOC a000::0001 100 ... b000::0002 200 ... c000::0003 300 ... which could be secured with DNSSEC (assuming it ever gets deployed). > This box needs to be deployed, hence, we need support outside the > multihomed site, right? I think I see what you're saying. So, there are 4 cases: 1) unmapped source, unmapped destination: this is what we have now. 2) mapped source, mapped destination: this would be the goal. 3) mapped source, unmapped destination: if the destination is reachable via the "legacy" routing system, this would work if the mapping service is able to determine that the destination is not mapped and fall back to case 1. For this to work, the source identifier would have to be routable, perhaps sub-optimally, in the "legacy" routing system. 4) unmapped source, mapped destination: since the source knows nothing about mapping, the only way the destination would be reachable is if the destination identifier is routable, perhaps sub- optimally, in the "legacy" routing system. Given this, as a transition mechanism, the existing "addresses" (which I'm defining to be the merged identifier/locator blob of bits we have in the source and destination fields of IP packets now) would be treated as identifiers if they are mapped and locators if they aren't. The mapping device/"edge" router would make the determination on the fly based on whether the mapping succeeded or failed. So, yes, there would need to be some support outside the multi-homed site to take advantage of the multi-homing (etc.), but things will still work, perhaps sub-optimally, without it. Rgds, -drc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Dec 11 10:50:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtnPZ-0003w5-HK; Mon, 11 Dec 2006 10:49:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtnPX-0003vP-JX for architecture-discuss@ietf.org; Mon, 11 Dec 2006 10:49:47 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtnPV-0000zs-61 for architecture-discuss@ietf.org; Mon, 11 Dec 2006 10:49:47 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id D7D0E86AE4; Mon, 11 Dec 2006 10:49:42 -0500 (EST) To: architecture-discuss@ietf.org Subject: RE: [arch-d] Major practical decision Message-Id: <20061211154942.D7D0E86AE4@mercury.lcs.mit.edu> Date: Mon, 11 Dec 2006 10:49:42 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: "Bound, Jim" >> The question of whether we add a new end-end namespace, or a new >> routing-names namespace > I think we need two new name spaces. Actually, as I was thinking all this over last night, I decided that I had missed one option I had spoken of earlier, which is (exactly as you say) to have two new namespaces; one for routing-name, and one for end-end identity. I.e. migrate out of the existing IPvN "addresses" in both directions at once. However, I worry that that will be a bit much for everyone to swallow! :-) > The transition will require jack-up but eventually the jack-up should > not be required in either case. Well, by "jack-up" I simply mean the insertion of a new layer. *How* that happens I was not yet discussing (as Pekka pointed out, that's to some degree orthagonal to more basic questions like "how many namespaces"). I would assume that initially it would be done invisibly to the hosts, by "mapping boxes" acting on their behalf (so we don't need to change any hosts), but that over time hosts might become aware of the existence of another layer down there. I may be misunderstanding the implications of your comment, but let me see if this is what you meant: were you saying that initial deployment of jack-up would be invisible to hosts, but that eventually we might dispense with the mapping boxes, and the hosts would do it all themselves? I say that because if the jack-up inserts a new layer which is used for routing, I can't see how we'd ever be able to stop using that new layer (which is what your comment "eventually the jack-up should not be required" might be read to mean). > Where we can use existing tools to help is probably a wise excercise > depending on our time-to-market resolution to IAB concerns. Do you mean that we might re-cycle existing protocols/code for the new higher and lower layers? I agree that's a good goal, but I would not like to cramp long-term development by insisting that we have to use the most simplistic option. E.g. if we do jack-up, I'd like to use MPLS as the inter-router forwarding element of the new internetworking layer, rather than IPvN. The original IPv4 architecture assumed the same packet format for inter-router communication as for host-router communication, but I'm not sure that simplification is really apt anymore in such a large system (since larger systems always benefit from more specialization). Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Dec 12 11:53:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuApt-000604-Ht; Tue, 12 Dec 2006 11:50:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuAps-0005zi-Ec for architecture-discuss@ietf.org; Tue, 12 Dec 2006 11:50:32 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuApp-0003mI-Re for architecture-discuss@ietf.org; Tue, 12 Dec 2006 11:50:32 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id 28A8D4AC6E; Tue, 12 Dec 2006 11:50:27 -0500 (EST) Date: Tue, 12 Dec 2006 11:50:27 -0500 From: John Leslie To: "Bound, Jim" Message-ID: <20061212165027.GA60450@verdi> References: <816DD9299957E547B5D758D7F977D6DC010F2B0F@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <816DD9299957E547B5D758D7F977D6DC010F2B0F@tayexc14.americas.cpqcorp.net> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: architecture-discuss@ietf.org Subject: [arch-d] Do we have "partial consensus"? X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Bound, Jim wrote: > > I believe we must separate transport end-to-end as one problem space and > routing as another problem space completely... I agree with Jim, and I'd like to try for a first pass at consensus on architecture. I don't have enough time right now to break down the portion of this that we _do_ agree on, so please feel free to work this over in search of consensus. However, we need to _be_ "in search of consensus" about "architecture". This must not deteriorate into factions arguing "positions". I will try to outline areas of questions; but first please let me do a complete statement: I welcome discussion of the issues I'll name, and I welcome listing other areas of question. I'm even OK with, "you're so far out of it that you need to go away for a week or two!" (This is not intended to be a complete statement: there are many other issues we must address. I believe those can be deferred until after we reach consensus on this much.) Statement: We want to work towards an architecture with separate "layers" for "routing" and "transport", where "routing" is responsible for - delivering packets to destinations on the same network; - forwarding the other packets to another network "closer" to their destination; - dropping the other packets if no "closer" network is available; - building forwarding tables believed to be loop-free; - detecting loops in forwarding paths actually used; - dropping packets which would cause excessive congestion; and "transport" is responsible for - detecting and adjusting for packet loss; - detecting and adjusting for packet corruption; - reducing packet injection rate when a path is congested; - choosing among multiple paths (if available). Question Areas: - is there a better name than "layers" for these problem spaces? - is there a better name than "routing" for the lower "layer"? - is there a better name than "transport" for the upper "layer"? - are any of the responsibilities clearly assigned to the wrong "layer"? - are we ready to agree to define separate namespaces for these "layers"? (I know there are other responsibilities which _must_ be assigned before we can have a working system: I'd _really_ prefer not to argue where they belong yet...) -- John Leslie _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Dec 12 13:25:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuCIR-0003Ku-EO; Tue, 12 Dec 2006 13:24:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuCIP-0003Jd-Vs for architecture-discuss@ietf.org; Tue, 12 Dec 2006 13:24:05 -0500 Received: from imo-d22.mx.aol.com ([205.188.144.208]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuCGC-0006Pe-4J for architecture-discuss@ietf.org; Tue, 12 Dec 2006 13:21:48 -0500 Received: from HeinerHummel@aol.com by imo-d22.mx.aol.com (mail_out_v38_r7.6.) id o.c5a.7edb897 (14467); Tue, 12 Dec 2006 13:21:32 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Tue, 12 Dec 2006 13:21:29 EST Subject: Re: [arch-d] Do we have "partial consensus"? To: john@jlc.net, Jim.Bound@hp.com MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5009 X-Spam-Flag: NO X-Spam-Score: 0.7 (/) X-Scan-Signature: 850245b51c39701e2700a112f3032caa 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="===============0818602207==" Errors-To: architecture-discuss-bounces@ietf.org --===============0818602207== Content-Type: multipart/alternative; boundary="-----------------------------1165947689" -------------------------------1165947689 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 I have a different list of objectives: - develop an architecture which fits even for a 100 times bigger internet=20 while the workload for the individual router becomes 100 times less than is= =20 necessary today (obviously it can only be hierarchical; compare: 100 +100+1= 00=20 +100=3D 400 while 100 x100x100x100 =3D100 ,000,000. Will say, by knowing the hierarchical network topology of 100 nodes+300=20 hierarchical nodes the same can be accomplished than be learning about 100=20 million routers. =20 -develop a one-face-only architecture (rather than a collection of =20 completely orthogonal concepts like BGP versus OSPF) PNNI at least tried to accomplish such a one-face-only architecture. It was=20= =20 later, in response to PNNI, that OSPF came up with areas (simpler,less =20 ambitious, but not as perfect in design). =20 -do routing such that fear of loops doesn't have to be at all. =20 -do routing such that real-time traffic balancing is enabled =20 =20 -do clean cuts:=20 a)at the edges: the used technology there (LAN,WLAN,...) is outside the =20 scope. b)wrt. layering and also within the routing protocol: flooding is needed fo= r=20 detecting the topology. As soon as the topology is provided, loopfree=20 propagation/advertisement of whatsoever can be done better than by flooding= .If it=20 is not routing relevant but rather end-to-end relevant it should not even b= e=20 part ot routing. Compare: Neither OSPF- nor IDR-WG will ever be shut down. They may sleep =20 eventually while waiting for some new topic, as to get their shares just l= ike=20 the MIB-folks would get. This however is due to the lack of a clean cut. I don't like the idea of a =20 building which is never completed. c) wrt. addressing: PNNI tried to handle at least 3 prefix-summarizable address families ( IPv4= =20 not counted in) of users. Obviously all of them could not be used for=20 identifying PNNI-nodes concurrently. User addresses must not be mixed up wi= th=20 (hierarchical) nodes' addresses. =20 =20 Heiner =20 =20 =20 =20 =20 =20 In einer eMail vom 12.12.2006 17:52:37 Westeurop=E4ische Normalzeit schreibt= =20 john@jlc.net: Bound, Jim wrote: >=20 > I believe we must separate transport end-to-end as one problem space and > routing as another problem space completely... I agree with Jim, and I'd like to try for a first pass at consensus on architecture. Statement: We want to work towards an architecture with separate "layers" for "routing" and "transport", where "routing" is responsible for - delivering packets to destinations on the same network; - forwarding the other packets to another network "closer" to their destination; - dropping the other packets if no "closer" network is available; - building forwarding tables believed to be loop-free; - detecting loops in forwarding paths actually used; - dropping packets which would cause excessive congestion; and "transport" is responsible for - detecting and adjusting for packet loss; - detecting and adjusting for packet corruption; - reducing packet injection rate when a path is congested; - choosing among multiple paths (if available). Question Areas: - is there a better name than "layers" for these problem spaces? - is there a better name than "routing" for the lower "layer"? - is there a better name than "transport" for the upper "layer"? - are any of the responsibilities clearly assigned to the wrong "layer"? - are we ready to agree to define separate namespaces for these "layers"? (I know there are other responsibilities which _must_ be assigned before we can have a working system: I'd _really_ prefer not to argue where they belong yet...) -- John Leslie _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss -------------------------------1165947689 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
I have a different list of objectives:
- develop an architecture which fits even for a 100  times bigger=20 internet while the workload for the individual router becomes 100 times= =20 less than is necessary today (obviously it can only be hierarchical; compare= :=20 100 +100+100 +100=3D 400 while 100 x100x100x100 =3D100 ,000,000.
Will say, by knowing  the hierarchical network=20 topology of  100 nodes+300 hierarchical nodes the same can be=20 accomplished than be learning about 100 million routers.
 
-develop a one-face-only architecture (rather than a collection of=20 completely orthogonal concepts like BGP versus OSPF)
PNNI at least tried to accomplish such a one-face-only architecture. It= was=20 later, in response to PNNI, that OSPF came up with areas (simpler,less=20 ambitious, but not as perfect in design).
 
-do routing such that   fear of loops doesn't have to  b= e at=20 all.
 
-do routing such that real-time traffic balancing is enabled 
 
-do clean cuts:
a)at the edges: the used technology there (LAN,WLAN,...) is outside the= =20 scope.
b)wrt. layering and also within the routing protocol: flooding is neede= d=20 for detecting the topology. As soon as the topology is provided,=20 loopfree propagation/advertisement of whatsoever can be done better tha= n by=20 flooding.If it is not routing relevant but rather end-to-end relevant it sho= uld=20 not even be part ot routing.
Compare: Neither OSPF- nor IDR-WG will ever be shut down. They may slee= p=20 eventually while waiting for some  new topic, as to get their shar= es=20 just like the MIB-folks would get.
This however is due to the lack of a clean cut. I don't like the idea o= f a=20 building which is never completed.
c) wrt. addressing:
PNNI tried to handle at least 3 prefix-summarizable address families (=20  IPv4 not counted in) of users. Obviously all of them could not be= =20 used for identifying PNNI-nodes concurrently. User addresses must not be mix= ed=20 up with (hierarchical) nodes' addresses.
 
 
Heiner
 
 
 
 
 
 
In einer eMail vom 12.12.2006 17:52:37 Westeurop=E4ische Normalzeit sch= reibt=20 john@jlc.net:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>Bound,=20 Jim <Jim.Bound@hp.com> wrote:
>
> I believe we must=20 separate transport end-to-end as one problem space and
> routing as=20 another problem space completely...

   I agree with Jim,=20= and=20 I'd like to try for a first pass at consensus=20 on
architecture.

   Statement:

   We=20= want=20 to work towards an architecture with separate "layers" for
"routing" an= d=20 "transport", where "routing" is responsible for
- delivering packets to= =20 destinations on the same network;
- forwarding the other packets to ano= ther=20 network "closer" to their
  destination;
- dropping the other=20 packets if no "closer" network is available;
- building forwarding tabl= es=20 believed to be loop-free;
- detecting loops in forwarding paths actuall= y=20 used;
- dropping packets which would cause excessive congestion;
and= =20 "transport" is responsible for
- detecting and adjusting for packet=20 loss;
- detecting and adjusting for packet corruption;
- reducing pa= cket=20 injection rate when a path is congested;
- choosing among multiple path= s=20 (if available).

Question Areas:

- is there a better name tha= n=20 "layers" for these problem spaces?

- is there a better name than=20 "routing" for the lower "layer"?

- is there a better name than=20 "transport" for the upper "layer"?

- are any of the responsibilitie= s=20 clearly assigned to the wrong "layer"?

- are we ready to agree to=20 define separate namespaces for these "layers"?

   (I know= =20 there are other responsibilities which _must_ be assigned
before we can= =20 have a working system: I'd _really_ prefer not to argue
where they belo= ng=20 yet...)

--
John Leslie=20 <john@jlc.net>

______________________________________________= _
Architecture-discuss=20 mailing=20 list
Architecture-discuss@ietf.org
https://www1.ietf.org/mailman/lis= tinfo/architecture-discuss
 
 -------------------------------1165947689-- --===============0818602207== 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 --===============0818602207==-- From architecture-discuss-bounces@ietf.org Tue Dec 12 13:48:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuCfU-0003yX-5m; Tue, 12 Dec 2006 13:47:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuCfS-0003yP-TM for architecture-discuss@ietf.org; Tue, 12 Dec 2006 13:47:54 -0500 Received: from web31804.mail.mud.yahoo.com ([68.142.207.67]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GuCfO-00039u-HR for architecture-discuss@ietf.org; Tue, 12 Dec 2006 13:47:54 -0500 Received: (qmail 53388 invoked by uid 60001); 12 Dec 2006 18:47:50 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=EI3ejcSNvyAb7BKA8o4/gTFS+OWsn+xKVqAXCpfyzcNinITXSPmQrASfvYXL1RRqE0WIZYD9AtD5v9iK6Q17etuqTWH80FRR17T4fhrKZVZ8uyo4IVJMPFd9+iJGP5fu6t/O1kHculX5w59m6EXmp5W3GtDKg62PUsDy5/W38Ko=; X-YMail-OSG: hRzgjrcVM1nAwuh0NMv0twYyG_XmydPNIUYyFsUR Received: from [162.130.197.18] by web31804.mail.mud.yahoo.com via HTTP; Tue, 12 Dec 2006 10:47:49 PST Date: Tue, 12 Dec 2006 10:47:49 -0800 (PST) From: David Barak Subject: Re: [arch-d] Do we have "partial consensus"? To: architecture-discuss@ietf.org In-Reply-To: <20061212165027.GA60450@verdi> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <911982.53372.qm@web31804.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org My disagreements are in-line --- John Leslie wrote: > Bound, Jim wrote: > Statement: > > We want to work towards an architecture with > separate "layers" for > "routing" and "transport", where "routing" is > responsible for > - delivering packets to destinations on the same > network; Define "network" in this context - normally, I think of routing as something done by a router: that is to say a node, not by a network. Networks are destinations, or logical groupings of nodes. > - forwarding the other packets to another network > "closer" to their destination; Do you mean to other nodes? > - dropping the other packets if no "closer" network > is available; > - building forwarding tables believed to be > loop-free; Today, it could be argued that forwarding and routing occupy different sub-layers: do you mean that they should be re-merged? > - detecting loops in forwarding paths actually used; Do you mean that the routing layer of a given node's stack should maintain state on every packet which passes, and check to see if it is seen again? The goals of rapidly determining to which interface to forward a given packet, and maintaining historical state information about that packet conflict. Routing is connectionless today - do you mean to imply that it should become connection-oriented? > - dropping packets which would cause excessive > congestion; Based on what, and where? If a packet I send will cause excessive congestion 3 hops down the path, should I drop the packets? Congestion is either the result of an overburdened processor attempting to figure out what to do with packets, or it's trying to shove more packets through an interface than the interface can take. Should taking into account interface sizing become a routing-layer function, or is that best left to a physical or data-link layer to determine? > and "transport" is responsible for > - detecting and adjusting for packet loss; > - detecting and adjusting for packet corruption; > - reducing packet injection rate when a path is > congested; > - choosing among multiple paths (if available). I was okay until I got here :) If you do that, you lose the benefit of in-band signalling, and are more likely to have the routing and transport layers disagree about what the optimum path is. > > Question Areas: > > - is there a better name than "layers" for these > problem spaces? > > - is there a better name than "routing" for the > lower "layer"? If you break up the lower layer into "routing, forwarding, link, and physical" you'd have a cleaner separation. physical - what it sounds like link - framing, hop-by-hop compression, priority, & queueing forwarding - sending traffic to the network on which one resides (connected routing) routing - sending traffic to distant networks (recursive forwarding) -David David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Dec 12 14:20:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuD9O-0007G5-Ah; Tue, 12 Dec 2006 14:18:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuD9N-0007Fz-K6 for architecture-discuss@ietf.org; Tue, 12 Dec 2006 14:18:49 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuD9L-000124-E5 for architecture-discuss@ietf.org; Tue, 12 Dec 2006 14:18:49 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id DE6B54ACC3; Tue, 12 Dec 2006 14:18:43 -0500 (EST) Date: Tue, 12 Dec 2006 14:18:43 -0500 From: John Leslie To: HeinerHummel@aol.com Subject: Re: [arch-d] Do we have "partial consensus"? Message-ID: <20061212191843.GC68573@verdi> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I dare to assume Heiner didn't intend " " you're so far out of it that you need to go away for a week or two!" HeinerHummel@aol.com wrote: > > I have a different list of objectives: > > - develop an architecture which fits even for a 100 times bigger > internet while the workload for the individual router becomes > 100 times less than is necessary today I agree with this objective. Speaking only for myself: I specifically tried to minimize the "routing" "layer" task. My list contains _only_ the things I think can't be moved to another layer, and specifically excludes finding alternate paths if forwarding isn't possible. > Will say, by knowing the hierarchical network topology of 100 nodes+300 > hierarchical nodes the same can be accomplished than be learning about > 100 million routers. Again speaking only for myself: In describing "layer" responsibilities I did not intend that all must be accomlished in the same box. I can easily imagine totally separating the "routing protocol" boxes from the "forwarding" boxes. > - develop a one-face-only architecture (rather than a collection of > completely orthogonal concepts like BGP versus OSPF) > PNNI at least tried to accomplish such a one-face-only architecture. > It was later, in response to PNNI, that OSPF came up with areas > (simpler,less ambitious, but not as perfect in design). This sounds like it deserves its own thread... > -do routing such that fear of loops doesn't have to be at all. Hmm... I don't think "routing gurus" will get over that fear in my lifetime! > -do routing such that real-time traffic balancing is enabled Speaking only for myself: I don't think the "routing" "layer" can do any more for that than signal what bandwidth is available to particular destinations (currently CIDR block) forwarded from each forwarder's individual peers. Even that much begins to intrude on Heiner's first principle (scaling by a factor of 100). > - do clean cuts: > > a) at the edges: the used technology there (LAN,WLAN,...) is outside > the scope. I'd be happy to agree to that. However, the question seems premature. > b) wrt. layering and also within the routing protocol: flooding is > needed for detecting the topology. As soon as the topology is > provided, loopfree propagation/advertisement of whatsoever can be > done better than by flooding. If it is not routing relevant but > rather end-to-end relevant it should not even be part of routing. Feel free to start a new thread on this issue. (I'm not sure I understand your point well enough to respond yet.) > c) wrt. addressing: > PNNI tried to handle at least 3 prefix-summarizable address > families (IPv4 not counted in) of users. Obviously all of them > could not be used for identifying PNNI-nodes concurrently. > User addresses must not be mixed up with (hierarchical) nodes' > addresses. I agree it's important for us to _architecturally_ distinguish them. I doubt, however, we will be able to prevent users from confusing them. -- John Leslie _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Dec 12 14:50:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuDct-0004hX-9e; Tue, 12 Dec 2006 14:49:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuDcr-0004hP-Nj for architecture-discuss@ietf.org; Tue, 12 Dec 2006 14:49:17 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuDcq-0000OG-9W for architecture-discuss@ietf.org; Tue, 12 Dec 2006 14:49:17 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id 5431B4ACD2; Tue, 12 Dec 2006 14:49:15 -0500 (EST) Date: Tue, 12 Dec 2006 14:49:15 -0500 From: John Leslie To: David Barak Subject: Re: [arch-d] Do we have "partial consensus"? Message-ID: <20061212194915.GD68573@verdi> References: <20061212165027.GA60450@verdi> <911982.53372.qm@web31804.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <911982.53372.qm@web31804.mail.mud.yahoo.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org David Barak wrote: > --- John Leslie wrote: > >> Statement: >> >> We want to work towards an architecture with >> separate "layers" for "routing" and "transport", >> where "routing" is responsible for >> - delivering packets to destinations on the same >> network; > > Define "network" in this context - I don't feel able to do so. :^( (There may well be a better name for this "layer"...) > normally, I think of routing as something done by a router: > that is to say a node, not by a network. Agreed. Perhaps "forwarding" might be a better name? >> - forwarding the other packets to another network >> "closer" to their destination; > > Do you mean to other nodes? I think I mean "network" (even if I can't define it!). >> - dropping the other packets if no "closer" network >> is available; >> - building forwarding tables believed to be >> loop-free; > > Today, it could be argued that forwarding and routing > occupy different sub-layers: do you mean that they > should be re-merged? No. >> - detecting loops in forwarding paths actually used; > > Do you mean that the routing layer of a given node's > stack should maintain state on every packet which > passes, and check to see if it is seen again? No. This function currently depends on a Time-to-Live field being decremented. I do not mean to imply it must be done that way, but IMHO the function cannot be avoided. > The goals of rapidly determining to which interface to > forward a given packet, and maintaining historical > state information about that packet conflict. Routing > is connectionless today - do you mean to imply that it > should become connection-oriented? Absolutely not! >> - dropping packets which would cause excessive >> congestion; > > Based on what, and where? Handwaving, mostly. ;^) > If a packet I send will cause excessive congestion 3 hops > down the path, should I drop the packets? Speaking only for myself: if you actually know that, yes. However, I did not intend to claim it's desirable to know that, or even that it's possible. > Congestion is either the result of an overburdened > processor attempting to figure out what to do with packets, > or it's trying to shove more packets through an interface > than the interface can take. Should taking into account > interface sizing become a routing-layer function, or > is that best left to a physical or data-link layer to > determine? I did not mean to express an opinion on that. That's among the (many) things I intended to defer discussion on. >> and "transport" is responsible for >> - detecting and adjusting for packet loss; >> - detecting and adjusting for packet corruption; >> - reducing packet injection rate when a path is >> congested; >> - choosing among multiple paths (if available). > > I was okay until I got here :) That line was a mistake! Please accept my apology!!! > If you do that, you lose the benefit of in-band > signalling, and are more likely to have the routing > and transport layers disagree about what the optimum > path is. Somehow my addled brain thought this would clarify my intent that the "routing" "layer" is not _required_ to find an alternate path "quickly" when a link goes down. Again, I was wrong to include this here, and I apologize! (If we later agree on separate namespaces for these "layers", I may introduce what I was actually thinking but failed to remove: that there may be more than one "routing-name" for a "transport-name", and that the "transport" "layer" would be permitted to choose which of them to pass to the "routing" "layer". Regardless, the whole question doesn't belong in this discussion, and I beg unanimous consent to remove it.) >> Question Areas: >> >> - is there a better name than "routing" for the >> lower "layer"? > > If you break up the lower layer into "routing, > forwarding, link, and physical" you'd have a cleaner > separation. Anybody else have an opinion? > physical - what it sounds like > link - framing, hop-by-hop compression, priority, > & queueing > forwarding - sending traffic to the network on which > one resides (connected routing) > routing - sending traffic to distant networks > (recursive forwarding) I had intended no change to "physical" or "link" -- though I'd be happy to see discussion under another thread about how "interface sizing" could be better split between "link" and "forwarding". -- John Leslie _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Dec 13 04:40:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuQYz-0004g0-VC; Wed, 13 Dec 2006 04:38:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuQYy-0004fv-Dp for architecture-discuss@ietf.org; Wed, 13 Dec 2006 04:38:08 -0500 Received: from imo-d20.mx.aol.com ([205.188.139.136]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuQYw-0000ij-V4 for architecture-discuss@ietf.org; Wed, 13 Dec 2006 04:38:08 -0500 Received: from HeinerHummel@aol.com by imo-d20.mx.aol.com (mail_out_v38_r7.6.) id o.cf0.481929a (29678); Wed, 13 Dec 2006 04:38:03 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Wed, 13 Dec 2006 04:38:01 EST Subject: Re: [arch-d] Do we have "partial consensus"? To: john@jlc.net MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5009 X-Spam-Flag: NO X-Spam-Score: 0.7 (/) X-Scan-Signature: 578c2c9d0cb01ffe6e1ca36540edd070 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="===============0614327857==" Errors-To: architecture-discuss-bounces@ietf.org --===============0614327857== Content-Type: multipart/alternative; boundary="-----------------------------1166002681" -------------------------------1166002681 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 Some more notes pro hierarchical routing: =20 PNNI : The PNNI architects are still around: Ross Callon, Joel Halpern, =20 George Swallow, Mickey Spiegel. It was a fine protocol development which w= ould=20 never have been accomplished if the Bell-heads had understood more of it :-= ).=20 PNNI contains good and less good things. From some distance that can be =20 distinguished even better as to learn from both. =20 There is also a nicely written draft from Frank Kastenholz: ISLAY. But fro= m=20 a single draft you cannot learn "by experience", particularly you cannot=20 learn from its worse parts.=20 =20 And: We all do hierarchical routing day by day.When it comes to travelling,=20= =20 at least in your mind you do combine the city map where your trip starts as=20= to=20 get to the right exit, the country road map as to get to the nearest=20 airport, a world map with all the flight routes as to get to the destinatio= n=20 airport. And while you haven't yet left the ingress city your routing decis= ions do=20 not consider any road labor blockings nearby the hotel of your destinatio= n. =20 I can only repeat myself: There is no better solution than HR, and also HR =20 is sufficiently precise. =20 Heiner =20 In einer eMail vom 12.12.2006 20:19:49 Westeurop=E4ische Normalzeit schreibt= =20 john@jlc.net: I dare to assume Heiner didn't intend=20 "=20 " you're so far out of it that you need to go away for a week or two!" HeinerHummel@aol.com wrote: > =20 > I have a different list of objectives: > =20 > - develop an architecture which fits even for a 100 times bigger > internet while the workload for the individual router becomes > 100 times less than is necessary today I agree with this objective. Speaking only for myself: I specifically tried to minimize the "routing" "layer" task. My list contains _only_ the things I think can't be moved to another layer, and specifically excludes finding alternate paths if forwarding isn't possible. > Will say, by knowing the hierarchical network topology of 100 nodes+300=20 > hierarchical nodes the same can be accomplished than be learning about > 100 million routers. Again speaking only for myself: In describing "layer" responsibilities I did not intend that all must be accomlished in the same box. I can easily imagine totally separating the "routing protocol" boxes from the "forwarding" boxes. > - develop a one-face-only architecture (rather than a collection of =20 > completely orthogonal concepts like BGP versus OSPF) > PNNI at least tried to accomplish such a one-face-only architecture. > It was later, in response to PNNI, that OSPF came up with areas > (simpler,less ambitious, but not as perfect in design). This sounds like it deserves its own thread... > -do routing such that fear of loops doesn't have to be at all. Hmm... I don't think "routing gurus" will get over that fear in my lifetime! > -do routing such that real-time traffic balancing is enabled =20 Speaking only for myself: I don't think the "routing" "layer" can do any more for that than signal what bandwidth is available to particular destinations (currently CIDR block) forwarded from each forwarder's individual peers. Even that much begins to intrude on Heiner's first principle (scaling by a factor of 100). > - do clean cuts: =20 >=20 > a) at the edges: the used technology there (LAN,WLAN,...) is outside > the scope. I'd be happy to agree to that. However, the question seems premature. > b) wrt. layering and also within the routing protocol: flooding is > needed for detecting the topology. As soon as the topology is > provided, loopfree propagation/advertisement of whatsoever can be > done better than by flooding. If it is not routing relevant but > rather end-to-end relevant it should not even be part of routing. Feel free to start a new thread on this issue. (I'm not sure I understand your point well enough to respond yet.) > c) wrt. addressing: > PNNI tried to handle at least 3 prefix-summarizable address > families (IPv4 not counted in) of users. Obviously all of them > could not be used for identifying PNNI-nodes concurrently. > User addresses must not be mixed up with (hierarchical) nodes' > addresses. I agree it's important for us to _architecturally_ distinguish them. I doubt, however, we will be able to prevent users from confusing them. -- John Leslie -------------------------------1166002681 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Some more notes pro hierarchical routing:
 
PNNI : The PNNI architects are still around: Ross Callon, Joel Halpern,= =20 George Swallow, Mickey Spiegel.  It was a fine protocol development whi= ch=20 would never have been accomplished if the Bell-heads had understood more of=20= it=20 :-). PNNI contains good and less good things. From some distance that can be= =20 distinguished even better as to learn from both.
 
There is also a nicely written draft from Frank Kastenholz: ISLAY.=20 But  from a single draft you cannot learn  "by experience",=20 particularly you cannot learn from its worse parts.
 
And: We all do hierarchical routing day by day.When it comes to travell= ing,=20 at least in your mind you do combine the city map where your trip starts as=20= to=20 get to the right exit, the country road map as to get to the nearest airport= , a=20 world map with all the flight routes as to get to the destination airport. A= nd=20 while you haven't yet left the ingress city your routing decisions do not=20 consider any road labor blockings nearby  the hotel of your=20 destination.
 
I can only repeat myself: There is no better solution than HR, and also= HR=20 is sufficiently precise.
 
Heiner
 
In einer eMail vom 12.12.2006 20:19:49 Westeurop=E4ische Normalzeit sch= reibt=20 john@jlc.net:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000=20 size=3D2>   I dare to assume Heiner didn't intend
"
" yo= u're=20 so far out of it that you need to go away for a week or=20 two!"

HeinerHummel@aol.com <HeinerHummel@aol.com>=20 wrote:
> 
> I have a different list of objectives:
&g= t;=20
> - develop an architecture which fits even for a 100 times=20 bigger
>   internet while the workload for the individual=20 router becomes
>   100 times less than is necessary=20 today

   I agree with this objective.

  = =20 Speaking only for myself: I specifically tried to minimize the
"routing= "=20 "layer" task. My list contains _only_ the things I think
can't be moved= to=20 another layer, and specifically excludes finding
alternate paths if=20 forwarding isn't possible.

> Will say, by knowing the hierarchic= al=20 network topology of 100 nodes+300
> hierarchical nodes the same can= be=20 accomplished than be learning about
> 100 million=20 routers.

   Again speaking only for myself: In describing= =20 "layer" responsibilities
I did not intend that all must be accomlished=20= in=20 the same box. I can
easily imagine totally separating the "routing=20 protocol" boxes from the
"forwarding" boxes.

> - develop a=20 one-face-only architecture (rather than a collection of =20
>   completely orthogonal concepts like BGP versus=20 OSPF)
> PNNI at least tried to accomplish such a one-face-only=20 architecture.
> It was later, in response to PNNI, that OSPF came up= =20 with areas
> (simpler,less ambitious, but not as perfect in=20 design).

   This sounds like it deserves its own=20 thread...

> -do routing such that fear of loops doesn't have to=20= be=20 at  all.

   Hmm...

   I don't think= =20 "routing gurus" will get over that fear in my lifetime!

> -do=20 routing such that real-time traffic balancing is enabled =20

   Speaking only for myself: I don't think the "routing"= =20 "layer" can do
any more for that than signal what bandwidth is availabl= e to=20 particular
destinations (currently CIDR block) forwarded from each=20 forwarder's
individual peers. Even that much begins to intrude on Heine= r's=20 first
principle (scaling by a factor of 100).

> - do clean cu= ts:=20
>
>   a) at the edges: the used technology there=20 (LAN,WLAN,...) is outside
>      the=20 scope.

   I'd be happy to agree to that. However, the=20 question seems premature.

>   b) wrt. layering and als= o=20 within the routing protocol: flooding is
>      neede= d=20 for detecting the topology. As soon as the topology is
>   = ;=20   provided, loopfree propagation/advertisement of whatsoever can=20 be
>      done better than by flooding. If it is not=20 routing relevant but
>      rather end-to-end relevan= t it=20 should not even be part of routing.

   Feel free to start= a=20 new thread on this issue. (I'm not sure I
understand your point well en= ough=20 to respond yet.)

>   c) wrt. addressing:
> = =20     PNNI tried to handle at least 3 prefix-summarizable=20 address
>      families (IPv4 not counted in) of user= s.=20 Obviously all of them
>      could not be  used=20= for=20 identifying PNNI-nodes concurrently.
>      User=20 addresses must not be mixed up with (hierarchical) nodes'
>  &n= bsp;=20   addresses.

   I agree it's important for us to=20 _architecturally_ distinguish them.
I doubt, however, we will be able t= o=20 prevent users from confusing them.

--
John Leslie=20 <john@jlc.net>
 
-------------------------------1166002681-- --===============0614327857== 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 --===============0614327857==-- From architecture-discuss-bounces@ietf.org Wed Dec 13 07:43:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuTQS-0001oz-3D; Wed, 13 Dec 2006 07:41:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuTQQ-0001oo-Qs for architecture-discuss@ietf.org; Wed, 13 Dec 2006 07:41:30 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuTQO-0001Vt-9w for architecture-discuss@ietf.org; Wed, 13 Dec 2006 07:41:30 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id A7B24212E36; Wed, 13 Dec 2006 14:41:15 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 722E4212D98; Wed, 13 Dec 2006 14:41:15 +0200 (EET) In-Reply-To: <20061212165027.GA60450@verdi> References: <816DD9299957E547B5D758D7F977D6DC010F2B0F@tayexc14.americas.cpqcorp.net> <20061212165027.GA60450@verdi> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [arch-d] Do we have "partial consensus"? Date: Wed, 13 Dec 2006 14:41:11 +0200 To: John Leslie X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: architecture-discuss@ietf.org, "Bound, Jim" X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > ... I'd like to try for a first pass at consensus on architecture. Here's my take. > Statement: > > We want to work towards an architecture with separate "layers" for > "routing" and "transport", where "routing" is responsible for I'm afraid we need to be more specific about terminology here, unfortunately. Apparently we need to make a distinction between the routing and forwarding functions, and understand how routing names (locators) work in terms of them. Conversely, it may be a good idea to call the forwarding/routing layer as "internetworking" or the "network" layer, as it often has traditionally been. I'm still trying to figure out the transport functions and transport names. From a larger point of view, I'm not convinced that we need a "transport" layer with separate names. That said, I agree that we need to separate the currently confounded "identifier" and "locator" roles of IP addresses, thereby creating two distinct name spaces. The "identifier" name space will be mainly used by applications and the "locator" name space by routing and forwarding. I'm afraid that we haven't received any kind of consensus on how to do that separation. [Skipping a list of potential functions for the "internetnetworking" and "transport" layers.] > Question Areas: > > - is there a better name than "layers" for these problem spaces? I'm afraid we first need to sort out the main namespaces and the main functionality they are needed support. In my not so humble opinion, many of our current problems are exacerbated by the IP addresses being a confounding of being "identifiers" and "locators" (see RFC 4423, Section 4, but also notice that my thinking has evolved since). > - is there a better name than "routing" for the lower "layer"? As I stated above, I'd prefer "networking" or "internetworking". > - is there a better name than "transport" for the upper "layer"? I'd prefer "application", understanding that it partly subsumes what we have traditionally called "transport". The reason why I'd prefer "application" is that, IMHO, the "upper" name space should focus on the applications' demands. From an architectural point of view, I'm not convinced that the "transport" needs any stable naming at all. Indeed, think about how little independent naming TCP and UDP have today. > - are any of the responsibilities clearly assigned to the wrong > "layer"? I see this question as two-pronged: - starting from the current networking reality, we cannot move that much responsibility around without causing flag days, which clearly would be unacceptable - when thinking in terms of a "new" or clean slate architecture, I'm afraid that so much of our current wisdom must be reconsidered that it is probably a little bit too early to think in terms of layered responsibilities. > - are we ready to agree to define separate namespaces for these > "layers"? I think it would be a big step forward if we could agree that we need to separate the current IPvN namespaces into two "layered" name spaces, the "lower layer" names being used primarily by the routing and forwarding system and the "upper layer" names being geared primarily towards the needs of applications and the legacy socket APIs. [Apparently, the NSRG couldn't agree on that, and I don't remember having seen any announcement that any I* body would have agreed on that.] Note that when asking for consensus on this, I am not *not* asking for consensus on whether Noel's "jack-up" or the HIP/SHIM6 like way would be the way, or perhaps some other way, nor what would be the details of the "layered" namespaces, etc. That is, I am not asking for consensus on *any* of the details. I am merely asking if we have an early consensus on the problem in terms of the general solution approach. Do we agree that we need to separate the naming roles of the current IPvN addresses, as is described above? To further clarify: in this case, I find it very hard to produce an exact definition of all the architecturally inclined problems that we have; for example, I can easily count to up to six or seven different problems, all partially caused by the present role confounding. Hence, instead of trying to agree on a problem definition (since I think producing it would be very hard), I propose that perhaps we could agree on a general solution approach. --Pekka Nikander _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Dec 13 09:20:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuUwr-000524-LJ; Wed, 13 Dec 2006 09:19:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuUwp-00051u-TG for architecture-discuss@ietf.org; Wed, 13 Dec 2006 09:19:03 -0500 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuUwn-0003kr-If for architecture-discuss@ietf.org; Wed, 13 Dec 2006 09:19:03 -0500 Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 5861317; Wed, 13 Dec 2006 09:19:01 -0500 In-Reply-To: References: <816DD9299957E547B5D758D7F977D6DC010F2B0F@tayexc14.americas.cpqcorp.net> <20061212165027.GA60450@verdi> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <54CBE937-4DD8-462E-9ABF-85298D48CE37@multicasttech.com> Content-Transfer-Encoding: 7bit From: Marshall Eubanks Subject: Re: [arch-d] Do we have "partial consensus"? Date: Wed, 13 Dec 2006 09:18:58 -0500 To: Pekka Nikander X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: "Bound, Jim" , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Dear Pekka; On Dec 13, 2006, at 7:41 AM, Pekka Nikander wrote: >> ... I'd like to try for a first pass at consensus on architecture. > > Here's my take. > >> Statement: >> >> We want to work towards an architecture with separate "layers" for >> "routing" and "transport", where "routing" is responsible for > > I'm afraid we need to be more specific about terminology here, > unfortunately. Apparently we need to make a distinction between > the routing and forwarding functions, and understand how routing > names (locators) work in terms of them. Conversely, it may be a > good idea to call the forwarding/routing layer as "internetworking" > or the "network" layer, as it often has traditionally been. > > I'm still trying to figure out the transport functions and > transport names. From a larger point of view, I'm not convinced > that we need a "transport" layer with separate names. > > That said, I agree that we need to separate the currently > confounded "identifier" and "locator" roles of IP addresses, > thereby creating two distinct name spaces. The "identifier" name > space will be mainly used by applications and the "locator" name > space by routing and forwarding. > > I'm afraid that we haven't received any kind of consensus on how to > do that separation. Is it realistic to assume that that there will be only one split ? (For example, in the MPI case a geographically based locator might make sense, while for static networks a locator based on network hierarchy is probably more appropriate, and these very different choices will influence the type of locator, and maybe the type of identifier, chosen.) So wouldn't the first step be the selection of a means to identify the split being taken ? > [Skipping a list of potential functions for the > "internetnetworking" and "transport" layers.] > >> Question Areas: >> >> - is there a better name than "layers" for these problem spaces? > > I'm afraid we first need to sort out the main namespaces and the > main functionality they are needed support. In my not so humble > opinion, many of our current problems are exacerbated by the IP > addresses being a confounding of being "identifiers" and > "locators" (see RFC 4423, Section 4, but also notice that my > thinking has evolved since). > >> - is there a better name than "routing" for the lower "layer"? > > As I stated above, I'd prefer "networking" or "internetworking". > >> - is there a better name than "transport" for the upper "layer"? > > I'd prefer "application", understanding that it partly subsumes > what we have traditionally called "transport". > > The reason why I'd prefer "application" is that, IMHO, the "upper" > name space should focus on the applications' demands. From an > architectural point of view, I'm not convinced that the "transport" > needs any stable naming at all. Indeed, think about how little > independent naming TCP and UDP have today. > >> - are any of the responsibilities clearly assigned to the wrong >> "layer"? > > I see this question as two-pronged: > > - starting from the current networking reality, we cannot move that > much responsibility around without causing flag days, which clearly > would be unacceptable > > - when thinking in terms of a "new" or clean slate architecture, > I'm afraid that so much of our current wisdom must be reconsidered > that it is probably a little bit too early to think in terms of > layered responsibilities. > >> - are we ready to agree to define separate namespaces for these >> "layers"? > > I think it would be a big step forward if we could agree that we > need to separate the current IPvN namespaces into two "layered" > name spaces, the "lower layer" names being used primarily by the > routing and forwarding system and the "upper layer" names being > geared primarily towards the needs of applications and the legacy > socket APIs. [Apparently, the NSRG couldn't agree on that, and I > don't remember having seen any announcement that any I* body would > have agreed on that.] > > Note that when asking for consensus on this, I am not *not* asking > for consensus on whether Noel's "jack-up" or the HIP/SHIM6 like way > would be the way, or perhaps some other way, nor what would be the > details of the "layered" namespaces, etc. That is, I am not asking > for consensus on *any* of the details. > > > I am merely asking if we have an early consensus on the problem in > terms of the general solution approach. Do we agree that we need > to separate the naming roles of the current IPvN addresses, as is > described above? > > > To further clarify: in this case, I find it very hard to produce an > exact definition of all the architecturally inclined problems that > we have; for example, I can easily count to up to six or seven > different problems, all partially caused by the present role > confounding. Hence, instead of trying to agree on a problem > definition (since I think producing it would be very hard), I > propose that perhaps we could agree on a general solution approach. This indicates to me that, again, "one size fits all" is probably not realistic. Regards Marshall > > --Pekka Nikander > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Dec 13 12:26:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuXpg-0004E8-1p; Wed, 13 Dec 2006 12:23:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuXpe-0004Dp-Hi for architecture-discuss@ietf.org; Wed, 13 Dec 2006 12:23:50 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuXpd-0007SS-6P for architecture-discuss@ietf.org; Wed, 13 Dec 2006 12:23:50 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id B2839872E0; Wed, 13 Dec 2006 12:23:48 -0500 (EST) To: architecture-discuss@ietf.org Subject: Re: [arch-d] Do we have "partial consensus"? Message-Id: <20061213172348.B2839872E0@mercury.lcs.mit.edu> Date: Wed, 13 Dec 2006 12:23:48 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: Pekka Nikander Most of this I agree with; a few comments: >> We want to work towards an architecture with separate "layers" for >> "routing" and "transport", where "routing" is responsible for > I'm afraid we need to be more specific about terminology here, > unfortunately. Apparently we need to make a distinction between the > routing and forwarding functions I agree, and this terminology distinction (routing/forwarding) is one most people working on routers use. I like to use the term "path selection" for "routing", though, because the latter term may not be clearly defined to many people (just like "address") - some people see it as meaning "forwarding". However, "path selection" can have only one meaning. "Forwarding" seems safe to use as-is, though. > Conversely, it may be a good idea to call the forwarding/routing layer > as "internetworking" or the "network" layer, as it often has > traditionally been. I would strongly resist calling it the "network" layer. I know this terminology is a result of the ISO-7 model, but when one gets to things like ATM and other networks, which have real and non-trivial protocols of their own, not having a separate name for that network-specific stuff can be very confusing. So I have, for many years now (see, for instance, Section 7.1, "A New Layer Model", in 'Endpoints and Endpoint Names') added an "internetwork" layer as a new, *additional*, fully-fledged layer, in between the existing "network" and "transport" layer in the ISO stack. To do anything else, is, IMO, really badly misguided. > I'm still trying to figure out the transport functions and transport > names. From a larger point of view, I'm not convinced that we need a > "transport" layer with separate names. I agree - but at the same time, we have the constraint that we don't have a blank sheet of paper, and have to devise an evolutionary, interoperable, path. Given that constraint, adding transport names (whether something like HIP, or a recasting of existing IPvN "addresses") may be the best way forward from here. Even if we do name endpoints, we still need even more names at higher layers (e.g. to name various aspects of communication with a server farm, where one can continue an existing interaction even if the particular server one is talking to drops dead - HTTP cookies do this now, really). So, yes, a blank-sheet design would probably dispense with them - but we don't have a blank sheet... > The "identifier" name space will be mainly used by applications and the > "locator" name space by routing and forwarding. It remains to be seen how much use people would make of the routing-name names, i) if they existed, and ii) if the path-selection system was less of a "black box" over which the users have almost no control. E.g. I personally like being able to select my path when I'm in my car, and I might do the same for some of my network traffic, too, *if I could*, which I currently can not. >> is there a better name than "layers" for these problem spaces? > I'm afraid we first need to sort out the main namespaces and the main > functionality they are needed support. I agree, but it's worth pointing out that typically there is an association between a namespace and a layer, so in thinking about these things, one is almost necessarily thinking about both of them. > when thinking in terms of a "new" or clean slate architecture, I'm > afraid that so much of our current wisdom must be reconsidered that it > is probably a little bit too early to think in terms of layered > responsibilities. Hunh! If we're really clean-slating, the first thing to do is ditch the whole simplistic "layers" model, and go with the more general "modularization dependency graph" (probably a tree, actually - see the references from Section 7.2, "Layering and General System Modularization Principles"). > I think it would be a big step forward if we could agree that we need > to separate the current IPvN namespaces into two "layered" name spaces, > the "lower layer" names being used primarily by the routing and > forwarding system and the "upper layer" names being geared primarily > towards the needs of applications and the legacy socket APIs. My sense is there is now rough consensus on this point. Just to check this, does anyone out there disagree with that principle? (Actually, people might miss this, buried in the body of a long message. I'll ask it separately, too.) > [Apparently, the NSRG couldn't agree on that, and I don't remember > having seen any announcement that any I* body would have agreed on > that.] Please, I'd rather not delve back into history (much as some of it may still rankle for me, privately :-). It's all water under the bridge. Let's focus on what people think now. > Note that when asking for consensus on this, I am not *not* asking for > consensus on .. what would be the details of the "layered" namespaces, > etc. That is, I am not asking for consensus on *any* of the details. Alas, I fear that the devil in this case is going to be precisely in the details... I remain dubious that any one approach will gain rough consensus, for a number of reasons. (Although nobody will be happier than me if my gloom on this point proves wrong, and we can agree.) For one, different solutions will have different costs and benefits for different groups, and so each will prefer the one that works best for them. For another, engineers (like most people :-) always seem to have a stubborn attachment to their own ideas. Etc, etc, etc... Even if the I* comes in and knocks heads and choses Door A, that doesn't necessarily mean that the vendors, customers, etc will all agree to go with Door A. So perhaps we can do nothing more than lay out a couple of options, and see which one the market picks. > instead of trying to agree on a problem definition (since I think > producing it would be very hard), I propose that perhaps we could agree > on a general solution approach. I agree. The process seems to favour creation of "requirements" documents, but in practise they don't really seem to have been that helpful - and, as you point out, in this case even production of that would be tricky. I think it will be much easier to get people to sign up to the general approach. Then we get to "how to actually do it", and that's where it's going to be difficult. I suspect that a coalition of ISP's may have to come together and pick a solution that works for them - since the driver for this, at base, is going to be routing problems in the backbone. Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Dec 13 15:51:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gub34-0000FG-Pi; Wed, 13 Dec 2006 15:49:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gub33-0000F7-1r for architecture-discuss@ietf.org; Wed, 13 Dec 2006 15:49:53 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gub30-0002ez-EP for architecture-discuss@ietf.org; Wed, 13 Dec 2006 15:49:53 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id AC04F4ACD0; Wed, 13 Dec 2006 15:49:41 -0500 (EST) Date: Wed, 13 Dec 2006 15:49:41 -0500 From: John Leslie To: Pekka Nikander Subject: Re: [arch-d] Do we have "partial consensus"? Message-ID: <20061213204941.GB2478@verdi> References: <816DD9299957E547B5D758D7F977D6DC010F2B0F@tayexc14.americas.cpqcorp.net> <20061212165027.GA60450@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Pekka Nikander wrote: > [John Leslie wrote:] > >> Statement: >> >> We want to work towards an architecture with separate "layers" for >> "routing" and "transport", where "routing" is responsible for > > I'm afraid we need to be more specific about terminology here, > unfortunately. I take this as discussion about "better names" for the layers. > Apparently we need to make a distinction between the routing and > forwarding functions, and understand how routing names (locators) > work in terms of them. This is certainly a necessary work item... > Conversely, it may be a good idea to call the forwarding/routing > layer as "internetworking" or the "network" layer, as it often has > traditionally been. Speaking only for myself, something like "internetworking" fits rather nicely. I don't like the name "network" because it confuses almost everybody as to what the layer is about. > I'm still trying to figure out the transport functions and transport > names. From a larger point of view, I'm not convinced that we need a > "transport" layer with separate names. I think the question of designing a name structure is better taken up after agreeing on the functions we're trying to accomplish. I quite agree that in the absence of agreed functions there's no good reason to design a name structure. (Please note that I left the question of namespaces quite open, merely appending a question _whether_ we think we're ready to talk about it.) > That said, I agree that we need to separate the currently confounded > "identifier" and "locator" roles of IP addresses, thereby creating > two distinct name spaces. The "identifier" name space will be mainly > used by applications and the "locator" name space by routing and > forwarding. That souds like support for the overall statment _iff_ we come up with the right names. > I'm afraid that we haven't received any kind of consensus on how to > do that separation. Nor, IMHO, should we try to at this stage. We should first lay out what we want the layers to do; then discuss what sorts of namespaces are appropriate for those functions. (BTW, my personal opinion is that "improved office routers" can do whatever transition functions we might agree upon, and that ISPs could perform those same functions for their customers who choose not to purchase "improved office routers".) >> Question Areas: >> >> - is there a better name than "layers" for these problem spaces? > > I'm afraid we first need to sort out the main namespaces and the main > functionality they are needed support. In my not so humble opinion, > many of our current problems are exacerbated by the IP addresses > being a confounding of being "identifiers" and "locators" (see RFC > 4423, Section 4, but also notice that my thinking has evolved since). I take this to be, "Maybe, but we aren't ready to agree what it is." >> - is there a better name than "routing" for the lower "layer"? > > As I stated above, I'd prefer "networking" or "internetworking". I accept "internetworking" as a suggested replacement. > >- is there a better name than "transport" for the upper "layer"? > > I'd prefer "application", understanding that it partly subsumes what > we have traditionally called "transport". Speaking only for myself, I consider that a poor choice. Inevitably, it seems to infer that "transport", "session", and "presentation" couldn't benefit from their own namespace -- a question I think best avoided. IMHO, we'll be better equipped to name this layer if we can agree upon some functions for it. Recall, I suggested " " - detecting and adjusting for packet loss; " - detecting and adjusting for packet corruption; " - reducing packet injection rate when a path is congested; It was my intention to list needed functions without laying too much responsibility on this layer -- in the interests of scalability. These three are current responsibilities of TCP. > The reason why I'd prefer "application" is that, IMHO, the "upper" > name space should focus on the applications' demands. From an > architectural point of view, I'm not convinced that the "transport" > needs any stable naming at all. Indeed, think about how little > independent naming TCP and UDP have today. Bingo! The three functions I listed clearly _can_ be accomplished without a new namespace. If we design a new namespace at this point, it is only based on a belief that we'll find some other function(s) -- possibly relating to multi-homing and mobility. IMHO, "applccations" are mostly agnostic about multi-homing and mobility. > >- are any of the responsibilities clearly assigned to the wrong > >"layer"? > > I see this question as two-pronged: > > - starting from the current networking reality, we cannot move that > much responsibility around without causing flag days, which clearly > would be unacceptable I disagree. But let's first try to agree what we'd _like_ to move... > - when thinking in terms of a "new" or clean slate architecture, I'm > afraid that so much of our current wisdom must be reconsidered that > it is probably a little bit too early to think in terms of layered > responsibilities. 1. I doubt we really can think entirely "clean-slate". 2. It doesn't feel too early to me. >> - are we ready to agree to define separate namespaces for these >> "layers"? > > I think it would be a big step forward if we could agree that we need > to separate the current IPvN namespaces into two "layered" name > spaces, the "lower layer" names being used primarily by the routing > and forwarding system and the "upper layer" names being geared > primarily towards the needs of applications and the legacy socket > APIs. [Apparently, the NSRG couldn't agree on that, and I don't > remember having seen any announcement that any I* body would have > agreed on that.] This statement is too vague, IMHO. "Routing/Forwarding" _could_ expand to fill any space allotted. I think it's important -- in the name of scalability -- to make sure it doesn't. I can't attach any distinct meaning to "needs of applications and the legacy socket APIs". When searching for consensus, it helps _a_lot_ to make the statements crisp. It's human nature to "reach agreement" by writing words which mean one thing to one faction and something else to another. This can only postpone the problem. Eventually you'll be saddled with so many points of failed understanding that "consensus by exhaustion" is the only kind of consensus possible. That can never produce a good design. > I am merely asking if we have an early consensus on the problem in > terms of the general solution approach. Do we agree that we need to > separate the naming roles of the current IPvN addresses, as is > described above? I will not answer that, even for myself. It sounds like an easy question, but it isn't. As Pekka himself noted, TCP doesn't need its own namespace to accomplish its current functions: thus we're asked to agree to create a new namespace which doesn't yet have any reason to exist. While I believe we will find reasons, I'm quite nervous about starting the design without them. > To further clarify: in this case, I find it very hard to produce an > exact definition of all the architecturally inclined problems that we > have; I do not believe we need to list "all" yet. I'm not sure it would even help if we could. Architecture is about designing for _unknown_ problems. > for example, I can easily count to up to six or seven different > problems, all partially caused by the present role confounding. I don't think we need to list even that many to decide it's worth our while to sort out the proper roles. > Hence, instead of trying to agree on a problem definition (since I > think producing it would be very hard), I propose that perhaps we > could agree on a general solution approach. Architecture doesn't start from a "problem definition" -- it starts from a list of desires. The consensus I'm seeking is on a small part of a list of desires. Do we want these things? We'll have plenty of opportunity to add to the list later. Trying to "solve" how to satisfy the list every time we want to add a new item will only serve to exhaust us all. -- John Leslie _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Dec 13 16:36:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gubla-0001t3-Tv; Wed, 13 Dec 2006 16:35:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GublZ-0001sr-Us for architecture-discuss@ietf.org; Wed, 13 Dec 2006 16:35:53 -0500 Received: from web58712.mail.re1.yahoo.com ([66.196.100.189]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GublU-0002p6-JH for architecture-discuss@ietf.org; Wed, 13 Dec 2006 16:35:53 -0500 Received: (qmail 86257 invoked by uid 60001); 13 Dec 2006 21:35:48 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=YaZnUZ+1PchU2j15+zb82B7HJiUTZTFBDibEVEbxnVMpfN1wDpo0+uAnpvV7K2xY8iYuLQ9CT5e8cvS13796aQtDpDK0Q764IPveTAVT1fcoPwKmBAyvmZR3TdDjV3J73uaXe5amFsCo0BJ8D/ZfZU3yv4d9cfUJVDKKs4NfNJo=; X-YMail-OSG: irOchLEVM1mMbjWTlmd_1yS8Jg4c7zpw6tW00My8 Received: from [207.107.50.100] by web58712.mail.re1.yahoo.com via HTTP; Wed, 13 Dec 2006 13:35:48 PST Date: Wed, 13 Dec 2006 13:35:48 -0800 (PST) From: Peter Sherbin Subject: Re: [arch-d] Do we have "partial consensus"? To: HeinerHummel@aol.com, john@jlc.net In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <392595.86082.qm@web58712.mail.re1.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Would the following suffice: - the globe is covered with a hierarchical backbone terminating at attachement points(AP) e.g. per every 10 sq miles - each AP has a unique address, i.e. fixed geo/topo location - every edge network has a globally unique name - AP maintains a table of attached names to route packets within its area - AP combines its address with a name to route packets outside of its area - the lowest size of the edge networks is one node - parts of the backbone are supported by various public / private entities - AP addresses are distributed by RIR - edge network names are distributed by e.g. local tax authorities The above allows free moves of edge networks carrying only their names between AP. IETF/IANA regulates two pools of numbers: backbone/AP addresses and edge networks' names. Thanks, Peter --- HeinerHummel@aol.com wrote: > > Some more notes pro hierarchical routing: > > PNNI : The PNNI architects are still around: Ross Callon, Joel Halpern, > George Swallow, Mickey Spiegel. It was a fine protocol development which would > never have been accomplished if the Bell-heads had understood more of it :-). > PNNI contains good and less good things. From some distance that can be > distinguished even better as to learn from both. > > There is also a nicely written draft from Frank Kastenholz: ISLAY. But from > a single draft you cannot learn "by experience", particularly you cannot > learn from its worse parts. > > And: We all do hierarchical routing day by day.When it comes to travelling, > at least in your mind you do combine the city map where your trip starts as to > get to the right exit, the country road map as to get to the nearest > airport, a world map with all the flight routes as to get to the destination > airport. And while you haven't yet left the ingress city your routing decisions > do > not consider any road labor blockings nearby the hotel of your destination. > > I can only repeat myself: There is no better solution than HR, and also HR > is sufficiently precise. > > Heiner > > In einer eMail vom 12.12.2006 20:19:49 Westeuropäische Normalzeit schreibt > john@jlc.net: > > I dare to assume Heiner didn't intend > " > " you're so far out of it that you need to go away for a week or two!" > > HeinerHummel@aol.com wrote: > > > > I have a different list of objectives: > > > > - develop an architecture which fits even for a 100 times bigger > > internet while the workload for the individual router becomes > > 100 times less than is necessary today > > I agree with this objective. > > Speaking only for myself: I specifically tried to minimize the > "routing" "layer" task. My list contains _only_ the things I think > can't be moved to another layer, and specifically excludes finding > alternate paths if forwarding isn't possible. > > > Will say, by knowing the hierarchical network topology of 100 nodes+300 > > hierarchical nodes the same can be accomplished than be learning about > > 100 million routers. > > Again speaking only for myself: In describing "layer" responsibilities > I did not intend that all must be accomlished in the same box. I can > easily imagine totally separating the "routing protocol" boxes from the > "forwarding" boxes. > > > - develop a one-face-only architecture (rather than a collection of > > completely orthogonal concepts like BGP versus OSPF) > > PNNI at least tried to accomplish such a one-face-only architecture. > > It was later, in response to PNNI, that OSPF came up with areas > > (simpler,less ambitious, but not as perfect in design). > > This sounds like it deserves its own thread... > > > -do routing such that fear of loops doesn't have to be at all. > > Hmm... > > I don't think "routing gurus" will get over that fear in my lifetime! > > > -do routing such that real-time traffic balancing is enabled > > Speaking only for myself: I don't think the "routing" "layer" can do > any more for that than signal what bandwidth is available to particular > destinations (currently CIDR block) forwarded from each forwarder's > individual peers. Even that much begins to intrude on Heiner's first > principle (scaling by a factor of 100). > > > - do clean cuts: > > > > a) at the edges: the used technology there (LAN,WLAN,...) is outside > > the scope. > > I'd be happy to agree to that. However, the question seems premature. > > > b) wrt. layering and also within the routing protocol: flooding is > > needed for detecting the topology. As soon as the topology is > > provided, loopfree propagation/advertisement of whatsoever can be > > done better than by flooding. If it is not routing relevant but > > rather end-to-end relevant it should not even be part of routing. > > Feel free to start a new thread on this issue. (I'm not sure I > understand your point well enough to respond yet.) > > > c) wrt. addressing: > > PNNI tried to handle at least 3 prefix-summarizable address > > families (IPv4 not counted in) of users. Obviously all of them > > could not be used for identifying PNNI-nodes concurrently. > > User addresses must not be mixed up with (hierarchical) nodes' > > addresses. > > I agree it's important for us to _architecturally_ distinguish them. > I doubt, however, we will be able to prevent users from confusing them. > > -- > John Leslie > > > > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss > ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Dec 13 19:30:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GueRw-0003a6-GV; Wed, 13 Dec 2006 19:27:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GueRv-0003a0-UA for architecture-discuss@ietf.org; Wed, 13 Dec 2006 19:27:47 -0500 Received: from [203.167.203.10] (helo=enso.acheron.indranet.co.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GueRu-0006AT-7U for architecture-discuss@ietf.org; Wed, 13 Dec 2006 19:27:47 -0500 Received: from [127.0.0.1] (IDENT:root@enso.acheron.indranet.co.nz [192.168.1.1]) by enso.acheron.indranet.co.nz (8.9.3-20030919/8.9.3) with ESMTP id NAA01643; Thu, 14 Dec 2006 13:27:32 +1300 In-Reply-To: References: <816DD9299957E547B5D758D7F977D6DC010F2B0F@tayexc14.americas.cpqcorp.net> <20061212165027.GA60450@verdi> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5551A266-5BDB-42EF-B645-81AF5B9F452B@indranet.co.nz> Content-Transfer-Encoding: 7bit From: Andrew McGregor Subject: Re: [arch-d] Do we have "partial consensus"? Date: Thu, 14 Dec 2006 13:29:16 +1300 To: Pekka Nikander X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: "Bound, Jim" , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I agree with all of this; instead of characterising the confusion, agree on the source of it and go from there. We do, I think, agree that the confusion is there, and that naming conflation is the root cause of problem. Andrew On 14/12/2006, at 1:41 AM, Pekka Nikander wrote: > > I think it would be a big step forward if we could agree that we > need to separate the current IPvN namespaces into two "layered" > name spaces, the "lower layer" names being used primarily by the > routing and forwarding system and the "upper layer" names being > geared primarily towards the needs of applications and the legacy > socket APIs. [Apparently, the NSRG couldn't agree on that, and I > don't remember having seen any announcement that any I* body would > have agreed on that.] > > Note that when asking for consensus on this, I am not *not* asking > for consensus on whether Noel's "jack-up" or the HIP/SHIM6 like way > would be the way, or perhaps some other way, nor what would be the > details of the "layered" namespaces, etc. That is, I am not asking > for consensus on *any* of the details. > > > I am merely asking if we have an early consensus on the problem in > terms of the general solution approach. Do we agree that we need > to separate the naming roles of the current IPvN addresses, as is > described above? > > > To further clarify: in this case, I find it very hard to produce an > exact definition of all the architecturally inclined problems that > we have; for example, I can easily count to up to six or seven > different problems, all partially caused by the present role > confounding. Hence, instead of trying to agree on a problem > definition (since I think producing it would be very hard), I > propose that perhaps we could agree on a general solution approach. > > --Pekka Nikander > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Dec 13 20:10:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guf6I-000831-30; Wed, 13 Dec 2006 20:09:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guf6G-00082u-Lv for architecture-discuss@ietf.org; Wed, 13 Dec 2006 20:09:28 -0500 Received: from [203.167.203.10] (helo=enso.acheron.indranet.co.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Guf6E-0003YN-Sf for architecture-discuss@ietf.org; Wed, 13 Dec 2006 20:09:28 -0500 Received: from [127.0.0.1] (IDENT:root@enso.acheron.indranet.co.nz [192.168.1.1]) by enso.acheron.indranet.co.nz (8.9.3-20030919/8.9.3) with ESMTP id OAA02391; Thu, 14 Dec 2006 14:09:16 +1300 In-Reply-To: <392595.86082.qm@web58712.mail.re1.yahoo.com> References: <392595.86082.qm@web58712.mail.re1.yahoo.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Andrew McGregor Subject: Re: [arch-d] Do we have "partial consensus"? Date: Thu, 14 Dec 2006 14:10:59 +1300 To: Peter Sherbin X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Cc: HeinerHummel@aol.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: , Errors-To: architecture-discuss-bounces@ietf.org Unfortunately, no. The real network isn't nearly this simple. Solutions in this class =20 have to derive the locators from the observed topology (which will =20 change with time). This is the problem with Heiner's hierarchical =20 suggestion too. Not to say that it can't be done, but we cannot =20 posit a topological simplification; the topology is only going to get =20= more complicated. Andrew On 14/12/2006, at 10:35 AM, Peter Sherbin wrote: > Would the following suffice: > > - the globe is covered with a hierarchical backbone terminating at =20 > attachement > points(AP) e.g. per every 10 sq miles > - each AP has a unique address, i.e. fixed geo/topo location > - every edge network has a globally unique name > - AP maintains a table of attached names to route packets within =20 > its area > - AP combines its address with a name to route packets outside of =20 > its area > - the lowest size of the edge networks is one node > - parts of the backbone are supported by various public / private =20 > entities > - AP addresses are distributed by RIR > - edge network names are distributed by e.g. local tax authorities > > The above allows free moves of edge networks carrying only their =20 > names between > AP. > IETF/IANA regulates two pools of numbers: backbone/AP addresses and =20= > edge networks' > names. > > Thanks, > > Peter > > --- HeinerHummel@aol.com wrote: > >> >> Some more notes pro hierarchical routing: >> >> PNNI : The PNNI architects are still around: Ross Callon, Joel =20 >> Halpern, >> George Swallow, Mickey Spiegel. It was a fine protocol =20 >> development which would >> never have been accomplished if the Bell-heads had understood more =20= >> of it :-). >> PNNI contains good and less good things. =46rom some distance that =20= >> can be >> distinguished even better as to learn from both. >> >> There is also a nicely written draft from Frank Kastenholz: =20 >> ISLAY. But from >> a single draft you cannot learn "by experience", particularly =20 >> you cannot >> learn from its worse parts. >> >> And: We all do hierarchical routing day by day.When it comes to =20 >> travelling, >> at least in your mind you do combine the city map where your trip =20 >> starts as to >> get to the right exit, the country road map as to get to the nearest >> airport, a world map with all the flight routes as to get to the =20 >> destination >> airport. And while you haven't yet left the ingress city your =20 >> routing decisions >> do >> not consider any road labor blockings nearby the hotel of your =20 >> destination. >> >> I can only repeat myself: There is no better solution than HR, and =20= >> also HR >> is sufficiently precise. >> >> Heiner >> >> In einer eMail vom 12.12.2006 20:19:49 Westeurop=E4ische Normalzeit =20= >> schreibt >> john@jlc.net: >> >> I dare to assume Heiner didn't intend >> " >> " you're so far out of it that you need to go away for a week or =20= >> two!" >> >> HeinerHummel@aol.com wrote: >>> >>> I have a different list of objectives: >>> >>> - develop an architecture which fits even for a 100 times bigger >>> internet while the workload for the individual router becomes >>> 100 times less than is necessary today >> >> I agree with this objective. >> >> Speaking only for myself: I specifically tried to minimize the >> "routing" "layer" task. My list contains _only_ the things I think >> can't be moved to another layer, and specifically excludes finding >> alternate paths if forwarding isn't possible. >> >>> Will say, by knowing the hierarchical network topology of 100 =20 >>> nodes+300 >>> hierarchical nodes the same can be accomplished than be learning =20= >>> about >>> 100 million routers. >> >> Again speaking only for myself: In describing "layer" =20 >> responsibilities >> I did not intend that all must be accomlished in the same box. I can >> easily imagine totally separating the "routing protocol" boxes =20 >> from the >> "forwarding" boxes. >> >>> - develop a one-face-only architecture (rather than a collection of >>> completely orthogonal concepts like BGP versus OSPF) >>> PNNI at least tried to accomplish such a one-face-only =20 >>> architecture. >>> It was later, in response to PNNI, that OSPF came up with areas >>> (simpler,less ambitious, but not as perfect in design). >> >> This sounds like it deserves its own thread... >> >>> -do routing such that fear of loops doesn't have to be at all. >> >> Hmm... >> >> I don't think "routing gurus" will get over that fear in my =20 >> lifetime! >> >>> -do routing such that real-time traffic balancing is enabled >> >> Speaking only for myself: I don't think the "routing" "layer" can do >> any more for that than signal what bandwidth is available to =20 >> particular >> destinations (currently CIDR block) forwarded from each forwarder's >> individual peers. Even that much begins to intrude on Heiner's first >> principle (scaling by a factor of 100). >> >>> - do clean cuts: >>> >>> a) at the edges: the used technology there (LAN,WLAN,...) is =20 >>> outside >>> the scope. >> >> I'd be happy to agree to that. However, the question seems =20 >> premature. >> >>> b) wrt. layering and also within the routing protocol: =20 >>> flooding is >>> needed for detecting the topology. As soon as the topology is >>> provided, loopfree propagation/advertisement of whatsoever =20 >>> can be >>> done better than by flooding. If it is not routing relevant =20= >>> but >>> rather end-to-end relevant it should not even be part of =20 >>> routing. >> >> Feel free to start a new thread on this issue. (I'm not sure I >> understand your point well enough to respond yet.) >> >>> c) wrt. addressing: >>> PNNI tried to handle at least 3 prefix-summarizable address >>> families (IPv4 not counted in) of users. Obviously all of them >>> could not be used for identifying PNNI-nodes concurrently. >>> User addresses must not be mixed up with (hierarchical) nodes' >>> addresses. >> >> I agree it's important for us to _architecturally_ distinguish them. >> I doubt, however, we will be able to prevent users from confusing =20= >> them. >> >> -- >> John Leslie >> >> >> >> >>> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www1.ietf.org/mailman/listinfo/architecture-discuss >> > > > > > ______________________________________________________________________=20= > ______________ > Do you Yahoo!? > Everyone is raving about the all-new Yahoo! Mail beta. > http://new.mail.yahoo.com > > _______________________________________________ > 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 Thu Dec 14 02:30:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gul2B-0001hn-Vb; Thu, 14 Dec 2006 02:29:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gul2B-0001hi-BC for architecture-discuss@ietf.org; Thu, 14 Dec 2006 02:29:39 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gul29-0005Mi-LH for architecture-discuss@ietf.org; Thu, 14 Dec 2006 02:29:39 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id E4C92212E56; Thu, 14 Dec 2006 09:29:35 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 787FA212E36; Thu, 14 Dec 2006 09:29:35 +0200 (EET) In-Reply-To: <20061213204941.GB2478@verdi> References: <816DD9299957E547B5D758D7F977D6DC010F2B0F@tayexc14.americas.cpqcorp.net> <20061212165027.GA60450@verdi> <20061213204941.GB2478@verdi> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3195C332-FDB8-45C8-A196-5247AE1059AD@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: [arch-d] On the role of "transport" (was Re: Do we have "partial consensus"?) Date: Thu, 14 Dec 2006 09:29:33 +0200 To: John Leslie X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org John, In general I feel we had mostly terminology disagreements, partly reflecting that we apparently look at the problem from slightly different angles. We also seem to be mostly over with the terminology issues. I'd be happy with what Noel stated about the terms. Disregarding the terminology, I think we are in pretty good overall agreement sans how to handle the "transport". Hence, I'm focusing on that, but before I get to that, I need to do a small detour. To start with, and as I have stated at least three times so far, if we think about our current global communications system as sets of components, we can see there three independently changing sets of components: "routers", "host os stacks", and "applications". [Note that the structure is *economic*, not technical. The sets of components have different purchasing cycles and lifetimes.] Between the components, we have two relatively well defined and understood interfaces: 1. One between routers and stacks, i.e., sending IP packets over Ethernet, PPP, etc. 2. One between stacks and applications, i.e., the socket API and its equivalents. These two interfaces are the ones that are hardest to change as changing them requires that more than one of the involved component sets are changed at the same time. Changing the syntax of the interfaces is almost out of the question. Changing semantics -- that we need to do, but we need to be pretty careful when doing so. Now, architecturally, to implement the identifier / locator separation we seem to have two fundamentally different paths: 1. In what Noel calls the "jack up" approaches, we change the "routers". Conversely, we change the semantics of what now are IP addresses to "identifiers" at *both* interfaces. In this approach, what now are IP addresses will become "identifiers", both within the "stacks" and "applications". In this model, "locators" are internal to the network, and only seen by (some) "routers". 2. In the "shim" approaches (HIP/SHIM6/SCTP/...), we change the "stacks"; perhaps not immediately but eventually. Conversely, we change the semantics of what now are IP addresses so that they become "locators" at the "router/stack" interface and "identifiers" at the "stack/application" interface. As a consequence, applications will deal with "identifiers" and routers will deal with "locators"; the "stack" will do the translation. While writing this, I noticed that, at least in theory, we also have a third approach. [But I am not aware of any viable solution proposals here.] 3. In the "apps" approaches we change the "apps"; not necessarily the apps themselves but e.g. resolution, libraries, etc. Conversely, we change the semantics of what now are "IP addresses" so that they become "locators" at *both* of the interfaces. The "apps layer" will do the translation, and "identifiers" are internal to the apps. [This approach also has problems related to e.g. TCP state during mobility events, so it may be impossible to do a clean-cut implementation based on this architectural approach.] Four more notes before we get to the point: 1a. It is also possible to implement the "jack up" mechanisms in the hosts, but that changes the underlying trust model and therefore security properties. The consequences and implications -- think about them. 2a. It is possible to implement the "shim" mechanisms in a separate box (proxy) in a way that structurally resembles the "jack up" mechanisms. But, the trust model is slightly different than in a plain, "stack" based "shim" approach. 3a. I have hard time imagining how to implement the "apps" approach in a proxy box, but intuitively I have the feeling that it should be doable. 4. Implication: From an implementation point of view, the difference between the "jack up" and "shim" approaches need not be that big. Both can be implemented either in some new "router" boxes or in the host os stacks, or in some combination thereof. Perhaps even the "apps" approach can be implemented in that way. Ergo: The differences are architectural, reflecting different architectural semantics and fundamentally different trust models! Now we are finally done with our detour and I get to my point: If you read carefully what I stated above, I did not need the word "transport", not even once. And I did not try to avoid it -- it just wasn't needed. t is pretty clear that somewhere within the "router layer" we will need "locators", aka routing names. It is pretty clear that in the "application layer" we will need "identifiers", identifying entities that the apps are interested in. [Whether the ids identify "hosts", "stacks", or other entities will need to be discussed, but that can be deferred.] It is pretty clear that somewhere we will need to make a translation between them. However, that translation can take place in at least four different locations: 1. In the routing system, resulting in "jack up". 2. In the stack as a "shim", with at least two potential choices for the location: 2a. In the "internetworking" layer, somewhere near IPsec, similar to SHIM6 and HIP. 2b. In the "transport" layer, similar to SCTP add IP. 3. In the "apps layer", e.g., in a library. If we talk about the "transport" layer and "transport" names, that gives the implication that the "transport" needs stable, location- independent names. I don't think that's the case. Its the applications that have the need for such entity-referring location- independent stable names. Hence, I prefer to consider the "upper names" aka "identifiers" as something that the applications, not the transport, are interested in. From a theoretical point of view, it is an open question whether the "transport" should see them or not. --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 Dec 14 05:53:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuoCc-0000Ce-B1; Thu, 14 Dec 2006 05:52:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuoCb-0000CK-F6 for architecture-discuss@ietf.org; Thu, 14 Dec 2006 05:52:37 -0500 Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuoCa-0003BI-5D for architecture-discuss@ietf.org; Thu, 14 Dec 2006 05:52:37 -0500 Received: from pc6 (1Cust98.tnt106.lnd4.gbr.da.uu.net [213.116.60.98]) by astro.systems.pipex.net (Postfix) with SMTP id E0B1AE00039D; Thu, 14 Dec 2006 10:52:31 +0000 (GMT) Message-ID: <021e01c71f65$8cbb6dc0$0601a8c0@pc6> From: "tom.petch" To: , "Noel Chiappa" References: <20061213172348.B2839872E0@mercury.lcs.mit.edu> Subject: Re: [arch-d] Do we have "partial consensus"? Date: Thu, 14 Dec 2006 10:49:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org ----- Original Message ----- From: "Noel Chiappa" To: Cc: Sent: Wednesday, December 13, 2006 6:23 PM Subject: Re: [arch-d] Do we have "partial consensus"? > > From: Pekka Nikander > > Most of this I agree with; a few comments: > > > > I think it would be a big step forward if we could agree that we need > > to separate the current IPvN namespaces into two "layered" name spaces, > > the "lower layer" names being used primarily by the routing and > > forwarding system and the "upper layer" names being geared primarily > > towards the needs of applications and the legacy socket APIs. > > My sense is there is now rough consensus on this point. Just to check this, > does anyone out there disagree with that principle? > > (Actually, people might miss this, buried in the body of a long message. I'll > ask it separately, too.) > I agree with it and see it successfully done in legacy, proprietary networks. The corollary is that you need a directory service to at least do the forward if not the reverse mapping. What I have never understood is why, in IP, it is the lower layer address (IP) that is used by the upper layers (see for example the analyses performed by v6ops in support of a change of format of the lower layer address) when, in theory, a distinct upper layer address (DNS) is available. Tom Petch > > Noel > > _______________________________________________ > 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 Thu Dec 14 05:58:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuoHv-0003Q5-Vq; Thu, 14 Dec 2006 05:58:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuoHv-0003Px-6O for architecture-discuss@ietf.org; Thu, 14 Dec 2006 05:58:07 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuoHt-000429-NK for architecture-discuss@ietf.org; Thu, 14 Dec 2006 05:58:07 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 33067212E56; Thu, 14 Dec 2006 12:58:04 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id EFA9C212E36; Thu, 14 Dec 2006 12:58:03 +0200 (EET) In-Reply-To: <54CBE937-4DD8-462E-9ABF-85298D48CE37@multicasttech.com> References: <816DD9299957E547B5D758D7F977D6DC010F2B0F@tayexc14.americas.cpqcorp.net> <20061212165027.GA60450@verdi> <54CBE937-4DD8-462E-9ABF-85298D48CE37@multicasttech.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [arch-d] Do we have "partial consensus"? Date: Thu, 14 Dec 2006 12:58:01 +0200 To: Marshall Eubanks X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org >> That said, I agree that we need to separate the currently >> confounded "identifier" and "locator" roles of IP addresses, >> thereby creating two distinct name spaces. The "identifier" name >> space will be mainly used by applications and the "locator" name >> space by routing and forwarding. >> >> I'm afraid that we haven't received any kind of consensus on how >> to do that separation. > > Is it realistic to assume that that there will be only one split ? > (For example, in the MPI case a geographically based locator might > make sense, while for static networks a locator based on network > hierarchy is probably more appropriate, and these very different > choices will influence the type of locator, and maybe the type of > identifier, chosen.) So wouldn't the first step be the selection of > a means to identify the split being taken ? I am not sure if I understand you correctly (e.g. I don't know what you refer to with "MPI"), but if I understand you correctly, to me your statement feels like that you would like to have multiple different locator spaces. If so, as I have written before, I don't see any architectural reason why an id/loc split implementation couldn't include mechanisms for architected NATs and NATPs, thereby allowing different locators and routing mechanisms at different areas in the net. On the other hand, I would see there tremendous social utility value if we managed to move back to a single, global identifier space. >> To further clarify: in this case, I find it very hard to produce >> an exact definition of all the architecturally inclined problems >> that we have; for example, I can easily count to up to six or >> seven different problems, all partially caused by the present role >> confounding. > > This indicates to me that, again, "one size fits all" is probably > not realistic. You are right that it may be unrealistic to solve all of the related problems, or even my "six or seven" problems, at a single shot. OTOH, I have practical reasons to believe that all of my "six or seven" problems could be solved with a public-keys-based identity- layer clearly more elegantly (and with less complexity) than we are able to do today. [For reference, the problems I've considered are the following: scalability of the routing system; combined host mobility and multi- homing; fast and vertical handovers with re-authentication; architected NAT, IPv4/v6 interop, etc.; some forms of bad traffic (DDoS); sub-network naming and mobility; and flexible and secure application naming.] --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 Dec 14 09:36:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GurfY-0003Rc-2B; Thu, 14 Dec 2006 09:34:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GurfX-0003RN-3I for architecture-discuss@ietf.org; Thu, 14 Dec 2006 09:34:43 -0500 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GurfU-00020a-Po for architecture-discuss@ietf.org; Thu, 14 Dec 2006 09:34:43 -0500 Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 5865213; Thu, 14 Dec 2006 09:34:40 -0500 In-Reply-To: References: <816DD9299957E547B5D758D7F977D6DC010F2B0F@tayexc14.americas.cpqcorp.net> <20061212165027.GA60450@verdi> <54CBE937-4DD8-462E-9ABF-85298D48CE37@multicasttech.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <397A61D4-5B2E-4689-A417-1AC22C1C83A0@multicasttech.com> Content-Transfer-Encoding: 7bit From: Marshall Eubanks Subject: Re: [arch-d] Do we have "partial consensus"? Date: Thu, 14 Dec 2006 09:34:36 -0500 To: Pekka Nikander X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Dear Pekka; On Dec 14, 2006, at 5:58 AM, Pekka Nikander wrote: >>> That said, I agree that we need to separate the currently >>> confounded "identifier" and "locator" roles of IP addresses, >>> thereby creating two distinct name spaces. The "identifier" name >>> space will be mainly used by applications and the "locator" name >>> space by routing and forwarding. >>> >>> I'm afraid that we haven't received any kind of consensus on how >>> to do that separation. >> >> Is it realistic to assume that that there will be only one split ? >> (For example, in the MPI case a geographically based locator might >> make sense, while for static networks a locator based on network >> hierarchy is probably more appropriate, and these very different >> choices will influence the type of locator, and maybe the type of >> identifier, chosen.) So wouldn't the first step be the selection >> of a means to identify the split being taken ? > > I am not sure if I understand you correctly (e.g. I don't know what > you refer to with "MPI"), but if I understand you correctly, to me > your statement feels like that you would like to have multiple > different locator spaces. If so, as I have written before, I don't > see any architectural reason why an id/loc split implementation > couldn't include mechanisms for architected NATs and NATPs, thereby > allowing different locators and routing mechanisms at different > areas in the net. > > On the other hand, I would see there tremendous social utility > value if we managed to move back to a single, global identifier space. > Mobile Platform Internet - Autonomous Systems on wings (or wheels or...). Some documentation is at http://www.multicasttech.com/mpi/ (Think of a 787 with hundreds of internal computers, 3 or more internal address blocks, and (potentially) dozens of IP interfaces, such as 802.16 to the ground, 802.11 to the tower, and several satellite links, and a strong need to multihome to all of these.) In the MPI case, I think that a geographically based locater may make sense. Suppose that you know that I was at this location, at this time. That would in principal allow you to determine which Satellite footprints, 802.16 nets, and 802.11 ATC links I could be part of at that time. If, say, there was a set of gateways for satellite uplinks, you would know which gateway to forward to. If you were sending ATC information, you would (in principal) know whether to send to the satellite or to the local tower. (In a sense, this discussion is more about aggregation and scalability than routing. We know how to route to aircraft; BGP can do it. I think that the real question is, how do we do it in a way that doesn't require global visibility of the platform.) Also note that in this mobile case, you need to include a time tag, as the locators will change with time and old locators will require different routing. (Locators might change significantly during a long tcp session, for example.) Of course, in the static case, my rack in an exchange or co-lo may be less than one meter from your rack but in a totally different place in network topology, and I doubt that pure geography is worth much. >>> To further clarify: in this case, I find it very hard to produce >>> an exact definition of all the architecturally inclined problems >>> that we have; for example, I can easily count to up to six or >>> seven different problems, all partially caused by the present >>> role confounding. >> >> This indicates to me that, again, "one size fits all" is probably >> not realistic. > > You are right that it may be unrealistic to solve all of the > related problems, or even my "six or seven" problems, at a single > shot. OTOH, I have practical reasons to believe that all of my > "six or seven" problems could be solved with a public-keys-based > identity-layer clearly more elegantly (and with less complexity) > than we are able to do today. > > [For reference, the problems I've considered are the following: > scalability of the routing system; combined host mobility and multi- > homing; fast and vertical handovers with re-authentication; > architected NAT, IPv4/v6 interop, etc.; some forms of bad traffic > (DDoS); sub-network naming and mobility; and flexible and secure > application naming.] > > --Pekka Nikander > Is there a write-up of this ? Regards Marshall _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Dec 14 11:09:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gut8w-0002RI-EV; Thu, 14 Dec 2006 11:09:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gut8v-0002R9-7e for architecture-discuss@ietf.org; Thu, 14 Dec 2006 11:09:09 -0500 Received: from web58703.mail.re1.yahoo.com ([66.196.100.125]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gut8t-0003uK-Vh for architecture-discuss@ietf.org; Thu, 14 Dec 2006 11:09:09 -0500 Received: (qmail 78152 invoked by uid 60001); 14 Dec 2006 16:08:58 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=JSYF1J9dnaf3TtUn+o7BL3PIV4h6EZKUxf9g3k3NakQzjXJGM4oce6r7timQI6RI5EfV0m/5FWaEfCSYg9XGw1y/TLcYhCGfOy+aBxbWMI8EWm9+dUlNyBMt9RG5bKoO1/8XgvjpKBshqXieXPZH/vo4nzeLNWMB3ZhLZkMRgrI=; X-YMail-OSG: VT6QImwVM1k8GD0XSTb7oPl9_kemCFfRzS5JBtJ.1vzXyspiAluC4Hj3dMLY1zUlDfn1roqphVyrXpNwed94Lp9CJvOLgPFspbABmUC8C89nksdDg2xdceTEQcrCyJTNj5tJ231U6jeJ.A-- Received: from [207.107.50.100] by web58703.mail.re1.yahoo.com via HTTP; Thu, 14 Dec 2006 08:08:58 PST Date: Thu, 14 Dec 2006 08:08:58 -0800 (PST) From: Peter Sherbin Subject: Re: [arch-d] On the role of "transport" (was Re: Do we have "partial consensus"?) To: Pekka Nikander , John Leslie In-Reply-To: <3195C332-FDB8-45C8-A196-5247AE1059AD@nomadiclab.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <649056.76266.qm@web58703.mail.re1.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org >applications will deal with "identifiers" and routers will deal with "locators" Whout it be more clear to use "names" for "identifiers" and "addresses" for "locators"? Thanks, Peter ____________________________________________________________________________________ Cheap talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. http://voice.yahoo.com _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Dec 14 11:28:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GutQr-00020x-P6; Thu, 14 Dec 2006 11:27:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GutQp-0001zT-VS for architecture-discuss@ietf.org; Thu, 14 Dec 2006 11:27:39 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GutQn-0006G9-Ps for architecture-discuss@ietf.org; Thu, 14 Dec 2006 11:27:39 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 300CA872C5; Thu, 14 Dec 2006 11:27:37 -0500 (EST) To: architecture-discuss@ietf.org, pesherb@yahoo.com Subject: Re: [arch-d] On the role of "transport" (was Re: Do we have "partial consensus"?) Message-Id: <20061214162737.300CA872C5@mercury.lcs.mit.edu> Date: Thu, 14 Dec 2006 11:27:37 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > From: Peter Sherbin > Whout it be more clear to use "names" for "identifiers" and "addresses" > for "locators"? No, and no. Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Dec 14 16:57:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuyXy-00080I-8m; Thu, 14 Dec 2006 16:55:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuyXw-0007zf-TR for architecture-discuss@ietf.org; Thu, 14 Dec 2006 16:55:20 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Guu7r-0002Rw-Qk for architecture-discuss@ietf.org; Thu, 14 Dec 2006 12:12:09 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id 17AF54AC9B; Thu, 14 Dec 2006 12:12:04 -0500 (EST) Date: Thu, 14 Dec 2006 12:12:04 -0500 From: John Leslie To: architecture-discuss@ietf.org Message-ID: <20061214171204.GD2478@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [arch-d] Should "mobility" be "trackable"? X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Found on news.bbc.co.uk: ] ] Gartner also predicted that: ] ] By 2010, 60% of the worldwide cellular population will be "trackable" ] via an emerging "follow-me internet" (I wonder... trackable by who?) -- John Leslie _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Dec 14 17:17:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guyrx-0008K2-9u; Thu, 14 Dec 2006 17:16:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guyrw-0008Jx-Jz for architecture-discuss@ietf.org; Thu, 14 Dec 2006 17:16:00 -0500 Received: from rwcrmhc15.comcast.net ([204.127.192.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Guyrv-0000kw-3x for architecture-discuss@ietf.org; Thu, 14 Dec 2006 17:16:00 -0500 Received: from [10.0.1.33] (c-24-34-102-194.hsd1.ma.comcast.net[24.34.102.194]) by comcast.net (rwcrmhc15) with ESMTP id <20061214221557m1500qgcl9e>; Thu, 14 Dec 2006 22:15:57 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <392595.86082.qm@web58712.mail.re1.yahoo.com> Date: Thu, 14 Dec 2006 17:08:32 -0500 To: Andrew McGregor , Peter Sherbin From: John Day Subject: Re: [arch-d] Do we have "partial consensus"? Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Cc: HeinerHummel@aol.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: , Errors-To: architecture-discuss-bounces@ietf.org Catching up: No the topology shouldn't change. But the graph may. At 14:10 +1300 2006/12/14, Andrew McGregor wrote: >Unfortunately, no. > >The real network isn't nearly this simple.=20 >Solutions in this class have to derive the=20 >locators from the observed topology (which will=20 >change with time). This is the problem with=20 >Heiner's hierarchical suggestion too. Not to=20 >say that it can't be done, but we cannot posit a=20 >topological simplification; the topology is only=20 >going to get more complicated. > >Andrew > >On 14/12/2006, at 10:35 AM, Peter Sherbin wrote: > >>Would the following suffice: >> >>- the globe is covered with a hierarchical=20 >>backbone terminating at attachement >>points(AP) e.g. per every 10 sq miles >>- each AP has a unique address, i.e. fixed geo/topo location >>- every edge network has a globally unique name >>- AP maintains a table of attached names to route packets within its area >>- AP combines its address with a name to route packets outside of its area >>- the lowest size of the edge networks is one node >>- parts of the backbone are supported by various public / private entities >>- AP addresses are distributed by RIR >>- edge network names are distributed by e.g. local tax authorities >> >>The above allows free moves of edge networks=20 >>carrying only their names between >>AP. >>IETF/IANA regulates two pools of numbers:=20 >>backbone/AP addresses and edge networks' >>names. >> >>Thanks, >> >>Peter >> >>--- HeinerHummel@aol.com wrote: >> >>> >>>Some more notes pro hierarchical routing: >>> >>>PNNI : The PNNI architects are still around: Ross Callon, Joel Halpern, >>>George Swallow, Mickey Spiegel. It was a fine=20 >>>protocol development which would >>>never have been accomplished if the Bell-heads=20 >>>had understood more of it :-). >>>PNNI contains good and less good things. From some distance that can be >>>distinguished even better as to learn from both. >>> >>>There is also a nicely written draft from=20 >>>Frank Kastenholz: ISLAY. But from >>>a single draft you cannot learn "by experience", particularly you canno= t >>>learn from its worse parts. >>> >>>And: We all do hierarchical routing day by day.When it comes to travellin= g, >>>at least in your mind you do combine the city=20 >>>map where your trip starts as to >>> get to the right exit, the country road map as to get to the nearest >>>airport, a world map with all the flight=20 >>>routes as to get to the destination >>>airport. And while you haven't yet left the=20 >>>ingress city your routing decisions >>>do >>>not consider any road labor blockings nearby the hotel of your >>>destination. >>> >>>I can only repeat myself: There is no better solution than HR, and also H= R >>>is sufficiently precise. >>> >>>Heiner >>> >>>In einer eMail vom 12.12.2006 20:19:49 Westeurop=E4ische Normalzeit schre= ibt >>>john@jlc.net: >>> >>>I dare to assume Heiner didn't intend >>>" >>>" you're so far out of it that you need to go away for a week or >>>two!" >>> >>>HeinerHummel@aol.com wrote: >>>> >>>>I have a different list of objectives: >>>> >>>>- develop an architecture which fits even for a 100 times bigger >>>> internet while the workload for the individual router becomes >>>> 100 times less than is necessary today >>> >>>I agree with this objective. >>> >>>Speaking only for myself: I specifically tried to minimize the >>>"routing" "layer" task. My list contains _only_ the things I think >>>can't be moved to another layer, and specifically excludes finding >>>alternate paths if forwarding isn't possible. >>> >>>>Will say, by knowing the hierarchical network topology of 100 nodes+300 >>>>hierarchical nodes the same can be accomplished than be learning about >>>>100 million routers. >>> >>>Again speaking only for myself: In describing "layer" responsibilities >>>I did not intend that all must be accomlished in the same box. I can >>>easily imagine totally separating the "routing protocol" boxes from the >>>"forwarding" boxes. >>> >>>>- develop a one-face-only architecture (rather than a collection of >>>> completely orthogonal concepts like BGP versus OSPF) >>>>PNNI at least tried to accomplish such a one-face-only >>>>architecture. >>>>It was later, in response to PNNI, that OSPF came up with areas >>>>(simpler,less ambitious, but not as perfect in design). >>> >>>This sounds like it deserves its own thread... >>> >>>>-do routing such that fear of loops doesn't have to be at all. >>> >>>Hmm... >>> >>>I don't think "routing gurus" will get over that fear in my lifetime! >>> >>>>-do routing such that real-time traffic balancing is enabled >>> >>>Speaking only for myself: I don't think the "routing" "layer" can do >>>any more for that than signal what bandwidth is available to >>>particular >>>destinations (currently CIDR block) forwarded from each forwarder's >>>individual peers. Even that much begins to intrude on Heiner's first >>>principle (scaling by a factor of 100). >>> >>>>- do clean cuts: >>>> >>>> a) at the edges: the used technology there (LAN,WLAN,...) is outside >>>> the scope. >>> >>>I'd be happy to agree to that. However, the question seems premature. >>> >>>> b) wrt. layering and also within the routing protocol: flooding is >>>> needed for detecting the topology. As soon as the topology is >>>> provided, loopfree propagation/advertisement of whatsoever can be >>>> done better than by flooding. If it is not routing relevant but >>>> rather end-to-end relevant it should not even be part of routing. >>> >>>Feel free to start a new thread on this issue. (I'm not sure I >>>understand your point well enough to respond yet.) >>> >>>> c) wrt. addressing: >>>> PNNI tried to handle at least 3 prefix-summarizable address >>>> families (IPv4 not counted in) of users. Obviously all of them >>>> could not be used for identifying PNNI-nodes concurrently. >>>> User addresses must not be mixed up with (hierarchical) nodes' >>>> addresses. >>> >>>I agree it's important for us to _architecturally_ distinguish them. >>>I doubt, however, we will be able to prevent users from confusing them. >>> >>>-- >>>John Leslie >>> >>> >>> >>>>_______________________________________________ >>>Architecture-discuss mailing list >>>Architecture-discuss@ietf.org >>>https://www1.ietf.org/mailman/listinfo/architecture-discuss >>> >> >> >> >> >>__________________________________________________________________________= __________ >>Do you Yahoo!? >>Everyone is raving about the all-new Yahoo! Mail beta. >>http://new.mail.yahoo.com >> >>_______________________________________________ >>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 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Dec 15 08:56:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvDX6-0002dX-KB; Fri, 15 Dec 2006 08:55:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvDX5-0002dK-6O for architecture-discuss@ietf.org; Fri, 15 Dec 2006 08:55:27 -0500 Received: from mtagate3.uk.ibm.com ([195.212.29.136]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvDX2-0007Y2-Pg for architecture-discuss@ietf.org; Fri, 15 Dec 2006 08:55:27 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate3.uk.ibm.com (8.13.8/8.13.8) with ESMTP id kBFDtNUn118144 for ; Fri, 15 Dec 2006 13:55:23 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kBFDtNjG1536116 for ; Fri, 15 Dec 2006 13:55:23 GMT Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kBFDtNCg000548 for ; Fri, 15 Dec 2006 13:55:23 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kBFDtNGs000537; Fri, 15 Dec 2006 13:55:23 GMT Received: from zurich.ibm.com ([9.4.210.199]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA35954; Fri, 15 Dec 2006 14:55:22 +0100 Message-ID: <4582A94A.80002@zurich.ibm.com> Date: Fri, 15 Dec 2006 14:55:22 +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: Noel Chiappa Subject: Re: [arch-d] Major practical decision References: <20061208165449.0CD0C86ADB@mercury.lcs.mit.edu> In-Reply-To: <20061208165449.0CD0C86ADB@mercury.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Interesting thread you started there... just one point I think needs clarifying for the record: Noel Chiappa wrote: ... > However, it's not clear to me that a new end-end naming layer (e.g. SHIM6 or > HIP) is really a viable solution, because of the amount of legacy equipment > out there. (And a top of the hatly hat to David Conrad for first raising this > issue.) I.e. if your site is multi-homed, and you've deployed HIP/whatever, > that's not much use if many of the people trying to talk to you haven't. SHIM6 is specifically designed so that a shimmed host can talk to an unshimmed host (i.e., the shim becomes a no-op) and no upper layer protocol needs to be touched (i.e., the socket API continues to work). No router needs to be touched, except possibly for the exit router selection problem. Brian _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Dec 15 09:15:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvDpY-0001QN-QQ; Fri, 15 Dec 2006 09:14:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvDpX-0001Q4-Ve for architecture-discuss@ietf.org; Fri, 15 Dec 2006 09:14:31 -0500 Received: from mtagate4.uk.ibm.com ([195.212.29.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvDpT-0001Hj-BG for architecture-discuss@ietf.org; Fri, 15 Dec 2006 09:14:31 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate4.uk.ibm.com (8.13.8/8.13.8) with ESMTP id kBFEEQXm027712 for ; Fri, 15 Dec 2006 14:14:26 GMT Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kBFEEQjm1482884 for ; Fri, 15 Dec 2006 14:14:26 GMT Received: from d06av03.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av03.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kBFEEPXT029725 for ; Fri, 15 Dec 2006 14:14:25 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av03.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kBFEEPI0029712; Fri, 15 Dec 2006 14:14:25 GMT Received: from zurich.ibm.com ([9.4.210.199]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA106638; Fri, 15 Dec 2006 15:14:25 +0100 Message-ID: <4582ADC0.70909@zurich.ibm.com> Date: Fri, 15 Dec 2006 15:14:24 +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: Marshall Eubanks Subject: Re: [arch-d] Do we have "partial consensus"? References: <816DD9299957E547B5D758D7F977D6DC010F2B0F@tayexc14.americas.cpqcorp.net> <20061212165027.GA60450@verdi> <54CBE937-4DD8-462E-9ABF-85298D48CE37@multicasttech.com> <397A61D4-5B2E-4689-A417-1AC22C1C83A0@multicasttech.com> In-Reply-To: <397A61D4-5B2E-4689-A417-1AC22C1C83A0@multicasttech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > Mobile Platform Internet - Autonomous Systems on wings (or wheels > or...). Some documentation is at > http://www.multicasttech.com/mpi/ Oh boy. MPI means something very different to many networking people: Message Passing Interface. This is very widely used in high performance cluster computing, with multiple implementations. See http://www.mpi-forum.org or http://www.open-mpi.org/ . This is a very confusing acronym clash. Brian _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Dec 15 10:30:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvF0Z-0005UT-E4; Fri, 15 Dec 2006 10:29:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvF0Y-0005TE-0y for architecture-discuss@ietf.org; Fri, 15 Dec 2006 10:29:58 -0500 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvF0T-00037T-Pe for architecture-discuss@ietf.org; Fri, 15 Dec 2006 10:29:58 -0500 Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 5868946; Fri, 15 Dec 2006 10:29:53 -0500 In-Reply-To: <4582ADC0.70909@zurich.ibm.com> References: <816DD9299957E547B5D758D7F977D6DC010F2B0F@tayexc14.americas.cpqcorp.net> <20061212165027.GA60450@verdi> <54CBE937-4DD8-462E-9ABF-85298D48CE37@multicasttech.com> <397A61D4-5B2E-4689-A417-1AC22C1C83A0@multicasttech.com> <4582ADC0.70909@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <545298A3-A373-4C25-89ED-173C4FDA2E82@multicasttech.com> Content-Transfer-Encoding: 7bit From: Marshall Eubanks Subject: Re: [arch-d] Do we have "partial consensus"? Date: Fri, 15 Dec 2006 10:29:51 -0500 To: Brian E Carpenter X-Mailer: Apple Mail (2.752.2) 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: , Errors-To: architecture-discuss-bounces@ietf.org Dear Brian; On Dec 15, 2006, at 9:14 AM, Brian E Carpenter wrote: >> Mobile Platform Internet - Autonomous Systems on wings (or wheels >> or...). Some documentation is at >> http://www.multicasttech.com/mpi/ > > Oh boy. MPI means something very different to many networking people: > Message Passing Interface. This is very widely used in high > performance > cluster computing, with multiple implementations. > See http://www.mpi-forum.org or http://www.open-mpi.org/ . > > This is a very confusing acronym clash. > > Brian I suspect that every 3 letter acronym has clashes - I found the Meeting Professionals International and the Master Painters Institute, but not this one. Even with 4 letters, there are overlaps. For example, there is IETF (International Engineering & Technology Fair), a bi-annual exhibition organized by Confederation of Indian Industry (CII) since 1975 and (my favorite, for some reason) the International Essential Tremor Foundation (IETF). At any rate, I don't think that the people thinking about Internet connections to these mobile platforms are wedded to the name, and I would welcome alternative suggestions. Regards Marshall _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Dec 15 10:38:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvF8B-0000lK-Po; Fri, 15 Dec 2006 10:37:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvF8B-0000lC-8d; Fri, 15 Dec 2006 10:37:51 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvF89-0004Eu-Sl; Fri, 15 Dec 2006 10:37:51 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id kBFFbjlK003438; Fri, 15 Dec 2006 07:37:45 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id kBFFbeM9003435; Fri, 15 Dec 2006 07:37:40 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 15 Dec 2006 07:37:40 -0800 From: David Meyer To: routingworkshop@lists.i1b.org Message-ID: <20061215153739.GA2627@1-4-5.net> Mime-Version: 1.0 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: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: v6ops@ops.ietf.org, architecture-discuss@ietf.org, ram@iab.org Subject: [arch-d] draft-iab-raws-report-00.txt posted to the ID repository 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="===============1074211217==" Errors-To: architecture-discuss-bounces@ietf.org --===============1074211217== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SUOF0GtieIMvvwua" Content-Disposition: inline --SUOF0GtieIMvvwua Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable =09 Folks, First, sorry about the wide distribution and any duplicates you may receive. I just posted draft-iab-raws-report-00.txt posted to the ID repository. Until it gets there, I've put a copy on=20 http://www.1-4-5.net/~dmm/draft-iab-raws-report-00.txt for your light holiday reading :-) Looking forward to your comments and the ongoing discussion.=20 --dmm (for dmm, lixia, and kevin) --SUOF0GtieIMvvwua Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFgsFCORgD1qCZ2KcRAmcQAKCLyMeMzNx7ROt11ApvGOGLMpA1MQCfcYHF QcQMW2AAVdlBKJPCPE5EkVE= =GU14 -----END PGP SIGNATURE----- --SUOF0GtieIMvvwua-- --===============1074211217== 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 --===============1074211217==-- From architecture-discuss-bounces@ietf.org Fri Dec 15 11:11:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvFeQ-0005cI-Ob; Fri, 15 Dec 2006 11:11:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvFeP-0005c3-6I for architecture-discuss@ietf.org; Fri, 15 Dec 2006 11:11:09 -0500 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 1GvFeM-0001K3-Pz for architecture-discuss@ietf.org; Fri, 15 Dec 2006 11:11:09 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 15 Dec 2006 08:11:06 -0800 X-IronPort-AV: i="4.12,176,1165219200"; d="scan'208"; a="352159380:sNHT45550688" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kBFGB6tD002418; Fri, 15 Dec 2006 08:11:06 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kBFGAqjc023327; Fri, 15 Dec 2006 08:11:01 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Dec 2006 08:10:55 -0800 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Dec 2006 08:10:55 -0800 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Fri, 15 Dec 2006 10:10:51 -0600 From: David Ward To: David Meyer , , David Ward Message-ID: Thread-Topic: [RAM] draft-iab-raws-report-00.txt posted to the ID repository Thread-Index: AccgY5b31aKQ0oxWEduJiwAX8sbpFw== In-Reply-To: <20061215153739.GA2627@1-4-5.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 15 Dec 2006 16:10:55.0562 (UTC) FILETIME=[99AF92A0:01C72063] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1169; t=1166199066; x=1167063066; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dward@cisco.com; z=From:=20David=20Ward=20 |Subject:=20Re=3A=20[RAM]=20draft-iab-raws-report-00.txt=20posted=20to=20 the=20ID=20repository |Sender:=20; bh=aziWbth/aEjYBqLGsbxaVcosUji9SZOnQ9s1rCeqEfU=; b=PZZcMj0N5tpXKmX4/uDjSAXVkcB1P8+ZvyGv5G7zfN25G1lE7zvM054o/omjKCw1j0KR3jl+ er6+sV+fjngWqE3DUwdq9jlajVstnahYHicuw8R0kdV0/zDMu4VpXYm3; Authentication-Results: sj-dkim-2; header.From=dward@cisco.com; dkim=pass (s ig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: v6ops@ops.ietf.org, architecture-discuss@ietf.org, ram@iab.org Subject: [arch-d] Re: [RAM] draft-iab-raws-report-00.txt posted to the ID repository X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Dave - As editor of the document that captures the presentations and discussion during this workshop, how should incorrect statements be handled? Unfortunately, there are some errors in the statements that don't quite reflect reality (once example is in the Routing convergence section 7.3). Since the doc represents what was discussed, it may not be appropriate to correct the statements. Would any corrections or clarifications go into the future problem statement document that you mention? Thanks -DWard On 12/15/06 9:37 AM, "David Meyer" wrote: > > Folks, > > First, sorry about the wide distribution and any > duplicates you may receive. > > I just posted draft-iab-raws-report-00.txt posted to the > ID repository. Until it gets there, I've put a copy on > > http://www.1-4-5.net/~dmm/draft-iab-raws-report-00.txt > > for your light holiday reading :-) > > Looking forward to your comments and the ongoing > discussion. > > --dmm (for dmm, lixia, and kevin) > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Dec 15 11:23:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvFpL-0000yb-0P; Fri, 15 Dec 2006 11:22:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvFpJ-0000yP-Km; Fri, 15 Dec 2006 11:22:25 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvFpF-0002tc-T5; Fri, 15 Dec 2006 11:22:25 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id kBFGLVjE005349; Fri, 15 Dec 2006 08:21:31 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id kBFGLVbZ005348; Fri, 15 Dec 2006 08:21:31 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 15 Dec 2006 08:21:31 -0800 From: David Meyer To: David Ward Message-ID: <20061215162131.GA5146@1-4-5.net> References: <20061215153739.GA2627@1-4-5.net> Mime-Version: 1.0 In-Reply-To: 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: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: v6ops@ops.ietf.org, routingworkshop@lists.i1b.org, architecture-discuss@ietf.org, ram@iab.org Subject: [arch-d] Re: [RAM] draft-iab-raws-report-00.txt posted to the ID repository 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="===============0904350397==" Errors-To: architecture-discuss-bounces@ietf.org --===============0904350397== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PEIAKu/WMn1b1Hv9" Content-Disposition: inline --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Dave, > As editor of the document that captures the presentations and discuss= ion > during this workshop, how should incorrect statements be handled? > Unfortunately, there are some errors in the statements that don't quite > reflect reality (once example is in the Routing convergence section 7.3). > Since the doc represents what was discussed, it may not be appropriate to > correct the statements. Would any corrections or clarifications go into t= he > future problem statement document that you mention? I understand your problem with 7.3. Clearly, we understand that IGPs can (and do) converge more quickly that BGP does. If I understand your concern, it is with this text (please correct me if I'm wrong): The IGP convergence can also be very slow, which can lead to intolerable performance problems for real time applications such as VoIP. The cause for this slow convergence can be due to multiple factors, including... in that it seems to suggest that IGP convergence is *slower* that BGP convergence (correct)? If so, will text like: While IGPs are designed to and do converge much more qucikly that BGP might, the workshop participants were concerened that the growth of the size of the DFZ RIB, in addition to the various specical purpose routes they must carry can slow IGP convergence. The cause for this slow convergence can be due to multiple factors, including.... or similar address your concern?=20 thnx for the comments, --dmm --PEIAKu/WMn1b1Hv9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFgsuLORgD1qCZ2KcRAuyJAJ41UlVqsAnpanA/u5g2dKnCjW68AgCfVAGj Kqkp2i8oq7oBS2kHCpfLR80= =upIN -----END PGP SIGNATURE----- --PEIAKu/WMn1b1Hv9-- --===============0904350397== 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 --===============0904350397==-- From architecture-discuss-bounces@ietf.org Fri Dec 15 11:45:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvGAm-00039R-1R; Fri, 15 Dec 2006 11:44:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvGAk-00035Y-LH for architecture-discuss@ietf.org; Fri, 15 Dec 2006 11:44:34 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvGAh-0006fS-Ji for architecture-discuss@ietf.org; Fri, 15 Dec 2006 11:44:34 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 15 Dec 2006 08:44:31 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id kBFGiUPI025452; Fri, 15 Dec 2006 08:44:30 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kBFGiQZi027911; Fri, 15 Dec 2006 08:44:26 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Dec 2006 08:44:25 -0800 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Dec 2006 08:44:25 -0800 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Fri, 15 Dec 2006 10:44:21 -0600 From: David Ward To: David Meyer , David Ward Message-ID: Thread-Topic: [RAM] draft-iab-raws-report-00.txt posted to the ID repository Thread-Index: AccgaEUFg7PkGoxbEduJiwAX8sbpFw== In-Reply-To: <20061215162131.GA5146@1-4-5.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 15 Dec 2006 16:44:25.0619 (UTC) FILETIME=[47C5EE30:01C72068] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2308; t=1166201070; x=1167065070; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dward@cisco.com; z=From:=20David=20Ward=20 |Subject:=20Re=3A=20[RAM]=20draft-iab-raws-report-00.txt=20posted=20to=20 the=20ID=20repository |Sender:=20; bh=RnkmmfNq27+3cL+3FXUt/TK90wNKZY9g1N6QFNIEtJw=; b=lBoiWkhxO0PPRB4uDtbhTPNNbLcpQlO2WLxT/hIHT05ZPMeO3KmV4/ebjYLTCjxYvpUVkv5p vkWENMPuoSY7iURXyn03W1ayhbpG8aMw1KylSgpBOMHdpVLuluFCnMRB; Authentication-Results: sj-dkim-5; header.From=dward@cisco.com; dkim=pass (s ig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: v6ops@ops.ietf.org, routingworkshop@lists.i1b.org, architecture-discuss@ietf.org, ram@iab.org Subject: [arch-d] Re: [RAM] draft-iab-raws-report-00.txt posted to the ID repository X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Dave - It is better but, still not completely correct (given the remainder of the section). The meta-point is that the doc is a statement of what was discussed in the workshop. There are factual errors in the doc in addition to what I cited (I purposefully chose perhaps the least controversial in 7.3). Your answer below implies that you would like the workshop doc to be correct vs leaving it as a statement from the workshop and then having the problem statement fully clarified. I suggest that you proceed forward w/ the problem statement and not potentially revise history. Of course, it is up to authors and group ... 0.02$ -DWard On 12/15/06 10:21 AM, "David Meyer" wrote: > Dave, > >> As editor of the document that captures the presentations and discussion >> during this workshop, how should incorrect statements be handled? >> Unfortunately, there are some errors in the statements that don't quite >> reflect reality (once example is in the Routing convergence section 7.3). >> Since the doc represents what was discussed, it may not be appropriate to >> correct the statements. Would any corrections or clarifications go into the >> future problem statement document that you mention? > > I understand your problem with 7.3. Clearly, we > understand that IGPs can (and do) converge more quickly > that BGP does. If I understand your concern, it is with > this text (please correct me if I'm wrong): > > The IGP convergence can also be very slow, which can > lead to intolerable performance problems for real time > applications such as VoIP. The cause for this slow > convergence can be due to multiple factors, including... > > in that it seems to suggest that IGP convergence is > *slower* that BGP convergence (correct)? If so, will > text like: > > While IGPs are designed to and do converge much more > qucikly that BGP might, the workshop participants were > concerened that the growth of the size of the DFZ RIB, > in addition to the various specical purpose routes > they must carry can slow IGP convergence. The cause > for this slow convergence can be due to multiple > factors, including.... > > or similar address your concern? > > thnx for the comments, > > --dmm > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Dec 15 12:03:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvGSc-0002mM-7t; Fri, 15 Dec 2006 12:03:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvGSb-0002mA-8v; Fri, 15 Dec 2006 12:03:01 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvGSU-0001PV-Rf; Fri, 15 Dec 2006 12:03:01 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id kBFH2nos006503; Fri, 15 Dec 2006 09:02:49 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id kBFH2f4g006502; Fri, 15 Dec 2006 09:02:41 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 15 Dec 2006 09:02:41 -0800 From: David Meyer To: David Ward Message-ID: <20061215170241.GC6427@1-4-5.net> References: <20061215162131.GA5146@1-4-5.net> Mime-Version: 1.0 In-Reply-To: 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: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: v6ops@ops.ietf.org, routingworkshop@lists.i1b.org, architecture-discuss@ietf.org, ram@iab.org Subject: [arch-d] Re: [RAM] draft-iab-raws-report-00.txt posted to the ID repository 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="===============0437972605==" Errors-To: architecture-discuss-bounces@ietf.org --===============0437972605== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DIOMP1UsTsWJauNi" Content-Disposition: inline --DIOMP1UsTsWJauNi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 15, 2006 at 10:44:21AM -0600, David Ward wrote: > Dave - >=20 > It is better but, still not completely correct (given the remainder of > the section). The meta-point is that the doc is a statement of what was > discussed in the workshop. There are factual errors in the doc in addition > to what I cited (I purposefully chose perhaps the least controversial in > 7.3). Your answer below implies that you would like the workshop doc to be > correct vs leaving it as a statement from the workshop and then having the > problem statement fully clarified. I suggest that you proceed forward w/ = the > problem statement and not potentially revise history. Of course, it is up= to > authors and group ... Well, what the report is supposed to reflect is what happened at the workshop. So I didn't intend to revise history, but rather clarify what was said. --dmm --DIOMP1UsTsWJauNi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFgtUxORgD1qCZ2KcRAihXAJ0fL9/D8h1W0S6xRPveW0RmeeUahACdFizH Gtj6SXrKsHTWeijFCQTPYio= =pQjo -----END PGP SIGNATURE----- --DIOMP1UsTsWJauNi-- --===============0437972605== 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 --===============0437972605==-- From architecture-discuss-bounces@ietf.org Fri Dec 15 13:43:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvI0T-0007eY-L1; Fri, 15 Dec 2006 13:42:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvI0S-0007eK-E1; Fri, 15 Dec 2006 13:42:04 -0500 Received: from imo-d23.mx.aol.com ([205.188.139.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvI0R-0007R8-34; Fri, 15 Dec 2006 13:42:04 -0500 Received: from HeinerHummel@aol.com by imo-d23.mx.aol.com (mail_out_v38_r7.6.) id z.471.355fb5df (40520); Fri, 15 Dec 2006 13:41:42 -0500 (EST) From: HeinerHummel@aol.com Message-ID: <471.355fb5df.32b44663@aol.com> Date: Fri, 15 Dec 2006 13:41:39 EST Subject: Re: [arch-d] Re: [RAM] draft-iab-raws-report-00.txt posted to the ID repository To: dmm@1-4-5.net, dward@cisco.com MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5009 X-Spam-Flag: NO X-Spam-Score: 0.2 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: v6ops@ops.ietf.org, routingworkshop@lists.i1b.org, architecture-discuss@ietf.org, ram@iab.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="===============0603326532==" Errors-To: architecture-discuss-bounces@ietf.org --===============0603326532== Content-Type: multipart/alternative; boundary="-----------------------------1166208099" -------------------------------1166208099 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 I am glad that this IAB-workshop confirms my saying that there is no future=20= =20 with IPv6 and BGP.Both are children of the 90's. Also: it is not only the ba= d =20 convergency of BGP (which is due to its flat design and which is also the=20 cause for instability(=3Drouting churn) AND non-scalability. Furthermore i= t=20 prevents real-time traffic balancing for good. OSPF could do better, but do= esn't=20 either as long as there is this SPF-dogma ( I accused it four years ago in=20= a=20 longer thread "Rambo-SPF....") where each router behaves as if it were the=20 center of the internet :-( =20 Heiner =20 =20 In einer eMail vom 15.12.2006 18:04:48 Westeurop=E4ische Normalzeit schreibt= =20 dmm@1-4-5.net: On Fri, Dec 15, 2006 at 10:44:21AM -0600, David Ward wrote: > Dave - > =20 > It is better but, still not completely correct (given the remainder o= f > the section). The meta-point is that the doc is a statement of what was > discussed in the workshop. There are factual errors in the doc in additio= n > to what I cited (I purposefully chose perhaps the least controversial in > 7.3). Your answer below implies that you would like the workshop doc to b= e > correct vs leaving it as a statement from the workshop and then having th= e > problem statement fully clarified. I suggest that you proceed forward w/=20 the > problem statement and not potentially revise history. Of course, it is up= =20 to > authors and group ... Well, what the report is supposed to reflect is what happened at the workshop. So I didn't intend to revise history, but rather clarify what was said. --dmm _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss -------------------------------1166208099 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
I am glad that this IAB-workshop confirms my saying that there is no fu= ture=20 with IPv6 and BGP.Both are children of the 90's. Also: it is not only the ba= d=20 convergency of BGP (which is due to its flat design and which  is=20 also the cause  for instability(=3Drouting churn) AND non-scalabil= ity.=20 Furthermore it prevents real-time traffic balancing for good. OSPF coul= d do=20 better, but doesn't either as long as there is this SPF-dogma ( I accused it= =20 four years ago in a longer thread "Rambo-SPF....") where each router behaves= as=20 if it were the center of the internet :-(
 
Heiner
 
 
In einer eMail vom 15.12.2006 18:04:48 Westeurop=E4ische Normalzeit sch= reibt=20 dmm@1-4-5.net:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>On Fri,=20 Dec 15, 2006 at 10:44:21AM -0600, David Ward wrote:
> Dave -
>= =20
>     It is better but, still not completely correct= =20 (given the remainder of
> the section). The meta-point is that the d= oc=20 is a statement of what was
> discussed in the workshop. There are=20 factual errors in the doc in addition
> to what I cited (I purposefu= lly=20 chose perhaps the least controversial in
> 7.3). Your answer below=20 implies that you would like the workshop doc to be
> correct vs leav= ing=20 it as a statement from the workshop and then having the
> problem=20 statement fully clarified. I suggest that you proceed forward w/ the
&g= t;=20 problem statement and not potentially revise history. Of course, it is up=20 to
> authors and group ...

    Well, what the repor= t is=20 supposed to reflect is what
    happened at the workshop. So=20= I=20 didn't intend to revise
    history, but rather clarify what=20= was=20 said.

   =20 --dmm

_______________________________________________
Architectu= re-discuss=20 mailing=20 list
Architecture-discuss@ietf.org
https://www1.ietf.org/mailman/lis= tinfo/architecture-discuss
 
-------------------------------1166208099-- --===============0603326532== 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 --===============0603326532==-- From architecture-discuss-bounces@ietf.org Sat Dec 16 04:08:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvVV8-0001ef-T8; Sat, 16 Dec 2006 04:06:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvVV7-0001eU-Da for architecture-discuss@ietf.org; Sat, 16 Dec 2006 04:06:37 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvVV3-0005Mw-Mk for architecture-discuss@ietf.org; Sat, 16 Dec 2006 04:06:37 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 5CD63212F4E; Sat, 16 Dec 2006 11:06:25 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id C0437212F45; Sat, 16 Dec 2006 11:06:24 +0200 (EET) In-Reply-To: <397A61D4-5B2E-4689-A417-1AC22C1C83A0@multicasttech.com> References: <816DD9299957E547B5D758D7F977D6DC010F2B0F@tayexc14.americas.cpqcorp.net> <20061212165027.GA60450@verdi> <54CBE937-4DD8-462E-9ABF-85298D48CE37@multicasttech.com> <397A61D4-5B2E-4689-A417-1AC22C1C83A0@multicasttech.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <812E1D29-A610-42AB-ADF7-18CDCF51F703@nomadiclab.com> Content-Transfer-Encoding: quoted-printable From: Pekka Nikander Subject: Re: [arch-d] Do we have "partial consensus"? Date: Sat, 16 Dec 2006 11:06:23 +0200 To: Marshall Eubanks X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Dear Marshall, > Also note that in this mobile case, you need to include a time tag, =20= > as the locators will change with time and old locators will require =20= > different routing. (Locators might change significantly during a =20 > long tcp session, for example.) An interesting observation! But I have never thought that we'd try =20 to address fast mobility at IP layer. Future location prediction is =20 nothing new in mobile radio networks, of course. For example, =20 complex MIMO (multiple in, multiple out) antenna systems do it all =20 the time to get the interference patterns right. >> You are right that it may be unrealistic to solve all of the =20 >> related problems, or even my "six or seven" problems, at a single =20 >> shot. OTOH, I have practical reasons to believe that all of my =20 >> "six or seven" problems could be solved with a public-keys-based =20 >> identity-layer clearly more elegantly (and with less complexity) =20 >> than we are able to do today. >> >> [For reference, the problems I've considered are the following: =20 >> scalability of the routing system; combined host mobility and =20 >> multi-homing; fast and vertical handovers with re-authentication; =20 >> architected NAT, IPv4/v6 interop, etc.; some forms of bad traffic =20 >> (DDoS); sub-network naming and mobility; and flexible and secure =20 >> application naming.] > > Is there a write-up of this ? Not a single one, but see below. As you may know, most of our practical work in this are was done with =20= HIP, but mostly be applied to many other architectural options, too. =20= Considering the issues, I am not aware of any papers that would =20 directly address routing and forwarding with HIP -- we've generally =20 assumed that since it allows the locators to be rewritten in the fly =20 it would do as well as any id/loc split mechanism. For some considerations and comparison to legacy NAT, see [1]. =20 Combined mobility and multi-homing is described in [2], [3] and [4]. =20= For fast handovers, see e.g. [5], for vertical handovers, e.g. [6]; I =20= haven't been that much involved in that work and don't know all the =20 details. Architected NAT and IPv4/IPv6 interoperability is discussed =20= in [1], [3], [7], and [8]. DoS is addressed in RFC 4423, DDoS in [9] =20= and [10]. Sub-network mobility is still work in progress and I am =20 not aware of publications, but there are submitted papers and we have =20= a working prototype. Application naming is discussed in [11]. --Pekka Nikander [1] Jukka Ylitalo, Patrik Salmela, and Hannes Tschofenig, "SPINAT: =20 Integrating IPsec into Overlay Routing", in Proc. of the First =20 International Conference on Security and Privacy for Emerging Areas =20 in Communication Networks (SecureComm'05), Athens, Greece, September =20 5-9, 2005. http://users.tkk.fi/~jylitalo/publications/SecureComm05-=20 Ylitalo-et-al.pdf [2] Pekka Nikander, Jukka Ylitalo, and Jorma Wall, "Integrating =20 Security, Mobility, and Multi-Homing in a HIP Way", in Proc. of =20 Network and Distributed Systems Security Symposium (NDSS'03), pp. =20 87-99, ISBN 1-891562-16-9, Internet Society, San Diego, CA, US, =20 February 6-7, 2003. http://www.tml.tkk.fi/~pnr/publications/NDSS03-Nikander-et-al.pdf [3] Jukka Ylitalo, Pekka Nikander, "A new Name Space for End-Points: =20 Implementing secure Mobility and Multi-homing across the two versions =20= of IP," in Proceedings of the Fifth European Wireless Conference, =20 Mobile and Wireless Systems beyond 3G (EW2004), pp. 435-441, =20 Barcelona, Spain, February 24-27, 2004. http://www.tml.tkk.fi/~pnr/publications/ew2004.pdf [4] T. Henderson (ed), "End-Host Mobility and Multihoming with the =20 Host Identity Protocol", ID, IETF. http://www.ietf.org/internet-drafts/draft-ietf-hip-mm-04.txt [5] Jari Arkko and Pekka Nikander, "Fast network attachment", =20 WO2006018045, EPO. [6] Jokela P., Wall J., Melen J., Rinta-aho T., Kauppinen T., =20 Mahkonen H., Jokikyyny T., Kuparinen M., Korhonen J., "Handover Performance with HIP and MIPv6", =20= International Symposium on Wireless Communication Systems, in Proceedings of ISWCS'04. [7] Hannes Tschofenig, Andrei Gurtov, Jukka Ylitalo, Aarthi =20 Nagarajan, and Murugaraj Shanmugam, "Traversing Middleboxes with the =20 Host Identity Protocol", in Proc. of the Tenth Australasian =20 Conference on Information Security and Privacy (ACISP'05), Brisbane, =20 Australia, July 4-6, 2005. http://users.tkk.fi/~jylitalo/publications/ACISP2005-Tschofenig-et-=20 al.pdf [8] Petri Jokela, Pekka Nikander, Jan Melen, Jukka Ylitalo and Jorma =20 Wall, "Host Identity Protocol: Achieving IPv4 - IPv6 handovers =20 without tunneling", in Proceedings of Evolute workshop 2003: "Beyond =20 3G Evolution of Systems and Services", University of Surrey, =20 Guildford, UK, November 10, 2003. http://www.tml.tkk.fi/~pnr/publications/evolute2003.pdf [9] Pekka Nikander, Jari Arkko, and B=F6rje Ohlman, Host Identity =20 Indirection Infrastructure (Hi3)," in Proceedings of The Second =20 Swedish National Computer Networking Workshop 2004 (SNCNW2004), =20 Karlstad University, Karlstad, Sweden, Nov 23-24, 2004. http://www.tml.tkk.fi/~pnr/publications/sncnw2004.pdf [10] Andrei Gurtov, Dmitry Korzun, Pekka Nikander, "Hi3: An Efficient =20= and Secure Networking Architecture for Mobile Hosts," Technical =20 report 2005-2, Helsinki Institute for Information Technology, June 2005. http://www.tml.tkk.fi/~pnr/publications/HIIT_gurtov_hi3_report_2005.pdf [11] Teemu Koponen, Andrei Gurtov, Pekka Nikander, "Application =20 mobility with Host Identity Protocol," Extended Abstract in Proc. of =20 NDSS Wireless and Mobile Security Workshop, San Diego, CA, USA, =20 February 2005. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Dec 17 09:38:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gvx8B-00020d-Ce; Sun, 17 Dec 2006 09:36:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gvx8A-00020W-Cv for architecture-discuss@ietf.org; Sun, 17 Dec 2006 09:36:46 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gvx85-0004WJ-2f for architecture-discuss@ietf.org; Sun, 17 Dec 2006 09:36:46 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id BD0B834084; Sun, 17 Dec 2006 09:36:43 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 17 Dec 2006 09:36:40 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.5 Subject: RE: [arch-d] Major practical decision Date: Sun, 17 Dec 2006 09:36:38 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC01178F6F@tayexc14.americas.cpqcorp.net> In-Reply-To: <20061211154942.D7D0E86AE4@mercury.lcs.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Major practical decision Thread-Index: AccdO/1gvCEuYwZnTPSJX3cT2AJg1QEq8ptA From: "Bound, Jim" To: "Noel Chiappa" , X-OriginalArrivalTime: 17 Dec 2006 14:36:40.0274 (UTC) FILETIME=[C3B29B20:01C721E8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org =20 > -----Original Message----- > From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu]=20 > Sent: Monday, December 11, 2006 10:50 AM > To: architecture-discuss@ietf.org > Cc: jnc@mercury.lcs.mit.edu > Subject: RE: [arch-d] Major practical decision >=20 > > From: "Bound, Jim" >=20 > >> The question of whether we add a new end-end=20 > namespace, or a new > >> routing-names namespace >=20 > > I think we need two new name spaces. >=20 > Actually, as I was thinking all this over last night, I=20 > decided that I had missed one option I had spoken of earlier,=20 > which is (exactly as you say) to have two new namespaces; one=20 > for routing-name, and one for end-end identity. > I.e. migrate out of the existing IPvN "addresses" in both=20 > directions at once. Agree I would suggest using the word "transition" than migration. >=20 > However, I worry that that will be a bit much for everyone to=20 > swallow! :-) Not with a good transition strategy. That is key. >=20 >=20 > > The transition will require jack-up but eventually the=20 > jack-up should > > not be required in either case. >=20 > Well, by "jack-up" I simply mean the insertion of a new=20 > layer. *How* that happens I was not yet discussing (as Pekka=20 > pointed out, that's to some degree orthagonal to more basic=20 > questions like "how many namespaces").=20 I agree with Pekka for idea generation I do not agree that we can complete any new model or architecture without considering transition at some point. >I would assume that=20 > initially it would be done invisibly to the hosts, by=20 > "mapping boxes" acting on their behalf (so we don't need to=20 > change any hosts), but that over time hosts might become=20 > aware of the existence of another layer down there. That is where we discuss SHIM6 as potential Jack-Up at least for end-to-end and for routing I agree it should be transparent to hosts. But the concept of routers, switch, and gateway nodes is becoming blurred in the market as a point to note. =20 >=20 > I may be misunderstanding the implications of your comment,=20 > but let me see if this is what you meant: were you saying=20 > that initial deployment of jack-up would be invisible to=20 > hosts, but that eventually we might dispense with the mapping=20 > boxes, and the hosts would do it all themselves? For hosts end-to-end yes. >=20 > I say that because if the jack-up inserts a new layer which=20 > is used for routing, I can't see how we'd ever be able to=20 > stop using that new layer (which is what your comment=20 > "eventually the jack-up should not be required" > might be read to mean). I guess that depends on how we arechitect the new model. Have to reserve the right to comment later as we progress but I do see your point today. >=20 >=20 > > Where we can use existing tools to help is probably a=20 > wise excercise > > depending on our time-to-market resolution to IAB concerns. >=20 > Do you mean that we might re-cycle existing protocols/code=20 > for the new higher and lower layers? I agree that's a good=20 > goal, but I would not like to cramp long-term development by=20 > insisting that we have to use the most simplistic option. This gets to the engineering part of the job. Due dilligence for engineering I believe will guide what we need to do as opposed to computer science exercise where we may not worry as much about the business case, deployment with current infrastructure etc. Big diff between engineering and computer science for "networking". >=20 > E.g. if we do jack-up, I'd like to use MPLS as the=20 > inter-router forwarding element of the new internetworking=20 > layer, rather than IPvN. The original IPv4 architecture=20 > assumed the same packet format for inter-router communication=20 > as for host-router communication, but I'm not sure that=20 > simplification is really apt anymore in such a large system=20 > (since larger systems always benefit from more specialization). I understand what your saying and will agree IFF we mean a core between to edge networks. Best, /jim >=20 > Noel >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Dec 17 09:43:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvxEC-0004WO-7Y; Sun, 17 Dec 2006 09:43:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvxEA-0004V6-SA for architecture-discuss@ietf.org; Sun, 17 Dec 2006 09:42:58 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvxE5-0005w3-Ld for architecture-discuss@ietf.org; Sun, 17 Dec 2006 09:42:58 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 1FC7634068; Sun, 17 Dec 2006 09:42:57 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 17 Dec 2006 09:42:53 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.5 Subject: RE: [arch-d] Do we have "partial consensus"? Date: Sun, 17 Dec 2006 09:42:52 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC01178F72@tayexc14.americas.cpqcorp.net> In-Reply-To: <911982.53372.qm@web31804.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Do we have "partial consensus"? Thread-Index: AcceHiJzsec2Z0jeQj+P+ADBECYl8QDyzDZQ From: "Bound, Jim" To: "David Barak" , X-OriginalArrivalTime: 17 Dec 2006 14:42:53.0206 (UTC) FILETIME=[A1FB8360:01C721E9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org =20 > > and "transport" is responsible for > > - detecting and adjusting for packet loss; > > - detecting and adjusting for packet corruption; > > - reducing packet injection rate when a path is congested; > > - choosing among multiple paths (if available). >=20 > I was okay until I got here :) >=20 > If you do that, you lose the benefit of in-band signalling,=20 > and are more likely to have the routing and transport layers=20 > disagree about what the optimum path is. On the contrary is my view. The capability to use in-band-signaling to identify best multiple paths is something that should be made easier with the new model. I also believe one of the inputs to the forwarding path is information from end nodes using in-band-signaling but lets not go down the QoS path for now. But QoS is a part of what needs some thought for a new model. /jim _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Dec 17 09:51:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvxLr-0005hD-Cj; Sun, 17 Dec 2006 09:50:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvxLq-0005h7-MI for architecture-discuss@ietf.org; Sun, 17 Dec 2006 09:50:54 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvxLm-0007Os-9B for architecture-discuss@ietf.org; Sun, 17 Dec 2006 09:50:54 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 8920134068; Sun, 17 Dec 2006 09:50:52 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 17 Dec 2006 09:50:49 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.5 Subject: RE: [arch-d] On the role of "transport" (was Re: Do we have "partialconsensus"?) Date: Sun, 17 Dec 2006 09:50:48 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC01178F74@tayexc14.americas.cpqcorp.net> In-Reply-To: <3195C332-FDB8-45C8-A196-5247AE1059AD@nomadiclab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] On the role of "transport" (was Re: Do we have "partialconsensus"?) Thread-Index: AccfUcRh3ZXIFH8SS8SzI8T1lYywtQCmMFtg From: "Bound, Jim" To: "Pekka Nikander" , "John Leslie" X-OriginalArrivalTime: 17 Dec 2006 14:50:49.0841 (UTC) FILETIME=[BE143E10:01C721EA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org We need a transport layer Pekka or call it what you want but it must exist and its between the internet-networking layer and the apps layer. Unless I misundertand your input? Also we are not done we have no way to gage consensus and until we have that saying we are done is not fair. Someone needs to write all this down in a draft at minimum. /jim=20 > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Sent: Thursday, December 14, 2006 2:30 AM > To: John Leslie > Cc: architecture-discuss@ietf.org > Subject: [arch-d] On the role of "transport" (was Re: Do we=20 > have "partialconsensus"?) >=20 > John, >=20 > In general I feel we had mostly terminology disagreements,=20 > partly reflecting that we apparently look at the problem from=20 > slightly different angles. We also seem to be mostly over=20 > with the terminology issues. I'd be happy with what Noel=20 > stated about the terms. >=20 > Disregarding the terminology, I think we are in pretty good=20 > overall agreement sans how to handle the "transport". Hence,=20 > I'm focusing on that, but before I get to that, I need to do=20 > a small detour. >=20 >=20 > To start with, and as I have stated at least three times so=20 > far, if we think about our current global communications=20 > system as sets of components, we can see there three=20 > independently changing sets of > components: "routers", "host os stacks", and "applications". =20 > [Note that the structure is *economic*, not technical. The=20 > sets of components have different purchasing cycles and=20 > lifetimes.] Between the components, we have two relatively=20 > well defined and understood > interfaces: >=20 > 1. One between routers and stacks, i.e., sending IP packets=20 > over Ethernet, PPP, etc. >=20 > 2. One between stacks and applications, i.e., the socket API=20 > and its equivalents. >=20 > These two interfaces are the ones that are hardest to change=20 > as changing them requires that more than one of the involved=20 > component sets are changed at the same time. Changing the=20 > syntax of the interfaces is almost out of the question. =20 > Changing semantics -- that we need to do, but we need to be=20 > pretty careful when doing so. >=20 >=20 > Now, architecturally, to implement the identifier / locator=20 > separation we seem to have two fundamentally different paths: >=20 > 1. In what Noel calls the "jack up" approaches, we change the=20 > "routers". Conversely, we change the semantics of what now=20 > are IP addresses to "identifiers" at *both* interfaces. In=20 > this approach, what now are IP addresses will become=20 > "identifiers", both within the "stacks" and "applications". =20 > In this model, "locators" are internal to the network, and=20 > only seen by (some) "routers". >=20 > 2. In the "shim" approaches (HIP/SHIM6/SCTP/...), we change=20 > the "stacks"; perhaps not immediately but eventually. =20 > Conversely, we change the semantics of what now are IP=20 > addresses so that they become "locators" at the=20 > "router/stack" interface and "identifiers" at the=20 > "stack/application" interface. As a consequence,=20 > applications will deal with "identifiers" and routers will=20 > deal with "locators"; the "stack" will do the translation. >=20 > While writing this, I noticed that, at least in theory, we=20 > also have a third approach. [But I am not aware of any=20 > viable solution proposals here.] >=20 > 3. In the "apps" approaches we change the "apps"; not=20 > necessarily the apps themselves but e.g. resolution,=20 > libraries, etc. Conversely, we change the semantics of what=20 > now are "IP addresses" so that they become "locators" at=20 > *both* of the interfaces. The "apps layer" will =20 > do the translation, and "identifiers" are internal to the apps. =20 > [This approach also has problems related to e.g. TCP state=20 > during mobility events, so it may be impossible to do a=20 > clean-cut implementation based on this architectural approach.] >=20 > Four more notes before we get to the point: >=20 > 1a. It is also possible to implement the "jack up"=20 > mechanisms in the hosts, but that changes the underlying=20 > trust model and therefore security properties. The=20 > consequences and implications -- think about them. >=20 > 2a. It is possible to implement the "shim" mechanisms in a=20 > separate box (proxy) in a way that structurally resembles the=20 > "jack up" =20 > mechanisms. But, the trust model is slightly different than=20 > in a plain, "stack" based "shim" approach. >=20 > 3a. I have hard time imagining how to implement the "apps"=20 > approach in a proxy box, but intuitively I have the feeling=20 > that it should be doable. >=20 > 4. Implication: From an implementation point of view, the difference =20 > between the "jack up" and "shim" approaches need not be that big. =20 > Both can be implemented either in some new "router" boxes or=20 > in the host os stacks, or in some combination thereof. =20 > Perhaps even the "apps" approach can be implemented in that way. >=20 > Ergo: The differences are architectural, reflecting different=20 > architectural semantics and fundamentally different trust models! >=20 >=20 > Now we are finally done with our detour and I get to my point: >=20 > If you read carefully what I stated above, I did not need the=20 > word "transport", not even once. And I did not try to avoid=20 > it -- it just wasn't needed. >=20 > t is pretty clear that somewhere within the "router layer" we=20 > will need "locators", aka routing names. It is pretty clear=20 > that in the "application layer" we will need "identifiers",=20 > identifying entities that the apps are interested in. =20 > [Whether the ids identify "hosts", "stacks", or other=20 > entities will need to be discussed, but that can be=20 > deferred.] It is pretty clear that somewhere we will need to=20 > make a translation between them. >=20 > However, that translation can take place in at least four different > locations: >=20 > 1. In the routing system, resulting in "jack up". >=20 > 2. In the stack as a "shim", with at least two potential=20 > choices for the location: >=20 > 2a. In the "internetworking" layer, somewhere near IPsec, similar to > SHIM6 and HIP. >=20 > 2b. In the "transport" layer, similar to SCTP add IP. >=20 > 3. In the "apps layer", e.g., in a library. >=20 > If we talk about the "transport" layer and "transport" names,=20 > that gives the implication that the "transport" needs stable,=20 > location- independent names. I don't think that's the case. =20 > Its the applications that have the need for such=20 > entity-referring location- independent stable names. Hence,=20 > I prefer to consider the "upper names" aka "identifiers" as=20 > something that the applications, not the transport, are=20 > interested in. From a theoretical point of view, it is an=20 > open question whether the "transport" should see them or not. >=20 > --Pekka Nikander >=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 Sun Dec 17 09:53:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvxOS-0007E3-Aa; Sun, 17 Dec 2006 09:53:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvxOR-0007Dy-CS for architecture-discuss@ietf.org; Sun, 17 Dec 2006 09:53:35 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvxOM-0007nf-5b for architecture-discuss@ietf.org; Sun, 17 Dec 2006 09:53:35 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 070CE34049; Sun, 17 Dec 2006 09:53:32 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 17 Dec 2006 09:53:29 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.5 Subject: RE: [arch-d] Do we have "partial consensus"? Date: Sun, 17 Dec 2006 09:53:28 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC01178F77@tayexc14.americas.cpqcorp.net> In-Reply-To: <021e01c71f65$8cbb6dc0$0601a8c0@pc6> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Do we have "partial consensus"? Thread-Index: AccfbhWWoec3X1nrRTCcQWwQcQ4u8ACfLN9g From: "Bound, Jim" To: "tom.petch" , , "Noel Chiappa" X-OriginalArrivalTime: 17 Dec 2006 14:53:29.0765 (UTC) FILETIME=[1D66B550:01C721EB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org =20 > The corollary is that you need a directory service to at=20 > least do the forward if not the reverse mapping. What I have=20 > never understood is why, in IP, it is the lower layer address=20 > (IP) that is used by the upper layers (see for example the=20 > analyses performed by v6ops in support of a change of format=20 > of the lower layer > address) when, in theory, a distinct upper layer address=20 > (DNS) is available. I brought this up early on this list. This is one of my concerns this will not scale for forwarding to look up in some name space directory there is a required caching mechanism similar to DNS zone transfer or X.500 transfers for the name space. Assuming a look up at each forwarding point in a stack is not wise. DNS to me I will say now is not an option in my view. /jim _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Dec 17 09:54:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvxP7-00085m-78; Sun, 17 Dec 2006 09:54:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvxP5-00083G-1S for architecture-discuss@ietf.org; Sun, 17 Dec 2006 09:54:15 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvxOz-0007tf-NX for architecture-discuss@ietf.org; Sun, 17 Dec 2006 09:54:15 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id EE85B34068; Sun, 17 Dec 2006 09:54:09 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 17 Dec 2006 09:54:09 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.5 Subject: RE: [arch-d] Do we have "partial consensus"? Date: Sun, 17 Dec 2006 09:54:08 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC01178F78@tayexc14.americas.cpqcorp.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Do we have "partial consensus"? Thread-Index: AccfbsrO7HYKxfdIQGe7gEF1LIryMgCfGDHw From: "Bound, Jim" To: "Pekka Nikander" , "Marshall Eubanks" X-OriginalArrivalTime: 17 Dec 2006 14:54:09.0351 (UTC) FILETIME=[34FF0D70:01C721EB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org MPI is a message passing interface and used widely. /jim=20 > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Sent: Thursday, December 14, 2006 5:58 AM > To: Marshall Eubanks > Cc: architecture-discuss@ietf.org > Subject: Re: [arch-d] Do we have "partial consensus"? >=20 > >> That said, I agree that we need to separate the currently=20 > confounded=20 > >> "identifier" and "locator" roles of IP addresses, thereby creating=20 > >> two distinct name spaces. The "identifier" name space=20 > will be mainly=20 > >> used by applications and the "locator" name space by routing and=20 > >> forwarding. > >> > >> I'm afraid that we haven't received any kind of consensus=20 > on how to=20 > >> do that separation. > > > > Is it realistic to assume that that there will be only one split ? =20 > > (For example, in the MPI case a geographically based locator might=20 > > make sense, while for static networks a locator based on network=20 > > hierarchy is probably more appropriate, and these very different=20 > > choices will influence the type of locator, and maybe the type of=20 > > identifier, chosen.) So wouldn't the first step be the=20 > selection of a=20 > > means to identify the split being taken ? >=20 > I am not sure if I understand you correctly (e.g. I don't=20 > know what you refer to with "MPI"), but if I understand you=20 > correctly, to me your statement feels like that you would=20 > like to have multiple different locator spaces. If so, as I=20 > have written before, I don't see any architectural reason why=20 > an id/loc split implementation couldn't include mechanisms=20 > for architected NATs and NATPs, thereby allowing different=20 > locators and routing mechanisms at different areas in the net. >=20 > On the other hand, I would see there tremendous social=20 > utility value if we managed to move back to a single, global=20 > identifier space. >=20 > >> To further clarify: in this case, I find it very hard to=20 > produce an=20 > >> exact definition of all the architecturally inclined=20 > problems that we=20 > >> have; for example, I can easily count to up to six or=20 > seven different=20 > >> problems, all partially caused by the present role confounding. > > > > This indicates to me that, again, "one size fits all" is=20 > probably not=20 > > realistic. >=20 > You are right that it may be unrealistic to solve all of the related =20 > problems, or even my "six or seven" problems, at a single shot. =20 > OTOH, I have practical reasons to believe that all of my "six=20 > or seven" problems could be solved with a public-keys-based=20 > identity- layer clearly more elegantly (and with less=20 > complexity) than we are able to do today. >=20 > [For reference, the problems I've considered are the following: =20 > scalability of the routing system; combined host mobility and=20 > multi- homing; fast and vertical handovers with=20 > re-authentication; architected NAT, IPv4/v6 interop, etc.;=20 > some forms of bad traffic (DDoS); sub-network naming and=20 > mobility; and flexible and secure application naming.] >=20 > --Pekka Nikander >=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 Sun Dec 17 09:55:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvxQ3-0000c4-3H; Sun, 17 Dec 2006 09:55:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvxQ2-0000bw-1l for architecture-discuss@ietf.org; Sun, 17 Dec 2006 09:55:14 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvxPw-00083C-Li for architecture-discuss@ietf.org; Sun, 17 Dec 2006 09:55:14 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id A3D5F34049; Sun, 17 Dec 2006 09:55:08 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 17 Dec 2006 09:55:08 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.5 Subject: RE: [arch-d] Do we have "partial consensus"? Date: Sun, 17 Dec 2006 09:55:06 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC01178F79@tayexc14.americas.cpqcorp.net> In-Reply-To: <397A61D4-5B2E-4689-A417-1AC22C1C83A0@multicasttech.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Do we have "partial consensus"? Thread-Index: AccfjSfwZY3HlnRCSo6CbFPWAI4bewCXhxjQ From: "Bound, Jim" To: "Marshall Eubanks" , "Pekka Nikander" X-OriginalArrivalTime: 17 Dec 2006 14:55:08.0290 (UTC) FILETIME=[58206E20:01C721EB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Nevermind that is the MPI below. I thought reference was to accessing the name space for a new model. /jim=20 > -----Original Message----- > From: Marshall Eubanks [mailto:tme@multicasttech.com]=20 > Sent: Thursday, December 14, 2006 9:35 AM > To: Pekka Nikander > Cc: architecture-discuss@ietf.org > Subject: Re: [arch-d] Do we have "partial consensus"? >=20 > Dear Pekka; >=20 > On Dec 14, 2006, at 5:58 AM, Pekka Nikander wrote: >=20 > >>> That said, I agree that we need to separate the currently=20 > confounded=20 > >>> "identifier" and "locator" roles of IP addresses, thereby=20 > creating=20 > >>> two distinct name spaces. The "identifier" name space will be=20 > >>> mainly used by applications and the "locator" name space=20 > by routing=20 > >>> and forwarding. > >>> > >>> I'm afraid that we haven't received any kind of consensus=20 > on how to=20 > >>> do that separation. > >> > >> Is it realistic to assume that that there will be only one=20 > split ? =20 > >> (For example, in the MPI case a geographically based locator might=20 > >> make sense, while for static networks a locator based on network=20 > >> hierarchy is probably more appropriate, and these very different=20 > >> choices will influence the type of locator, and maybe the type of=20 > >> identifier, chosen.) So wouldn't the first step be the=20 > selection of a=20 > >> means to identify the split being taken ? > > > > I am not sure if I understand you correctly (e.g. I don't know what=20 > > you refer to with "MPI"), but if I understand you correctly, to me=20 > > your statement feels like that you would like to have multiple=20 > > different locator spaces. If so, as I have written before, I don't=20 > > see any architectural reason why an id/loc split implementation=20 > > couldn't include mechanisms for architected NATs and NATPs, thereby=20 > > allowing different locators and routing mechanisms at=20 > different areas=20 > > in the net. > > > > On the other hand, I would see there tremendous social=20 > utility value=20 > > if we managed to move back to a single, global identifier space. > > >=20 > Mobile Platform Internet - Autonomous Systems on wings (or wheels =20 > or...). Some documentation is at > http://www.multicasttech.com/mpi/ >=20 > (Think of a 787 with hundreds of internal computers, 3 or more =20 > internal address blocks, and (potentially) dozens of IP > interfaces, such as 802.16 to the ground, 802.11 to the tower, and =20 > several satellite links, and a strong need to multihome to all of =20 > these.) >=20 > In the MPI case, I think that a geographically based locater=20 > may make =20 > sense. Suppose that you know that I was at this location, at > this time. That would in principal allow you to determine which =20 > Satellite footprints, 802.16 nets, and 802.11 ATC links I could be =20 > part of at that time. If, say, there was a set of gateways for =20 > satellite uplinks, you would know which gateway to forward=20 > to. If you =20 > were sending ATC information, you would (in principal) know whether =20 > to send to the satellite or to the local tower. >=20 > (In a sense, this discussion is more about aggregation and =20 > scalability than routing. We know how to route to aircraft; BGP can =20 > do it. I think that the real question is, how do we do it in a way =20 > that doesn't require global visibility of the platform.) >=20 > Also note that in this mobile case, you need to include a time tag, =20 > as the locators will change with time and old locators will require =20 > different routing. (Locators might change significantly=20 > during a long =20 > tcp session, for example.) >=20 > Of course, in the static case, my rack in an exchange or=20 > co-lo may be =20 > less than one meter from your rack but in a totally different place =20 > in network topology, and I doubt that pure geography is worth much. >=20 > >>> To further clarify: in this case, I find it very hard to produce =20 > >>> an exact definition of all the architecturally inclined problems =20 > >>> that we have; for example, I can easily count to up to six or =20 > >>> seven different problems, all partially caused by the present =20 > >>> role confounding. > >> > >> This indicates to me that, again, "one size fits all" is probably =20 > >> not realistic. > > > > You are right that it may be unrealistic to solve all of the =20 > > related problems, or even my "six or seven" problems, at a single =20 > > shot. OTOH, I have practical reasons to believe that all of my =20 > > "six or seven" problems could be solved with a public-keys-based =20 > > identity-layer clearly more elegantly (and with less complexity) =20 > > than we are able to do today. > > > > [For reference, the problems I've considered are the following: =20 > > scalability of the routing system; combined host mobility=20 > and multi-=20 > > homing; fast and vertical handovers with re-authentication; =20 > > architected NAT, IPv4/v6 interop, etc.; some forms of bad traffic =20 > > (DDoS); sub-network naming and mobility; and flexible and secure =20 > > application naming.] > > > > --Pekka Nikander > > >=20 > Is there a write-up of this ? >=20 > Regards > Marshall >=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 Sun Dec 17 09:56:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvxQq-0000mW-0Y; Sun, 17 Dec 2006 09:56:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvxQo-0000ky-4O for architecture-discuss@ietf.org; Sun, 17 Dec 2006 09:56:02 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvxQi-0008Ne-TO for architecture-discuss@ietf.org; Sun, 17 Dec 2006 09:56:02 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id F1ED434068; Sun, 17 Dec 2006 09:55:58 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 17 Dec 2006 09:55:56 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.5 Subject: RE: [arch-d] On the role of "transport" (was Re: Do we have "partialconsensus"?) Date: Sun, 17 Dec 2006 09:55:55 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC01178F7A@tayexc14.americas.cpqcorp.net> In-Reply-To: <20061214162737.300CA872C5@mercury.lcs.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] On the role of "transport" (was Re: Do we have "partialconsensus"?) Thread-Index: AccfnOXRODMW0tRpS5an7q3lw5wRuQCTnyMg From: "Bound, Jim" To: "Noel Chiappa" , , X-OriginalArrivalTime: 17 Dec 2006 14:55:56.0526 (UTC) FILETIME=[74E0A8E0:01C721EB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org We will need addresses as identifiers. Hmmm I don't agree. /jim=20 > -----Original Message----- > From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu]=20 > Sent: Thursday, December 14, 2006 11:28 AM > To: architecture-discuss@ietf.org; pesherb@yahoo.com > Cc: jnc@mercury.lcs.mit.edu > Subject: Re: [arch-d] On the role of "transport" (was Re: Do=20 > we have "partialconsensus"?) >=20 > > From: Peter Sherbin >=20 > > Whout it be more clear to use "names" for "identifiers"=20 > and "addresses" > > for "locators"? >=20 > No, and no. >=20 > Noel >=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 Sun Dec 17 09:57:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvxSI-00014q-5W; Sun, 17 Dec 2006 09:57:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GvxSG-00013h-OW for architecture-discuss@ietf.org; Sun, 17 Dec 2006 09:57:32 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GvxS8-0008W9-1k for architecture-discuss@ietf.org; Sun, 17 Dec 2006 09:57:32 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id B252B34086; Sun, 17 Dec 2006 09:57:25 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 17 Dec 2006 09:57:23 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.5 Subject: RE: [arch-d] Do we have "partial consensus"? Date: Sun, 17 Dec 2006 09:57:22 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC01178F7C@tayexc14.americas.cpqcorp.net> In-Reply-To: <4582ADC0.70909@zurich.ibm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Do we have "partial consensus"? Thread-Index: AccgU3LJPx2/bnDfR1qND1tMYQwsjABmByZA From: "Bound, Jim" To: "Brian E Carpenter" , "Marshall Eubanks" X-OriginalArrivalTime: 17 Dec 2006 14:57:23.0699 (UTC) FILETIME=[A8D63430:01C721EB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Yes and it confused me. We are going to need a doc soon so we all have common understanding of terminology e.g. MIP, Jack-Up, Name-Space, Identifier et al. /jim=20 > -----Original Message----- > From: Brian E Carpenter [mailto:brc@zurich.ibm.com]=20 > Sent: Friday, December 15, 2006 9:14 AM > To: Marshall Eubanks > Cc: architecture-discuss@ietf.org > Subject: Re: [arch-d] Do we have "partial consensus"? >=20 > > Mobile Platform Internet - Autonomous Systems on wings (or wheels=20 > > or...). Some documentation is at http://www.multicasttech.com/mpi/ >=20 > Oh boy. MPI means something very different to many networking people: > Message Passing Interface. This is very widely used in high=20 > performance cluster computing, with multiple implementations. > See http://www.mpi-forum.org or http://www.open-mpi.org/ . >=20 > This is a very confusing acronym clash. >=20 > Brian >=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 Sun Dec 17 13:36:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gw0qk-0001H8-QS; Sun, 17 Dec 2006 13:35:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gw0qj-0001Fw-B3 for architecture-discuss@ietf.org; Sun, 17 Dec 2006 13:35:01 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gw0qi-0003nB-JN for architecture-discuss@ietf.org; Sun, 17 Dec 2006 13:35:01 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 1AF74212F4E; Sun, 17 Dec 2006 20:34:52 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 69DBE212F45; Sun, 17 Dec 2006 20:34:51 +0200 (EET) In-Reply-To: <816DD9299957E547B5D758D7F977D6DC01178F74@tayexc14.americas.cpqcorp.net> References: <816DD9299957E547B5D758D7F977D6DC01178F74@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [arch-d] On the role of "transport" (was Re: Do we have "partialconsensus"?) Date: Sun, 17 Dec 2006 20:34:49 +0200 To: "Bound, Jim" X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Jim, I agree that we need a transport layer. What I don't know is whether we need explicit transport names, and if we do, whether they should be locators or identifiers. (Remember that right now we do not have explicit transport names but they are created by combining IP addresses and port numbers.) What I outlined below were three architectural choices of *where* to do an identifier locator separation. One of those (#3) is ABOVE transport. In that case the names that transport sees will be locators, not identifiers. Based on that, I objected to John's use of "transport names" as a generic name for upper layer identifiers. For example, in the SHIM6 case transport sees identifiers, yes. But in some other choices it is only above transport that locators get mapped to identifiers and vice versa. Based on that, I'd consider "application names" a better choice for ULIDs than "transport names". However, perhaps the best choice would be "identifier"; or "ULID", as used in SHIM6. --Pekka On 17 Dec 2006, at 16:50, Bound, Jim wrote: > We need a transport layer Pekka or call it what you want but it must > exist and its between the internet-networking layer and the apps > layer. > Unless I misundertand your input? Also we are not done we have no way > to gage consensus and until we have that saying we are done is not > fair. > Someone needs to write all this down in a draft at minimum. > > /jim > >> -----Original Message----- >> From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] >> Sent: Thursday, December 14, 2006 2:30 AM >> To: John Leslie >> Cc: architecture-discuss@ietf.org >> Subject: [arch-d] On the role of "transport" (was Re: Do we >> have "partialconsensus"?) >> >> John, >> >> In general I feel we had mostly terminology disagreements, >> partly reflecting that we apparently look at the problem from >> slightly different angles. We also seem to be mostly over >> with the terminology issues. I'd be happy with what Noel >> stated about the terms. >> >> Disregarding the terminology, I think we are in pretty good >> overall agreement sans how to handle the "transport". Hence, >> I'm focusing on that, but before I get to that, I need to do >> a small detour. >> >> >> To start with, and as I have stated at least three times so >> far, if we think about our current global communications >> system as sets of components, we can see there three >> independently changing sets of >> components: "routers", "host os stacks", and "applications". >> [Note that the structure is *economic*, not technical. The >> sets of components have different purchasing cycles and >> lifetimes.] Between the components, we have two relatively >> well defined and understood >> interfaces: >> >> 1. One between routers and stacks, i.e., sending IP packets >> over Ethernet, PPP, etc. >> >> 2. One between stacks and applications, i.e., the socket API >> and its equivalents. >> >> These two interfaces are the ones that are hardest to change >> as changing them requires that more than one of the involved >> component sets are changed at the same time. Changing the >> syntax of the interfaces is almost out of the question. >> Changing semantics -- that we need to do, but we need to be >> pretty careful when doing so. >> >> >> Now, architecturally, to implement the identifier / locator >> separation we seem to have two fundamentally different paths: >> >> 1. In what Noel calls the "jack up" approaches, we change the >> "routers". Conversely, we change the semantics of what now >> are IP addresses to "identifiers" at *both* interfaces. In >> this approach, what now are IP addresses will become >> "identifiers", both within the "stacks" and "applications". >> In this model, "locators" are internal to the network, and >> only seen by (some) "routers". >> >> 2. In the "shim" approaches (HIP/SHIM6/SCTP/...), we change >> the "stacks"; perhaps not immediately but eventually. >> Conversely, we change the semantics of what now are IP >> addresses so that they become "locators" at the >> "router/stack" interface and "identifiers" at the >> "stack/application" interface. As a consequence, >> applications will deal with "identifiers" and routers will >> deal with "locators"; the "stack" will do the translation. >> >> While writing this, I noticed that, at least in theory, we >> also have a third approach. [But I am not aware of any >> viable solution proposals here.] >> >> 3. In the "apps" approaches we change the "apps"; not >> necessarily the apps themselves but e.g. resolution, >> libraries, etc. Conversely, we change the semantics of what >> now are "IP addresses" so that they become "locators" at >> *both* of the interfaces. The "apps layer" will >> do the translation, and "identifiers" are internal to the apps. >> [This approach also has problems related to e.g. TCP state >> during mobility events, so it may be impossible to do a >> clean-cut implementation based on this architectural approach.] >> >> Four more notes before we get to the point: >> >> 1a. It is also possible to implement the "jack up" >> mechanisms in the hosts, but that changes the underlying >> trust model and therefore security properties. The >> consequences and implications -- think about them. >> >> 2a. It is possible to implement the "shim" mechanisms in a >> separate box (proxy) in a way that structurally resembles the >> "jack up" >> mechanisms. But, the trust model is slightly different than >> in a plain, "stack" based "shim" approach. >> >> 3a. I have hard time imagining how to implement the "apps" >> approach in a proxy box, but intuitively I have the feeling >> that it should be doable. >> >> 4. Implication: From an implementation point of view, the difference >> between the "jack up" and "shim" approaches need not be that big. >> Both can be implemented either in some new "router" boxes or >> in the host os stacks, or in some combination thereof. >> Perhaps even the "apps" approach can be implemented in that way. >> >> Ergo: The differences are architectural, reflecting different >> architectural semantics and fundamentally different trust models! >> >> >> Now we are finally done with our detour and I get to my point: >> >> If you read carefully what I stated above, I did not need the >> word "transport", not even once. And I did not try to avoid >> it -- it just wasn't needed. >> >> t is pretty clear that somewhere within the "router layer" we >> will need "locators", aka routing names. It is pretty clear >> that in the "application layer" we will need "identifiers", >> identifying entities that the apps are interested in. >> [Whether the ids identify "hosts", "stacks", or other >> entities will need to be discussed, but that can be >> deferred.] It is pretty clear that somewhere we will need to >> make a translation between them. >> >> However, that translation can take place in at least four different >> locations: >> >> 1. In the routing system, resulting in "jack up". >> >> 2. In the stack as a "shim", with at least two potential >> choices for the location: >> >> 2a. In the "internetworking" layer, somewhere near IPsec, similar to >> SHIM6 and HIP. >> >> 2b. In the "transport" layer, similar to SCTP add IP. >> >> 3. In the "apps layer", e.g., in a library. >> >> If we talk about the "transport" layer and "transport" names, >> that gives the implication that the "transport" needs stable, >> location- independent names. I don't think that's the case. >> Its the applications that have the need for such >> entity-referring location- independent stable names. Hence, >> I prefer to consider the "upper names" aka "identifiers" as >> something that the applications, not the transport, are >> interested in. From a theoretical point of view, it is an >> open question whether the "transport" should see them or not. >> >> --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 Sun Dec 17 16:11:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gw3Gk-0005Ln-Mn; Sun, 17 Dec 2006 16:10:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gw3Gj-0005LC-DA for architecture-discuss@ietf.org; Sun, 17 Dec 2006 16:10:01 -0500 Received: from web31802.mail.mud.yahoo.com ([68.142.207.65]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gw3Gf-0001dC-3R for architecture-discuss@ietf.org; Sun, 17 Dec 2006 16:10:01 -0500 Received: (qmail 82999 invoked by uid 60001); 17 Dec 2006 21:09:41 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=e8J8Ouv61Nlr02VeJ8CCA0m8rIqveo/XUp1hec83Yn3A5c1/tpfaeWHCr+S2MjoYA5/+x2TiHT/JNGQf4Ljd/sW0AUSeOnuGf5W7LiGliqb1k6afFJ8vhvr/plBpPudmkQEbQ81CSNbYbR8eugJDWMDO8Jyh2AZgvnmMCaa7+e0=; X-YMail-OSG: VaAwruIVM1kyFVzqD_qFiDaBbWwPmidL8u5Q.MRi3Bqts.jGEvcwDB6vukPhz7mMm4g1YLnUHmwxhRg4ZEap6rDtbu.AcUpeGYCvMJdnCKn8kRjbQ6LE0U.6uu_AcO.CdL.iMerVzF5iMicvuK4ghz4dNBXw1UwCJEJ3pxfvno5baEgdKhY5Dg-- Received: from [68.34.60.18] by web31802.mail.mud.yahoo.com via HTTP; Sun, 17 Dec 2006 13:09:41 PST Date: Sun, 17 Dec 2006 13:09:41 -0800 (PST) From: David Barak Subject: RE: [arch-d] Do we have "partial consensus"? To: "Bound, Jim" , architecture-discuss@ietf.org In-Reply-To: <816DD9299957E547B5D758D7F977D6DC01178F72@tayexc14.americas.cpqcorp.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <623826.82279.qm@web31802.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org --- "Bound, Jim" wrote: > > > > and "transport" is responsible for > > > - choosing among multiple paths (if available). > > > > I was okay until I got here :) > > > > If you do that, you lose the benefit of in-band > signalling, > > and are more likely to have the routing and > transport layers > > disagree about what the optimum path is. > > On the contrary is my view. The capability to use > in-band-signaling to > identify best multiple paths is something that > should be made easier > with the new model. Only a transport-layer-aware device can perform transport-layer functions. Currently, selection of the best path is done below the transport layer, at the same layer which actually forwards packets. If the layers above the routing layer can perform path selection, then there either needs to be a layering violation (i.e. multiple layers required to be in synch at all times), or every hop must be a transport-layer-device, which means that there is no concept of end-to-end forwarding (see X.25), or there needs to be a huge amount of state held on all end hosts which are the transport-aware devices. None of those are improvements on the existing in-band signalling (i.e. routing happens over data plane) from a scalability or simplicity approach. -David David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Dec 17 22:04:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gw8mO-0007lM-Je; Sun, 17 Dec 2006 22:03:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gw8mM-0007lB-Uu for architecture-discuss@ietf.org; Sun, 17 Dec 2006 22:03:02 -0500 Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gw8mI-00020y-FV for architecture-discuss@ietf.org; Sun, 17 Dec 2006 22:03:02 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id 0F06D34095; Sun, 17 Dec 2006 22:02:58 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 17 Dec 2006 22:02:57 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.5 Subject: RE: [arch-d] On the role of "transport" (was Re: Do we have "partialconsensus"?) Date: Sun, 17 Dec 2006 22:02:56 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC01178FEF@tayexc14.americas.cpqcorp.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] On the role of "transport" (was Re: Do we have "partialconsensus"?) Thread-Index: AcciChDLnUr2po8YSZGkCAFxMFVPUgARNO9g From: "Bound, Jim" To: "Pekka Nikander" X-OriginalArrivalTime: 18 Dec 2006 03:02:57.0762 (UTC) FILETIME=[05290C20:01C72251] X-Spam-Score: 0.0 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Pekka,=20 > I agree that we need a transport layer. >=20 > What I don't know is whether we need explicit transport=20 > names, and if we do, whether they should be locators or=20 > identifiers. (Remember that right now we do not have=20 > explicit transport names but they are created by combining IP=20 > addresses and port numbers.) Yes I know I am taking a purist *new* approach and assuming transport has nothing to do with the internetworking layer at all other than the transport dst identifier is a hint or vector to what locators or routing-namespace-identifiers are used to deliver the packet. Talking with a few offline on this to see if I have gone to far to remove all notion of routing, path, and all the other words we use today as nomenclature. So will come back to this later. The transport layer to me in a **new** model participates in notification of problems to support applications and to be the front end across a network for those applications. I am being very abstract at this point. >=20 > What I outlined below were three architectural choices of=20 > *where* to do an identifier locator separation. One of those=20 > (#3) is ABOVE transport. In that case the names that=20 > transport sees will be locators, not identifiers. But in my abstraction above there is no reason for locators is where I am headed that is the layer below. >=20 > Based on that, I objected to John's use of "transport names"=20 > as a generic name for upper layer identifiers. For example,=20 > in the SHIM6 =20 > case transport sees identifiers, yes. But in some other choices it =20 > is only above transport that locators get mapped to=20 > identifiers and vice versa. I am in agreement with John I believe on this principle. Whether locators or routing-namespace-identifiers below and different than the transport are needed is my question at least for me right now. =20 >=20 > Based on that, I'd consider "application names" a better=20 > choice for ULIDs than "transport names". However, perhaps=20 > the best choice would be "identifier"; or "ULID", as used in SHIM6. I think your right above and I do like the SHIM6 model of ULID. But the selection of locators in SHIM6 with a **new** model (Noel, John L, you, Tony L, Peter S. and others) may not be necessary??????? I could be off the deep end here totally removing that from transport but I just want to think about it and run a bit :--). /jim >=20 > --Pekka >=20 > On 17 Dec 2006, at 16:50, Bound, Jim wrote: >=20 > > We need a transport layer Pekka or call it what you want=20 > but it must=20 > > exist and its between the internet-networking layer and the apps=20 > > layer. > > Unless I misundertand your input? Also we are not done we=20 > have no way=20 > > to gage consensus and until we have that saying we are done is not=20 > > fair. > > Someone needs to write all this down in a draft at minimum. > > > > /jim > > > >> -----Original Message----- > >> From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] > >> Sent: Thursday, December 14, 2006 2:30 AM > >> To: John Leslie > >> Cc: architecture-discuss@ietf.org > >> Subject: [arch-d] On the role of "transport" (was Re: Do we have=20 > >> "partialconsensus"?) > >> > >> John, > >> > >> In general I feel we had mostly terminology disagreements, partly=20 > >> reflecting that we apparently look at the problem from slightly=20 > >> different angles. We also seem to be mostly over with the=20 > >> terminology issues. I'd be happy with what Noel stated about the=20 > >> terms. > >> > >> Disregarding the terminology, I think we are in pretty=20 > good overall=20 > >> agreement sans how to handle the "transport". Hence, I'm=20 > focusing on=20 > >> that, but before I get to that, I need to do a small detour. > >> > >> > >> To start with, and as I have stated at least three times=20 > so far, if=20 > >> we think about our current global communications system as sets of=20 > >> components, we can see there three independently changing sets of > >> components: "routers", "host os stacks", and "applications". > >> [Note that the structure is *economic*, not technical. =20 > The sets of=20 > >> components have different purchasing cycles and=20 > lifetimes.] Between=20 > >> the components, we have two relatively well defined and understood > >> interfaces: > >> > >> 1. One between routers and stacks, i.e., sending IP packets over=20 > >> Ethernet, PPP, etc. > >> > >> 2. One between stacks and applications, i.e., the socket=20 > API and its=20 > >> equivalents. > >> > >> These two interfaces are the ones that are hardest to change as=20 > >> changing them requires that more than one of the involved=20 > component=20 > >> sets are changed at the same time. Changing the syntax of the=20 > >> interfaces is almost out of the question. > >> Changing semantics -- that we need to do, but we need to be pretty=20 > >> careful when doing so. > >> > >> > >> Now, architecturally, to implement the identifier / locator=20 > >> separation we seem to have two fundamentally different paths: > >> > >> 1. In what Noel calls the "jack up" approaches, we change the=20 > >> "routers". Conversely, we change the semantics of what now are IP=20 > >> addresses to "identifiers" at *both* interfaces. In this=20 > approach,=20 > >> what now are IP addresses will become "identifiers", both=20 > within the=20 > >> "stacks" and "applications". > >> In this model, "locators" are internal to the network, and=20 > only seen=20 > >> by (some) "routers". > >> > >> 2. In the "shim" approaches (HIP/SHIM6/SCTP/...), we change the=20 > >> "stacks"; perhaps not immediately but eventually. > >> Conversely, we change the semantics of what now are IP=20 > addresses so=20 > >> that they become "locators" at the "router/stack" interface and=20 > >> "identifiers" at the "stack/application" interface. As a=20 > >> consequence, applications will deal with "identifiers" and routers=20 > >> will deal with "locators"; the "stack" will do the translation. > >> > >> While writing this, I noticed that, at least in theory, we=20 > also have=20 > >> a third approach. [But I am not aware of any viable solution=20 > >> proposals here.] > >> > >> 3. In the "apps" approaches we change the "apps"; not=20 > necessarily the=20 > >> apps themselves but e.g. resolution, libraries, etc. =20 > Conversely, we=20 > >> change the semantics of what now are "IP addresses" so that they=20 > >> become "locators" at > >> *both* of the interfaces. The "apps layer" will do the=20 > translation,=20 > >> and "identifiers" are internal to the apps. > >> [This approach also has problems related to e.g. TCP state during=20 > >> mobility events, so it may be impossible to do a clean-cut=20 > >> implementation based on this architectural approach.] > >> > >> Four more notes before we get to the point: > >> > >> 1a. It is also possible to implement the "jack up" > >> mechanisms in the hosts, but that changes the underlying=20 > trust model=20 > >> and therefore security properties. The consequences and=20 > implications=20 > >> -- think about them. > >> > >> 2a. It is possible to implement the "shim" mechanisms in=20 > a separate=20 > >> box (proxy) in a way that structurally resembles the "jack up" > >> mechanisms. But, the trust model is slightly different than in a=20 > >> plain, "stack" based "shim" approach. > >> > >> 3a. I have hard time imagining how to implement the "apps" > >> approach in a proxy box, but intuitively I have the=20 > feeling that it=20 > >> should be doable. > >> > >> 4. Implication: From an implementation point of view, the=20 > difference=20 > >> between the "jack up" and "shim" approaches need not be that big. > >> Both can be implemented either in some new "router" boxes=20 > or in the=20 > >> host os stacks, or in some combination thereof. > >> Perhaps even the "apps" approach can be implemented in that way. > >> > >> Ergo: The differences are architectural, reflecting different=20 > >> architectural semantics and fundamentally different trust models! > >> > >> > >> Now we are finally done with our detour and I get to my point: > >> > >> If you read carefully what I stated above, I did not need the word=20 > >> "transport", not even once. And I did not try to avoid it=20 > -- it just=20 > >> wasn't needed. > >> > >> t is pretty clear that somewhere within the "router layer" we will=20 > >> need "locators", aka routing names. It is pretty clear=20 > that in the=20 > >> "application layer" we will need "identifiers",=20 > identifying entities=20 > >> that the apps are interested in. > >> [Whether the ids identify "hosts", "stacks", or other=20 > entities will=20 > >> need to be discussed, but that can be deferred.] It is=20 > pretty clear=20 > >> that somewhere we will need to make a translation between them. > >> > >> However, that translation can take place in at least four different > >> locations: > >> > >> 1. In the routing system, resulting in "jack up". > >> > >> 2. In the stack as a "shim", with at least two potential=20 > choices for=20 > >> the location: > >> > >> 2a. In the "internetworking" layer, somewhere near IPsec,=20 > similar to > >> SHIM6 and HIP. > >> > >> 2b. In the "transport" layer, similar to SCTP add IP. > >> > >> 3. In the "apps layer", e.g., in a library. > >> > >> If we talk about the "transport" layer and "transport" names, that=20 > >> gives the implication that the "transport" needs stable, > >> location- independent names. I don't think that's the case. > >> Its the applications that have the need for such entity-referring=20 > >> location- independent stable names. Hence, I prefer to=20 > consider the=20 > >> "upper names" aka "identifiers" as something that the=20 > applications,=20 > >> not the transport, are interested in. From a theoretical point of=20 > >> view, it is an open question whether the "transport"=20 > should see them=20 > >> or not. > >> > >> --Pekka Nikander > >> > >> > >> _______________________________________________ > >> Architecture-discuss mailing list > >> Architecture-discuss@ietf.org > >> https://www1.ietf.org/mailman/listinfo/architecture-discuss > >> > > >=20 >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Dec 17 22:06:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gw8p5-0008CW-Do; Sun, 17 Dec 2006 22:05:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gw8p4-0008CR-N1 for architecture-discuss@ietf.org; Sun, 17 Dec 2006 22:05:50 -0500 Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gw8oz-0002F2-EG for architecture-discuss@ietf.org; Sun, 17 Dec 2006 22:05:50 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id 4028D34012; Sun, 17 Dec 2006 22:05:45 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 17 Dec 2006 22:05:45 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.5 Subject: RE: [arch-d] Do we have "partial consensus"? Date: Sun, 17 Dec 2006 22:05:44 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC01178FF0@tayexc14.americas.cpqcorp.net> In-Reply-To: <623826.82279.qm@web31802.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Do we have "partial consensus"? Thread-Index: AcciH61SSLU2lNLWQiKG7qGXWlw8lwAMWWkw From: "Bound, Jim" To: "David Barak" , X-OriginalArrivalTime: 18 Dec 2006 03:05:45.0104 (UTC) FILETIME=[68E76900:01C72251] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org I think you have captured an important point but the reality is today the layers are really virtual and the "violation" you speak of is in most code I know of on the street and indirectly in specs. =20 How do we want the stack to look? Like an hour glass, wine glass, or bulge in the center? I think this is important to think about if any core architecture princples are to survive for 100 years. /jim=20 > -----Original Message----- > From: David Barak [mailto:thegameiam@yahoo.com]=20 > Sent: Sunday, December 17, 2006 4:10 PM > To: Bound, Jim; architecture-discuss@ietf.org > Subject: RE: [arch-d] Do we have "partial consensus"? >=20 >=20 > --- "Bound, Jim" wrote: >=20 > > =20 > > > > and "transport" is responsible for > > > > - choosing among multiple paths (if available). > > >=20 > > > I was okay until I got here :) > > >=20 > > > If you do that, you lose the benefit of in-band > > signalling, > > > and are more likely to have the routing and > > transport layers > > > disagree about what the optimum path is. > >=20 > > On the contrary is my view. The capability to use=20 > in-band-signaling=20 > > to identify best multiple paths is something that should be made=20 > > easier with the new model. >=20 > Only a transport-layer-aware device can perform=20 > transport-layer functions. Currently, selection of the best=20 > path is done below the transport layer, at the same layer=20 > which actually forwards packets. =20 >=20 > If the layers above the routing layer can perform path=20 > selection, then there either needs to be a layering violation=20 > (i.e. multiple layers required to be in synch at all times),=20 > or every hop must be a transport-layer-device, which means=20 > that there is no concept of end-to-end forwarding (see X.25),=20 > or there needs to be a huge amount of state held on all end=20 > hosts which are the transport-aware devices. >=20 > None of those are improvements on the existing in-band=20 > signalling (i.e. routing happens over data plane) from a=20 > scalability or simplicity approach. >=20 > -David >=20 > David Barak > Need Geek Rock? Try The Franchise:=20 > http://www.listentothefranchise.com >=20 > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection=20 > around http://mail.yahoo.com=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 Dec 18 00:40:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwBDL-0003wq-MI; Mon, 18 Dec 2006 00:39:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwBDL-0003wl-E3 for architecture-discuss@ietf.org; Mon, 18 Dec 2006 00:39:03 -0500 Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwBDK-0002mx-30 for architecture-discuss@ietf.org; Mon, 18 Dec 2006 00:39:03 -0500 Received: from [127.0.0.1] (pool-71-106-94-15.lsanca.dsl-w.verizon.net [71.106.94.15]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id kBI5ciEU000271; Sun, 17 Dec 2006 21:38:45 -0800 (PST) Message-ID: <45862962.7050808@isi.edu> Date: Sun, 17 Dec 2006 21:38:42 -0800 From: Joe Touch User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Pekka Nikander Subject: Re: [arch-d] On the role of "transport" (was Re: Do we have "partialconsensus"?) References: <816DD9299957E547B5D758D7F977D6DC01178F74@tayexc14.americas.cpqcorp.net> In-Reply-To: X-Enigmail-Version: 0.94.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: architecture-discuss@ietf.org, "Bound, Jim" X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0579179885==" Errors-To: architecture-discuss-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0579179885== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF47F4B8C0E25BE4AD02DFEC0" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF47F4B8C0E25BE4AD02DFEC0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Pekka Nikander wrote: > Jim, >=20 > I agree that we need a transport layer. >=20 > What I don't know is whether we need explicit transport names, and if w= e > do, whether they should be locators or identifiers. (Remember that > right now we do not have explicit transport names but they are created > by combining IP addresses and port numbers.) That combination is used for two things: transport names _after_ a connection is established service names _before_ a connection is established (the two overlap, e.g., in UDP). The point is there's another level of naming here that's orthogonal and could/should be split out. See draft-touch-tcp-portnames (soon to be reissued with updates). Joe --------------enigF47F4B8C0E25BE4AD02DFEC0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFhiliE5f5cImnZrsRAlH6AKCq0Xxi+HpfJlbEhRSqqobtmQThBwCghoC2 32trQDlzMg8B4CytLcRngPQ= =4DNl -----END PGP SIGNATURE----- --------------enigF47F4B8C0E25BE4AD02DFEC0-- --===============0579179885== 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 --===============0579179885==-- From architecture-discuss-bounces@ietf.org Mon Dec 18 01:41:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwCAY-0007si-8a; Mon, 18 Dec 2006 01:40:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwCAV-0007sa-Md for architecture-discuss@ietf.org; Mon, 18 Dec 2006 01:40:11 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwCAR-0004bb-4v for architecture-discuss@ietf.org; Mon, 18 Dec 2006 01:40:11 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id E59AF212F55; Mon, 18 Dec 2006 08:40:00 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 54E9F212F4E; Mon, 18 Dec 2006 08:40:00 +0200 (EET) In-Reply-To: <816DD9299957E547B5D758D7F977D6DC01178FEF@tayexc14.americas.cpqcorp.net> References: <816DD9299957E547B5D758D7F977D6DC01178FEF@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [arch-d] On the role of "transport" (was Re: Do we have "partialconsensus"?) Date: Mon, 18 Dec 2006 08:39:58 +0200 To: "Bound, Jim" X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Jim, [Cutting and rearranging the old content a little bit, in order to help readability.] On 18 Dec 2006, at 05:02, Bound, Jim wrote: > ... I am taking a purist *new* approach and assuming transport has > nothing to do with the internetworking layer at all other than the > transport dst identifier is a hint or vector to what locators or > routing-namespace-identifiers are used to deliver the packet. ... To me, this sounds like my "architectural approach #2": >>>> 2. In the "shim" approaches (HIP/SHIM6/SCTP/...), we change the >>>> "stacks"; perhaps not immediately but eventually. Conversely, >>>> we change the semantics of what now are IP addresses so that >>>> they become "locators" at the "router/stack" interface and >>>> "identifiers" at the "stack/application" interface. As a >>>> consequence, applications will deal with "identifiers" and >>>> routers will deal with "locators"; the "stack" will do the >>>> translation. What I was trying to say with this approach (#2) was the following: - change the host stack implementations (but during transition the same functionality may happen elsewhere) - in the internetworking layer, use locators aka routing-namespace- identifiers - in the transport layer, use identifiers aka ULIDs Now, this happen also to be my favourite approach; i.e, we seem to agree. BUT, I am simultaneously trying to understand the pros and cons of the other two approaches (#1 and #3). > Talking with a few offline on this to see if I have gone to far to > remove all notion of routing, path, and all the other words we use > today as nomenclature. So will come back to this later. Personally, I don't believe you've gone too far, at least when speaking architecturally. However, once we'll get back to engineering, we'll probably need some terms for those or similar functions again. > But in my abstraction above there is no reason for locators is > where I am headed that is the layer below. I think I understand: no locators at transport but only in a layer below. BUT, there are some applications people that would like to do the id/loc split above transport. I think it would be good to understand the merits and drawbacks of that approach, too. >> Based on that, I'd consider "application names" a better choice >> for ULIDs than "transport names". However, perhaps the best >> choice would be "identifier"; or "ULID", as used in SHIM6. > > I think your right above and I do like the SHIM6 model of ULID. So, at least you and I seem to be converging to using the term "ULID" for the names that John used the term "transport name" for, in his original consensus call. > But the selection of locators in SHIM6 with a **new** model (Noel, > John L, you, Tony L, Peter S. and others) may not be necessary??????? I am not sure what you are saying, but if we do the identifier locator separation, some function somewhere must select what locator to use for an outgoing packet. [Traditionally, the choice was made in the application code, either in the application proper or in some library.] What I think we have mostly worked out so far are the architectural options of where to do that choice in the new world. In some new models, the selection function is located elsewhere than where it is in SHIM6 and HIP. Once we understand better the options or approaches of *where* to do the locator selection in an architectural sense, we'll still have lots to do: how to select a good locator, what kind of infrastructure (if any) is needed to support that selection, what are the new packet structures and headers (if any), how the locator selection interacts with transports, etc. Considering the details, we've so far worked out how to do the identifier locator separation with HIP and SHIM6. Of HIP we have had working experimental implementations for some 3-5 years now, but still too little practical experience on e.g. how it works with existing congestion control. AFAIK, the first SHIM6 implementations should be ready very soon. Unfortunately, I am ignorant of the implementation and experimentation situation of Noel's "jack up" (approach #1) or the recently recognised "above transport" (approach #3) approaches. > I could be off the deep end here totally removing that from > transport but I just want to think about it and run a bit :--). One of the areas where I notice myself being somewhat weak is understanding all the implications of id/loc split to the traditional transport functions, i.e. e2e error control and congestion control. I once thought I understood the case, and recorded my view in a position paper [1]. But now I'm puzzled, again. [1] Pekka Nikander, "ACCCoRD: Architectural Considerations on the placement of Congestion Control Routines and Data -- Extended Abstract," in Proceedings of High Speed Networking Workshop, Budabest, Hungary, May 17-18, 2004, Budabest University of Technology and Economics. http://www.tml.tkk.fi/~pnr/publications/hsn2004.pdf --Pekka Nikander _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Dec 18 09:12:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwJCj-0004W1-U5; Mon, 18 Dec 2006 09:10:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwJCi-0004Vv-O2 for architecture-discuss@ietf.org; Mon, 18 Dec 2006 09:10:56 -0500 Received: from web58708.mail.re1.yahoo.com ([66.196.100.185]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GwJCg-0003I4-FU for architecture-discuss@ietf.org; Mon, 18 Dec 2006 09:10:56 -0500 Received: (qmail 84996 invoked by uid 60001); 18 Dec 2006 14:10:45 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=oXPs53zK9eHJ7jbgmti2z2D3M7u+8QuKL3InI85WUJAahJzLC8m+7jZThHLAZR/amH6q9sYVLpHh0p0jWtbNy6HxecBI8kOO2CRWTSjfYQtdCBGWvYcYGS2/jO0zYc8IzP+YblSivhNrY8fadVzC8XtV/G9bzDVzE2xPiNW73pE=; X-YMail-OSG: CTNN7tUVM1mfemtvva..KUS9ZuV5FXDT1MeznH11NAb9D9F.OpeW_tDzB.FPzAWluQ-- Received: from [207.107.50.100] by web58708.mail.re1.yahoo.com via HTTP; Mon, 18 Dec 2006 06:10:45 PST Date: Mon, 18 Dec 2006 06:10:45 -0800 (PST) From: Peter Sherbin Subject: RE: [arch-d] Do we have "partial consensus"? To: "Bound, Jim" , Brian E Carpenter , Marshall Eubanks In-Reply-To: <816DD9299957E547B5D758D7F977D6DC01178F7C@tayexc14.americas.cpqcorp.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <828805.81822.qm@web58708.mail.re1.yahoo.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: , Errors-To: architecture-discuss-bounces@ietf.org > We are going to need a doc soon so we all have common understanding of terminology e.g. MIP, Jack-Up, Name-Space, Identifier et al. Would it help to have basic terms defined: application, port, system, transport, network, datalink, node, interface, name, identifier, address, locator, topology,..., a sort of RFC 2119 for architecture? Thanks, Peter --- "Bound, Jim" wrote: > Yes and it confused me. We are going to need a doc soon so we all have > common understanding of terminology e.g. MIP, Jack-Up, Name-Space, > Identifier et al. > /jim __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Dec 18 10:03:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwK14-0004Bh-EE; Mon, 18 Dec 2006 10:02:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwK12-0004An-Br for architecture-discuss@ietf.org; Mon, 18 Dec 2006 10:02:56 -0500 Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwJzY-0003no-2K for architecture-discuss@ietf.org; Mon, 18 Dec 2006 10:01:29 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id AEB6C340FA; Mon, 18 Dec 2006 10:01:23 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Dec 2006 10:01:23 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.5 Subject: RE: [arch-d] Do we have "partial consensus"? Date: Mon, 18 Dec 2006 10:01:22 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC01179139@tayexc14.americas.cpqcorp.net> In-Reply-To: <828805.81822.qm@web58708.mail.re1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] Do we have "partial consensus"? Thread-Index: Accirlc469Y3DV5tTmO/oXmIbBg2lQABpHCQ From: "Bound, Jim" To: "Peter Sherbin" , "Brian E Carpenter" , "Marshall Eubanks" X-OriginalArrivalTime: 18 Dec 2006 15:01:23.0554 (UTC) FILETIME=[6236EC20:01C722B5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > > We are going to need a doc soon so we all have common=20 > understanding of=20 > > terminology > e.g. MIP, Jack-Up, Name-Space, Identifier et al. >=20 > Would it help to have basic terms defined: application, port,=20 > system, transport, network, datalink, node, interface, name,=20 > identifier, address, locator, topology,..., a sort of RFC=20 > 2119 for architecture?=20 Yes but some of these I hope remain the same from the many specs in the IETF now. Its the new ones that are most important. And identifier is IMHO brand new for this work though HIP is good reference to develop that nomenclature both semantics and syntax. I like the idea of the new needing a 2119. NB: One suggestion - please for the new no ASN1 or XML encodings for now :--) Just simple plain normal text description. /jim _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Dec 18 10:03:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwK1I-0004HB-7o; Mon, 18 Dec 2006 10:03:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwK1E-0004Ed-9L for architecture-discuss@ietf.org; Mon, 18 Dec 2006 10:03:08 -0500 Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwJw5-0003Qf-10 for architecture-discuss@ietf.org; Mon, 18 Dec 2006 09:57:57 -0500 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id A726B34052; Mon, 18 Dec 2006 09:57:48 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Dec 2006 09:57:48 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.5 Subject: RE: [arch-d] On the role of "transport" (was Re: Do we have "partialconsensus"?) Date: Mon, 18 Dec 2006 09:57:46 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC01179136@tayexc14.americas.cpqcorp.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [arch-d] On the role of "transport" (was Re: Do we have "partialconsensus"?) Thread-Index: Accib1/BDLEldthFRy6Iqq4alSh+dQAQr0rQ From: "Bound, Jim" To: "Pekka Nikander" X-OriginalArrivalTime: 18 Dec 2006 14:57:48.0465 (UTC) FILETIME=[E202F210:01C722B4] X-Spam-Score: 0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Pekka,=20 > [Cutting and rearranging the old content a little bit, in=20 > order to help readability.] >=20 > On 18 Dec 2006, at 05:02, Bound, Jim wrote: > > ... I am taking a purist *new* approach and assuming transport has=20 > > nothing to do with the internetworking layer at all other than the=20 > > transport dst identifier is a hint or vector to what locators or=20 > > routing-namespace-identifiers are used to deliver the packet. ... >=20 > To me, this sounds like my "architectural approach #2": OK will double check but will take your word for it in my response. I have already had bugs in my readings on this list and other work need to slow down. >=20 > >>>> 2. In the "shim" approaches (HIP/SHIM6/SCTP/...), we change the=20 > >>>> "stacks"; perhaps not immediately but eventually. =20 > Conversely, we=20 > >>>> change the semantics of what now are IP addresses so that > >>>> they become "locators" at the "router/stack" interface and =20 > >>>> "identifiers" at the "stack/application" interface. As a=20 > >>>> consequence, applications will deal with "identifiers"=20 > and routers=20 > >>>> will deal with "locators"; the "stack" will do the translation. >=20 > What I was trying to say with this approach (#2) was the following: >=20 > - change the host stack implementations (but during=20 > transition the same functionality may happen elsewhere) Yes. >=20 > - in the internetworking layer, use locators aka=20 > routing-namespace- identifiers Yes. >=20 > - in the transport layer, use identifiers aka ULIDs Yes. >=20 > Now, this happen also to be my favourite approach; i.e, we=20 > seem to agree. BUT, I am simultaneously trying to understand=20 > the pros and cons of the other two approaches (#1 and #3). Absolutely and due dilligence for sure. >=20 > > Talking with a few offline on this to see if I have gone to far to=20 > > remove all notion of routing, path, and all the other words we use > > today as nomenclature. So will come back to this later. >=20 > Personally, I don't believe you've gone too far, at least=20 > when speaking architecturally. However, once we'll get back=20 > to engineering, we'll probably need some terms for those or=20 > similar functions again. ACK. >=20 > > But in my abstraction above there is no reason for locators=20 > is where I=20 > > am headed that is the layer below. >=20 > I think I understand: no locators at transport but only in a=20 > layer below. BUT, there are some applications people that=20 > would like to do the id/loc split above transport. I think=20 > it would be good to understand the merits and drawbacks of=20 > that approach, too. Agreed that there will be exceptions. What I think we will need in this case and must permit is a fast path like raw sockets API to the internetworking-layer. The nasty part of this for deployment as you know the bindings, PRUs, et al in most stack implementatons integrate quite tightly-coupled the transport with API bindings and that gets to you point about engineering above for this issue too. But my view is many product vendors will need direct access to the internetworking-layer. For true uses of locators in transport layer I think there should be justified use cases and I would wager a small amount most of that can be done via raw sockets (note just using sockets because it is widely well understood there are many APIs and DLLs etc. that do this I realize). >=20 > >> Based on that, I'd consider "application names" a better=20 > choice for=20 > >> ULIDs than "transport names". However, perhaps the best=20 > choice would=20 > >> be "identifier"; or "ULID", as used in SHIM6. > > > > I think your right above and I do like the SHIM6 model of ULID. I will follow yours and others lead on how we determine namespace not my forte but I do understand the pain if we implement them wrong in the network subsystem for an internetworking-layer esp. for forwarding. >=20 > So, at least you and I seem to be converging to using the=20 > term "ULID" =20 > for the names that John used the term "transport name" for,=20 > in his original consensus call. I am ok either way as long as we all agree what it means. ULID is used by SHIM6 and that is pretty good. But ULID might be to generic. What I mean by that is suppose we need identifiers above the *new* transport we might want to attach specific layer syntax to the identifiers now so we can expand them tomorrow. ULID is pretty generic? Just a thought. In that case John's approach could be the right one? >=20 > > But the selection of locators in SHIM6 with a **new** model (Noel,=20 > > John L, you, Tony L, Peter S. and others) may not be=20 > necessary??????? >=20 > I am not sure what you are saying, but if we do the=20 > identifier locator separation, some function somewhere must=20 > select what locator to use for an outgoing packet. =20 > [Traditionally, the choice was made in the application code,=20 > either in the application proper or in some library.] What I=20 > think we have mostly worked out so far are the =20 > architectural options of where to do that choice in the new world. =20 > In some new models, the selection function is located=20 > elsewhere than where it is in SHIM6 and HIP. The selection of path is based on the apps dst identifier which does not have to be a locator or better yet a routing-namespace-identifier. For transition we could easily have a branch condition in the library of the app until the new model is implemented cleanly (note this is how I would move apps to SHIM6 and more importantly today to SCTP :--)). I am speaking from the blank page here and as you know I am the last one to ever support anything that breaks stuff in the market but if we are to have this blank page discussion for "transport" lets have it totally. >=20 > Once we understand better the options or approaches of=20 > *where* to do the locator selection in an architectural=20 > sense, we'll still have lots to do: how to select a good=20 > locator, what kind of infrastructure (if any) is needed to=20 > support that selection, what are the new packet structures=20 > and headers (if any), how the locator selection interacts=20 > with transports, etc. Absolutely. >=20 > Considering the details, we've so far worked out how to do=20 > the identifier locator separation with HIP and SHIM6. Of HIP=20 > we have had working experimental implementations for some 3-5=20 > years now, but still too little practical experience on e.g.=20 > how it works with existing congestion control. AFAIK, the=20 > first SHIM6 implementations should be ready very soon. =20 > Unfortunately, I am ignorant of the implementation and=20 > experimentation situation of Noel's "jack up" (approach #1)=20 > or the recently recognised "above transport" (approach #3) approaches. Understood and the jack-up though I agree is still fuzzy but we need to go there. This work on this list and if we get enough momentum can be the catalyst for more implementations three we have seen happen like this (and there are more) are SCTP, IPv6 Parts, and RDMA. So a good list, friendly debate, smart people and understanding the ground rules in this community bringing all to same mission is very powerful aspect of the IETF. >=20 > > I could be off the deep end here totally removing that from=20 > transport=20 > > but I just want to think about it and run a bit :--). >=20 > One of the areas where I notice myself being somewhat weak is=20 > understanding all the implications of id/loc split to the=20 > traditional =20 > transport functions, i.e. e2e error control and congestion control. =20 > I once thought I understood the case, and recorded my view in=20 > a position paper [1]. But now I'm puzzled, again. I believe most algorithms will remain the same (but we need more than we have today e.g. Satcom lossy links, nodes seamless mobile where QoS changes, etc), but the key is the routing-namespace-identifiers also have to work with functions like heartbeat packets, PTMU, et al. >=20 > [1] Pekka Nikander, "ACCCoRD: Architectural Considerations on=20 > the placement of Congestion Control Routines and Data --=20 > Extended Abstract," in Proceedings of High Speed Networking=20 > Workshop, Budabest, Hungary, May 17-18, 2004, Budabest=20 > University of Technology and Economics. > http://www.tml.tkk.fi/~pnr/publications/hsn2004.pdf I pulled it and will read as I can. The only reason I am keeping up now is because things are slowing down for the holiday season and cheer :--). /jim >=20 > --Pekka Nikander >=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 Dec 18 12:10:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwLzn-0004B2-R5; Mon, 18 Dec 2006 12:09:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwLzn-0004Ax-3z for architecture-discuss@ietf.org; Mon, 18 Dec 2006 12:09:47 -0500 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwLzj-0003do-Ol for architecture-discuss@ietf.org; Mon, 18 Dec 2006 12:09:47 -0500 Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 5882055; Mon, 18 Dec 2006 12:09:43 -0500 In-Reply-To: <812E1D29-A610-42AB-ADF7-18CDCF51F703@nomadiclab.com> References: <816DD9299957E547B5D758D7F977D6DC010F2B0F@tayexc14.americas.cpqcorp.net> <20061212165027.GA60450@verdi> <54CBE937-4DD8-462E-9ABF-85298D48CE37@multicasttech.com> <397A61D4-5B2E-4689-A417-1AC22C1C83A0@multicasttech.com> <812E1D29-A610-42AB-ADF7-18CDCF51F703@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Marshall Eubanks Subject: Re: [arch-d] Do we have "partial consensus"? Date: Mon, 18 Dec 2006 12:09:27 -0500 To: Pekka Nikander X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org Dear Pekka; On Dec 16, 2006, at 4:06 AM, Pekka Nikander wrote: > Dear Marshall, > >> Also note that in this mobile case, you need to include a time =20 >> tag, as the locators will change with time and old locators will =20 >> require different routing. (Locators might change significantly =20 >> during a long tcp session, for example.) > > An interesting observation! But I have never thought that we'd try =20= > to address fast mobility at IP layer. Future location I would define "fast mobility" as something that is comparable to or =20 shorter than the routing convergence time, i.e., order seconds or less. > prediction is nothing new in mobile radio networks, of course. For =20= > example, complex MIMO (multiple in, multiple out) antenna systems =20 > do it all the time to get the interference patterns right. Yes, and that is truly fast mobility. One of the characteristics of =20 large platform mobility is that, on the time scale of routing convergence, they don't move fast (i.e., convergence times =20 are typically < mobility time scale). I would agree that in the case of truly fast mobility, things should be addressed at a =20 lower level or by more specialized solutions. > >>> You are right that it may be unrealistic to solve all of the =20 >>> related problems, or even my "six or seven" problems, at a single =20= >>> shot. OTOH, I have practical reasons to believe that all of my =20 >>> "six or seven" problems could be solved with a public-keys-based =20 >>> identity-layer clearly more elegantly (and with less complexity) =20 >>> than we are able to do today. >>> >>> [For reference, the problems I've considered are the following: =20 >>> scalability of the routing system; combined host mobility and =20 >>> multi-homing; fast and vertical handovers with re-authentication; =20= >>> architected NAT, IPv4/v6 interop, etc.; some forms of bad traffic =20= >>> (DDoS); sub-network naming and mobility; and flexible and secure =20 >>> application naming.] >> >> Is there a write-up of this ? > > Not a single one, but see below. > Thank you for this thorough response. Regards Marshall > As you may know, most of our practical work in this are was done =20 > with HIP, but mostly be applied to many other architectural =20 > options, too. Considering the issues, I am not aware of any papers =20= > that would directly address routing and forwarding with HIP -- =20 > we've generally assumed that since it allows the locators to be =20 > rewritten in the fly it would do as well as any id/loc split =20 > mechanism. > > For some considerations and comparison to legacy NAT, see [1]. =20 > Combined mobility and multi-homing is described in [2], [3] and =20 > [4]. For fast handovers, see e.g. [5], for vertical handovers, =20 > e.g. [6]; I haven't been that much involved in that work and don't =20 > know all the details. Architected NAT and IPv4/IPv6 =20 > interoperability is discussed in [1], [3], [7], and [8]. DoS is =20 > addressed in RFC 4423, DDoS in [9] and [10]. Sub-network mobility =20 > is still work in progress and I am not aware of publications, but =20 > there are submitted papers and we have a working prototype. =20 > Application naming is discussed in [11]. > > --Pekka Nikander > > [1] Jukka Ylitalo, Patrik Salmela, and Hannes Tschofenig, "SPINAT: =20 > Integrating IPsec into Overlay Routing", in Proc. of the First =20 > International Conference on Security and Privacy for Emerging Areas =20= > in Communication Networks (SecureComm'05), Athens, Greece, =20 > September 5-9, 2005. http://users.tkk.fi/~jylitalo/publications/=20 > SecureComm05-Ylitalo-et-al.pdf > > [2] Pekka Nikander, Jukka Ylitalo, and Jorma Wall, "Integrating =20 > Security, Mobility, and Multi-Homing in a HIP Way", in Proc. of =20 > Network and Distributed Systems Security Symposium (NDSS'03), pp. =20 > 87-99, ISBN 1-891562-16-9, Internet Society, San Diego, CA, US, =20 > February 6-7, 2003. > http://www.tml.tkk.fi/~pnr/publications/NDSS03-Nikander-et-al.pdf > > [3] Jukka Ylitalo, Pekka Nikander, "A new Name Space for End-=20 > Points: Implementing secure Mobility and Multi-homing across the =20 > two versions of IP," in Proceedings of the Fifth European Wireless =20 > Conference, Mobile and Wireless Systems beyond 3G (EW2004), pp. =20 > 435-441, Barcelona, Spain, February 24-27, 2004. > http://www.tml.tkk.fi/~pnr/publications/ew2004.pdf > > [4] T. Henderson (ed), "End-Host Mobility and Multihoming with the =20 > Host Identity Protocol", ID, IETF. > http://www.ietf.org/internet-drafts/draft-ietf-hip-mm-04.txt > > [5] Jari Arkko and Pekka Nikander, "Fast network attachment", =20 > WO2006018045, EPO. > > [6] Jokela P., Wall J., Melen J., Rinta-aho T., Kauppinen T., =20 > Mahkonen H., Jokikyyny T., > Kuparinen M., Korhonen J., "Handover Performance with HIP and =20 > MIPv6", International > Symposium on Wireless Communication Systems, in Proceedings of =20 > ISWCS'04. > > [7] Hannes Tschofenig, Andrei Gurtov, Jukka Ylitalo, Aarthi =20 > Nagarajan, and Murugaraj Shanmugam, "Traversing Middleboxes with =20 > the Host Identity Protocol", in Proc. of the Tenth Australasian =20 > Conference on Information Security and Privacy (ACISP'05), =20 > Brisbane, Australia, July 4-6, 2005. > http://users.tkk.fi/~jylitalo/publications/ACISP2005-Tschofenig-et-=20 > al.pdf > > [8] Petri Jokela, Pekka Nikander, Jan Melen, Jukka Ylitalo and =20 > Jorma Wall, "Host Identity Protocol: Achieving IPv4 - IPv6 =20 > handovers without tunneling", in Proceedings of Evolute workshop =20 > 2003: "Beyond 3G Evolution of Systems and Services", University of =20 > Surrey, Guildford, UK, November 10, 2003. > http://www.tml.tkk.fi/~pnr/publications/evolute2003.pdf > > [9] Pekka Nikander, Jari Arkko, and B=F6rje Ohlman, Host Identity =20 > Indirection Infrastructure (Hi3)," in Proceedings of The Second =20 > Swedish National Computer Networking Workshop 2004 (SNCNW2004), =20 > Karlstad University, Karlstad, Sweden, Nov 23-24, 2004. > http://www.tml.tkk.fi/~pnr/publications/sncnw2004.pdf > > [10] Andrei Gurtov, Dmitry Korzun, Pekka Nikander, "Hi3: An =20 > Efficient and Secure Networking Architecture for Mobile Hosts," =20 > Technical report 2005-2, Helsinki Institute for Information =20 > Technology, June 2005. > http://www.tml.tkk.fi/~pnr/publications/=20 > HIIT_gurtov_hi3_report_2005.pdf > > [11] Teemu Koponen, Andrei Gurtov, Pekka Nikander, "Application =20 > mobility with Host Identity Protocol," Extended Abstract in Proc. =20 > of NDSS Wireless and Mobile Security Workshop, San Diego, CA, USA, =20 > February 2005. > > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Mon Dec 18 12:40:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwMT8-0001d7-J9; Mon, 18 Dec 2006 12:40:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwMT6-0001cs-TI for architecture-discuss@ietf.org; Mon, 18 Dec 2006 12:40:04 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwMT4-000880-7W for architecture-discuss@ietf.org; Mon, 18 Dec 2006 12:40:04 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 18 Dec 2006 18:40:02 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kBIHdxnH027550; Mon, 18 Dec 2006 18:39:59 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kBIHdktD005469; Mon, 18 Dec 2006 18:39:49 +0100 (MET) Received: from lwood-wxp01.cisco.com (ams3-vpn-dhcp128.cisco.com [10.61.64.128]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA06586; Mon, 18 Dec 2006 17:39:46 GMT Message-Id: <200612181739.RAA06586@cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 18 Dec 2006 17:39:13 +0000 To: Marshall Eubanks From: Lloyd Wood Subject: Re: [arch-d] Do we have "partial consensus"? In-Reply-To: References: <816DD9299957E547B5D758D7F977D6DC010F2B0F@tayexc14.americas.cpqcorp.net> <20061212165027.GA60450@verdi> <54CBE937-4DD8-462E-9ABF-85298D48CE37@multicasttech.com> <397A61D4-5B2E-4689-A417-1AC22C1C83A0@multicasttech.com> <812E1D29-A610-42AB-ADF7-18CDCF51F703@nomadiclab.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Authentication-Results: ams-dkim-2; header.From=L.Wood@surrey.ac.uk; dkim=neutral X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: Pekka Nikander , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org An observation on this discussion: the word 'mobility' is overused and= overloaded in the IETF world. 'Fast mobility', as discussed below, is pretty much what everyone else has= always called mobility; truly fast mobility needs to take advantage of= physical channel diversity (i.e. make before break for a seamless= handover). 'Slow mobility' or 'mobility' is pretty much what everyone else calls= 'roaming' - 'Mobile IP' is imo misnamed, since it's really about preserving= your static address in a home network while roaming on a different network,= and that roaming may or may not have a mobility aspect with regular= handovers involved. [US: read 'handover' as 'handoff'] L. "Partial consensus"? Is that like "partly pregnant"? At Monday 18/12/2006 12:09 -0500, Marshall Eubanks wrote: >Dear Pekka; > >On Dec 16, 2006, at 4:06 AM, Pekka Nikander wrote: > >>Dear Marshall, >> >>>Also note that in this mobile case, you need to include a time =20 >>>tag, as the locators will change with time and old locators will =20 >>>require different routing. (Locators might change significantly =20 >>>during a long tcp session, for example.) >> >>An interesting observation! But I have never thought that we'd try =20 >>to address fast mobility at IP layer. Future location > >I would define "fast mobility" as something that is comparable to or =20 >shorter than the routing convergence time, i.e., order seconds >or less. > >>prediction is nothing new in mobile radio networks, of course. For =20 >>example, complex MIMO (multiple in, multiple out) antenna systems =20 >>do it all the time to get the interference patterns right. > >Yes, and that is truly fast mobility. One of the characteristics of =20 >large platform mobility is that, on the time scale of >routing convergence, they don't move fast (i.e., convergence times =20 >are typically < mobility time scale). I would agree that >in the case of truly fast mobility, things should be addressed at a =20 >lower level or by more specialized solutions. > >> >>>>You are right that it may be unrealistic to solve all of the =20 >>>>related problems, or even my "six or seven" problems, at a single =20 >>>>shot. OTOH, I have practical reasons to believe that all of my =20 >>>>"six or seven" problems could be solved with a public-keys-based =20 >>>>identity-layer clearly more elegantly (and with less complexity) =20 >>>>than we are able to do today. >>>> >>>>[For reference, the problems I've considered are the following: =20 >>>>scalability of the routing system; combined host mobility and =20 >>>>multi-homing; fast and vertical handovers with re-authentication; =20 >>>>architected NAT, IPv4/v6 interop, etc.; some forms of bad traffic =20 >>>>(DDoS); sub-network naming and mobility; and flexible and secure =20 >>>>application naming.] >>> >>>Is there a write-up of this ? >> >>Not a single one, but see below. > >Thank you for this thorough response. > >Regards >Marshall > >>As you may know, most of our practical work in this are was done =20 >>with HIP, but mostly be applied to many other architectural =20 >>options, too. Considering the issues, I am not aware of any papers =20 >>that would directly address routing and forwarding with HIP -- =20 >>we've generally assumed that since it allows the locators to be =20 >>rewritten in the fly it would do as well as any id/loc split =20 >>mechanism. >> >>For some considerations and comparison to legacy NAT, see [1]. =20 >>Combined mobility and multi-homing is described in [2], [3] and =20 >>[4]. For fast handovers, see e.g. [5], for vertical handovers, =20 >>e.g. [6]; I haven't been that much involved in that work and don't =20 >>know all the details. Architected NAT and IPv4/IPv6 =20 >>interoperability is discussed in [1], [3], [7], and [8]. DoS is =20 >>addressed in RFC 4423, DDoS in [9] and [10]. Sub-network mobility =20 >>is still work in progress and I am not aware of publications, but =20 >>there are submitted papers and we have a working prototype. =20 >>Application naming is discussed in [11]. >> >>--Pekka Nikander >> >>[1] Jukka Ylitalo, Patrik Salmela, and Hannes Tschofenig, "SPINAT: =20 >>Integrating IPsec into Overlay Routing", in Proc. of the First =20 >>International Conference on Security and Privacy for Emerging Areas =20 >>in Communication Networks (SecureComm'05), Athens, Greece, =20 >>September 5-9, 2005. http://users.tkk.fi/~jylitalo/publications/= SecureComm05-Ylitalo-et-al.pdf >> >>[2] Pekka Nikander, Jukka Ylitalo, and Jorma Wall, "Integrating =20 >>Security, Mobility, and Multi-Homing in a HIP Way", in Proc. of =20 >>Network and Distributed Systems Security Symposium (NDSS'03), pp. =20 >>87-99, ISBN 1-891562-16-9, Internet Society, San Diego, CA, US, =20 >>February 6-7, 2003. >>http://www.tml.tkk.fi/~pnr/publications/NDSS03-Nikander-et-al.pdf >> >>[3] Jukka Ylitalo, Pekka Nikander, "A new Name Space for End- Points:= Implementing secure Mobility and Multi-homing across the =20 >>two versions of IP," in Proceedings of the Fifth European Wireless =20 >>Conference, Mobile and Wireless Systems beyond 3G (EW2004), pp. =20 >>435-441, Barcelona, Spain, February 24-27, 2004. >>http://www.tml.tkk.fi/~pnr/publications/ew2004.pdf >> >>[4] T. Henderson (ed), "End-Host Mobility and Multihoming with the =20 >>Host Identity Protocol", ID, IETF. >>http://www.ietf.org/internet-drafts/draft-ietf-hip-mm-04.txt >> >>[5] Jari Arkko and Pekka Nikander, "Fast network attachment", =20 >>WO2006018045, EPO. >> >>[6] Jokela P., Wall J., Melen J., Rinta-aho T., Kauppinen T., =20 >>Mahkonen H., Jokikyyny T., >>Kuparinen M., Korhonen J., "Handover Performance with HIP and =20 >>MIPv6", International >>Symposium on Wireless Communication Systems, in Proceedings of =20 >>ISWCS'04. >> >>[7] Hannes Tschofenig, Andrei Gurtov, Jukka Ylitalo, Aarthi =20 >>Nagarajan, and Murugaraj Shanmugam, "Traversing Middleboxes with =20 >>the Host Identity Protocol", in Proc. of the Tenth Australasian =20 >>Conference on Information Security and Privacy (ACISP'05), =20 >>Brisbane, Australia, July 4-6, 2005. >>http://users.tkk.fi/~jylitalo/publications/ACISP2005-Tschofenig-et- al.pdf >> >>[8] Petri Jokela, Pekka Nikander, Jan Melen, Jukka Ylitalo and =20 >>Jorma Wall, "Host Identity Protocol: Achieving IPv4 - IPv6 =20 >>handovers without tunneling", in Proceedings of Evolute workshop =20 >>2003: "Beyond 3G Evolution of Systems and Services", University of =20 >>Surrey, Guildford, UK, November 10, 2003. >>http://www.tml.tkk.fi/~pnr/publications/evolute2003.pdf >> >>[9] Pekka Nikander, Jari Arkko, and B=F6rje Ohlman, Host Identity =20 >>Indirection Infrastructure (Hi3)," in Proceedings of The Second =20 >>Swedish National Computer Networking Workshop 2004 (SNCNW2004), =20 >>Karlstad University, Karlstad, Sweden, Nov 23-24, 2004. >>http://www.tml.tkk.fi/~pnr/publications/sncnw2004.pdf >> >>[10] Andrei Gurtov, Dmitry Korzun, Pekka Nikander, "Hi3: An =20 >>Efficient and Secure Networking Architecture for Mobile Hosts," =20 >>Technical report 2005-2, Helsinki Institute for Information =20 >>Technology, June 2005. >>http://www.tml.tkk.fi/~pnr/publications/ HIIT_gurtov_hi3_report_2005.pdf >> >>[11] Teemu Koponen, Andrei Gurtov, Pekka Nikander, "Application =20 >>mobility with Host Identity Protocol," Extended Abstract in Proc. =20 >>of NDSS Wireless and Mobile Security Workshop, San Diego, CA, USA, =20 >>February 2005. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Tue Dec 19 12:49:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwj4B-0000q8-Nz; Tue, 19 Dec 2006 12:47:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwj4A-0000px-LR for architecture-discuss@ietf.org; Tue, 19 Dec 2006 12:47:50 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gwj48-00082Q-PP for architecture-discuss@ietf.org; Tue, 19 Dec 2006 12:47:50 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id CA76F4ACA5; Tue, 19 Dec 2006 12:47:42 -0500 (EST) Date: Tue, 19 Dec 2006 12:47:42 -0500 From: John Leslie To: architecture-discuss@ietf.org Subject: Re: [arch-d] Do we have "partial consensus"? Message-ID: <20061219174742.GN2478@verdi> References: <816DD9299957E547B5D758D7F977D6DC010F2B0F@tayexc14.americas.cpqcorp.net> <20061212165027.GA60450@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061212165027.GA60450@verdi> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org A week has passed: I'll try for an update: John Leslie wrote: > > ... I will try to outline areas of questions; but first please let me > do a complete statement: I welcome discussion of the issues I'll name, > and I welcome listing other areas of question... > > Statement: (See below for a discussion of the layer names.) > We want to work towards an architecture with separate "layers" for > "routing" and "transport", where "routing" is responsible for > - delivering packets to destinations on the same network; > - forwarding the other packets to another network "closer" to their > destination; > - dropping the other packets if no "closer" network is available; > - building forwarding tables believed to be loop-free; > - detecting loops in forwarding paths actually used; > - dropping packets which would cause excessive congestion; There has been discussion whether some of these responsibilities belong to an even lower layer: I don't think there's consensus on that; and I think we can proceed without settling that question. > and "transport" is responsible for > - detecting and adjusting for packet loss; > - detecting and adjusting for packet corruption; > - reducing packet injection rate when a path is congested; (The erroneous fourth bullet under "transport" has been removed.) > Question Areas: > > - is there a better name than "layers" for these problem spaces? None has been proposed: let's stick with "layers". > - is there a better name than "routing" for the lower "layer"? It has been suggested we call the lower layer "internetworking". I endorse such a change. > - is there a better name than "transport" for the upper "layer"? I think we have rough consensus to talk of a "transport" layer; but there is still confusion about whether we're trying to assign too much to it. IMHO, we're close enough to consensus to agree to discuss a "transport" layer with the three named functions, and possibly others. > - are any of the responsibilities clearly assigned to the wrong > "layer"? None have been proposed (not counting the questions about a layer below "internetworking").. > - are we ready to agree to define separate namespaces for these > "layers"? We're not ready for that yet, as I read the posts. :^( However, I think we're close to consensus that the "namespace" for the "internetworking" layer should be locators; and that some higher layer (not necessarily "transport") should have a namespace containing identifiers not tied to "internetworking" topology. That may be close enough... (Important though this task surely is, I remain convinced that we've got to assign responsibilities before we can logically design a new namespace.) > (I know there are other responsibilities which _must_ be assigned > before we can have a working system: I'd _really_ prefer not to > argue where they belong yet...) If I've correctly stated the partial consensus above, I think we're ready to discuss where other responsibilities belong. In any case, I'd like to ask: - what other responsibilities should be assigned to these layers? - are there responsibilities which should be assigned a layer higher than "transport"? -- John Leslie _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Dec 27 10:48:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzazT-0007c4-Ls; Wed, 27 Dec 2006 10:46:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzazS-0007aM-OX for architecture-discuss@ietf.org; Wed, 27 Dec 2006 10:46:50 -0500 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GzazR-0001wL-Hq for architecture-discuss@ietf.org; Wed, 27 Dec 2006 10:46:50 -0500 Received: by mailhost.jlc.net (Postfix, from userid 104) id 5CDDE4ACC5; Wed, 27 Dec 2006 10:46:47 -0500 (EST) Date: Wed, 27 Dec 2006 10:46:47 -0500 From: John Leslie To: architecture-discuss@ietf.org Subject: Re: [arch-d] Do we have "partial consensus"? Message-ID: <20061227154647.GA2859@verdi> References: <816DD9299957E547B5D758D7F977D6DC010F2B0F@tayexc14.americas.cpqcorp.net> <20061212165027.GA60450@verdi> <20061219174742.GN2478@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061219174742.GN2478@verdi> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org A week has passed... John Leslie wrote: > > If I've correctly stated the partial consensus above, I think we're > ready to discuss where other responsibilities belong. In any case, > I'd like to ask: > > - what other responsibilities should be assigned to these layers? > > - are there responsibilities which should be assigned a layer higher > than "transport"? The list has been (completely) quiet: I take this to indicate the time of year. Regardless, I'd be really surprised if _nobody_ has a wishlist concerning mobility, security, and/or privacy. It would be really helpful if we gathered these wishlists within the next week... -- John Leslie _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Dec 28 01:37:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gzos5-0003Xy-7Q; Thu, 28 Dec 2006 01:36:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gzos3-0003Xh-C5 for architecture-discuss@ietf.org; Thu, 28 Dec 2006 01:36:07 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gzos1-0006KC-K2 for architecture-discuss@ietf.org; Thu, 28 Dec 2006 01:36:07 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 2DD7A2130B1; Thu, 28 Dec 2006 08:35:50 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id CC6E72130A7; Thu, 28 Dec 2006 08:35:49 +0200 (EET) In-Reply-To: <20061227154647.GA2859@verdi> References: <816DD9299957E547B5D758D7F977D6DC010F2B0F@tayexc14.americas.cpqcorp.net> <20061212165027.GA60450@verdi> <20061219174742.GN2478@verdi> <20061227154647.GA2859@verdi> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: [arch-d] About the location of mobility, security, and privacy (was Re: Do we have "partial consensus"?) Date: Thu, 28 Dec 2006 08:35:46 +0200 To: John Leslie X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: architecture-discuss-bounces@ietf.org > Regardless, I'd be really surprised if _nobody_ has a wishlist > concerning mobility, security, and/or privacy. It would be really > helpful if we gathered these wishlists within the next week... I still don't understand what you are aiming or what you are trying to accomplish with this "partial consensus", but very briefly w.r.t the three functions above: A. Mobility functionality we may need on almost all "layers": 1. physical layer looks like the best layer for handling local, fast, radio based mobility (MIMO etc) 2. link layer looks like the best layer for handling local, cross link or cross base station mobility 3-4. internetworking and/or transport looks like the natural layer for global host mobility; there are weak indications (signalling efficiency, aggregation etc) indicating that internetworking is probably better 5. personally, I still don't understand all the subtleties related to session mobility, especially inter-node session handovers, and e2e error correction and congestion control state 7. if we had proper application naming aggregation structures, we could most probably handle subnet mobility and application-level delegation much better than today B. Different security functions we will need on almost all "layers": 1. physical layer is a great place to implement geographic location security and over-the-air opportunistic encryption, etc. 2. link layer is a good place to include network access control 3-4. there are indications that the location of IPsec, i.e., between traditional internetworking and traditional transport, is a good choice for placing e2e encryption and integrity 7. it is cumbersome to place user and service authentication and access control outside of the application layer, as they have their application specific aspects C. It is impossible to properly implement privacy without considering all "layers" simultaneously 1-7. just consider session tracking and mobility --Pekka Nikander _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss