From architecture-discuss-bounces@ietf.org Mon Oct 17 16:01:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERbAT-00013I-EP; Mon, 17 Oct 2005 16:01:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERbAK-0000sE-5N; Mon, 17 Oct 2005 16:01:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04889; Mon, 17 Oct 2005 16:00:52 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERbLd-0000jj-Td; Mon, 17 Oct 2005 16:12:46 -0400 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1ERbAE-0008Un-CK; Mon, 17 Oct 2005 16:00:54 -0400 Content-Type: text/plain Mime-Version: 1.0 To: IETF Announcement list From: Leslie Daigle Message-Id: Date: Mon, 17 Oct 2005 16:00:54 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: iab@ietf.org, iesg@ietf.org, architecture-discuss@ietf.org Subject: [Architecture-discuss] New architecture-discuss mailing list forum X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org A new mailing list has been created to provide a forum for general discussion of Internet architectural issues: architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss The architecture-discuss list serves as a technical discussion forum for all members of the IETF community that are interested in larger architectural issues. It is meant to be an open discussion forum for all long and/or wide range architectural concerns related to the Internet Architecture. In particular, it may be used to discuss and bring forth different points of view on controversial architectural questions. Discussions that drill down and dwell on specifics of individual protocols or technologies are to be discouraged, redirected to appropriate other fora, or re-cast to discussions of broader implications for Internet architecture. This is an IAB-sponsored activity, but IAB members will be participating as individuals and not representatives of the IAB. As such, postings to list must not be considered as IAB opinion, and must not be quoted as such. Indeed, it is expected that IAB members will disagree with each other, at least occasionally, just like the any part of this community. :-) Note that questions asking for an official IAB opinion, issues requiring immediate action (by anyone), issues related to the way the IETF operates, do not belong on this list. Issues pertaining to IAB business should still be directed to iab@iab.org . Leslie Daigle, for the IAB. ------------------------ [Some examples of potential topics for discussion, provided by Pekka Nikkander] 1. Mobility and multi-homing The IETF currently hosts a bunch of working groups focusing on various aspects of mobility and multi homing. At the Internet Area, there are five WGs and a couple of almost-WGs charted for standards track work: MIP4, MIP6, NEMO, SHIM6, MONAMI6, and NETLMM. In addition to those, there are experimental approaches, such as HIP, and optimisations, such as MIPSHOP and MOBOPTS. Outside of the Internet area, MOBIKE is focusing on mobility and multi-homing for IPsec and SCTP and DCCP folks have had their mobility and multi- homing discussions. The wider research community is full of various proposals, including overlay approaches (such as i3) and underlay approaches (such as using MPLS tunnels to implement host routes). Given this multitude of work and even partially overlapping standards track solutions, what would be the right way or right ways forward? Could we design a way towards converging solutions? How do we ensure robustness of solutions if we attempt to deploy multiple solutions at the same time; for example, SHIM6 + Mobile IPv6 + SHIM6? How do more unified solutions, like using CGA-based mobility with SHIM6 contrast to this? What about using HIP with routable IP addresses instead of Host Identity Tags (HITs) as Upper Layer Identifiers? Going a little bit furthermore, what are the architectural impacts of doing mobility and multi-homing at the IP layer vs. other layers? 2. IP virtualisation In the recent discussion w.r.t. tunnelling at the Internet Area list, a clear need for virtualisation came up. While tunnelling with clear implementation-level virtualisation boundaries is clearly one viable way to implement virtual IP networks on the top of the "real" IP infrastructure, this issue seems to warrant some deeper digging. Tunnelling has well known drawbacks, and we may want to ask what would be the alternatives. In order to understand alternatives, if any, we need to understand better the requirements behind IP virtualisation, or what people *really* want to achieve with it. Is it merely ease of configuration, or reduced operational costs? If so, could there be other architectural ways of achieving the same ease or perhaps even larger capital and operational savings? Some people have been promoting adding "realms" as a first class service to the base IP. Would that provide an alternative solution? While the mobility and multi-homing discussion seems to more circle around evaluating existing proposals and trying to navigate towards more unified solutions, here we seem to lack genuine alternatives and deep understanding of the real problem domain. 3. Overall open architectural issues Some IAB members have been collecting open architectural issues for a while, with the intention of bringing up an up to date collection of information at a later date, probably in a form of a WikiPedia-like web site. This work is going on, and we'd like to get as much information as possible from the wider community. Hence, suggestions on what are the more pressing longer-term open issues are very welcome. To given an idea of the current issues so far identified, here is a partial list. The list doesn't say much without explanation, but it may give an idea of the type of issues we are looking at. End-to-end connectivity ======================= The original value of the Internet, the ability to connect to any host with any protocol, has eroded away during the last decade. While it is impossible to get back to the original mode of operation, largely due to security reasons, some form of better-than-today end- to-end connectivity would be very valuable. o Living with NATs, filters, and firewalls o Introducing identity realms or domains o Evolving the application interface (API) End-user experience =================== o Transparent security o Zero Configuration and Service Discovery Balancing Accessibility, Security, and Privacy ============================================== o System for plausible sender identity for received packets o Secure self-configuration o Integrating security across the stack o Dealing with bad traffic _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Oct 26 17:49:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUt9N-0001kw-Lz; Wed, 26 Oct 2005 17:49:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUt9M-0001kP-3z for architecture-discuss@megatron.ietf.org; Wed, 26 Oct 2005 17:49:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28750 for ; Wed, 26 Oct 2005 17:49:20 -0400 (EDT) Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUtMa-0006WE-1M for architecture-discuss@ietf.org; Wed, 26 Oct 2005 18:03:17 -0400 Received: from [192.35.165.156] ([::ffff:128.107.248.220]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Wed, 26 Oct 2005 17:49:21 -0400 id 0158806D.435FF9E1.000017A0 Message-ID: <435FF9DE.1060205@thinkingcat.com> Date: Wed, 26 Oct 2005 17:49:18 -0400 From: Leslie Daigle User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: architecture-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Subject: [Architecture-discuss] Mobility and multi-homing X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org [Tap tap tap -- "is this thing on?" ;-) I'm forwarding Pekka Nikander's suggested topic-starters, one at a time, to see if we can get some "discuss" going, about "architecture". -- LLD] [Pekka wrote:] 1. Mobility and multi-homing The IETF currently hosts a bunch of working groups focusing on various aspects of mobility and multi homing. At the Internet Area, there are five WGs and a couple of almost-WGs charted for standards track work: MIP4, MIP6, NEMO, SHIM6, MONAMI6, and NETLMM. In addition to those, there are experimental approaches, such as HIP, and optimisations, such as MIPSHOP and MOBOPTS. Outside of the Internet area, MOBIKE is focusing on mobility and multi-homing for IPsec and SCTP and DCCP folks have had their mobility and multi- homing discussions. The wider research community is full of various proposals, including overlay approaches (such as i3) and underlay approaches (such as using MPLS tunnels to implement host routes). Given this multitude of work and even partially overlapping standards track solutions, what would be the right way or right ways forward? Could we design a way towards converging solutions? How do we ensure robustness of solutions if we attempt to deploy multiple solutions at the same time; for example, SHIM6 + Mobile IPv6 + SHIM6? How do more unified solutions, like using CGA-based mobility with SHIM6 contrast to this? What about using HIP with routable IP addresses instead of Host Identity Tags (HITs) as Upper Layer Identifiers? Going a little bit furthermore, what are the architectural impacts of doing mobility and multi-homing at the IP layer vs. other layers? _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Oct 26 17:51:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUtAz-0002xm-Qp; Wed, 26 Oct 2005 17:51:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUtAx-0002tp-Il for architecture-discuss@megatron.ietf.org; Wed, 26 Oct 2005 17:51:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28858 for ; Wed, 26 Oct 2005 17:50:59 -0400 (EDT) Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUtO9-0006Yu-GW for architecture-discuss@ietf.org; Wed, 26 Oct 2005 18:04:56 -0400 Received: from [192.35.165.156] ([::ffff:128.107.248.220]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Wed, 26 Oct 2005 17:50:58 -0400 id 0158806D.435FFA42.00001814 Message-ID: <435FFA3F.1060309@thinkingcat.com> Date: Wed, 26 Oct 2005 17:50:55 -0400 From: Leslie Daigle User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: architecture-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Subject: [Architecture-discuss] IP virtualisation X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org [I'm forwarding Pekka Nikander's suggested topic-starters, one at a time, to see if we can get some "discuss" going, about "architecture". -- LLD] [Pekka wrote:] 2. IP virtualisation In the recent discussion w.r.t. tunnelling at the Internet Area list, a clear need for virtualisation came up. While tunnelling with clear implementation-level virtualisation boundaries is clearly one viable way to implement virtual IP networks on the top of the "real" IP infrastructure, this issue seems to warrant some deeper digging. Tunnelling has well known drawbacks, and we may want to ask what would be the alternatives. In order to understand alternatives, if any, we need to understand better the requirements behind IP virtualisation, or what people *really* want to achieve with it. Is it merely ease of configuration, or reduced operational costs? If so, could there be other architectural ways of achieving the same ease or perhaps even larger capital and operational savings? Some people have been promoting adding "realms" as a first class service to the base IP. Would that provide an alternative solution? While the mobility and multi-homing discussion seems to more circle around evaluating existing proposals and trying to navigate towards more unified solutions, here we seem to lack genuine alternatives and deep understanding of the real problem domain. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Oct 26 17:52:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUtBl-0004MS-71; Wed, 26 Oct 2005 17:52:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUtBk-0004Ky-3v for architecture-discuss@megatron.ietf.org; Wed, 26 Oct 2005 17:52:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28902 for ; Wed, 26 Oct 2005 17:51:48 -0400 (EDT) Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUtOz-0006Yu-6R for architecture-discuss@ietf.org; Wed, 26 Oct 2005 18:05:45 -0400 Received: from [192.35.165.156] ([::ffff:128.107.248.220]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Wed, 26 Oct 2005 17:51:58 -0400 id 0158806D.435FFA7E.00001865 Message-ID: <435FFA7B.50903@thinkingcat.com> Date: Wed, 26 Oct 2005 17:51:55 -0400 From: Leslie Daigle User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: architecture-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Subject: [Architecture-discuss] Overall open architectural issues X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org [I'm forwarding Pekka Nikander's suggested topic-starters, one at a time, to see if we can get some "discuss" going, about "architecture". -- LLD] [Pekka wrote:] 3. Overall open architectural issues Some IAB members have been collecting open architectural issues for a while, with the intention of bringing up an up to date collection of information at a later date, probably in a form of a WikiPedia-like web site. This work is going on, and we'd like to get as much information as possible from the wider community. Hence, suggestions on what are the more pressing longer-term open issues are very welcome. To given an idea of the current issues so far identified, here is a partial list. The list doesn't say much without explanation, but it may give an idea of the type of issues we are looking at. End-to-end connectivity ======================= The original value of the Internet, the ability to connect to any host with any protocol, has eroded away during the last decade. While it is impossible to get back to the original mode of operation, largely due to security reasons, some form of better-than-today end- to-end connectivity would be very valuable. o Living with NATs, filters, and firewalls o Introducing identity realms or domains o Evolving the application interface (API) End-user experience =================== o Transparent security o Zero Configuration and Service Discovery Balancing Accessibility, Security, and Privacy ============================================== o System for plausible sender identity for received packets o Secure self-configuration o Integrating security across the stack o Dealing with bad traffic _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Wed Oct 26 22:41:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUxiH-00012N-D8; Wed, 26 Oct 2005 22:41:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUxiG-00010r-8j for architecture-discuss@megatron.ietf.org; Wed, 26 Oct 2005 22:41:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16882 for ; Wed, 26 Oct 2005 22:41:40 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUxvX-0003th-Rl for architecture-discuss@ietf.org; Wed, 26 Oct 2005 22:55:40 -0400 Received: from i01m-62-35-167-26.d4.club-internet.fr ([62.35.167.26] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EUxi9-0000it-C4; Wed, 26 Oct 2005 19:41:50 -0700 Message-Id: <6.2.3.4.2.20051027033350.06775490@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Thu, 27 Oct 2005 04:15:07 +0200 To: Leslie Daigle , architecture-discuss@ietf.org From: "JFC (Jefsey) Morfin" In-Reply-To: <435FFA7B.50903@thinkingcat.com> References: <435FFA7B.50903@thinkingcat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Subject: [Architecture-discuss] small suggestion X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org Dear Leslie and all, this new mailing list is a new exercise. May I suggest an initial suggestion and explain my - often controverted approach? I am interested in usage architecture. I am not much concerned therefore by layers 1-7, but I learned over Tymnet, OSI, Internet that the architectural culture has a dramatic simplification impact on usage architecture. This is why I need global consistency and quality of the IETF deliverables. And I am excited by this list. I see two main needs: - architectural coordination between diversified propositions from different WG. Probably the largest demand. - reduction of the Internet proposition to a much simpler and powerful one, in having architecture as a priority. Like when one cleans an old city and build new, open, wide avenues. The most interesting issue. I have read your two other mails. No to say something stupid about what is quoted, I would need to spend one or two years in a few WG I am interested only in a very side aspect. May be could we agree that everything discussed should be accompanied of the a URL summarising the current state of the art/thinking of the matter in a few lines and further links. I am sure it would help me, and probably a few other ones. May such a notes could be hosted by IAB and made part of the current effort to document the IETF work? To explain my ignorance, my interest in core issue and my possible unexpected positions, I must explain that my current effort (for already 4 years of usage architecture oriented work) consists in starting from what I name a "corebox". This is the core of a user network system. And then to investigate what I need to address each of my needs, discussing the simplest, most robust, most consistent, most scalable way to get it. The needs starts with my small network/home network and extend to a global coverage of the whole digital ecosystem and to all its partners. Whatever the technology (Internet, phone, TV, radio, CD, printed mail, etc..), whatever the language and culture (my core language is not English). This user-centric approach is certainly different. It does not covers everything. But I learned that looking at the same thing from a different point of view, often helped a lot. At least it will explain the silly remarks I will make and the dumb priorities and interests I may have. jfc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Oct 27 08:24:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV6nq-0002Km-D4; Thu, 27 Oct 2005 08:24:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV6nn-0002Ij-RZ for architecture-discuss@megatron.ietf.org; Thu, 27 Oct 2005 08:24:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25691 for ; Thu, 27 Oct 2005 08:23:58 -0400 (EDT) Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV718-0000Hd-G5 for architecture-discuss@ietf.org; Thu, 27 Oct 2005 08:38:04 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id F31AA86AEE; Thu, 27 Oct 2005 08:24:04 -0400 (EDT) To: architecture-discuss@ietf.org Subject: Re: [Architecture-discuss] Mobility and multi-homing Message-Id: <20051027122404.F31AA86AEE@mercury.lcs.mit.edu> Date: Thu, 27 Oct 2005 08:24:04 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org > From: Leslie Daigle > The IETF currently hosts a bunch of working groups focusing on various > aspects of mobility and multi homing. >From an architectural perspective, any attempt to provide such capabilities, when the underlying architecture isn't rich enough in namespaces/mechanisms/etc to do so in a clean way, will result in ugly "bags on the side" which just accelerate the death of the existing system through feature-cancer (of which your long list of WG's, etc is a perfect example). The alternative, a genuine architectural re-think and resulting restructuring, is something that long and painful experience has shown is not very palatable to the IETF community - my sense is that the costs have always seemed too high to most. Maybe the community is more ready now to pay the price (bearing in mind the old adage that you generally get what you pay for - and when you pay $0 for better architecture, you don't get any better architecture), but at this point my optimism is pretty worn out. I don't have any good solution to this. I think in engineering terms, I think the NSRG concept of designing a new namespace, and deploying it one application and/or transport layer at a time, was the best one. (Efforts like NewArch which involve "forklift" upgrades to the entire stack are interesting - and necessary - academic exercises, but aren't practical models for how to upgrade the engines in flight.) However, two problems. One, I don't have a good concept of how to make it happen organizationally - either i) to make disparate groups adhere to the concept, or ii) provide the drive to make it happen. Two, even then you have to accept that lots of legacy "stuff" (protocols, boxes, etc) won't be able to utilize those new capabilities. > what would be the right way or right ways forward? Could we design a > way towards converging solutions? How do we ensure robustness of > solutions if we attempt to deploy multiple solutions at the same time There is no substitute for an overall vision of where you want to wind up, in terms of architecture. Without that, engineering efforts will head off in disparate, unconnected, directions. Once you have such a vision (in terms of namespaces, mechanisms, etc) then you have a defined toolbox that all efforts use in common, which will automatically create coherence, etc. > What about using HIP with routable IP addresses instead of Host > Identity Tags (HITs) as Upper Layer Identifiers? Oh, yes, let's try a *different* way of fitting the proverbial 10 pounds into the 5 pound sack. Maybe this time it will work! I assume I need say no more about this idea, which frankly should have instantly triggered the bogometer of anyone subscribed to an "architecture" list... > Going a little bit furthermore, what are the architectural impacts of > doing mobility and multi-homing at the IP layer vs. other layers? Well, that's an interesting question. First, I'm going to back you up and recast what you said as "are architectural features used to support mobility and multi-homing resident at the IP layer, or other layers?" To an architect, mobility and multi-homing are *applications* - we merely supply *tools* that other people can use to design things that procide them. I think it's clear that such support has to happen above the "deliver a packet from this interface to that interface" layer. Whether one integrates all - or part - of it with tranports, or makes some of it a separate shim (which one might notionally think of as part of the internetwork layer, although in reality it would be a separate sub-layer above the "deliver a packet from this interface to that interface" stuff) is a useful question. In a perfect world, I'd go for the shim, but in the real world, where the plane is flying, maybe you have to bundle it with transports. Actually, the question I wound up pondering was whether the old TCP model of "endpoint to endpoint" was the way to go, or whether we needed some richer model in which you were talking to a pool of servers, so that things like load-sharing and failover popped out as well-supported by the basic transport. Right now, with the Web, people get around this by using cookies, all those redirector kludges, just clicking on the link again when your transaction fails, etc. But would it be desirable to have that capability architected in? And if so, how to do it in a way that means that things that *don't* want that capability don't wind up paying for it? How you answer this has a big impact on what kinds of namespace(s) you add, etc. E.g. is endpoint-endpoint communication still critical enough that you need a namespace for naming endpoints? 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 Thu Oct 27 08:27:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV6qi-0003hr-Uc; Thu, 27 Oct 2005 08:27:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV6qg-0003hi-Sc for architecture-discuss@megatron.ietf.org; Thu, 27 Oct 2005 08:27:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25799 for ; Thu, 27 Oct 2005 08:26:57 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV742-0000Lf-IQ for architecture-discuss@ietf.org; Thu, 27 Oct 2005 08:41:03 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 27 Oct 2005 05:27:04 -0700 X-IronPort-AV: i="3.97,258,1125903600"; d="scan'208"; a="669760564:sNHT25173156" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9RCR1Jh006841; Thu, 27 Oct 2005 05:27:02 -0700 (PDT) Received: from [10.255.65.166] (sjc-vpn6-319.cisco.com [10.21.121.63]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j9RCatB5022115; Thu, 27 Oct 2005 05:36:56 -0700 In-Reply-To: <6.2.3.4.2.20051027033350.06775490@mail.jefsey.com> References: <435FFA7B.50903@thinkingcat.com> <6.2.3.4.2.20051027033350.06775490@mail.jefsey.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <633E9D5B-1DB2-4ED0-BD12-332861B08776@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [Architecture-discuss] small suggestion Date: Thu, 27 Oct 2005 08:26:58 -0400 To: "JFC (Jefsey) Morfin" X-Mailer: Apple Mail (2.734) DKIM-Signature: a=rsa-sha1; q=dns; l=627; t=1130416616; x=1130848816; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:Re=3A=20[Architecture-discuss]=20small=20suggestion=20| From:Fred=20Baker=20| Date:Thu,=2027=20Oct=202005=2008=3A26=3A58=20-0400| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=jI/zSXjxZOWWQpg8QSudFuj83APeNuK+7H1PGRtEGc4f80ZAShJmF+yXbsWR6RsYhJwMPBev 34ozWQ8Is4YEU7GHlbYRfXVkA+AbrfHfv/Ev8I1RGcilplBlp4XA6ZZIGTac9hHG6YRCiavHsLW KDKAD9kQsoRmgOlFEoC2dBAc= Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org Without gainsaying anything you said, I'd like to know more specifically what you're looking for. What problems would you like to see solved, and what are the "usage architecture" issues that affect the solutions? On Oct 26, 2005, at 10:15 PM, JFC (Jefsey) Morfin wrote: > this new mailing list is a new exercise. May I suggest an initial > suggestion and explain my - often controverted approach? I am > interested in usage architecture. I am not much concerned therefore > by layers 1-7, but I learned over Tymnet, OSI, Internet that the > architectural culture has a dramatic simplification impact on usage > architecture. This is why I need global consistency and quality of > the IETF deliverables. And I am excited by this list. I see two > main needs: > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Oct 27 08:58:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV7L7-0004ph-5e; Thu, 27 Oct 2005 08:58:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV7L5-0004pa-2O for architecture-discuss@megatron.ietf.org; Thu, 27 Oct 2005 08:58:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27301 for ; Thu, 27 Oct 2005 08:58:23 -0400 (EDT) Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV7YQ-00015Y-El for architecture-discuss@ietf.org; Thu, 27 Oct 2005 09:12:28 -0400 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 8FB1C19C; Thu, 27 Oct 2005 18:58:11 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Oct 2005 08:58:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Architecture-discuss] Mobility and multi-homing Date: Thu, 27 Oct 2005 08:58:18 -0400 Message-ID: <936A4045C332714F975800409DE09240013881E9@tayexc14.americas.cpqcorp.net> Thread-Topic: [Architecture-discuss] Mobility and multi-homing Thread-Index: AcXa8X4pIqywuiHRTvG2ks5BRP5vZgAA2QYg From: "Bound, Jim" To: "Noel Chiappa" , X-OriginalArrivalTime: 27 Oct 2005 12:58:21.0180 (UTC) FILETIME=[1BB84BC0:01C5DAF6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org I agree with Noel's discussion and input in this case. One point below I strongly agree with and will comment as I know it will come up.=20 >=20 > > What about using HIP with routable IP addresses instead of Host > > Identity Tags (HITs) as Upper Layer Identifiers? >=20 > Oh, yes, let's try a *different* way of fitting the=20 > proverbial 10 pounds into > the 5 pound sack. Maybe this time it will work! This is very true and also the architecture change from engineering implementation is very significant to the entire IP stack and network utility applications to that stack (e.g. DNS, TCPDUMP, PMTUD). But, I believe two important principles have been maintained with this suggestion, and important to this discussion: keep the intelligence required at the ends and at a minimum within the network, and maintain the principles of end-to-end. These tenets for mobility and multihoming, and the need for guaranteed QoS for tomorrow. /jim > -----Original Message----- > From: architecture-discuss-bounces@ietf.org=20 > [mailto:architecture-discuss-bounces@ietf.org] On Behalf Of=20 > Noel Chiappa > Sent: Thursday, October 27, 2005 8:24 AM > To: architecture-discuss@ietf.org > Cc: jnc@mercury.lcs.mit.edu > Subject: Re: [Architecture-discuss] Mobility and multi-homing >=20 > > From: Leslie Daigle >=20 > > The IETF currently hosts a bunch of working groups=20 > focusing on various > > aspects of mobility and multi homing. >=20 > >From an architectural perspective, any attempt to provide=20 > such capabilities, > when the underlying architecture isn't rich enough in > namespaces/mechanisms/etc to do so in a clean way, will=20 > result in ugly "bags > on the side" which just accelerate the death of the existing=20 > system through > feature-cancer (of which your long list of WG's, etc is a=20 > perfect example). >=20 > The alternative, a genuine architectural re-think and resulting > restructuring, is something that long and painful experience=20 > has shown is not > very palatable to the IETF community - my sense is that the=20 > costs have always > seemed too high to most. Maybe the community is more ready=20 > now to pay the > price (bearing in mind the old adage that you generally get=20 > what you pay for > - and when you pay $0 for better architecture, you don't get=20 > any better > architecture), but at this point my optimism is pretty worn out. >=20 > I don't have any good solution to this. I think in=20 > engineering terms, I think > the NSRG concept of designing a new namespace, and deploying it one > application and/or transport layer at a time, was the best=20 > one. (Efforts like > NewArch which involve "forklift" upgrades to the entire stack=20 > are interesting > - and necessary - academic exercises, but aren't practical=20 > models for how to > upgrade the engines in flight.) However, two problems. >=20 > One, I don't have a good concept of how to make it happen=20 > organizationally - > either i) to make disparate groups adhere to the concept, or=20 > ii) provide the > drive to make it happen. Two, even then you have to accept=20 > that lots of > legacy "stuff" (protocols, boxes, etc) won't be able to=20 > utilize those new > capabilities. >=20 >=20 > > what would be the right way or right ways forward?=20 > Could we design a > > way towards converging solutions? How do we ensure robustness of > > solutions if we attempt to deploy multiple solutions at=20 > the same time >=20 > There is no substitute for an overall vision of where you=20 > want to wind up, in > terms of architecture. Without that, engineering efforts will=20 > head off in > disparate, unconnected, directions. >=20 > Once you have such a vision (in terms of namespaces,=20 > mechanisms, etc) then > you have a defined toolbox that all efforts use in common, which will > automatically create coherence, etc. >=20 >=20 > > What about using HIP with routable IP addresses instead of Host > > Identity Tags (HITs) as Upper Layer Identifiers? >=20 > Oh, yes, let's try a *different* way of fitting the=20 > proverbial 10 pounds into > the 5 pound sack. Maybe this time it will work! >=20 > I assume I need say no more about this idea, which frankly should have > instantly triggered the bogometer of anyone subscribed to an=20 > "architecture" > list... >=20 >=20 > > Going a little bit furthermore, what are the=20 > architectural impacts of > > doing mobility and multi-homing at the IP layer vs.=20 > other layers? >=20 > Well, that's an interesting question. >=20 > First, I'm going to back you up and recast what you said as "are > architectural features used to support mobility and=20 > multi-homing resident at > the IP layer, or other layers?" To an architect, mobility and=20 > multi-homing > are *applications* - we merely supply *tools* that other=20 > people can use to > design things that procide them. >=20 > I think it's clear that such support has to happen above the=20 > "deliver a > packet from this interface to that interface" layer. Whether=20 > one integrates > all - or part - of it with tranports, or makes some of it a=20 > separate shim > (which one might notionally think of as part of the=20 > internetwork layer, > although in reality it would be a separate sub-layer above=20 > the "deliver a > packet from this interface to that interface" stuff) is a=20 > useful question. In > a perfect world, I'd go for the shim, but in the real world,=20 > where the plane > is flying, maybe you have to bundle it with transports. >=20 >=20 > Actually, the question I wound up pondering was whether the=20 > old TCP model of > "endpoint to endpoint" was the way to go, or whether we=20 > needed some richer > model in which you were talking to a pool of servers, so that=20 > things like > load-sharing and failover popped out as well-supported by the=20 > basic transport. >=20 > Right now, with the Web, people get around this by using=20 > cookies, all those > redirector kludges, just clicking on the link again when your=20 > transaction > fails, etc. >=20 > But would it be desirable to have that capability architected=20 > in? And if so, > how to do it in a way that means that things that *don't* want that > capability don't wind up paying for it? >=20 > How you answer this has a big impact on what kinds of=20 > namespace(s) you add, > etc. E.g. is endpoint-endpoint communication still critical=20 > enough that you > need a namespace for naming endpoints? 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 Thu Oct 27 09:07:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV7TR-00018J-8q; Thu, 27 Oct 2005 09:07:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV7TQ-000180-7g for architecture-discuss@megatron.ietf.org; Thu, 27 Oct 2005 09:07:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27740 for ; Thu, 27 Oct 2005 09:07:00 -0400 (EDT) Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV7gk-0001Js-E2 for architecture-discuss@ietf.org; Thu, 27 Oct 2005 09:21:05 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 7172226C103; Thu, 27 Oct 2005 15:06:51 +0200 (CEST) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 44E1E26C0FE; Thu, 27 Oct 2005 15:06:50 +0200 (CEST) Received: from batilda.nic.fr (postfix@batilda.nic.fr [192.134.4.69]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id j9RD6oYa851667; Thu, 27 Oct 2005 15:06:50 +0200 (CEST) Received: by batilda.nic.fr (Postfix, from userid 1000) id 29EFF16A9F2; Thu, 27 Oct 2005 15:06:50 +0200 (CEST) Date: Thu, 27 Oct 2005 15:06:50 +0200 From: Stephane Bortzmeyer To: Fred Baker Message-ID: <20051027130650.GA12556@nic.fr> References: <435FFA7B.50903@thinkingcat.com> <6.2.3.4.2.20051027033350.06775490@mail.jefsey.com> <633E9D5B-1DB2-4ED0-BD12-332861B08776@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <633E9D5B-1DB2-4ED0-BD12-332861B08776@cisco.com> X-Operating-System: Debian GNU/Linux 3.1 X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at mx2.nic.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: architecture-discuss@ietf.org Subject: [Architecture-discuss] Re: small suggestion X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org On Thu, Oct 27, 2005 at 08:26:58AM -0400, Fred Baker wrote a message of 21 lines which said: > Without gainsaying anything you said, I'd like to know more > specifically what you're looking for. Sine it is difficult to find a mailing list where Jefsey Morfin does not send ten messages a day, I suggest at least not to answer him for the reasons explained here: http://www.alvestrand.no/ietf/jefsey-pr-action.php _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Oct 27 11:29:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV9hX-0006Lr-LC; Thu, 27 Oct 2005 11:29:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV9hV-0006Ja-ON for architecture-discuss@megatron.ietf.org; Thu, 27 Oct 2005 11:29:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17408 for ; Thu, 27 Oct 2005 11:29:41 -0400 (EDT) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV9uo-0001Eu-Kw for architecture-discuss@ietf.org; Thu, 27 Oct 2005 11:43:47 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id KAA29635; Thu, 27 Oct 2005 10:29:30 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j9RFTUY04097; Thu, 27 Oct 2005 10:29:30 -0500 (CDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Oct 2005 08:29:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Architecture-discuss] Mobility and multi-homing Date: Thu, 27 Oct 2005 08:29:23 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6DC9E4F8@XCH-NW-5V1.nw.nos.boeing.com> Thread-Topic: [Architecture-discuss] Mobility and multi-homing Thread-Index: AcXa8XjdsQ9D+YQ2ROyv5w75TBX1bgAGJU9g From: "Henderson, Thomas R" To: "Noel Chiappa" , X-OriginalArrivalTime: 27 Oct 2005 15:29:24.0743 (UTC) FILETIME=[36064170:01C5DB0B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org =20 > -----Original Message----- > From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu]=20 > Sent: Thursday, October 27, 2005 5:24 AM > To: architecture-discuss@ietf.org > Cc: jnc@mercury.lcs.mit.edu > Subject: Re: [Architecture-discuss] Mobility and multi-homing >=20 >=20 > I don't have any good solution to this. I think in=20 > engineering terms, I think the NSRG concept of designing a=20 > new namespace, and deploying it one application and/or=20 > transport layer at a time, was the best one. (Efforts like=20 > NewArch which involve "forklift" upgrades to the entire stack=20 > are interesting > - and necessary - academic exercises, but aren't practical=20 > models for how to upgrade the engines in flight.) However,=20 > two problems. >=20 > One, I don't have a good concept of how to make it happen=20 > organizationally - either i) to make disparate groups adhere=20 > to the concept, or ii) provide the drive to make it happen.=20 > Two, even then you have to accept that lots of legacy "stuff"=20 > (protocols, boxes, etc) won't be able to utilize those new=20 > capabilities. >=20 >=20 > > What about using HIP with routable IP addresses instead of Host > > Identity Tags (HITs) as Upper Layer Identifiers? >=20 > Oh, yes, let's try a *different* way of fitting the=20 > proverbial 10 pounds into the 5 pound sack. Maybe this time=20 > it will work! >=20 > I assume I need say no more about this idea, which frankly=20 > should have instantly triggered the bogometer of anyone=20 > subscribed to an "architecture" > list... >=20 I think you are mistaking the above HIP idea as an architectural suggestion rather than as a deployment hack. Rather, it seems to me to support what you argued for in the above-- don't deploy a forklift upgrade to the whole stack. Tom _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Oct 27 11:36:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV9o1-0002tE-0O; Thu, 27 Oct 2005 11:36:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV9nz-0002sb-Ik for architecture-discuss@megatron.ietf.org; Thu, 27 Oct 2005 11:36:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20598 for ; Thu, 27 Oct 2005 11:36:22 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVA1J-0002UA-3f for architecture-discuss@ietf.org; Thu, 27 Oct 2005 11:50:27 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id j9RFmL1Q024570; Thu, 27 Oct 2005 08:48:25 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr01.mot.com (8.13.1/8.13.0) with ESMTP id j9RFkMeF018967; Thu, 27 Oct 2005 10:46:23 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 123CC865980; Thu, 27 Oct 2005 17:36:23 +0200 (CEST) Message-ID: <4360F3F6.4060006@motorola.com> Date: Thu, 27 Oct 2005 17:36:22 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: Leslie Daigle Subject: Re: NETLMM and dumb network (was: [Architecture-discuss] Mobility and multi-homing) References: <435FF9DE.1060205@thinkingcat.com> In-Reply-To: <435FF9DE.1060205@thinkingcat.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org [Why forwarding only Pekka's emails? There are plenty discussions happening in the mobility related working groups often founded by "don't do it this way because its not architecturally sound", or "this other thing _is_ architecturally sound". Following is some doubts I have, and my architecture knowledge is a beginner's.] Leslie Daigle wrote: > [Tap tap tap -- "is this thing on?" ;-) I'm forwarding Pekka > Nikander's suggested topic-starters, one at a time, to see if we can > get some "discuss" going, about "architecture". -- LLD] > > [Pekka wrote:] 1. Mobility and multi-homing > > The IETF currently hosts a bunch of working groups focusing on > various aspects of mobility and multi homing. At the Internet Area, > there are five WGs and a couple of almost-WGs charted for standards > track work: MIP4, MIP6, NEMO, SHIM6, MONAMI6, and NETLMM. NETLMM and dumb network. In netlmm there's a proposal to manage host mobility entirely by the network, in that a small network changes its state dynamically such as to update paths towards a moving host, which keeps its address stable, doesn't change it. Or, the network was supposed to be dumb. But, architecture is applied differently in different contexts, too. So, how would an Internet architect critique this aspect? Alex _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Oct 27 12:57:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVB44-0002vg-8W; Thu, 27 Oct 2005 12:57:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVB42-0002va-UF for architecture-discuss@megatron.ietf.org; Thu, 27 Oct 2005 12:57:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15299 for ; Thu, 27 Oct 2005 12:57:02 -0400 (EDT) Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVBHQ-0003hu-Pq for architecture-discuss@ietf.org; Thu, 27 Oct 2005 13:11:10 -0400 Received: from 201.sub-70-209-62.myvzw.com (201.sub-70-209-62.myvzw.com [70.209.62.201]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9RGuKn28888; Thu, 27 Oct 2005 09:56:21 -0700 (PDT) Date: Thu, 27 Oct 2005 09:56:14 -0700 From: Aaron Falk To: Noel Chiappa Subject: Re: [Architecture-discuss] Mobility and multi-homing Message-ID: <781BF33CC9B5A9C7506B2426@nak.isi.edu> In-Reply-To: <20051027122404.F31AA86AEE@mercury.lcs.mit.edu> References: <20051027122404.F31AA86AEE@mercury.lcs.mit.edu> X-Mailer: Mulberry/4.0.4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: falk@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org --On October 27, 2005 8:24:04 AM -0400 Noel Chiappa wrote: > > Actually, the question I wound up pondering was whether the old TCP model > of "endpoint to endpoint" was the way to go, or whether we needed some > richer model in which you were talking to a pool of servers, so that > things like load-sharing and failover popped out as well-supported by the > basic transport. > > Right now, with the Web, people get around this by using cookies, all > those redirector kludges, just clicking on the link again when your > transaction fails, etc. > > But would it be desirable to have that capability architected in? And if > so, how to do it in a way that means that things that *don't* want that > capability don't wind up paying for it? > > How you answer this has a big impact on what kinds of namespace(s) you > add, etc. E.g. is endpoint-endpoint communication still critical enough > that you need a namespace for naming endpoints? Etc, etc... Noel- I just want to observe that you have enlarged the scope of the question from changing the architecture to fix something that is broken (maintaining transport connections when an endpoint moves from one network to another) to include fixing something that doesn't seem broken (maintaining transport connection when an endpoint moves from one host to anther within a network). Does the latter seem like it needs fixing to you? Or are you motivated by a desire for a cleaner architecture? Your comment that the plane is flying is important and I'm loath to change engines just because the current one needs a paint job. regards, --aaron _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Oct 27 13:06:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVBCq-0005iz-I5; Thu, 27 Oct 2005 13:06:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVBCl-0005iC-TN for architecture-discuss@megatron.ietf.org; Thu, 27 Oct 2005 13:06:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15943 for ; Thu, 27 Oct 2005 13:06:03 -0400 (EDT) Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVBQ9-00041z-NN for architecture-discuss@ietf.org; Thu, 27 Oct 2005 13:20:11 -0400 Received: from 201.sub-70-209-62.myvzw.com (201.sub-70-209-62.myvzw.com [70.209.62.201]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9RH5Vn01136; Thu, 27 Oct 2005 10:05:31 -0700 (PDT) Date: Thu, 27 Oct 2005 10:05:24 -0700 From: Aaron Falk To: Pekka Nikander Subject: Re: [Architecture-discuss] IP virtualisation Message-ID: <62773DFEBB4D27AE03BE2F67@nak.isi.edu> In-Reply-To: <435FFA3F.1060309@thinkingcat.com> References: <435FFA3F.1060309@thinkingcat.com> X-Mailer: Mulberry/4.0.4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: falk@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org --On October 26, 2005 5:50:55 PM -0400 Leslie Daigle wrote: > > [Pekka wrote:] > Tunnelling has well known > drawbacks, and we may want to ask what would be the alternatives. Pekka- In the interest of motivating the need for a fresh look at IP virtualization, would you mind summarizing what you see as the 'well-known drawbacks' of tunneling? Folks on this list may not have been part of the Internet area discussion on the topic and, even so, I don't recall coming away from it with a clear understanding of tunneling's shortcomings. regards, --aaron _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Oct 27 13:38:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVBht-0008NN-US; Thu, 27 Oct 2005 13:38:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVBhs-0008Kk-CC for architecture-discuss@megatron.ietf.org; Thu, 27 Oct 2005 13:38:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17863 for ; Thu, 27 Oct 2005 13:38:10 -0400 (EDT) Received: from portola.portolanetworks.tv ([66.121.157.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVBvF-00054A-SH for architecture-discuss@ietf.org; Thu, 27 Oct 2005 13:52:19 -0400 Received: from [192.168.2.22] ([66.121.157.194]) by portola.portolanetworks.tv with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Oct 2005 10:33:32 -0700 In-Reply-To: <62773DFEBB4D27AE03BE2F67@nak.isi.edu> References: <435FFA3F.1060309@thinkingcat.com> <62773DFEBB4D27AE03BE2F67@nak.isi.edu> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Architecture-discuss] IP virtualisation Date: Thu, 27 Oct 2005 10:38:01 -0700 To: Aaron Falk X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 27 Oct 2005 17:33:32.0453 (UTC) FILETIME=[8D349D50:01C5DB1C] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit 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: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org > In the interest of motivating the need for a fresh look at IP > virtualization, would you mind summarizing what you see as the > 'well-known drawbacks' of tunneling? Folks on this list may not > have been part of the Internet area discussion on the topic and, > even so, I don't recall coming away from it with a clear > understanding of tunneling's shortcomings. Issues: 1) MTU - Tunneling overhead may break the link level PMTU. Does the tunnel fragment and reassemble? 2) Overhead - The tunnel always incurs some level of additional wrapper as overhead and thus consumes bandwidth. 3) Transparency - Tunneling creates an issue for firewalls, as unintended traffic can be tunneled around the policy control points. Speaking architecturally, tunneling is necessarily a second class solution to any problem. That's not to say that it's without value, rather that when we have to resort to tunneling, we're kludging and hacking and thus should be thinking about how to perform whatever functionality we're trying to achieve in a native manner, if at all possible. Tony p.s. Please refer to RFC 1701 before flaming me. ;-) _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Oct 27 13:52:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVBv2-0004A3-Rn; Thu, 27 Oct 2005 13:52:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVBv1-00049a-7d for architecture-discuss@megatron.ietf.org; Thu, 27 Oct 2005 13:52:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18455 for ; Thu, 27 Oct 2005 13:51:44 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVC8N-0005Re-IN for architecture-discuss@ietf.org; Thu, 27 Oct 2005 14:05:52 -0400 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j9RHpvD7007610 for ; Thu, 27 Oct 2005 11:51:58 -0600 (MDT) Received: from kebe.east.sun.com (kebe.East.Sun.COM [129.148.174.48]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j9RHpvH0020276 for ; Thu, 27 Oct 2005 13:51:57 -0400 (EDT) Received: from kebe.east.sun.com (localhost [127.0.0.1]) by kebe.east.sun.com (8.13.5+Sun/8.13.5) with ESMTP id j9RHpuF8025773; Thu, 27 Oct 2005 13:51:56 -0400 (EDT) Received: (from danmcd@localhost) by kebe.east.sun.com (8.13.5+Sun/8.13.5/Submit) id j9RHpurS025772; Thu, 27 Oct 2005 13:51:56 -0400 (EDT) Date: Thu, 27 Oct 2005 13:51:56 -0400 From: Dan McDonald To: Tony Li Subject: Re: [Architecture-discuss] IP virtualisation Message-ID: <20051027175156.GJ25525@kebe.East.Sun.COM> References: <435FFA3F.1060309@thinkingcat.com> <62773DFEBB4D27AE03BE2F67@nak.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Organization: Sun Microsystems, Inc. - Solaris Networking & Security X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org On Thu, Oct 27, 2005 at 10:38:01AM -0700, Tony Li wrote: > > Issues: > > 1) MTU - Tunneling overhead may break the link level PMTU. Does the > tunnel fragment and reassemble? > > 2) Overhead - The tunnel always incurs some level of additional > wrapper as overhead and thus consumes bandwidth. > > 3) Transparency - Tunneling creates an issue for firewalls, as > unintended traffic can be tunneled around the policy control points. I will admit my bias up front: IMHO IP-in-IP tunnels should be just another link layer choice for IP, and should look-and-feel just like any other network interface. My own experiences with your tunneling issues are (given my biases): 1 -- A network interface of type IP-in-IP reflects back a (link - overhead) MTU. It can even do this dynamically per-destination using existing PathMTU discovery techniques. (You may lose that first large packet when the lower IP discovers something new, but hey, it's IP.) 2 -- Yes, that is always a bandwidth issue. It's also a latency issue, especially if any additional transformations ( IPsec ) are performed on the packet. 3 -- If your firewall allows a class of traffic to pass, there is no (practical) way to control how users {,ab}use that class of traffic. Speaking of firewalls... > Speaking architecturally, tunneling is necessarily a second class > solution to any problem. That's not to say that it's without value, > rather that when we have to resort to tunneling, we're kludging and > hacking and thus should be thinking about how to perform whatever > functionality we're trying to achieve in a native manner, if at all > possible. I believe performing: s/tunneling/firewalling/g to your above paragraph yields additional valuable input for this list. :) Dan _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Oct 27 14:01:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVC4O-0006C8-CP; Thu, 27 Oct 2005 14:01:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVC4M-0006Bq-97 for architecture-discuss@megatron.ietf.org; Thu, 27 Oct 2005 14:01:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19088 for ; Thu, 27 Oct 2005 14:01:25 -0400 (EDT) Received: from portola.portolanetworks.tv ([66.121.157.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVCHk-0005jz-7X for architecture-discuss@ietf.org; Thu, 27 Oct 2005 14:15:33 -0400 Received: from [192.168.2.22] ([66.121.157.194]) by portola.portolanetworks.tv with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Oct 2005 10:56:55 -0700 In-Reply-To: <20051027122404.F31AA86AEE@mercury.lcs.mit.edu> References: <20051027122404.F31AA86AEE@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Architecture-discuss] Mobility and multi-homing Date: Thu, 27 Oct 2005 11:01:24 -0700 To: Noel Chiappa X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 27 Oct 2005 17:56:55.0890 (UTC) FILETIME=[D1B81B20:01C5DB1F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org > One, I don't have a good concept of how to make it happen > organizationally - > either i) to make disparate groups adhere to the concept, or ii) > provide the > drive to make it happen. I want to amplify this point: For the IETF to do any kind of *effective* changes to the architecture, there must be architectural control at some point in the organization. Prior to Kobe, it was the old boys network, as instantiated by the IAB. Post Kobe, there seems to be a unfillable vacuum in architectural leadership. To make significant architectural progress in *any* direction, we need to first resolve the question of who is providing this leadership and under what authorization. The basic premise of the post-Kobe debacle is that the IAB does not have the authority to make architectural decisions that are at odds with popular opinion. Until something happens to alter that premise, we will continue to run in circles. Regards, Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Oct 27 14:16:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVCJ0-00031D-DU; Thu, 27 Oct 2005 14:16:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVCIy-0002y1-9T for architecture-discuss@megatron.ietf.org; Thu, 27 Oct 2005 14:16:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20172 for ; Thu, 27 Oct 2005 14:16:31 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVCWM-0006GH-1G for architecture-discuss@ietf.org; Thu, 27 Oct 2005 14:30:40 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 27 Oct 2005 14:16:32 -0400 X-IronPort-AV: i="3.97,259,1125892800"; d="scan'208"; a="74570140:sNHT25504508" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9RIGQ25003112; Thu, 27 Oct 2005 14:16:29 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Oct 2005 14:16:27 -0400 Received: from cisco.com ([10.86.240.194]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Oct 2005 14:16:26 -0400 Date: Thu, 27 Oct 2005 14:15:25 -0400 From: Scott W Brim To: Tony Li Subject: Re: [Architecture-discuss] IP virtualisation Message-ID: <20051027181525.GH5992@sbrim-wxp01> References: <435FFA3F.1060309@thinkingcat.com> <62773DFEBB4D27AE03BE2F67@nak.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 27 Oct 2005 18:16:26.0763 (UTC) FILETIME=[8B9D25B0:01C5DB22] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Pekka Nikander , Aaron Falk , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org On Thu, Oct 27, 2005 10:38:01AM -0700, Tony Li allegedly wrote: > Speaking architecturally, tunneling is necessarily a second class > solution to any problem. That's not to say that it's without value, > rather that when we have to resort to tunneling, we're kludging and > hacking and thus should be thinking about how to perform whatever > functionality we're trying to achieve in a native manner, if at all > possible. I used to think exactly that before you yourself convinced me otherwise. We can have One Universal Solution to all problems, but in order to handle all needs, that OUS can become very complex (a VCOUS). Your system can be simpler in the aggregate, and significantly more robust, if you allow two parallel solutions -- in this case one for the general Internet case and another for special cases. For example, consider QoS-based routing and the superstructure for EF, versus using tunnels for the traffic that needs special treatment. swb _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Oct 27 14:50:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVCpx-00013i-Lp; Thu, 27 Oct 2005 14:50:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVCpw-00013d-1e for architecture-discuss@megatron.ietf.org; Thu, 27 Oct 2005 14:50:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22208 for ; Thu, 27 Oct 2005 14:50:34 -0400 (EDT) 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 1EVD3J-0007GR-4I for architecture-discuss@ietf.org; Thu, 27 Oct 2005 15:04:44 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 27 Oct 2005 11:50:40 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9RIoSJn012297; Thu, 27 Oct 2005 11:50:37 -0700 (PDT) Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Oct 2005 14:50:36 -0400 Received: from 10.21.96.247 ([10.21.96.247]) by xmb-rtp-205.amer.cisco.com ([64.102.31.59]) via Exchange Front-End Server email.cisco.com ([171.70.151.174]) with Microsoft Exchange Server HTTP-DAV ; Thu, 27 Oct 2005 18:50:36 +0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 27 Oct 2005 14:50:34 -0400 Subject: Re: [Architecture-discuss] IP virtualisation From: Melinda Shore To: Tony Li Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 27 Oct 2005 18:50:36.0596 (UTC) FILETIME=[5168D740:01C5DB27] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org On 10/27/05 1:38 PM, "Tony Li" wrote: > 3) Transparency - Tunneling creates an issue for firewalls, as > unintended traffic can be tunneled around the policy control points. I'm a little sympathetic to that argument but not a lot sympathetic. I think what you're describing is a more general problem, that the destination address in the IP header no longer represents the endpoint and various things flow from that when we're using the address as basically a proxy for identity and therefore for policy enforcements of various types (including routing). However, saying that it's a problem because the address is concealed from the firewall is an argument that can be used against encryption, as well, and in fact has been used against encryption. But it seems to me that there's another question here about how much information needs to be exposed for basic network functions to work. Melinda _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Oct 27 14:52:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVCrB-0001e6-HR; Thu, 27 Oct 2005 14:52:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVCr9-0001cx-SP for architecture-discuss@megatron.ietf.org; Thu, 27 Oct 2005 14:52:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22238 for ; Thu, 27 Oct 2005 14:51:50 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVD4Y-0007J5-V0 for architecture-discuss@ietf.org; Thu, 27 Oct 2005 15:06:00 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 27 Oct 2005 11:51:57 -0700 Received: from cisco.com (dino-lnx.cisco.com [171.71.54.55]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j9RIpq8k000378; Thu, 27 Oct 2005 11:51:53 -0700 (PDT) Received: from dino-lnx.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j9RIptUj019285; Thu, 27 Oct 2005 11:51:55 -0700 Received: (from dino@localhost) by dino-lnx.cisco.com (8.12.11/8.12.11/Submit) id j9RIpthR019281; Thu, 27 Oct 2005 11:51:55 -0700 Date: Thu, 27 Oct 2005 11:51:55 -0700 Message-Id: <200510271851.j9RIpthR019281@dino-lnx.cisco.com> From: Dino Farinacci To: sbrim@cisco.com In-reply-to: <20051027181525.GH5992@sbrim-wxp01> (message from Scott W Brim on Thu, 27 Oct 2005 14:15:25 -0400) Subject: Re: [Architecture-discuss] IP virtualisation References: <435FFA3F.1060309@thinkingcat.com> <62773DFEBB4D27AE03BE2F67@nak.isi.edu> <20051027181525.GH5992@sbrim-wxp01> X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: pekka.nikander@nomadiclab.com, falk@ISI.EDU, architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org Just joined the list. Sorry for coming in late. >> On Thu, Oct 27, 2005 10:38:01AM -0700, Tony Li allegedly wrote: >> > Speaking architecturally, tunneling is necessarily a second class >> > solution to any problem. That's not to say that it's without value, >> > rather that when we have to resort to tunneling, we're kludging and >> > hacking and thus should be thinking about how to perform whatever >> > functionality we're trying to achieve in a native manner, if at all >> > possible. >> >> I used to think exactly that before you yourself convinced me >> otherwise. Since tunneling allows transparency in the core, that would seem to be a fairly robust architectural principle with lots of value. Or would most think the transparency is a bug and not a feature? And I would argue a lot of application value has come to us over the years because of "application-level tunneling" where if the infrastructure would have had to be upgraded to do these things, we may have less cool new apps these days. Dino _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Oct 27 15:27:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVDPQ-0000UA-04; Thu, 27 Oct 2005 15:27:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVDPO-0000St-MZ for architecture-discuss@megatron.ietf.org; Thu, 27 Oct 2005 15:27:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24088 for ; Thu, 27 Oct 2005 15:27:15 -0400 (EDT) Received: from portola.portolanetworks.tv ([66.121.157.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVDcl-0008Hn-Nx for architecture-discuss@ietf.org; Thu, 27 Oct 2005 15:41:23 -0400 Received: from [192.168.2.22] ([66.121.157.194]) by portola.portolanetworks.tv with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Oct 2005 12:22:38 -0700 In-Reply-To: <200510271851.j9RIpthR019281@dino-lnx.cisco.com> References: <435FFA3F.1060309@thinkingcat.com> <62773DFEBB4D27AE03BE2F67@nak.isi.edu> <20051027181525.GH5992@sbrim-wxp01> <200510271851.j9RIpthR019281@dino-lnx.cisco.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4FAA9E49-366C-41C6-8B51-8C05AA128FF4@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Architecture-discuss] IP virtualisation Date: Thu, 27 Oct 2005 12:27:07 -0700 To: Dino Farinacci X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 27 Oct 2005 19:22:38.0453 (UTC) FILETIME=[CAECF250:01C5DB2B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: pekka.nikander@nomadiclab.com, falk@ISI.EDU, architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org Ok, apparently I need to clarify quite a bit. I'm *NOT* dumping on tunneling. I'm not trying to shoot it, kill it or maim it in any way. I *am* trying to get across the perspective that it is not 100% transparent and is always necessarily going to be a second-class citizen in an architecture. If we do want a clean, straightforward architecture, we should retain tunneling for our exceptions, but it should never be our primary mechanism. Hope that's more clear, Tony On Oct 27, 2005, at 11:51 AM, Dino Farinacci wrote: > Just joined the list. Sorry for coming in late. > > >>> On Thu, Oct 27, 2005 10:38:01AM -0700, Tony Li allegedly wrote: >>> >>>> Speaking architecturally, tunneling is necessarily a second class >>>> solution to any problem. That's not to say that it's without >>>> value, >>>> rather that when we have to resort to tunneling, we're kludging and >>>> hacking and thus should be thinking about how to perform whatever >>>> functionality we're trying to achieve in a native manner, if at all >>>> possible. >>>> >>> >>> I used to think exactly that before you yourself convinced me >>> otherwise. >>> > > Since tunneling allows transparency in the core, that would > seem to be > a fairly robust architectural principle with lots of value. > > Or would most think the transparency is a bug and not a feature? > > And I would argue a lot of application value has come to us > over the years > because of "application-level tunneling" where if the > infrastructure > would have had to be upgraded to do these things, we may have > less cool > new apps these days. > > Dino > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Oct 27 16:59:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVEqg-0000GN-KQ; Thu, 27 Oct 2005 16:59:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVEqf-0000GI-IY for architecture-discuss@megatron.ietf.org; Thu, 27 Oct 2005 16:59:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17019 for ; Thu, 27 Oct 2005 16:59:29 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVF42-0000ah-Jk for architecture-discuss@ietf.org; Thu, 27 Oct 2005 17:13:38 -0400 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j9RKxddK023425; Thu, 27 Oct 2005 13:59:39 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j9RKxcH0025068; Thu, 27 Oct 2005 16:59:38 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j9RKxcHr002360; Thu, 27 Oct 2005 16:59:38 -0400 (EDT) Subject: Re: [Architecture-discuss] IP virtualisation From: Bill Sommerfeld To: Tony Li In-Reply-To: References: <435FFA3F.1060309@thinkingcat.com> <62773DFEBB4D27AE03BE2F67@nak.isi.edu> Content-Type: text/plain; charset=iso-8859-1 Message-Id: <1130446777.1347.428.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.323 Date: Thu, 27 Oct 2005 16:59:38 -0400 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: Pekka Nikander , Aaron Falk , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org On Thu, 2005-10-27 at 13:38, Tony Li wrote: > 3) Transparency - Tunneling creates an issue for firewalls, as > unintended traffic can be tunneled around the policy control points. And firewalls will most likely always be on the losing end of this battle. For the most part, any pair of consenting parties separated by a "toll booth" firewall can invent a tunneling protocol which looks like innocuous traffic, allowing them to exchange arbitrary traffic regardless of the policy enforced by the firewall. - Bill _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Oct 27 19:03:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVGlz-0000n9-6f; Thu, 27 Oct 2005 19:03:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVGlx-0000mk-He for architecture-discuss@megatron.ietf.org; Thu, 27 Oct 2005 19:03:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24410 for ; Thu, 27 Oct 2005 19:02:44 -0400 (EDT) Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVGzO-0004SM-9q for architecture-discuss@ietf.org; Thu, 27 Oct 2005 19:16:54 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 00C9020001C3; Thu, 27 Oct 2005 19:02:42 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Oct 2005 19:02:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Architecture-discuss] Mobility and multi-homing Date: Thu, 27 Oct 2005 19:02:13 -0400 Message-ID: <936A4045C332714F975800409DE0924001388523@tayexc14.americas.cpqcorp.net> Thread-Topic: [Architecture-discuss] Mobility and multi-homing Thread-Index: AcXbIKKCuSqcB7fFTBe5k88ig62wRQAJ2bQg From: "Bound, Jim" To: "Tony Li" , "Noel Chiappa" X-OriginalArrivalTime: 27 Oct 2005 23:02:14.0634 (UTC) FILETIME=[788A9CA0:01C5DB4A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: quoted-printable Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org I don't agree we need a leader group. It should be a working group or this list and run it similar in fashion to the way we have done IPR. But we need rules of engagement and before all of that or this should exists define exactly=20 "what problem are we solving"? To use a phrase from Aaron I like if all we need is a paint job then lets not change the engine. I personally believe some of the engine needs enhancments. But not where all often go for IP virtualization (ughhh I think that is more than tunnels but no big deal for now), or lets change what the identifier is for transport, but rather some other thoughts: Can guranteed QoS be achieved end-to-end and we have so many views on this and the current work and results from Diff and Int serve are not good enough by themselves, what is the answer?=20 Conventional routing protocols do not work for ad hoc networks and do we need another virtual layer for them in the IP reference model, regardless if they are mobile which to me is orthogonal. 3rd world cultures will skip an entire generation of Internet technology solutions and interoperate in a network environment of total wireless connections with some IX pipes, and Satcom as the dominant routing core, is the IP reference model today ok or does the engine need new parts? I personally think the transport does with re-think beginning with SCTP and SCP-PS. Just thoughts not saying this should be the work, but once we identify the problem a list will be much easier to identify and then how do we work on such things. Just saying well I think I have a problem so I will go hire and build a new architecture team is not wise from an IETF workload witin the community, architecture, and business view. And a good ole boy self-proclaimed elitists is not the answer and the IETF should make very sure that does not happen, it will just be rejected by the new age Internet community, the market, and industry. Been there done that. Also if this should start, out of IETF bodies will show up too like ITU and others. The Internet is far more important to a lot of entities now, than in 1983 or 1991, and a multi-Xillion dollar business and the IETF has not impressed the world regarding time-to-market in several areas. This work would be far different than delivering standards specifications most likely, but maybe not? /jim =20 > -----Original Message----- > From: architecture-discuss-bounces@ietf.org=20 > [mailto:architecture-discuss-bounces@ietf.org] On Behalf Of Tony Li > Sent: Thursday, October 27, 2005 2:01 PM > To: Noel Chiappa > Cc: architecture-discuss@ietf.org > Subject: Re: [Architecture-discuss] Mobility and multi-homing >=20 > > One, I don't have a good concept of how to make it happen =20 > > organizationally - > > either i) to make disparate groups adhere to the concept, or ii) =20 > > provide the > > drive to make it happen. >=20 >=20 > I want to amplify this point: >=20 > For the IETF to do any kind of *effective* changes to the =20 > architecture, there must be architectural control at some point in =20 > the organization. Prior to Kobe, it was the old boys network, as =20 > instantiated by the IAB. Post Kobe, there seems to be a unfillable =20 > vacuum in architectural leadership. To make significant =20 > architectural progress in *any* direction, we need to first resolve =20 > the question of who is providing this leadership and under what =20 > authorization. The basic premise of the post-Kobe debacle is that =20 > the IAB does not have the authority to make architectural decisions =20 > that are at odds with popular opinion. Until something happens to =20 > alter that premise, we will continue to run in circles. >=20 > Regards, > Tony >=20 >=20 >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www1.ietf.org/mailman/listinfo/architecture-discuss >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Oct 27 19:07:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVGqe-0002XR-Tq; Thu, 27 Oct 2005 19:07:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVGqc-0002XM-VX for architecture-discuss@megatron.ietf.org; Thu, 27 Oct 2005 19:07:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25839 for ; Thu, 27 Oct 2005 19:07:34 -0400 (EDT) Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVH44-00051w-6r for architecture-discuss@ietf.org; Thu, 27 Oct 2005 19:21:45 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 07FE820001CC; Thu, 27 Oct 2005 19:07:41 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Oct 2005 19:07:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Architecture-discuss] IP virtualisation Date: Thu, 27 Oct 2005 19:07:08 -0400 Message-ID: <936A4045C332714F975800409DE0924001388527@tayexc14.americas.cpqcorp.net> Thread-Topic: [Architecture-discuss] IP virtualisation Thread-Index: AcXbJ4FKSjNpKuhBQFKColfh6erBPwAIy21w From: "Bound, Jim" To: "Melinda Shore" , "Tony Li" X-OriginalArrivalTime: 27 Oct 2005 23:07:09.0615 (UTC) FILETIME=[285D23F0:01C5DB4B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org But some are supporting and developing next gen nets that will restore end-to-end as a plan and also the data below the IP header in the packet could be encrypted end-to-end and thus as you state all any will see in the path is the header. This affects the entire issue of what is a firewall and does it become a security manager for end-to-end. So I think adding this question to the list at some point may happen. It also makes a statement that those who want to control the Internet by snooping and filtering are basically and potentially out of business for some deployments, unless they find a new means to operate. /jim=20 > -----Original Message----- > From: architecture-discuss-bounces@ietf.org=20 > [mailto:architecture-discuss-bounces@ietf.org] On Behalf Of=20 > Melinda Shore > Sent: Thursday, October 27, 2005 2:51 PM > To: Tony Li > Cc: architecture-discuss@ietf.org > Subject: Re: [Architecture-discuss] IP virtualisation >=20 > On 10/27/05 1:38 PM, "Tony Li" wrote: > > 3) Transparency - Tunneling creates an issue for firewalls, as > > unintended traffic can be tunneled around the policy control points. >=20 > I'm a little sympathetic to that argument but not a lot sympathetic. > I think what you're describing is a more general problem, that the > destination address in the IP header no longer represents the > endpoint and various things flow from that when we're using the > address as basically a proxy for identity and therefore for > policy enforcements of various types (including routing). However, > saying that it's a problem because the address is concealed from > the firewall is an argument that can be used against encryption, as > well, and in fact has been used against encryption. But it seems > to me that there's another question here about how much information > needs to be exposed for basic network functions to work. >=20 > Melinda >=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 Oct 27 19:11:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVGuN-0006Qs-9m; Thu, 27 Oct 2005 19:11:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVGuM-0006MU-6Y for architecture-discuss@megatron.ietf.org; Thu, 27 Oct 2005 19:11:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26049 for ; Thu, 27 Oct 2005 19:11:25 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVH7n-00058E-Du for architecture-discuss@ietf.org; Thu, 27 Oct 2005 19:25:36 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EVGu8-0005rU-HX; Thu, 27 Oct 2005 16:11:28 -0700 Message-Id: <6.2.3.4.2.20051027213526.054ca6d0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Thu, 27 Oct 2005 23:14:54 +0200 To: Fred Baker From: "JFC (Jefsey) Morfin" Subject: Re: [Architecture-discuss] small suggestion In-Reply-To: <633E9D5B-1DB2-4ED0-BD12-332861B08776@cisco.com> References: <435FFA7B.50903@thinkingcat.com> <6.2.3.4.2.20051027033350.06775490@mail.jefsey.com> <633E9D5B-1DB2-4ED0-BD12-332861B08776@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org At 14:26 27/10/2005, Fred Baker wrote: >Without gainsaying anything you said, I'd like to know more >specifically what you're looking for. What problems would you like to >see solved, and what are the "usage architecture" issues that affect >the solutions? Dear Fred, Usage architecture (or name as you want the way users may architecture their own convergent usage of the various technologies) depends from the individual and community demands and on the underlaying architectural propositions. The changes in these underlaying technologies may greatly affect them. I see that solutions affect usage architecture. But obviously considering them may lead the proposition of more adequate solutions what would be great. I am not sure you want to discuss this now: it may concern a lot of aspects (you live for as many years with the IETF approach as I do with that interest). Quoting most might be confused. But I am certainly interested in issues like a better understanding of the edge vs. the end, distributed registries, multilingualism (universalisation vs. internationalisation), samert and universal numbering plans, hybrid solutions, extended networking model, architectural parametering and structuring, reducting option and kludge, information networking, telco rotation, etc. This is not so much architecture, but side aspects would be highly beneficial to us like appeal of charters, state of the art current documentation, jfc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Oct 27 19:14:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVGxA-0007q5-Lc; Thu, 27 Oct 2005 19:14:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVGx9-0007px-4Y for architecture-discuss@megatron.ietf.org; Thu, 27 Oct 2005 19:14:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26160 for ; Thu, 27 Oct 2005 19:14:18 -0400 (EDT) Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVHAa-0005By-9I for architecture-discuss@ietf.org; Thu, 27 Oct 2005 19:28:29 -0400 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id F195920000CF; Thu, 27 Oct 2005 19:14:24 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Oct 2005 19:14:23 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Architecture-discuss] IP virtualisation Date: Thu, 27 Oct 2005 19:14:21 -0400 Message-ID: <936A4045C332714F975800409DE0924001388530@tayexc14.americas.cpqcorp.net> Thread-Topic: [Architecture-discuss] IP virtualisation Thread-Index: AcXbJ6SzozyDUfRsSNWxUwL7ZxDlRgAI9MeQ From: "Bound, Jim" To: "Dino Farinacci" , X-OriginalArrivalTime: 27 Oct 2005 23:14:23.0411 (UTC) FILETIME=[2AED2830:01C5DB4C] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Cc: pekka.nikander@nomadiclab.com, falk@ISI.EDU, architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org To add to Dino's question this gets to the current debate is the intelligence for the network at the app, edge, or within the network or at all three? Service Oriented Architecture (SOA) true believers support control at what we view as the App layer as IP personnel or IETF people. Intense debate goiung on in industry and other bodies. Serious and obvious vendor agendas appear immediately too and will probably here too, as vendors try to expand there markets into other vendors territory. But, I hope not. Are we about to open pandora's box and should we stop now? It could get very ugly. /jim=20 > -----Original Message----- > From: architecture-discuss-bounces@ietf.org=20 > [mailto:architecture-discuss-bounces@ietf.org] On Behalf Of=20 > Dino Farinacci > Sent: Thursday, October 27, 2005 2:52 PM > To: sbrim@cisco.com > Cc: pekka.nikander@nomadiclab.com; falk@ISI.EDU;=20 > architecture-discuss@ietf.org > Subject: Re: [Architecture-discuss] IP virtualisation >=20 > Just joined the list. Sorry for coming in late. >=20 > >> On Thu, Oct 27, 2005 10:38:01AM -0700, Tony Li allegedly wrote: > >> > Speaking architecturally, tunneling is necessarily a=20 > second class =20 > >> > solution to any problem. That's not to say that it's=20 > without value, =20 > >> > rather that when we have to resort to tunneling, we're=20 > kludging and =20 > >> > hacking and thus should be thinking about how to perform=20 > whatever =20 > >> > functionality we're trying to achieve in a native=20 > manner, if at all =20 > >> > possible. > >>=20 > >> I used to think exactly that before you yourself convinced me > >> otherwise. >=20 > Since tunneling allows transparency in the core, that=20 > would seem to be > a fairly robust architectural principle with lots of value.=20 >=20 > Or would most think the transparency is a bug and not a feature? >=20 > And I would argue a lot of application value has come to=20 > us over the years > because of "application-level tunneling" where if the=20 > infrastructure > would have had to be upgraded to do these things, we may=20 > have less cool > new apps these days. >=20 > Dino =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 Thu Oct 27 19:25:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVH7L-0005nI-2k; Thu, 27 Oct 2005 19:25:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVH7K-0005n7-Dt for architecture-discuss@megatron.ietf.org; Thu, 27 Oct 2005 19:25:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26680 for ; Thu, 27 Oct 2005 19:24:49 -0400 (EDT) Received: from outbound-mail.lax.untd.com ([64.136.28.164]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EVHKi-0005Sz-Bq for architecture-discuss@ietf.org; Thu, 27 Oct 2005 19:39:01 -0400 Received: from webmail33.lax.untd.com (webmail33.lax.untd.com [10.131.27.173]) by smtpout02.lax.untd.com with SMTP id AABBYC2NVAPQCNRS for (sender ); Thu, 27 Oct 2005 16:24:03 -0700 (PDT) Received: (from fergdawg@netzero.net) by webmail33.lax.untd.com (jqueuemail) id K8CVBVS9; Thu, 27 Oct 2005 16:23:04 PDT Received: from [68.91.216.251] by webmail33.lax.untd.com with HTTP: Thu, 27 Oct 2005 23:21:57 GMT X-Originating-IP: [68.91.216.251] Mime-Version: 1.0 From: "Fergie" Date: Thu, 27 Oct 2005 23:21:57 GMT To: architecture-discuss@ietf.org Subject: RE: [Architecture-discuss] Mobility and multi-homing X-Mailer: Webmail Version 4.0 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain Message-Id: <20051027.162304.22075.63142@webmail33.lax.untd.com> X-ContentStamp: 33:16:2144297036 X-MAIL-INFO: 49333fda9a17ca5b6aa35bc30f6e0f6b1f8b0beb17b3e7b33b0be747b30fee6fdfb37a2bb37e028f0a X-UNTD-OriginStamp: AcganUYbgVGZ0C6nm/9IPRc6B+K9FRsnUOSO+U0/psAUr+l5YYu0mw== X-UNTD-Peer-Info: 10.131.27.173|webmail33.lax.untd.com|webmail33.lax.untd.com|fergdawg@netzero.net X-Spam-Score: 0.9 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Content-Transfer-Encoding: quoted-printable X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org As an observer, and an interested party, I agree with Jim on this one -- the first order of business would be a "problem statement". And I also agree that working outside the auspices of the general IAB/IESG/IETF framework would indeed be seen as somewhat illegitimate, at least by folks who build networks, develop products, and make architectural decisions when it comes to implementation. I've seen banter about inconsistencies in IP-in-IP tunnels (among other things), but this is no different that shortcomings brought up in the associated IETF WG meetings when these protocols were initially developed... - ferg -- "Bound, Jim" wrote: I don't agree we need a leader group. It should be a working group or this list and run it similar in fashion to the way we have done IPR. But we need rules of engagement and before all of that or this should exists define exactly = "what problem are we solving"? To use a phrase from Aaron I like if all we need is a paint job then lets not change the engine. I personally believe some of the engine needs enhancments. But not where all often go for IP virtualization (ughhh I think that is more than tunnels but no big deal for now), or lets change what the identifier is for transport, but rather some other thoughts: Can guranteed QoS be achieved end-to-end and we have so many views on this and the current work and results from Diff and Int serve are not good enough by themselves, what is the answer? = Conventional routing protocols do not work for ad hoc networks and do we= need another virtual layer for them in the IP reference model, regardless if they are mobile which to me is orthogonal. 3rd world cultures will skip an entire generation of Internet technology= solutions and interoperate in a network environment of total wireless connections with some IX pipes, and Satcom as the dominant routing core,= is the IP reference model today ok or does the engine need new parts? I personally think the transport does with re-think beginning with SCTP and SCP-PS. Just thoughts not saying this should be the work, but once we identify the problem a list will be much easier to identify and then how do we work on such things. Just saying well I think I have a problem so I will go hire and build a new architecture team is not wise from an IETF workload witin the community, architecture, and business view. And a good ole boy self-proclaimed elitists is not the answer and the IETF should make very sure that does not happen, it will just be rejected by the new age Internet community, the market, and industry. Been there done that. Also if this should start, out of IETF bodies will show up too like ITU and others. The Internet is far more important to a lot of entities now,= than in 1983 or 1991, and a multi-Xillion dollar business and the IETF has not impressed the world regarding time-to-market in several areas. This work would be far different than delivering standards specifications most likely, but maybe not? /jim = > -----Original Message----- > From: architecture-discuss-bounces@ietf.org = > [mailto:architecture-discuss-bounces@ietf.org] On Behalf Of Tony Li > Sent: Thursday, October 27, 2005 2:01 PM > To: Noel Chiappa > Cc: architecture-discuss@ietf.org > Subject: Re: [Architecture-discuss] Mobility and multi-homing > = > > One, I don't have a good concept of how to make it happen = > > organizationally - > > either i) to make disparate groups adhere to the concept, or ii) = > > provide the > > drive to make it happen. > = > = > I want to amplify this point: > = > For the IETF to do any kind of *effective* changes to the = > architecture, there must be architectural control at some point in = > the organization. Prior to Kobe, it was the old boys network, as = > instantiated by the IAB. Post Kobe, there seems to be a unfillable = > vacuum in architectural leadership. To make significant = > architectural progress in *any* direction, we need to first resolve = > the question of who is providing this leadership and under what = > authorization. The basic premise of the post-Kobe debacle is that = > the IAB does not have the authority to make architectural decisions = > that are at odds with popular opinion. Until something happens to = > alter that premise, we will continue to run in circles. > = > Regards, > Tony > = _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Thu Oct 27 21:27:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVJ1f-0000Dz-US; Thu, 27 Oct 2005 21:27:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVJ1d-00008I-Ox for architecture-discuss@megatron.ietf.org; Thu, 27 Oct 2005 21:27:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09904 for ; Thu, 27 Oct 2005 21:27:04 -0400 (EDT) Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVJF6-0002U6-7o for architecture-discuss@ietf.org; Thu, 27 Oct 2005 21:41:17 -0400 Received: from 201.sub-70-209-62.myvzw.com (143.sub-70-209-37.myvzw.com [70.209.37.143]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9S1Qqn00663; Thu, 27 Oct 2005 18:26:52 -0700 (PDT) Date: Thu, 27 Oct 2005 18:26:45 -0700 From: Aaron Falk To: Tony Li Subject: Re: [Architecture-discuss] IP virtualisation Message-ID: <7AE52D12F0FADE3FCEBAB64C@nak.isi.edu> In-Reply-To: References: <435FFA3F.1060309@thinkingcat.com> <62773DFEBB4D27AE03BE2F67@nak.isi.edu> X-Mailer: Mulberry/4.0.4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: falk@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org Hi Tony- --On October 27, 2005 10:38:01 AM -0700 Tony Li wrote: > > 1) MTU - Tunneling overhead may break the link level PMTU. Does the > tunnel fragment and reassemble? This sounds like a bug in tunnels (or perhaps MTU) as they currently exist. Does Path MTU Discovery fix this? > > 2) Overhead - The tunnel always incurs some level of additional wrapper > as overhead and thus consumes bandwidth. I'm not very sympathetic to bandwidth as an architectural driver. The Internet was not intended to be efficient as much as it was intended to be general. As network capacity continues to climb, I suggest that designing for efficiency continues to be a low priority. > > 3) Transparency - Tunneling creates an issue for firewalls, as > unintended traffic can be tunneled around the policy control points. Deep packet inspection on unencrypted tunnels seems pretty easy -- or at least, not much harder than without tunnels. I think your (valid) concern is with encryption. I propose we set that aside for a (potential, future) privacy vs. protection discussion on the tussle that motivates firewalls and encryption. --aaron _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Oct 28 00:15:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVLcz-0007nK-L8; Fri, 28 Oct 2005 00:14:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVLcx-0007n6-Dr for architecture-discuss@megatron.ietf.org; Fri, 28 Oct 2005 00:14:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17853 for ; Fri, 28 Oct 2005 00:13:46 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVLqR-00071a-B6 for architecture-discuss@ietf.org; Fri, 28 Oct 2005 00:28:00 -0400 Received: from [192.168.1.47] (pool-71-106-130-244.lsanca.dsl-w.verizon.net [71.106.130.244]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9S4CXL25102; Thu, 27 Oct 2005 21:12:33 -0700 (PDT) Message-ID: <4361A529.5080905@isi.edu> Date: Thu, 27 Oct 2005 21:12:25 -0700 From: Joe Touch User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Tony Li Subject: Re: [Architecture-discuss] IP virtualisation References: <435FFA3F.1060309@thinkingcat.com> <62773DFEBB4D27AE03BE2F67@nak.isi.edu> <7AE52D12F0FADE3FCEBAB64C@nak.isi.edu> In-Reply-To: <7AE52D12F0FADE3FCEBAB64C@nak.isi.edu> X-Enigmail-Version: 0.93.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: 92df29fa99cf13e554b84c8374345c17 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="===============0009510234==" Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0009510234== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE6BC9BC812347C8EC937401A" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE6BC9BC812347C8EC937401A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Tony, > --On October 27, 2005 10:38:01 AM -0700 Tony Li wrote= : > > 1) MTU - Tunneling overhead may break the link level PMTU. Does the > tunnel fragment and reassemble? Whether a tunnel does this or not is the same as whether a link does this or not. Consider ATM ;-( There are cases where this should propagate back to the endpoints, and cases where reassembly at the destination should mask it. Ultimately, tunneling exposed assumptions in IP as deployed, not as designed. This happens - there were similar assumptions about NFS and the typical LAN bandwidth that 100Mbps blew away, and pipelining had to be incorporated. IMO, this is an opportunity to fix the erroneous assumption that the host interface gives you the final word on a good MTU= =2E As Aaron hinted, newer versions of path MTU discovery should accomodate tunnels fine. > 2) Overhead - The tunnel always incurs some level of additional wrappe= r > as overhead and thus consumes bandwidth. The primary impact is in payload size; the headers can be compressed a bit. This may consume bandwidth, but how much can vary. However, there are other cases where we have traded efficiency for flexibility. Virtual memory does two lookups per address. But we accept the overhead because of the flexibility. I believe that virtual networking (based on tunnels) has similar benefits, with similar overheads. > 3) Transparency - Tunneling creates an issue for firewalls, as > unintended traffic can be tunneled around the policy control points. Tunneling around policy control points is a feature, not a bug. It is why tunneling is succeeding as a way to deploy new protocols incrementally, and a way to experiment with protocols at the application layer. Firewalls make the assumption that there is information available at the network layer that can be used to limit traffic, and that routing will direct traffic towards the firewall. Both of these assumptions are the real bug - as Aaron noted, encryption defeats packet inspection moreso than tunneling anyway. Joe --------------enigE6BC9BC812347C8EC937401A 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.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDYaUpE5f5cImnZrsRAv26AJ9YOssJy19p7p/Ifn9G1TH+qCxxwwCeMKFK 4kwo8vWM7Qwl30FQKaZMyE8= =OSLv -----END PGP SIGNATURE----- --------------enigE6BC9BC812347C8EC937401A-- --===============0009510234== 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 --===============0009510234==-- From architecture-discuss-bounces@ietf.org Fri Oct 28 06:54:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVRsR-0007oS-9K; Fri, 28 Oct 2005 06:54:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVRsQ-0007oK-6Y for architecture-discuss@megatron.ietf.org; Fri, 28 Oct 2005 06:54:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07253 for ; Fri, 28 Oct 2005 06:54:09 -0400 (EDT) Received: from web31814.mail.mud.yahoo.com ([68.142.206.167]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EVS5x-0001Rf-Ju for architecture-discuss@ietf.org; Fri, 28 Oct 2005 07:08:27 -0400 Received: (qmail 87146 invoked by uid 60001); 28 Oct 2005 10:54:14 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=54WV8s7RGJChUfjeWN2ZGdRoBKgbn3A9PlTLlfCgTNyarlyzwiBBgGxl4qN9ur5KzN7T8z5JFeG4pOj5+0YFSugVL9BWI2MzAAfnvUVz2GuyAgScSUuVbcO6S8ZWAWNP5I64pS29Qx613Dr0xJrDVi53bEJLBh+Os2sIt2ZXTi8= ; Message-ID: <20051028105414.87144.qmail@web31814.mail.mud.yahoo.com> Received: from [68.48.216.32] by web31814.mail.mud.yahoo.com via HTTP; Fri, 28 Oct 2005 03:54:14 PDT Date: Fri, 28 Oct 2005 03:54:14 -0700 (PDT) From: David Barak To: architecture-discuss@ietf.org In-Reply-To: <4360F3F6.4060006@motorola.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.6 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 8bit Subject: [Architecture-discuss] Re: NETLMM and dumb network X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org --- Alexandru Petrescu wrote: > NETLMM and dumb network. > > In netlmm there's a proposal to manage host mobility > entirely by the > network, in that a small network changes its state > dynamically such as > to update paths towards a moving host, which keeps > its address stable, > doesn't change it. This has worked moderately well for the GSM/CDMA types, but the fundamental difficulty with having hosts update a network (instead of vice-versa) is that they have to do that whether or not they're mobile. With c.phones, it makes sense, because by definition they're always mobile, but for other types of less-mobile devices, that may not be the most efficient use of bandwidth. > > Or, the network was supposed to be dumb. I've always understood this to mean that the *CORE* network was dumb - that decisions are made as close to the host as possible, but not necessarily on the host itself: routing is a network function which the host is dimly aware of. With discussions of Shim6, the routing intelligence seems to be moving to the host (eeek!) but there is a significant amount of justified concern about whether that will work or scale. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 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 Fri Oct 28 07:03:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVS1N-00040u-Nn; Fri, 28 Oct 2005 07:03:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVS1M-00040o-Be for architecture-discuss@megatron.ietf.org; Fri, 28 Oct 2005 07:03:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07558 for ; Fri, 28 Oct 2005 07:03:23 -0400 (EDT) Received: from web31807.mail.mud.yahoo.com ([68.142.207.70]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EVSEt-0001eG-Ia for architecture-discuss@ietf.org; Fri, 28 Oct 2005 07:17:40 -0400 Received: (qmail 78866 invoked by uid 60001); 28 Oct 2005 11:03:26 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=1kCUCHSYi/YfanOBIiln3VrL9OAbfkkG/hpgqs8VtpTkb6QVpQdSEGtcvXOO5GYIHZ8IJXEZHwWUfITiwc/+tzEKEGN8gOjRBwXRIVDH0aYqm7+Zl1g2HelPvGUa6CKbf8L+4+cufalM2OxzlTujFTzvrIE22/r7m/vo5P9LohI= ; Message-ID: <20051028110326.78864.qmail@web31807.mail.mud.yahoo.com> Received: from [68.48.216.32] by web31807.mail.mud.yahoo.com via HTTP; Fri, 28 Oct 2005 04:03:26 PDT Date: Fri, 28 Oct 2005 04:03:26 -0700 (PDT) From: David Barak Subject: Re: [Architecture-discuss] Mobility and multi-homing To: architecture-discuss@ietf.org In-Reply-To: <781BF33CC9B5A9C7506B2426@nak.isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 8bit X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org --- Aaron Falk wrote: > --On October 27, 2005 8:24:04 AM -0400 Noel Chiappa > wrote: > > > > Actually, the question I wound up pondering was > whether the old TCP model > > of "endpoint to endpoint" was the way to go, or > whether we needed some > > richer model in which you were talking to a pool > of servers, so that > > things like load-sharing and failover popped out > as well-supported by the > > basic transport. > > > > Right now, with the Web, people get around this by > using cookies, all > > those redirector kludges, just clicking on the > link again when your > > transaction fails, etc. > > > > But would it be desirable to have that capability > architected in? And if > > so, how to do it in a way that means that things > that *don't* want that > > capability don't wind up paying for it? > > > > How you answer this has a big impact on what kinds > of namespace(s) you > > add, etc. E.g. is endpoint-endpoint communication > still critical enough > > that you need a namespace for naming endpoints? > Etc, etc... > > Noel- > > I just want to observe that you have enlarged the > scope of the question > from changing the architecture to fix something that > is broken (maintaining > transport connections when an endpoint moves from > one network to another) > to include fixing something that doesn't seem broken > (maintaining transport > connection when an endpoint moves from one host to > anther within a > network). Does the latter seem like it needs fixing > to you? Or are you > motivated by a desire for a cleaner architecture? > Your comment that the > plane is flying is important and I'm loath to change > engines just because > the current one needs a paint job. For some of us, the cure here would be significantly worse than the disease. Permitting stateful connections to ride on top of connections which do not require state is a beautiful thing - it's one of the profound successes of the layered model, and redesigning that to ensure that all endpoints are locatable and uniquely identifiable will cause a tremendous amount of pain to operators. I would venture to say that this would not make the architecture "cleaner" in any way: witness the kludgyness of IPv6 in its layer-munging. Yes, there are definite benefits to uniquely identifying endpoints by non-transitory IDs; however, the we lose the distinction between layer 2 and 3, and end up with (at best) very, very ugly addressing. At worst, you end up losing the power of both layer 2 and layer 3 to aggregate. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Oct 28 07:10:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVS7t-0008D7-Tu; Fri, 28 Oct 2005 07:10:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVS7s-0008D2-Nj for architecture-discuss@megatron.ietf.org; Fri, 28 Oct 2005 07:10:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07772 for ; Fri, 28 Oct 2005 07:10:07 -0400 (EDT) Received: from web31807.mail.mud.yahoo.com ([68.142.207.70]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EVSLQ-0001nq-Ch for architecture-discuss@ietf.org; Fri, 28 Oct 2005 07:24:25 -0400 Received: (qmail 81034 invoked by uid 60001); 28 Oct 2005 11:10:14 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=PZEDJD+eO7q6rsVMAUL7rRZAfqU20G9Twbpn8SYTiDQDUuwhPh32aajq3gYKns4DAaxv1ZNkm8B5KGO6ppw6Jf+Sjf4fKZTLJblkgCf0Wb4BdVOSAA8JdkXfO8PGFUmVjmdLcQS/gKjXBzsg7vXBJK5nq73ssqfNPT+xBSC2GiA= ; Message-ID: <20051028111014.81032.qmail@web31807.mail.mud.yahoo.com> Received: from [68.48.216.32] by web31807.mail.mud.yahoo.com via HTTP; Fri, 28 Oct 2005 04:10:14 PDT Date: Fri, 28 Oct 2005 04:10:14 -0700 (PDT) From: David Barak Subject: Re: [Architecture-discuss] IP virtualisation To: architecture-discuss@ietf.org In-Reply-To: <4FAA9E49-366C-41C6-8B51-8C05AA128FF4@tony.li> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 8bit X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org --- Tony Li wrote: > > > Ok, apparently I need to clarify quite a bit. > > I'm *NOT* dumping on tunneling. I'm not trying to > shoot it, kill it > or maim it in any way. > > I *am* trying to get across the perspective that it > is not 100% > transparent and is always necessarily going to be a > second-class > citizen in an architecture. If we do want a clean, > straightforward > architecture, we should retain tunneling for our > exceptions, but it > should never be our primary mechanism. > > Hope that's more clear, > Tony > > On Oct 27, 2005, at 11:51 AM, Dino Farinacci wrote: > > Since tunneling allows transparency in the > core, that would > > seem to be > > a fairly robust architectural principle with > lots of value. > > > > Or would most think the transparency is a bug > and not a feature? > > > > And I would argue a lot of application value > has come to us > > over the years > > because of "application-level tunneling" where > if the > > infrastructure > > would have had to be upgraded to do these > things, we may have > > less cool > > new apps these days. > > > > Dino > > I think that y'all are talking past each other. Dino, what you're referring to as "application-level-tunneling" is basically building persistent connections between hosts at layer 7 (think SSL). What Tony is talking about is bypassing layer 3 at layer 3 (as in a GRE tunnel), and supporting all layers of service through this. When I think of tunnelling, I think more of Tony's definition than Dino's - that is, Tony's description is more of a network service: something which supports not only the two virtually connected host/routers, but also serve as a virtual network for other hosts, which are transparently redirected. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com __________________________________ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Oct 28 08:44:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVTax-0000wm-Qo; Fri, 28 Oct 2005 08:44:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVTav-0000wX-Oq for architecture-discuss@megatron.ietf.org; Fri, 28 Oct 2005 08:44:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12033 for ; Fri, 28 Oct 2005 08:44:12 -0400 (EDT) Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVToU-0004GE-7V for architecture-discuss@ietf.org; Fri, 28 Oct 2005 08:58:31 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 7894886AFA; Fri, 28 Oct 2005 08:44:19 -0400 (EDT) To: architecture-discuss@ietf.org Subject: Re: [Architecture-discuss] Mobility and multi-homing Message-Id: <20051028124419.7894886AFA@mercury.lcs.mit.edu> Date: Fri, 28 Oct 2005 08:44:19 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org > From: Tony Li > For the IETF to do any kind of *effective* changes to the architecture, > there must be architectural control at some point in the organization. > .. there seems to be a unfillable vacuum in architectural leadership. > To make significant architectural progress in *any* direction, we need > to first resolve the question of who is providing this leadership and > under what authorization. Tony, while I happen to basically agree with you, my view is that it's Not My Problem, and I think this list should ignore it. The IETF and the IAB do indeed need to work out how to do this, but that's something the IETF and IAB are going to have to tackle. (And no doubt there wil be those aplenty who don't understand that "architecture committee" is an oxymoron; they need to go read 'Mythical Man-Month' Chapter 4, "Aristocracy, Democracy, and System Design".) I have less than zero interest in getting involved in making that happen; somebody else (the IAB, etc) is going to have to fight that battle. > The basic premise of the post-Kobe debacle is that the IAB does not > have the authority to make architectural decisions that are at odds > with popular opinion. Until something happens to alter that premise, we > will continue to run in circles. One of two things will happen. Either i) the IETF community will accept that a system needs an architectural compass, and committees (especially of the whole) cannot provide that, or ii) the system will become even more screwed up by feature-cancer than it already is, and eventually the IETF's stewardship will be so obviously broken that something else will replace it. I fail to see why I should tilt at that windmill (again! :-) when I can just sit back and wait for natural forces to do that job for me (while I amuse myself with more pleasant pastimes). "We are a lighthouse. Your call." Noel _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Oct 28 09:18:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVU7Q-0003nX-EA; Fri, 28 Oct 2005 09:18:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVU7O-0003nS-IP for architecture-discuss@megatron.ietf.org; Fri, 28 Oct 2005 09:18:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13962 for ; Fri, 28 Oct 2005 09:17:42 -0400 (EDT) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVUKv-0005EK-8a for architecture-discuss@ietf.org; Fri, 28 Oct 2005 09:32:02 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j9SDHc108749; Fri, 28 Oct 2005 09:17:38 -0400 (EDT) Received: from zcarhxs1.corp.nortel.com ([47.129.230.89]) by zrc2hxm2.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 28 Oct 2005 08:17:37 -0500 Received: from [127.0.0.1] ([47.130.17.87] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 28 Oct 2005 09:17:36 -0400 Message-ID: <436224EB.1000602@nortel.com> Date: Fri, 28 Oct 2005 09:17:31 -0400 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Touch Subject: Re: [Architecture-discuss] IP virtualisation References: <435FFA3F.1060309@thinkingcat.com> <62773DFEBB4D27AE03BE2F67@nak.isi.edu> <7AE52D12F0FADE3FCEBAB64C@nak.isi.edu> <4361A529.5080905@isi.edu> In-Reply-To: <4361A529.5080905@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Oct 2005 13:17:36.0910 (UTC) FILETIME=[F70072E0:01C5DBC1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org Seems to me we could clarify the architectural role of firewalls. We need to line up what information is available, where, and what information is needed to do the job of protecting hosts. There will be a division of labour between network-based firewalls and host-based firewalls. What new information does the network have to pass on to hosts so their firewalls can do their jobs? Joe Touch wrote: > Hi, Tony, > > ... > >>3) Transparency - Tunneling creates an issue for firewalls, as >>unintended traffic can be tunneled around the policy control points. > > > Tunneling around policy control points is a feature, not a bug. It is > why tunneling is succeeding as a way to deploy new protocols > incrementally, and a way to experiment with protocols at the application > layer. > > Firewalls make the assumption that there is information available at the > network layer that can be used to limit traffic, and that routing will > direct traffic towards the firewall. Both of these assumptions are the > real bug - as Aaron noted, encryption defeats packet inspection moreso > than tunneling anyway. > > Joe > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Oct 28 10:54:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVVcc-0006pI-Q7; Fri, 28 Oct 2005 10:54:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVVcc-0006pC-1R for architecture-discuss@megatron.ietf.org; Fri, 28 Oct 2005 10:54:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22438 for ; Fri, 28 Oct 2005 10:54:05 -0400 (EDT) Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVVqB-0008Gw-HW for architecture-discuss@ietf.org; Fri, 28 Oct 2005 11:08:24 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 43B1720000E9; Fri, 28 Oct 2005 10:53:58 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 28 Oct 2005 10:53:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Architecture-discuss] IP virtualisation Date: Fri, 28 Oct 2005 10:53:44 -0400 Message-ID: <936A4045C332714F975800409DE09240013886F4@tayexc14.americas.cpqcorp.net> Thread-Topic: [Architecture-discuss] IP virtualisation Thread-Index: AcXbwkIQrwbCNL/6TUKORB1sW9vKLAADQDrg From: "Bound, Jim" To: "Tom-PT Taylor" , "Joe Touch" X-OriginalArrivalTime: 28 Oct 2005 14:53:45.0882 (UTC) FILETIME=[6593B7A0:01C5DBCF] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org Also if the only part of the packet exposed is the header it complicates filtering and also Intrusion Detection is affected. /jim=20 > -----Original Message----- > From: architecture-discuss-bounces@ietf.org=20 > [mailto:architecture-discuss-bounces@ietf.org] On Behalf Of=20 > Tom-PT Taylor > Sent: Friday, October 28, 2005 9:18 AM > To: Joe Touch > Cc: architecture-discuss@ietf.org > Subject: Re: [Architecture-discuss] IP virtualisation >=20 > Seems to me we could clarify the architectural role of firewalls. We=20 > need to line up what information is available, where, and what=20 > information is needed to do the job of protecting hosts. =20 > There will be=20 > a division of labour between network-based firewalls and host-based=20 > firewalls. What new information does the network have to pass on to=20 > hosts so their firewalls can do their jobs? >=20 > Joe Touch wrote: > > Hi, Tony, > >=20 > >=20 > ... >=20 > >=20 > >>3) Transparency - Tunneling creates an issue for firewalls, as > >>unintended traffic can be tunneled around the policy control points. > >=20 > >=20 > > Tunneling around policy control points is a feature, not a=20 > bug. It is > > why tunneling is succeeding as a way to deploy new protocols > > incrementally, and a way to experiment with protocols at=20 > the application > > layer. > >=20 > > Firewalls make the assumption that there is information=20 > available at the > > network layer that can be used to limit traffic, and that=20 > routing will > > direct traffic towards the firewall. Both of these=20 > assumptions are the > > real bug - as Aaron noted, encryption defeats packet=20 > inspection moreso > > than tunneling anyway. > >=20 > > Joe > >=20 > >=20 > >=20 > >=20 > -------------------------------------------------------------- > ---------- > >=20 > > _______________________________________________ > > 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 >=20 _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Oct 28 11:23:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVW4K-0004x3-I4; Fri, 28 Oct 2005 11:23:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVW4J-0004u9-ID for architecture-discuss@megatron.ietf.org; Fri, 28 Oct 2005 11:22:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24239 for ; Fri, 28 Oct 2005 11:22:42 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVWHu-0000nT-32 for architecture-discuss@ietf.org; Fri, 28 Oct 2005 11:37:02 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id A897B89842; Fri, 28 Oct 2005 18:22:44 +0300 (EEST) Message-ID: <43624250.4070203@piuha.net> Date: Fri, 28 Oct 2005 18:22:56 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Leslie Daigle , "Pekka Nikander (JO/LMF)" , jnc@mercury.lcs.mit.edu Subject: Re: [Architecture-discuss] Mobility and multi-homing References: <435FF9DE.1060205@thinkingcat.com> In-Reply-To: <435FF9DE.1060205@thinkingcat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org Leslie Daigle wrote: > [Tap tap tap -- "is this thing on?" ;-) I'm forwarding Pekka > Nikander's suggested topic-starters, one at a time, to see if > we can get some "discuss" going, about "architecture". -- LLD] First, I'd like to thank you Leslia and Pekka for setting this list and discussion up. I believe this can be very useful. We do talk too little of the architecture in the IETF. And Pekka wrote: > 1. Mobility and multi-homing Actually, I have a bit different view into this than seems to be the focus of the discussion so far. What I view as architecture isn't necessarily agreement on a single solution, nor is it the simplicity of solutions. What seems more important is that we have broken down the problem into separable pieces. Solutions for individual pieces can then proceed in their own pace and style. It seems evident to me that we have a case of "market will decide" here for some components, and I think its fine - but don't take this as opinion that markets work in all cases. Also, "we have options and we will let the market choose" shouldn't be the same as "we aren't doing anything to guide the solutions". Some examples of the separable pieces include - Network attachment functions that satisfy needs of mobile hosts. There's a lot of ongoing work in this space relating to either functional or performance improvements, e.g., DNA, optimized v6 setups (optimistic DAD), access security for roaming (EAP), and so on. - The actual multiaddressing function, e.g., Mobile IPv6 + extensions, HIP + extensions, SHIM+SEND+ friends, application layer. - Triggering mechanisms that assist getting information about conditions, better attachment points, etc. - Interfaces to transport layer to inform them about switching to a new path and/or getting information from them about current reachability. - Local "services", such as ability to offer forwarding agents via DHCP, maybe ability to pull old packets from previous router, etc. Re: deploy multiple solutions at the same time. Here I think we have a case for some more short term work. We are starting to have so many extensions to the "waist" of IP that I'm not fully convinced anyone knows which order all those processing steps should be taken. Re: what would be the right way or right ways forward? Looking at this field, I think we've learned a few lessons over the years. One of the issues that we need to pay more attention to include deployment (e.g. ability to do something without having to (a) set up servers in the network and (b) set up subscriptions of users for those servers). Another issue is different environments. Mechanisms that are more likely to be deployed are likely to work despite IP versions, NATs, etc. Re: functions beyond multiaddress suggested by Noel. I don't think we should work on server pooling; this seems to work well now. But another issue that may deserve more attention is denial-of-service protection. --Jari _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Oct 28 11:31:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVWCk-00005J-EO; Fri, 28 Oct 2005 11:31:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVWCj-0008WO-Am for architecture-discuss@megatron.ietf.org; Fri, 28 Oct 2005 11:31:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24724 for ; Fri, 28 Oct 2005 11:31:24 -0400 (EDT) Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVWQK-000159-3A for architecture-discuss@ietf.org; Fri, 28 Oct 2005 11:45:44 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 2A5A220001C1; Fri, 28 Oct 2005 11:31:32 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 28 Oct 2005 11:31:25 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Architecture-discuss] Mobility and multi-homing Date: Fri, 28 Oct 2005 11:31:23 -0400 Message-ID: <936A4045C332714F975800409DE0924001388756@tayexc14.americas.cpqcorp.net> Thread-Topic: [Architecture-discuss] Mobility and multi-homing Thread-Index: AcXb04qUL6agFMeLTxu2nip6e0VApQAAIiQw From: "Bound, Jim" To: "Jari Arkko" , "Leslie Daigle" , "Pekka Nikander (JO/LMF)" , X-OriginalArrivalTime: 28 Oct 2005 15:31:25.0010 (UTC) FILETIME=[A81F4B20:01C5DBD4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: quoted-printable Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org Jari, This is all current working group work??? Or I am working on this now for nothing :--) (this is in jest). All need to take Noel's mail very seriously on lets not add yet more confusion by adding parts and I too agree I could just sit back and watch other forces fix architecture issues. I do still have faith in committees that have good leaders that believe leadership is an action not discussion, pontification, and more meetings :--). What problem needs to be solved again? I also agree if there is a problem, the IETF only has X time to solve it or someone else will solve it out of here. But, I still don't have firm grasp on the architecture problem other than end-to-end is total mess today which has caused other bad things IMO. /jim=20 > -----Original Message----- > From: architecture-discuss-bounces@ietf.org=20 > [mailto:architecture-discuss-bounces@ietf.org] On Behalf Of Jari Arkko > Sent: Friday, October 28, 2005 11:23 AM > To: Leslie Daigle; Pekka Nikander (JO/LMF); jnc@mercury.lcs.mit.edu > Cc: architecture-discuss@ietf.org > Subject: Re: [Architecture-discuss] Mobility and multi-homing >=20 > Leslie Daigle wrote: >=20 > > [Tap tap tap -- "is this thing on?" ;-) I'm forwarding Pekka > > Nikander's suggested topic-starters, one at a time, to see if > > we can get some "discuss" going, about "architecture". -- LLD] >=20 > First, I'd like to thank you Leslia and Pekka for setting this > list and discussion up. I believe this can be very useful. > We do talk too little of the architecture in the IETF. >=20 > And Pekka wrote: >=20 > > 1. Mobility and multi-homing >=20 > Actually, I have a bit different view into this than seems > to be the focus of the discussion so far. What I view as > architecture isn't necessarily agreement on a single > solution, nor is it the simplicity of solutions. What seems > more important is that we have broken down the problem > into separable pieces. Solutions for individual pieces > can then proceed in their own pace and style. It seems > evident to me that we have a case of "market will decide" > here for some components, and I think its fine - but don't > take this as opinion that markets work in all cases. Also, > "we have options and we will let the market choose" shouldn't > be the same as "we aren't doing anything to guide the > solutions". >=20 > Some examples of the separable pieces include >=20 > - Network attachment functions that satisfy > needs of mobile hosts. There's a lot of ongoing > work in this space relating to either functional > or performance improvements, e.g., DNA, optimized > v6 setups (optimistic DAD), access security for > roaming (EAP), and so on. >=20 > - The actual multiaddressing function, e.g., Mobile > IPv6 + extensions, HIP + extensions, SHIM+SEND+ > friends, application layer. >=20 > - Triggering mechanisms that assist getting > information about conditions, better attachment > points, etc. >=20 > - Interfaces to transport layer to inform them > about switching to a new path and/or getting > information from them about current reachability. >=20 > - Local "services", such as ability to offer forwarding > agents via DHCP, maybe ability to pull old packets > from previous router, etc. >=20 > Re: deploy multiple solutions at the same time. Here > I think we have a case for some more short term work. > We are starting to have so many extensions to the > "waist" of IP that I'm not fully convinced anyone knows > which order all those processing steps should be taken. >=20 > Re: what would be the right way or right ways forward? > Looking at this field, I think we've learned a few lessons > over the years. One of the issues that we need to pay > more attention to include deployment (e.g. ability to > do something without having to (a) set up servers in > the network and (b) set up subscriptions of users for > those servers). Another issue is different environments. > Mechanisms that are more likely to be deployed are > likely to work despite IP versions, NATs, etc. >=20 > Re: functions beyond multiaddress suggested by Noel. > I don't think we should work on server pooling; this > seems to work well now. But another issue that may > deserve more attention is denial-of-service protection. >=20 > --Jari >=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 Oct 28 14:02:28 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVYYe-0003YG-1D; Fri, 28 Oct 2005 14:02:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVYYb-0003Vc-0b for architecture-discuss@megatron.ietf.org; Fri, 28 Oct 2005 14:02:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01153 for ; Fri, 28 Oct 2005 14:02:07 -0400 (EDT) Received: from portola.portolanetworks.tv ([66.121.157.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVYmC-0005A9-OX for architecture-discuss@ietf.org; Fri, 28 Oct 2005 14:16:29 -0400 Received: from [192.168.2.22] ([66.121.157.194]) by portola.portolanetworks.tv with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Oct 2005 10:57:30 -0700 In-Reply-To: <20051028124419.7894886AFA@mercury.lcs.mit.edu> References: <20051028124419.7894886AFA@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2EC87CDD-16E3-48BF-8629-8530074437FD@tony.li> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Architecture-discuss] Mobility and multi-homing Date: Fri, 28 Oct 2005 11:02:00 -0700 To: Noel Chiappa X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 28 Oct 2005 17:57:30.0312 (UTC) FILETIME=[10A63C80:01C5DBE9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org > The IETF and the IAB do indeed need to work out how to do this, but > that's > something the IETF and IAB are going to have to tackle. (And no > doubt there > wil be those aplenty who don't understand that "architecture > committee" is an > oxymoron; they need to go read 'Mythical Man-Month' Chapter 4, > "Aristocracy, > Democracy, and System Design".) I have less than zero interest in > getting > involved in making that happen; somebody else (the IAB, etc) is > going to have > to fight that battle. > > One of two things will happen. Either i) the IETF community will > accept that > a system needs an architectural compass, and committees (especially > of the > whole) cannot provide that, or ii) the system will become even more > screwed > up by feature-cancer than it already is, and eventually the IETF's > stewardship will be so obviously broken that something else will > replace it. > > I fail to see why I should tilt at that windmill (again! :-) when I > can just > sit back and wait for natural forces to do that job for me (while I > amuse > myself with more pleasant pastimes). "We are a lighthouse. Your call." > > > > > > > Noel, With all due respect, if everyone in the IETF sits back and waits for change to happen, then change is not going to happen. Further, if you are truly waiting for change, why are you bothering to comment here? While I understand that you don't want to hit your head on the wall again, I suspect that you are not just amusing yourself. Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Oct 28 16:02:57 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVaRF-0002ke-KT; Fri, 28 Oct 2005 16:02:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVaRC-0002gC-FZ for architecture-discuss@megatron.ietf.org; Fri, 28 Oct 2005 16:02:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07896 for ; Fri, 28 Oct 2005 16:02:36 -0400 (EDT) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVaeo-0000O6-As for architecture-discuss@ietf.org; Fri, 28 Oct 2005 16:17:00 -0400 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j9SK1KL12109; Fri, 28 Oct 2005 13:01:20 -0700 (PDT) Message-ID: <43628391.1060300@isi.edu> Date: Fri, 28 Oct 2005 13:01:21 -0700 From: Joe Touch User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom-PT Taylor Subject: Re: [Architecture-discuss] IP virtualisation References: <435FFA3F.1060309@thinkingcat.com> <62773DFEBB4D27AE03BE2F67@nak.isi.edu> <7AE52D12F0FADE3FCEBAB64C@nak.isi.edu> <4361A529.5080905@isi.edu> <436224EB.1000602@nortel.com> In-Reply-To: <436224EB.1000602@nortel.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom-PT Taylor wrote: > Seems to me we could clarify the architectural role of firewalls. They keep out 'traffic I don't want' - but 'don't want' defined by application-layer content as well as endpoint context in ways that a firewall can't always access (by definition, if it's a transit or not authorized with copies of decryption keys). > We > need to line up what information is available, where, and what > information is needed to do the job of protecting hosts. The trouble is as much whether the endpoint is willing to give the needed information, and whether doing so compromises security or not. > There will be > a division of labour between network-based firewalls and host-based > firewalls. What new information does the network have to pass on to > hosts so their firewalls can do their jobs? IMO, 'what new information' = everything. For any given traffic, the information may include both all the data in the traffic as well as all the information in the host (keys, context, etc.). Although firewalls could be more manageable, in the extreme they can't be complete or architecturally well-defined, as a result. Joe > Joe Touch wrote: > >> Hi, Tony, >> >> > ... > >> >>> 3) Transparency - Tunneling creates an issue for firewalls, as >>> unintended traffic can be tunneled around the policy control points. >> >> >> >> Tunneling around policy control points is a feature, not a bug. It is >> why tunneling is succeeding as a way to deploy new protocols >> incrementally, and a way to experiment with protocols at the application >> layer. >> >> Firewalls make the assumption that there is information available at the >> network layer that can be used to limit traffic, and that routing will >> direct traffic towards the firewall. Both of these assumptions are the >> real bug - as Aaron noted, encryption defeats packet inspection moreso >> than tunneling anyway. >> >> Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDYoORE5f5cImnZrsRAjzUAKD+WQBZHtTzaREOZSDhIPb/YV+ltACfWSTm 8j4E2+poShXjgaYIzxrZob0= =Ve70 -----END PGP SIGNATURE----- _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Fri Oct 28 18:40:44 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVctw-00022H-4D; Fri, 28 Oct 2005 18:40:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVctu-00022C-8S for architecture-discuss@megatron.ietf.org; Fri, 28 Oct 2005 18:40:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24447 for ; Fri, 28 Oct 2005 18:40:25 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVd7X-0007gg-TV for architecture-discuss@ietf.org; Fri, 28 Oct 2005 18:54:49 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EVcti-0005RK-Rg; Fri, 28 Oct 2005 15:40:31 -0700 Message-Id: <6.2.3.4.2.20051028204704.04a61ca0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Sat, 29 Oct 2005 00:40:21 +0200 To: jnc@mercury.lcs.mit.edu (Noel Chiappa), architecture-discuss@ietf.org From: "JFC (Jefsey) Morfin" Subject: Re: [Architecture-discuss] Mobility and multi-homing In-Reply-To: <20051028124419.7894886AFA@mercury.lcs.mit.edu> References: <20051028124419.7894886AFA@mercury.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org At 14:44 28/10/2005, Noel Chiappa wrote: > > From: Tony Li > > > For the IETF to do any kind of *effective* changes to the architecture, > > there must be architectural control at some point in the organization. > > .. there seems to be a unfillable vacuum in architectural leadership. > > To make significant architectural progress in *any* direction, we need > > to first resolve the question of who is providing this leadership and > > under what authorization. > >Tony, while I happen to basically agree with you, my view is that it's Not My >Problem, and I think this list should ignore it. may be should we accept this leadership is the users demand (the IETF is the specialisation of some experimenters+developpers+users, it should not be a split). Its legitimacy is that users decide anyway, at the end (but a wasted time). The difficulty is to understand it and then to get it translated into Charters. This is where IMHO architectural models can dramatically help as a common reference. May be the IRTF too? I am afraid saying that "this list should ignore" this leadership, leads it to find other ways to see its needs addressed (other SSDOs and grassroots process). NAT, VoIP, Grid, MP3, etc. are examples. Listening to the user demand in an appropriate way, rather than filtering it as Stephane suggests it, permits to hear new ideas (they are usually singly voiced). The user grassroots process (political, commercial) is not necessarily the best process to welcome and nurture architectural R&D. See IAB RFC 3869. jfc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Oct 29 02:43:43 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVkRL-0003bk-E1; Sat, 29 Oct 2005 02:43:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVkRI-0003bc-Nb for architecture-discuss@megatron.ietf.org; Sat, 29 Oct 2005 02:43:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14693 for ; Sat, 29 Oct 2005 02:43:22 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVkf0-0001lm-Ge for architecture-discuss@ietf.org; Sat, 29 Oct 2005 02:57:52 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j9T6hEA12185; Sat, 29 Oct 2005 09:43:15 +0300 Date: Sat, 29 Oct 2005 09:43:14 +0300 (EEST) From: Pekka Savola To: Tony Li Subject: Re: [Architecture-discuss] Mobility and multi-homing In-Reply-To: Message-ID: References: <20051027122404.F31AA86AEE@mercury.lcs.mit.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 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: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org On Thu, 27 Oct 2005, Tony Li wrote: > For the IETF to do any kind of *effective* changes to the architecture, there > must be architectural control at some point in the organization. Prior to > Kobe, it was the old boys network, as instantiated by the IAB. Post Kobe, > there seems to be a unfillable vacuum in architectural leadership. To make > significant architectural progress in *any* direction, we need to first > resolve the question of who is providing this leadership and under what > authorization. The basic premise of the post-Kobe debacle is that the IAB > does not have the authority to make architectural decisions that are at odds > with popular opinion. Until something happens to alter that premise, we will > continue to run in circles. Agreed. While many participants would likely want us to move towards more architectural decisions, they don't want such moves to comoe at odds with their _own_ work. The problem is exactly the "popular opinion"; the architectural control commitee would end up requiring changes that go against rough concensus of a WG, BOF, or even the IETF. Some parts of the IESG have tried to provide guidance before, but their authority to make those decisions has been questioned, with ugly results. If you want examples, look no farther than: http://www.watersprings.org/pub/id/draft-ietf-grow-rift-01.txt -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Oct 29 02:52:38 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVkZx-00074B-Si; Sat, 29 Oct 2005 02:52:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVkZv-0006zG-IQ for architecture-discuss@megatron.ietf.org; Sat, 29 Oct 2005 02:52:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15018 for ; Sat, 29 Oct 2005 02:52:17 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVknd-0001zE-FQ for architecture-discuss@ietf.org; Sat, 29 Oct 2005 03:06:46 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j9T6qFk12344; Sat, 29 Oct 2005 09:52:15 +0300 Date: Sat, 29 Oct 2005 09:52:15 +0300 (EEST) From: Pekka Savola To: Aaron Falk In-Reply-To: <7AE52D12F0FADE3FCEBAB64C@nak.isi.edu> Message-ID: References: <435FFA3F.1060309@thinkingcat.com> <62773DFEBB4D27AE03BE2F67@nak.isi.edu> <7AE52D12F0FADE3FCEBAB64C@nak.isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: architecture-discuss@ietf.org Subject: [Architecture-discuss] MTU-tunneling and PMTU [Re: IP virtualisation] X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org On Thu, 27 Oct 2005, Aaron Falk wrote: > --On October 27, 2005 10:38:01 AM -0700 Tony Li wrote: >> >> 1) MTU - Tunneling overhead may break the link level PMTU. Does the >> tunnel fragment and reassemble? > > This sounds like a bug in tunnels (or perhaps MTU) as they currently exist. > Does Path MTU Discovery fix this? PMTUD has its limits. I've studied the operational approaches when you need to tunnel inside the network (and not just from a host to host, which is simpler), see: http://www.ietf.org/internet-drafts/draft-savola-mtufrag-network-tunneling-05.txt Feedback is appreciated. NB: I had very long discussion with Joe Touch on int-area list about whether it's appropriate to describe implementations which don't honor DF-bit in a way I've done; let's not revisit it here. Have a look at his opinion at: http://www1.ietf.org/mail-archive/web/int-area/current/msg00103.html and the follow-up message. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Oct 29 08:20:54 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVphe-00019K-3w; Sat, 29 Oct 2005 08:20:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVphc-00019C-Aa for architecture-discuss@megatron.ietf.org; Sat, 29 Oct 2005 08:20:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28152 for ; Sat, 29 Oct 2005 08:20:33 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVpvG-0001lS-D9 for architecture-discuss@ietf.org; Sat, 29 Oct 2005 08:35:06 -0400 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j9TCKbdK004396 for ; Sat, 29 Oct 2005 05:20:38 -0700 (PDT) Received: from localhost.east.sun.com ([129.150.80.8]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j9TCKbH0025795 for ; Sat, 29 Oct 2005 08:20:37 -0400 (EDT) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j9TCKDkS026723; Sat, 29 Oct 2005 08:20:14 -0400 (EDT) Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.13.4+Sun/8.13.4/Submit) id j9TCKCY4026722; Sat, 29 Oct 2005 08:20:12 -0400 (EDT) X-Authentication-Warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: [Architecture-discuss] MTU-tunneling and PMTU [Re: IP virtualisation] From: Bill Sommerfeld To: Pekka Savola In-Reply-To: References: <435FFA3F.1060309@thinkingcat.com> <62773DFEBB4D27AE03BE2F67@nak.isi.edu> <7AE52D12F0FADE3FCEBAB64C@nak.isi.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1130588411.26214.102.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.324 Date: Sat, 29 Oct 2005 08:20:11 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: Aaron Falk , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org On Sat, 2005-10-29 at 02:52, Pekka Savola wrote: > > This sounds like a bug in tunnels (or perhaps MTU) as they currently exist. > > Does Path MTU Discovery fix this? > > PMTUD has its limits. You're far too kind. PMTUD based on feedback from ICMP Fragmentation Needed messages is essentially unusable in the as-built Internet, thanks in part to so-called "security auditors" who view all ICMP as potentially toxic. ICMP Black holes are everywhere. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Oct 29 12:26:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVtXR-0001fy-Q5; Sat, 29 Oct 2005 12:26:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVtXP-0001ft-I2 for architecture-discuss@megatron.ietf.org; Sat, 29 Oct 2005 12:26:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09356 for ; Sat, 29 Oct 2005 12:26:18 -0400 (EDT) Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVtlC-0007me-Jx for architecture-discuss@ietf.org; Sat, 29 Oct 2005 12:40:52 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id j9TGQPqx027081; Sat, 29 Oct 2005 09:26:25 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) id j9TGQOn2027080; Sat, 29 Oct 2005 09:26:24 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Sat, 29 Oct 2005 09:26:24 -0700 From: David Meyer To: Pekka Savola Subject: Re: [Architecture-discuss] Mobility and multi-homing Message-ID: <20051029162624.GA27059@1-4-5.net> References: <20051027122404.F31AA86AEE@mercury.lcs.mit.edu> 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: Noel Chiappa , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1166306826==" Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org --===============1166306826== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vkogqOf2sHV7VnPd" Content-Disposition: inline --vkogqOf2sHV7VnPd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Oct 29, 2005 at 09:43:14AM +0300, Pekka Savola wrote: > On Thu, 27 Oct 2005, Tony Li wrote: > >For the IETF to do any kind of *effective* changes to the architecture,= =20 > >there must be architectural control at some point in the organization. = =20 > >Prior to Kobe, it was the old boys network, as instantiated by the IAB. = =20 > >Post Kobe, there seems to be a unfillable vacuum in architectural=20 > >leadership. To make significant architectural progress in *any*=20 > >direction, we need to first resolve the question of who is providing thi= s=20 > >leadership and under what authorization. The basic premise of the=20 > >post-Kobe debacle is that the IAB does not have the authority to make=20 > >architectural decisions that are at odds with popular opinion. Until=20 > >something happens to alter that premise, we will continue to run in=20 > >circles. >=20 > Agreed. >=20 > While many participants would likely want us to move towards more=20 > architectural decisions, they don't want such moves to comoe at odds=20 > with their _own_ work. >=20 > The problem is exactly the "popular opinion"; the architectural=20 > control commitee would end up requiring changes that go against rough=20 > concensus of a WG, BOF, or even the IETF. Some parts of the IESG have=20 > tried to provide guidance before, but their authority to make those=20 > decisions has been questioned, with ugly results. >=20 > If you want examples, look no farther than: > http://www.watersprings.org/pub/id/draft-ietf-grow-rift-01.txt To be honest, I didn't see much in the way of IESG "guidance" associated with the rift work, unless of course you mean the "guidance" to attempt to document the issues. Dave --vkogqOf2sHV7VnPd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFDY6KwORgD1qCZ2KcRAu3CAJ9kN/N3FJkQ3YENLsDUR9mLTp/IyQCgkYxt EuDtWyfJvJuECTnyVST4X3w= =EzzV -----END PGP SIGNATURE----- --vkogqOf2sHV7VnPd-- --===============1166306826== 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 --===============1166306826==-- From architecture-discuss-bounces@ietf.org Sat Oct 29 13:33:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVuZl-0001GV-VN; Sat, 29 Oct 2005 13:33:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVuZk-0001EQ-9d for architecture-discuss@megatron.ietf.org; Sat, 29 Oct 2005 13:33:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12105 for ; Sat, 29 Oct 2005 13:32:46 -0400 (EDT) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVunX-0000wP-QL for architecture-discuss@ietf.org; Sat, 29 Oct 2005 13:47:21 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j9THWeA23024; Sat, 29 Oct 2005 20:32:40 +0300 Date: Sat, 29 Oct 2005 20:32:40 +0300 (EEST) From: Pekka Savola To: David Meyer Subject: Re: [Architecture-discuss] Mobility and multi-homing In-Reply-To: <20051029162624.GA27059@1-4-5.net> Message-ID: References: <20051027122404.F31AA86AEE@mercury.lcs.mit.edu> <20051029162624.GA27059@1-4-5.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Noel Chiappa , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org On Sat, 29 Oct 2005, David Meyer wrote: >> The problem is exactly the "popular opinion"; the architectural >> control commitee would end up requiring changes that go against rough >> concensus of a WG, BOF, or even the IETF. Some parts of the IESG have >> tried to provide guidance before, but their authority to make those >> decisions has been questioned, with ugly results. >> >> If you want examples, look no farther than: >> http://www.watersprings.org/pub/id/draft-ietf-grow-rift-01.txt > > To be honest, I didn't see much in the way of IESG > "guidance" associated with the rift work, unless of > course you mean the "guidance" to attempt to document the > issues. I wasn't very closely in the loop, but the following was my perception: My recollection is that an IESG member first started being vocal on the RIFT issues. This resulted in extended discussion and a RIFT document. Later, it also resulted in creation of a WG (without having to go through a BOF), the most important task of which seemed to be be documenting the issue. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Oct 29 13:37:05 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVudd-0003Ut-6c; Sat, 29 Oct 2005 13:37:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVudZ-0003Uo-A7 for architecture-discuss@megatron.ietf.org; Sat, 29 Oct 2005 13:37:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12297 for ; Sat, 29 Oct 2005 13:36:43 -0400 (EDT) Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVurN-00013t-05 for architecture-discuss@ietf.org; Sat, 29 Oct 2005 13:51:18 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.4/8.13.4) with ESMTP id j9THapvN027851; Sat, 29 Oct 2005 10:36:51 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.4/8.12.11/Submit) id j9THapji027850; Sat, 29 Oct 2005 10:36:51 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Sat, 29 Oct 2005 10:36:51 -0700 From: David Meyer To: Pekka Savola Subject: Re: [Architecture-discuss] Mobility and multi-homing Message-ID: <20051029173651.GA27831@1-4-5.net> References: <20051027122404.F31AA86AEE@mercury.lcs.mit.edu> <20051029162624.GA27059@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: 0ddefe323dd869ab027dbfff7eff0465 Cc: Noel Chiappa , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1735031207==" Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org --===============1735031207== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tThc/1wpZn/ma/RB" Content-Disposition: inline --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Oct 29, 2005 at 08:32:40PM +0300, Pekka Savola wrote: > On Sat, 29 Oct 2005, David Meyer wrote: > >>The problem is exactly the "popular opinion"; the architectural > >>control commitee would end up requiring changes that go against rough > >>concensus of a WG, BOF, or even the IETF. Some parts of the IESG have > >>tried to provide guidance before, but their authority to make those > >>decisions has been questioned, with ugly results. > >> > >>If you want examples, look no farther than: > >>http://www.watersprings.org/pub/id/draft-ietf-grow-rift-01.txt > > > > To be honest, I didn't see much in the way of IESG > > "guidance" associated with the rift work, unless of > > course you mean the "guidance" to attempt to document the > > issues. >=20 > I wasn't very closely in the loop, but the following was my=20 > perception: >=20 > My recollection is that an IESG member first started being vocal on=20 > the RIFT issues. This resulted in extended discussion and a RIFT=20 > document. Later, it also resulted in creation of a WG (without having=20 > to go through a BOF), the most important task of which seemed to be be=20 > documenting the issue. I don't remember a WG being created, motivated by the rift document, with or without a BOF. Which WG are you referring to? Dave --tThc/1wpZn/ma/RB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFDY7MyORgD1qCZ2KcRApALAJ0cqsJFykUtcgDcuXn5FGfpI0UBHACfVz/p Yrzp8lhr6uLBHP2HmKrhn+g= =EtjB -----END PGP SIGNATURE----- --tThc/1wpZn/ma/RB-- --===============1735031207== 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 --===============1735031207==-- From architecture-discuss-bounces@ietf.org Sat Oct 29 13:47:43 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVunv-00075S-7q; Sat, 29 Oct 2005 13:47:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVunt-00075N-N5 for architecture-discuss@megatron.ietf.org; Sat, 29 Oct 2005 13:47:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12790 for ; Sat, 29 Oct 2005 13:47:23 -0400 (EDT) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVv1h-0001Jd-BH for architecture-discuss@ietf.org; Sat, 29 Oct 2005 14:01:58 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 121C2258077; Sat, 29 Oct 2005 19:46:47 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08567-07; Sat, 29 Oct 2005 19:46:42 +0200 (CEST) Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3E52F258062; Sat, 29 Oct 2005 19:46:42 +0200 (CEST) Date: Sat, 29 Oct 2005 19:48:07 +0200 From: Harald Tveit Alvestrand To: Pekka Savola , Tony Li Subject: Sources of architectural change (Re: [Architecture-discuss] Mobility and multi-homing) Message-ID: In-Reply-To: References: <20051027122404.F31AA86AEE@mercury.lcs.mit.edu> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable Cc: Noel Chiappa , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org Since this thread has grown far away from the subject line, I'm changing=20 it.... It's been clear to me for years that fundamental architectural *change* can = only come about in the same way that the Internet itself did: Some people get together and work out what to aim for, and DO IT; then,=20 having proved that it can work, they turn around and push it out into an=20 uncaring and hostile world. What the IETF with its consensus principle can do is to *protect* an=20 architecture - against both those who would change it in "bad" ways and=20 against those who would apply "minor" changes without thinking about its=20 result - this leads to the IETF, at its best, being an effective body for=20 enacting minor changes and extensions to an architecture with reasonable=20 thought about the consequences. The corridors of the IETF are filled with people who are *able* to think of = new architectures, and sometimes even *willing* to do so - at its best, the = IETF can form an environment in which they can meet. If we're really lucky, the IETF will be able to give prospective new=20 architectures some room and time to grow and socialize.... like MPLS, HIP,=20 BGP, LDAP, SNMP, RSVP and many others have tried to do - with opinions=20 sharply differing over the beauty of the result, of course. But those who expect *fundamental* change to be *started* within *any*=20 established organization understand neither organizations nor human nature. My $0.02 of pessimism. Harald --On l=F8rdag, oktober 29, 2005 09:43:14 +0300 Pekka Savola=20 wrote: > While many participants would likely want us to move towards more > architectural decisions, they don't want such moves to comoe at odds with > their _own_ work. > > The problem is exactly the "popular opinion"; the architectural control > commitee would end up requiring changes that go against rough concensus > of a WG, BOF, or even the IETF. Some parts of the IESG have tried to > provide guidance before, but their authority to make those decisions has > been questioned, with ugly results. _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Oct 29 16:41:54 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVxWU-00010g-Eb; Sat, 29 Oct 2005 16:41:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVxWT-00010b-1A for architecture-discuss@megatron.ietf.org; Sat, 29 Oct 2005 16:41:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23838 for ; Sat, 29 Oct 2005 16:41:34 -0400 (EDT) Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVxkI-00070Z-HZ for architecture-discuss@ietf.org; Sat, 29 Oct 2005 16:56:11 -0400 Received: from [192.168.1.5] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (sccrmhc12) with SMTP id <2005102920412101200dmhuoe>; Sat, 29 Oct 2005 20:41:32 +0000 In-Reply-To: References: <20051027122404.F31AA86AEE@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Date: Sat, 29 Oct 2005 13:41:19 -0700 To: Harald Tveit Alvestrand X-Mailer: Apple Mail (2.734) X-Spam-Score: 0.1 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Cc: architecture-discuss@ietf.org, Noel Chiappa Subject: [Architecture-discuss] Re: Sources of architectural change X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org Harald, > It's been clear to me for years that fundamental architectural > *change* can only come about in the same way that the Internet > itself did: > > Some people get together and work out what to aim for, and DO IT; > then, having proved that it can work, they turn around and push it > out into an uncaring and hostile world. Thank you for the inspirational approach, but hey, we've been there, done that, and got the egg on our faces to show for it. Remember GSE? For those that don't, it was an architectural change that would have made major semantic changes to v6. It was dismissed, in the view of some, unjustly. > If we're really lucky, the IETF will be able to give prospective > new architectures some room and time to grow and socialize.... like > MPLS, HIP, BGP, LDAP, SNMP, RSVP and many others have tried to do - > with opinions sharply differing over the beauty of the result, of > course. I agree, but we have clear evidence to the contrary: architectural change will be shut down in the name of politics. Until that room to grow is in evidence, the only precedent that we have is that innovation will be stifled by the high priests of v6. > But those who expect *fundamental* change to be *started* within > *any* established organization understand neither organizations nor > human nature. You can call me naive all day long, but let's be accurate here: my hope is that the organization will change itself so that it can foster new thinking. I don't expect or even want the organization itself to provide the innovation. Architecture by committee? Been there, seen that movie too. Ugly. How the IETF opens itself to change is an open question and there are many different possible paths. Whether we declare victory and say that IPv6 is done or declare disaster and start over makes no difference to me. Either way, we need to move on, and the IAB is in the best position to lead the community to accept this. The creation of this mailing list is certainly one possible step. It can be viewed as being open to actually discussing change. Alternately, it can be viewed as simply a rat hole to absorb dissent. It's not clear which it is, and only the actions of the IAB over time will tell. We all have one common and overriding goal: the continued and ongoing growth of the Internet. Growth requires change and, as you note, organizations tend to resist change. Thus, if the IETF is not careful, it is well positioned to inhibit the growth of the Internet and thus become self-defeating. As stewards of the IETF, we must continue be watchful of this trap and encourage innovation, even when it opposes the status quo and political forces within the organization. That is our responsibility to one another and to each and every Internet user, past, present and future. Respectfully yours, Tony _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sat Oct 29 20:29:15 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EW14U-0005BZ-PW; Sat, 29 Oct 2005 20:29:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EW14S-0005BJ-HW for architecture-discuss@megatron.ietf.org; Sat, 29 Oct 2005 20:29:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02882 for ; Sat, 29 Oct 2005 20:28:54 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EW1IK-0003l7-VN for architecture-discuss@ietf.org; Sat, 29 Oct 2005 20:43:33 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EW14D-0002y1-Me; Sat, 29 Oct 2005 17:28:58 -0700 Message-Id: <6.2.3.4.2.20051029205005.0426deb0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Sat, 29 Oct 2005 20:52:04 +0200 To: Harald Tveit Alvestrand , Pekka Savola , Tony Li From: "JFC (Jefsey) Morfin" Subject: Re: Sources of architectural change (Re: [Architecture-discuss] Mobility and multi-homing) In-Reply-To: References: <20051027122404.F31AA86AEE@mercury.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.7 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Noel Chiappa , architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org At 19:48 29/10/2005, Harald Tveit Alvestrand wrote: >It's been clear to me for years that fundamental architectural >*change* can only come about in the same way that the Internet itself did: > >Some people get together and work out what to aim for, and DO IT; >then, having proved that it can work, they turn around and push it >out into an uncaring and hostile world. Harald, Allways agreed with you here. This is why I push out my globalisation approach aside of yours, into an uncaring IETF and a favorable world. >What the IETF with its consensus principle can do is to *protect* an >architecture - against both those who would change it in "bad" ways >and against those who would apply "minor" changes without thinking >about its result - this leads to the IETF, at its best, being an >effective body for enacting minor changes and extensions to an >architecture with reasonable thought about the consequences. This list is IAB's. If the result is the same it will demonstrate the split between, at leat some, users and the IETF is too deep for a patch. This would acknowledge a balkanisation divide in the architecture itself. Don't kill my last hopes. >But those who expect *fundamental* change to be *started* within >*any* established organization understand neither organizations nor >human nature. The fundamental changes I look for are simplification in the low layers for a more solid trunc, and architectural development in user layers for new branches. This will result in fundamental changes in the way to use the networks, not in their current architecture. Question: is this for IAB/IETF? Reponses will be on this list and at PESCI. My 2 euro cent of hope. jfc _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss From architecture-discuss-bounces@ietf.org Sun Oct 30 18:19:53 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWMSv-00041F-EE; Sun, 30 Oct 2005 18:19:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWMSs-00041A-K8 for architecture-discuss@megatron.ietf.org; Sun, 30 Oct 2005 18:19:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24597 for ; Sun, 30 Oct 2005 18:19:32 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWMgw-0005B1-2N for architecture-discuss@ietf.org; Sun, 30 Oct 2005 18:34:23 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 30 Oct 2005 18:19:41 -0500 X-IronPort-AV: i="3.97,267,1125892800"; d="scan'208"; a="74745758:sNHT26337986" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9UNJbEi009559; Sun, 30 Oct 2005 18:19:38 -0500 (EST) Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 30 Oct 2005 18:19:37 -0500 Received: from 10.21.123.129 ([10.21.123.129]) by xmb-rtp-205.amer.cisco.com ([64.102.31.59]) via Exchange Front-End Server email.cisco.com ([171.70.151.174]) with Microsoft Exchange Server HTTP-DAV ; Sun, 30 Oct 2005 23:19:37 +0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sun, 30 Oct 2005 18:19:34 -0500 Subject: Re: Sources of architectural change (Re: [Architecture-discuss] Mobility and multi-homing) From: Melinda Shore To: Harald Tveit Alvestrand Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 30 Oct 2005 23:19:37.0884 (UTC) FILETIME=[659B2DC0:01C5DDA8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: architecture-discuss@ietf.org X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: architecture-discuss-bounces@ietf.org Errors-To: architecture-discuss-bounces@ietf.org On 10/29/05 12:48 PM, "Harald Tveit Alvestrand" wrote: > What the IETF with its consensus principle can do is to *protect* an > architecture - against both those who would change it in "bad" ways and > against those who would apply "minor" changes without thinking about its > result Unfortunately I don't think that's true, regardless of the decision- making mechanism. An awful lot of the things that are being done that I think are causing problems are being driven by concerns that aren't strictly technical - revenue models, cost of ownership issues, deployment management (it's a heck of a lot easier to drop a new box into the network than it is to either change something that's already there or get rid of something that's already there), and so on. The NAT traversal stuff would probably make a good case study of how things can go wrong. The IAB's UNSAF document should have been taken a lot more seriously than it was but now, to the extent that it's being thought about at all, it's being thought about as just a hoop to jump through to get some documents published. The industry just got out in front, jumped on some technology we all knew was flawed, and the stuff got published. My .signature elsewhere says "software longa, hardware brevis," and I hope that one thing that we can agree to in the future is that no badly flawed short-term technologies are going to squeak through under the assumption that something more correct is going to be published later and will supercede it, 'cause that probably isn't going to happen. Melinda _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www1.ietf.org/mailman/listinfo/architecture-discuss