From owner-multi6@ops.ietf.org Mon Dec 2 07:21:27 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11326 for ; Mon, 2 Dec 2002 07:21:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18IpaI-000Cxh-00 for multi6-data@psg.com; Mon, 02 Dec 2002 04:21:58 -0800 Received: from tlp1.cobweb.autonomica.se ([130.244.10.138] helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #2) id 18IpaG-000CxU-00 for multi6@ops.ietf.org; Mon, 02 Dec 2002 04:21:56 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (8.12.2/8.10.2) with ESMTP id gB2CMOb8001979; Mon, 2 Dec 2002 13:22:24 +0100 (CET) Date: Mon, 2 Dec 2002 11:01:45 +0100 Subject: Re: Multihoming and what we discussed in Atlanta Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: <20021126233642.U9655-100000@sequoia.muada.com> Message-Id: <107E4436-05DD-11D7-B37A-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > - it's = "it is", its = "owned by it" Thanks! > - maybe leave the first few sections out until you're ready to find a > wider audience as this is extremely familiar... True but I prefer to give some background. > - better explain what you mean by not aggregate in 5.1. Do you mean > they > shouldn't announce a less specific, or that they should announce the > /48? Or both? I actually mean both. I will update that. >> Browsing through mail I though I saw something similar from Iljitsch. >> If that is the case let's see if we can merge something. > > I discuss several other methods to achieve the same thing. Let me know > which one you think can be included in this draft. If that's all or > nearly all of them, it makes sense to merge. > See comments on your email. Best regards, - kurtis - From owner-multi6@ops.ietf.org Mon Dec 2 10:32:18 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19672 for ; Mon, 2 Dec 2002 10:32:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18IsZM-000J9b-00 for multi6-data@psg.com; Mon, 02 Dec 2002 07:33:12 -0800 Received: from mh2dmz1.bloomberg.com ([199.172.169.37]) by psg.com with esmtp (Exim 3.36 #2) id 18IsZJ-000J9P-00 for multi6@ops.ietf.org; Mon, 02 Dec 2002 07:33:09 -0800 Received: from ns2.bloomberg.com by mh2dmz1.bloomberg.com with ESMTP; Mon, 2 Dec 2002 10:33:06 -0500 Received: from ny11012205a (aisaac-pc1 [160.43.2.152]) by ns2.bloomberg.com (8.9.3/8.9.3) with SMTP id KAA12407; Mon, 2 Dec 2002 10:33:05 -0500 (EST) From: "Aldrin Isaac" To: "Kurt Erik Lindqvist" , Subject: RE: Multihoming and what we discussed in Atlanta Date: Mon, 2 Dec 2002 10:33:15 -0500 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <851D2D7C-010C-11D7-9767-000393AB1404@kurtis.pp.se> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01,USER_AGENT_OUTLOOK version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit % draft-kurtis-multihoming-longprefix-00 % 6.1 Aggregation effects with the current allocation policies % .... % improved. With the proposal for multihoming IPv6 as described in % this document, the potential for the same routing table growth % explosion as we have today exists. However, given that the current % allocation blocks to ISPs are blocks with 32 bit long prefixes, one % of these blocks will fit the current address assignments of most % ISPs. This means that the routing table will be inherently small to % start with. Even if all ASes that are active today where to announce % IPv6 address space, it would only be around 14 000 routes. Almost % 90% less of the current routing table. This means that we have quite % a lot of breathing space before we starting running into the same % scalability problems as today. This is due to the current % allocations. Doing multihoming by announcing longer prefixes out of % allocated blocks will make the routing larger but looking at the % current amount of multihomed networks, this should not pose a % problem. IMHO, for this form of multihoming, multihomers should *not* use prefixes that that are part of the allocation of any of the ISPs over which it multihomes. A multihomers address should come from well-known managed PI blocks. Using part of an ISPs allocation results in inefficient routing, unneccessary fragmentation of ISP address blocks, and more complex policies for ISP peering. -- aldrin From owner-multi6@ops.ietf.org Tue Dec 3 13:28:03 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08296 for ; Tue, 3 Dec 2002 13:28:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JHmL-000Ff9-00 for multi6-data@psg.com; Tue, 03 Dec 2002 10:28:17 -0800 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #2) id 18JHlp-000FeC-00 for multi6@ops.ietf.org; Tue, 03 Dec 2002 10:27:45 -0800 Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Tue, 03 Dec 2002 10:27:46 -0800 Reply-To: From: "Tony Hain" To: "'Tony Li'" , Subject: RE: Next question... Date: Tue, 3 Dec 2002 10:27:34 -0800 Message-ID: <01f601c29af9$a676c150$237ba8c0@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA08296 Tony Li wrote: > Folks, > > Have we reached consensus that we need to deal with > multihoming policies? I thought that was one of the goals of the requirements document... > And do we agree that doing so at the > per-host level doesn't scale? > My interpretation of 'doesn't scale' in this case is that the host policies are not managed by the network infrastructure team, therefore per-host can't be part of the multi-homing solution using current management tools and divisions of labor. If that interpretation is correct, a simple non-technical approach like having the host and network management teams actually talk to each other would remove the scaling issue. Other approaches like better management tools would also help. Removing per-host from the solution set may make it easier for the network focused participants to reach consensus, but it blinds the host & applications from the alternatives. Scaling in this case depends on your perspective. From the app point of view, a network that does not react appropriately is useless for anything more than a bit-pipe and will be routed around or tunneled over (re: POTS, ATM, ...). Managing fine-grained TE aspects of uncoordinated traffic sources with an IGP sounds like a nice research topic. Tony From owner-multi6@ops.ietf.org Tue Dec 3 13:33:36 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08765 for ; Tue, 3 Dec 2002 13:33:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JHt0-000G9u-00 for multi6-data@psg.com; Tue, 03 Dec 2002 10:35:10 -0800 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #2) id 18JHsU-000G6B-00 for multi6@ops.ietf.org; Tue, 03 Dec 2002 10:34:39 -0800 Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Tue, 03 Dec 2002 10:34:40 -0800 Reply-To: From: "Tony Hain" To: "'marcelo bagnulo'" , "'Tony Li'" , "'Michael H. Lambert'" Cc: Subject: RE: Consensus check Date: Tue, 3 Dec 2002 10:34:27 -0800 Message-ID: <01f701c29afa$9cc84fb0$237ba8c0@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit marcelo bagnulo wrote: > ... > I mean, the main objection that i have heard is that > providers would have to carry packets for non customers, but > in your case (if i understand the scenario correctly) it > seems like a cooperative environement, so i would say that > this is acceptable, rigth? > This depends on the relationship of the exchange to the transit provider. If the exchange is just a netural interconnect, you are correct, a transit provider could end up carrying traffic for a non-customer. BUT if the exchange were a customer of the transit providers, the non-customer problem disappears. Tony From owner-multi6@ops.ietf.org Tue Dec 3 23:57:51 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03295 for ; Tue, 3 Dec 2002 23:57:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JRbh-0009oD-00 for multi6-data@psg.com; Tue, 03 Dec 2002 20:57:57 -0800 Received: from dhcp1.kurtis.pp.se ([195.43.225.70] helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #2) id 18JRbW-0009nZ-00 for multi6@ops.ietf.org; Tue, 03 Dec 2002 20:57:46 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (8.12.2/8.10.2) with ESMTP id gB44wGwt000541; Wed, 4 Dec 2002 05:58:16 +0100 (CET) Date: Tue, 3 Dec 2002 11:03:42 +0100 Subject: Re: Router solutions Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: Iljitsch van Beijnum , To: Joe Abley From: Kurt Erik Lindqvist In-Reply-To: <90718E2F-0234-11D7-ADCE-00039312C852@automagic.org> Message-Id: <80E91C96-06A6-11D7-B37A-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) X-Spam-Status: No, hits=-2.4 required=5.0 tests=DATE_IN_PAST_12_24,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> I think this is text is addressing several questions. >> >> I think it would be a good starting point for the WG item describing >> how multihoming is done today (but isn't there such a document >> already?). > > I made a first cut as such a document by ripping relevant text out of > the -01 requirements draft, but it was really rough and needs lots of > work. There were a few operators and researchers at the time who > offered to lend their experience to the draft to make it more useful, > but those offers of assistance didn't materalise at the time for one > reason or another (the rapid transition from room-to-think to > fear-of-being-laid-off at the time had more than a little to do with > it). > > I would be very happy to lend time to making that document useful, if > there is interest in doing so (and in contributing opinions and text > to it). I'm not sufficiently naive to think that consensus on such a > document would be a trivial thing to achieve, but I suspect it might > be easier to obtain than consensus on the requirements draft :) > I would suggest to incorporate the text from Iljitsch document if needed, and I would be willing to contribute as well. BTW, what is the name of the document? - kurtis - From owner-multi6@ops.ietf.org Tue Dec 3 23:58:03 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03312 for ; Tue, 3 Dec 2002 23:58:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JRbn-0009oZ-00 for multi6-data@psg.com; Tue, 03 Dec 2002 20:58:03 -0800 Received: from dhcp1.kurtis.pp.se ([195.43.225.70] helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #2) id 18JRbk-0009oN-00 for multi6@ops.ietf.org; Tue, 03 Dec 2002 20:58:01 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (8.12.2/8.10.2) with ESMTP id gB44wWwt000571; Wed, 4 Dec 2002 05:58:32 +0100 (CET) Date: Tue, 3 Dec 2002 16:46:36 +0100 Subject: Re: Site local Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: "Brian E Carpenter" , "Iljitsch van Beijnum" , To: "Tony Li" From: Kurt Erik Lindqvist In-Reply-To: Message-Id: <67ED63BC-06D6-11D7-B37A-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) X-Spam-Status: No, hits=-4.0 required=5.0 tests=DATE_IN_PAST_12_24,EMAIL_ATTRIBUTION,IN_REP_TO, QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On fredag, nov 29, 2002, at 05:38 Europe/Stockholm, Tony Li wrote: > > Hope you're feeling better. Yupp! > In particular, what I was suggesting was that the separation of > locators and identifiers would greatly simplify the (perceived) > problem that is driving site local addresses anyway. A site would > get global identifiers immediately and then when they connect to > the net (or change connections), they would only change the locator > part. > > By itself, that seems like a lesser win. However, if the architecture > is tweaked so that the site's global locators are only known to the > site's border routers, then the only changes that need to be done > are very trivial. > > In short, someone else has another motivation for the same > architectural > flexibility that a group here has been asking for all along. Ok, I am more or less with the idea of locator+identifier. What I am worried about is the effects of this on the applications. My main reason for being against anything that could lead down a NAT road (and I am worried that any attempt besides assigning global addresses everywhere will lead there) is that I have seen the effects this has had on delaying deployment of new services and creating problems at end sites. - kurtis - From owner-multi6@ops.ietf.org Tue Dec 3 23:58:18 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03329 for ; Tue, 3 Dec 2002 23:58:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JRbZ-0009nu-00 for multi6-data@psg.com; Tue, 03 Dec 2002 20:57:49 -0800 Received: from dhcp1.kurtis.pp.se ([195.43.225.70] helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #2) id 18JRbW-0009nY-00 for multi6@ops.ietf.org; Tue, 03 Dec 2002 20:57:46 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (8.12.2/8.10.2) with ESMTP id gB44wHwt000544; Wed, 4 Dec 2002 05:58:17 +0100 (CET) Date: Tue, 3 Dec 2002 11:17:51 +0100 Subject: Re: Router solutions Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: <20021127224139.I11464-100000@sequoia.muada.com> Message-Id: <7A94EE33-06A8-11D7-B37A-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) X-Spam-Status: No, hits=-2.4 required=5.0 tests=DATE_IN_PAST_12_24,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> I think it would be a good starting point for the WG item describing >> how multihoming is done today (but isn't there such a document >> already?). As for the really short term solution that Thomas described >> in Atlanta I think we need to nail it down more and stick to one >> solution. > > Maybe. But I think selecting one without even discussing it is Ofcourse not, this is the IETF :) > premature. Also, I don't think PA hole shooting is the best option, > especially since it requires renumbering when changing (primary) ISPs. > It's not the best, but it is IMO without question the fastest way to get started and would already help solve several of the problems we are seeing and it does not require any implementation, and best of all - it has a back out option. Best regards, - kurtis - From owner-multi6@ops.ietf.org Tue Dec 3 23:58:25 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03343 for ; Tue, 3 Dec 2002 23:58:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JRcO-0009pp-00 for multi6-data@psg.com; Tue, 03 Dec 2002 20:58:40 -0800 Received: from dhcp1.kurtis.pp.se ([195.43.225.70] helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #2) id 18JRcM-0009pa-00 for multi6@ops.ietf.org; Tue, 03 Dec 2002 20:58:38 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (8.12.2/8.10.2) with ESMTP id gB44x2wt000624; Wed, 4 Dec 2002 05:59:02 +0100 (CET) Date: Wed, 4 Dec 2002 05:58:21 +0100 Subject: Re: Multihoming and what we discussed in Atlanta Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: To: "Aldrin Isaac" From: Kurt Erik Lindqvist In-Reply-To: Message-Id: <0339B34C-0745-11D7-A3F3-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > IMHO, for this form of multihoming, multihomers should *not* use > prefixes that that are part of the allocation of any of the ISPs over > which it multihomes. A multihomers address should come from > well-known managed PI blocks. Using part of an ISPs allocation > results in inefficient routing, unneccessary fragmentation of ISP > address blocks, and more complex policies for ISP peering. What do we gain with having a dedicated PI block? Except administrative overhead. In what way will routing be more efficient just because the addresses are from a dedicated block? Why would the the ISP peering policy become more complex? On a side note, I have handled peering issues on one of the Tier-1 transit free providers, this would not have been an issue for us. - kurtis - From owner-multi6@ops.ietf.org Tue Dec 3 23:58:48 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03357 for ; Tue, 3 Dec 2002 23:58:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JRbi-0009oH-00 for multi6-data@psg.com; Tue, 03 Dec 2002 20:57:58 -0800 Received: from dhcp1.kurtis.pp.se ([195.43.225.70] helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #2) id 18JRbf-0009nw-00 for multi6@ops.ietf.org; Tue, 03 Dec 2002 20:57:55 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (8.12.2/8.10.2) with ESMTP id gB44wRwt000559; Wed, 4 Dec 2002 05:58:27 +0100 (CET) Date: Tue, 3 Dec 2002 14:04:49 +0100 Subject: Re: Site local Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: multi6@ops.ietf.org To: Brian E Carpenter From: Kurt Erik Lindqvist In-Reply-To: <3DE5F88A.D3FCF78C@hursley.ibm.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) X-Spam-Status: No, hits=-2.7 required=5.0 tests=DATE_IN_PAST_12_24,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> ..I am behind on email due to flu but one thing I haven't figured out >> in this "GUPI" thread....what would be the difference to the PIs we >> have today? Aren't we trying to work around RIR policy with address >> architecture? > > Firstly, we have no PIs today in IPv6. If you're referring to pre-CIDR > IPv4 prefixes, I think the difference is that people believe the > scaling > issues with the DFZ will severely limit the ISP's ability to route > non-aggregatable IPv6 prefixes, however much money they are paid to do > so I was actually referring to IPv4 PI space. That is not necessarily pre-CIDR, you can still get it. You are right in saying that it will affect the DFZ size, but that is a problem we are dealing with today as well. Notice that there are around 14000 ASes, assume they are all LIRs they will all get a /32, that gives us 14000 routes. Then we have a scaling factor of ten to start with there already. More, I don't think that any of these solutions with PIs that are routed will come for free. There will be a cost from the operators for routing any of this. - kurtis - From owner-multi6@ops.ietf.org Tue Dec 3 23:58:55 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03372 for ; Tue, 3 Dec 2002 23:58:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JRbx-0009or-00 for multi6-data@psg.com; Tue, 03 Dec 2002 20:58:13 -0800 Received: from dhcp1.kurtis.pp.se ([195.43.225.70] helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #2) id 18JRbu-0009oe-00 for multi6@ops.ietf.org; Tue, 03 Dec 2002 20:58:11 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (8.12.2/8.10.2) with ESMTP id gB44wdwt000595; Wed, 4 Dec 2002 05:58:39 +0100 (CET) Date: Tue, 3 Dec 2002 20:22:55 +0100 Subject: Re: (ipv6mh) the Rebel Alliance meetings in Atlanta (long) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: ipv6mh , multi6@ops.ietf.org To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: <20021202130630.L20423-100000@sequoia.muada.com> Message-Id: X-Mailer: Apple Mail (2.548) X-Spam-Status: No, hits=-3.4 required=5.0 tests=DATE_IN_PAST_06_12,EMAIL_ATTRIBUTION,HOT_NASTY,IN_REP_TO, QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA03372 (I trimmed the CC list...) On måndag, dec 2, 2002, at 13:15 Europe/Stockholm, Iljitsch van Beijnum wrote: > On Thu, 28 Nov 2002, Kurt Erik Lindqvist wrote: > >>> The main issue is, devise an exit plan before you let stuff pollute >>> the >>> routing tables: part of the consensus should be an agreement on how >>> the >>> advertisements will be limited in the future, so that only very few >>> sites get advertised that way. For example, maybe we should only >>> agree >>> that a given ISP can only allocate a limited number of "routable >>> /48". >>> Maybe a condition for accepting such a BGP advertisement will be that >>> the /48 should be of the form xxxx:xxxx:000y, where xxxx:xxxx is the >>> /32 >>> allocated to the provider -- this would limit inflation to 16 entries >>> per provider... > >> I think that is to few, but the concept is actually pretty nice. Then >> again, I am not sure it will have much effect. > > X per ISP is not going to work as there are global ISPs and very, very > local ones. Well, what I meant was that the day an ISP run out of their PI blocks they will just continue down the address block, just as ISPs today are announcing more specifics than their RIR allocation and complaining that these are not accepted. I don't see why we think people would behave differently just because this is IPv6.... > >> Backing out is simple and will happen on it's own, as is the case >> today. > > It would be much, much better if we could agree that everyone does this > the same way. Having a route in 90% of the routers isn't much better > than having it in 100% of the routers, but being able to reach 90% of > the internet is much worse than being able to reach 100%. That is the way it works for many (perhaps most) of the multihomers today. 90% is better than the 0% we have today. Still, I agree that if we can come up with a common solution that would be better. My proposal is to accept /48 for the time being and not scale back until there is a new solution. > > If geo aggregation isn't feasible, then I think a fixed block of PI > /48s > for each RIR would be the next best option. I think that everyone can > agree that 4 or 5 x 1024 - 8192 (for a total of 4096 - 40960) routes > wouldn't be too bad if we can keep a tight lid on this. And if and when > other blocks are commisioned, people can choose to carry or filter > those, without hurting existing multihomers. > What is it that we think we gain with these specific blocks, be it for site-locals or multihoming? The number of routes are not going to be less. If the RIRs use up their current assignments -good! Then at least we have a IPv6 network from where we can start drawing conclusions. The current routing table is mostly 6bone space that is temporary and should go away. That leaves us with the ~250 sub-TLAs currently assigned. I am not worried yet. - kurtis - From owner-multi6@ops.ietf.org Wed Dec 4 03:10:00 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01696 for ; Wed, 4 Dec 2002 03:10:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JUcp-000Oq1-00 for multi6-data@psg.com; Wed, 04 Dec 2002 00:11:19 -0800 Received: from dmz1.procket.com ([65.174.124.36]) by psg.com with esmtp (Exim 3.36 #2) id 18JUcm-000OpX-00 for multi6@ops.ietf.org; Wed, 04 Dec 2002 00:11:16 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id A481223C41; Wed, 4 Dec 2002 00:10:04 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id gB48AiiI001558; Wed, 4 Dec 2002 00:10:44 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Site local Date: Wed, 4 Dec 2002 00:10:44 -0800 Message-ID: Thread-Topic: Site local Thread-Index: AcKbUb8GYTTa+bNASwqaG2Ol8PeeXAAFnqRA From: "Tony Li" To: "Kurt Erik Lindqvist" Cc: "Brian E Carpenter" , "Iljitsch van Beijnum" , X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA01696 Kurt, | Ok, I am more or less with the idea of locator+identifier. | What I am | worried about is the effects of this on the applications. | | My main reason for being against anything that could lead | down a NAT | road (and I am worried that any attempt besides assigning global | addresses everywhere will lead there) is that I have seen | the effects | this has had on delaying deployment of new services and creating | problems at end sites. Well, let's think about this a bit... Let's assume that the transport layer is going to use only the identifier, not the locator. So, for example, the identifier is part of the TCP pseudo-header. We also need to assume that the (architecturally evil) applications that today carry around IPv4 addresses would morph into carrying around identifiers, but NOT locators. If you're willing to stipulate to that, then NAT is not at all necessary and the border routers do NOT need to know about specific applications. Make sense? Tony From owner-multi6@ops.ietf.org Wed Dec 4 03:10:57 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01738 for ; Wed, 4 Dec 2002 03:10:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JUeu-000OsD-00 for multi6-data@psg.com; Wed, 04 Dec 2002 00:13:28 -0800 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #2) id 18JUes-000OrV-00 for multi6@ops.ietf.org; Wed, 04 Dec 2002 00:13:26 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 734AC35095; Wed, 4 Dec 2002 00:22:42 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id gB48ChiI001646; Wed, 4 Dec 2002 00:12:43 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Consensus check Date: Wed, 4 Dec 2002 00:12:43 -0800 Message-ID: Thread-Topic: Consensus check Thread-Index: AcKa+qkEhQ2MpMZkTNuT3M85snNxggAchYOA From: "Tony Li" To: , "marcelo bagnulo" , "Michael H. Lambert" Cc: X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA01738 I'm unaware of any exchanges that actually buy transit. In fact, the exchanges that I know of are selling either facilities space or switch port bandwidth. Tony | marcelo bagnulo wrote: | > ... | > I mean, the main objection that i have heard is that | > providers would have to carry packets for non customers, but | > in your case (if i understand the scenario correctly) it | > seems like a cooperative environement, so i would say that | > this is acceptable, rigth? | > | | This depends on the relationship of the exchange to the transit | provider. If the exchange is just a netural interconnect, you are | correct, a transit provider could end up carrying traffic for a | non-customer. BUT if the exchange were a customer of the transit | providers, the non-customer problem disappears. | | Tony | | | From owner-multi6@ops.ietf.org Wed Dec 4 03:16:32 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01939 for ; Wed, 4 Dec 2002 03:16:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JUjt-000OyN-00 for multi6-data@psg.com; Wed, 04 Dec 2002 00:18:37 -0800 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #2) id 18JUjq-000Oy0-00 for multi6@ops.ietf.org; Wed, 04 Dec 2002 00:18:35 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 159FF35096; Wed, 4 Dec 2002 00:27:51 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id gB48I4iI002090; Wed, 4 Dec 2002 00:18:04 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Next question... Date: Wed, 4 Dec 2002 00:18:03 -0800 Message-ID: Thread-Topic: Next question... Thread-Index: AcKa+bZgPa4OBzKxSTqDJqTMnliOiQAczxpg From: "Tony Li" To: , X-Spam-Status: No, hits=1.6 required=5.0 tests=SPAM_PHRASE_05_08 version=2.43 X-Spam-Level: * Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA01939 Tony, | Removing per-host from the solution set ... | blinds the host | & applications from the alternatives. Well, if the host is not blind to the routing subsystem then you end up with a tight binding between the subsystems in the architecture. Not to mention the fact that the host has to maintain or refer to a great deal of state. | From the app point of view, a network | that does not | react appropriately is useless for anything more than a bit-pipe and | will be routed around or tunneled over (re: POTS, ATM, | ...). Have a network that reacts then implies that you have no visibility in the host and then have pushed the issues into the network. Am I not following you? | Managing | fine-grained TE aspects of uncoordinated traffic sources with an IGP | sounds like a nice research topic. I think that you can safely assume that I, of all people, would not recommend that. Tony From owner-multi6@ops.ietf.org Wed Dec 4 04:36:47 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03866 for ; Wed, 4 Dec 2002 04:36:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JVyV-0000UD-00 for multi6-data@psg.com; Wed, 04 Dec 2002 01:37:47 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 18JVyS-0000U0-00 for multi6@ops.ietf.org; Wed, 04 Dec 2002 01:37:45 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gB49b5p26918; Wed, 4 Dec 2002 10:37:05 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Wed, 4 Dec 2002 10:37:05 +0100 (CET) From: Iljitsch van Beijnum To: Kurt Erik Lindqvist cc: Subject: Re: Site local In-Reply-To: <67ED63BC-06D6-11D7-B37A-000393AB1404@kurtis.pp.se> Message-ID: <20021204103114.P22837-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_05_08 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 3 Dec 2002, Kurt Erik Lindqvist wrote: > Ok, I am more or less with the idea of locator+identifier. What I am > worried about is the effects of this on the applications. > My main reason for being against anything that could lead down a NAT > road (and I am worried that any attempt besides assigning global > addresses everywhere will lead there) Tony already addressed this, but let me offer a different spin: The problem with NAT is not that the addresses in the IP header are changed. The problem with NAT is that you're not talking to who you think you are talking to. And if you don't know, you can't tell someone else, so it becomes impossible to set up new connections in a different way than from the same source to the same destination as the current session. So this breaks pretty much everything except stuff that follows a simple client/server model. In a identifier/locator system, the endpoints are always aware of the identifiers. Since such a system isn't here yet, we can make this a very hard requirement. Changing the locators around is then no longer an issue. Iljitsch From owner-multi6@ops.ietf.org Wed Dec 4 04:53:19 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04127 for ; Wed, 4 Dec 2002 04:53:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JWF6-000189-00 for multi6-data@psg.com; Wed, 04 Dec 2002 01:54:56 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 18JWF2-00017s-00 for multi6@ops.ietf.org; Wed, 04 Dec 2002 01:54:52 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gB49sCY26941; Wed, 4 Dec 2002 10:54:12 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Wed, 4 Dec 2002 10:54:11 +0100 (CET) From: Iljitsch van Beijnum To: Kurt Erik Lindqvist cc: ipv6mh , Subject: Re: (ipv6mh) the Rebel Alliance meetings in Atlanta (long) In-Reply-To: Message-ID: <20021204103719.B22837-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.7 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 3 Dec 2002, Kurt Erik Lindqvist wrote: > (I trimmed the CC list...) Good, I got some of your messages three times... > > X per ISP is not going to work as there are global ISPs and very, very > > local ones. > Well, what I meant was that the day an ISP run out of their PI blocks > they will just continue down the address block, just as ISPs today are > announcing more specifics than their RIR allocation and complaining > that these are not accepted. I don't see why we think people would > behave differently just because this is IPv6.... We think that because they do. At the moment, at least. Also, we want them to, as current IPv4 routing practices aren't exactly great. On the one hand it is good that people want to keep the IPv6 routing table clean, on the other hand we don't want to be so restrictive it doesn't work. Remember that most people have a good reason to pollute the IPv4 routing table. Just not allowing this without offering alternatives isn't good enough. > > It would be much, much better if we could agree that everyone does this > > the same way. Having a route in 90% of the routers isn't much better > > than having it in 100% of the routers, but being able to reach 90% of > > the internet is much worse than being able to reach 100%. > That is the way it works for many (perhaps most) of the multihomers > today. 90% is better than the 0% we have today. Disagree. People who multihome care about their connectivity more than others. For PI, 90% isn't enough. 99% isn't even enough. On the other hand, for shooting holes in PA, having a 90% backup is probably good enough, but I'd rather have 99% or even 100%, especially if I have to eat the cost and annoyance of renumbering when changing my primary ISP. > Still, I agree that if > we can come up with a common solution that would be better. My proposal > is to accept /48 for the time being and not scale back until there is a > new solution. I could live with that if we can get consensus among operators. Without those /48s in the routing table this is still too risky as it doesn't protect you against an entire ISP going down. However, I don't think it's the best solution. Also, if we end up with a multi-address solution, it could very well be that all PA will be tied to interconnect locations. For instance, I live between two of the largest exchange points in the world: the LINX and the AMS-IX. If I were a single homed multi-address capable network I would want addresses that are always routed over the LINX and also addresses that are always routed over the AMS-IX, so I can do traffic engineering. I'm not saying we should start doing this now, but it would be good to anticipate future developments. > > If geo aggregation isn't feasible, then I think a fixed block of PI /48s > > for each RIR would be the next best option. I think that everyone can > > agree that 4 or 5 x 1024 - 8192 (for a total of 4096 - 40960) routes > > wouldn't be too bad if we can keep a tight lid on this. And if and when > > other blocks are commisioned, people can choose to carry or filter > > those, without hurting existing multihomers. > What is it that we think we gain with these specific blocks, be it for > site-locals or multihoming? The number of routes are not going to be > less. This way you can easily identify these routes with a prefix filter. I'm not saying that's always absolutely necessary, but as long as we have the choice, why not create this option? > If the RIRs use up their current assignments -good! Then at least > we have a IPv6 network from where we can start drawing conclusions. Fully agree. Iljitsch BTW, I'm writing an article about if/when IPv6 will be adopted for a Dutch magazine. I'm still looking for good quotes from IPv6-skeptics. :-) From owner-multi6@ops.ietf.org Wed Dec 4 09:31:24 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12988 for ; Wed, 4 Dec 2002 09:31:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JaZc-0007u2-00 for multi6-data@psg.com; Wed, 04 Dec 2002 06:32:24 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #2) id 18JaZY-0007tN-00 for multi6@ops.ietf.org; Wed, 04 Dec 2002 06:32:20 -0800 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id JAA07340; Wed, 4 Dec 2002 09:32:17 -0500 Date: Wed, 4 Dec 2002 09:32:17 -0500 From: "J. Noel Chiappa" Message-Id: <200212041432.JAA07340@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: Site local Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=1.6 required=5.0 tests=SPAM_PHRASE_05_08 version=2.43 X-Spam-Level: * Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Iljitsch van Beijnum > The problem with NAT is not that the addresses in the IP header are > changed. Well, that is a problem (e.g. with IPSec), but you're right, it's more of an engineering problem than an architectural one. > The problem with NAT is that you're not talking to who you think you > are talking to. And if you don't know, you can't tell someone else, so > it becomes impossible to set up new connections in a different way > than from the same source to the same destination as the current > session. Actually, it means you can't use the address namespace to tell someone else the identity of a third party. You could pass the third party's identity using some other namespace (e.g. a DNS name), which would then go through the same process of creating a forwarding tag with local scope (i.e. a NAT'ed address), and installing the necessary bindings. Which leads us to the *real* architectural problem with NAT, which is that it means that there is critical state (those bindings) stored in boxes out on the network. This hasn't proved to be a major problem so far, as most uses of NAT boxes (e.g. the one in front of the network in my house) are i) on the only path out anyway, and ii) fairly reliable. However, were we to start seeing configurations where i) there are alternate paths from the source to the destination, and ii) there is a NAT box in the path *after* the two paths split, then we'd have something of a problem. Noel From owner-multi6@ops.ietf.org Wed Dec 4 09:48:34 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14066 for ; Wed, 4 Dec 2002 09:48:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Jaqe-0008Rn-00 for multi6-data@psg.com; Wed, 04 Dec 2002 06:50:00 -0800 Received: from smtp1.extremenetworks.com ([216.52.8.6]) by psg.com with esmtp (Exim 3.36 #2) id 18JaqZ-0008Ok-00 for multi6@ops.ietf.org; Wed, 04 Dec 2002 06:49:56 -0800 Received: from extremenetworks.com (unknown [10.0.8.127]) by smtp1.extremenetworks.com (Postfix) with ESMTP id E9AC07A0F; Wed, 4 Dec 2002 06:49:19 -0800 (PST) Date: Wed, 4 Dec 2002 09:49:20 -0500 Subject: Re: ESP/AH Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: multi6@ops.ietf.org To: "J. Noel Chiappa" From: RJ Atkinson In-Reply-To: <200212041432.JAA07340@ginger.lcs.mit.edu> Message-Id: <924AFFD5-0797-11D7-9475-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, Dec 4, 2002, at 09:32 America/Montreal, J. Noel Chiappa wrote: >> From: Iljitsch van Beijnum >> The problem with NAT is not that the addresses in the IP header are >> changed. > > Well, that is a problem (e.g. with IPSec), but you're right, it's more > of an > engineering problem than an architectural one. ESP/AH do that *only* because another more suitable identifier did not exist in the Internet Architecture. If we could add such an identifier to the architecture, the logical thing would be to update ESP/AH to use that identifier (instead of using addresses) in an ESP/AH Security Association. Ran rja@extremenetworks.com From owner-multi6@ops.ietf.org Wed Dec 4 11:47:44 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21239 for ; Wed, 4 Dec 2002 11:47:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JciD-000BlT-00 for multi6-data@psg.com; Wed, 04 Dec 2002 08:49:25 -0800 Received: from fep03-mail.bloor.is.net.cable.rogers.com ([66.185.86.73]) by psg.com with esmtp (Exim 3.36 #2) id 18Jci4-000BkH-00 for multi6@ops.ietf.org; Wed, 04 Dec 2002 08:49:16 -0800 Received: from automagic.org ([24.103.90.17]) by fep03-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.05.06 201-253-122-126-106-20020509) with ESMTP id <20021204164845.NUAY4292.fep03-mail.bloor.is.net.cable.rogers.com@automagic.org>; Wed, 4 Dec 2002 11:48:45 -0500 Date: Wed, 4 Dec 2002 11:48:44 -0500 Subject: Re: Consensus check Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: , "marcelo bagnulo" , "Michael H. Lambert" , To: "Tony Li" From: Joe Abley In-Reply-To: Message-Id: <4053ABB0-07A8-11D7-AD4A-00039312C852@automagic.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) X-Authentication-Info: Submitted using SMTP AUTH PLAIN at fep03-mail.bloor.is.net.cable.rogers.com from [24.103.90.17] using ID at Wed, 4 Dec 2002 11:48:44 -0500 X-Spam-Status: No, hits=-4.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, Dec 4, 2002, at 03:12 Canada/Eastern, Tony Li wrote: > I'm unaware of any exchanges that actually buy transit. In > fact, the exchanges that I know of are selling either facilities > space or switch port bandwidth. [this is not particularly germane to the discussion, but may be interesting to someone] The LINX in London buys transit. The contracts LINX participants sign in order to connect to the exchange include requirements that routes corresponding to the numbers used to number the exchange fabrics (there are two of them) are not propagated to any other organisation. The LINX has its own AS, and originates a supernet which covers the exchange subnets. Joe From owner-multi6@ops.ietf.org Wed Dec 4 12:44:19 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24684 for ; Wed, 4 Dec 2002 12:44:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Jdb4-000Dxn-00 for multi6-data@psg.com; Wed, 04 Dec 2002 09:46:06 -0800 Received: from fep02-mail.bloor.is.net.cable.rogers.com ([66.185.86.72]) by psg.com with esmtp (Exim 3.36 #2) id 18Jdaw-000Dx4-00 for multi6@ops.ietf.org; Wed, 04 Dec 2002 09:45:58 -0800 Received: from automagic.org ([24.103.90.17]) by fep02-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.05.06 201-253-122-126-106-20020509) with ESMTP id <20021204174527.RJCN4594.fep02-mail.bloor.is.net.cable.rogers.com@automagic.org>; Wed, 4 Dec 2002 12:45:27 -0500 Date: Wed, 4 Dec 2002 12:45:26 -0500 Subject: Re: Router solutions Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: Iljitsch van Beijnum , To: Kurt Erik Lindqvist From: Joe Abley In-Reply-To: <80E91C96-06A6-11D7-B37A-000393AB1404@kurtis.pp.se> Message-Id: <2C3C9EC9-07B0-11D7-AD4A-00039312C852@automagic.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) X-Authentication-Info: Submitted using SMTP AUTH PLAIN at fep02-mail.bloor.is.net.cable.rogers.com from [24.103.90.17] using ID at Wed, 4 Dec 2002 12:45:27 -0500 X-Spam-Status: No, hits=-4.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tuesday, Dec 3, 2002, at 05:03 Canada/Eastern, Kurt Erik Lindqvist wrote: >>> I think this is text is addressing several questions. >>> >>> I think it would be a good starting point for the WG item describing >>> how multihoming is done today (but isn't there such a document >>> already?). >> >> I made a first cut as such a document by ripping relevant text out of >> the -01 requirements draft, but it was really rough and needs lots of >> work. There were a few operators and researchers at the time who >> offered to lend their experience to the draft to make it more useful, >> but those offers of assistance didn't materalise at the time for one >> reason or another (the rapid transition from room-to-think to >> fear-of-being-laid-off at the time had more than a little to do with >> it). >> >> I would be very happy to lend time to making that document useful, if >> there is interest in doing so (and in contributing opinions and text >> to it). I'm not sufficiently naive to think that consensus on such a >> document would be a trivial thing to achieve, but I suspect it might >> be easier to obtain than consensus on the requirements draft :) >> > > I would suggest to incorporate the text from Iljitsch document if > needed, and I would be willing to contribute as well. > > BTW, what is the name of the document? Iljitsch's document is here: http://www.muada.com/routersol.txt The document I mentioned is here: http://www.potaroo.net/ietf/xld-ids/draft-ietf-multi6-v4-multihoming- 00.txt I had hoped to find time to work on merging these already, but that hasn't happened yet. I should have time before the end of the week, but if anybody else feels like having a go before then they should feel very welcome. Joe From owner-multi6@ops.ietf.org Wed Dec 4 14:28:12 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29723 for ; Wed, 4 Dec 2002 14:28:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JfDQ-000Hio-00 for multi6-data@psg.com; Wed, 04 Dec 2002 11:29:48 -0800 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #2) id 18JfDN-000Hib-00 for multi6@ops.ietf.org; Wed, 04 Dec 2002 11:29:45 -0800 Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 04 Dec 2002 11:29:49 -0800 Reply-To: From: "Tony Hain" To: "'Tony Li'" , Subject: RE: Next question... Date: Wed, 4 Dec 2002 11:29:33 -0800 Message-ID: <02dd01c29bcb$79472fd0$237ba8c0@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal X-Spam-Status: No, hits=-0.5 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA29723 Tony Li wrote: > Tony, > > | Removing per-host from the solution set ... > | blinds the host > | & applications from the alternatives. > > > Well, if the host is not blind to the routing subsystem then you > end up with a tight binding between the subsystems in the > architecture. Not to mention the fact that the host has to > maintain or refer to a great deal of state. There is a difference between the host being aware of the routing subsystem, and being aware of alternative locators. Yes the host has to maintain state, but not much more than it would anyway, and the overall system scales much better if state maintenance is at the edge rather than somewhere in the middle. > > > | From the app point of view, a network > | that does not > | react appropriately is useless for anything more than a > bit-pipe and > | will be routed around or tunneled over (re: POTS, ATM, > | ...). > > > Have a network that reacts then implies that you have no > visibility in the > host and then have pushed the issues into the network. Am I > not following > you? I didn't do a very good job of clearly making the point... ;) In the cases where the multi-homing approach is to mask alternatives from the host, if the network has locked on a path that is unacceptable to the application, there is no way to fix it. In the case where the host is aware of alternative locators, it has the option to walk the list until it finds an acceptable set. It doesn't need to know the details of the path and be tightly interlocked with routing, but it does need an option to signal the routing system to make a different choice. The only current mechanism the host has to signal the routing system is choice of locators. > > > | Managing > | fine-grained TE aspects of uncoordinated traffic sources > with an IGP > | sounds like a nice research topic. > > > I think that you can safely assume that I, of all people, would not > recommend that. I was not suggesting you would, so much as reacting to other comments in the thread where TE appeared to be a goal. The theme seemed to be that we have to do TE in the local network, but we refuse to let the hosts play any part because they are not managed by the network gods. It is a fine thing that the goal of TE is to manage resources, but it is often the case that people forget that the role of the network is to deliver the expected service to an application. If the applications are effectively uncoordinated traffic sources, it is challenging to figure out a way to deliver the expected service to every app. Tony > > Tony > From owner-multi6@ops.ietf.org Wed Dec 4 18:56:07 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11095 for ; Wed, 4 Dec 2002 18:56:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JjO8-0005gG-00 for multi6-data@psg.com; Wed, 04 Dec 2002 15:57:08 -0800 Received: from mh1dmz1.bloomberg.com ([199.172.169.36]) by psg.com with esmtp (Exim 3.36 #2) id 18JjO1-0005fy-00 for multi6@ops.ietf.org; Wed, 04 Dec 2002 15:57:02 -0800 Received: from ns2.bloomberg.com by mh1dmz1.bloomberg.com with ESMTP; Wed, 4 Dec 2002 18:56:56 -0500 Received: from ny11012205a (aisaac-pc1 [160.43.2.152]) by ns2.bloomberg.com (8.9.3/8.9.3) with SMTP id SAA00108; Wed, 4 Dec 2002 18:56:54 -0500 (EST) From: "Aldrin Isaac" To: "Kurt Erik Lindqvist" Cc: Subject: RE: Multihoming and what we discussed in Atlanta Date: Wed, 4 Dec 2002 18:56:51 -0500 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <0339B34C-0745-11D7-A3F3-000393AB1404@kurtis.pp.se> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01,USER_AGENT_OUTLOOK version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit % From: Kurt Erik Lindqvist [mailto:kurtis@kurtis.pp.se] % Sent: Tuesday, December 03, 2002 11:58 PM % Subject: Re: Multihoming and what we discussed in Atlanta % % % > IMHO, for this form of multihoming, multihomers should *not* use % > prefixes that that are part of the allocation of any of the ISPs over % > which it multihomes. A multihomers address should come from % > well-known managed PI blocks. Using part of an ISPs allocation % > results in inefficient routing, unneccessary fragmentation of ISP % > address blocks, and more complex policies for ISP peering. % % What do we gain with having a dedicated PI block? Except % administrative overhead. In what way will routing be more % efficient just because the addresses are from a dedicated block? It's more administrative overhead for address registries, but that's what they're there to do. Having separate space for multihomers makes it possible for an ISP to avoid having to identify it's multihoming customers that are not addressed with it's allocation to it's peers. Assume a customer (1.) addresses with a /48 from ISP-A who's /32 is announced as /32 to his peers (2.) customer advertises this /48 to ISP-B (3.) ISP-B must advertise this /48 to his peers for multihoming to work for customer. If customers intention was to solicit traffic over link from ISP-A, he can't since his /48 is more specifically routed over ISP-B. This problem and other's caused by ISPs aggregating routes is what I refer to as inefficient routing. If customer had a PI /48 (from well-known limited PI blocks) which he advertised to both ISP-A and ISP-B, routing will be more efficient since ISPs know not to aggregate these blocks and therefore there is end-to-end transparency for customer's /48 route over the Internet. These blocks are easily identified with a prefix filter. If these PI blocks are limited, say to 2^16 well-known /48s, DFZ growth due to multihoming can be controlled and registries won't have too much administrative work. -- aldrin From owner-multi6@ops.ietf.org Thu Dec 5 02:24:57 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02640 for ; Thu, 5 Dec 2002 02:24:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JqO2-0008F5-00 for multi6-data@psg.com; Wed, 04 Dec 2002 23:25:30 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18JqO0-00083q-00 for multi6@ops.ietf.org; Wed, 04 Dec 2002 23:25:28 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gB57NV025006; Thu, 5 Dec 2002 09:23:31 +0200 Date: Thu, 5 Dec 2002 09:23:31 +0200 (EET) From: Pekka Savola To: Kurt Erik Lindqvist cc: Iljitsch van Beijnum , ipv6mh , Subject: same or different address block for PI? [Re: (ipv6mh) the Rebel Alliance meetings in Atlanta (long)] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 3 Dec 2002, Kurt Erik Lindqvist wrote: > What is it that we think we gain with these specific blocks, be it for > site-locals or multihoming? The number of routes are not going to be > less. If the RIRs use up their current assignments -good! Then at least > we have a IPv6 network from where we can start drawing conclusions. The > current routing table is mostly 6bone space that is temporary and > should go away. That leaves us with the ~250 sub-TLAs currently > assigned. I am not worried yet. If PI allocations are from a specific block, advertisements from there can be denied very easily everywhere in DFZ, leaving just private arrangements. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-multi6@ops.ietf.org Thu Dec 5 05:51:20 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07153 for ; Thu, 5 Dec 2002 05:51:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Jtd2-000Fy1-00 for multi6-data@psg.com; Thu, 05 Dec 2002 02:53:12 -0800 Received: from node147c0.a2000.nl ([24.132.71.192] helo=kirk.rvdp.org) by psg.com with esmtp (Exim 3.36 #2) id 18Jtcx-000Fxl-00 for multi6@ops.ietf.org; Thu, 05 Dec 2002 02:53:07 -0800 Received: (from rvdp@localhost) by kirk.rvdp.org (8.11.6/8.11.6) id gB5AqW607224; Thu, 5 Dec 2002 11:52:32 +0100 (CET) Date: Thu, 5 Dec 2002 11:52:32 +0100 From: Ronald van der Pol To: Iljitsch van Beijnum Cc: Kurt Erik Lindqvist , ipv6mh , multi6@ops.ietf.org Subject: Re: (ipv6mh) the Rebel Alliance meetings in Atlanta (long) Message-ID: <20021205105232.GA6682@rvdp.org> References: <20021204103719.B22837-100000@sequoia.muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021204103719.B22837-100000@sequoia.muada.com> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-4.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, Dec 04, 2002 at 10:54:11 +0100, Iljitsch van Beijnum wrote: > BTW, I'm writing an article about if/when IPv6 will be adopted for a > Dutch magazine. I'm still looking for good quotes from IPv6-skeptics. :-) Wrong question. IPv6 *is* being adopted at an exponential rate. See http://www.nlnetlabs.nl/ipv6/measurements/index.en.html rvdp From owner-multi6@ops.ietf.org Thu Dec 5 06:27:04 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07839 for ; Thu, 5 Dec 2002 06:27:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JuCC-000HCW-00 for multi6-data@psg.com; Thu, 05 Dec 2002 03:29:32 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 18JuCA-000HCK-00 for multi6@ops.ietf.org; Thu, 05 Dec 2002 03:29:30 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gB5BSbC29349; Thu, 5 Dec 2002 12:28:37 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Thu, 5 Dec 2002 12:28:37 +0100 (CET) From: Iljitsch van Beijnum To: Ronald van der Pol cc: ipv6mh , Subject: Re: (ipv6mh) the Rebel Alliance meetings in Atlanta (long) In-Reply-To: <20021205105232.GA6682@rvdp.org> Message-ID: <20021205121423.D29163-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.7 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 5 Dec 2002, Ronald van der Pol wrote: > > BTW, I'm writing an article about if/when IPv6 will be adopted for a > > Dutch magazine. I'm still looking for good quotes from IPv6-skeptics. :-) > Wrong question. IPv6 *is* being adopted at an exponential rate. See > http://www.nlnetlabs.nl/ipv6/measurements/index.en.html I'm not sure what that proves... So the increase in IPv6 ASes is 50 - 100 % a year. At 100%, it will take 6 years for IPv6 to catch up with IPv4, at 50% it may never happen because of the autonomous growth in IPv4 ASes. But that's not even very important: as of this week, you may see AS12854 in the statistics. However, in IPv6 this is usually just a single box with no real services available: nothing compared with what you see if you use IPv4. At the same time, v6 is making progress all the time, and large scale adoption could happen very quickly, since most of what we need is in place or getting close. But there's no telling when this will happen. From owner-multi6@ops.ietf.org Thu Dec 5 07:09:33 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08802 for ; Thu, 5 Dec 2002 07:09:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18JurE-000Ily-00 for multi6-data@psg.com; Thu, 05 Dec 2002 04:11:56 -0800 Received: from node147c0.a2000.nl ([24.132.71.192] helo=kirk.rvdp.org) by psg.com with esmtp (Exim 3.36 #2) id 18JurB-000Ilc-00 for multi6@ops.ietf.org; Thu, 05 Dec 2002 04:11:53 -0800 Received: (from rvdp@localhost) by kirk.rvdp.org (8.11.6/8.11.6) id gB5CBne07639; Thu, 5 Dec 2002 13:11:49 +0100 (CET) Date: Thu, 5 Dec 2002 13:11:49 +0100 From: Ronald van der Pol To: Iljitsch van Beijnum Cc: Ronald van der Pol , ipv6mh , multi6@ops.ietf.org Subject: Re: (ipv6mh) the Rebel Alliance meetings in Atlanta (long) Message-ID: <20021205121149.GC6682@rvdp.org> References: <20021205105232.GA6682@rvdp.org> <20021205121423.D29163-100000@sequoia.muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021205121423.D29163-100000@sequoia.muada.com> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-4.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, Dec 05, 2002 at 12:28:37 +0100, Iljitsch van Beijnum wrote: > > Wrong question. IPv6 *is* being adopted at an exponential rate. See > > http://www.nlnetlabs.nl/ipv6/measurements/index.en.html > > I'm not sure what that proves... It shows that IPv6 is being adopted, the question you asked. You were not talking about massive deployment or comparing it with IPv4. rvdp From owner-multi6@ops.ietf.org Thu Dec 5 21:50:33 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10990 for ; Thu, 5 Dec 2002 21:50:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18K8ZW-0004iD-00 for multi6-data@psg.com; Thu, 05 Dec 2002 18:50:34 -0800 Received: from dmz1.procket.com ([65.174.124.36]) by psg.com with esmtp (Exim 3.36 #2) id 18K8Z0-0004fi-00 for multi6@ops.ietf.org; Thu, 05 Dec 2002 18:50:02 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id D8DE423C33; Thu, 5 Dec 2002 18:48:46 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id gB62nViI005289; Thu, 5 Dec 2002 18:49:31 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Next question... Date: Thu, 5 Dec 2002 18:49:31 -0800 Message-ID: Thread-Topic: Next question... Thread-Index: AcKbzF/E38n9nJP0Qqmos/211FpDQwBBOXww From: "Tony Li" To: , X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_02_03 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA10990 | There is a difference between the host being aware of the routing | subsystem, and being aware of alternative locators. Yes the | host has to | maintain state, but not much more than it would anyway, and | the overall | system scales much better if state maintenance is at the edge rather | than somewhere in the middle. Ok, so if the point is where to put locator selection policy, I think that this is a much more bounded problem. The two obvious proposals are to 1) Put the locators in the host, so that it can control which locator it wants to use. This allows the application to change locators if its service is unacceptable. 2) Put the locators in the border router. This frees the host of the management burden, but makes it somewhat harder for a site to provide site-wide policy. Note that either of these two alternatives could be enhanced by further communications. Either the border can inform the host of site policy, or the host can inform the border of its local policy. One could also do both, but this is starting to look like a dromedary. Does that about cover the high points? Tony From owner-multi6@ops.ietf.org Fri Dec 6 00:36:21 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15429 for ; Fri, 6 Dec 2002 00:36:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KBBO-000DCs-00 for multi6-data@psg.com; Thu, 05 Dec 2002 21:37:50 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.36 #2) id 18KBAt-000DBD-00 for multi6@ops.ietf.org; Thu, 05 Dec 2002 21:37:19 -0800 content-class: urn:content-classes:message Subject: RE: Next question... MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 5 Dec 2002 21:37:30 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405E514@server2000> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: Next question... Thread-Index: AcKbzF/E38n9nJP0Qqmos/211FpDQwBBOXwwAAWmyGA= From: "Michel Py" To: "Tony Li" , "Tony Hain" , X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA15429 Tony, > Tony Li wrote: > 1) Put the locators in the host, so that it can control > which locator it wants to use. This allows the > application to change locators if its service is > unacceptable. > 2) Put the locators in the border router. This frees > the host of the management burden, but makes it > somewhat harder for a site to provide site-wide > policy. Why would it be harder? For this purpose, I don't see a difference between the choice of the locator to be used and the choice of the site exit link. If the choice of the locator is based on the AS-PATH, turns out to be the same. > Note that either of these two alternatives could be > enhanced by further communications. Either the border > can inform the host of site policy, or the host can > inform the border of its local policy. One could also > do both, but this is starting to look like a dromedary. Full-duplex communications between all hosts and the routing system about policy is probably a utopia. However, some DFZ hosts feeding the routing system clues about which destination are crappy over which locators has good value. Some people will scream about hosts making routing decisions, but there are cases where this could be beneficial as apps react differently from one another. > Does that about cover the high points? Makes sense to me. Michel. From owner-multi6@ops.ietf.org Fri Dec 6 02:51:02 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28019 for ; Fri, 6 Dec 2002 02:51:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KDGa-000JDw-00 for multi6-data@psg.com; Thu, 05 Dec 2002 23:51:20 -0800 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by psg.com with esmtp (Exim 3.36 #2) id 18KDG4-000JCt-00 for multi6@ops.ietf.org; Thu, 05 Dec 2002 23:50:48 -0800 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA11941; Thu, 5 Dec 2002 23:50:16 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id gB67o7H23921; Fri, 6 Dec 2002 08:50:07 +0100 (MET) Date: Fri, 6 Dec 2002 08:46:47 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: network controls are neccessary To: Michel Py Cc: Erik Nordmark , "Craig A. Huegen" , multi6@ops.ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Status: No, hits=3.1 required=5.0 tests=NO_MX_FOR_FROM,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: *** Sender: owner-multi6@ops.ietf.org Precedence: bulk Sorry for the delayed response. > > Erik Nordmark wrote: > > For instance, would it make sense to push > > all of the rules into the hosts > > Be careful, Craig might have a heart attack just at the thought of doing > it. There would be terrible security consequences. I don't see how this > could be anything else than pushing subnet-specific rules to the hosts > that belong to the subnet. > > > or is the set of rules so large that a host-based > > solution would need to cache subsets of the rules > > on demand? > > It's not a matter of size but complexity. > > First, the hosts do not have the intelligence that routers have. For > example, how long is it going to take before all hosts implement the > equivalent of a route-map? Are you going to enable an IP phone to > process BGP communities? Pushing all the rules to hosts would imply > either: I did not suggest that hosts should run BGP. That would be completely silly. But IPv6 hosts are supposed to have a source address selection table according to a draft in the IPv6 WG (soon RFC). If the exit routing policy can be expressed with a few rules it would essentially be additional rules in that table (and a protocol by which the hosts can learn those rules). Hence my questions on the list (so far without answer) about reasonable sizes for the exit router selection policy/routes. > a) The hosts to have the same routing capabilities as routers currently > have. Sorry I don't follow the logic. The hosts don't route. Hosts with multiple source locators that talk to a node with multiple destination locators just do a selection e.g. when creating a new connection. > b) The rules have to be modified to accommodate dumber hosts. > > Second, part of the configuration of a router is the router's location, > which is implied. Pushing policies to the hosts would require a coupling > between the topological database and the routing policies that is beyond > what most large companies typically have (not to mention that it is > questionable that such a monster could be maintained). > > One in the other, the sad truth is that multiple addresses per host do > not fly in the large organization. What is not flying either is policy > that is not at the edge for egress traffic (stateful firewall issues, > etc). We have had multiple posts about this on mh. I'm not talking about today - I'm talking about a future solution which separates identifiers and locators end2end e.g. using Pekka Nikander's proposed HIP approach. In that case the administrative cost of the additional locators would be close to zero. And you could get reasonable security. > There is nothing fundamentally wrong in having multihoming schemes that > use several addresses, but this should be virtualized at the edge of the > network, which is basically what MHAP does. I think the edge thing is also important to explore in parallel with a host-based scheme. Getting a handle on the security aspects (starting with a threat analysis) for the edge solutions would be quite useful IMHO. Erik From owner-multi6@ops.ietf.org Fri Dec 6 03:40:18 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29061 for ; Fri, 6 Dec 2002 03:40:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KE4O-000LNo-00 for multi6-data@psg.com; Fri, 06 Dec 2002 00:42:48 -0800 Received: from dmz1.procket.com ([65.174.124.36]) by psg.com with esmtp (Exim 3.36 #2) id 18KE3s-000LK4-00 for multi6@ops.ietf.org; Fri, 06 Dec 2002 00:42:16 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 8B41723C33; Fri, 6 Dec 2002 00:41:02 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id gB68fgiI021338; Fri, 6 Dec 2002 00:41:42 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Next question... Date: Fri, 6 Dec 2002 00:41:42 -0800 Message-ID: Thread-Topic: Next question... Thread-Index: AcKbzF/E38n9nJP0Qqmos/211FpDQwBBOXwwAAWmyGAABsVVwA== From: "Tony Li" To: "Michel Py" , "Tony Hain" , X-Spam-Status: No, hits=0.5 required=5.0 tests=SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA29061 Michel, | > Tony Li wrote: | > 1) Put the locators in the host, so that it can control | > which locator it wants to use. This allows the | > application to change locators if its service is | > unacceptable. | > 2) Put the locators in the border router. This frees | > the host of the management burden, but makes it | > somewhat harder for a site to provide site-wide | > policy. | | Why would it be harder? For this purpose, I don't see a difference | between the choice of the locator to be used and the choice | of the site | exit link. If the choice of the locator is based on the | AS-PATH, turns | out to be the same. It's harder because as site administrator, I now need to communicate policy to each system in the enterprise. That can be daunting. Ever manage an enterprise with 2000 hosts in it? | > Note that either of these two alternatives could be | > enhanced by further communications. Either the border | > can inform the host of site policy, or the host can | > inform the border of its local policy. One could also | > do both, but this is starting to look like a dromedary. | | Full-duplex communications between all hosts and the routing system | about policy is probably a utopia. More like a nightmare. ;-) Tony From owner-multi6@ops.ietf.org Fri Dec 6 06:41:34 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02474 for ; Fri, 6 Dec 2002 06:41:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KGsa-0002Gf-00 for multi6-data@psg.com; Fri, 06 Dec 2002 03:42:48 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 18KGsX-0002GS-00 for multi6@ops.ietf.org; Fri, 06 Dec 2002 03:42:46 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gB6Bg2i31195; Fri, 6 Dec 2002 12:42:03 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Fri, 6 Dec 2002 12:42:02 +0100 (CET) From: Iljitsch van Beijnum To: Tony Li cc: , Subject: RE: Next question... In-Reply-To: Message-ID: <20021206095951.Q30032-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 5 Dec 2002, Tony Li wrote: > 1) Put the locators in the host, so that it can control which locator > it wants to use. This allows the application to change locators if > its service is unacceptable. > 2) Put the locators in the border router. This frees the host of the > management burden, but makes it somewhat harder for a site to > provide site-wide policy. > Note that either of these two alternatives could be enhanced by further > communications. Either the border can inform the host of site policy, > or the host can inform the border of its local policy. One could also > do both, but this is starting to look like a dromedary. I'd go for the dromedary. Host/router isn't the essence of the question, since if we make this for routers it can/will be easily implemented in hosts as well. If we feel the possibility of offloading this to an external box is unneeded it makes sense to take advantage of end-to-end state in the host. I think being able to offload multiaddress processing to an external box is an important feature, since that makes it possible to multihome unmodified hosts. If we want to go down this road we either ignore the hosts end-to-end state or we create (optional) mechanisms for multiaddress-aware hosts to be more involved in this within the policy limits set by edge devices. This part would be complex, but as it's optional, that isn't too huge a problem. From owner-multi6@ops.ietf.org Fri Dec 6 10:36:29 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10668 for ; Fri, 6 Dec 2002 10:36:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KKXM-000CTr-00 for multi6-data@psg.com; Fri, 06 Dec 2002 07:37:08 -0800 Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by psg.com with esmtp (Exim 3.36 #2) id 18KKXJ-000CTX-00 for multi6@ops.ietf.org; Fri, 06 Dec 2002 07:37:05 -0800 Received: from [63.113.114.131] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 4023355 for multi6@ops.ietf.org; Fri, 06 Dec 2002 10:37:03 -0500 Message-Id: <5.1.0.14.0.20021206103018.017b57f0@mail.stevecrocker.com> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 06 Dec 2002 10:35:50 -0500 To: multi6@ops.ietf.org From: "Joel M. Halpern" Subject: RE: network controls are necessary In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=2.3 required=5.0 tests=IN_REP_TO,RCVD_IN_RFCI,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: ** Sender: owner-multi6@ops.ietf.org Precedence: bulk Expecting hosts to have useful logic to perform source address selection seems a recipe for trouble in multiple regards. Recognizing and selecting link local addresses is probably not an issue. But as soon as you step beyond that, things break. They break in two different ways at once. In one regard, you end up needing significantly more logic in the host to make any kind of intelligent choice. This means more code, more state, and more things for the network administrator to configure (probably incorrectly.) Secondly, you couple the hosts into the behavior of the rest of the routing system, reducing the ability of the system to cope with changes (either network changes or protocol changes.) If we really want the hosts to make the choice (a concept I am doubtful of) I suppose we could invent a query / response protocol for the purpose of asking a routing intelligent server what source /dest pair from a given set of sources and dests would be a good pair to use. I strongly prefer the notion that other entities in the system would make the intelligent choice about the source address to use, and could change that choice as necessary. Yours, Joel M. Halpern At 08:46 AM 12/6/2002 +0100, Erik Nordmark wrote: >I did not suggest that hosts should run BGP. That would be completely silly. >But IPv6 hosts are supposed to have a source address selection table >according to a draft in the IPv6 WG (soon RFC). >If the exit routing policy can be expressed with a few rules it >would essentially be additional rules in that table (and a protocol >by which the hosts can learn those rules). >Hence my questions on the list (so far without answer) about reasonable >sizes for the exit router selection policy/routes. > > > a) The hosts to have the same routing capabilities as routers currently > > have. > >Sorry I don't follow the logic. The hosts don't route. Hosts with multiple >source locators that talk to a node with multiple destination locators >just do a selection e.g. when creating a new connection. From owner-multi6@ops.ietf.org Fri Dec 6 11:03:37 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11870 for ; Fri, 6 Dec 2002 11:03:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KKzO-000Drv-00 for multi6-data@psg.com; Fri, 06 Dec 2002 08:06:06 -0800 Received: from portal.hamachi.org ([140.239.227.17]) by psg.com with esmtp (Exim 3.36 #2) id 18KKzK-000Drj-00 for multi6@ops.ietf.org; Fri, 06 Dec 2002 08:06:03 -0800 Received: from syn.hamachi.org (localhost [127.0.0.1]) by portal.hamachi.org (Postfix) with ESMTP id 6491C17926; Fri, 6 Dec 2002 11:01:51 -0500 (EST) Received: from syn.hamachi.org (sommerfeld@localhost) by syn.hamachi.org (8.11.6/8.8.8) with ESMTP id gB6G5jO11799; Fri, 6 Dec 2002 11:05:45 -0500 (EST) Message-Id: <200212061605.gB6G5jO11799@syn.hamachi.org> From: Bill Sommerfeld To: "Joel M. Halpern" Cc: multi6@ops.ietf.org Subject: Re: network controls are necessary In-Reply-To: Message from "Joel M. Halpern" of "Fri, 06 Dec 2002 10:35:50 EST." <5.1.0.14.0.20021206103018.017b57f0@mail.stevecrocker.com> Reply-To: sommerfeld@orchard.arlington.ma.us Date: Fri, 06 Dec 2002 11:05:45 -0500 X-Spam-Status: No, hits=0.9 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_3,SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk > If we really want the hosts to make the choice (a concept I am doubtful of) > I suppose we could invent a query / response protocol for the purpose of > asking a routing intelligent server what source /dest pair from a given set > of sources and dests would be a good pair to use. one problem with that interface is that if the host determines that the recommended address pair doesn't work and wants to try something else, it has no idea whether to blacklist the source, the destination, or both, when it next asks. and it would be good for scalability if the host could know when it was appropriate to cache the results. - Bill From owner-multi6@ops.ietf.org Fri Dec 6 11:34:22 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12902 for ; Fri, 6 Dec 2002 11:34:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KLSy-000FKG-00 for multi6-data@psg.com; Fri, 06 Dec 2002 08:36:40 -0800 Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by psg.com with esmtp (Exim 3.36 #2) id 18KLSw-000FK4-00 for multi6@ops.ietf.org; Fri, 06 Dec 2002 08:36:38 -0800 Received: from [63.113.114.131] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 4023495 for multi6@ops.ietf.org; Fri, 06 Dec 2002 11:36:35 -0500 Message-Id: <5.1.0.14.0.20021206112926.02760790@mail.stevecrocker.com> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 06 Dec 2002 11:35:27 -0500 To: multi6@ops.ietf.org From: "Joel M. Halpern" Subject: Re: network controls are necessary In-Reply-To: <200212061605.gB6G5jO11799@syn.hamachi.org> References: <5.1.0.14.0.20021206103018.017b57f0@mail.stevecrocker.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=2.3 required=5.0 tests=IN_REP_TO,RCVD_IN_RFCI,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: ** Sender: owner-multi6@ops.ietf.org Precedence: bulk Thinking about this question (of what the host might know / want) I think that there are several things that should be teased apart: 1) The address pair does not work because there really is no connectivity over that path. In that case, presumably routing will catch up pretty quickly. In the mean time, it is probably unlikely that trying random combinations will produce better results. 2) The "doesn't work" is in some sense other than connectivity. This has been alluded to by some folks in the discussion. Trying to get some kind of service behavior out of address selection is clearly a matter of using the wrong tool for the wrong problem. 3) There is a corner case of some unusual failure that means that some locator for the remote host is not useable, but still appears fine in routing. The mechanisms for resolving locators ought to deal with that, not the connecting host. For clarity, I would actually prefer to have the hosts have nothing at all to do with the locator selection. The host may need a mechanism to say "this communication appears not to be working" to cause the routing system to take appropriate local steps. Yours, Joel M. Halpern At 11:05 AM 12/6/2002 -0500, Bill Sommerfeld wrote: > > If we really want the hosts to make the choice (a concept I am doubtful > of) > > I suppose we could invent a query / response protocol for the purpose of > > asking a routing intelligent server what source /dest pair from a given > set > > of sources and dests would be a good pair to use. > >one problem with that interface is that if the host determines that >the recommended address pair doesn't work and wants to try something >else, it has no idea whether to blacklist the source, the destination, >or both, when it next asks. > >and it would be good for scalability if the host could know when it >was appropriate to cache the results. > > - Bill From owner-multi6@ops.ietf.org Fri Dec 6 11:48:43 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13452 for ; Fri, 6 Dec 2002 11:48:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KLgi-000G5D-00 for multi6-data@psg.com; Fri, 06 Dec 2002 08:50:52 -0800 Received: from mail1.microsoft.com ([131.107.3.125]) by psg.com with esmtp (Exim 3.36 #2) id 18KLgD-000G2q-00 for multi6@ops.ietf.org; Fri, 06 Dec 2002 08:50:21 -0800 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Fri, 6 Dec 2002 08:49:49 -0800 Received: from 157.54.6.150 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 06 Dec 2002 08:49:49 -0800 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by INET-HUB-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Fri, 6 Dec 2002 08:49:41 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Fri, 6 Dec 2002 08:49:42 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Fri, 6 Dec 2002 08:49:51 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: network controls are necessary Date: Fri, 6 Dec 2002 08:49:46 -0800 Message-ID: Thread-Topic: network controls are necessary Thread-Index: AcKdPrYlgpboEIxbTq+Z0seYO238/gABycDw From: "Christian Huitema" To: "Joel M. Halpern" , X-OriginalArrivalTime: 06 Dec 2002 16:49:51.0758 (UTC) FILETIME=[7EEE4AE0:01C29D47] X-Spam-Status: No, hits=-0.3 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA13452 > If we really want the hosts to make the choice (a concept I am doubtful > of) > I suppose we could invent a query / response protocol for the purpose of > asking a routing intelligent server what source /dest pair from a given > set > of sources and dests would be a good pair to use. I am much more optimistic than Joel about the possibilities of hosts. The average PC has as much CPU and memory as the average router, if not more; even small appliances tend to have much more memory and CPU than the routers of yesteryears, which we trusted to make routing decisions at the time. I like the way Tony phrased the problem. I think that any solution should allow a smart host to manage the set of "locators" that it want to use. (Rant: an old tenet of networking is that a name is not an address and an address is not a route; I don't see why we would need to invent new names and refer to names as identifiers and addresses as locators.) Clearly, there is an issue with the smallest appliances, which can at best be expected to perform random choices. In most cases, it does not matter, as most of the smallish appliances communications are likely to take place inside a single site. But to be general, we need to either ensure that the default choices work, or somehow let the appliances be informed by the routing fabric. There is also an issue with policy enforcement. However, we already have mechanisms to inform the hosts: router advertisements can carry preferences for this or that prefix or router; ICMP can inform the hosts that their choices are not acceptable. In fact, ICMP can also be used from the site exit router(s) to suggest alternatives on a case by case basis. -- Christian Huitema From owner-multi6@ops.ietf.org Fri Dec 6 12:32:31 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15322 for ; Fri, 6 Dec 2002 12:32:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KMN3-000IX2-00 for multi6-data@psg.com; Fri, 06 Dec 2002 09:34:37 -0800 Received: from cyphermail.sandelman.ottawa.on.ca ([192.139.46.78] helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 3.36 #2) id 18KMMW-000IWZ-00 for multi6@ops.ietf.org; Fri, 06 Dec 2002 09:34:04 -0800 Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id gB6HWl220534 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Fri, 6 Dec 2002 12:32:48 -0500 (EST) Received: from sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id gB6HWjft009881 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Fri, 6 Dec 2002 12:32:46 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id gB6HWhGB009877 for ; Fri, 6 Dec 2002 12:32:44 -0500 Message-Id: <200212061732.gB6HWhGB009877@sandelman.ottawa.on.ca> To: multi6@ops.ietf.org Subject: Re: network controls are necessary In-reply-to: Your message of "Fri, 06 Dec 2002 10:35:50 EST." <5.1.0.14.0.20021206103018.017b57f0@mail.stevecrocker.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 06 Dec 2002 12:32:43 -0500 From: Michael Richardson X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk >>>>> "Joel" == Joel M Halpern writes: Joel> In one regard, you end up needing significantly more logic in the host to Joel> make any kind of intelligent choice. This means more code, more state, and Joel> more things for the network administrator to configure (probably incorrectly.) Joel> Secondly, you couple the hosts into the behavior of the rest of the routing Joel> system, reducing the ability of the system to cope with changes (either Joel> network changes or protocol changes.) On the other hand, it scales, and is far more friendly to end-to-end. The host already has to maintain the indexes to demux the connections, and may already have significant state invested in the connection. Joel> If we really want the hosts to make the choice (a concept I am doubtful of) Joel> I suppose we could invent a query / response protocol for the purpose of Joel> asking a routing intelligent server what source /dest pair from a given set Joel> of sources and dests would be a good pair to use. Yes, we will need such a protocol. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ From owner-multi6@ops.ietf.org Fri Dec 6 12:50:53 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16165 for ; Fri, 6 Dec 2002 12:50:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KMet-000JYy-00 for multi6-data@psg.com; Fri, 06 Dec 2002 09:53:03 -0800 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #2) id 18KMeO-000JXo-00 for multi6@ops.ietf.org; Fri, 06 Dec 2002 09:52:32 -0800 Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Fri, 06 Dec 2002 09:52:34 -0800 Reply-To: From: "Tony Hain" To: "'Joel M. Halpern'" , Subject: RE: network controls are necessary Date: Fri, 6 Dec 2002 09:52:23 -0800 Message-ID: <044901c29d50$3bd00bf0$237ba8c0@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <5.1.0.14.0.20021206103018.017b57f0@mail.stevecrocker.com> Importance: Normal X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA16165 Joel M. Halpern wrote: > ... > In one regard, you end up needing significantly more logic in > the host to make any kind of intelligent choice. By 'intelligent' you mean 'the same policy choice as the network admin', right? This is not really a technical problem as much as a domain of control problem. The address selection rules allow for local administration. So if a network manager can convince the local host manager to set source selection policy to prefer a specific order from the list of prefixes in an RA, "the intelligent thing will happen". If the network admin can't do that, the hosts are effectively uncoordinated traffic sources that any transit ISP has to deal with already. Attempting to dictate operational policy through a standards process is going to fail. > This means more code, more state, and > more things for the network administrator to configure > (probably incorrectly.) Secondly, you couple the hosts into > the behavior of the rest of the routing > system, reducing the ability of the system to cope with > changes (either > network changes or protocol changes.) This looks like a big problem to the network admin, because they are used to dealing with a few boxes, but for a host admin, this is exactly what they do. What needs to happen here is for them to work together (*gasp*). > > If we really want the hosts to make the choice (a concept I > am doubtful of) > I suppose we could invent a query / response protocol for the > purpose of > asking a routing intelligent server what source /dest pair > from a given set > of sources and dests would be a good pair to use. If you want the ability to change policy in real-time from the network, it makes much more sense to put options in the RA than create a query/response protocol. > > I strongly prefer the notion that other entities in the > system would make > the intelligent choice about the source address to use, and > could change > that choice as necessary. Even though accomplishing that will require changing all the application software globally??? Tony > > Yours, > Joel M. Halpern > > At 08:46 AM 12/6/2002 +0100, Erik Nordmark wrote: > >I did not suggest that hosts should run BGP. That would be > completely > >silly. But IPv6 hosts are supposed to have a source address > selection > >table according to a draft in the IPv6 WG (soon RFC). If the exit > >routing policy can be expressed with a few rules it would > essentially > >be additional rules in that table (and a protocol by which the hosts > >can learn those rules). Hence my questions on the list (so > far without > >answer) about reasonable sizes for the exit router selection > >policy/routes. > > > > > a) The hosts to have the same routing capabilities as routers > > > currently have. > > > >Sorry I don't follow the logic. The hosts don't route. Hosts with > >multiple source locators that talk to a node with multiple > destination > >locators just do a selection e.g. when creating a new connection. > > > From owner-multi6@ops.ietf.org Fri Dec 6 12:53:37 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16253 for ; Fri, 6 Dec 2002 12:53:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KMhk-000JlS-00 for multi6-data@psg.com; Fri, 06 Dec 2002 09:56:00 -0800 Received: from cyphermail.sandelman.ottawa.on.ca ([192.139.46.78] helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 3.36 #2) id 18KMhE-000JjR-00 for multi6@ops.ietf.org; Fri, 06 Dec 2002 09:55:28 -0800 Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id gB6Hs6220640 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Fri, 6 Dec 2002 12:54:12 -0500 (EST) Received: from sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id gB6Hs4ft010218 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Fri, 6 Dec 2002 12:54:05 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id gB6Hs3cU010214 for ; Fri, 6 Dec 2002 12:54:03 -0500 Message-Id: <200212061754.gB6Hs3cU010214@sandelman.ottawa.on.ca> To: multi6@ops.ietf.org Subject: Re: network controls are necessary In-reply-to: Your message of "Fri, 06 Dec 2002 08:49:46 PST." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 06 Dec 2002 12:54:02 -0500 From: Michael Richardson X-Spam-Status: No, hits=-1.4 required=5.0 tests=IN_REP_TO,LINES_OF_YELLING,PGP_SIGNATURE,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Christian" == Christian Huitema writes: Christian> I am much more optimistic than Joel about the possibilities of hosts. Christian> The average PC has as much CPU and memory as the average router, if not As am I. Christian> Clearly, there is an issue with the smallest appliances, which can at Christian> best be expected to perform random choices. In most cases, it does not 1) *Today's* smallest appliances rival the high end desktop systems of less than a decade ago. 2) if the defaults work okay, except during network failures, it might not matter if my gas meter is a bit unresponsive. Christian> There is also an issue with policy enforcement. However, we already have Christian> mechanisms to inform the hosts: router advertisements can carry Christian> preferences for this or that prefix or router; ICMP can inform the hosts Christian> that their choices are not acceptable. In fact, ICMP can also be used Christian> from the site exit router(s) to suggest alternatives on a case by case Christian> basis. Router advertisements I will trust. Not because they are unspoofable, but because we have to secure them anyway (SEND issue). I would love to be able to secure ICMPs from the site exit routers. I am skeptical that we will be able to do that. I expect my link-local routers to be able to develop a trust relationship with the site exit routers much easier than an end-system can. Yes, as Bill says, we have to have strong indications of cacheability. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPfDkOIqHRg3pndX9AQGn1gP/fKAefikkiGsZknAAzFHwrDsL7iSNkzw/ rI2j0xr71/7P/Cw7QvYFhCdVyXftVe1XKFu3FVfpF98ldy8UgcfYuPktHxLlV5v0 PX8q0vzJmaSAKlZ+1L9dn0o9on1iJdLblJlDwFtmfW3Md1UKpvSwgingvLQEvxAB z8TzJRV5wdk= =IKYO -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Fri Dec 6 13:01:37 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16727 for ; Fri, 6 Dec 2002 13:01:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KMpa-000KFr-00 for multi6-data@psg.com; Fri, 06 Dec 2002 10:04:06 -0800 Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by psg.com with esmtp (Exim 3.36 #2) id 18KMpS-000KCq-00 for multi6@ops.ietf.org; Fri, 06 Dec 2002 10:03:59 -0800 Received: from [63.113.114.131] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 4023743; Fri, 06 Dec 2002 13:03:51 -0500 Message-Id: <5.1.0.14.0.20021206130043.02783e40@mail.stevecrocker.com> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 06 Dec 2002 13:02:42 -0500 To: , From: "Joel M. Halpern" Subject: RE: network controls are necessary In-Reply-To: <044901c29d50$3bd00bf0$237ba8c0@eagleswings> References: <5.1.0.14.0.20021206103018.017b57f0@mail.stevecrocker.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=1.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI,REFERENCES, SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-multi6@ops.ietf.org Precedence: bulk If I thought having the network make the selections would require change in application logic, I would not be suggesting such a solution. I would prefer a solution that is completely invisible to the application (such as Tony Li's suggesting that the application is handed a 32 bit identifier when it currently expects an IP address). Failing that, I would prefer to minimize the application coupling. Having application level address selection increases the application impact. Yours, Joel M. Halpern At 09:52 AM 12/6/2002 -0800, Tony Hain wrote: > > > > I strongly prefer the notion that other entities in the > > system would make > > the intelligent choice about the source address to use, and > > could change > > that choice as necessary. > >Even though accomplishing that will require changing all the application >software globally??? > >Tony From owner-multi6@ops.ietf.org Fri Dec 6 13:04:00 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16864 for ; Fri, 6 Dec 2002 13:04:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KMs2-000KRI-00 for multi6-data@psg.com; Fri, 06 Dec 2002 10:06:38 -0800 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #2) id 18KMrX-000KPR-00 for multi6@ops.ietf.org; Fri, 06 Dec 2002 10:06:07 -0800 Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Fri, 06 Dec 2002 10:06:15 -0800 Reply-To: From: "Tony Hain" To: "'Tony Li'" , Subject: RE: Next question... Date: Fri, 6 Dec 2002 10:06:05 -0800 Message-ID: <044a01c29d52$253589e0$237ba8c0@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal X-Spam-Status: No, hits=-1.1 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA16864 Tony Li wrote: > Ok, so if the point is where to put locator selection policy, > I think that this is a much more bounded problem. The two > obvious proposals are to > > 1) Put the locators in the host, so that it can control which locator > it wants to use. This allows the application to change locators if > its service is unacceptable. > > 2) Put the locators in the border router. This frees the host of the > management burden, but makes it somewhat harder for a site to > provide site-wide policy. > > Note that either of these two alternatives could be enhanced > by further communications. Either the border can inform the > host of site policy, or the host can inform the border of its > local policy. One could also do both, but this is starting > to look like a dromedary. > > Does that about cover the high points? Yes. I suspect most of the complaints about host based locator selection is really an indirect fear of loss of control. If that is true, having the routing system inform hosts of policy preferences would allow for that control in the general case, but still allow individual hosts to override it when necessary. This could be done through a local policy to respect ordering the RA, or possibly an explicit option. It would be possible for the hosts to inform the routing system about policy preferences, but the state maintenance to support N,000 policies in current hardware would not scale. Also, how is the host supposed to know which routers need to be informed of the policy, or if traffic shifts during a connection, which new router needs to be updated? RSVP tried to do exactly this, but the routing community refused to support it over scaling concerns. Tony From owner-multi6@ops.ietf.org Fri Dec 6 13:14:27 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17434 for ; Fri, 6 Dec 2002 13:14:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KN1z-000L1Z-00 for multi6-data@psg.com; Fri, 06 Dec 2002 10:16:55 -0800 Received: from halt-in.cisco.com ([171.70.144.185] helo=mailman.cisco.com) by psg.com with esmtp (Exim 3.36 #2) id 18KN1U-000Kzm-00 for multi6@ops.ietf.org; Fri, 06 Dec 2002 10:16:24 -0800 Received: from [10.21.96.34] by mailman.cisco.com (171.70.144.185) with ESMTP; 06 Dec 2002 03:36:06 +0000 Message-ID: <3DF0E958.2060809@cisco.com> Date: Fri, 06 Dec 2002 10:15:52 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021118 X-Accept-Language: en-us, en MIME-Version: 1.0 To: alh-ietf@tndh.net CC: "'Joel M. Halpern'" , multi6@ops.ietf.org Subject: Re: network controls are necessary References: <044901c29d50$3bd00bf0$237ba8c0@eagleswings> In-Reply-To: <044901c29d50$3bd00bf0$237ba8c0@eagleswings> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03, USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tony Hain wrote: > This looks like a big problem to the network admin, because they are > used to dealing with a few boxes, but for a host admin, this is exactly > what they do. What needs to happen here is for them to work together > (*gasp*). This is the end to end argument run amok. If this truely is an assumption then Joel is right, and this is a recipe for failure. You were right to gasp because more often than not in large companies this is *not* the case. Eliot From owner-multi6@ops.ietf.org Fri Dec 6 13:23:31 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17815 for ; Fri, 6 Dec 2002 13:23:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KNAw-000LVc-00 for multi6-data@psg.com; Fri, 06 Dec 2002 10:26:10 -0800 Received: from rip.psg.com ([147.28.0.39]) by psg.com with esmtp (Exim 3.36 #2) id 18KNAR-000LSx-00 for multi6@ops.ietf.org; Fri, 06 Dec 2002 10:25:39 -0800 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18KNAR-00011W-00; Fri, 06 Dec 2002 10:25:39 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Tony Hain Cc: multi6@ops.ietf.org Subject: RE: Next question... References: <044a01c29d52$253589e0$237ba8c0@eagleswings> Message-Id: Date: Fri, 06 Dec 2002 10:25:39 -0800 X-Spam-Status: No, hits=-0.5 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I suspect most of the complaints about host based locator selection is > really an indirect fear of loss of control. i suspect it is folk with a knowledge of just how difficult and complex global routing is when isolated to a site border router and our minds boggle when we think of all the hosts having to do it too. randy From owner-multi6@ops.ietf.org Fri Dec 6 13:24:15 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17854 for ; Fri, 6 Dec 2002 13:24:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KNBe-000LWx-00 for multi6-data@psg.com; Fri, 06 Dec 2002 10:26:54 -0800 Received: from dmz1.procket.com ([65.174.124.36]) by psg.com with esmtp (Exim 3.36 #2) id 18KNBb-000LVq-00 for multi6@ops.ietf.org; Fri, 06 Dec 2002 10:26:51 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 8351A23C24; Fri, 6 Dec 2002 10:25:34 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id gB6IQKiI006902; Fri, 6 Dec 2002 10:26:20 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: network controls are necessary Date: Fri, 6 Dec 2002 10:26:20 -0800 Message-ID: Thread-Topic: network controls are necessary Thread-Index: AcKdVFK69fv2hSdFStyRoP9zNSFNZQAAC4uw From: "Tony Li" To: "Eliot Lear" , Cc: "Joel M. Halpern" , X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_02_03 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA17854 | Tony Hain wrote: | > This looks like a big problem to the network admin, | because they are | > used to dealing with a few boxes, but for a host admin, | this is exactly | > what they do. What needs to happen here is for them to | work together | > (*gasp*). | | This is the end to end argument run amok. If this truely is an | assumption then Joel is right, and this is a recipe for | failure. You | were right to gasp because more often than not in large | companies this | is *not* the case. In fact, in my humble experience, it is normally the case that they are mortal enemies, competing for budget. Tony From owner-multi6@ops.ietf.org Fri Dec 6 13:28:20 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18094 for ; Fri, 6 Dec 2002 13:28:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KNFS-000Lid-00 for multi6-data@psg.com; Fri, 06 Dec 2002 10:30:50 -0800 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #2) id 18KNFO-000LhS-00 for multi6@ops.ietf.org; Fri, 06 Dec 2002 10:30:47 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id EAB0D352C8; Fri, 6 Dec 2002 10:40:06 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id gB6IUGiI007233; Fri, 6 Dec 2002 10:30:16 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: network controls are necessary Date: Fri, 6 Dec 2002 10:30:15 -0800 Message-ID: Thread-Topic: network controls are necessary Thread-Index: AcKdUmhRvj2irJvkSuKSbi00d46ksAAArlpw From: "Tony Li" To: "Joel M. Halpern" , , X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA18094 | If I thought having the network make the selections would | require change in | application logic, I would not be suggesting such a solution. | I would prefer a solution that is completely invisible to | the application | (such as Tony Li's suggesting that the application is | handed a 32 bit | identifier when it currently expects an IP address). | Failing that, I would prefer to minimize the application coupling. | Having application level address selection increases the | application impact. I'd second that. Even assuming that the host has policy control (which I'm not in favor of), the management of locators would belong in the stack, NOT in the application code. I would tend to extend the API to have a "Hey, this connection isn't working" entry so that applications can signal the stack. Tony From owner-multi6@ops.ietf.org Fri Dec 6 13:37:18 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18557 for ; Fri, 6 Dec 2002 13:37:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KNNv-000MAy-00 for multi6-data@psg.com; Fri, 06 Dec 2002 10:39:35 -0800 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #2) id 18KNNq-000M8s-00 for multi6@ops.ietf.org; Fri, 06 Dec 2002 10:39:30 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id B5692352C4; Fri, 6 Dec 2002 10:48:49 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id gB6IcxiI007820; Fri, 6 Dec 2002 10:38:59 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Next question... Date: Fri, 6 Dec 2002 10:38:59 -0800 Message-ID: Thread-Topic: Next question... Thread-Index: AcKdVX3uqgGgCHRGTkK1gX9q7FCUrQAABVnQ From: "Tony Li" To: "Randy Bush" , "Tony Hain" Cc: X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA18557 | > I suspect most of the complaints about host based locator | selection is | > really an indirect fear of loss of control. | | i suspect it is folk with a knowledge of just how difficult | and complex | global routing is when isolated to a site border router and | our minds | boggle when we think of all the hosts having to do it too. I have to disagree with both. First, there is no way that the site border router OR the host is going to have full information about global routing. They *might* have some limited policy information and a mechanism to retrieve locators. My concern is not so much about loss of control as it is with the administrative burden of implementing the policies. Most policies are going to be site-wide, not host specific. Having to distribute this policy and keep it consistent across an enterprise can be done by our standard system administration tools, but the effort involved in doing so is non-trivial and the number of exception hosts is likely to be small, so this just seems like a poor ROI for the site administrator(s). Our job, as architects, is not to create an architecture with infinite flexibility. Rather, it is to reject those options which lead to unnecessary complications down the line. Control at the host seems like an infrequently used feature. Note that policy for a specific host can be implemented at either the site border router (SBR) or at the host, so removing the policy decision from the host isn't actually eliminating architectural flexibility. Tony From owner-multi6@ops.ietf.org Fri Dec 6 17:44:08 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28426 for ; Fri, 6 Dec 2002 17:44:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KREN-0008p8-00 for multi6-data@psg.com; Fri, 06 Dec 2002 14:45:59 -0800 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #2) id 18KREK-0008oi-00 for multi6@ops.ietf.org; Fri, 06 Dec 2002 14:45:56 -0800 Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Fri, 06 Dec 2002 14:46:03 -0800 Reply-To: From: "Tony Hain" To: "'Randy Bush'" Cc: Subject: RE: Next question... Date: Fri, 6 Dec 2002 14:45:52 -0800 Message-ID: <045c01c29d79$3b6d7cf0$237ba8c0@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA28426 Randy Bush wrote: > > I suspect most of the complaints about host based locator > selection is > > really an indirect fear of loss of control. > > i suspect it is folk with a knowledge of just how difficult > and complex global routing is when isolated to a site border > router and our minds boggle when we think of all the hosts > having to do it too. The only suggestions that hosts participate in routing are coming from those who keep spreading FUD. We are talking about selection of locators, which has nothing to do with routing. There are very simple policies here, provider A is preferred over B, etc. It is not rocket science to configure a host to prefer one source prefix so it will conform to traffic engineering policies in the normal case. Tony From owner-multi6@ops.ietf.org Fri Dec 6 18:12:35 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29664 for ; Fri, 6 Dec 2002 18:12:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KRfz-000AUt-00 for multi6-data@psg.com; Fri, 06 Dec 2002 15:14:31 -0800 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #2) id 18KRfw-000AUd-00 for multi6@ops.ietf.org; Fri, 06 Dec 2002 15:14:28 -0800 Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Fri, 06 Dec 2002 15:14:37 -0800 Reply-To: From: "Tony Hain" To: "'Tony Li'" , "'Randy Bush'" Cc: Subject: RE: Next question... Date: Fri, 6 Dec 2002 15:14:26 -0800 Message-ID: <045e01c29d7d$388469f0$237ba8c0@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA29664 Tony Li wrote: > I have to disagree with both. First, there is no way that > the site border router OR the host is going to have full > information about global routing. They *might* have some > limited policy information and a mechanism to retrieve locators. > > My concern is not so much about loss of control as it is with > the administrative burden of implementing the policies. Isn't perception of burden really a function of direct vs. indirect control? > Most policies are going to be site-wide, not host specific. > Having to distribute this policy and keep it consistent > across an enterprise can be done by our standard system > administration tools, but the effort involved in doing so is > non-trivial and the number of exception hosts is likely to be > small, so this just seems like a poor ROI for the site > administrator(s). I agree that most policies are site wide, but ROI depends on how valuable the exception list is. If you are in the exception list, your perspective is different than if you are not. As far as triviality, that depends on the mechansim. If it were something like a static policy on all host to prefer the prefix order in the RA, it seems pretty trivial to me. > > Our job, as architects, is not to create an architecture with > infinite flexibility. Rather, it is to reject those options > which lead to unnecessary complications down the line. And our disagreement really comes down to definition of 'necessary'. > Control at the host seems like an infrequently used feature. Frequency is not an indication of value. Besides it is done on every connection today, so that seems pretty frequent to me. > Note that policy for a specific host can be implemented at either the > site border router (SBR) or at the host, so removing the > policy decision from the host isn't actually eliminating > architectural flexibility. I absolutely disagree. Hosts actually make those policy decisions today, and the system works. The machine I am typing this on has 4 IPv4 addresses, yet it has no trouble opening a connection to CNN.com by picking from that list of possible sources, and the 8 available IPv4 destination addresses. There seems to be a fear that providing more choices to the host will magically make the world more complex. The only thing that doesn't happen when the host selects the locator is that the network administrator doesn't get to enforce fine-grained TE for the return traffic. If this is what we are defining as 'unnecessary complications', I have to question the necessity of changing the entire infrastructure so that it will support the arbitrary replacement of locators without affecting applications. That sounds a lot more complex to me than simply adding one more policy to the set of things the host administrators have to do already. Tony From owner-multi6@ops.ietf.org Fri Dec 6 18:29:29 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00313 for ; Fri, 6 Dec 2002 18:29:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KRwt-000BR1-00 for multi6-data@psg.com; Fri, 06 Dec 2002 15:31:59 -0800 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #2) id 18KRwq-000BQM-00 for multi6@ops.ietf.org; Fri, 06 Dec 2002 15:31:56 -0800 Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Fri, 06 Dec 2002 15:32:04 -0800 Reply-To: From: "Tony Hain" To: "'Tony Li'" , "'Eliot Lear'" Cc: "'Joel M. Halpern'" , Subject: RE: network controls are necessary Date: Fri, 6 Dec 2002 15:31:53 -0800 Message-ID: <045f01c29d7f$a8eee0b0$237ba8c0@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tony Li wrote: > | Tony Hain wrote: > | > This looks like a big problem to the network admin, > | because they are > | > used to dealing with a few boxes, but for a host admin, > | this is exactly > | > what they do. What needs to happen here is for them to > | work together > | > (*gasp*). > | > | This is the end to end argument run amok. If this truely is an > | assumption then Joel is right, and this is a recipe for > | failure. You > | were right to gasp because more often than not in large > | companies this > | is *not* the case. > > > In fact, in my humble experience, it is normally the case > that they are mortal enemies, competing for budget. This does not mean it is our responsibility to foster the petty bickering. The goal appears to be to pick sides, with heavy representation from those who are most closely related to the network side. I am not advocating that the hosts do it all, in fact I don't think either side can go it alone, much as they would often like to. Our job is to define a mechanism that allows a disparate range of policies to be implemented without serious detriment to the routing system. Locking down so that the routing system is in complete control makes defining a technology simpler, but that doesn't mean the result will actually address the policy requirements. Dismissing a set of policies is a fine thing to do when building a network, but not when defining the standard technology that those individual networks will use. Tony From owner-multi6@ops.ietf.org Fri Dec 6 21:38:07 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06170 for ; Fri, 6 Dec 2002 21:38:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KUt0-000LJw-00 for multi6-data@psg.com; Fri, 06 Dec 2002 18:40:10 -0800 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #2) id 18KUsy-000LHh-00 for multi6@ops.ietf.org; Fri, 06 Dec 2002 18:40:08 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 022703534C; Fri, 6 Dec 2002 18:49:29 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id gB72daiI028569; Fri, 6 Dec 2002 18:39:36 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: network controls are necessary Date: Fri, 6 Dec 2002 18:39:36 -0800 Message-ID: Thread-Topic: network controls are necessary Thread-Index: AcKdf64v3x6Wjt59S8SbloSi0kc5ygAGJEzg From: "Tony Li" To: , "Eliot Lear" Cc: "Joel M. Halpern" , X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_02_03 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA06170 Tony, | > In fact, in my humble experience, it is normally the case | > that they are mortal enemies, competing for budget. | | This does not mean it is our responsibility to foster the petty | bickering. The goal appears to be to pick sides, with heavy | representation from those who are most closely related to | the network | side. I am not advocating that the hosts do it all, in fact I don't | think either side can go it alone, much as they would often | like to. I agree that it's not our place to foster bickering. But we should also be cognizant of it when we think about how sites are administered. We cannot dictate that it be fixed. I'm somewhat offended that you would accuse us of being partisan. This is an architectural discussion about the right engineering compromises to help grow the Internet. I'm fully cognizant of what a host administrator has to do. I was a Unix and VMS sysadmin for USC from 1983-2000. We supported over 2000 workstations and 30,000 user accounts. Simplifying host management was a requirement then and still. I have nothing to gain by having control in the SBR. I no longer work at Cisco, so I have no interest in placing more responsibility and complexity into the CPE gear. I'm just trying to design a clean architecture that scales. That's what we should all be striving for. | Our job is to define a mechanism that allows a disparate range of | policies to be implemented without serious detriment to the routing | system. Locking down so that the routing system is in | complete control | makes defining a technology simpler, but that doesn't mean | the result | will actually address the policy requirements. Dismissing a set of | policies is a fine thing to do when building a network, but not when | defining the standard technology that those individual networks will | use. Our first job is to define an architecture, not a mechanism. That architecture will be able to support some policies, not all. We need to understand the bounds of the policies that can be supported by a particular architecture and to choose the architecture which balances policy against complexity and our other design goals. Supporting all possible policies is not an architectural trait that is supported with either host or SBR policies. The amount of possibly relevant information that either of them will have is far too limited in any rational design to begin to implement all policies. So we have to choose. Tony From owner-multi6@ops.ietf.org Fri Dec 6 21:50:44 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06384 for ; Fri, 6 Dec 2002 21:50:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KV5d-000M1U-00 for multi6-data@psg.com; Fri, 06 Dec 2002 18:53:13 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.36 #2) id 18KV5b-000M1G-00 for multi6@ops.ietf.org; Fri, 06 Dec 2002 18:53:11 -0800 content-class: urn:content-classes:message Subject: RE: Next question... MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 6 Dec 2002 18:53:25 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405E518@server2000> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: Next question... Thread-Index: AcKbzF/E38n9nJP0Qqmos/211FpDQwBBOXwwAAWmyGAABsVVwAAmANrQ From: "Michel Py" To: "Tony Li" , "Tony Hain" , X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA06384 Tony, >>> Tony Li wrote: >>> 2) Put the locators in the border router. This frees >>> the host of the management burden, but makes it >>> somewhat harder for a site to provide site-wide >>> policy. >> Michel Py wrote: >> Why would it be harder? For this purpose, I don't see a >> difference between the choice of the locator to be used >> and the choice of the site exit link. If the choice of the >> locator is based on the AS-PATH, turns out to be the same. > It's harder because as site administrator, I now need to > communicate policy to each system in the enterprise. That > can be daunting. Ever manage an enterprise with 2000 hosts > in it? 2000 hosts: small potatoes. Allow me to rephrase my question: if you put locators in the border router and they are unknown to the hosts, why would it be harder? You would not have to communicate policy to the hosts. Michel. From owner-multi6@ops.ietf.org Fri Dec 6 22:24:19 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07043 for ; Fri, 6 Dec 2002 22:24:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KVcC-000NjH-00 for multi6-data@psg.com; Fri, 06 Dec 2002 19:26:52 -0800 Received: from dmz1.procket.com ([65.174.124.36]) by psg.com with esmtp (Exim 3.36 #2) id 18KVcA-000Nip-00 for multi6@ops.ietf.org; Fri, 06 Dec 2002 19:26:51 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id F393423C24; Fri, 6 Dec 2002 19:25:34 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id gB73QGiI000187; Fri, 6 Dec 2002 19:26:16 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Next question... Date: Fri, 6 Dec 2002 19:26:16 -0800 Message-ID: Thread-Topic: Next question... Thread-Index: AcKbzF/E38n9nJP0Qqmos/211FpDQwBBOXwwAAWmyGAABsVVwAAmANrQAAE4rZA= From: "Tony Li" To: "Michel Py" , "Tony Hain" , X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA07043 | >>> Tony Li wrote: | >>> 2) Put the locators in the border router. This frees | >>> the host of the management burden, but makes it | >>> somewhat harder for a site to provide site-wide | >>> policy. | | 2000 hosts: small potatoes. Allow me to rephrase my | question: if you put | locators in the border router and they are unknown to the hosts, why | would it be harder? You would not have to communicate policy to the | hosts. Would you believe that it's because I am an idiot? First, what I wrote is the exact opposite of what I was thinking. Second, even that was wrong. ;-) What I should have written was: 2) Put the locators in the border router. This frees the host of the management burden, but makes it somewhat harder for the host administrator to implement host specific policies without the assistance of the administrator of the border router. Host specific policies can still be implemented, they just need to be managed by the border router. The number of unique host policies can be a scalability issue for the border router. Fair enough? Tony From owner-multi6@ops.ietf.org Fri Dec 6 22:35:02 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07512 for ; Fri, 6 Dec 2002 22:35:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KVmZ-000OFw-00 for multi6-data@psg.com; Fri, 06 Dec 2002 19:37:35 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.36 #2) id 18KVmW-000OFj-00 for multi6@ops.ietf.org; Fri, 06 Dec 2002 19:37:32 -0800 content-class: urn:content-classes:message Subject: RE: network controls are neccessary MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 6 Dec 2002 19:37:46 -0800 Message-ID: <2B81403386729140A3A899A8B39B04640BD4E8@server2000> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: network controls are neccessary Thread-Index: AcKc/Fz7xZfqccdYTBCgUNRswpxfdAAhBB5Q From: "Michel Py" To: "Erik Nordmark" Cc: "Craig A. Huegen" , X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA07512 Erik, > Erik Nordmark wrote: > If the exit routing policy can be expressed with a few rules > it would essentially be additional rules in that table (and a > protocol by which the hosts can learn those rules). > Hence my questions on the list (so far without answer) about > reasonable sizes for the exit router selection policy/routes. It's not that simple, because the policy can be the combination of several fractional policies applied at different points. For example, a network administrator could tag a route or a summary a certain way to make traffic flow in a general direction, then the site-exit router that happens to be in that direction would make another policy decision based on the AS-PATH, that kind of thing. The end-result of TE, which is the policy that determines which interface on which router is the one being used can be the result of decisions made in several routers. It can be a tree, not a flat policy. >> Michel Py wrote: >> a) The hosts to have the same routing capabilities as routers >> currently have. > Sorry I don't follow the logic. The hosts don't route. Hosts > with multiple source locators that talk to a node with > multiple destination locators just do a selection e.g. when > creating a new connection. My bad, I should have said: "The hosts to have the same *decision* capabilities as routers currently have". You are correct, instead of choosing the egress interface the host would choose among several addresses, which in turn would influence the egress interface. TE is not about routing, it's about choosing the egress interface (and a few other things). The point is about the criteria the host would use to make this choice. The way TE is today, the router has a wide variety of things to help decide, including the AS-PATH, MEDs, route tags, port numbers, diffserv codepoints, name it it's used somewhere in a route-map. Since we don't want hosts to run BGP, you would have to transform all these criteria into something simpler that the host would understand. This not something I know how to do. A simplistic approach says that since we can't have the hosts receive the same quality of information than routers, the solution is a querying mechanism where the host would query the routing system with a list of possible source addresses, a list of possible destination addresses, a protocol and port number, and have the routing system reply with a primary and possibly a backup pair. In short: I think I will concur with what Joel and Michael have contributed, and I think host solutions will need a protocol that is an interface between the routing system policies and the choice of the right address or address pair. > I think the edge thing is also important to explore in parallel > with a host-based scheme. I have heard of another ML that has made it part of its charter :-) Michel. From owner-multi6@ops.ietf.org Fri Dec 6 22:39:56 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07577 for ; Fri, 6 Dec 2002 22:39:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KVqi-000OVW-00 for multi6-data@psg.com; Fri, 06 Dec 2002 19:41:52 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.36 #2) id 18KVqg-000OVH-00 for multi6@ops.ietf.org; Fri, 06 Dec 2002 19:41:50 -0800 content-class: urn:content-classes:message Subject: RE: Next question... MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 6 Dec 2002 19:42:04 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405E519@server2000> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: Next question... Thread-Index: AcKbzF/E38n9nJP0Qqmos/211FpDQwBBOXwwAAWmyGAABsVVwAAmANrQAAE4rZAAAG/WMA== From: "Michel Py" To: "Tony Li" , X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA07577 Tony, > Tony Li wrote: > Would you believe that it's because I am an idiot? No. Find a better excuse. What were you doing at the same time you wrote this? What did you drink before? > 2) Put the locators in the border router. This frees the host > of the management burden, but makes it somewhat harder for the > host administrator to implement host specific policies without > the assistance of the administrator of the border router. Host > specific policies can still be implemented, they just need to > be managed by the border router. The number of unique host > policies can be a scalability issue for the border router. Much better. Now, what is the difference with what you wrote above and the way TE is done today? Michel. From owner-multi6@ops.ietf.org Sat Dec 7 02:15:31 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21535 for ; Sat, 7 Dec 2002 02:15:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KZDK-0009dE-00 for multi6-data@psg.com; Fri, 06 Dec 2002 23:17:26 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #2) id 18KZDI-0009d0-00 for multi6@ops.ietf.org; Fri, 06 Dec 2002 23:17:24 -0800 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id CAA23449; Sat, 7 Dec 2002 02:17:22 -0500 Date: Sat, 7 Dec 2002 02:17:22 -0500 From: "J. Noel Chiappa" Message-Id: <200212070717.CAA23449@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: RE: Next question... Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Randy Bush > folk with a knowledge of just how difficult and complex global routing > is when isolated to a site border router and our minds boggle when we > think of all the hosts having to do it too. Umm, this is a bit off-topic, but... A big reason global routing is "difficult and complex" is that the existing routing architecture is a total piece of canine alimentary refuse. Yes, all the inter-provider peering agreements also contribute to the complexity, but... As for the difficulty of having hosts do it too, may I point out that the average human being seems to be able to deal with getting in a car on one side of a continent (well, maybe only in North America and Western Europe where the road systems are good) and figuring out a path to a destination on the other side. It doesn't take a PhD. Similarly, network routing *shouldn't* need a PhD. It does only because of the aforementioned canine refuseness. Of course this is a bit irrelevant to multi-6, because removal of canine refuse is outside scope for this WG. Noel From owner-multi6@ops.ietf.org Sat Dec 7 02:18:23 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21560 for ; Sat, 7 Dec 2002 02:18:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KZGu-0009sk-00 for multi6-data@psg.com; Fri, 06 Dec 2002 23:21:08 -0800 Received: from dmz1.procket.com ([65.174.124.36]) by psg.com with esmtp (Exim 3.36 #2) id 18KZGr-0009qF-00 for multi6@ops.ietf.org; Fri, 06 Dec 2002 23:21:05 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id F1A4B23C24; Fri, 6 Dec 2002 23:19:47 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id gB77KXiI006611; Fri, 6 Dec 2002 23:20:34 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Next question... Date: Fri, 6 Dec 2002 23:20:33 -0800 Message-ID: Thread-Topic: Next question... Thread-Index: AcKbzF/E38n9nJP0Qqmos/211FpDQwBBOXwwAAWmyGAABsVVwAAmANrQAAE4rZAAAG/WMAAHuzAQ From: "Tony Li" To: "Michel Py" , X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA21560 | > Tony Li wrote: | > Would you believe that it's because I am an idiot? | | No. Find a better excuse. What were you doing at the same | time you wrote | this? What did you drink before? Diet Pepsi, I swear! ;-) | > 2) Put the locators in the border router. This frees the host | > of the management burden, but makes it somewhat harder for the | > host administrator to implement host specific policies without | > the assistance of the administrator of the border router. Host | > specific policies can still be implemented, they just need to | > be managed by the border router. The number of unique host | > policies can be a scalability issue for the border router. | | Much better. Now, what is the difference with what you | wrote above and | the way TE is done today? Typically today, there is NO TE within the site and almost nothing at the SBR. The easy way of doing outbound TE is to prioritize different prefixes from the multiple providers in the SBRs routing table. This is easy if there's only one SBR, but folks frequently want two to protect against a single point of failure. In that case, the SBRs have to be linked with IBGP so that they make consistent policy decisions. TE within a transit domain is another matter entirely, of course. Tony From owner-multi6@ops.ietf.org Sat Dec 7 02:23:21 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21647 for ; Sat, 7 Dec 2002 02:23:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KZLW-000A1H-00 for multi6-data@psg.com; Fri, 06 Dec 2002 23:25:54 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #2) id 18KZLV-000A15-00 for multi6@ops.ietf.org; Fri, 06 Dec 2002 23:25:53 -0800 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id CAA23492; Sat, 7 Dec 2002 02:25:51 -0500 Date: Sat, 7 Dec 2002 02:25:51 -0500 From: "J. Noel Chiappa" Message-Id: <200212070725.CAA23492@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: RE: network controls are necessary Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: "Christian Huitema" > Rant: an old tenet of networking is that a name is not an address and > an address is not a route This simplistic analysis (by Shoch) of the correct set of namespaces for a network architecture was made obsolete by Saltzer about 20 years ago, and I strongly suspect that Shoch would be the first to tell you so. > I don't see why we would need to invent new names and refer to names as > identifiers and addresses as locators. "Name" properly is a meta-syntactic term for any kind of identifying string, so in some sense every name in the IP architecture (IEEE addresses, IPvN addresses, DNS names, etc) are *all* names. The reason for inventing a new namespace and calling them "identifiers", and referring to what we used to call "addresses" as "locators" is to make plain that we have different namespaces to say i) *who* something is, and ii) *where* it is - and "locators" *only* do the latter. This is unlike IPvN at the moment, where effectively there is only one kind of name, which does both - which has been shown to have significant disadvantages. Noel From owner-multi6@ops.ietf.org Sat Dec 7 02:45:32 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22123 for ; Sat, 7 Dec 2002 02:45:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KZgv-000BMj-00 for multi6-data@psg.com; Fri, 06 Dec 2002 23:48:01 -0800 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #2) id 18KZgt-000BMF-00 for multi6@ops.ietf.org; Fri, 06 Dec 2002 23:47:59 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 88CD735361; Fri, 6 Dec 2002 23:50:57 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id gB77f6iI007330; Fri, 6 Dec 2002 23:41:06 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: network controls are necessary Date: Fri, 6 Dec 2002 23:41:05 -0800 Message-ID: Thread-Topic: network controls are necessary Thread-Index: AcKdwomtXNXc5pVPRdSkKqzXT8xgfAAAC1+A From: "Tony Li" To: "J. Noel Chiappa" , X-Spam-Status: No, hits=1.6 required=5.0 tests=SPAM_PHRASE_05_08 version=2.43 X-Spam-Level: * Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA22123 | The reason for inventing a new namespace and calling them | "identifiers", and | referring to what we used to call "addresses" as "locators" | is to make plain | that we have different namespaces to say i) *who* something | is, and ii) | *where* it is - and "locators" *only* do the latter. This | is unlike IPvN at | the moment, where effectively there is only one kind of | name, which does both | - which has been shown to have significant disadvantages. BTW, practical experience bears this out. For hosts with multiple interfaces, sooner or later, you find that you need a unique IPv4 address to use regardless of what connectivity is available. You end up putting an IP address on a loopback interface to provide the "identifier". If you come at it the other way and start with a CLNP host that has an identifier but no interface addresses, you quickly find that people ALSO want to be able to reference a system based on it's particular location. IPv4 did a fine thing in colocating the identifier and locator in 32 bits. And it made sense when the IMP port number was part of the address. But those days are well past us now, the net is much more richly connected and being multihomed no longer means that you had two IMPs. If we are to move the Internet architecture forward, then we need to apply what we've learned over the past 30 odd years and deploy a new routing and addressing architecture that fixes the semantic overload that was once a practical necessity and give ourselves the additional flexibility that results. Articulating the same position for 10 years now, I remain yours in routing, Tony From owner-multi6@ops.ietf.org Sat Dec 7 13:54:50 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04530 for ; Sat, 7 Dec 2002 13:54:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Kk6U-000NqP-00 for multi6-data@psg.com; Sat, 07 Dec 2002 10:55:06 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 18Kk6R-000Npp-00 for multi6@ops.ietf.org; Sat, 07 Dec 2002 10:55:03 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gB7Iqch36251; Sat, 7 Dec 2002 19:52:41 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Sat, 7 Dec 2002 19:52:38 +0100 (CET) From: Iljitsch van Beijnum To: "Joel M. Halpern" cc: , Subject: RE: network controls are necessary In-Reply-To: <5.1.0.14.0.20021206130043.02783e40@mail.stevecrocker.com> Message-ID: <20021207194235.S31466-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 6 Dec 2002, Joel M. Halpern wrote: > If I thought having the network make the selections would require change in > application logic, I would not be suggesting such a solution. > I would prefer a solution that is completely invisible to the application > (such as Tony Li's suggesting that the application is handed a 32 bit > identifier when it currently expects an IP address). > Failing that, I would prefer to minimize the application coupling. > Having application level address selection increases the application impact. A few weeks back, on the IETF discussion list in the "kernelizing the address lookup" (or similar) thread, the opposite point was made, by several people if I remember correctly. Some applications need to see more than just the host name. If we are going to build something where a host can have several addresses tied to several paths with different properties (fast/slow, secure/insecure, free/cheap/expensive), applications will want to make selecting addresses their business. Currently, IPv6 doesn't support backwards compatibility with applications that use the traditional socket API. The past three days I've been trying to find a web browser with IPv6 support for my new iBook, so I think I've earned the right to say there aren't enough IPv6 applications yet that breaking those is a big issue. However, if we go down the path of requiring applications to change, we should make very, very, very sure this is a one time thing and we build in everything we need for IPv6 - IPv15. From owner-multi6@ops.ietf.org Sat Dec 7 14:02:42 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04763 for ; Sat, 7 Dec 2002 14:02:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KkFV-000OYD-00 for multi6-data@psg.com; Sat, 07 Dec 2002 11:04:25 -0800 Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by psg.com with esmtp (Exim 3.36 #2) id 18KkFT-000OY1-00 for multi6@ops.ietf.org; Sat, 07 Dec 2002 11:04:23 -0800 Received: from [66.95.38.74] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 4025723; Sat, 07 Dec 2002 14:04:00 -0500 Message-Id: <5.1.0.14.0.20021207135936.017e1738@mail.stevecrocker.com> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 07 Dec 2002 14:02:35 -0500 To: Iljitsch van Beijnum From: "Joel M. Halpern" Subject: RE: network controls are necessary Cc: In-Reply-To: <20021207194235.S31466-100000@sequoia.muada.com> References: <5.1.0.14.0.20021206130043.02783e40@mail.stevecrocker.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-0.5 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk As far as I know, 1) We do not have paths that provide these properties 2) If we had such paths, the likelihood is that the host would not have enough information to determine which locator would give the desired properties. Yes, there is (and has been for many years) ongoing discussion of QoS. We still have not found a sensible and useful way to provide differentiation in that dimension. One of the reasons I want to keep hosts out of the routing space is that if we ever do find routing solutions that we want to use for new capabilities (QoS or otherwise) I would not want to have to upgrade the hosts as well as the routers to deliver such capabilities. Yours, Joel M. Halpern At 07:52 PM 12/7/2002 +0100, Iljitsch van Beijnum wrote: >Some applications need to see more than just the host name. If we are >going to build something where a host can have several addresses tied to >several paths with different properties (fast/slow, secure/insecure, >free/cheap/expensive), applications will want to make selecting >addresses their business. From owner-multi6@ops.ietf.org Sat Dec 7 14:04:30 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04830 for ; Sat, 7 Dec 2002 14:04:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KkIB-000OoC-00 for multi6-data@psg.com; Sat, 07 Dec 2002 11:07:11 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 18KkI7-000Ont-00 for multi6@ops.ietf.org; Sat, 07 Dec 2002 11:07:08 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gB7J5D736275; Sat, 7 Dec 2002 20:05:14 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Sat, 7 Dec 2002 20:05:13 +0100 (CET) From: Iljitsch van Beijnum To: Tony Li cc: Subject: RE: Next question... In-Reply-To: Message-ID: <20021207200137.N31466-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 6 Dec 2002, Tony Li wrote: > What I should have written was: > 2) Put the locators in the border router. This frees the host > of the management burden, but makes it somewhat harder for the > host administrator to implement host specific policies without > the assistance of the administrator of the border router. Host > specific policies can still be implemented, they just need to > be managed by the border router. The number of unique host > policies can be a scalability issue for the border router. I would still like some hint from the host to the border router that the current connection isn't working. If a host needs specific policies, would it be possible to "move the border" for that host to that host? Then the real border routers only have to pass the traffic without touching it and the host is in full control, the border routers only get to say yes or no, which should be enough to keep rogue sysadmins in check. Iljitsch From owner-multi6@ops.ietf.org Sat Dec 7 17:02:51 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08565 for ; Sat, 7 Dec 2002 17:02:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Kn3s-000CXo-00 for multi6-data@psg.com; Sat, 07 Dec 2002 14:04:36 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 18Kn3p-000CXZ-00 for multi6@ops.ietf.org; Sat, 07 Dec 2002 14:04:33 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gB7M2EG36448; Sat, 7 Dec 2002 23:02:14 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Sat, 7 Dec 2002 23:02:13 +0100 (CET) From: Iljitsch van Beijnum To: "Joel M. Halpern" cc: Subject: RE: network controls are necessary In-Reply-To: <5.1.0.14.0.20021207135936.017e1738@mail.stevecrocker.com> Message-ID: <20021207220649.C31466-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sat, 7 Dec 2002, Joel M. Halpern wrote: > 1) We do not have paths that provide these properties Sure we do, hosts such as laptops routinely have different interfaces connecting to different services with different properties. Today, we typically don't use those at the same time, but it's not a big leap to expect this will happen more in the future. For instance, if I'm walking around a convention center with my laptop while I'm downloading a file and I'm looking at a device over a telnet/SSH connection, I would like both of these applications to use wireless LAN connectivity if available. But when I'm out of range of the wireless LAN, I'd want the terminal connection to switch to GPRS or something similar, but the download should simply stop and resume later when there is more/cheaper bandwidth. > 2) If we had such paths, the likelihood is that the host would not have > enough information to determine which locator would give the desired > properties. In the example above it does. If selecting the path is done further upstream (border router) then a host wouldn't automatically know this, yes. The question then becomes: do we want the applications to know the properties of different paths and then select one, or do we want the applications to tag their packets with something that indicates the desired service level, and let the routing infrastructure take it from there? I've heared arguments that hosts are plenty smart and can do everything routers can. This would mean that the ultimate decision is the host's, and that the routing infrastructure only provides the necessary building blocks. But I don't buy this. People sitting in a bus can also be excellent drivers, but that doesn't mean they get to second guess the bus driver. Hosts need to look after the applications running on them, routers need to look after the network as a whole. Getting routers to work together is hard enough, getting hosts which are much more diverse in every way to do the same is next to impossible. However, that does not mean hosts should be kept stupid: any task a host can perform autonomously without adverse effects on other systems should be performed by the host and not by the network infrastructure. > Yes, there is (and has been for many years) ongoing discussion of QoS. We > still have not found a sensible and useful way to provide differentiation > in that dimension. The same was true for interdomain multicast for a long time. But as far as I can tell, it works fine now for those who have a transit provider that supports it. I think the QoS effort hasn't been as productive as it could have because the focus has mainly been to split the bandwidth for a single link (or sequential set of links) in creative ways. However, this is only a useful approach if most of your traffic is bulk that can be throttled back if there is higher priority traffic. But oversubscribing regular traffic and then investing in equipment that can throttle it back even further doesn't work nearly as well as simply putting that money towards bigger pipes. However, not all bandwidth problems can be solved with bigger pipes: you can get only so many bits per second through a radio channel, especially if there are antenna size, power, mobility and interference constraints. So I think there is a future for QoS mechanisms that can make applications run free over cheap/bandwidth-rich links but tome them in over expensive/bandwidth-starved links. An interesting observation: while hosts with biggest links now have 17,000 times as much bandwidth as those connected to the original Arpanet, the hosts with the smallest links actually have 6 times _less_ bandwidth as those early Arpanet hosts 30 years ago. > One of the reasons I want to keep hosts out of the routing space is that if > we ever do find routing solutions that we want to use for new capabilities > (QoS or otherwise) I would not want to have to upgrade the hosts as well as > the routers to deliver such capabilities. I agree 100%. Iljitsch From owner-multi6@ops.ietf.org Sat Dec 7 18:49:13 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10243 for ; Sat, 7 Dec 2002 18:49:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KoiW-000Kxi-00 for multi6-data@psg.com; Sat, 07 Dec 2002 15:50:40 -0800 Received: from unknown-1-11.wrs.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #2) id 18KoiQ-000Ksq-00 for multi6@ops.ietf.org; Sat, 07 Dec 2002 15:50:35 -0800 Received: from IDLEWYLDE.windriver.com ([147.11.233.24]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id PAA29898; Sat, 7 Dec 2002 15:49:24 -0800 (PST) Message-Id: <5.1.0.14.0.20021207184702.02a67988@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 07 Dec 2002 18:49:02 -0500 To: "Michel Py" From: Margaret Wasserman Subject: RE: Next question... Cc: "Tony Li" , "Tony Hain" , In-Reply-To: <2B81403386729140A3A899A8B39B046405E518@server2000> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk > >2000 hosts: small potatoes. Allow me to rephrase my question: if you put >locators in the border router and they are unknown to the hosts, why >would it be harder? You would not have to communicate policy to the >hosts. How does this differ from the GSE proposal -- routing goop inserted at the edge routers? Would these locators be considered part of the IP address by upper layers? What happens when a communication that was within the site (no locators present) starts bouncing off of an edge router, due to dynamic routing changes? If a host needs to send its identifier and locator information to another host (as in the FTP PORT command), what does it send? Margaret From owner-multi6@ops.ietf.org Sat Dec 7 19:28:26 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10843 for ; Sat, 7 Dec 2002 19:28:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KpL3-000OYn-00 for multi6-data@psg.com; Sat, 07 Dec 2002 16:30:29 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 18KpKz-000OYY-00 for multi6@ops.ietf.org; Sat, 07 Dec 2002 16:30:25 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gB80SSm36580; Sun, 8 Dec 2002 01:28:29 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Sun, 8 Dec 2002 01:28:28 +0100 (CET) From: Iljitsch van Beijnum To: Margaret Wasserman cc: Subject: RE: Next question... In-Reply-To: <5.1.0.14.0.20021207184702.02a67988@mail.windriver.com> Message-ID: <20021208012341.N31466-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sat, 7 Dec 2002, Margaret Wasserman wrote: > >2000 hosts: small potatoes. Allow me to rephrase my question: if you put > >locators in the border router and they are unknown to the hosts, why > >would it be harder? You would not have to communicate policy to the > >hosts. > How does this differ from the GSE proposal -- routing goop inserted > at the edge routers? There is no single concrete proposal at this time - maybe we'll raise GSE from the dead. (But I don't think so.) > Would these locators be considered part of the IP address by upper > layers? What happens when a communication that was within the site > (no locators present) starts bouncing off of an edge router, due > to dynamic routing changes? It could very well be that there are always locators, either because the source host must add them, or because multihoming benefits are also nice tto have within a site, for instance by a host with two NICs. If the border routers (or something close to the border routers) is responsible for puting in the locators, then obviously there wouldn't be any bouncing, other than the usual inconsistencies during routing convergence. > If a host needs to send its identifier and locator information to > another host (as in the FTP PORT command), what does it send? This is what the identifiers are for. From owner-multi6@ops.ietf.org Sat Dec 7 20:45:16 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11869 for ; Sat, 7 Dec 2002 20:45:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KqWS-0004s3-00 for multi6-data@psg.com; Sat, 07 Dec 2002 17:46:20 -0800 Received: from unknown-1-11.windriver.com ([147.11.1.11] helo=mail.wrs.com) by psg.com with esmtp (Exim 3.36 #2) id 18KqWQ-0004rf-00 for multi6@ops.ietf.org; Sat, 07 Dec 2002 17:46:18 -0800 Received: from IDLEWYLDE.windriver.com ([147.11.233.24]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id RAA29004; Sat, 7 Dec 2002 17:45:08 -0800 (PST) Message-Id: <5.1.0.14.0.20021207204356.02a4b3e0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 07 Dec 2002 20:44:53 -0500 To: Iljitsch van Beijnum From: Margaret Wasserman Subject: RE: Next question... Cc: In-Reply-To: <20021208012341.N31466-100000@sequoia.muada.com> References: <5.1.0.14.0.20021207184702.02a67988@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-1.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk > > If a host needs to send its identifier and locator information to > > another host (as in the FTP PORT command), what does it send? > >This is what the identifiers are for. So, the identifier would be sent, and there would be some way for the receiving host to obtain a locator that matches the identifier for return traffic? Margaret From owner-multi6@ops.ietf.org Sun Dec 8 01:27:02 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15941 for ; Sun, 8 Dec 2002 01:27:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Kutc-0000Dk-00 for multi6-data@psg.com; Sat, 07 Dec 2002 22:26:32 -0800 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #2) id 18Kuta-0000Cq-00 for multi6@ops.ietf.org; Sat, 07 Dec 2002 22:26:31 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 97984353AF; Sat, 7 Dec 2002 22:35:52 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id gB86PxiI009652; Sat, 7 Dec 2002 22:25:59 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Next question... Date: Sat, 7 Dec 2002 22:25:58 -0800 Message-ID: Thread-Topic: Next question... Thread-Index: AcKeXCTXb4iagndORkiN5MzeBZ7YRQAJnM+Q From: "Tony Li" To: "Margaret Wasserman" , "Iljitsch van Beijnum" Cc: X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA15941 | > > If a host needs to send its identifier and locator | information to | > > another host (as in the FTP PORT command), what does it send? | > | >This is what the identifiers are for. | | So, the identifier would be sent, and there would be some way for | the receiving host to obtain a locator that matches the identifier | for return traffic? Yes, there would need to be a hierarchical mapping from identifier to a set of locators. Tony From owner-multi6@ops.ietf.org Sun Dec 8 05:02:25 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28518 for ; Sun, 8 Dec 2002 05:02:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KyHE-0004jx-00 for multi6-data@psg.com; Sun, 08 Dec 2002 02:03:08 -0800 Received: from dmz1.procket.com ([65.174.124.36]) by psg.com with esmtp (Exim 3.36 #2) id 18KyHC-0004jb-00 for multi6@ops.ietf.org; Sun, 08 Dec 2002 02:03:06 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id A2E3A23C24; Sun, 8 Dec 2002 02:01:46 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id gB8A2YiI014275; Sun, 8 Dec 2002 02:02:35 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Next question... Date: Sun, 8 Dec 2002 02:02:34 -0800 Message-ID: Thread-Topic: Next question... Thread-Index: AcKeI6w0sBIvae2ERjG5cIZdBSUzYAAfB38Q From: "Tony Li" To: "Iljitsch van Beijnum" Cc: X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA28518 | > 2) Put the locators in the border router. This frees the host | > of the management burden, but makes it somewhat harder for the | > host administrator to implement host specific policies without | > the assistance of the administrator of the border router. Host | > specific policies can still be implemented, they just need to | > be managed by the border router. The number of unique host | > policies can be a scalability issue for the border router. | | I would still like some hint from the host to the border | router that the | current connection isn't working. Not an unreasonable request. | If a host needs specific policies, would it be possible to "move the | border" for that host to that host? Then the real border | routers only | have to pass the traffic without touching it and the host is in full | control, the border routers only get to say yes or no, | which should be | enough to keep rogue sysadmins in check. I think that this puts us firmly behind the dromedary. Putting control functionality in both places is more complicated than is truly necessary, IMHO, and thus is a fine candidate for Occam's Razor. Tony From owner-multi6@ops.ietf.org Sun Dec 8 05:05:40 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28613 for ; Sun, 8 Dec 2002 05:05:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KyLl-0004qK-00 for multi6-data@psg.com; Sun, 08 Dec 2002 02:07:49 -0800 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #2) id 18KyLi-0004pE-00 for multi6@ops.ietf.org; Sun, 08 Dec 2002 02:07:46 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id C7434353B4; Sun, 8 Dec 2002 02:16:02 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id gB8A69iI014310; Sun, 8 Dec 2002 02:06:09 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: network controls are necessary Date: Sun, 8 Dec 2002 02:06:09 -0800 Message-ID: Thread-Topic: network controls are necessary Thread-Index: AcKeIweBvsUD1WSSR0maTBPYYd2DXAAfftOw From: "Tony Li" To: "Iljitsch van Beijnum" , "Joel M. Halpern" Cc: , X-Spam-Status: No, hits=0.5 required=5.0 tests=SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA28613 | Some applications need to see more than just the host name. | If we are | going to build something where a host can have several | addresses tied to | several paths with different properties (fast/slow, secure/insecure, | free/cheap/expensive), applications will want to make selecting | addresses their business. Yes, but should the application have the details about the locators? Or should it specify its properties and then let underlying systems choose? For the sake of a loosely coupled system, I'd say that the applications shouldn't ever worry about locators. And this is regardless of whether the host is implementing the policies or the SBR. | Currently, IPv6 doesn't support backwards compatibility with | applications that use the traditional socket API. The past | three days | I've been trying to find a web browser with IPv6 support for my new | iBook, so I think I've earned the right to say there aren't | enough IPv6 | applications yet that breaking those is a big issue. | However, if we go | down the path of requiring applications to change, we | should make very, | very, very sure this is a one time thing and we build in | everything we | need for IPv6 - IPv15. How big will identifiers be in IPv9 and do you want to hard code that into your application? Ans: make it opaque. The application asks for a connection to a hostname only. Tony From owner-multi6@ops.ietf.org Sun Dec 8 05:14:38 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28728 for ; Sun, 8 Dec 2002 05:14:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18KyUN-00052V-00 for multi6-data@psg.com; Sun, 08 Dec 2002 02:16:43 -0800 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #2) id 18KyUJ-00051M-00 for multi6@ops.ietf.org; Sun, 08 Dec 2002 02:16:39 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 573EB353B9; Sun, 8 Dec 2002 02:26:03 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id gB8AG9iI014424; Sun, 8 Dec 2002 02:16:09 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Next question... Date: Sun, 8 Dec 2002 02:16:08 -0800 Message-ID: Thread-Topic: Next question... Thread-Index: AcKdfUJbcu3aKAjKSya3bdypXO4WdQBJGa5Q From: "Tony Li" To: , "Randy Bush" Cc: X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_02_03 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA28728 Tony, | > My concern is not so much about loss of control as it is with | > the administrative burden of implementing the policies. | | Isn't perception of burden really a function of direct vs. indirect | control? Umm... no, it's a function of the number of unique operations necessary to implement and maintain the desired policies. | > Most policies are going to be site-wide, not host specific. | > Having to distribute this policy and keep it consistent | > across an enterprise can be done by our standard system | > administration tools, but the effort involved in doing so is | > non-trivial and the number of exception hosts is likely to be | > small, so this just seems like a poor ROI for the site | > administrator(s). | | I agree that most policies are site wide, but ROI depends on how | valuable the exception list is. If you are in the exception | list, your | perspective is different than if you are not. As far as | triviality, that | depends on the mechansim. If it were something like a | static policy on | all host to prefer the prefix order in the RA, it seems | pretty trivial | to me. Such a policy is trivial regardless of the location of policy implementation. The question is about the effort to distribute that policy. If it's on the SBR's then it's less than ten systems. If it's on the hosts, then it's thousands and any rogue sysadmin can abuse it. | > Our job, as architects, is not to create an architecture with | > infinite flexibility. Rather, it is to reject those options | > which lead to unnecessary complications down the line. | | And our disagreement really comes down to definition of | 'necessary'. True. Why is individual host control 'necessary'? | > Control at the host seems like an infrequently used feature. | | Frequency is not an indication of value. Besides it is done on every | connection today, so that seems pretty frequent to me. AFAIK, no host has the wherewithal to make the intelligent routing decisions that you're proposing. Which connections are you thinking of? | > Note that policy for a specific host can be implemented | at either the | > site border router (SBR) or at the host, so removing the | > policy decision from the host isn't actually eliminating | > architectural flexibility. | | I absolutely disagree. Hosts actually make those policy | decisions today, | and the system works. The machine I am typing this on has 4 IPv4 | addresses, yet it has no trouble opening a connection to CNN.com by | picking from that list of possible sources, and the 8 available IPv4 | destination addresses. There seems to be a fear that providing more | choices to the host will magically make the world more complex. No. Providing the host with the information so that it can make the choice about 8 destination addresses and 4 source addresses is part of what's scary. That and distributing the policies. Tony From owner-multi6@ops.ietf.org Sun Dec 8 07:31:44 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00827 for ; Sun, 8 Dec 2002 07:31:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18L0cI-0009st-00 for multi6-data@psg.com; Sun, 08 Dec 2002 04:33:02 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 18L0cG-0009sg-00 for multi6@ops.ietf.org; Sun, 08 Dec 2002 04:33:00 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gB8CV5237731; Sun, 8 Dec 2002 13:31:06 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Sun, 8 Dec 2002 13:31:05 +0100 (CET) From: Iljitsch van Beijnum To: Tony Li cc: Subject: RE: network controls are necessary In-Reply-To: Message-ID: <20021208132136.F31466-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_02_03 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sun, 8 Dec 2002, Tony Li wrote: > | free/cheap/expensive), applications will want to make selecting > | addresses their business. > Yes, but should the application have the details about the locators? Or > should it specify its properties and then let underlying systems choose? > For the sake of a loosely coupled system, I'd say that the applications > shouldn't ever worry about locators. And this is regardless of whether > the host is implementing the policies or the SBR. This would be the diffserv paradigm rather than an address selection paradigm. Do we have enough information to make this choice at this time? > | However, if we go down the path of requiring applications to change, we > | should make very, very, very sure this is a one time thing and we > | build in everything we need for IPv6 - IPv15. > How big will identifiers be in IPv9 and do you want to hard code that > into your application? Ans: make it opaque. The application asks for > a connection to a hostname Yes! Can we all agree on this? > only. The application probably wants to include some additional information, such as the type of service that it needs/wants. Also, we may want to consider including a name space or address family identifier. That would make using IPv4 and IPv6 addresses as identifiers more easily backward compatible and knowing the nature of the host name makes selecting the right name to address mapping service easier. Iljitsch From owner-multi6@ops.ietf.org Sun Dec 8 12:33:55 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05459 for ; Sun, 8 Dec 2002 12:33:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18L5LL-000Jnn-00 for multi6-data@psg.com; Sun, 08 Dec 2002 09:35:51 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #2) id 18L5LJ-000Jnb-00 for multi6@ops.ietf.org; Sun, 08 Dec 2002 09:35:49 -0800 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id MAA03906; Sun, 8 Dec 2002 12:35:46 -0500 Date: Sun, 8 Dec 2002 12:35:46 -0500 From: "J. Noel Chiappa" Message-Id: <200212081735.MAA03906@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: RE: Next question... Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_02_03 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Margaret Wasserman > How does this differ from the GSE proposal -- routing goop inserted at > the edge routers? I must confess that at this remove I've forgotten the fine details of GSE. I do recall that it included more than just dividing the IPv6 address field into location and identity parts, although I do vaguely recall the function you alluded to (some of the location information being added at the border). Could you give us a brief refresher? > Would these locators be considered part of the IP address by upper > layers? Did you really mean to ask that exact question, or were you asking instead "would this location information be considered part of the identity of the far end, by upper layers?" If the latter, then I think the answer is definitely "no" - the whole point is to make "location" separate from identity, so that the former can change (although the binding between the two needs to be secured to prevent connection/etc hijacking). I said "location" since that might also include which ISP you're currently using, for a multi-homed site, even if your actual network connectivity hasn't changed. If the former, however, it would depend on i) exactly what scheme you pick for the two kinds of name (i.e. do you cram it into an IP address, or perhaps rather into some sort of option read by the higher level), and ii) whether you change e.g. TCPv6's checksum algorithm. Note that if you *do* make it part of the IPv6 address, you're partly (mostly?) vitiating the whole point of having separate location and identity, as discussed in the previous paragraph. At this point, it's too late for the combination of i) 8+8 and ii) not changing TCPv6, since the TCPv6 pseudo-header already includes all 16 bytes. So note that going with 8+8 now is not really very useful, since without ugly TCPv6 checksum hacks, it's going to be hard to switch to a different locator (at least, if your functional goal includes keeping open connections up). 16+16 looks attractive for that reason, plus to which applications which have already been modified to work with 16 byte identities will continue to work, too. Noel From owner-multi6@ops.ietf.org Sun Dec 8 13:02:28 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06201 for ; Sun, 8 Dec 2002 13:02:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18L5nW-000KZy-00 for multi6-data@psg.com; Sun, 08 Dec 2002 10:04:58 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #2) id 18L5nU-000KZi-00 for multi6@ops.ietf.org; Sun, 08 Dec 2002 10:04:56 -0800 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.9.1/8.9.1) id NAA04105; Sun, 8 Dec 2002 13:04:54 -0500 Date: Sun, 8 Dec 2002 13:04:54 -0500 From: "J. Noel Chiappa" Message-Id: <200212081804.NAA04105@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: RE: network controls are necessary Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=1.6 required=5.0 tests=SPAM_PHRASE_05_08 version=2.43 X-Spam-Level: * Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: "Joel M. Halpern" > One of the reasons I want to keep hosts out of the routing space is > that if we ever do find routing solutions that we want to use for new > capabilities (QoS or otherwise) I would not want to have to upgrade the > hosts as well as the routers to deliver such capabilities. On first reading this, I thought you were meaning that you wanted to keep hosts out of any involvement in path selection altogether (which I think is unreasonable - re-run statement about each car driver making their own routing choices :-). But I gather you instead that you simply mean that you don't want to have to change the hosts (more than once). This is reasonable, but I would go slightly further: the current routing architecture (i.e. based on exchange of routing tables) is so broken there's no point in having hosts involved in path selection until it has been ditched completely. > From: Iljitsch van Beijnum > People sitting in a bus can also be excellent drivers, but that doesn't > mean they get to second guess the bus driver. .. Getting routers to > work together is hard enough, getting hosts which are much more diverse > in every way to do the same is next to impossible. ## > However, that does not mean hosts should be kept stupid: any task a ## > host can perform autonomously without adverse effects on other systems ## > should be performed by the host and not by the network infrastructure. Exactly! I couldn't have said it better myself (and I'll probably be 'borrowing' this phrase in the future! :-). The only (minor) change I would make would be to say "{may} be performed by the host and not by the network infrastructure" - we probably want to provide the 'vanilla' version of the function somewhere in the network, so the host doesn't *have* to do it unless it wants to. Alas, the Multi-6 group has to live with the routing as it is, not as it ought to be, so this entire point, while of great interest, is purely academic at this stage. Noel From owner-multi6@ops.ietf.org Sun Dec 8 17:30:21 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11265 for ; Sun, 8 Dec 2002 17:30:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18L9xp-0002Up-00 for multi6-data@psg.com; Sun, 08 Dec 2002 14:31:53 -0800 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #2) id 18L9xh-0002TG-00 for multi6@ops.ietf.org; Sun, 08 Dec 2002 14:31:45 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 5D680353EF; Sun, 8 Dec 2002 14:41:07 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id gB8MVDiI026623; Sun, 8 Dec 2002 14:31:13 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: network controls are necessary Date: Sun, 8 Dec 2002 14:31:12 -0800 Message-ID: Thread-Topic: network controls are necessary Thread-Index: AcKetceA9euy8mkUQuG3zv5TJRofIgAUuhMQ From: "Tony Li" To: "Iljitsch van Beijnum" Cc: X-Spam-Status: No, hits=1.1 required=5.0 tests=SPAM_PHRASE_03_05 version=2.43 X-Spam-Level: * Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA11265 | > For the sake of a loosely coupled system, I'd say that | the applications | > shouldn't ever worry about locators. And this is | regardless of whether | > the host is implementing the policies or the SBR. | | This would be the diffserv paradigm rather than an address selection | paradigm. Do we have enough information to make this choice at this | time? Yes, I think so. It's not a matter of low level information, it's a matter of architectural principles. Address selection is pretty clearly a tight coupling of the application to network layer information. Any such coupling hampers an architecture because one cannot be changed without the other changing. This is the same reason that we create API's, system call interfaces, chip data sheets, etc. Simple well defined interfaces are a Good Thing. | > | However, if we go down the path of requiring | applications to change, we | > | should make very, very, very sure this is a one time | thing and we | > | build in everything we need for IPv6 - IPv15. | | > How big will identifiers be in IPv9 and do you want to | hard code that | > into your application? Ans: make it opaque. The | application asks for | > a connection to a hostname | | Yes! Can we all agree on this? | | > only. | | The application probably wants to include some additional | information, | such as the type of service that it needs/wants. Exactly. | Also, we | may want to | consider including a name space or address family | identifier. That would | make using IPv4 and IPv6 addresses as identifiers more | easily backward | compatible and knowing the nature of the host name makes | selecting the | right name to address mapping service easier. And this seems exactly backwards. If you can get your TCP connection to www.yahoo.com, why do you care if it's over IPv6, IPv4 or CLNP? To put it more clearly: if we can make the system work with less information on the interface between application and stack, we should. Yes, everything you take out of the interface will limit the power of the application, but we need to balance that against the complexity that it introduces. Nothing is perfect until you have removed all that can be removed. Tony From owner-multi6@ops.ietf.org Sun Dec 8 17:55:01 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11658 for ; Sun, 8 Dec 2002 17:55:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LAMl-0003Ll-00 for multi6-data@psg.com; Sun, 08 Dec 2002 14:57:39 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18LAMi-0003LX-00; Sun, 08 Dec 2002 14:57:36 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18LAMh-0004oN-00; Sun, 08 Dec 2002 14:57:35 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Tony Li Cc: multi6@ops.ietf.org Subject: RE: network controls are necessary References: Message-Id: Date: Sun, 08 Dec 2002 14:57:35 -0800 X-Spam-Status: No, hits=-0.5 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > To put it more clearly: if we can make the system work with > less information on the interface between application and stack, > we should. Yes, everything you take out of the interface will > limit the power of the application, but we need to balance that > against the complexity that it introduces. hourglass, a well-known win, revisited randy From owner-multi6@ops.ietf.org Sun Dec 8 18:41:30 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12286 for ; Sun, 8 Dec 2002 18:41:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LB5C-00058e-00 for multi6-data@psg.com; Sun, 08 Dec 2002 15:43:34 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 18LB4z-00056w-00 for multi6@ops.ietf.org; Sun, 08 Dec 2002 15:43:22 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gB8NgNr00939; Mon, 9 Dec 2002 00:42:24 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Mon, 9 Dec 2002 00:42:23 +0100 (CET) From: Iljitsch van Beijnum To: Tony Li cc: Subject: RE: network controls are necessary In-Reply-To: Message-ID: <20021209000058.F552-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_05_08 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sun, 8 Dec 2002, Tony Li wrote: > | Also, we may want to > | consider including a name space or address family > | identifier. That would > | make using IPv4 and IPv6 addresses as identifiers more > | easily backward > | compatible and knowing the nature of the host name makes > | selecting the > | right name to address mapping service easier. > And this seems exactly backwards. Hence the term "backward compatibility". > If you can get your TCP > connection to www.yahoo.com, why do you care if it's over IPv6, > IPv4 or CLNP? Actually I'm writing an article about the adoption of IPv6 so I'm surfing the web while keeping an eye on my "tcpdump -i gif0 ip6 port 80" output to see how many sites are v6 enabled. But that's not really germane to this discussion. What I was referring to was an AFI for the identifier, not for the locator. So I don't care about whether the packets end up being IPv6, IPv4 or CLNP, but I do care that "www.yahoo.com" is a FQDN and not an IPv4 address, an IPv6 address, a CLNP NET, or a phone number. I want to know it's a v4 or v6 address so I can build TCP packets that are compatible with today's IPv4 or IPv6 TCP packets, even if I then choose to transmit them over CLNP. I want to know if it's a phone number so I can apply the processing best used for phone numbers rather than feed it to the DNS and get nothing back. > To put it more clearly: if we can make the system work with > less information on the interface between application and stack, > we should. Yes, everything you take out of the interface will > limit the power of the application, but we need to balance that > against the complexity that it introduces. > Nothing is perfect until you have removed all that can be removed. On the other hand, something that can't be expanded later to accommodate new needs isn't very perfect either. Iljitsch From owner-multi6@ops.ietf.org Sun Dec 8 19:18:58 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12900 for ; Sun, 8 Dec 2002 19:18:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LBfv-0006Po-00 for multi6-data@psg.com; Sun, 08 Dec 2002 16:21:31 -0800 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #2) id 18LBfs-0006PE-00 for multi6@ops.ietf.org; Sun, 08 Dec 2002 16:21:29 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 82264353F7; Sun, 8 Dec 2002 16:30:52 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id gB90KviI028468; Sun, 8 Dec 2002 16:20:57 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: network controls are necessary Date: Sun, 8 Dec 2002 16:20:56 -0800 Message-ID: Thread-Topic: network controls are necessary Thread-Index: AcKfE2x6hukkzZnvQQK8y7ep3mFTEwABUd6Q From: "Tony Li" To: "Iljitsch van Beijnum" Cc: X-Spam-Status: No, hits=1.1 required=5.0 tests=SPAM_PHRASE_03_05 version=2.43 X-Spam-Level: * Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA12900 | What I was referring to was an AFI for the identifier, not for the | locator. So I don't care about whether the packets end up | being IPv6, | IPv4 or CLNP, but I do care that "www.yahoo.com" is a FQDN | and not an | IPv4 address, an IPv6 address, a CLNP NET, or a phone | number. I want to | know it's a v4 or v6 address so I can build TCP packets that are | compatible with today's IPv4 or IPv6 TCP packets, even if I | then choose | to transmit them over CLNP. I want to know if it's a phone | number so I | can apply the processing best used for phone numbers rather | than feed it | to the DNS and get nothing back. That shouldn't be necessary. Syntactically, they are all sufficiently different that the lower layers should be able to figure this out without difficulty. | > Nothing is perfect until you have removed all that can be removed. | | On the other hand, something that can't be expanded later | to accommodate | new needs isn't very perfect either. Hence the need for loose coupling. Tony From owner-multi6@ops.ietf.org Sun Dec 8 23:23:22 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16947 for ; Sun, 8 Dec 2002 23:23:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LFT6-000HEF-00 for multi6-data@psg.com; Sun, 08 Dec 2002 20:24:32 -0800 Received: from dhcp1.kurtis.pp.se ([195.43.225.70] helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #2) id 18LFT2-000HE0-00 for multi6@ops.ietf.org; Sun, 08 Dec 2002 20:24:29 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (8.12.2/8.10.2) with ESMTP id gB94Ocwt012096; Mon, 9 Dec 2002 05:24:39 +0100 (CET) Date: Fri, 6 Dec 2002 16:15:03 +0100 Subject: Re: Site local Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: "Brian E Carpenter" , "Iljitsch van Beijnum" , To: "Tony Li" From: Kurt Erik Lindqvist In-Reply-To: Message-Id: <7E8E9E66-092D-11D7-A3F3-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) X-Spam-Status: No, hits=-1.2 required=5.0 tests=DATE_IN_PAST_48_96,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > | Ok, I am more or less with the idea of locator+identifier. > | What I am > | worried about is the effects of this on the applications. > | > | My main reason for being against anything that could lead > | down a NAT > | road (and I am worried that any attempt besides assigning global > | addresses everywhere will lead there) is that I have seen > | the effects > | this has had on delaying deployment of new services and creating > | problems at end sites. > > > Well, let's think about this a bit... > > Let's assume that the transport layer is going to use only the > identifier, not the locator. So, for example, the identifier is > part of the TCP pseudo-header. We also need to assume that the > (architecturally evil) applications that today carry around > IPv4 addresses would morph into carrying around identifiers, but > NOT locators. > > If you're willing to stipulate to that, then NAT is not at all > necessary and the border routers do NOT need to know about specific > applications. > > Make sense? > Well, yes. BUT, the problem comes with the applications. I can see applications where this could be an issue, and where this would not be an issue. I still think that what this group is discussing needs feedback from applications. We need someone (preferably from the applications area) to write a document on how the various suggestions would impact various application layer protocols. - kurtis - From owner-multi6@ops.ietf.org Sun Dec 8 23:23:29 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16961 for ; Sun, 8 Dec 2002 23:23:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LFU0-000HGL-00 for multi6-data@psg.com; Sun, 08 Dec 2002 20:25:28 -0800 Received: from dhcp1.kurtis.pp.se ([195.43.225.70] helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #2) id 18LFTx-000HG4-00 for multi6@ops.ietf.org; Sun, 08 Dec 2002 20:25:25 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (8.12.2/8.10.2) with ESMTP id gB94Pvwt012121; Mon, 9 Dec 2002 05:25:57 +0100 (CET) Date: Fri, 6 Dec 2002 17:23:19 +0100 Subject: Re: (ipv6mh) the Rebel Alliance meetings in Atlanta (long) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: ipv6mh , To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: <20021204103719.B22837-100000@sequoia.muada.com> Message-Id: <0814D5B5-0937-11D7-A3F3-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) X-Spam-Status: No, hits=-1.5 required=5.0 tests=DATE_IN_PAST_48_96,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> Well, what I meant was that the day an ISP run out of their PI blocks >> they will just continue down the address block, just as ISPs today are >> announcing more specifics than their RIR allocation and complaining >> that these are not accepted. I don't see why we think people would >> behave differently just because this is IPv6.... > > We think that because they do. At the moment, at least. Also, we want > them to, as current IPv4 routing practices aren't exactly great. On the > one hand it is good that people want to keep the IPv6 routing table > clean, on the other hand we don't want to be so restrictive it doesn't > work. Remember that most people have a good reason to pollute the IPv4 > routing table. Just not allowing this without offering alternatives > isn't good enough. Well, let me restate what I said in Atlanta: 1) We have no idea how popular multihoming is in reality. If it turns out my DLS subscriber charges me $50 a month for a single homed connection and $500 a month for multihoming this might not be as popular as we think. One thing I think we must realize is that a) IPv6 will be more expensive that IPv4, b) multihoming will not be for free. 2) We don't understand what effects the "better starting point" with aggregation will have on the routing table. What I suggest will give us experience with the above and then we have some facts to discuss around. Today we only have wet dreams. > > Disagree. People who multihome care about their connectivity more than > others. For PI, 90% isn't enough. 99% isn't even enough. On the other > hand, for shooting holes in PA, having a 90% backup is probably good > enough, but I'd rather have 99% or even 100%, especially if I have to > eat the cost and annoyance of renumbering when changing my primary ISP. Uhm so you support my proposal then? Makeing it a requirement to accept the longer prefixes would help - right? > >> Still, I agree that if >> we can come up with a common solution that would be better. My >> proposal >> is to accept /48 for the time being and not scale back until there is >> a >> new solution. > > I could live with that if we can get consensus among operators. Without > those /48s in the routing table this is still too risky as it doesn't > protect you against an entire ISP going down. I don't think the operators are a problem here. Finding enough operators to actually connect the customers are a problem, not the prefix length. > Also, if we end up with a multi-address solution, it could very well be > that all PA will be tied to interconnect locations. For instance, I > live > between two of the largest exchange points in the world: the LINX and > the AMS-IX. If I were a single homed multi-address capable network I > would want addresses that are always routed over the LINX and also > addresses that are always routed over the AMS-IX, so I can do traffic > engineering. Having been one of the largest operators connected to both AMS-IX and Linx, I would not want this. But most people probably agree. I would have asked for the traffic flowing over the private peerings. >> What is it that we think we gain with these specific blocks, be it for >> site-locals or multihoming? The number of routes are not going to be >> less. > > This way you can easily identify these routes with a prefix filter. I'm > not saying that's always absolutely necessary, but as long as we have > the choice, why not create this option? But if we introduce prefix filters we lost the entire idea of creating these in the first place. > > BTW, I'm writing an article about if/when IPv6 will be adopted for a > Dutch magazine. I'm still looking for good quotes from IPv6-skeptics. > :-) > I am not necessary an IPv6 sceptic. I just don't think it will give us peace in the middle-east. Contact me offline if you want to talk more. MY GSM number is in my RIPE object. - kurtis - From owner-multi6@ops.ietf.org Sun Dec 8 23:23:37 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16975 for ; Sun, 8 Dec 2002 23:23:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LFTx-000HG7-00 for multi6-data@psg.com; Sun, 08 Dec 2002 20:25:25 -0800 Received: from dhcp1.kurtis.pp.se ([195.43.225.70] helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #2) id 18LFTu-000HFu-00 for multi6@ops.ietf.org; Sun, 08 Dec 2002 20:25:22 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (8.12.2/8.10.2) with ESMTP id gB94Pqwt012118; Mon, 9 Dec 2002 05:25:55 +0100 (CET) Date: Fri, 6 Dec 2002 17:13:04 +0100 Subject: Re: Site local Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: <20021204103114.P22837-100000@sequoia.muada.com> Message-Id: <9961D24E-0935-11D7-A3F3-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) X-Spam-Status: No, hits=-0.4 required=5.0 tests=DATE_IN_PAST_48_96,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_05_08,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > The problem with NAT is not that the addresses in the IP header are > changed. The problem with NAT is that you're not talking to who you > think you are talking to. And if you don't know, you can't tell someone > else, so it becomes impossible to set up new connections in a different > way than from the same source to the same destination as the current > session. So this breaks pretty much everything except stuff that > follows > a simple client/server model. It even breaks that. See SIP through NAT. See IP-Sec through NAT, etc. > In a identifier/locator system, the endpoints are always aware of the > identifiers. Since such a system isn't here yet, we can make this a > very > hard requirement. Changing the locators around is then no longer an > issue. > I am still worried about some of the application protocols, but I am not a applications guy. So I still think we should get this run through the applications area. - kurtis - From owner-multi6@ops.ietf.org Mon Dec 9 01:41:59 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19711 for ; Mon, 9 Dec 2002 01:41:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LHc7-000OEt-00 for multi6-data@psg.com; Sun, 08 Dec 2002 22:41:59 -0800 Received: from mail4.microsoft.com ([131.107.3.122]) by psg.com with esmtp (Exim 3.36 #2) id 18LHc4-000ODj-00 for multi6@ops.ietf.org; Sun, 08 Dec 2002 22:41:56 -0800 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Sun, 8 Dec 2002 22:41:19 -0800 Received: from 157.54.8.23 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 08 Dec 2002 22:41:25 -0800 Received: from RED-IMC-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Sun, 8 Dec 2002 22:41:21 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Sun, 8 Dec 2002 22:41:21 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Sun, 8 Dec 2002 22:41:24 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: (ipv6mh) the Rebel Alliance meetings in Atlanta (long) Date: Sun, 8 Dec 2002 22:40:54 -0800 Message-ID: Thread-Topic: (ipv6mh) the Rebel Alliance meetings in Atlanta (long) Thread-Index: AcKfOy5il4EJmNxOR6+Qui5GdOz9igAEe1wb From: "Christian Huitema" To: "Kurt Erik Lindqvist" , "Iljitsch van Beijnum" Cc: "ipv6mh" , X-OriginalArrivalTime: 09 Dec 2002 06:41:24.0495 (UTC) FILETIME=[FE2549F0:01C29F4D] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03,SUPERLONG_LINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA19711 There are two forms of multi-homing that can happen quite quickly. The obvious first is multi-homing a site to both native IPv6 and "6to4". Assuming that you have at least one global IPv4 for the site, multi-homing to 6to4 does not involve any extra payment for connectivity and does improve communication performance when exchanging data with 6to4 destinations. The second one is multi-homing to both a fixed connection and a wireless connection. For example, I could connect my home network to a cable modem service and to a local wireless community such as "Seattle wireless." Again, not much extra payment involved; the wireless stuff is likely to be handled by a couple of motivated teen-agers... -- Christian Huitema ________________________________ From: Kurt Erik Lindqvist [mailto:kurtis@kurtis.pp.se] Sent: Fri 12/6/2002 8:23 AM To: Iljitsch van Beijnum Cc: ipv6mh; multi6@ops.ietf.org Subject: Re: (ipv6mh) the Rebel Alliance meetings in Atlanta (long) >> Well, what I meant was that the day an ISP run out of their PI blocks >> they will just continue down the address block, just as ISPs today are >> announcing more specifics than their RIR allocation and complaining >> that these are not accepted. I don't see why we think people would >> behave differently just because this is IPv6.... > > We think that because they do. At the moment, at least. Also, we want > them to, as current IPv4 routing practices aren't exactly great. On the > one hand it is good that people want to keep the IPv6 routing table > clean, on the other hand we don't want to be so restrictive it doesn't > work. Remember that most people have a good reason to pollute the IPv4 > routing table. Just not allowing this without offering alternatives > isn't good enough. Well, let me restate what I said in Atlanta: 1) We have no idea how popular multihoming is in reality. If it turns out my DLS subscriber charges me $50 a month for a single homed connection and $500 a month for multihoming this might not be as popular as we think. One thing I think we must realize is that a) IPv6 will be more expensive that IPv4, b) multihoming will not be for free. 2) We don't understand what effects the "better starting point" with aggregation will have on the routing table. What I suggest will give us experience with the above and then we have some facts to discuss around. Today we only have wet dreams. > > Disagree. People who multihome care about their connectivity more than > others. For PI, 90% isn't enough. 99% isn't even enough. On the other > hand, for shooting holes in PA, having a 90% backup is probably good > enough, but I'd rather have 99% or even 100%, especially if I have to > eat the cost and annoyance of renumbering when changing my primary ISP. Uhm so you support my proposal then? Makeing it a requirement to accept the longer prefixes would help - right? > >> Still, I agree that if >> we can come up with a common solution that would be better. My >> proposal >> is to accept /48 for the time being and not scale back until there is >> a >> new solution. > > I could live with that if we can get consensus among operators. Without > those /48s in the routing table this is still too risky as it doesn't > protect you against an entire ISP going down. I don't think the operators are a problem here. Finding enough operators to actually connect the customers are a problem, not the prefix length. > Also, if we end up with a multi-address solution, it could very well be > that all PA will be tied to interconnect locations. For instance, I > live > between two of the largest exchange points in the world: the LINX and > the AMS-IX. If I were a single homed multi-address capable network I > would want addresses that are always routed over the LINX and also > addresses that are always routed over the AMS-IX, so I can do traffic > engineering. Having been one of the largest operators connected to both AMS-IX and Linx, I would not want this. But most people probably agree. I would have asked for the traffic flowing over the private peerings. >> What is it that we think we gain with these specific blocks, be it for >> site-locals or multihoming? The number of routes are not going to be >> less. > > This way you can easily identify these routes with a prefix filter. I'm > not saying that's always absolutely necessary, but as long as we have > the choice, why not create this option? But if we introduce prefix filters we lost the entire idea of creating these in the first place. > > BTW, I'm writing an article about if/when IPv6 will be adopted for a > Dutch magazine. I'm still looking for good quotes from IPv6-skeptics. > :-) > I am not necessary an IPv6 sceptic. I just don't think it will give us peace in the middle-east. Contact me offline if you want to talk more. MY GSM number is in my RIPE object. - kurtis - From owner-multi6@ops.ietf.org Mon Dec 9 08:58:20 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09378 for ; Mon, 9 Dec 2002 08:58:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LORx-000OFe-00 for multi6-data@psg.com; Mon, 09 Dec 2002 05:59:57 -0800 Received: from mailman.cisco.com ([171.70.144.185]) by psg.com with esmtp (Exim 3.36 #2) id 18LORm-000OB2-01 for multi6@ops.ietf.org; Mon, 09 Dec 2002 05:59:46 -0800 Received: from [64.100.160.211] by mailman.cisco.com (171.70.144.185) with ESMTP; 09 Dec 2002 06:00:02 +0000 Message-ID: <3DF3CD83.4060908@cisco.com> Date: Sun, 08 Dec 2002 14:53:55 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021118 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tony Li CC: Iljitsch van Beijnum , multi6@ops.ietf.org Subject: Re: Next question... References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.2 required=5.0 tests=DATE_IN_PAST_06_12,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tony Li wrote: > | I would still like some hint from the host to the border > | router that the > | current connection isn't working. > > > Not an unreasonable request. At first blush this may seem like a reasonable request, but there are so many reasons why a remote host would not respond that it would be impossible for the routing system to trust the local host with such requests. For instance, perhaps the reason the remote host isn't responding is because the remote application has not properly authenticated the local user. Another reason is that the remote host is down or misconfigured. Eliot From owner-multi6@ops.ietf.org Mon Dec 9 08:58:28 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09401 for ; Mon, 9 Dec 2002 08:58:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LORo-000OFU-00 for multi6-data@psg.com; Mon, 09 Dec 2002 05:59:48 -0800 Received: from mailman.cisco.com ([171.70.144.185]) by psg.com with esmtp (Exim 3.36 #2) id 18LORm-000OB2-00 for multi6@ops.ietf.org; Mon, 09 Dec 2002 05:59:46 -0800 Received: from [64.100.160.211] by mailman.cisco.com (171.70.144.185) with ESMTP; 09 Dec 2002 06:00:00 +0000 Message-ID: <3DF3CCB9.5060004@cisco.com> Date: Sun, 08 Dec 2002 14:50:33 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021118 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: "Joel M. Halpern" , multi6@ops.ietf.org Subject: Re: network controls are necessary References: <20021207220649.C31466-100000@sequoia.muada.com> In-Reply-To: <20021207220649.C31466-100000@sequoia.muada.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.2 required=5.0 tests=DATE_IN_PAST_06_12,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > Sure we do, hosts such as laptops routinely have different interfaces > connecting to different services with different properties. Today, we > typically don't use those at the same time, but it's not a big leap to > expect this will happen more in the future. For instance, if I'm walking > around a convention center with my laptop while I'm downloading a file > and I'm looking at a device over a telnet/SSH connection, I would like > both of these applications to use wireless LAN connectivity if > available. But when I'm out of range of the wireless LAN, I'd want the > terminal connection to switch to GPRS or something similar, but the > download should simply stop and resume later when there is more/cheaper > bandwidth. And this is easily accomplished without any support from the routing system today. All it requires is an ACL saying what sort of traffic is allowed on a given link. In two words, access lists. That has NOTHING to do with the routing system. Eliot From owner-multi6@ops.ietf.org Mon Dec 9 11:03:01 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15274 for ; Mon, 9 Dec 2002 11:02:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LQOR-0007gp-00 for multi6-data@psg.com; Mon, 09 Dec 2002 08:04:27 -0800 Received: from portal.hamachi.org ([140.239.227.17]) by psg.com with esmtp (Exim 3.36 #2) id 18LQOJ-0007gD-00 for multi6@ops.ietf.org; Mon, 09 Dec 2002 08:04:19 -0800 Received: from syn.hamachi.org (localhost [127.0.0.1]) by portal.hamachi.org (Postfix) with ESMTP id 36CA917926; Mon, 9 Dec 2002 11:00:01 -0500 (EST) Received: from syn.hamachi.org (sommerfeld@localhost) by syn.hamachi.org (8.11.6/8.8.8) with ESMTP id gB9G3qU20319; Mon, 9 Dec 2002 11:03:52 -0500 (EST) Message-Id: <200212091603.gB9G3qU20319@syn.hamachi.org> From: Bill Sommerfeld To: "Joel M. Halpern" Cc: multi6@ops.ietf.org Subject: Re: network controls are necessary Reply-To: sommerfeld@orchard.arlington.ma.us Date: Mon, 09 Dec 2002 11:03:52 -0500 X-Spam-Status: No, hits=0.9 required=5.0 tests=MSG_ID_ADDED_BY_MTA_3,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk > 1) The address pair does not work because there really is no connectivity > over that path. In that case, presumably routing will catch up pretty > quickly. I'm curious about something like that can be made to happen.. That seems to require either that alternate paths with alternate locators have to silently cover for each other.. (which appears to have the layer-9 probloems of geographic addressing), or that information about failure of (for instance) an individual link to a site will "pretty quickly" propagate all the way across the network, which seems hard to scale up.. Maybe we have different ideas about what "pretty quickly" means. Maybe a site could withdraw the identifier->locator mapping when a link is known to have lost connectivity, but that clearly limits what can be done to cache identifier-locator mappings.. - Bill From owner-multi6@ops.ietf.org Mon Dec 9 11:34:21 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16818 for ; Mon, 9 Dec 2002 11:34:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LQtf-000AGH-00 for multi6-data@psg.com; Mon, 09 Dec 2002 08:36:43 -0800 Received: from mail2.microsoft.com ([131.107.3.124]) by psg.com with esmtp (Exim 3.36 #2) id 18LQtc-000ACp-00 for multi6@ops.ietf.org; Mon, 09 Dec 2002 08:36:40 -0800 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 9 Dec 2002 08:35:43 -0800 Received: from 157.54.8.109 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 09 Dec 2002 08:35:43 -0800 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by INET-HUB-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Mon, 9 Dec 2002 08:33:21 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 9 Dec 2002 08:35:20 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Mon, 9 Dec 2002 08:36:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: network controls are necessary Date: Mon, 9 Dec 2002 08:36:03 -0800 Message-ID: Thread-Topic: network controls are necessary Thread-Index: AcKdf64v3x6Wjt59S8SbloSi0kc5ygAGJEzgAIH6gAA= From: "Christian Huitema" To: "Tony Li" Cc: X-OriginalArrivalTime: 09 Dec 2002 16:36:04.0946 (UTC) FILETIME=[115A0B20:01C29FA1] X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA16818 > I have nothing to gain by having control in the SBR. I no longer work > at Cisco, so I have no interest in placing more responsibility and > complexity into the CPE gear. I'm just trying to design a clean > architecture > that scales. That's what we should all be striving for. I have heard many assertions that this or that solution does not scale. Since we are engineers, I would very much like that references to scaling be backed up by a complexity analysis. Lacking that, we are dealing with beliefs and esthetics. For example, we can say that, with CIDR, the size of the routing tables in the DFZ routers should scale as something between O(P), which is the number of DFZ providers, which itself is expected to scale with the number of sites as something like either O(log S) or O(sqrt S), depending which opinion you believe. On the other hand, without CIDR, the routing tables would scale as O(S). That makes the comparison quite clear. -- Christian Huitema From owner-multi6@ops.ietf.org Mon Dec 9 12:59:58 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21970 for ; Mon, 9 Dec 2002 12:59:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LSDU-000H8q-00 for multi6-data@psg.com; Mon, 09 Dec 2002 10:01:16 -0800 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #2) id 18LSDQ-000H8d-00 for multi6@ops.ietf.org; Mon, 09 Dec 2002 10:01:12 -0800 Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Mon, 09 Dec 2002 10:01:07 -0800 Reply-To: From: "Tony Hain" To: "'Tony Li'" , "'Eliot Lear'" Cc: "'Joel M. Halpern'" , Subject: RE: network controls are necessary Date: Mon, 9 Dec 2002 10:00:57 -0800 Message-ID: <053b01c29fac$eccb1a40$237ba8c0@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA21970 Tony Li wrote: > .... > I'm somewhat offended that you would accuse us of being > partisan. I was not trying to acuse or label anyone. My point was that we all are bringing viewpoints based on past expierence, and they can cause particular approaches to be declaired 'too complex' without serious study. > This > is an architectural discussion about the right engineering compromises > to help grow the Internet. I'm fully cognizant of what a > host administrator > has to do. I was a Unix and VMS sysadmin for USC from 1983-2000. We > supported over 2000 workstations and 30,000 user accounts. > Simplifying > host management was a requirement then and still. Simplifying does not always mean moving the function into the network. In fact that approach may make the host job more complex, because the network has limited knowledge. > > I have nothing to gain by having control in the SBR. I no > longer work > at Cisco, so I have no interest in placing more responsibility and > complexity into the CPE gear. I'm just trying to design a > clean architecture > that scales. That's what we should all be striving for. I agree, and was not trying to acuse anyone of focusing on financial gain. I do think we need more voices involved from host & network administrators of end sites that are currently multi-homed. The real trick is finding the people from that set who are willing to put time into the IETF, and who have some understanding of the range of options they will have with IPv6. If everyone approaches this from the standpoint of 'this is how it is done in IPv4', we may be unnecessarily limiting our options. > > Our first job is to define an architecture, not a mechanism. That > architecture will be able to support some policies, not all. I agree we can't arbitrarily support all policies, but we appear to be writing off a significant number of them because the mechanisms that would allow them to fit into the target architecture are too complex. > We need to > understand the bounds of the policies that can be supported by a > particular architecture and to choose the architecture which > balances policy against complexity and our other design goals. > Supporting all possible policies is not an architectural trait that > is supported with either host or SBR policies. The amount of possibly > relevant information that either of them will have is far too limited > in any rational design to begin to implement all policies. > > So we have to choose. Yes we have to choose. My concern is that the vocal participants are not providing a balanced perspective on the cost / benefit tradeoffs. Again, this is not to fault anyone, just raise awareness that we need more participation from multi-homed host administrators. Tony From owner-multi6@ops.ietf.org Mon Dec 9 13:50:59 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24545 for ; Mon, 9 Dec 2002 13:50:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LT1q-000LfX-00 for multi6-data@psg.com; Mon, 09 Dec 2002 10:53:18 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 18LT1l-000Lf9-00 for multi6@ops.ietf.org; Mon, 09 Dec 2002 10:53:14 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gB9IqB602891; Mon, 9 Dec 2002 19:52:11 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Mon, 9 Dec 2002 19:52:11 +0100 (CET) From: Iljitsch van Beijnum To: Kurt Erik Lindqvist cc: Subject: Re: Site local In-Reply-To: <9961D24E-0935-11D7-A3F3-000393AB1404@kurtis.pp.se> Message-ID: <20021209192320.J552-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 6 Dec 2002, Kurt Erik Lindqvist wrote: > > In a identifier/locator system, the endpoints are always aware of the > > identifiers. Since such a system isn't here yet, we can make this a very > > hard requirement. Changing the locators around is then no longer an issue. > I am still worried about some of the application protocols, but I am > not a applications guy. So I still think we should get this run through > the applications area. Well, let's create something that we feel comfortable showing others first. I don't think the application part is all that complex. Either you are a sender or a receiver. The sender sets up a session or packet. The most important information here is the destination address/name and port, but the sender may also specify a source. The sender fires off a TCP session or a (UDP) packet. Meanwhile, the receiver has started listening on an address/port. A packet or session request comes in. The receiver looks at the source address/port and decides whether to accept the session/packet. All reasonably simple. The problems start when one or both ends (or a third and so on end) of the communication puts information about the addresses and ports in a protocol but these addresses/ports aren't the ones aren't the real ones because they are changed somewhere along the way. If we create new identifiers for the applications to work with and make sure those aren't changed in the middle at any point, we should be fine. Iljitsch From owner-multi6@ops.ietf.org Mon Dec 9 14:05:00 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25370 for ; Mon, 9 Dec 2002 14:04:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LTF8-000Mws-00 for multi6-data@psg.com; Mon, 09 Dec 2002 11:07:02 -0800 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #2) id 18LTF6-000Mrg-00 for multi6@ops.ietf.org; Mon, 09 Dec 2002 11:07:00 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 3E8D63548C; Mon, 9 Dec 2002 11:16:24 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id gB9J6SiI003121; Mon, 9 Dec 2002 11:06:28 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Next question... Date: Mon, 9 Dec 2002 11:06:27 -0800 Message-ID: Thread-Topic: Next question... Thread-Index: AcKfiy1C2KduecRvTvyVsgUUIHFQvAAKsSDA From: "Tony Li" To: "Eliot Lear" Cc: "Iljitsch van Beijnum" , X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA25370 | Tony Li wrote: | > | I would still like some hint from the host to the border | > | router that the | > | current connection isn't working. | > | > | > Not an unreasonable request. | | At first blush this may seem like a reasonable request, but | there are so | many reasons why a remote host would not respond that it would be | impossible for the routing system to trust the local host with such | requests. For instance, perhaps the reason the remote host isn't | responding is because the remote application has not properly | authenticated the local user. Another reason is that the | remote host is | down or misconfigured. Assuming that the request is authenticated, what's the real issue? Yes, the host cannot know that it is impossible to satisfy the request, but all this is is a hint to try another alternative. Tony From owner-multi6@ops.ietf.org Mon Dec 9 14:07:25 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25530 for ; Mon, 9 Dec 2002 14:07:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LTI7-000N98-00 for multi6-data@psg.com; Mon, 09 Dec 2002 11:10:07 -0800 Received: from dmz1.procket.com ([65.174.124.36]) by psg.com with esmtp (Exim 3.36 #2) id 18LTI5-000N4E-00 for multi6@ops.ietf.org; Mon, 09 Dec 2002 11:10:05 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 0DC0123C3A; Mon, 9 Dec 2002 11:08:43 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id gB9J9YiI003232; Mon, 9 Dec 2002 11:09:34 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: network controls are necessary Date: Mon, 9 Dec 2002 11:09:33 -0800 Message-ID: Thread-Topic: network controls are necessary Thread-Index: AcKfnW/TImMHf3VrRSWE+wFWlElpOgAGNRIw From: "Tony Li" To: , "Joel M. Halpern" Cc: X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA25530 | Maybe a site could withdraw the identifier->locator mapping when a | link is known to have lost connectivity, but that clearly limits | what can be done to cache identifier-locator mappings.. Oy. I think the thought was that the routing system would detect the loss of connectivity via the locator and would send an ICMP unreachable, which would then trigger a switch to an alternate locator. Tony From owner-multi6@ops.ietf.org Mon Dec 9 14:08:35 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25645 for ; Mon, 9 Dec 2002 14:08:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LTJA-000NEf-00 for multi6-data@psg.com; Mon, 09 Dec 2002 11:11:12 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 18LTJ5-000NEG-00 for multi6@ops.ietf.org; Mon, 09 Dec 2002 11:11:07 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gB9J9Ru02922; Mon, 9 Dec 2002 20:09:27 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Mon, 9 Dec 2002 20:09:26 +0100 (CET) From: Iljitsch van Beijnum To: Eliot Lear cc: Subject: Re: Next question... In-Reply-To: <3DF3CD83.4060908@cisco.com> Message-ID: <20021209195700.F552-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sun, 8 Dec 2002, Eliot Lear wrote: > > | I would still like some hint from the host to the border > > | router that the > > | current connection isn't working. > > Not an unreasonable request. > At first blush this may seem like a reasonable request, but there are so > many reasons why a remote host would not respond that it would be > impossible for the routing system to trust the local host with such > requests. For instance, perhaps the reason the remote host isn't > responding is because the remote application has not properly > authenticated the local user. Another reason is that the remote host is > down or misconfigured. I'm not sure if I understand what you're getting at the the issue of trust. But there is another problem: a site has many hosts. As you say, a host can be down, but that doesn't mean a neighboring host is also down. So if the SBR is going to reroute the traffic for a host a the source's request, this must be done on a per-destination host basis, or the source must request the alternate path in each individual packet, for instance with a diffserv code point. Both of these are at least somewhat problematic. All of this makes me feel that doing this at the source host in the first place might be a better solution in many cases. From owner-multi6@ops.ietf.org Mon Dec 9 14:13:47 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25984 for ; Mon, 9 Dec 2002 14:13:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LTOB-000NlB-00 for multi6-data@psg.com; Mon, 09 Dec 2002 11:16:23 -0800 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #2) id 18LTO9-000Nh6-00 for multi6@ops.ietf.org; Mon, 09 Dec 2002 11:16:21 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 119233548F; Mon, 9 Dec 2002 11:25:46 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id gB9JFoiI003533; Mon, 9 Dec 2002 11:15:50 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: network controls are necessary Date: Mon, 9 Dec 2002 11:15:50 -0800 Message-ID: Thread-Topic: network controls are necessary Thread-Index: AcKdf64v3x6Wjt59S8SbloSi0kc5ygAGJEzgAIH6gAAABZeiQA== From: "Tony Li" To: "Christian Huitema" Cc: X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_02_03 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA25984 | For example, we can say that, with CIDR, the size of the | routing tables | in the DFZ routers should scale as something between O(P), | which is the | number of DFZ providers, which itself is expected to scale with the | number of sites as something like either O(log S) or O(sqrt S), | depending which opinion you believe. On the other hand, | without CIDR, | the routing tables would scale as O(S). That makes the | comparison quite | clear. Christian, For M multihomed sites, CIDR will give us growth of O(P + M), where M is likely to come to dominate (and overwhelm). We need an architecture where we have some confidence that in the long term, the M factor is either removed from the equation or controlled. Certainly something like O(P + log M) might be reasonable, but I see no way of doing that other than something like the geographic approach and the issues there are considerable. I can see a way to get to O(P), but we're a long way from consensus on that. In any case, the real scalability requirement is that d(DFZ) ------ << Moore's law dt O(P+M) does not meet this requirement, IMHO. Tony From owner-multi6@ops.ietf.org Mon Dec 9 14:21:14 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26452 for ; Mon, 9 Dec 2002 14:21:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LTVH-000OPU-00 for multi6-data@psg.com; Mon, 09 Dec 2002 11:23:43 -0800 Received: from mailman.cisco.com ([171.70.144.185] helo=halt-in.cisco.com) by psg.com with esmtp (Exim 3.36 #2) id 18LTV7-000OOB-00 for multi6@ops.ietf.org; Mon, 09 Dec 2002 11:23:33 -0800 Received: from [64.100.160.211] by halt-in.cisco.com (171.70.144.185) with ESMTP; 09 Dec 2002 11:21:35 +0000 Message-ID: <3DF4ED21.10905@cisco.com> Date: Mon, 09 Dec 2002 11:21:05 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021118 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tony Li CC: Iljitsch van Beijnum , multi6@ops.ietf.org Subject: Re: Next question... References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tony Li wrote: > Assuming that the request is authenticated, what's the real issue? > Yes, the host cannot know that it is impossible to satisfy the > request, but all this is is a hint to try another alternative. I DDOS attack the far end. The local end then sends an authenticated hint to the routing system. In fact, if I DDOS a popular host, I can get a lot of local ends to provide "hints" and thus indirectly DDOS the routing system. And then suppose the routing system believes the hint. Now I can stop my DDOS on the host and go hide. OTOH, if a host wants to provide either quality or reachability information about itself, I'm okay with that so long as it's authenticated and we can find a way to sanely aggregate the information. Eliot From owner-multi6@ops.ietf.org Mon Dec 9 14:28:44 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26839 for ; Mon, 9 Dec 2002 14:28:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LTck-000P97-00 for multi6-data@psg.com; Mon, 09 Dec 2002 11:31:26 -0800 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #2) id 18LTcf-000P7M-00 for multi6@ops.ietf.org; Mon, 09 Dec 2002 11:31:22 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id C619B35496; Mon, 9 Dec 2002 11:40:45 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id gB9JUliI004361; Mon, 9 Dec 2002 11:30:47 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: network controls are necessary Date: Mon, 9 Dec 2002 11:30:47 -0800 Message-ID: Thread-Topic: network controls are necessary Thread-Index: AcKfrPqMzN/08TArQCSuKd5wTaQgugACzZtw From: "Tony Li" To: , "Eliot Lear" Cc: "Joel M. Halpern" , X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_02_03 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA26839 Tony, | I was not trying to acuse or label anyone. My point was | that we all are | bringing viewpoints based on past expierence, and they can cause | particular approaches to be declaired 'too complex' without serious | study. Yes, I'm aware that we all have biases and that rational engineering should dominate the conversation. Thank you for the reminder. If you see us straying from the path, please feel free to remind us again. | Simplifying does not always mean moving the function into | the network. | In fact that approach may make the host job more complex, | because the | network has limited knowledge. IMHO, the network includes the hosts. Moving the function into the routing subsystem may or may not simplify the overall system. Our job has to be to weigh the advantages of the alternatives and weight them properly. | > Our first job is to define an architecture, not a mechanism. That | > architecture will be able to support some policies, not all. | | I agree we can't arbitrarily support all policies, but we | appear to be | writing off a significant number of them because the mechanisms that | would allow them to fit into the target architecture are | too complex. That is bound to happen. There are an infinite set of policies (my packets should all go through Phoenix, but only on Tuesdays of months with an 'R' in them) and we will necessarily support fewer of them than we will have to exclude. Ergo, we need to decide which ones we need to support. To do that we need to understand which ones are going to have the biggest impact and the cost for supporting them. Some policies are easy to support, but no one will use them. No point there. Other policies would be very helpful, but would require us to carry a great deal of information. Those we might find to be too expensive. We need to make the cost/benefit analysis and make the call(s). | Yes we have to choose. My concern is that the vocal | participants are not | providing a balanced perspective on the cost / benefit | tradeoffs. Again, | this is not to fault anyone, just raise awareness that we need more | participation from multi-homed host administrators. Not to oppose that, but I think that Craig has been a fine representative. More are certainly welcome. Tony From owner-multi6@ops.ietf.org Mon Dec 9 14:29:46 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26874 for ; Mon, 9 Dec 2002 14:29:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LTdn-000PIh-00 for multi6-data@psg.com; Mon, 09 Dec 2002 11:32:31 -0800 Received: from portal.hamachi.org ([140.239.227.17]) by psg.com with esmtp (Exim 3.36 #2) id 18LTdm-000PIS-00 for multi6@ops.ietf.org; Mon, 09 Dec 2002 11:32:30 -0800 Received: from syn.hamachi.org (localhost [127.0.0.1]) by portal.hamachi.org (Postfix) with ESMTP id 6D58217926; Mon, 9 Dec 2002 14:28:13 -0500 (EST) Received: from syn.hamachi.org (sommerfeld@localhost) by syn.hamachi.org (8.11.6/8.8.8) with ESMTP id gB9JW4L22544; Mon, 9 Dec 2002 14:32:04 -0500 (EST) Message-Id: <200212091932.gB9JW4L22544@syn.hamachi.org> From: Bill Sommerfeld To: "Tony Li" Cc: sommerfeld@orchard.arlington.ma.us, "Joel M. Halpern" , multi6@ops.ietf.org Subject: Re: network controls are necessary In-Reply-To: Message from "Tony Li" of "Mon, 09 Dec 2002 11:09:33 PST." Reply-To: sommerfeld@orchard.arlington.ma.us Date: Mon, 09 Dec 2002 14:32:01 -0500 X-Spam-Status: No, hits=0.1 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_3,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk > | Maybe a site could withdraw the identifier->locator mapping when a > | link is known to have lost connectivity, but that clearly limits > | what can be done to cache identifier-locator mappings.. > > Oy. I think the thought was that the routing system would detect the > loss of connectivity via the locator and would send an ICMP unreachable, > which would then trigger a switch to an alternate locator. I thought of that sort of mechanism but immediately dismissed it; it's got a track record of failing miserably in the as-built Internet[1]. I'm skeptical that this would be effective without some sort of black-hole detection (rotating to a new locator after a couple RTO's of silence?). - Bill [1] Path MTU discovery. Try surfing the web with a <1500 MTU bottleneck in the path some time. PPPoE implementations which rewrite TCP MSS options don't count. From owner-multi6@ops.ietf.org Mon Dec 9 15:03:11 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28578 for ; Mon, 9 Dec 2002 15:03:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LU9o-0002Y0-00 for multi6-data@psg.com; Mon, 09 Dec 2002 12:05:36 -0800 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #2) id 18LU9l-0002Xm-00 for multi6@ops.ietf.org; Mon, 09 Dec 2002 12:05:33 -0800 Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Mon, 09 Dec 2002 12:05:34 -0800 Reply-To: From: "Tony Hain" To: "'Tony Li'" , "'Eliot Lear'" Cc: "'Joel M. Halpern'" , Subject: RE: network controls are necessary Date: Mon, 9 Dec 2002 12:05:23 -0800 Message-ID: <057201c29fbe$4f491f30$237ba8c0@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA28578 Tony Li wrote: > ... > Not to oppose that, but I think that Craig has been a fine > representative. More > are certainly welcome. Again, not to fault Craig or his participation, but he brings a multi-homed site network perspective. If his host admin counterpart were also participating, we might get a slightly different view about the complexity trade-off's. What I would really like to see is at least one host admin from someplace with 1/4M end systems, or diverse system types and manageability requirements like a Boeing, GE, or Sony. Tony From owner-multi6@ops.ietf.org Mon Dec 9 15:29:26 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29738 for ; Mon, 9 Dec 2002 15:29:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LUZ3-0004lC-00 for multi6-data@psg.com; Mon, 09 Dec 2002 12:31:41 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 18LUZ0-0004ks-00 for multi6@ops.ietf.org; Mon, 09 Dec 2002 12:31:39 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gB9KUek03067; Mon, 9 Dec 2002 21:30:40 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Mon, 9 Dec 2002 21:30:40 +0100 (CET) From: Iljitsch van Beijnum To: Tony Hain cc: Subject: RE: network controls are necessary In-Reply-To: <057201c29fbe$4f491f30$237ba8c0@eagleswings> Message-ID: <20021209212404.I552-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 9 Dec 2002, Tony Hain wrote: > What I would really like to see is at least one host admin from > someplace with 1/4M end systems, or diverse system types and > manageability requirements like a Boeing, GE, or Sony. While I wouldn't go so far as to say that we shouldn't listen to this input if it were offered, I don't think this is the right approach. If we give every network with 250k end systems 10 globally visible prefixes we'll still have a smaller v6 table than what we have in v4 now. The sites that now can't even multihome in IPv4 because they don't qualify for a /24 are the ones that are going to kill us in IPv6. Iljitsch From owner-multi6@ops.ietf.org Mon Dec 9 15:46:16 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00894 for ; Mon, 9 Dec 2002 15:46:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LUpd-0006Vv-00 for multi6-data@psg.com; Mon, 09 Dec 2002 12:48:49 -0800 Received: from mailman.cisco.com ([171.70.144.186]) by psg.com with esmtp (Exim 3.36 #2) id 18LUpb-0006QL-00 for multi6@ops.ietf.org; Mon, 09 Dec 2002 12:48:47 -0800 Received: from [64.100.160.211] by 171.70.144.186 (mailman.cisco.com) with ESMTP; 09 Dec 2002 04:49:55 +0000 Message-ID: <3DF5018F.7090505@cisco.com> Date: Mon, 09 Dec 2002 12:48:15 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021118 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: Tony Hain , multi6@ops.ietf.org Subject: Re: network controls are necessary References: <20021209212404.I552-100000@sequoia.muada.com> In-Reply-To: <20021209212404.I552-100000@sequoia.muada.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I can enumerate the entities that have as many as 250,000 end devices. This tells me that they are the wrong target community. Especially since even if we gave them 1000 prefixes each it wouldn't make a dent in the routing system. Eliot From owner-multi6@ops.ietf.org Mon Dec 9 16:34:45 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03231 for ; Mon, 9 Dec 2002 16:34:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LVZm-000Ak9-00 for multi6-data@psg.com; Mon, 09 Dec 2002 13:36:30 -0800 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #2) id 18LVZG-000AeP-00 for multi6@ops.ietf.org; Mon, 09 Dec 2002 13:35:58 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 1DDAC354B7; Mon, 9 Dec 2002 13:45:22 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id gB9LZRiI009643; Mon, 9 Dec 2002 13:35:27 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Next question... Date: Mon, 9 Dec 2002 13:35:26 -0800 Message-ID: Thread-Topic: Next question... Thread-Index: AcKfuGfqbTbWDTbDQ4O7Azq5frDBzgAARipw From: "Tony Li" To: "Eliot Lear" Cc: "Iljitsch van Beijnum" , X-Spam-Status: No, hits=1.1 required=5.0 tests=SPAM_PHRASE_03_05 version=2.43 X-Spam-Level: * Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA03231 | I DDOS attack the far end. The local end then sends an | authenticated | hint to the routing system. In fact, if I DDOS a popular | host, I can | get a lot of local ends to provide "hints" and thus | indirectly DDOS the | routing system. And then suppose the routing system | believes the hint. | Now I can stop my DDOS on the host and go hide. The hint is only going as far as your SBR, because that's the system that is responsible for locator selection for your outbound packets. This would only be a small DDOS against your own SBR. | OTOH, if a host wants to provide either quality or reachability | information about itself, I'm okay with that so long as it's | authenticated and we can find a way to sanely aggregate the | information. In its full generality, this will be hard. It's difficult to create an abstraction from random, unrelated items. Tony From owner-multi6@ops.ietf.org Mon Dec 9 17:04:57 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04838 for ; Mon, 9 Dec 2002 17:04:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LVj0-000Bgz-00 for multi6-data@psg.com; Mon, 09 Dec 2002 13:46:02 -0800 Received: from dmz1.procket.com ([65.174.124.36]) by psg.com with esmtp (Exim 3.36 #2) id 18LViy-000BbN-00 for multi6@ops.ietf.org; Mon, 09 Dec 2002 13:46:00 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 43AC323C3F; Mon, 9 Dec 2002 13:44:37 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id gB9LjPiI010206; Mon, 9 Dec 2002 13:45:25 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: network controls are necessary Date: Mon, 9 Dec 2002 13:45:22 -0800 Message-ID: Thread-Topic: network controls are necessary Thread-Index: AcKfubmmQjLJ7Zf4S4y19iKJV5nzGgAEhl8w From: "Tony Li" To: Cc: "Joel M. Halpern" , X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA04838 Bill, | > | Maybe a site could withdraw the identifier->locator | mapping when a | > | link is known to have lost connectivity, but that | clearly limits | > | what can be done to cache identifier-locator mappings.. | > | > Oy. I think the thought was that the routing system | would detect the | > loss of connectivity via the locator and would send an | ICMP unreachable, | > which would then trigger a switch to an alternate locator. | | I thought of that sort of mechanism but immediately | dismissed it; it's | got a track record of failing miserably in the as-built Internet[1]. | I'm skeptical that this would be effective without some sort of | black-hole detection (rotating to a new locator after a couple RTO's | of silence?). | | [1] Path MTU discovery. Try surfing the web with a <1500 MTU | bottleneck in the path some time. PPPoE implementations | which rewrite | TCP MSS options don't count. Path MTU is a case where the network needs to signal back to the host and the host needs to respond to the signal. Part of the reason that this isn't solid is that many host implementations don't respond correctly. The case that we're talking about is the reverse: the host detects the problem and then signals its SBR. Yes, this would require black hole detection on the part of the host. It would then signal to its SBR to force a locator change. I cannot think of a single mechanism today that would be analogous to this. Does that help? Tony From owner-multi6@ops.ietf.org Mon Dec 9 17:10:28 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05012 for ; Mon, 9 Dec 2002 17:10:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LW91-000EDD-00 for multi6-data@psg.com; Mon, 09 Dec 2002 14:12:55 -0800 Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by psg.com with esmtp (Exim 3.36 #2) id 18LW8v-000ECU-00 for multi6@ops.ietf.org; Mon, 09 Dec 2002 14:12:49 -0800 Received: from chuegen-sjcvpn-5.cisco.com (chuegen-sjcvpn-5.cisco.com [10.25.2.102]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gB9MBvjT028173; Mon, 9 Dec 2002 14:11:57 -0800 (PST) Date: Mon, 9 Dec 2002 16:12:17 -0600 (Central Standard Time) From: "Craig A. Huegen" To: Tony Li cc: sommerfeld@orchard.arlington.ma.us, "Joel M. Halpern" , Subject: RE: network controls are necessary In-Reply-To: Message-ID: X-X-Sender: chuegen@chuegen-sun.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.0 required=5.0 tests=EMAIL_ATTRIBUTION,GAPPY_TEXT,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 9 Dec 2002, Tony Li wrote: > Oy. I think the thought was that the routing system would detect the > loss of connectivity via the locator and would send an ICMP unreachable, > which would then trigger a switch to an alternate locator. I'm slightly concerned about the security/DoS implications of allowing unsolicited messages to vastly affect connectivity, even though some topologies support the use of ingress filtering and unicast-RPF to mitigate. I'm also concerned with the network device having to send back all those ICMP messages in response to active traffic in case of a major link failing. /cah --- Craig A. Huegen, Chief Network Architect C i s c o S y s t e m s IT Transport, Network Technology & Design || || Cisco Systems, Inc., 400 East Tasman Drive || || San Jose, CA 95134, (408) 526-8104 |||| |||| email: chuegen@cisco.com CCIE #2100 ..:||||||:..:||||||:.. From owner-multi6@ops.ietf.org Mon Dec 9 17:12:24 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05053 for ; Mon, 9 Dec 2002 17:12:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LW00-000DOg-00 for multi6-data@psg.com; Mon, 09 Dec 2002 14:03:36 -0800 Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by psg.com with esmtp (Exim 3.36 #2) id 18LVzw-000DNS-00 for multi6@ops.ietf.org; Mon, 09 Dec 2002 14:03:32 -0800 Received: from chuegen-sjcvpn-5.cisco.com (chuegen-sjcvpn-5.cisco.com [10.25.2.102]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gB9M2cjT021766; Mon, 9 Dec 2002 14:02:39 -0800 (PST) Date: Mon, 9 Dec 2002 16:02:58 -0600 (Central Standard Time) From: "Craig A. Huegen" To: Tony Hain cc: "'Tony Li'" , "'Eliot Lear'" , "'Joel M. Halpern'" , Subject: RE: network controls are necessary In-Reply-To: <053b01c29fac$eccb1a40$237ba8c0@eagleswings> Message-ID: X-X-Sender: chuegen@chuegen-sun.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.3 required=5.0 tests=EMAIL_ATTRIBUTION,GAPPY_TEXT,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 9 Dec 2002, Tony Hain wrote: > Simplifying does not always mean moving the function into the network. > In fact that approach may make the host job more complex, because the > network has limited knowledge. As long as you are considering how to take a network of 100,000 hosts in a distribution of 65% OS-A, 25% OS-B, 5% OS-C, and 5% OS-Other (comprised of about 35 different other OS's), push this policy to them within a day or so, and ensure that the policy will behave the same way across the 39 OS's, then I've got no problem with a fully-distributed host-based selection mechanism. The alternative, of course, is for the administrator to make perhaps a couple of policy changes in a central policy database that are then automatically utilized by those 100,000 hosts. Either way you want to approach it, it _will_ require standards, and better standards than the leftmost longest-bit-match that the address selection draft provides. Whether there be a finite set of policy capabilities a host MUST have, or whether there is a standard protocol that allows extensibility of the policy engine (a la DNS-like operation), we have to come up with it. (PS - No, those aren't real numbers of operating system distribution at any particular entity that still exists. It is, however, a representative distribution of a technology-oriented R&D operation that has no particular ties to anyone I'm currently affiliated with. I'm sure that some other larger organizations have a more standardized environment, and I'm sure some universities have a significantly more complex environment.) > administrators of end sites that are currently multi-homed. The real > trick is finding the people from that set who are willing to put time > into the IETF, and who have some understanding of the range of options The trick is finding those exact people who have the capability to give their time. I'm so busy that I can maybe get to the discussions here once every two weeks if I'm lucky. > Yes we have to choose. My concern is that the vocal participants are not > providing a balanced perspective on the cost / benefit tradeoffs. Again, > this is not to fault anyone, just raise awareness that we need more > participation from multi-homed host administrators. Network administrators generally have a good view of host administration already, at least enough to know what manpower it would take to communicate changes, modify standard images, offer alternatives for the non-conformists, make the change, and support the change. We all make design decisions to change various aspects of our networks and we must know what impact that causes to the host administrators, whether it can be scripted or not, and the end result effort. I agree we need more of these people. /cah --- Craig A. Huegen, Chief Network Architect C i s c o S y s t e m s IT Transport, Network Technology & Design || || Cisco Systems, Inc., 400 East Tasman Drive || || San Jose, CA 95134, (408) 526-8104 |||| |||| email: chuegen@cisco.com CCIE #2100 ..:||||||:..:||||||:.. From owner-multi6@ops.ietf.org Mon Dec 9 17:13:47 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05160 for ; Mon, 9 Dec 2002 17:13:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LWBu-000Ebe-00 for multi6-data@psg.com; Mon, 09 Dec 2002 14:15:54 -0800 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #2) id 18LWBq-000EbI-00 for multi6@ops.ietf.org; Mon, 09 Dec 2002 14:15:50 -0800 Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Mon, 09 Dec 2002 14:15:49 -0800 Reply-To: From: "Tony Hain" To: Subject: RE: Next question... Date: Mon, 9 Dec 2002 14:15:38 -0800 Message-ID: <05b401c29fd0$82655c50$237ba8c0@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal X-Spam-Status: No, hits=-1.1 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA05160 Tony Li wrote: > ... > AFAIK, no host has the wherewithal to make the intelligent > routing decisions that you're proposing. Which connections are you > thinking of? I am not suggesting that the host make a routing decision ... The only thing the host has knowledge of are the locators. Yes those are the objects the routing system keys on, but the host is doing nothing more than selecting the endpoints. The routing system actually does the path selection job, and the host should have no direct role in that, because they don't have sufficient information to do so. If the goal is service optimization and the origin end system decides that the selected path is not acceptable for the application, it may wish to have alternatives explored. It could request that the routing system just do that, but then it would have to explain what characteristics it was looking for (RSVP), and the routing system would have to have a mechanism to measure the possible paths (???). The alternative is that the origin end system walk through the lists of locators to see if any result in acceptable service. It is not doing path selection per se, but leveraging the fact that the routing system will key off the locators to do that. This approach leaves knowledge of the desired characteristics and measurement located close to the application, and distributes in a way that scales much better than an SBR. OTOH, if the goal is policy enforcement through locator selection, the SBR may provide a more scaleable approach because it limits the number of places that have to understand the policy. This could also be done by having the network inform the end systems about the policy, but concerns are raised about crossing an artificial trust boundary. If the focus is on the term 'enforcement', crossing trust boundaries is a big deal and perceived costs will always outweigh potential benefits. If the focus is on scalable application of a policy, moving the process to the edge is a more reasonable engineering approach. As I said earlier, hosts already do the locator selection today. The routing system seems to be intact (as much as it is capable of anyway), so moving this function to the routing system is not an engineering decision based on scale, it is one based on perceived need for control. It is my understanding that the need for control stems from TE requirements where egress policy wants to enforce the destination locator, and ingress policy wants to enforce the source locator. While rewriting the locators at the SBR may allow a site network admin to achieve fine-grained TE, the approach requires rebuilding the hosts and applications to live with arbitrary external changes. The lack of coordination between the sites also means it is not possible to arbitrarily meet the ingress & egress policies of both sides. Given all that, what problem are we trying to solve? If it is to support failover, encapsulation techniques work, and translation would work when the applications were unaware. If it is TE load distribution, we need a negotiation protocol between the sites to figure out the mutually acceptable set of locators from the options (else we end up violating policy on one end). If it is performance or differing service types, we need a mechanism for the application to declare / identify the acceptable levels of service. If it is for AUP, we need to know if the granularity is per host, per application, or per user, or combinations thereof. (Per host or per unencrypted application is possible in the SBR, but per encrypted application, per user, or combinations would require the host to be part of the solution space.) If it is all of the above (as per the multi-6 requirements draft), we need a mechanism that can identify and track the acceptable level of service for each application, adheres to the AUP (most commonly per user & app simultaneously), meets the TE policies of both ends (while still allowing any transit providers complete control), and fails over gracefully with no more disruption to the app than the lost packets. If it is petty bickering about control between the host or routing system administrators, we can't define a standard that will satisfy both so we will end up choosing the winner/looser. Once we sort through that list, we need to figure out where to apply it. From my experience, the first two probably scale more cost effectively in the SBR (though translation approaches would require changes in all hosts and applications), while the second two scale more cost effectively in the hosts, and the last two are hopeless. This leaves us without a clear path, so the tendency is to gravitate to the one the participants are most familiar with; doing it in the routing system. My point is that by focusing on the SBR approach, we are starting from the point of application, without really agreeing on the problem space. While people use different aspects of the requirements list in different situations, they can't all be used simultaneously (take the simple case of path selection by both ends and the middle). Maybe rather than stating the list as requirements, claim they are capabilities that are used in the current IPv4 environment. Then require all architectural approaches to address how well they address each of those capabilities, and comment on the scaling trade-off's or protocol additions that would be required to implement that architecture. Tony From owner-multi6@ops.ietf.org Mon Dec 9 17:17:07 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05299 for ; Mon, 9 Dec 2002 17:17:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LWFh-000EzL-00 for multi6-data@psg.com; Mon, 09 Dec 2002 14:19:49 -0800 Received: from mailman.cisco.com ([171.70.144.186]) by psg.com with esmtp (Exim 3.36 #2) id 18LWFf-000EyO-00 for multi6@ops.ietf.org; Mon, 09 Dec 2002 14:19:47 -0800 Received: from [64.100.160.211] by 171.70.144.186 (mailman.cisco.com) with ESMTP; 09 Dec 2002 06:20:58 +0000 Message-ID: <3DF516E5.7080605@cisco.com> Date: Mon, 09 Dec 2002 14:19:17 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021118 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tony Li CC: Iljitsch van Beijnum , multi6@ops.ietf.org Subject: Re: Next question... References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_03_05, USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tony Li wrote: > The hint is only going as far as your SBR, because that's the system > that is responsible for locator selection for your outbound packets. > This would only be a small DDOS against your own SBR. No, it's against YOUR SBR (and everyone else's) because I've DDOSed the remote host, perhaps intermittantly, and YOU have authoritatively reported to your SBR a connectivity problem because of my attack. Eliot From owner-multi6@ops.ietf.org Mon Dec 9 17:35:57 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05989 for ; Mon, 9 Dec 2002 17:35:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LWWz-000Gdo-00 for multi6-data@psg.com; Mon, 09 Dec 2002 14:37:41 -0800 Received: from portal.hamachi.org ([140.239.227.17]) by psg.com with esmtp (Exim 3.36 #2) id 18LWWx-000Gdb-00 for multi6@ops.ietf.org; Mon, 09 Dec 2002 14:37:39 -0800 Received: from syn.hamachi.org (localhost [127.0.0.1]) by portal.hamachi.org (Postfix) with ESMTP id 5886617926; Mon, 9 Dec 2002 17:33:22 -0500 (EST) Received: from syn.hamachi.org (sommerfeld@localhost) by syn.hamachi.org (8.11.6/8.8.8) with ESMTP id gB9MYcC23855; Mon, 9 Dec 2002 17:34:38 -0500 (EST) Message-Id: <200212092234.gB9MYcC23855@syn.hamachi.org> From: Bill Sommerfeld To: "Tony Li" Cc: sommerfeld@orchard.arlington.ma.us, "Joel M. Halpern" , multi6@ops.ietf.org Subject: Re: network controls are necessary In-Reply-To: Message from "Tony Li" of "Mon, 09 Dec 2002 13:45:22 PST." Reply-To: sommerfeld@orchard.arlington.ma.us Date: Mon, 09 Dec 2002 17:34:35 -0500 X-Spam-Status: No, hits=0.1 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_3,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk > Path MTU is a case where the network needs to signal back to the > host and the host needs to respond to the signal. Part of the > reason that this isn't solid is that many host implementations don't > respond correctly. more commonly, it's a misconfigured firewall, but NATs and similar devices (load balancers) also can get it wrong. - Bill From owner-multi6@ops.ietf.org Mon Dec 9 17:43:27 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06271 for ; Mon, 9 Dec 2002 17:43:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LWf8-000HX3-00 for multi6-data@psg.com; Mon, 09 Dec 2002 14:46:06 -0800 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #2) id 18LWf5-000HWe-00 for multi6@ops.ietf.org; Mon, 09 Dec 2002 14:46:03 -0800 Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Mon, 09 Dec 2002 14:46:05 -0800 Reply-To: From: "Tony Hain" To: "'Eliot Lear'" , "'Iljitsch van Beijnum'" Cc: Subject: RE: network controls are necessary Date: Mon, 9 Dec 2002 14:45:54 -0800 Message-ID: <05bb01c29fd4$bbaa2b90$237ba8c0@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <3DF5018F.7090505@cisco.com> Importance: Normal X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Eliot Lear wrote: > I can enumerate the entities that have as many as 250,000 end > devices. > This tells me that they are the wrong target community. Especially > since even if we gave them 1000 prefixes each it wouldn't > make a dent in > the routing system. The point was not to get their perspective on impact to the routing system (we already have enough of that). Rather it was to get their perspective on realistic scaling properties of host distribution and conformance to a policy. We are making cost / benefit trade-off's here, yet there seems to be a FUD campaign to keep one key set of input off the table. Tony From owner-multi6@ops.ietf.org Mon Dec 9 18:02:43 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07116 for ; Mon, 9 Dec 2002 18:02:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LWxi-000Jbl-00 for multi6-data@psg.com; Mon, 09 Dec 2002 15:05:18 -0800 Received: from mailman.cisco.com ([171.70.144.186] helo=mace-in.cisco.com) by psg.com with esmtp (Exim 3.36 #2) id 18LWxg-000JS2-00 for multi6@ops.ietf.org; Mon, 09 Dec 2002 15:05:16 -0800 Received: from [64.100.160.211] by 171.70.144.186 (mace-in.cisco.com) with ESMTP; 09 Dec 2002 07:06:28 +0000 Message-ID: <3DF5218C.60902@cisco.com> Date: Mon, 09 Dec 2002 15:04:44 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021118 X-Accept-Language: en-us, en MIME-Version: 1.0 To: alh-ietf@tndh.net CC: "'Iljitsch van Beijnum'" , multi6@ops.ietf.org Subject: Re: network controls are necessary References: <05bb01c29fd4$bbaa2b90$237ba8c0@eagleswings> In-Reply-To: <05bb01c29fd4$bbaa2b90$237ba8c0@eagleswings> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Yes, but perhaps we could expand our focus to include smaller companies, such as the Dow 30 components? Eliot From owner-multi6@ops.ietf.org Mon Dec 9 18:14:09 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07561 for ; Mon, 9 Dec 2002 18:14:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LX8l-000KjT-00 for multi6-data@psg.com; Mon, 09 Dec 2002 15:16:43 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 18LX8i-000Kj5-00 for multi6@ops.ietf.org; Mon, 09 Dec 2002 15:16:40 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gB9NFhk03326; Tue, 10 Dec 2002 00:15:43 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Tue, 10 Dec 2002 00:15:43 +0100 (CET) From: Iljitsch van Beijnum To: Tony Hain cc: Subject: RE: network controls are necessary In-Reply-To: <05bb01c29fd4$bbaa2b90$237ba8c0@eagleswings> Message-ID: <20021210000113.I552-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 9 Dec 2002, Tony Hain wrote: > > This tells me that they are the wrong target community. Especially > > since even if we gave them 1000 prefixes each it wouldn't > > make a dent in the routing system. > The point was not to get their perspective on impact to the routing > system (we already have enough of that). Rather it was to get their > perspective on realistic scaling properties of host distribution and > conformance to a policy. We are making cost / benefit trade-off's here, > yet there seems to be a FUD campaign to keep one key set of input off > the table. Such large networks can simply use current multihoming mechanisms along with current traffic engineering and policy expression mechanisms. If we can create something that works for a 100 host network but not for anything larger than 1000 hosts because it becomes too complex to manage, I think that would meet the goals set for this wg. 250k host networks are always going to be extremely complex to manage no matter what you do. Iljitsch From owner-multi6@ops.ietf.org Mon Dec 9 18:20:15 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07731 for ; Mon, 9 Dec 2002 18:20:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LXEl-000LTC-00 for multi6-data@psg.com; Mon, 09 Dec 2002 15:22:55 -0800 Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by psg.com with esmtp (Exim 3.36 #2) id 18LXEh-000LNK-00 for multi6@ops.ietf.org; Mon, 09 Dec 2002 15:22:52 -0800 Received: from chuegen-sjcvpn-5.cisco.com (chuegen-sjcvpn-5.cisco.com [10.25.2.102]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gB9NLxjT015299; Mon, 9 Dec 2002 15:22:00 -0800 (PST) Date: Mon, 9 Dec 2002 17:22:19 -0600 (Central Standard Time) From: "Craig A. Huegen" To: Tony Hain cc: multi6@ops.ietf.org Subject: RE: Next question... In-Reply-To: <05b401c29fd0$82655c50$237ba8c0@eagleswings> Message-ID: X-X-Sender: chuegen@chuegen-sun.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.0 required=5.0 tests=EMAIL_ATTRIBUTION,GAPPY_TEXT,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Tony, On Mon, 9 Dec 2002, Tony Hain wrote: > As I said earlier, hosts already do the locator selection today. The > routing system seems to be intact (as much as it is capable of anyway), > so moving this function to the routing system is not an engineering Depending upon what your belief is of the current best common practice for multi-homing, one could argue hosts in IPv4 actually do the identifier selection and the routers select the path which is analagous to the concept of a locator. This is in the case of PI space -- we take this approach with the multi-homing of Cisco's network, to the extent that www.cisco.com has a single A record and the routing system has the true "locators" (in the form of BGP paths). > If it is petty bickering about control between the host or routing > system administrators, we can't define a standard that will satisfy both > so we will end up choosing the winner/looser. It is certainly not this. I would love to be able to hand a policy specification to my counterparts in our desktop standards group and have them figure out how to apply this, in communication, coordination, etc. Less work for my team. But I recognize (as detailed in a previous e-mail) that the time and effort required to manage the configurations on a significant number of hosts and various permutations of host capabilities/extensions is far greater than an extensible policy infrastructure that allows me as the administrator to change policy and immediately have it applied across the entire infrastructure. I can enhance the policy engine on less than 30 devices globally as opposed to coordinating features from a number of vendors for a number of operating systems for 100,000 hosts. /cah --- Craig A. Huegen, Chief Network Architect C i s c o S y s t e m s IT Transport, Network Technology & Design || || Cisco Systems, Inc., 400 East Tasman Drive || || San Jose, CA 95134, (408) 526-8104 |||| |||| email: chuegen@cisco.com CCIE #2100 ..:||||||:..:||||||:.. From owner-multi6@ops.ietf.org Mon Dec 9 18:29:46 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08017 for ; Mon, 9 Dec 2002 18:29:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LXNs-000MR0-00 for multi6-data@psg.com; Mon, 09 Dec 2002 15:32:20 -0800 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.36 #2) id 18LXNo-000MQN-00 for multi6@ops.ietf.org; Mon, 09 Dec 2002 15:32:17 -0800 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id KAA00106 for ; Tue, 10 Dec 2002 10:32:14 +1100 (EST) Date: Tue, 10 Dec 2002 10:32:14 +1100 (EST) From: Peter Tattam To: Multi6 Working Group Subject: host based MH with a connectivity cache Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.2 required=5.0 tests=SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Here are the latest thoughts I've had with the MH stuff... This is a kind of hybrid host based and BGP MH solution. Some preamble... a) One of the problems I can see is that any MH solution that relies on the originating sites view of connectivity is likely to fail. The reason for this is that the path and ultimate connectivity between two sites is going to be dependendent on where they are located in relation to each other. i.e. If a site is multihomed, the MH address to use as a source address is going to vary depending who it's maintaining a connection to. This would preclude any static advertising of MH addresses by the site (e.g. DNS or other kinds of mapping) without an additional connectivity protocol to find the best path. b) Another issue is the DFZ debate. Since we have applied a rule to the DFZ that say no advertising of longer prefixes, we have effectively placed a barrier for MH information to transit across the internet. We should not forget that the full MH information is *still* in the BGP system, it's just not visible between BGP zones. Since the information is still there, it would be a waste not to use it on some way. Now some of this is hand waving - apologies if some of it won't fly. My idea contains two parts... first... the host based MH part (yeah I can't let go of my idea :) 1. Use a host based MH solution as I've previously discussed. Apply it to the entire IP layer, not just TCP, and use the techniques for address handover as recently discussed. 2. MH should be restricted to prefixes only. MH addresses with different prefixes, but the same host part are the same address, however equivalent addresses must still be checked. 3. Deploy a site based Connectivity Cache System (CCS) that links directly into the BGP system, and runs parallel to this system. It would operate on a similar basis to DNS in that the entire BGP is not required, but just the parts that the site is interested in reaching from it's perspective. My guess is it would scale in roughly the same way as DNS would. Such a connectivty cache should take advantage of the hiearchical nature of the MH system to provide hints that branches of the BGP tree had come & gone. It would by nature be a more dynamic structure than the DNS currently is, and care should be taken to manage the security aspects. Typically a site would maintain 1 or 2 of these caches in a similar way to DNS, and also a large site could maintain a centralized cache for the use of smaller sites within it's control. It must also be able to determine whether a path exists between two MH addresses and for the reasons of load balancing determine some level of fine grained path characteristics, possibly supplemented by policy controls. The ultimate purpose of such a cache is to restore the MH information to end points that the strongly aggregated DFZ has thrown away. It is important to remember that much of the BGP information is already available in the BGP system that is currently deployed. 4. A site would advertise it's MH prefixes into this system and the prefixes are bound together by MH identifier. This is very close to BGP as we know it, but the important part is that the MH binding identifier should be visible to the site's hosts and would be used to query the connectivity cache. 5. This is optional - the MH identifier can be used to construct a PI MH prefix which would be advertised into the DNS system and used much in the way that an IPv4 prefix is. I will refer to this prefix/address as being the FORMAL prefix/address and the MH prefixes/addresses used for transport as the ACTUAL prefixes/addresses. A host need only ever be aware of the address formed from this prefix in the application layer and can be used for the usual reasons where a host identifier is required. When the address gets used, it is up to either the host to maintain actual address pairs, or the site border routers to translate the formal address into the actual address(es). I would propose that a section of the IPv6 address be allocated as a PI address space for the specific purpose of multi homing. Any site that is multi homed must have a PI address prefix. The name space by it's nature would be a flat address space and could be constructed by concatenating a reserved MH prefix with the existing IPv4 ASN. It would never be legal for such an address to be used for transport outside a host/site, but must always be translated into actual addresses once packets leave the host/site. 5(b). If 5 is not acceptable, it is still possible for the connectivity cache to be queried for a particular address to return all the actual MH prefixes associated with that prefix and the reachability to each address. 6. if host based MH is to be used, it relies on the connectivity cache to get up to date MH information and would interact roughly in the same manner as DNS, but would require additional information if connectivity were lost for a particular host. The level of authntication for host based based MH would be equivalent to ND and so could take advantage of the hop count to maintain a reasonable level of integrity. 7. If a site based MH solution is deployed through address translation, by virtue of (2), the amount of stateful information to be kept will be kept to a minimum (one state per source-dest site path). However because of preamble (a) I don't think it will be possible to completely remove states. A major concern is that this translation will need to be done at borders on expensive routers and this has the potential not to scale. The ideal answer is to never translate packets once they leave a host which means the hosts must manage the prefix modification. Of these points, 1,2 and 5 are fairly well understood. 3,4 & 6 are the hard part - scalability needs to be evaluated. 7 may not scale. Point 5 is controversial also. These are my thoughts - they are a bit unpolished and may indeed be things previously proposed. Apologies if I have just rehashed something that's been done. The key components of this idea are... use of a BGP style cache that doesn't requre the full BGP tree to be shuffled around and frees core routers to do routing only. The other key idea is the use of a formal PI MH address which are then translated into actual MH addresses which operate without intervention by routers. Regards Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 From owner-multi6@ops.ietf.org Mon Dec 9 18:46:23 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08502 for ; Mon, 9 Dec 2002 18:46:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LXdb-000O5j-00 for multi6-data@psg.com; Mon, 09 Dec 2002 15:48:35 -0800 Received: from gnat.inet.org ([63.108.254.91]) by psg.com with esmtp (Exim 3.36 #2) id 18LXdY-000O5U-00 for multi6@ops.ietf.org; Mon, 09 Dec 2002 15:48:33 -0800 Received: from extremenetworks.com (unknown [10.0.8.115]) by gnat.inet.org (Postfix) with ESMTP id 0FA1667116; Mon, 9 Dec 2002 15:14:40 -0500 (EST) Date: Mon, 9 Dec 2002 18:47:55 -0500 Subject: Re: network controls are necessary Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: multi6@ops.ietf.org To: sommerfeld@orchard.arlington.ma.us From: RJ Atkinson In-Reply-To: <200212092234.gB9MYcC23855@syn.hamachi.org> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) X-Spam-Status: No, hits=-1.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI, SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Monday, Dec 9, 2002, at 17:34 America/Montreal, Bill Sommerfeld wrote: >> Path MTU is a case where the network needs to signal back to the >> host and the host needs to respond to the signal. Part of the >> reason that this isn't solid is that many host implementations don't >> respond correctly. > > more commonly, it's a misconfigured firewall, but NATs and similar > devices (load balancers) also can get it wrong. I don't have significant problems using PMTU these days, perhaps I'm just lucky. I did have problems in earlier days when PMTU was first implemented, but the early problems seem to have been early implementation anomalies. Ran From owner-multi6@ops.ietf.org Mon Dec 9 18:50:10 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08600 for ; Mon, 9 Dec 2002 18:50:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LXhh-000ObI-00 for multi6-data@psg.com; Mon, 09 Dec 2002 15:52:49 -0800 Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by psg.com with esmtp (Exim 3.36 #2) id 18LXhe-000OVh-00 for multi6@ops.ietf.org; Mon, 09 Dec 2002 15:52:47 -0800 Received: from chuegen-sjcvpn-5.cisco.com (chuegen-sjcvpn-5.cisco.com [10.25.2.102]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gB9NprjT003941; Mon, 9 Dec 2002 15:51:54 -0800 (PST) Date: Mon, 9 Dec 2002 17:52:13 -0600 (Central Standard Time) From: "Craig A. Huegen" To: Tony Hain cc: "'Tony Li'" , "'Randy Bush'" , Subject: RE: Next question... In-Reply-To: <045e01c29d7d$388469f0$237ba8c0@eagleswings> Message-ID: X-X-Sender: chuegen@chuegen-sun.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.3 required=5.0 tests=EMAIL_ATTRIBUTION,GAPPY_TEXT,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 6 Dec 2002, Tony Hain wrote: > I absolutely disagree. Hosts actually make those policy decisions today, > and the system works. The machine I am typing this on has 4 IPv4 > addresses, yet it has no trouble opening a connection to CNN.com by > picking from that list of possible sources, and the 8 available IPv4 > destination addresses. There seems to be a fear that providing more > choices to the host will magically make the world more complex. Start tracing to all those addresses you get with www.cnn.com. That is *not* multihoming, that's local infrastructure resiliency via DNS load-balancing. Those prefixes are all located within Atlanta. Take a look in BGP route tables and see that the real path selection happens in the routing infrastructure via BGP paths. The fact that your host randomly picked a destination address from DNS and used the outbound interface's primary IP address for a new connection isn't true multihoming. Now, take a scenario: Your host has source addresses from aaaa::/16, bbbb::/16, cccc::/16, and dddd::/16. Destination host has source addresses from aaab::/16 and dddf::/16. You pay $100k per megabyte from the provider allocated aaa0::/12, and $2 per megabyte from the other three. You also need every host in your organization to be able to use the aaa0::/12 provider to reach a very critical service with address aaaf::/16, which you're willing to pay the $100k per megabyte for. This critical service also has connectivity via providers B and D in bbbe::/16 and ddde::/16, but with sub-par connectivity and you want to avoid that. Using address selection or even RA ordering, you cannot specify this policy. But these types of policies are perfectly realistic today in the IPv4 world. In order to emulate this policy, I would have to specify a policy which forced a destination address change through NAT in order to accomplish my objective. IMO, an absolute requirement here is that we have a policy capability that's far greater than longest bit match or preferred order for RA prefixes. Policy in path selection for multihomed enterprises, at a minimum, needs to be able to prefer or avoid certain intersections of source and destination addresses for a given destination *host* (not address!) that would normally be avoided or preferred. A nice-to-have is a policy engine that is also aware of AS-path data so that policies can be programmed for AS preference when it involves more than one AS between two communicating organizations. > The only thing that doesn't happen when the host selects the locator is > that the network administrator doesn't get to enforce fine-grained TE > for the return traffic. If this is what we are defining as 'unnecessary > complications', I have to question the necessity of changing the entire > infrastructure so that it will support the arbitrary replacement of > locators without affecting applications. That sounds a lot more complex > to me than simply adding one more policy to the set of things the host > administrators have to do already. Take a look at the scenario above. These are examples of the types of policy that enterprises need. /cah --- Craig A. Huegen, Chief Network Architect C i s c o S y s t e m s IT Transport, Network Technology & Design || || Cisco Systems, Inc., 400 East Tasman Drive || || San Jose, CA 95134, (408) 526-8104 |||| |||| email: chuegen@cisco.com CCIE #2100 ..:||||||:..:||||||:.. From owner-multi6@ops.ietf.org Mon Dec 9 19:01:55 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09129 for ; Mon, 9 Dec 2002 19:01:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LXsw-000PjP-00 for multi6-data@psg.com; Mon, 09 Dec 2002 16:04:26 -0800 Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by psg.com with esmtp (Exim 3.36 #2) id 18LXsq-000Phz-00 for multi6@ops.ietf.org; Mon, 09 Dec 2002 16:04:20 -0800 Received: from chuegen-sjcvpn-5.cisco.com (chuegen-sjcvpn-5.cisco.com [10.25.2.102]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gBA03QjT011120; Mon, 9 Dec 2002 16:03:26 -0800 (PST) Date: Mon, 9 Dec 2002 18:03:46 -0600 (Central Standard Time) From: "Craig A. Huegen" To: "J. Noel Chiappa" cc: multi6@ops.ietf.org Subject: RE: Next question... In-Reply-To: <200212070717.CAA23449@ginger.lcs.mit.edu> Message-ID: X-X-Sender: chuegen@chuegen-sun.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.0 required=5.0 tests=EMAIL_ATTRIBUTION,GAPPY_TEXT,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sat, 7 Dec 2002, J. Noel Chiappa wrote: > As for the difficulty of having hosts do it too, may I point out that the > average human being seems to be able to deal with getting in a car on one side > of a continent (well, maybe only in North America and Western Europe where the > road systems are good) and figuring out a path to a destination on the other > side. It doesn't take a PhD. Similarly, network routing *shouldn't* need a > PhD. It does only because of the aforementioned canine refuseness. This is a simple analogy but doesn't hold water when you look into more detail. At risk of making people groan by extending it: The owner of a fleet of cars may want his drivers to avoid using Saddle Rd. because he isn't covered by his insurance there, or he may want his drivers to use less toll roads because he can't afford the $100 tolls for taking the shorter roads. Or, the fleet owner might want to force the drivers to use I-3 because it has pretty flowers along the side and it boosts morale. Whatever the reasons, the drivers don't get to make those decisions -- the fleet owner does. The fleet owner has to inform the drivers where they're permitted to operate the vehicle and where they are not -- that is policy. Under unusual circumstances, the drivers may be given flexibility to take a path to get his job done. A good fall-back mechanism takes care of this. Enterprise network operators also build and express policy based on the business parameters surrounding the connectivity, whether latency, cost, or personal preference. /cah --- Craig A. Huegen, Chief Network Architect C i s c o S y s t e m s IT Transport, Network Technology & Design || || Cisco Systems, Inc., 400 East Tasman Drive || || San Jose, CA 95134, (408) 526-8104 |||| |||| email: chuegen@cisco.com CCIE #2100 ..:||||||:..:||||||:.. From owner-multi6@ops.ietf.org Mon Dec 9 21:13:06 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13478 for ; Mon, 9 Dec 2002 21:13:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LZuo-000C0v-00 for multi6-data@psg.com; Mon, 09 Dec 2002 18:14:30 -0800 Received: from evrtwa1-ar8-4-65-020-139.evrtwa1.dsl-verizon.net ([4.65.20.139] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #2) id 18LZul-000C0f-00 for multi6@ops.ietf.org; Mon, 09 Dec 2002 18:14:27 -0800 Received: from eagleswings (127.0.0.1) by localhost with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Mon, 09 Dec 2002 18:14:28 -0800 Reply-To: From: "Tony Hain" To: "'Craig A. Huegen'" Cc: "'Tony Li'" , "'Randy Bush'" , Subject: RE: Next question... Date: Mon, 9 Dec 2002 18:14:17 -0800 Message-ID: <05e801c29ff1$d8225aa0$237ba8c0@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal X-Spam-Status: No, hits=-1.1 required=5.0 tests=GAPPY_TEXT,IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA13478 Craig A. Huegen wrote: > Start tracing to all those addresses you get with > www.cnn.com. That is > *not* multihoming, that's local infrastructure resiliency via > DNS load-balancing. Those prefixes are all located within > Atlanta. Take a look in BGP route tables and see that the > real path selection happens in the routing infrastructure via > BGP paths. > > The fact that your host randomly picked a destination address > from DNS and used the outbound interface's primary IP address > for a new connection isn't true multihoming. All the host is capable of doing is selecting source and destination locators. What is so hard to understand about; the routing system does path selection, because the host doesn't know anything more than locators. There is no difference between the host selecting the source locator based on an RA ordering or doing that based on a defined primary. Those are functionally the same capability. This leaves the question of selecting destination locator, which could be random, or based on some deterministic process. Either way the host is the one selecting the locator. The fact that it is local load balancing vs. multi-homing is only known in the routing system. > > Now, take a scenario: Your host has source addresses from > aaaa::/16, bbbb::/16, cccc::/16, and dddd::/16. Destination > host has source addresses from aaab::/16 and dddf::/16. You > pay $100k per megabyte from the provider allocated aaa0::/12, > and $2 per megabyte from the other three. You also need > every host in your organization to be able to use the > aaa0::/12 provider to reach a very critical service with > address aaaf::/16, which you're willing to pay the $100k per > megabyte for. This critical service also has connectivity > via providers B and D in bbbe::/16 and ddde::/16, but with > sub-par connectivity and you want to avoid that. > > Using address selection or even RA ordering, you cannot > specify this policy. But these types of policies are > perfectly realistic today in the IPv4 world. > > In order to emulate this policy, I would have to specify a > policy which forced a destination address change through NAT > in order to accomplish my objective. So show how that would be done without nat in IPv4. I presume this will start by limiting the source address list to 1 choice, but there is no clear way to avoid the bbbe & ddde services if that is what DNS returns to the host. Yes it is easy to route the outbound to the preferred provider despite the destination locator, but that is also true for IPv6. The real rub comes on the return path. If the connection is opened to the wrong address, the return traffic will not take the preferred ingress path. Even if it is, there is no guarantee that the cost structure at the remote site will match, so the traffic might end up on the least preferred path anyway. > > IMO, an absolute requirement here is that we have a policy > capability that's far greater than longest bit match or > preferred order for RA prefixes. Policy in path selection > for multihomed enterprises, at a minimum, needs to be able to > prefer or avoid certain intersections of source and > destination addresses for a given destination *host* (not > address!) that would normally be avoided or preferred. Path selection is a routing function. To implement the policy outlined above you would have to intercept and possibly rewrite all dns messages as well. Tony > A > nice-to-have is a policy engine that is also aware of AS-path > data so that policies can be programmed for AS preference > when it involves more than one AS between two communicating > organizations. > > > The only thing that doesn't happen when the host selects > the locator > > is that the network administrator doesn't get to enforce > fine-grained > > TE for the return traffic. If this is what we are defining as > > 'unnecessary complications', I have to question the necessity of > > changing the entire infrastructure so that it will support the > > arbitrary replacement of locators without affecting > applications. That > > sounds a lot more complex to me than simply adding one more > policy to > > the set of things the host administrators have to do already. > > Take a look at the scenario above. These are examples of the > types of policy that enterprises need. > > /cah > > --- > Craig A. Huegen, Chief Network Architect C i s c o S y s t e m s > IT Transport, Network Technology & Design || || > Cisco Systems, Inc., 400 East Tasman Drive || || > San Jose, CA 95134, (408) 526-8104 |||| |||| > email: chuegen@cisco.com CCIE #2100 ..:||||||:..:||||||:.. > From owner-multi6@ops.ietf.org Wed Dec 11 00:08:58 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01842 for ; Wed, 11 Dec 2002 00:08:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Lz6v-000HJX-00 for multi6-data@psg.com; Tue, 10 Dec 2002 21:08:41 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.36 #2) id 18Lz6s-000HJL-00 for multi6@ops.ietf.org; Tue, 10 Dec 2002 21:08:39 -0800 content-class: urn:content-classes:message Subject: RE: network controls are necessary MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 10 Dec 2002 21:08:37 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405E523@server2000> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: network controls are necessary Thread-Index: AcKfz5k3TErPN/zLT7m6WCIE9oPU7ABAbMfg From: "Michel Py" To: "Craig A. Huegen" Cc: X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA01842 > Craig A. Huegen wrote: > As long as you are considering how to take a network of > 100,000 hosts in a distribution of 65% OS-A, 25% OS-B, > 5% OS-C, and 5% OS-Other (comprised of about 35 different > other OS's), > (PS - No, those aren't real numbers of operating system > distribution at any particular entity that still exists. Not that far off. S-A = win2k OS-B = nt4 Out of the 36 different OS for OS-C and Other-OS, I can enumerate: Windows 95 Windows 98 Windows 98se Windows Me Windows XP MacOs pre OS8.6 MacOs pre-OS X MacOs X Linux FreeBSD Solaris 7 Solaris 8 UnixWare HP/UX different flavors of OS/400 w/TCP/IP .. .. Not to mention that on lots of networks I had to work on, 6 to 7 protocols on the wire are common, given the basic 5 found all the time: IP IPX AT Ph II Decnet SNA Although I agree that we do need more host people involved, the fact of the matter is that the network administrator is the one that sees the big picture, given the fact that the AS/400 guys don't talk to the Macintosh guys that don't talk to the Windows guys. TE is not only about IP. Stuff like DLSW+ and proprietary video protocols come to mind. Michel. From owner-multi6@ops.ietf.org Wed Dec 11 00:15:51 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01977 for ; Wed, 11 Dec 2002 00:15:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18LzEx-000Hl3-00 for multi6-data@psg.com; Tue, 10 Dec 2002 21:16:59 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.36 #2) id 18LzEm-000HkU-00 for multi6@ops.ietf.org; Tue, 10 Dec 2002 21:16:48 -0800 content-class: urn:content-classes:message Subject: RE: Next question... MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 10 Dec 2002 21:16:46 -0800 Message-ID: <2B81403386729140A3A899A8B39B04640BD502@server2000> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: Next question... Thread-Index: AcKf2pGdZQ550yEZTBCNJob7U0NgZwA+YZdw From: "Michel Py" To: "Craig A. Huegen" Cc: X-Spam-Status: No, hits=0.0 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA01977 > Craig A. Huegen wrote: > It is certainly not this. I would love to be able to hand > a policy specification to my counterparts in our desktop > standards group and have them figure out how to apply this, > in communication, coordination, etc. Less work for my team. > But I recognize (as detailed in a previous e-mail) that the > time and effort required to manage the configurations on a > significant number of hosts and various permutations of host > capabilities/extensions is far greater than an extensible > policy infrastructure that allows me as the administrator > to change policy and immediately have it applied across the > entire infrastructure. I can enhance the policy engine on > less than 30 devices globally as opposed to coordinating > features from a number of vendors for a number of operating > systems for 100,000 hosts. I could not agree more. Michel. From owner-multi6@ops.ietf.org Wed Dec 11 10:11:48 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08321 for ; Wed, 11 Dec 2002 10:11:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18M8Wk-000D2L-00 for multi6-data@psg.com; Wed, 11 Dec 2002 07:11:58 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 18M8Wh-000D29-00 for multi6@ops.ietf.org; Wed, 11 Dec 2002 07:11:55 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gBBFAwR06977 for ; Wed, 11 Dec 2002 16:10:58 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Wed, 11 Dec 2002 16:10:58 +0100 (CET) From: Iljitsch van Beijnum To: Subject: host or border router Message-ID: <20021211135008.K552-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.5 required=5.0 tests=SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk [Peter, I was going to reply to your message but decided against it in order to more easily maintain my own train of thought.] If we are going to create a multihoming solution that uses identifiers that are usable as IPv6 adresess for end-to-end identification and regular unicast IPv6 adresses that replace the identifiers in transit, I see three ways to handle the address replacement: 1. In the end-host 2. In a site border router (SBR) 3. In some kind of middlebox I believe doing it in the actual SBR is a non-starter. Sure, you can build a box that can replace addresses and maintain the state that goes with this. And sure, you can build a box that can forward IP real fast. I'm just not sure you can do both at the same time, and even if it's possible, it won't be cost effective. As far as I know, there are no software-based routers that can handle IP(v6) forwarding at line rate for gigabit interfaces. Now obviously this changes all the time (I've done some tests recently and it looks like off-the-shelf PC hardware has about reached this performance level not too long ago) but bandwidth requirements also go up so the fundamental problem should remain the same. Anyway, not all that many people have more than 1000 Mbps worth of bandwidth to the net, but those that do need hardware support. But AFAIK, most of the really fast boxes are deployed either inside corporate networks or in ISP networks, where address rewriting for multihoming support isn't an issue. So this means router vendors have to bake much more complex silicon for a very small group of customers. I just don't see this happening, with the result that very large edge networks (think Google, Yahoo, Amazon) won't be able to talk multihomedly to their correspondents. That would be very bad. There is little value in requiring that this happens in the real SBR anyway. This type of processing can be done on middleboxes (ie existing firewalls or new special purpose boxes) which either select the right SBR or work together with the SBR(s) so the source/destination addresses are compatible with the routing decisions made by the SBRs. Doing this in middleboxes has the advantage that neither the routers nor the hosts have to change. Having said this, I think it is possible to do it on the hosts. This has the advantage that the state the host has to maintain anyway can be used to do quick failover to an alternate address. This would be hard/expensive to implement in an external box. Whether it's the hosts or middleboxes that do this, we need to support some important policy/traffic engineering requirements. The ones that I can think of are: 1. Always prefer link A, use link B only as a backup 2. Use link A for certain destinations/applications, link B for everything else 3. Send/receive x% of traffic over link A, 100-x% over link B 4. Select shortest path path for each destination 5. Combinations of the above Currently, the routing system only supports 1. relatively well. The others are doable to a certain degree, but the routing system doesn't fully support them. To support these, we need: 1 outbound: statically configured policy, reachability information 1 inbound: statically configured policy must be conveyed to correspondent, reachability information 2 outbound: same as 1 outbound 2 inbound: same as 1 inbound 3 outbound: link usage information 3 inbound: link usage information must be conveyed to correspondent 4 outbound: topology information or path attribute measurements + ability to measure both paths simultaneously 4 inbound: will be determined by correspondent 5 outbound: 1, 3 and 4 outbound combined 5 inbound: 1 and 3 inbound combined To make a long story short, we need: - statically configured policies - link usage information - topology information and path measurements, preferably for both paths at the same time - a way to negotiate session parameters with the correspondent - a way to map identifiers to locators in order to bootstrap the negotiation process Obviously querying the SBRs for link statistics isn't something we want all hosts to do. So we need a small number of boxes that manage at least part of the policy/traffic engineering. However, this doesn't mean these boxes should also handle the traffic: it would be perfectly reasonable to aggregate the P/TE info here and then distribute this to hosts. A good way to do this would be "DNSng" where the host looks up a hostname for a remote host and receives not only one or several IP addresses, but also extra information such as the preference for each of those addresses and the source address that goes with them, and DSCP or flow label suggestions. Note that such a DNSng box wouldn't be able to provide conclusive mapping information as it doesn't have the very granular reachability information hosts or boxes that sit in the middle of the traffic stream have. Alternatively, all of this can be handled in middleboxes that also do the actual mapping, so they are aware of which addresses work and which don't. Then we probably want a protocol to distribute information between those, but there is no rush there. Iljitsch From owner-multi6@ops.ietf.org Wed Dec 11 12:57:05 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14658 for ; Wed, 11 Dec 2002 12:57:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18MB8j-000Kec-00 for multi6-data@psg.com; Wed, 11 Dec 2002 09:59:21 -0800 Received: from dmz1.procket.com ([65.174.124.36]) by psg.com with esmtp (Exim 3.36 #2) id 18MB8g-000KbO-00 for multi6@ops.ietf.org; Wed, 11 Dec 2002 09:59:18 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 9AACD23C46; Wed, 11 Dec 2002 09:57:52 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id gBBHwliI003702; Wed, 11 Dec 2002 09:58:48 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: host or border router Date: Wed, 11 Dec 2002 09:58:47 -0800 Message-ID: Thread-Topic: host or border router Thread-Index: AcKhKHtT3bVKb5Z7RYW8F6JlwsE/7wAFf2fw From: "Tony Li" To: "Iljitsch van Beijnum" , X-Spam-Status: No, hits=0.5 required=5.0 tests=SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA14658 | I believe doing it in the actual SBR is a non-starter. Sure, you can | build a box that can replace addresses and maintain the | state that goes | with this. And sure, you can build a box that can forward | IP real fast. | I'm just not sure you can do both at the same time, and even if it's | possible, it won't be cost effective. Sorry, nope. First, there are multiple systems out there today that could do this or are close to it. Folks are pretty much there today with OC-48 interfaces and silicon forwarding, so there is enough thrust to support a wire speed GigE. Yes, this is a step up from today's SBR, but the major step up here is because of the bandwidth, not the added complexity. For folks with a T1, the cannonical 2600 class machine will still run just fine. We have an existance proof thanks to NAT. Tony From owner-multi6@ops.ietf.org Wed Dec 11 13:28:12 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15565 for ; Wed, 11 Dec 2002 13:28:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18MBcr-000MGx-00 for multi6-data@psg.com; Wed, 11 Dec 2002 10:30:29 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #2) id 18MBcn-000MGi-00 for multi6@ops.ietf.org; Wed, 11 Dec 2002 10:30:25 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id gBBITRq07259; Wed, 11 Dec 2002 19:29:27 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Wed, 11 Dec 2002 19:29:27 +0100 (CET) From: Iljitsch van Beijnum To: Tony Li cc: Subject: RE: host or border router In-Reply-To: Message-ID: <20021211191703.J552-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 11 Dec 2002, Tony Li wrote: > | I believe doing it in the actual SBR is a non-starter. > Sorry, nope. First, there are multiple systems out there today > that could do this or are close to it. Folks are pretty much there > today with OC-48 interfaces and silicon forwarding, so there is > enough thrust to support a wire speed GigE. I'm not saying it can't be done, just that only a small number of the people buying very fast routers need this, so building this functionality inside generic routers probably isn't the best way to go. Not _requiring_ it to be done in the SBR leaves the option to do it in the SBR anyway wide open for those who think that's a good idea. The other way around is more problematic. From owner-multi6@ops.ietf.org Wed Dec 11 13:31:41 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15675 for ; Wed, 11 Dec 2002 13:31:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18MBga-000MR0-00 for multi6-data@psg.com; Wed, 11 Dec 2002 10:34:20 -0800 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #2) id 18MBgW-000MNQ-00 for multi6@ops.ietf.org; Wed, 11 Dec 2002 10:34:16 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id B7E6D3442A; Wed, 11 Dec 2002 10:43:42 -0800 (PST) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id gBBIXiiI005250; Wed, 11 Dec 2002 10:33:44 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: host or border router Date: Wed, 11 Dec 2002 10:33:44 -0800 Message-ID: Thread-Topic: host or border router Thread-Index: AcKhQzUu4U8hTuP6QCyLqeoM7e5abwAAHTcg From: "Tony Li" To: "Iljitsch van Beijnum" Cc: X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA15675 | > Sorry, nope. First, there are multiple systems out there today | > that could do this or are close to it. Folks are pretty | much there | > today with OC-48 interfaces and silicon forwarding, so there is | > enough thrust to support a wire speed GigE. | | I'm not saying it can't be done, just that only a small | number of the | people buying very fast routers need this, so building this | functionality inside generic routers probably isn't the | best way to go. That's what they said about NAT. Now you can buy it from Linksys, Netgear, etc. | Not _requiring_ it to be done in the SBR leaves the option | to do it in | the SBR anyway wide open for those who think that's a good idea. The | other way around is more problematic. Having many options leads to complexity. IMHO, we need to decide how this will work. Tony From owner-multi6@ops.ietf.org Wed Dec 11 13:39:09 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15857 for ; Wed, 11 Dec 2002 13:39:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18MBnm-000Mrn-00 for multi6-data@psg.com; Wed, 11 Dec 2002 10:41:46 -0800 Received: from gnat.inet.org ([63.108.254.91]) by psg.com with esmtp (Exim 3.36 #2) id 18MBni-000Mqx-00 for multi6@ops.ietf.org; Wed, 11 Dec 2002 10:41:43 -0800 Received: from extremenetworks.com (unknown [10.0.8.72]) by gnat.inet.org (Postfix) with ESMTP id 3F1AC6712D; Wed, 11 Dec 2002 10:08:12 -0500 (EST) Date: Wed, 11 Dec 2002 13:41:07 -0500 Subject: Re: host or border router Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: To: "Tony Li" From: RJ Atkinson In-Reply-To: Message-Id: <1C8A167A-0D38-11D7-9F3B-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) X-Spam-Status: No, hits=-0.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI,SPAM_PHRASE_01_02, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, Dec 11, 2002, at 12:58 America/Montreal, Tony Li wrote: > | I believe doing it in the actual SBR is a non-starter. Sure, you > can > | build a box that can replace addresses and maintain the > | state that goes > | with this. And sure, you can build a box that can forward > | IP real fast. > | I'm just not sure you can do both at the same time, and even if > it's > | possible, it won't be cost effective. > > > Sorry, nope. First, there are multiple systems out there today > that could do this or are close to it. Folks are pretty much there > today with OC-48 interfaces and silicon forwarding, so there is > enough thrust to support a wire speed GigE. There are multiple equipment vendors out there today who can do roughly this on multiple interfaces at more than 1 Gbps line rate per interface. I'm not sure about 10 Gbps line rate today, but in a year or two even on a 10 GigE interface this should be feasible for multiple equipment vendors. Consider high-speed NAT products as a starting point, because they have to keep roughly the same state and perform roughly the same functions. Technology is just not a problem here. > Yes, this is a step up from today's SBR, but the major step up here > is because of the bandwidth, not the added complexity. For folks > with a T1, the cannonical 2600 class machine will still run just > fine. We have an existance proof thanks to NAT. Yep. Ran rja@extremenetworks.com From owner-multi6@ops.ietf.org Wed Dec 11 13:59:23 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16484 for ; Wed, 11 Dec 2002 13:59:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18MC72-000Op7-00 for multi6-data@psg.com; Wed, 11 Dec 2002 11:01:40 -0800 Received: from gnat.inet.org ([63.108.254.91]) by psg.com with esmtp (Exim 3.36 #2) id 18MC6r-000OlM-00 for multi6@ops.ietf.org; Wed, 11 Dec 2002 11:01:30 -0800 Received: from extremenetworks.com (unknown [10.0.8.72]) by gnat.inet.org (Postfix) with ESMTP id 8E0176712F; Wed, 11 Dec 2002 10:27:59 -0500 (EST) Date: Wed, 11 Dec 2002 14:00:49 -0500 Subject: Re: host or border router Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: To: Iljitsch van Beijnum From: RJ Atkinson In-Reply-To: <20021211191703.J552-100000@sequoia.muada.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI,SPAM_PHRASE_00_01, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, Dec 11, 2002, at 13:29 America/Montreal, Iljitsch van Beijnum wrote: > I'm not saying it can't be done, just that only a small number of the > people buying very fast routers need this, so building this > functionality inside generic routers probably isn't the best way to go. I believe it can be done in lower cost generic routers using existing commodity silicon. For sure it is available today from multiple vendors in products costing less than US$ 5000 (street price). At 100 Mbps performance, it is available in shipping products for less than US$ 1000 (street price) today. It is available at 10 Mbps performance in really really cheap equipment for home use today for ~US$ 100. Putting it in the router is unlikely to increase the router cost and many routers will be able to do it today (e.g. tli's comment about the 2600). Ran rja@extremenetworks.com From owner-multi6@ops.ietf.org Wed Dec 11 17:52:02 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24078 for ; Wed, 11 Dec 2002 17:52:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18MFi9-000ByD-00 for multi6-data@psg.com; Wed, 11 Dec 2002 14:52:13 -0800 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.36 #2) id 18MFi5-000Bxs-00 for multi6@ops.ietf.org; Wed, 11 Dec 2002 14:52:09 -0800 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id JAA15091; Thu, 12 Dec 2002 09:52:00 +1100 (EST) Date: Thu, 12 Dec 2002 09:52:00 +1100 (EST) From: Peter Tattam To: Iljitsch van Beijnum cc: multi6@ops.ietf.org Subject: Re: host or border router In-Reply-To: <20021211135008.K552-100000@sequoia.muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 11 Dec 2002, Iljitsch van Beijnum wrote: > [Peter, I was going to reply to your message but decided against it in > order to more easily maintain my own train of thought.] That's ok. I was going to expand further on the CCS as to how I'd typically see it deployed. However there has been little comment on my idea - just waiting for feedback before expending more intellectual resources on the ideas. > > If we are going to create a multihoming solution that uses identifiers > that are usable as IPv6 adresess for end-to-end identification and > regular unicast IPv6 adresses that replace the identifiers in transit, I > see three ways to handle the address replacement: > > 1. In the end-host > 2. In a site border router (SBR) > 3. In some kind of middlebox > > Whatever solution is deployed, of these 3, I would prefer 1. I think there will always be concerns as to whether a SBR will work. The problem with what I am propoing is that is isn't optional. it's an all or nothing idea. People can opt to use NAT and find a hardware solution that works. When they run out of steam, they have to move to real addressing and a proper network. Firewalls are much the same. They function ok when they are small, but when you get a monster site and you start having to make difficult choices like making sure it isn't stateful and stuff. A middlebox is another point of failure and this would need to be thought through carefully - can it be made redundant with rapid failover? Is it additional hardware cost in an IT world which is starting to count pennies more than ever? Since we are trying to design for the future, not for things as we see it now, I would always prefer a solution that has room to scale. We should be looking for solutions where packets are not modified in transit - this is consistent with IPv6 routing conventions. That's why doing it in the hosts is starting to look like the most scalable solution for the long term, but only if we can constrain the lists of alternative addresses so that the host is not burdened too much. If we can get the CCS right, the address twiddling only needs to be done at connection establishment time and when there is a path failure. If the CCS is rugged enough, the host would only need to keep two addresses - the formal address and the actual address, and trust the CCX to return the right information. I still think it's a good idea to authenticate a new address when it is to be switched over, and keeping the full set of potential MH addresses is optional for the host. Whichever way we go, it is important that the complete list be able to be reconstructed at any point in the lifetime of a connection - it's a matter of how much the host wants to trust the CCS and how much MH information it wants to maintain itself. Perhaps for regular work like a large web site or somthing, the CCS is adequate, but for mission cirtical stuff where you want to be absolutely sure you aren't being spoofed (e.g. linking exchanges - see later), you do the full MH exchange of addresses at connection startup and keep the full address lists. Some more on the CCS - I think that acronym is too overloaded so how about CCX (Connection Cache eXchange system) but I will continue to use CCS for the time being. I will refer to nodes in the CCS as exchanges. I see it as a parasitic system that monitors the BGP system in a read only manner. Kind of like an autonomous feedback system for the network, and I'd visualize it as an organism that has tentacles tapping into border and transit routers. An exchange could monitor as many BGP nodes as it feels necessary and has authority to do so. Very likely such monitoring will need to be authenticated to prevent spoofing of CCS information. Some additional characteristics. It would have to push network state information around in some manner and would also have to be immune to some extent from path failures that it is trying to prevent - would SCTP be a good candidate here? Linking exchanges. Within a site if an exchange is 1 hop away, we can trust it to the same level as we already do for ND. The same applies for adjacent exchanges - if they are 1 hop away, then they can be trusted in much the same way as BGP trusts its own peers (this assumes that a border router doubles as an exchange). If an adjacent exchange is more than one hop away, then I think the traffic should be authenticated - I don't see this as difficulty because an exchange is a key infrastructure item and so adding a level of security would prevent hostile attacks on exchanges. One advantage over the BGP system is that exchanges can be more highly meshed than just its neighbors. It would be possible to mesh exchanges so that a high degree of path redudancy is maintained so that information can reliably sent. However one needs to take care that the right path topology is returned to the site boundaries so that the correct MH prefixes can be used. Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 From owner-multi6@ops.ietf.org Wed Dec 11 18:37:14 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25576 for ; Wed, 11 Dec 2002 18:37:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18MGR0-000EdA-00 for multi6-data@psg.com; Wed, 11 Dec 2002 15:38:34 -0800 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.36 #2) id 18MGQw-000Eco-00 for multi6@ops.ietf.org; Wed, 11 Dec 2002 15:38:31 -0800 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id KAA18539; Thu, 12 Dec 2002 10:38:16 +1100 (EST) Date: Thu, 12 Dec 2002 10:38:16 +1100 (EST) From: Peter Tattam To: Iljitsch van Beijnum cc: multi6@ops.ietf.org Subject: Re: host or border router In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.6 required=5.0 tests=IN_REP_TO,SPAM_PHRASE_00_01,USER_AGENT_PINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Some further thoughts on your comments.... Much of this MH debate is about pleasing as many interests as possible. While I think that no one solution is going to please everyone, I think that compromise and hybrid solutions can be implemented in several ways might come close. That said, one of the major criticisms of a host based solution is that the IP stacks need changing and we've already deployed a lot of stuff. I think that the idea of a middlebox can deal with the legacy issues for the short term and also serve to supply such infrastructure to machines that it is impractical to impose such requirements on. So I guess what I'm saying is that the same result can be achieved with either host based or middlebox solutions and that we should pursue both directions simultaneously, with the ultimate goal to have host based MH as the preferred option for deploying such a system. Also one possibility might be to combine the middlebox and the CCS exchange as the two are likely to be strongly related. There is a lot of mixing and matching that could take place and leave room for exploration of various configurations of what I've proposed. Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 From owner-multi6@ops.ietf.org Fri Dec 13 02:43:05 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17456 for ; Fri, 13 Dec 2002 02:43:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18MkUH-000EXs-00 for multi6-data@psg.com; Thu, 12 Dec 2002 23:43:57 -0800 Received: from d12lmsgate-3.de.ibm.com ([194.196.100.236]) by psg.com with esmtp (Exim 3.36 #2) id 18MkUD-000EV7-00 for multi6@ops.ietf.org; Thu, 12 Dec 2002 23:43:53 -0800 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id gBD7h2Vi018544; Fri, 13 Dec 2002 08:43:07 +0100 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.12.3/NCO/VER6.4) with SMTP id gBD7h1TF095820; Fri, 13 Dec 2002 08:43:01 +0100 Received: from dhcp23-27.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA61276 from ; Fri, 13 Dec 2002 08:42:52 +0100 Message-Id: <3DF85B12.BBF2AB5D@hursley.ibm.com> Date: Thu, 12 Dec 2002 10:46:58 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: RJ Atkinson Cc: Iljitsch van Beijnum , multi6@ops.ietf.org Subject: Re: host or border router References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-0.8 required=5.0 tests=DATE_IN_PAST_12_24,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit We shouldn't even debate whether the intermediary is physically in the same box as the SBR or is separate. What we should debate is whether an intermediary or the host is the best place, or even whether the functionality can be defined in such a way that even this doesn't matter. In other words, derive the functionality from the requirements, and leave the decision about placement open as long as possible. Brian RJ Atkinson wrote: > > On Wednesday, Dec 11, 2002, at 13:29 America/Montreal, Iljitsch van > Beijnum wrote: > > I'm not saying it can't be done, just that only a small number of the > > people buying very fast routers need this, so building this > > functionality inside generic routers probably isn't the best way to go. > > I believe it can be done in lower cost generic routers using existing > commodity silicon. For sure it is available today from multiple vendors > in products costing less than US$ 5000 (street price). At 100 Mbps > performance, it is available in shipping products for less than US$ 1000 > (street price) today. > > It is available at 10 Mbps performance in really really cheap equipment > for home use today for ~US$ 100. > > Putting it in the router is unlikely to increase the router cost and > many routers will be able to do it today (e.g. tli's comment about > the 2600). > > Ran > rja@extremenetworks.com b From owner-multi6@ops.ietf.org Fri Dec 13 16:34:27 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05934 for ; Fri, 13 Dec 2002 16:34:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18MxQe-000JEY-00 for multi6-data@psg.com; Fri, 13 Dec 2002 13:33:04 -0800 Received: from [194.230.235.202] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #2) id 18MxQa-000JCX-00 for multi6@ops.ietf.org; Fri, 13 Dec 2002 13:33:01 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (8.12.2/8.10.2) with ESMTP id gBDLWp1q000542; Fri, 13 Dec 2002 22:32:57 +0100 (CET) Date: Fri, 13 Dec 2002 10:25:53 +0100 Subject: Re: Multihoming and what we discussed in Atlanta Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: To: "Aldrin Isaac" From: Kurt Erik Lindqvist In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) X-Spam-Status: No, hits=-2.1 required=5.0 tests=DATE_IN_PAST_12_24,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_03_05,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > It's more administrative overhead for address registries, but that's > what they're there to do. Having separate space for multihomers makes > it possible for an ISP to avoid having to identify it's multihoming > customers that are not addressed with it's allocation to it's peers. I have been running engineering and peering policy for the largest transit provider in Europe, and this was never an issue to us... > > Assume a customer (1.) addresses with a /48 from ISP-A who's /32 is > announced as /32 to his peers (2.) customer advertises this /48 to > ISP-B (3.) ISP-B must advertise this /48 to his peers for multihoming > to work for customer. If customers intention was to solicit traffic > over link from ISP-A, he can't since his /48 is more specifically > routed over ISP-B. This problem and other's caused by ISPs > aggregating routes is what I refer to as inefficient routing. I think you missed one of my points. Doing what you suggest above is what I suggest we do immediately to buy us time for a more permanent solution. My solution to your problem above is to give out PI space. But this could come from the addresses already allocated to the RIRs from IANA. We don't need a dedicated block for that. > If customer had a PI /48 (from well-known limited PI blocks) which he > Why does it have to be from a well known block? What you describe above work just as fine with the current allocations. > > These blocks are easily identified with a prefix filter. If these PI > blocks are limited, say to 2^16 well-known /48s, DFZ growth due to > multihoming can be controlled and registries won't have too much > But if I am filtering these blocks, they are not really multihomed? - kurtis - From owner-multi6@ops.ietf.org Fri Dec 13 16:34:33 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05949 for ; Fri, 13 Dec 2002 16:34:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18MxQm-000JEp-00 for multi6-data@psg.com; Fri, 13 Dec 2002 13:33:12 -0800 Received: from [194.230.235.202] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #2) id 18MxQa-000JD9-00 for multi6@ops.ietf.org; Fri, 13 Dec 2002 13:33:01 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (8.12.2/8.10.2) with ESMTP id gBDLX31q000548; Fri, 13 Dec 2002 22:33:07 +0100 (CET) Date: Fri, 13 Dec 2002 10:53:58 +0100 Subject: Re: (ipv6mh) the Rebel Alliance meetings in Atlanta (long) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: Iljitsch van Beijnum , ipv6mh , multi6@ops.ietf.org To: Ronald van der Pol From: Kurt Erik Lindqvist In-Reply-To: <20021205105232.GA6682@rvdp.org> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) X-Spam-Status: No, hits=-2.2 required=5.0 tests=DATE_IN_PAST_06_12,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> BTW, I'm writing an article about if/when IPv6 will be adopted for a >> Dutch magazine. I'm still looking for good quotes from IPv6-skeptics. >> :-) > > Wrong question. IPv6 *is* being adopted at an exponential rate. See > http://www.nlnetlabs.nl/ipv6/measurements/index.en.html > Well, with low enough relative numbers you can make anything grow exponentially. :) - kurtis - From owner-multi6@ops.ietf.org Fri Dec 13 19:41:17 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11485 for ; Fri, 13 Dec 2002 19:41:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18N0OS-00016f-00 for multi6-data@psg.com; Fri, 13 Dec 2002 16:43:00 -0800 Received: from roam.psg.com ([147.28.4.2] ident=mailnull) by psg.com with esmtp (Exim 3.36 #2) id 18N0OP-00016T-00 for multi6@ops.ietf.org; Fri, 13 Dec 2002 16:42:58 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.10) id 18N0OO-00045k-00 for multi6@ops.ietf.org; Fri, 13 Dec 2002 16:42:57 -0800 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: From: "Aldrin Isaac" To: "Kurt Erik Lindqvist" Cc: Subject: RE: Multihoming and what we discussed in Atlanta Date: Fri, 13 Dec 2002 17:25:16 -0500 X-Spam-Status: No, hits=-0.2 required=5.0 tests=IN_REP_TO,RESENT_TO,SPAM_PHRASE_02_03 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kurt, % From: Kurt Erik Lindqvist % % > If customer had a PI /48 (from well-known limited PI blocks) which he % % Why does it have to be from a well known block? What you describe above % work just as fine with the current allocations. Why do we have well-known blocks for RFC1918, RFC3056, RFC2471, etc. Why couldn't they have come from arbitrary RIR blocks? How will an ISP who does not have an arrangement with you know not to aggregate multihoming customers allocated from your block? % > These blocks are easily identified with a prefix filter. If these PI % > blocks are limited, say to 2^16 well-known /48s, DFZ growth due to % > multihoming can be controlled and registries won't have too much % > % % But if I am filtering these blocks, they are not really multihomed? What I said was "identified with a prefix filter". I didn't specify what action should be taken after the identification. The action I imply is that ISPs MUST NOT AGGREGATE /48s from this well-known block. By keeping the block small DFZ growth by multi-homing can be controlled. regards -- aldrin From owner-multi6@ops.ietf.org Sun Dec 15 09:38:33 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03764 for ; Sun, 15 Dec 2002 09:38:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18NZsp-0004AB-00 for multi6-data@psg.com; Sun, 15 Dec 2002 06:36:43 -0800 Received: from smtp02.uc3m.es ([163.117.136.122] helo=smtp.uc3m.es) by psg.com with esmtp (Exim 3.36 #2) id 18NZsj-00049l-00 for multi6@ops.ietf.org; Sun, 15 Dec 2002 06:36:37 -0800 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id E6E6A4319B; Sun, 15 Dec 2002 15:36:28 +0100 (CET) Received: from localhost.localdomain (unknown [163.117.252.48]) by smtp02.uc3m.es (Postfix) with ESMTP id 353C699F34; Sun, 15 Dec 2002 15:36:25 +0100 (CET) Subject: Re: host based MH with a connectivity cache From: marcelo bagnulo To: Peter Tattam Cc: Multi6 Working Group In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1039962472.780.32.camel@presto> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.0.5 Date: 15 Dec 2002 15:36:33 +0100 X-Spam-Status: No, hits=-1.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Peter, I am trying to understand your idea but I fail to understand some points. If i understand correctly the CSS (or CSX) stores information about mapping between identifiers (FORMAL addresses/prefixes) and CURRENLTY working locators (ACTUAL addresses/prefixes). Moreover, if you have a CSS within the site A, it will store: - mapping information between identifiers and locators about hosts that belong to the site A, so it can provide this information to other CSS that can need it (this would be the server part) - mapping information between identifiers and locators about other sites, so it can provide it to hosts belonging to the site A (this would be the cache part) Then, let's say you have two sites: site A which is multi-homed and site B which is not multi-homed. If a host (hostB) that belongs to the site B wants to communicate with hostA belonging to site A, (we suppose that HostB already has HostA identifier, for instance it obtained it from the DNS) then - hostB request mapping information about hostA from the CSS of its site (site B) (CSSB) - CSSB asks CSSA about the mapping info - CSSB answer to hostB - hostB starts the communication using one of the locators returned Would this be correct? If this is so, - I do not see how does the BGP interaction works. I mean, CSSB should return to hostB, information about locators that are currently reachable. This means that if you send a packet from site B addressed to that locator, an available path exits. Doesn't aggregation would preclude you to see that? - How do you propose to find out which is the CSS for a given address In the example how does CSSB find out CSSA? Something like the reverse lookup in DNS perhaps? - The CSS seems like a critical part of the system, so i guess it should benefit from multi-homing fault tolerance capabilities, so i guess that an alternative method to provide its multi-homing capabilities is required, right? - the solutions requires at least one CSS per site (multi-homed or not)? Thanks, marcelo On Tue, 2002-12-10 at 00:32, Peter Tattam wrote: > Here are the latest thoughts I've had with the MH stuff... > > This is a kind of hybrid host based and BGP MH solution. > > Some preamble... > > a) One of the problems I can see is that any MH solution that relies on the > originating sites view of connectivity is likely to fail. The reason for this > is that the path and ultimate connectivity between two sites is going to be > dependendent on where they are located in relation to each other. i.e. If a > site is multihomed, the MH address to use as a source address is going to vary > depending who it's maintaining a connection to. This would preclude any static > advertising of MH addresses by the site (e.g. DNS or other kinds of mapping) > without an additional connectivity protocol to find the best path. > > b) Another issue is the DFZ debate. Since we have applied a rule to the DFZ > that say no advertising of longer prefixes, we have effectively placed a > barrier for MH information to transit across the internet. We should not > forget that the full MH information is *still* in the BGP system, it's just not > visible between BGP zones. Since the information is still there, it would be a > waste not to use it on some way. > > Now some of this is hand waving - apologies if some of it won't fly. > > My idea contains two parts... > > first... the host based MH part (yeah I can't let go of my idea :) > > 1. Use a host based MH solution as I've previously discussed. Apply it to the > entire IP layer, not just TCP, and use the techniques for address handover as > recently discussed. > > 2. MH should be restricted to prefixes only. MH addresses with different > prefixes, but the same host part are the same address, however equivalent > addresses must still be checked. > > 3. Deploy a site based Connectivity Cache System (CCS) that links directly into > the BGP system, and runs parallel to this system. It would operate on a > similar basis to DNS in that the entire BGP is not required, but just the parts > that the site is interested in reaching from it's perspective. My guess is it > would scale in roughly the same way as DNS would. Such a connectivty cache > should take advantage of the hiearchical nature of the MH system to provide > hints that branches of the BGP tree had come & gone. It would by nature be a > more dynamic structure than the DNS currently is, and care should be taken to > manage the security aspects. Typically a site would maintain 1 or 2 of these > caches in a similar way to DNS, and also a large site could maintain a > centralized cache for the use of smaller sites within it's control. It must > also be able to determine whether a path exists between two MH addresses and > for the reasons of load balancing determine some level of fine grained path > characteristics, possibly supplemented by policy controls. > > The ultimate purpose of such a cache is to restore the MH information to end > points that the strongly aggregated DFZ has thrown away. It is important to > remember that much of the BGP information is already available in the BGP > system that is currently deployed. > > 4. A site would advertise it's MH prefixes into this system and the prefixes > are bound together by MH identifier. This is very close to BGP as we know it, > but the important part is that the MH binding identifier should be visible to > the site's hosts and would be used to query the connectivity cache. > > 5. This is optional - the MH identifier can be used to construct a PI MH prefix > which would be advertised into the DNS system and used much in the way that an > IPv4 prefix is. I will refer to this prefix/address as being the FORMAL > prefix/address and the MH prefixes/addresses used for transport as the ACTUAL > prefixes/addresses. A host need only ever be aware of the address formed from > this prefix in the application layer and can be used for the usual reasons > where a host identifier is required. When the address gets used, it is up to > either the host to maintain actual address pairs, or the site border routers to > translate the formal address into the actual address(es). > > I would propose that a section of the IPv6 address be allocated as a PI address > space for the specific purpose of multi homing. Any site that is multi homed > must have a PI address prefix. The name space by it's nature would be a flat > address space and could be constructed by concatenating a reserved MH prefix > with the existing IPv4 ASN. It would never be legal for such an address to be > used for transport outside a host/site, but must always be translated into > actual addresses once packets leave the host/site. > > 5(b). If 5 is not acceptable, it is still possible for the connectivity cache > to be queried for a particular address to return all the actual MH prefixes > associated with that prefix and the reachability to each address. > > 6. if host based MH is to be used, it relies on the connectivity cache to get > up to date MH information and would interact roughly in the same manner as DNS, > but would require additional information if connectivity were lost for a > particular host. The level of authntication for host based based MH would be > equivalent to ND and so could take advantage of the hop count to maintain a > reasonable level of integrity. > > 7. If a site based MH solution is deployed through address translation, by > virtue of (2), the amount of stateful information to be kept will be kept to a > minimum (one state per source-dest site path). However because of preamble (a) > I don't think it will be possible to completely remove states. A major concern > is that this translation will need to be done at borders on expensive routers > and this has the potential not to scale. The ideal answer is to never > translate packets once they leave a host which means the hosts must manage the > prefix modification. > > > Of these points, 1,2 and 5 are fairly well understood. 3,4 & 6 are the hard > part - scalability needs to be evaluated. 7 may not scale. Point 5 is > controversial also. > > These are my thoughts - they are a bit unpolished and may indeed be things > previously proposed. Apologies if I have just rehashed something that's been > done. > > The key components of this idea are... use of a BGP style cache that doesn't > requre the full BGP tree to be shuffled around and frees core routers to do > routing only. The other key idea is the use of a formal PI MH address which are > then translated into actual MH addresses which operate without intervention by > routers. > > Regards > > Peter > -- > Peter R. Tattam peter@trumpet.com > Managing Director, Trumpet Software International Pty Ltd > Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 > > From owner-multi6@ops.ietf.org Sun Dec 15 17:43:18 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11411 for ; Sun, 15 Dec 2002 17:43:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18NhUb-000JaC-00 for multi6-data@psg.com; Sun, 15 Dec 2002 14:44:13 -0800 Received: from dhcp1.kurtis.pp.se ([195.43.225.70] helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 3.36 #2) id 18NhUY-000JZm-00 for multi6@ops.ietf.org; Sun, 15 Dec 2002 14:44:11 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (8.12.2/8.10.2) with ESMTP id gBFMiO1q000742; Sun, 15 Dec 2002 23:44:25 +0100 (CET) Date: Sun, 15 Dec 2002 20:58:03 +0100 Subject: Re: Site local Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: <20021209192320.J552-100000@sequoia.muada.com> Message-Id: <857AAD80-1067-11D7-BE91-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01, USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Well, let's create something that we feel comfortable showing others > first. More to the list of situations, how would we support multicast in this model? Do we need to? > I don't think the application part is all that complex. Either you are > a > sender or a receiver. The sender sets up a session or packet. The most Well, the same goes for NAT and applications still don't work :) > important information here is the destination address/name and port, > but > the sender may also specify a source. The sender fires off a TCP > session > or a (UDP) packet. Meanwhile, the receiver has started listening on an > address/port. A packet or session request comes in. The receiver looks > at the source address/port and decides whether to accept the > session/packet. Well, my worry is that we (I at least) don't understand all application designs well enough to make the claim that the above model would hold as a benchmark. I still think we should have the applications group look at the proposals and make a comment on them. - kurtis - From owner-multi6@ops.ietf.org Sun Dec 15 18:12:06 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11893 for ; Sun, 15 Dec 2002 18:12:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18Nhxs-000KWY-00 for multi6-data@psg.com; Sun, 15 Dec 2002 15:14:28 -0800 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.36 #2) id 18Nhxm-000KWK-00 for multi6@ops.ietf.org; Sun, 15 Dec 2002 15:14:22 -0800 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id KAA09758; Mon, 16 Dec 2002 10:14:14 +1100 (EST) Date: Mon, 16 Dec 2002 10:14:13 +1100 (EST) From: Peter Tattam To: marcelo bagnulo cc: Multi6 Working Group Subject: Re: host based MH with a connectivity cache In-Reply-To: <1039962472.780.32.camel@presto> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_02_03,USER_AGENT_PINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On 15 Dec 2002, marcelo bagnulo wrote: > Hi Peter, > > I am trying to understand your idea but I fail to understand some > points. > > If i understand correctly the CSS (or CSX) stores information about > mapping between identifiers (FORMAL addresses/prefixes) and CURRENLTY > working locators (ACTUAL addresses/prefixes). Moreover, if you have a > CSS within the site A, it will store: > - mapping information between identifiers and locators about hosts that > belong to the site A, so it can provide this information to other CSS > that can need it (this would be the server part) > - mapping information between identifiers and locators about other > sites, so it can provide it to hosts belonging to the site A (this would > be the cache part) > > Then, let's say you have two sites: site A which is multi-homed and site > B which is not multi-homed. > > If a host (hostB) that belongs to the site B wants to communicate with > hostA belonging to site A, (we suppose that HostB already has HostA > identifier, for instance it obtained it from the DNS) then > - hostB request mapping information about hostA from the CSS of its site > (site B) (CSSB) > - CSSB asks CSSA about the mapping info > - CSSB answer to hostB > - hostB starts the communication using one of the locators returned > > Would this be correct? > > If this is so, > > - I do not see how does the BGP interaction works. I mean, CSSB should > return to hostB, information about locators that are currently > reachable. This means that if you send a packet from site B addressed to > that locator, an available path exits. Doesn't aggregation would > preclude you to see that? Yes, you are right about that & I mentioned this in the preface. It up to the CSSB to restore the missing BGP information via the interaction with its peer CSS(n)s not via the BGP visible at that point in the network, possibly in a recursive manner like the DNS operates. As the BGP view information traverses the net via the CSSes, the accessiblity information should probably be modified based on the CSS's derivation of the BGP information that it can see from that point. This an important point as it the best view of the other end of a connection should be the best approximation of the BGP as given by the CSS closest to the the site being referenced. Now this is perhaps the hand waving and I am open to assistance here. As far as I can envisage there would be two sets of information to be transferred between CSSes. There would be the initial set of mappings between formal and actual addresses along with the weights for each path based as reconstructed by the CSS system. This would be cached by the CSS system, and would be pulled by the local CSS in much the same way as DNS. Then there would be path update information which would be pushed by neighbouring CSSes to the local one. One would not want to have every CSS broadcasting to the whole CSS system, so I guess one would have to have a selective broadcasting system between CSSes. There are techniques from other disciplines we could borrow - perhaps something like the multicast system. A CSS requests from its peers that it wants to receive updates for paths which it knows are in use, and the neighbouring peers in turn receive the same information. In the worst case of a fully meshed CSS, the amount of information traversing would degenerate into the equivalent to a totally unaggregated BGP system with the DFZ being much the same as we have in IPv4. Only empirical data will tell us what the true picture will be. There is one advantage though, and that is the CSS system load can be removed from the core routing system and could be managed with cheaper hardware even if it ultimately resembles something like the BGP system we currently are used to. > - How do you propose to find out which is the CSS for a given address In > the example how does CSSB find out CSSA? Something like the reverse > lookup in DNS perhaps? It is not necessary to find any given CSS, only information about prefixes. Each CSS has an approximation of the full DFZ which would have resulted from an non aggregated internet but only for prefixes it is interested in. The appoximation is built up from the paths that the originating site needs to see (cached information) + the definitive MH information advertised by the site(s) that the CSS handles. There need not be a 1-1 mapping between sites and CSS, a CSS can serve many sites, but a site must have at least one CSS (and can possibly have more than one). However you have made a good point. It is not sufficient to just get the cached view from a neigbouring CSS. The information should be modified in such a way as to provide an accurate view which would be equivalent to that seen by a BGP system which had full unaggregated information in the DFZ. As long as CSSes are arranged in the right way topologically, it should be possible to determine the weights of the various MH paths between the source and destination paths. > - The CSS seems like a critical part of the system, so i guess it should > benefit from multi-homing fault tolerance capabilities, so i guess that > an alternative method to provide its multi-homing capabilities is > required, right? A CSS only needs to have hard wired into it all the MH paths to its peers and an independent mechanism to determine which of these paths is accessible (keepalives like BGP?) The quality of traffic between CSSes should not in any way affect the information that traverses the CSS system. I personally believe this is a fault in the current BGP system and the reason for the BGP storms we have grown accustomed to dealing with. > - the solutions requires at least one CSS per site (multi-homed or not)? Yes.. See above. > > Thanks, marcelo > I am sorry for the hand waving - I am trying my best to understand the full implications of how such an idea could work. I am happy to throw the ideas open to debate and input/enhancement from others. Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 From owner-multi6@ops.ietf.org Tue Dec 17 05:06:55 2002 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10638 for ; Tue, 17 Dec 2002 05:06:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #2) id 18OEd7-000520-00 for multi6-data@psg.com; Tue, 17 Dec 2002 02:07:13 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.36 #2) id 18OEd4-00051K-00 for multi6@ops.ietf.org; Tue, 17 Dec 2002 02:07:10 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id gBHA74g06071 for ; Tue, 17 Dec 2002 12:07:04 +0200 Date: Tue, 17 Dec 2002 12:07:04 +0200 (EET) From: Pekka Savola To: multi6@ops.ietf.org Subject: draft-kurtis-multihoming-longprefix comments Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.1 required=5.0 tests=SIGNATURE_SHORT_DENSE,SPAM_PHRASE_02_03,USER_AGENT_PINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Hello, A few comments on the draft. Major comments: 1) Seems to give wrong impression about the effectiveness of this mechanism. I believe (I'm collecting and analyzing some data too) that a significant portion of multihomers do it because they want to obtain operator independence. They usually don't have PI addresses, but what I'd call "PA sold off as PI" or "PA advertised as PI". (Esp 5.3) There must be an applicability section or statement early on what this tries to accomplish. 2) If we really need to go down with longer prefixes approach, I'd really want to restrict hem to peerings (and even smaller upstreams) only, _NOT_ DMZ. More specifics (:-): Longer prefix multihoming SHOULD NOT be used as an excuse to disable RPF checks. ==> there are usually many ways to do uRPF. One is a "feasible paths" approach, where sourcing a packet is ok as long as there is route towards the source in that interface (even if it is not active, due to a policy reason). This seems rather nice way to do uRPF in the multihoming case. 8. Acknowledgments This paper builds on a discussion at the IETF-55 in Atlanta. People who was part in the idea is Thomas Narten and Chirstian Huitema but also all the people who where are the unofficial multi6 meeting. ==> The idea of longer prefixes is ages old but rightfully scorned. I think you should mention that this is not a new idea at all. Editorials: In the current IP version 4 Internet, many organizations that are not Internet Service Providers are still getting their Internet connectivity through multiple providers by having address space that are announced via multiple paths. ==> s/that are // ==> this is one example of multihoming (though only really visible one) connections. For this they have also applied for similar blocks an their own AS numbers just as the ISPs use today. This document how ==> s/an/and/ ==> s/document/document describes/ In order to make use of the methods for achiving multihoming as ==> s/achiving/achieving/ addresses from their network service provide. In the case of already existing multiple service providers, only one of the should allocate a address block to be used ==> s/provide/provider/ ==> s/a address/an address/ These upstreams SHOULD accept a prefix length of 48 bits from their peers, and SHOULD NOT aggregate these routes. For the provider that have allocated ==> s/aggregate/automatically aggregate/ (or clarify that it's still ok to advertise the aggregate route :-) ==> s/have allocated/has allocated/ should configure it's border routers to announce the prefix it have ==> s/have/has/ will prove that claim either false or right. the second advantage of ==> s/the/The/ of concern for some enterprises to stay way from IPv6, but it does at ==> s/way/away/ Another popular reason in the IPv4 Internet have also been the fact that you with a multihoming setup would get so called Provider Independent addresses. These PI addresses are allocated directly from the RIRs to the enterprise. ==> move 'you' to before 'would'. In the IPv4 Internet routing table, also know as the Default Free ==> s/know/known/ -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords