From owner-multi6@ops.ietf.org Sat Mar 1 15:37:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17206 for ; Sat, 1 Mar 2003 15:37:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18pDiX-000Gs7-00 for multi6-data@psg.com; Sat, 01 Mar 2003 12:36:21 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 18pDiS-000Gru-00 for multi6@ops.ietf.org; Sat, 01 Mar 2003 12:36:17 -0800 From: Masataka Ohta Message-Id: <200303012028.FAA02354@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id FAA02354; Sun, 2 Mar 2003 05:27:53 +0859 Subject: Re: Draft: PI addressing derived from AS numbers In-Reply-To: <3E5CC8DD.C1217402@hursley.ibm.com> from Brian E Carpenter at "Feb 26, 2003 03:02:05 pm" To: Brian E Carpenter Date: Sun, 2 Mar 2003 05:27:53 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-0.7 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Brian; > > > So what I'm getting from this discussion is that 8+8 is too late but > > > 16+16 is too large??? I would agree that 16+16 is too large. How > > > about 4+16? > > > > > > > I am still curious as to why people think that 16+16 would be any > > different to 8+8. > > Because, like 4+16, it can coexist with plain 16. Whether people like > it or not, the product investments in RFC 2460 at this point oblige > any plausible solution to behave as an upgrade to plain 16. No problem. First, it is not RFC2460 but RFC2373. When I proposed to modify IPv6 addressing architecuture from 10+6 (with 48 bit MAC) to 8+8 (with 64 bit MAC, the current one in RFC2373), I have been carefully watching that universal/local and individual/group bits are not overridden. Thus, it is OK to give special meaning on local group MAC addresses. When both source and destinaiton addresses looks like local group MAC address, IP, TCP and other stacks should behave diffferently from leagacy ones. People who still need local addresses should be careful not to make it a group address, which is a trivial local administration issue. 62 bits are enough for globally unique reverse lookup. That's all. Masataka Ohta From owner-multi6@ops.ietf.org Sat Mar 1 15:55:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17378 for ; Sat, 1 Mar 2003 15:55:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18pE2J-000HRE-00 for multi6-data@psg.com; Sat, 01 Mar 2003 12:56:47 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 18pE2G-000HQV-00 for multi6@ops.ietf.org; Sat, 01 Mar 2003 12:56:44 -0800 From: Masataka Ohta Message-Id: <200303012044.FAA02442@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id FAA02442; Sun, 2 Mar 2003 05:44:15 +0900 Subject: Re: ISP failures and site multihoming [Re: Enforcing unreachability of site local addresses] In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F54C39@server2000.arneill-py.sacramento.ca.us> from Michel Py at "Feb 24, 2003 08:09:30 pm" To: Michel Py Date: Sun, 2 Mar 2003 05:44:14 +0859 () CC: Kurt Erik Lindqvist , Iljitsch van Beijnum , Pekka Savola , "Alan E. Beard" , Tim Chown , ipng@sunroof.eng.sun.com, multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-0.7 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Michel; > > Kurt Erik Lindqvist wrote: > > This I thought was more or less standard. I was talking about > > less than 100ms convergence. > > Dude, this requires a keepalive or hello at 10ms intervals and a 25~30 > ms rtt. You might need to talk to a guy named Albert Einstein; he wrote > interesting RFCs about the speed of light that, as far as I know, have > not been debunked yet. A simple end to end solution is to send multiple copies of a data to multiple pathes. Mission critical application over SONET is already doing so and it is said that, even if a path fails, not even a single bit is lost. As for IP multihoming, it is already implemented with a VoIP protocol and is working fine. Senders send multiple copies of a RTP data. At the receivers, RTP takes care of duplicate packet deletion. Having a few voice streams is not a problem at all, of course. Masataka Ohta From owner-multi6@ops.ietf.org Mon Mar 3 04:48:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14000 for ; Mon, 3 Mar 2003 04:48:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18pmWc-000PR7-00 for multi6-data@psg.com; Mon, 03 Mar 2003 01:46:22 -0800 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74] helo=dhcp-168-17-124.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18pmWJ-000PQM-00 for multi6@ops.ietf.org; Mon, 03 Mar 2003 01:46:03 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by dhcp-168-17-124.autonomica.se (8.12.6/8.10.2) with ESMTP id h239kxif011473; Mon, 3 Mar 2003 10:46:59 +0100 (CET) Date: Mon, 3 Mar 2003 10:46:59 +0100 Subject: Re: ISP failures and site multihoming [Re: Enforcing unreachability of site local addresses] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Michel Py , Iljitsch van Beijnum , Pekka Savola , "Alan E. Beard" , Tim Chown , ipng@sunroof.eng.sun.com, multi6@ops.ietf.org To: Masataka Ohta From: Kurt Erik Lindqvist In-Reply-To: <200303012044.FAA02442@necom830.hpcl.titech.ac.jp> Message-Id: <13EA0568-4D5D-11D7-ADF5-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) 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 > A simple end to end solution is to send multiple copies of a data to > multiple pathes. Mission critical application over SONET is already > doing so and it is said that, even if a path fails, not even a single > bit is lost. No. - kurtis - From owner-multi6@ops.ietf.org Mon Mar 3 06:47:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18318 for ; Mon, 3 Mar 2003 06:47:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18poPq-00026D-00 for multi6-data@psg.com; Mon, 03 Mar 2003 03:47:30 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 18poPm-00025y-00 for multi6@ops.ietf.org; Mon, 03 Mar 2003 03:47:27 -0800 From: Masataka Ohta Message-Id: <200303031140.UAA02194@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id UAA02194; Mon, 3 Mar 2003 20:39:52 +0859 Subject: Re: ISP failures and site multihoming [Re: Enforcing unreachability of site local addresses] In-Reply-To: <13EA0568-4D5D-11D7-ADF5-000393AB1404@kurtis.pp.se> from Kurt Erik Lindqvist at "Mar 3, 2003 10:46:59 am" To: Kurt Erik Lindqvist Date: Mon, 3 Mar 2003 20:39:52 +0859 () CC: Michel Py , Iljitsch van Beijnum , Pekka Savola , "Alan E. Beard" , Tim Chown , ipng@sunroof.eng.sun.com, multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-0.7 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Kurtis; > > A simple end to end solution is to send multiple copies of a data to > > multiple pathes. Mission critical application over SONET is already > > doing so and it is said that, even if a path fails, not even a single > > bit is lost. > > No. Which part are you arguing against? Masataka Ohta From owner-multi6@ops.ietf.org Tue Mar 11 09:12:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20016 for ; Tue, 11 Mar 2003 09:12:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18skUC-0006Vu-00 for multi6-data@psg.com; Tue, 11 Mar 2003 06:12:08 -0800 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by psg.com with esmtp (Exim 3.36 #1) id 18skU9-0006Vh-00 for multi6@ops.ietf.org; Tue, 11 Mar 2003 06:12:05 -0800 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id OAA13241 for ; Tue, 11 Mar 2003 14:12:04 GMT Received: from login.ecs.soton.ac.uk (login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id OAA18104 for ; Tue, 11 Mar 2003 14:03:20 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h2BE3Kw29251 for multi6@ops.ietf.org; Tue, 11 Mar 2003 14:03:20 GMT Date: Tue, 11 Mar 2003 14:03:20 +0000 From: Tim Chown To: multi6@ops.ietf.org Subject: Again no multi6 at IETF#56 Message-ID: <20030311140320.GS8715@login.ecs.soton.ac.uk> Mail-Followup-To: multi6@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-0.9 required=5.0 tests=SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Hi, What is required to break the impasse of no progress within the IETF on multi6? There are some good ideas in the "rebel" ipv6mh group (e.g. Christian's ideas for incremental solutions using existing tools). Even the multi6 chairs were seen in ipv6mh meetings :) We really don't want to be appraoching IETF#57 with this bizarre situation continuing, or do we? Tim From owner-multi6@ops.ietf.org Tue Mar 11 09:27:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20567 for ; Tue, 11 Mar 2003 09:27:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18skl4-0007CG-00 for multi6-data@psg.com; Tue, 11 Mar 2003 06:29:34 -0800 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.36 #1) id 18skky-0007Bw-00 for multi6@ops.ietf.org; Tue, 11 Mar 2003 06:29:28 -0800 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id BAA24746; Wed, 12 Mar 2003 01:29:21 +1100 (EST) Date: Wed, 12 Mar 2003 01:29:21 +1100 (EST) From: Peter Tattam To: Tim Chown cc: multi6@ops.ietf.org Subject: Re: Again no multi6 at IETF#56 In-Reply-To: <20030311140320.GS8715@login.ecs.soton.ac.uk> 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_00_01,USER_AGENT_PINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk I am interested in completing a solution which I sketched out a couple of months back, but my schedule is rather full so it won't be ready for the coming IETF meeting, but I had planned on something by the next meeting. Peter On Tue, 11 Mar 2003, Tim Chown wrote: > Hi, > > What is required to break the impasse of no progress within the IETF on > multi6? > > There are some good ideas in the "rebel" ipv6mh group (e.g. Christian's > ideas for incremental solutions using existing tools). Even the multi6 > chairs were seen in ipv6mh meetings :) > > We really don't want to be appraoching IETF#57 with this bizarre situation > continuing, or do we? > > Tim > > -- 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 Mar 11 10:24:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23458 for ; Tue, 11 Mar 2003 10:24:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sldQ-0009gW-00 for multi6-data@psg.com; Tue, 11 Mar 2003 07:25:44 -0800 Received: from gnat.inet.org ([63.108.254.91]) by psg.com with esmtp (Exim 3.36 #1) id 18sldI-0009fI-00 for multi6@ops.ietf.org; Tue, 11 Mar 2003 07:25:37 -0800 Received: from extremenetworks.com (unknown [10.18.3.101]) by gnat.inet.org (Postfix) with ESMTP id 36F1167103; Tue, 11 Mar 2003 10:41:33 -0500 (EST) Date: Tue, 11 Mar 2003 10:25:28 -0500 Subject: Re: Again no multi6 at IETF#56 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: multi6@ops.ietf.org To: Tim Chown From: RJ Atkinson In-Reply-To: <20030311140320.GS8715@login.ecs.soton.ac.uk> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) 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 Tuesday, Mar 11, 2003, at 09:03 America/Montreal, Tim Chown wrote: > What is required to break the impasse of no progress within the IETF on > multi6? I'm not *recommending* this, but any action/inaction on the part of the IESG, including the ADs for this WG, is appealable provided that one follows the formal appeals process. Frankly, I think the ADs and WG Chairs for multi6 are well across the line, outside the boundaries of civilised behaviour to not even permit an active WG with active on-charter list discussions to meet to discuss items listed in an IESG-approved WG charter. This is particularly true since it is not a one-time occurrance, but a repeated behaviour on their part. Yours, Ran rja@extremenetworks.com From owner-multi6@ops.ietf.org Tue Mar 11 10:46:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24394 for ; Tue, 11 Mar 2003 10:46:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18slyk-000Ah6-00 for multi6-data@psg.com; Tue, 11 Mar 2003 07:47:46 -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 #1) id 18slyi-000Agj-00 for multi6@ops.ietf.org; Tue, 11 Mar 2003 07:47:44 -0800 Subject: RE: Again no multi6 at IETF#56 Date: Tue, 11 Mar 2003 07:47:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <963621801C6D3E4A9CF454A1972AE8F54C99@server2000.arneill-py.sacramento.ca.us> Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Thread-Topic: Again no multi6 at IETF#56 Thread-Index: AcLn23ciSvQaXqqrQ6aXIIgMy7NFUwACNj3Q From: "Michel Py" To: "Peter Tattam" , "Tim Chown" 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 KAA24394 ipv6mh does meet in SFO on Sunday March 16 and probably some ad-hoc meetings during the week as well such as the one Jordi called in Atlanta. Details on the meeting location will be posted on the ipv6mh mailing list. Non-members are welcomed too. _ ____ __ __ ____ _ _ _ _ | | | _ \ \ \ / / / ___| | \ / | | | | | Michel Py | | | |_| | \ \ / / | |__ | \/ | | |__| | Sr. Network Engineer | | | __/ \ \/ / | _ \ | \ / | | __ | CCIE #6673 | | | | \ / | |_| | | |\/| | | | | | mpy@ieee.org |_| |_| \/ \___/ |_| |_| |_| |_| IPv6 Multihoming Solutions http://arneill-py.sacramento.ca.us/ipv6mh http://arneill-py.sacramento.ca.us/public/ipv6mh/ From owner-multi6@ops.ietf.org Tue Mar 11 11:22:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25716 for ; Tue, 11 Mar 2003 11:22:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18smXA-000CUn-00 for multi6-data@psg.com; Tue, 11 Mar 2003 08:23:20 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18smX1-000CSp-00; Tue, 11 Mar 2003 08:23:18 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18smWz-0008jf-00; Tue, 11 Mar 2003 08:23:10 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 11 Mar 2003 11:23:09 -0500 To: RJ Atkinson Cc: multi6@ops.ietf.org Subject: Re: Again no multi6 at IETF#56 References: <20030311140320.GS8715@login.ecs.soton.ac.uk> Message-Id: 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 >> What is required to break the impasse of no progress within the IETF on >> multi6? > > I'm not *recommending* this, but any action/inaction on the part of the > IESG, including the ADs for this WG, is appealable provided that one > follows the formal appeals process. i am impressed by your approach to technology and engineering. welcome to the new ietf where we care more about process and politics than protocol and product. sheesh! > Frankly, I think the ADs and WG Chairs for multi6 are well across the > line, outside the boundaries of civilised behaviour to not even permit an > active WG with active on-charter list discussions to meet to discuss items > listed in an IESG-approved WG charter. This is particularly true since it > is not a one-time occurrance, but a repeated behaviour on their part. quite an assertion. can you point to the request sent to agenda@ietf.org to hold a meeting? if not, ... where the sun don't shine. to be blunt, where's the protein? where is any good approach to this problem that does not derive from 8+8? and where is any progress on 8+8 that has not been stiffled by a middle-school clique approach to working on it (thanks, ran)? randy From owner-multi6@ops.ietf.org Tue Mar 11 12:05:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28003 for ; Tue, 11 Mar 2003 12:05:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18snD1-000Egw-00 for multi6-data@psg.com; Tue, 11 Mar 2003 09:06:35 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 18snCv-000Eex-00; Tue, 11 Mar 2003 09:06:30 -0800 From: Masataka Ohta Message-Id: <200303111655.BAA11820@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id BAA11820; Wed, 12 Mar 2003 01:55:08 +0900 Subject: Re: Again no multi6 at IETF#56 In-Reply-To: from Randy Bush at "Mar 11, 2003 11:23:09 am" To: Randy Bush Date: Wed, 12 Mar 2003 01:55:07 +0859 () CC: RJ Atkinson , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=0.1 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,SPAM_PHRASE_02_03 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Randy; > to be blunt, where's the protein? I'm glad to know that you asked for not a requirement draft but the protein. Masataka Ohta From owner-multi6@ops.ietf.org Tue Mar 11 12:15:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28453 for ; Tue, 11 Mar 2003 12:15:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18snNL-000FDZ-00 for multi6-data@psg.com; Tue, 11 Mar 2003 09:17:15 -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 #1) id 18snNI-000FDC-00 for multi6@ops.ietf.org; Tue, 11 Mar 2003 09:17:13 -0800 Subject: RE: Again no multi6 at IETF#56 Date: Tue, 11 Mar 2003 09:17:12 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <963621801C6D3E4A9CF454A1972AE8F50454C0@server2000.arneill-py.sacramento.ca.us> Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Thread-Topic: Again no multi6 at IETF#56 Thread-Index: AcLn8cQ68jMKiVKBQUqj7QK0HYTtxgAAB3SQ From: "Michel Py" To: "Masataka Ohta" , "Randy Bush" Cc: "RJ Atkinson" , 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 MAA28453 >> Randy Bush wrote: >> to be blunt, where's the protein? > Masataka Ohta wrote: > I'm glad to know that you asked for not a > requirement draft but the protein. Me too. Middle schoolers need proteins. Michel. From owner-multi6@ops.ietf.org Tue Mar 11 12:46:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29414 for ; Tue, 11 Mar 2003 12:46:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18snrK-000Gp4-00 for multi6-data@psg.com; Tue, 11 Mar 2003 09:48:14 -0800 Received: from gnat.inet.org ([63.108.254.91]) by psg.com with esmtp (Exim 3.36 #1) id 18snrH-000Gn8-00 for multi6@ops.ietf.org; Tue, 11 Mar 2003 09:48:11 -0800 Received: from extremenetworks.com (unknown [10.18.3.101]) by gnat.inet.org (Postfix) with ESMTP id 1412A67103; Tue, 11 Mar 2003 13:04:16 -0500 (EST) Date: Tue, 11 Mar 2003 12:48:11 -0500 Subject: Re: Again no multi6 at IETF#56 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: multi6@ops.ietf.org To: Randy Bush From: RJ Atkinson In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.9 required=5.0 tests=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 Tuesday, Mar 11, 2003, at 11:23 America/Montreal, Randy Bush wrote: > i am impressed by your approach to technology and engineering. welcome > to the new ietf where we care more about process and politics than > protocol > and product. sheesh! Kindly check in the mirror. It is the IESG members who have turned the IETF into a world where "process and politics" matter. And one of the chairs of this WG is in fact an active IESG member, in addition to being co-chair, though he is not the AD for this area. > to be blunt, where's the protein? There is a requirements I-D. Several folks here would like to discuss that I-D in-person in order to try to work through the details needed to advance that to RFC. Said activity is listed in the WG Charter that was approved by the IESG. > where is any good approach to this problem that does not derive from > 8+8? > and where is any progress on 8+8 that has not been stiffled by a > middle-school > clique approach to working on it (thanks, ran)? I'm not aware of anyone doing any collaborative work on 8+8 outside of this list. And I haven't been aware of any such work since the IRTF NSRG disbanded. Maybe I'm missing some other data ? Or were you suggesting that discussing topics that are in-charter for an IRTF RG inside that IRTF RG is "a middle-school clique approach" ? Oh, I forgot, the IESG gets spun up about the IRTF because the IESG don't control the IRTF. My mistake. My apologies for forgetting that being on the IESG is all about top-down control these days. If the AD or the WG Co-Chairs want to provide guidance, that would be really helpful. Blocking WG meetings to discuss topics clearly in-charter without providing such guidance (what is happening in this WG) is not terribly helpful, IMHO. Would you rather take pot shots or provide some help to the WG ? If the former, it would be more intellectually honest to just shutdown the WG than to play the political game of blocking in-person meetings. Ran From owner-multi6@ops.ietf.org Tue Mar 11 13:07:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29986 for ; Tue, 11 Mar 2003 13:07:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18soAt-000Hz3-00 for multi6-data@psg.com; Tue, 11 Mar 2003 10:08:27 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18soAq-000Hyh-00; Tue, 11 Mar 2003 10:08:24 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2BI7SD70330; Tue, 11 Mar 2003 19:07:28 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Tue, 11 Mar 2003 19:07:28 +0100 (CET) From: Iljitsch van Beijnum To: Randy Bush cc: RJ Atkinson , Subject: Re: Again no multi6 at IETF#56 In-Reply-To: Message-ID: <20030311184043.A69506-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 Tue, 11 Mar 2003, Randy Bush wrote: > > I'm not *recommending* this, but any action/inaction on the part of the > > IESG, including the ADs for this WG, is appealable provided that one > > follows the formal appeals process. > i am impressed by your approach to technology and engineering. welcome > to the new ietf where we care more about process and politics than protocol > and product. sheesh! Is it just me or did we have a discussion or two about protocols? (Not sure what "product" in this context would be.) > quite an assertion. can you point to the request sent to agenda@ietf.org > to hold a meeting? if not, ... where the sun don't shine. I clearly remember asking the chairs to schedule a meeting for Atlanta. > to be blunt, where's the protein? where is any good approach to this > problem that does not derive from 8+8? There are plenty of proposals and some drafts. Their good- and derivativeness would be good subjects for discussion, I think. Also, AFAIK everyone who attended found the unofficial meetings in Atlanta useful. From owner-multi6@ops.ietf.org Tue Mar 11 13:14:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00248 for ; Tue, 11 Mar 2003 13:14:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18soId-000IT7-00 for multi6-data@psg.com; Tue, 11 Mar 2003 10:16:27 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 18soIa-000ISc-00; Tue, 11 Mar 2003 10:16:24 -0800 From: Masataka Ohta Message-Id: <200303111812.DAA12467@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id DAA12467; Wed, 12 Mar 2003 03:11:54 +0859 Subject: Re: Again no multi6 at IETF#56 In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F50454C0@server2000.arneill-py.sacramento.ca.us> from Michel Py at "Mar 11, 2003 09:17:12 am" To: Michel Py Date: Wed, 12 Mar 2003 03:11:53 +0859 () CC: Randy Bush , RJ Atkinson , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=0.1 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,SPAM_PHRASE_02_03 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk > >> Randy Bush wrote: > >> to be blunt, where's the protein? > > > Masataka Ohta wrote: > > I'm glad to know that you asked for not a > > requirement draft but the protein. > > Me too. Middle schoolers need proteins. Can we meet at: Transitions Planning BOF (6bonebof) Tuesday, March 18 at 1700-1800 and state an opinion that 6bone address management responsibilities should be transferred to RIRs only after multihoming issues are solved? It seems to be that it is a (perhaps the only) rough consensus of multi6. Or, does so many of us think v6 addresses may be widely assigned without multihoming issues solved? Masataka Ohta From owner-multi6@ops.ietf.org Tue Mar 11 13:35:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01002 for ; Tue, 11 Mar 2003 13:35:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18socd-000Jft-00 for multi6-data@psg.com; Tue, 11 Mar 2003 10:37:07 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18soca-000Jfg-00 for multi6@ops.ietf.org; Tue, 11 Mar 2003 10:37:04 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2BIa8170404 for ; Tue, 11 Mar 2003 19:36:08 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Tue, 11 Mar 2003 19:36:08 +0100 (CET) From: Iljitsch van Beijnum To: Subject: Move forward Message-ID: <20030311190933.T69506-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Let me offer an opinion on how we can move forward. As I see it, there are basically four classess of IPv6 multihoming solutions that have any promise: 1. "No changes" routing-based approaches, ranging from simple (ignore the scalability problem for now) to complex (geo aggregation). 2. Weak identifier/locator separation: the identifier is an address usable for routing that is replaced/hidden in transit in some way, typically by a router or middlebox (MHAP, but also tunneling/redirection mechanisms) 3. Strong identifier/locator separation: the identifer isn't an address usable for routing, so the end host must implement the solution (basic multiaddressing as we know it today, SCTP, HIP) 4. Mobility-based approaches (although this could be classified under 2.) If we can make an upgrade path from type 1 solutions to type 2 solutions and from type 2 solutions to type 3 solutions, this will greatly enhance the prospects of each. Also, it should be much, much easier to draw up good requirements for each type of solution rather than the generic "we want it all but it can't cost anything" type of requirements we have now. With those requirements in hand we can apply the "people who say something can't be done shouldn't get in the way of the people doing it" rule. From owner-multi6@ops.ietf.org Tue Mar 11 13:41:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01317 for ; Tue, 11 Mar 2003 13:41:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18soil-000Jyy-00 for multi6-data@psg.com; Tue, 11 Mar 2003 10:43:27 -0800 Received: from mailout.zma.compaq.com ([161.114.64.105] helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18soih-000Jyj-00 for multi6@ops.ietf.org; Tue, 11 Mar 2003 10:43:23 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id E88158228; Tue, 11 Mar 2003 13:43:22 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 11 Mar 2003 13:43:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Again no multi6 at IETF#56 Date: Tue, 11 Mar 2003 13:43:20 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0324100F@tayexc13.americas.cpqcorp.net> Thread-Topic: Again no multi6 at IETF#56 Thread-Index: AcLn/CvRlJjtHzv8RHiH0i5xidk/mwAAFfDA From: "Bound, Jim" To: "Masataka Ohta" , "Michel Py" Cc: "Randy Bush" , "RJ Atkinson" , X-OriginalArrivalTime: 11 Mar 2003 18:43:22.0875 (UTC) FILETIME=[17EA84B0:01C2E7FE] X-Spam-Status: No, hits=0.0 required=5.0 tests=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 NAA01317 They are already being assigned and used folks. Now not just by Asia and European ISPs, but U.S. ISPs and IXs too. It has begun!! Within private enterprise preparation and IT test beds are running and learning to cope with the new route-exchange TLA rules. Appears RFC 3178 will be used to develop SLAs as temporary fix till this work is done here or outside of the IETF. Taking what IPv6 is today and working it is the only course I think for time-to-market of this spec in or out of the IETF. I also believe Ran has asked some very valid questions that should be answered. See: http://www.6bone.net/ and then http://www.ripe.net/ripencc/mem-services/registration/ipv6/ipv6allocs.ht ml Regards, /jim > -----Original Message----- > From: Masataka Ohta [mailto:mohta@necom830.hpcl.titech.ac.jp] > Sent: Tuesday, March 11, 2003 1:13 PM > To: Michel Py > Cc: Randy Bush; RJ Atkinson; multi6@ops.ietf.org > Subject: Re: Again no multi6 at IETF#56 > > > > >> Randy Bush wrote: > > >> to be blunt, where's the protein? > > > > > Masataka Ohta wrote: > > > I'm glad to know that you asked for not a > > > requirement draft but the protein. > > > > Me too. Middle schoolers need proteins. > > Can we meet at: > > Transitions Planning BOF (6bonebof) > > Tuesday, March 18 at 1700-1800 > > and state an opinion that 6bone address management > responsibilities should be transferred to RIRs only after > multihoming issues are solved? > > It seems to be that it is a (perhaps the only) rough > consensus of multi6. > > Or, does so many of us think v6 addresses may be widely > assigned without multihoming issues solved? > > Masataka Ohta > > From owner-multi6@ops.ietf.org Tue Mar 11 13:56:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02479 for ; Tue, 11 Mar 2003 13:56:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sowq-000KrE-00 for multi6-data@psg.com; Tue, 11 Mar 2003 10:58:00 -0800 Received: from dhcp1.kurtis.pp.se ([195.43.225.70] helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18sowl-000Kqd-00 for multi6@ops.ietf.org; Tue, 11 Mar 2003 10:57:56 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2BIxDKW000636; Tue, 11 Mar 2003 19:59:14 +0100 (CET) Date: Tue, 11 Mar 2003 19:59:13 +0100 Subject: Re: Move forward Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: <20030311190933.T69506-100000@sequoia.muada.com> Message-Id: <8C931BE5-53F3-11D7-BAEF-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) 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 > As I see it, there are basically four classess of IPv6 multihoming > solutions that have any promise: > > 1. "No changes" routing-based approaches, ranging from simple (ignore > the scalability problem for now) to complex (geo aggregation). > > 2. Weak identifier/locator separation: the identifier is an address > usable for routing that is replaced/hidden in transit in some way, > typically by a router or middlebox (MHAP, but also > tunneling/redirection mechanisms) > > 3. Strong identifier/locator separation: the identifer isn't an address > usable for routing, so the end host must implement the solution > (basic multiaddressing as we know it today, SCTP, HIP) > > 4. Mobility-based approaches (although this could be classified under > 2.) > > If we can make an upgrade path from type 1 solutions to type 2 > solutions and from type 2 solutions to type 3 solutions, this will I think this is a very good approach and also what I tried to start doing with the road-map, except that I tried to group all solutions, and only noted the need to create a path forward. Do you think it would be useful to extend this document with this (or create a new one?). I don't mind changing the classes if we can consensus on a common grouping of approaches? > greatly enhance the prospects of each. Also, it should be much, much > easier to draw up good requirements for each type of solution rather > than the generic "we want it all but it can't cost anything" type of > requirements we have now. > > With those requirements in hand we can apply the "people who say > something can't be done shouldn't get in the way of the people doing > it" > rule. > Well said. - kurtis - From owner-multi6@ops.ietf.org Tue Mar 11 13:56:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02555 for ; Tue, 11 Mar 2003 13:56:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18soxY-000Kv4-00 for multi6-data@psg.com; Tue, 11 Mar 2003 10:58:44 -0800 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by psg.com with esmtp (Exim 3.36 #1) id 18soxT-000Kuo-00 for multi6@ops.ietf.org; Tue, 11 Mar 2003 10:58:40 -0800 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id SAA29321 for ; Tue, 11 Mar 2003 18:58:33 GMT Received: from login.ecs.soton.ac.uk (login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id SAA08672 for ; Tue, 11 Mar 2003 18:58:33 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h2BIwXC29174 for multi6@ops.ietf.org; Tue, 11 Mar 2003 18:58:33 GMT Date: Tue, 11 Mar 2003 18:58:33 +0000 From: Tim Chown To: multi6@ops.ietf.org Subject: Re: Again no multi6 at IETF#56 Message-ID: <20030311185833.GB29126@login.ecs.soton.ac.uk> Mail-Followup-To: multi6@ops.ietf.org References: <20030311184043.A69506-100000@sequoia.muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030311184043.A69506-100000@sequoia.muada.com> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-3.0 required=5.0 tests=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 Tue, Mar 11, 2003 at 07:07:28PM +0100, Iljitsch van Beijnum wrote: > > There are plenty of proposals and some drafts. Their good- and > derivativeness would be good subjects for discussion, I think. Also, > AFAIK everyone who attended found the unofficial meetings in Atlanta > useful. Absolutely. Hence the question as to why the brainstorming can't be taken officially on board. I find it both baffling and frustrating that we've gone two meetings without a multi6 session for what some people argue is "the last missing piece of the IPv6 jigsaw". Could we at least not get a BoF session scheduled, at least something on the official agenda, maybe nearer the end so ipv6mh input from their meetings can be tabled. Tim From owner-multi6@ops.ietf.org Tue Mar 11 13:56:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02581 for ; Tue, 11 Mar 2003 13:56:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18soxg-000Kvj-00 for multi6-data@psg.com; Tue, 11 Mar 2003 10:58:52 -0800 Received: from dhcp1.kurtis.pp.se ([195.43.225.70] helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18soxZ-000Kuz-00; Tue, 11 Mar 2003 10:58:45 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2BIxrKW000639; Tue, 11 Mar 2003 19:59:53 +0100 (CET) Date: Tue, 11 Mar 2003 19:59:52 +0100 Subject: Re: Again no multi6 at IETF#56 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Michel Py , Randy Bush , RJ Atkinson , multi6@ops.ietf.org To: Masataka Ohta From: Kurt Erik Lindqvist In-Reply-To: <200303111812.DAA12467@necom830.hpcl.titech.ac.jp> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) 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 > Can we meet at: > > Transitions Planning BOF (6bonebof) > > Tuesday, March 18 at 1700-1800 > > and state an opinion that 6bone address management responsibilities > should be transferred to RIRs only after multihoming issues are solved? > > It seems to be that it is a (perhaps the only) rough consensus of > multi6. > > Or, does so many of us think v6 addresses may be widely assigned > without multihoming issues solved? I am not following your reasoning. I don't see why we should not move address management to where it belongs, and what that have to do with the multi6 issue? - kurtis - From owner-multi6@ops.ietf.org Tue Mar 11 14:23:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05728 for ; Tue, 11 Mar 2003 14:23:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18spM9-000MP2-00 for multi6-data@psg.com; Tue, 11 Mar 2003 11:24:09 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18spM7-000MOo-00 for multi6@ops.ietf.org; Tue, 11 Mar 2003 11:24:07 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2BJN7p70534; Tue, 11 Mar 2003 20:23:07 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Tue, 11 Mar 2003 20:23:07 +0100 (CET) From: Iljitsch van Beijnum To: Kurt Erik Lindqvist cc: Subject: Re: Move forward In-Reply-To: <8C931BE5-53F3-11D7-BAEF-000393AB1404@kurtis.pp.se> Message-ID: <20030311200840.K69506-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 Tue, 11 Mar 2003, Kurt Erik Lindqvist wrote: > I think this is a very good approach and also what I tried to start > doing with the road-map, except that I tried to group all solutions, > and only noted the need to create a path forward. Do you think it would > be useful to extend this document with this (or create a new one?). I > don't mind changing the classes if we can consensus on a common > grouping of approaches? I think this way of classifying solutions can be very useful when trying to come up with requirements or creating desing teams. However, in a document that introduces someone to the subject this grouping may seem arbitrary. From owner-multi6@ops.ietf.org Tue Mar 11 18:06:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16795 for ; Tue, 11 Mar 2003 18:06:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sspd-0008n8-00 for multi6-data@psg.com; Tue, 11 Mar 2003 15:06:49 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 18sspZ-0008mj-00; Tue, 11 Mar 2003 15:06:46 -0800 From: Masataka Ohta Message-Id: <200303112253.HAA13876@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id HAA13876; Wed, 12 Mar 2003 07:53:24 +0900 Subject: Re: Again no multi6 at IETF#56 In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B0324100F@tayexc13.americas.cpqcorp.net> from "Bound, Jim" at "Mar 11, 2003 01:43:20 pm" To: "Bound, Jim" Date: Wed, 12 Mar 2003 07:53:23 +0859 () CC: Michel Py , Randy Bush , RJ Atkinson , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-0.7 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Jim; > They are already being assigned and used folks. Now not just by Asia > and European ISPs, but U.S. ISPs and IXs too. It has begun!! I'm afraid you have been saying "It has begu!!" for these eight years that we should assume that it won't begin for next eight years. Thank you. > Taking what IPv6 is today and working it is the > only course I think for time-to-market of this spec in or out of the Taking what IPv6 has been for these eight years and? Masataka Ohta From owner-multi6@ops.ietf.org Tue Mar 11 18:08:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16974 for ; Tue, 11 Mar 2003 18:08:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sssw-0008yh-00 for multi6-data@psg.com; Tue, 11 Mar 2003 15:10:14 -0800 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by psg.com with esmtp (Exim 3.36 #1) id 18ssse-0008xa-00 for multi6@ops.ietf.org; Tue, 11 Mar 2003 15:09:57 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 6811BB70; Tue, 11 Mar 2003 18:09:54 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 11 Mar 2003 18:09:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Again no multi6 at IETF#56 Date: Tue, 11 Mar 2003 18:09:53 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCB8B@tayexc13.americas.cpqcorp.net> Thread-Topic: Again no multi6 at IETF#56 Thread-Index: AcLoIuMkeG0VeRlgRQWxbX2pXgLWSQAAF9xQ From: "Bound, Jim" To: "Masataka Ohta" Cc: "Michel Py" , "Randy Bush" , "RJ Atkinson" , X-OriginalArrivalTime: 11 Mar 2003 23:09:54.0377 (UTC) FILETIME=[53981390:01C2E823] 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 SAA16974 See the URLs. Thank You, /jim > -----Original Message----- > From: Masataka Ohta [mailto:mohta@necom830.hpcl.titech.ac.jp] > Sent: Tuesday, March 11, 2003 5:54 PM > To: Bound, Jim > Cc: Michel Py; Randy Bush; RJ Atkinson; multi6@ops.ietf.org > Subject: Re: Again no multi6 at IETF#56 > > > Jim; > > > They are already being assigned and used folks. Now not > just by Asia > > and European ISPs, but U.S. ISPs and IXs too. It has begun!! > > I'm afraid you have been saying "It has begu!!" for these > eight years that we should assume that it won't begin for > next eight years. > > Thank you. > > > Taking what IPv6 is today and working it is the > > only course I think for time-to-market of this spec in or out of the > > Taking what IPv6 has been for these eight years and? > > Masataka Ohta > From owner-multi6@ops.ietf.org Tue Mar 11 18:14:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17772 for ; Tue, 11 Mar 2003 18:14:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ssyw-0009Pf-00 for multi6-data@psg.com; Tue, 11 Mar 2003 15:16:26 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 18ssyt-0009PT-00 for multi6@ops.ietf.org; Tue, 11 Mar 2003 15:16:24 -0800 From: Masataka Ohta Message-Id: <200303112311.IAA13953@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id IAA13953; Wed, 12 Mar 2003 08:11:02 +0900 Subject: Re: Move forward In-Reply-To: <20030311190933.T69506-100000@sequoia.muada.com> from Iljitsch van Beijnum at "Mar 11, 2003 07:36:08 pm" To: Iljitsch van Beijnum Date: Wed, 12 Mar 2003 08:11:02 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-0.7 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Iljitsch; > If we can make an upgrade path from type 1 solutions to type 2 > solutions and from type 2 solutions to type 3 solutions, this will > greatly enhance the prospects of each. No. > 1. "No changes" routing-based approaches, ranging from simple (ignore > the scalability problem for now) to complex (geo aggregation). > > 2. Weak identifier/locator separation: the identifier is an address > usable for routing that is replaced/hidden in transit in some way, > typically by a router or middlebox (MHAP, but also > tunneling/redirection mechanisms) The proble is that there is no such solutions. If you disagree, feel free to use type 1 and 2 solutions with IPv4. > 3. Strong identifier/locator separation: the identifer isn't an address > usable for routing, so the end host must implement the solution > (basic multiaddressing as we know it today, SCTP, HIP) Here is the point where the merit of having longer address could be deployed. A point of multi6 is that we can do it from the beginning. > With those requirements in hand we can apply the "people who say > something can't be done shouldn't get in the way of the people doing it" > rule. You are getting in the way of the people doing type 2 and 3 insisting that there should be upgrade path from type 1 and 2. Masataka Ohta From owner-multi6@ops.ietf.org Tue Mar 11 18:51:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19275 for ; Tue, 11 Mar 2003 18:51:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18stYW-000BXI-00 for multi6-data@psg.com; Tue, 11 Mar 2003 15:53:12 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18stYT-000BX3-00 for multi6@ops.ietf.org; Tue, 11 Mar 2003 15:53:09 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2BNq9x70924; Wed, 12 Mar 2003 00:52:09 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Wed, 12 Mar 2003 00:52:08 +0100 (CET) From: Iljitsch van Beijnum To: Masataka Ohta cc: Subject: Re: Move forward In-Reply-To: <200303112311.IAA13953@necom830.hpcl.titech.ac.jp> Message-ID: <20030312002836.J69506-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, 12 Mar 2003, Masataka Ohta wrote: > > If we can make an upgrade path from type 1 solutions to type 2 > > solutions and from type 2 solutions to type 3 solutions, this will > > greatly enhance the prospects of each. > No. If we want to do something with PI in type 1, that's going to be hard because it doesn't scale well enough in the long run. If we want to do 2 at all there's the problem that everyone has to implement it before it works. However, if we first do 1 and then 2 people who want 2 will use 1 as long as 2 isn't available yet (so more use for 1) and people don't have to be afraid 1 will blow up in their faces because they're migrating to 2 later. So both are more viable. > > 1. "No changes" routing-based approaches, ranging from simple (ignore > > the scalability problem for now) to complex (geo aggregation). > > 2. Weak identifier/locator separation: the identifier is an address > > usable for routing that is replaced/hidden in transit in some way, > > typically by a router or middlebox (MHAP, but also > > tunneling/redirection mechanisms) > The proble is that there is no such solutions. There are drafts. Don't know if they solve anything... But the point is that we work on it. It seems likely that any existing draft or proposal can be improved upon if we work together. You wouldn't know it, but there are actually some very smart people in multi6. :-) > If you disagree, feel free to use type 1 and 2 solutions with IPv4. GFN isn't going to work to any usable degree with IPv4 because there simply aren't enough bits. There are many other type 1-like solutions in actual use in v4, though. Type 2 could work well if you don't mind burning two or three times as many addresses. > > 3. Strong identifier/locator separation: the identifer isn't an address > > usable for routing, so the end host must implement the solution > > (basic multiaddressing as we know it today, SCTP, HIP) > Here is the point where the merit of having longer address could be > deployed. Actually this type of solution doesn't really need the bigger addresses. I would even like to have type 3 run over both v4 and v6. > > With those requirements in hand we can apply the "people who say > > something can't be done shouldn't get in the way of the people doing it" > > rule. > You are getting in the way of the people doing type 2 and 3 insisting > that there should be upgrade path from type 1 and 2. Since anything that can be done in a middlebox can also be done in a host, the upgrade path from 2 to 3 shouldn't limit 2 too much. Essentially, 2 is a subset of 3. As for 1 to 2: I think the burden should be mostly on 1 there. More concrete: I want to use PI addresses in a type 1 solution that become the identifiers in a type 2 solution. A type 2 solution could also use PA addresses but that would be stupid as PI is much better for the user and there aren't many down sides to using PI in type 2. There are in type 1 so we should see if we can afford it there. From owner-multi6@ops.ietf.org Tue Mar 11 19:15:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20015 for ; Tue, 11 Mar 2003 19:15:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18stvR-000Cuy-00 for multi6-data@psg.com; Tue, 11 Mar 2003 16:16:53 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 18stvI-000CuZ-00; Tue, 11 Mar 2003 16:16:44 -0800 From: Masataka Ohta Message-Id: <200303120008.JAA14599@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id JAA14599; Wed, 12 Mar 2003 09:08:13 +0900 Subject: Re: Again no multi6 at IETF#56 In-Reply-To: from Kurt Erik Lindqvist at "Mar 11, 2003 07:59:52 pm" To: Kurt Erik Lindqvist Date: Wed, 12 Mar 2003 09:08:13 +0859 () CC: Michel Py , Randy Bush , RJ Atkinson , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-0.7 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Kurt; > > Transitions Planning BOF (6bonebof) > > > > Tuesday, March 18 at 1700-1800 > > > > and state an opinion that 6bone address management responsibilities > > should be transferred to RIRs only after multihoming issues are solved? > > > > It seems to be that it is a (perhaps the only) rough consensus of > > multi6. > > > > Or, does so many of us think v6 addresses may be widely assigned > > without multihoming issues solved? > > I am not following your reasoning. I don't see why we should not move > address management to where it belongs, and what that have to do with > the multi6 issue? Huh? Are you saying it already belongs to where it belongs that there should be no BoF? Masataka Ohta From owner-multi6@ops.ietf.org Tue Mar 11 19:34:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20656 for ; Tue, 11 Mar 2003 19:34:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18suEO-000E5j-00 for multi6-data@psg.com; Tue, 11 Mar 2003 16:36:28 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 18suEL-000E5T-00 for multi6@ops.ietf.org; Tue, 11 Mar 2003 16:36:25 -0800 From: Masataka Ohta Message-Id: <200303120031.JAA14713@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id JAA14713; Wed, 12 Mar 2003 09:31:15 +0900 Subject: Re: Move forward In-Reply-To: <20030312002836.J69506-100000@sequoia.muada.com> from Iljitsch van Beijnum at "Mar 12, 2003 00:52:08 am" To: Iljitsch van Beijnum Date: Wed, 12 Mar 2003 09:31:14 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-1.0 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Iljitsch; > Essentially, 2 is a subset of 3. You are saying your classification is meaningless. We can move forward a little if you admit that, by definition, weak separation is not a subset of strong separation. The hard part, then, is to define what are "weak" and "strong". > If we want to do 2 > at all there's the problem that everyone has to implement it before it > works. Remember that my 8+8 with doubtlessly-strong separation is interoperating with leagacy IPv6 stack that it can be deployed gradually. That is, we can move forward without wasting time to define what is "weak". The problem of deploying type 1 is that it will bloat global routing table unnecessarily, which can not be restored later. Note that, in an RIR, some says routing table must grow unmanageably large. > > The proble is that there is no such solutions. > > There are drafts. Don't know if they solve anything... > > But the point is that we work on it. We should "move forward", not "work on moving backward". Masataka Ohta From owner-multi6@ops.ietf.org Tue Mar 11 21:31:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23496 for ; Tue, 11 Mar 2003 21:31:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18sw1h-000KU7-00 for multi6-data@psg.com; Tue, 11 Mar 2003 18:31:29 -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 #1) id 18sw1c-000KTt-00 for multi6@ops.ietf.org; Tue, 11 Mar 2003 18:31:24 -0800 Subject: RE: Again no multi6 at IETF#56 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 11 Mar 2003 18:31:24 -0800 Message-ID: <963621801C6D3E4A9CF454A1972AE8F54CA0@server2000.arneill-py.sacramento.ca.us> Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Thread-Topic: Again no multi6 at IETF#56 Thread-Index: AcLoAO4T+vN477QWQS2E4C40T8GGxQAPdTGw From: "Michel Py" To: "Tim Chown" , 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 VAA23496 Tim, > Tim Chown wrote: > Could we at least not get a BoF session scheduled In which area? Did you find an AD to go for a BOF that would obviously conflict with multi6? Having a meeting for the purpose of having a meeting does not do any good to anybody. Little reminder for those that were not present: The last multi6 meeting happened in Salt Lake in 2001, at my request. After 15 or 20 minutes out of the 1-hour window the meeting was over and nothing was done, which has not changed since. I do not see the point of having another SLC-like meeting, flat out a waste of time. Michel. From owner-multi6@ops.ietf.org Wed Mar 12 02:11:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09703 for ; Wed, 12 Mar 2003 02:11:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18t0PI-0002Ys-00 for multi6-data@psg.com; Tue, 11 Mar 2003 23:12:08 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18t0PG-0002Yf-00; Tue, 11 Mar 2003 23:12:06 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2C7Bot10827; Wed, 12 Mar 2003 09:11:50 +0200 Date: Wed, 12 Mar 2003 09:11:50 +0200 (EET) From: Pekka Savola To: Masataka Ohta cc: Michel Py , Randy Bush , RJ Atkinson , Subject: multihoming issues [Re: Again no multi6 at IETF#56] In-Reply-To: <200303111812.DAA12467@necom830.hpcl.titech.ac.jp> 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 Wed, 12 Mar 2003, Masataka Ohta wrote: > Or, does so many of us think v6 addresses may be widely assigned > without multihoming issues solved? Certainly. Quit the excuses already. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Wed Mar 12 02:18:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12926 for ; Wed, 12 Mar 2003 02:18:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18t0XI-0002r3-00 for multi6-data@psg.com; Tue, 11 Mar 2003 23:20:24 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18t0XE-0002pi-00 for multi6@ops.ietf.org; Tue, 11 Mar 2003 23:20:20 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2C7JgA10850; Wed, 12 Mar 2003 09:19:42 +0200 Date: Wed, 12 Mar 2003 09:19:42 +0200 (EET) From: Pekka Savola To: Michel Py cc: Tim Chown , Subject: multi6 wg [RE: Again no multi6 at IETF#56] In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F54CA0@server2000.arneill-py.sacramento.ca.us> 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, 11 Mar 2003, Michel Py wrote: > > Tim Chown wrote: > > Could we at least not get a BoF session scheduled > > In which area? Did you find an AD to go for a BOF that would obviously > conflict with multi6? Having a meeting for the purpose of having a > meeting does not do any good to anybody. You can forget about a BoF IMO. If multi6 is not good, it could be disbanded and new one created, or.. > Little reminder for those that were not present: The last multi6 meeting > happened in Salt Lake in 2001, at my request. After 15 or 20 minutes out > of the 1-hour window the meeting was over and nothing was done, which > has not changed since. .. we could, for example: - change the management [ie. chair(s)], or - change the w.g. members [ie. mostly ignore input from some members], or - settle the worst past grievances and grow up > I do not see the point of having another SLC-like > meeting, flat out a waste of time. In my agenda, 20 minutes out of an IETF meeting is probably not waste of time, no matter how I look at it. Of course, if one only is interested in multi6, that may be a problem, but then again I'd be questioning the participation in the IETF anyway. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Wed Mar 12 02:22:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16593 for ; Wed, 12 Mar 2003 02:22:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18t0bG-0002zl-00 for multi6-data@psg.com; Tue, 11 Mar 2003 23:24:30 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18t0bD-0002zU-00 for multi6@ops.ietf.org; Tue, 11 Mar 2003 23:24:28 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2C7OOn10897; Wed, 12 Mar 2003 09:24:24 +0200 Date: Wed, 12 Mar 2003 09:24:24 +0200 (EET) From: Pekka Savola To: Iljitsch van Beijnum cc: multi6@ops.ietf.org Subject: Re: Move forward In-Reply-To: <20030311190933.T69506-100000@sequoia.muada.com> 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, 11 Mar 2003, Iljitsch van Beijnum wrote: > 1. "No changes" routing-based approaches, ranging from simple (ignore > the scalability problem for now) to complex (geo aggregation). > > 2. Weak identifier/locator separation: the identifier is an address > usable for routing that is replaced/hidden in transit in some way, > typically by a router or middlebox (MHAP, but also > tunneling/redirection mechanisms) > > 3. Strong identifier/locator separation: the identifer isn't an address > usable for routing, so the end host must implement the solution > (basic multiaddressing as we know it today, SCTP, HIP) > > 4. Mobility-based approaches (although this could be classified under 2.) This is ignoring the short-term solutions with multiple addresses. I'm not sure what you refer to with mobility based approaches. It seems to me that such do not exist (which would help with multihoming, that is). I'll be probably submitting a draft on my "big picture" in April or so. At the moment it looks like we don't have all that much work to do in the short term.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Wed Mar 12 04:14:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26870 for ; Wed, 12 Mar 2003 04:14:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18t2Km-0006NX-00 for multi6-data@psg.com; Wed, 12 Mar 2003 01:15:36 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18t2Ki-0006ND-00 for multi6@ops.ietf.org; Wed, 12 Mar 2003 01:15:33 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18t2I8-000DfP-00 for multi6@ops.ietf.org; Wed, 12 Mar 2003 01:12:52 -0800 Message-ID: <20030312090839.GA18652@login.ecs.soton.ac.uk> Mail-Followup-To: multi6@ops.ietf.org References: <963621801C6D3E4A9CF454A1972AE8F54CA0@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F54CA0@server2000.arneill-py.sacramento.ca.us> Date: Wed, 12 Mar 2003 09:08:39 +0000 From: Tim Chown To: multi6@ops.ietf.org Subject: Re: Again no multi6 at IETF#56 X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,RESENT_TO, SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Given the 6+ hours of ipv6mh sessions in Atlanta, I see no problem filling a 1 hour (or more) slot with multi6 discussion. There have been at least 1,000 posts to ipv6mh (and multi6) since Atlanta. So I would not be worried at all about running out of steam inside an hour :) Of course a productive meeting is another matter. That means we have to approve or ditch the requirements draft, approve a new charter, and get real progress moving... Tim On Tue, Mar 11, 2003 at 06:31:24PM -0800, Michel Py wrote: > Tim, > > > Tim Chown wrote: > > Could we at least not get a BoF session scheduled > > In which area? Did you find an AD to go for a BOF that would obviously > conflict with multi6? Having a meeting for the purpose of having a > meeting does not do any good to anybody. > > Little reminder for those that were not present: The last multi6 meeting > happened in Salt Lake in 2001, at my request. After 15 or 20 minutes out > of the 1-hour window the meeting was over and nothing was done, which > has not changed since. I do not see the point of having another SLC-like > meeting, flat out a waste of time. > > Michel. > From owner-multi6@ops.ietf.org Wed Mar 12 04:56:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27595 for ; Wed, 12 Mar 2003 04:56:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18t2ze-0007Xt-00 for multi6-data@psg.com; Wed, 12 Mar 2003 01:57:50 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18t2za-0007XZ-00 for multi6@ops.ietf.org; Wed, 12 Mar 2003 01:57:47 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2C9umm72096; Wed, 12 Mar 2003 10:56:48 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Wed, 12 Mar 2003 10:56:48 +0100 (CET) From: Iljitsch van Beijnum To: Masataka Ohta cc: Subject: Re: Move forward In-Reply-To: <200303120031.JAA14713@necom830.hpcl.titech.ac.jp> Message-ID: <20030312104531.W69506-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_03_05 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 12 Mar 2003, Masataka Ohta wrote: > > Essentially, 2 is a subset of 3. > You are saying your classification is meaningless. No, I'm pretty much sure you're saying this. But then I firmly believe that everything is meaningless except for the meaning we choose to bestow upon any particular thing. If you find my my classification meaningless that's ok, I'll use it as long as it suits my needs. > We can move forward a little if you admit that, by definition, > weak separation is not a subset of strong separation. > The hard part, then, is to define what are "weak" and "strong". Feel free to suggest better names for the classes. > > If we want to do 2 > > at all there's the problem that everyone has to implement it before it > > works. > Remember that my 8+8 with doubtlessly-strong separation is > interoperating with leagacy IPv6 stack that it can be deployed > gradually. ??? How? > The problem of deploying type 1 is that it will bloat global routing > table unnecessarily, which can not be restored later. My point is that this isn't necessarily the case: if we start giving out PI space that is simply allowed in the global routing table, we have bloat. But if at some point a type 2 solution becomes available, we can simply start moving in the middleboxes and after a suitable transition period the PI /48s can be removed from the global routing table because the middleboxes translate all the traffic. It should be possible to do this in a way that is transparent to end hosts. From owner-multi6@ops.ietf.org Wed Mar 12 05:00:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27717 for ; Wed, 12 Mar 2003 05:00:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18t34B-0007hk-00 for multi6-data@psg.com; Wed, 12 Mar 2003 02:02:31 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18t348-0007hW-00 for multi6@ops.ietf.org; Wed, 12 Mar 2003 02:02:29 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2CA1VA72109; Wed, 12 Mar 2003 11:01:32 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Wed, 12 Mar 2003 11:01:31 +0100 (CET) From: Iljitsch van Beijnum To: Pekka Savola cc: Subject: Re: Move forward In-Reply-To: Message-ID: <20030312105705.M69506-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, 12 Mar 2003, Pekka Savola wrote: > > 3. Strong identifier/locator separation: the identifer isn't an address > > usable for routing, so the end host must implement the solution > > (basic multiaddressing as we know it today, SCTP, HIP) > This is ignoring the short-term solutions with multiple addresses. No, these are type 3. Note that they fail to meet some basic multihoming requirements, though, so they shouldn't be considered viable solutions as-is, except for some specific application types such as the DNS. > I'm not sure what you refer to with mobility based approaches. It seems > to me that such do not exist (which would help with multihoming, that is). Agree. The overlap with mobility has been observed many times, but little progress so far in this area. > I'll be probably submitting a draft on my "big picture" in April or so. > At the moment it looks like we don't have all that much work to do in the > short term.. Obviously writing drafts hasn't helped to move things forward so far. So I want to build some proof of concept stuff. That's plenty of short term work. :-) From owner-multi6@ops.ietf.org Wed Mar 12 05:13:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27923 for ; Wed, 12 Mar 2003 05:13:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18t3Gf-00089G-00 for multi6-data@psg.com; Wed, 12 Mar 2003 02:15:25 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18t3Gc-00088G-00 for multi6@ops.ietf.org; Wed, 12 Mar 2003 02:15:22 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2CAFJk12143; Wed, 12 Mar 2003 12:15:19 +0200 Date: Wed, 12 Mar 2003 12:15:18 +0200 (EET) From: Pekka Savola To: Iljitsch van Beijnum cc: multi6@ops.ietf.org Subject: Re: Move forward In-Reply-To: <20030312105705.M69506-100000@sequoia.muada.com> 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 Wed, 12 Mar 2003, Iljitsch van Beijnum wrote: > > > 3. Strong identifier/locator separation: the identifer isn't an address > > > usable for routing, so the end host must implement the solution > > > (basic multiaddressing as we know it today, SCTP, HIP) > > > This is ignoring the short-term solutions with multiple addresses. > > No, these are type 3. Well, not by the classification: there is no strong identifier/locator separation in e.g. host-centric multihoming approach. > Note that they fail to meet some basic multihoming > requirements, though, so they shouldn't be considered viable solutions > as-is, except for some specific application types such as the DNS. Which realistic solutions _do_ meet those requirements? Right.. > > I'm not sure what you refer to with mobility based approaches. It seems > > to me that such do not exist (which would help with multihoming, that is). > > Agree. The overlap with mobility has been observed many times, but > little progress so far in this area. Mobility could be useful, IMO, if and only if you could secure a construct like Binding Update with like, IPsec. And this is a non-starter at the moment. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Wed Mar 12 05:30:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28159 for ; Wed, 12 Mar 2003 05:30:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18t3We-0008hH-00 for multi6-data@psg.com; Wed, 12 Mar 2003 02:31:56 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18t3Wb-0008gu-00 for multi6@ops.ietf.org; Wed, 12 Mar 2003 02:31:53 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2CAUjg72185; Wed, 12 Mar 2003 11:30:45 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Wed, 12 Mar 2003 11:30:45 +0100 (CET) From: Iljitsch van Beijnum To: Pekka Savola cc: Subject: Re: Move forward In-Reply-To: Message-ID: <20030312112237.D69506-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, 12 Mar 2003, Pekka Savola wrote: > > > > 3. Strong identifier/locator separation: the identifer isn't an address > > > > usable for routing, so the end host must implement the solution > > > > (basic multiaddressing as we know it today, SCTP, HIP) > > > This is ignoring the short-term solutions with multiple addresses. > > No, these are type 3. > Well, not by the classification: there is no strong identifier/locator > separation in e.g. host-centric multihoming approach. Well, let's not start a flame war over this. If we're going to have a few more classes then it would make sense to make this a separate class. But my reasoning is that those solutions really use an implicit locator/identifier separation: an email domain has several MXes. The email domain is the identifier, the MX addresses are the locators. SCTP doesn't even seem to use an identifier at all, so I guess the socket or control block is the identifier there. It's certainly not any of the individual addresses. And this must be done on the host so it's the "strong" variety. > > Note that they fail to meet some basic multihoming > > requirements, though, so they shouldn't be considered viable solutions > > as-is, except for some specific application types such as the DNS. > Which realistic solutions _do_ meet those requirements? > Right.. Address agile TCP, to name just one? > Mobility could be useful, IMO, if and only if you could secure a construct > like Binding Update with like, IPsec. And this is a non-starter at the > moment. IPsec isn't as evil as people think it is. I got it to work in a few hours. As long as we can have the IPsec just between the mobile host and the home agent this shouldn't really be a show stopper. From owner-multi6@ops.ietf.org Wed Mar 12 05:47:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28741 for ; Wed, 12 Mar 2003 05:47:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18t3nY-0009Ms-00 for multi6-data@psg.com; Wed, 12 Mar 2003 02:49:24 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18t3nL-0009M3-00 for multi6@ops.ietf.org; Wed, 12 Mar 2003 02:49:11 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2CAn7R12354; Wed, 12 Mar 2003 12:49:07 +0200 Date: Wed, 12 Mar 2003 12:49:07 +0200 (EET) From: Pekka Savola To: Iljitsch van Beijnum cc: multi6@ops.ietf.org Subject: Re: Move forward In-Reply-To: <20030312112237.D69506-100000@sequoia.muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 12 Mar 2003, Iljitsch van Beijnum wrote: > > Which realistic solutions _do_ meet those requirements? > > > Right.. > > Address agile TCP, to name just one? Some folks might not agree on its reality. Besides, how can you manage e.g. inbound loadbalancing/traffic engineering with that? I think that was one of those "we want everything" requirements. > > Mobility could be useful, IMO, if and only if you could secure a construct > > like Binding Update with like, IPsec. And this is a non-starter at the > > moment. > > IPsec isn't as evil as people think it is. I got it to work in a few > hours. As long as we can have the IPsec just between the mobile host and > the home agent this shouldn't really be a show stopper. No, this is not enough. Such a model just shifts the problem around so that we'd require "truly multihomed" home agents. IMO, that's not a solution. On the other hand, if global PKI existed and was usable, one could perform "homeless mobility". Node X with addresses X_1 and X_2 (from different ISP's) could just signal to the other endpoint that the sessions should continue using the other address. But this authentication is not possible today. In fact, if you take a few more steps in this direction, you'll stumble upon HIP. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Wed Mar 12 06:03:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29563 for ; Wed, 12 Mar 2003 06:03:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18t43D-000A7C-00 for multi6-data@psg.com; Wed, 12 Mar 2003 03:05:35 -0800 Received: from smtp01.uc3m.es ([163.117.136.121] helo=smtp.uc3m.es) by psg.com with esmtp (Exim 3.36 #1) id 18t437-000A6z-00 for multi6@ops.ietf.org; Wed, 12 Mar 2003 03:05:31 -0800 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 52AD34323D; Wed, 12 Mar 2003 12:05:28 +0100 (CET) Received: from it.uc3m.es (saltamontes.it.uc3m.es [163.117.140.51]) by smtp01.uc3m.es (Postfix) with ESMTP id BB14899E71; Wed, 12 Mar 2003 12:05:27 +0100 (CET) Message-ID: <3E6F1479.1030400@it.uc3m.es> Date: Wed, 12 Mar 2003 12:05:29 +0100 From: Marcelo Bagnulo User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.16 i686; en-US; 0.7) Gecko/20010316 X-Accept-Language: en MIME-Version: 1.0 To: Pekka Savola Cc: Iljitsch van Beijnum , multi6@ops.ietf.org Subject: Re: Move forward References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-3.7 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_01_02,USER_AGENT,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pekka, Iljitsch Pekka Savola wrote: > On Wed, 12 Mar 2003, Iljitsch van Beijnum wrote: > >>> Which realistic solutions _do_ meet those requirements? >> >>> Right.. >> >> Address agile TCP, to name just one? > > > Some folks might not agree on its reality. > > Besides, how can you manage e.g. inbound loadbalancing/traffic engineering > with that? I think that was one of those "we want everything" > requirements. > > >>> Mobility could be useful, IMO, if and only if you could secure a construct >>> like Binding Update with like, IPsec. And this is a non-starter at the >>> moment. >> >> IPsec isn't as evil as people think it is. I got it to work in a few >> hours. As long as we can have the IPsec just between the mobile host and >> the home agent this shouldn't really be a show stopper. > > > No, this is not enough. Such a model just shifts the problem around so > that we'd require "truly multihomed" home agents. IMO, that's not a > solution. We have tried to evaluate a concrete proposal for multi-homing using MIPv6 tools. The result can be found: http://www.ietf.org/internet-drafts/draft-bagnulo-multi6-mnm-00.txt We would really appreciate your comments, Thanks, marcelo > > On the other hand, if global PKI existed and was usable, one could perform > "homeless mobility". Node X with addresses X_1 and X_2 (from different > ISP's) could just signal to the other endpoint that the sessions should > continue using the other address. But this authentication is not possible > today. In fact, if you take a few more steps in this direction, you'll > stumble upon HIP. > From owner-multi6@ops.ietf.org Wed Mar 12 10:49:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08866 for ; Wed, 12 Mar 2003 10:49:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18t8Tv-000LMb-00 for multi6-data@psg.com; Wed, 12 Mar 2003 07:49:27 -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 #1) id 18t8Tr-000LMF-00 for multi6@ops.ietf.org; Wed, 12 Mar 2003 07:49:23 -0800 Subject: RE: Again no multi6 at IETF#56 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 12 Mar 2003 07:49:22 -0800 Message-ID: <963621801C6D3E4A9CF454A1972AE8F54CA2@server2000.arneill-py.sacramento.ca.us> Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Thread-Topic: Again no multi6 at IETF#56 Thread-Index: AcLoeLyFs0W954cJQsKHQjFDGolPCwANbAUw From: "Michel Py" To: "Tim Chown" , 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 KAA08866 > Tim Chown wrote: > Given the 6+ hours of ipv6mh sessions in Atlanta, I see > no problem filling a 1 hour (or more) slot with multi6 > discussion. There have been at least 1,000 posts to ipv6mh > (and multi6) since Atlanta. So I would not be worried > at all about running out of steam inside an hour :) > Of course a productive meeting is another matter. That > means we have to approve or ditch the requirements draft, > approve a new charter, and get real progress moving... Exactly, but what makes you think that there has been changes WRT to this? Michel. From owner-multi6@ops.ietf.org Wed Mar 12 12:36:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12545 for ; Wed, 12 Mar 2003 12:36:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tA9W-000Ond-00 for multi6-data@psg.com; Wed, 12 Mar 2003 09:36:30 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 18tA9S-000Oms-00 for multi6@ops.ietf.org; Wed, 12 Mar 2003 09:36:27 -0800 From: Masataka Ohta Message-Id: <200303121723.CAA18149@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id CAA18149; Thu, 13 Mar 2003 02:23:22 +0900 Subject: Re: Move forward In-Reply-To: <20030312104531.W69506-100000@sequoia.muada.com> from Iljitsch van Beijnum at "Mar 12, 2003 10:56:48 am" To: Iljitsch van Beijnum Date: Thu, 13 Mar 2003 02:23:21 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-0.7 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_02_03 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Iljitsch; > > > Essentially, 2 is a subset of 3. > > > You are saying your classification is meaningless. > > No, I'm pretty much sure you're saying this. But then I firmly believe > that everything is meaningless except for the meaning we choose to > bestow upon any particular thing. If you find my my classification > meaningless that's ok, I'll use it as long as it suits my needs. For a classification suits some need, classes of the classification, by definition, MUST be mutually disjoint. That is, your need is nonsense even in an abstract sense. > > We can move forward a little if you admit that, by definition, > > weak separation is not a subset of strong separation. > > > The hard part, then, is to define what are "weak" and "strong". > > Feel free to suggest better names for the classes. I suggested not to have the classes, which actually are not classes at all. > > > If we want to do 2 > > > at all there's the problem that everyone has to implement it before it > > > works. > > > Remember that my 8+8 with doubtlessly-strong separation is > > interoperating with leagacy IPv6 stack that it can be deployed > > gradually. > > ??? How? As I wrote to Brian, reserve some bit(s) to designate address families and use legacy upper layers unless both source and destination addresses are of the new ones. It is implemented and is interoperating with the legacy stack. > > The problem of deploying type 1 is that it will bloat global routing > > table unnecessarily, which can not be restored later. > > My point is that this isn't necessarily the case: if we start giving out > PI space that is simply allowed in the global routing table, we have > bloat. That is enough to argue against 6bonebof. > But if at some point a type 2 solution becomes available, we can > simply start moving in the middleboxes and after a suitable transition > period the PI /48s can be removed from the global routing table because > the middleboxes translate all the traffic. It should be possible to do > this in a way that is transparent to end hosts. If ever the type 1 is deployed to some extent, people using it won't accept any proposal which require them additionally purchase the middleboxes. Wheter it is transparent to end hosts or not is irrelevant. Proposals requiring middleboxes at some transition stage is definitely not deployable. Masataka Ohta From owner-multi6@ops.ietf.org Wed Mar 12 12:44:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13105 for ; Wed, 12 Mar 2003 12:44:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tAJL-000P6q-00 for multi6-data@psg.com; Wed, 12 Mar 2003 09:46:39 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 18tAJH-000P6S-00 for multi6@ops.ietf.org; Wed, 12 Mar 2003 09:46:36 -0800 From: Masataka Ohta Message-Id: <200303121738.CAA18244@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id CAA18244; Thu, 13 Mar 2003 02:37:48 +0859 Subject: Re: Move forward In-Reply-To: from Pekka Savola at "Mar 12, 2003 09:24:24 am" To: Pekka Savola Date: Thu, 13 Mar 2003 02:37:48 +0859 () CC: Iljitsch van Beijnum , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-0.7 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Pekka; > > 4. Mobility-based approaches (although this could be classified under 2.) > I'm not sure what you refer to with mobility based approaches. It seems > to me that such do not exist (which would help with multihoming, that is). There is no approaches based on MIPv6. Mobile protocol with a single home agent (or something like that) is unreliable and useless. That is, to make multihoming useful, it should be without any single point of failure and have multiple home agents. Then, such mobile protocols solve most, or all, of the problems of multihoming. However, the classification for type 4 is not productive, as all the useful solutions are, in a sense, mobility based. Masataka Ohta From owner-multi6@ops.ietf.org Wed Mar 12 12:55:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13680 for ; Wed, 12 Mar 2003 12:55:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tASs-000PU9-00 for multi6-data@psg.com; Wed, 12 Mar 2003 09:56:30 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18tASo-000PTk-00 for multi6@ops.ietf.org; Wed, 12 Mar 2003 09:56:26 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2CHuFb15213; Wed, 12 Mar 2003 19:56:15 +0200 Date: Wed, 12 Mar 2003 19:56:15 +0200 (EET) From: Pekka Savola To: Masataka Ohta cc: Iljitsch van Beijnum , Subject: Re: Move forward In-Reply-To: <200303121738.CAA18244@necom830.hpcl.titech.ac.jp> 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 Thu, 13 Mar 2003, Masataka Ohta wrote: > > > 4. Mobility-based approaches (although this could be classified under 2.) > > > I'm not sure what you refer to with mobility based approaches. It seems > > to me that such do not exist (which would help with multihoming, that is). > > There is no approaches based on MIPv6. > > Mobile protocol with a single home agent (or something like that) > is unreliable and useless. > > That is, to make multihoming useful, it should be without any single > point of failure and have multiple home agents. > > Then, such mobile protocols solve most, or all, of the problems of > multihoming. > > However, the classification for type 4 is not productive, as all the > useful solutions are, in a sense, mobility based. These "mobile protocols" you refer to are locator/identifier separation variants, like HIP or LIN6, I assume. I agree with them as long term approaches, but I'm not sure about the classification of all the useful solutions under "mobility". Mobility is too vague a word for that. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Wed Mar 12 13:16:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14462 for ; Wed, 12 Mar 2003 13:16:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tAma-00008p-00 for multi6-data@psg.com; Wed, 12 Mar 2003 10:16:52 -0800 Received: from dhcp1.kurtis.pp.se ([195.43.225.70] helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18tAmX-00008a-00 for multi6@ops.ietf.org; Wed, 12 Mar 2003 10:16:50 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2CIH0KW001462; Wed, 12 Mar 2003 19:17:00 +0100 (CET) Date: Wed, 12 Mar 2003 19:17:00 +0100 Mime-Version: 1.0 (Apple Message framework v551) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Subject: Fwd: multi6 From: Kurt Erik Lindqvist To: paf@cisco.com, Lars-Johan Liman , Johan Ihren , multi6@ops.ietf.org Message-Id: X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.4 required=5.0 tests=FWD_MSG,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 NAA14462 Eftersom jag ännu inte tackat ja kan ni väl hålla detta för er själva... Är det dumt att acceptera detta? Notera att minst halva multi6-wg antagligen anser att Randy och nuvarande chairs är ett större problem än multihoming.... Den andra halvan anser att problemet är den första halvan och att om de inte funnits hade vi redan haft en lösning (baserad på 8+8). Randys inlägg i debatten om vilka personer som är orsaken gör knappast saken bättre. Jag lutar dock åt att tacka ja... - kurtis - Begin forwarded message: > From: Randy Bush > Date: ons mar 12, 2003 17:09:45 Europe/Stockholm > To: Kurtis Lindqvist > Cc: Bert Wijnen > Subject: multi6 > > [ sorry for second copy. forgot to cc: bert on the first ] > > would you consider taking over thomas's position as co-chair of > multi6? > > randy > From owner-multi6@ops.ietf.org Wed Mar 12 13:51:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16080 for ; Wed, 12 Mar 2003 13:51:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tBLW-0001K8-00 for multi6-data@psg.com; Wed, 12 Mar 2003 10:52:58 -0800 Received: from dhcp1.kurtis.pp.se ([195.43.225.70] helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18tBLH-0001Jc-00 for multi6@ops.ietf.org; Wed, 12 Mar 2003 10:52:44 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2CIqrKW001481; Wed, 12 Mar 2003 19:52:53 +0100 (CET) Date: Wed, 12 Mar 2003 19:52:53 +0100 Subject: Re: multi6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: paf@cisco.com, Lars-Johan Liman , Johan Ihren , multi6@ops.ietf.org To: Kurt Erik Lindqvist From: Kurt Erik Lindqvist In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-3.0 required=5.0 tests=EMAIL_ATTRIBUTION,FROM_AND_TO_SAME_2,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 NAA16080 Ok, screwed up. this was not ment to go to the multi6 list. it was ment to go to some friends asking for advice on if they though I should accept or not. I owe a lot of people many excuses for this, Thomas, Randy and Bert are first of the list. My deepest and sincerest apologies for this. Please disregard this. Best regards, - kurtis - On onsdag, mar 12, 2003, at 19:17 Europe/Stockholm, Kurt Erik Lindqvist wrote: > > Eftersom jag ännu inte tackat ja kan ni väl hålla detta för er > själva... > > Är det dumt att acceptera detta? Notera att minst halva multi6-wg > antagligen anser att Randy och nuvarande chairs är ett större problem > än multihoming.... > Den andra halvan anser att problemet är den första halvan och att om > de inte funnits hade vi redan haft en lösning (baserad på 8+8). Randys > inlägg i debatten om vilka personer som är orsaken gör knappast saken > bättre. > > Jag lutar dock åt att tacka ja... > > - kurtis - > > > Begin forwarded message: > >> From: Randy Bush >> Date: ons mar 12, 2003 17:09:45 Europe/Stockholm >> To: Kurtis Lindqvist >> Cc: Bert Wijnen >> Subject: multi6 >> >> [ sorry for second copy. forgot to cc: bert on the first ] >> >> would you consider taking over thomas's position as co-chair of >> multi6? >> >> randy >> > > From owner-multi6@ops.ietf.org Wed Mar 12 14:30:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17379 for ; Wed, 12 Mar 2003 14:30:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tBwz-0002jk-00 for multi6-data@psg.com; Wed, 12 Mar 2003 11:31:41 -0800 Received: from dhcp1.kurtis.pp.se ([195.43.225.70] helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18tBwv-0002jT-00 for multi6@ops.ietf.org; Wed, 12 Mar 2003 11:31:37 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2CJX2KW001517; Wed, 12 Mar 2003 20:33:02 +0100 (CET) Date: Wed, 12 Mar 2003 20:33:02 +0100 Subject: Re: Move forward Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: <20030311200840.K69506-100000@sequoia.muada.com> Message-Id: <705547D1-54C1-11D7-952D-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) 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 >> I think this is a very good approach and also what I tried to start >> doing with the road-map, except that I tried to group all solutions, >> and only noted the need to create a path forward. Do you think it >> would >> be useful to extend this document with this (or create a new one?). I >> don't mind changing the classes if we can consensus on a common >> grouping of approaches? > > I think this way of classifying solutions can be very useful when > trying > to come up with requirements or creating desing teams. However, in a > document that introduces someone to the subject this grouping may seem > arbitrary. Agreed. But if you are referring to the road-map document, that was not meant to be an introduction to the subject. - kurtis - From owner-multi6@ops.ietf.org Wed Mar 12 15:23:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20672 for ; Wed, 12 Mar 2003 15:23:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tClW-0004ti-00 for multi6-data@psg.com; Wed, 12 Mar 2003 12:23:54 -0800 Received: from dhcp1.kurtis.pp.se ([195.43.225.70] helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18tClJ-0004si-00; Wed, 12 Mar 2003 12:23:41 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2CKOvKW001559; Wed, 12 Mar 2003 21:24:57 +0100 (CET) Date: Wed, 12 Mar 2003 21:24:56 +0100 Subject: Re: Again no multi6 at IETF#56 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Michel Py , Randy Bush , RJ Atkinson , multi6@ops.ietf.org To: Masataka Ohta From: Kurt Erik Lindqvist In-Reply-To: <200303120008.JAA14599@necom830.hpcl.titech.ac.jp> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) 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 >>> and state an opinion that 6bone address management responsibilities >>> should be transferred to RIRs only after multihoming issues are >>> solved? >>> >>> It seems to be that it is a (perhaps the only) rough consensus of >>> multi6. >>> >>> Or, does so many of us think v6 addresses may be widely assigned >>> without multihoming issues solved? >> >> I am not following your reasoning. I don't see why we should not move >> address management to where it belongs, and what that have to do with >> the multi6 issue? > > Huh? > > Are you saying it already belongs to where it belongs that there > should be no BoF? > I am saying that address registration and allocation/assignment management belongs with the RIRs. - kurtis - From owner-multi6@ops.ietf.org Wed Mar 12 18:16:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29197 for ; Wed, 12 Mar 2003 18:16:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tFSZ-000BmX-00 for multi6-data@psg.com; Wed, 12 Mar 2003 15:16:31 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 18tFSW-000Bm0-00 for multi6@ops.ietf.org; Wed, 12 Mar 2003 15:16:28 -0800 From: Masataka Ohta Message-Id: <200303122305.IAA20055@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id IAA20055; Thu, 13 Mar 2003 08:05:11 +0900 Subject: Re: Move forward In-Reply-To: from Pekka Savola at "Mar 12, 2003 07:56:15 pm" To: Pekka Savola Date: Thu, 13 Mar 2003 08:05:11 +0859 () CC: Iljitsch van Beijnum , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-0.7 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Pekka; > > > > 4. Mobility-based approaches (although this could be classified under 2.) > > However, the classification for type 4 is not productive, as all the > > useful solutions are, in a sense, mobility based. > > These "mobile protocols" you refer to are locator/identifier separation > variants, like HIP or LIN6, I assume. No. All. > I agree with them as long term approaches, but I'm not sure about the > classification of all the useful solutions under "mobility". I can't see any reason to have short and long term approaches. All we need is a solution and a solution-specific transition strategy. Some solution may require two steps of transition. But, such a solution is poor with complex and painful transition and should be avoided. > Mobility is too vague a word for that. That is a problem of the original classification attempt. Masataka Ohta From owner-multi6@ops.ietf.org Wed Mar 12 18:25:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29575 for ; Wed, 12 Mar 2003 18:25:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tFcc-000CCJ-00 for multi6-data@psg.com; Wed, 12 Mar 2003 15:26:54 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 18tFcR-000CBf-00; Wed, 12 Mar 2003 15:26:43 -0800 From: Masataka Ohta Message-Id: <200303122313.IAA20104@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id IAA20104; Thu, 13 Mar 2003 08:12:56 +0859 Subject: Re: Again no multi6 at IETF#56 In-Reply-To: from Kurt Erik Lindqvist at "Mar 12, 2003 09:24:56 pm" To: Kurt Erik Lindqvist Date: Thu, 13 Mar 2003 08:12:56 +0859 () CC: Michel Py , Randy Bush , RJ Atkinson , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-0.7 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Kurt; > >>> and state an opinion that 6bone address management responsibilities > >>> should be transferred to RIRs only after multihoming issues are > >>> solved? > >>> > >>> It seems to be that it is a (perhaps the only) rough consensus of > >>> multi6. > >>> > >>> Or, does so many of us think v6 addresses may be widely assigned > >>> without multihoming issues solved? > >> > >> I am not following your reasoning. I don't see why we should not move > >> address management to where it belongs, and what that have to do with > >> the multi6 issue? > > > > Huh? > > > > Are you saying it already belongs to where it belongs that there > > should be no BoF? > > > I am saying that address registration and allocation/assignment > management belongs with the RIRs. How, do you think, it should be managed? "just like IPv4" is not an answer. Masataka Ohta From owner-multi6@ops.ietf.org Thu Mar 13 02:07:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18306 for ; Thu, 13 Mar 2003 02:07:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tMp1-0002Pq-00 for multi6-data@psg.com; Wed, 12 Mar 2003 23:08:11 -0800 Received: from dhcp1.kurtis.pp.se ([195.43.225.70] helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18tMoy-0002Pc-00; Wed, 12 Mar 2003 23:08:08 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2D79DKW001671; Thu, 13 Mar 2003 08:09:13 +0100 (CET) Date: Thu, 13 Mar 2003 08:09:13 +0100 Subject: Re: Again no multi6 at IETF#56 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Michel Py , Randy Bush , RJ Atkinson , multi6@ops.ietf.org To: Masataka Ohta From: Kurt Erik Lindqvist In-Reply-To: <200303122313.IAA20104@necom830.hpcl.titech.ac.jp> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) 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 >>> Are you saying it already belongs to where it belongs that there >>> should be no BoF? >>> >> I am saying that address registration and allocation/assignment >> management belongs with the RIRs. > > How, do you think, it should be managed? > > "just like IPv4" is not an answer. > And your suggestion is? - kurtis - From owner-multi6@ops.ietf.org Thu Mar 13 09:16:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01197 for ; Thu, 13 Mar 2003 09:16:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tTVj-000Gg0-00 for multi6-data@psg.com; Thu, 13 Mar 2003 06:16:43 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 18tTVf-000Gf7-00; Thu, 13 Mar 2003 06:16:40 -0800 From: Masataka Ohta Message-Id: <200303131408.XAA23284@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id XAA23284; Thu, 13 Mar 2003 23:08:34 +0900 Subject: Re: Again no multi6 at IETF#56 In-Reply-To: from Kurt Erik Lindqvist at "Mar 13, 2003 08:09:13 am" To: Kurt Erik Lindqvist Date: Thu, 13 Mar 2003 23:08:32 +0859 () CC: Michel Py , Randy Bush , RJ Atkinson , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-0.7 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Kurtis; > >>> Are you saying it already belongs to where it belongs that there > >>> should be no BoF? > >>> > >> I am saying that address registration and allocation/assignment > >> management belongs with the RIRs. > > > > How, do you think, it should be managed? > > > > "just like IPv4" is not an answer. > > > > And your suggestion is? Have a consensus at multi6 meetings. Have them. Masataka Ohta From owner-multi6@ops.ietf.org Thu Mar 13 09:21:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01435 for ; Thu, 13 Mar 2003 09:21:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tTcW-000H3D-00 for multi6-data@psg.com; Thu, 13 Mar 2003 06:23:44 -0800 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74]) by psg.com with esmtp (Exim 3.36 #1) id 18tTcU-000H2L-00; Thu, 13 Mar 2003 06:23:42 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2DEOpKW001956; Thu, 13 Mar 2003 15:24:51 +0100 (CET) Date: Thu, 13 Mar 2003 15:24:50 +0100 Subject: Re: Again no multi6 at IETF#56 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Michel Py , Randy Bush , RJ Atkinson , multi6@ops.ietf.org To: Masataka Ohta From: Kurt Erik Lindqvist In-Reply-To: <200303131408.XAA23284@necom830.hpcl.titech.ac.jp> Message-Id: <8D052508-555F-11D7-B6B3-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) 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 >>>>> Are you saying it already belongs to where it belongs that there >>>>> should be no BoF? >>>>> >>>> I am saying that address registration and allocation/assignment >>>> management belongs with the RIRs. >>> >>> How, do you think, it should be managed? >>> >>> "just like IPv4" is not an answer. >>> >> >> And your suggestion is? > > Have a consensus at multi6 meetings. > On assignment policy and registration? Wow. - kurtis - From owner-multi6@ops.ietf.org Thu Mar 13 10:32:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05593 for ; Thu, 13 Mar 2003 10:32:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tUiV-000KES-00 for multi6-data@psg.com; Thu, 13 Mar 2003 07:33:59 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 18tUiR-000KEB-00; Thu, 13 Mar 2003 07:33:55 -0800 From: Masataka Ohta Message-Id: <200303131525.AAA23985@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id AAA23985; Fri, 14 Mar 2003 00:24:59 +0859 Subject: Re: Again no multi6 at IETF#56 In-Reply-To: <8D052508-555F-11D7-B6B3-000393AB1404@kurtis.pp.se> from Kurt Erik Lindqvist at "Mar 13, 2003 03:24:50 pm" To: Kurt Erik Lindqvist Date: Fri, 14 Mar 2003 00:24:59 +0859 () CC: Michel Py , Randy Bush , RJ Atkinson , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-0.7 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Kurt; > >>>>> Are you saying it already belongs to where it belongs that there > >>>>> should be no BoF? > >>>>> > >>>> I am saying that address registration and allocation/assignment > >>>> management belongs with the RIRs. > >>> > >>> How, do you think, it should be managed? > >>> > >>> "just like IPv4" is not an answer. > >>> > >> > >> And your suggestion is? > > > > Have a consensus at multi6 meetings. > > > > On assignment policy and registration? Of course. It is impossible for RIRs to define an assignment policy unless they recognize how multihomed sites should be treated. Masataka Ohta From owner-multi6@ops.ietf.org Thu Mar 13 12:23:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09508 for ; Thu, 13 Mar 2003 12:23:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tWQn-000PLU-00 for multi6-data@psg.com; Thu, 13 Mar 2003 09:23:49 -0800 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #1) id 18tWQi-000PL4-00 for multi6@ops.ietf.org; Thu, 13 Mar 2003 09:23:44 -0800 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA01827; Thu, 13 Mar 2003 09:23:43 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h2DHNhn26092; Thu, 13 Mar 2003 09:23:43 -0800 X-mProtect: <200303131723> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (209.157.142.163, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdazNu1Z; Thu, 13 Mar 2003 09:23:40 PST Message-Id: <4.3.2.7.2.20030313092109.02cee468@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 13 Mar 2003 09:23:24 -0800 To: Kurt Erik Lindqvist From: Bob Hinden Subject: Re: Again no multi6 at IETF#56 Cc: multi6@ops.ietf.org In-Reply-To: <8D052508-555F-11D7-B6B3-000393AB1404@kurtis.pp.se> References: <200303131408.XAA23284@necom830.hpcl.titech.ac.jp> 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 I think the answer is that the RIRs can do allocations based on the technical requirements given to them by the IETF. Bob >On assignment policy and registration? Wow. > >- kurtis - > From owner-multi6@ops.ietf.org Thu Mar 13 12:36:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09874 for ; Thu, 13 Mar 2003 12:36:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tWea-00009V-00 for multi6-data@psg.com; Thu, 13 Mar 2003 09:38:04 -0800 Received: from dhcp1.kurtis.pp.se ([195.43.225.70] helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18tWeV-00009F-00 for multi6@ops.ietf.org; Thu, 13 Mar 2003 09:38:00 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2DHdMKW002123; Thu, 13 Mar 2003 18:39:23 +0100 (CET) Date: Thu, 13 Mar 2003 18:39:22 +0100 Subject: Re: Again no multi6 at IETF#56 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: multi6@ops.ietf.org To: Bob Hinden From: Kurt Erik Lindqvist In-Reply-To: <4.3.2.7.2.20030313092109.02cee468@mailhost.iprg.nokia.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.9 required=5.0 tests=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 think the answer is that the RIRs can do allocations based on the > technical requirements given to them by the IETF. Hmm. This depends on what you mean. Policy is today decided by the membership of the RIRs. I think that RIRs should do allocations according to the policy set by the RIRs members. The IETF should set technical standards for the protocols using those addresses or making up those addresses. If those protocols require limitations in policy, that should be declared in the protocol specification. I think you will find it hard to get the RIR membership to agree on having policy set outside the RIR membership. If you want to influence the allocation policy, go the RIRs meetings. - kurtis - From owner-multi6@ops.ietf.org Thu Mar 13 13:16:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11392 for ; Thu, 13 Mar 2003 13:16:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tXHY-0002H4-00 for multi6-data@psg.com; Thu, 13 Mar 2003 10:18:20 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 18tXHN-0002Ge-00 for multi6@ops.ietf.org; Thu, 13 Mar 2003 10:18:09 -0800 Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 0E65F137F06; Thu, 13 Mar 2003 10:18:07 -0800 (PST) Date: Thu, 13 Mar 2003 10:18:07 -0800 Subject: Re: Again no multi6 at IETF#56 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Kurt Erik Lindqvist , multi6@ops.ietf.org To: Bob Hinden From: David Conrad In-Reply-To: <4.3.2.7.2.20030313092109.02cee468@mailhost.iprg.nokia.com> Message-Id: <23E1D31A-5580-11D7-8B65-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) 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 Um. No. See http://www.arin.net/policy/ipep.html On Thursday, March 13, 2003, at 09:23 AM, Bob Hinden wrote: > I think the answer is that the RIRs can do allocations based on the > technical requirements given to them by the IETF. > > Bob > > > > >> On assignment policy and registration? Wow. >> >> - kurtis - >> > > From owner-multi6@ops.ietf.org Thu Mar 13 13:36:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12102 for ; Thu, 13 Mar 2003 13:36:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tXaH-0003P7-00 for multi6-data@psg.com; Thu, 13 Mar 2003 10:37:41 -0800 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #1) id 18tXaC-0003Or-00 for multi6@ops.ietf.org; Thu, 13 Mar 2003 10:37:36 -0800 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA04757; Thu, 13 Mar 2003 10:37:34 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h2DIbXE27977; Thu, 13 Mar 2003 10:37:33 -0800 X-mProtect: <200303131837> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.150, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdc1s3c7; Thu, 13 Mar 2003 10:37:31 PST Message-Id: <4.3.2.7.2.20030313102616.02cf2028@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 13 Mar 2003 10:37:17 -0800 To: Kurt Erik Lindqvist From: Bob Hinden Subject: Re: Again no multi6 at IETF#56 Cc: multi6@ops.ietf.org In-Reply-To: References: <4.3.2.7.2.20030313092109.02cee468@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-0.8 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Kurt, >>I think the answer is that the RIRs can do allocations based on the >>technical requirements given to them by the IETF. > >Hmm. This depends on what you mean. Policy is today decided by the >membership of the RIRs. I think that RIRs should do allocations according >to the policy set by the RIRs members. The IETF should set technical >standards for the protocols using those addresses or making up those >addresses. If those protocols require limitations in policy, that should >be declared in the protocol specification. I think you will find it hard >to get the RIR membership to agree on having policy set outside the RIR >membership. The policy has to be consistent with the technical constraints. The IETF needs to define what the technical requirements (i.e., what works, waht doesn't work, what the limitations are, scaling properties, etc.) in order for the RIR to create the policy that is practical. >If you want to influence the allocation policy, go the RIRs meetings. Agreed. But the policy needs to consistent with the technical requirements. For example there are technical limitations of routing protocols that relate to the number of routes and interconnections between ISPs. If the RIRs were to adopt a policy that did not take these technical requirements it would result in an Internet that didn't work. Bob From owner-multi6@ops.ietf.org Thu Mar 13 13:54:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12677 for ; Thu, 13 Mar 2003 13:54:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tXrv-0004RN-00 for multi6-data@psg.com; Thu, 13 Mar 2003 10:55:55 -0800 Received: from dhcp1.kurtis.pp.se ([195.43.225.70] helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18tXrs-0004R8-00 for multi6@ops.ietf.org; Thu, 13 Mar 2003 10:55:53 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2DIuWKW002151; Thu, 13 Mar 2003 19:56:33 +0100 (CET) Date: Thu, 13 Mar 2003 19:56:32 +0100 Subject: Re: Again no multi6 at IETF#56 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: multi6@ops.ietf.org To: Bob Hinden From: Kurt Erik Lindqvist In-Reply-To: <4.3.2.7.2.20030313102616.02cf2028@mailhost.iprg.nokia.com> Message-Id: <8196D486-5585-11D7-B6B3-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) 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 >>> Bob, >>> I think the answer is that the RIRs can do allocations based on the >>> technical requirements given to them by the IETF. >> >> Hmm. This depends on what you mean. Policy is today decided by the >> membership of the RIRs. I think that RIRs should do allocations >> according to the policy set by the RIRs members. The IETF should set >> technical standards for the protocols using those addresses or making >> up those addresses. If those protocols require limitations in policy, >> that should be declared in the protocol specification. I think you >> will find it hard to get the RIR membership to agree on having policy >> set outside the RIR membership. > > The policy has to be consistent with the technical constraints. The > IETF needs to define what the technical requirements (i.e., what > works, waht doesn't work, what the limitations are, scaling > properties, etc.) in order for the RIR to create the policy that is > practical. As IPv6 build IIDs out of MAC addresses, should the IETF make rules on how MAC addresses are assigned? From what I remember there is an agreement between the RIRs and the IETF on who does what, right? Making the claim above implies changing a lot more than IETF specs. I agree with you that it is up to the IETF to set the technical specifications, but to say that the IETF decides "in order for the RIRs to create the policy that is practical" is dangerous. > >> If you want to influence the allocation policy, go the RIRs meetings. > > Agreed. But the policy needs to consistent with the technical > requirements. For example there are technical limitations of routing > protocols that relate to the number of routes and interconnections > between ISPs. If the RIRs were to adopt a policy that did not take > these technical requirements it would result in an Internet that > didn't work. > You can do this in multiple ways. You could (playing the devils advocate) argue that the IETF should create technical specifications that can handle the policy of the RIRs. After all, to a large extent the RIR membership is most likely a better representation of "end-users" (for some definition of users) than the IETF is. A better way to move forward is most likely to have the IETF _cooperate_ with the RIRs on a working policy. I still to some extend fail to see the underlaying problem though. - kurtis - From owner-multi6@ops.ietf.org Thu Mar 13 14:37:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14520 for ; Thu, 13 Mar 2003 14:37:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tYWq-000745-00 for multi6-data@psg.com; Thu, 13 Mar 2003 11:38:12 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18tYWn-00073H-00 for multi6@ops.ietf.org; Thu, 13 Mar 2003 11:38:09 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2DJbDf75714; Thu, 13 Mar 2003 20:37:13 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Thu, 13 Mar 2003 20:37:13 +0100 (CET) From: Iljitsch van Beijnum To: Kurt Erik Lindqvist cc: Subject: Re: Again no multi6 at IETF#56 In-Reply-To: <8196D486-5585-11D7-B6B3-000393AB1404@kurtis.pp.se> Message-ID: <20030313202813.K69506-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, 13 Mar 2003, Kurt Erik Lindqvist wrote: > You can do this in multiple ways. You could (playing the devils > advocate) argue that the IETF should create technical specifications > that can handle the policy of the RIRs. After all, to a large extent > the RIR membership is most likely a better representation of > "end-users" (for some definition of users) than the IETF is. I don't agree. Even if ISPs (overwhelming majority of RIR membership) represent end-users better than vendors (majority of IETF membership) there is only one RIR policy and users don't get to choose, while there are usually many ways to implement some functionality that are endorsed by the IETF and not being endorsed by the IETF doesn't mean it can't be implemented or used. Having a choice is always the better option. From owner-multi6@ops.ietf.org Thu Mar 13 14:49:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15022 for ; Thu, 13 Mar 2003 14:49:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tYjC-00086N-00 for multi6-data@psg.com; Thu, 13 Mar 2003 11:50:58 -0800 Received: from dhcp1.se.kurtis.pp.se ([195.43.225.70] helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18tYj9-000864-00 for multi6@ops.ietf.org; Thu, 13 Mar 2003 11:50:55 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2DJq1KW002168; Thu, 13 Mar 2003 20:52:01 +0100 (CET) Date: Thu, 13 Mar 2003 20:52:00 +0100 Subject: Re: Again no multi6 at IETF#56 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: <20030313202813.K69506-100000@sequoia.muada.com> Message-Id: <414BA7C8-558D-11D7-B6B3-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.9 required=5.0 tests=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 >> You can do this in multiple ways. You could (playing the devils >> advocate) argue that the IETF should create technical specifications >> that can handle the policy of the RIRs. After all, to a large extent >> the RIR membership is most likely a better representation of >> "end-users" (for some definition of users) than the IETF is. > > I don't agree. Even if ISPs (overwhelming majority of RIR membership) > represent end-users better than vendors (majority of IETF membership) > there is only one RIR policy and users don't get to choose, while there > are usually many ways to implement some functionality that are endorsed > by the IETF and not being endorsed by the IETF doesn't mean it can't be > implemented or used. Having a choice is always the better option. I think you need to go and check the RIR policies. They are not the same. They are similar, but not the same. Besides that, the RIRs have a similar policy in order not create competition for a resource that is considered limited and i order to limit routing table growth (the problem that is trying to be solved by having the IETF set the policy) . If the resource is not limited and routing table growth is not an issue, let each RIR set their own policy. Now, if your argument is that we should have multiple RIRs that compete with cost between eachother - that is definitely out of scope for the IETF. I then suggest you take this to the LIR-WG, ARIN policy list etc. - kurtis - From owner-multi6@ops.ietf.org Thu Mar 13 15:24:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17654 for ; Thu, 13 Mar 2003 15:24:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tZH4-000ATd-00 for multi6-data@psg.com; Thu, 13 Mar 2003 12:25:58 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18tZH1-000ATJ-00 for multi6@ops.ietf.org; Thu, 13 Mar 2003 12:25:55 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2DKP0q75831; Thu, 13 Mar 2003 21:25:00 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Thu, 13 Mar 2003 21:24:59 +0100 (CET) From: Iljitsch van Beijnum To: Kurt Erik Lindqvist cc: Subject: Re: Again no multi6 at IETF#56 In-Reply-To: <414BA7C8-558D-11D7-B6B3-000393AB1404@kurtis.pp.se> Message-ID: <20030313211916.B69506-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 Thu, 13 Mar 2003, Kurt Erik Lindqvist wrote: > I think you need to go and check the RIR policies. They are not the > same. They are similar, but not the same. Addresses are hard to get and I need to pay. Those are the parts that bother me. The rest, I don't care much about... :-) > Besides that, the RIRs have a similar policy in order not create > competition for a resource that is considered limited and i order to > limit routing table growth (the problem that is trying to be solved by > having the IETF set the policy) . If the resource is not limited and > routing table growth is not an issue, let each RIR set their own policy. Ok, I'll hold you to that when we've solved the multihoming problem. (Address space isn't scarce anymore with v6 of course.) > Now, if your argument is that we should have multiple RIRs that compete > with cost between eachother - that is definitely out of scope for the > IETF. Not at all. What I'm saying is that if we have a choice whether the IETF or the RIRs can make a certain policy, this is a no-brainer: the IETF. Only when the scarcity issues come into play you need the RIRs. That's what they're good at, lets not distract them with anything else. But this is all moot most of the time, as the RIRs do existing stuff while the IETF tries to build new stuff. So the overlap isn't that big. From owner-multi6@ops.ietf.org Thu Mar 13 17:26:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22040 for ; Thu, 13 Mar 2003 17:26:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tbAV-000KLp-00 for multi6-data@psg.com; Thu, 13 Mar 2003 14:27:19 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18tbAL-000KHQ-00; Thu, 13 Mar 2003 14:27:10 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18tbAH-0000Na-00; Thu, 13 Mar 2003 17:27:06 -0500 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 13 Mar 2003 17:27:05 -0500 To: Kurt Erik Lindqvist Cc: Bob Hinden , multi6@ops.ietf.org Subject: Re: Again no multi6 at IETF#56 References: <4.3.2.7.2.20030313102616.02cf2028@mailhost.iprg.nokia.com> <8196D486-5585-11D7-B6B3-000393AB1404@kurtis.pp.se> Message-Id: 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 > You can do this in multiple ways. You could (playing the devils > advocate) argue that the IETF should create technical specifications > that can handle the policy of the RIRs. After all, to a large extent > the RIR membership is most likely a better representation of > "end-users" (for some definition of users) than the IETF is. problem is that the rirs, aside from missing protocol folk, are also missing router/backbone ops folk. so they get a very narrow view. > A better way to move forward is most likely to have the IETF > _cooperate_ with the RIRs on a working policy. bingo! randy From owner-multi6@ops.ietf.org Fri Mar 14 10:06:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27418 for ; Fri, 14 Mar 2003 10:06:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tqll-000NNM-00 for multi6-data@psg.com; Fri, 14 Mar 2003 07:06:49 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 18tqlf-000NN9-00 for multi6@ops.ietf.org; Fri, 14 Mar 2003 07:06:44 -0800 From: Masataka Ohta Message-Id: <200303141452.XAA06678@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id XAA06678; Fri, 14 Mar 2003 23:52:29 +0900 Subject: Re: Again no multi6 at IETF#56 In-Reply-To: <23E1D31A-5580-11D7-8B65-000393DB42B2@nominum.com> from David Conrad at "Mar 13, 2003 10:18:07 am" To: David Conrad Date: Fri, 14 Mar 2003 23:52:29 +0859 () CC: Bob Hinden , Kurt Erik Lindqvist , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-0.7 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk David; > Um. No. See http://www.arin.net/policy/ipep.html Are you saying "Board of Trustees", "ARIN Advisory Council" and or general public" related to ARIN decision will make decisions just randomly without having knowledge on technical requirements? Masataka Ohta > > I think the answer is that the RIRs can do allocations based on the > > technical requirements given to them by the IETF. > > > > Bob > > > > > > > > > >> On assignment policy and registration? Wow. > >> > >> - kurtis - > >> > > > > > > > From owner-multi6@ops.ietf.org Fri Mar 14 10:14:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28536 for ; Fri, 14 Mar 2003 10:14:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tqvG-000NgU-00 for multi6-data@psg.com; Fri, 14 Mar 2003 07:16:38 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 18tqvB-000Ng6-00 for multi6@ops.ietf.org; Fri, 14 Mar 2003 07:16:33 -0800 From: Masataka Ohta Message-Id: <200303141506.AAA06744@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id AAA06744; Sat, 15 Mar 2003 00:06:33 +0900 Subject: Re: Again no multi6 at IETF#56 In-Reply-To: <20030313211916.B69506-100000@sequoia.muada.com> from Iljitsch van Beijnum at "Mar 13, 2003 09:24:59 pm" To: Iljitsch van Beijnum Date: Sat, 15 Mar 2003 00:06:32 +0859 () CC: Kurt Erik Lindqvist , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-0.4 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_03_05 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Iljitsch; > > I think you need to go and check the RIR policies. They are not the > > same. They are similar, but not the same. > > Addresses are hard to get and I need to pay. Those are the parts that > bother me. The rest, I don't care much about... :-) IPv6 addresses will be easy to get and you need not to pay much. However, TLAs will be harder to get and you need to pay a lot more. Masataka Ohta From owner-multi6@ops.ietf.org Fri Mar 14 10:14:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28561 for ; Fri, 14 Mar 2003 10:14:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tqvK-000Ngh-00 for multi6-data@psg.com; Fri, 14 Mar 2003 07:16:42 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 18tqvH-000NgR-00 for multi6@ops.ietf.org; Fri, 14 Mar 2003 07:16:40 -0800 From: Masataka Ohta Message-Id: <200303141503.AAA06731@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id AAA06731; Sat, 15 Mar 2003 00:03:32 +0900 Subject: Re: Again no multi6 at IETF#56 In-Reply-To: <414BA7C8-558D-11D7-B6B3-000393AB1404@kurtis.pp.se> from Kurt Erik Lindqvist at "Mar 13, 2003 08:52:00 pm" To: Kurt Erik Lindqvist Date: Sat, 15 Mar 2003 00:03:31 +0859 () CC: Iljitsch van Beijnum , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-1.0 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Kurt; > >> You can do this in multiple ways. You could (playing the devils > >> advocate) argue that the IETF should create technical specifications > >> that can handle the policy of the RIRs. After all, to a large extent > >> the RIR membership is most likely a better representation of > >> "end-users" (for some definition of users) than the IETF is. > > > > I don't agree. Even if ISPs (overwhelming majority of RIR membership) > > represent end-users better than vendors (majority of IETF membership) > > there is only one RIR policy and users don't get to choose, while there > > are usually many ways to implement some functionality that are endorsed > > by the IETF and not being endorsed by the IETF doesn't mean it can't be > > implemented or used. Having a choice is always the better option. > > I think you need to go and check the RIR policies. They are not the > same. They are similar, but not the same. They don't have to be similar but they have to be consistent. > Besides that, the RIRs have a similar policy in order not create > competition for a resource that is considered limited and i order to > limit routing table growth (the problem that is trying to be solved by > having the IETF set the policy) . If the resource is not limited and > routing table growth is not an issue, let each RIR set their own policy. Wrong. If the resource is not limited and routing table growth is not an issue, don't let each RIR set their own policy. Just assign as much resource as demanded. However, routing table is a limited resource and routing table size is an issue. Masataka Ohta From owner-multi6@ops.ietf.org Fri Mar 14 12:31:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03421 for ; Fri, 14 Mar 2003 12:31:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tt1j-0002eq-00 for multi6-data@psg.com; Fri, 14 Mar 2003 09:31:27 -0800 Received: from mailhost.iprg.nokia.com ([205.226.5.12]) by psg.com with esmtp (Exim 3.36 #1) id 18tt1d-0002eb-00; Fri, 14 Mar 2003 09:31:21 -0800 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA20347; Fri, 14 Mar 2003 09:31:20 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h2EHVJ313651; Fri, 14 Mar 2003 09:31:19 -0800 X-mProtect: <200303141731> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.150, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdFMqG92; Fri, 14 Mar 2003 09:31:16 PST Message-Id: <4.3.2.7.2.20030314092205.035dd700@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 14 Mar 2003 09:29:30 -0800 To: Randy Bush From: Bob Hinden Subject: Re: Again no multi6 at IETF#56 Cc: multi6@ops.ietf.org In-Reply-To: References: <4.3.2.7.2.20030313102616.02cf2028@mailhost.iprg.nokia.com> <8196D486-5585-11D7-B6B3-000393AB1404@kurtis.pp.se> 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 Randy, At 02:27 PM 3/13/2003, Randy Bush wrote: > > You can do this in multiple ways. You could (playing the devils > > advocate) argue that the IETF should create technical specifications > > that can handle the policy of the RIRs. After all, to a large extent > > the RIR membership is most likely a better representation of > > "end-users" (for some definition of users) than the IETF is. > >problem is that the rirs, aside from missing protocol folk, are >also missing router/backbone ops folk. so they get a very narrow >view. I agree. It's not clear to me that either the IETF or the RIRs represent the "end-users". The RIRs are focused on their members who are mostly ISPs and the IETF is populated by people from vendors, standards professionals, some ISPs, and researchers. IMHO neither groups primary focus is the "end-users". I would think that the ISOC could possibly fill this role. > > A better way to move forward is most likely to have the IETF > > _cooperate_ with the RIRs on a working policy. > >bingo! YES! Bob From owner-multi6@ops.ietf.org Fri Mar 14 15:04:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11297 for ; Fri, 14 Mar 2003 15:04:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tvQg-0008s2-00 for multi6-data@psg.com; Fri, 14 Mar 2003 12:05:22 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 18tvQd-0008rq-00 for multi6@ops.ietf.org; Fri, 14 Mar 2003 12:05:19 -0800 Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 0559A137F06; Fri, 14 Mar 2003 12:05:19 -0800 (PST) Date: Fri, 14 Mar 2003 12:05:18 -0800 Subject: Re: Again no multi6 at IETF#56 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Bob Hinden , Kurt Erik Lindqvist , multi6@ops.ietf.org To: Masataka Ohta From: David Conrad In-Reply-To: <200303141452.XAA06678@necom830.hpcl.titech.ac.jp> Message-Id: <47785C23-5658-11D7-85A7-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) 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 Silly rhetorical question. As the URL documents, RIR policies are established via public policy meetings in which interested parties, including those affected by the policies, can provide input. Technical implications of policies are part of the input. Have you ever been to a RIR public policy meeting? Rgds, -drc On Friday, March 14, 2003, at 06:53 AM, Masataka Ohta wrote: > David; > >> Um. No. See http://www.arin.net/policy/ipep.html > > Are you saying "Board of Trustees", "ARIN Advisory Council" and > or general public" related to ARIN decision will make decisions > just randomly without having knowledge on technical requirements? > > Masataka Ohta > >>> I think the answer is that the RIRs can do allocations based on the >>> technical requirements given to them by the IETF. >>> >>> Bob >>> >>> >>> >>> >>>> On assignment policy and registration? Wow. >>>> >>>> - kurtis - >>>> >>> >>> >> >> >> > From owner-multi6@ops.ietf.org Fri Mar 14 15:06:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11576 for ; Fri, 14 Mar 2003 15:06:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tvTd-0008yF-00 for multi6-data@psg.com; Fri, 14 Mar 2003 12:08:25 -0800 Received: from dmz1.procket.com ([65.174.124.36]) by psg.com with esmtp (Exim 3.36 #1) id 18tvTa-0008xt-00 for multi6@ops.ietf.org; Fri, 14 Mar 2003 12:08:22 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 9FB0523C24; Fri, 14 Mar 2003 12:34: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 h2EK8GYB007002; Fri, 14 Mar 2003 12:08:17 -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="us-ascii" Subject: RE: Again no multi6 at IETF#56 Date: Fri, 14 Mar 2003 12:08:16 -0800 Message-ID: Thread-Topic: Again no multi6 at IETF#56 Thread-Index: AcLpsd55ygf0lejTTlymDbEqBOsu6gAszEuw From: "Tony Li" To: "Randy Bush" , "Kurt Erik Lindqvist" Cc: "Bob Hinden" , 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 PAA11576 Gentlefolk, I think we're missing the big picture here. Handing out addresses before you understand how addresses will be used is not a good idea. We did this in IPv4 and it resulted in the swamp. To not make this mistake again, we need to have a firm routing architecture for v6 in hand that includes support for multi-homing as a first level, non-scalability-impacting element. We are not there yet. Tony From owner-multi6@ops.ietf.org Fri Mar 14 15:10:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12082 for ; Fri, 14 Mar 2003 15:10:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tvX6-000974-00 for multi6-data@psg.com; Fri, 14 Mar 2003 12:12:00 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 18tvX3-00096d-00 for multi6@ops.ietf.org; Fri, 14 Mar 2003 12:11:57 -0800 Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 0CF1A137F0B; Fri, 14 Mar 2003 12:11:57 -0800 (PST) Date: Fri, 14 Mar 2003 12:11:56 -0800 Subject: Re: Again no multi6 at IETF#56 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Randy Bush , multi6@ops.ietf.org To: Bob Hinden From: David Conrad In-Reply-To: <4.3.2.7.2.20030314092205.035dd700@mailhost.iprg.nokia.com> Message-Id: <349B44BC-5659-11D7-85A7-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.9 required=5.0 tests=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 This is not particularly related to multi6. On Friday, March 14, 2003, at 09:29 AM, Bob Hinden wrote: >> > A better way to move forward is most likely to have the IETF >> > _cooperate_ with the RIRs on a working policy. >> bingo! > YES! Perhaps, say, Thomas Narten, Takeshi Arano, or David Kessens could work with ARIN and the other RIRs to come up with IPv6 policies? Or maybe folks from IPng like Bob Hinden could run drafts of proposals for addressing architectures by the RIRs for input? Oh. Wait. Rgds, -drc From owner-multi6@ops.ietf.org Fri Mar 14 16:50:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15909 for ; Fri, 14 Mar 2003 16:50:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tx4x-000DQF-00 for multi6-data@psg.com; Fri, 14 Mar 2003 13:51:03 -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 #1) id 18tx4p-000DOn-00 for multi6@ops.ietf.org; Fri, 14 Mar 2003 13:50:55 -0800 Subject: RE: Again no multi6 at IETF#56 Date: Fri, 14 Mar 2003 13:50:54 -0800 Message-ID: <963621801C6D3E4A9CF454A1972AE8F50454F6@server2000.arneill-py.sacramento.ca.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Thread-Topic: Again no multi6 at IETF#56 Content-class: urn:content-classes:message Thread-Index: AcLpsd55ygf0lejTTlymDbEqBOsu6gAszEuwAAOkbxA= X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 From: "Michel Py" To: "Tony Li" , "Randy Bush" , "Kurt Erik Lindqvist" Cc: "Bob Hinden" , 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 QAA15909 > Tony Li wrote: > I think we're missing the big picture here. Handing > out addresses before you understand how addresses > will be used is not a good idea. We did this in IPv4 > and it resulted in the swamp. > To not make this mistake again, we need to have a > firm routing architecture for v6 in hand that includes > support for multi-homing as a first level, > non-scalability-impacting element. > We are not there yet. I could not agree more. Michel. From owner-multi6@ops.ietf.org Fri Mar 14 17:33:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17017 for ; Fri, 14 Mar 2003 17:33:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18txlF-000FOW-00 for multi6-data@psg.com; Fri, 14 Mar 2003 14:34:45 -0800 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by psg.com with esmtp (Exim 3.36 #1) id 18txl4-000FOC-00 for multi6@ops.ietf.org; Fri, 14 Mar 2003 14:34:34 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 0B3A41045; Fri, 14 Mar 2003 17:34:34 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 14 Mar 2003 17:34:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Again no multi6 at IETF#56 Date: Fri, 14 Mar 2003 17:34:33 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCC82@tayexc13.americas.cpqcorp.net> Thread-Topic: Again no multi6 at IETF#56 Thread-Index: AcLqURL27+U2CPi5RB+0xqPr9DV1jQAKG8ig From: "Bound, Jim" To: "Bob Hinden" , "Randy Bush" Cc: X-OriginalArrivalTime: 14 Mar 2003 22:34:33.0910 (UTC) FILETIME=[E2EFBD60:01C2EA79] 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 RAA17017 There is mini ARIN work shop April 6th and that week in Memphis. A few End users I know will be there and downstream providers that are using the address space and going to request more. ARIN listens to all input. /jim > -----Original Message----- > From: Bob Hinden [mailto:hinden@IPRG.nokia.com] > Sent: Friday, March 14, 2003 12:30 PM > To: Randy Bush > Cc: multi6@ops.ietf.org > Subject: Re: Again no multi6 at IETF#56 > > > Randy, > > At 02:27 PM 3/13/2003, Randy Bush wrote: > > > You can do this in multiple ways. You could (playing the devils > > > advocate) argue that the IETF should create technical > specifications > > > that can handle the policy of the RIRs. After all, to a > large extent > > > the RIR membership is most likely a better representation of > > > "end-users" (for some definition of users) than the IETF is. > > > >problem is that the rirs, aside from missing protocol folk, are also > >missing router/backbone ops folk. so they get a very narrow view. > > I agree. It's not clear to me that either the IETF or the > RIRs represent > the "end-users". The RIRs are focused on their members who > are mostly ISPs > and the IETF is populated by people from vendors, standards > professionals, > some ISPs, and researchers. IMHO neither groups primary focus is the > "end-users". I would think that the ISOC could possibly fill > this role. > > > > A better way to move forward is most likely to have the IETF > > > _cooperate_ with the RIRs on a working policy. > > > >bingo! > > YES! > > Bob > > > From owner-multi6@ops.ietf.org Fri Mar 14 17:44:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17284 for ; Fri, 14 Mar 2003 17:44:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18txwj-000Fzn-00 for multi6-data@psg.com; Fri, 14 Mar 2003 14:46:37 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 18txwg-000FzV-00; Fri, 14 Mar 2003 14:46:35 -0800 From: Masataka Ohta Message-Id: <200303142234.HAA01586@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id HAA01586; Sat, 15 Mar 2003 07:34:10 +0900 Subject: Re: Again no multi6 at IETF#56 In-Reply-To: <349B44BC-5659-11D7-85A7-000393DB42B2@nominum.com> from David Conrad at "Mar 14, 2003 12:11:56 pm" To: David Conrad Date: Sat, 15 Mar 2003 07:34:09 +0859 () CC: Bob Hinden , Randy Bush , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-0.7 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk drc; > >> > A better way to move forward is most likely to have the IETF > >> > _cooperate_ with the RIRs on a working policy. > >> bingo! > > YES! > > Perhaps, say, Thomas Narten, Takeshi Arano, or David Kessens could work > with ARIN and the other RIRs to come up with IPv6 policies? None of them is IETF. Moreover, > Or maybe > folks from IPng like Bob Hinden could run drafts of proposals for > addressing architectures by the RIRs for input? IPng WG has no idea on addressing architecture for multihoming. IPng WG has no idea on how global routing table size should be managed. Masataka Ohta From owner-multi6@ops.ietf.org Fri Mar 14 17:57:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17549 for ; Fri, 14 Mar 2003 17:57:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ty8Y-000Gc3-00 for multi6-data@psg.com; Fri, 14 Mar 2003 14:58:50 -0800 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by psg.com with esmtp (Exim 3.36 #1) id 18ty8W-000Gbp-00 for multi6@ops.ietf.org; Fri, 14 Mar 2003 14:58:48 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 328893AAE; Fri, 14 Mar 2003 17:58:47 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 14 Mar 2003 17:58:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Again no multi6 at IETF#56 Date: Fri, 14 Mar 2003 17:58:27 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03241031@tayexc13.americas.cpqcorp.net> Thread-Topic: Again no multi6 at IETF#56 Thread-Index: AcLpsd55ygf0lejTTlymDbEqBOsu6gAszEuwAAOkbxAAAjdfEA== From: "Bound, Jim" To: "Michel Py" , "Tony Li" , "Randy Bush" , "Kurt Erik Lindqvist" Cc: "Bob Hinden" , X-OriginalArrivalTime: 14 Mar 2003 22:58:27.0568 (UTC) FILETIME=[39769700:01C2EA7D] 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 RAA17549 I don't agree. Not because I don't believe multi6 issues should not be done. But, because RIRs are dealing with free enterprise. The market will adjust but should not wait for a process that cannot deliver. And they won't. Does this effort want to fix the multihome problem or the routing architecture to be something other than what we have? Two different goals. But, whatever is done will now have to be done while IPv6 is in process in the market. I would suggest solving the multihome problem is a good focus first, using IPv6 as defined. /jim > -----Original Message----- > From: Michel Py [mailto:michel@arneill-py.sacramento.ca.us] > Sent: Friday, March 14, 2003 4:51 PM > To: Tony Li; Randy Bush; Kurt Erik Lindqvist > Cc: Bob Hinden; multi6@ops.ietf.org > Subject: RE: Again no multi6 at IETF#56 > > > > Tony Li wrote: > > I think we're missing the big picture here. Handing > > out addresses before you understand how addresses > > will be used is not a good idea. We did this in IPv4 > > and it resulted in the swamp. > > To not make this mistake again, we need to have a > > firm routing architecture for v6 in hand that includes support for > > multi-homing as a first level, non-scalability-impacting element. > > We are not there yet. > > I could not agree more. > > Michel. > > > From owner-multi6@ops.ietf.org Fri Mar 14 19:04:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20318 for ; Fri, 14 Mar 2003 19:04:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18tzAg-000Joz-00 for multi6-data@psg.com; Fri, 14 Mar 2003 16:05:06 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 18tzAa-000JnN-00; Fri, 14 Mar 2003 16:05:00 -0800 From: Masataka Ohta Message-Id: <200303142355.IAA02460@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id IAA02460; Sat, 15 Mar 2003 08:54:52 +0859 Subject: Re: Again no multi6 at IETF#56 In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03241031@tayexc13.americas.cpqcorp.net> from "Bound, Jim" at "Mar 14, 2003 05:58:27 pm" To: "Bound, Jim" Date: Sat, 15 Mar 2003 08:54:51 +0859 () CC: Michel Py , Tony Li , Randy Bush , Kurt Erik Lindqvist , Bob Hinden , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-0.7 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Jim; > I don't agree. Not because I don't believe multi6 issues should not be > done. But, because RIRs are dealing with free enterprise. There ain't no such thing as a free Internet. Masataka Ohta From owner-multi6@ops.ietf.org Fri Mar 14 20:06:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21743 for ; Fri, 14 Mar 2003 20:06:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18u09D-000Mwi-00 for multi6-data@psg.com; Fri, 14 Mar 2003 17:07:39 -0800 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #1) id 18u099-000MwT-00 for multi6@ops.ietf.org; Fri, 14 Mar 2003 17:07:35 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id BF84834443; Fri, 14 Mar 2003 16:20:31 -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 h2F17XYB016124; Fri, 14 Mar 2003 17:07: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="us-ascii" Subject: RE: Again no multi6 at IETF#56 Date: Fri, 14 Mar 2003 17:07:33 -0800 Message-ID: Thread-Topic: Again no multi6 at IETF#56 Thread-Index: AcLpsd55ygf0lejTTlymDbEqBOsu6gAszEuwAAOkbxAAAjdfEAAEmiUA From: "Tony Li" To: "Bound, Jim" , "Michel Py" , "Randy Bush" , "Kurt Erik Lindqvist" Cc: "Bob Hinden" , 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 UAA21743 | I don't agree. Not because I don't believe multi6 issues | should not be | done. But, because RIRs are dealing with free enterprise. So you're saying that you're waiting for the market to deliver a routing architecture? Or that the RIRs are going to? | Does this effort want to fix the multihome | problem or the | routing architecture to be something other than what we have? Two | different goals. The goal is to fix the multihoming problem, but to do it will take a routing architecture that is different than what we have. | But, whatever is done will now have to be | done while | IPv6 is in process in the market. I would suggest solving | the multihome | problem is a good focus first, using IPv6 as defined. Well, that's kinda hard, because IPv6 as defined simply ingrains the problem. Tony From owner-multi6@ops.ietf.org Fri Mar 14 20:07:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21757 for ; Fri, 14 Mar 2003 20:07:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18u0AQ-000Myw-00 for multi6-data@psg.com; Fri, 14 Mar 2003 17:08:54 -0800 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by psg.com with esmtp (Exim 3.36 #1) id 18u0AO-000Mye-00 for multi6@ops.ietf.org; Fri, 14 Mar 2003 17:08:52 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id C91CD3A8B; Fri, 14 Mar 2003 20:08:51 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 14 Mar 2003 20:08:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Again no multi6 at IETF#56 Date: Fri, 14 Mar 2003 20:08:51 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCC91@tayexc13.americas.cpqcorp.net> Thread-Topic: Again no multi6 at IETF#56 Thread-Index: AcLqhoFoSLAvUrzWSDix+oE3X4No5AACNm8g From: "Bound, Jim" To: "Masataka Ohta" Cc: "Michel Py" , "Tony Li" , "Randy Bush" , "Kurt Erik Lindqvist" , "Bob Hinden" , X-OriginalArrivalTime: 15 Mar 2003 01:08:51.0695 (UTC) FILETIME=[71019FF0:01C2EA8F] 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 UAA21757 Masataka, Exactly. Free Enterprise means no Free stuff including the Internet. Thanks /jim >-----Original Message----- >From: Masataka Ohta [mailto:mohta@necom830.hpcl.titech.ac.jp] >Sent: Friday, March 14, 2003 6:56 PM >To: Bound, Jim >Cc: Michel Py; Tony Li; Randy Bush; Kurt Erik Lindqvist; Bob >Hinden; multi6@ops.ietf.org >Subject: Re: Again no multi6 at IETF#56 > > >Jim; > >> I don't agree. Not because I don't believe multi6 issues should not >> be done. But, because RIRs are dealing with free enterprise. > >There ain't no such thing as a free Internet. > > Masataka Ohta > From owner-multi6@ops.ietf.org Fri Mar 14 20:15:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21935 for ; Fri, 14 Mar 2003 20:15:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18u0IG-000NOO-00 for multi6-data@psg.com; Fri, 14 Mar 2003 17:17:00 -0800 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by psg.com with esmtp (Exim 3.36 #1) id 18u0ID-000NO8-00 for multi6@ops.ietf.org; Fri, 14 Mar 2003 17:16:58 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 4BA152FF5; Fri, 14 Mar 2003 20:16:57 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 14 Mar 2003 20:16:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Again no multi6 at IETF#56 Date: Fri, 14 Mar 2003 20:16:56 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03241034@tayexc13.americas.cpqcorp.net> Thread-Topic: Again no multi6 at IETF#56 Thread-Index: AcLpsd55ygf0lejTTlymDbEqBOsu6gAszEuwAAOkbxAAAjdfEAAEmiUAAAAoLFA= From: "Bound, Jim" To: "Tony Li" , "Michel Py" , "Randy Bush" , "Kurt Erik Lindqvist" Cc: "Bob Hinden" , X-OriginalArrivalTime: 15 Mar 2003 01:16:57.0192 (UTC) FILETIME=[92629680:01C2EA90] 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 UAA21935 >So you're saying that you're waiting for the market to deliver >a routing architecture? Or that the RIRs are going to? RIRs will just give out addresses that is all. THe market will deliver a routing architecture via new industry consortia or we will figure it out here. >| Does this effort want to fix the multihome >| problem or the >| routing architecture to be something other than what we have? Two >| different goals. > >The goal is to fix the multihoming problem, but to do it will >take a routing architecture that is different than what we have. Might be good to define routing architecture? If we begin by reducing traffic that causes problems for routing at the ISP in the end systems I believe that is a start. If new routing architecture means change to IPv6 then I say engineers go in a room and make work what you have. Extensions to IPv6 are acceptable I think. >Well, that's kinda hard, because IPv6 as defined simply >ingrains the problem. That's where we will never agree and I don't use the word never to often. One possible solution to this statemate is for someone to define what exactly routing architecture would look like as a model. Then if we all agreed on that model each could apply that model to their favorite solution. I for one would look at extensions to IPv6 that are quite possible and there are many places to define extensions (e.g. DST Options, Hop-by-Hop, Next Headers new formats). /jim From owner-multi6@ops.ietf.org Fri Mar 14 21:20:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23055 for ; Fri, 14 Mar 2003 21:20:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18u1JH-0001D6-00 for multi6-data@psg.com; Fri, 14 Mar 2003 18:22:07 -0800 Received: from adsl-63-202-92-157.dsl.snfc21.pacbell.net ([63.202.92.157] helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18u1JD-0001BY-00 for multi6@ops.ietf.org; Fri, 14 Mar 2003 18:22:03 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2F2NPKW002326; Sat, 15 Mar 2003 03:23:26 +0100 (CET) Date: Fri, 14 Mar 2003 15:03:17 +0100 Subject: Re: Again no multi6 at IETF#56 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: <20030313211916.B69506-100000@sequoia.muada.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-1.6 required=5.0 tests=DATE_IN_PAST_12_24,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 >> I think you need to go and check the RIR policies. They are not the >> same. They are similar, but not the same. > > Addresses are hard to get and I need to pay. Those are the parts that > bother me. The rest, I don't care much about... :-) ...for IPv4. For IPv6 this is true for a reason. The very reason that it's being argued that the IETF should 'help' the RIRs. If you actually go and look at the policy you will find that IP addresses are allocated/assigned with various ease by various RIRs. >> Now, if your argument is that we should have multiple RIRs that >> compete >> with cost between eachother - that is definitely out of scope for the >> IETF. > > Not at all. What I'm saying is that if we have a choice whether the > IETF > or the RIRs can make a certain policy, this is a no-brainer: the IETF. You will find that _a lot_ of people disagrees with you. They will say it's a no-brainer to have the RIRs set the policy. The IETF is not about policy. > Only when the scarcity issues come into play you need the RIRs. That's > what they're good at, lets not distract them with anything else. No. The RIRs do much more than that. They provided a number of services around a policy. Registration is one of them. Do you really expect the IETF to set the policy, have the RIRs register this and ask people to pay for this without having a thing to say? I think you need to go to some more RIR meetings. > But this is all moot most of the time, as the RIRs do existing stuff > while the IETF tries to build new stuff. So the overlap isn't that big. ..which is why I fail to see what this discussion is about. The RIRs do registry and address policy. The IETF do architecture, protocols and some technology. There are well established rules to handle the overlap. - kurtis - From owner-multi6@ops.ietf.org Fri Mar 14 21:20:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23071 for ; Fri, 14 Mar 2003 21:20:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18u1Ig-0001B3-00 for multi6-data@psg.com; Fri, 14 Mar 2003 18:21:30 -0800 Received: from adsl-63-202-92-157.dsl.snfc21.pacbell.net ([63.202.92.157] helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18u1Ic-0001Ag-00; Fri, 14 Mar 2003 18:21:26 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2F2MXKW002314; Sat, 15 Mar 2003 03:22:41 +0100 (CET) Date: Fri, 14 Mar 2003 12:37:23 +0100 Subject: Re: Again no multi6 at IETF#56 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Michel Py , Randy Bush , RJ Atkinson , multi6@ops.ietf.org To: Masataka Ohta From: Kurt Erik Lindqvist In-Reply-To: <200303131525.AAA23985@necom830.hpcl.titech.ac.jp> Message-Id: <52E89F2F-5611-11D7-B6B3-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) 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 >>>> And your suggestion is? >>> >>> Have a consensus at multi6 meetings. >>> >> >> On assignment policy and registration? > > Of course. > > It is impossible for RIRs to define an assignment policy unless > they recognize how multihomed sites should be treated. > Fist I think we need a 'somewhat' wider consensus on how do deal with multihomed sites, before the IETF starts giving directions to the RIRs... - kurtis - From owner-multi6@ops.ietf.org Fri Mar 14 21:21:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23108 for ; Fri, 14 Mar 2003 21:21:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18u1JT-0001Es-00 for multi6-data@psg.com; Fri, 14 Mar 2003 18:22:19 -0800 Received: from adsl-63-202-92-157.dsl.snfc21.pacbell.net ([63.202.92.157] helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18u1JN-0001EZ-00; Fri, 14 Mar 2003 18:22:13 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2F2NYKW002332; Sat, 15 Mar 2003 03:23:36 +0100 (CET) Date: Fri, 14 Mar 2003 18:22:56 +0100 Subject: Re: Again no multi6 at IETF#56 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Bob Hinden , multi6@ops.ietf.org To: Randy Bush From: Kurt Erik Lindqvist In-Reply-To: Message-Id: <98852C10-5641-11D7-B6B3-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) 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 >> You can do this in multiple ways. You could (playing the devils >> advocate) argue that the IETF should create technical specifications >> that can handle the policy of the RIRs. After all, to a large extent >> the RIR membership is most likely a better representation of >> "end-users" (for some definition of users) than the IETF is. > > problem is that the rirs, aside from missing protocol folk, are > also missing router/backbone ops folk. so they get a very narrow > view. I guess this to some extend varies a bit between the RIRs, but in general I agree. Still, it's a better representation than vendors voting on the policy... - kurtis - From owner-multi6@ops.ietf.org Fri Mar 14 21:55:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23585 for ; Fri, 14 Mar 2003 21:55:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18u1rR-0003Hy-00 for multi6-data@psg.com; Fri, 14 Mar 2003 18:57:25 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 18u1rO-0003Hg-00 for multi6@ops.ietf.org; Fri, 14 Mar 2003 18:57:22 -0800 Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 103AB137F06; Fri, 14 Mar 2003 18:57:20 -0800 (PST) Date: Fri, 14 Mar 2003 18:57:20 -0800 Subject: Re: Again no multi6 at IETF#56 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Bob Hinden , Randy Bush , multi6@ops.ietf.org To: Masataka Ohta From: David Conrad In-Reply-To: <200303142234.HAA01586@necom830.hpcl.titech.ac.jp> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) 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 Ohta-san, On Friday, March 14, 2003, at 02:35 PM, Masataka Ohta wrote: >> Perhaps, say, Thomas Narten, Takeshi Arano, or David Kessens could >> work >> with ARIN and the other RIRs to come up with IPv6 policies? > None of them is IETF. True, however at least two of the three are quite active in IPv6 related issues within the IETF and I think it safe to assume technical concerns from the IETF (and elsewhere) were taken into account during the development of the current v6 policies. > IPng WG has no idea on addressing architecture for multihoming. > IPng WG has no idea on how global routing table size should > be managed. Yes. However, the RIRs have come under significant criticism in the past for being perceived as road blocks to IPv6 allocations and have, in fact, reduced the requirements for v6 space. Even in this list, they are criticized for making obtaining address space 'hard'. Seems they are damned if they do and damned if they don't. Rgds, -drc From owner-multi6@ops.ietf.org Fri Mar 14 21:56:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23613 for ; Fri, 14 Mar 2003 21:56:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18u1so-0003K4-00 for multi6-data@psg.com; Fri, 14 Mar 2003 18:58:50 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18u1sl-0003Js-00; Fri, 14 Mar 2003 18:58:48 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18u1sk-0006SJ-00; Fri, 14 Mar 2003 21:58:46 -0500 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 14 Mar 2003 21:58:45 -0500 To: Kurt Erik Lindqvist Cc: Bob Hinden , multi6@ops.ietf.org Subject: Re: Again no multi6 at IETF#56 References: <98852C10-5641-11D7-B6B3-000393AB1404@kurtis.pp.se> Message-Id: 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 >> problem is that the rirs, aside from missing protocol folk, are >> also missing router/backbone ops folk. so they get a very narrow >> view. > I guess this to some extend varies a bit between the RIRs, but in > general I agree. Still, it's a better representation than vendors > voting on the policy... rofl! From owner-multi6@ops.ietf.org Sat Mar 15 02:42:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12304 for ; Sat, 15 Mar 2003 02:42:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18u6J8-000KPU-00 for multi6-data@psg.com; Fri, 14 Mar 2003 23:42:18 -0800 Received: from dmz1.procket.com ([65.174.124.36]) by psg.com with esmtp (Exim 3.36 #1) id 18u6J4-000KO9-00 for multi6@ops.ietf.org; Fri, 14 Mar 2003 23:42:14 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 0B1B723C35; Sat, 15 Mar 2003 00:08:00 -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 h2F7gDYB026929; Fri, 14 Mar 2003 23:42: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="us-ascii" Subject: RE: Again no multi6 at IETF#56 Date: Fri, 14 Mar 2003 23:42:12 -0800 Message-ID: Thread-Topic: Again no multi6 at IETF#56 Thread-Index: AcLpsd55ygf0lejTTlymDbEqBOsu6gAszEuwAAOkbxAAAjdfEAAEmiUAAAAoLFAADU7MwA== From: "Tony Li" To: "Bound, Jim" , "Michel Py" , "Randy Bush" , "Kurt Erik Lindqvist" Cc: "Bob Hinden" , 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 CAA12304 | RIRs will just give out addresses that is all. THe market | will deliver | a routing architecture via new industry consortia or we | will figure it | out here. A new industry consortia is now in charge of IPv6? Please, point us at it. Figuring it out here is 'challenging'. | >| Does this effort want to fix the multihome | >| problem or the | >| routing architecture to be something other than what | we have? Two | >| different goals. | > | >The goal is to fix the multihoming problem, but to do it will | >take a routing architecture that is different than what we have. | | Might be good to define routing architecture? 10 years and we still don't understand the problem that we're trying to solve? Sigh. Routing is the other half of ROAD. The part that we didn't ever finish. Ok, just for posterity: routing architecture tells you how packets get from point A to point B in the network. It includes the semantics of the address, the routing protocols, and the forwarding paradigm. | If we begin | by reducing | traffic that causes problems for routing at the ISP in the | end systems I | believe that is a start. Ok, let's turn off v6. Solved. | If new routing architecture | means change to | IPv6 then I say engineers go in a room and make work what you have. | Extensions to IPv6 are acceptable I think. Extensions imply that the architecture could not support that case properly as a first class citizen and that you're crocking and kludging to make it work. Seems like a pretty poor basis for a "new" protocol when you're trying to get it deployed and you admit up front that it doesn't cut it. | >Well, that's kinda hard, because IPv6 as defined simply | >ingrains the problem. | | That's where we will never agree and I don't use the word never to | often. One possible solution to this statemate is for | someone to define | what exactly routing architecture would look like as a | model. Then if | we all agreed on that model each could apply that model to their | favorite solution. I for one would look at extensions to | IPv6 that are | quite possible and there are many places to define | extensions (e.g. DST | Options, Hop-by-Hop, Next Headers new formats). Jim, if you're going to be so closed minded as to say that we will never agree, then I don't see how you can reasonably expect anyone to change the architecture. Multihoming can never be a first class citizen in the architecture if you do not divorce the 'locator' from the 'identifier'. And that's what IPv6 insists on today. If we continue down that path, then the only alternatives are: 1) Forbid multihoming. Not gonna happen. 2) All multihomed sites get global addresses and the routing subsystem implodes. This is the only way to get a single 'identifier' and then use it for 'location' across all of my exit paths. I must advertise the route throughout the topology. Which of these do you choose? My vote: 3) Change the semantics of a v6 address. Tony From owner-multi6@ops.ietf.org Sat Mar 15 05:16:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13782 for ; Sat, 15 Mar 2003 05:16:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18u8iL-0000Ov-00 for multi6-data@psg.com; Sat, 15 Mar 2003 02:16:29 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 18u8iI-0000Od-00; Sat, 15 Mar 2003 02:16:27 -0800 From: Masataka Ohta Message-Id: <200303151009.TAA06911@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id TAA06911; Sat, 15 Mar 2003 19:09:40 +0900 Subject: Re: Again no multi6 at IETF#56 In-Reply-To: from David Conrad at "Mar 14, 2003 06:57:20 pm" To: David Conrad Date: Sat, 15 Mar 2003 19:09:39 +0859 () CC: Bob Hinden , Randy Bush , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-0.7 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk drc; > > IPng WG has no idea on addressing architecture for multihoming. > > IPng WG has no idea on how global routing table size should > > be managed. > > Yes. However, the RIRs have come under significant criticism in the > past for being perceived as road blocks to IPv6 allocations and have, > in fact, reduced the requirements for v6 space. Even in this list, > they are criticized for making obtaining address space 'hard'. Significant criticism by who? The primary obstacles for IPv6 deployment have been: 0) Supession, not reduction, of IPv4 address consumption. 1) Complexity of protocol such as ND, IPsec and routing header useful for no meaningful purposes. 2) People insisting on keeping complex useless features and not introducing necessary features. > Seems they are damned if they do and damned if they don't. They are never damned. There are other people to be damned. Masataka Ohta From owner-multi6@ops.ietf.org Sat Mar 15 15:10:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24713 for ; Sat, 15 Mar 2003 15:10:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uHz5-0001J1-00 for multi6-data@psg.com; Sat, 15 Mar 2003 12:10:23 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18uHz2-0001In-00 for multi6@ops.ietf.org; Sat, 15 Mar 2003 12:10:20 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2FK85182520; Sat, 15 Mar 2003 21:08:07 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Sat, 15 Mar 2003 21:08:05 +0100 (CET) From: Iljitsch van Beijnum To: Marcelo Bagnulo cc: Pekka Savola , Subject: Re: Move forward In-Reply-To: <3E6F1479.1030400@it.uc3m.es> Message-ID: <20030315203547.M69506-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, 12 Mar 2003, Marcelo Bagnulo wrote: > We have tried to evaluate a concrete proposal for multi-homing using > MIPv6 tools. The result can be found: > http://www.ietf.org/internet-drafts/draft-bagnulo-multi6-mnm-00.txt > We would really appreciate your comments, Ok, some comments: - It looks like you want to authenticate the secondary address beforehand when there is still return routability. But can you then simply keep the secndary address in some kind of "hot standby" state untill it is time to start using it and then use it for some considerable amount of time without re-authentication? Does this work and is it secure? Oh wait: "This is a major limitation for this application, since the binding can not be refreshed until the original route is restored and outages can last longer than 420 seconds." - ICMP echo for keepalive wouldn't work. Not so much because of all the broken firewalls that block them, but because the only thing an echo reply tells you is that there is _someone_ present at the address, it doesn't tell you who it is. (Ie dial user may have logged out and another logged in and gotten the same address.) - Why don't you look at the return traffic to see if the path is still viable? If you keep (re)sending data but there is no reply from the other side, something must be broken. This probably needs per-session state, though. - "If a failure has occurred along the path, the attempt to initiate the communication will fail and the CN will try again with another address. Eventually, a packet from CN will reach MHH." As this is application-dependent you can't count on this. Worse: the all-time most popular networked application typically chokes if the first address tried doesn't work. - Having to interact every 70 seconds may break sessions that would otherwise remain intact. For instance, I often put my laptop to sleep in the middle of a session to conserve the battery. When it wakes up, my session is still ok because there was no communication during the nap so the fact that my laptop was effecitvely disconnected didn't matter. So lack of a HoT my not be an outage but simply saving energy... This is excellent work. It shows multihoming in IPv6 is just around the corner, and not impossible as some people seem to believe. However, I do see a problem: as this solution isn't well suited to medium-sized and larger sites, and provides no compatibility with other solutions that do cater to larger sites, implementing this as-is may not bring as much benefit as we hope. After all, the majority of all communication is with at least one non-small site. And I don't think Google or some other huge site really wants to start doing MIP as a mattoer of course on all those 200 msec TCP sessions just because the other side is multihomed. So what I'd like to see is compatibility with one or more solutions that are more suited for larger sites. But I guess the first thing we need for that is one or more solutions that are ore suited for larger sites. :-) Iljitsch From owner-multi6@ops.ietf.org Sat Mar 15 16:21:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26520 for ; Sat, 15 Mar 2003 16:21:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uJ6w-0006Yb-00 for multi6-data@psg.com; Sat, 15 Mar 2003 13:22:34 -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 #1) id 18uJ6u-0006YI-00 for multi6@ops.ietf.org; Sat, 15 Mar 2003 13:22:32 -0800 Content-class: urn:content-classes:message Subject: RE: Again no multi6 at IETF#56 Date: Sat, 15 Mar 2003 13:22:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <963621801C6D3E4A9CF454A1972AE8F5045506@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Thread-Topic: Again no multi6 at IETF#56 Thread-Index: AcLpsd55ygf0lejTTlymDbEqBOsu6gAszEuwAAOkbxAAAjdfEAAEmiUAAAAoLFAADU7MwAAdA0mA From: "Michel Py" To: "Tony Li" , "Bound, Jim" , "Randy Bush" , "Kurt Erik Lindqvist" Cc: "Bob Hinden" , 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 QAA26520 > Tony Li wrote: > 3) Change the semantics of a v6 address. Wow that's a little too extreme for my taste. Michel. From owner-multi6@ops.ietf.org Sat Mar 15 20:16:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00911 for ; Sat, 15 Mar 2003 20:16:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uMlX-000PCy-00 for multi6-data@psg.com; Sat, 15 Mar 2003 17:16:43 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 18uMlU-000PCh-00; Sat, 15 Mar 2003 17:16:40 -0800 From: Masataka Ohta Message-Id: <200303160105.KAA12891@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id KAA12891; Sun, 16 Mar 2003 10:05:41 +0900 Subject: Re: Again no multi6 at IETF#56 In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F5045506@server2000.arneill-py.sacramento.ca.us> from Michel Py at "Mar 15, 2003 01:22:27 pm" To: Michel Py Date: Sun, 16 Mar 2003 10:05:40 +0859 () CC: Tony Li , "Bound, Jim" , Randy Bush , Kurt Erik Lindqvist , Bob Hinden , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=0.1 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk > > Tony Li wrote: > > 3) Change the semantics of a v6 address. > > Wow that's a little too extreme for my taste. Reasonable complaint. :-) So, let's admit freedom of those who insist on leagacy v6 to use it forever and interoperate with the rest of the v6 world but without the benefit of multihoming. Production level v6 address assignment can begin as soon as we agree on a multihomed solution. Is it OK, Jim? Masataka Ohta From owner-multi6@ops.ietf.org Sat Mar 15 20:59:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01679 for ; Sat, 15 Mar 2003 20:59:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uNSF-0002rI-00 for multi6-data@psg.com; Sat, 15 Mar 2003 18:00:51 -0800 Received: from mailout.zma.compaq.com ([161.114.64.103] helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18uNSD-0002r6-00 for multi6@ops.ietf.org; Sat, 15 Mar 2003 18:00:49 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 600D23333; Sat, 15 Mar 2003 21:00:48 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sat, 15 Mar 2003 21:00:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Again no multi6 at IETF#56 Date: Sat, 15 Mar 2003 21:00:47 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCC9B@tayexc13.americas.cpqcorp.net> Thread-Topic: Again no multi6 at IETF#56 Thread-Index: AcLqmvdNN/hLiLo1TPKt9slBHM+YewAxI/cQ From: "Bound, Jim" To: "Kurt Erik Lindqvist" , "Iljitsch van Beijnum" Cc: X-OriginalArrivalTime: 16 Mar 2003 02:00:48.0341 (UTC) FILETIME=[DD15D050:01C2EB5F] 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 UAA01679 >..which is why I fail to see what this discussion is about. >The RIRs do >registry and address policy. The IETF do architecture, protocols and >some technology. There are well established rules to handle >the overlap. I don't get the discussion either. The IETF will never control what the RIRs do and lots of people would scream with far more influence than the IETF if this even was suggested. Also the IETF is a standards body. The IETF can suggest the architecture through the standards. No one builds networks based on the IETF opinion or whatever. IETF is a just a standards body and no more. /jim From owner-multi6@ops.ietf.org Sat Mar 15 21:00:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01764 for ; Sat, 15 Mar 2003 21:00:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uNTm-0002za-00 for multi6-data@psg.com; Sat, 15 Mar 2003 18:02:26 -0800 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by psg.com with esmtp (Exim 3.36 #1) id 18uNTj-0002xa-00 for multi6@ops.ietf.org; Sat, 15 Mar 2003 18:02:23 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id A94C23F76; Sat, 15 Mar 2003 21:02:22 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sat, 15 Mar 2003 21:02:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Again no multi6 at IETF#56 Date: Sat, 15 Mar 2003 21:02:22 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCC9C@tayexc13.americas.cpqcorp.net> Thread-Topic: Again no multi6 at IETF#56 Thread-Index: AcLqoA0mbP2f0WBgTKaiQMBZONDOnAAv/Hug From: "Bound, Jim" To: "David Conrad" , "Masataka Ohta" Cc: "Bob Hinden" , "Randy Bush" , X-OriginalArrivalTime: 16 Mar 2003 02:02:22.0638 (UTC) FILETIME=[154A64E0:01C2EB60] 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 VAA01764 Unlike the IETF RIRs do have to respond to market pressure. RIRs do take into consideration the IETF standards. But not as gospel. /jim >-----Original Message----- >From: David Conrad [mailto:david.conrad@nominum.com] >Sent: Friday, March 14, 2003 9:57 PM >To: Masataka Ohta >Cc: Bob Hinden; Randy Bush; multi6@ops.ietf.org >Subject: Re: Again no multi6 at IETF#56 > > >Ohta-san, > >On Friday, March 14, 2003, at 02:35 PM, Masataka Ohta wrote: >>> Perhaps, say, Thomas Narten, Takeshi Arano, or David Kessens could >>> work >>> with ARIN and the other RIRs to come up with IPv6 policies? >> None of them is IETF. > >True, however at least two of the three are quite active in IPv6 >related issues within the IETF and I think it safe to assume technical >concerns from the IETF (and elsewhere) were taken into account during >the development of the current v6 policies. > >> IPng WG has no idea on addressing architecture for multihoming. >> IPng WG has no idea on how global routing table size should >> be managed. > >Yes. However, the RIRs have come under significant criticism in the >past for being perceived as road blocks to IPv6 allocations and have, >in fact, reduced the requirements for v6 space. Even in this list, >they are criticized for making obtaining address space 'hard'. > >Seems they are damned if they do and damned if they don't. > >Rgds, >-drc > > > From owner-multi6@ops.ietf.org Sat Mar 15 21:05:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01909 for ; Sat, 15 Mar 2003 21:05:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uNYG-0003US-00 for multi6-data@psg.com; Sat, 15 Mar 2003 18:07:04 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18uNYD-0003UA-00 for multi6@ops.ietf.org; Sat, 15 Mar 2003 18:07:01 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2G26u411771; Sun, 16 Mar 2003 04:06:56 +0200 Date: Sun, 16 Mar 2003 04:06:55 +0200 (EET) From: Pekka Savola To: Marcelo Bagnulo cc: Iljitsch van Beijnum , Subject: comments on mipv6 application to multihoming [Re: Move forward] In-Reply-To: <3E6F1479.1030400@it.uc3m.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 12 Mar 2003, Marcelo Bagnulo wrote: > We have tried to evaluate a concrete proposal for multi-homing using > MIPv6 tools. The result can be found: > > http://www.ietf.org/internet-drafts/draft-bagnulo-multi6-mnm-00.txt > > We would really appreciate your comments, Some jetlagged comments. substantial: ------------ ==> The problem is that this mechanism only "works" (for some definition of works) for sessions that are broken over 140 seconds (ie. connection is not aborted before that), with the upper bound of 420 seconds. On top of that, quite a bit of signalling is performed just in case that a link might go down. Needless to say, this doesn't seem to be all that useful, the tradeoffs would seem to be quite overwhelming: especially the 140 seconds; I'd say the outage of 10-20 seconds is the most that's acceptable for most connections to stay properly alive. ==> however, I appreciate thinking the whole thing through.. however, as it is, the doc is quite heavy to read as it's full of gritty details (which are nice when you want to get down to it, and verify it), but more focus should be given to the big picture.. ==> there is a need for a shorter overview before section 4.3 ==> sect 4.3 must be split into smaller pieces In the application scenario, according to [3], Site Exit Anycast Addresses for ISPA is PA:Site:FFFF:FFFF:FFFF:FFFF:FFFF (Hereafter SEAAA) Site Exit Anycast Addresses for ISPB is PB:Site:FFFF:FFFF:FFFF:FFFF:FFFF (Hereafter SEAAB) Then, MHH will try first to send a first packet with: ==> these values seem to be irrelevant, remove. Btw, how does a node know the prefix length of his site? Not an easy problem, unless it's guessing.. editorials: ----------- Application of the MIPv6 protocol to the multi-homing problem ==> uppercase the first chars of the most words ==> same goes for the section titles This note attempts to describe how to apply the MIPv6 protocol to ==> s/MIPv6/Mobile IPv6 (MIPv6)/ 1. Introduction ==> split the section; too long paragraphs are difficult to read ==> actually, a lot of paragraphs should be split up 1- A path failure detection mechanism, that enables end-hosts to ==> s/,// 4.2.3 Required capability #1 ==> reqs should be listed in order or numbered differently alternative ISP is to be used for coursing packets. Source address ==> I'm not sure what you mean by "coursing" but I suggest using another :-) (many other places..) the second message. IF this is the case, a BU message is sent, ==> s/IF/If/ Finally, this solution does not requires that multi-homed sites to ==> s/requires that/require/ References [1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", Internet Draft, Work in progress, May 2002. ==> split the refs ==> s/J. Arkko/Arkko, J./ (same everywhere) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Sat Mar 15 21:35:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02981 for ; Sat, 15 Mar 2003 21:35:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uO0Y-0005qG-00 for multi6-data@psg.com; Sat, 15 Mar 2003 18:36:18 -0800 Received: from mailout.zma.compaq.com ([161.114.64.104] helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18uO0U-0005pw-00 for multi6@ops.ietf.org; Sat, 15 Mar 2003 18:36:14 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id DD08B16F5; Sat, 15 Mar 2003 21:36:13 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sat, 15 Mar 2003 21:36:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Again no multi6 at IETF#56 Date: Sat, 15 Mar 2003 21:36:13 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03241036@tayexc13.americas.cpqcorp.net> Thread-Topic: Again no multi6 at IETF#56 Thread-Index: AcLpsd55ygf0lejTTlymDbEqBOsu6gAszEuwAAOkbxAAAjdfEAAEmiUAAAAoLFAADU7MwAAm+aTA From: "Bound, Jim" To: "Tony Li" , "Michel Py" , "Randy Bush" , "Kurt Erik Lindqvist" Cc: "Bob Hinden" , X-OriginalArrivalTime: 16 Mar 2003 02:36:13.0811 (UTC) FILETIME=[CFF6CC30:01C2EB64] 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 VAA02981 >| RIRs will just give out addresses that is all. THe market >| will deliver >| a routing architecture via new industry consortia or we >| will figure it >| out here. > > >A new industry consortia is now in charge of IPv6? Please, >point us at it. Figuring it out here is 'challenging'. If this and many other specs do not begin to produce solutions in a timely manner then I predict there will be a deployment body for IPv6 to go work on those specs and send them to the IETF but not with the intention of waiting for 4 years for them to complete but implement and work the IETF at same time. So my statement was the result of an "if". > > >| >| Does this effort want to fix the multihome >| >| problem or the >| >| routing architecture to be something other than what >| we have? Two >| >| different goals. >| > >| >The goal is to fix the multihoming problem, but to do it will >| >take a routing architecture that is different than what we have. >| >| Might be good to define routing architecture? > > >10 years and we still don't understand the problem that we're >trying to solve? Sigh. I think we do. I think we just do not agree on some very basic ways to solve the problem. One will win and one will loose. The loser will predict horrible fates from the others choice. I find asking the most basic obvious questions before that result is the case, might be prudent. Because I think this is all going to stop soon and some solutiion will just happen. For me no solution to change the IPv6 address or the IPv6 architecture is acceptable. Period. I do not believe that is required. More below. > >Routing is the other half of ROAD. The part that we didn't >ever finish. > >Ok, just for posterity: routing architecture tells you how >packets get from point A to point B in the network. It >includes the semantics of the address, the routing protocols, >and the forwarding paradigm. Ahaha. I do not agree that includes the semantics of the address. But the use of the semantics of the address. So I am glad I asked this obvious question. But you and I will never agree on some basics that appear to be deep rooted. Like fixed vs variable addresses for the IP header. > > >| If we begin >| by reducing >| traffic that causes problems for routing at the ISP in the >| end systems I >| believe that is a start. > > >Ok, let's turn off v6. Solved. Go back and read the SCTP suggestions as one initial solution to this problem. If the end system is smart enough to failover interfaces to different ISPs, because it is aware of its multi-home nature it will help reduce the need for ISPs to share aggregate routes. The end system will not need them to do that for most cases. I realize this is not a total solution. Nor do I believe there is one total solution. But multiple solutions at different points in the network. > > >| If new routing architecture >| means change to >| IPv6 then I say engineers go in a room and make work what >you have. >| Extensions to IPv6 are acceptable I think. > > >Extensions imply that the architecture could not support that >case properly as a first class citizen and that you're >crocking and kludging to make it work. Seems like a pretty >poor basis for a "new" protocol when you're trying to get it >deployed and you admit up front that it doesn't cut it. This is the negative view yes, but there is the positive view. First I am not clear that the extensions are needed I suggested them to you if you believe IPv6 needs **new** features, there is way to add them. The positive view is that IPv6 is a base architecture that can be extended far better than IPv4. As a note the only complaint I have heard from entities really deploying IPv6 routing with their ISP to an enterprise is they would like to see more sub-routes for the /48s permitted. The ISPs are sticking to the rules and saying NO. The ISPs are also handling the mutlihome routes through peerings currently. > > >| >Well, that's kinda hard, because IPv6 as defined simply >| >ingrains the problem. >| >| That's where we will never agree and I don't use the >word never to >| often. One possible solution to this statemate is for >| someone to define >| what exactly routing architecture would look like as a >| model. Then if >| we all agreed on that model each could apply that model to their >| favorite solution. I for one would look at extensions to >| IPv6 that are >| quite possible and there are many places to define >| extensions (e.g. DST >| Options, Hop-by-Hop, Next Headers new formats). > > >Jim, if you're going to be so closed minded as to say that we >will never agree, then I don't see how you can reasonably >expect anyone to change the architecture. Not being closed minded. But taking a stand. IPv6 exists it is being deployed and cannot be changed in 2460, 2461, 2462, and others. Applications are being ported. The point is the product has been shipped work with the product. If you can't then by all means compete against it. The locator and identifier has been discussed many times it has not born fruit and it is not going to happen with a change to 2460. I personally don't buy the entire notion. That's just my view and I am free to have it and state it and your free to state yours. That's a good thing. > Multihoming can >never be a first class citizen in the architecture if you do >not divorce the 'locator' from the 'identifier'. And that's >what IPv6 insists on today. If we continue down that path, >then the only alternatives are: I don't agree at all. > >1) Forbid multihoming. Not gonna happen. Agreed. > >2) All multihomed sites get global addresses and the routing >subsystem implodes. This is the only way to get a single >'identifier' and then use it for 'location' across all of my >exit paths. I must advertise the route throughout the topology. I vote for #2 above but I do not believe the routing subsystem will implode, it will just require faster/better routers, and peerings. But we should look at the problem further to see if it can be optimized with a change to the semantics of the v6 address. >3) Change the semantics of a v6 address. So you are not suggesting a syntax change only semantics to the 128bits? But I don't believe location and identification should be different. The address should be overloaded to support both context.I believe that is possible. The address is both a location and an identifier. The IPv6 address supports location top down from the left most bits for routing. So I believe what you ask exists now. Do you agree with the way we have stated the multi6 problem? Regards, /jim From owner-multi6@ops.ietf.org Sat Mar 15 21:52:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03434 for ; Sat, 15 Mar 2003 21:52:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uOIT-0007es-00 for multi6-data@psg.com; Sat, 15 Mar 2003 18:54:49 -0800 Received: from mailout.zma.compaq.com ([161.114.64.104] helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18uOIQ-0007ed-00 for multi6@ops.ietf.org; Sat, 15 Mar 2003 18:54:46 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id F0629148D; Sat, 15 Mar 2003 21:54:45 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sat, 15 Mar 2003 21:54:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Again no multi6 at IETF#56 Date: Sat, 15 Mar 2003 21:54:45 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03241037@tayexc13.americas.cpqcorp.net> Thread-Topic: Again no multi6 at IETF#56 Thread-Index: AcLrWbMaLEzFb5pYT0Ghu5DnqhzfxQADCQEw From: "Bound, Jim" To: "Masataka Ohta" , "Michel Py" Cc: "Tony Li" , "Randy Bush" , "Kurt Erik Lindqvist" , "Bob Hinden" , X-OriginalArrivalTime: 16 Mar 2003 02:54:45.0898 (UTC) FILETIME=[66D1CEA0:01C2EB67] 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 VAA03434 >Production level v6 address assignment can begin as soon as >we agree on a multihomed solution. Production addresses are now being handed out now to ISPs and ISPs to end users. None of us here and can stop that it is not our decision. I won't go into the reasons why it is happening but it is and far more than most would imagine. But, no one is putting IPv6 in production mode at this point. The reason is that more testing is required and more applications to be ported. That is what is happening now from places I know in Asia, U.S. and Europe. The first production use of IPv6 will be 3GPP IM subsystem and I believe by this time next year it will exists. But we have thought that before so we will see. > >Is it OK, Jim? Multihoming is clearly documented to be a problem area. Any user I know is aware of the problem. But it is perceived to be an ISP problem mostly. I think it is more than an ISP problem but a routing architecture problem (on that Tony and I do agree). Even large user sites will have multihome issues before packets even enter the public Internet. For those facing this now with some test bed deployment where their organizations are multihomed and those tests involve multiple ISPs and remote geography, the only solution is peering and they will use the essence of 3178 till there is a mutli-home solution. IPv6 deployment will not wait for multi-homing to be solved. But, Ipv6 deployment is not today far enough a long that a quick and expedient solution would be possible at the intersection from test bed deployment to wide production deployment. More importantly what I believe will bust open is home use with IPv6. If multi6 can deliver a multi-home set of answers in stages with step 1, step 2, step 3, do not break IPv6 applications in process, and do not break the IPv6 address it will integrate well into the current deployment. But for anyone to believe we have time to completely revamp IPv6 or the market will buy into it, I think is wishful thinking not grounded in reality. Regards, /jim > > Masataka Ohta > From owner-multi6@ops.ietf.org Sun Mar 16 00:13:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05739 for ; Sun, 16 Mar 2003 00:13:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uQUE-000KX6-00 for multi6-data@psg.com; Sat, 15 Mar 2003 21:15:06 -0800 Received: from wl-131-230.wireless.ietf56.ietf.org ([130.129.131.230] helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18uQUC-000KWr-00 for multi6@ops.ietf.org; Sat, 15 Mar 2003 21:15:04 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2G5GKKW002675; Sun, 16 Mar 2003 06:16:22 +0100 (CET) Date: Sun, 16 Mar 2003 06:16:20 +0100 Subject: Re: Again no multi6 at IETF#56 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Iljitsch van Beijnum , multi6@ops.ietf.org To: Masataka Ohta From: Kurt Erik Lindqvist In-Reply-To: <200303141503.AAA06731@necom830.hpcl.titech.ac.jp> Message-Id: <6C10343E-576E-11D7-B6B3-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.9 required=5.0 tests=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 think you need to go and check the RIR policies. They are not the >> same. They are similar, but not the same. > > They don't have to be similar but they have to be consistent. Which is what I meant and what they are. >> Besides that, the RIRs have a similar policy in order not create >> competition for a resource that is considered limited and i order to >> limit routing table growth (the problem that is trying to be solved by >> having the IETF set the policy) . If the resource is not limited and >> routing table growth is not an issue, let each RIR set their own >> policy. > > Wrong. If the resource is not limited and routing table growth is > not an issue, don't let each RIR set their own policy. Just assign > as much resource as demanded. The resource is limited. - kurtis - From owner-multi6@ops.ietf.org Sun Mar 16 00:45:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06296 for ; Sun, 16 Mar 2003 00:45:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uQyu-000NOG-00 for multi6-data@psg.com; Sat, 15 Mar 2003 21:46:48 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 18uQyo-000NO1-00; Sat, 15 Mar 2003 21:46:43 -0800 From: Masataka Ohta Message-Id: <200303160540.OAA14025@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id OAA14025; Sun, 16 Mar 2003 14:40:09 +0900 Subject: Re: Again no multi6 at IETF#56 In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03241036@tayexc13.americas.cpqcorp.net> from "Bound, Jim" at "Mar 15, 2003 09:36:13 pm" To: "Bound, Jim" Date: Sun, 16 Mar 2003 14:40:08 +0859 () CC: Tony Li , Michel Py , Randy Bush , Kurt Erik Lindqvist , Bob Hinden , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-0.7 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Jim; > >A new industry consortia is now in charge of IPv6? Please, > >point us at it. Figuring it out here is 'challenging'. > > If this and many other specs do not begin to produce solutions in a > timely manner then I predict there will be a deployment body for IPv6 to > go work on those specs and send them to the IETF but not with the > intention of waiting for 4 years for them to complete but implement and > work the IETF at same time. So my statement was the result of an "if". 4 years? 8 years have already wasted because some people has been believing leagacy IPv6 were deployable. Masataka Ohta From owner-multi6@ops.ietf.org Sun Mar 16 00:45:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06310 for ; Sun, 16 Mar 2003 00:45:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uQye-000NMC-00 for multi6-data@psg.com; Sat, 15 Mar 2003 21:46:32 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 18uQyb-000NJv-00 for multi6@ops.ietf.org; Sat, 15 Mar 2003 21:46:30 -0800 From: Masataka Ohta Message-Id: <200303160533.OAA14009@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id OAA14009; Sun, 16 Mar 2003 14:33:02 +0900 Subject: Re: Again no multi6 at IETF#56 In-Reply-To: <6C10343E-576E-11D7-B6B3-000393AB1404@kurtis.pp.se> from Kurt Erik Lindqvist at "Mar 16, 2003 06:16:20 am" To: Kurt Erik Lindqvist Date: Sun, 16 Mar 2003 14:33:02 +0859 () CC: Iljitsch van Beijnum , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-1.0 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Kurt; > >> I think you need to go and check the RIR policies. They are not the > >> same. They are similar, but not the same. > > > > They don't have to be similar but they have to be consistent. > > Which is what I meant and what they are. How can you be sure they are consistent? Note that they may not be similar. > >> Besides that, the RIRs have a similar policy in order not create > >> competition for a resource that is considered limited and i order to > >> limit routing table growth (the problem that is trying to be solved by > >> having the IETF set the policy) . If the resource is not limited and > >> routing table growth is not an issue, let each RIR set their own > >> policy. > > > > Wrong. If the resource is not limited and routing table growth is > > not an issue, don't let each RIR set their own policy. Just assign > > as much resource as demanded. > > The resource is limited. Then, we need some policy to deny some assignment based on the technical reasoning on why, how and how seriously the resource is limited. Masataka Ohta From owner-multi6@ops.ietf.org Sun Mar 16 00:54:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06447 for ; Sun, 16 Mar 2003 00:54:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uR8U-000OUR-00 for multi6-data@psg.com; Sat, 15 Mar 2003 21:56:42 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 18uR8R-000OUD-00; Sat, 15 Mar 2003 21:56:40 -0800 From: Masataka Ohta Message-Id: <200303160550.OAA14089@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id OAA14089; Sun, 16 Mar 2003 14:50:13 +0900 Subject: Re: Again no multi6 at IETF#56 In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03241037@tayexc13.americas.cpqcorp.net> from "Bound, Jim" at "Mar 15, 2003 09:54:45 pm" To: "Bound, Jim" Date: Sun, 16 Mar 2003 14:50:12 +0859 () CC: Michel Py , Tony Li , Randy Bush , Kurt Erik Lindqvist , Bob Hinden , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-1.0 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Jim; > >Production level v6 address assignment can begin as soon as > >we agree on a multihomed solution. > > Production addresses are now being handed out now to ISPs and ISPs to > end users. No. Production means QUANTITY. > I won't go into the reasons why it is happening but it is and far more > than most would imagine. I fully agree with you. It has been and is happening for these 8 years and will continue to be happening for next 8 years. > The first production use of IPv6 will be > 3GPP IM subsystem and I believe by this time next year it will exists. 3GPP has nothing to do with the Internet. The world largest deployment of mobile-capable IPv6 Internet is our LIN6-based project in Kyoto with hundreds of wireless base stations (but, with little users, because the base stations are, of course, IPv4 capable). > >Is it OK, Jim? > > Multihoming is clearly documented to be a problem area. Any user I know > is aware of the problem. But it is perceived to be an ISP problem > mostly. Then, it is a problem of RIRs, collections of ISPs. problem is solved. > For those facing this now with some test bed deployment where their As the problem is scalability, test bed, which means small scale, deployment is helpless. > IPv6 deployment will not wait for multi-homing to be solved. Then, what has been waited for? > More importantly what I believe will > bust open is home use with IPv6. Some may use IPv6 at research labo. Very few at home. Masataka Ohta From owner-multi6@ops.ietf.org Sun Mar 16 01:18:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06733 for ; Sun, 16 Mar 2003 01:18:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uRV7-0000o1-00 for multi6-data@psg.com; Sat, 15 Mar 2003 22:20:05 -0800 Received: from wl-131-230.wireless.ietf56.ietf.org ([130.129.131.230] helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18uRUz-0000nC-00; Sat, 15 Mar 2003 22:19:57 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2G6KwKW002991; Sun, 16 Mar 2003 07:20:59 +0100 (CET) Date: Sun, 16 Mar 2003 07:20:57 +0100 Subject: Re: Again no multi6 at IETF#56 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Masataka Ohta , Bob Hinden , Randy Bush , multi6@ops.ietf.org To: David Conrad From: Kurt Erik Lindqvist In-Reply-To: Message-Id: <7368EB72-5777-11D7-B6B3-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) 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 > Yes. However, the RIRs have come under significant criticism in the > past for being perceived as road blocks to IPv6 allocations and have, > in fact, reduced the requirements for v6 space. Even in this list, > they are criticized for making obtaining address space 'hard'. > > Seems they are damned if they do and damned if they don't. The RIRs had a period of a complete open policy that I think lasted for two years. 200 applied. I wouldn't blame the RIRs. - kurtis - From owner-multi6@ops.ietf.org Sun Mar 16 01:38:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07034 for ; Sun, 16 Mar 2003 01:38:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uRoX-0002hF-00 for multi6-data@psg.com; Sat, 15 Mar 2003 22:40:09 -0800 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #1) id 18uRoV-0002h0-00 for multi6@ops.ietf.org; Sat, 15 Mar 2003 22:40:07 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 5B3DA34446; Sat, 15 Mar 2003 21:53: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 h2G6e6YB022331; Sat, 15 Mar 2003 22:40: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="us-ascii" Subject: RE: Again no multi6 at IETF#56 Date: Sat, 15 Mar 2003 22:40:05 -0800 Message-ID: Thread-Topic: Again no multi6 at IETF#56 Thread-Index: AcLpsd55ygf0lejTTlymDbEqBOsu6gAszEuwAAOkbxAAAjdfEAAEmiUAAAAoLFAADU7MwAAm+aTAAAlQT6A= From: "Tony Li" To: "Bound, Jim" , "Michel Py" , "Randy Bush" , "Kurt Erik Lindqvist" Cc: "Bob Hinden" , 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 BAA07034 Jim, | >3) Change the semantics of a v6 address. | | So you are not suggesting a syntax change only semantics | to the 128bits? Correct. If it matters, yes, I don't believe that the current IPv6 approach is the ultimately correct way of approaching things, but I'm not trying to cause a revolution here. Just prevent v6 from being a total waste of time. We can work with the 128 bits for now. | But I don't believe location and identification should be | different. The | address should be overloaded to support both context.I | believe that is | possible. The address is both a location and an | identifier. The IPv6 | address supports location top down from the left most bits | for routing. | So I believe what you ask exists now. I'm asking that we separate the identifier and the location. Can't do that if they're one and the same. I agree that the current semantics are one and the same today. This is exactly what makes multihoming hard. | Do you agree with the way we have stated the multi6 problem? Not particularly. But I can state it very succinctly: a host needs one identifier and multiple locators. Tony From owner-multi6@ops.ietf.org Sun Mar 16 01:42:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07091 for ; Sun, 16 Mar 2003 01:42:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uRtA-0003Jx-00 for multi6-data@psg.com; Sat, 15 Mar 2003 22:44:56 -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 #1) id 18uRt8-0003Ji-00 for multi6@ops.ietf.org; Sat, 15 Mar 2003 22:44:54 -0800 Content-class: urn:content-classes:message Subject: RE: Again no multi6 at IETF#56 Date: Sat, 15 Mar 2003 22:44:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <963621801C6D3E4A9CF454A1972AE8F5045511@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Thread-Topic: Again no multi6 at IETF#56 Thread-Index: AcLpsd55ygf0lejTTlymDbEqBOsu6gAszEuwAAOkbxAAAjdfEAAEmiUAAAAoLFAADU7MwAAm+aTAAAlQT6AAAFXY8A== From: "Michel Py" To: "Tony Li" , "Bound, Jim" , "Randy Bush" , "Kurt Erik Lindqvist" Cc: "Bob Hinden" , 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 BAA07091 > Tony Li wrote: > Not particularly. But I can state it very succinctly: > a host needs one identifier and multiple locators. Mmmm. This sounds familiar. Michel. From owner-multi6@ops.ietf.org Sun Mar 16 06:48:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23007 for ; Sun, 16 Mar 2003 06:48:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uWe0-00083y-00 for multi6-data@psg.com; Sun, 16 Mar 2003 03:49:36 -0800 Received: from mailout.zma.compaq.com ([161.114.64.105] helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18uWdu-000827-00 for multi6@ops.ietf.org; Sun, 16 Mar 2003 03:49:30 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 9A2FC106E; Sun, 16 Mar 2003 06:49:29 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 16 Mar 2003 06:49:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Again no multi6 at IETF#56 Date: Sun, 16 Mar 2003 06:49:29 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCCB5@tayexc13.americas.cpqcorp.net> Thread-Topic: Again no multi6 at IETF#56 Thread-Index: AcLrhwTL0tCZijLpQ8uEmI+mNIxniwAKtGpQ From: "Bound, Jim" To: "Masataka Ohta" Cc: "Tony Li" , "Michel Py" , "Randy Bush" , "Kurt Erik Lindqvist" , "Bob Hinden" , X-OriginalArrivalTime: 16 Mar 2003 11:49:29.0482 (UTC) FILETIME=[1A2036A0:01C2EBB2] X-Spam-Status: No, hits=0.3 required=5.0 tests=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 GAA23007 You don't get it. Your own country has IPv6 deployed as I depicted in your native backbone. You never will get it I fear. Hope I can talk to you face to face a the IETF to see if we can resolve. I have a kanto sword given to me my martial arts master should I bring it :--) /jim > -----Original Message----- > From: Masataka Ohta [mailto:mohta@necom830.hpcl.titech.ac.jp] > Sent: Sunday, March 16, 2003 12:41 AM > To: Bound, Jim > Cc: Tony Li; Michel Py; Randy Bush; Kurt Erik Lindqvist; Bob > Hinden; multi6@ops.ietf.org > Subject: Re: Again no multi6 at IETF#56 > > > Jim; > > > >A new industry consortia is now in charge of IPv6? Please, > > >point us at it. Figuring it out here is 'challenging'. > > > > If this and many other specs do not begin to produce solutions in a > > timely manner then I predict there will be a deployment > body for IPv6 > > to go work on those specs and send them to the IETF but not > with the > > intention of waiting for 4 years for them to complete but implement > > and work the IETF at same time. So my statement was the > result of an > > "if". > > 4 years? > > 8 years have already wasted because some people has been > believing leagacy IPv6 were deployable. > > Masataka Ohta > From owner-multi6@ops.ietf.org Sun Mar 16 06:51:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23071 for ; Sun, 16 Mar 2003 06:51:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uWhx-0008XI-00 for multi6-data@psg.com; Sun, 16 Mar 2003 03:53:41 -0800 Received: from mailout.zma.compaq.com ([161.114.64.103] helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18uWhv-0008X2-00 for multi6@ops.ietf.org; Sun, 16 Mar 2003 03:53:39 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id D54423A67; Sun, 16 Mar 2003 06:53:38 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 16 Mar 2003 06:53:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Again no multi6 at IETF#56 Date: Sun, 16 Mar 2003 06:53:38 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCCB6@tayexc13.americas.cpqcorp.net> Thread-Topic: Again no multi6 at IETF#56 Thread-Index: AcLpsd55ygf0lejTTlymDbEqBOsu6gAszEuwAAOkbxAAAjdfEAAEmiUAAAAoLFAADU7MwAAm+aTAAAlQT6AACxaRAA== From: "Bound, Jim" To: "Tony Li" , "Michel Py" , "Randy Bush" , "Kurt Erik Lindqvist" Cc: "Bob Hinden" , X-OriginalArrivalTime: 16 Mar 2003 11:53:38.0779 (UTC) FILETIME=[AEB7EAB0:01C2EBB2] 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 GAA23071 Tony, Could you write up your technical idea without a lot of man hours to describe and why it solves the multihome problem. I would listen for one. But I am suspect of the entire notion of the separation, which just being technically accute having heard many solutions to this over the years. This could not be agreed on regardless of IPv6 all the way back to NIMROD, which had nothing to do with IPv6. /jim > -----Original Message----- > From: Tony Li [mailto:Tony.Li@procket.com] > Sent: Sunday, March 16, 2003 1:40 AM > To: Bound, Jim; Michel Py; Randy Bush; Kurt Erik Lindqvist > Cc: Bob Hinden; multi6@ops.ietf.org > Subject: RE: Again no multi6 at IETF#56 > > > > Jim, > > | >3) Change the semantics of a v6 address. > | > | So you are not suggesting a syntax change only semantics > | to the 128bits? > > > Correct. If it matters, yes, I don't believe that the > current IPv6 approach is the ultimately correct way of > approaching things, but I'm not trying to cause a revolution > here. Just prevent v6 from being a total waste of time. We > can work with the 128 bits for now. > > > | But I don't believe location and identification should be > | different. The > | address should be overloaded to support both context.I > | believe that is > | possible. The address is both a location and an > | identifier. The IPv6 > | address supports location top down from the left most bits > | for routing. > | So I believe what you ask exists now. > > > I'm asking that we separate the identifier and the location. > Can't do that if they're one and the same. I agree that the > current semantics are one and the same today. This is > exactly what makes multihoming hard. > > > | Do you agree with the way we have stated the multi6 problem? > > > Not particularly. But I can state it very succinctly: a host > needs one identifier and multiple locators. > > Tony > > From owner-multi6@ops.ietf.org Sun Mar 16 06:58:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23198 for ; Sun, 16 Mar 2003 06:58:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uWoV-0009CP-00 for multi6-data@psg.com; Sun, 16 Mar 2003 04:00:27 -0800 Received: from mailout.zma.compaq.com ([161.114.64.104] helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18uWoR-0009C6-00 for multi6@ops.ietf.org; Sun, 16 Mar 2003 04:00:23 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id F341897E; Sun, 16 Mar 2003 07:00:22 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 16 Mar 2003 07:00:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Again no multi6 at IETF#56 Date: Sun, 16 Mar 2003 07:00:22 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0324103C@tayexc13.americas.cpqcorp.net> Thread-Topic: Again no multi6 at IETF#56 Thread-Index: AcLriVywCBOcP6kuSzC7WL5xRFn18AAKZ+sg From: "Bound, Jim" To: "Masataka Ohta" Cc: "Michel Py" , "Tony Li" , "Randy Bush" , "Kurt Erik Lindqvist" , "Bob Hinden" , X-OriginalArrivalTime: 16 Mar 2003 12:00:22.0904 (UTC) FILETIME=[9F987F80:01C2EBB3] X-Spam-Status: No, hits=1.8 required=5.0 tests=CASHCASHCASH,QUOTED_EMAIL_TEXT,SPAM_PHRASE_02_03 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 GAA23198 Masataka, > > Production addresses are now being handed out now to ISPs > and ISPs to > > end users. > > No. > > Production means QUANTITY. Production to me means USE. > > > I won't go into the reasons why it is happening but it is > and far more > > than most would imagine. > > I fully agree with you. It has been and is happening for > these 8 years and will continue to be happening for next 8 years. > > > The first production use of IPv6 will be > > 3GPP IM subsystem and I believe by this time next year it > will exists. > > 3GPP has nothing to do with the Internet. Yes it does. It is doing it in baby steps with IM system. > > The world largest deployment of mobile-capable IPv6 Internet > is our LIN6-based project in Kyoto with hundreds of wireless > base stations (but, with little users, because the base > stations are, of course, IPv4 capable). Yes. But that will change. I believe this will overrule 3GPP too. > > > >Is it OK, Jim? > > > > Multihoming is clearly documented to be a problem area. Any user I > > know is aware of the problem. But it is perceived to be an ISP > > problem mostly. > > Then, it is a problem of RIRs, collections of ISPs. > problem is solved. But the deployment will not stop nor does it have to thusb far. > > > For those facing this now with some test bed deployment where their > > As the problem is scalability, test bed, which means small > scale, deployment is helpless. Not clear to me this is true. > > > IPv6 deployment will not wait for multi-homing to be solved. > > Then, what has been waited for? $$$$$$$$$$$$$$$$$$$$$$$$$ > > > More importantly what I believe will > > bust open is home use with IPv6. > > Some may use IPv6 at research labo. Very few at home. I believe that will change and maybe in the U.S. first. /jim > > Masataka Ohta > From owner-multi6@ops.ietf.org Sun Mar 16 07:02:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23295 for ; Sun, 16 Mar 2003 07:02:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uWsU-0009kQ-00 for multi6-data@psg.com; Sun, 16 Mar 2003 04:04:34 -0800 Received: from mailout.zma.compaq.com ([161.114.64.105] helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18uWsO-0009f2-00 for multi6@ops.ietf.org; Sun, 16 Mar 2003 04:04:28 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id EC8B8510F; Sun, 16 Mar 2003 07:04:27 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 16 Mar 2003 07:04:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Again no multi6 at IETF#56 Date: Sun, 16 Mar 2003 07:04:27 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCCBA@tayexc13.americas.cpqcorp.net> Thread-Topic: Again no multi6 at IETF#56 Thread-Index: AcLrhwTL0tCZijLpQ8uEmI+mNIxniwAKtGpQAACNcCA= From: "Bound, Jim" To: "Bound, Jim" , "Masataka Ohta" Cc: "Tony Li" , "Michel Py" , "Randy Bush" , "Kurt Erik Lindqvist" , "Bob Hinden" , X-OriginalArrivalTime: 16 Mar 2003 12:04:27.0851 (UTC) FILETIME=[319871B0:01C2EBB4] X-Spam-Status: No, hits=1.7 required=5.0 tests=FROM_AND_TO_SAME_6,QUOTED_EMAIL_TEXT,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 HAA23295 Errrr forget that I will never get through baggage check :---) Leaving now. But we all have to compromise or this will not get done. /jim > -----Original Message----- > From: Bound, Jim > Sent: Sunday, March 16, 2003 6:49 AM > To: 'Masataka Ohta' > Cc: Tony Li; Michel Py; Randy Bush; Kurt Erik Lindqvist; Bob > Hinden; multi6@ops.ietf.org > Subject: RE: Again no multi6 at IETF#56 > > > You don't get it. Your own country has IPv6 deployed as I > depicted in your native backbone. You never will get it I > fear. Hope I can talk to you face to face a the IETF to see > if we can resolve. I have a kanto sword given to me my > martial arts master should I bring it :--) > > /jim > > > > > > -----Original Message----- > > From: Masataka Ohta [mailto:mohta@necom830.hpcl.titech.ac.jp] > > Sent: Sunday, March 16, 2003 12:41 AM > > To: Bound, Jim > > Cc: Tony Li; Michel Py; Randy Bush; Kurt Erik Lindqvist; Bob > > Hinden; multi6@ops.ietf.org > > Subject: Re: Again no multi6 at IETF#56 > > > > > > Jim; > > > > > >A new industry consortia is now in charge of IPv6? > Please, point > > > >us at it. Figuring it out here is 'challenging'. > > > > > > If this and many other specs do not begin to produce > solutions in a > > > timely manner then I predict there will be a deployment > > body for IPv6 > > > to go work on those specs and send them to the IETF but not > > with the > > > intention of waiting for 4 years for them to complete but > implement > > > and work the IETF at same time. So my statement was the > > result of an > > > "if". > > > > 4 years? > > > > 8 years have already wasted because some people has been > > believing leagacy IPv6 were deployable. > > > > Masataka Ohta > > > From owner-multi6@ops.ietf.org Sun Mar 16 10:05:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26196 for ; Sun, 16 Mar 2003 10:05:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uZiX-0004aV-00 for multi6-data@psg.com; Sun, 16 Mar 2003 07:06:29 -0800 Received: from ipl-67-0142.pppoe.stargate.net ([206.210.67.142] helo=localhost) by psg.com with esmtp (Exim 3.36 #1) id 18uZiV-0004aD-00 for multi6@ops.ietf.org; Sun, 16 Mar 2003 07:06:28 -0800 Received: from [192.168.1.100] (localhost [127.0.0.1]) by localhost (8.12.7/8.12.2) with ESMTP id h2GF6Ut6002202; Sun, 16 Mar 2003 10:06:30 -0500 (EST) Date: Sun, 16 Mar 2003 10:06:29 -0500 From: "Michael H. Lambert" To: "Bound, Jim" cc: multi6@ops.ietf.org Subject: RE: Again no multi6 at IETF#56 Message-ID: <3996181.1047809189@[192.168.1.100]> In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03241037@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B03241037@tayexc13.americas.cpqc orp.net> X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 --On Saturday, 15 March 2003 21:54 -0500 "Bound, Jim" wrote: > IPv6 deployment will not wait for multi-homing to be solved. [...] I don't think multi-homing will wait for multi-homing to be solved, either. I'm sure there are many sites out there, not "knowing" there are problems with MH, that will blindly multi-home using PA addresses. And I bet many of them will be quite happy. What we need are reports of operational experience with PA MH. Michael +-----------------------------------------------------------------------+ | Michael H. Lambert, Network Engineer Phone: +1 412 268-4960 | | Pittsburgh Supercomputing Center FAX: +1 412 268-8200 | | 4400 Fifth Avenue, Pittsburgh, PA 15213 lambert@psc.edu | +-----------------------------------------------------------------------+ From owner-multi6@ops.ietf.org Sun Mar 16 10:22:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27496 for ; Sun, 16 Mar 2003 10:22:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ua0E-0006ek-00 for multi6-data@psg.com; Sun, 16 Mar 2003 07:24:46 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18ua0C-0006eW-00 for multi6@ops.ietf.org; Sun, 16 Mar 2003 07:24:44 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2GFNhj84224; Sun, 16 Mar 2003 16:23:43 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Sun, 16 Mar 2003 16:23:43 +0100 (CET) From: Iljitsch van Beijnum To: "Bound, Jim" cc: Subject: Identifier/locator recap In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCCB6@tayexc13.americas.cpqcorp.net> Message-ID: <20030316160246.F69506-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, 16 Mar 2003, Bound, Jim wrote: > Could you write up your technical idea without a lot of man hours to > describe and why it solves the multihome problem. I'm not Tony, but: Traditional multihoming as is done in IPv4 will not scale. An alternative is to give each host in a multihomed site an address for each ISP the site is connected to. When (the link to) one ISP fails, the communciation is diverted over the other ISP. However, current transport protocols are unable to jump to new addresses in mid-session. Solution: separate the identifier and locator functions of the IP address. Transport protocols then use the identifier, which doesn't change during the lifetime of the session, while IP uses the locator, which may be changed at any time in order to route around broken parts of the network. A few things that need to be addressed to make this happen: - Locators must always be present in each packet. But what about the identifiers? Do we include them in each packet (= tunneling) or are they implied? - How do we discover identifiers and/or locators? - How to we authenticate the relationship between locators and identifiers? There is also the question of what makes good identifiers. HIP uses the fingerprint of a cryptographic key. MHAP uses provider-independent IPv6 addresses that aren't visible in the global routing table. I myself have suggested to use FQDNs as the first choice. Note that there seems consensus here that we shouldn't try to revive GSE or 8+8: some kind of "16+16" would be much easier to deploy. Iljitsch From owner-multi6@ops.ietf.org Sun Mar 16 12:21:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29936 for ; Sun, 16 Mar 2003 12:21:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ubpA-000KFN-00 for multi6-data@psg.com; Sun, 16 Mar 2003 09:21:28 -0800 Received: from gnat.inet.org ([63.108.254.91]) by psg.com with esmtp (Exim 3.36 #1) id 18ubp7-000KFA-00 for multi6@ops.ietf.org; Sun, 16 Mar 2003 09:21:25 -0800 Received: from extremenetworks.com (unknown [10.0.8.94]) by gnat.inet.org (Postfix) with ESMTP id 0567F67105 for ; Sun, 16 Mar 2003 12:38:19 -0500 (EST) Date: Sun, 16 Mar 2003 12:21:19 -0500 Subject: Re: Identifier/locator recap Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: RJ Atkinson To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit In-Reply-To: <20030316160246.F69506-100000@sequoia.muada.com> Message-Id: X-Mailer: Apple Mail (2.551) 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 Sunday, Mar 16, 2003, at 10:23 America/Montreal, Iljitsch van Beijnum wrote: > Note that there seems consensus here that we shouldn't try to revive > GSE > or 8+8: some kind of "16+16" would be much easier to deploy. It is not clear to me that this group has consensus on anything other than: "The current IPv4/IPv6 multihoming approach does not scale adequately." Ran From owner-multi6@ops.ietf.org Sun Mar 16 12:57:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00788 for ; Sun, 16 Mar 2003 12:57:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ucPR-000MXN-00 for multi6-data@psg.com; Sun, 16 Mar 2003 09:58:57 -0800 Received: from [130.129.131.230] (helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18ucPP-000MWZ-00 for multi6@ops.ietf.org; Sun, 16 Mar 2003 09:58:55 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2GHw0KW003761; Sun, 16 Mar 2003 18:58:01 +0100 (CET) Date: Sun, 16 Mar 2003 18:57:59 +0100 Subject: Re: Again no multi6 at IETF#56 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Iljitsch van Beijnum , multi6@ops.ietf.org To: Masataka Ohta From: Kurt Erik Lindqvist In-Reply-To: <200303160533.OAA14009@necom830.hpcl.titech.ac.jp> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.9 required=5.0 tests=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 think you need to go and check the RIR policies. They are not the >>>> same. They are similar, but not the same. >>> >>> They don't have to be similar but they have to be consistent. >> >> Which is what I meant and what they are. > > How can you be sure they are consistent? Note that they may not > be similar. I know the three policies fairly well. They are not similar but they are fairly consistent. They are at least not diverse enough to create competition among the RIRs (which is what started this part of the thread). > >>>> Besides that, the RIRs have a similar policy in order not create >>>> competition for a resource that is considered limited and i order to >>>> limit routing table growth (the problem that is trying to be solved >>>> by >>>> having the IETF set the policy) . If the resource is not limited and >>>> routing table growth is not an issue, let each RIR set their own >>>> policy. >>> >>> Wrong. If the resource is not limited and routing table growth is >>> not an issue, don't let each RIR set their own policy. Just assign >>> as much resource as demanded. >> >> The resource is limited. > > Then, we need some policy to deny some assignment based on the > technical reasoning on why, how and how seriously the resource > is limited. > The resource is limited as there is a fixed number of addresses. The RIRs was created to handled and manage policy for a limited resource. Let's use them for that. The IETF was created to develop standards let them handle that. I fail to see what problem you are trying to point out here. - kurtis - From owner-multi6@ops.ietf.org Sun Mar 16 13:00:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00868 for ; Sun, 16 Mar 2003 13:00:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ucT3-000Mcw-00 for multi6-data@psg.com; Sun, 16 Mar 2003 10:02:41 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #1) id 18ucT0-000Mcj-00 for multi6@ops.ietf.org; Sun, 16 Mar 2003 10:02:39 -0800 Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.6/8.12.6) with ESMTP id h2GI2Fkw007582; Sun, 16 Mar 2003 13:02:15 -0500 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.6/8.12.6/Submit) id h2GI2FfW007581; Sun, 16 Mar 2003 13:02:15 -0500 Date: Sun, 16 Mar 2003 13:02:15 -0500 From: "J. Noel Chiappa" Message-Id: <200303161802.h2GI2FfW007581@ginger.lcs.mit.edu> To: Jim.Bound@hp.com, multi6@ops.ietf.org Subject: RE: Again no multi6 at IETF#56 Cc: hinden@iprg.nokia.com, 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: "Bound, Jim" > I am suspect of the entire notion of the separation, which just being > technically accute having heard many solutions to this over the years. Those many solutions would includ MIPv6, right Jim? Noel From owner-multi6@ops.ietf.org Sun Mar 16 14:24:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03531 for ; Sun, 16 Mar 2003 14:24:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18udlV-000PVQ-00 for multi6-data@psg.com; Sun, 16 Mar 2003 11:25:49 -0800 Received: from smtp03.uc3m.es ([163.117.136.123] helo=smtp.uc3m.es) by psg.com with esmtp (Exim 3.36 #1) id 18udlS-000PVC-00 for multi6@ops.ietf.org; Sun, 16 Mar 2003 11:25:46 -0800 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 5DBE7432D5; Sun, 16 Mar 2003 20:25:47 +0100 (CET) Received: from vpn-252-65.uc3m.es (vpn-252-65.uc3m.es [163.117.252.65]) by smtp03.uc3m.es (Postfix) with ESMTP id 8F1F099DED; Sun, 16 Mar 2003 20:25:43 +0100 (CET) Subject: Re: comments on mipv6 application to multihoming [Re: Move forward] From: marcelo bagnulo To: Pekka Savola Cc: Iljitsch van Beijnum , multi6@ops.ietf.org In-Reply-To: References: Content-Type: text/plain Organization: uc3m Message-Id: <1047842492.789.380.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 16 Mar 2003 20:25:33 +0100 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_02_03 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pekka, Thank for your comments, they are very welcomed. > > Some jetlagged comments. > > substantial: > ------------ > Initial comment: the idea of the draft is to assess if MIPv6 can be used unmodified to support multi-homing. A possible conclusion of this analysis could be that it is not possible, but i am not sure that this is clear yet. > ==> The problem is that this mechanism only "works" (for some definition of > works) Preserves established sessions perhaps? > for sessions that are broken over 140 seconds This is an upper bound. I mean it can be reduced but it can not be increased. In order to reduce it all that it is needed is to increase the frequency of HoTI CoTI message exchange. This would indeed increase the overhead, and cost benefit analysis should be performed in order to obtain an optimal choice. What it can not be done is to have a longer detection period. But if i understand correctly you do not have a problem with this. Mechanism that provide a faster response to failures have to be included once that other problems have been solved (like the next one) > (ie. connection is not > aborted before that), with the upper bound of 420 seconds. This is the real problem IMO.The alternative address can only be used for a limited period (420 secs). Then you have to perform the RR procedure again to obtain new valid authorization data that is to be used for extending the lifetime of the new address. THis is a major problem since you can not perform the RR procedure because the HoA is no longer available. The solution for this would be to extend the lifetime of the binding but this may have security implications. you have previously worked in MIPv6 security, right? could you comment about the security concerns of extending this timer? > On top of that, > quite a bit of signalling is performed just in case that a link might go > down. e2e failure detection implies traffic exchange. It is important to discuss whether this overhead is acceptable or not. However this is not strictly related with the usage of MIP but with host based solutions IMO. I have studied an alternative for this in http://www.it.uc3m.es/marcelo/mhExtHdr.txt But it did present some other issues though... > > Needless to say, this doesn't seem to be all that useful, the tradeoffs > would seem to be quite overwhelming: especially the 140 seconds; I'd say > the outage of 10-20 seconds is the most that's acceptable for most > connections to stay properly alive. Great. THis part can be solved, i think. Higher frequency would provide this with an acceptable cost, i think. Specially when piggybacking is included in MIPv6. As i said earlier, if this is deemed acceptable, the message exchange for failure detection needs to be reasonably tuned. Moreover, probably adaptive mechanisms are needed to provide a reasonably good performance. But i think this can be done (once that other issues are solved, specially the 420 secs timer) > > ==> however, I appreciate thinking the whole thing through.. however, as > it is, the doc is quite heavy to read as it's full of gritty details > (which are nice when you want to get down to it, and verify it), but more > focus should be given to the big picture.. > > ==> there is a need for a shorter overview before section 4.3 > Ok, i'll try to do this > ==> sect 4.3 must be split into smaller pieces > > In the application scenario, according to [3], > > Site Exit Anycast Addresses for ISPA is > PA:Site:FFFF:FFFF:FFFF:FFFF:FFFF (Hereafter SEAAA) > > Site Exit Anycast Addresses for ISPB is > PB:Site:FFFF:FFFF:FFFF:FFFF:FFFF (Hereafter SEAAB) > > Then, MHH will try first to send a first packet with: > > ==> these values seem to be irrelevant, remove. > Btw, how does a node know the > prefix length of his site? Not an easy problem, unless it's guessing.. > Good point!!! An option is to consider that it is always a /48, but i don't thik this is a good approach. Another possibility is to assign the site exit routers anycast address of every subnet to the corresponding exit router and propagate it within the site as a host route. So hosts will address packets to its own subnet exit site router anycast address, which will be routed to the correspondent exit router. Since the explanation is not so clear i will put an example +----+ +----+ |R1 | |R2 | |P1::| |P2::| +----+ +----+ P1:Subnet1:Router1 | P2:Subnet2:Router2 | ------------------------------------- P1:Subnet1:Router3 | P2:Subnet2:Router3 | +----+ |R3 | +----+ P1:Subnet3:Router3 | P2:Subnet4:Router3 | ----------------------------------- P1:Subnet3:Host | P2:Subnet4:Host | +----+ |Host| +----+ So Addresses P1:Subnet1:FFFF:FFFF:FFFF:FFFF and P1:Subnet3:FFFF:FFFF:FFFF:FFFF are assigned to R1. P1:Subnet3:FFFF:FFFF:FFFF:FFFF is announced within the site as a host route to R1 Addresses P2:Subnet2:FFFF:FFFF:FFFF:FFFF and P2:Subnet4:FFFF:FFFF:FFFF:FFFF are assigned to R2. P2:Subnet4:FFFF:FFFF:FFFF:FFFF is announced within the site as a host route to R2 So when Host sends a packet whose source address contains the prefix P1, it includes a routing header with P1:Subnet3:FFFF:FFFF:FFFF:FFFF which is deduced from its own prefix. Not very nice, but i guess this would work, don't you? > editorials: > ----------- > will fix, thanks. Thanks again for your feedback, regards, marcelo > Application of the MIPv6 protocol to the multi-homing problem > > ==> uppercase the first chars of the most words > ==> same goes for the section titles > > This note attempts to describe how to apply the MIPv6 protocol to > > ==> s/MIPv6/Mobile IPv6 (MIPv6)/ > > 1. Introduction > > ==> split the section; too long paragraphs are difficult to read > ==> actually, a lot of paragraphs should be split up > > 1- A path failure detection mechanism, that enables end-hosts to > > ==> s/,// > > 4.2.3 Required capability #1 > > ==> reqs should be listed in order or numbered differently > > alternative ISP is to be used for coursing packets. Source address > > ==> I'm not sure what you mean by "coursing" but I suggest using another :-) > (many other places..) > > the second message. IF this is the case, a BU message is sent, > > ==> s/IF/If/ > > Finally, this solution does not requires that multi-homed sites to > > ==> s/requires that/require/ > > References > > [1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in > IPv6", Internet Draft, Work in progress, May 2002. > > ==> split the refs > ==> s/J. Arkko/Arkko, J./ (same everywhere) -- marcelo bagnulo uc3m From owner-multi6@ops.ietf.org Sun Mar 16 14:25:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03547 for ; Sun, 16 Mar 2003 14:25:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18udlR-000PV8-00 for multi6-data@psg.com; Sun, 16 Mar 2003 11:25:45 -0800 Received: from smtp02.uc3m.es ([163.117.136.122] helo=smtp.uc3m.es) by psg.com with esmtp (Exim 3.36 #1) id 18udlK-000PUf-00 for multi6@ops.ietf.org; Sun, 16 Mar 2003 11:25:39 -0800 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 4A58E432EA; Sun, 16 Mar 2003 20:25:41 +0100 (CET) Received: from vpn-252-65.uc3m.es (vpn-252-65.uc3m.es [163.117.252.65]) by smtp02.uc3m.es (Postfix) with ESMTP id BFBD499E14; Sun, 16 Mar 2003 20:25:37 +0100 (CET) Subject: Re: Move forward From: marcelo bagnulo To: Iljitsch van Beijnum Cc: Pekka Savola , multi6@ops.ietf.org In-Reply-To: <20030315203547.M69506-100000@sequoia.muada.com> References: <20030315203547.M69506-100000@sequoia.muada.com> Content-Type: text/plain Organization: uc3m Message-Id: <1047839560.789.282.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 16 Mar 2003 20:25:27 +0100 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.5 required=5.0 tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_03_05 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Iljitsch, Thanks you very much for your feedback. Comments below... > > Ok, some comments: > > - It looks like you want to authenticate the secondary address > beforehand when there is still return routability. Right. That is what MIPv6 does and the idea is to try to use without modifications (if possible) > But can you then > simply keep the secndary address in some kind of "hot standby" state > untill it is time to start using it and then use it for some > considerable amount of time without re-authentication? Does this work > and is it secure? Oh wait: "This is a major limitation for this > application, since the binding can not be refreshed until the original > route is restored and outages can last longer than 420 seconds." > There are two issues here that need to be differentiated: - First the Return Routability procedure provides BU authorization data that has a limited lifetime, so it is not permitted by the spec that you have an alternative address in "standby" as you reasonably suggest. MIPv6 spec demands the HoTI CoTI exchange to be performed periodically. This is cumbersome, but i think it can be used as a failure detection mechanism, which would provide an added value to the RR procedure in its application to multi-homing. - The second and really major problem is that you can only use the alternative address for a limited period (420 secs). Then you have to perform the RR procedure again to obtain new valid authorization data that is to be used for extending the lifetime of the new address. THis is a major problem since you can not perform the RR procedure because the HoA is no longer available. The solution for this would be to extend the lifetime of the binding but this may have security implications that have to be studied > - ICMP echo for keepalive wouldn't work. Not so much because of all the > broken firewalls that block them, but because the only thing an echo > reply tells you is that there is _someone_ present at the address, it > doesn't tell you who it is. (Ie dial user may have logged out and > another logged in and gotten the same address.) > Agree. I guess that the HoTI CoTI exchange is better suited for this application then. > - Why don't you look at the return traffic to see if the path is still > viable? If you keep (re)sending data but there is no reply from the > other side, something must be broken. This probably needs per-session > state, though. > A proposed extension for MIPv6 is the piggybacking of mobility messages in regular traffic. In this case you would use return traffic to transport signaling data. This kind of optimizations can be done. However this mechanism allows the it is used also in unidirectional traffic, which i guess is a good feature > - "If a failure has occurred along the path, the attempt to initiate > the communication will fail and the CN will try again with another > address. Eventually, a packet from CN will reach MHH." As this is > application-dependent you can't count on this. Worse: the all-time > most popular networked application typically chokes if the first address > tried doesn't work. > Good point. I do not have much data about how applications normally behave in this case. But if this is the case, this is an issue. However, AFAIK this is probably the case for IPv4 where interfaces usually have only one address configured. However in IPv6, considering "Default Address Selection mechanism" i was hoping that application used the list of addresses generated by the mechanism and try to use them to communicate > - Having to interact every 70 seconds may break sessions that would > otherwise remain intact. For instance, I often put my laptop to sleep > in the middle of a session to conserve the battery. When it wakes up, > my session is still ok because there was no communication during the > nap so the fact that my laptop was effecitvely disconnected didn't > matter. So lack of a HoT my not be an outage but simply saving > energy... Good point again. Perhaps additional intelligence could be included in the mechanism to cope with this, i will think it over. > > This is excellent work. It shows multihoming in IPv6 is just around the > corner, and not impossible as some people seem to believe. > Thanks :-) > However, I do see a problem: as this solution isn't well suited to > medium-sized and larger sites, indeed > and provides no compatibility with other > solutions that do cater to larger sites, I am not certain about this. We could study compatibility between solutions and see what happens. I guess that there is no compatibility problems between this solution and the classical IPv4 solution... :-) Really, This is very relevant point to consider seriously and i 'll try to study it. What solutions do you think i should consider? > implementing this as-is may not > bring as much benefit as we hope. After all, the majority of all > communication is with at least one non-small site. And I don't think > Google or some other huge site really wants to start doing MIP as a > mattoer of course on all those 200 msec TCP sessions just because the > other side is multihomed. Not so sure about that. I mean, Google only has to do the CN RO support, which will be probably included in most stacks (besides, probably Google will want to be accessed by mobile hosts) So, it will really won't be able to tell the difference whether this is a multi-homed host or a mobile host. > > So what I'd like to see is compatibility with one or more solutions that > are more suited for larger sites. But I guess the first thing we need > for that is one or more solutions that are ore suited for larger sites. :-) > Again i think this a very valid point and i will try to study compatibility with some of the solutions that we have Thanks again for your valuable feedback. marcelo > Iljitsch -- marcelo bagnulo uc3m From owner-multi6@ops.ietf.org Sun Mar 16 16:55:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09459 for ; Sun, 16 Mar 2003 16:55:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ug5y-0003I7-00 for multi6-data@psg.com; Sun, 16 Mar 2003 13:55:06 -0800 Received: from wl-134-243.wireless.ietf56.ietf.org ([130.129.134.243] helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18ug5v-0003Hh-00 for multi6@ops.ietf.org; Sun, 16 Mar 2003 13:55:04 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2GLuNKW004788; Sun, 16 Mar 2003 22:56:24 +0100 (CET) Date: Sun, 16 Mar 2003 22:56:22 +0100 Subject: Re: Again no multi6 at IETF#56 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Bound, Jim" , multi6@ops.ietf.org To: "Michael H. Lambert" From: Kurt Erik Lindqvist In-Reply-To: <3996181.1047809189@[192.168.1.100]> Message-Id: <20807807-57FA-11D7-B6B3-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.9 required=5.0 tests=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 >> IPv6 deployment will not wait for multi-homing to be solved. [...] > > I don't think multi-homing will wait for multi-homing to be solved, > either. I'm sure there are many sites out there, not "knowing" there > are problems with MH, that will blindly multi-home using PA addresses. > And I bet many of them will be quite happy. What we need are reports > of operational experience with PA MH. Not only that, but it also works very well. - kurtis - From owner-multi6@ops.ietf.org Sun Mar 16 17:16:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10059 for ; Sun, 16 Mar 2003 17:16:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ugSf-0003yE-00 for multi6-data@psg.com; Sun, 16 Mar 2003 14:18:33 -0800 Received: from hlm-c-06e6.mxs.adsl.euronet.nl ([212.129.134.230] helo=lavinia.baume.org) by psg.com with esmtp (Exim 3.36 #1) id 18ugSc-0003xy-00; Sun, 16 Mar 2003 14:18:30 -0800 Received: from localhost (pierre@localhost) by lavinia.baume.org (8.11.6/8.11.6) with ESMTP id h2GMIBW16791; Sun, 16 Mar 2003 23:18:11 +0100 Date: Sun, 16 Mar 2003 23:18:11 +0100 (CET) From: Pierre Baume To: Michel Py cc: Tony Li , "Bound, Jim" , Randy Bush , Kurt Erik Lindqvist , Bob Hinden , Subject: RE: Again no multi6 at IETF#56 In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F5045511@server2000.arneill-py.sacramento.ca.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,SPAM_PHRASE_00_01, USER_AGENT_PINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Michel, On Sat, 15 Mar 2003, Michel Py wrote: > > Tony Li wrote: > > Not particularly. But I can state it very succinctly: > > a host needs one identifier and multiple locators. > > Mmmm. This sounds familiar. > > Michel. Hrm, like in the dns system? Ducking and running... :p Pierre. From owner-multi6@ops.ietf.org Sun Mar 16 17:24:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10491 for ; Sun, 16 Mar 2003 17:24:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ugaA-0004FX-00 for multi6-data@psg.com; Sun, 16 Mar 2003 14:26:18 -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 #1) id 18uga7-0004FD-00 for multi6@ops.ietf.org; Sun, 16 Mar 2003 14:26:16 -0800 Content-class: urn:content-classes:message Subject: RE: Again no multi6 at IETF#56 Date: Sun, 16 Mar 2003 14:26:15 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <963621801C6D3E4A9CF454A1972AE8F54CCF@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Thread-Topic: Again no multi6 at IETF#56 Thread-Index: AcLsCfDEuTYgfKo/Q0qkmCy61AKnIAAAJ4jw From: "Michel Py" To: "Pierre Baume" Cc: "Tony Li" , "Bound, Jim" , "Randy Bush" , "Kurt Erik Lindqvist" , "Bob Hinden" , 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 RAA10491 Pierre, >>> Tony Li wrote: >>> Not particularly. But I can state it very succinctly: >>> a host needs one identifier and multiple locators. >> Michel Py wrote: >> Mmmm. This sounds familiar. > Pierre Baume wrote: > Hrm, like in the dns system? No, like in MHAP: http://arneill-py.sacramento.ca.us/ipv6mh/draft-py-mhap-intro-00.txt or like in HIP: draft-ietf-moskowitz-hip-05.txt Michel. From owner-multi6@ops.ietf.org Sun Mar 16 17:26:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10660 for ; Sun, 16 Mar 2003 17:26:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ugcX-0004LU-00 for multi6-data@psg.com; Sun, 16 Mar 2003 14:28:45 -0800 Received: from wl-134-243.wireless.ietf56.ietf.org ([130.129.134.243] helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18ugcV-0004LH-00 for multi6@ops.ietf.org; Sun, 16 Mar 2003 14:28:43 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2GMTcKW004866; Sun, 16 Mar 2003 23:29:46 +0100 (CET) Date: Sun, 16 Mar 2003 23:29:37 +0100 Subject: Re: Again no multi6 at IETF#56 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Pierre Baume" , "Tony Li" , "Bound, Jim" , "Randy Bush" , "Bob Hinden" , To: "Michel Py" From: Kurt Erik Lindqvist In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F54CCF@server2000.arneill-py.sacramento.ca.us> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) 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 >>>> Tony Li wrote: >>>> Not particularly. But I can state it very succinctly: >>>> a host needs one identifier and multiple locators. > >>> Michel Py wrote: >>> Mmmm. This sounds familiar. > >> Pierre Baume wrote: >> Hrm, like in the dns system? > > No, like in MHAP: > http://arneill-py.sacramento.ca.us/ipv6mh/draft-py-mhap-intro-00.txt > > or like in HIP: > draft-ietf-moskowitz-hip-05.txt > or 8+8 or 16+16 or GSE or.... - kurtis - From owner-multi6@ops.ietf.org Sun Mar 16 18:55:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13446 for ; Sun, 16 Mar 2003 18:55:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uhyv-000749-00 for multi6-data@psg.com; Sun, 16 Mar 2003 15:55:57 -0800 Received: from dmz1.procket.com ([65.174.124.36]) by psg.com with esmtp (Exim 3.36 #1) id 18uhyt-00073w-00 for multi6@ops.ietf.org; Sun, 16 Mar 2003 15:55:55 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 002F723C3E; Sun, 16 Mar 2003 16:20:44 -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 h2GNtrYB011524; Sun, 16 Mar 2003 15:55:54 -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="us-ascii" Subject: RE: Identifier/locator recap Date: Sun, 16 Mar 2003 15:55:53 -0800 Message-ID: Thread-Topic: Identifier/locator recap Thread-Index: AcLr0UUqrC8+DccjTRmkA6VIEiZiUAARgDuw From: "Tony Li" To: "Iljitsch van Beijnum" , "Bound, Jim" 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 SAA13446 Iljitsch, You did a fine impersonation. At this point, I'm quite happy not to sweat the 8+8/GSE/16+16 distinction. If we can get to consensus that we need separation of locators and identifiers, then we will have made good progress. Let's agree on the macro before we work out the micro. Tony | -----Original Message----- | From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] | Sent: Sunday, March 16, 2003 7:24 AM | To: Bound, Jim | Cc: multi6@ops.ietf.org | Subject: Identifier/locator recap | | | On Sun, 16 Mar 2003, Bound, Jim wrote: | | > Could you write up your technical idea without a lot of | man hours to | > describe and why it solves the multihome problem. | | I'm not Tony, but: | | Traditional multihoming as is done in IPv4 will not scale. | | An alternative is to give each host in a multihomed site | an address for | each ISP the site is connected to. When (the link to) one | ISP fails, the | communciation is diverted over the other ISP. However, | current transport | protocols are unable to jump to new addresses in | mid-session. Solution: | separate the identifier and locator functions of the IP address. | Transport protocols then use the identifier, which doesn't | change during | the lifetime of the session, while IP uses the locator, | which may be | changed at any time in order to route around broken parts of the | network. | | A few things that need to be addressed to make this happen: | | - Locators must always be present in each packet. But what | about the | identifiers? Do we include them in each packet (= | tunneling) or are | they implied? | | - How do we discover identifiers and/or locators? | | - How to we authenticate the relationship between locators and | identifiers? | | There is also the question of what makes good identifiers. | HIP uses the | fingerprint of a cryptographic key. MHAP uses | provider-independent IPv6 | addresses that aren't visible in the global routing table. | I myself have | suggested to use FQDNs as the first choice. | | Note that there seems consensus here that we shouldn't try | to revive GSE | or 8+8: some kind of "16+16" would be much easier to deploy. | | Iljitsch | | | From owner-multi6@ops.ietf.org Sun Mar 16 20:02:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14429 for ; Sun, 16 Mar 2003 20:02:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uj1b-0009Kx-00 for multi6-data@psg.com; Sun, 16 Mar 2003 17:02:47 -0800 Received: from mailout.zma.compaq.com ([161.114.64.105] helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18uj1W-0009Kl-00 for multi6@ops.ietf.org; Sun, 16 Mar 2003 17:02:42 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 7E34250B4; Sun, 16 Mar 2003 20:02:41 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 16 Mar 2003 20:02:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Again no multi6 at IETF#56 Date: Sun, 16 Mar 2003 20:02:40 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCCC1@tayexc13.americas.cpqcorp.net> Thread-Topic: Again no multi6 at IETF#56 Thread-Index: AcLrzZ7HiakuIcgRSi+eYshK5zssRgAUv1IA From: "Bound, Jim" To: "Michael H. Lambert" Cc: X-OriginalArrivalTime: 17 Mar 2003 01:02:41.0349 (UTC) FILETIME=[E916CF50:01C2EC20] 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 UAA14429 I agree. I am trying to get people to come here doing it now. Seems to be some kind of issue I don't get though. Probably afraid to get unproffessional mail responses is one comment I heard from the IETF lists??? That's too bad. /jim > -----Original Message----- > From: Michael H. Lambert [mailto:lambert@psc.edu] > Sent: Sunday, March 16, 2003 10:06 AM > To: Bound, Jim > Cc: multi6@ops.ietf.org > Subject: RE: Again no multi6 at IETF#56 > > > --On Saturday, 15 March 2003 21:54 -0500 "Bound, Jim" > > wrote: > > > IPv6 deployment will not wait for multi-homing to be solved. [...] > > I don't think multi-homing will wait for multi-homing to be > solved, either. > I'm sure there are many sites out there, not "knowing" there > are problems > with MH, that will blindly multi-home using PA addresses. > And I bet many > of them will be quite happy. What we need are reports of operational > experience with PA MH. > > Michael > > +------------------------------------------------------------- > ----------+ > | Michael H. Lambert, Network Engineer Phone: +1 > 412 268-4960 | > | Pittsburgh Supercomputing Center FAX: +1 > 412 268-8200 | > | 4400 Fifth Avenue, Pittsburgh, PA 15213 > lambert@psc.edu | > +------------------------------------------------------------- > ----------+ > From owner-multi6@ops.ietf.org Sun Mar 16 20:10:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14553 for ; Sun, 16 Mar 2003 20:10:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ujBH-0009iU-00 for multi6-data@psg.com; Sun, 16 Mar 2003 17:12:47 -0800 Received: from mailout.zma.compaq.com ([161.114.64.104] helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18ujBE-0009iF-00 for multi6@ops.ietf.org; Sun, 16 Mar 2003 17:12:45 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 148729FF; Sun, 16 Mar 2003 20:12:42 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 16 Mar 2003 20:12:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Again no multi6 at IETF#56 Date: Sun, 16 Mar 2003 20:12:41 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0324103E@tayexc13.americas.cpqcorp.net> Thread-Topic: Again no multi6 at IETF#56 Thread-Index: AcLr5jKMF6JLbIDcRYSGQ3odz2mDngAO1EBg From: "Bound, Jim" To: "J. Noel Chiappa" , Cc: X-OriginalArrivalTime: 17 Mar 2003 01:12:41.0986 (UTC) FILETIME=[4F18BE20:01C2EC22] 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 UAA14553 > > I am suspect of the entire notion of the separation, > which just being > > technically accute having heard many solutions to this > over the years. > > Those many solutions would includ MIPv6, right Jim? How does MIPv6 fit the model? Also I am not against trying I just said suspect. WOuld like to see model though as I believe the two can be overloaded. Maybe not. /jim > > Noel > From owner-multi6@ops.ietf.org Sun Mar 16 20:36:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15202 for ; Sun, 16 Mar 2003 20:36:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ujZt-000BG5-00 for multi6-data@psg.com; Sun, 16 Mar 2003 17:38:13 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #1) id 18ujZo-000BFs-00 for multi6@ops.ietf.org; Sun, 16 Mar 2003 17:38:08 -0800 Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.6/8.12.6) with ESMTP id h2H1c1kw009499; Sun, 16 Mar 2003 20:38:01 -0500 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.6/8.12.6/Submit) id h2H1c0eX009498; Sun, 16 Mar 2003 20:38:00 -0500 Date: Sun, 16 Mar 2003 20:38:00 -0500 From: "J. Noel Chiappa" Message-Id: <200303170138.h2H1c0eX009498@ginger.lcs.mit.edu> To: Jim.Bound@hp.com, multi6@ops.ietf.org Subject: RE: Again no multi6 at IETF#56 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: "Bound, Jim" > How does MIPv6 fit the model? Because it separates location from identity. Noel From owner-multi6@ops.ietf.org Sun Mar 16 21:25:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16296 for ; Sun, 16 Mar 2003 21:25:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ukKd-000DEk-00 for multi6-data@psg.com; Sun, 16 Mar 2003 18:26:31 -0800 Received: from teldanex.hiit.fi ([212.68.5.99] helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 3.36 #1) id 18ukKb-000DEY-00 for multi6@ops.ietf.org; Sun, 16 Mar 2003 18:26:29 -0800 Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 902331C; Mon, 17 Mar 2003 04:36:32 +0200 (EET) Message-ID: <3E75325F.4030801@nomadiclab.com> Date: Sun, 16 Mar 2003 18:26:39 -0800 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030310 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "J. Noel Chiappa" Cc: Jim.Bound@hp.com, multi6@ops.ietf.org Subject: Re: Again no multi6 at IETF#56 References: <200303170138.h2H1c0eX009498@ginger.lcs.mit.edu> In-Reply-To: <200303170138.h2H1c0eX009498@ginger.lcs.mit.edu> 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_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 J. Noel Chiappa wrote: > > From: "Bound, Jim" > > > How does MIPv6 fit the model? > > Because it separates location from identity. YMMV. In my opinion it does not. It does *almost* separate location from identity, but not quite. At least if you do with the current security solutions. If you invent better scalable security, then maybe. [For current MN-HA security, you need a pre-established security context. For MN-CN security, you rely on HoT packets, periodically (every 5 minutes) sent through the Home Agent.] --Pekka Nikander From owner-multi6@ops.ietf.org Sun Mar 16 21:44:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16790 for ; Sun, 16 Mar 2003 21:44:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ukdy-000E4y-00 for multi6-data@psg.com; Sun, 16 Mar 2003 18:46:30 -0800 Received: from edison.cisco.com ([171.70.144.164]) by psg.com with esmtp (Exim 3.36 #1) id 18ukdw-000E4m-00 for multi6@ops.ietf.org; Sun, 16 Mar 2003 18:46:28 -0800 Received: from cisco.com (sjc-vpn4-213.cisco.com [10.21.80.213]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id SAA05784; Sun, 16 Mar 2003 18:46:20 -0800 (PST) Message-ID: <3E7536FB.5090408@cisco.com> Date: Sun, 16 Mar 2003 18:46:19 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tony Li CC: Iljitsch van Beijnum , "Bound, Jim" , multi6@ops.ietf.org Subject: Re: Identifier/locator recap 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: > At this point, I'm quite happy not to sweat the 8+8/GSE/16+16 > distinction. If we can get to consensus that we need separation > of locators and identifiers, then we will have made good progress. > Let's agree on the macro before we work out the micro. I would like to second Tony's request. We would do well to fully understand all of the architectural limitations to making this separation happen. There is now a lot of work in this space from which we can build. HIP, 8+8, and MIPv6 are good starting points. The NSRG still has a forthcoming RFC on these points. Eliot From owner-multi6@ops.ietf.org Sun Mar 16 22:11:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17171 for ; Sun, 16 Mar 2003 22:11:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ul3h-000F7h-00 for multi6-data@psg.com; Sun, 16 Mar 2003 19:13:05 -0800 Received: from wl-134-243.wireless.ietf56.ietf.org ([130.129.134.243] helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18ul3e-000F7Q-00 for multi6@ops.ietf.org; Sun, 16 Mar 2003 19:13:02 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2H3EOKW005150; Mon, 17 Mar 2003 04:14:25 +0100 (CET) Date: Mon, 17 Mar 2003 04:14:23 +0100 Subject: Re: Again no multi6 at IETF#56 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Michael H. Lambert" , To: "Bound, Jim" From: Kurt Erik Lindqvist In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCCC1@tayexc13.americas.cpqcorp.net> Message-Id: <8DA10865-5826-11D7-B5E1-000393AB1404@kurtis.pp.se> X-Mailer: Apple Mail (2.551) 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA17171 That is sad. I would be really interested in this, as multihoming with PA is what I suggested in draft-kurtis-mulithoming-longprefix-00.txt. I still think that doing it the IPv4 way is the best and fastest hack we have for multihoming IPv6. Best regards, - kurtis - On måndag, mar 17, 2003, at 02:02 Europe/Stockholm, Bound, Jim wrote: > I agree. I am trying to get people to come here doing it now. Seems > to > be some kind of issue I don't get though. Probably afraid to get > unproffessional mail responses is one comment I heard from the IETF > lists??? That's too bad. > > /jim > > > > >> -----Original Message----- >> From: Michael H. Lambert [mailto:lambert@psc.edu] >> Sent: Sunday, March 16, 2003 10:06 AM >> To: Bound, Jim >> Cc: multi6@ops.ietf.org >> Subject: RE: Again no multi6 at IETF#56 >> >> >> --On Saturday, 15 March 2003 21:54 -0500 "Bound, Jim" >> >> wrote: >> >>> IPv6 deployment will not wait for multi-homing to be solved. [...] >> >> I don't think multi-homing will wait for multi-homing to be >> solved, either. >> I'm sure there are many sites out there, not "knowing" there >> are problems >> with MH, that will blindly multi-home using PA addresses. >> And I bet many >> of them will be quite happy. What we need are reports of operational >> experience with PA MH. >> >> Michael >> >> +------------------------------------------------------------- >> ----------+ >> | Michael H. Lambert, Network Engineer Phone: +1 >> 412 268-4960 | >> | Pittsburgh Supercomputing Center FAX: +1 >> 412 268-8200 | >> | 4400 Fifth Avenue, Pittsburgh, PA 15213 >> lambert@psc.edu | >> +------------------------------------------------------------- >> ----------+ >> > From owner-multi6@ops.ietf.org Sun Mar 16 23:40:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19444 for ; Sun, 16 Mar 2003 23:40:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18umQp-000JCA-00 for multi6-data@psg.com; Sun, 16 Mar 2003 20:41:03 -0800 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by psg.com with esmtp (Exim 3.36 #1) id 18umQm-000JBu-00 for multi6@ops.ietf.org; Sun, 16 Mar 2003 20:41:00 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id A0632808; Sun, 16 Mar 2003 23:40:56 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 16 Mar 2003 23:40:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Identifier/locator recap Date: Sun, 16 Mar 2003 23:40:56 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCCC9@tayexc13.americas.cpqcorp.net> Thread-Topic: Identifier/locator recap Thread-Index: AcLrz/76VTCqQR8YQsOsjDwo2omr+QAbrpvw From: "Bound, Jim" To: "Iljitsch van Beijnum" Cc: X-OriginalArrivalTime: 17 Mar 2003 04:40:56.0547 (UTC) FILETIME=[666F7330:01C2EC3F] 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 XAA19444 > > Could you write up your technical idea without a lot of man > hours to > > describe and why it solves the multihome problem. > > I'm not Tony, but: > > Traditional multihoming as is done in IPv4 will not scale. > > An alternative is to give each host in a multihomed site an > address for each ISP the site is connected to. When (the link > to) one ISP fails, the communciation is diverted over the > other ISP. However, current transport protocols are unable to > jump to new addresses in mid-session. Solution: separate the > identifier and locator functions of the IP address. Transport > protocols then use the identifier, which doesn't change > during the lifetime of the session, while IP uses the > locator, which may be changed at any time in order to route > around broken parts of the network. I think the MIPv6 MHH is on the right track and it is an excellent piece of technical work. I have read it twice and I believe it could work. But I also like the note to all in GAPI which states we have two sets of space. THe unicast space and the MHH space. I for now like that thinking model. > > A few things that need to be addressed to make this happen: > > - Locators must always be present in each packet. But what about the > identifiers? Do we include them in each packet (= tunneling) or are > they implied? If we can make them implied its an extra condition check for routers and hosts but will make the overall architecture less heavy and less to manage. I believe in overload though it is complex to implement not impossible. > > - How do we discover identifiers and/or locators? Still parsing the PI space MHAP. But that is on the right road. > > - How to we authenticate the relationship between locators and > identifiers? > > There is also the question of what makes good identifiers. > HIP uses the fingerprint of a cryptographic key. MHAP uses > provider-independent IPv6 addresses that aren't visible in > the global routing table. I myself have suggested to use > FQDNs as the first choice. I suggest not being dependent on crypto anything is wise it implies PKI to the solution and I fear that is a non-starter? > > Note that there seems consensus here that we shouldn't try to > revive GSE or 8+8: some kind of "16+16" would be much easier > to deploy. No comment. I agree with Tony lets get the Macro done. I do think we need to work on the Model so it is clear to all and then we can do the architecture and then apply implementation discussion? /jim > > Iljitsch > > From owner-multi6@ops.ietf.org Sun Mar 16 23:41:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19477 for ; Sun, 16 Mar 2003 23:41:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18umTE-000JGp-00 for multi6-data@psg.com; Sun, 16 Mar 2003 20:43:32 -0800 Received: from mailout.zma.compaq.com ([161.114.64.103] helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18umTC-000JGc-00 for multi6@ops.ietf.org; Sun, 16 Mar 2003 20:43:30 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 378B23BBD; Sun, 16 Mar 2003 23:43:30 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 16 Mar 2003 23:43:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Again no multi6 at IETF#56 Date: Sun, 16 Mar 2003 23:43:29 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCCCA@tayexc13.americas.cpqcorp.net> Thread-Topic: Again no multi6 at IETF#56 Thread-Index: AcLsJdzK5412C0EgQ1q4fJYe7+dKGgAGcvOQ From: "Bound, Jim" To: "J. Noel Chiappa" , X-OriginalArrivalTime: 17 Mar 2003 04:43:30.0123 (UTC) FILETIME=[C1F949B0:01C2EC3F] 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 XAA19477 > Because it separates location from identity. You believe this because the CoA is not the HoA? /jim > > Noel > From owner-multi6@ops.ietf.org Sun Mar 16 23:52:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19744 for ; Sun, 16 Mar 2003 23:52:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18umdu-000JsV-00 for multi6-data@psg.com; Sun, 16 Mar 2003 20:54:34 -0800 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by psg.com with esmtp (Exim 3.36 #1) id 18umds-000JsJ-00 for multi6@ops.ietf.org; Sun, 16 Mar 2003 20:54:32 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id BC3475309; Sun, 16 Mar 2003 23:54:31 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 16 Mar 2003 23:54:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Again no multi6 at IETF#56 Date: Sun, 16 Mar 2003 23:54:31 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCCCE@tayexc13.americas.cpqcorp.net> Thread-Topic: Again no multi6 at IETF#56 Thread-Index: AcLsLKJ40q5bK9/ORrWbJBY02BUrYwAFAQwA From: "Bound, Jim" To: "Pekka Nikander" , "J. Noel Chiappa" Cc: X-OriginalArrivalTime: 17 Mar 2003 04:54:31.0607 (UTC) FILETIME=[4C3FBC70:01C2EC41] X-Spam-Status: No, hits=0.3 required=5.0 tests=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 XAA19744 I am not convinced yet either. But the fact that the MN can restate its location via CoA via BU via RR+IPsec with HA. Then the type-2 RH permits packet to get to MN via CN via HoA. Seems there is a bit of the abstraction for sure. It also makes the MIPv6 MHH spec out quite believable. But that is only part of the solution and I will stop there as I said we need the model defined even before the architecture solution. We could view the MH model as XML We could view the MH Architecture as Java We could view the MH implementations as JDK X.X version XML can support multiple descriptions. Java can compile multiple descriptions. The JDK can provide multiple primitives for exectution via libraries. /jim > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] > Sent: Sunday, March 16, 2003 9:27 PM > To: J. Noel Chiappa > Cc: Bound, Jim; multi6@ops.ietf.org > Subject: Re: Again no multi6 at IETF#56 > > > J. Noel Chiappa wrote: > > > From: "Bound, Jim" > > > > > How does MIPv6 fit the model? > > > > Because it separates location from identity. > > YMMV. In my opinion it does not. It does *almost* > separate location from identity, but not quite. > At least if you do with the current security > solutions. If you invent better scalable security, > then maybe. > > [For current MN-HA security, you need a pre-established > security context. For MN-CN security, you rely on HoT > packets, periodically (every 5 minutes) sent through the Home Agent.] > > --Pekka Nikander > > > From owner-multi6@ops.ietf.org Sun Mar 16 23:54:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19791 for ; Sun, 16 Mar 2003 23:54:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18umfg-000Jzk-00 for multi6-data@psg.com; Sun, 16 Mar 2003 20:56:24 -0800 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by psg.com with esmtp (Exim 3.36 #1) id 18umfb-000JzN-00 for multi6@ops.ietf.org; Sun, 16 Mar 2003 20:56:19 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id EC6B03BA1; Sun, 16 Mar 2003 23:56:18 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 16 Mar 2003 23:56:18 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Again no multi6 at IETF#56 Date: Sun, 16 Mar 2003 23:56:18 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCCD0@tayexc13.americas.cpqcorp.net> Thread-Topic: Again no multi6 at IETF#56 Thread-Index: AcLsMx5NLhNOeW4vRWGv8T9PNdLgsAADlpuA From: "Bound, Jim" To: "Kurt Erik Lindqvist" Cc: "Michael H. Lambert" , X-OriginalArrivalTime: 17 Mar 2003 04:56:18.0888 (UTC) FILETIME=[8C318480:01C2EC41] 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 XAA19791 Yes it is. But today they are doing what you said. They really have no choice. /jim > -----Original Message----- > From: Kurt Erik Lindqvist [mailto:kurtis@kurtis.pp.se] > Sent: Sunday, March 16, 2003 10:14 PM > To: Bound, Jim > Cc: Michael H. Lambert; multi6@ops.ietf.org > Subject: Re: Again no multi6 at IETF#56 > > > > That is sad. > > I would be really interested in this, as multihoming with PA > is what I > suggested in draft-kurtis-mulithoming-longprefix-00.txt. I > still think > that doing it the IPv4 way is the best and fastest hack we have for > multihoming IPv6. > > Best regards, > > - kurtis - > > On måndag, mar 17, 2003, at 02:02 Europe/Stockholm, Bound, Jim wrote: > > > I agree. I am trying to get people to come here doing it > now. Seems > > to > > be some kind of issue I don't get though. Probably afraid to get > > unproffessional mail responses is one comment I heard from the IETF > > lists??? That's too bad. > > > > /jim > > > > > > > > > >> -----Original Message----- > >> From: Michael H. Lambert [mailto:lambert@psc.edu] > >> Sent: Sunday, March 16, 2003 10:06 AM > >> To: Bound, Jim > >> Cc: multi6@ops.ietf.org > >> Subject: RE: Again no multi6 at IETF#56 > >> > >> > >> --On Saturday, 15 March 2003 21:54 -0500 "Bound, Jim" > >> > >> wrote: > >> > >>> IPv6 deployment will not wait for multi-homing to be solved. [...] > >> > >> I don't think multi-homing will wait for multi-homing to > be solved, > >> either. I'm sure there are many sites out there, not > "knowing" there > >> are problems > >> with MH, that will blindly multi-home using PA addresses. > >> And I bet many > >> of them will be quite happy. What we need are reports of > operational > >> experience with PA MH. > >> > >> Michael > >> > >> +------------------------------------------------------------- > >> ----------+ > >> | Michael H. Lambert, Network Engineer Phone: +1 > >> 412 268-4960 | > >> | Pittsburgh Supercomputing Center FAX: +1 > >> 412 268-8200 | > >> | 4400 Fifth Avenue, Pittsburgh, PA 15213 > >> lambert@psc.edu | > >> +------------------------------------------------------------- > >> ----------+ > >> > > > > From owner-multi6@ops.ietf.org Mon Mar 17 00:01:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19984 for ; Mon, 17 Mar 2003 00:01:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18umma-000KOm-00 for multi6-data@psg.com; Sun, 16 Mar 2003 21:03:32 -0800 Received: from wl-134-243.wireless.ietf56.ietf.org ([130.129.134.243] helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18ummQ-000KOI-00 for multi6@ops.ietf.org; Sun, 16 Mar 2003 21:03:22 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2H54cKW005340; Mon, 17 Mar 2003 06:04:41 +0100 (CET) Date: Mon, 17 Mar 2003 06:04:33 +0100 Subject: Re: Again no multi6 at IETF#56 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Michael H. Lambert" , To: "Bound, Jim" From: Kurt Erik Lindqvist In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCCD0@tayexc13.americas.cpqcorp.net> Message-Id: X-Mailer: Apple Mail (2.551) 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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA19984 I don't think we need a choice - today. We need something now though - which leads me to this draft....: -) - kurtis - On måndag, mar 17, 2003, at 05:56 Europe/Stockholm, Bound, Jim wrote: > Yes it is. > > But today they are doing what you said. They really have no choice. > > /jim > > > > >> -----Original Message----- >> From: Kurt Erik Lindqvist [mailto:kurtis@kurtis.pp.se] >> Sent: Sunday, March 16, 2003 10:14 PM >> To: Bound, Jim >> Cc: Michael H. Lambert; multi6@ops.ietf.org >> Subject: Re: Again no multi6 at IETF#56 >> >> >> >> That is sad. >> >> I would be really interested in this, as multihoming with PA >> is what I >> suggested in draft-kurtis-mulithoming-longprefix-00.txt. I >> still think >> that doing it the IPv4 way is the best and fastest hack we have for >> multihoming IPv6. >> >> Best regards, >> >> - kurtis - >> >> On måndag, mar 17, 2003, at 02:02 Europe/Stockholm, Bound, Jim wrote: >> >>> I agree. I am trying to get people to come here doing it >> now. Seems >>> to >>> be some kind of issue I don't get though. Probably afraid to get >>> unproffessional mail responses is one comment I heard from the IETF >>> lists??? That's too bad. >>> >>> /jim >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: Michael H. Lambert [mailto:lambert@psc.edu] >>>> Sent: Sunday, March 16, 2003 10:06 AM >>>> To: Bound, Jim >>>> Cc: multi6@ops.ietf.org >>>> Subject: RE: Again no multi6 at IETF#56 >>>> >>>> >>>> --On Saturday, 15 March 2003 21:54 -0500 "Bound, Jim" >>>> >>>> wrote: >>>> >>>>> IPv6 deployment will not wait for multi-homing to be solved. [...] >>>> >>>> I don't think multi-homing will wait for multi-homing to >> be solved, >>>> either. I'm sure there are many sites out there, not >> "knowing" there >>>> are problems >>>> with MH, that will blindly multi-home using PA addresses. >>>> And I bet many >>>> of them will be quite happy. What we need are reports of >> operational >>>> experience with PA MH. >>>> >>>> Michael >>>> >>>> +------------------------------------------------------------- >>>> ----------+ >>>> | Michael H. Lambert, Network Engineer Phone: +1 >>>> 412 268-4960 | >>>> | Pittsburgh Supercomputing Center FAX: +1 >>>> 412 268-8200 | >>>> | 4400 Fifth Avenue, Pittsburgh, PA 15213 >>>> lambert@psc.edu | >>>> +------------------------------------------------------------- >>>> ----------+ >>>> >>> >> >> From owner-multi6@ops.ietf.org Mon Mar 17 00:47:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21795 for ; Mon, 17 Mar 2003 00:47:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18unUk-000Mov-00 for multi6-data@psg.com; Sun, 16 Mar 2003 21:49:10 -0800 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by psg.com with esmtp (Exim 3.36 #1) id 18unUh-000Moh-00 for multi6@ops.ietf.org; Sun, 16 Mar 2003 21:49:07 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 9F82E9D7 for ; Mon, 17 Mar 2003 00:49:06 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Mar 2003 00:49:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2EC48.EC0912A2" Subject: Reducing Peerings for MH Routing within a site via end systems Date: Mon, 17 Mar 2003 00:49:06 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03241040@tayexc13.americas.cpqcorp.net> Thread-Topic: Reducing Peerings for MH Routing within a site via end systems Thread-Index: AcLsSOfSvGXrMnooRAieaRoipQ9LGw== From: "Bound, Jim" To: X-OriginalArrivalTime: 17 Mar 2003 05:49:06.0544 (UTC) FILETIME=[EC437700:01C2EC48] 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 This is a multi-part message in MIME format. ------_=_NextPart_001_01C2EC48.EC0912A2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Do we agree on the following (I don't care about the high order words/terms). =20 Reducing Peering: =20 If a sites end systems do not depend on providers peering, but can always failover to other provider from within the site, this reduces the routing tables for the providers, and for the routers within the Internet in the MHH case? =20 Would this solve an immediate problem from IPv6 MHH case? =20 thanks /jim =20 =20 =20 ------_=_NextPart_001_01C2EC48.EC0912A2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Do we = agree on the=20 following (I don't care about the high order = words/terms).
 
Reducing=20 Peering:
 
If a = sites end=20 systems do not depend on providers peering, but can always failover to = other=20 provider from within the site, this reduces the routing tables for the=20 providers, and for the routers within the Internet in the MHH=20 case?
 
Would = this solve an=20 immediate problem from IPv6 MHH case?
 
thanks
/jim
 
 
 
=00 ------_=_NextPart_001_01C2EC48.EC0912A2-- From owner-multi6@ops.ietf.org Mon Mar 17 00:55:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21862 for ; Mon, 17 Mar 2003 00:55:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uncc-000NBR-00 for multi6-data@psg.com; Sun, 16 Mar 2003 21:57:18 -0800 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by psg.com with esmtp (Exim 3.36 #1) id 18unca-000NBF-00 for multi6@ops.ietf.org; Sun, 16 Mar 2003 21:57:16 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 7A77B844 for ; Mon, 17 Mar 2003 00:57:15 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Mar 2003 00:57:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2EC4A.0F6C851D" Subject: Location Date: Mon, 17 Mar 2003 00:57:15 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03241041@tayexc13.americas.cpqcorp.net> Thread-Topic: Location Thread-Index: AcLsSgs7xJYH5uk+QKKDRW6582/UJg== From: "Bound, Jim" To: X-OriginalArrivalTime: 17 Mar 2003 05:57:15.0373 (UTC) FILETIME=[0FA0D9D0:01C2EC4A] 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 This is a multi-part message in MIME format. ------_=_NextPart_001_01C2EC4A.0F6C851D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Location: =20 Do we believe that providers should know location of all nodes on the Internet without peering? =20 Do we believe that providers should know location of all nodes within a specific topology, without peering? =20 Do we believe that providers should know location of all nodes within a specific topology within specific rendezvous points within the aforementioned specific topology, without peering? =20 Do we believe that providers should only know peerings for providers that exist near specific locations? =20 I did not use the word geographic or other boundary descriptive associations for topology for that attribute for now. We could do that later I suggest. =20 /jim =20 =20 =20 =20 =20 ------_=_NextPart_001_01C2EC4A.0F6C851D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Location:
 
Do we = believe that=20 providers should know location of all nodes on the Internet without=20 peering?
 
Do we = believe that=20 providers should know location of all nodes within a specific topology, = without=20 peering?
 
Do we = believe that=20 providers should know location of all nodes within a specific topology = within=20 specific rendezvous points within the aforementioned specific topology, = without=20 peering?
 
Do we = believe that=20 providers should only know peerings for providers that exist near = specific=20 locations?
 
I did = not use the=20 word geographic or other boundary descriptive associations for=20 topology for that attribute for now.  We could do that later I = suggest.
 
/jim
 
 
 
 
 
=00 ------_=_NextPart_001_01C2EC4A.0F6C851D-- From owner-multi6@ops.ietf.org Mon Mar 17 00:59:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21921 for ; Mon, 17 Mar 2003 00:59:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ungC-000NQ2-00 for multi6-data@psg.com; Sun, 16 Mar 2003 22:01:00 -0800 Received: from mailout.zma.compaq.com ([161.114.64.105] helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18ung7-000NPf-00 for multi6@ops.ietf.org; Sun, 16 Mar 2003 22:00:55 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 9186C3E28 for ; Mon, 17 Mar 2003 01:00:54 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Mar 2003 01:00:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2EC4A.9219EA8D" Subject: Routing Date: Mon, 17 Mar 2003 01:00:54 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03241042@tayexc13.americas.cpqcorp.net> Thread-Topic: Routing Thread-Index: AcLsSo3t+L5GVeaNQnSAQp9sWnIdsg== From: "Bound, Jim" To: X-OriginalArrivalTime: 17 Mar 2003 06:00:54.0498 (UTC) FILETIME=[923CAC20:01C2EC4A] X-Spam-Status: No, hits=1.1 required=5.0 tests=HTML_50_70,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-multi6@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C2EC4A.9219EA8D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Routing making it better: =20 Reduction of dynamic routing path would make routing better? =20 Static routes for key Locations as part of the above reduction would improve routing? =20 /jim =20 =20 =20 ------_=_NextPart_001_01C2EC4A.9219EA8D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Routing making it=20 better:
 
Reduction of dynamic=20 routing path would make routing better?
 
Static = routes for=20 key Locations as part of the above reduction would improve=20 routing?
 
/jim
 
 
 
=00 ------_=_NextPart_001_01C2EC4A.9219EA8D-- From owner-multi6@ops.ietf.org Mon Mar 17 01:10:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22194 for ; Mon, 17 Mar 2003 01:10:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18unqm-000NzM-00 for multi6-data@psg.com; Sun, 16 Mar 2003 22:11:56 -0800 Received: from mailout.zma.compaq.com ([161.114.64.103] helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18unqj-000Nyu-00 for multi6@ops.ietf.org; Sun, 16 Mar 2003 22:11:53 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 427873A49 for ; Mon, 17 Mar 2003 01:11:53 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Mar 2003 01:11:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2EC4C.1AA79D05" Subject: The Network is Chaos should Routing be based on that Chaos Date: Mon, 17 Mar 2003 01:11:52 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03241043@tayexc13.americas.cpqcorp.net> Thread-Topic: The Network is Chaos should Routing be based on that Chaos Thread-Index: AcLsTBZsl3Zqej/jTvemY1f+H4XSiQ== From: "Bound, Jim" To: X-OriginalArrivalTime: 17 Mar 2003 06:11:53.0152 (UTC) FILETIME=[1AD34C00:01C2EC4C] 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 This is a multi-part message in MIME format. ------_=_NextPart_001_01C2EC4C.1AA79D05 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Chaotic Routing: =20 Whatever we define today will become chaotic tomorrow? =20 Does fractal analysis teach us anything? We may be able to group fractals for a period of time, but by definition the inherent chaotic property of those fractals will destroy any static order defined? =20 So there are multiple levels to address the Chaotic Routing model: =20 1. At time T the topology is at Location A 2. At time T1 the topology is at Location A+1 =20 Could it be we need enhancement to routing protocols to just exist for Location change? =20 Then under that routing we know how to do now based on that Location change, it becomes adaptive to Location A+1. =20 Predicting chaotic rate of change is impossible I suggest, and the best we can do is define Location and within specific rendezvous segments within that Location, which can be adaptive to T+1? =20 /jim =20 =20 ------_=_NextPart_001_01C2EC4C.1AA79D05 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Chaotic=20 Routing:
 
Whatever we define=20 today will become chaotic tomorrow?
 
Does = fractal=20 analysis teach us anything?  We may be able to group fractals for a = period=20 of time, but by definition the inherent chaotic property of those = fractals will=20 destroy any static order defined?
 
So = there are=20 multiple levels to address the Chaotic Routing = model:
 
1. At = time T the=20 topology is at Location A
2. At = time T1 the=20 topology is at Location A+1
 
Could = it be we need=20 enhancement to routing protocols to just exist for Location=20 change?
 
Then = under that=20 routing we know how to do now based on that Location change, it becomes = adaptive=20 to Location A+1.
 
Predicting=20 chaotic rate of change is impossible I suggest, and the best = we can do=20 is define Location and within specific rendezvous segments within that = Location,=20 which can be adaptive to T+1?
 
/jim
 
 
=00 ------_=_NextPart_001_01C2EC4C.1AA79D05-- From owner-multi6@ops.ietf.org Mon Mar 17 01:14:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22323 for ; Mon, 17 Mar 2003 01:14:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18unvQ-000OJy-00 for multi6-data@psg.com; Sun, 16 Mar 2003 22:16:44 -0800 Received: from mailout.zma.compaq.com ([161.114.64.105] helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18unvO-000OIm-00 for multi6@ops.ietf.org; Sun, 16 Mar 2003 22:16:42 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id B3CBB52CA for ; Mon, 17 Mar 2003 01:16:41 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Mar 2003 01:16:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2EC4C.C694186C" Subject: Identification Date: Mon, 17 Mar 2003 01:16:41 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03241044@tayexc13.americas.cpqcorp.net> Thread-Topic: Identification Thread-Index: AcLsTMI4+3SreT6pRGKwmBM2xx8y1A== From: "Bound, Jim" To: X-OriginalArrivalTime: 17 Mar 2003 06:16:41.0638 (UTC) FILETIME=[C6C6C460:01C2EC4C] X-Spam-Status: No, hits=1.1 required=5.0 tests=HTML_50_70,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-multi6@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C2EC4C.C694186C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Identification: =20 Identifiers will be both mobile and stationary? =20 Identifiers should be able to communicate with other identifiers through multiple locations? =20 Identifiers should be able to change their location? =20 But we cannot hard code identifiers in silicon? =20 Can identifiers be within the context of Location? =20 /jim =20 =20 ------_=_NextPart_001_01C2EC4C.C694186C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Identification:
 
Identifiers will be=20 both mobile and stationary?
 
Identifiers should=20 be able to communicate with other identifiers through multiple=20 locations?
 
Identifiers should=20 be able to change their location?
 
But we = cannot hard=20 code identifiers in silicon?
 
Can = identifiers be=20 within the context of Location?
 
/jim
 
 
=00 ------_=_NextPart_001_01C2EC4C.C694186C-- From owner-multi6@ops.ietf.org Mon Mar 17 01:31:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22615 for ; Mon, 17 Mar 2003 01:31:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uoAx-000PC9-00 for multi6-data@psg.com; Sun, 16 Mar 2003 22:32:47 -0800 Received: from wl-134-243.wireless.ietf56.ietf.org ([130.129.134.243] helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18uoAs-000PAN-00 for multi6@ops.ietf.org; Sun, 16 Mar 2003 22:32:42 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2H6XnKW005406; Mon, 17 Mar 2003 07:33:50 +0100 (CET) Date: Mon, 17 Mar 2003 07:33:49 +0100 Subject: Re: Again no multi6 at IETF#56 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Bound, Jim" , "Michael H. Lambert" , To: Kurt Erik Lindqvist From: Kurt Erik Lindqvist In-Reply-To: Message-Id: <697F9680-5842-11D7-B5E1-000393AB1404@kurtis.pp.se> X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-3.3 required=5.0 tests=EMAIL_ATTRIBUTION,FROM_AND_TO_SAME_2,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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA22615 s/need/have/ - kurtis - On måndag, mar 17, 2003, at 06:04 Europe/Stockholm, Kurt Erik Lindqvist wrote: > > > I don't think we need a choice - today. > > We need something now though - which leads me to this draft....: -) > > - kurtis - > > On måndag, mar 17, 2003, at 05:56 Europe/Stockholm, Bound, Jim wrote: > >> Yes it is. >> >> But today they are doing what you said. They really have no choice. >> >> /jim >> >> >> >> >>> -----Original Message----- >>> From: Kurt Erik Lindqvist [mailto:kurtis@kurtis.pp.se] >>> Sent: Sunday, March 16, 2003 10:14 PM >>> To: Bound, Jim >>> Cc: Michael H. Lambert; multi6@ops.ietf.org >>> Subject: Re: Again no multi6 at IETF#56 >>> >>> >>> >>> That is sad. >>> >>> I would be really interested in this, as multihoming with PA >>> is what I >>> suggested in draft-kurtis-mulithoming-longprefix-00.txt. I >>> still think >>> that doing it the IPv4 way is the best and fastest hack we have for >>> multihoming IPv6. >>> >>> Best regards, >>> >>> - kurtis - >>> >>> On måndag, mar 17, 2003, at 02:02 Europe/Stockholm, Bound, Jim wrote: >>> >>>> I agree. I am trying to get people to come here doing it >>> now. Seems >>>> to >>>> be some kind of issue I don't get though. Probably afraid to get >>>> unproffessional mail responses is one comment I heard from the IETF >>>> lists??? That's too bad. >>>> >>>> /jim >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Michael H. Lambert [mailto:lambert@psc.edu] >>>>> Sent: Sunday, March 16, 2003 10:06 AM >>>>> To: Bound, Jim >>>>> Cc: multi6@ops.ietf.org >>>>> Subject: RE: Again no multi6 at IETF#56 >>>>> >>>>> >>>>> --On Saturday, 15 March 2003 21:54 -0500 "Bound, Jim" >>>>> >>>>> wrote: >>>>> >>>>>> IPv6 deployment will not wait for multi-homing to be solved. [...] >>>>> >>>>> I don't think multi-homing will wait for multi-homing to >>> be solved, >>>>> either. I'm sure there are many sites out there, not >>> "knowing" there >>>>> are problems >>>>> with MH, that will blindly multi-home using PA addresses. >>>>> And I bet many >>>>> of them will be quite happy. What we need are reports of >>> operational >>>>> experience with PA MH. >>>>> >>>>> Michael >>>>> >>>>> +------------------------------------------------------------- >>>>> ----------+ >>>>> | Michael H. Lambert, Network Engineer Phone: +1 >>>>> 412 268-4960 | >>>>> | Pittsburgh Supercomputing Center FAX: +1 >>>>> 412 268-8200 | >>>>> | 4400 Fifth Avenue, Pittsburgh, PA 15213 >>>>> lambert@psc.edu | >>>>> +------------------------------------------------------------- >>>>> ----------+ >>>>> >>>> >>> >>> > > From owner-multi6@ops.ietf.org Mon Mar 17 01:44:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22893 for ; Mon, 17 Mar 2003 01:44:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uoNd-000PsI-00 for multi6-data@psg.com; Sun, 16 Mar 2003 22:45:53 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 18uoNb-000Prw-00 for multi6@ops.ietf.org; Sun, 16 Mar 2003 22:45:51 -0800 Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 76E17137F06; Sun, 16 Mar 2003 22:45:48 -0800 (PST) Date: Sun, 16 Mar 2003 22:45:48 -0800 Subject: Re: Identification Content-Type: multipart/alternative; boundary=Apple-Mail-2-856871866 Mime-Version: 1.0 (Apple Message framework v551) Cc: To: "Bound, Jim" From: David Conrad In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03241044@tayexc13.americas.cpqcorp.net> Message-Id: <164A28A8-5844-11D7-B7F3-000393DB42B2@nominum.com> X-Mailer: Apple Mail (2.551) 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 --Apple-Mail-2-856871866 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Jim, You seem to be implicitly assuming something, but I'm not quite sure=20 what. To me, identifiers are values that uniquely and globally (at least=20 within the context of an internet) identify communication end points. =20= =46rom this definition, I'll hazard a guess at answers to your = questions: On Sunday, March 16, 2003, at 10:16 PM, Bound, Jim wrote: > Identification: > =A0 > Identifiers will be both mobile and stationary? Identifiers are independent of location, thus they can be either. > =A0Identifiers should be able to communicate with other identifiers=20 > through multiple locations? Yes. > =A0Identifiers should be able to change their location? Of course. > =A0But we cannot hard code identifiers in silicon? There is no _technical_ reason this couldn't be done. People concerned=20= about privacy might get uptight about this though. > =A0Can identifiers be within the context of Location? Not sure what this means. Reachability to a given identifier depends=20 on its locator, so perhaps I'd say yes. Rgds, -drc --Apple-Mail-2-856871866 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jim, You seem to be implicitly assuming something, but I'm not quite sure what. To me, identifiers are values that uniquely and globally (at least within the context of an internet) identify communication end points.=20 =46rom this definition, I'll hazard a guess at answers to your = questions: On Sunday, March 16, 2003, at 10:16 PM, Bound, Jim wrote: = ArialIdentification: =A0 ArialIdentifiers will be both mobile and stationary? Identifiers are independent of location, thus they can be either. =A0ArialIdentifiers should be able to communicate with other identifiers through multiple locations? Yes. =A0ArialIdentifiers should be able to change their location? Of course. =A0ArialBut we cannot hard code identifiers in silicon? There is no _technical_ reason this couldn't be done. People concerned about privacy might get uptight about this though. =A0ArialCan identifiers be within the context of Location? Not sure what this means. Reachability to a given identifier depends on its locator, so perhaps I'd say yes. Rgds, -drc --Apple-Mail-2-856871866-- From owner-multi6@ops.ietf.org Mon Mar 17 02:09:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03050 for ; Mon, 17 Mar 2003 02:09:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uom2-0001Gj-00 for multi6-data@psg.com; Sun, 16 Mar 2003 23:11:06 -0800 Received: from mailout.zma.compaq.com ([161.114.64.103] helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18uolw-0001GQ-00 for multi6@ops.ietf.org; Sun, 16 Mar 2003 23:11:00 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 0672D7E16; Mon, 17 Mar 2003 02:11:00 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Mar 2003 02:10:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Identification Date: Mon, 17 Mar 2003 02:10:59 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03241045@tayexc13.americas.cpqcorp.net> Thread-Topic: Identification Thread-Index: AcLsUNpZWvs7TtZXRxWAppg6eEzizgAAgUmA From: "Bound, Jim" To: "David Conrad" Cc: X-OriginalArrivalTime: 17 Mar 2003 07:10:59.0911 (UTC) FILETIME=[5CDBC570:01C2EC54] 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 CAA03050 Dave, Assuming nothing. Asking. Setting a model. If we all agree on base principles/assumptions we can move forward. But I agree with your interpretations except for one I think? >> But we cannot hard code identifiers in silicon? >There is no _technical_ reason this couldn't be done. People concerned about >privacy might get uptight about this though. We don't want people to put identifiers in my CD player EIA interfaces if they exist within the context of location. The stateless property of the IPv6 architecture permits that can be changed by processing on the local network. Also we want my CD player to be able to support a self healing link partition if I change the IPv6 scope of identifier, or merge two links to one link local domain as two examples. Ergo XXX Electronics cannot burn IPv6 addresses in their chips and assume permanent identification. Even identifiers are chaotic and IPv6 architecture implies this is not technically wise. In addition to privacy nut-cakes who are worried about my CD player and refridgerator being attacked by the boogie man :---) /jim From owner-multi6@ops.ietf.org Mon Mar 17 02:28:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05387 for ; Mon, 17 Mar 2003 02:28:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18up50-0002Eu-00 for multi6-data@psg.com; Sun, 16 Mar 2003 23:30:42 -0800 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by psg.com with esmtp (Exim 3.36 #1) id 18up4y-0002EG-00 for multi6@ops.ietf.org; Sun, 16 Mar 2003 23:30:40 -0800 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id HAA20300 for ; Mon, 17 Mar 2003 07:30:38 GMT Received: from login.ecs.soton.ac.uk (login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id HAA24647 for ; Mon, 17 Mar 2003 07:30:38 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h2H7UcC24899 for multi6@ops.ietf.org; Mon, 17 Mar 2003 07:30:38 GMT Date: Mon, 17 Mar 2003 07:30:38 +0000 From: Tim Chown To: multi6@ops.ietf.org Subject: Re: Identification Message-ID: <20030317073038.GK24236@login.ecs.soton.ac.uk> Mail-Followup-To: multi6@ops.ietf.org References: <9C422444DE99BC46B3AD3C6EAFC9711B03241045@tayexc13.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03241045@tayexc13.americas.cpqcorp.net> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-3.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02, USER_AGENT,USER_AGENT_MUTT version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, Mar 17, 2003 at 02:10:59AM -0500, Bound, Jim wrote: > > Also we want my CD player to be able to support a self healing link > partition if I change the IPv6 scope of identifier, or merge two links > to one link local domain as two examples. Before long that piece of CD hifi is more likely to be a wireless MP3 player which could download new tracks from anywhere. But if you are constrained to the home I wouldn't want my appliances using well-known MAC prefixes either else an inventory of household electronics is on the wire as my TV/TiVo accesses programme info or my CD accesses the cddb or my fridge auto-orders more beer. Of course most households have these items, but the MAC address might identify high-end products - so it's not just a concern of privacy nut-cakes :) (BTW, for my CD or MP3 player to query cddb to lookup track info the lack of a stateless DNS discovery method means you need a DHCP client in your MP3 player...) Tim From owner-multi6@ops.ietf.org Mon Mar 17 02:36:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05608 for ; Mon, 17 Mar 2003 02:36:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18upCY-0002dk-00 for multi6-data@psg.com; Sun, 16 Mar 2003 23:38:30 -0800 Received: from wl-131-235.wireless.ietf56.ietf.org ([130.129.131.235] helo=wl-131-245.wireless.ietf56.ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 18upCT-0002dS-00 for multi6@ops.ietf.org; Sun, 16 Mar 2003 23:38:25 -0800 Received: (from ggm@localhost) by wl-131-245.wireless.ietf56.ietf.org (8.11.6/8.11.6) id h2H7b1v01813; Mon, 17 Mar 2003 17:37:01 +1000 (EST) Date: Mon, 17 Mar 2003 17:37:01 +1000 From: George Michaelson To: multi6@ops.ietf.org Subject: RFID in V6? Message-Id: <20030317173701.4dccedc4.ggm@apnic.net> In-Reply-To: <20030317073038.GK24236@login.ecs.soton.ac.uk> References: <9C422444DE99BC46B3AD3C6EAFC9711B03241045@tayexc13.americas.cpqcorp.net> <20030317073038.GK24236@login.ecs.soton.ac.uk> Organization: APNIC Pty Ltd X-Mailer: Sylpheed version 0.8.10claws101 (GTK+ 1.2.10; i386--netbsdelf) X-Fruit-Of-The-Month-Club: persimmon Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-0.7 required=5.0 tests=IN_REP_TO,NOSPAM_INC,REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Will RFID map into V6 in a sensible manner? If there was even a restricted subset mapping, what kinds of things could we do with it? -George From owner-multi6@ops.ietf.org Mon Mar 17 02:44:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05840 for ; Mon, 17 Mar 2003 02:44:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18upK6-000365-00 for multi6-data@psg.com; Sun, 16 Mar 2003 23:46:18 -0800 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #1) id 18upK3-00035j-00 for multi6@ops.ietf.org; Sun, 16 Mar 2003 23:46:15 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 6D1C73443C; Sun, 16 Mar 2003 22:59:14 -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 h2H7kFYB021856; Sun, 16 Mar 2003 23:46:15 -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="us-ascii" Subject: RE: Again no multi6 at IETF#56 Date: Sun, 16 Mar 2003 23:46:14 -0800 Message-ID: Thread-Topic: Again no multi6 at IETF#56 Thread-Index: AcLsNFNl0JT2JGQaQp+RTnMNLiVy0AAJINmw From: "Tony Li" To: "Kurt Erik Lindqvist" , "Bound, Jim" Cc: "Michael H. Lambert" , 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 CAA05840 | I still think | that doing it the IPv4 way is the best and fastest hack we | have for | multihoming IPv6. Kurt, It may well be the fastest. Certainly the old way usually is. And it may be the 'best' that we have right now because we don't have agreement on a better path. However, if we do go down the path of long prefix distribution, the core is almost certain to implode. Here, there be dragons that we should avoid. And regarding the issue of 'choice', we need there to be no choice in the matter. If there is a choice in how to multi-home, then some folks will inevitably choose the wrong way and we will again implode. Freedom from choice: it's what you want. -- Devo Tony From owner-multi6@ops.ietf.org Mon Mar 17 02:44:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05854 for ; Mon, 17 Mar 2003 02:44:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18upK7-000369-00 for multi6-data@psg.com; Sun, 16 Mar 2003 23:46:19 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 18upK5-00035t-00 for multi6@ops.ietf.org; Sun, 16 Mar 2003 23:46:17 -0800 Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 3193F137F06; Sun, 16 Mar 2003 23:46:16 -0800 (PST) Date: Sun, 16 Mar 2003 23:46:16 -0800 Subject: Re: Identification Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: "Bound, Jim" From: David Conrad In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03241045@tayexc13.americas.cpqcorp.net> Message-Id: <88DDF8B4-584C-11D7-B7F3-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.9 required=5.0 tests=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 Jim, On Sunday, March 16, 2003, at 11:10 PM, Bound, Jim wrote: >> There is no _technical_ reason this couldn't be done. People >> concerned about >> privacy might get uptight about this though. > > We don't want people to put identifiers in my CD player EIA interfaces > if they exist within the context of location. As I said in my previous message, identity is independent of location. Reachability of identifiers is dependent on location. > The stateless property of > the IPv6 architecture permits that can be changed by processing on the > local network. > Also we want my CD player to be able to support a self healing link > partition if I change the IPv6 scope of identifier, or merge two links > to one link local domain as two examples. None of these are identity issues, they are location issues. > Ergo XXX Electronics cannot burn IPv6 addresses in their chips and > assume permanent identification. Given current IPv6 addressing architecture, this is very true -- it would be very silly. However, if they only burned the lower 64 bits of an IPv6 address into their chips as permanent identifiers, there is no issue provided those identifiers are globally unique. > Even identifiers are chaotic and IPv6 > architecture implies this is not technically wise. In the context of routing, IPv6 treats the lower 64 bits as opaque values, does it not? Rgds, -drc From owner-multi6@ops.ietf.org Mon Mar 17 02:48:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05927 for ; Mon, 17 Mar 2003 02:48:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18upOE-0003KT-00 for multi6-data@psg.com; Sun, 16 Mar 2003 23:50:34 -0800 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by psg.com with esmtp (Exim 3.36 #1) id 18upO9-0003K7-00 for multi6@ops.ietf.org; Sun, 16 Mar 2003 23:50:29 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 4A8E5108F; Mon, 17 Mar 2003 02:50:28 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Mar 2003 02:50:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Identification Date: Mon, 17 Mar 2003 02:50:27 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCCE1@tayexc13.americas.cpqcorp.net> Thread-Topic: Identification Thread-Index: AcLsWU3AObqg+n2pTrWTX617tzErFQAAFAGw From: "Bound, Jim" To: "David Conrad" Cc: X-OriginalArrivalTime: 17 Mar 2003 07:50:28.0083 (UTC) FILETIME=[E0662430:01C2EC59] 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 CAA05927 > However, if they only burned the lower 64 bits of an IPv6 > address into > their chips as permanent identifiers, there is no issue > provided those > identifiers are globally unique. That's a big if. I think it can be done and margin of duplication would be minimal. > > > Even identifiers are chaotic and IPv6 > > architecture implies this is not technically wise. > > In the context of routing, IPv6 treats the lower 64 bits as opaque > values, does it not? For one Format Prefix yes. But not all. This was part of the Robert Elz objection to the recent addr arch to IAB. /jim > > Rgds, > -drc > > From owner-multi6@ops.ietf.org Mon Mar 17 02:50:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05975 for ; Mon, 17 Mar 2003 02:50:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18upPs-0003T4-00 for multi6-data@psg.com; Sun, 16 Mar 2003 23:52:16 -0800 Received: from mailout.zma.compaq.com ([161.114.64.103] helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18upPp-0003Sh-00 for multi6@ops.ietf.org; Sun, 16 Mar 2003 23:52:13 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 3EB8C3B94; Mon, 17 Mar 2003 02:52:13 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Mar 2003 02:52:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Again no multi6 at IETF#56 Date: Mon, 17 Mar 2003 02:52:12 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCCE2@tayexc13.americas.cpqcorp.net> Thread-Topic: Again no multi6 at IETF#56 Thread-Index: AcLsNFNl0JT2JGQaQp+RTnMNLiVy0AAJINmwAABJh+A= From: "Bound, Jim" To: "Tony Li" , "Kurt Erik Lindqvist" Cc: "Michael H. Lambert" , X-OriginalArrivalTime: 17 Mar 2003 07:52:13.0169 (UTC) FILETIME=[1F08FE10:01C2EC5A] 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 CAA05975 > Freedom from choice: it's what you want. > -- Devo Ouch. Whip it Whip it good :--) Same folks right >?>> /jim From owner-multi6@ops.ietf.org Mon Mar 17 02:55:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06150 for ; Mon, 17 Mar 2003 02:55:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18upUL-0003oK-00 for multi6-data@psg.com; Sun, 16 Mar 2003 23:56:53 -0800 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #1) id 18upUI-0003o7-00 for multi6@ops.ietf.org; Sun, 16 Mar 2003 23:56:50 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 5B9E43443C; Sun, 16 Mar 2003 23:09: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 h2H7uoYB022147; Sun, 16 Mar 2003 23:56: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: multipart/alternative; boundary="----_=_NextPart_001_01C2EC5A.C420A634" Subject: RE: Identification Date: Sun, 16 Mar 2003 23:56:50 -0800 Message-ID: Thread-Topic: Identification Thread-Index: AcLsU4JVuqZdTr0MRJqmbi0deFgrgQABgz6w From: "Tony Li" To: "David Conrad" , "Bound, Jim" Cc: X-Spam-Status: No, hits=1.0 required=5.0 tests=HTML_FONT_COLOR_BLUE,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-multi6@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C2EC5A.C420A634 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 I agree with most of what David said, except for this. I interpret Jim's comment as asking if the identifier is local to a particular location. In other words, it acts as the low order bits of the 'address'. The issue with this is that it makes absolute identification a bit more challenging. For example, suppose that A, B, C, ... are locators and we have identifier Z. =20 A.Z and B.Z just happen to be the same host because it's multihomed, but then C.Z is another host entirely. What happens? It means that hosts can no longer key on 'Z', and then have to have other mechanisms so that they can determine that A.Z and B.Z are the same host, both at an insecure and secure level. =20 If Z is instead global, then I believe that the identification problem is a bit simpler. Consider the role of looking up the TCB in your TCP implementation. You just index by Z and ports and you're done. No futzing around trying to figure out if A.Z and B.Z are the right thing. =20 For this reason, I would tend to favor making identifiers global. I think it's just simpler. However, the other way probably CAN be made to work with enough effort. In my mind, this is one of the microarchitectural pieces that we don't need to argue about now. =20 Tony =20 =09 =09 Can identifiers be within the context of Location?=20 Not sure what this means. Reachability to a given identifier depends on its locator, so perhaps I'd say yes. =20 =20 ------_=_NextPart_001_01C2EC5A.C420A634 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
 
I=20 agree with most of what David said, except for this.  I interpret = Jim's=20 comment as asking
if the=20 identifier is local to a particular location.  In other words, it = acts as=20 the low order bits
of the=20 'address'.  The issue with this is that it makes absolute = identification a=20 bit more
challenging.  For example, suppose that A, B, C, ... are = locators=20 and we have identifier Z.
 
A.Z=20 and B.Z just happen to be the same host because it's multihomed, but = then C.Z is=20 another
host=20 entirely.  What happens?  It means that hosts can no longer = key on=20 'Z', and then have to
have=20 other mechanisms so that they can determine that A.Z and B.Z are the = same host,=20 both
at an=20 insecure and secure level.
 
If Z=20 is instead global, then I believe that the identification problem is a = bit=20 simpler.  Consider the
role=20 of looking up the TCB in your TCP implementation.  You just index = by Z and=20 ports and you're
done.  No futzing around trying to figure out if A.Z and = B.Z are the=20 right thing.
 
For=20 this reason, I would tend to favor making identifiers global.  I = think it's=20 just simpler.
However, the other way probably CAN be made to work with enough = effort.  In my mind, this
is one=20 of the microarchitectural pieces that we don't need to argue about=20 now.
 
Tony
 

 Can identifiers be within the = context of=20 Location?


Not sure what this means. Reachability to a given identifier = depends on its=20 locator, so perhaps I'd say yes.  
 

=00 ------_=_NextPart_001_01C2EC5A.C420A634-- From owner-multi6@ops.ietf.org Mon Mar 17 02:57:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06240 for ; Mon, 17 Mar 2003 02:57:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18upWf-0003uc-00 for multi6-data@psg.com; Sun, 16 Mar 2003 23:59:17 -0800 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by psg.com with esmtp (Exim 3.36 #1) id 18upWd-0003uQ-00 for multi6@ops.ietf.org; Sun, 16 Mar 2003 23:59:15 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id CAB69A71; Mon, 17 Mar 2003 02:59:14 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Mar 2003 02:59:14 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Identification Date: Mon, 17 Mar 2003 02:59:14 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03241047@tayexc13.americas.cpqcorp.net> Thread-Topic: Identification Thread-Index: AcLsWM55WVtzovtpTJiFxNyUw3KDzgAAYd5Q From: "Bound, Jim" To: "Tim Chown" , X-OriginalArrivalTime: 17 Mar 2003 07:59:14.0720 (UTC) FILETIME=[1A4C9200:01C2EC5B] X-Spam-Status: No, hits=0.3 required=5.0 tests=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 CAA06240 > Also we want my CD player to be able to support a self healing link > > partition if I change the IPv6 scope of identifier, or > merge two links > > to one link local domain as two examples. > > Before long that piece of CD hifi is more likely to be a wireless MP3 > player which could download new tracks from anywhere. But if you are > constrained to the home I wouldn't want my appliances using > well-known MAC prefixes either else an inventory of household > electronics is on the wire as my TV/TiVo accesses programme > info or my CD accesses the cddb or my fridge auto-orders more > beer. Of course most households have these items, but the > MAC address might identify high-end products - so it's not > just a concern of privacy nut-cakes :) Yep. I suppose a terrorist could infect my fridge with some kind of virus and then I could eat that and die. Bummer. Yep better be able to change my MAC address (identifier) :---) > > (BTW, for my CD or MP3 player to query cddb to lookup track > info the lack of a stateless DNS discovery method means you > need a DHCP client in your > MP3 player...) Ahaha......another argument to support SHOULD for M/O bits for stateful in node requirements doc and how about a dhcpv6 beer server for your fridge, when low it shows up on your porch :--) /jim From owner-multi6@ops.ietf.org Mon Mar 17 03:01:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06345 for ; Mon, 17 Mar 2003 03:01:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18upaf-0004Ao-00 for multi6-data@psg.com; Mon, 17 Mar 2003 00:03:25 -0800 Received: from dmz1.procket.com ([65.174.124.36]) by psg.com with esmtp (Exim 3.36 #1) id 18upac-0004Ab-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 00:03:22 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id CAECF23C3E; Mon, 17 Mar 2003 00:28:11 -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 h2H83LYB022265; Mon, 17 Mar 2003 00:03:21 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2EC5B.AD5892F2" Subject: RE: The Network is Chaos should Routing be based on that Chaos Date: Mon, 17 Mar 2003 00:03:21 -0800 Message-ID: Thread-Topic: The Network is Chaos should Routing be based on that Chaos Thread-Index: AcLsTBZsl3Zqej/jTvemY1f+H4XSiQADxM4g From: "Tony Li" To: "Bound, Jim" , X-Spam-Status: No, hits=0.7 required=5.0 tests=HTML_FONT_COLOR_BLUE,SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C2EC5B.AD5892F2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 I'm sure that I need a couple of shots of Scotch before I'm in the frame of mind to fully understand where you're going Jim, but lemme see if I can clarify. =20 You're suggesting that routing not only know where static hosts are, but also ones that are changing location and that routing try to 'predict' where the host will be next. Did I get that right? =20 If I could write code that did that, I'd use it on the stock market, not on the Internet. ;-) I think you agree in your last line. I'm not sure what you were proposing at the last bit tho. Care to expound? =20 =20 Tony =20 -----Original Message----- From: Bound, Jim [mailto:Jim.Bound@hp.com]=20 Sent: Sunday, March 16, 2003 10:12 PM To: multi6@ops.ietf.org Subject: The Network is Chaos should Routing be based on that Chaos =09 =09 Chaotic Routing: =20 Whatever we define today will become chaotic tomorrow? =20 Does fractal analysis teach us anything? We may be able to group fractals for a period of time, but by definition the inherent chaotic property of those fractals will destroy any static order defined? =20 So there are multiple levels to address the Chaotic Routing model: =20 1. At time T the topology is at Location A 2. At time T1 the topology is at Location A+1 =20 Could it be we need enhancement to routing protocols to just exist for Location change? =20 Then under that routing we know how to do now based on that Location change, it becomes adaptive to Location A+1. =20 Predicting chaotic rate of change is impossible I suggest, and the best we can do is define Location and within specific rendezvous segments within that Location, which can be adaptive to T+1? =20 /jim =20 =20 ------_=_NextPart_001_01C2EC5B.AD5892F2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
 
 
I'm=20 sure that I need a couple of shots of Scotch before I'm in the frame of=20 mind
to=20 fully understand where you're going Jim, but lemme see if I can=20 clarify.
 
You're=20 suggesting that routing not only know where static hosts are, but=20 also
ones=20 that are changing location and that routing try to 'predict' where the=20 host
will=20 be next.  Did I get that right?
 
If I=20 could write code that did that, I'd use it on the stock market, not on=20 the
Internet.  ;-)  I think you agree in your last = line.  I'm=20 not sure what you were
proposing at the last bit tho.  Care to expound? =20
 
Tony
 
-----Original Message-----
From: = Bound, Jim=20 [mailto:Jim.Bound@hp.com]
Sent: Sunday, March 16, 2003 = 10:12=20 PM
To: multi6@ops.ietf.org
Subject: The Network is = Chaos=20 should Routing be based on that Chaos

Chaotic=20 Routing:
 
Whatever we define=20 today will become chaotic tomorrow?
 
Does = fractal=20 analysis teach us anything?  We may be able to group fractals for = a=20 period of time, but by definition the inherent chaotic property of = those=20 fractals will destroy any static order defined?
 
So = there are=20 multiple levels to address the Chaotic Routing = model:
 
1. = At time T the=20 topology is at Location A
2. = At time T1 the=20 topology is at Location A+1
 
Could it be we=20 need enhancement to routing protocols to just exist for Location=20 change?
 
Then = under that=20 routing we know how to do now based on that Location change, it = becomes=20 adaptive to Location A+1.
 
Predicting=20 chaotic rate of change is impossible I suggest, and the best = we can=20 do is define Location and within specific rendezvous segments within = that=20 Location, which can be adaptive to T+1?
 
/jim
 
 
=00 ------_=_NextPart_001_01C2EC5B.AD5892F2-- From owner-multi6@ops.ietf.org Mon Mar 17 03:04:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06365 for ; Mon, 17 Mar 2003 03:04:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18updF-0004Pg-00 for multi6-data@psg.com; Mon, 17 Mar 2003 00:06:05 -0800 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by psg.com with esmtp (Exim 3.36 #1) id 18updC-0004PK-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 00:06:02 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id B80FA52A2; Mon, 17 Mar 2003 03:06:01 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Mar 2003 03:06:01 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2EC5C.0C7A32BF" Subject: RE: Identification Date: Mon, 17 Mar 2003 03:06:01 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03241048@tayexc13.americas.cpqcorp.net> Thread-Topic: Identification Thread-Index: AcLsU4JVuqZdTr0MRJqmbi0deFgrgQABgz6wAABxfyA= From: "Bound, Jim" To: "Tony Li" , "David Conrad" Cc: X-OriginalArrivalTime: 17 Mar 2003 08:06:01.0577 (UTC) FILETIME=[0CCE0590:01C2EC5C] X-Spam-Status: No, hits=1.0 required=5.0 tests=HTML_FONT_COLOR_BLUE,SPAM_PHRASE_00_01 version=2.43 X-Spam-Level: * Sender: owner-multi6@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C2EC5C.0C7A32BF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree. But can we make them global? I think so. Ted Lemon fought this battle in DHCPv6 and there may be a precedent there at least it had consensus in that forum/WG. And we did come up with these really far fetched ways of breaking Teds postulate but it was silliness to even worry about it. Nothing will be perfect. Good point about Z + Port to find TCB. It must be possible I think. But my fridge should be able to update its identifier I think. =20 OK time to sleep. =20 /jim =20 =20 =20 -----Original Message----- From: Tony Li [mailto:Tony.Li@procket.com]=20 Sent: Monday, March 17, 2003 2:57 AM To: David Conrad; Bound, Jim Cc: multi6@ops.ietf.org Subject: RE: Identification =09 =09 =20 I agree with most of what David said, except for this. I interpret Jim's comment as asking if the identifier is local to a particular location. In other words, it acts as the low order bits of the 'address'. The issue with this is that it makes absolute identification a bit more challenging. For example, suppose that A, B, C, ... are locators and we have identifier Z. =20 A.Z and B.Z just happen to be the same host because it's multihomed, but then C.Z is another host entirely. What happens? It means that hosts can no longer key on 'Z', and then have to have other mechanisms so that they can determine that A.Z and B.Z are the same host, both at an insecure and secure level. =20 If Z is instead global, then I believe that the identification problem is a bit simpler. Consider the role of looking up the TCB in your TCP implementation. You just index by Z and ports and you're done. No futzing around trying to figure out if A.Z and B.Z are the right thing. =20 For this reason, I would tend to favor making identifiers global. I think it's just simpler. However, the other way probably CAN be made to work with enough effort. In my mind, this is one of the microarchitectural pieces that we don't need to argue about now. =20 Tony =20 =09 =09 Can identifiers be within the context of Location?=20 Not sure what this means. Reachability to a given identifier depends on its locator, so perhaps I'd say yes. =20 =20 ------_=_NextPart_001_01C2EC5C.0C7A32BF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
I=20 agree.  But can we make them global?  I think so.  Ted = Lemon=20 fought this battle in DHCPv6 and there may be a precedent there at least = it had=20 consensus in that forum/WG.  And we did come up with these really = far=20 fetched ways of breaking Teds postulate but it was silliness to even = worry about=20 it.  Nothing will be perfect.
Good=20 point about Z +  Port to find TCB.  It must be possible I = think. =20 But my fridge should be able to update its identifier I=20 think.
 
OK=20 time to sleep.
 
/jim
 
 
 
-----Original Message-----
From: Tony = Li=20 [mailto:Tony.Li@procket.com]
Sent: Monday, March 17, 2003 = 2:57=20 AM
To: David Conrad; Bound, Jim
Cc:=20 multi6@ops.ietf.org
Subject: RE: = Identification

 
I=20 agree with most of what David said, except for this.  I interpret = Jim's=20 comment as asking
if=20 the identifier is local to a particular location.  In other = words, it=20 acts as the low order bits
of=20 the 'address'.  The issue with this is that it makes absolute=20 identification a bit more
challenging.  For example, suppose that A, B, C, ... are = locators=20 and we have identifier Z.
 
A.Z=20 and B.Z just happen to be the same host because it's multihomed, but = then C.Z=20 is another
host=20 entirely.  What happens?  It means that hosts can no longer = key on=20 'Z', and then have to
have=20 other mechanisms so that they can determine that A.Z and B.Z are the = same=20 host, both
at=20 an insecure and secure level.
 
If Z=20 is instead global, then I believe that the identification problem is a = bit=20 simpler.  Consider the
role=20 of looking up the TCB in your TCP implementation.  You just index = by Z=20 and ports and you're
done.  No futzing around trying to figure out if A.Z and = B.Z are=20 the right thing.
 
For=20 this reason, I would tend to favor making identifiers global.  I = think=20 it's just simpler.
However, the other way probably CAN be made to work with = enough=20 effort.  In my mind, this
is=20 one of the microarchitectural pieces that we don't need to argue about = now.
 
Tony
 

 Can identifiers be within the = context of=20 Location?


Not sure what this means. Reachability to a given identifier = depends on=20 its locator, so perhaps I'd say yes.  
 

=00 ------_=_NextPart_001_01C2EC5C.0C7A32BF-- From owner-multi6@ops.ietf.org Mon Mar 17 03:08:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06407 for ; Mon, 17 Mar 2003 03:08:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uphg-0004Y4-00 for multi6-data@psg.com; Mon, 17 Mar 2003 00:10:40 -0800 Received: from dmz1.procket.com ([65.174.124.36]) by psg.com with esmtp (Exim 3.36 #1) id 18uphe-0004Xs-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 00:10:38 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 345A923C3E; Mon, 17 Mar 2003 00:35:28 -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 h2H8AbYB022386; Mon, 17 Mar 2003 00:10:38 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2EC5C.B16F0D06" Subject: RE: Location Date: Mon, 17 Mar 2003 00:10:37 -0800 Message-ID: Thread-Topic: Location Thread-Index: AcLsSgs7xJYH5uk+QKKDRW6582/UJgAEcRkw From: "Tony Li" To: "Bound, Jim" , X-Spam-Status: No, hits=1.9 required=5.0 tests=HTML_50_70,HTML_FONT_COLOR_BLUE,SPAM_PHRASE_08_13 version=2.43 X-Spam-Level: * Sender: owner-multi6@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C2EC5C.B16F0D06 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Location:=20 =20 Do we believe that providers should know location of all nodes on the Internet without peering?=20 =20 =20 That implies that you can route based on static location and implies that your locators are independent of the network topology. Unfortunately, that is exactly the reverse of what scales. It implies that you must flood=20 topology information for the entire net. =20 =20 Do we believe that providers should know location of all nodes within a specific topology, without peering?=20 =20 Same answer. You either distribute full topology information or prefix information. =20 Do we believe that providers should know location of all nodes within a specific topology within specific rendezvous points within the aforementioned specific topology, without peering?=20 =20 I can't parse. =20 Do we believe that providers should only know peerings for providers that exist near specific locations?=20 =20 This either. =20 Tony =20 ------_=_NextPart_001_01C2EC5C.B16F0D06 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Location: 
 
 Do=20 we believe that providers should know location of all nodes on the = Internet=20 without peering? 
 
 
That implies = that you=20 can route based on static location and implies that your locators are=20 independent of the
network = topology. =20 Unfortunately, that is exactly the reverse of what scales.  It = implies that=20 you must flood
topology = information for=20 the entire net.
 
 
 Do we believe that providers should know = location of=20 all nodes within a specific topology, without peering? 
 
Same = answer.  You=20 either distribute full topology information or prefix=20 information.
 
 Do we believe that providers should know = location of=20 all nodes within a specific topology within specific rendezvous points = within=20 the aforementioned specific topology, without peering? 
 
I can't=20 parse.
 
 Do we believe that providers should only know = peerings=20 for providers that exist near specific locations? 
 
This=20 either.
 
Tony
  =00 ------_=_NextPart_001_01C2EC5C.B16F0D06-- From owner-multi6@ops.ietf.org Mon Mar 17 03:12:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06509 for ; Mon, 17 Mar 2003 03:12:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18upkk-0004eY-00 for multi6-data@psg.com; Mon, 17 Mar 2003 00:13:50 -0800 Received: from dmz1.procket.com ([65.174.124.36]) by psg.com with esmtp (Exim 3.36 #1) id 18upki-0004e7-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 00:13:48 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 9E1F923C49; Mon, 17 Mar 2003 00:38: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 h2H8DlYB022426; Mon, 17 Mar 2003 00:13: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: multipart/alternative; boundary="----_=_NextPart_001_01C2EC5D.2260CFE8" Subject: RE: Routing Date: Mon, 17 Mar 2003 00:13:47 -0800 Message-ID: Thread-Topic: Routing Thread-Index: AcLsSo3t+L5GVeaNQnSAQp9sWnIdsgAEiz6A From: "Tony Li" To: "Bound, Jim" , X-Spam-Status: No, hits=1.9 required=5.0 tests=HTML_50_70,HTML_FONT_COLOR_BLUE,SPAM_PHRASE_08_13 version=2.43 X-Spam-Level: * Sender: owner-multi6@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C2EC5D.2260CFE8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Reducing the dynamic path implies that you're extending the static information. If that information is effectively static (e.g., a singly homed site), then having that information be static is a fine things. Certainly what most folks do with tail circuits today. =20 However, static routing to key locations locks you into those static paths, which may then fail. What now? =20 Note that you can do dynamic routing to a key location (a landmark) and then dynamic routing from there, but you quite possibly lose out on more optimal paths. I believe that someone has written a paper on just this, tho I can't confess to representing it. =20 Tony =20 Routing making it better: =20 Reduction of dynamic routing path would make routing better? =20 Static routes for key Locations as part of the above reduction would improve routing? =20 ------_=_NextPart_001_01C2EC5D.2260CFE8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
 
Reducing the dynamic path implies that you're = extending the=20 static information.
If that information is effectively static = (e.g., a singly=20 homed site), then having
that information be static is a fine = things. =20 Certainly what most folks do with
tail circuits today.
 
However, static routing to key locations locks = you into=20 those static paths, which may
then fail.  What = now?
 
Note that you can do dynamic routing to a key = location (a=20 landmark) and then dynamic
routing from there, but you quite possibly lose = out on more=20 optimal paths.  I believe
that someone has written a paper on just this, = tho I can't=20 confess to representing it.
 
Tony
 
Routing making it=20 better:
 
Reduction of=20 dynamic routing path would make routing better?
 
Static routes for=20 key Locations as part of the above reduction would improve=20 routing?
 
=00 ------_=_NextPart_001_01C2EC5D.2260CFE8-- From owner-multi6@ops.ietf.org Mon Mar 17 03:22:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06704 for ; Mon, 17 Mar 2003 03:22:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18upuv-0004wZ-00 for multi6-data@psg.com; Mon, 17 Mar 2003 00:24:21 -0800 Received: from dmz1.procket.com ([65.174.124.36]) by psg.com with esmtp (Exim 3.36 #1) id 18uput-0004wN-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 00:24:19 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 8CF4523C3E; Mon, 17 Mar 2003 00:49:08 -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 h2H8OIYB022926; Mon, 17 Mar 2003 00:24:18 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2EC5E.9A5F3DA2" Subject: RE: Reducing Peerings for MH Routing within a site via end systems Date: Mon, 17 Mar 2003 00:24:18 -0800 Message-ID: Thread-Topic: Reducing Peerings for MH Routing within a site via end systems Thread-Index: AcLsSOfSvGXrMnooRAieaRoipQ9LGwAFQc9w From: "Tony Li" To: "Bound, Jim" , 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 This is a multi-part message in MIME format. ------_=_NextPart_001_01C2EC5E.9A5F3DA2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If a host has multiple locators and a single identifier and other hosts are able to change the locator that they are using at will, then it implies that special routing information about that site need not be propagated upwards. Effectively, the site has PA space from each of its providers and that PA space is nicely aggregated in global routing. =20 Yes, this makes MHH's much nicer for global routing, tho it may still lead to issues with local routing. Kinda depends what you want to do within your IGP. One could reasonably argue that you take the layer of separation down recursively. =20 Note that this alleviates the most painful reason to avoid PA space: renumbering is now a non-issue. You assign a new locator to your entire site, advertise it to the world and you're good to go. Individual host identifiers need not change. No host renumbering. =20 Tony =20 =20 Do we agree on the following (I don't care about the high order words/terms). =20 Reducing Peering: =20 If a sites end systems do not depend on providers peering, but can always failover to other provider from within the site, this reduces the routing tables for the providers, and for the routers within the Internet in the MHH case? =20 Would this solve an immediate problem from IPv6 MHH case? =20 ------_=_NextPart_001_01C2EC5E.9A5F3DA2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

If a host has=20 multiple locators and a single identifier and other hosts are able to=20 change
the = locator that=20 they are using at will, then it implies that special routing=20 information
about = that site=20 need not be propagated upwards.  Effectively, the site has PA=20 space
from = each of its=20 providers and that PA space is nicely aggregated in global=20 routing.
 
Yes, = this makes=20 MHH's much nicer for global routing, tho it may still lead to=20 issues
with = local=20 routing.  Kinda depends what you want to do within your IGP.  = One=20 could
reasonably argue=20 that you take the layer of separation down = recursively.
 
Note = that this=20 alleviates the most painful reason to avoid PA space: renumbering=20 is
now a = non-issue.  You assign a new locator to your entire site, advertise = it to=20 the
world = and you're=20 good to go.  Individual host identifiers need not change.  No=20 host
renumbering.
 
Tony
 
 
Do = we agree on the=20 following (I don't care about the high order = words/terms).
 
Reducing=20 Peering:
 
If a = sites end=20 systems do not depend on providers peering, but can always failover to = other=20 provider from within the site, this reduces the routing tables for the = providers, and for the routers within the Internet in the = MHH=20 case?
 
Would this solve=20 an immediate problem from IPv6 MHH case?
 
=00 ------_=_NextPart_001_01C2EC5E.9A5F3DA2-- From owner-multi6@ops.ietf.org Mon Mar 17 03:25:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06738 for ; Mon, 17 Mar 2003 03:25:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18upy7-00051l-00 for multi6-data@psg.com; Mon, 17 Mar 2003 00:27:39 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18upy3-00051X-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 00:27:35 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2H8QVb86027; Mon, 17 Mar 2003 09:26:31 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Mon, 17 Mar 2003 09:26:30 +0100 (CET) From: Iljitsch van Beijnum To: "Bound, Jim" cc: Subject: RE: Identifier/locator recap In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCCC9@tayexc13.americas.cpqcorp.net> Message-ID: <20030317091658.S69506-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, 16 Mar 2003, Bound, Jim wrote: > > - Locators must always be present in each packet. But what about the > > identifiers? Do we include them in each packet (= tunneling) or are > > they implied? > If we can make them implied its an extra condition check for routers and > hosts but will make the overall architecture less heavy and less to > manage. I believe in overload though it is complex to implement not > impossible. Routers don't have to do anything, just the end points. Having the identifier in each packet really doesn't buy you any simplicity since the relationship between the locators and identifiers must be authenticated to steer clear of endless security troubles. > > There is also the question of what makes good identifiers. > > HIP uses the fingerprint of a cryptographic key. MHAP uses > > provider-independent IPv6 addresses that aren't visible in > > the global routing table. I myself have suggested to use > > FQDNs as the first choice. > I suggest not being dependent on crypto anything is wise it implies PKI > to the solution and I fear that is a non-starter? No, HIP is smarter than that. But what I find troublesome with that approach is that the identifiers are a flat 120+ bit space which makes it incredibly hard to create a distributed way to look up properties for identifiers. > I do think we need to work on the Model so it is clear to all and then > we can do the architecture and then apply implementation discussion? Sounds good to me. Iljitsch From owner-multi6@ops.ietf.org Mon Mar 17 03:34:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06862 for ; Mon, 17 Mar 2003 03:34:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uq6i-0005HH-00 for multi6-data@psg.com; Mon, 17 Mar 2003 00:36:32 -0800 Received: from mailout.zma.compaq.com ([161.114.64.105] helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18uq6e-0005Gb-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 00:36:28 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 367974FE8; Mon, 17 Mar 2003 03:36:28 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Mar 2003 03:36:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: The Network is Chaos should Routing be based on that Chaos Date: Mon, 17 Mar 2003 03:36:27 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03241049@tayexc13.americas.cpqcorp.net> Thread-Topic: The Network is Chaos should Routing be based on that Chaos Thread-Index: AcLsTBZsl3Zqej/jTvemY1f+H4XSiQADxM4gAABFG8A= From: "Bound, Jim" To: "Tony Li" , X-OriginalArrivalTime: 17 Mar 2003 08:36:28.0081 (UTC) FILETIME=[4D7C6A10:01C2EC60] 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 DAA06862 >I'm sure that I need a couple of shots of Scotch before I'm in the frame of mind >to fully understand where you're going Jim, but lemme see if I can clarify. Coffee works better :---) >You're suggesting that routing not only know where static hosts are, but also >ones that are changing location and that routing try to 'predict' where the host >will be next. Did I get that right? >If I could write code that did that, I'd use it on the stock market, not on the >Internet. ;-) I think you agree in your last line. I'm not sure what you were >proposing at the last bit tho. Care to expound? Sure. Assume for discussion there are only two locations X and Y. If X is location for X1, X2, ....Xn and Y is location for Y1, Y2, ...Yn X only has to worry about its routes and only if something comes to X for Y. If X1 moves to Y it becomes Y-'X1' (being the global id of X but now part of Y) So Locations are static to start simply for high order route prefixes or locators how ever they are to be defined. Now suppose that Y gets to big or to chaotic and the routing tables/performance/etc is predicted to be bad soon. Then we have a way to take Y and make Y and Z and now we have three locations X, Y, and Z. THis would be a formal location change control routing protocol. So I am not saying predict movement but design it into the algorithm for location "expansion" via routing protoocol and inherent to the architecture. Location change would have to be propogated across the system yes. Using ipv6mh ideas if we define specific locations this can be done for a long time with IPv6 128bits on planet earth. That's a lot of bits. So this is a means to adapt to the chaos of change we cannot see. Like right now and more so very soon imagine all the IP devices about to descend. Then nano sensors. Then stuff I can't imagine right now without some sleep :---) THe point is the system keeps growing and then splitting much like our galaxy :--) There is no order its all chaos. All we can do is see patterns and adapt through location routing updates. That is why extensibility is key to any protocol (earlier comment this a.m.). We reached the limit with IPv4 and now bad stuff is going to happen if it is not replaced expediently. So if we can compromise here on an answer with IPv6 and not break apps/apis/basic stuff but alter to get to location + identifier we are probably ok for 20-30 years. And if not well we do it again. Not much lasts longer than that regardless of what we do. The IETF is an infinite recursive effort for all time now :---) Unless we really screw up and blow up the planet. Did that help? /jim From owner-multi6@ops.ietf.org Mon Mar 17 03:48:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07009 for ; Mon, 17 Mar 2003 03:48:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uqJJ-0005an-00 for multi6-data@psg.com; Mon, 17 Mar 2003 00:49:33 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18uqJD-0005ab-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 00:49:28 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2H8mRu86064; Mon, 17 Mar 2003 09:48:27 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Mon, 17 Mar 2003 09:48:27 +0100 (CET) From: Iljitsch van Beijnum To: David Conrad cc: Subject: Re: Identification In-Reply-To: <164A28A8-5844-11D7-B7F3-000393DB42B2@nominum.com> Message-ID: <20030317092653.Y69506-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id DAA07009 On Sun, 16 Mar 2003, David Conrad wrote: > To me, identifiers are values that uniquely and globally (at least > within the context of an internet) identify communication end points. This is old-style thinking. :-) What makes a good identifier? Not something like an EUI64 identifier, for the following reasons: 1. no usable hierarchy, hard to create a distributed database 2. when I replace my network card, I haven't changed my identity 3. It would be extremely hard to make sure each EUI64 is only used once globally 4. I could very well be using several network cards but it's still always "me" So we need to identify hosts rather than interfaces. But we can be even more radical if we want to: an identity could be assigned to a service or other resource that lives on more than one host. If I want to connect to www.cnn.com, do I care whether I get www4.cnn.com or www7.cnn.com? On the other hand, when i have a connection, I want to keep communicating with the same host for the life time of the connection. I feel FQDNs are the ideal identifiers. They have a good hierarchy and the past 10 years or so have shown that building a distributed database to look up properties associated with them can work well. Also, it is possible to map arbitrary stuff (IPv4 or IPv6 addresses, phone numbers) to FQDNs so it should still be possible to adopt "better" identifiers later. (Or "inferior" ones first for backward compatibility.) (But maybe I'm getting ahead of things.) > >  But we cannot hard code identifiers in silicon? > There is no _technical_ reason this couldn't be done. Again, how are you going to look them up? Without some form of hierarchy you need a centralized database. This is unworkable on a global scale. Iljitsch From owner-multi6@ops.ietf.org Mon Mar 17 03:54:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07159 for ; Mon, 17 Mar 2003 03:54:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uqPb-0005ls-00 for multi6-data@psg.com; Mon, 17 Mar 2003 00:56:03 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18uqPY-0005lU-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 00:56:01 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2H8t3U86080; Mon, 17 Mar 2003 09:55:03 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Mon, 17 Mar 2003 09:55:03 +0100 (CET) From: Iljitsch van Beijnum To: David Conrad cc: Subject: Re: Identification In-Reply-To: <88DDF8B4-584C-11D7-B7F3-000393DB42B2@nominum.com> Message-ID: <20030317094830.E69506-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, 16 Mar 2003, David Conrad wrote: > However, if they only burned the lower 64 bits of an IPv6 address into > their chips as permanent identifiers, there is no issue provided those > identifiers are globally unique. Even assuming they come out of the factory with unique addresses (I've heard stories from people getting 5 cards all with the same address) how long is this going to stay unique after my little brother types "man ifconfig"? Sure, it's possible to repair all these problems, but why exactly were we doing this in the first place again...? Hardware addresses make bad identifiers. Just give me 64 bytes of NVRAM so I can burn in the identifier of my choice. From owner-multi6@ops.ietf.org Mon Mar 17 04:08:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07561 for ; Mon, 17 Mar 2003 04:08:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uqck-000678-00 for multi6-data@psg.com; Mon, 17 Mar 2003 01:09:38 -0800 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.36 #1) id 18uqci-00066s-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 01:09:36 -0800 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id UAA08823; Mon, 17 Mar 2003 20:09:26 +1100 (EST) Date: Mon, 17 Mar 2003 20:09:26 +1100 (EST) From: Peter Tattam To: Iljitsch van Beijnum cc: David Conrad , multi6@ops.ietf.org Subject: Re: Identification In-Reply-To: <20030317094830.E69506-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 As long as they are unique enough within a site, I can't see a problem. All you want is to not be mistaken for someone else in the quagmire of the internet soup. A site is a pretty good approximation. The GUID is only a few more bits of uniqueness. Peter P.S. waiting for Jim's beer server to arrive on the back doorstep. We had a 30 degrees celsius day here :) On Mon, 17 Mar 2003, Iljitsch van Beijnum wrote: > On Sun, 16 Mar 2003, David Conrad wrote: > > > However, if they only burned the lower 64 bits of an IPv6 address into > > their chips as permanent identifiers, there is no issue provided those > > identifiers are globally unique. > > Even assuming they come out of the factory with unique addresses > (I've heard stories from people getting 5 cards all with the same > address) how long is this going to stay unique after my little brother > types "man ifconfig"? > > Sure, it's possible to repair all these problems, but why exactly were > we doing this in the first place again...? Hardware addresses make bad > identifiers. Just give me 64 bytes of NVRAM so I can burn in the > identifier of my choice. > > > -- 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 Mar 17 04:43:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08662 for ; Mon, 17 Mar 2003 04:43:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18urAH-00070u-00 for multi6-data@psg.com; Mon, 17 Mar 2003 01:44:17 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18urA5-00070G-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 01:44:06 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2H9guC86150; Mon, 17 Mar 2003 10:42:56 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Mon, 17 Mar 2003 10:42:56 +0100 (CET) From: Iljitsch van Beijnum To: Peter Tattam cc: David Conrad , Subject: Re: Identification In-Reply-To: Message-ID: <20030317103614.I69506-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-1.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 17 Mar 2003, Peter Tattam wrote: > As long as they are unique enough within a site, I can't see a problem. All > you want is to not be mistaken for someone else in the quagmire of the internet > soup. A site is a pretty good approximation. The GUID is only a few more bits > of uniqueness. What we need here is something that uniquely identifies one end of a transport session for at least the duration of such a session (for which there is no clear upper bound). The lower 64 bits of an IP address can't be such an identifier because several hosts on the internet can use the same value for the lower 64 bits of their address at the same time and there is no way to make sure they won't try to communicate with the same host at the same time. We have duplicate address detection on local links for a reason... From owner-multi6@ops.ietf.org Mon Mar 17 04:54:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08939 for ; Mon, 17 Mar 2003 04:54:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18urMN-0007r9-00 for multi6-data@psg.com; Mon, 17 Mar 2003 01:56:47 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 18urMK-0007q8-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 01:56:45 -0800 From: Masataka Ohta Message-Id: <200303170944.SAA20431@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id SAA20431; Mon, 17 Mar 2003 18:44:12 +0900 Subject: Re: Identifier/locator recap In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCCC9@tayexc13.americas.cpqcorp.net> from "Bound, Jim" at "Mar 16, 2003 11:40:56 pm" To: "Bound, Jim" Date: Mon, 17 Mar 2003 18:44:11 +0859 () CC: Iljitsch van Beijnum , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-0.7 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Jim; > I think the MIPv6 MHH is on the right track and it is an excellent piece > of technical work. I have read it twice and I believe it could work. No. MIPV6 is on IP layer having no idea on proper time out values, which depends on transport/application layers, and is not a solution. Masataka Ohta From owner-multi6@ops.ietf.org Mon Mar 17 05:04:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09144 for ; Mon, 17 Mar 2003 05:04:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18urW1-0008Bj-00 for multi6-data@psg.com; Mon, 17 Mar 2003 02:06:45 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 18urVx-0008B6-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 02:06:42 -0800 From: Masataka Ohta Message-Id: <200303170959.SAA20532@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id SAA20532; Mon, 17 Mar 2003 18:58:50 +0859 Subject: Re: Again no multi6 at IETF#56 In-Reply-To: from Kurt Erik Lindqvist at "Mar 16, 2003 06:57:59 pm" To: Kurt Erik Lindqvist Date: Mon, 17 Mar 2003 18:58:50 +0859 () CC: Iljitsch van Beijnum , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-1.0 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Kurt; > >>>> I think you need to go and check the RIR policies. They are not the > >>>> same. They are similar, but not the same. > >>> > >>> They don't have to be similar but they have to be consistent. > >> > >> Which is what I meant and what they are. > > > > How can you be sure they are consistent? Note that they may not > > be similar. > > I know the three policies fairly well. They are not similar but they > are fairly consistent. How can you be sure they are consistent? What is the evaluation criteria? > They are at least not diverse enough to create > competition among the RIRs (which is what started this part of the > thread). You are saying they are similar. > > Then, we need some policy to deny some assignment based on the > > technical reasoning on why, how and how seriously the resource > > is limited. > > > > The resource is limited as there is a fixed number of addresses. The > RIRs was created to handled and manage policy for a limited resource. > Let's use them for that. The IETF was created to develop standards let > them handle that. So, IETF must supply standards and technical rationals behind them. > I fail to see what problem you are trying to point out here. I see no problem not to let RIRs assign IPv6 addresses. I fail to see what problem you are trying to point out here. Masataka Ohtaq From owner-multi6@ops.ietf.org Mon Mar 17 05:05:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09183 for ; Mon, 17 Mar 2003 05:05:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18urWl-0008Cz-00 for multi6-data@psg.com; Mon, 17 Mar 2003 02:07:31 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 18urWj-0008Cm-00; Mon, 17 Mar 2003 02:07:29 -0800 From: Masataka Ohta Message-Id: <200303170953.SAA20520@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id SAA20520; Mon, 17 Mar 2003 18:53:16 +0900 Subject: Re: Again no multi6 at IETF#56 In-Reply-To: from Pierre Baume at "Mar 16, 2003 11:18:11 pm" To: Pierre Baume Date: Mon, 17 Mar 2003 18:53:16 +0859 () CC: Michel Py , Tony Li , "Bound, Jim" , Randy Bush , Kurt Erik Lindqvist , Bob Hinden , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=0.1 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Pierre; > > > Tony Li wrote: > > > Not particularly. But I can state it very succinctly: > > > a host needs one identifier and multiple locators. > > > > Mmmm. This sounds familiar. > > > > Michel. > > Hrm, like in the dns system? In a sense, yes. It is necessary to involve DNS for, say, ID->locator mapping. However, a problem of using a domain name as an identifier is that not all the packets contain the domain name. If you work hard, connection oriented protocols such as TCP may mostly work. But, the approach is not applicable to the connectionless Internet. Another desirable property (to prevent source locator forging etc.) is to let source ISPs modify the source locator, which is impossible with 16+16. Masataka Ohta From owner-multi6@ops.ietf.org Mon Mar 17 05:15:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09368 for ; Mon, 17 Mar 2003 05:15:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18urfj-0008WF-00 for multi6-data@psg.com; Mon, 17 Mar 2003 02:16:47 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 18urfg-0008VM-00; Mon, 17 Mar 2003 02:16:44 -0800 From: Masataka Ohta Message-Id: <200303171011.TAA20626@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id TAA20626; Mon, 17 Mar 2003 19:11:16 +0900 Subject: Re: Again no multi6 at IETF#56 In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B0324103C@tayexc13.americas.cpqcorp.net> from "Bound, Jim" at "Mar 16, 2003 07:00:22 am" To: "Bound, Jim" Date: Mon, 17 Mar 2003 19:11:15 +0859 () CC: Michel Py , Tony Li , Randy Bush , Kurt Erik Lindqvist , Bob Hinden , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=0.8 required=5.0 tests=CASHCASHCASH,IN_REP_TO,MSG_ID_ADDED_BY_MTA_2, QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Jim; > > > Production addresses are now being handed out now to ISPs > > and ISPs to > > > end users. > > > > No. > > > > Production means QUANTITY. > > Production to me means USE. Then, all most all the protocols are used by small number of people. So? (See below for "$$$$$$$$$$$$$$$$$$$$$$$$$") > > > I won't go into the reasons why it is happening but it is > > and far more > > > than most would imagine. > > > > I fully agree with you. It has been and is happening for > > these 8 years and will continue to be happening for next 8 years. > > > > > The first production use of IPv6 will be > > > 3GPP IM subsystem and I believe by this time next year it > > will exists. > > > > 3GPP has nothing to do with the Internet. > > Yes it does. It is doing it in baby steps with IM system. Not at all. 3GPP may use IPv6 as private IP-based telephone network. But that's all. Distinguish VoIP over charged IP-based telehone network and free "Voice over the Internet". > > The world largest deployment of mobile-capable IPv6 Internet > > is our LIN6-based project in Kyoto with hundreds of wireless > > base stations (but, with little users, because the base > > stations are, of course, IPv4 capable). > > Yes. But that will change. I believe this will overrule 3GPP too. What will change? > > > Multihoming is clearly documented to be a problem area. Any user I > > > know is aware of the problem. But it is perceived to be an ISP > > > problem mostly. > > > > Then, it is a problem of RIRs, collections of ISPs. > > problem is solved. > > But the deployment will not stop nor does it have to thusb far. Aren't you saying that the deployment should not, IYHO, stop but has been starting (that is stopping) for these 8 years? > > > For those facing this now with some test bed deployment where their > > > > As the problem is scalability, test bed, which means small > > scale, deployment is helpless. > > Not clear to me this is true. How large is the routing tablel of 6bone? > > > IPv6 deployment will not wait for multi-homing to be solved. > > > > Then, what has been waited for? > > $$$$$$$$$$$$$$$$$$$$$$$$$ The commercial value ($$$$$$$$$$$$$$$$$$$$$$$$$) of a network is proportional to the number of users connected to it. The Internet has defeated leagacy networks only because very small users was using the leagacy networks for data communmication. > > > More importantly what I believe will > > > bust open is home use with IPv6. > > > > Some may use IPv6 at research labo. Very few at home. > > I believe that will change and maybe in the U.S. first. Within 10 years, maybe. But, it can not be a reason to argue against modification to IPv6. Masataka Ohta From owner-multi6@ops.ietf.org Mon Mar 17 05:24:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09513 for ; Mon, 17 Mar 2003 05:24:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18urpS-0008qc-00 for multi6-data@psg.com; Mon, 17 Mar 2003 02:26:50 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 18urpP-0008qE-00; Mon, 17 Mar 2003 02:26:47 -0800 From: Masataka Ohta Message-Id: <200303171018.TAA20719@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id TAA20719; Mon, 17 Mar 2003 19:18:39 +0900 Subject: Re: Again no multi6 at IETF#56 In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCCB5@tayexc13.americas.cpqcorp.net> from "Bound, Jim" at "Mar 16, 2003 06:49:29 am" To: "Bound, Jim" Date: Mon, 17 Mar 2003 19:18:39 +0859 () CC: Tony Li , Michel Py , Randy Bush , Kurt Erik Lindqvist , Bob Hinden , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-0.4 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_03_05 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Jim; > You don't get it. Your own country has IPv6 deployed as I depicted in > your native backbone. You never will get it I fear. As I said, we deplyed LIN6-based homed environment with hundreds of routers. If you call it production level IPv6 deployment, I'm fine. But, it does not change the reality that IPv6 is not deployed not even in Japan. > I have a kanto > sword given to me my martial arts master should I bring it :--) You seems to be having a very strange view to Japan. I have never heard about a sword called "a kanto sword". Or, are you talking about Occam's Razor to be applicable to the current IPv6 specification? Masataka Ohta From owner-multi6@ops.ietf.org Mon Mar 17 05:37:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09907 for ; Mon, 17 Mar 2003 05:37:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18us0g-0009E9-00 for multi6-data@psg.com; Mon, 17 Mar 2003 02:38:26 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18urze-0009Ay-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 02:37:22 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2HAaNf86246; Mon, 17 Mar 2003 11:36:25 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Mon, 17 Mar 2003 11:36:23 +0100 (CET) From: Iljitsch van Beijnum To: marcelo bagnulo cc: Subject: Re: Move forward In-Reply-To: <1047839560.789.282.camel@presto.it.uc3m.es> Message-ID: <20030317110728.P69506-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 16 Mar 2003, marcelo bagnulo wrote: > > - Why don't you look at the return traffic to see if the path is still > > viable? If you keep (re)sending data but there is no reply from the > > other side, something must be broken. This probably needs per-session > > state, though. > A proposed extension for MIPv6 is the piggybacking of mobility messages > in regular traffic. In this case you would use return traffic to > transport signaling data. This kind of optimizations can be done. I didn't mean including explicit signaling in the normal traffic, but just _looking_ at the normal traffic to see if everything still works. This could work by having a list of destination hosts we're communicating with. Each time a normal-looking packet (ie non-ICMP, non-tunnel, non-multicast, big enough so it's not just an ACK) goes out, some session state is saved and a timer is started. When the timer elapses (after 5 or 10 seconds or so) without any return traffic, we do a "real" reachability check. So during normal traffic flow, there is no need for explicit or piggy-backed reachability checks. This probably needs some more heuristics, but I think it could work well. > However this mechanism allows the it is used also in unidirectional > traffic, which i guess is a good feature All regular unicast protocols need some form of acknowledgement in order to keep the traffic flowing. Without this, traffic would continue to flow long after the receiver has disappeared. That would be extremely bad. > > - "If a failure has occurred along the path, the attempt to initiate > > the communication will fail and the CN will try again with another > > address. Eventually, a packet from CN will reach MHH." As this is > > application-dependent you can't count on this. Worse: the all-time > > most popular networked application typically chokes if the first address > > tried doesn't work. > Good point. I do not have much data about how applications normally > behave in this case. But if this is the case, this is an issue. However, > AFAIK this is probably the case for IPv4 where interfaces usually have > only one address configured. The number of addresses per interface isn't really an issue, I would think. In v4 having several addresses for a DNS name isn't all that unusual: > host www.cnn.com www.cnn.com is a nickname for cnn.com cnn.com has address 64.236.24.28 cnn.com has address 64.236.16.20 cnn.com has address 64.236.16.52 cnn.com has address 64.236.16.84 cnn.com has address 64.236.16.116 cnn.com has address 64.236.24.4 cnn.com has address 64.236.24.12 cnn.com has address 64.236.24.20 > However in IPv6, considering "Default > Address Selection mechanism" i was hoping that application used the list > of addresses generated by the mechanism and try to use them to > communicate Actually this may make it worse, as the "best" address is always selected. If the "best" address is unreachable, no dice. At least with random or round robin you can hit reload to try again. Iljitsch From owner-multi6@ops.ietf.org Mon Mar 17 09:27:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14035 for ; Mon, 17 Mar 2003 09:27:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uvZT-000HAJ-00 for multi6-data@psg.com; Mon, 17 Mar 2003 06:26:35 -0800 Received: from smtp03.uc3m.es ([163.117.136.123] helo=smtp.uc3m.es) by psg.com with esmtp (Exim 3.36 #1) id 18uvZN-000HA2-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 06:26:29 -0800 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 8F6474312A; Mon, 17 Mar 2003 15:26:28 +0100 (CET) Received: from presto.it.uc3m.es (presto.it.uc3m.es [163.117.139.134]) by smtp03.uc3m.es (Postfix) with ESMTP id 5BB1E99E7B; Mon, 17 Mar 2003 15:26:28 +0100 (CET) Subject: Re: Move forward From: marcelo bagnulo To: Iljitsch van Beijnum Cc: multi6@ops.ietf.org In-Reply-To: <20030317110728.P69506-100000@sequoia.muada.com> References: <20030317110728.P69506-100000@sequoia.muada.com> Content-Type: text/plain Organization: uc3m Message-Id: <1047911180.720.25.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 17 Mar 2003 15:26:21 +0100 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I didn't mean including explicit signaling in the normal traffic, but > just _looking_ at the normal traffic to see if everything still works. > This could work by having a list of destination hosts we're > communicating with. Each time a normal-looking packet (ie non-ICMP, > non-tunnel, non-multicast, big enough so it's not just an ACK) goes out, > some session state is saved and a timer is started. When the timer > elapses (after 5 or 10 seconds or so) without any return traffic, we do > a "real" reachability check. So during normal traffic flow, there is no > need for explicit or piggy-backed reachability checks. This probably > needs some more heuristics, but I think it could work well. > I agree that better and more optimal failure detection can be provided, which could use some of these ideas. I am more worried about MIPv6 timers though... [...] > > > - "If a failure has occurred along the path, the attempt to initiate > > > the communication will fail and the CN will try again with another > > > address. Eventually, a packet from CN will reach MHH." As this is > > > application-dependent you can't count on this. Worse: the all-time > > > most popular networked application typically chokes if the first address > > > tried doesn't work. > > > Good point. I do not have much data about how applications normally > > behave in this case. But if this is the case, this is an issue. However, > > AFAIK this is probably the case for IPv4 where interfaces usually have > > only one address configured. > > The number of addresses per interface isn't really an issue, I would > think. In v4 having several addresses for a DNS name isn't all that > unusual: > > > host www.cnn.com > www.cnn.com is a nickname for cnn.com > cnn.com has address 64.236.24.28 > cnn.com has address 64.236.16.20 > cnn.com has address 64.236.16.52 > cnn.com has address 64.236.16.84 > cnn.com has address 64.236.16.116 > cnn.com has address 64.236.24.4 > cnn.com has address 64.236.24.12 > cnn.com has address 64.236.24.20 > > > However in IPv6, considering "Default > > Address Selection mechanism" i was hoping that application used the list > > of addresses generated by the mechanism and try to use them to > > communicate > > Actually this may make it worse, as the "best" address is always > selected. If the "best" address is unreachable, no dice. At least with > random or round robin you can hit reload to try again. > Sorry i am probably missing something... >From RFC 3484 6. Destination Address Selection The destination address selection algorithm takes a list of destination addresses and sorts the addresses to produce a new list. ^^^^ I guess that applications now obtain a list of addresses, after the default address selection mechanism has sorted them. Moreover, the first rule of the mechanism discards unreachable destinations, so if one of multiple is unreachable it will be included last. Regards, marcelo > Iljitsch -- marcelo bagnulo uc3m From owner-multi6@ops.ietf.org Mon Mar 17 09:36:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14306 for ; Mon, 17 Mar 2003 09:36:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uvkw-000Hg5-00 for multi6-data@psg.com; Mon, 17 Mar 2003 06:38:26 -0800 Received: from teldanex.hiit.fi ([212.68.5.99] helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 3.36 #1) id 18uvkt-000Hfk-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 06:38:23 -0800 Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 93FD51C; Mon, 17 Mar 2003 16:48:25 +0200 (EET) Message-ID: <3E75DDE8.9080108@nomadiclab.com> Date: Mon, 17 Mar 2003 06:38:32 -0800 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030310 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum Cc: "Bound, Jim" , multi6@ops.ietf.org Subject: Re: Identifier/locator recap References: <20030317091658.S69506-100000@sequoia.muada.com> In-Reply-To: <20030317091658.S69506-100000@sequoia.muada.com> 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 Iljitsch van Beijnum wrote: > No, HIP is smarter than that. But what I find troublesome with that > approach is that the identifiers are a flat 120+ bit space which makes > it incredibly hard to create a distributed way to look up properties for > identifiers. Not really. Distributes hash tables (DHT) should work. Somebody just need to work out the details; they are not exactly simple, though. But not that complicated either, I would believe. See the proceedings of recent peer-to-peer conferences and you will find multiple occasions where DHTs have been used. --Pekka Nikander From owner-multi6@ops.ietf.org Mon Mar 17 09:45:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14464 for ; Mon, 17 Mar 2003 09:45:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uvtY-000I6m-00 for multi6-data@psg.com; Mon, 17 Mar 2003 06:47:20 -0800 Received: from mailout.zma.compaq.com ([161.114.64.103] helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18uvtV-000I6a-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 06:47:17 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id A3E2944B1; Mon, 17 Mar 2003 09:47:16 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Mar 2003 09:47:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Routing Date: Mon, 17 Mar 2003 09:47:16 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0324104B@tayexc13.americas.cpqcorp.net> Thread-Topic: Routing Thread-Index: AcLsSo3t+L5GVeaNQnSAQp9sWnIdsgAEiz6AAA2cnCA= From: "Bound, Jim" To: "Tony Li" , X-OriginalArrivalTime: 17 Mar 2003 14:47:16.0560 (UTC) FILETIME=[1A9CE500:01C2EC94] X-Spam-Status: No, hits=0.0 required=5.0 tests=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 JAA14464 > However, static routing to key locations locks you into those static paths, > which maythen fail. What now? My assumption is those locations are minimal. Forward to them is fast lookup and high order bits. Failover is not a function IMO of any protocol but implementation. But the protocol should have features within it to permit failover. As a note I figured out how to completely failover TCP and SCTP and UDP in implementation, and including all protocol context and state and transfer that state in proprietary manner. Hopefully I will get rich :--). But to do it in open source and public domain manner requires protocol attributes. The BU for MIPv6 is very close to provide this either in router or host but not complete solution. >Note that you can do dynamic routing to a key location (a landmark) and then >dynamic routing from there, but you quite possibly lose out on more optimal >paths. I believe that someone has written a paper on just this, tho I can't >confess to representing it. This sounds very good. Besides the macro view we also have to realize we will not achieve perfection. /jim From owner-multi6@ops.ietf.org Mon Mar 17 09:58:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14716 for ; Mon, 17 Mar 2003 09:58:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uw5n-000Iey-00 for multi6-data@psg.com; Mon, 17 Mar 2003 06:59:59 -0800 Received: from mailout.zma.compaq.com ([161.114.64.105] helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18uw5g-000Ie7-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 06:59:52 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id E2B5C529D; Mon, 17 Mar 2003 09:59:51 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Mar 2003 09:59:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Location Date: Mon, 17 Mar 2003 09:59:43 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0324104C@tayexc13.americas.cpqcorp.net> Thread-Topic: Location Thread-Index: AcLsSgs7xJYH5uk+QKKDRW6582/UJgAEcRkwAA4UOKA= From: "Bound, Jim" To: "Tony Li" , X-OriginalArrivalTime: 17 Mar 2003 14:59:49.0660 (UTC) FILETIME=[DB7ED5C0:01C2EC95] X-Spam-Status: No, hits=0.8 required=5.0 tests=QUOTED_EMAIL_TEXT,SPAM_PHRASE_05_08 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 JAA14716 >>Location: >> Do we believe that providers should know location of all nodes on the Internet >>without peering? >That implies that you can route based on static location and implies that your >locators are independent of the network topology. Unfortunately, that is >exactly the reverse of what scales. It implies that you must flood >topology information for the entire net. I agree. I do not believe this is a solution but put it here to kill it. >>Do we believe that providers should know location of all nodes within a >> specific topology, without peering? >Same answer. You either distribute full topology information or prefix >information. I think answer is different. If the topology sectors are say under ordinal 100? Why is that unreasonable. We do not need all topology flood for each topology sector or AS domain. It is a simple fast path to 100 or less locations? I believe we can begin the locations less than 20 initially for IPv6? >>Do we believe that providers should know location of all nodes within a >>specific topology within specific rendezvous points within the aforementioned >>specific topology, without peering? >I can't parse. If location became greater than 100 then within each topology some locations become redezvous point (RZP). The RZPs are not propogated above any topology sector. It is hierarchical lower route only to that location? >>Do we believe that providers should only know peerings for providers that >> exist near specific locations? >This either. Provider = Topology Sectors. Providers would not know RZPs in other Sectors? Thanks /jim Tony From owner-multi6@ops.ietf.org Mon Mar 17 09:59:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14747 for ; Mon, 17 Mar 2003 09:59:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uw78-000Ii8-00 for multi6-data@psg.com; Mon, 17 Mar 2003 07:01:22 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18uw6y-000Ihg-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 07:01:12 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2HF13g00386; Mon, 17 Mar 2003 17:01:03 +0200 Date: Mon, 17 Mar 2003 17:01:02 +0200 (EET) From: Pekka Savola To: Iljitsch van Beijnum cc: "Bound, Jim" , Subject: HIP and PKI reqs [RE: Identifier/locator recap] In-Reply-To: <20030317091658.S69506-100000@sequoia.muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-0.9 required=5.0 tests=IN_REP_TO,SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01, USER_AGENT_PINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 17 Mar 2003, Iljitsch van Beijnum wrote: > > I suggest not being dependent on crypto anything is wise it implies PKI > > to the solution and I fear that is a non-starter? > > No, HIP is smarter than that. [...] Uhh, no. HIP requires either DNSsec or opportunistic key distribution a la SSH. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Mon Mar 17 10:13:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16221 for ; Mon, 17 Mar 2003 10:13:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uwKb-000JTZ-00 for multi6-data@psg.com; Mon, 17 Mar 2003 07:15:17 -0800 Received: from teldanex.hiit.fi ([212.68.5.99] helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 3.36 #1) id 18uwKQ-000JTI-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 07:15:06 -0800 Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id C81EB1C; Mon, 17 Mar 2003 17:25:09 +0200 (EET) Message-ID: <3E75E684.9080502@nomadiclab.com> Date: Mon, 17 Mar 2003 07:15:16 -0800 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030310 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola Cc: Iljitsch van Beijnum , "Bound, Jim" , multi6@ops.ietf.org Subject: Re: HIP and PKI reqs [RE: Identifier/locator recap] References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02, USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: > On Mon, 17 Mar 2003, Iljitsch van Beijnum wrote: > >>>I suggest not being dependent on crypto anything is wise it implies PKI >>>to the solution and I fear that is a non-starter? >> >>No, HIP is smarter than that. [... > > Uhh, no. HIP requires either DNSsec or opportunistic key distribution a > la SSH. Opportunistic key distribution a la SSH works pretty well. Going further, HIP *without* DNSsec/PKI is slightly *more* secure than today's insecured TCP/UDP, even if HIP is used to implement mobility and/or multihoming. See our security ' analysis in our recent NDSS'03 paper. However, if you want to use HIP to secure something that goes beyond mobility or multi-homing, or want to achieve a security level that is more than slightly more secure than the current unsecured IPv4, you have to rely on DNSsec, or accept the vulnerabilities in opportunistic mode. Summary: HIP without DNSsec or PKI can provide security for mobility and/or multi-homing that is acceptable according to the current security requirements. --Pekka Nikander From owner-multi6@ops.ietf.org Mon Mar 17 10:15:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16414 for ; Mon, 17 Mar 2003 10:15:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uwMZ-000JXz-00 for multi6-data@psg.com; Mon, 17 Mar 2003 07:17:19 -0800 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by psg.com with esmtp (Exim 3.36 #1) id 18uwMT-000JWo-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 07:17:13 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 032F74449; Mon, 17 Mar 2003 10:17:11 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Mar 2003 10:17:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Reducing Peerings for MH Routing within a site via end systems Date: Mon, 17 Mar 2003 10:17:07 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0324104D@tayexc13.americas.cpqcorp.net> Thread-Topic: Reducing Peerings for MH Routing within a site via end systems Thread-Index: AcLsSOfSvGXrMnooRAieaRoipQ9LGwAFQc9wAA4h0VA= From: "Bound, Jim" To: "Tony Li" , X-OriginalArrivalTime: 17 Mar 2003 15:17:11.0763 (UTC) FILETIME=[48A32230:01C2EC98] 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 KAA16414 >If a host has multiple locators and a single identifier and other hosts are able >to change the locator that they are using at will, then it implies that special Clarification. Above you have "conjunction" ...and other hosts? I assume you mean any host can change their locator? >routing information about that site need not be propagated upwards. That is where I was going with RZPs. >Effectively, the site has PA space from each of its providers and that PA space >is nicely aggregated in global routing. So the locators for this site is known by all of the sites providers, correct? >Yes, this makes MHH's much nicer for global routing, tho it may still lead to >issues with local routing. Kinda depends what you want to do within your IGP. Agree but what one does with IGP should not break peer-to-peer applications between remote provider on the other side of the planet. IPsec between those two peers without any translation of the packets headers. Do we agree on that and this is a core principle for any Internet engineer one way or the other? Has nothing to do with routing except as input to what one is willing to give up in the design of routing architecture and an important point to raise amongst ourseleves on the list !!!! >One could reasonably argue that you take the layer of separation down >recursively. Within the IGP from the Provider space? If that, then I agree. >Note that this alleviates the most painful reason to avoid PA space: But above you state "nicely aggregates provider space"? Can you rectify? >renumbering is now a non-issue. You assign a new locator to your entire site, >advertise it to the world and you're good to go. Individual host identifiers >need not change. No host renumbering. But still implies locators can change? For example one move to completely new providers? Your location is not worldwide provider space but only for relative provider space for a site? Is that correct? /jim From owner-multi6@ops.ietf.org Mon Mar 17 10:18:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16777 for ; Mon, 17 Mar 2003 10:18:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uwPZ-000Jkx-00 for multi6-data@psg.com; Mon, 17 Mar 2003 07:20:25 -0800 Received: from mailout.zma.compaq.com ([161.114.64.103] helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18uwPW-000Jkj-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 07:20:22 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 1BD7343F1; Mon, 17 Mar 2003 10:20:22 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Mar 2003 10:20:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Identifier/locator recap Date: Mon, 17 Mar 2003 10:20:18 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCCEF@tayexc13.americas.cpqcorp.net> Thread-Topic: Identifier/locator recap Thread-Index: AcLsXuOrXRLxvQu2RgGOGv1PrDIV5QAOX6tQ From: "Bound, Jim" To: "Iljitsch van Beijnum" Cc: X-OriginalArrivalTime: 17 Mar 2003 15:20:21.0934 (UTC) FILETIME=[B9FCECE0:01C2EC98] 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 KAA16777 > > If we can make them implied its an extra condition check > for routers > > and hosts but will make the overall architecture less heavy > and less > > to manage. I believe in overload though it is complex to implement > > not impossible. > > Routers don't have to do anything, just the end points. > Having the identifier in each packet really doesn't buy you > any simplicity since the relationship between the locators > and identifiers must be authenticated to steer clear of > endless security troubles. At the last hop to the node the identifier is needed by the router. > > > > There is also the question of what makes good > identifiers. HIP uses > > > the fingerprint of a cryptographic key. MHAP uses > > > provider-independent IPv6 addresses that aren't visible in the > > > global routing table. I myself have suggested to use FQDNs as the > > > first choice. > > > I suggest not being dependent on crypto anything is wise it implies > > PKI to the solution and I fear that is a non-starter? > > No, HIP is smarter than that. But what I find troublesome > with that approach is that the identifiers are a flat 120+ > bit space which makes it incredibly hard to create a > distributed way to look up properties for identifiers. Not a fan of HIP. But should I go down that rathole and my issues with it? At least for now. Rather spend my energy on the model/architecture agreement. Thanks /jim From owner-multi6@ops.ietf.org Mon Mar 17 10:33:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17368 for ; Mon, 17 Mar 2003 10:33:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uwdV-000KU7-00 for multi6-data@psg.com; Mon, 17 Mar 2003 07:34:49 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18uwdP-000KTg-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 07:34:44 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2HFYYw00716; Mon, 17 Mar 2003 17:34:34 +0200 Date: Mon, 17 Mar 2003 17:34:33 +0200 (EET) From: Pekka Savola To: Pekka Nikander cc: Iljitsch van Beijnum , "Bound, Jim" , Subject: Re: HIP and PKI reqs [RE: Identifier/locator recap] In-Reply-To: <3E75E684.9080502@nomadiclab.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SIGNATURE_SHORT_DENSE, SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 17 Mar 2003, Pekka Nikander wrote: > Pekka Savola wrote: > > On Mon, 17 Mar 2003, Iljitsch van Beijnum wrote: > > > >>>I suggest not being dependent on crypto anything is wise it implies PKI > >>>to the solution and I fear that is a non-starter? > >> > >>No, HIP is smarter than that. [... > > > > Uhh, no. HIP requires either DNSsec or opportunistic key distribution a > > la SSH. > > Opportunistic key distribution a la SSH works pretty well. > > Going further, HIP *without* DNSsec/PKI is slightly *more* > secure than today's insecured TCP/UDP, even if HIP is used > to implement mobility and/or multihoming. See our security ' > analysis in our recent NDSS'03 paper. > > However, if you want to use HIP to secure something that > goes beyond mobility or multi-homing, or want to achieve > a security level that is more than slightly more secure > than the current unsecured IPv4, you have to rely on > DNSsec, or accept the vulnerabilities in opportunistic mode. > > Summary: HIP without DNSsec or PKI can provide security > for mobility and/or multi-homing that is acceptable according > to the current security requirements. Not having read the paper, I think we agree -- what's basically left is on-the-path attackers, local attackers or DNS-based forgery. All of those are also problems in the unsecured IPv4. DNS-based forgery may be a bit easier though, but that might need more analysis. However, my complaint with HIP model is that it seems so closely tied to ESP and security. Is it possible to use HIP without IPsec ESP? Or do you have to use ESP with null encryption? The security model above is possibly ok if the user gets no assumption that "because I use HIP, I must be secure now". -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Mon Mar 17 10:44:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17631 for ; Mon, 17 Mar 2003 10:44:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uwoF-000L5g-00 for multi6-data@psg.com; Mon, 17 Mar 2003 07:45:55 -0800 Received: from teldanex.hiit.fi ([212.68.5.99] helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 3.36 #1) id 18uwoA-000L4E-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 07:45:50 -0800 Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id C25FB1C; Mon, 17 Mar 2003 17:55:54 +0200 (EET) Message-ID: <3E75EDB9.3040306@nomadiclab.com> Date: Mon, 17 Mar 2003 07:46:01 -0800 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030310 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola Cc: multi6@ops.ietf.org Subject: Re: HIP and PKI reqs [RE: Identifier/locator recap] 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 Pekka Savola wrote: > However, my complaint with HIP model is that it seems so closely tied to > ESP and security. Is it possible to use HIP without IPsec ESP? Or do you > have to use ESP with null encryption? There is no architectural reasons why you couldn't use HIP without ESP. For example, you could use two IP headers, the inner one carrying HIP ids (HITs) and the outer one locators, i.e. conventional IP addresses. However, what's the point, it would take 40 bytes, and ESP takes less. You can always use ESP with null encryption, and even with no integrity protection if you really want. Now, we have had some loose chat about how to use HIP without any extra headers, i.e. just an IP header followed by TCP/UDP. However, given that we would have to be prepared to talk to both HIP enabled and non-HIP enabled hosts at the same time, it would require some trickery at the kernel, and that might be brittle. If you loose security requirements even more, it would even be possible to use opportunistic HIP without the Diffie-Hellman key exchange, but that would be vulnerable to bidding down attacks. Thus, I haven't bothered to think about that any further. --Pekka Nikander From owner-multi6@ops.ietf.org Mon Mar 17 11:29:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19062 for ; Mon, 17 Mar 2003 11:29:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uxVP-000Nbi-00 for multi6-data@psg.com; Mon, 17 Mar 2003 08:30:31 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 18uxVM-000NbN-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 08:30:28 -0800 Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id C5613137F06; Mon, 17 Mar 2003 08:30:26 -0800 (PST) Date: Mon, 17 Mar 2003 08:30:27 -0800 Subject: Re: Identification Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: Iljitsch van Beijnum From: David Conrad In-Reply-To: <20030317092653.Y69506-100000@sequoia.muada.com> Message-Id: X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.3 required=5.0 tests=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: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA19062 Iljitsch, On Monday, March 17, 2003, at 12:48 AM, Iljitsch van Beijnum wrote: > On Sun, 16 Mar 2003, David Conrad wrote: >> To me, identifiers are values that uniquely and globally (at least >> within the context of an internet) identify communication end points. > What makes a good identifier? Not something like an EUI64 identifier, > for the following reasons: > > 1. no usable hierarchy, hard to create a distributed database No. An identifier can have hierarchy if desired. What is important is that the identifier hierarchy is independent of the location hierarchy. > 2. when I replace my network card, I haven't changed my identity Whether you've changed 'your' identity depends on what you are calling the endpoint of communication. If the endpoint is a toaster and the network connector dies, it is likely you'll be replacing the toaster, thus the identity has changed. > 3. It would be extremely hard to make sure each EUI64 is only used once > globally See the comment above. > 4. I could very well be using several network cards but it's still > always "me" See the comment above. > So we need to identify hosts rather than interfaces. Using your argument above, what if I move to a different host? If identity is mapped to higher level constructs, I would want communications to move with me. > I feel FQDNs are the ideal identifiers. Fine. > (But maybe I'm getting ahead of things.) Yes. >>>  But we cannot hard code identifiers in silicon? >> There is no _technical_ reason this couldn't be done. > Again, how are you going to look them up? Without some form of > hierarchy > you need a centralized database. This is unworkable on a global scale. One (not the only) obvious solution, using your ideal identifiers: play the ENUM game. If you have a EUI64 identifier, ASCII encode the nybbles and append a TLD, say eui64,arpa. This name could map into a set of locators. Rgds, -drc From owner-multi6@ops.ietf.org Mon Mar 17 11:29:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19082 for ; Mon, 17 Mar 2003 11:29:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uxWT-000NdK-00 for multi6-data@psg.com; Mon, 17 Mar 2003 08:31:37 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 18uxWQ-000Nd2-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 08:31:34 -0800 Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 96BF4137F06; Mon, 17 Mar 2003 08:31:33 -0800 (PST) Date: Mon, 17 Mar 2003 08:31:34 -0800 Subject: Re: Identification Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: Iljitsch van Beijnum From: David Conrad In-Reply-To: <20030317094830.E69506-100000@sequoia.muada.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) 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 Monday, March 17, 2003, at 12:55 AM, Iljitsch van Beijnum wrote: > Even assuming they come out of the factory with unique addresses > (I've heard stories from people getting 5 cards all with the same > address) how long is this going to stay unique after my little brother > types "man ifconfig"? > > Sure, it's possible to repair all these problems, but why exactly were > we doing this in the first place again...? Hardware addresses make bad > identifiers. Just give me 64 bytes of NVRAM so I can burn in the > identifier of my choice. And how will you be assuring that 64 bytes is globally unique? Rgds, -drc From owner-multi6@ops.ietf.org Mon Mar 17 12:00:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20446 for ; Mon, 17 Mar 2003 12:00:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uxzO-000PQm-00 for multi6-data@psg.com; Mon, 17 Mar 2003 09:01:30 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18uxzI-000PQZ-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 09:01:24 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2HH0Rf86840; Mon, 17 Mar 2003 18:00:27 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Mon, 17 Mar 2003 18:00:27 +0100 (CET) From: Iljitsch van Beijnum To: marcelo bagnulo cc: Subject: Re: Move forward In-Reply-To: <1047911180.720.25.camel@presto.it.uc3m.es> Message-ID: <20030317174331.T86639-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 17 Mar 2003, marcelo bagnulo wrote: > > > However in IPv6, considering "Default > > > Address Selection mechanism" i was hoping that application used the list > > > of addresses generated by the mechanism and try to use them to > > > communicate > > Actually this may make it worse, as the "best" address is always > > selected. If the "best" address is unreachable, no dice. At least with > > random or round robin you can hit reload to try again. > From RFC 3484 > 6. Destination Address Selection > The destination address selection algorithm takes a list of > destination addresses and sorts the addresses to produce a new list. > ^^^^ > I guess that applications now obtain a list of addresses, after the > default address selection mechanism has sorted them. Yes. But then the application still has to go through the trouble of trying every address. I don't think web browsers typically do that. (And if the user has to wait for a timeout, it might not matter anyway.) For your experimentation pleasure I have created some DNS names with 7 IPv4 and/or IPv6 addresses, only one of which works. It's a Cisco, so you can telnet, but HTTP is probably more interesting (if it works, you'll get an authentication requester). The names are: tryme.bgpexpert.com trymev4.bgpexpert.com trymev6.bgpexpert.com > Moreover, the first rule of the mechanism discards unreachable > destinations, so if one of multiple is unreachable it will be included > last. How does the resolver library know which addresses are reachable? Or usable for the application in question? From owner-multi6@ops.ietf.org Mon Mar 17 12:15:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20999 for ; Mon, 17 Mar 2003 12:15:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uyF8-0000Qi-00 for multi6-data@psg.com; Mon, 17 Mar 2003 09:17:46 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18uyF2-0000QL-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 09:17:40 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2HHGgX86860; Mon, 17 Mar 2003 18:16:43 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Mon, 17 Mar 2003 18:16:42 +0100 (CET) From: Iljitsch van Beijnum To: Pekka Nikander cc: Subject: Re: Identifier/locator recap In-Reply-To: <3E75DDE8.9080108@nomadiclab.com> Message-ID: <20030317181357.X86639-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 Mon, 17 Mar 2003, Pekka Nikander wrote: > > No, HIP is smarter than that. But what I find troublesome with that > > approach is that the identifiers are a flat 120+ bit space which makes > > it incredibly hard to create a distributed way to look up properties for > > identifiers. > Not really. Distributes hash tables (DHT) should work. Somebody > just need to work out the details; they are not exactly simple, though. > But not that complicated either, I would believe. See the proceedings > of recent peer-to-peer conferences and you will find multiple occasions > where DHTs have been used. Hm, I'm not very familiar with this technique and I can't find a good explanation of how it applies to the problem at hand right now. But it seems to me that such a distributed system is very vulnerable to malicious nodes holding back information that they are supposed to share. Also, the self-organizing could make unsuspecting nodes attract more traffic than they can handle. From owner-multi6@ops.ietf.org Mon Mar 17 12:23:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21259 for ; Mon, 17 Mar 2003 12:23:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uyMY-0000pY-00 for multi6-data@psg.com; Mon, 17 Mar 2003 09:25:26 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18uyMN-0000p0-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 09:25:15 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2HHOII86878; Mon, 17 Mar 2003 18:24:18 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Mon, 17 Mar 2003 18:24:18 +0100 (CET) From: Iljitsch van Beijnum To: Pekka Nikander cc: Subject: Re: HIP and PKI reqs [RE: Identifier/locator recap] In-Reply-To: <3E75E684.9080502@nomadiclab.com> Message-ID: <20030317181827.B86639-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_03_05 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 17 Mar 2003, Pekka Nikander wrote: > > Uhh, no. HIP requires either DNSsec or opportunistic key distribution a > > la SSH. > Opportunistic key distribution a la SSH works pretty well. It works a lot less well if you don't have local storage to keep the keys, or if node A wants to refer node B to node C. The problem I see with HIP is that you can't initiate a session with just the identifier to identify the host you want to communicate with. Now that would be fine if it were possible to feed this identifier to a lookup engine and get back something you _can_ use to initiate a session. But this isn't possible either. So effectively the HIP identifier serves no identifying purpose. > Summary: HIP without DNSsec or PKI can provide security > for mobility and/or multi-homing that is acceptable according > to the current security requirements. Cool. Now if only it could provide functionality... Note that I'm not anti-HIP. I'm sure there are problems that can be solved by HIP. But it can't be a general solution for multihoming as it only moves the problem to a different area. Iljitsch From owner-multi6@ops.ietf.org Mon Mar 17 12:32:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21712 for ; Mon, 17 Mar 2003 12:32:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uyV8-0001d3-00 for multi6-data@psg.com; Mon, 17 Mar 2003 09:34:18 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18uyV6-0001bm-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 09:34:16 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18uyV1-0002Q3-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 12:34:12 -0500 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 17 Mar 2003 09:34:11 -0800 To: multi6@ops.ietf.org Subject: changing deck chairs on the titanic :-) Message-Id: 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: 7bit thomas narten is retiring back to the sunny palms of the iesg holiday cruise after some years of getting this wg on the rails. thanks thomas. as readers of swedish will already know, Kurtis Lindqvist is joing sean as co-chair of the wg. be kind to him. [ my wife would say "think of the people on the titanic who declined dessert" ] randy From owner-multi6@ops.ietf.org Mon Mar 17 12:49:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22298 for ; Mon, 17 Mar 2003 12:49:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uylO-0002sJ-00 for multi6-data@psg.com; Mon, 17 Mar 2003 09:51:06 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18uylI-0002ra-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 09:51:00 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2HHo2Z86915; Mon, 17 Mar 2003 18:50:03 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Mon, 17 Mar 2003 18:50:02 +0100 (CET) From: Iljitsch van Beijnum To: David Conrad cc: Subject: Re: Identification In-Reply-To: Message-ID: <20030317182739.T86639-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_03_05 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 17 Mar 2003, David Conrad wrote: > > 1. no usable hierarchy, hard to create a distributed database > No. An identifier can have hierarchy if desired. Sure, an identifier can. But an EUI64 can't. (Note that the vendor/other part distinction is of no use here.) > > 2. when I replace my network card, I haven't changed my identity > Whether you've changed 'your' identity depends on what you are calling > the endpoint of communication. If the endpoint is a toaster and the > network connector dies, it is likely you'll be replacing the toaster, > thus the identity has changed. I was thinking more along the lines of computers. If I change a NIC, I don't want the box to change its behavior other than that the network connection is now better. > > 3. It would be extremely hard to make sure each EUI64 is only used once > > globally > See the comment above. Your comment doesn't address this. > > So we need to identify hosts rather than interfaces. > Using your argument above, what if I move to a different host? If > identity is mapped to higher level constructs, I would want > communications to move with me. Fair enough. I think we should keep an open mind about this. However, I see no reasonable way to accomplish it. A service moving from one host to another is a different matter, though. I think a next generation identifier should definately support that. (But not necessarily without breaking sessions.) > > Again, how are you going to look them up? Without some form of hierarchy > > you need a centralized database. This is unworkable on a global scale. > One (not the only) obvious solution, using your ideal identifiers: play > the ENUM game. If you have a EUI64 identifier, ASCII encode the > nybbles and append a TLD, say eui64,arpa. This name could map into a > set of locators. What does that buy us? That means that either you have to cooperate with the people who bought NICs with the same high order 60 bits as you and together run a server that provides the mapping from your identifier to the locators you use. Alternatively, the eui64.arpa people have to manage 2^64 delegations. > > Sure, it's possible to repair all these problems, but why exactly were > > we doing this in the first place again...? Hardware addresses make bad > > identifiers. Just give me 64 bytes of NVRAM so I can burn in the > > identifier of my choice. > And how will you be assuring that 64 bytes is globally unique? I won't. However, this 64 bytes should be more than enough to store a globally or subnet unique value that the host can use at boot time, even if it doesn't have (access to) permanent storage. This way, I can make sure my boxes keep using the same address without having to use a configuration server even if I swap some hardware around. Iljitsch From owner-multi6@ops.ietf.org Mon Mar 17 12:53:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22564 for ; Mon, 17 Mar 2003 12:53:51 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uypy-00039c-00 for multi6-data@psg.com; Mon, 17 Mar 2003 09:55:50 -0800 Received: from wl-134-243.wireless.ietf56.ietf.org ([130.129.134.243] helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18uypw-000397-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 09:55:48 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2HHuaKW005833; Mon, 17 Mar 2003 18:56:38 +0100 (CET) Date: Mon, 17 Mar 2003 18:55:54 +0100 Subject: Re: Again no multi6 at IETF#56 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Bound, Jim" , "Michael H. Lambert" , To: "Tony Li" From: Kurt Erik Lindqvist In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) 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 > Tony, > | I still think > | that doing it the IPv4 way is the best and fastest hack we > | have for > | multihoming IPv6. > It may well be the fastest. Certainly the old way usually is. > And it may be the 'best' that we have right now because we don't > have agreement on a better path. However, if we do go down the > path of long prefix distribution, the core is almost certain to > implode. Here, there be dragons that we should avoid. I fully agree that this is a far from perfect model. However, note one thing. I only advocate the _announcement_ of a longer prefix, not _allocation_. If I change provider, I need to hand the address space back. But let's look at the explosion of the routing table. Today there are 15k ASes in the DFZ. If these all have three upstreams that is 45k routes. If we use all the 16-bit AS numbers we have around 192k routes. This is a poor calculation and comparison, but the fact is that the natural aggregation of the larger IPv6 allocations are helping us here. I still think that what will limit multihoming for the coming years is not scarcity of resources but the cost of doing it. Last, as we today think that a policy of not announcing longer prefixes are prohibiting this, I assume that we believe we can enforce this in the future as well? That gives us a potential roll-back scenario. Also note that this is almost more of documenting BCP than defining a new policy.- > And regarding the issue of 'choice', we need there to be no > choice in the matter. If there is a choice in how to multi-home, > then some folks will inevitably choose the wrong way and we > will again implode. > There will be different choices at different times. We need apply the solution we have today with zero implementation. And I don't see any other alternative. six months from now we might have something better. Let's do that then. Best regards, - kurtis - From owner-multi6@ops.ietf.org Mon Mar 17 13:18:26 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23402 for ; Mon, 17 Mar 2003 13:18:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uzCb-0004eV-00 for multi6-data@psg.com; Mon, 17 Mar 2003 10:19: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 #1) id 18uzCZ-0004eH-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 10:19:11 -0800 Content-class: urn:content-classes:message Subject: RE: Again no multi6 at IETF#56 Date: Mon, 17 Mar 2003 10:19:10 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <963621801C6D3E4A9CF454A1972AE8F54CD6@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Thread-Topic: Again no multi6 at IETF#56 Thread-Index: AcLsrzOxCuQqOnBIRZWFU3h8PiBJswAAMC0g From: "Michel Py" To: "Kurt Erik Lindqvist" , "Tony Li" Cc: "Bound, Jim" , "Michael Lambert" , 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 NAA23402 Kurtis, > Tony Li wrote: > However, if we do go down the path of long prefix > distribution, the core is almost certain to implode. > Here, there be dragons that we should avoid. I heard Tony's comment from many other persons too. Although I do see some potential in what you wrote, and as mentioned yesterday I see it from a different prospective, allow me to remind you what reality here is: Quote from the one and only document in this WG: > 3.2.1 Scalability > [snip] > A new IPv6 multihoming architecture MUST scale to > accommodate orders of magnitude more multihomed > sites without imposing unreasonable requirements > on the routing system. As chair, you simply can not recommend to go a way that blatantly violates the only working document we have. This text is clear, and it's a "MUST" not a "must" which has a very specific meaning as per RFC 2119. Michel. From owner-multi6@ops.ietf.org Mon Mar 17 13:30:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24047 for ; Mon, 17 Mar 2003 13:30:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18uzOR-0005Mx-00 for multi6-data@psg.com; Mon, 17 Mar 2003 10:31:27 -0800 Received: from edison.cisco.com ([171.70.144.164]) by psg.com with esmtp (Exim 3.36 #1) id 18uzOO-0005Ml-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 10:31:24 -0800 Received: from cisco.com (sjc-vpn1-431.cisco.com [10.21.97.175]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA17314; Mon, 17 Mar 2003 10:31:08 -0800 (PST) Message-ID: <3E76146A.1070703@cisco.com> Date: Mon, 17 Mar 2003 10:31:06 -0800 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: Pekka Nikander , multi6@ops.ietf.org Subject: Re: HIP and PKI reqs [RE: Identifier/locator recap] References: <20030317181827.B86639-100000@sequoia.muada.com> In-Reply-To: <20030317181827.B86639-100000@sequoia.muada.com> 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 But it is possible. We needn't forsake DNS entirely... Eliot Iljitsch van Beijnum wrote: > On Mon, 17 Mar 2003, Pekka Nikander wrote: > > >>>Uhh, no. HIP requires either DNSsec or opportunistic key distribution a >>>la SSH. > > >>Opportunistic key distribution a la SSH works pretty well. > > > It works a lot less well if you don't have local storage to keep the > keys, or if node A wants to refer node B to node C. > > The problem I see with HIP is that you can't initiate a session with > just the identifier to identify the host you want to communicate with. > Now that would be fine if it were possible to feed this identifier to a > lookup engine and get back something you _can_ use to initiate a > session. But this isn't possible either. So effectively the HIP > identifier serves no identifying purpose. > > >>Summary: HIP without DNSsec or PKI can provide security >>for mobility and/or multi-homing that is acceptable according >>to the current security requirements. > > > Cool. Now if only it could provide functionality... > > Note that I'm not anti-HIP. I'm sure there are problems that can be > solved by HIP. But it can't be a general solution for multihoming as it > only moves the problem to a different area. > > Iljitsch > > > > From owner-multi6@ops.ietf.org Mon Mar 17 14:21:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25878 for ; Mon, 17 Mar 2003 14:21:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18v0Be-0009KN-00 for multi6-data@psg.com; Mon, 17 Mar 2003 11:22:18 -0800 Received: from buffoon.automagic.org ([208.185.30.208]) by psg.com with smtp (Exim 3.36 #1) id 18v0Bb-0009K6-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 11:22:16 -0800 Received: (qmail 80908 invoked by uid 0); 17 Mar 2003 19:22:14 -0000 Received: from localhost.automagic.org (HELO isc.org) (root@127.0.0.1) by localhost.automagic.org with SMTP; 17 Mar 2003 19:22:14 -0000 Date: Mon, 17 Mar 2003 11:22:29 -0800 Subject: Re: Again no multi6 at IETF#56 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Kurt Erik Lindqvist" , "Tony Li" , "Bound, Jim" , "Michael Lambert" , To: "Michel Py" From: Joe Abley In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F54CD6@server2000.arneill-py.sacramento.ca.us> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) 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 Monday, Mar 17, 2003, at 10:19 US/Pacific, Michel Py wrote: > Quote from the one and only document in this WG: > >> 3.2.1 Scalability >> [snip] >> A new IPv6 multihoming architecture MUST scale to >> accommodate orders of magnitude more multihomed >> sites without imposing unreasonable requirements >> on the routing system. > > As chair, you simply can not recommend to go a way that blatantly > violates the only working document we have. This text is clear, and > it's > a "MUST" not a "must" which has a very specific meaning as per RFC > 2119. To be pedantic, the requirements doc doesn't specify the starting point: orders of magnitude more multihomed sites than exist today on the v6 network is still easily achievable using draft-kurtis-call-me-when-we-get-1000-routes-in-the-dfz-00. Joe From owner-multi6@ops.ietf.org Mon Mar 17 14:31:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26394 for ; Mon, 17 Mar 2003 14:31:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18v0Ma-000ADg-00 for multi6-data@psg.com; Mon, 17 Mar 2003 11:33:36 -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 #1) id 18v0MX-000ADT-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 11:33:33 -0800 Content-class: urn:content-classes:message Subject: RE: Again no multi6 at IETF#56 Date: Mon, 17 Mar 2003 11:33:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <963621801C6D3E4A9CF454A1972AE8F54CDA@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Thread-Topic: Again no multi6 at IETF#56 Thread-Index: AcLsuoVSIiLue/H3S4WPwl7IDZneEwAAHFAw From: "Michel Py" To: "Joe Abley" Cc: "Kurt Erik Lindqvist" , "Tony Li" , "Bound, Jim" , "Michael Lambert" , 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 OAA26394 > Joe Abley wrote: > To be pedantic, the requirements doc doesn't specify > the starting point I do not agree. It is clear from that paragraph that the starting point is either "Current IPV4 multihoming practices" or "the Internet's BGP Routing Table". Without an accompanying "than xxxx" the "more" refers to the text immediately above. | 3.2.1 Scalability | Current IPV4 multihoming practices contribute to the | significant growth currently observed in the state held | in the global inter-provider routing system; this is a | concern both because of the hardware requirements it | imposes and also because of the impact on the stability | of the routing system. This issue is discussed in | great detail in [9]. [Huston, G., "Analyzing the | Internet's BGP Routing Table", January 2001.] | A new IPv6 multihoming architecture MUST scale to | accommodate orders of magnitude more multihomed sites | without imposing unreasonable requirements on the | routing system. Michel. From owner-multi6@ops.ietf.org Mon Mar 17 14:38:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26958 for ; Mon, 17 Mar 2003 14:38:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18v0TI-000Ajn-00 for multi6-data@psg.com; Mon, 17 Mar 2003 11:40:32 -0800 Received: from smtp03.uc3m.es ([163.117.136.123] helo=smtp.uc3m.es) by psg.com with esmtp (Exim 3.36 #1) id 18v0TF-000AjW-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 11:40:29 -0800 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 322364315A; Mon, 17 Mar 2003 20:40:28 +0100 (CET) Received: from presto.it.uc3m.es (presto.it.uc3m.es [163.117.139.134]) by smtp03.uc3m.es (Postfix) with ESMTP id B6B9699E1B; Mon, 17 Mar 2003 20:40:27 +0100 (CET) Subject: Re: Move forward From: marcelo bagnulo To: Iljitsch van Beijnum Cc: multi6@ops.ietf.org In-Reply-To: <20030317174331.T86639-100000@sequoia.muada.com> References: <20030317174331.T86639-100000@sequoia.muada.com> Content-Type: text/plain Organization: uc3m Message-Id: <1047930019.725.42.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 17 Mar 2003 20:40:19 +0100 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.5 required=5.0 tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_03_05 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 2003-03-17 at 18:00, Iljitsch van Beijnum wrote: > On 17 Mar 2003, marcelo bagnulo wrote: > > > > > However in IPv6, considering "Default > > > > Address Selection mechanism" i was hoping that application used the list > > > > of addresses generated by the mechanism and try to use them to > > > > communicate > > > > Actually this may make it worse, as the "best" address is always > > > selected. If the "best" address is unreachable, no dice. At least with > > > random or round robin you can hit reload to try again. > > > From RFC 3484 > > > 6. Destination Address Selection > > > The destination address selection algorithm takes a list of > > destination addresses and sorts the addresses to produce a new list. > > ^^^^ > > I guess that applications now obtain a list of addresses, after the > > default address selection mechanism has sorted them. > > Yes. But then the application still has to go through the trouble of > trying every address. I don't think web browsers typically do that. (And > if the user has to wait for a timeout, it might not matter anyway.) > > For your experimentation pleasure I have created some DNS names with 7 > IPv4 and/or IPv6 addresses, only one of which works. It's a Cisco, so > you can telnet, but HTTP is probably more interesting (if it works, > you'll get an authentication requester). The names are: > > tryme.bgpexpert.com trymev4.bgpexpert.com trymev6.bgpexpert.com > Thank you very much !!! We have tried it with the Konqueror browser. Its behaviour was: It tried with the first address => it was a "fake" address so it failed but it received a host unreachable message (almost immediately) Then it tried with the next one => it was the good one Ok! This seems to be an suitable behaviour for our needs, right? (What i didn't told you is that it only tries with 2 addresses, so if the real one was the third, it would have failed) So it seems to me that different aps have different behaviour. I still think that this is reasonable mechanism for selecting the first address, it is pretty fast if the host unreachable message is sent, also. But i do agree with you that it is application dependent. Perhaps we need more feedback from application developers? > > Moreover, the first rule of the mechanism discards unreachable > > destinations, so if one of multiple is unreachable it will be included > > last. > > How does the resolver library know which addresses are reachable? Or > usable for the application in question? It tries and if it is not working, this result is cached for next attempts (this is one possible mechanism included in the spec) Regards, marcelo -- marcelo bagnulo uc3m From owner-multi6@ops.ietf.org Mon Mar 17 15:15:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29271 for ; Mon, 17 Mar 2003 15:15:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18v12g-000D8m-00 for multi6-data@psg.com; Mon, 17 Mar 2003 12:17:06 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 18v12a-000D7F-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 12:17:00 -0800 From: Masataka Ohta Message-Id: <200303172011.FAA23579@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id FAA23579; Tue, 18 Mar 2003 05:10:46 +0859 Subject: Re: Again no multi6 at IETF#56 In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F54CDA@server2000.arneill-py.sacramento.ca.us> from Michel Py at "Mar 17, 2003 11:33:33 am" To: Michel Py Date: Tue, 18 Mar 2003 05:10:46 +0859 () CC: Joe Abley , Kurt Erik Lindqvist , Tony Li , "Bound, Jim" , Michael Lambert , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-0.7 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Michel; > > Joe Abley wrote: > > To be pedantic, the requirements doc doesn't specify > > the starting point > > I do not agree. It is clear from that paragraph that the starting point > is either "Current IPV4 multihoming practices" or "the Internet's BGP > Routing Table". Not at all. The global routing table should contain one entry for each tier1 ISP or, maybe, a little more than that. Initially, there may be 10. AS numbers, of course, may be assigned to tier2 and other ISPs, which have multiple peers to other ISPs and want to control traffic with BGP. Masataka Ohta From owner-multi6@ops.ietf.org Mon Mar 17 15:56:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00884 for ; Mon, 17 Mar 2003 15:56:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18v1f9-000Fuy-00 for multi6-data@psg.com; Mon, 17 Mar 2003 12:56:51 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 18v1f3-000FuO-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 12:56:45 -0800 Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 5E008137F06; Mon, 17 Mar 2003 12:56:44 -0800 (PST) Date: Mon, 17 Mar 2003 12:56:43 -0800 Subject: Re: Again no multi6 at IETF#56 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Michel Py , Joe Abley , Kurt Erik Lindqvist , Tony Li , "Bound, Jim" , Michael Lambert , multi6@ops.ietf.org To: Masataka Ohta From: David Conrad In-Reply-To: <200303172011.FAA23579@necom830.hpcl.titech.ac.jp> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) 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 Define "tier 1". Rgds, -drc On Monday, March 17, 2003, at 12:11 PM, Masataka Ohta wrote: > Michel; > >>> Joe Abley wrote: >>> To be pedantic, the requirements doc doesn't specify >>> the starting point >> >> I do not agree. It is clear from that paragraph that the starting >> point >> is either "Current IPV4 multihoming practices" or "the Internet's BGP >> Routing Table". > > Not at all. > > The global routing table should contain one entry for each tier1 > ISP or, maybe, a little more than that. > > Initially, there may be 10. > > AS numbers, of course, may be assigned to tier2 and other ISPs, > which have multiple peers to other ISPs and want to control > traffic with BGP. > > Masataka Ohta > From owner-multi6@ops.ietf.org Mon Mar 17 16:00:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01090 for ; Mon, 17 Mar 2003 16:00:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18v1kE-000GJa-00 for multi6-data@psg.com; Mon, 17 Mar 2003 13:02:06 -0800 Received: from dmz1.procket.com ([65.174.124.36]) by psg.com with esmtp (Exim 3.36 #1) id 18v1kB-000GIx-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 13:02:03 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 0BD8823C49; Mon, 17 Mar 2003 13:27:33 -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 h2HL22YB012064; Mon, 17 Mar 2003 13:02:02 -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="us-ascii" Subject: RE: Again no multi6 at IETF#56 Date: Mon, 17 Mar 2003 13:02:02 -0800 Message-ID: Thread-Topic: Again no multi6 at IETF#56 Thread-Index: AcLsrnXCqTVJuIJdTxKC471iqioXVgAGRqlw From: "Tony Li" To: "Kurt Erik Lindqvist" Cc: "Bound, Jim" , "Michael H. Lambert" , 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 QAA01090 | I fully agree that this is a far from perfect model. | However, note one | thing. I only advocate the _announcement_ of a longer prefix, not | _allocation_. If I change provider, I need to hand the | address space | back. All of the pain and none of the gain? Any announcement of longer prefixes is at the expense of routing scalability. | But let's look at the explosion of the routing table. | Today there are | 15k ASes in the DFZ. If these all have three upstreams that is 45k | routes. If we use all the 16-bit AS numbers we have around | 192k routes. | This is a poor calculation and comparison, but the fact is | that the | natural aggregation of the larger IPv6 allocations are | helping us here. | I still think that what will limit multihoming for the | coming years is | not scarcity of resources but the cost of doing it. The cost of multihoming is falling. Today, sitting at home on my couch, I can easily connect to my neighbor's WAP. If we were to tweak things a bit, both of us would be multi-homed through the other. In fact, the cost of connectivity is continuing to fall, so one might expect that the cost of multi-homing will fall too. If you subscribe to the view that businesses find the Web interface to be important, then it stands to reason that the interest in multihoming would continue to grow. | Last, as we today think that a policy of not announcing | longer prefixes | are prohibiting this, I assume that we believe we can | enforce this in | the future as well? That gives us a potential roll-back | scenario. Also | note that this is almost more of documenting BCP than | defining a new | policy.- It's very unlikely that we can ever undo what was done before. You may recall the flap during the CIDR days about asking people to renumber so that we could aggregate. | > And regarding the issue of 'choice', we need there to be no | > choice in the matter. If there is a choice in how to multi-home, | > then some folks will inevitably choose the wrong way and we | > will again implode. | | There will be different choices at different times. We | need apply the | solution we have today with zero implementation. And I | don't see any | other alternative. six months from now we might have | something better. | Let's do that then. And then, six months from now, someone stands up and says "thanks, but we've got an installed base and we can't change". No thanks. Do it right the first time, or not at all. Tony From owner-multi6@ops.ietf.org Mon Mar 17 16:05:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01294 for ; Mon, 17 Mar 2003 16:05:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18v1pj-000GhP-00 for multi6-data@psg.com; Mon, 17 Mar 2003 13:07:47 -0800 Received: from teldanex.hiit.fi ([212.68.5.99] helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 3.36 #1) id 18v1ph-000GhC-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 13:07:45 -0800 Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 0E2941C; Mon, 17 Mar 2003 23:17:48 +0200 (EET) Message-ID: <3E76392A.9040700@nomadiclab.com> Date: Mon, 17 Mar 2003 13:07:54 -0800 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030310 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum Cc: multi6@ops.ietf.org Subject: Re: HIP and PKI reqs [RE: Identifier/locator recap] References: <20030317181827.B86639-100000@sequoia.muada.com> In-Reply-To: <20030317181827.B86639-100000@sequoia.muada.com> 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 Iljitsch van Beijnum wrote: > The problem I see with HIP is that you can't initiate a session with > just the identifier to identify the host you want to communicate with. You are right. More work is needed. As I wrote, someone should work out the details how to utilize DHTs, perhaps in conjunction with DNS. Or something similar. > Now that would be fine if it were possible to feed this identifier to a > lookup engine and get back something you _can_ use to initiate a > session. But this isn't possible either. I would say that _currently_ such a mechanism does not exist. But I would *not* say that it is not _possible_. The fact that such a solution does not currently exist does not make it impossible to create one. I have a hunch that a DHT based solution should not be too complicated. However, to really see how DHTs would fit in to the DNS model would require some kind of an idea how DNS servers are going to be distributed in the IPv6 space, and I don't currently have any good guesses for that. If someone could provide one, that might help. The question is really about load balancing between DNS servers so that no one gets too much load. Integrity is not much a problem. I see some potential DoS problems, but it is easy enough to provide completely independent servers with DHT structures. > So effectively the HIP > identifier serves no identifying purpose. I couldn't understand that. Could you please explain? > Note that I'm not anti-HIP. I'm sure there are problems that can be > solved by HIP. But it can't be a general solution for multihoming as it > only moves the problem to a different area. So you want me to come up with a completely worked out solution? Cool! :-) Should I will crawl back to my research cubicle until I find someting? :-) More seriously, personally I believe that HIP has large potential for end-host multi-homing. Much more than the ID->locator mapping I see the crypto overhead (Diffie-Hellman) as a problem. There are also lots of other details to be worked out, with time. Furthermore, HIP is definitely not a solution for doing large site multi-homing, other solutions are needed for that. --Pekka Nikander From owner-multi6@ops.ietf.org Mon Mar 17 17:04:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04267 for ; Mon, 17 Mar 2003 17:04:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18v2ik-000Kvz-00 for multi6-data@psg.com; Mon, 17 Mar 2003 14:04:38 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18v2ih-000Kvj-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 14:04:35 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2HM3cM87357; Mon, 17 Mar 2003 23:03:38 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Mon, 17 Mar 2003 23:03:38 +0100 (CET) From: Iljitsch van Beijnum To: Pekka Nikander cc: Subject: Re: HIP and PKI reqs [RE: Identifier/locator recap] In-Reply-To: <3E76392A.9040700@nomadiclab.com> Message-ID: <20030317223932.D86639-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-2.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_03_05 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 17 Mar 2003, Pekka Nikander wrote: > > The problem I see with HIP is that you can't initiate a session with > > just the identifier to identify the host you want to communicate with. > You are right. More work is needed. As I wrote, someone > should work out the details how to utilize DHTs, perhaps > in conjunction with DNS. Or something similar. As I said, I'm not up to speed with DHT but I can envision something like this: the address space is spread out as a flat one-dimensional space, where everyone who has a prefix points to a number of others higher and lower (For instance, x + 1, x + 2, x + 4, x + 8 for higher and so on). Then you can do something close to a binary search by jumping up and down through the address space from server to server in ever smaller jumps. This could work extremely well except for one tiny problem: what if some nodes don't cooperate and don't follow the protocol? > > Now that would be fine if it were possible to feed this identifier to a > > lookup engine and get back something you _can_ use to initiate a > > session. But this isn't possible either. > I would say that _currently_ such a mechanism does not exist. > But I would *not* say that it is not _possible_. The fact > that such a solution does not currently exist does not make > it impossible to create one. This is essentially the same old problem: looking up entries in huge piles of data that lacks a hierarchical structure simply doesn't scale. Maybe this is already in there (I can't remember the latest HIP identifier structure, but it's no longer 127 bits of fingerprint, AFAIK) but just in case: why don't you shrink the fingerprint part to 64 or 80 bits. Then you can use the high 48 or 64 bits in a DNS-compatible manner. > > So effectively the HIP > > identifier serves no identifying purpose. > I couldn't understand that. Could you please explain? It's like pointing to something in a dark room. The action seems valid but the result is disappointing. :-) With today's FQDNs and IP addresses there is a fairly simple relationship: each can map to the other. With FQDNs, HIP identifiers and locators this gets a bit complicated. I really think the FQDN is the actual identifier here, not the HIP id. (But I don't think it serves much of a purpose to duke this out.) > > Note that I'm not anti-HIP. I'm sure there are problems that can be > > solved by HIP. But it can't be a general solution for multihoming as it > > only moves the problem to a different area. > So you want me to come up with a completely worked out solution? Could you? :-) > More seriously, personally I believe that HIP has large potential > for end-host multi-homing. Much more than the ID->locator > mapping I see the crypto overhead (Diffie-Hellman) as a problem. > There are also lots of other details to be worked out, with time. > Furthermore, HIP is definitely not a solution for doing large site > multi-homing, other solutions are needed for that. Agree. HIP is good if you're on a single host and need the security. We still need other stuff. From owner-multi6@ops.ietf.org Mon Mar 17 17:30:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04942 for ; Mon, 17 Mar 2003 17:30:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18v397-000N4L-00 for multi6-data@psg.com; Mon, 17 Mar 2003 14:31:53 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 18v394-000N3h-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 14:31:50 -0800 From: Masataka Ohta Message-Id: <200303172210.HAA24143@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id HAA24143; Tue, 18 Mar 2003 07:10:20 +0900 Subject: Re: Again no multi6 at IETF#56 In-Reply-To: from David Conrad at "Mar 17, 2003 12:56:43 pm" To: David Conrad Date: Tue, 18 Mar 2003 07:10:19 +0859 () CC: Michel Py , Joe Abley , Kurt Erik Lindqvist , Tony Li , "Bound, Jim" , Michael Lambert , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-0.7 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk drc; > Define "tier 1". Good question. Let RIRs define it. It can, for example, be defined purely technically with # of POPS and so on or purely financially with auction. Masataka Ohta > > Rgds, > -drc > > On Monday, March 17, 2003, at 12:11 PM, Masataka Ohta wrote: > > > Michel; > > > >>> Joe Abley wrote: > >>> To be pedantic, the requirements doc doesn't specify > >>> the starting point > >> > >> I do not agree. It is clear from that paragraph that the starting > >> point > >> is either "Current IPV4 multihoming practices" or "the Internet's BGP > >> Routing Table". > > > > Not at all. > > > > The global routing table should contain one entry for each tier1 > > ISP or, maybe, a little more than that. > > > > Initially, there may be 10. > > > > AS numbers, of course, may be assigned to tier2 and other ISPs, > > which have multiple peers to other ISPs and want to control > > traffic with BGP. > > > > Masataka Ohta > > > > From owner-multi6@ops.ietf.org Mon Mar 17 18:40:08 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08224 for ; Mon, 17 Mar 2003 18:40:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18v4Dq-0002RB-00 for multi6-data@psg.com; Mon, 17 Mar 2003 15:40:50 -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 #1) id 18v4Dl-0002Qy-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 15:40:45 -0800 Received: from sandelman.ottawa.on.ca (wl-193-246.wireless.ietf56.ietf.org [130.129.193.246] (may be forged)) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h2HNdRD07142 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Mon, 17 Mar 2003 18:39:29 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1] (may be forged)) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h2HNdPMc011352 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 17 Mar 2003 15:39:26 -0800 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-5) with ESMTP id h2HNdOiw011348 for ; Mon, 17 Mar 2003 15:39:25 -0800 Message-Id: <200303172339.h2HNdOiw011348@marajade.sandelman.ottawa.on.ca> To: multi6@ops.ietf.org Subject: Re: Location In-reply-to: Your message of "Mon, 17 Mar 2003 00:57:15 EST." <9C422444DE99BC46B3AD3C6EAFC9711B03241041@tayexc13.americas.cpqcorp.net> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 17 Mar 2003 15:39:23 -0800 From: Michael Richardson X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,LINES_OF_YELLING,MAY_BE_FORGED,PGP_SIGNATURE, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Bound," == Bound, Jim writes: Bound> Location: Bound> Do we believe that providers should know location of all nodes on Bound> the Internet without peering? It took me a bit to understand the question. I think that providers should be able to tell: 1) if a node is reachable by peering or by another method. 2) if another method, then they should be able to identify the method from the address. So, my answer is possibly no. I don't see how we can scale without losing information. ] 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 iQCVAwUBPnZcqoqHRg3pndX9AQGD6AP/fm8Yf25PTXZ8XTX7sqcHFp+wEHq6Pg4L Wc0H1VzPwIGwQgUvW1LTreDvfHbhXwtaI/qZIP66ZDO7deSalFa6om1rj2rhN2Vu 5EzUR+K4OIvlgJ3NcTj43SPhZn/jj6ww/N4IsApwQ4ViC92j70iy+Uu3CYuAXWlH UwpI8xxIRFw= =XvaY -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Mon Mar 17 19:04:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09105 for ; Mon, 17 Mar 2003 19:04:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18v4bu-0004Ux-00 for multi6-data@psg.com; Mon, 17 Mar 2003 16:05:42 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 18v4bs-0004Uh-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 16:05:40 -0800 Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id A46CA137F06; Mon, 17 Mar 2003 16:05:39 -0800 (PST) Date: Mon, 17 Mar 2003 16:05:38 -0800 Subject: Re: Again no multi6 at IETF#56 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Michel Py , Joe Abley , Kurt Erik Lindqvist , Tony Li , "Bound, Jim" , Michael Lambert , multi6@ops.ietf.org To: Masataka Ohta From: David Conrad In-Reply-To: <200303172210.HAA24143@necom830.hpcl.titech.ac.jp> Message-Id: <5982C4FC-58D5-11D7-B7F3-000393DB42B2@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) 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 Hmmm. If you believe this to be an appropriate function of the RIRs, feel free to propose it for an RIR public policy meeting. Bring marshmallows... :-) Rgds, -drc On Monday, March 17, 2003, at 02:11 PM, Masataka Ohta wrote: > drc; > >> Define "tier 1". > > Good question. > > Let RIRs define it. > > It can, for example, be defined purely technically with # of POPS and > so on or purely financially with auction. > > Masataka Ohta >> >> Rgds, >> -drc >> >> On Monday, March 17, 2003, at 12:11 PM, Masataka Ohta wrote: >> >>> Michel; >>> >>>>> Joe Abley wrote: >>>>> To be pedantic, the requirements doc doesn't specify >>>>> the starting point >>>> >>>> I do not agree. It is clear from that paragraph that the starting >>>> point >>>> is either "Current IPV4 multihoming practices" or "the Internet's >>>> BGP >>>> Routing Table". >>> >>> Not at all. >>> >>> The global routing table should contain one entry for each tier1 >>> ISP or, maybe, a little more than that. >>> >>> Initially, there may be 10. >>> >>> AS numbers, of course, may be assigned to tier2 and other ISPs, >>> which have multiple peers to other ISPs and want to control >>> traffic with BGP. >>> >>> Masataka Ohta >>> >> >> > From owner-multi6@ops.ietf.org Mon Mar 17 19:07:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09351 for ; Mon, 17 Mar 2003 19:07:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18v4fV-0004qo-00 for multi6-data@psg.com; Mon, 17 Mar 2003 16:09:25 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18v4fT-0004qN-00; Mon, 17 Mar 2003 16:09:23 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18v4fT-0002iv-00; Mon, 17 Mar 2003 19:09:23 -0500 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 17 Mar 2003 16:09:22 -0800 To: Michael Richardson Cc: multi6@ops.ietf.org Subject: Re: Location References: <9C422444DE99BC46B3AD3C6EAFC9711B03241041@tayexc13.americas.cpqcorp.net> <200303172339.h2HNdOiw011348@marajade.sandelman.ottawa.on.ca> Message-Id: X-Spam-Status: No, hits=0.3 required=5.0 tests=REFERENCES,SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I don't see how we can scale without losing information. s/losing/(scoping|hiding)/ From owner-multi6@ops.ietf.org Mon Mar 17 19:13:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09518 for ; Mon, 17 Mar 2003 19:13:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18v4lA-0005LY-00 for multi6-data@psg.com; Mon, 17 Mar 2003 16:15:16 -0800 Received: from teldanex.hiit.fi ([212.68.5.99] helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 3.36 #1) id 18v4l5-0005Kp-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 16:15:12 -0800 Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 843D41C; Tue, 18 Mar 2003 02:25:16 +0200 (EET) Message-ID: <3E76651C.3060108@nomadiclab.com> Date: Mon, 17 Mar 2003 16:15:24 -0800 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030310 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum Cc: multi6@ops.ietf.org Subject: Re: HIP and PKI reqs [RE: Identifier/locator recap] References: <20030317223932.D86639-100000@sequoia.muada.com> In-Reply-To: <20030317223932.D86639-100000@sequoia.muada.com> 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 Iljitsch van Beijnum wrote: > This could work extremely well except for one tiny problem: what if some > nodes don't cooperate and don't follow the protocol? You just take a different hash (or a different part of an hash), and try again. Or something like that, it's been a few months since I read the DHT papers, and I don't remember the details any more. > This is essentially the same old problem: looking up entries in huge > piles of data that lacks a hierarchical structure simply doesn't scale. Yes it does, if the data is randomly distributed. If it is hierarchical, you can use a tree structure. If it is randomly distributed, you can use a hash structure. The trick is how you distribute your hash structure. We know how to distrubute a tree structures. Distributed hash tables is exactly the method for distributing hash structures. (Sorry that I can't be more specific or write a tutorial, but the DHT stuff is too new for me, too.) > Maybe this is already in there (I can't remember the latest HIP > identifier structure, but it's no longer 127 bits of fingerprint, AFAIK) > but just in case: why don't you shrink the fingerprint part to 64 or 80 > bits. Then you can use the high 48 or 64 bits in a DNS-compatible > manner. It's there: There are two formats for HIT. These two formats are designed to avoid the most commonly occurring IPv6 addresses in RFC2373 [3]. Bits 0 and 1 are used to differentiate the formats. If Bit 0 is zero and Bit 1 is one, then the rest of HIT is a 126 bits of a SHA-1 hash of the Host Identity. If Bit 0 is one and Bit 1 is zero, then the next 62 bits is the Host Assigning Authority (HAA) field, and only the last 64 bits come from a SHA-1 hash of the Host Identity. This format for HIT is recommended for 'well known' systems. It is possible to support a resolution mechanism for these names in directories like DNS. Another use of HAA is in policy controls. > I really think the FQDN is the > actual identifier here, not the HIP id. There we have the difference. Computers don't understand names. Names are just bit strings to them. Public keys make *re*cognition possible to computers, just like faces make it to people. --Pekka Nikander From owner-multi6@ops.ietf.org Mon Mar 17 19:32:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10141 for ; Mon, 17 Mar 2003 19:32:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18v53l-0006sD-00 for multi6-data@psg.com; Mon, 17 Mar 2003 16:34:29 -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 #1) id 18v53i-0006rt-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 16:34:26 -0800 Received: from sandelman.ottawa.on.ca (wl-193-246.wireless.ietf56.ietf.org [130.129.193.246] (may be forged)) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h2I0X7D07339 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Mon, 17 Mar 2003 19:33:09 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1] (may be forged)) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h2I0X5Mc012850 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 17 Mar 2003 16:33:06 -0800 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-5) with ESMTP id h2I0X5H2012846 for ; Mon, 17 Mar 2003 16:33:05 -0800 Message-Id: <200303180033.h2I0X5H2012846@marajade.sandelman.ottawa.on.ca> To: multi6@ops.ietf.org Subject: Re: HIP and PKI reqs [RE: Identifier/locator recap] In-reply-to: Your message of "Mon, 17 Mar 2003 17:34:33 +0200." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 17 Mar 2003 16:33:05 -0800 From: Michael Richardson X-Spam-Status: No, hits=-0.3 required=5.0 tests=IN_REP_TO,LINES_OF_YELLING,MAY_BE_FORGED,PGP_SIGNATURE, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Pekka" == Pekka Savola writes: Pekka> However, my complaint with HIP model is that it seems so closely Pekka> tied to Pekka> ESP and security. Why is this a problem for you? I think that we very much need better security. This is end-to-end security. P4s don't even notice doing 3DES (let alone AES), and TPCA may put hardware accelerators on every motherboard. ] 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 iQCVAwUBPnZpP4qHRg3pndX9AQEeDgQAz1PLCjM3Mduevr//hMHtbWQrWzF1pudo JZa3hp44vMJFvbaOZyJsRGJ3dBYwam03EqP0MrPd1tZl4E4DJOCwwkAc99dRA5DO r9KAz9LA8rDit5BDHayaJd3C/DKskhSQR1C7ezT2Yztw+nHZ8p3UqvaSy4IbdR/T E8qQYZePkc4= =eJY4 -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Mon Mar 17 19:57:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10965 for ; Mon, 17 Mar 2003 19:57:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18v5RA-0009Xu-00 for multi6-data@psg.com; Mon, 17 Mar 2003 16:58:40 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18v5R4-0009Xf-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 16:58:35 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2I0wM805407; Tue, 18 Mar 2003 02:58:30 +0200 Date: Tue, 18 Mar 2003 02:58:21 +0200 (EET) From: Pekka Savola To: marcelo bagnulo cc: Iljitsch van Beijnum , Subject: Re: comments on mipv6 application to multihoming [Re: Move forward] In-Reply-To: <1047842492.789.380.camel@presto.it.uc3m.es> 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_02_03,USER_AGENT_PINE version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk On 16 Mar 2003, marcelo bagnulo wrote: > > ==> The problem is that this mechanism only "works" (for some definition of > > works) > > Preserves established sessions perhaps? Yes -- with certain tradeoffs: to preserve established sessions, you *typically* have to react quickly, and of course the sessions should be preservable for the duration of the failure, but that's not as hard a requirement to me (ie. if you get a warning that connections have failed, using backups whic will help you for the next 5 minutes, shut them down gracefully if the break is expected to last longer). > > > for sessions that are broken over 140 seconds > > This is an upper bound. I mean it can be reduced but it can not be > increased. In order to reduce it all that it is needed is to increase > the frequency of HoTI CoTI message exchange. This would indeed increase > the overhead, and cost benefit analysis should be performed in order to > obtain an optimal choice. What it can not be done is to have a longer > detection period. But if i understand correctly you do not have a > problem with this. > > Mechanism that provide a faster response to failures have to be included > once that other problems have been solved (like the next one) Yes, definitely the reaction time would have to be shorter. However, I'm not sure if the HOTI/COTI exchange is the right mechanism for that: I'm not sure whether it scales down properly. (It was never meant as a heartbeat mechanism.) > > (ie. connection is not > > aborted before that), with the upper bound of 420 seconds. > > This is the real problem IMO.The alternative address can only be used > for a limited period (420 secs). Then you have to > perform the RR procedure again to obtain new valid authorization data > that is to be used for extending the lifetime of the new address. THis > is a major problem since you can not perform the RR procedure because > the HoA is no longer available. The solution for this would be to extend > the lifetime of the binding but this may have security implications. you > have previously worked in MIPv6 security, right? could you comment about > the security concerns of extending this timer? Due to the RR procedure, it doesn't protect you from on-the-link or on-the-path attackers. Attackers which *have been* on the link or on the path can wreak havoc to up to MAX_RR_BINDING_LIFETIME (420 s) after leaving the link or the path. Cranking it up significantly would certainly have implications but slight modifications probably not so much (e.g. if your friendly router implementation rebooting takes 430 seconds, the lifetime could very well be 600 seconds). The order of magnitude matters. .. but there may be something I'm missing. > > On top of that, > > quite a bit of signalling is performed just in case that a link might go > > down. > > e2e failure detection implies traffic exchange. It is important to > discuss whether this overhead is acceptable or not. Indeed -- some mechanism do this always, some just after the fact (when suspecting some error has occurred, e.g. TCP acks get delayed), some both. > > Btw, how does a node know the > > prefix length of his site? Not an easy problem, unless it's guessing.. > > > > Good point!!! > An option is to consider that it is always a /48, but i don't thik this > is a good approach. > Another possibility is to assign the site exit routers anycast address > of every subnet to the corresponding exit router and propagate it within > the site as a host route. So hosts will address packets to its own > subnet exit site router anycast address, which will be routed to the > correspondent exit router. > Since the explanation is not so clear i will put an example > > > > +----+ +----+ > |R1 | |R2 | > |P1::| |P2::| > +----+ +----+ > P1:Subnet1:Router1 | P2:Subnet2:Router2 | > ------------------------------------- > P1:Subnet1:Router3 | > P2:Subnet2:Router3 | > +----+ > |R3 | > +----+ > P1:Subnet3:Router3 | > P2:Subnet4:Router3 | > ----------------------------------- > P1:Subnet3:Host | > P2:Subnet4:Host | > +----+ > |Host| > +----+ > So Addresses P1:Subnet1:FFFF:FFFF:FFFF:FFFF and > P1:Subnet3:FFFF:FFFF:FFFF:FFFF are assigned to R1. > P1:Subnet3:FFFF:FFFF:FFFF:FFFF is announced within the site as a host > route to R1 > Addresses P2:Subnet2:FFFF:FFFF:FFFF:FFFF and > P2:Subnet4:FFFF:FFFF:FFFF:FFFF are assigned to R2. > P2:Subnet4:FFFF:FFFF:FFFF:FFFF is announced within the site as a host > route to R2 > So when Host sends a packet whose source address contains the prefix P1, > it includes a routing header with P1:Subnet3:FFFF:FFFF:FFFF:FFFF which > is deduced from its own prefix. > > Not very nice, but i guess this would work, don't you? Doesn't work -- the host will detect that the prefix is on-link, and will try to reach it by sending neighbor solicitation to it. The access router would have to perform proxy-ND for it. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Mon Mar 17 20:04:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11321 for ; Mon, 17 Mar 2003 20:04:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18v5ZC-000ALM-00 for multi6-data@psg.com; Mon, 17 Mar 2003 17:06:58 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 18v5Z6-000AJX-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 17:06:52 -0800 From: Masataka Ohta Message-Id: <200303180100.JAA25331@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id JAA25331; Tue, 18 Mar 2003 09:59:51 +0859 Subject: Re: Again no multi6 at IETF#56 In-Reply-To: <5982C4FC-58D5-11D7-B7F3-000393DB42B2@nominum.com> from David Conrad at "Mar 17, 2003 04:05:38 pm" To: David Conrad Date: Tue, 18 Mar 2003 09:59:50 +0859 () CC: Michel Py , Joe Abley , Kurt Erik Lindqvist , Tony Li , "Bound, Jim" , Michael Lambert , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-0.7 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk drc; > If you believe this to be an appropriate function of the RIRs, feel > free to propose it for an RIR public policy meeting. An appropriate function of RIRs is to develop policy on how one can be qualified to be assigned resources such as addresses. IETF should tell RIRs that at most 10, for example, TLA should be assinged and details will be figured out within RIRs. Masataka Ohta From owner-multi6@ops.ietf.org Mon Mar 17 22:19:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14864 for ; Mon, 17 Mar 2003 22:19:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18v7ds-000GEH-00 for multi6-data@psg.com; Mon, 17 Mar 2003 19:19:56 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18v7dp-000GDx-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 19:19:53 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2I3Jfc06878; Tue, 18 Mar 2003 05:19:41 +0200 Date: Tue, 18 Mar 2003 05:19:40 +0200 (EET) From: Pekka Savola To: Michael Richardson cc: multi6@ops.ietf.org Subject: Re: HIP and PKI reqs [RE: Identifier/locator recap] In-Reply-To: <200303180033.h2I0X5H2012846@marajade.sandelman.ottawa.on.ca> 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 Mon, 17 Mar 2003, Michael Richardson wrote: > >>>>> "Pekka" == Pekka Savola writes: > Pekka> However, my complaint with HIP model is that it seems so closely > Pekka> tied to > Pekka> ESP and security. > > Why is this a problem for you? Two words: Middleboxes, policy. Yeah, those are something that security hackers aren't concerned about.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Mon Mar 17 23:19:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16770 for ; Mon, 17 Mar 2003 23:19:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18v8a3-000J2P-00 for multi6-data@psg.com; Mon, 17 Mar 2003 20:20:03 -0800 Received: from dmz1.procket.com ([65.174.124.36]) by psg.com with esmtp (Exim 3.36 #1) id 18v8a0-000J1y-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 20:20:00 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id AC16223C4E; Mon, 17 Mar 2003 20:44:50 -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 h2I4JqYB027153; Mon, 17 Mar 2003 20:19:58 -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="us-ascii" Subject: RE: Reducing Peerings for MH Routing within a site via end systems Date: Mon, 17 Mar 2003 20:19:52 -0800 Message-ID: Thread-Topic: Reducing Peerings for MH Routing within a site via end systems Thread-Index: AcLsSOfSvGXrMnooRAieaRoipQ9LGwAFQc9wAA4h0VAAEdF5IA== From: "Tony Li" To: "Bound, Jim" , 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 XAA16770 Jim, | >If a host has multiple locators and a single identifier | and other hosts | are able >to change the locator that they are using at | will, then it | implies that special | | Clarification. Above you have "conjunction" ...and other hosts? I | assume you mean any host can change their locator? I think that a host should be able to change the set of locators that make it reachable at will. The rate that the system can disseminate these changes is still TBD, but there obviously needs to be an upper bound (no pun intended ;-). Correspondent hosts are free to try different locators at any time. Typically they will use transport layer hints to trigger things. | >Effectively, the site has PA space from each of its | providers and that | PA space >is nicely aggregated in global routing. | | So the locators for this site is known by all of the sites | providers, | correct? Yes. Even more strongly, the locators are allocated by the providers. | IPsec between those two peers without any translation of | the packets | headers. Ipsec, in particular, needs to use the identifier in crafting the security association, NOT the locators. [This would also allow Ipsec to work through NAT. ;-) ] | Do we agree on that and this is a core principle for any Internet | engineer one way or the other? Please restate with dereferenced pronouns. | >One could reasonably argue that you take the layer of | separation down | >recursively. | | Within the IGP from the Provider space? If that, then I agree. Within the site IGP, but using the locators provided in PA space. | >Note that this alleviates the most painful reason to | avoid PA space: | | But above you state "nicely aggregates provider space"? Can you | rectify? These aren't incompatible. Your locators are aggregateable and you don't need to renumber. Should make everyone happy... ;-) | >renumbering is now a non-issue. You assign a new locator to your | entire site, | >advertise it to the world and you're good to go. Individual host | identifiers | >need not change. No host renumbering. | | But still implies locators can change? For example one move to | completely new providers? Of course. You add new provider, configure edge router with new locator prefix, update the locator database and you're done. | Your location is not worldwide provider space but only for relative | provider space for a site? | Is that correct? Locators are part of what we would now think of as PA space. That is, they are topologically significant information that vary per-provider. Tony From owner-multi6@ops.ietf.org Mon Mar 17 23:34:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17364 for ; Mon, 17 Mar 2003 23:34:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18v8q0-000JpV-00 for multi6-data@psg.com; Mon, 17 Mar 2003 20:36:32 -0800 Received: from mailout.zma.compaq.com ([161.114.64.105] helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18v8px-000JpB-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 20:36:29 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id C4EEE80B8; Mon, 17 Mar 2003 23:36:28 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Mar 2003 23:36:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Reducing Peerings for MH Routing within a site via end systems Date: Mon, 17 Mar 2003 23:36:28 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCD14@tayexc13.americas.cpqcorp.net> Thread-Topic: Reducing Peerings for MH Routing within a site via end systems Thread-Index: AcLsSOfSvGXrMnooRAieaRoipQ9LGwAFQc9wAA4h0VAAEdF5IAAKiDqw From: "Bound, Jim" To: "Tony Li" , X-OriginalArrivalTime: 18 Mar 2003 04:36:28.0708 (UTC) FILETIME=[F1343640:01C2ED07] 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 XAA17364 Tony, Thanks. No response will try to not do the pronoun thing. /jim > -----Original Message----- > From: Tony Li [mailto:Tony.Li@procket.com] > Sent: Monday, March 17, 2003 11:20 PM > To: Bound, Jim; multi6@ops.ietf.org > Subject: RE: Reducing Peerings for MH Routing within a site > via end systems > > > > > Jim, > > | >If a host has multiple locators and a single identifier > | and other hosts > | are able >to change the locator that they are using at > | will, then it > | implies that special > | > | Clarification. Above you have "conjunction" ...and > other hosts? I > | assume you mean any host can change their locator? > > > I think that a host should be able to change the set of > locators that make it reachable at will. The rate that the > system can disseminate these changes is still TBD, but there > obviously needs to be an upper bound (no pun intended ;-). > > Correspondent hosts are free to try different locators at any > time. Typically they will use transport layer hints to > trigger things. > > > | >Effectively, the site has PA space from each of its > | providers and that > | PA space >is nicely aggregated in global routing. > | > | So the locators for this site is known by all of the sites > | providers, > | correct? > > > Yes. Even more strongly, the locators are allocated by the providers. > > > | IPsec between those two peers without any translation of > | the packets > | headers. > > > Ipsec, in particular, needs to use the identifier in crafting > the security association, NOT the locators. [This would also > allow Ipsec to work through NAT. ;-) ] > > > | Do we agree on that and this is a core principle for any Internet > | engineer one way or the other? > > > Please restate with dereferenced pronouns. > > > | >One could reasonably argue that you take the layer of > | separation down > | >recursively. > | > | Within the IGP from the Provider space? If that, then I agree. > > > Within the site IGP, but using the locators provided in PA space. > > > | >Note that this alleviates the most painful reason to > | avoid PA space: > | > | But above you state "nicely aggregates provider space"? Can you > | rectify? > > > These aren't incompatible. Your locators are aggregateable > and you don't need to renumber. Should make everyone happy... ;-) > > > | >renumbering is now a non-issue. You assign a new > locator to your > | entire site, > | >advertise it to the world and you're good to go. > Individual host > | identifiers > | >need not change. No host renumbering. > | > | But still implies locators can change? For example one move to > | completely new providers? > > > Of course. You add new provider, configure edge router with > new locator prefix, update the locator database and you're done. > > > | Your location is not worldwide provider space but only > for relative > | provider space for a site? > | Is that correct? > > > Locators are part of what we would now think of as PA space. > That is, they are topologically significant information that > vary per-provider. > > Tony > > From owner-multi6@ops.ietf.org Tue Mar 18 00:25:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18857 for ; Tue, 18 Mar 2003 00:25:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18v9cV-000MI2-00 for multi6-data@psg.com; Mon, 17 Mar 2003 21:26:39 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 18v9cT-000MHf-00 for multi6@ops.ietf.org; Mon, 17 Mar 2003 21:26:37 -0800 From: Masataka Ohta Message-Id: <200303180515.OAA26850@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id OAA26850; Tue, 18 Mar 2003 14:15:10 +0900 Subject: Re: Reducing Peerings for MH Routing within a site via end systems In-Reply-To: from Tony Li at "Mar 17, 2003 08:19:52 pm" To: Tony Li Date: Tue, 18 Mar 2003 14:15:09 +0859 () CC: "Bound, Jim" , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-0.7 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Tony; > I think that a host should be able to change the set of locators > that make it reachable at will. The rate that the system can > disseminate these changes is still TBD, but there obviously > needs to be an upper bound (no pun intended ;-). You don't have to determine it. Cache period of DNS, for example, is configurable. > Of course. You add new provider, configure edge router with new > locator prefix, update the locator database and you're done. IPv6 WG is seriously considering to automate prefix configuration of routers. But, it seems to me that the automatic update of the database is impossible, if, as is often the case, the prefix of servers of the database is being configured. :-) Masataka Ohta From owner-multi6@ops.ietf.org Tue Mar 18 03:51:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04455 for ; Tue, 18 Mar 2003 03:51:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vCof-0006AB-00 for multi6-data@psg.com; Tue, 18 Mar 2003 00:51:25 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18vCoZ-00069h-00 for multi6@ops.ietf.org; Tue, 18 Mar 2003 00:51:19 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2I8oJp88481; Tue, 18 Mar 2003 09:50:20 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Tue, 18 Mar 2003 09:50:19 +0100 (CET) From: Iljitsch van Beijnum To: Michael Richardson cc: Subject: Re: HIP and PKI reqs [RE: Identifier/locator recap] In-Reply-To: <200303180033.h2I0X5H2012846@marajade.sandelman.ottawa.on.ca> Message-ID: <20030318093731.T87639-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, 17 Mar 2003, Michael Richardson wrote: > Pekka> However, my complaint with HIP model is that it seems so closely > Pekka> tied to ESP and security. > Why is this a problem for you? I can't speak for anyone else, but there are many times I have no need to obfuscate my communications. In those cases, why should I suffer the bandwidth, CPU and management overhead of IPsec? (In IPv6 everything will configure pretty much automatically but doing IPsec of course fully negates (and more) this advantage.) > I think that we very much need better security. This is end-to-end > security. P4s don't even notice doing 3DES (let alone AES), and TPCA may > put hardware accelerators on every motherboard. This is hardly true: 3DES maxes out at around 200 Mbps if we are to believe http://www.mediacrypt.com/engl/Downloads/IDEA_Perf_Overall.pdf In high speed networking, every copy cycle hurts. So how can encryption be "free"? Also, even if I have a P4 at my disposal (which I don't) I could very well need the CPU time for something else. And on mobile devices, this eats up battery power unnecessarily. There is often a need for crypto. However, there is also often a need to _not_ have crypto. From owner-multi6@ops.ietf.org Tue Mar 18 04:08:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04735 for ; Tue, 18 Mar 2003 04:08:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vD76-0006uj-00 for multi6-data@psg.com; Tue, 18 Mar 2003 01:10:28 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18vD73-0006uW-00 for multi6@ops.ietf.org; Tue, 18 Mar 2003 01:10:25 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2I99Ro88502; Tue, 18 Mar 2003 10:09:27 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Tue, 18 Mar 2003 10:09:27 +0100 (CET) From: Iljitsch van Beijnum To: Pekka Nikander cc: Subject: Re: HIP and PKI reqs [RE: Identifier/locator recap] In-Reply-To: <3E76651C.3060108@nomadiclab.com> Message-ID: <20030318095215.L87639-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 Mon, 17 Mar 2003, Pekka Nikander wrote: > > This could work extremely well except for one tiny problem: what if some > > nodes don't cooperate and don't follow the protocol? > You just take a different hash (or a different part > of an hash), and try again. Hm, this means that there must be a record with a cryptographic signature for every possible entry, including non-existing ones so a node can't fake a "doesn't exist" message. But I still don't like the idea of having to depend on some random servers somewhere on the net that I have no influence over. > > This is essentially the same old problem: looking up entries in huge > > piles of data that lacks a hierarchical structure simply doesn't scale. > Yes it does, if the data is randomly distributed. > If it is hierarchical, you can use a tree structure. > If it is randomly distributed, you can use a hash structure. Ok, I should have mentioned some constraints, mostly "distributed". In a tree, you can delegate sub-trees to organizations. When using a hash (or a simple flat space that can be searched using binary search) stuff from different people ends up on one pile so you need some level of trust to make it work. > > I really think the FQDN is the > > actual identifier here, not the HIP id. > There we have the difference. Computers don't understand names. > Names are just bit strings to them. Public keys make *re*cognition > possible to computers, just like faces make it to people. This is a good comparison. Yes, we recognize people by their face, but a face is not what identifies a person, that's their name and some extra info to discriminate against people with the same name. It is a very useful feature if computers can recognize other computers, but it's only relevant if they can translate this into something a user can understand, like: "this message was authenticated as written by jbezos@amazon.com" or "you are now communicating securely with ietf93registration.ietf.org". In other words: to the user, the identifier is the FQDN or an application-specific name (usually based on a FQDN). (But it's ok if there must be some additional mapping between internal stuff and user stuff.) From owner-multi6@ops.ietf.org Tue Mar 18 11:36:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16853 for ; Tue, 18 Mar 2003 11:36:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vK5k-0002X0-00 for multi6-data@psg.com; Tue, 18 Mar 2003 08:37:32 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #1) id 18vK5h-0002Wk-00 for multi6@ops.ietf.org; Tue, 18 Mar 2003 08:37:29 -0800 Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.6/8.12.6) with ESMTP id h2IGbRkw020377; Tue, 18 Mar 2003 11:37:27 -0500 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.6/8.12.6/Submit) id h2IGbQ6I020376; Tue, 18 Mar 2003 11:37:26 -0500 Date: Tue, 18 Mar 2003 11:37:26 -0500 From: "J. Noel Chiappa" Message-Id: <200303181637.h2IGbQ6I020376@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: Identifier/locator recap Cc: jnc@ginger.lcs.mit.edu 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 > From: Iljitsch van Beijnum I've been meaning to send in a minor rant for some time now, and this message gives me a good hook.. > Traditional multihoming as is done in IPv4 will not scale. That is to say, multihoming which is supported entirely by the routing. > An alternative is to give each host in a multihomed site an address for > each ISP the site is connected to. .. However, current transport > protocols are unable to jump to new addresses in mid-session. Solution: > separate the identifier and locator functions of the IP address. Here's my rant: This group is spending a lot of its time discussing the identity/location separation. I wish to make it crystal clear that this is a *secondary* issue when it comes to supporting multi-homing (the expressed purpose of this group :-). The way in which one does multi-homing that scales is use of multiple routing-names (a.k.a. addresses)#. Not as much attention has been given to this part of the problem (e.g. how do you decide which address to use, how do you decide when to switch, etc) although I have recently seen some traffic about it. But please everyone, keep in mind that separation of location and identity is *not* what supports multi-homing - what makes multi-homing work is use of multiple addresses. Separation of location and identity comes in because of *other* concerns that people have. Noel Note #: I think it's possible to do multi-homing with only a single routing-name (a.k.a. address) - but to do so would require that the addresses be asigned automatically by a system which was looking at the actual physical connectivity. In other words, addresses would not be assigned by a registry, and would change as the topology changed. In terms of the location/identity issue, you'd still wind up with the same problem, that an address was not a useful long-term idenitifer of *who* you were talking to - it would only say *where* it is. From owner-multi6@ops.ietf.org Tue Mar 18 11:39:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16963 for ; Tue, 18 Mar 2003 11:39:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vK9Y-0002nI-00 for multi6-data@psg.com; Tue, 18 Mar 2003 08:41:28 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18vK9U-0002n5-00 for multi6@ops.ietf.org; Tue, 18 Mar 2003 08:41:24 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18vK9U-000379-00 for multi6@ops.ietf.org; Tue, 18 Mar 2003 11:41:24 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200303181639.h2IGdlkw020411@ginger.lcs.mit.edu> In-reply-to: Your message of Mon, 17 Mar 2003 13:07:54 -0800. <3E76392A.9040700@nomadiclab.com> From: Tim Shepard To: Pekka Nikander cc: Iljitsch van Beijnum , multi6@ops.ietf.org Subject: Re: HIP and PKI reqs [RE: Identifier/locator recap] Date: Tue, 18 Mar 2003 11:39:47 -0500 X-Spam-Status: No, hits=-0.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RESENT_TO,SPAM_PHRASE_08_13 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] > > The problem I see with HIP is that you can't initiate a session with > > just the identifier to identify the host you want to communicate with. > > You are right. More work is needed. As I wrote, someone > should work out the details how to utilize DHTs, perhaps > in conjunction with DNS. Or something similar. Today you cannot initiate a connection if all you have is the ssh host key. Is this a problem with ssh that needs to be fixed? If not, then why does it need to be fixed with HIP? I also thought I'd mention that you cannot initiate a connection with a web server if all you have is one of those certificates used to authenticate the identity of https servers. But then I realized that you can, because the dns name of the server is embeded in the certificate. The real question is how does anyone ever get their hands on one of these certificates in the first place? My real point is that perhaps we do not need to solve this problem. We can do as ssh does, and start with a DNS name which gets us an IP address (and perhaps a HIT), then initiate a HIP exchange with whatever is at that IP address. (In any case, implementing some sort of DHT as Pekka Nikander suggests sounds like a cool idea and an interesting research question. And it may be as easy as he believes.) -Tim Shepard shep@alum.mit.edu From owner-multi6@ops.ietf.org Tue Mar 18 11:56:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18151 for ; Tue, 18 Mar 2003 11:56:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vKPz-000416-00 for multi6-data@psg.com; Tue, 18 Mar 2003 08:58:27 -0800 Received: from teldanex.hiit.fi ([212.68.5.99] helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 3.36 #1) id 18vKPw-00040m-00 for multi6@ops.ietf.org; Tue, 18 Mar 2003 08:58:25 -0800 Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 63DD21C; Tue, 18 Mar 2003 19:08:28 +0200 (EET) Message-ID: <3E77503C.7060502@nomadiclab.com> Date: Tue, 18 Mar 2003 08:58:36 -0800 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030310 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum Cc: multi6@ops.ietf.org Subject: Re: HIP and PKI reqs [RE: Identifier/locator recap] References: <20030318095215.L87639-100000@sequoia.muada.com> In-Reply-To: <20030318095215.L87639-100000@sequoia.muada.com> 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 Iljitsch van Beijnum wrote: >>You just take a different hash (or a different part >>of an hash), and try again. > > Hm, this means that there must be a record with a cryptographic > signature for every possible entry, including non-existing ones so a > node can't fake a "doesn't exist" message. Actually you can do easier by not having a "doesn't exist" message. If you don't get a reply from the primary server, as resolved from the primary part of the hash, you just try to secondary server, resolved from another part of the hash. There can't be any correlation between the servers (the hash is basically a random number, pointing you to random servers). The probability of collusion between the servers is very very low, and can be ignored. Thus, you don't need to have any signatures for non-existing ones. > But I still don't like the > idea of having to depend on some random servers somewhere on the net > that I have no influence over. Do you feel the same about MHAP randezvous points? > Ok, I should have mentioned some constraints, mostly "distributed". In a > tree, you can delegate sub-trees to organizations. When using a hash (or > a simple flat space that can be searched using binary search) stuff from > different people ends up on one pile so you need some level of trust to > make it work. Trust, or random reduncancy. With random redundancy, you get some level of byzantine robustness. Other than that, I agree with you. >>There we have the difference. Computers don't understand names. >>Names are just bit strings to them. Public keys make *re*cognition >>possible to computers, just like faces make it to people > > This is a good comparison. Yes, we recognize people by their face, but a > face is not what identifies a person, that's their name and some extra > info to discriminate against people with the same name. Agree. (As with the rest of your comment.) --Pekka Nikander From owner-multi6@ops.ietf.org Tue Mar 18 11:58:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18268 for ; Tue, 18 Mar 2003 11:58:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vKRj-00046n-00 for multi6-data@psg.com; Tue, 18 Mar 2003 09:00:15 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18vKRZ-000463-00 for multi6@ops.ietf.org; Tue, 18 Mar 2003 09:00:05 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2IGx5a89138; Tue, 18 Mar 2003 17:59:05 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Tue, 18 Mar 2003 17:59:05 +0100 (CET) From: Iljitsch van Beijnum To: Tim Shepard cc: Subject: Re: HIP and PKI reqs [RE: Identifier/locator recap] In-Reply-To: <200303181639.h2IGdlkw020411@ginger.lcs.mit.edu> Message-ID: <20030318175615.W87639-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 Tue, 18 Mar 2003, Tim Shepard wrote: > My real point is that perhaps we do not need to solve this problem. > We can do as ssh does, and start with a DNS name which gets us an IP > address (and perhaps a HIT), then initiate a HIP exchange with > whatever is at that IP address. That's fine if you're the one initiating the session, but what if you are on the receiving end? You then get locator IP addresses which may not have good PTR records (remember, HIP is for mobility too) and a HIP id that can't be resolved into a name. > (In any case, implementing some sort of DHT as Pekka Nikander suggests > sounds like a cool idea and an interesting research question. And > it may be as easy as he believes.) Tell me how this can be secure. From owner-multi6@ops.ietf.org Tue Mar 18 12:08:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18721 for ; Tue, 18 Mar 2003 12:08:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vKah-0004lK-00 for multi6-data@psg.com; Tue, 18 Mar 2003 09:09:31 -0800 Received: from smtp01.uc3m.es ([163.117.136.121] helo=smtp.uc3m.es) by psg.com with esmtp (Exim 3.36 #1) id 18vKad-0004l6-00 for multi6@ops.ietf.org; Tue, 18 Mar 2003 09:09:27 -0800 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 4702743190; Tue, 18 Mar 2003 18:09:26 +0100 (CET) Received: from presto.it.uc3m.es (presto.it.uc3m.es [163.117.139.134]) by smtp01.uc3m.es (Postfix) with ESMTP id 362B799E66; Tue, 18 Mar 2003 18:09:26 +0100 (CET) Subject: Re: Identifier/locator recap From: marcelo bagnulo To: "J. Noel Chiappa" Cc: multi6@ops.ietf.org In-Reply-To: <200303181637.h2IGbQ6I020376@ginger.lcs.mit.edu> References: <200303181637.h2IGbQ6I020376@ginger.lcs.mit.edu> Content-Type: text/plain Organization: uc3m Message-Id: <1048007364.1379.29.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 18 Mar 2003 18:09:24 +0100 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.0 required=5.0 tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_05_08 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Noel, Fully agree with your comment, just wanted to add... > The way in which one does multi-homing that scales is use of multiple > routing-names (a.k.a. addresses)#. Not as much attention has been given to > this part of the problem (e.g. how do you decide which address to use, how do > you decide when to switch, etc) although I have recently seen some traffic > about it. > > But please everyone, keep in mind that separation of location and identity is > *not* what supports multi-homing - what makes multi-homing work is use of > multiple addresses. ...bound to *one* (upper layer) identifier (which can be both a locator and an identifier (like HoAs)). IMHO this is the difficult part (security, preservation of established connections) > Separation of location and identity comes in because of > *other* concerns that people have. > This is solution for a more general problem but it also addresses this particular issue. If the identifier and the locator are already separated and the architecture provides tools to bind them safely, i would say that you have solved the mh problem. Regards, marcelo > Noel > > > Note #: I think it's possible to do multi-homing with only a single > routing-name (a.k.a. address) - but to do so would require that the addresses > be asigned automatically by a system which was looking at the actual physical > connectivity. In other words, addresses would not be assigned by a registry, > and would change as the topology changed. In terms of the location/identity > issue, you'd still wind up with the same problem, that an address was not a > useful long-term idenitifer of *who* you were talking to - it would only say > *where* it is. -- marcelo bagnulo uc3m From owner-multi6@ops.ietf.org Tue Mar 18 12:29:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19389 for ; Tue, 18 Mar 2003 12:29:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vKu7-0005UQ-00 for multi6-data@psg.com; Tue, 18 Mar 2003 09:29:35 -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 #1) id 18vKu4-0005UC-00 for multi6@ops.ietf.org; Tue, 18 Mar 2003 09:29:33 -0800 Received: from sandelman.ottawa.on.ca (wl-142-230.wireless.ietf56.ietf.org [130.129.142.230]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h2IHS9D10401 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Tue, 18 Mar 2003 12:28:13 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1] (may be forged)) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h2IHS7AR018366 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 18 Mar 2003 09:28:08 -0800 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-5) with ESMTP id h2IHS7oL018362 for ; Tue, 18 Mar 2003 09:28:07 -0800 Message-Id: <200303181728.h2IHS7oL018362@marajade.sandelman.ottawa.on.ca> To: multi6@ops.ietf.org Subject: Re: Location In-reply-to: Your message of "Mon, 17 Mar 2003 16:09:22 PST." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 18 Mar 2003 09:28:06 -0800 From: Michael Richardson X-Spam-Status: No, hits=0.0 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED,SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk >>>>> "Randy" == Randy Bush writes: >> I don't see how we can scale without losing information. Randy> s/losing/(scoping|hiding)/ Yes, I agree. Hiding is the right thought. ] 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 Tue Mar 18 12:55:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20603 for ; Tue, 18 Mar 2003 12:55:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vLKM-0006Wq-00 for multi6-data@psg.com; Tue, 18 Mar 2003 09:56:42 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 18vLKI-0006WP-00 for multi6@ops.ietf.org; Tue, 18 Mar 2003 09:56:39 -0800 From: Masataka Ohta Message-Id: <200303181744.CAA29515@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id CAA29515; Wed, 19 Mar 2003 02:43:46 +0859 Subject: Re: Identifier/locator recap In-Reply-To: <200303181637.h2IGbQ6I020376@ginger.lcs.mit.edu> from "J. Noel Chiappa" at "Mar 18, 2003 11:37:26 am" To: "J. Noel Chiappa" Date: Wed, 19 Mar 2003 02:43:46 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-1.0 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Noel; > But please everyone, keep in mind that separation of location and identity is > *not* what supports multi-homing - what makes multi-homing work is use of > multiple addresses. Supporting multiple addresses becomes extremely simple with ID/locator separation, extremely complex otherwise. > Separation of location and identity comes in because of > *other* concerns that people have. Simplicity of specifications and implementations, which are essential requirement to have multihoming or anything else. > Note #: I think it's possible to do multi-homing with only a single > routing-name (a.k.a. address) - but to do so would require that the addresses > be asigned automatically by a system which was looking at the actual physical > connectivity. In other words, addresses would not be assigned by a registry, > and would change as the topology changed. You are saying to use multiple addresses as the topology change. You also ignore that if a topology allows for multiple pathes between hosts, there can be multiple addresses of a host. And, it is a scalability problem for a registry to reassign addresses upon topology change to all the affected hosts. Masataka Ohta From owner-multi6@ops.ietf.org Tue Mar 18 15:39:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29192 for ; Tue, 18 Mar 2003 15:39:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vNrG-000EKK-00 for multi6-data@psg.com; Tue, 18 Mar 2003 12:38:50 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #1) id 18vNrA-000EJS-00 for multi6@ops.ietf.org; Tue, 18 Mar 2003 12:38:44 -0800 Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.6/8.12.6) with ESMTP id h2IKcgkw021794; Tue, 18 Mar 2003 15:38:42 -0500 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.6/8.12.6/Submit) id h2IKcgQ5021791; Tue, 18 Mar 2003 15:38:42 -0500 Date: Tue, 18 Mar 2003 15:38:42 -0500 From: "J. Noel Chiappa" Message-Id: <200303182038.h2IKcgQ5021791@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: Again no multi6 at IETF#56 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: Kurt Erik Lindqvist >> If there is a choice in how to multi-home, then some folks will >> inevitably choose the wrong way and we will again implode. > We need apply the solution we have today with zero implementation. And > I don't see any other alternative. six months from now we might have > something better. Let's do that then. The thing is that we don't need to do anything to allow people to do it the "current way" (i.e. let the routing handle it, al la IPv4 MH) - in fact, I doubt we could stop them, actually. On the other hand, there's no need to put the IETF Gold Seal of Approval on something we now won't scale in the long term. Taken together, that all argues that we should press on and say nothing about the interim IPv4-type thing. Noel From owner-multi6@ops.ietf.org Tue Mar 18 16:05:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00145 for ; Tue, 18 Mar 2003 16:05:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vOID-000FXP-00 for multi6-data@psg.com; Tue, 18 Mar 2003 13:06:41 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 18vOI2-000FWu-00 for multi6@ops.ietf.org; Tue, 18 Mar 2003 13:06:30 -0800 From: Masataka Ohta Message-Id: <200303182059.FAA00828@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id FAA00828; Wed, 19 Mar 2003 05:59:18 +0900 Subject: Re: Again no multi6 at IETF#56 In-Reply-To: <200303182038.h2IKcgQ5021791@ginger.lcs.mit.edu> from "J. Noel Chiappa" at "Mar 18, 2003 03:38:42 pm" To: "J. Noel Chiappa" Date: Wed, 19 Mar 2003 05:59:17 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-0.7 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Noel; > > From: Kurt Erik Lindqvist > > >> If there is a choice in how to multi-home, then some folks will > >> inevitably choose the wrong way and we will again implode. > > > We need apply the solution we have today with zero implementation. And > > I don't see any other alternative. six months from now we might have > > something better. Let's do that then. Our LIN6 based scalable multihoming implementaion has been working for about a year on the world largest mobile IPv6 environment with more than hundred wireless routers and less than 10 users. A problem is that we haven't written specification in English, yet. :-) > The thing is that we don't need to do anything to allow people to do it the > "current way" (i.e. let the routing handle it, al la IPv4 MH) - in fact, I > doubt we could stop them, actually. We can't stop them use IPv4 with IPv4-style multihoming. :-) Masataka Ohta From owner-multi6@ops.ietf.org Tue Mar 18 16:30:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00850 for ; Tue, 18 Mar 2003 16:30:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vOgi-000Gfv-00 for multi6-data@psg.com; Tue, 18 Mar 2003 13:32:00 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18vOgf-000Gfj-00 for multi6@ops.ietf.org; Tue, 18 Mar 2003 13:31:57 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2ILUxM89608; Tue, 18 Mar 2003 22:30:59 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Tue, 18 Mar 2003 22:30:59 +0100 (CET) From: Iljitsch van Beijnum To: "J. Noel Chiappa" cc: Subject: Re: Again no multi6 at IETF#56 In-Reply-To: <200303182038.h2IKcgQ5021791@ginger.lcs.mit.edu> Message-ID: <20030318221059.J87639-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 Tue, 18 Mar 2003, J. Noel Chiappa wrote: > > We need apply the solution we have today with zero implementation. And > > I don't see any other alternative. six months from now we might have > > something better. Let's do that then. > The thing is that we don't need to do anything to allow people to do it the > "current way" (i.e. let the routing handle it, al la IPv4 MH) - in fact, I > doubt we could stop them, actually. > On the other hand, there's no need to put the IETF Gold Seal of Approval on > something we now won't scale in the long term. > Taken together, that all argues that we should press on and say nothing about > the interim IPv4-type thing. Well there is one way of multihoming that provides reasonable benefits without too many issues that can be deployed today: take address space from one ISP and announce it to two or more ISPs. As long as there is peering between these ISPs you're protected against all common failure modes. (Ok, not counting ISP going bankrupt as "common" here...) If ISPs filter the /48, there isn't much of an issue as long as the aggregate is still visible from ISP A and ISP A forwards the traffic to ISP B. The one thing that needs some consideration is filtering between ISPs: if ISP C filters packets it gets from ISP B with ISP A source addresses, all of this breaks. There are two ways around this: ISP C accepts the /48 (assuming they're doing uRPF) or they don't filter but trust ISP B to filter their customers. Now do this with two /48s from two ISPs and you can start experimenting with multiaddressing and have a safety net at the same time. Just one down side for the enterprise: this is PA space, so it is necessary to renumber when changing ISPs. Any reason why we shouldn't publish this with the IETF bronze seal of approval as a temporary best practice? About the first most important multihoming issue you ranted about in an earlier message: I don't think we are overlooking this (see my comments to Marcelo's draft, and my conversion to favoring transport layer solutions a few months ago). But: 1. This isn't all that controversial 2. Doing it wrong first and improve later doesn't create an impossible-to-clean-up-mess (like allowing /48s in the DFZ) Iljitsch From owner-multi6@ops.ietf.org Tue Mar 18 16:51:34 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01990 for ; Tue, 18 Mar 2003 16:51:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vP16-000Hkt-00 for multi6-data@psg.com; Tue, 18 Mar 2003 13:53:04 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 18vP12-000HkX-00 for multi6@ops.ietf.org; Tue, 18 Mar 2003 13:53:01 -0800 From: Masataka Ohta Message-Id: <200303182143.GAA01517@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id GAA01517; Wed, 19 Mar 2003 06:43:01 +0900 Subject: Re: Again no multi6 at IETF#56 In-Reply-To: <20030318221059.J87639-100000@sequoia.muada.com> from Iljitsch van Beijnum at "Mar 18, 2003 10:30:59 pm" To: Iljitsch van Beijnum Date: Wed, 19 Mar 2003 06:43:00 +0859 () CC: "J. Noel Chiappa" , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-0.7 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Iljitsch; > Well there is one way of multihoming that provides reasonable benefits > without too many issues that can be deployed today: take address space > from one ISP and announce it to two or more ISPs. As long as there is > peering between these ISPs you're protected against all common failure > modes. (Ok, not counting ISP going bankrupt as "common" here...) It does not protect a site from ISP failure including but not limited to bankrupcy. Moreover, routes to imported addresses can not be aggregated that it cause a scalability problems within ISPs. Masataka Ohta From owner-multi6@ops.ietf.org Tue Mar 18 17:11:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02783 for ; Tue, 18 Mar 2003 17:11:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vPJi-000IoD-00 for multi6-data@psg.com; Tue, 18 Mar 2003 14:12:18 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18vPJX-000Inq-00 for multi6@ops.ietf.org; Tue, 18 Mar 2003 14:12:08 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2IMB4F89679; Tue, 18 Mar 2003 23:11:04 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Tue, 18 Mar 2003 23:11:04 +0100 (CET) From: Iljitsch van Beijnum To: Masataka Ohta cc: "J. Noel Chiappa" , Subject: Re: Again no multi6 at IETF#56 In-Reply-To: <200303182143.GAA01517@necom830.hpcl.titech.ac.jp> Message-ID: <20030318230958.B87639-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, 19 Mar 2003, Masataka Ohta wrote: > It does not protect a site from ISP failure including but > not limited to bankrupcy. > Moreover, routes to imported addresses can not be aggregated that it > cause a scalability problems within ISPs. Both true but I don't think this technique is thereby disqualified. From owner-multi6@ops.ietf.org Tue Mar 18 17:45:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03479 for ; Tue, 18 Mar 2003 17:45:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vPqt-000KcT-00 for multi6-data@psg.com; Tue, 18 Mar 2003 14:46:35 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 18vPqq-000KcB-00 for multi6@ops.ietf.org; Tue, 18 Mar 2003 14:46:32 -0800 From: Masataka Ohta Message-Id: <200303182240.HAA01850@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id HAA01850; Wed, 19 Mar 2003 07:40:27 +0900 Subject: Re: Again no multi6 at IETF#56 In-Reply-To: <20030318230958.B87639-100000@sequoia.muada.com> from Iljitsch van Beijnum at "Mar 18, 2003 11:11:04 pm" To: Iljitsch van Beijnum Date: Wed, 19 Mar 2003 07:40:26 +0859 () CC: "J. Noel Chiappa" , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-0.7 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Iljitsch; > > It does not protect a site from ISP failure including but > > not limited to bankrupcy. > > > Moreover, routes to imported addresses can not be aggregated that it > > cause a scalability problems within ISPs. > > Both true but I don't think this technique is thereby disqualified. The former problem is already too bad for people expecting multihomed environment. Moreover, I'm afraid you underestimate the latter scalability problem. To move on, we must estimate the seriousness of lack of scalability and, if it is not so bad, develop proper address assignment policy, both of which take time, which disqualify your proposal. Masataka Ohta From owner-multi6@ops.ietf.org Tue Mar 18 18:10:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04923 for ; Tue, 18 Mar 2003 18:10:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vQFH-000MYu-00 for multi6-data@psg.com; Tue, 18 Mar 2003 15:11:47 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18vQFE-000MYe-00 for multi6@ops.ietf.org; Tue, 18 Mar 2003 15:11:44 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2INAiT89769; Wed, 19 Mar 2003 00:10:44 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Wed, 19 Mar 2003 00:10:44 +0100 (CET) From: Iljitsch van Beijnum To: Masataka Ohta cc: Subject: Re: Again no multi6 at IETF#56 In-Reply-To: <200303182240.HAA01850@necom830.hpcl.titech.ac.jp> Message-ID: <20030319000649.M87639-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, 19 Mar 2003, Masataka Ohta wrote: > The former problem is already too bad for people expecting multihomed > environment. It's still better than singlehoming. > Moreover, I'm afraid you underestimate the latter scalability problem. > To move on, we must estimate the seriousness of lack of scalability > and, if it is not so bad, develop proper address assignment policy, > both of which take time, which disqualify your proposal. It doesn't, as the evaluation can be performed while the solution is being used. As there is a built in "you have to renumber at some point" guarantee, whenever problems come up they can be fixed. But if you feel that geographic aggregation is superior to such a stop gap solution, I'm not going to argue. From owner-multi6@ops.ietf.org Tue Mar 18 18:55:25 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07111 for ; Tue, 18 Mar 2003 18:55:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vQwg-000OyN-00 for multi6-data@psg.com; Tue, 18 Mar 2003 15:56:38 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 18vQwc-000Oy6-00 for multi6@ops.ietf.org; Tue, 18 Mar 2003 15:56:34 -0800 From: Masataka Ohta Message-Id: <200303182344.IAA02426@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id IAA02426; Wed, 19 Mar 2003 08:43:47 +0859 Subject: Re: Again no multi6 at IETF#56 In-Reply-To: <20030319000649.M87639-100000@sequoia.muada.com> from Iljitsch van Beijnum at "Mar 19, 2003 00:10:44 am" To: Iljitsch van Beijnum Date: Wed, 19 Mar 2003 08:43:47 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-0.7 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Iljitsch; > > The former problem is already too bad for people expecting multihomed > > environment. > > It's still better than singlehoming. It is a variation of singlehoming. > > Moreover, I'm afraid you underestimate the latter scalability problem. > > > To move on, we must estimate the seriousness of lack of scalability > > and, if it is not so bad, develop proper address assignment policy, > > both of which take time, which disqualify your proposal. > > It doesn't, as the evaluation can be performed while the solution is > being used. As there is a built in "you have to renumber at some point" > guarantee, whenever problems come up they can be fixed. That kind of guarantee never works. > But if you feel that geographic aggregation is superior to such a stop > gap solution, I'm not going to argue. I see no point discussing on stop gap solutions. Masataka Ohta From owner-multi6@ops.ietf.org Tue Mar 18 19:58:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09824 for ; Tue, 18 Mar 2003 19:58:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vRvG-0001Xk-00 for multi6-data@psg.com; Tue, 18 Mar 2003 16:59:14 -0800 Received: from wl-142-224.wireless.ietf56.ietf.org ([130.129.142.224] helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18vRvD-0001XY-00 for multi6@ops.ietf.org; Tue, 18 Mar 2003 16:59:11 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2J10FKW007202; Wed, 19 Mar 2003 02:00:19 +0100 (CET) Date: Wed, 19 Mar 2003 01:40:16 +0100 Subject: Re: Again no multi6 at IETF#56 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Iljitsch van Beijnum , multi6@ops.ietf.org To: Masataka Ohta From: Kurt Erik Lindqvist In-Reply-To: <200303170959.SAA20532@necom830.hpcl.titech.ac.jp> Message-Id: <5ADB804A-59A3-11D7-B5E1-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) 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 >> I know the three policies fairly well. They are not similar but they >> are fairly consistent. > > How can you be sure they are consistent? What is the evaluation > criteria? This is starting to be off-topic and I think we should move this to a more appropriate list like LIR-WG for RIPE. I know the policies of the different regions fairly well. - kurtis - From owner-multi6@ops.ietf.org Tue Mar 18 21:01:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11833 for ; Tue, 18 Mar 2003 21:01:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vSuU-000494-00 for multi6-data@psg.com; Tue, 18 Mar 2003 18:02:30 -0800 Received: from wl-142-224.wireless.ietf56.ietf.org ([130.129.142.224] helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18vSuS-00048s-00 for multi6@ops.ietf.org; Tue, 18 Mar 2003 18:02:28 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2J23tKW007222 for ; Wed, 19 Mar 2003 03:03:56 +0100 (CET) Date: Wed, 19 Mar 2003 03:03:54 +0100 Mime-Version: 1.0 (Apple Message framework v551) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Start running From: Kurt Erik Lindqvist To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: <0998EAA8-59AF-11D7-B5E2-000393AB1404@kurtis.pp.se> X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-1.3 required=5.0 tests=SPAM_PHRASE_01_02,USER_AGENT_APPLEMAIL version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit All, A number of comments have been made on the list recently (well, over a long time) on what is needed to get this working group going. As the new and naive co-chair, I have discussed this with Sean. We have agreed that there are a number of steps we need to take to move forward and start producing results. To achive some of these will most likely require us to change at least parts of the charter, and definetly the milestones. The things that comes to mind are From a procedure perspective we need to have a clear problem statement document; we need to havve the requirements document updated; we need to agree on a road-map to a solution (but for now just agreeing on the outline should do it) and we need to evaluate what solutions are to be considered as working group documents. For the first steps we are looking for volunteers for the problem statement (I guess one of us could do it as well), for the requirements document I think that at least Joe would be willing to update it. For the road-map there is my document, and there have been some ideas from Christian (but I forget what mailiglist he posted it to). I would also like to see other proposals. As for solution documents, me and Sean would like to encourage people to sumbit drafts on solutions, protocols, etc. Our thoughts are to hold a WG meeting (I promise. I buy the beer if we don't) in Vienna to go through all the above documents, disucuss them, and agree which should be adopted as WG documents. Last, we will try and have a beer BOF tomorrow at 17.30-19.30. If you feel you want to give input on the way forward, discuss solutoins, or just make fun of me not knowing how my mail client work, see you in the bar! I will also be at the ipv6mh meeting tonight. Best regards, - kurtis - From owner-multi6@ops.ietf.org Tue Mar 18 21:13:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12079 for ; Tue, 18 Mar 2003 21:13:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vT76-0004jP-00 for multi6-data@psg.com; Tue, 18 Mar 2003 18:15:32 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 18vT73-0004j6-00 for multi6@ops.ietf.org; Tue, 18 Mar 2003 18:15:29 -0800 From: Masataka Ohta Message-Id: <200303190209.LAA03498@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id LAA03498; Wed, 19 Mar 2003 11:09:24 +0900 Subject: Start looping In-Reply-To: <0998EAA8-59AF-11D7-B5E2-000393AB1404@kurtis.pp.se> from Kurt Erik Lindqvist at "Mar 19, 2003 03:03:54 am" To: Kurt Erik Lindqvist Date: Wed, 19 Mar 2003 11:09:23 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-0.7 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Kurt; > From a procedure perspective we need to have a clear problem > statement document; we need to havve the requirements document > updated; we need to agree on a road-map to a solution (but for now > just agreeing on the outline should do it) and we need to evaluate > what solutions are to be considered as working group documents. From owner-multi6@ops.ietf.org Tue Mar 18 21:22:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12307 for ; Tue, 18 Mar 2003 21:22:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vTFb-00058S-00 for multi6-data@psg.com; Tue, 18 Mar 2003 18:24:19 -0800 Received: from wl-142-224.wireless.ietf56.ietf.org ([130.129.142.224] helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18vTFU-000584-00 for multi6@ops.ietf.org; Tue, 18 Mar 2003 18:24:12 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2J2PYKW007474; Wed, 19 Mar 2003 03:25:35 +0100 (CET) Date: Wed, 19 Mar 2003 03:25:33 +0100 Subject: Re: Start looping Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: multi6@ops.ietf.org To: Masataka Ohta From: Kurt Erik Lindqvist In-Reply-To: <200303190209.LAA03498@necom830.hpcl.titech.ac.jp> Message-Id: <0FDC9A8A-59B2-11D7-B5E2-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) 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 >> Masataka, >> From a procedure perspective we need to have a clear problem >> statement document; we need to havve the requirements document >> updated; we need to agree on a road-map to a solution (but for now >> just agreeing on the outline should do it) and we need to evaluate >> what solutions are to be considered as working group documents. >> care to elaborate? - kurtis - From owner-multi6@ops.ietf.org Tue Mar 18 21:42:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12827 for ; Tue, 18 Mar 2003 21:42:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vTYn-00060U-00 for multi6-data@psg.com; Tue, 18 Mar 2003 18:44:09 -0800 Received: from buffoon.automagic.org ([208.185.30.208]) by psg.com with smtp (Exim 3.36 #1) id 18vTYh-0005zi-00 for multi6@ops.ietf.org; Tue, 18 Mar 2003 18:44:03 -0800 Received: (qmail 7258 invoked by uid 0); 19 Mar 2003 02:44:01 -0000 Received: from localhost.automagic.org (HELO isc.org) (root@127.0.0.1) by localhost.automagic.org with SMTP; 19 Mar 2003 02:44:01 -0000 Date: Tue, 18 Mar 2003 18:44:19 -0800 Subject: Re: Start running Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: multi6@ops.ietf.org To: Kurt Erik Lindqvist From: Joe Abley In-Reply-To: <0998EAA8-59AF-11D7-B5E2-000393AB1404@kurtis.pp.se> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) 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, Mar 18, 2003, at 18:03 US/Pacific, Kurt Erik Lindqvist wrote: > For the first steps we are looking for volunteers for the problem > statement (I guess one of us could do it as well), for the > requirements document I think that at least Joe would be willing to > update it. I am willing. Joe From owner-multi6@ops.ietf.org Tue Mar 18 22:16:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13722 for ; Tue, 18 Mar 2003 22:16:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vU4Q-0007Lo-00 for multi6-data@psg.com; Tue, 18 Mar 2003 19:16:50 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 18vU4N-0007Lc-00 for multi6@ops.ietf.org; Tue, 18 Mar 2003 19:16:48 -0800 From: Masataka Ohta Message-Id: <200303190256.LAA03899@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id LAA03899; Wed, 19 Mar 2003 11:56:32 +0900 Subject: Re: Again no multi6 at IETF#56 In-Reply-To: <5ADB804A-59A3-11D7-B5E1-000393AB1404@kurtis.pp.se> from Kurt Erik Lindqvist at "Mar 19, 2003 01:40:16 am" To: Kurt Erik Lindqvist Date: Wed, 19 Mar 2003 11:56:31 +0859 () CC: Iljitsch van Beijnum , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-1.0 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Kurt; > >> I know the three policies fairly well. They are not similar but they > >> are fairly consistent. > > > > How can you be sure they are consistent? What is the evaluation > > criteria? > I know the policies of the different regions fairly well. But, you don't know how to compare them. > This is starting to be off-topic and I think we should move this to a > more appropriate list like LIR-WG for RIPE. No. For the comparison, you need technical requirement to be discussed here. Masataka Ohta From owner-multi6@ops.ietf.org Tue Mar 18 23:15:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14816 for ; Tue, 18 Mar 2003 23:15:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vV0M-0009rW-00 for multi6-data@psg.com; Tue, 18 Mar 2003 20:16:42 -0800 Received: from wl-142-224.wireless.ietf56.ietf.org ([130.129.142.224] helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18vV0K-0009rJ-00 for multi6@ops.ietf.org; Tue, 18 Mar 2003 20:16:40 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2J4I0KW007551; Wed, 19 Mar 2003 05:18:01 +0100 (CET) Date: Wed, 19 Mar 2003 05:17:59 +0100 Subject: Re: Start running Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: multi6@ops.ietf.org To: Kurt Erik Lindqvist From: Kurt Erik Lindqvist In-Reply-To: <0998EAA8-59AF-11D7-B5E2-000393AB1404@kurtis.pp.se> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-1.4 required=5.0 tests=FROM_AND_TO_SAME_2,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 > Last, we will try and have a beer BOF tomorrow at 17.30-19.30. If you > feel you want to give input on the way forward, discuss solutoins, or > It was pointed out that this is during the dinner break. For those of you who do not know me - I (and I guess Sean) will most likely be at the bar after the IESG session as well. - kurtis - From owner-multi6@ops.ietf.org Tue Mar 18 23:53:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15890 for ; Tue, 18 Mar 2003 23:53:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vVbQ-000BbC-00 for multi6-data@psg.com; Tue, 18 Mar 2003 20:55:00 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 18vVbN-000BZz-00 for multi6@ops.ietf.org; Tue, 18 Mar 2003 20:54:57 -0800 From: Masataka Ohta Message-Id: <200303190450.NAA04885@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id NAA04885; Wed, 19 Mar 2003 13:50:21 +0900 Subject: Re: Start running In-Reply-To: from Kurt Erik Lindqvist at "Mar 19, 2003 05:17:59 am" To: Kurt Erik Lindqvist Date: Wed, 19 Mar 2003 13:50:20 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-0.7 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.43 Sender: owner-multi6@ops.ietf.org Precedence: bulk Kurt; > > Last, we will try and have a beer BOF tomorrow at 17.30-19.30. If you > > feel you want to give input on the way forward, discuss solutoins, or > It was pointed out that this is during the dinner break. For those of > you who do not know me - I (and I guess Sean) will most likely be at > the bar after the IESG session as well. As I'm returning to Japan tonight (as scheduled long before), I just leave a comment. Instead of wasting time on a requirement draft again, how about having several design teams to work on their own proposals and let them apeal to the WG? Each team can have their own requirements. Note that it is an approach used to develop IPv6. Masataka Ohta From owner-multi6@ops.ietf.org Wed Mar 19 00:16:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16368 for ; Wed, 19 Mar 2003 00:16:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vVxf-000CZo-00 for multi6-data@psg.com; Tue, 18 Mar 2003 21:17:59 -0800 Received: from wl-142-224.wireless.ietf56.ietf.org ([130.129.142.224] helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18vVxd-000CZA-00 for multi6@ops.ietf.org; Tue, 18 Mar 2003 21:17:57 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2J5JGKW007684; Wed, 19 Mar 2003 06:19:18 +0100 (CET) Date: Wed, 19 Mar 2003 06:19:16 +0100 Subject: Re: Start running Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: multi6@ops.ietf.org To: Masataka Ohta From: Kurt Erik Lindqvist In-Reply-To: <200303190450.NAA04885@necom830.hpcl.titech.ac.jp> Message-Id: <5445FF34-59CA-11D7-B5E2-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.9 required=5.0 tests=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 >>> Last, we will try and have a beer BOF tomorrow at 17.30-19.30. If you >>> feel you want to give input on the way forward, discuss solutoins, or > >> It was pointed out that this is during the dinner break. For those of >> you who do not know me - I (and I guess Sean) will most likely be at >> the bar after the IESG session as well. > > As I'm returning to Japan tonight (as scheduled long before), > I just leave a comment. > > Instead of wasting time on a requirement draft again, how about > having several design teams to work on their own proposals > and let them apeal to the WG? Each team can have their own > requirements. > That is part of what I tried to say. So I agree :-) I do want us to get solutions that can be discussed! Send text! :) The idea is that we discuss and evaluate the solutions in Vienna. - kurtis - From owner-multi6@ops.ietf.org Wed Mar 19 01:13:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17831 for ; Wed, 19 Mar 2003 01:13:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vWqg-000Enn-00 for multi6-data@psg.com; Tue, 18 Mar 2003 22:14:50 -0800 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by psg.com with esmtp (Exim 3.36 #1) id 18vWqd-000Enb-00 for multi6@ops.ietf.org; Tue, 18 Mar 2003 22:14: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 WAA03305; Tue, 18 Mar 2003 22:14:45 -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 h2J6EgP07973; Wed, 19 Mar 2003 07:14:42 +0100 (MET) Date: Wed, 19 Mar 2003 07:10:42 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Identifier/locator recap To: Tony Li Cc: Iljitsch van Beijnum , "Bound, Jim" , multi6@ops.ietf.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII 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 > At this point, I'm quite happy not to sweat the 8+8/GSE/16+16 > distinction. If we can get to consensus that we need separation > of locators and identifiers, then we will have made good progress. > Let's agree on the macro before we work out the micro. To me this is a no brainer because I can't see how there can exist a scalable approach to multihoming that doesn't separate identifiers and locators. At some level one could argue that host multi-addressing is scalable (at the expense of moving complexity to the hosts and applications).but my concern is that host multi-addressing will more or less have the hosts track with source/destination combinations (which approximate routing paths at some rough level) work vs. doesn't. To get fast failover this essentially turns into doing end-to-end "hello" traffic instead of relying on the local hello traffic performed by the routing protocols. So I think there are severe limitations in making this scale. (And trying to aggregate this end-to-end "hello" traffic will just cause a reinvention of routing.) From the email traffic I'm guessing there is a significant fraction of the folks on this list that think that identifier/locator separation is necessary for the long-term solution. There seems to be more disagreement about possible shorter term steps. But I could be misreading things... Erik From owner-multi6@ops.ietf.org Wed Mar 19 02:46:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15361 for ; Wed, 19 Mar 2003 02:46:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vYH8-000IgB-00 for multi6-data@psg.com; Tue, 18 Mar 2003 23:46:14 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18vYH2-000Ify-00 for multi6@ops.ietf.org; Tue, 18 Mar 2003 23:46:08 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2J7j9t90858; Wed, 19 Mar 2003 08:45:09 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Wed, 19 Mar 2003 08:45:09 +0100 (CET) From: Iljitsch van Beijnum To: Erik Nordmark cc: Subject: RE: Identifier/locator recap In-Reply-To: Message-ID: <20030319082806.J87639-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, 19 Mar 2003, Erik Nordmark wrote: > At some level one could argue that host multi-addressing is scalable > (at the expense of moving complexity to the hosts and applications).but > my concern is that host multi-addressing will more or less have > the hosts track with source/destination combinations (which approximate > routing paths at some rough level) work vs. doesn't. > To get fast failover this essentially turns into doing end-to-end "hello" > traffic instead of relying on the local hello traffic performed by the routing > protocols. So I think there are severe limitations in making this scale. There is one big fat advantage to having this in the hosts: those already track the end-to-end status of sessions. Doing it in middleboxes is more complex, but it should be doable without spending too much bandwidth on reachability tests: a middlebox typically communicates with many other middleboxes (or hosts) and many of these sessions share a significant amount of infrastructure. So rather than do a reachability check for each session every 90 seconds (yes, this is very long but it's the same as the BGP hold time listed in RFC 1771 and Cisco even uses 180 seconds by default) the middlebox can simply do a reachability check for say 1/300th of all sessions each second. That means each sessions will be checked every 5 minutes. But as checks start to fail, their number is increased, starting with ones that fall inside the same 32. The effect is that the closer the failure is to the middlebox, the faster it will be detected. Only when the path between two middleboxes shares no infrastructure with other paths, and this non-shared infrastructure fails, it may be necessary to wait the full 300 seconds. Iljitsch From owner-multi6@ops.ietf.org Wed Mar 19 13:01:40 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28225 for ; Wed, 19 Mar 2003 13:01:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vhsy-0000aP-00 for multi6-data@psg.com; Wed, 19 Mar 2003 10:01:56 -0800 Received: from dmz1.procket.com ([65.174.124.36]) by psg.com with esmtp (Exim 3.36 #1) id 18vhsn-0000Z1-00 for multi6@psg.com; Wed, 19 Mar 2003 10:01:45 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 8670C23C62 for ; Wed, 19 Mar 2003 10:25:15 -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 h2JI1iYB007485 for ; Wed, 19 Mar 2003 10:01: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="us-ascii" Subject: FW: Mail delivery failed: returning message to sender Date: Wed, 19 Mar 2003 10:01:44 -0800 Message-ID: Thread-Topic: Mail delivery failed: returning message to sender Thread-Index: AcLuQOBONLNqhxmqSL2BQ76S9A57RQAAJAQA From: "Tony Li" To: X-Spam-Status: No, hits=0.7 required=5.0 tests=OUTLOOK_FW_MSG,SPAM_PHRASE_00_01 version=2.44 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA28225 Retransmitting due to mail bounce... apologies if it's a duplicate. | Erik, | | | To me this is a no brainer because I can't see how there | | can exist a scalable approach to multihoming that doesn't | | separate identifiers and locators. | | | Excellent, welcome to the club. | | =20 | | At some level one could argue that host multi-addressing=20 | | is scalable | | (at the expense of moving complexity to the hosts and=20 | | applications).but | | my concern is that host multi-addressing will more or | less have | | the hosts track with source/destination combinations=20 | | (which approximate | | routing paths at some rough level) work vs. doesn't. | | | Yes, that's going to happen. | | | | To get fast failover this essentially turns into doing=20 | | end-to-end "hello" | | traffic instead of relying on the local hello traffic=20 | | performed by the routing | | protocols. So I think there are severe limitations in=20 | | making this scale. | | (And trying to aggregate this end-to-end "hello" | traffic will just | | cause a reinvention of routing.) | | | As Iljitsch seemed to hint at, there is no need to add protocol to | do this. For example, a TCP implementation can simply watch the | RTT, compare it to the sRTT and consider switching locators anytime | it needs to retransmit. | | I don't know of a requirement that asks us to react faster | than that | timeframe, just that we not drop TCP connections. So why not use | what's there? | | Tony | From owner-multi6@ops.ietf.org Wed Mar 19 13:01:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28240 for ; Wed, 19 Mar 2003 13:01:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vhne-00009y-00 for multi6-data@psg.com; Wed, 19 Mar 2003 09:56:26 -0800 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #1) id 18vhna-00009V-00 for multi6@ops.ietf.org; Wed, 19 Mar 2003 09:56:23 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id B9C8C34464; Wed, 19 Mar 2003 09:06:41 -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 h2JHraYB007118; Wed, 19 Mar 2003 09:53:37 -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="us-ascii" Subject: RE: Identifier/locator recap Date: Wed, 19 Mar 2003 09:53:36 -0800 Message-ID: Thread-Topic: Identifier/locator recap Thread-Index: AcLt3uCIExwE6W4wSzSkjOZPDinfGAAYK80A From: "Tony Li" To: "Erik Nordmark" Cc: "Iljitsch van Beijnum" , "Bound, Jim" , Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA28240 Erik, | To me this is a no brainer because I can't see how there | can exist a scalable approach to multihoming that doesn't | separate identifiers and locators. Excellent, welcome to the club. | At some level one could argue that host multi-addressing | is scalable | (at the expense of moving complexity to the hosts and | applications).but | my concern is that host multi-addressing will more or less have | the hosts track with source/destination combinations | (which approximate | routing paths at some rough level) work vs. doesn't. Yes, that's going to happen. | To get fast failover this essentially turns into doing | end-to-end "hello" | traffic instead of relying on the local hello traffic | performed by the routing | protocols. So I think there are severe limitations in | making this scale. | (And trying to aggregate this end-to-end "hello" traffic will just | cause a reinvention of routing.) As Iljitsch seemed to hint at, there is no need to add protocol to do this. For example, a TCP implementation can simply watch the RTT, compare it to the sRTT and consider switching locators anytime it needs to retransmit. I don't know of a requirement that asks us to react faster than that timeframe, just that we not drop TCP connections. So why not use what's there? Tony From owner-multi6@ops.ietf.org Wed Mar 19 13:01:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28258 for ; Wed, 19 Mar 2003 13:01:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vhoI-0000E4-00 for multi6-data@psg.com; Wed, 19 Mar 2003 09:57:06 -0800 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #1) id 18vhoD-0000DU-00 for multi6@ops.ietf.org; Wed, 19 Mar 2003 09:57:01 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 87C8F34466; Wed, 19 Mar 2003 09:10:05 -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 h2JHv1YB007207; Wed, 19 Mar 2003 09:57:01 -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="us-ascii" Subject: RE: Reducing Peerings for MH Routing within a site via end systems Date: Wed, 19 Mar 2003 09:57:00 -0800 Message-ID: Thread-Topic: Reducing Peerings for MH Routing within a site via end systems Thread-Index: AcLtDvKUA7nwY7xrQDCxjsDp2cHiyQBMZnEA From: "Tony Li" To: "Masataka Ohta" Cc: "Bound, Jim" , X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_02_03 version=2.44 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA28258 Ohta-san, | > I think that a host should be able to change the set of locators | > that make it reachable at will. The rate that the system can | > disseminate these changes is still TBD, but there obviously | > needs to be an upper bound (no pun intended ;-). | | You don't have to determine it. Cache period of DNS, for | example, is | configurable. Yes, but the cache time is an upper bound on the validity of the entries. What I'm suggesting is that there needs to be some reasonable constraints on the MINIMUM cache period that you can specify. Currently I believe that's 1s. Seems a tad fast. Tony From owner-multi6@ops.ietf.org Wed Mar 19 13:08:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28438 for ; Wed, 19 Mar 2003 13:08:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vi1B-0001Jm-00 for multi6-data@psg.com; Wed, 19 Mar 2003 10:10:25 -0800 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #1) id 18vi17-0001JX-00 for multi6@ops.ietf.org; Wed, 19 Mar 2003 10:10:21 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 552B834465; Wed, 19 Mar 2003 08:58:16 -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 h2JHj6YB006675; Wed, 19 Mar 2003 09:45: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="us-ascii" Subject: RE: Start running Date: Wed, 19 Mar 2003 09:45:06 -0800 Message-ID: Thread-Topic: Start running Thread-Index: AcLt1QI79mlBA1T/TJWzJHInE7NieQAaZv/A From: "Tony Li" To: "Masataka Ohta" , "Kurt Erik Lindqvist" Cc: X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.44 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA28438 And look what a wonderful result that was! I'd seriously like to suggest that we NOT run down the proposal path. Again, all that does is lock people in on their personal approach. Folks dig in their heels and it comes to bloodshed. I would rather that we take the approach that this is a collaborative effort and address the issues and resolve them. Start with a top level architecture and work down. Yes, this is harder on the chairs, but it needs to be done this way to ensure closure without bloodshed. Tony | -----Original Message----- | From: Masataka Ohta [mailto:mohta@necom830.hpcl.titech.ac.jp] | Sent: Tuesday, March 18, 2003 8:51 PM | To: Kurt Erik Lindqvist | Cc: multi6@ops.ietf.org | Subject: Re: Start running | | | Kurt; | | > > Last, we will try and have a beer BOF tomorrow at | 17.30-19.30. If you | > > feel you want to give input on the way forward, | discuss solutoins, or | | > It was pointed out that this is during the dinner break. | For those of | > you who do not know me - I (and I guess Sean) will most | likely be at | > the bar after the IESG session as well. | | As I'm returning to Japan tonight (as scheduled long before), | I just leave a comment. | | Instead of wasting time on a requirement draft again, how about | having several design teams to work on their own proposals | and let them apeal to the WG? Each team can have their own | requirements. | | Note that it is an approach used to develop IPv6. | | Masataka Ohta | | From owner-multi6@ops.ietf.org Wed Mar 19 13:18:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28950 for ; Wed, 19 Mar 2003 13:18:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18viAl-0002J6-00 for multi6-data@psg.com; Wed, 19 Mar 2003 10:20:19 -0800 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #1) id 18viAf-0002Hu-00 for multi6@ops.ietf.org; Wed, 19 Mar 2003 10:20:13 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 0759134464; Wed, 19 Mar 2003 09:33:15 -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 h2JIKBYB008149; Wed, 19 Mar 2003 10:20:11 -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="us-ascii" Subject: RE: Routing Date: Wed, 19 Mar 2003 10:20:11 -0800 Message-ID: Thread-Topic: Routing Thread-Index: AcLsSo3t+L5GVeaNQnSAQp9sWnIdsgAEiz6AAA2cnCAAbDC9wA== From: "Tony Li" To: "Bound, Jim" , X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.44 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA28950 Catching up on old mail... | > However, static routing to key locations locks you into | those static | paths, | > which maythen fail. What now? | | My assumption is those locations are minimal. Forward to | them is fast | lookup and high order bits. Failover is not a function IMO of any | protocol but implementation. But the protocol should have features | within it to permit failover. A few locations implies that they are high bandwidth because they are interconnects. I'm very hopeful that we don't need a separate protocol to implement failover. Tony From owner-multi6@ops.ietf.org Wed Mar 19 14:06:18 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01246 for ; Wed, 19 Mar 2003 14:06:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vitd-0006WT-00 for multi6-data@psg.com; Wed, 19 Mar 2003 11:06:41 -0800 Received: from wl-142-224.wireless.ietf56.ietf.org ([130.129.142.224] helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18vitX-0006Vy-00 for multi6@ops.ietf.org; Wed, 19 Mar 2003 11:06:35 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2JJ7rKW007785 for ; Wed, 19 Mar 2003 20:07:59 +0100 (CET) Date: Wed, 19 Mar 2003 20:07:22 +0100 Subject: Requirements document [was Re: Again no multi6 at IETF#56] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Kurt Erik Lindqvist To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <038848D8-5A3E-11D7-B5E2-000393AB1404@kurtis.pp.se> X-Mailer: Apple Mail (2.551) 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.44 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> Quote from the one and only document in this WG: >> >>> 3.2.1 Scalability >>> [snip] >>> A new IPv6 multihoming architecture MUST scale to >>> accommodate orders of magnitude more multihomed >>> sites without imposing unreasonable requirements >>> on the routing system. >> >> As chair, you simply can not recommend to go a way that blatantly >> violates the only working document we have. This text is clear, and >> it's >> a "MUST" not a "must" which has a very specific meaning as per RFC >> 2119. > > To be pedantic, the requirements doc doesn't specify the starting > point: orders of magnitude more multihomed sites than exist today on > the v6 network is still easily achievable using > draft-kurtis-call-me-when-we-get-1000-routes-in-the-dfz-00. > That is true, But it does bring up the issue of the status of the requirements document. From what I know it has been ready to be shipped to the IESG for last-call for quite some time. Some people have privately expressed to me that they see little point in moving this forward. I want to disagree, as I do think that this documents provides a good base-line and a tool for us as chairs to keep people focused on what we need to achieve. That said, I do not think that "requirements" are the right word as we will have different requirements at different times (and I know that people disagrees to this statement). I have discussed this with Joe and if I have understood him correctly he is for updating the document to better reflect this as considerations for potential multihoming solutions. I suggest that we hold off discussions on this until we have a updated document and then see where to take it from there. ...and yes, I do realize that this creates problems with the charter and the milestones, but that is the least of my worries at the moment :-). We need to fix that anyway. - kurtis - From owner-multi6@ops.ietf.org Wed Mar 19 14:07:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01359 for ; Wed, 19 Mar 2003 14:07:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18viwl-0006iZ-00 for multi6-data@psg.com; Wed, 19 Mar 2003 11:09:55 -0800 Received: from teldanex.hiit.fi ([212.68.5.99] helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 3.36 #1) id 18viwk-0006iK-00 for multi6@ops.ietf.org; Wed, 19 Mar 2003 11:09:54 -0800 Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 57F5F1C; Wed, 19 Mar 2003 17:11:07 +0200 (EET) Message-ID: <3E78863B.9060902@nomadiclab.com> Date: Wed, 19 Mar 2003 07:01:15 -0800 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030310 X-Accept-Language: en-us, en MIME-Version: 1.0 To: multi6@ops.ietf.org Cc: Erik Nordmark Subject: Identifier/locator recap and hop-by-hop vs. source routing 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.44 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > But my concern is that host multi-addressing will more or less have > the hosts track with source/destination combinations (which > approximate routing paths at some rough level) work vs. doesn't. To > get fast failover this essentially turns into doing end-to-end > "hello" traffic instead of relying on the local hello traffic > performed by the routing protocols. So I think there are severe > limitations in making this scale. ... Erik's comment above let me back to an observation that I made some time ago, but which I failed to write up before this. It looks like that if we go for the locator/identifier separation and multi-addressing, we go for an architecture where we combine today's hop-by-hop routing with some limited source routing. The routers continue to do hop-by-hop routing on addresses, just as today. However, either the hosts or some middleboxes start doing what is effectively some kind of limited source routing: based on the identifier they select the best destination/source address pair from a number of possibilities. In that way they affect the route that the packet takes, i.e., perform source routing. To perform high quality source routing there should be some idea of the topology. That idea does not need to be detailed; often simple RTT estimates might be enough. But something is needed. I think Christian's slides contained a fairly good summary of this. I don't know if this observation is of any value. I just wanted to post it in the case that it might help people in their thinking. --Pekka Nikander From owner-multi6@ops.ietf.org Wed Mar 19 16:04:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08055 for ; Wed, 19 Mar 2003 16:04:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vkjZ-000F2D-00 for multi6-data@psg.com; Wed, 19 Mar 2003 13:04:25 -0800 Received: from smtp01.uc3m.es ([163.117.136.121] helo=smtp.uc3m.es) by psg.com with esmtp (Exim 3.36 #1) id 18vkjQ-000Ezj-00 for multi6@ops.ietf.org; Wed, 19 Mar 2003 13:04:17 -0800 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 9FADF431CD; Wed, 19 Mar 2003 22:04:12 +0100 (CET) Received: from [163.117.252.56] (unknown [163.117.252.56]) by smtp01.uc3m.es (Postfix) with ESMTP id 0CE9799E6E; Wed, 19 Mar 2003 22:04:05 +0100 (CET) Subject: Re: comments on mipv6 application to multihoming [Re: Move forward] From: marcelo bagnulo To: Pekka Savola Cc: Iljitsch van Beijnum , multi6@ops.ietf.org In-Reply-To: References: Content-Type: text/plain Organization: uc3m Message-Id: <1048107706.762.131.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 19 Mar 2003 22:03:59 +0100 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.1 required=5.0 tests=IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_01_02 version=2.44 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 2003-03-18 at 01:58, Pekka Savola wrote: > On 16 Mar 2003, marcelo bagnulo wrote: > > > ==> The problem is that this mechanism only "works" (for some definition of > > > works) > > > > Preserves established sessions perhaps? > > Yes -- with certain tradeoffs: to preserve established sessions, you > *typically* have to react quickly, and of course the sessions should be > preservable for the duration of the failure, but that's not as hard a > requirement to me (ie. if you get a warning that connections have failed, > using backups whic will help you for the next 5 minutes, shut them down > gracefully if the break is expected to last longer). > I like this approach. However, i would really prefer that connections could survive longer. > > > > for sessions that are broken over 140 seconds > > > > This is an upper bound. I mean it can be reduced but it can not be > > increased. In order to reduce it all that it is needed is to increase > > the frequency of HoTI CoTI message exchange. This would indeed increase > > the overhead, and cost benefit analysis should be performed in order to > > obtain an optimal choice. What it can not be done is to have a longer > > detection period. But if i understand correctly you do not have a > > problem with this. > > > > Mechanism that provide a faster response to failures have to be included > > once that other problems have been solved (like the next one) > > Yes, definitely the reaction time would have to be shorter. However, I'm > not sure if the HOTI/COTI exchange is the right mechanism for that: I'm > not sure whether it scales down properly. (It was never meant as a > heartbeat mechanism.) > I was, however designed to prevent DoS attacks, imposing minimal workload to CN. No state nor crypto is needed to generate HoT or CoT messages. I would say it is ok... > > > (ie. connection is not > > > aborted before that), with the upper bound of 420 seconds. > > > > This is the real problem IMO.The alternative address can only be used > > for a limited period (420 secs). Then you have to > > perform the RR procedure again to obtain new valid authorization data > > that is to be used for extending the lifetime of the new address. THis > > is a major problem since you can not perform the RR procedure because > > the HoA is no longer available. The solution for this would be to extend > > the lifetime of the binding but this may have security implications. you > > have previously worked in MIPv6 security, right? could you comment about > > the security concerns of extending this timer? > > Due to the RR procedure, it doesn't protect you from on-the-link or > on-the-path attackers. Attackers which *have been* on the link or on the > path can wreak havoc to up to MAX_RR_BINDING_LIFETIME (420 s) after > leaving the link or the path. > > Cranking it up significantly would certainly have implications but slight > modifications probably not so much (e.g. if your friendly router > implementation rebooting takes 430 seconds, the lifetime could very well > be 600 seconds). The order of magnitude matters. > > .. but there may be something I'm missing. > Again, i think that the solution would be much more valuable if connections could survive much longer. I have a proposal to extend MAX_RR_BINDING_LIFETIME, but it is a bit long to include it in here. If you would like to consider it, i can send it to you. (i would appreciate it very much) > > > On top of that, > > > quite a bit of signalling is performed just in case that a link might go > > > down. > > > > e2e failure detection implies traffic exchange. It is important to > > discuss whether this overhead is acceptable or not. > > Indeed -- some mechanism do this always, some just after the fact (when > suspecting some error has occurred, e.g. TCP acks get delayed), some both. > > > > Btw, how does a node know the > > > prefix length of his site? Not an easy problem, unless it's guessing.. > > > > > > > Good point!!! > > An option is to consider that it is always a /48, but i don't thik this > > is a good approach. > > Another possibility is to assign the site exit routers anycast address > > of every subnet to the corresponding exit router and propagate it within > > the site as a host route. So hosts will address packets to its own > > subnet exit site router anycast address, which will be routed to the > > correspondent exit router. > > Since the explanation is not so clear i will put an example > > > > > > > > +----+ +----+ > > |R1 | |R2 | > > |P1::| |P2::| > > +----+ +----+ > > P1:Subnet1:Router1 | P2:Subnet2:Router2 | > > ------------------------------------- > > P1:Subnet1:Router3 | > > P2:Subnet2:Router3 | > > +----+ > > |R3 | > > +----+ > > P1:Subnet3:Router3 | > > P2:Subnet4:Router3 | > > ----------------------------------- > > P1:Subnet3:Host | > > P2:Subnet4:Host | > > +----+ > > |Host| > > +----+ > > So Addresses P1:Subnet1:FFFF:FFFF:FFFF:FFFF and > > P1:Subnet3:FFFF:FFFF:FFFF:FFFF are assigned to R1. > > P1:Subnet3:FFFF:FFFF:FFFF:FFFF is announced within the site as a host > > route to R1 > > Addresses P2:Subnet2:FFFF:FFFF:FFFF:FFFF and > > P2:Subnet4:FFFF:FFFF:FFFF:FFFF are assigned to R2. > > P2:Subnet4:FFFF:FFFF:FFFF:FFFF is announced within the site as a host > > route to R2 > > So when Host sends a packet whose source address contains the prefix P1, > > it includes a routing header with P1:Subnet3:FFFF:FFFF:FFFF:FFFF which > > is deduced from its own prefix. > > > > Not very nice, but i guess this would work, don't you? > > Doesn't work -- the host will detect that the prefix is on-link, and will > try to reach it by sending neighbor solicitation to it. The access router > would have to perform proxy-ND for it. Good point (again) I am running out of solutions here :-) I can think of the following options for this, but i am not sure i like anyone of them. First option: (i think this would be the most elegant, but i think its time has passed) use a site local anycast address So you can compose the site exit router anycast address by appending the prefix assigned to the link to the site local prefix. I like this, but the problem is that there may be no more site locals for connected sites. I guess i should wait and see the outcome of the site local debate. Second option: use the above configuration and configure R3 as a ND proxy. I do not like this much because it imposes additional configuration in all the routers (it is better than configuring all the hosts, though) Third option: (nasty hack) use the above configuration but change the site exit router anycast format by changing the less significant bit of the directly attached subnet. This would make that the anycast address is not on-link, so that it has to be routed through a router. Opinions? Regards, marcelo -- marcelo bagnulo uc3m From owner-multi6@ops.ietf.org Wed Mar 19 17:46:32 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13065 for ; Wed, 19 Mar 2003 17:46:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vmKz-000M6A-00 for multi6-data@psg.com; Wed, 19 Mar 2003 14:47:09 -0800 Received: from gnat.inet.org ([63.108.254.91]) by psg.com with esmtp (Exim 3.36 #1) id 18vmKx-000M5n-00 for multi6@ops.ietf.org; Wed, 19 Mar 2003 14:47:07 -0800 Received: from extremenetworks.com (unknown [10.255.51.14]) by gnat.inet.org (Postfix) with ESMTP id C324867104 for ; Wed, 19 Mar 2003 18:04:22 -0500 (EST) Date: Wed, 19 Mar 2003 11:57:12 -0500 Subject: Re: Identifier/locator recap Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: RJ Atkinson To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit In-Reply-To: <20030319082806.J87639-100000@sequoia.muada.com> Message-Id: X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-1.5 required=5.0 tests=DATE_IN_PAST_03_06,IN_REP_TO,SPAM_PHRASE_00_01, USER_AGENT_APPLEMAIL version=2.44 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I concur with Erik Nordmark's analysis of things. On Wednesday, Mar 19, 2003, at 02:45 America/Montreal, Iljitsch van Beijnum wrote: > Doing it in middleboxes is more complex,... Middleboxes break the end-to-end principle and are generally not desirable architecturally. Since we have at least one architectural approach (i.e. identifier/locator separation) that does not need/use any middleboxes, please let us all agree that middlebox approaches are not desirable here -- and not discuss them at any further length in this WG. IMHO, Ran rja@extremenetworks.com From owner-multi6@ops.ietf.org Wed Mar 19 18:13:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14815 for ; Wed, 19 Mar 2003 18:13:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vmlo-000NA9-00 for multi6-data@psg.com; Wed, 19 Mar 2003 15:14:52 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18vmlm-000N9t-00 for multi6@ops.ietf.org; Wed, 19 Mar 2003 15:14:50 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2JNDn492249; Thu, 20 Mar 2003 00:13:50 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Thu, 20 Mar 2003 00:13:49 +0100 (CET) From: Iljitsch van Beijnum To: RJ Atkinson cc: Subject: Re: Identifier/locator recap In-Reply-To: Message-ID: <20030320000846.M87639-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.44 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 19 Mar 2003, RJ Atkinson wrote: > Middleboxes break the end-to-end principle and are generally not > desirable architecturally. > Since we have at least one architectural approach (i.e. > identifier/locator separation) that does not need/use any > middleboxes, please let us all agree > that middlebox approaches are not desirable here -- and not discuss them > at any further length in this WG. I agree middleboxes aren't desirable. On the other hand, I doubt very many people will applaud a clean architecture if that means they have to upgrade large numbers of individual hosts rather than a few middleboxes. And it's not just deployment; implementing policies on individual hosts is much harder than doing it on middleboxes or border routers. Iljitsch From owner-multi6@ops.ietf.org Wed Mar 19 18:42:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16270 for ; Wed, 19 Mar 2003 18:42:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vnEW-000OW6-00 for multi6-data@psg.com; Wed, 19 Mar 2003 15:44:32 -0800 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #1) id 18vnEK-000OVc-00 for multi6@ops.ietf.org; Wed, 19 Mar 2003 15:44:20 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id BE73B34435; Wed, 19 Mar 2003 14:57: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 h2JNiJYB018651; Wed, 19 Mar 2003 15:44:19 -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="us-ascii" Subject: RE: Identifier/locator recap Date: Wed, 19 Mar 2003 15:44:19 -0800 Message-ID: Thread-Topic: Identifier/locator recap Thread-Index: AcLub5lZA5qRL1quR8GguddyhuazPAAAZLiw From: "Tony Li" To: "Iljitsch van Beijnum" , "RJ Atkinson" Cc: X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.44 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA16270 | > Middleboxes break the end-to-end principle and are generally not | > desirable architecturally. | | I agree middleboxes aren't desirable. On the other hand, I | doubt very | many people will applaud a clean architecture if that | means they have to | upgrade large numbers of individual hosts rather than a | few middleboxes. Folks, Let's please understand that these are not mutually exclusive. We can have an architecture that does not require middleboxes and at the same time does not exclude them. Tony From owner-multi6@ops.ietf.org Wed Mar 19 18:44:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16302 for ; Wed, 19 Mar 2003 18:44:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vnGa-000Odv-00 for multi6-data@psg.com; Wed, 19 Mar 2003 15:46:40 -0800 Received: from d12lmsgate-5.de.ibm.com ([194.196.100.238]) by psg.com with esmtp (Exim 3.36 #1) id 18vnGX-000Odg-00 for multi6@ops.ietf.org; Wed, 19 Mar 2003 15:46:38 -0800 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-5.de.ibm.com (8.12.8/8.12.3) with ESMTP id h2JNkSOI105130; Thu, 20 Mar 2003 00:46:28 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h2JNkRtY201216; Thu, 20 Mar 2003 00:46:28 +0100 Received: from gsine01.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA25494 from ; Thu, 20 Mar 2003 00:46:25 +0100 Message-Id: <3E79010E.DF3F0834@hursley.ibm.com> Date: Thu, 20 Mar 2003 00:45:18 +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: Kurt Erik Lindqvist Cc: multi6@ops.ietf.org Subject: Re: Requirements document [was Re: Again no multi6 at IETF#56] References: <038848D8-5A3E-11D7-B5E2-000393AB1404@kurtis.pp.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-1.0 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.44 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I'm with Kurt here. We need this document on record, and if people are worried by the R-word, then don't call them requirements. Call them desirable properties, and lose the RFC 2119 language. Let's not get hung up on our own process hooks. Brian Kurt Erik Lindqvist wrote: > > >> Quote from the one and only document in this WG: > >> > >>> 3.2.1 Scalability > >>> [snip] > >>> A new IPv6 multihoming architecture MUST scale to > >>> accommodate orders of magnitude more multihomed > >>> sites without imposing unreasonable requirements > >>> on the routing system. > >> > >> As chair, you simply can not recommend to go a way that blatantly > >> violates the only working document we have. This text is clear, and > >> it's > >> a "MUST" not a "must" which has a very specific meaning as per RFC > >> 2119. > > > > To be pedantic, the requirements doc doesn't specify the starting > > point: orders of magnitude more multihomed sites than exist today on > > the v6 network is still easily achievable using > > draft-kurtis-call-me-when-we-get-1000-routes-in-the-dfz-00. > > > > That is true, But it does bring up the issue of the status of the > requirements document. From what I know it has been ready to be shipped > to the IESG for last-call for quite some time. Some people have > privately expressed to me that they see little point in moving this > forward. I want to disagree, as I do think that this documents provides > a good base-line and a tool for us as chairs to keep people focused on > what we need to achieve. That said, I do not think that "requirements" > are the right word as we will have different requirements at different > times (and I know that people disagrees to this statement). > > I have discussed this with Joe and if I have understood him correctly > he is for updating the document to better reflect this as > considerations for potential multihoming solutions. I suggest that we > hold off discussions on this until we have a updated document and then > see where to take it from there. > > ...and yes, I do realize that this creates problems with the charter > and the milestones, but that is the least of my worries at the moment > :-). We need to fix that anyway. > > - kurtis - From owner-multi6@ops.ietf.org Wed Mar 19 19:46:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18273 for ; Wed, 19 Mar 2003 19:46:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18voDL-0001X7-00 for multi6-data@psg.com; Wed, 19 Mar 2003 16:47:23 -0800 Received: from wl-142-224.wireless.ietf56.ietf.org ([130.129.142.224] helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18voDG-0001Wv-00 for multi6@ops.ietf.org; Wed, 19 Mar 2003 16:47:18 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2K0mLKW007952; Thu, 20 Mar 2003 01:48:28 +0100 (CET) Date: Thu, 20 Mar 2003 01:48:18 +0100 Subject: Re: Again no multi6 at IETF#56 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Bound, Jim" , "Michael H. Lambert" , To: "Tony Li" From: Kurt Erik Lindqvist In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) 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.44 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > (Trying to catch up on mail here) > | I fully agree that this is a far from perfect model. > | However, note one > | thing. I only advocate the _announcement_ of a longer prefix, not > | _allocation_. If I change provider, I need to hand the > | address space > | back. > > > All of the pain and none of the gain? Any announcement of longer > prefixes is at the expense of routing scalability. Agreed. No question. But with 350 routes I am more worried over the lack of routes.... > | But let's look at the explosion of the routing table. > | Today there are > | 15k ASes in the DFZ. If these all have three upstreams that is 45k > | routes. If we use all the 16-bit AS numbers we have around > | 192k routes. > | This is a poor calculation and comparison, but the fact is > | that the > | natural aggregation of the larger IPv6 allocations are > | helping us here. > | I still think that what will limit multihoming for the > | coming years is > | not scarcity of resources but the cost of doing it. > > > The cost of multihoming is falling. Today, sitting at home on > my couch, I can easily connect to my neighbor's WAP. If we > were to tweak things a bit, both of us would be multi-homed > through the other. In fact, the cost of connectivity is > continuing to fall, so one might expect that the cost of > multi-homing will fall too. I don't question that. What makes me wonder is how many home users will actually want/need multihoming? How many SOHO will? How many enterprises? > If you subscribe to the view that businesses find the Web > interface to be important, then it stands to reason that the > interest in multihoming would continue to grow. Agreed, the question is how fast? > | Last, as we today think that a policy of not announcing > | longer prefixes > | are prohibiting this, I assume that we believe we can > | enforce this in > | the future as well? That gives us a potential roll-back > | scenario. Also > | note that this is almost more of documenting BCP than > | defining a new > | policy.- > > > It's very unlikely that we can ever undo what was done before. > You may recall the flap during the CIDR days about asking > people to renumber so that we could aggregate. I tend to agree with you here. Which is why I have always said that it only has potential to do this. Just as we scaled back the routing table growth a few years ago (I know it was more the .com hysteria collapsing) with filters, we have the potential do to similar things here. > And then, six months from now, someone stands up and says "thanks, > but we've got an installed base and we can't change". No thanks. > Do it right the first time, or not at all. > Well, I think we need to move in steps for a number of reasons, urgency, implementation lead times, and last to get consensus. This said, I think that we need to always keep in mind how we will get from A to B, and eventually to C. But that is what I hope will be the first issue we could get agreement here on. - kurtis - From owner-multi6@ops.ietf.org Wed Mar 19 20:37:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20084 for ; Wed, 19 Mar 2003 20:37:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vp11-0003fj-00 for multi6-data@psg.com; Wed, 19 Mar 2003 17:38:43 -0800 Received: from wl-142-224.wireless.ietf56.ietf.org ([130.129.142.224] helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18vp0w-0003fD-00 for multi6@ops.ietf.org; Wed, 19 Mar 2003 17:38:40 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2K1dvKW007961 for ; Thu, 20 Mar 2003 02:40:00 +0100 (CET) Date: Thu, 20 Mar 2003 02:39:54 +0100 Mime-Version: 1.0 (Apple Message framework v551) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Beer BOF From: Kurt Erik Lindqvist To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-1.0 required=5.0 tests=SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.44 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I am sitting over in the right hand corner when you walk in from the lobby if anyone is looking for me. - kurtis - From owner-multi6@ops.ietf.org Wed Mar 19 20:52:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20575 for ; Wed, 19 Mar 2003 20:52:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vpFp-0004TH-00 for multi6-data@psg.com; Wed, 19 Mar 2003 17:54:01 -0800 Received: from wl-142-224.wireless.ietf56.ietf.org ([130.129.142.224] helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18vpFn-0004T0-00 for multi6@ops.ietf.org; Wed, 19 Mar 2003 17:53:59 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2K1tGKW007964 for ; Thu, 20 Mar 2003 02:55:24 +0100 (CET) Date: Thu, 20 Mar 2003 02:55:14 +0100 Mime-Version: 1.0 (Apple Message framework v551) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Beer after the plenary... From: Kurt Erik Lindqvist To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-1.0 required=5.0 tests=SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.44 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit For the session after the plenary, I will be at the bar disk (or around there) after the plenary. I am wearing a black fleece and looking confused. Just so that it is easier to find me. - kurtis - From owner-multi6@ops.ietf.org Wed Mar 19 21:01:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20763 for ; Wed, 19 Mar 2003 21:01:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vpP5-0004vI-00 for multi6-data@psg.com; Wed, 19 Mar 2003 18:03:35 -0800 Received: from mail3.microsoft.com ([131.107.3.123]) by psg.com with esmtp (Exim 3.36 #1) id 18vpP2-0004uy-00 for multi6@ops.ietf.org; Wed, 19 Mar 2003 18:03:32 -0800 Received: from mail6.microsoft.com ([157.54.6.196]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Wed, 19 Mar 2003 18:03:18 -0800 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 19 Mar 2003 18:03:27 -0800 Received: from 157.54.6.150 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 19 Mar 2003 18:03:26 -0800 Received: from RED-IMC-02.redmond.corp.microsoft.com ([157.54.9.107]) by INET-HUB-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3765.0); Wed, 19 Mar 2003 18:03:15 -0800 Received: from WIN-IMC-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 19 Mar 2003 18:03:25 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by WIN-IMC-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3765.0); Wed, 19 Mar 2003 18:02:53 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C2EE84.E2E92E9E" Subject: FW: Simple dual homing experiment Date: Wed, 19 Mar 2003 18:03:22 -0800 Message-ID: X-MS-Has-Attach: yes Thread-Topic: Simple dual homing experiment Thread-Index: AcLtrXBvA7fKf01vSPaEW4bECTXvUwAAR78wAC/wOnkABZmvJw== From: "Christian Huitema" To: Cc: X-OriginalArrivalTime: 20 Mar 2003 02:02:53.0015 (UTC) FILETIME=[D10C8E70:01C2EE84] X-Spam-Status: No, hits=0.7 required=5.0 tests=OUTLOOK_FW_MSG,SPAM_PHRASE_00_01 version=2.44 Sender: owner-multi6@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C2EE84.E2E92E9E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Kurtis, David and I wrote up a "simple dual homing" proposal, based on previous = drafts and private conversations. This may be one of several ways of = going forward in multi6. -- Christian Huitema ------_=_NextPart_001_01C2EE84.E2E92E9E Content-Type: text/richtext; name="Dual Homing Experiment.rtf" Content-Description: Dual Homing Experiment.rtf Content-Disposition: attachment; filename="Dual Homing Experiment.rtf" Content-Transfer-Encoding: base64 e1xydGYxXGFuc2lcYW5zaWNwZzEyNTJcdWMxXGRlZmYwXHN0c2hmZGJjaDBcc3RzaGZsb2NoMFxz dHNoZmhpY2gwXHN0c2hmYmkwXGRlZmxhbmcxMDMzXGRlZmxhbmdmZTEwMzN7XGZvbnR0Ymx7XGYw XGZyb21hblxmY2hhcnNldDBcZnBycTJ7XCpccGFub3NlIDAyMDIwNjAzMDUwNDA1MDIwMzA0fVRp bWVzIE5ldyBSb21hbjt9e1xmMVxmc3dpc3NcZmNoYXJzZXQwXGZwcnEye1wqXHBhbm9zZSAwMjBi MDYwNDAyMDIwMjAyMDIwNH1BcmlhbDt9DQp7XGYyXGZtb2Rlcm5cZmNoYXJzZXQwXGZwcnExe1wq XHBhbm9zZSAwMjA3MDMwOTAyMDIwNTAyMDQwNH1Db3VyaWVyIE5ldzt9e1xmM1xmcm9tYW5cZmNo YXJzZXQyXGZwcnEye1wqXHBhbm9zZSAwNTA1MDEwMjAxMDcwNjAyMDUwN31TeW1ib2w7fXtcZjEw XGZuaWxcZmNoYXJzZXQyXGZwcnEye1wqXHBhbm9zZSAwNTAwMDAwMDAwMDAwMDAwMDAwMH1XaW5n ZGluZ3M7fQ0Ke1xmMzVcZnN3aXNzXGZjaGFyc2V0MFxmcHJxMntcKlxwYW5vc2UgMDIwYjA2MDQw MzA1MDQwNDAyMDR9VGFob21hO317XGYzNlxmcm9tYW5cZmNoYXJzZXQyMzhcZnBycTIgVGltZXMg TmV3IFJvbWFuIENFO317XGYzN1xmcm9tYW5cZmNoYXJzZXQyMDRcZnBycTIgVGltZXMgTmV3IFJv bWFuIEN5cjt9e1xmMzlcZnJvbWFuXGZjaGFyc2V0MTYxXGZwcnEyIFRpbWVzIE5ldyBSb21hbiBH cmVlazt9DQp7XGY0MFxmcm9tYW5cZmNoYXJzZXQxNjJcZnBycTIgVGltZXMgTmV3IFJvbWFuIFR1 cjt9e1xmNDFcZnJvbWFuXGZjaGFyc2V0MTc3XGZwcnEyIFRpbWVzIE5ldyBSb21hbiAoSGVicmV3 KTt9e1xmNDJcZnJvbWFuXGZjaGFyc2V0MTc4XGZwcnEyIFRpbWVzIE5ldyBSb21hbiAoQXJhYmlj KTt9e1xmNDNcZnJvbWFuXGZjaGFyc2V0MTg2XGZwcnEyIFRpbWVzIE5ldyBSb21hbiBCYWx0aWM7 fQ0Ke1xmNDRcZnJvbWFuXGZjaGFyc2V0MTYzXGZwcnEyIFRpbWVzIE5ldyBSb21hbiAoVmlldG5h bWVzZSk7fXtcZjQ2XGZzd2lzc1xmY2hhcnNldDIzOFxmcHJxMiBBcmlhbCBDRTt9e1xmNDdcZnN3 aXNzXGZjaGFyc2V0MjA0XGZwcnEyIEFyaWFsIEN5cjt9e1xmNDlcZnN3aXNzXGZjaGFyc2V0MTYx XGZwcnEyIEFyaWFsIEdyZWVrO317XGY1MFxmc3dpc3NcZmNoYXJzZXQxNjJcZnBycTIgQXJpYWwg VHVyO30NCntcZjUxXGZzd2lzc1xmY2hhcnNldDE3N1xmcHJxMiBBcmlhbCAoSGVicmV3KTt9e1xm NTJcZnN3aXNzXGZjaGFyc2V0MTc4XGZwcnEyIEFyaWFsIChBcmFiaWMpO317XGY1M1xmc3dpc3Nc ZmNoYXJzZXQxODZcZnBycTIgQXJpYWwgQmFsdGljO317XGY1NFxmc3dpc3NcZmNoYXJzZXQxNjNc ZnBycTIgQXJpYWwgKFZpZXRuYW1lc2UpO317XGY1NlxmbW9kZXJuXGZjaGFyc2V0MjM4XGZwcnEx IENvdXJpZXIgTmV3IENFO30NCntcZjU3XGZtb2Rlcm5cZmNoYXJzZXQyMDRcZnBycTEgQ291cmll ciBOZXcgQ3lyO317XGY1OVxmbW9kZXJuXGZjaGFyc2V0MTYxXGZwcnExIENvdXJpZXIgTmV3IEdy ZWVrO317XGY2MFxmbW9kZXJuXGZjaGFyc2V0MTYyXGZwcnExIENvdXJpZXIgTmV3IFR1cjt9e1xm NjFcZm1vZGVyblxmY2hhcnNldDE3N1xmcHJxMSBDb3VyaWVyIE5ldyAoSGVicmV3KTt9DQp7XGY2 MlxmbW9kZXJuXGZjaGFyc2V0MTc4XGZwcnExIENvdXJpZXIgTmV3IChBcmFiaWMpO317XGY2M1xm bW9kZXJuXGZjaGFyc2V0MTg2XGZwcnExIENvdXJpZXIgTmV3IEJhbHRpYzt9e1xmNjRcZm1vZGVy blxmY2hhcnNldDE2M1xmcHJxMSBDb3VyaWVyIE5ldyAoVmlldG5hbWVzZSk7fXtcZjM4Nlxmc3dp c3NcZmNoYXJzZXQyMzhcZnBycTIgVGFob21hIENFO317XGYzODdcZnN3aXNzXGZjaGFyc2V0MjA0 XGZwcnEyIFRhaG9tYSBDeXI7fQ0Ke1xmMzg5XGZzd2lzc1xmY2hhcnNldDE2MVxmcHJxMiBUYWhv bWEgR3JlZWs7fXtcZjM5MFxmc3dpc3NcZmNoYXJzZXQxNjJcZnBycTIgVGFob21hIFR1cjt9e1xm MzkxXGZzd2lzc1xmY2hhcnNldDE3N1xmcHJxMiBUYWhvbWEgKEhlYnJldyk7fXtcZjM5Mlxmc3dp c3NcZmNoYXJzZXQxNzhcZnBycTIgVGFob21hIChBcmFiaWMpO317XGYzOTNcZnN3aXNzXGZjaGFy c2V0MTg2XGZwcnEyIFRhaG9tYSBCYWx0aWM7fQ0Ke1xmMzk0XGZzd2lzc1xmY2hhcnNldDE2M1xm cHJxMiBUYWhvbWEgKFZpZXRuYW1lc2UpO317XGYzOTVcZnN3aXNzXGZjaGFyc2V0MjIyXGZwcnEy IFRhaG9tYSAoVGhhaSk7fX17XGNvbG9ydGJsO1xyZWQwXGdyZWVuMFxibHVlMDtccmVkMFxncmVl bjBcYmx1ZTI1NTtccmVkMFxncmVlbjI1NVxibHVlMjU1O1xyZWQwXGdyZWVuMjU1XGJsdWUwO1xy ZWQyNTVcZ3JlZW4wXGJsdWUyNTU7XHJlZDI1NVxncmVlbjBcYmx1ZTA7DQpccmVkMjU1XGdyZWVu MjU1XGJsdWUwO1xyZWQyNTVcZ3JlZW4yNTVcYmx1ZTI1NTtccmVkMFxncmVlbjBcYmx1ZTEyODtc cmVkMFxncmVlbjEyOFxibHVlMTI4O1xyZWQwXGdyZWVuMTI4XGJsdWUwO1xyZWQxMjhcZ3JlZW4w XGJsdWUxMjg7XHJlZDEyOFxncmVlbjBcYmx1ZTA7XHJlZDEyOFxncmVlbjEyOFxibHVlMDtccmVk MTI4XGdyZWVuMTI4XGJsdWUxMjg7XHJlZDE5MlxncmVlbjE5MlxibHVlMTkyO317XHN0eWxlc2hl ZXR7DQpccWwgXGxpMFxyaTBcd2lkY3RscGFyXGFzcGFscGhhXGFzcG51bVxmYWF1dG9cYWRqdXN0 cmlnaHRccmluMFxsaW4wXGl0YXAwIFxmczI0XGxhbmcxMDMzXGxhbmdmZTEwMzNcY2dyaWRcbGFu Z25wMTAzM1xsYW5nZmVucDEwMzMgXHNuZXh0MCBOb3JtYWw7fXtcczFccWwgXGZpLTQzMlxsaTQz MlxyaTBcbm93aWRjdGxwYXJcamNsaXN0dGFiXHR4NDMyXGZhYXV0b1xsczdcb3V0bGluZWxldmVs MFxyaW4wXGxpbjQzMlxpdGFwMCANClxmMzVcZnMzNlxsYW5nMTAzM1xsYW5nZmUxMDMzXGNncmlk XGxhbmducDEwMzNcbGFuZ2ZlbnAxMDMzIFxzYmFzZWRvbjAgXHNuZXh0MCBoZWFkaW5nIDE7fXtc czJccWwgXGZpLTU3NlxsaTU3NlxyaTBcbm93aWRjdGxwYXJcamNsaXN0dGFiXHR4NTc2XGZhYXV0 b1xsczdcaWx2bDFcb3V0bGluZWxldmVsMVxyaW4wXGxpbjU3NlxpdGFwMCBcZjM1XGZzMzJcbGFu ZzEwMzNcbGFuZ2ZlMTAzM1xjZ3JpZFxsYW5nbnAxMDMzXGxhbmdmZW5wMTAzMyANClxzYmFzZWRv bjAgXHNuZXh0MCBoZWFkaW5nIDI7fXtcczNccWwgXGZpLTcyMFxsaTcyMFxyaTBcbm93aWRjdGxw YXJcamNsaXN0dGFiXHR4NzIwXGZhYXV0b1xsczdcaWx2bDJcb3V0bGluZWxldmVsMlxyaW4wXGxp bjcyMFxpdGFwMCBcZjM1XGZzMjhcbGFuZzEwMzNcbGFuZ2ZlMTAzM1xjZ3JpZFxsYW5nbnAxMDMz XGxhbmdmZW5wMTAzMyBcc2Jhc2Vkb24wIFxzbmV4dDAgaGVhZGluZyAzO317DQpcczRccWwgXGZp LTg2NFxsaTg2NFxyaTBcbm93aWRjdGxwYXJcamNsaXN0dGFiXHR4ODY0XGZhYXV0b1xsczdcaWx2 bDNcb3V0bGluZWxldmVsM1xyaW4wXGxpbjg2NFxpdGFwMCBcZjM1XGZzMjRcbGFuZzEwMzNcbGFu Z2ZlMTAzM1xjZ3JpZFxsYW5nbnAxMDMzXGxhbmdmZW5wMTAzMyBcc2Jhc2Vkb24wIFxzbmV4dDAg aGVhZGluZyA0O317XHM1XHFsIFxmaS0xMDA4XGxpMTAwOFxyaTBcbm93aWRjdGxwYXINClxqY2xp c3R0YWJcdHgxMDA4XGZhYXV0b1xsczdcaWx2bDRcb3V0bGluZWxldmVsNFxyaW4wXGxpbjEwMDhc aXRhcDAgXGYzNVxmczIwXGxhbmcxMDMzXGxhbmdmZTEwMzNcY2dyaWRcbGFuZ25wMTAzM1xsYW5n ZmVucDEwMzMgXHNiYXNlZG9uMCBcc25leHQwIGhlYWRpbmcgNTt9e1xzNlxxbCBcZmktMTE1Mlxs aTExNTJccmkwXG5vd2lkY3RscGFyDQpcamNsaXN0dGFiXHR4MTE1MlxmYWF1dG9cbHM3XGlsdmw1 XG91dGxpbmVsZXZlbDVccmluMFxsaW4xMTUyXGl0YXAwIFxmMzVcZnMyMFxsYW5nMTAzM1xsYW5n ZmUxMDMzXGNncmlkXGxhbmducDEwMzNcbGFuZ2ZlbnAxMDMzIFxzYmFzZWRvbjAgXHNuZXh0MCBo ZWFkaW5nIDY7fXtcczdccWwgXGZpLTEyOTZcbGkxMjk2XHJpMFxzYjI0MFxzYTYwXHdpZGN0bHBh cg0KXGpjbGlzdHRhYlx0eDEyOTZcYXNwYWxwaGFcYXNwbnVtXGZhYXV0b1xsczdcaWx2bDZcb3V0 bGluZWxldmVsNlxhZGp1c3RyaWdodFxyaW4wXGxpbjEyOTZcaXRhcDAgXGZzMjRcbGFuZzEwMzNc bGFuZ2ZlMTAzM1xjZ3JpZFxsYW5nbnAxMDMzXGxhbmdmZW5wMTAzMyBcc2Jhc2Vkb24wIFxzbmV4 dDAgXHN0eXJzaWQxNDY5NTQ5OSBoZWFkaW5nIDc7fXtcczhccWwgXGZpLTE0NDBcbGkxNDQwXHJp MFxzYjI0MFxzYTYwXHdpZGN0bHBhcg0KXGpjbGlzdHRhYlx0eDE0NDBcYXNwYWxwaGFcYXNwbnVt XGZhYXV0b1xsczdcaWx2bDdcb3V0bGluZWxldmVsN1xhZGp1c3RyaWdodFxyaW4wXGxpbjE0NDBc aXRhcDAgXGlcZnMyNFxsYW5nMTAzM1xsYW5nZmUxMDMzXGNncmlkXGxhbmducDEwMzNcbGFuZ2Zl bnAxMDMzIFxzYmFzZWRvbjAgXHNuZXh0MCBcc3R5cnNpZDE0Njk1NDk5IGhlYWRpbmcgODt9e1xz OVxxbCBcZmktMTU4NFxsaTE1ODRccmkwXHNiMjQwXHNhNjBcd2lkY3RscGFyDQpcamNsaXN0dGFi XHR4MTU4NFxhc3BhbHBoYVxhc3BudW1cZmFhdXRvXGxzN1xpbHZsOFxvdXRsaW5lbGV2ZWw4XGFk anVzdHJpZ2h0XHJpbjBcbGluMTU4NFxpdGFwMCBcZjFcZnMyMlxsYW5nMTAzM1xsYW5nZmUxMDMz XGNncmlkXGxhbmducDEwMzNcbGFuZ2ZlbnAxMDMzIFxzYmFzZWRvbjAgXHNuZXh0MCBcc3R5cnNp ZDE0Njk1NDk5IGhlYWRpbmcgOTt9e1wqXGNzMTAgXGFkZGl0aXZlIFxzc2VtaWhpZGRlbiANCkRl ZmF1bHQgUGFyYWdyYXBoIEZvbnQ7fXtcKlx0czExXHRzcm93ZFx0cmZ0c1dpZHRoQjNcdHJwYWRk bDEwOFx0cnBhZGRyMTA4XHRycGFkZGZsM1x0cnBhZGRmdDNcdHJwYWRkZmIzXHRycGFkZGZyM1x0 cmNicGF0MVx0cmNmcGF0MVx0c2NlbGx3aWR0aGZ0czBcdHN2ZXJ0YWx0XHRzYnJkcnRcdHNicmRy bFx0c2JyZHJiXHRzYnJkcnJcdHNicmRyZGdsXHRzYnJkcmRnclx0c2JyZHJoXHRzYnJkcnYgDQpc cWwgXGxpMFxyaTBcd2lkY3RscGFyXGFzcGFscGhhXGFzcG51bVxmYWF1dG9cYWRqdXN0cmlnaHRc cmluMFxsaW4wXGl0YXAwIFxmczIwXGxhbmcxMDI0XGxhbmdmZTEwMjRcY2dyaWRcbGFuZ25wMTAy NFxsYW5nZmVucDEwMjQgXHNuZXh0MTEgXHNzZW1paGlkZGVuIE5vcm1hbCBUYWJsZTt9fXtcKlxs aXN0dGFibGV7XGxpc3RcbGlzdHRlbXBsYXRlaWQtMTgyMTMyMzg0MlxsaXN0c2ltcGxle1xsaXN0 bGV2ZWxcbGV2ZWxuZmMyMw0KXGxldmVsbmZjbjIzXGxldmVsamMwXGxldmVsamNuMFxsZXZlbGZv bGxvdzBcbGV2ZWxzdGFydGF0MFxsZXZlbHNwYWNlMFxsZXZlbGluZGVudDB7XGxldmVsdGV4dFwn MDEqO317XGxldmVsbnVtYmVyczt9fXtcbGlzdG5hbWUgO31cbGlzdGlkLTJ9e1xsaXN0XGxpc3R0 ZW1wbGF0ZWlkMjQzMDEyOTk4XGxpc3RoeWJyaWR7XGxpc3RsZXZlbFxsZXZlbG5mYzIzXGxldmVs bmZjbjIzXGxldmVsamMwXGxldmVsamNuMFxsZXZlbGZvbGxvdzANClxsZXZlbHN0YXJ0YXQxXGxl dmVsc3BhY2UzNjBcbGV2ZWxpbmRlbnQwe1xsZXZlbHRleHRcbGV2ZWx0ZW1wbGF0ZWlkNjc2OTg2 ODlcJzAxXHUtMzkxMyA/O317XGxldmVsbnVtYmVyczt9XGYzXGZiaWFzMCBcZmktMzYwXGxpNzIw XGpjbGlzdHRhYlx0eDcyMFxsaW43MjAgfXtcbGlzdGxldmVsXGxldmVsbmZjMjNcbGV2ZWxuZmNu MjNcbGV2ZWxqYzBcbGV2ZWxqY24wXGxldmVsZm9sbG93MFxsZXZlbHN0YXJ0YXQxXGxldmVsc3Bh Y2UzNjANClxsZXZlbGluZGVudDB7XGxldmVsdGV4dFxsZXZlbHRlbXBsYXRlaWQ2NzY5ODY5MVwn MDFvO317XGxldmVsbnVtYmVyczt9XGYyXGZiaWFzMCBcZmktMzYwXGxpMTQ0MFxqY2xpc3R0YWJc dHgxNDQwXGxpbjE0NDAgfXtcbGlzdGxldmVsXGxldmVsbmZjMjNcbGV2ZWxuZmNuMjNcbGV2ZWxq YzBcbGV2ZWxqY24wXGxldmVsZm9sbG93MFxsZXZlbHN0YXJ0YXQxXGxldmVsc3BhY2UzNjBcbGV2 ZWxpbmRlbnQwe1xsZXZlbHRleHQNClxsZXZlbHRlbXBsYXRlaWQ2NzY5ODY5M1wnMDFcdS0zOTI5 ID87fXtcbGV2ZWxudW1iZXJzO31cZjEwXGZiaWFzMCBcZmktMzYwXGxpMjE2MFxqY2xpc3R0YWJc dHgyMTYwXGxpbjIxNjAgfXtcbGlzdGxldmVsXGxldmVsbmZjMjNcbGV2ZWxuZmNuMjNcbGV2ZWxq YzBcbGV2ZWxqY24wXGxldmVsZm9sbG93MFxsZXZlbHN0YXJ0YXQxXGxldmVsc3BhY2UzNjBcbGV2 ZWxpbmRlbnQwe1xsZXZlbHRleHRcbGV2ZWx0ZW1wbGF0ZWlkNjc2OTg2ODkNClwnMDFcdS0zOTEz ID87fXtcbGV2ZWxudW1iZXJzO31cZjNcZmJpYXMwIFxmaS0zNjBcbGkyODgwXGpjbGlzdHRhYlx0 eDI4ODBcbGluMjg4MCB9e1xsaXN0bGV2ZWxcbGV2ZWxuZmMyM1xsZXZlbG5mY24yM1xsZXZlbGpj MFxsZXZlbGpjbjBcbGV2ZWxmb2xsb3cwXGxldmVsc3RhcnRhdDFcbGV2ZWxzcGFjZTM2MFxsZXZl bGluZGVudDB7XGxldmVsdGV4dFxsZXZlbHRlbXBsYXRlaWQ2NzY5ODY5MVwnMDFvO317XGxldmVs bnVtYmVyczt9DQpcZjJcZmJpYXMwIFxmaS0zNjBcbGkzNjAwXGpjbGlzdHRhYlx0eDM2MDBcbGlu MzYwMCB9e1xsaXN0bGV2ZWxcbGV2ZWxuZmMyM1xsZXZlbG5mY24yM1xsZXZlbGpjMFxsZXZlbGpj bjBcbGV2ZWxmb2xsb3cwXGxldmVsc3RhcnRhdDFcbGV2ZWxzcGFjZTM2MFxsZXZlbGluZGVudDB7 XGxldmVsdGV4dFxsZXZlbHRlbXBsYXRlaWQ2NzY5ODY5M1wnMDFcdS0zOTI5ID87fXtcbGV2ZWxu dW1iZXJzO31cZjEwXGZiaWFzMCBcZmktMzYwXGxpNDMyMA0KXGpjbGlzdHRhYlx0eDQzMjBcbGlu NDMyMCB9e1xsaXN0bGV2ZWxcbGV2ZWxuZmMyM1xsZXZlbG5mY24yM1xsZXZlbGpjMFxsZXZlbGpj bjBcbGV2ZWxmb2xsb3cwXGxldmVsc3RhcnRhdDFcbGV2ZWxzcGFjZTM2MFxsZXZlbGluZGVudDB7 XGxldmVsdGV4dFxsZXZlbHRlbXBsYXRlaWQ2NzY5ODY4OVwnMDFcdS0zOTEzID87fXtcbGV2ZWxu dW1iZXJzO31cZjNcZmJpYXMwIFxmaS0zNjBcbGk1MDQwXGpjbGlzdHRhYlx0eDUwNDBcbGluNTA0 MCB9DQp7XGxpc3RsZXZlbFxsZXZlbG5mYzIzXGxldmVsbmZjbjIzXGxldmVsamMwXGxldmVsamNu MFxsZXZlbGZvbGxvdzBcbGV2ZWxzdGFydGF0MVxsZXZlbHNwYWNlMzYwXGxldmVsaW5kZW50MHtc bGV2ZWx0ZXh0XGxldmVsdGVtcGxhdGVpZDY3Njk4NjkxXCcwMW87fXtcbGV2ZWxudW1iZXJzO31c ZjJcZmJpYXMwIFxmaS0zNjBcbGk1NzYwXGpjbGlzdHRhYlx0eDU3NjBcbGluNTc2MCB9e1xsaXN0 bGV2ZWxcbGV2ZWxuZmMyM1xsZXZlbG5mY24yMw0KXGxldmVsamMwXGxldmVsamNuMFxsZXZlbGZv bGxvdzBcbGV2ZWxzdGFydGF0MVxsZXZlbHNwYWNlMzYwXGxldmVsaW5kZW50MHtcbGV2ZWx0ZXh0 XGxldmVsdGVtcGxhdGVpZDY3Njk4NjkzXCcwMVx1LTM5MjkgPzt9e1xsZXZlbG51bWJlcnM7fVxm MTBcZmJpYXMwIFxmaS0zNjBcbGk2NDgwXGpjbGlzdHRhYlx0eDY0ODBcbGluNjQ4MCB9e1xsaXN0 bmFtZSA7fVxsaXN0aWQxOTc2NjY0MDF9e1xsaXN0XGxpc3R0ZW1wbGF0ZWlkLTEzMDA0MzkzNzgN ClxsaXN0aHlicmlke1xsaXN0bGV2ZWxcbGV2ZWxuZmMyM1xsZXZlbG5mY24yM1xsZXZlbGpjMFxs ZXZlbGpjbjBcbGV2ZWxmb2xsb3cwXGxldmVsc3RhcnRhdDFcbGV2ZWxzcGFjZTM2MFxsZXZlbGlu ZGVudDB7XGxldmVsdGV4dFxsZXZlbHRlbXBsYXRlaWQ2NzY5ODY4OVwnMDFcdS0zOTEzID87fXtc bGV2ZWxudW1iZXJzO31cZjNcZmJpYXMwIFxmaS0zNjBcbGk3MjBcamNsaXN0dGFiXHR4NzIwXGxp bjcyMCB9e1xsaXN0bGV2ZWxcbGV2ZWxuZmMyMw0KXGxldmVsbmZjbjIzXGxldmVsamMwXGxldmVs amNuMFxsZXZlbGZvbGxvdzBcbGV2ZWxzdGFydGF0MVxsZXZlbHNwYWNlMzYwXGxldmVsaW5kZW50 MHtcbGV2ZWx0ZXh0XGxldmVsdGVtcGxhdGVpZDY3Njk4NjkxXCcwMW87fXtcbGV2ZWxudW1iZXJz O31cZjJcZmJpYXMwIFxmaS0zNjBcbGkxNDQwXGpjbGlzdHRhYlx0eDE0NDBcbGluMTQ0MCB9e1xs aXN0bGV2ZWxcbGV2ZWxuZmMyM1xsZXZlbG5mY24yM1xsZXZlbGpjMFxsZXZlbGpjbjANClxsZXZl bGZvbGxvdzBcbGV2ZWxzdGFydGF0MVxsZXZlbHNwYWNlMzYwXGxldmVsaW5kZW50MHtcbGV2ZWx0 ZXh0XGxldmVsdGVtcGxhdGVpZDY3Njk4NjkzXCcwMVx1LTM5MjkgPzt9e1xsZXZlbG51bWJlcnM7 fVxmMTBcZmJpYXMwIFxmaS0zNjBcbGkyMTYwXGpjbGlzdHRhYlx0eDIxNjBcbGluMjE2MCB9e1xs aXN0bGV2ZWxcbGV2ZWxuZmMyM1xsZXZlbG5mY24yM1xsZXZlbGpjMFxsZXZlbGpjbjBcbGV2ZWxm b2xsb3cwXGxldmVsc3RhcnRhdDENClxsZXZlbHNwYWNlMzYwXGxldmVsaW5kZW50MHtcbGV2ZWx0 ZXh0XGxldmVsdGVtcGxhdGVpZDY3Njk4Njg5XCcwMVx1LTM5MTMgPzt9e1xsZXZlbG51bWJlcnM7 fVxmM1xmYmlhczAgXGZpLTM2MFxsaTI4ODBcamNsaXN0dGFiXHR4Mjg4MFxsaW4yODgwIH17XGxp c3RsZXZlbFxsZXZlbG5mYzIzXGxldmVsbmZjbjIzXGxldmVsamMwXGxldmVsamNuMFxsZXZlbGZv bGxvdzBcbGV2ZWxzdGFydGF0MVxsZXZlbHNwYWNlMzYwXGxldmVsaW5kZW50MA0Ke1xsZXZlbHRl eHRcbGV2ZWx0ZW1wbGF0ZWlkNjc2OTg2OTFcJzAxbzt9e1xsZXZlbG51bWJlcnM7fVxmMlxmYmlh czAgXGZpLTM2MFxsaTM2MDBcamNsaXN0dGFiXHR4MzYwMFxsaW4zNjAwIH17XGxpc3RsZXZlbFxs ZXZlbG5mYzIzXGxldmVsbmZjbjIzXGxldmVsamMwXGxldmVsamNuMFxsZXZlbGZvbGxvdzBcbGV2 ZWxzdGFydGF0MVxsZXZlbHNwYWNlMzYwXGxldmVsaW5kZW50MHtcbGV2ZWx0ZXh0XGxldmVsdGVt cGxhdGVpZDY3Njk4NjkzDQpcJzAxXHUtMzkyOSA/O317XGxldmVsbnVtYmVyczt9XGYxMFxmYmlh czAgXGZpLTM2MFxsaTQzMjBcamNsaXN0dGFiXHR4NDMyMFxsaW40MzIwIH17XGxpc3RsZXZlbFxs ZXZlbG5mYzIzXGxldmVsbmZjbjIzXGxldmVsamMwXGxldmVsamNuMFxsZXZlbGZvbGxvdzBcbGV2 ZWxzdGFydGF0MVxsZXZlbHNwYWNlMzYwXGxldmVsaW5kZW50MHtcbGV2ZWx0ZXh0XGxldmVsdGVt cGxhdGVpZDY3Njk4Njg5XCcwMVx1LTM5MTMgPzt9e1xsZXZlbG51bWJlcnMNCjt9XGYzXGZiaWFz MCBcZmktMzYwXGxpNTA0MFxqY2xpc3R0YWJcdHg1MDQwXGxpbjUwNDAgfXtcbGlzdGxldmVsXGxl dmVsbmZjMjNcbGV2ZWxuZmNuMjNcbGV2ZWxqYzBcbGV2ZWxqY24wXGxldmVsZm9sbG93MFxsZXZl bHN0YXJ0YXQxXGxldmVsc3BhY2UzNjBcbGV2ZWxpbmRlbnQwe1xsZXZlbHRleHRcbGV2ZWx0ZW1w bGF0ZWlkNjc2OTg2OTFcJzAxbzt9e1xsZXZlbG51bWJlcnM7fVxmMlxmYmlhczAgXGZpLTM2MFxs aTU3NjANClxqY2xpc3R0YWJcdHg1NzYwXGxpbjU3NjAgfXtcbGlzdGxldmVsXGxldmVsbmZjMjNc bGV2ZWxuZmNuMjNcbGV2ZWxqYzBcbGV2ZWxqY24wXGxldmVsZm9sbG93MFxsZXZlbHN0YXJ0YXQx XGxldmVsc3BhY2UzNjBcbGV2ZWxpbmRlbnQwe1xsZXZlbHRleHRcbGV2ZWx0ZW1wbGF0ZWlkNjc2 OTg2OTNcJzAxXHUtMzkyOSA/O317XGxldmVsbnVtYmVyczt9XGYxMFxmYmlhczAgXGZpLTM2MFxs aTY0ODBcamNsaXN0dGFiXHR4NjQ4MFxsaW42NDgwIH0NCntcbGlzdG5hbWUgO31cbGlzdGlkOTE3 NTE1ODE5fXtcbGlzdFxsaXN0dGVtcGxhdGVpZC0xNjM4NDc1ODU0XGxpc3RoeWJyaWR7XGxpc3Rs ZXZlbFxsZXZlbG5mYzIzXGxldmVsbmZjbjIzXGxldmVsamMwXGxldmVsamNuMFxsZXZlbGZvbGxv dzBcbGV2ZWxzdGFydGF0MVxsZXZlbHNwYWNlMzYwXGxldmVsaW5kZW50MHtcbGV2ZWx0ZXh0XGxl dmVsdGVtcGxhdGVpZDY3Njk4Njg5XCcwMVx1LTM5MTMgPzt9e1xsZXZlbG51bWJlcnM7fQ0KXGYz XGZiaWFzMCBcZmktMzYwXGxpNzIwXGpjbGlzdHRhYlx0eDcyMFxsaW43MjAgfXtcbGlzdGxldmVs XGxldmVsbmZjMjNcbGV2ZWxuZmNuMjNcbGV2ZWxqYzBcbGV2ZWxqY24wXGxldmVsZm9sbG93MFxs ZXZlbHN0YXJ0YXQxXGxldmVsc3BhY2UzNjBcbGV2ZWxpbmRlbnQwe1xsZXZlbHRleHRcbGV2ZWx0 ZW1wbGF0ZWlkNjc2OTg2OTFcJzAxbzt9e1xsZXZlbG51bWJlcnM7fVxmMlxmYmlhczAgXGZpLTM2 MFxsaTE0NDANClxqY2xpc3R0YWJcdHgxNDQwXGxpbjE0NDAgfXtcbGlzdGxldmVsXGxldmVsbmZj MjNcbGV2ZWxuZmNuMjNcbGV2ZWxqYzBcbGV2ZWxqY24wXGxldmVsZm9sbG93MFxsZXZlbHN0YXJ0 YXQxXGxldmVsc3BhY2UzNjBcbGV2ZWxpbmRlbnQwe1xsZXZlbHRleHRcbGV2ZWx0ZW1wbGF0ZWlk Njc2OTg2OTNcJzAxXHUtMzkyOSA/O317XGxldmVsbnVtYmVyczt9XGYxMFxmYmlhczAgXGZpLTM2 MFxsaTIxNjBcamNsaXN0dGFiXHR4MjE2MFxsaW4yMTYwIH0NCntcbGlzdGxldmVsXGxldmVsbmZj MjNcbGV2ZWxuZmNuMjNcbGV2ZWxqYzBcbGV2ZWxqY24wXGxldmVsZm9sbG93MFxsZXZlbHN0YXJ0 YXQxXGxldmVsc3BhY2UzNjBcbGV2ZWxpbmRlbnQwe1xsZXZlbHRleHRcbGV2ZWx0ZW1wbGF0ZWlk Njc2OTg2ODlcJzAxXHUtMzkxMyA/O317XGxldmVsbnVtYmVyczt9XGYzXGZiaWFzMCBcZmktMzYw XGxpMjg4MFxqY2xpc3R0YWJcdHgyODgwXGxpbjI4ODAgfXtcbGlzdGxldmVsXGxldmVsbmZjMjMN ClxsZXZlbG5mY24yM1xsZXZlbGpjMFxsZXZlbGpjbjBcbGV2ZWxmb2xsb3cwXGxldmVsc3RhcnRh dDFcbGV2ZWxzcGFjZTM2MFxsZXZlbGluZGVudDB7XGxldmVsdGV4dFxsZXZlbHRlbXBsYXRlaWQ2 NzY5ODY5MVwnMDFvO317XGxldmVsbnVtYmVyczt9XGYyXGZiaWFzMCBcZmktMzYwXGxpMzYwMFxq Y2xpc3R0YWJcdHgzNjAwXGxpbjM2MDAgfXtcbGlzdGxldmVsXGxldmVsbmZjMjNcbGV2ZWxuZmNu MjNcbGV2ZWxqYzBcbGV2ZWxqY24wDQpcbGV2ZWxmb2xsb3cwXGxldmVsc3RhcnRhdDFcbGV2ZWxz cGFjZTM2MFxsZXZlbGluZGVudDB7XGxldmVsdGV4dFxsZXZlbHRlbXBsYXRlaWQ2NzY5ODY5M1wn MDFcdS0zOTI5ID87fXtcbGV2ZWxudW1iZXJzO31cZjEwXGZiaWFzMCBcZmktMzYwXGxpNDMyMFxq Y2xpc3R0YWJcdHg0MzIwXGxpbjQzMjAgfXtcbGlzdGxldmVsXGxldmVsbmZjMjNcbGV2ZWxuZmNu MjNcbGV2ZWxqYzBcbGV2ZWxqY24wXGxldmVsZm9sbG93MFxsZXZlbHN0YXJ0YXQxDQpcbGV2ZWxz cGFjZTM2MFxsZXZlbGluZGVudDB7XGxldmVsdGV4dFxsZXZlbHRlbXBsYXRlaWQ2NzY5ODY4OVwn MDFcdS0zOTEzID87fXtcbGV2ZWxudW1iZXJzO31cZjNcZmJpYXMwIFxmaS0zNjBcbGk1MDQwXGpj bGlzdHRhYlx0eDUwNDBcbGluNTA0MCB9e1xsaXN0bGV2ZWxcbGV2ZWxuZmMyM1xsZXZlbG5mY24y M1xsZXZlbGpjMFxsZXZlbGpjbjBcbGV2ZWxmb2xsb3cwXGxldmVsc3RhcnRhdDFcbGV2ZWxzcGFj ZTM2MFxsZXZlbGluZGVudDANCntcbGV2ZWx0ZXh0XGxldmVsdGVtcGxhdGVpZDY3Njk4NjkxXCcw MW87fXtcbGV2ZWxudW1iZXJzO31cZjJcZmJpYXMwIFxmaS0zNjBcbGk1NzYwXGpjbGlzdHRhYlx0 eDU3NjBcbGluNTc2MCB9e1xsaXN0bGV2ZWxcbGV2ZWxuZmMyM1xsZXZlbG5mY24yM1xsZXZlbGpj MFxsZXZlbGpjbjBcbGV2ZWxmb2xsb3cwXGxldmVsc3RhcnRhdDFcbGV2ZWxzcGFjZTM2MFxsZXZl bGluZGVudDB7XGxldmVsdGV4dFxsZXZlbHRlbXBsYXRlaWQ2NzY5ODY5Mw0KXCcwMVx1LTM5Mjkg Pzt9e1xsZXZlbG51bWJlcnM7fVxmMTBcZmJpYXMwIFxmaS0zNjBcbGk2NDgwXGpjbGlzdHRhYlx0 eDY0ODBcbGluNjQ4MCB9e1xsaXN0bmFtZSA7fVxsaXN0aWQ5NDYyMzIzMDd9e1xsaXN0XGxpc3R0 ZW1wbGF0ZWlkNTE4ODE5NjUwXGxpc3RoeWJyaWR7XGxpc3RsZXZlbFxsZXZlbG5mYzIzXGxldmVs bmZjbjIzXGxldmVsamMwXGxldmVsamNuMFxsZXZlbGZvbGxvdzBcbGV2ZWxzdGFydGF0MVxsZXZl bHNwYWNlMzYwDQpcbGV2ZWxpbmRlbnQwe1xsZXZlbHRleHRcbGV2ZWx0ZW1wbGF0ZWlkNjc2OTg2 ODlcJzAxXHUtMzkxMyA/O317XGxldmVsbnVtYmVyczt9XGYzXGZiaWFzMCBcZmktMzYwXGxpNzIw XGpjbGlzdHRhYlx0eDcyMFxsaW43MjAgfXtcbGlzdGxldmVsXGxldmVsbmZjMjNcbGV2ZWxuZmNu MjNcbGV2ZWxqYzBcbGV2ZWxqY24wXGxldmVsZm9sbG93MFxsZXZlbHN0YXJ0YXQxXGxldmVsc3Bh Y2UzNjBcbGV2ZWxpbmRlbnQwe1xsZXZlbHRleHQNClxsZXZlbHRlbXBsYXRlaWQ2NzY5ODY5MVwn MDFvO317XGxldmVsbnVtYmVyczt9XGYyXGZiaWFzMCBcZmktMzYwXGxpMTQ0MFxqY2xpc3R0YWJc dHgxNDQwXGxpbjE0NDAgfXtcbGlzdGxldmVsXGxldmVsbmZjMjNcbGV2ZWxuZmNuMjNcbGV2ZWxq YzBcbGV2ZWxqY24wXGxldmVsZm9sbG93MFxsZXZlbHN0YXJ0YXQxXGxldmVsc3BhY2UzNjBcbGV2 ZWxpbmRlbnQwe1xsZXZlbHRleHRcbGV2ZWx0ZW1wbGF0ZWlkNjc2OTg2OTMNClwnMDFcdS0zOTI5 ID87fXtcbGV2ZWxudW1iZXJzO31cZjEwXGZiaWFzMCBcZmktMzYwXGxpMjE2MFxqY2xpc3R0YWJc dHgyMTYwXGxpbjIxNjAgfXtcbGlzdGxldmVsXGxldmVsbmZjMjNcbGV2ZWxuZmNuMjNcbGV2ZWxq YzBcbGV2ZWxqY24wXGxldmVsZm9sbG93MFxsZXZlbHN0YXJ0YXQxXGxldmVsc3BhY2UzNjBcbGV2 ZWxpbmRlbnQwe1xsZXZlbHRleHRcbGV2ZWx0ZW1wbGF0ZWlkNjc2OTg2ODlcJzAxXHUtMzkxMyA/ O317XGxldmVsbnVtYmVycw0KO31cZjNcZmJpYXMwIFxmaS0zNjBcbGkyODgwXGpjbGlzdHRhYlx0 eDI4ODBcbGluMjg4MCB9e1xsaXN0bGV2ZWxcbGV2ZWxuZmMyM1xsZXZlbG5mY24yM1xsZXZlbGpj MFxsZXZlbGpjbjBcbGV2ZWxmb2xsb3cwXGxldmVsc3RhcnRhdDFcbGV2ZWxzcGFjZTM2MFxsZXZl bGluZGVudDB7XGxldmVsdGV4dFxsZXZlbHRlbXBsYXRlaWQ2NzY5ODY5MVwnMDFvO317XGxldmVs bnVtYmVyczt9XGYyXGZiaWFzMCBcZmktMzYwXGxpMzYwMA0KXGpjbGlzdHRhYlx0eDM2MDBcbGlu MzYwMCB9e1xsaXN0bGV2ZWxcbGV2ZWxuZmMyM1xsZXZlbG5mY24yM1xsZXZlbGpjMFxsZXZlbGpj bjBcbGV2ZWxmb2xsb3cwXGxldmVsc3RhcnRhdDFcbGV2ZWxzcGFjZTM2MFxsZXZlbGluZGVudDB7 XGxldmVsdGV4dFxsZXZlbHRlbXBsYXRlaWQ2NzY5ODY5M1wnMDFcdS0zOTI5ID87fXtcbGV2ZWxu dW1iZXJzO31cZjEwXGZiaWFzMCBcZmktMzYwXGxpNDMyMFxqY2xpc3R0YWJcdHg0MzIwXGxpbjQz MjAgfQ0Ke1xsaXN0bGV2ZWxcbGV2ZWxuZmMyM1xsZXZlbG5mY24yM1xsZXZlbGpjMFxsZXZlbGpj bjBcbGV2ZWxmb2xsb3cwXGxldmVsc3RhcnRhdDFcbGV2ZWxzcGFjZTM2MFxsZXZlbGluZGVudDB7 XGxldmVsdGV4dFxsZXZlbHRlbXBsYXRlaWQ2NzY5ODY4OVwnMDFcdS0zOTEzID87fXtcbGV2ZWxu dW1iZXJzO31cZjNcZmJpYXMwIFxmaS0zNjBcbGk1MDQwXGpjbGlzdHRhYlx0eDUwNDBcbGluNTA0 MCB9e1xsaXN0bGV2ZWxcbGV2ZWxuZmMyMw0KXGxldmVsbmZjbjIzXGxldmVsamMwXGxldmVsamNu MFxsZXZlbGZvbGxvdzBcbGV2ZWxzdGFydGF0MVxsZXZlbHNwYWNlMzYwXGxldmVsaW5kZW50MHtc bGV2ZWx0ZXh0XGxldmVsdGVtcGxhdGVpZDY3Njk4NjkxXCcwMW87fXtcbGV2ZWxudW1iZXJzO31c ZjJcZmJpYXMwIFxmaS0zNjBcbGk1NzYwXGpjbGlzdHRhYlx0eDU3NjBcbGluNTc2MCB9e1xsaXN0 bGV2ZWxcbGV2ZWxuZmMyM1xsZXZlbG5mY24yM1xsZXZlbGpjMFxsZXZlbGpjbjANClxsZXZlbGZv bGxvdzBcbGV2ZWxzdGFydGF0MVxsZXZlbHNwYWNlMzYwXGxldmVsaW5kZW50MHtcbGV2ZWx0ZXh0 XGxldmVsdGVtcGxhdGVpZDY3Njk4NjkzXCcwMVx1LTM5MjkgPzt9e1xsZXZlbG51bWJlcnM7fVxm MTBcZmJpYXMwIFxmaS0zNjBcbGk2NDgwXGpjbGlzdHRhYlx0eDY0ODBcbGluNjQ4MCB9e1xsaXN0 bmFtZSA7fVxsaXN0aWQxMzkyNDU4MTIyfXtcbGlzdFxsaXN0dGVtcGxhdGVpZDY3Njk4NzI1e1xs aXN0bGV2ZWxcbGV2ZWxuZmMwDQpcbGV2ZWxuZmNuMFxsZXZlbGpjMFxsZXZlbGpjbjBcbGV2ZWxm b2xsb3cwXGxldmVsc3RhcnRhdDFcbGV2ZWxzcGFjZTBcbGV2ZWxpbmRlbnQwe1xsZXZlbHRleHRc JzAxXCcwMDt9e1xsZXZlbG51bWJlcnNcJzAxO31cczFcZmktNDMyXGxpNDMyXGpjbGlzdHRhYlx0 eDQzMlxsaW40MzIgfXtcbGlzdGxldmVsXGxldmVsbmZjMFxsZXZlbG5mY24wXGxldmVsamMwXGxl dmVsamNuMFxsZXZlbGZvbGxvdzBcbGV2ZWxzdGFydGF0MVxsZXZlbHNwYWNlMA0KXGxldmVsaW5k ZW50MHtcbGV2ZWx0ZXh0XCcwM1wnMDAuXCcwMTt9e1xsZXZlbG51bWJlcnNcJzAxXCcwMzt9XHMy XGZpLTU3NlxsaTU3NlxqY2xpc3R0YWJcdHg1NzZcbGluNTc2IH17XGxpc3RsZXZlbFxsZXZlbG5m YzBcbGV2ZWxuZmNuMFxsZXZlbGpjMFxsZXZlbGpjbjBcbGV2ZWxmb2xsb3cwXGxldmVsc3RhcnRh dDFcbGV2ZWxzcGFjZTBcbGV2ZWxpbmRlbnQwe1xsZXZlbHRleHRcJzA1XCcwMC5cJzAxLlwnMDI7 fXtcbGV2ZWxudW1iZXJzDQpcJzAxXCcwM1wnMDU7fVxzM1xmaS03MjBcbGk3MjBcamNsaXN0dGFi XHR4NzIwXGxpbjcyMCB9e1xsaXN0bGV2ZWxcbGV2ZWxuZmMwXGxldmVsbmZjbjBcbGV2ZWxqYzBc bGV2ZWxqY24wXGxldmVsZm9sbG93MFxsZXZlbHN0YXJ0YXQxXGxldmVsc3BhY2UwXGxldmVsaW5k ZW50MHtcbGV2ZWx0ZXh0XCcwN1wnMDAuXCcwMS5cJzAyLlwnMDM7fXtcbGV2ZWxudW1iZXJzXCcw MVwnMDNcJzA1XCcwNzt9XHM0XGZpLTg2NFxsaTg2NA0KXGpjbGlzdHRhYlx0eDg2NFxsaW44NjQg fXtcbGlzdGxldmVsXGxldmVsbmZjMFxsZXZlbG5mY24wXGxldmVsamMwXGxldmVsamNuMFxsZXZl bGZvbGxvdzBcbGV2ZWxzdGFydGF0MVxsZXZlbHNwYWNlMFxsZXZlbGluZGVudDB7XGxldmVsdGV4 dFwnMDlcJzAwLlwnMDEuXCcwMi5cJzAzLlwnMDQ7fXtcbGV2ZWxudW1iZXJzXCcwMVwnMDNcJzA1 XCcwN1wnMDk7fVxzNVxmaS0xMDA4XGxpMTAwOFxqY2xpc3R0YWJcdHgxMDA4XGxpbjEwMDggfQ0K e1xsaXN0bGV2ZWxcbGV2ZWxuZmMwXGxldmVsbmZjbjBcbGV2ZWxqYzBcbGV2ZWxqY24wXGxldmVs Zm9sbG93MFxsZXZlbHN0YXJ0YXQxXGxldmVsc3BhY2UwXGxldmVsaW5kZW50MHtcbGV2ZWx0ZXh0 XCcwYlwnMDAuXCcwMS5cJzAyLlwnMDMuXCcwNC5cJzA1O317XGxldmVsbnVtYmVyc1wnMDFcJzAz XCcwNVwnMDdcJzA5XCcwYjt9XHM2XGZpLTExNTJcbGkxMTUyXGpjbGlzdHRhYlx0eDExNTJcbGlu MTE1MiB9e1xsaXN0bGV2ZWxcbGV2ZWxuZmMwDQpcbGV2ZWxuZmNuMFxsZXZlbGpjMFxsZXZlbGpj bjBcbGV2ZWxmb2xsb3cwXGxldmVsc3RhcnRhdDFcbGV2ZWxzcGFjZTBcbGV2ZWxpbmRlbnQwe1xs ZXZlbHRleHRcJzBkXCcwMC5cJzAxLlwnMDIuXCcwMy5cJzA0LlwnMDUuXCcwNjt9e1xsZXZlbG51 bWJlcnNcJzAxXCcwM1wnMDVcJzA3XCcwOVwnMGJcJzBkO31cczdcZmktMTI5NlxsaTEyOTZcamNs aXN0dGFiXHR4MTI5NlxsaW4xMjk2IH17XGxpc3RsZXZlbFxsZXZlbG5mYzBcbGV2ZWxuZmNuMA0K XGxldmVsamMwXGxldmVsamNuMFxsZXZlbGZvbGxvdzBcbGV2ZWxzdGFydGF0MVxsZXZlbHNwYWNl MFxsZXZlbGluZGVudDB7XGxldmVsdGV4dFwnMGZcJzAwLlwnMDEuXCcwMi5cJzAzLlwnMDQuXCcw NS5cJzA2LlwnMDc7fXtcbGV2ZWxudW1iZXJzXCcwMVwnMDNcJzA1XCcwN1wnMDlcJzBiXCcwZFwn MGY7fVxzOFxmaS0xNDQwXGxpMTQ0MFxqY2xpc3R0YWJcdHgxNDQwXGxpbjE0NDAgfXtcbGlzdGxl dmVsXGxldmVsbmZjMFxsZXZlbG5mY24wDQpcbGV2ZWxqYzBcbGV2ZWxqY24wXGxldmVsZm9sbG93 MFxsZXZlbHN0YXJ0YXQxXGxldmVsc3BhY2UwXGxldmVsaW5kZW50MHtcbGV2ZWx0ZXh0XCcxMVwn MDAuXCcwMS5cJzAyLlwnMDMuXCcwNC5cJzA1LlwnMDYuXCcwNy5cJzA4O317XGxldmVsbnVtYmVy c1wnMDFcJzAzXCcwNVwnMDdcJzA5XCcwYlwnMGRcJzBmXCcxMTt9XHM5XGZpLTE1ODRcbGkxNTg0 XGpjbGlzdHRhYlx0eDE1ODRcbGluMTU4NCB9e1xsaXN0bmFtZSANCjt9XGxpc3RpZDE0NDExNDU1 NTR9fXtcKlxsaXN0b3ZlcnJpZGV0YWJsZXtcbGlzdG92ZXJyaWRlXGxpc3RpZC0yXGxpc3RvdmVy cmlkZWNvdW50MXtcbGZvbGV2ZWxcbGlzdG92ZXJyaWRlZm9ybWF0e1xsaXN0bGV2ZWxcbGV2ZWxu ZmMyM1xsZXZlbG5mY24yM1xsZXZlbGpjMFxsZXZlbGpjbjBcbGV2ZWxmb2xsb3cwXGxldmVsc3Rh cnRhdDBcbGV2ZWxvbGRcbGV2ZWxzcGFjZTBcbGV2ZWxpbmRlbnQwe1xsZXZlbHRleHQNClwnMDFc dS0zOTc3ID87fXtcbGV2ZWxudW1iZXJzO31cZjEwXGZzMjRcZmJpYXMwIH19XGxzMX17XGxpc3Rv dmVycmlkZVxsaXN0aWQtMlxsaXN0b3ZlcnJpZGVjb3VudDF7XGxmb2xldmVsXGxpc3RvdmVycmlk ZWZvcm1hdHtcbGlzdGxldmVsXGxldmVsbmZjMjNcbGV2ZWxuZmNuMjNcbGV2ZWxqYzBcbGV2ZWxq Y24wXGxldmVsZm9sbG93MFxsZXZlbHN0YXJ0YXQwXGxldmVsb2xkXGxldmVsc3BhY2UwXGxldmVs aW5kZW50MHtcbGV2ZWx0ZXh0DQpcJzAxXHUtMzk4NiA/O317XGxldmVsbnVtYmVyczt9XGYxMFxm czEyXGZiaWFzMCB9fVxsczJ9e1xsaXN0b3ZlcnJpZGVcbGlzdGlkLTJcbGlzdG92ZXJyaWRlY291 bnQxe1xsZm9sZXZlbFxsaXN0b3ZlcnJpZGVmb3JtYXR7XGxpc3RsZXZlbFxsZXZlbG5mYzIzXGxl dmVsbmZjbjIzXGxldmVsamMwXGxldmVsamNuMFxsZXZlbGZvbGxvdzBcbGV2ZWxzdGFydGF0MFxs ZXZlbG9sZFxsZXZlbHNwYWNlMFxsZXZlbGluZGVudDB7XGxldmVsdGV4dA0KXCcwMVx1LTM5Nzcg Pzt9e1xsZXZlbG51bWJlcnM7fVxmMTBcZnMyOFxmYmlhczAgfX1cbHMzfXtcbGlzdG92ZXJyaWRl XGxpc3RpZC0yXGxpc3RvdmVycmlkZWNvdW50MXtcbGZvbGV2ZWxcbGlzdG92ZXJyaWRlZm9ybWF0 e1xsaXN0bGV2ZWxcbGV2ZWxuZmMyM1xsZXZlbG5mY24yM1xsZXZlbGpjMFxsZXZlbGpjbjBcbGV2 ZWxmb2xsb3cwXGxldmVsc3RhcnRhdDBcbGV2ZWxvbGRcbGV2ZWxzcGFjZTBcbGV2ZWxpbmRlbnQw e1xsZXZlbHRleHQNClwnMDFcdS0zOTg2ID87fXtcbGV2ZWxudW1iZXJzO31cZjEwXGZzMTRcZmJp YXMwIH19XGxzNH17XGxpc3RvdmVycmlkZVxsaXN0aWQtMlxsaXN0b3ZlcnJpZGVjb3VudDF7XGxm b2xldmVsXGxpc3RvdmVycmlkZWZvcm1hdHtcbGlzdGxldmVsXGxldmVsbmZjMjNcbGV2ZWxuZmNu MjNcbGV2ZWxqYzBcbGV2ZWxqY24wXGxldmVsZm9sbG93MFxsZXZlbHN0YXJ0YXQwXGxldmVsb2xk XGxldmVsc3BhY2UwXGxldmVsaW5kZW50MHtcbGV2ZWx0ZXh0DQpcJzAxXHUtMzk3NyA/O317XGxl dmVsbnVtYmVyczt9XGYxMFxmczMyXGZiaWFzMCB9fVxsczV9e1xsaXN0b3ZlcnJpZGVcbGlzdGlk LTJcbGlzdG92ZXJyaWRlY291bnQxe1xsZm9sZXZlbFxsaXN0b3ZlcnJpZGVmb3JtYXR7XGxpc3Rs ZXZlbFxsZXZlbG5mYzIzXGxldmVsbmZjbjIzXGxldmVsamMwXGxldmVsamNuMFxsZXZlbGZvbGxv dzBcbGV2ZWxzdGFydGF0MFxsZXZlbG9sZFxsZXZlbHNwYWNlMFxsZXZlbGluZGVudDB7XGxldmVs dGV4dA0KXCcwMVx1LTM5ODYgPzt9e1xsZXZlbG51bWJlcnM7fVxmMTBcZnMxN1xmYmlhczAgfX1c bHM2fXtcbGlzdG92ZXJyaWRlXGxpc3RpZDE0NDExNDU1NTRcbGlzdG92ZXJyaWRlY291bnQwXGxz N317XGxpc3RvdmVycmlkZVxsaXN0aWQxOTc2NjY0MDFcbGlzdG92ZXJyaWRlY291bnQwXGxzOH17 XGxpc3RvdmVycmlkZVxsaXN0aWQ5MTc1MTU4MTlcbGlzdG92ZXJyaWRlY291bnQwXGxzOX17XGxp c3RvdmVycmlkZVxsaXN0aWQ5NDYyMzIzMDcNClxsaXN0b3ZlcnJpZGVjb3VudDBcbHMxMH17XGxp c3RvdmVycmlkZVxsaXN0aWQxMzkyNDU4MTIyXGxpc3RvdmVycmlkZWNvdW50MFxsczExfX17XCpc cnNpZHRibCBccnNpZDcxNTk1XHJzaWQ1MjY4OTdccnNpZDM1NjA3NjJccnNpZDQzNTUzNThccnNp ZDEwODM3MzkyXHJzaWQxMTAyMjIyNFxyc2lkMTQ2OTU0OTlccnNpZDE0NzAwMjI5fXtcKlxnZW5l cmF0b3IgTWljcm9zb2Z0IFdvcmQgMTAuMC40MjE5O317XGluZm8NCntcYXV0aG9yIENocmlzdGlh biBIdWl0ZW1hfXtcb3BlcmF0b3IgQ2hyaXN0aWFuIEh1aXRlbWF9e1xjcmVhdGltXHlyMjAwM1xt bzNcZHkxOVxocjEzXG1pbjQ3fXtccmV2dGltXHlyMjAwM1xtbzNcZHkxOVxocjE1XG1pbjh9e1x2 ZXJzaW9uMn17XGVkbWluczgxfXtcbm9mcGFnZXM0fXtcbm9md29yZHMxNDAwfXtcbm9mY2hhcnM3 OTgwfXtcKlxjb21wYW55IE1pY3Jvc29mdCBDb3Jwb3JhdGlvbn17XG5vZmNoYXJzd3M5MzYyfQ0K e1x2ZXJuMTY0Njl9fVx3aWRvd2N0cmxcZnRuYmpcYWVuZGRvY1xub3hsYXR0b3llblxleHBzaHJ0 blxub3VsdHJsc3BjXGRudGJsbnNiZGJcbm9zcGFjZWZvcnVsXGh5cGhjYXBzMFxob3J6ZG9jXGRn aHNwYWNlMTIwXGRndnNwYWNlMTIwXGRnaG9yaWdpbjE3MDFcZGd2b3JpZ2luMTk4NFxkZ2hzaG93 MFxkZ3ZzaG93Mw0KXGpjb21wcmVzc1x2aWV3a2luZDFcdmlld3NjYWxlMTAwXG5vbG5odGFkanRi bFx2aWV3bm9ib3VuZDFccnNpZHJvb3QxNDcwMDIyOSBcZmV0MFxzZWN0ZCBcbGluZXgwXHNlY3Rk ZWZhdWx0Y2xcc2Z0bmJqIHtcKlxwbnNlY2x2bDFccG51Y3JtXHBuc3RhcnQxXHBuaW5kZW50NzIw XHBuaGFuZyB7XHBudHh0YSAufX17XCpccG5zZWNsdmwyXHBudWNsdHJccG5zdGFydDFccG5pbmRl bnQ3MjBccG5oYW5nIHtccG50eHRhIC59fXtcKlxwbnNlY2x2bDMNClxwbmRlY1xwbnN0YXJ0MVxw bmluZGVudDcyMFxwbmhhbmcge1xwbnR4dGEgLn19e1wqXHBuc2VjbHZsNFxwbmxjbHRyXHBuc3Rh cnQxXHBuaW5kZW50NzIwXHBuaGFuZyB7XHBudHh0YSApfX17XCpccG5zZWNsdmw1XHBuZGVjXHBu c3RhcnQxXHBuaW5kZW50NzIwXHBuaGFuZyB7XHBudHh0YiAofXtccG50eHRhICl9fXtcKlxwbnNl Y2x2bDZccG5sY2x0clxwbnN0YXJ0MVxwbmluZGVudDcyMFxwbmhhbmcge1xwbnR4dGIgKH17XHBu dHh0YSApfX0NCntcKlxwbnNlY2x2bDdccG5sY3JtXHBuc3RhcnQxXHBuaW5kZW50NzIwXHBuaGFu ZyB7XHBudHh0YiAofXtccG50eHRhICl9fXtcKlxwbnNlY2x2bDhccG5sY2x0clxwbnN0YXJ0MVxw bmluZGVudDcyMFxwbmhhbmcge1xwbnR4dGIgKH17XHBudHh0YSApfX17XCpccG5zZWNsdmw5XHBu bGNybVxwbnN0YXJ0MVxwbmluZGVudDcyMFxwbmhhbmcge1xwbnR4dGIgKH17XHBudHh0YSApfX1c cGFyZFxwbGFpbiANClxzMVxxbCBcbGkwXHJpMFxub3dpZGN0bHBhclxmYWF1dG9cb3V0bGluZWxl dmVsMFxyaW4wXGxpbjBcaXRhcDBccGFyYXJzaWQ1MjY4OTcgXGYzNVxmczM2XGxhbmcxMDMzXGxh bmdmZTEwMzNcY2dyaWRcbGFuZ25wMTAzM1xsYW5nZmVucDEwMzMge1xpbnNyc2lkMTA4MzczOTIg RHVhbCBIb21pbmcgRXhwZXJpbWVudA0KXHBhciB9XHBhcmRccGxhaW4gXHFsIFxsaTBccmkwXHdp ZGN0bHBhclxhc3BhbHBoYVxhc3BudW1cZmFhdXRvXGFkanVzdHJpZ2h0XHJpbjBcbGluMFxpdGFw MFxwYXJhcnNpZDUyNjg5NyBcZnMyNFxsYW5nMTAzM1xsYW5nZmUxMDMzXGNncmlkXGxhbmducDEw MzNcbGFuZ2ZlbnAxMDMzIHtcaW5zcnNpZDEwODM3MzkyXGNoYXJyc2lkNTI2ODk3IENocmlzdGlh bn17XGluc3JzaWQxMDgzNzM5MiAgSHVpdGVtYX17XGluc3JzaWQxNDcwMDIyOSANCiwgRGF2aWQg S2Vzc2Vuc317XGluc3JzaWQxMDgzNzM5MiBcbGluZSANClxwYXIge1xsaXN0dGV4dFxwYXJkXHBs YWluXHMxIFxmMzVcZnMzNiBcaGljaFxhZjM1XGRiY2hcYWYwXGxvY2hcZjM1IDFcdGFifX1ccGFy ZFxwbGFpbiBcczFccWwgXGZpLTQzMlxsaTQzMlxyaTBcbm93aWRjdGxwYXJcamNsaXN0dGFiXHR4 NDMyXGZhYXV0b1xsczdcb3V0bGluZWxldmVsMFxyaW4wXGxpbjQzMlxpdGFwMFxwYXJhcnNpZDE0 NzAwMjI5IA0KXGYzNVxmczM2XGxhbmcxMDMzXGxhbmdmZTEwMzNcY2dyaWRcbGFuZ25wMTAzM1xs YW5nZmVucDEwMzMge1xpbnNyc2lkMTA4MzczOTIgU2ltcGxlIGR1YWwgaG9taW5nIHByb2JsZW0g c3RhdGVtZW50DQpccGFyIH1ccGFyZFxwbGFpbiBccWwgXGxpMFxyaTBcd2lkY3RscGFyXGFzcGFs cGhhXGFzcG51bVxmYWF1dG9cYWRqdXN0cmlnaHRccmluMFxsaW4wXGl0YXAwXHBhcmFyc2lkMTQ3 MDAyMjkgXGZzMjRcbGFuZzEwMzNcbGFuZ2ZlMTAzM1xjZ3JpZFxsYW5nbnAxMDMzXGxhbmdmZW5w MTAzMyB7XGluc3JzaWQxNDcwMDIyOSANCkluIG9yZGVyIHRvIG1ha2UgcHJvZ3Jlc3MgdG93YXJk cyBhbiBJUHY2IHNpdGUgbXVsdGktaG9taW5nIHNvbHV0aW9uLCB3ZSBwcm9wb3NlIHRvIHN0YXJ0 IHdpdGggYSBzaW1wbGUgcHJvYmxlbTogaG93IHRvIG11bHRpLWhvbWUgdGhlIHNpbXBsZXN0IHNp dGUsIGkuZS4gYSBzaXRlIGNvbXBvc2VkIG9mIGEgc2luZ2xlIGxpbmssIGUuZy4gYSBzd2l0Y2hl ZCBFdGhlcm5ldCBuZXR3b3JrLn17XGluc3JzaWQxMDgzNzM5MiANClxwYXIgfXtcaW5zcnNpZDE0 NzAwMjI5IA0KXHBhciBXZSBiZWxpZXZlIHRoYXQgYWRkcmVzc2luZyB0aGUgcHJvYmxlbSBvZiBz aW1wbGUsIHNtYWxsIG5ldHdvcmtzIGlzIGJvdGggdXJnZW50IGFuZCB1c2VmdWwuIFByb3ZpZGlu ZyBhIHNpbXBsZSBzb2x1dGlvbiBmb3IgdGhlIG1vc3QgbnVtZXJvdXMgbmV0d29ya3MgZHJhc3Rp Y2FsbHkgcmVkdWNlcyB0aGUgZGFuZ2VyIHRoYXQgZ2VuZXJhbGl6ZWQgbXVsdGktaG9taW5nIHBv c2VzIHRvIHRoZSBJbnRlcm5ldC4gDQpBIHNtYWxsIG5ldHdvcmsgc29sdXRpb24gbWF5IG9yIG1h eSBub3QgYmUgZWFzaWx5IGV4dGVuc2libGUgdG8gbGFyZ2VyIG5ldHdvcmtzLCBidXQgd2Uga25v dyB0aGF0IHRoZXJlIGFyZSBvcmRlciBvZiBtYWduaXR1ZGUgbGVzcyBsYXJnZSBuZXR3b3JrcyB0 aGFuIHNtYWxsLiBJZiB3ZSBoYXZlIGEgc29sdXRpb24gZm9yIHRoZSBzbWFsbCBuZXR3b3Jrcywg dGhlIHNjb3BlIG9mIHRoZSByZW1haW5pbmcgcHJvYmxlbSB3aWxsIFwnOTNvbmx5DQpcJzk0IGJl IHRoZSBodW5kcmVkcyBvZiB0aG91c2FuZHMgb2YgbGFyZ2VyIG5ldHdvcmtzLCByYXRoZXIgdGhh biB0aGUgaHVuZHJlZHMgb2YgbWlsbGlvbnMgb2YgaG9tZSBuZXR3b3Jrcy4NClxwYXIgDQpccGFy IE1hbnkgc21hbGwgYnVzaW5lc3MgbmV0d29ya3MgdXNlIGEgc2ltcGxlIHBhdHRlcm4gb2YgbXVs dGktaG9taW5nIHRvZGF5OiB0aGUgfXtcaW5zcnNpZDQzNTUzNTggdmVyeSB9e1xpbnNyc2lkMTQ3 MDAyMjkgc21hbGwgYnVzaW5lc3MgbmV0d29yayBpcyBjb21wb3NlZCBvZiBhIHN3aXRjaGVkIEV0 aGVybmV0LCBjb21iaW5pbmcgZml4ZWQgbGluZSBhbmQgd2lyZWxlc3MgbGlua3N9e1xpbnNyc2lk NDM1NTM1OCA7DQogaXQgY29ubmVjdHMgdG8gdGhlIEludGVybmV0IHRocm91Z2ggdHdvIGluZGVw ZW5kZW50IGNvbm5lY3Rpb25zLCBzdWNoIGFzIHR3byBEU0wgbGluZXMuIFRoZXJlIGlzIG5vIGNv b3JkaW5hdGlvbiBiZXR3ZWVuIHRoZSB0d28gcHJvdmlkZXJzLiBJbiBhIHR5cGljYWwgSVB2NCBz ZXQtdXAsIGVhY2ggSW50ZXJuZXQgY29ubmVjdGlvbiB0ZXJtaW5hdGVzIGluIGEgZGlmZmVyZW50 IE5BVC9GaXJld2FsbDsgb25lIGNvbm5lY3Rpb24gaXMNCiB1c2VkIGFzIGJhY2stdXAsIGFuZCBp cyB0dXJuZWQgb24gaWYgdGhlIG90aGVyIGNvbm5lY3Rpb24gZmFpbHMuDQpccGFyIA0KXHBhciBP dGhlciBleGFtcGxlcyBvZiB0aGlzIHNpbXBsZSBtdWx0aS1ob21pbmcgcGF0dGVybiBpbmNsdWRl IGhvbWUgbmV0d29ya3MgY29ubmVjdGVkIHRvIGEgYnJvYWRiYW5kIHNlcnZpY2UgYnV0IGFsc28g bWFpbnRhaW5pbmcgYSBkaWFsLXVwIGNvbm5lY3Rpb24gZm9yIGJhY2stdXA7IGFuZCBob21lIG5l dHdvcmtzIGNvbm5lY3RlZCB0byB0d28gYnJvYWRiYW5kIGNvbm5lY3Rpb25zIHN1Y2ggDQphcyBE U0wgYW5kIGNhYmxlLCBvciBwZXJoYXBzIHdpcmVsZXNzIHNlcnZpY2VzLg0KXHBhciANClxwYXIg e1xsaXN0dGV4dFxwYXJkXHBsYWluXHMxIFxmMzVcZnMzNlxpbnNyc2lkNDM1NTM1OFxjaGFycnNp ZDQzNTUzNTggXGhpY2hcYWYzNVxkYmNoXGFmMFxsb2NoXGYzNSAyXHRhYn19XHBhcmRccGxhaW4g XHMxXHFsIFxmaS00MzJcbGk0MzJccmkwXG5vd2lkY3RscGFyXGpjbGlzdHRhYlx0eDQzMlxmYWF1 dG9cbHM3XG91dGxpbmVsZXZlbDBccmluMFxsaW40MzJcaXRhcDBccGFyYXJzaWQ0MzU1MzU4IA0K XGYzNVxmczM2XGxhbmcxMDMzXGxhbmdmZTEwMzNcY2dyaWRcbGFuZ25wMTAzM1xsYW5nZmVucDEw MzMge1xpbnNyc2lkNDM1NTM1OFxjaGFycnNpZDQzNTUzNTggRGVmaW5lIH17XGluc3JzaWQ0MzU1 MzU4IGEgc2ltcGxlIHNldCBvZiByZXF1aXJlbWVudHN9e1xpbnNyc2lkNDM1NTM1OFxjaGFycnNp ZDQzNTUzNTggDQpccGFyIH1ccGFyZFxwbGFpbiBccWwgXGxpMFxyaTBcd2lkY3RscGFyXGFzcGFs cGhhXGFzcG51bVxmYWF1dG9cYWRqdXN0cmlnaHRccmluMFxsaW4wXGl0YXAwXHBhcmFyc2lkMTQ3 MDAyMjkgXGZzMjRcbGFuZzEwMzNcbGFuZ2ZlMTAzM1xjZ3JpZFxsYW5nbnAxMDMzXGxhbmdmZW5w MTAzMyB7XGluc3JzaWQ0MzU1MzU4IEZvciB0aGUgc21hbGwgbmV0d29ya3MsIHRoZSBiYXNpYyBt b3RpdmF0aW9uIGZvciBtdWx0aS1ob21pbmcgaXMgcmVkdW5kYW5jeSANCmFuZCByZWxpYWJpbGl0 eS4gUmVsaWFiaWxpdHkgaXMgZGVmaW5lZCwgYXMgYSBtaW5pbXVtLCBhcyB0aGUgfXtcaW5zcnNp ZDcxNTk1IHBvc3NpYmlsaXR5IHRvIG1haW50YWluIG9wZXJhdGlvbiBpbiBjYXNlc317XGluc3Jz aWQ0MzU1MzU4ICBvZiBmYWlsdXJlIG9mIG9uZSB0aGUgSW50ZXJuZXQgcHJvdmlkZXIgY29ubmVj dGlvbnMuIA0KXHBhciB9e1xpbnNyc2lkNzE1OTUgDQpccGFyIFdlIHdpbGwgZXhwZWN0IHRoZSBz aXRlIHRvIGNvbnRhaW4gYm90aCBcJzkzc2ltcGxlXCc5NCBhbmQgXCc5M3NtYXJ0XCc5NCBob3N0 cy4gU2ltcGxlIGhvc3RzIGhhdmUgYW4gaW1wbGVtZW50YXRpb24gb2YgSVB2NiBjb25mb3JtYW50 IHRvIFJGQyAyNjQxOyBzbWFydCBob3N0cyBhcmUgc3VwcG9zZWQgdG8gYmUgdXBncmFkZWQgdG8g YmVjb21lIFwnOTNzaXRlIG11bHRpLWhvbWluZyBhd2FyZVwnOTQuIFRoZSByZWxpYWJpbGl0eSAN CmV4cGVjdGF0aW9uIGlzIHNsaWdodGx5IGRpZmZlcmVudCBmb3IgdGhlIHR3byBraW5kcyBvZiBo b3N0cy4gSW4gY2FzZSBvZiBmYWlsdXJlIG9mIGEgcHJvdmlkZXIgY29ubmVjdGlvbiwgdGhlIHNp bXBsZSBob3N0cyBtYXkgc3VmZmVyIGZyb20gYSB0ZW1wb3JhcnkgbG9zcyBvZiBjb25uZWN0aXZp dHk7IHRoZSBleHBlY3RhdGlvbiBpcyB0aGF0IG9wZXJhdGlvbiB3aWxsIHNob3J0bHkgcmVzdW1l IG92ZXIgdGhlIHJlbWFpbmluZyANCmNvbm5lY3Rpb247IHRoaXMgbWF0Y2hlcyB0aGUgZXhwZWN0 YXRpb24gb2YgY3VycmVudCBJUHY0IFwnOTNiYWNrLXVwXCc5NCBzZXJ2aWNlcy4gT24gdGhlIGNv bnRyYXJ5LCB0aGUgc21hcnQgaG9zdHMgYXJlIGV4cGVjdGVkIHRvIG9idGFpbiBiZXR0ZXIgc2Vy dmljZXM6IGVzdGFibGlzaGVkIFRDUC1JUCBjb25uZWN0aW9ucyBzaG91bGQgc3Vydml2ZSB0aGUg bG9zcyBvZiBvbmUgb2YgdGhlIHByb3ZpZGVyIGNvbm5lY3Rpb25zDQo7IGlmIGNvbm5lY3Rpb25z IGNhbm5vdCBiZSBtYWludGFpbmVkLCBvcGVyYXRpb24gc2hvdWxkIGF0IGxlYXN0IHJlc3VtZSBp bW1lZGlhdGVseTsgaXQgc2hvdWxkIGJlIHBvc3NpYmxlIHRvIHBlcmZvcm0gc29tZSBhbW91bnQg b2YgbG9hZCBiYWxhbmNpbmcgYmV0d2VlbiB0aGUgdHdvIGNvbm5lY3Rpb25zLg0KXHBhciB9e1xp bnNyc2lkNDM1NTM1OCANClxwYXIgV2UgYXNzdW1lIHRoYXQgaXQgaXMgZW50aXJlbHkgYWNjZXB0 YWJsZSB0aGF0IHRoZSB0d28gSW50ZXJuZXQgcHJvdmlkZXJzIGVhY2ggYWxsb2NhdGUgYSBcJzkz cHJvdmlkZXIgYWdncmVnYXRlZFwnOTQgcH17XGluc3JzaWQ3MTU5NSByZWZpeCB0byB0aGUgc21h bGwgc2l0ZS4gU2ltcGxlIGhvc3RzIGFyZSBleHBlY3RlZCB0byBhdXRvLWNvbmZpZ3VyZSBhZGRy ZXNzZXMgdXNpbmcgYXQgbGVhc3Qgb25lIG9mIHRoZXNlIHANCnJlZml4ZXM7IHNtYXJ0IGhvc3Rz IGFyZSBleHBlY3RlZCB0byBhdXRvLWNvbmZpZ3VyZSBhZGRyZXNzZXMgdXNpbmcgYm90aC4gSXQg aXMgcmVhc29uYWJsZSB0byBleHBlY3QgdGhhdCBob3N0cyBoYXZlIHRvIGJlIHJlbnVtYmV9e1xp bnNyc2lkMTQ2OTU0OTkgcmVkIGENCmZ0ZXIgYSBjb25uZWN0aXZpdHkgZXZlbnQsIGFsdGhvdWdo IHdlIGFsc28gZXhwZWN0IHRoYXQgYWRkcmVzc2VzIGNvbmZpZ3VyZWQgd2l0aCBvbmUgcHJlZml4 IHdpbGwgcmVtYWluIHZhbGlkIGFzIGxvbmcgYXMgdGhpcyBwcmVmaXggaXMgdmFsaWQufXtcaW5z cnNpZDQzNTUzNTggDQpccGFyIH17XGluc3JzaWQxNDY5NTQ5OSANClxwYXIgVGhlfXtcaW5zcnNp ZDEwODM3MzkyICBmb2xsb3dpbmcgc2VjdGlvbiBkZXRhaWxzIH17XGluc3JzaWQxNDY5NTQ5OSBz cGVjaWZpYyBwcm9ibGVtcyB0aGF0IG11c3QgYmUgc29sdmVkIGJ5IHRoZSBzaW1wbGUgbXVsdGkt aG9taW5nIHNvbHV0aW9uLg0KXHBhciB7XGxpc3R0ZXh0XHBhcmRccGxhaW5cczEgXGYzNVxmczM2 XGluc3JzaWQxMDgzNzM5MiBcaGljaFxhZjM1XGRiY2hcYWYwXGxvY2hcZjM1IDNcdGFifX1ccGFy ZFxwbGFpbiBcczFccWwgXGZpLTQzMlxsaTQzMlxyaTBcbm93aWRjdGxwYXJcamNsaXN0dGFiXHR4 NDMyXGZhYXV0b1xsczdcb3V0bGluZWxldmVsMFxyaW4wXGxpbjQzMlxpdGFwMFxwYXJhcnNpZDEw ODM3MzkyIA0KXGYzNVxmczM2XGxhbmcxMDMzXGxhbmdmZTEwMzNcY2dyaWRcbGFuZ25wMTAzM1xs YW5nZmVucDEwMzMge1xpbnNyc2lkMTA4MzczOTIgTX17XGluc3JzaWQxNDY5NTQ5OSB1bHRpLWhv bWluZyBpc3N1ZXN9e1xpbnNyc2lkMzU2MDc2MlxjaGFycnNpZDM1NjA3NjIgDQpccGFyIH1ccGFy ZFxwbGFpbiBccWwgXGxpMFxyaTBcd2lkY3RscGFyXGFzcGFscGhhXGFzcG51bVxmYWF1dG9cYWRq dXN0cmlnaHRccmluMFxsaW4wXGl0YXAwXHBhcmFyc2lkMTQ2OTU0OTkgXGZzMjRcbGFuZzEwMzNc bGFuZ2ZlMTAzM1xjZ3JpZFxsYW5nbnAxMDMzXGxhbmdmZW5wMTAzMyB7XGluc3JzaWQxMDgzNzM5 MiBUaGUgZml2ZX17XGluc3JzaWQxNDY5NTQ5OSANCiBtdWx0aWhvbWluZyBpc3N1ZXMgdGhhdCB3 ZSB3YW50IHRvIHNvbHZlIGFyZSBpbmdyZXNzIGZpbHRlcmluZywgYXZvaWRhbmNlIG9mIGEgXCc5 M2RlYWQgY29ubmVjdGlvblwnOTR9e1xpbnNyc2lkMTA4MzczOTIgIGZvciBvdXRib3VuZCBjb25u ZWN0aW9ucywgYXZvaWRhbmNlIG9mIGEgZGVhZCBhZGRyZXNzIGZvciBpbmJvdW5kIGNvbm5lY3Rp b25zfXtcaW5zcnNpZDE0Njk1NDk5ICwgDQpjb25uZWN0aW9uIG1haW50ZW5hbmNlIGFuZCBleGl0 IHNlbGVjdGlvbi59e1xpbnNyc2lkMzU2MDc2MiAgV2UgYmVsaWV2ZSB0aGF0IHRoZSBzb2x1dGlv biB0byB0aGVzZSBwcm9ibGVtcyBpcyBpbiB0aGUgcmVhbG0gb2YgZW5naW5lZXJpbmcsIG5vdCBy ZXNlYXJjaC4gRm9yIGVhY2ggcHJvYmxlbSwgd2UgZ2l2ZSBoaW50IG9mIG9uZSBvciBzZXZlcmFs IHBvc3NpYmxlIHNvbHV0aW9ucy4gV2UgYWxzbyBiZWxpZXZlIHRoYXQgcmVsYXRpdmVseSANCnNp bXBsZSBzb2x1dGlvbnMgYXJlIHBvc3NpYmxlLCBhbmQgc2hvdWxkIGJlIHByZWZlcnJlZCB0byBc JzkzaW5ub3ZhdGl2ZVwnOTQgY29uc3RydWN0cy59e1xpbnNyc2lkMzU2MDc2MlxjaGFycnNpZDE0 Njk1NDk5IA0KXHBhciB7XGxpc3R0ZXh0XHBhcmRccGxhaW5cczIgXGYzNVxmczMyXGluc3JzaWQx NDY5NTQ5OSBcaGljaFxhZjM1XGRiY2hcYWYwXGxvY2hcZjM1IDMuMVx0YWJ9fVxwYXJkXHBsYWlu IFxzMlxxbCBcZmktNTc2XGxpNTc2XHJpMFxub3dpZGN0bHBhclxqY2xpc3R0YWJcdHg1NzZcZmFh dXRvXGxzN1xpbHZsMVxvdXRsaW5lbGV2ZWwxXHJpbjBcbGluNTc2XGl0YXAwXHBhcmFyc2lkMTQ2 OTU0OTkgDQpcZjM1XGZzMzJcbGFuZzEwMzNcbGFuZ2ZlMTAzM1xjZ3JpZFxsYW5nbnAxMDMzXGxh bmdmZW5wMTAzMyB7XGluc3JzaWQxNDY5NTQ5OSBJfXtcaW5zcnNpZDEwODM3MzkyIG5ncmVzcyBm aWx0ZXJpbmcNClxwYXIgfVxwYXJkXHBsYWluIFxxbCBcbGkwXHJpMFx3aWRjdGxwYXJcYXNwYWxw aGFcYXNwbnVtXGZhYXV0b1xhZGp1c3RyaWdodFxyaW4wXGxpbjBcaXRhcDBccGFyYXJzaWQxNDY5 NTQ5OSBcZnMyNFxsYW5nMTAzM1xsYW5nZmUxMDMzXGNncmlkXGxhbmducDEwMzNcbGFuZ2ZlbnAx MDMzIHtcaW5zcnNpZDE0Njk1NDk5XGNoYXJyc2lkMTQ2OTU0OTkgV2UgYXNzdW1lIHRoYXQgZWFj aCBvZiB0aGUgSVNQIG1heSBwZXJmb3JtIGluZ3Jlc3MgDQpmaWx0ZXJpbmcsIGFuZCB3aWxsIHJl amVjdCBwYWNrZXRzIHdob3NlIHNvdXJjZSBhZGRyZXNzIGRvZXMgbm90IGJlbG9uZyB0byB0aGUg cHJlZml4IGFsbG9jYXRlZCB0byB0aGUgbmV0d29yayBieSB0aGF0IElTUC4gVGhpcyBsZWFkcyB0 byBhIHBvc3NpYmxlIGZhaWx1cmV9e1xpbnNyc2lkMTA4MzczOTJcY2hhcnJzaWQxNDY5NTQ5OSAg c2NlbmFyaW99e1xpbnNyc2lkMTQ2OTU0OTkgOn17DQpcaW5zcnNpZDEwODM3MzkyXGNoYXJyc2lk MTQ2OTU0OTkgDQpccGFyIHtcbGlzdHRleHRccGFyZFxwbGFpblxmM1xjaGFycnNpZDE0Njk1NDk5 IFxsb2NoXGFmM1xkYmNoXGFmMFxoaWNoXGYzIFwnYjdcdGFifX1ccGFyZCBccWwgXGZpLTM2MFxs aTcyMFxyaTBcd2lkY3RscGFyXGpjbGlzdHRhYlx0eDcyMFxhc3BhbHBoYVxhc3BudW1cZmFhdXRv XGxzOFxhZGp1c3RyaWdodFxyaW4wXGxpbjcyMFxpdGFwMFxwYXJhcnNpZDE0Njk1NDk5IHtcaW5z cnNpZDEwODM3MzkyXGNoYXJyc2lkMTQ2OTU0OTkgDQpIb3N0IGNob29zZSBzb3VyY2UgYWRkcmVz cyBBDQpccGFyIHtcbGlzdHRleHRccGFyZFxwbGFpblxmM1xjaGFycnNpZDE0Njk1NDk5IFxsb2No XGFmM1xkYmNoXGFmMFxoaWNoXGYzIFwnYjdcdGFifURlZmF1bHQgcm91dGUgbGVhZHMgdG8gcm91 dGVyIEINClxwYXIge1xsaXN0dGV4dFxwYXJkXHBsYWluXGYzXGNoYXJyc2lkMTQ2OTU0OTkgXGxv Y2hcYWYzXGRiY2hcYWYwXGhpY2hcZjMgXCdiN1x0YWJ9Um91dGVyIEIgZm9yd2FyZHMgdGhlIHBh Y2tldCB0byBJU1AgQg0KXHBhciB7XGxpc3R0ZXh0XHBhcmRccGxhaW5cZjNcY2hhcnJzaWQxNDY5 NTQ5OSBcbG9jaFxhZjNcZGJjaFxhZjBcaGljaFxmMyBcJ2I3XHRhYn1QYWNrZXQgaXMgZHJvcHBl ZCBieSBpbmdyZXNzIGZpbHRlcmluZy4NClxwYXIgfVxwYXJkIFxxbCBcbGkwXHJpMFx3aWRjdGxw YXJcYXNwYWxwaGFcYXNwbnVtXGZhYXV0b1xhZGp1c3RyaWdodFxyaW4wXGxpbjBcaXRhcDBccGFy YXJzaWQxNDY5NTQ5OSB7XGluc3JzaWQxNDY5NTQ5OSBUaGUgbXVsdGktaG9taW5nIHByb3Bvc2Fs IG11c3QgcHJlc2VudCBhIHNvbHV0aW9uIHRvIHRoaXMgcHJvYmxlbS4gDQpXZSBiZWxpZXZlIHRo YXQgdGhpcyBzb2x1dGlvbiBjYW4gYmUgZW5naW5lZXJlZCBieSBzaW1wbGUgaW1wcm92ZW1lbnRz IGluIHRoZSBzbWFsbCBzaXRlIGV4aXQgcm91dGVycywgc3VjaCBhcyB9e1xpbnNyc2lkMTA4Mzcz OTJcY2hhcnJzaWQxNDY5NTQ5OSBjaGVja317XGluc3JzaWQxNDY5NTQ5OSBpbmcgdGhlfXtcaW5z cnNpZDEwODM3MzkyXGNoYXJyc2lkMTQ2OTU0OTkgIHNvdXJjZSBhZGRyZXNzfXtcaW5zcnNpZDE0 Njk1NDk5IA0KIG9mIHRoZSBJbnRlcm5ldCBib3VuZCBwYWNrZXRzIGFuZH17XGluc3JzaWQxMDgz NzM5MlxjaGFycnNpZDE0Njk1NDk5ICByZWRpcmVjdH17XGluc3JzaWQxNDY5NTQ5OSBpbmcgdGhl c2V9e1xpbnNyc2lkMTA4MzczOTJcY2hhcnJzaWQxNDY5NTQ5OSAgcGFja2V0fXtcaW5zcnNpZDE0 Njk1NDk5IHN9e1xpbnNyc2lkMTA4MzczOTJcY2hhcnJzaWQxNDY5NTQ5OSAgdG8gfXtcaW5zcnNp ZDE0Njk1NDk5IHRoZSB9ew0KXGluc3JzaWQxMDgzNzM5MlxjaGFycnNpZDE0Njk1NDk5IFwnOTNy aWdodFwnOTQgfXtcaW5zcnNpZDE0Njk1NDk5IGV4aXQgfXtcaW5zcnNpZDEwODM3MzkyXGNoYXJy c2lkMTQ2OTU0OTkgcm91dGVyIGluIGNhc2Ugb2YgcHJvYmxlbX17XGluc3JzaWQxNDY5NTQ5OSAu IFRoaXMgc29sdXRpb24gc2hvdWxkIG5vdCBkZXBlbmQgb24gYW55IHBhcnRpY3VsYXIgaG9zdCBi ZWhhdmlvciwgYmV5b25kIHdoYXQgaQ0KcyBtYW5kYXRlZCBieSBSRkMgMjY0MTsgaG93ZXZlciwg c21hcnQgaG9zdHMgbWF5IGltcHJvdmUgb24gdGhlIGJhc2ljIHNvbHV0aW9uLCBlLmcuIGJ5fXtc aW5zcnNpZDEwODM3MzkyXGNoYXJyc2lkMTQ2OTU0OTkgIHNlbGVjdH17XGluc3JzaWQxNDY5NTQ5 OSBpbmcgYSBuZXh0IGhvcCBleGl0fXtcaW5zcnNpZDEwODM3MzkyXGNoYXJyc2lkMTQ2OTU0OTkg IHJvdXRlciB9e1xpbnNyc2lkMTQ2OTU0OTkgDQphcyBhIGZ1bmN0aW9uIG9mIHRoZSBzb3VyY2Ug YWRkcmVzcy59e1xpbnNyc2lkMTA4MzczOTJcY2hhcnJzaWQxNDY5NTQ5OSANClxwYXIge1xsaXN0 dGV4dFxwYXJkXHBsYWluXHMyIFxmMzVcZnMzMlxpbnNyc2lkNTI2ODk3IFxoaWNoXGFmMzVcZGJj aFxhZjBcbG9jaFxmMzUgMy4yXHRhYn19XHBhcmRccGxhaW4gXHMyXHFsIFxmaS01NzZcbGk1NzZc cmkwXG5vd2lkY3RscGFyXGpjbGlzdHRhYlx0eDU3NlxmYWF1dG9cbHM3XGlsdmwxXG91dGxpbmVs ZXZlbDFccmluMFxsaW41NzZcaXRhcDBccGFyYXJzaWQ1MjY4OTcgDQpcZjM1XGZzMzJcbGFuZzEw MzNcbGFuZ2ZlMTAzM1xjZ3JpZFxsYW5nbnAxMDMzXGxhbmdmZW5wMTAzMyB7XGluc3JzaWQ1MjY4 OTcgQX17XGluc3JzaWQxMDgzNzM5MiB2b2lkIHVzaW5nIGRlYWQgcm91dGVyfXtcaW5zcnNpZDEw ODM3MzkyICBmb3Igb3V0Ym91bmQgY29ubmVjdGlvbnN9e1xpbnNyc2lkMTA4MzczOTIgDQpccGFy IH1ccGFyZFxwbGFpbiBccWwgXGxpMFxyaTBcd2lkY3RscGFyXGFzcGFscGhhXGFzcG51bVxmYWF1 dG9cYWRqdXN0cmlnaHRccmluMFxsaW4wXGl0YXAwXHBhcmFyc2lkNTI2ODk3IFxmczI0XGxhbmcx MDMzXGxhbmdmZTEwMzNcY2dyaWRcbGFuZ25wMTAzM1xsYW5nZmVucDEwMzMge1xpbnNyc2lkNTI2 ODk3IFRoZSBwdXJwb3NlIG9mIG11bHRpLWhvbWluZyBpcyB0byBwcm92aWRlIHJlZHVuZGFuY3ks IGFuZCB0byBhdm9pZCB0aGUgZm9sbG93aW5nIA0KZn17XGluc3JzaWQxMDgzNzM5MlxjaGFycnNp ZDUyNjg5NyBhaWx1cmUgc2NlbmFyaW99e1xpbnNyc2lkNTI2ODk3IDp9e1xpbnNyc2lkMTA4Mzcz OTJcY2hhcnJzaWQ1MjY4OTcgDQpccGFyIHtcbGlzdHRleHRccGFyZFxwbGFpblxmM1xjaGFycnNp ZDUyNjg5NyBcbG9jaFxhZjNcZGJjaFxhZjBcaGljaFxmMyBcJ2I3XHRhYn19XHBhcmQgXHFsIFxm aS0zNjBcbGk3MjBccmkwXHdpZGN0bHBhclxqY2xpc3R0YWJcdHg3MjBcYXNwYWxwaGFcYXNwbnVt XGZhYXV0b1xsczlcYWRqdXN0cmlnaHRccmluMFxsaW43MjBcaXRhcDBccGFyYXJzaWQ1MjY4OTcg e1xpbnNyc2lkMTA4MzczOTJcY2hhcnJzaWQ1MjY4OTcgDQpSb3V0ZXIgQSBpcyBkZWFkLCBvciBs aW5rIHRvIElTUCBBIGlzIGRlYWQNClxwYXIge1xsaXN0dGV4dFxwYXJkXHBsYWluXGYzXGNoYXJy c2lkNTI2ODk3IFxsb2NoXGFmM1xkYmNoXGFmMFxoaWNoXGYzIFwnYjdcdGFifUhvc3QgY29udGlu dWUgc2VuZGluZyB1c2luZyBzb3VyY2UgYWRkcmVzcyBBDQpccGFyIHtcbGlzdHRleHRccGFyZFxw bGFpblxmM1xpbnNyc2lkNTI2ODk3IFxsb2NoXGFmM1xkYmNoXGFmMFxoaWNoXGYzIFwnYjdcdGFi fX17XGluc3JzaWQ1MjY4OTcgQmVjYXVzZSBvZiBpbmdyZXNzIGZpbHRlcmluZywgcn17XGluc3Jz aWQxMDgzNzM5MlxjaGFycnNpZDUyNjg5NyBvdXRlciBCIGNhbm5vdCBmb3J3YXJkIHRoZSBwYWNr ZXRzDQpccGFyIH1ccGFyZCBccWwgXGxpMFxyaTBcd2lkY3RscGFyXGFzcGFscGhhXGFzcG51bVxm YWF1dG9cYWRqdXN0cmlnaHRccmluMFxsaW4wXGl0YXAwXHBhcmFyc2lkNTI2ODk3IHtcaW5zcnNp ZDUyNjg5NyBUaGUgbXVsdGktaG9taW5nIHByb3Bvc2FsIG11c3QgcHJlc2VudCBhIHNvbHV0aW9u IHRvIHRoaXMgcHJvYmxlbSwgYW5kIHRoZSBzb2x1dGlvbiBtdXN0DQogd29yayBmb3IgYm90aCBz aW1wbGUgaG9zdHMgYW5kIHNtYXJ0IGhvc3RzLiBXZSBiZWxpZXZlIHRoYXQgYSBzb2x1dGlvbiBj YW4gYmUgZW5naW5lZXJlZCBieSBhbiBhcHByb3ByaWF0ZSB1c2Ugb2YgXCc5M3JvdXRlciBhbm5v dW5jZVwnOTQNCiBtZXNzYWdlcywgc3VjaCBhcyBzdG9wcGluZyBhZHZlcnRpc2VtZW50IG9mIGEg cHJlZml4IGlmIHRoZSBjb25uZWN0aW9uIGlzIHVuYXZhaWxhYmxlLCBvciBwb3NzaWJseSBhZHZl cnRpc2luZyB0aGlzIHByZWZpeCBhcyBcJzkzZGVwcmVjYXRlZC5cJzk0IH17XGluc3JzaWQxMDgz NzM5MlxjaGFycnNpZDUyNjg5NyBTbWFydCBob3N0fXtcaW5zcnNpZDUyNjg5NyAgbWF5IGltcHJv dmUgb24gdGhhdCBzb2x1dGlvbiBieSBpbXBsZW1lbnRpbmcNCiBkZXRlY3RpbmcgdGhlIGxvc3Mg b2YgY29ubmVjdGl2aXR5IGluZGVwZW5kZW50bHkgb2YgdGhlIHJvdXRlciBhZHZlcnRpc2VtZW50 cywgYW5kIGF1dG9tYXRpY2FsbHkgcHJlZmVycmluZyB0aGUgb3RoZXIgfXtcaW5zcnNpZDEwODM3 MzkyXGNoYXJyc2lkNTI2ODk3IGFkZHJlc3N9e1xpbnNyc2lkNTI2ODk3ICBmb3IgbmV3IGNvbm5l Y3Rpb25zLn17XGluc3JzaWQxMDgzNzM5MiANClxwYXIge1xsaXN0dGV4dFxwYXJkXHBsYWluXHMy IFxmMzVcZnMzMlxpbnNyc2lkMTA4MzczOTIgXGhpY2hcYWYzNVxkYmNoXGFmMFxsb2NoXGYzNSAz LjNcdGFifX1ccGFyZFxwbGFpbiBcczJccWwgXGZpLTU3NlxsaTU3NlxyaTBcbm93aWRjdGxwYXJc amNsaXN0dGFiXHR4NTc2XGZhYXV0b1xsczdcaWx2bDFcb3V0bGluZWxldmVsMVxyaW4wXGxpbjU3 NlxpdGFwMFxwYXJhcnNpZDEwODM3MzkyIA0KXGYzNVxmczMyXGxhbmcxMDMzXGxhbmdmZTEwMzNc Y2dyaWRcbGFuZ25wMTAzM1xsYW5nZmVucDEwMzMge1xpbnNyc2lkMTA4MzczOTIgQXZvaWQgdXNp bmcgZGVhZCBhZGRyZXNzIGZvciBvdXRib3VuZCBjb25uZWN0aW9ucw0KXHBhciB9XHBhcmRccGxh aW4gXHFsIFxsaTBccmkwXHdpZGN0bHBhclxhc3BhbHBoYVxhc3BudW1cZmFhdXRvXGFkanVzdHJp Z2h0XHJpbjBcbGluMFxpdGFwMFxwYXJhcnNpZDEwODM3MzkyIFxmczI0XGxhbmcxMDMzXGxhbmdm ZTEwMzNcY2dyaWRcbGFuZ25wMTAzM1xsYW5nZmVucDEwMzMge1xpbnNyc2lkMTA4MzczOTIgQSB2 YXJpYXRpb24gb2YgdGhlIHByZXZpb3VzIGZ9e1xpbnNyc2lkMTA4MzczOTJcY2hhcnJzaWQ1MjY4 OTcgDQphaWx1cmUgc2NlbmFyaW99e1xpbnNyc2lkMTA4MzczOTIgIG9jY3VycyB3aGVuIGEgc2Vy dmljZSBpcyBob3N0ZWQgb24gdGhlIHNtYWxsIG5ldHdvcms6fXtcaW5zcnNpZDEwODM3MzkyXGNo YXJyc2lkNTI2ODk3IA0KXHBhciB7XGxpc3R0ZXh0XHBhcmRccGxhaW5cZjNcaW5zcnNpZDEwODM3 MzkyIFxsb2NoXGFmM1xkYmNoXGFmMFxoaWNoXGYzIFwnYjdcdGFifX1ccGFyZCBccWwgXGZpLTM2 MFxsaTcyMFxyaTBcd2lkY3RscGFyXGpjbGlzdHRhYlx0eDcyMFxhc3BhbHBoYVxhc3BudW1cZmFh dXRvXGxzOVxhZGp1c3RyaWdodFxyaW4wXGxpbjcyMFxpdGFwMFxwYXJhcnNpZDEwODM3MzkyIHtc aW5zcnNpZDEwODM3MzkyIA0KU2VydmljZSBhZHZlcnRpc2VzIGJvdGggYWRkcmVzcyBBIGFuZCBh ZGRyZXNzIEIgaW4gdGhlIEROUw0KXHBhciB7XGxpc3R0ZXh0XHBhcmRccGxhaW5cZjNcaW5zcnNp ZDEwODM3MzkyXGNoYXJyc2lkNTI2ODk3IFxsb2NoXGFmM1xkYmNoXGFmMFxoaWNoXGYzIFwnYjdc dGFifX17XGluc3JzaWQxMDgzNzM5MlxjaGFycnNpZDUyNjg5NyBSb3V0ZXIgQSBpcyBkZWFkLCBv ciBsaW5rIHRvIElTUCBBIGlzIGRlYWQNClxwYXIge1xsaXN0dGV4dFxwYXJkXHBsYWluXGYzXGlu c3JzaWQxMDgzNzM5MiBcbG9jaFxhZjNcZGJjaFxhZjBcaGljaFxmMyBcJ2I3XHRhYn19e1xpbnNy c2lkMTA4MzczOTIgQSByZW1vdGUgY2xpZW50IHNlbGVjdHMgfXtcaW5zcnNpZDEwODM3MzkyXGNo YXJyc2lkNTI2ODk3IGFkZHJlc3MgQX17XGluc3JzaWQxMDgzNzM5MiAgdG8gcmVhY2ggdGhlIHNl cnZpY2V9e1xpbnNyc2lkMTA4MzczOTJcY2hhcnJzaWQ1MjY4OTcgDQpccGFyIHtcbGlzdHRleHRc cGFyZFxwbGFpblxmM1xpbnNyc2lkMTA4MzczOTIgXGxvY2hcYWYzXGRiY2hcYWYwXGhpY2hcZjMg XCdiN1x0YWJ9fXtcaW5zcnNpZDEwODM3MzkyIFRoZSBjb25uZWN0aW9uIGZhaWxzfXtcaW5zcnNp ZDEwODM3MzkyXGNoYXJyc2lkNTI2ODk3IA0KXHBhciB9XHBhcmQgXHFsIFxsaTBccmkwXHdpZGN0 bHBhclxhc3BhbHBoYVxhc3BudW1cZmFhdXRvXGFkanVzdHJpZ2h0XHJpbjBcbGluMFxpdGFwMFxw YXJhcnNpZDEwODM3MzkyIHtcaW5zcnNpZDEwODM3MzkyIFRoZSBtdWx0aS1ob21pbmcgcHJvcG9z YWwgbXVzdCBwcmVzZW50IGEgc29sdXRpb24gdG8gdGhpcyBwcm9ibGVtLCBhbmQgdGhlIHNvbHV0 aW9uIG11c3Qgd29yayBmb3IgYm90aCBzaW1wbGUgaG9zdHMgYW5kIHNtYXJ0IGhvc3RzLg0KIEEg cG9zc2libGUgc29sdXRpb24gaXMgdG8gZXhwZWN0IHJlbW90ZSBob3N0cyB0byByZXRyeSB0aGUg Y29ubmVjdGlvbiBhdHRlbXB0IHVzaW5nIHRoZSBzZWNvbmQgYWRkcmVzczsgYW5vdGhlciBzb2x1 dGlvbiBpcyB0byBzb21laG93IHVwZGF0ZSB0aGUgRE5TLn17XGluc3JzaWQxMDgzNzM5MlxjaGFy cnNpZDUyNjg5NyANClxwYXIge1xsaXN0dGV4dFxwYXJkXHBsYWluXHMyIFxmMzVcZnMzMlxpbnNy c2lkNTI2ODk3IFxoaWNoXGFmMzVcZGJjaFxhZjBcbG9jaFxmMzUgMy40XHRhYn19XHBhcmRccGxh aW4gXHMyXHFsIFxmaS01NzZcbGk1NzZccmkwXG5vd2lkY3RscGFyXGpjbGlzdHRhYlx0eDU3Nlxm YWF1dG9cbHM3XGlsdmwxXG91dGxpbmVsZXZlbDFccmluMFxsaW41NzZcaXRhcDBccGFyYXJzaWQ1 MjY4OTcgDQpcZjM1XGZzMzJcbGFuZzEwMzNcbGFuZ2ZlMTAzM1xjZ3JpZFxsYW5nbnAxMDMzXGxh bmdmZW5wMTAzMyB7XGluc3JzaWQ1MjY4OTcgTX17XGluc3JzaWQxMDgzNzM5MiBhaW50YWlufXtc aW5zcnNpZDUyNjg5NyBpbmd9e1xpbnNyc2lkMTA4MzczOTIgIGNvbm5lY3Rpb259e1xpbnNyc2lk NTI2ODk3IHN9e1xpbnNyc2lkMTA4MzczOTIgDQpccGFyIH1ccGFyZFxwbGFpbiBccWwgXGxpMFxy aTBcd2lkY3RscGFyXGFzcGFscGhhXGFzcG51bVxmYWF1dG9cYWRqdXN0cmlnaHRccmluMFxsaW4w XGl0YXAwXHBhcmFyc2lkNTI2ODk3IFxmczI0XGxhbmcxMDMzXGxhbmdmZTEwMzNcY2dyaWRcbGFu Z25wMTAzM1xsYW5nZmVucDEwMzMge1xpbnNyc2lkNTI2ODk3IFNvbHZpbmcgdGhlIA0KaW5ncmVz cyBmaWx0ZXJpbmcgYW5kIGRlYWQgcm91dGVyIHByb2JsZW0gcHJvdmlkZXMgc21hbGwgc2l0ZSB3 aXRoIGEgZnVuY3Rpb25hbCBtdWx0aS1ob21pbmcgc29sdXRpb24sIGJ1dCBkb2VzIG5vdCByZXNv bHZlIHRoZSBmb2xsb3dpbmcgZn17XGluc3JzaWQxMDgzNzM5MlxjaGFycnNpZDUyNjg5NyBhaWx1 cmUgc2NlbmFyaW99e1xpbnNyc2lkNTI2ODk3IDp9e1xpbnNyc2lkMTA4MzczOTJcY2hhcnJzaWQ1 MjY4OTcgDQpccGFyIHtcbGlzdHRleHRccGFyZFxwbGFpblxmM1xjaGFycnNpZDUyNjg5NyBcbG9j aFxhZjNcZGJjaFxhZjBcaGljaFxmMyBcJ2I3XHRhYn19XHBhcmQgXHFsIFxmaS0zNjBcbGk3MjBc cmkwXHdpZGN0bHBhclxqY2xpc3R0YWJcdHg3MjBcYXNwYWxwaGFcYXNwbnVtXGZhYXV0b1xsczEw XGFkanVzdHJpZ2h0XHJpbjBcbGluNzIwXGl0YXAwXHBhcmFyc2lkNTI2ODk3IHtcaW5zcnNpZDEw ODM3MzkyXGNoYXJyc2lkNTI2ODk3IA0KSG9zdCBoYXMgY29ubmVjdGlvbiB3aXRoIHBlZXIgUCB1 c2luZyBhZGRyZXNzIEENClxwYXIge1xsaXN0dGV4dFxwYXJkXHBsYWluXGYzXGNoYXJyc2lkNTI2 ODk3IFxsb2NoXGFmM1xkYmNoXGFmMFxoaWNoXGYzIFwnYjdcdGFifVJvdXRlciBBIG9yIElTUCBB IGZhaWxzDQpccGFyIHtcbGlzdHRleHRccGFyZFxwbGFpblxmM1xjaGFycnNpZDUyNjg5NyBcbG9j aFxhZjNcZGJjaFxhZjBcaGljaFxmMyBcJ2I3XHRhYn1FeGlzdGluZyBjb25uZWN0aW9ucyBicmVh aw0KXHBhciB9XHBhcmQgXHFsIFxsaTBccmkwXHdpZGN0bHBhclxhc3BhbHBoYVxhc3BudW1cZmFh dXRvXGFkanVzdHJpZ2h0XHJpbjBcbGluMFxpdGFwMFxwYXJhcnNpZDUyNjg5NyB7XGluc3JzaWQ1 MjY4OTcgV2UgYWNjZXB0IHRoZSBsb3NzIG9mIGNvbm5lY3Rpb25zIGluIHRoZSBjYXNlIG9mIHRo ZSBzaW1wbGUgaG9zdHM7IHRoZSBzaW1wbGUgaG9zdHMgd2lsbCBzaW1wbHkgaGF2ZSB0byByZWVz dGFibGlzaCB0aGVpciBjb25uZWN0aW8NCm5zLiBIb3dldmVyLCB0aGUgbXVsdH17XGluc3JzaWQz NTYwNzYyIGktaG9taW5nIHByb3Bvc2FsIHNob3VsZCBwcm92aWRlIHNtYXJ0IGhvc3RzIHdpdGh9 e1xpbnNyc2lkNTI2ODk3ICBhIHNvbHV0aW9uIH17XGluc3JzaWQzNTYwNzYyIHRvIHRoaXMgcHJv YmxlbS4gV2UgYmVsaWV2ZSB0aGF0IGl0IGlzIHBvc3NpYmxlIHRvIGVuZ2luZWVyIHRoaXMgc29s dXRpb24gYnkgdXNpbmcgYSB2YXJpYXRpb24gb2YgTW9iaWxlIElQdjYufXsNClxpbnNyc2lkMTA4 MzczOTJcY2hhcnJzaWQ1MjY4OTcgDQpccGFyIHtcbGlzdHRleHRccGFyZFxwbGFpblxzMiBcZjM1 XGZzMzJcaW5zcnNpZDM1NjA3NjIgXGhpY2hcYWYzNVxkYmNoXGFmMFxsb2NoXGYzNSAzLjVcdGFi fX1ccGFyZFxwbGFpbiBcczJccWwgXGZpLTU3NlxsaTU3NlxyaTBcbm93aWRjdGxwYXJcamNsaXN0 dGFiXHR4NTc2XGZhYXV0b1xsczdcaWx2bDFcb3V0bGluZWxldmVsMVxyaW4wXGxpbjU3NlxpdGFw MFxwYXJhcnNpZDM1NjA3NjIgDQpcZjM1XGZzMzJcbGFuZzEwMzNcbGFuZ2ZlMTAzM1xjZ3JpZFxs YW5nbnAxMDMzXGxhbmdmZW5wMTAzMyB7XGluc3JzaWQzNTYwNzYyIFV9e1xpbnNyc2lkMTA4Mzcz OTIgc2UgdGhlIHJpZ2h0IGV4aXQvZW50cmFuY2UNClxwYXIgfVxwYXJkXHBsYWluIFxxbCBcbGkw XHJpMFx3aWRjdGxwYXJcYXNwYWxwaGFcYXNwbnVtXGZhYXV0b1xhZGp1c3RyaWdodFxyaW4wXGxp bjBcaXRhcDBccGFyYXJzaWQzNTYwNzYyIFxmczI0XGxhbmcxMDMzXGxhbmdmZTEwMzNcY2dyaWRc bGFuZ25wMTAzM1xsYW5nZmVucDEwMzMge1xpbnNyc2lkMzU2MDc2MiANCkV2ZW4gaWYgd2UgYXJl IGFibGUgdG8gcHJvdmlkZSByZWR1bmRhbmN5IGFuZCByZWxpYWJpbGl0eSwgdGhlIGR1YWwgaG9t ZWQgbmV0d29ya3MgYXJlIHN0aWxsIGV4cG9zZWQgdG8gdGhlIGZvbGxvd2luZyBmfXtcaW5zcnNp ZDEwODM3MzkyXGNoYXJyc2lkMzU2MDc2MiBhaWx1cmUgbW9kZX17XGluc3JzaWQzNTYwNzYyIDp9 e1xpbnNyc2lkMTA4MzczOTJcY2hhcnJzaWQzNTYwNzYyIA0KXHBhciB7XGxpc3R0ZXh0XHBhcmRc cGxhaW5cZjNcY2hhcnJzaWQzNTYwNzYyIFxsb2NoXGFmM1xkYmNoXGFmMFxoaWNoXGYzIFwnYjdc dGFifX1ccGFyZCBccWwgXGZpLTM2MFxsaTcyMFxyaTBcd2lkY3RscGFyXGpjbGlzdHRhYlx0eDcy MFxhc3BhbHBoYVxhc3BudW1cZmFhdXRvXGxzMTFcYWRqdXN0cmlnaHRccmluMFxsaW43MjBcaXRh cDBccGFyYXJzaWQzNTYwNzYyIHtcaW5zcnNpZDEwODM3MzkyXGNoYXJyc2lkMzU2MDc2MiANClBl ZXIgcGlja3MgYWRkcmVzcyBBIHJhdGhlciB0aGFuIGFkZHJlc3MgQg0KXHBhciB7XGxpc3R0ZXh0 XHBhcmRccGxhaW5cZjNcY2hhcnJzaWQzNTYwNzYyIFxsb2NoXGFmM1xkYmNoXGFmMFxoaWNoXGYz IFwnYjdcdGFifVJlc3VsdGluZyB0cmFmZmljIH17XGluc3JzaWQzNTYwNzYyIGlzIH17XGluc3Jz aWQxMDgzNzM5MlxjaGFycnNpZDM1NjA3NjIgcm91dGVkIH17XGluc3JzaWQzNTYwNzYyIG9uIGEg c2xvd2VyIHBhdGggb3Igb24gYSBjb25nZXN0ZWQgY29ubmVjdGlvbn17DQpcaW5zcnNpZDEwODM3 MzkyXGNoYXJyc2lkMzU2MDc2MiANClxwYXIge1xsaXN0dGV4dFxwYXJkXHBsYWluXGYzXGNoYXJy c2lkMzU2MDc2MiBcbG9jaFxhZjNcZGJjaFxhZjBcaGljaFxmMyBcJ2I3XHRhYn1QZXJmb3JtYW5j ZSBsb29rcyB0ZXJyaWJsZQ0KXHBhciB9XHBhcmQgXHFsIFxsaTBccmkwXHdpZGN0bHBhclxhc3Bh bHBoYVxhc3BudW1cZmFhdXRvXGFkanVzdHJpZ2h0XHJpbjBcbGluMFxpdGFwMFxwYXJhcnNpZDM1 NjA3NjIge1xpbnNyc2lkMzU2MDc2MiBUaGUgbXVsdGktaG9taW5nIHByb3Bvc2FsIHNob3VsZCBw cm92aWRlIGEgc29sdXRpb24gdG8gdGhpcyBwcm9ibGVtLCBhbmQgdGhpcyBzb2x1dGlvbiBzaG91 bGQgYmUgYXZhaWxhYmxlIGF0IGxlYXN0IHRvIHNtYXJ0IGhvc3RzLiANClRoZSBnb2FsIGlzIG5v dCB0byBvYnRhaW4gYW4gYWJzb2x1dGUgb3B0aW1pemF0aW9uIG9mIG5ldHdvcmsgdXNhZ2UsIGJ1 dCByYXRoZXIgdG8gYXZvaWQgdGhlIG1vc3Qgb2Jub3hpb3VzIHJlc3VsdHMgb2YgbG9hZCBpbWJh bGFuY2UuIFdlIGJlbGlldmUgdGhhdCBpdCBpcyBwb3NzaWJsZSB0byBlbmdpbmVlciBhIHNvbHV0 aW9uIA0KdXNpbmcgZWl0aGVyIGEgc21hcnQgbmFtaW5nIHNlcnZpY2UgKGEuay5hLiBETlMgbG9h ZCBiYWxhbmNpbmcpLCBhIHJvdXRpbmcgbGV2ZWwgb3B0aW1pemF0aW9uIHN1Y2ggYXMgYSByYW5k b21pemVkIGNob2ljZSBvZiBleGl0IHJvdXRlcnMsIG9yIHBvc3NpYmx5IGEgdmFyaWF0aW9uIG9m IE1vYmlsZSBJUHY2IHRvIG1vdmUgZXhpc3RpbmcgY29ubmVjdGlvbnMgdG93YXJkcyBhIGxlc3Mg bG9hZGVkIHBhdGgufXsNClxpbnNyc2lkMTA4MzczOTJcY2hhcnJzaWQzNTYwNzYyIA0KXHBhciB7 XGxpc3R0ZXh0XHBhcmRccGxhaW5cczEgXGYzNVxmczMyIFxoaWNoXGFmMzVcZGJjaFxhZjBcbG9j aFxmMzUgNFx0YWJ9fVxwYXJkXHBsYWluIFxzMVxxbCBcZmktNDMyXGxpNDMyXHJpMFxub3dpZGN0 bHBhclxqY2xpc3R0YWJcdHg0MzJcZmFhdXRvXGxzN1xvdXRsaW5lbGV2ZWwwXHJpbjBcbGluNDMy XGl0YXAwIFxmMzVcZnMzNlxsYW5nMTAzM1xsYW5nZmUxMDMzXGNncmlkXGxhbmducDEwMzNcbGFu Z2ZlbnAxMDMzIHsNClxmczMyXGluc3JzaWQxMDgzNzM5MiBGdXJ0aGVyIHN0dWR5DQpccGFyIH1c cGFyZFxwbGFpbiBccWwgXGxpMFxyaTBcd2lkY3RscGFyXGFzcGFscGhhXGFzcG51bVxmYWF1dG9c YWRqdXN0cmlnaHRccmluMFxsaW4wXGl0YXAwXHBhcmFyc2lkMTEwMjIyMjQgXGZzMjRcbGFuZzEw MzNcbGFuZ2ZlMTAzM1xjZ3JpZFxsYW5nbnAxMDMzXGxhbmdmZW5wMTAzMyB7XGluc3JzaWQxMTAy MjIyNCBUaGUgZ29hbCBvZiB0aGUgc2ltcGxlIGR1YWwgaG9taW5nIGV4ZXJjaXNlIGlzIHRvIHBy b3ZpZGUgYSBzaW1wbA0KZSBzb2x1dGlvbiB0byB0aGUgc2ltcGxlIHNpdGVzLiBPbmNlIHRoaXMg Z29hbCBpcyBhY2hpZXZlZCwgd2UgYmVsaWV2ZSB0aGF0IHRoZSBzb2x1dGlvbiBjYW4gYmUgZXh0 ZW5kZWQgaW4gdHdvIGRpcmVjdGlvbnM6IGV4dGVuZCB0aGUgc29sdXRpb24gdG8gbWVkaXVtIHNp emUgc2l0ZXM7IGFuZCBleHRlbmQgdGhlIHNvbHV0aW9uIHRvIGFjY29tbW9kYXRlIGEgZm9ybSBv ZiBwcm92aWRlciBpbmRlcGVuZGVudCBhZGRyZXNzaW5nLiANClxwYXIgDQpccGFyIFRoZSBleHRl bnNpb24gdG8gbWVkaXVtIHNpemUgc2l0ZXMgY2FuIGJlIHRob3VnaHQgYXMgYSBwcm9ncmVzcyBv biBhIHNjYWxlIG9mIGNvbXBsZXhpdHk6IGZpcnN0LCBleHRlbmQgdGhlIHNvbHV0aW9uIHRvIG11 bHRpbGluayBzdWJuZXRzLCB3aGVyZSB9e1xpbnNyc2lkMTA4MzczOTJcY2hhcnJzaWQxMTAyMjIy NCBhbGwgZXhpdCByb3V0ZXJzIH17XGluc3JzaWQxMTAyMjIyNCBhcmUgfXsNClxpbnNyc2lkMTA4 MzczOTJcY2hhcnJzaWQxMTAyMjIyNCBvbiB9e1xpbnNyc2lkMTEwMjIyMjQgdGhlIHNhbWUgbGlu azsgc2Vjb25kLCBleHRlbmQgdGhlIHNvbHV0aW9uIHRvIH17XGluc3JzaWQxMDgzNzM5MlxjaGFy cnNpZDExMDIyMjI0IHJvdXRlZCBuZXR3b3JrLH17XGluc3JzaWQxMTAyMjIyNCAgd2hlcmV9e1xp bnNyc2lkMTA4MzczOTJcY2hhcnJzaWQxMTAyMjIyNCAgYWxsIGV4aXQgcm91dGVycyB9e1xpbnNy c2lkMTEwMjIyMjQgYXJlIA0KfXtcaW5zcnNpZDEwODM3MzkyXGNoYXJyc2lkMTEwMjIyMjQgb24g fXtcaW5zcnNpZDExMDIyMjI0IHRoZSBzYW1lIGxpbms7IGFuZCB0aGlyZCwgZXh0ZW5kIHRoZSBz b2x1dGlvbiB0byB9e1xpbnNyc2lkMTA4MzczOTJcY2hhcnJzaWQxMTAyMjIyNCByb3V0ZWQgbmV0 d29yaywgfXtcaW5zcnNpZDExMDIyMjI0IHdoZXJlIGV4aXQgcm91dGVycyBhcmUgcHJlc2VudCBh dH17XGluc3JzaWQxMDgzNzM5MlxjaGFycnNpZDExMDIyMjI0IA0KIGRpZmZlcmVudCBsb2NhdGlv bn17XGluc3JzaWQxMTAyMjIyNCBzLn17XGluc3JzaWQxMDgzNzM5MiANClxwYXIgfXtcaW5zcnNp ZDExMDIyMjI0IA0KXHBhciBQcm92aWRlciBpbmRlcGVuZGVudCBhZGRyZXNzaW5nIGlzIG9mdGVu IHVzZWQgdG9kYXkgYnkgbGFyZ2UgSVB2NCBzaXRlcywgd2hpY2ggc2ltcGx5IG9idGFpbiBhIHBy ZWZpeCBmb3JtIGEgcmVnaXN0cnksIHVzZSB0aGlzIHByZWZpeCBmb3IgaW50ZXJuYWwgYWRkcmVz c2VzLCBhbmQgaW5zdXJlIHRoYXQgdGhlIHByZQ0KZml4IGlzIGRpc3RyaWJ1dGVkIGluIHRoZSBn bG9iYWwgcm91dGluZyB0YWJsZXMuIFdlIGJlbGlldmUgdGhhdCBzaW1pbGFyIHNvbHV0aW9ucyB3 aWxsIGJlIGF2YWlsYWJsZSBmb3IgbGFyZ2UgSVB2NiBzaXRlcywgYnV0IHdlIGFyZSBhbHNvIHZl cnkgYXdhcmUgdGhhdCB0aGV5IGNhbm5vdCBiZSBleHRlbmRlZCB0byB0aGUgbWFqb3JpdHkgb2Yg c21hbGxlciBJUHY2IHNpdGVzLiBZZXQsIHRoZSBzbWFsbCBJUHY2DQogc2l0ZXMgbWF5IGJlbmVm aXQgZnJvbSBzb21lIGZvcm0gb2YgcHJvdmlkZXIgaW5kZXBlbmRlbnQgYWRkcmVzc2VzLCBlLmcu IGluIG9yZGVyIHRvIGFkdmVydGlzZSBhZGRyZXNzZXMgdGhhdCBkb25ccnF1b3RlIHQgZGVwZW5k IG9uIGEgcGFydGljdWxhciBwcm92aWRlciBjb25maWd1cmF0aW9uLiBJdCBtYXkgYmUgcG9zc2li bGUgZm9yIHRoZXNlIHNpdGVzIHRvIHVzZSBhIFwnOTN2aXJ0dWFsIElQXCc5NA0KIHNvbHV0aW9u LCBpbiB3aGljaCBjb25uZWN0aXZpdHkgdGhyb3VnaCBhIFBJIGFkZHJlc3MgaXMgb3ZlcmxhaWQg b24gdG9wIG9mIHRoZSByZWd1bGFyIHByb3ZpZGVyIGJhc2VkIGFkZHJlc3NpbmcuIFRoaXMgY2Fu IGJlIHRob3VnaHQgb2YgYXMgYW4gZXh0ZW5zaW9uIG9mIHRoZSBzaW1wbGUgc29sdXRpb24ufXtc aW5zcnNpZDExMDIyMjI0XGNoYXJyc2lkMTEwMjIyMjQgDQpccGFyIH17XGluc3JzaWQxMDgzNzM5 MiANClxwYXIgfXtcaW5zcnNpZDEwODM3MzkyXGNoYXJyc2lkMTEwMjIyMjQgDQpccGFyIH19 ------_=_NextPart_001_01C2EE84.E2E92E9E-- From owner-multi6@ops.ietf.org Wed Mar 19 22:52:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22849 for ; Wed, 19 Mar 2003 22:52:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vr6n-000A3e-00 for multi6-data@psg.com; Wed, 19 Mar 2003 19:52:49 -0800 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #1) id 18vr6l-000A3R-00 for multi6@ops.ietf.org; Wed, 19 Mar 2003 19:52:47 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 469ED34459; Wed, 19 Mar 2003 19:05: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 h2K3qkYB006362; Wed, 19 Mar 2003 19:52:46 -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="us-ascii" Subject: RE: Again no multi6 at IETF#56 Date: Wed, 19 Mar 2003 19:52:45 -0800 Message-ID: Thread-Topic: Again no multi6 at IETF#56 Thread-Index: AcLuelDcx9/4UFYxRpWn2MBc/EwA4QAGGWrw From: "Tony Li" To: "Kurt Erik Lindqvist" Cc: "Bound, Jim" , "Michael H. Lambert" , X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_02_03 version=2.44 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA22849 Kurt, | > All of the pain and none of the gain? Any announcement of longer | > prefixes is at the expense of routing scalability. | | Agreed. No question. But with 350 routes I am more worried | over the | lack of routes.... Once upon a time, not so long ago, the entire IPv4 Internet was only 1000 routes. Since then, I've been fighting exponential growth. Be careful what you wish for. | > The cost of multihoming is falling. Today, sitting at home on | > my couch, I can easily connect to my neighbor's WAP. If we | > were to tweak things a bit, both of us would be multi-homed | > through the other. In fact, the cost of connectivity is | > continuing to fall, so one might expect that the cost of | > multi-homing will fall too. | | I don't question that. What makes me wonder is how many | home users will | actually want/need multihoming? How many SOHO will? How many | enterprises? Historically, about 10% of all Internet sites are multi-homed. I see no reason for this not to continue. As to homes, I can tell you that my provider is certainly not so reliable that I am happy being singly-homed. And I'm not alone, I know of many others with similar situations. | > If you subscribe to the view that businesses find the Web | > interface to be important, then it stands to reason that the | > interest in multihoming would continue to grow. | | Agreed, the question is how fast? Faster than we can possibly accommodate. Our job is to provide the technical leadership and be there with an architecture BEFORE the masses show up. Because by then, it's too late. | Well, I think we need to move in steps for a number of reasons, | urgency, implementation lead times, and last to get | consensus. This | said, I think that we need to always keep in mind how we | will get from | A to B, and eventually to C. | | But that is what I hope will be the first issue we could | get agreement | here on. I agree that we need all of those things. However, I don't believe that we're in an undue rush to move forward. Providing an interim solution is simply going to turn that interim into a final solution, and we will regret it. Tony From owner-multi6@ops.ietf.org Wed Mar 19 22:55:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22908 for ; Wed, 19 Mar 2003 22:55:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vrBC-000AGr-00 for multi6-data@psg.com; Wed, 19 Mar 2003 19:57:22 -0800 Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by psg.com with esmtp (Exim 3.36 #1) id 18vrBA-000AGa-00 for multi6@ops.ietf.org; Wed, 19 Mar 2003 19:57:21 -0800 Received: from consulintel02 ([130.129.140.228]) by consulintel.es ([127.0.0.1]) with SMTP (MDaemon.PRO.v6.7.2.R) for ; Thu, 20 Mar 2003 04:59:36 +0100 Message-ID: <1e6f01c2ee49$a5ab85a0$da4f8182@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: Subject: Re: Simple dual homing experiment Date: Wed, 19 Mar 2003 19:59:17 +0100 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-MDRemoteIP: 130.129.140.228 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: multi6@ops.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=DATE_IN_PAST_06_12,NOSPAM_INC,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_OE version=2.44 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I think we can do this testing easily in several part of the Euro6IX network. So, how we start ? Regards, Jordi ----- Original Message ----- From: "Christian Huitema" To: Cc: Sent: Thursday, March 20, 2003 3:03 AM Subject: FW: Simple dual homing experiment Kurtis, David and I wrote up a "simple dual homing" proposal, based on previous drafts and private conversations. This may be one of several ways of going forward in multi6. -- Christian Huitema ***************************** Madrid 2003 Global IPv6 Summit 12-14 May 2003 - Register at: http://www.ipv6-es.com From owner-multi6@ops.ietf.org Wed Mar 19 23:20:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23680 for ; Wed, 19 Mar 2003 23:20:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vrZb-000Bgp-00 for multi6-data@psg.com; Wed, 19 Mar 2003 20:22:35 -0800 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #1) id 18vrZZ-000Bgd-00 for multi6@ops.ietf.org; Wed, 19 Mar 2003 20:22:33 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 6D6D234459; Wed, 19 Mar 2003 19:35: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 h2K4MVYD009701; Wed, 19 Mar 2003 20:22:33 -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="us-ascii" Subject: RE: Simple dual homing experiment Date: Wed, 19 Mar 2003 20:22:12 -0800 Message-ID: Thread-Topic: Simple dual homing experiment Thread-Index: AcLtrXBvA7fKf01vSPaEW4bECTXvUwAAR78wAC/wOnkABZmvJwAEX8Vg From: "Tony Li" To: "Christian Huitema" , Cc: X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.44 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA23680 | David and I wrote up a "simple dual homing" proposal, | based on previous drafts and private conversations. This | may be one of several ways of going forward in multi6. Christian, First, I don't believe that 3.5 is a real requirement. It is not a problem that is solved today in any technology short of full blown traffic engineering. While I agree that this would be valuable, I don't see how this really cuts it as a requirement. Of your other requirements, it would seem that they would all be addressed as long as: 1) routers which don't have a working exit don't advertise default 2) hosts rotate their source (and destination) addresses among the possible set Further, I would argue that your requirement for 3.4 isn't strong enough. That the connection should NOT break. Comments? Tony From owner-multi6@ops.ietf.org Thu Mar 20 01:21:16 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27495 for ; Thu, 20 Mar 2003 01:21:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vtRT-000JCJ-00 for multi6-data@psg.com; Wed, 19 Mar 2003 22:22:19 -0800 Received: from wl-142-224.wireless.ietf56.ietf.org ([130.129.142.224] helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18vtRR-000JBl-00 for multi6@ops.ietf.org; Wed, 19 Mar 2003 22:22:17 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2K6NaKW008124; Thu, 20 Mar 2003 07:23:39 +0100 (CET) Date: Thu, 20 Mar 2003 07:19:06 +0100 Subject: Re: Again no multi6 at IETF#56 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "J. Noel Chiappa" , To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: <20030318221059.J87639-100000@sequoia.muada.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) 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.44 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The below is exactly what I describe in the draft-kurtis-longprefix-multihoming-00.txt draft. I agree that declaring it BCP is probably better than propose it as a standard. It still have the problems that Tony points out though. - kurtis - On tisdag, mar 18, 2003, at 22:30 Europe/Stockholm, Iljitsch van Beijnum wrote: > On Tue, 18 Mar 2003, J. Noel Chiappa wrote: > >>> We need apply the solution we have today with zero implementation. >>> And >>> I don't see any other alternative. six months from now we might have >>> something better. Let's do that then. > >> The thing is that we don't need to do anything to allow people to do >> it the >> "current way" (i.e. let the routing handle it, al la IPv4 MH) - in >> fact, I >> doubt we could stop them, actually. > >> On the other hand, there's no need to put the IETF Gold Seal of >> Approval on >> something we now won't scale in the long term. > >> Taken together, that all argues that we should press on and say >> nothing about >> the interim IPv4-type thing. > > Well there is one way of multihoming that provides reasonable benefits > without too many issues that can be deployed today: take address space > from one ISP and announce it to two or more ISPs. As long as there is > peering between these ISPs you're protected against all common failure > modes. (Ok, not counting ISP going bankrupt as "common" here...) > > If ISPs filter the /48, there isn't much of an issue as long as the > aggregate is still visible from ISP A and ISP A forwards the traffic to > ISP B. > > The one thing that needs some consideration is filtering between ISPs: > if ISP C filters packets it gets from ISP B with ISP A source > addresses, > all of this breaks. There are two ways around this: ISP C accepts the > /48 (assuming they're doing uRPF) or they don't filter but trust ISP B > to filter their customers. > > Now do this with two /48s from two ISPs and you can start experimenting > with multiaddressing and have a safety net at the same time. > > Just one down side for the enterprise: this is PA space, so it is > necessary to renumber when changing ISPs. > > Any reason why we shouldn't publish this with the IETF bronze seal of > approval as a temporary best practice? > > About the first most important multihoming issue you ranted about in an > earlier message: I don't think we are overlooking this (see my comments > to Marcelo's draft, and my conversion to favoring transport layer > solutions a few months ago). But: > > 1. This isn't all that controversial > 2. Doing it wrong first and improve later doesn't create an > impossible-to-clean-up-mess (like allowing /48s in the DFZ) > > Iljitsch > > From owner-multi6@ops.ietf.org Thu Mar 20 02:00:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28381 for ; Thu, 20 Mar 2003 02:00:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18vu3C-000LfT-00 for multi6-data@psg.com; Wed, 19 Mar 2003 23:01:18 -0800 Received: from hlm-c-06e6.mxs.adsl.euronet.nl ([212.129.134.230] helo=lavinia.baume.org) by psg.com with esmtp (Exim 3.36 #1) id 18vu3A-000Leq-00; Wed, 19 Mar 2003 23:01:16 -0800 Received: from localhost (pierre@localhost) by lavinia.baume.org (8.11.6/8.11.6) with ESMTP id h2K70n320372; Thu, 20 Mar 2003 08:00:49 +0100 Date: Thu, 20 Mar 2003 08:00:48 +0100 (CET) From: Pierre Baume To: Masataka Ohta cc: Michel Py , Tony Li , "Bound, Jim" , Randy Bush , Kurt Erik Lindqvist , Bob Hinden , Subject: Re: Again no multi6 at IETF#56 In-Reply-To: <200303170953.SAA20520@necom830.hpcl.titech.ac.jp> 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_00_01,USER_AGENT_PINE version=2.44 Sender: owner-multi6@ops.ietf.org Precedence: bulk Masataka, On Mon, 17 Mar 2003, Masataka Ohta wrote: > Pierre; > > > Hrm, like in the dns system? > > In a sense, yes. It is necessary to involve DNS for, say, ID->locator > mapping. > > However, a problem of using a domain name as an identifier is that not > all the packets contain the domain name. [snip] A reverse lookup can provide it. Pierre. From owner-multi6@ops.ietf.org Thu Mar 20 08:36:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17060 for ; Thu, 20 Mar 2003 08:36:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18w0Dg-000Gko-00 for multi6-data@psg.com; Thu, 20 Mar 2003 05:36:32 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 18w0De-000GkX-00 for multi6@ops.ietf.org; Thu, 20 Mar 2003 05:36:30 -0800 From: Masataka Ohta Message-Id: <200303201332.WAA10883@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id WAA10883; Thu, 20 Mar 2003 22:32:06 +0900 Subject: Re: Identifier/locator recap In-Reply-To: from RJ Atkinson at "Mar 19, 2003 11:57:12 am" To: RJ Atkinson Date: Thu, 20 Mar 2003 22:32:05 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-0.7 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.44 Sender: owner-multi6@ops.ietf.org Precedence: bulk Ran; > I concur with Erik Nordmark's analysis of things. > > > On Wednesday, Mar 19, 2003, at 02:45 America/Montreal, Iljitsch van > Beijnum wrote: > > Doing it in middleboxes is more complex,... > > Middleboxes break the end-to-end principle and are generally not > desirable architecturally. Right. However, to be honest, DNS servers are middleboxes. But, they are not intelligent but dumb middleboxes. Load concentration, caused by the violation of the e2e principle, is taken care of by light weight protocol. Never say X.500. Lack of reliablity, caused by the violation of the e2e principle, is taken care of by multiple servers. DNS servers are necessary evil that the point is not to introduce yet another evil > Since we have at least one architectural approach (i.e. > identifier/locator > separation) that does not need/use any middleboxes, please let us all > agree > that middlebox approaches are not desirable here -- and not discuss them > at any further length in this WG. But, we need DNS. With IPv6 with 16 bytes of an address, we are a lot more motivated to favour domain names over raw address than with IPv4. With multiple addresses (or locators), we are motiveted even more. In general, if we want to introduce structure unrelated to the network topology, we have similar problem as DNS. Masataka Ohta From owner-multi6@ops.ietf.org Thu Mar 20 13:14:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27815 for ; Thu, 20 Mar 2003 13:14:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18w4Xn-0008gb-00 for multi6-data@psg.com; Thu, 20 Mar 2003 10:13:35 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com) by psg.com with esmtp (Exim 3.36 #1) id 18w4Xl-0008gP-00 for multi6@ops.ietf.org; Thu, 20 Mar 2003 10:13:33 -0800 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18w4Xl-0001f1-00 for multi6@ops.ietf.org; Thu, 20 Mar 2003 10:13:33 -0800 Message-ID: <57FD2C3A246F76438CA6FDAD8FE9F195A7F3AC@hrtades7.atea.be> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" From: Coene Lode To: "'Christian Huitema'" , kurtis@kurtis.pp.se Cc: multi6@ops.ietf.org Subject: RE: Simple dual homing experiment Date: Thu, 20 Mar 2003 19:03:55 +0100 X-Spam-Status: No, hits=-0.5 required=5.0 tests=QUOTED_EMAIL_TEXT,RESENT_TO,SPAM_PHRASE_01_02 version=2.44 Sender: owner-multi6@ops.ietf.org Precedence: bulk [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] > -----Original Message----- > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > Sent: Thursday, March 20, 2003 3:03 AM > To: kurtis@kurtis.pp.se > Cc: multi6@ops.ietf.org > Subject: FW: Simple dual homing experiment > > > Kurtis, > > David and I wrote up a "simple dual homing" proposal, based > on previous drafts and private conversations. This may be one > of several ways of going forward in multi6. > > -- Christian Huitema > > > issue 3.1 : egress filtering: I would think that selecting the destination address based on the source address is a bit strange... Transport protocols(SCTP in particular) selects a destination address, the IP layer selects an outgoing interface, thus in order to have a msg with the correct source address to get through egress filtering, the msg should contain the IP address of the outgoing interface as this is the address the interface got assigned by the provider upstream(and the provider would let its own sourceaddresses/prefixes through, wouldn't it..??..) issue 3.2: some form of heatbeating per destination(as in SCTP) should do the trick... no problem there issue 3.3: looks the same from the perspective of the transport layer.. use same solutions as in 3.2 solve one, get a extra free with... issue 3.4: changeover to a active connection/path.. some transport protocols can do that also.. no problem.. issue 3.5: actually the only guy that could do optimisations is the endpoint itself: it has the congestion information, it could know the load distribution between the different paths/connections if she is smart enough.. basically the smart solution should not pose any problems.. atn least it hasn't give us(=SCTP implementations) any problems up till now. And multiple TCP connections(or something in that direction) would deliver the same stuff... yours sincerly, Lode Coene Siemens atea atealaan 34 2200 Herentals, Belgium E-mail: lode.coene@siemens.com Tel: +32-14-252081 Fax: +32-14-253212 From owner-multi6@ops.ietf.org Thu Mar 20 14:47:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01957 for ; Thu, 20 Mar 2003 14:47:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18w61p-000FoN-00 for multi6-data@psg.com; Thu, 20 Mar 2003 11:48:41 -0800 Received: from mail1.microsoft.com ([131.107.3.125]) by psg.com with esmtp (Exim 3.36 #1) id 18w61l-000Fnf-00 for multi6@ops.ietf.org; Thu, 20 Mar 2003 11:48:37 -0800 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.6659); Thu, 20 Mar 2003 11:48:36 -0800 Received: from 157.54.8.155 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 20 Mar 2003 11:48:35 -0800 Received: from RED-IMC-01.redmond.corp.microsoft.com ([157.54.9.102]) by INET-HUB-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Thu, 20 Mar 2003 11:48:38 -0800 Received: from WIN-IMC-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 20 Mar 2003 11:48:34 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by WIN-IMC-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3765.0); Thu, 20 Mar 2003 11:48:34 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Simple dual homing experiment Date: Thu, 20 Mar 2003 11:48:32 -0800 Message-ID: Thread-Topic: Simple dual homing experiment Thread-Index: AcLtrXBvA7fKf01vSPaEW4bECTXvUwAAR78wAC/wOnkABZmvJwAEX8VgACCyMeM= From: "Christian Huitema" To: "Tony Li" , Cc: X-OriginalArrivalTime: 20 Mar 2003 19:48:34.0576 (UTC) FILETIME=[B1307900:01C2EF19] X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01,SUPERLONG_LINE version=2.44 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA01957 I agree that exit selection (3.5) is more of a "nice to have" -- the real requirement is, try to achieve some load sharing so we do not get a gross misuse of the resource. The reason for "should not break" rather than "must not break" is that in a similar set up today (e.g. main connection backed up by a DSL line), turning on backup actually breaks connections. Also, I am not confident that we can make sure that no connection will ever break, so "must" may well be slightly out of the reach of engineering. By the way, your general observation is correct: David an I believe that most of the solution is actually fairly easy to engineer. ________________________________ From: Tony Li [mailto:Tony.Li@procket.com] Sent: Wed 3/19/2003 8:22 PM To: Christian Huitema; kurtis@kurtis.pp.se Cc: multi6@ops.ietf.org Subject: RE: Simple dual homing experiment | David and I wrote up a "simple dual homing" proposal, | based on previous drafts and private conversations. This | may be one of several ways of going forward in multi6. Christian, First, I don't believe that 3.5 is a real requirement. It is not a problem that is solved today in any technology short of full blown traffic engineering. While I agree that this would be valuable, I don't see how this really cuts it as a requirement. Of your other requirements, it would seem that they would all be addressed as long as: 1) routers which don't have a working exit don't advertise default 2) hosts rotate their source (and destination) addresses among the possible set Further, I would argue that your requirement for 3.4 isn't strong enough. That the connection should NOT break. Comments? Tony From owner-multi6@ops.ietf.org Thu Mar 20 15:54:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06176 for ; Thu, 20 Mar 2003 15:54:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18w73C-000L6i-00 for multi6-data@psg.com; Thu, 20 Mar 2003 12:54:10 -0800 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #1) id 18w739-000L6W-00 for multi6@ops.ietf.org; Thu, 20 Mar 2003 12:54:07 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id B3EE434465; Thu, 20 Mar 2003 12:07:12 -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 h2KKs6YB014372; Thu, 20 Mar 2003 12:54: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="us-ascii" Subject: RE: Simple dual homing experiment Date: Thu, 20 Mar 2003 12:54:06 -0800 Message-ID: Thread-Topic: Simple dual homing experiment Thread-Index: AcLtrXBvA7fKf01vSPaEW4bECTXvUwAAR78wAC/wOnkABZmvJwAEX8VgACCyMeMAAldgwA== From: "Tony Li" To: "Christian Huitema" , Cc: X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01 version=2.44 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA06176 Perfectly reasonable. I should point out that turning up an additional link today breaks connections because the host isn't capable of trying a different address. You could, in theory, write a non-standard TCP that had the right host behavior, even with IPv4 today. But it doesn't exist, AFAIK. Now, does this test actually distinguish anything between any of the proposals that have been discussed? Tony | -----Original Message----- | From: Christian Huitema [mailto:huitema@windows.microsoft.com] | Sent: Thursday, March 20, 2003 11:49 AM | To: Tony Li; kurtis@kurtis.pp.se | Cc: multi6@ops.ietf.org | Subject: RE: Simple dual homing experiment | | | I agree that exit selection (3.5) is more of a "nice to | have" -- the real requirement is, try to achieve some load | sharing so we do not get a gross misuse of the resource. | | The reason for "should not break" rather than "must not | break" is that in a similar set up today (e.g. main | connection backed up by a DSL line), turning on backup | actually breaks connections. Also, I am not confident that | we can make sure that no connection will ever break, so | "must" may well be slightly out of the reach of engineering. | | By the way, your general observation is correct: David an | I believe that most of the solution is actually fairly | easy to engineer. | | | | ________________________________ | | From: Tony Li [mailto:Tony.Li@procket.com] | Sent: Wed 3/19/2003 8:22 PM | To: Christian Huitema; kurtis@kurtis.pp.se | Cc: multi6@ops.ietf.org | Subject: RE: Simple dual homing experiment | | | | | | David and I wrote up a "simple dual homing" proposal, | | based on previous drafts and private conversations. This | | may be one of several ways of going forward in multi6. | | | Christian, | | First, I don't believe that 3.5 is a real requirement. It is | not a problem that is solved today in any technology short of | full blown traffic engineering. While I agree that this would | be valuable, I don't see how this really cuts it as a requirement. | | Of your other requirements, it would seem that they would all | be addressed as long as: | | 1) routers which don't have a working exit don't advertise | default | 2) hosts rotate their source (and destination) addresses | among the possible set | | Further, I would argue that your requirement for 3.4 isn't strong | enough. That the connection should NOT break. | | Comments? | | Tony | | From owner-multi6@ops.ietf.org Thu Mar 20 16:41:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08591 for ; Thu, 20 Mar 2003 16:41:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18w7oL-000P3e-00 for multi6-data@psg.com; Thu, 20 Mar 2003 13:42:53 -0800 Received: from mail5.microsoft.com ([131.107.3.121]) by psg.com with esmtp (Exim 3.36 #1) id 18w7oF-000P36-00 for multi6@ops.ietf.org; Thu, 20 Mar 2003 13:42:47 -0800 Received: from mail6.microsoft.com ([157.54.6.196]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Thu, 20 Mar 2003 13:42:45 -0800 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 20 Mar 2003 13:42:36 -0800 Received: from 157.54.8.155 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 20 Mar 2003 13:42:40 -0800 Received: from RED-IMC-01.redmond.corp.microsoft.com ([157.54.9.102]) by INET-HUB-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Thu, 20 Mar 2003 13:42:40 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 20 Mar 2003 13:42:35 -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.3765.0); Thu, 20 Mar 2003 13:42:41 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Simple dual homing experiment Date: Thu, 20 Mar 2003 13:42:40 -0800 Message-ID: Thread-Topic: Simple dual homing experiment Thread-Index: AcLtrXBvA7fKf01vSPaEW4bECTXvUwAAR78wAC/wOnkABZmvJwAEX8VgACCyMeMAAldgwAABuqaC From: "Christian Huitema" To: "Tony Li" , Cc: X-OriginalArrivalTime: 20 Mar 2003 21:42:41.0648 (UTC) FILETIME=[A25CBF00:01C2EF29] X-Spam-Status: No, hits=0.8 required=5.0 tests=SPAM_PHRASE_00_01,SUPERLONG_LINE version=2.44 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA08591 The idea is to build to split the problem in pieces: how to solve ingress filtering, how to solve connection maintenance, etc., and then to agree on at least one good solution. Good = easy to deploy, minimal development, etc. ________________________________ From: Tony Li [mailto:Tony.Li@procket.com] Sent: Thu 3/20/2003 12:54 PM To: Christian Huitema; kurtis@kurtis.pp.se Cc: multi6@ops.ietf.org Subject: RE: Simple dual homing experiment Perfectly reasonable. I should point out that turning up an additional link today breaks connections because the host isn't capable of trying a different address. You could, in theory, write a non-standard TCP that had the right host behavior, even with IPv4 today. But it doesn't exist, AFAIK. Now, does this test actually distinguish anything between any of the proposals that have been discussed? Tony | -----Original Message----- | From: Christian Huitema [mailto:huitema@windows.microsoft.com] | Sent: Thursday, March 20, 2003 11:49 AM | To: Tony Li; kurtis@kurtis.pp.se | Cc: multi6@ops.ietf.org | Subject: RE: Simple dual homing experiment | | | I agree that exit selection (3.5) is more of a "nice to | have" -- the real requirement is, try to achieve some load | sharing so we do not get a gross misuse of the resource. | | The reason for "should not break" rather than "must not | break" is that in a similar set up today (e.g. main | connection backed up by a DSL line), turning on backup | actually breaks connections. Also, I am not confident that | we can make sure that no connection will ever break, so | "must" may well be slightly out of the reach of engineering. | | By the way, your general observation is correct: David an | I believe that most of the solution is actually fairly | easy to engineer. | | | | ________________________________ | | From: Tony Li [mailto:Tony.Li@procket.com] | Sent: Wed 3/19/2003 8:22 PM | To: Christian Huitema; kurtis@kurtis.pp.se | Cc: multi6@ops.ietf.org | Subject: RE: Simple dual homing experiment | | | | | | David and I wrote up a "simple dual homing" proposal, | | based on previous drafts and private conversations. This | | may be one of several ways of going forward in multi6. | | | Christian, | | First, I don't believe that 3.5 is a real requirement. It is | not a problem that is solved today in any technology short of | full blown traffic engineering. While I agree that this would | be valuable, I don't see how this really cuts it as a requirement. | | Of your other requirements, it would seem that they would all | be addressed as long as: | | 1) routers which don't have a working exit don't advertise | default | 2) hosts rotate their source (and destination) addresses | among the possible set | | Further, I would argue that your requirement for 3.4 isn't strong | enough. That the connection should NOT break. | | Comments? | | Tony | | From owner-multi6@ops.ietf.org Thu Mar 20 18:28:28 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14027 for ; Thu, 20 Mar 2003 18:28:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18w9Sy-0003t4-00 for multi6-data@psg.com; Thu, 20 Mar 2003 15:28:56 -0800 Received: from wl-142-224.wireless.ietf56.ietf.org ([130.129.142.224] helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18w9Sv-0003sd-00 for multi6@ops.ietf.org; Thu, 20 Mar 2003 15:28:53 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2KNU5KW008900; Fri, 21 Mar 2003 00:30:10 +0100 (CET) Date: Fri, 21 Mar 2003 00:30:04 +0100 Subject: Re: Move forward Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: marcelo bagnulo , To: Iljitsch van Beijnum From: Kurt Erik Lindqvist In-Reply-To: <20030317174331.T86639-100000@sequoia.muada.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) 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.44 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > How does the resolver library know which addresses are reachable? Or > usable for the application in question? It doesn't. If time out it will retry. - kurtis - From owner-multi6@ops.ietf.org Fri Mar 21 01:59:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24108 for ; Fri, 21 Mar 2003 01:59:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18wGUv-000O4Y-00 for multi6-data@psg.com; Thu, 20 Mar 2003 22:59:25 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18wGUs-000O4E-00 for multi6@ops.ietf.org; Thu, 20 Mar 2003 22:59:22 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2L6xCp07870; Fri, 21 Mar 2003 08:59:18 +0200 Date: Fri, 21 Mar 2003 08:59:12 +0200 (EET) From: Pekka Savola To: marcelo bagnulo cc: Iljitsch van Beijnum , Subject: Re: comments on mipv6 application to multihoming [Re: Move forward] In-Reply-To: <1048107706.762.131.camel@presto.it.uc3m.es> 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.44 Sender: owner-multi6@ops.ietf.org Precedence: bulk On 19 Mar 2003, marcelo bagnulo wrote: > I am running out of solutions here :-) > I can think of the following options for this, but i am not sure i like > anyone of them. > > First option: (i think this would be the most elegant, but i think its > time has passed) use a site local anycast address > So you can compose the site exit router anycast address by appending the > prefix assigned to the link to the site local prefix. I like this, but > the problem is that there may be no more site locals for connected > sites. I guess i should wait and see the outcome of the site local > debate. > > Second option: use the above configuration and configure R3 as a ND > proxy. I do not like this much because it imposes additional > configuration in all the routers (it is better than configuring all the > hosts, though) > > Third option: (nasty hack) use the above configuration but change the > site exit router anycast format by changing the less significant bit of > the directly attached subnet. This would make that the anycast address > is not on-link, so that it has to be routed through a router. 1) is out of question, 2) seems undesirable but acceptable, 3) too hacky. A possibly valid approach could be advertising the addresses or portions of significant information thereof (e.g. prefix length and have a reserved anycast address) in route advertisements. But I don't really like this approach either. A discovery approach would also be possible: e.g. send traceroutes using all the source addresses and watch out for responses (assuming there is some special "site exit router discovery" ICMP message). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Sat Mar 22 11:19:05 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29128 for ; Sat, 22 Mar 2003 11:19:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18wldb-0007Ky-00 for multi6-data@psg.com; Sat, 22 Mar 2003 08:14:27 -0800 Received: from dhcp1.se.kurtis.pp.se ([195.43.225.70] helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18wldX-0007Ke-00 for multi6@ops.ietf.org; Sat, 22 Mar 2003 08:14:23 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2MGFcKW009447; Sat, 22 Mar 2003 17:15:39 +0100 (CET) Date: Sat, 22 Mar 2003 06:23:36 +0100 Subject: Re: Start running Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Masataka Ohta" , To: "Tony Li" From: Kurt Erik Lindqvist In-Reply-To: Message-Id: <6EDB3E54-5C26-11D7-B5E2-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.5 required=5.0 tests=DATE_IN_PAST_06_12,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_01_02,USER_AGENT_APPLEMAIL version=2.44 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > And look what a wonderful result that was! I see your point for a longer term vision, HOWEVER..... > I'd seriously like to suggest that we NOT run down the proposal > path. Again, all that does is lock people in on their personal > approach. Folks dig in their heels and it comes to bloodshed. Although I generally tend to agree with your view, I do think that we need let everyone present their opinions and evaluate them. You and me have a certain view of where to go, maybe that is where we will end up eventually (of-course I hope so), but in order to start working on one single solution we need to have a consensus saying that is where we want to go. And we wont get there unless we have looked at the alternatives thoroughly. > I would rather that we take the approach that this is a collaborative > effort and address the issues and resolve them. Start with a > top level architecture and work down. Yes, this is harder > on the chairs, but it needs to be done this way to ensure closure > without bloodshed. I have no problem with loading the chairs (I guess Sean will give me a hard time for this...:) ) if that brings us forward, and I think you are right, but I think we need to do some other steps first. - kurtis - > > Tony > > | -----Original Message----- > | From: Masataka Ohta [mailto:mohta@necom830.hpcl.titech.ac.jp] > | Sent: Tuesday, March 18, 2003 8:51 PM > | To: Kurt Erik Lindqvist > | Cc: multi6@ops.ietf.org > | Subject: Re: Start running > | > | > | Kurt; > | > | > > Last, we will try and have a beer BOF tomorrow at > | 17.30-19.30. If you > | > > feel you want to give input on the way forward, > | discuss solutoins, or > | > | > It was pointed out that this is during the dinner break. > | For those of > | > you who do not know me - I (and I guess Sean) will most > | likely be at > | > the bar after the IESG session as well. > | > | As I'm returning to Japan tonight (as scheduled long before), > | I just leave a comment. > | > | Instead of wasting time on a requirement draft again, how about > | having several design teams to work on their own proposals > | and let them apeal to the WG? Each team can have their own > | requirements. > | > | Note that it is an approach used to develop IPv6. > | > | Masataka Ohta > | > | From owner-multi6@ops.ietf.org Sat Mar 22 11:19:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29143 for ; Sat, 22 Mar 2003 11:19:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18wldh-0007LE-00 for multi6-data@psg.com; Sat, 22 Mar 2003 08:14:33 -0800 Received: from dhcp1.se.kurtis.pp.se ([195.43.225.70] helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18wlde-0007L1-00 for multi6@ops.ietf.org; Sat, 22 Mar 2003 08:14:31 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2MGFsKW009456; Sat, 22 Mar 2003 17:15:55 +0100 (CET) Date: Sat, 22 Mar 2003 16:25:23 +0100 Subject: Re: Again no multi6 at IETF#56 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Bound, Jim" , "Michael H. Lambert" , To: "Tony Li" From: Kurt Erik Lindqvist In-Reply-To: Message-Id: <803AD88B-5C7A-11D7-B5E2-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_05_08, USER_AGENT_APPLEMAIL version=2.44 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Tony, > | > All of the pain and none of the gain? Any announcement of > longer > | > prefixes is at the expense of routing scalability. > | > | Agreed. No question. But with 350 routes I am more worried > | over the > | lack of routes.... > > > Once upon a time, not so long ago, the entire IPv4 Internet was only > 1000 > routes. Since then, I've been fighting exponential growth. Be careful > what you wish for. I am well aware of this fact and I have always said that this is not the answer for any longer term. It's just that with only 350 routes people are already announcing much longer prefixes and are successful in suing them. This is just copy the routing operational practices from ISPs today. > | > The cost of multihoming is falling. Today, sitting at home on > | > my couch, I can easily connect to my neighbor's WAP. If we > | > were to tweak things a bit, both of us would be multi-homed > | > through the other. In fact, the cost of connectivity is > | > continuing to fall, so one might expect that the cost of > | > multi-homing will fall too. > | > | I don't question that. What makes me wonder is how many > | home users will > | actually want/need multihoming? How many SOHO will? How many > | enterprises? > > > Historically, about 10% of all Internet sites are multi-homed. I > see no reason for this not to continue. As to homes, I can tell > you that my provider is certainly not so reliable that I am happy > being singly-homed. And I'm not alone, I know of many others > with similar situations. I am sure there are. But price is still a factor that you need to calculate with. > > > | > If you subscribe to the view that businesses find the Web > | > interface to be important, then it stands to reason that the > | > interest in multihoming would continue to grow. > | > | Agreed, the question is how fast? > > > Faster than we can possibly accommodate. Our job is to provide the > technical leadership and be there with an architecture BEFORE the > masses show up. Because by then, it's too late. Agreed, still we need to try and guess when that will be. Mostly because that will set the agenda. I would be interested in seeing what the trend curves for the IPv6 routing table looks like from the people monitoring these. But I am not sure if Geoff Huston or Gert During for example are on this list. > | Well, I think we need to move in steps for a number of reasons, > | urgency, implementation lead times, and last to get > | consensus. This > | said, I think that we need to always keep in mind how we > | will get from > | A to B, and eventually to C. > | > | But that is what I hope will be the first issue we could > | get agreement > | here on. > > > I agree that we need all of those things. However, I don't believe > that we're in an undue rush to move forward. Providing an interim > solution is simply going to turn that interim into a final solution, > and we will regret it. > Maybe. But coming to that conclusion and consensus is also an achievement we have yet to make. - kurtis - From owner-multi6@ops.ietf.org Sat Mar 22 13:45:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01609 for ; Sat, 22 Mar 2003 13:45:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18wnwX-000Orq-00 for multi6-data@psg.com; Sat, 22 Mar 2003 10:42:09 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.36 #1) id 18wnwR-000Ord-00 for multi6@ops.ietf.org; Sat, 22 Mar 2003 10:42:03 -0800 Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 8C45B137F02; Sat, 22 Mar 2003 10:42:02 -0800 (PST) Date: Sat, 22 Mar 2003 10:42:01 -0800 Subject: Re: Again no multi6 at IETF#56 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Tony Li" , "Bound, Jim" , "Michael H. Lambert" , To: Kurt Erik Lindqvist From: David Conrad In-Reply-To: <803AD88B-5C7A-11D7-B5E2-000393AB1404@kurtis.pp.se> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_01_02, USER_AGENT_APPLEMAIL version=2.44 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kurtis, On Saturday, March 22, 2003, at 07:25 AM, Kurt Erik Lindqvist wrote: > Agreed, still we need to try and guess when that will be. Mostly > because that will set the agenda. I would be interested in seeing what > the trend curves for the IPv6 routing table looks like from the people > monitoring these. But I am not sure if Geoff Huston or Gert During for > example are on this list. There are not enough significant data points to do any sort of trend analysis at this point in time. I agree with Tony -- as a person who personally still gets criticized for the fact that China doesn't have as much address space as MIT, we will regret not addressing the multi-homing (and related) issues now, before "historical mistakes" become permanent. Further, if we address the multi-homing (and related) issues, there will be a clear and obvious justification for IPv6 deployment which has not, to date, been made. Rgds, -drc From owner-multi6@ops.ietf.org Sun Mar 23 02:55:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27200 for ; Sun, 23 Mar 2003 02:55:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18wzo9-000NBd-00 for multi6-data@psg.com; Sat, 22 Mar 2003 23:22:17 -0800 Received: from dmz1.procket.com ([65.174.124.36]) by psg.com with esmtp (Exim 3.36 #1) id 18wzo8-000NBR-00 for multi6@ops.ietf.org; Sat, 22 Mar 2003 23:22:16 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 1342823C4E; Sat, 22 Mar 2003 23:57:50 -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 h2N7M4YB003860; Sat, 22 Mar 2003 23:22:12 -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="us-ascii" Subject: RE: Start running Date: Sat, 22 Mar 2003 23:22:04 -0800 Message-ID: Thread-Topic: Start running Thread-Index: AcLwjiD0qkl6BaPFRum6cGZWL2O0NAAfZQTQ From: "Tony Li" To: "Kurt Erik Lindqvist" Cc: "Masataka Ohta" , X-Spam-Status: No, hits=0.5 required=5.0 tests=SPAM_PHRASE_01_02 version=2.44 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA27200 Kurt, | Although I generally tend to agree with your view, I do | think that we | need let everyone present their opinions and evaluate | them. I fully endorse this. But the implication of drafting full blown proposals for each alternative is not one where you, as a manager, set yourself up for success. You instantly make it competitive and not collaborative. | You and me | have a certain view of where to go, maybe that is where we | will end up | eventually (of-course I hope so), but in order to start | working on one | single solution we need to have a consensus saying that is | where we | want to go. And we wont get there unless we have looked at the | alternatives thoroughly. Then we should apply good engineering practices (see problem statement WG) and bound the problem, partition the solution space and discuss the high level approaches. Only after we have consensus should we be pushing down into more details. | I have no problem with loading the chairs (I guess Sean | will give me a | hard time for this...:) ) if that brings us forward, and I | think you | are right, but I think we need to do some other steps first. Ok, what and when? Tony From owner-multi6@ops.ietf.org Sun Mar 23 03:03:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27297 for ; Sun, 23 Mar 2003 03:03:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18x0NP-000Cvy-00 for multi6-data@psg.com; Sat, 22 Mar 2003 23:58:43 -0800 Received: from dmz1.procket.com ([65.174.124.36]) by psg.com with esmtp (Exim 3.36 #1) id 18x0Mt-000BTb-00 for multi6@ops.ietf.org; Sat, 22 Mar 2003 23:58:11 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 8598C23C56; Sun, 23 Mar 2003 00:04:48 -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 h2N7TAYB004180; Sat, 22 Mar 2003 23:29:11 -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="us-ascii" Subject: RE: Again no multi6 at IETF#56 Date: Sat, 22 Mar 2003 23:29:10 -0800 Message-ID: Thread-Topic: Again no multi6 at IETF#56 Thread-Index: AcLwjiUssb57eRNKQIq8zLP6tMHMpgAfvgyA From: "Tony Li" To: "Kurt Erik Lindqvist" Cc: "Bound, Jim" , "Michael H. Lambert" , X-Spam-Status: No, hits=0.5 required=5.0 tests=SPAM_PHRASE_01_02 version=2.44 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA27297 Kurt, | > | Agreed, the question is how fast? | > | > | > Faster than we can possibly accommodate. Our job is to | provide the | > technical leadership and be there with an architecture BEFORE the | > masses show up. Because by then, it's too late. | | | Agreed, still we need to try and guess when that will be. Mostly | because that will set the agenda. I would be interested in | seeing what | the trend curves for the IPv6 routing table looks like | from the people | monitoring these. But I am not sure if Geoff Huston or | Gert During for | example are on this list. We are currently trying to hold people off from deploying v6 because this issue is not closed. If it was closed, if v6 really was a better architecture, if things actually worked, then we would have been done a few years ago. Consider: Windows has already adopted it, most of the routers are well along the way. All it takes is us (the IETF community) telling folks that it's ready. So please don't set the schedule based on when people WILL show up. If we wait for that point, then events will have overtaken us, we will have lost control of deployment and the same old routing architecture will be too solidly ingrained for people to think about moving. We are already getting quite a bit of backpressure on not changing anything related to v6 already. This can only grow over time. | Maybe. But coming to that conclusion and consensus is also an | achievement we have yet to make. That's not something that we need to come to consensus on. We need consensus on how we move forward. Not how and where all of the traps are. Tony From owner-multi6@ops.ietf.org Sun Mar 23 07:27:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00853 for ; Sun, 23 Mar 2003 07:27:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18x4Zh-0004SA-00 for multi6-data@psg.com; Sun, 23 Mar 2003 04:27:41 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 18x4ZA-0004Pa-00 for multi6@ops.ietf.org; Sun, 23 Mar 2003 04:27:08 -0800 From: Masataka Ohta Message-Id: <200303231206.VAA16622@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id VAA16622; Sun, 23 Mar 2003 21:06:35 +0900 Subject: Re: Start running In-Reply-To: from Tony Li at "Mar 19, 2003 09:45:06 am" To: Tony Li Date: Sun, 23 Mar 2003 21:06:35 +0859 () CC: Kurt Erik Lindqvist , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-0.7 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01 version=2.44 Sender: owner-multi6@ops.ietf.org Precedence: bulk Tony; > I'd seriously like to suggest that we NOT run down the proposal > path. Again, all that does is lock people in on their personal > approach. Folks dig in their heels and it comes to bloodshed. What's wrong with bloodshed? > I would rather that we take the approach that this is a collaborative > effort and address the issues and resolve them. Start with a > top level architecture and work down. Yes, this is harder > on the chairs, but it needs to be done this way to ensure closure > without bloodshed. What's wrong with bloodshed? Bloodshed on requirement draft as observed in this WG has been wrong, of course. But, bloodshed on fully implemented solutions are the best way to develop good protocols. Remember the bloodshed between the Internet and the OSI protocol suits. Masataka Ohta From owner-multi6@ops.ietf.org Sun Mar 23 12:27:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05798 for ; Sun, 23 Mar 2003 12:27:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18x9FW-000GbD-00 for multi6-data@psg.com; Sun, 23 Mar 2003 09:27:10 -0800 Received: from dhcp1.se.kurtis.pp.se ([195.43.225.70] helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18x9Ez-000GTQ-00 for multi6@ops.ietf.org; Sun, 23 Mar 2003 09:26:37 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2NHRfKW010167 for ; Sun, 23 Mar 2003 18:27:47 +0100 (CET) Date: Sun, 23 Mar 2003 18:27:40 +0100 Mime-Version: 1.0 (Apple Message framework v551) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Longer prefixes From: Kurt Erik Lindqvist To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-2.1 required=5.0 tests=USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit As there was some discussions in Atlanta on wether longer prefixes is actually in use today. This is just the first page of sh ipv6 route on one of my home routers : IPv6 Routing Table - 438 entries Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea Timers: Uptime/Expires B 2001:200:126::/48 [20/6] via FE80::C15E:FA3A, Tunnel10, 02:22:30/never B 2001:200:202::/48 [20/6] via FE80::C15E:FA3A, Tunnel10, 02:22:56/never B 2001:200:203::/48 [20/6] via FE80::C15E:FA3A, Tunnel10, 4d01h/never B 2001:200:200::/40 [20/5] via 2001:670:87:3001::, Tunnel10, 4d01h/never B 2001:200:340::/48 [20/6] via FE80::C15E:FA3A, Tunnel10, 4d01h/never B 2001:200:300::/40 [20/6] via FE80::C15E:FA3A, Tunnel10, 4d01h/never B 2001:200:500::/40 [20/3] via FE80::C15E:FA3A, Tunnel10, 5d17h/never B 2001:200::/35 [20/3] via 2001:670:87:3001::, Tunnel10, 3d03h/never B 2001:208::/32 [20/5] via 2001:670:87:3001::, Tunnel10, 3d03h/never B 2001:218::/32 [20/3] via 2001:670:87:3001::, Tunnel10, 1d06h/never B 2001:220::/35 [20/4] via FE80::82F4:B4, Tunnel30, 02:51:25/never B 2001:228:C00::/40 [20/5] via 2001:670:87:3001::, Tunnel10, 4d01h/never It appears as if there are number of prefix lengths being in use. Best regards, - kurtis - From owner-multi6@ops.ietf.org Sun Mar 23 15:15:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09760 for ; Sun, 23 Mar 2003 15:15:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xBsv-0001r5-00 for multi6-data@psg.com; Sun, 23 Mar 2003 12:16:01 -0800 Received: from gnat.inet.org ([63.108.254.91]) by psg.com with esmtp (Exim 3.36 #1) id 18xBsO-0001kB-00 for multi6@ops.ietf.org; Sun, 23 Mar 2003 12:15:28 -0800 Received: from extremenetworks.com (unknown [10.0.8.86]) by gnat.inet.org (Postfix) with ESMTP id 5DB8F6710D; Sun, 23 Mar 2003 15:32:57 -0500 (EST) Date: Sun, 23 Mar 2003 15:14:41 -0500 Subject: Re: Start running Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: "Tony Li" From: RJ Atkinson In-Reply-To: Message-Id: <1496D278-5D6C-11D7-85E9-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-21.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Sunday, Mar 23, 2003, at 02:22 America/Montreal, Tony Li wrote: > | Although I generally tend to agree with your view, I do > | think that we > | need let everyone present their opinions and evaluate > | them. > > I fully endorse this. But the implication of drafting full blown > proposals for each alternative is not one where you, as a manager, > set yourself up for success. You instantly make it competitive and > not collaborative. I'll try to paraphrase tli's view. Full and open discussion is necessary and helpful. However, having such discussion does not imply that the WG Chairs should create something resembling a "horse race" to create competing proposals that will then "fight it out". An alternative approach, one (IMHO) much more likely to be successful in creating a co-operative WG environment, is to have an open discussion that is thoughtfully structured, top down. For example, the initial phase of the discussion probably should be about the high-level technical issues being addressed and possible architectural approaches to those issues. Once rough consensus (smooth consensus not being a customary IETF requirement) is achieved on the high-level issues and on the architectural approach, the discussion could then move on to a next phase with a few high-level engineering details being sorted out. Once those are sorted out, an additional level of detail could be addressed. Only at the end would the discussion delve into the nitty gritty implementation details. This way, the chairs would create a path forward that encourages competition rather than cooperation. And any good idea could be considered by the whole group. By contrast, asking folks to create full-fledged proposals right now does the opposite -- encouraging competition and confrontation, rather than cooperation. Please consider taking the cooperative path forward. Ran rja@extremenetworks.com From owner-multi6@ops.ietf.org Sun Mar 23 19:07:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15977 for ; Sun, 23 Mar 2003 19:07:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xFUX-000KEj-00 for multi6-data@psg.com; Sun, 23 Mar 2003 16:07:05 -0800 Received: from sj-core-5.cisco.com ([171.71.177.238]) by psg.com with esmtp (Exim 3.36 #1) id 18xFTz-000K8o-00 for multi6@ops.ietf.org; Sun, 23 Mar 2003 16:06:31 -0800 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2O05pHp001633; Sun, 23 Mar 2003 16:05:56 -0800 (PST) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id AAA07994; Mon, 24 Mar 2003 00:05:51 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: Kurt Erik Lindqvist Cc: multi6@ops.ietf.org Subject: Re: Longer prefixes From: Ole Troan Date: Mon, 24 Mar 2003 00:05:51 +0000 In-Reply-To: (Kurt Erik Lindqvist's message of "Sun, 23 Mar 2003 18:27:40 +0100") Message-ID: <7t5vfy9wrvk.fsf@mrwint.cisco.com> User-Agent: Gnus/5.090011 (Oort Gnus v0.11) Emacs/21.2.95 (sparc-sun-solaris2.8) References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-27.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_GNUS_UA,X_AUTH_WARNING autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > As there was some discussions in Atlanta on wether longer prefixes is > actually in use today. This is just the first page of sh ipv6 route on > one of my home routers : ipv6-lab-gw>show ipv6 route summary IPv6 Routing Table Summary - 730 entries 167 local, 84 connected, 38 static, 6 RIP, 435 BGP 0 IS-IS, 0 OSPF Number of prefixes: /8: 1, /10: 1, /16: 1, /24: 47, /28: 49, /32: 207, /33: 2, /34: 2 /35: 54, /36: 2, /40: 6, /42: 1, /44: 4, /48: 94, /64: 85, /96: 1 /112: 1, /125: 1, /126: 4, /127: 1, /128: 166 /ot From owner-multi6@ops.ietf.org Sun Mar 23 20:04:56 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17042 for ; Sun, 23 Mar 2003 20:04:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xGPV-000PTl-00 for multi6-data@psg.com; Sun, 23 Mar 2003 17:05:57 -0800 Received: from host217-37-202-105.in-addr.btopenworld.com ([217.37.202.105] helo=ab.use.net) by psg.com with esmtp (Exim 3.36 #1) id 18xGNo-000PBu-00 for multi6@ops.ietf.org; Sun, 23 Mar 2003 17:04:12 -0800 Received: from ab.use.net (conf.use.net [217.37.202.109]) by ab.use.net (Postfix) with ESMTP id 22D48B98; Mon, 24 Mar 2003 01:03:45 +0000 (GMT) Date: Mon, 24 Mar 2003 01:03:44 +0000 Subject: A Way Forward Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: multi6@ops.ietf.org To: Kurt Erik Lindqvist From: Sean Doran In-Reply-To: <6EDB3E54-5C26-11D7-B5E2-000393AB1404@kurtis.pp.se> Message-Id: <75F600C2-5D94-11D7-9B7A-0003938E4DE4@ab.use.net> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-21.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit (public message follows) Kurtis - On Saturday, Mar 22, 2003, at 05:23 Europe/London, Kurt Erik Lindqvist wrote: > I have no problem with loading the chairs (I guess Sean will give me a > hard time for this...:) ) No. Setting out a (fairly typical) process and trying to convince the volunteers here to come to consensus on the first item was a nearly-complete failure, so I am watching to see if a consensus develops over other approaches. I have to say that at least three stark contrasts -- that advanced by tli/rja suggesting a new process, that advanced by Christian Huitema (and apparently attractive to you) suggesting a parallelization of labour, and that advanced by Ohta-san, suggesting all-out warfare, each have their alluring qualities (and some drawbacks), as well as considerable history within other parts of the IETF. There is also an unstated but discussed-in-the-background approach of developing consensus over a document stating that: - scalable site-multihoming IS in the critical path of deployment - the problem is not currently well-understood within the IETF - there are many ideas about the problem, and about its solution - there are no known working-code/tested solutions - there is no agreed way to evaluate such solutions properly anyway - however, some are worth development & experimentation (even those that would require a fundamental revisiting of the architectural underpinnings of IPv6 by the Internet Area) - some are plainly stupid - "we tried and failed" Which approach to support officially is not clear to me right now, although *personally* I am leaning towards the last one. Since that approach can be done later if necessary ("we tried twice and failed"... "we tried n times and failed"), I shall probably continue to hover in the background until what looks like a very very very rough consensus starts to develop on this. Sean. From owner-multi6@ops.ietf.org Sun Mar 23 20:08:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17091 for ; Sun, 23 Mar 2003 20:08:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xGSE-000Pi9-00 for multi6-data@psg.com; Sun, 23 Mar 2003 17:08:46 -0800 Received: from d12lmsgate-5.de.ibm.com ([194.196.100.238]) by psg.com with esmtp (Exim 3.36 #1) id 18xGRi-000Pd6-00 for multi6@ops.ietf.org; Sun, 23 Mar 2003 17:08:14 -0800 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-5.de.ibm.com (8.12.8/8.12.3) with ESMTP id h2O17kOI115702 for ; Mon, 24 Mar 2003 02:07:46 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h2O17k7A225546 for ; Mon, 24 Mar 2003 02:07:46 +0100 Received: from gsine06.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA29190 from ; Mon, 24 Mar 2003 02:07:38 +0100 Message-Id: <3E7E4F0E.69D97DB1@hursley.ibm.com> Date: Mon, 24 Mar 2003 01:19:26 +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: multi6@ops.ietf.org Subject: Re: Again no multi6 at IETF#56 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-9.8 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tony Li wrote: ... > We are currently trying to hold people off from deploying v6 because > this issue is not closed. Who's "we" please? There's a fair number of people who certainly aren't trying to do anything of the kind. Brian From owner-multi6@ops.ietf.org Sun Mar 23 20:38:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17567 for ; Sun, 23 Mar 2003 20:38:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xGwb-0002la-00 for multi6-data@psg.com; Sun, 23 Mar 2003 17:40:09 -0800 Received: from d12lmsgate-2.de.ibm.com ([194.196.100.235]) by psg.com with esmtp (Exim 3.36 #1) id 18xGw4-0002aT-00 for multi6@ops.ietf.org; Sun, 23 Mar 2003 17:39:37 -0800 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.8/8.12.8) with ESMTP id h2O1cx33015410; Mon, 24 Mar 2003 02:39:00 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h2O1cx7A231408; Mon, 24 Mar 2003 02:38:59 +0100 Received: from gsine06.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA35552 from ; Mon, 24 Mar 2003 02:38:56 +0100 Message-Id: <3E7E616F.DFA505C6@hursley.ibm.com> Date: Mon, 24 Mar 2003 02:37:51 +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: Ole Troan Cc: Kurt Erik Lindqvist , multi6@ops.ietf.org Subject: Re: Longer prefixes References: <7t5vfy9wrvk.fsf@mrwint.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-6.6 required=5.0 tests=REFERENCES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ole Troan wrote: ... > /96: 1 > /112: 1, /125: 1, /126: 4, /127: 1 And what are these?? Brian From owner-multi6@ops.ietf.org Mon Mar 24 02:39:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06754 for ; Mon, 24 Mar 2003 02:39:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xMYQ-0008zO-00 for multi6-data@psg.com; Sun, 23 Mar 2003 23:39:34 -0800 Received: from dmz2.procket.com ([65.174.124.37]) by psg.com with esmtp (Exim 3.36 #1) id 18xMXu-0008tD-00 for multi6@ops.ietf.org; Sun, 23 Mar 2003 23:39:02 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id CA5E03444A; Sun, 23 Mar 2003 22:51:50 -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 h2O7cdYB016985; Sun, 23 Mar 2003 23:38:39 -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="us-ascii" Subject: RE: Again no multi6 at IETF#56 Date: Sun, 23 Mar 2003 23:38:39 -0800 Message-ID: Thread-Topic: Again no multi6 at IETF#56 Thread-Index: AcLxo8n4G9obXf/ES2C9AyNQkCaoQQANHVsw From: "Tony Li" To: "Brian E Carpenter" , X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA06754 | Tony Li wrote: | ... | > We are currently trying to hold people off from | deploying v6 because | > this issue is not closed. | | Who's "we" please? There's a fair number of people who certainly | aren't trying to do anything of the kind. Some of us who aren't fans of the current routing architecture. Not all of them are IETF folks and I'm certainly not in a position where I can claim to speak for them. Tony From owner-multi6@ops.ietf.org Mon Mar 24 04:07:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07996 for ; Mon, 24 Mar 2003 04:07:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xNts-000FGp-00 for multi6-data@psg.com; Mon, 24 Mar 2003 01:05:48 -0800 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74]) by psg.com with esmtp (Exim 3.36 #1) id 18xNtL-000FCc-00 for multi6@ops.ietf.org; Mon, 24 Mar 2003 01:05:15 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2O96IKW010367; Mon, 24 Mar 2003 10:06:18 +0100 (CET) Date: Mon, 24 Mar 2003 10:06:17 +0100 Subject: Re: Again no multi6 at IETF#56 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Tony Li" , "Bound, Jim" , "Michael H. Lambert" , To: David Conrad From: Kurt Erik Lindqvist In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-9.2 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> Agreed, still we need to try and guess when that will be. Mostly >> because that will set the agenda. I would be interested in seeing >> what the trend curves for the IPv6 routing table looks like from the >> people monitoring these. But I am not sure if Geoff Huston or Gert >> During for example are on this list. > > There are not enough significant data points to do any sort of trend > analysis at this point in time. I agree with Tony -- as a person who > personally still gets criticized for the fact that China doesn't have > as much address space as MIT, we will regret not addressing the > multi-homing (and related) issues now, before "historical mistakes" > become permanent. Well, I haven't said that we should deploy or standardize multiple solutions necessarily. > > Further, if we address the multi-homing (and related) issues, there > will be a clear and obvious justification for IPv6 deployment which > has not, to date, been made. I am not convinced that comes out of the multi6 problem alone. - kurtis - From owner-multi6@ops.ietf.org Mon Mar 24 04:11:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08062 for ; Mon, 24 Mar 2003 04:11:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xO0W-000FgR-00 for multi6-data@psg.com; Mon, 24 Mar 2003 01:12:40 -0800 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74]) by psg.com with esmtp (Exim 3.36 #1) id 18xNzz-000Fcs-00 for multi6@ops.ietf.org; Mon, 24 Mar 2003 01:12:08 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2O9DBKW010370; Mon, 24 Mar 2003 10:13:12 +0100 (CET) Date: Mon, 24 Mar 2003 10:13:10 +0100 Subject: Re: Start running Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Masataka Ohta" , To: "Tony Li" From: Kurt Erik Lindqvist In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-9.2 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > | Although I generally tend to agree with your view, I do > | think that we > | need let everyone present their opinions and evaluate > | them. > > > I fully endorse this. But the implication of drafting full blown > proposals for each alternative is not one where you, as a manager, > set yourself up for success. You instantly make it competitive and > not collaborative. Ok, I think I have misunderstood you, or the other way around. I am not suggesting that we draft full blown solutions for each alternative. I think we need to have them all up for review and that we need to have enough meat on the bones to be able to make a judgment. Exactly what those are is still to be decided but should somehow me in the milestones IMO. > > | You and me > | have a certain view of where to go, maybe that is where we > | will end up > | eventually (of-course I hope so), but in order to start > | working on one > | single solution we need to have a consensus saying that is > | where we > | want to go. And we wont get there unless we have looked at the > | alternatives thoroughly. > > > Then we should apply good engineering practices (see problem > statement WG) and bound the problem, partition the solution space > and discuss the high level approaches. Only after we have consensus > should we be pushing down into more details. Agree! > > > | I have no problem with loading the chairs (I guess Sean > | will give me a > | hard time for this...:) ) if that brings us forward, and I > | think you > | are right, but I think we need to do some other steps first. > > > Ok, what and when? > My personal view is (not discussed with my co-chair or the ADs in any greater length yet) that we need to a) Get the 'requirements' document shipped, B) We need to determine what solutions categories we want to look at c) We need to determine to what level of detail we want these solutions worked out d) We need to get the results of b) and c) into the WG charter and update the dates of the milestones e) we need to agree on what solution is to be worked out in more detailed In terms of time-line this very much depends on how fast we can do b) and c). One scenario is that we work on b) and c) in parallel to c) and then discuss all of these in Vienna. That will be a very long WG session though... - kurtis - From owner-multi6@ops.ietf.org Mon Mar 24 04:13:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08084 for ; Mon, 24 Mar 2003 04:13:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xO3F-000Frh-00 for multi6-data@psg.com; Mon, 24 Mar 2003 01:15:29 -0800 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74]) by psg.com with esmtp (Exim 3.36 #1) id 18xO2C-000Flo-00 for multi6@ops.ietf.org; Mon, 24 Mar 2003 01:14:24 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2O9FUKW010373; Mon, 24 Mar 2003 10:15:31 +0100 (CET) Date: Mon, 24 Mar 2003 10:15:30 +0100 Subject: Re: Again no multi6 at IETF#56 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Bound, Jim" , "Michael H. Lambert" , To: "Tony Li" From: Kurt Erik Lindqvist In-Reply-To: Message-Id: <289A82EC-5DD9-11D7-B5E2-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-9.2 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > | Agreed, still we need to try and guess when that will be. Mostly > | because that will set the agenda. I would be interested in > | seeing what > | the trend curves for the IPv6 routing table looks like > | from the people > | monitoring these. But I am not sure if Geoff Huston or > | Gert During for > | example are on this list. > > > We are currently trying to hold people off from deploying v6 because > this issue is not closed. If it was closed, if v6 really was a > better architecture, if things actually worked, then we would have > been done a few years ago. Consider: Windows has already adopted it, > most of the routers are well along the way. All it takes is us > (the IETF community) telling folks that it's ready. I have for a quite long time been saying that IPv6 currently does not give any advantage to IPv4 except longer addresses. Now, there is enough room for discussion for it's own mailing list so I guess that is somewhat off-topic. > > So please don't set the schedule based on when people WILL show up. > If we wait for that point, then events will have overtaken us, we > will have lost control of deployment and the same old routing > architecture will be too solidly ingrained for people to think > about moving. We are already getting quite a bit of backpressure > on not changing anything related to v6 already. This can only > grow over time. Agreed. The schedule have to be independent of when people will show up. - kurtis - From owner-multi6@ops.ietf.org Mon Mar 24 04:18:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08266 for ; Mon, 24 Mar 2003 04:18:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xO7Q-000G7Q-00 for multi6-data@psg.com; Mon, 24 Mar 2003 01:19:48 -0800 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74]) by psg.com with esmtp (Exim 3.36 #1) id 18xO6u-000G1t-00 for multi6@ops.ietf.org; Mon, 24 Mar 2003 01:19:16 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2O9KLKW010376; Mon, 24 Mar 2003 10:20:22 +0100 (CET) Date: Mon, 24 Mar 2003 10:20:21 +0100 Subject: Re: Start running Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Tony Li" , To: RJ Atkinson From: Kurt Erik Lindqvist In-Reply-To: <1496D278-5D6C-11D7-85E9-00039357A82A@extremenetworks.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-8.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> | Although I generally tend to agree with your view, I do >> | think that we >> | need let everyone present their opinions and evaluate >> | them. >> >> I fully endorse this. But the implication of drafting full blown >> proposals for each alternative is not one where you, as a manager, >> set yourself up for success. You instantly make it competitive and >> not collaborative. > > I'll try to paraphrase tli's view. > > Full and open discussion is necessary and helpful. However, having > such discussion does not imply that the WG Chairs should create > something > resembling a "horse race" to create competing proposals that will then > "fight it out". That was not my intention or what I meant. See other mail to Tony. > An alternative approach, one (IMHO) much more likely to be successful > in creating a co-operative WG environment, is to have an open > discussion > that is thoughtfully structured, top down. For example, the initial > phase > of the discussion probably should be about the high-level technical > issues > being addressed and possible architectural approaches to those issues. > Once > rough consensus (smooth consensus not being a customary IETF > requirement) > is achieved on the high-level issues and on the architectural approach, > the discussion could then move on to a next phase with a few high-level > engineering details being sorted out. Once those are sorted out, an This sounds like what I proposed in the mail to Tony? > additional level of detail could be addressed. Only at the end would > the > discussion delve into the nitty gritty implementation details. This > way, > the chairs would create a path forward that encourages competition > rather > than cooperation. And any good idea could be considered by the whole > group. > > By contrast, asking folks to create full-fledged proposals right > now does the opposite -- encouraging competition and confrontation, > rather than cooperation. > > Please consider taking the cooperative path forward. > I think you are describing what I said in the mail to Tony. The problem as I see it at the moment is that there currently is no solution that is on the table and there is no "magic dust" (expression stolen). We need to start with realizing that we are at scratch (I know some people disagree). However, I also think that there currently are to many views on what the architecture should be based on. In order to better understand this, I think we need to look at the various architectural proposals made. This needs to be made as a working group, and then from there we need to work together on one solution. Best regards, - kurtis - From owner-multi6@ops.ietf.org Mon Mar 24 04:25:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08324 for ; Mon, 24 Mar 2003 04:25:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xOEi-000GcR-00 for multi6-data@psg.com; Mon, 24 Mar 2003 01:27:20 -0800 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74]) by psg.com with esmtp (Exim 3.36 #1) id 18xOEB-000GYV-00 for multi6@ops.ietf.org; Mon, 24 Mar 2003 01:26:48 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2O9QgKW010379; Mon, 24 Mar 2003 10:26:42 +0100 (CET) Date: Mon, 24 Mar 2003 10:26:41 +0100 Subject: Re: A Way Forward Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: multi6@ops.ietf.org To: Sean Doran From: Kurt Erik Lindqvist In-Reply-To: <75F600C2-5D94-11D7-9B7A-0003938E4DE4@ab.use.net> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-9.2 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > I have to say that at least three stark contrasts -- that advanced by > tli/rja suggesting a new process, that advanced by Christian Huitema > (and apparently attractive to you) suggesting a parallelization of > labour, > and that advanced by Ohta-san, suggesting all-out warfare, each > have their alluring qualities (and some drawbacks), as well as > considerable > history within other parts of the IETF. I agree on this observation, but note that I would like to combine the proposals of tli/rja and Christian. > There is also an unstated but discussed-in-the-background > approach of developing consensus over a document stating that: > > - scalable site-multihoming IS in the critical path of deployment > - the problem is not currently well-understood within the IETF > - there are many ideas about the problem, and about its solution > - there are no known working-code/tested solutions > - there is no agreed way to evaluate such solutions properly anyway > - however, some are worth development & experimentation > (even those that would require a fundamental revisiting of > the architectural underpinnings of IPv6 by the Internet Area) > - some are plainly stupid > - "we tried and failed" I think that a document like to above would be useful, but I do not see what the road after this would be. I agree with the statements above, and indirectly this to me implies that we have failed with the design of IPv6. Now in a way that might be a reasonable statement depending on your needs, but at the same time it does little to help us move forward. > Which approach to support officially is not clear to me right now, > although *personally* I am leaning towards the last one. Since that > approach can be done later if necessary ("we tried twice and failed"... > "we tried n times and failed"), I shall probably continue to hover in > the > background until what looks like a very very very rough consensus > starts to develop on this. > And I think we therefor need this discussion on where we want to move. Maybe you are right and we will come to the conclusion above. As I said before, I would consider reaching consensus on failure and that there is no way forward an achievement as well. But I am just a bit to stubborn to give up just yet. Best regards, - kurtis - From owner-multi6@ops.ietf.org Mon Mar 24 08:27:21 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16635 for ; Mon, 24 Mar 2003 08:27:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xRyq-0007DT-00 for multi6-data@psg.com; Mon, 24 Mar 2003 05:27:12 -0800 Received: from gnat.inet.org ([63.108.254.91]) by psg.com with esmtp (Exim 3.36 #1) id 18xRyJ-00078w-00 for multi6@ops.ietf.org; Mon, 24 Mar 2003 05:26:40 -0800 Received: from extremenetworks.com (unknown [10.0.8.83]) by gnat.inet.org (Postfix) with ESMTP id C1B0D6710B; Mon, 24 Mar 2003 08:44:34 -0500 (EST) Date: Mon, 24 Mar 2003 08:26:13 -0500 Subject: Re: Start running Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Tony Li" , To: Kurt Erik Lindqvist From: RJ Atkinson In-Reply-To: Message-Id: <2F33CCF1-5DFC-11D7-98ED-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-21.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Monday, Mar 24, 2003, at 04:20 America/Montreal, Kurt Erik Lindqvist wrote: > That was not my intention or what I meant. See other mail to Tony. > ... > This sounds like what I proposed in the mail to Tony? > ... > I think you are describing what I said in the mail to Tony. It was certainly not apparent that your note to tli contained anything like the proposal I outlined above. Thanks for the clarification. > The problem as I see it at the moment is that there currently is > no solution that is on the table and there is no "magic dust" > (expression stolen). We need to start with realizing that we are > at scratch (I know some people disagree). However, I also think > that there currently are to many views on what the architecture > should be based on. In order to better understand this, I think > we need to look at the various architectural proposals made. This > needs to be made as a working group, and then from there we need > to work together on one solution. s/architectural proposals/architectural approaches/ Again, "proposals" sounds like one is trying to foster competition, rather than cooperation. And while opinions will vary about what constitutes "architecture", maybe we all agree that architecture is extremely high-level, hence devoid of most/all implementation details. Ran rja@extremenetworks.com From owner-multi6@ops.ietf.org Mon Mar 24 08:28:06 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16728 for ; Mon, 24 Mar 2003 08:28:05 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xS1A-0007Ka-00 for multi6-data@psg.com; Mon, 24 Mar 2003 05:29:36 -0800 Received: from gnat.inet.org ([63.108.254.91]) by psg.com with esmtp (Exim 3.36 #1) id 18xS0d-0007IE-00 for multi6@ops.ietf.org; Mon, 24 Mar 2003 05:29:03 -0800 Received: from extremenetworks.com (unknown [10.0.8.83]) by gnat.inet.org (Postfix) with ESMTP id 7D7BD6710B for ; Mon, 24 Mar 2003 08:47:02 -0500 (EST) Date: Mon, 24 Mar 2003 08:28:41 -0500 Subject: Architectural approaches to multi6 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: RJ Atkinson To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <873629A0-5DFC-11D7-98ED-00039357A82A@extremenetworks.com> X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-21.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Monday, Mar 24, 2003, at 04:20 America/Montreal, Kurt Erik Lindqvist wrote: > However, I also think that there currently are to many views on what > the architecture should be based on. The only architectural approach that I've seen on this list in recent months is the notion of deprecating the concept of an "address", in favour of using "locator" and "identifier" for the separate purposes of routing and identity. Maybe I've overlooked something ? If there is another architectural approach in the wings, maybe someone would be kind enough to summarise that alternate approach to the list ? Ran rja@extremenetworks.com From owner-multi6@ops.ietf.org Mon Mar 24 08:35:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16969 for ; Mon, 24 Mar 2003 08:35:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xS7w-0007vo-00 for multi6-data@psg.com; Mon, 24 Mar 2003 05:36:36 -0800 Received: from gnat.inet.org ([63.108.254.91]) by psg.com with esmtp (Exim 3.36 #1) id 18xS7Q-0007pe-00 for multi6@ops.ietf.org; Mon, 24 Mar 2003 05:36:04 -0800 Received: from extremenetworks.com (unknown [10.0.8.83]) by gnat.inet.org (Postfix) with ESMTP id EE0FC6710B; Mon, 24 Mar 2003 08:54:00 -0500 (EST) Date: Mon, 24 Mar 2003 08:35:39 -0500 Subject: Re: A Way Forward Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Sean Doran , multi6@ops.ietf.org To: Kurt Erik Lindqvist From: RJ Atkinson In-Reply-To: Message-Id: <80AD53D1-5DFD-11D7-98ED-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-21.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Monday, Mar 24, 2003, at 04:26 America/Montreal, Kurt Erik Lindqvist wrote: >> I have to say that at least three stark contrasts -- that advanced by >> tli/rja suggesting a new process, that advanced by Christian Huitema >> (and apparently attractive to you) suggesting a parallelization of >> labour, >> and that advanced by Ohta-san, suggesting all-out warfare, each >> have their alluring qualities (and some drawbacks), as well as >> considerable >> history within other parts of the IETF. > > I agree on this observation, but note that I would like to combine > the proposals of tli/rja and Christian. Kurt, Well that would not be the same as what tli/rja have proposed. Earlier today you claimed to agree with the process approach proposed by tli/rja. Now you say you want something different, though it is unclear (to me at least) what you want to do differently. I'm fairly confused by your various notes of the past few days. Maybe you could start over again and outline what process approach that you are proposing that the WG follow ? >> There is also an unstated but discussed-in-the-background >> approach of developing consensus over a document stating that: >> >> - scalable site-multihoming IS in the critical path of deployment >> - the problem is not currently well-understood within the IETF >> - there are many ideas about the problem, and about its solution >> - there are no known working-code/tested solutions >> - there is no agreed way to evaluate such solutions properly anyway >> - however, some are worth development & experimentation >> (even those that would require a fundamental revisiting of >> the architectural underpinnings of IPv6 by the Internet Area) >> - some are plainly stupid >> - "we tried and failed" > > I think that a document like to above would be useful, > but I do not see what the road after this would be. I think that everything from smd, except the last bullet, is pretty widely agreed upon here and would be worth documenting. The last bullet ("we tried and failed") is too pessimistic for my own view right now, hence the desire to try a top-down cooperative approach (starting with finding an agreeable architectural approach). I'd also like to see some requirements document get sorted out and published, so that we understand what issues we are trying to address. One possible way to sort it out would be for the document editor to hold an organised on-list document review section by section, with several days to discuss the current contents of each section. Other approaches might also work to sort through such a document. Ran rja@extremenetworks.com From owner-multi6@ops.ietf.org Mon Mar 24 08:54:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18395 for ; Mon, 24 Mar 2003 08:54:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xSQa-0009hO-00 for multi6-data@psg.com; Mon, 24 Mar 2003 05:55:52 -0800 Received: from sj-core-5.cisco.com ([171.71.177.238]) by psg.com with esmtp (Exim 3.36 #1) id 18xSOm-0009UB-00 for multi6@ops.ietf.org; Mon, 24 Mar 2003 05:54:00 -0800 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2ODrRHp000749; Mon, 24 Mar 2003 05:53:28 -0800 (PST) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id NAA23818; Mon, 24 Mar 2003 13:53:16 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: Brian E Carpenter Cc: Kurt Erik Lindqvist , multi6@ops.ietf.org Subject: Re: Longer prefixes From: Ole Troan Date: Mon, 24 Mar 2003 13:53:16 +0000 In-Reply-To: <3E7E616F.DFA505C6@hursley.ibm.com> (Brian E Carpenter's message of "Mon, 24 Mar 2003 02:37:51 +0100") Message-ID: <7t5el4wrhv7.fsf@mrwint.cisco.com> User-Agent: Gnus/5.090011 (Oort Gnus v0.11) Emacs/21.2.95 (sparc-sun-solaris2.8) References: <7t5vfy9wrvk.fsf@mrwint.cisco.com> <3E7E616F.DFA505C6@hursley.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-17.7 required=5.0 tests=IN_REP_TO,REFERENCES,USER_AGENT_GNUS_UA,X_AUTH_WARNING autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk >> /96: 1 >> /112: 1, /125: 1, /126: 4, /127: 1 > > And what are these?? automatic tunnelling (::/96) and point to point links. /ot From owner-multi6@ops.ietf.org Mon Mar 24 09:17:50 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19450 for ; Mon, 24 Mar 2003 09:17:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xSn4-000BQE-00 for multi6-data@psg.com; Mon, 24 Mar 2003 06:19:06 -0800 Received: from d12lmsgate-3.de.ibm.com ([194.196.100.236]) by psg.com with esmtp (Exim 3.36 #1) id 18xSmY-000BL5-00 for multi6@ops.ietf.org; Mon, 24 Mar 2003 06:18:35 -0800 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.8/8.12.8) with ESMTP id h2OEI6EO113890 for ; Mon, 24 Mar 2003 15:18:06 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h2OEI52g134360 for ; Mon, 24 Mar 2003 15:18:06 +0100 Received: from gsine06.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA49344 from ; Mon, 24 Mar 2003 15:18:03 +0100 Message-Id: <3E7F135A.C15DA98D@hursley.ibm.com> Date: Mon, 24 Mar 2003 15:16: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: multi6@ops.ietf.org Subject: Re: Start running References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-9.8 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kurt Erik Lindqvist wrote: ... > In order to > better understand this, I think we need to look at the various > architectural proposals made. This needs to be made as a working group, > and then from there we need to work together on one solution. Can't disagree with that as a strategy. However, the 8+8 experience was that you have to go a long way into the details to find out if a solution is really useable. So it will be hard to avoid a detailed analysis of each possible proposal. Brian From owner-multi6@ops.ietf.org Mon Mar 24 09:59:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20727 for ; Mon, 24 Mar 2003 09:59:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xTQh-000Enl-00 for multi6-data@psg.com; Mon, 24 Mar 2003 07:00:03 -0800 Received: from elle.sprintlink.net ([199.0.234.34] helo=iscserv1.res.sprintlink.net) by psg.com with esmtp (Exim 3.36 #1) id 18xTOt-000EdB-00 for multi6@ops.ietf.org; Mon, 24 Mar 2003 06:58:11 -0800 Received: from localhost (rrockell@localhost) by iscserv1.res.sprintlink.net (8.8.8+Sun/8.6.12) with ESMTP id KAA23448; Mon, 24 Mar 2003 10:01:00 -0500 (EST) X-Authentication-Warning: iscserv1.res.sprintlink.net: rrockell owned process doing -bs Date: Mon, 24 Mar 2003 10:01:00 -0500 (EST) From: "Robert J. Rockell" X-X-Sender: To: Kurt Erik Lindqvist cc: Subject: Re: Longer prefixes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-17.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,USER_AGENT_PINE,X_AUTH_WARNING autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Is this a broken filter, or needed de-aggregation? I would expect the former. Has there been any official move away from 2772 for production space? Thanks Rob Rockell SprintLink (+1) 703-689-6322 ----------------------------------------------------------------------- On Sun, 23 Mar 2003, Kurt Erik Lindqvist wrote: -> -> ->As there was some discussions in Atlanta on wether longer prefixes is ->actually in use today. This is just the first page of sh ipv6 route on ->one of my home routers : -> ->IPv6 Routing Table - 438 entries ->Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP -> I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea ->Timers: Uptime/Expires -> ->B 2001:200:126::/48 [20/6] -> via FE80::C15E:FA3A, Tunnel10, 02:22:30/never ->B 2001:200:202::/48 [20/6] -> via FE80::C15E:FA3A, Tunnel10, 02:22:56/never ->B 2001:200:203::/48 [20/6] -> via FE80::C15E:FA3A, Tunnel10, 4d01h/never ->B 2001:200:200::/40 [20/5] -> via 2001:670:87:3001::, Tunnel10, 4d01h/never ->B 2001:200:340::/48 [20/6] -> via FE80::C15E:FA3A, Tunnel10, 4d01h/never ->B 2001:200:300::/40 [20/6] -> via FE80::C15E:FA3A, Tunnel10, 4d01h/never ->B 2001:200:500::/40 [20/3] -> via FE80::C15E:FA3A, Tunnel10, 5d17h/never ->B 2001:200::/35 [20/3] -> via 2001:670:87:3001::, Tunnel10, 3d03h/never ->B 2001:208::/32 [20/5] -> via 2001:670:87:3001::, Tunnel10, 3d03h/never ->B 2001:218::/32 [20/3] -> via 2001:670:87:3001::, Tunnel10, 1d06h/never ->B 2001:220::/35 [20/4] -> via FE80::82F4:B4, Tunnel30, 02:51:25/never ->B 2001:228:C00::/40 [20/5] -> via 2001:670:87:3001::, Tunnel10, 4d01h/never -> -> ->It appears as if there are number of prefix lengths being in use. -> ->Best regards, -> ->- kurtis - -> -> From owner-multi6@ops.ietf.org Mon Mar 24 11:01:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24068 for ; Mon, 24 Mar 2003 11:01:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xUPA-000K7L-00 for multi6-data@psg.com; Mon, 24 Mar 2003 08:02:32 -0800 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74]) by psg.com with esmtp (Exim 3.36 #1) id 18xUOe-000K2e-00 for multi6@ops.ietf.org; Mon, 24 Mar 2003 08:02:00 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2OG34KW010597; Mon, 24 Mar 2003 17:03:04 +0100 (CET) Date: Mon, 24 Mar 2003 17:03:03 +0100 Subject: Re: Start running Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Tony Li" , To: RJ Atkinson From: Kurt Erik Lindqvist In-Reply-To: <2F33CCF1-5DFC-11D7-98ED-00039357A82A@extremenetworks.com> Message-Id: <17D11312-5E12-11D7-B5E2-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-8.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> That was not my intention or what I meant. See other mail to Tony. >> ... >> This sounds like what I proposed in the mail to Tony? >> ... >> I think you are describing what I said in the mail to Tony. > > It was certainly not apparent that your note to tli contained anything > like the proposal I outlined above. Thanks for the clarification. Well, I think we are close anyway. > >> The problem as I see it at the moment is that there currently is >> no solution that is on the table and there is no "magic dust" >> (expression stolen). We need to start with realizing that we are >> at scratch (I know some people disagree). However, I also think >> that there currently are to many views on what the architecture >> should be based on. In order to better understand this, I think >> we need to look at the various architectural proposals made. This >> needs to be made as a working group, and then from there we need >> to work together on one solution. > > s/architectural proposals/architectural approaches/ > > Again, "proposals" sounds like one is trying to foster competition, > rather than cooperation. > > And while opinions will vary about what constitutes "architecture", > maybe we all agree that architecture is extremely high-level, > hence devoid of most/all implementation details. > I think that this is what I would like to work out. A common understanding of what exactly want to put on the table to start with. What to call it, and how much details. - kurtis - From owner-multi6@ops.ietf.org Mon Mar 24 11:49:39 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25118 for ; Mon, 24 Mar 2003 11:49:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xV9a-000OOU-00 for multi6-data@psg.com; Mon, 24 Mar 2003 08:50:30 -0800 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by psg.com with esmtp (Exim 3.36 #1) id 18xV94-000OJ3-00 for multi6@ops.ietf.org; Mon, 24 Mar 2003 08:49:58 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id A93B4165D; Mon, 24 Mar 2003 11:49:35 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 24 Mar 2003 11:49:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Again no multi6 at IETF#56 Date: Mon, 24 Mar 2003 11:49:35 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCDE6@tayexc13.americas.cpqcorp.net> Thread-Topic: Again no multi6 at IETF#56 Thread-Index: AcLxo5uXVQvky+NsRmqhT1SMHwz+LQAgWU+w From: "Bound, Jim" To: "Brian E Carpenter" , X-OriginalArrivalTime: 24 Mar 2003 16:49:35.0612 (UTC) FILETIME=[59EB9BC0:01C2F225] X-Spam-Status: No, hits=-3.2 required=5.0 tests=QUOTED_EMAIL_TEXT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA25118 ACK. I support no statement to hold of IPv6 deployment. It is in process accept that. And the IETF again does not state or have anything to say about deployment of any protocol. Not our job here. /jim > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Sunday, March 23, 2003 7:19 PM > To: multi6@ops.ietf.org > Subject: Re: Again no multi6 at IETF#56 > > > Tony Li wrote: > ... > > We are currently trying to hold people off from deploying > v6 because > > this issue is not closed. > > Who's "we" please? There's a fair number of people who > certainly aren't trying to do anything of the kind. > > Brian > > > > From owner-multi6@ops.ietf.org Mon Mar 24 11:51:12 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25164 for ; Mon, 24 Mar 2003 11:51:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xVBX-000OcK-00 for multi6-data@psg.com; Mon, 24 Mar 2003 08:52:31 -0800 Received: from mailout.zma.compaq.com ([161.114.64.103] helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18xVB1-000OVg-00 for multi6@ops.ietf.org; Mon, 24 Mar 2003 08:51:59 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 5AA1333FD; Mon, 24 Mar 2003 11:51:36 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 24 Mar 2003 11:51:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Again no multi6 at IETF#56 Date: Mon, 24 Mar 2003 11:51:35 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCDE7@tayexc13.americas.cpqcorp.net> Thread-Topic: Again no multi6 at IETF#56 Thread-Index: AcLx5bbW5j2C6rtuSNObA2MJqml9xAAP9How From: "Bound, Jim" To: "Kurt Erik Lindqvist" , "Tony Li" Cc: "Michael H. Lambert" , X-OriginalArrivalTime: 24 Mar 2003 16:51:36.0098 (UTC) FILETIME=[A1BC5020:01C2F225] X-Spam-Status: No, hits=-3.2 required=5.0 tests=QUOTED_EMAIL_TEXT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA25164 > I have for a quite long time been saying that IPv6 currently does not > give any advantage to IPv4 except longer addresses. Now, there is > enough room for discussion for it's own mailing list so I > guess that is > somewhat off-topic. May I suggest we not go here? Not relative to our mission. Thanks /jim From owner-multi6@ops.ietf.org Mon Mar 24 12:59:31 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27065 for ; Mon, 24 Mar 2003 12:59:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xWEa-0005Cf-00 for multi6-data@psg.com; Mon, 24 Mar 2003 09:59:44 -0800 Received: from dmz1.procket.com ([65.174.124.36]) by psg.com with esmtp (Exim 3.36 #1) id 18xWE3-000587-00 for multi6@ops.ietf.org; Mon, 24 Mar 2003 09:59:11 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 7DE3123C24; Mon, 24 Mar 2003 09:48: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 h2OHwlYB001209; Mon, 24 Mar 2003 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="us-ascii" Subject: RE: Architectural approaches to multi6 Date: Mon, 24 Mar 2003 09:58:47 -0800 Message-ID: Thread-Topic: Architectural approaches to multi6 Thread-Index: AcLyDL2jG+TjvP2gRw63MSXkMI4CDAAIebYQ From: "Tony Li" To: "RJ Atkinson" , X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA27065 | The only architectural approach that I've seen on this | list in recent | months is the notion of deprecating the concept of an "address", | in favour of using "locator" and "identifier" for the | separate purposes | of routing and identity. Maybe I've overlooked something ? | | If there is another architectural approach in the wings, | maybe someone | would be kind enough to summarise that alternate approach | to the list ? Ran, I've seen a number of other proposals, but at the architectural level, they seem to all boil down to using tunneling to provide virtual topology that would match the addressing. While this certainly works and I'm a big fan of tunneling for some reasons, I'm concerned about an architecture that makes multi-homing a second class citizen. It seems to me that if we can do it right the first time, we should. Tony From owner-multi6@ops.ietf.org Mon Mar 24 13:38:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28407 for ; Mon, 24 Mar 2003 13:38:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xWr0-00098X-00 for multi6-data@psg.com; Mon, 24 Mar 2003 10:39:26 -0800 Received: from gnat.inet.org ([63.108.254.91]) by psg.com with esmtp (Exim 3.36 #1) id 18xWqT-00091z-00 for multi6@ops.ietf.org; Mon, 24 Mar 2003 10:38:54 -0800 Received: from extremenetworks.com (unknown [10.0.8.117]) by gnat.inet.org (Postfix) with ESMTP id D3DBD6710B; Mon, 24 Mar 2003 13:56:52 -0500 (EST) Date: Mon, 24 Mar 2003 13:38:30 -0500 Subject: Re: Architectural approaches to multi6 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: "Tony Li" From: RJ Atkinson In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-21.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Monday, Mar 24, 2003, at 12:58 America/Montreal, Tony Li wrote: > I've seen a number of other proposals, but at the architectural > level, they seem to all boil down to using tunneling to provide > virtual topology that would match the addressing. > > While this certainly works and I'm a big fan of tunneling for > some reasons, I'm concerned about an architecture that makes > multi-homing a second class citizen. It seems to me that > if we can do it right the first time, we should. I also would strongly prefer a solution that makes multi-homing a native/first-class property of IPv6. Does anyone else have any other architectural approaches (besides the two mentioned so far) that the WG should consider ?? Existing architectural approaches seem to be: 1: identity/location separation; with the locator following the actual network topology & the identifier being quite independent of topology. 2: tunneling to create a virtual topology that matches the addressing Thanks, Ran From owner-multi6@ops.ietf.org Mon Mar 24 14:01:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29065 for ; Mon, 24 Mar 2003 14:01:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xXDW-000BUE-00 for multi6-data@psg.com; Mon, 24 Mar 2003 11:02:42 -0800 Received: from host217-37-202-105.in-addr.btopenworld.com ([217.37.202.105] helo=ab.use.net) by psg.com with esmtp (Exim 3.36 #1) id 18xXCz-000BP3-00 for multi6@ops.ietf.org; Mon, 24 Mar 2003 11:02:10 -0800 Received: from ab.use.net (ab.use.net [217.37.202.105]) by ab.use.net (Postfix) with ESMTP id 1614CBAF for ; Mon, 24 Mar 2003 19:01:42 +0000 (GMT) Date: Mon, 24 Mar 2003 18:56:16 +0000 Subject: Re: Again no multi6 at IETF#56 Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Sean Doran To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCDE6@tayexc13.americas.cpqcorp.net> Message-Id: <4A9CB1E0-5E2A-11D7-98D1-00039301C606@ab.use.net> X-Mailer: Apple Mail (2.552) X-Spam-Status: No, hits=-11.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jim - On mandag, mar 24, 2003, at 16:49 Europe/London, Bound, Jim wrote: > the IETF again does not state or have anything > to say about deployment of any protocol. Agreed, with one proviso: it is reasonable here to identify the present lack of scalable site multihoming as an obstacle to deployment, and to suggest ways in which this obstacle may be met and dealt with. > Not our job here. Our job is twofold: firstly, try to arrive at consensus over a good approach to scalable site multihoming that includes the current & former network operators participating in the WG, and secondly, to take advantage of the availability of willing operational experience and clue to avoid some of the brick walls we have hit (or approached at high speed) with IPv4, like this unpleasant period in late 1995: http://groups.google.com/ groups?selm=DHqupL.ALC%40gpu.utcc.utoronto.ca&oe=UTF-8&output=gplain Admittedly we learned quite a bit about how to build and operate fast routers from this sort of thing, but hitting the wall operationally is far more costly today than it was when the Internet was much smaller. I believe the market as a whole will choose to avoid serious scalability problems that are already known, since there are more than enough that are not known yet. Whether this happens by engineering IPv6 in directions different from -- but informed by -- IPv4, or by non-deployment, possibly will be influenced somewhat by cooperation here and between multi6 and the Internet Area. Sean. From owner-multi6@ops.ietf.org Mon Mar 24 14:28:44 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29825 for ; Mon, 24 Mar 2003 14:28:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xXdy-000ELR-00 for multi6-data@psg.com; Mon, 24 Mar 2003 11:30:02 -0800 Received: from smtp01.uc3m.es ([163.117.136.121] helo=smtp.uc3m.es) by psg.com with esmtp (Exim 3.36 #1) id 18xXdR-000EFO-00 for multi6@ops.ietf.org; Mon, 24 Mar 2003 11:29:29 -0800 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 996A64316A; Mon, 24 Mar 2003 20:29:07 +0100 (CET) Received: from presto.it.uc3m.es (presto.it.uc3m.es [163.117.139.134]) by smtp01.uc3m.es (Postfix) with ESMTP id 8B26899E68; Mon, 24 Mar 2003 20:29:06 +0100 (CET) Subject: Re: Architectural approaches to multi6 From: marcelo bagnulo To: RJ Atkinson Cc: Tony Li , multi6@ops.ietf.org In-Reply-To: References: Content-Type: text/plain Organization: uc3m Message-Id: <1048534134.722.44.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 24 Mar 2003 20:28:54 +0100 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-32.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_XIMIAN autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 2003-03-24 at 19:38, RJ Atkinson wrote: > On Monday, Mar 24, 2003, at 12:58 America/Montreal, Tony Li wrote: > > I've seen a number of other proposals, but at the architectural > > level, they seem to all boil down to using tunneling to provide > > virtual topology that would match the addressing. > > > > While this certainly works and I'm a big fan of tunneling for > > some reasons, I'm concerned about an architecture that makes > > multi-homing a second class citizen. It seems to me that > > if we can do it right the first time, we should. > > I also would strongly prefer a solution that makes > multi-homing a native/first-class property of IPv6. > > Does anyone else have any other architectural approaches > (besides the two mentioned so far) that the WG should > consider ?? > managing multiple addresses a-la SCTP perhaps? thanks, marcelo > Existing architectural approaches seem to be: > 1: identity/location separation; with the locator > following the actual network topology & the > identifier being quite independent of topology. > 2: tunneling to create a virtual topology > that matches the addressing > > Thanks, > > Ran -- marcelo bagnulo uc3m From owner-multi6@ops.ietf.org Mon Mar 24 14:29:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29867 for ; Mon, 24 Mar 2003 14:29:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xXf7-000EWB-00 for multi6-data@psg.com; Mon, 24 Mar 2003 11:31:13 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #1) id 18xXe5-000EKS-00 for multi6@ops.ietf.org; Mon, 24 Mar 2003 11:30:09 -0800 Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.6/8.12.6) with ESMTP id h2OJTfkw002455; Mon, 24 Mar 2003 14:29:41 -0500 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.6/8.12.6/Submit) id h2OJTe46002452; Mon, 24 Mar 2003 14:29:40 -0500 Date: Mon, 24 Mar 2003 14:29:40 -0500 From: "J. Noel Chiappa" Message-Id: <200303241929.h2OJTe46002452@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: Start running Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Brian E Carpenter > the 8+8 experience was that you have to go a long way into the > details to find out if a solution is really useable. No. It was instantly clear to people who are used to thinking at an architectural level that the 8+8 approach (as outlined by Mo) would do what he wanted, but had two areas of concern: - how to protect the binding between location and address - for "full-on" 8+8 (as originally posited by Mo), where/how the RG was added/modified Solutions to the first problem were instantly obvious (either don't allow a change in the binding for the duration of a connection, or crptographically secure it). I will concede that solutions to the second problem weren't as obvious, and I'm not sure this was ever looked at thoroughly. Later discussion served to illuminate these points a bit (although not in the case of the famed analysis I-D, which was severely flawed), but not in any significant way. There were also other areas of what I will call "interest", which are to say areas where 8+8 offered the *potential* of improved functionality (over the baseline IPv4/v6 architecture), provided appropriate mechanisms could be developed. An example would be using 8+8 as part of a mobility solution - you still have to deal with all the tricky bits like "what happens if you want to contact a mobile host and the current identity/location binding you have for it is not current". It's only when you look at the mechanisms needed to handle that case (mechanisms which will depend on how you handle other things) that you can decide whether that that case is not worth solving - i.e. that the mechanism is too complex/expensive compared to the cost of just ignoring that case. It should be self-obvious that only when you have detailed mechanisms in hand can you evaluate whether the mechanisms used to handle particular cases are cost-effective. Perhaps this is more what you were thinking of in your comments above? Noel From owner-multi6@ops.ietf.org Mon Mar 24 14:37:49 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00219 for ; Mon, 24 Mar 2003 14:37:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xXmv-000FLA-00 for multi6-data@psg.com; Mon, 24 Mar 2003 11:39:17 -0800 Received: from ginger.lcs.mit.edu ([18.26.0.82]) by psg.com with esmtp (Exim 3.36 #1) id 18xXmP-000FI5-00 for multi6@ops.ietf.org; Mon, 24 Mar 2003 11:38:46 -0800 Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.6/8.12.6) with ESMTP id h2OJcMkw002517; Mon, 24 Mar 2003 14:38:22 -0500 Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.6/8.12.6/Submit) id h2OJcLue002514; Mon, 24 Mar 2003 14:38:21 -0500 Date: Mon, 24 Mar 2003 14:38:21 -0500 From: "J. Noel Chiappa" Message-Id: <200303241938.h2OJcLue002514@ginger.lcs.mit.edu> To: multi6@ops.ietf.org Subject: Re: Architectural approaches to multi6 Cc: jnc@ginger.lcs.mit.edu X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: RJ Atkinson > The only architectural approach that I've seen on this list in recent > months is the notion of deprecating the concept of an "address", in > favour of using "locator" and "identifier" for the separate purposes of > routing and identity. Maybe I've overlooked something ? Ahem. Separating "location" and "identification" is an architectural approach to dealing with the fact that the address of the entity at the other end may change 'frequently'. It's *not* an architectural approach to handling multi-homing in a scalable way. The only architectural approach to scalable multi-homing that seems to have much interest is using multiple addresses (i.e. overlapping topology naming abstractions), and switching among them as needed. I have in the past mentioned a number of other approaches, e.g.: - DDC's "route stubs" - the equivalent in MD-systems (let's call them "map stubs") - highly dynamic abstraction boundaries with a deep hierarchy but they all involve i) big changes to the routing architecture, and ii) for the third, at least, frequent changes in address (in other words, you need the I/L split there too). Overlapping naming abstractions - which we can do with the existing routing architecture - seems to be the only choice anyone has expressed interest in. Noel From owner-multi6@ops.ietf.org Mon Mar 24 15:27:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02697 for ; Mon, 24 Mar 2003 15:27:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xYWl-000KyL-00 for multi6-data@psg.com; Mon, 24 Mar 2003 12:26:39 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18xYWF-000Kri-00 for multi6@ops.ietf.org; Mon, 24 Mar 2003 12:26:08 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2OKOhJ04477; Mon, 24 Mar 2003 21:24:44 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Mon, 24 Mar 2003 21:24:43 +0100 (CET) From: Iljitsch van Beijnum To: RJ Atkinson cc: Subject: Re: Architectural approaches to multi6 In-Reply-To: Message-ID: <20030324211354.Q95912-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-9.8 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 24 Mar 2003, RJ Atkinson wrote: > I also would strongly prefer a solution that makes > multi-homing a native/first-class property of IPv6. Agree. But I doubt that's going to happen without some serious changes to different parts of the protocol stack. Is that something we're comfortable with? > Does anyone else have any other architectural approaches > (besides the two mentioned so far) that the WG should > consider ?? > Existing architectural approaches seem to be: > 1: identity/location separation; with the locator > following the actual network topology & the > identifier being quite independent of topology. > 2: tunneling to create a virtual topology > that matches the addressing 3: remove addresses from all places in the protocol stack above the IP layer. If higher layers are unaware of addresses and the addresses follow the topology, IP can route around failures by changing addresses. Iljitsch From owner-multi6@ops.ietf.org Mon Mar 24 16:05:13 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03649 for ; Mon, 24 Mar 2003 16:05:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xZ8w-000OYz-00 for multi6-data@psg.com; Mon, 24 Mar 2003 13:06:06 -0800 Received: from dhcp1.se.kurtis.pp.se ([195.43.225.70] helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18xZ8P-000OX3-00 for multi6@ops.ietf.org; Mon, 24 Mar 2003 13:05:33 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2OL6XKW010907; Mon, 24 Mar 2003 22:06:34 +0100 (CET) Date: Mon, 24 Mar 2003 22:06:32 +0100 Subject: Re: A Way Forward Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Sean Doran , multi6@ops.ietf.org To: RJ Atkinson From: Kurt Erik Lindqvist In-Reply-To: <80AD53D1-5DFD-11D7-98ED-00039357A82A@extremenetworks.com> Message-Id: <7D9BAF4C-5E3C-11D7-B5E2-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-9.2 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>> I have to say that at least three stark contrasts -- that advanced by >>> tli/rja suggesting a new process, that advanced by Christian Huitema >>> (and apparently attractive to you) suggesting a parallelization of >>> labour, >>> and that advanced by Ohta-san, suggesting all-out warfare, each >>> have their alluring qualities (and some drawbacks), as well as >>> considerable >>> history within other parts of the IETF. >> >> I agree on this observation, but note that I would like to combine >> the proposals of tli/rja and Christian. > > Kurt, > > Well that would not be the same as what tli/rja have proposed. > Earlier today you claimed to agree with the process approach > proposed by tli/rja. Now you say you want something different, > though it is unclear (to me at least) what you want to do differently. > > I'm fairly confused by your various notes of the past few days. > > Maybe you could start over again and outline what process approach > that you are proposing that the WG follow ? (First of all I am trying to get a discussion going so I have been a bit vague to get people to come forward...) So, I agree with Tli/Rja that we do not want a race with multiple full-blown solutions. I do agree with Christian that we need to evaluate the solution spaces somehow. Now, what I think we need to do is to find the middle way by a) defining the solution space, which I think is more or less done b) Define the depth of the descriptions of each solution we need. Brian Carpenter have a point in that we want to have make sure they at least have enough content to prevent a long fight over that later on. This depth would be defined by a number of milestones per architectural approach. Does this make sense? > > The last bullet ("we tried and failed") is too pessimistic for my > own view right now, hence the desire to try a top-down cooperative > approach (starting with finding an agreeable architectural approach). See above. That is where I want us to move right now. > I'd also like to see some requirements document get sorted out and > published, so that we understand what issues we are trying to address. After discussing with Joe Abley in SF, he will resubmit the document with changed normative references and title, and let's see if we then can get consensus for that. > One possible way to sort it out would be for the document editor to > hold > an organised on-list document review section by section, with several > days > to discuss the current contents of each section. Other approaches > might also work to sort through such a document. Joe? - kurtis - From owner-multi6@ops.ietf.org Mon Mar 24 16:07:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03738 for ; Mon, 24 Mar 2003 16:07:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xZBe-000OiB-00 for multi6-data@psg.com; Mon, 24 Mar 2003 13:08:54 -0800 Received: from dhcp1.se.kurtis.pp.se ([195.43.225.70] helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18xZB8-000OeA-00 for multi6@ops.ietf.org; Mon, 24 Mar 2003 13:08:23 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2OL9SKW010910; Mon, 24 Mar 2003 22:09:28 +0100 (CET) Date: Mon, 24 Mar 2003 22:09:27 +0100 Subject: Re: Architectural approaches to multi6 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: multi6@ops.ietf.org To: RJ Atkinson From: Kurt Erik Lindqvist In-Reply-To: <873629A0-5DFC-11D7-98ED-00039357A82A@extremenetworks.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-8.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> However, I also think that there currently are to many views on what >> the architecture should be based on. > > The only architectural approach that I've seen on this list in recent > months is the notion of deprecating the concept of an "address", > in favour of using "locator" and "identifier" for the separate purposes > of routing and identity. Maybe I've overlooked something ? Well, there is also Christians multiple address solution and on other lists there have been suggestions on using mobility based solutions. > If there is another architectural approach in the wings, maybe someone > would be kind enough to summarise that alternate approach to the list ? > Well, I want to give people a few days to present their solutions (there are also a few personal drafts submitted to the IETF) or 'ask' to have them reviewed. Then we need to start to move on. But in principal the division of solution space could be - multiaddress - Mobility based - Location/Identifier separation - Based on today (basically improved routing, but I haven't seen any real proposals on this). - kurtis - From owner-multi6@ops.ietf.org Mon Mar 24 16:09:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03801 for ; Mon, 24 Mar 2003 16:08:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xZCr-000Onv-00 for multi6-data@psg.com; Mon, 24 Mar 2003 13:10:09 -0800 Received: from dhcp1.se.kurtis.pp.se ([195.43.225.70] helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18xZCK-000OjK-00 for multi6@ops.ietf.org; Mon, 24 Mar 2003 13:09:36 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2OLAhKW010913; Mon, 24 Mar 2003 22:10:44 +0100 (CET) Date: Mon, 24 Mar 2003 22:10:42 +0100 Subject: Re: Longer prefixes Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: "Robert J. Rockell" From: Kurt Erik Lindqvist In-Reply-To: Message-Id: <1281F3B6-5E3D-11D7-B5E2-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-8.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Is this a broken filter, or needed de-aggregation? I would expect the > former. Has there been any official move away from 2772 for > production > space? > No, but I expect that people are starting to make up the lack of official support for multihoming. Just as with RIR allocation boundary filtering in IPv4. But that is just me guessing. - kurtis - From owner-multi6@ops.ietf.org Mon Mar 24 16:09:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03838 for ; Mon, 24 Mar 2003 16:09:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xZDe-000OuG-00 for multi6-data@psg.com; Mon, 24 Mar 2003 13:10:58 -0800 Received: from dhcp1.se.kurtis.pp.se ([195.43.225.70] helo=laptop2.kurtis.autonomica.se) by psg.com with esmtp (Exim 3.36 #1) id 18xZD8-000OmA-00 for multi6@ops.ietf.org; Mon, 24 Mar 2003 13:10:26 -0800 Received: from kurtis.pp.se (localhost [127.0.0.1]) by laptop2.kurtis.autonomica.se (8.12.7/8.10.2) with ESMTP id h2OLBHKW010916; Mon, 24 Mar 2003 22:11:17 +0100 (CET) Date: Mon, 24 Mar 2003 22:11:16 +0100 Subject: Re: Again no multi6 at IETF#56 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Tony Li" , "Michael H. Lambert" , To: "Bound, Jim" From: Kurt Erik Lindqvist In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCDE7@tayexc13.americas.cpqcorp.net> Message-Id: <26B82B6E-5E3D-11D7-B5E2-000393AB1404@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-8.6 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> I have for a quite long time been saying that IPv6 currently does not >> give any advantage to IPv4 except longer addresses. Now, there is >> enough room for discussion for it's own mailing list so I >> guess that is >> somewhat off-topic. > > May I suggest we not go here? Not relative to our mission. > I fully agree!!! :-) - kurtis - From owner-multi6@ops.ietf.org Mon Mar 24 16:20:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04053 for ; Mon, 24 Mar 2003 16:20:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xZNZ-000Pfw-00 for multi6-data@psg.com; Mon, 24 Mar 2003 13:21:13 -0800 Received: from gnat.inet.org ([63.108.254.91]) by psg.com with esmtp (Exim 3.36 #1) id 18xZMf-000PZc-00 for multi6@ops.ietf.org; Mon, 24 Mar 2003 13:20:17 -0800 Received: from extremenetworks.com (unknown [10.0.8.135]) by gnat.inet.org (Postfix) with ESMTP id 8A33467108; Mon, 24 Mar 2003 16:38:18 -0500 (EST) Date: Mon, 24 Mar 2003 16:19:50 -0500 Subject: Re: Architectural approaches to multi6 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: multi6@ops.ietf.org To: Kurt Erik Lindqvist From: RJ Atkinson In-Reply-To: Message-Id: <58FEE084-5E3E-11D7-983D-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-21.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Monday, Mar 24, 2003, at 16:09 America/Montreal, Kurt Erik Lindqvist wrote: > But in principal the division of solution space could be > > - multiaddress > - Mobility based Does "Mobility-based" mean MIPv6 or something very similar ? I would say that MIPv6 is an instance of Locator/Identifier separation. I'd guess there are lots of potential instances of any given approach. I was trying to take a much higher altitude perspective on the potential approaches that are fundamentally different from each other, then work top down. > - Location/Identifier separation > - Based on today (basically improved routing, but I haven't seen any > real proposals on this). I'm not sure what "based on today" means. So if someone does have a proposal for this, a high-level outline would be pleasant. Ran From owner-multi6@ops.ietf.org Mon Mar 24 16:38:20 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04551 for ; Mon, 24 Mar 2003 16:38:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xZdZ-0000ur-00 for multi6-data@psg.com; Mon, 24 Mar 2003 13:37:45 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 18xZd0-0000ov-00 for multi6@ops.ietf.org; Mon, 24 Mar 2003 13:37:10 -0800 From: Masataka Ohta Message-Id: <200303242129.GAA17321@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id GAA17321; Tue, 25 Mar 2003 06:29:43 +0900 Subject: Re: Start running In-Reply-To: from Kurt Erik Lindqvist at "Mar 24, 2003 10:13:10 am" To: Kurt Erik Lindqvist Date: Tue, 25 Mar 2003 06:29:41 +0859 () CC: Tony Li , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-6.8 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1 autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Kurt, Tony, Ran; > > | Although I generally tend to agree with your view, I do > > | think that we > > | need let everyone present their opinions and evaluate > > | them. > > > > > > I fully endorse this. But the implication of drafting full blown > > proposals for each alternative is not one where you, as a manager, > > set yourself up for success. You instantly make it competitive and > > not collaborative. > > Ok, I think I have misunderstood you, or the other way around. I am not > suggesting that we draft full blown solutions for each alternative. Can you say "running code"? Masataka Ohta From owner-multi6@ops.ietf.org Mon Mar 24 16:40:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04814 for ; Mon, 24 Mar 2003 16:40:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xZhq-0001IP-00 for multi6-data@psg.com; Mon, 24 Mar 2003 13:42:10 -0800 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by psg.com with esmtp (Exim 3.36 #1) id 18xZhK-0001Fk-00 for multi6@ops.ietf.org; Mon, 24 Mar 2003 13:41:38 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id B66326EC; Mon, 24 Mar 2003 16:41:15 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 24 Mar 2003 16:41:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Again no multi6 at IETF#56 Date: Mon, 24 Mar 2003 16:41:15 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCDF4@tayexc13.americas.cpqcorp.net> Thread-Topic: Again no multi6 at IETF#56 Thread-Index: AcLyOhEnVaSFxP9yTsG9wDC8fli3swAE78aA From: "Bound, Jim" To: "Sean Doran" , X-OriginalArrivalTime: 24 Mar 2003 21:41:15.0635 (UTC) FILETIME=[18BF3430:01C2F24E] X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA04814 Sean, Agree with all except question. >Whether this happens by engineering IPv6 in directions different from -- but >informed by -- IPv4, or by non-deployment, possibly will be influenced somewhat >by cooperation here and between multi6 and the Internet Area. The Internet Area does not influence deployment either? The IETF does not influence deployment was my statement. Regards, /jim From owner-multi6@ops.ietf.org Mon Mar 24 16:55:33 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05233 for ; Mon, 24 Mar 2003 16:55:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xZvx-0002TZ-00 for multi6-data@psg.com; Mon, 24 Mar 2003 13:56:45 -0800 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by psg.com with esmtp (Exim 3.36 #1) id 18xZvI-0002RH-00 for multi6@ops.ietf.org; Mon, 24 Mar 2003 13:56:04 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 2EDB2210E; Mon, 24 Mar 2003 16:55:41 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 24 Mar 2003 16:55:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Architectural approaches to multi6 Date: Mon, 24 Mar 2003 16:55:31 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCDF9@tayexc13.americas.cpqcorp.net> Thread-Topic: Architectural approaches to multi6 Thread-Index: AcLyRd+cS7urOc2YR52xqPzosh4vDwACe+9A From: "Bound, Jim" To: "Iljitsch van Beijnum" , "RJ Atkinson" Cc: X-OriginalArrivalTime: 24 Mar 2003 21:55:31.0630 (UTC) FILETIME=[16F5ACE0:01C2F250] X-Spam-Status: No, hits=-3.2 required=5.0 tests=QUOTED_EMAIL_TEXT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA05233 > 3: remove addresses from all places in the protocol stack above the IP > layer. If higher layers are unaware of addresses and the addresses > follow the topology, IP can route around failures by changing > addresses. Wearing my IP stack product developer hat. Errrrr maybe in the year 2050 if we start now. The entire stack on end systems and routing code on embedded systems I have worked with have addresses not only embedded but permeated through all layers. I see the vision but don't have to be real here? /jim From owner-multi6@ops.ietf.org Mon Mar 24 17:50:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06829 for ; Mon, 24 Mar 2003 17:50:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xamS-0006hd-00 for multi6-data@psg.com; Mon, 24 Mar 2003 14:51:00 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18xakl-0006Wj-00 for multi6@ops.ietf.org; Mon, 24 Mar 2003 14:49:15 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2OMlk404733; Mon, 24 Mar 2003 23:47:46 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Mon, 24 Mar 2003 23:47:46 +0100 (CET) From: Iljitsch van Beijnum To: "Bound, Jim" cc: RJ Atkinson , Subject: RE: Architectural approaches to multi6 In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCDF9@tayexc13.americas.cpqcorp.net> Message-ID: <20030324232618.N95912-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-20.1 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 24 Mar 2003, Bound, Jim wrote: > > 3: remove addresses from all places in the protocol stack above the IP > > layer. If higher layers are unaware of addresses and the addresses > > follow the topology, IP can route around failures by changing > > addresses. > Wearing my IP stack product developer hat. Errrrr maybe in the year > 2050 if we start now. The entire stack on end systems and routing code > on embedded systems I have worked with have addresses not only embedded > but permeated through all layers. I see the vision but don't have to be > real here? Yes, we have to be real at some point but not just yet. First we have to determine if 3. has merit. And I have reason to believe transition won't be as hard as it may seem at first glance. From owner-multi6@ops.ietf.org Mon Mar 24 17:56:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07157 for ; Mon, 24 Mar 2003 17:56:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xatG-0007Kx-00 for multi6-data@psg.com; Mon, 24 Mar 2003 14:58:02 -0800 Received: from mailout.zma.compaq.com ([161.114.64.105] helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18xasi-0007G9-00 for multi6@ops.ietf.org; Mon, 24 Mar 2003 14:57:28 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 9DA937F1A; Mon, 24 Mar 2003 17:57:05 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 24 Mar 2003 17:57:05 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Architectural approaches to multi6 Date: Mon, 24 Mar 2003 17:57:05 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCE04@tayexc13.americas.cpqcorp.net> Thread-Topic: Architectural approaches to multi6 Thread-Index: AcLyV113wgbztDaGQ9Cc+phUY4jmsAAAUv9w From: "Bound, Jim" To: "Iljitsch van Beijnum" Cc: "RJ Atkinson" , X-OriginalArrivalTime: 24 Mar 2003 22:57:05.0542 (UTC) FILETIME=[B0B3EA60:01C2F258] X-Spam-Status: No, hits=-3.2 required=5.0 tests=QUOTED_EMAIL_TEXT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA07157 OK that is fair. /jim > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: Monday, March 24, 2003 5:48 PM > To: Bound, Jim > Cc: RJ Atkinson; multi6@ops.ietf.org > Subject: RE: Architectural approaches to multi6 > > > On Mon, 24 Mar 2003, Bound, Jim wrote: > > > > 3: remove addresses from all places in the protocol stack > above the IP > > > layer. If higher layers are unaware of addresses and > the addresses > > > follow the topology, IP can route around failures by changing > > > addresses. > > > Wearing my IP stack product developer hat. Errrrr maybe in > the year > > 2050 if we start now. The entire stack on end systems and routing > > code on embedded systems I have worked with have addresses not only > > embedded but permeated through all layers. I see the > vision but don't > > have to be real here? > > Yes, we have to be real at some point but not just yet. First > we have to determine if 3. has merit. > > And I have reason to believe transition won't be as hard as > it may seem at first glance. > > > From owner-multi6@ops.ietf.org Mon Mar 24 18:58:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10203 for ; Mon, 24 Mar 2003 18:58:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xbq3-000CVR-00 for multi6-data@psg.com; Mon, 24 Mar 2003 15:58:47 -0800 Received: from dmz1.procket.com ([65.174.124.36]) by psg.com with esmtp (Exim 3.36 #1) id 18xbpP-000CQB-00 for multi6@ops.ietf.org; Mon, 24 Mar 2003 15:58:07 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id C050023C49; Mon, 24 Mar 2003 15:47:48 -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 h2ONviYB014064; Mon, 24 Mar 2003 15:57: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="us-ascii" Subject: RE: Architectural approaches to multi6 Date: Mon, 24 Mar 2003 15:57:44 -0800 Message-ID: Thread-Topic: Architectural approaches to multi6 Thread-Index: AcLyV113wgbztDaGQ9Cc+phUY4jmsAAAUv9wAAIbQ4A= From: "Tony Li" To: "Bound, Jim" , "Iljitsch van Beijnum" Cc: "RJ Atkinson" , X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA10203 Indeed. If, in fact, we can convert upper layers to deal with just the identifiers, we would be very close to done. ;-) Tony | -----Original Message----- | From: Bound, Jim [mailto:Jim.Bound@hp.com] | Sent: Monday, March 24, 2003 2:57 PM | To: Iljitsch van Beijnum | Cc: RJ Atkinson; multi6@ops.ietf.org | Subject: RE: Architectural approaches to multi6 | | | OK that is fair. | /jim | | | | | > -----Original Message----- | > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] | > Sent: Monday, March 24, 2003 5:48 PM | > To: Bound, Jim | > Cc: RJ Atkinson; multi6@ops.ietf.org | > Subject: RE: Architectural approaches to multi6 | > | > | > On Mon, 24 Mar 2003, Bound, Jim wrote: | > | > > > 3: remove addresses from all places in the protocol stack | > above the IP | > > > layer. If higher layers are unaware of addresses and | > the addresses | > > > follow the topology, IP can route around failures | by changing | > > > addresses. | > | > > Wearing my IP stack product developer hat. Errrrr maybe in | > the year | > > 2050 if we start now. The entire stack on end systems | and routing | > > code on embedded systems I have worked with have | addresses not only | > > embedded but permeated through all layers. I see the | > vision but don't | > > have to be real here? | > | > Yes, we have to be real at some point but not just yet. First | > we have to determine if 3. has merit. | > | > And I have reason to believe transition won't be as hard as | > it may seem at first glance. | > | > | > | | From owner-multi6@ops.ietf.org Mon Mar 24 19:32:27 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11151 for ; Mon, 24 Mar 2003 19:32:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xcMz-000FRW-00 for multi6-data@psg.com; Mon, 24 Mar 2003 16:32:49 -0800 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by psg.com with esmtp (Exim 3.36 #1) id 18xcMS-000FKo-00 for multi6@ops.ietf.org; Mon, 24 Mar 2003 16:32:16 -0800 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id AAA00345 for ; Tue, 25 Mar 2003 00:31:48 GMT Received: from login.ecs.soton.ac.uk (login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id AAA00370 for ; Tue, 25 Mar 2003 00:31:47 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h2P0VlW02056 for multi6@ops.ietf.org; Tue, 25 Mar 2003 00:31:47 GMT Date: Tue, 25 Mar 2003 00:31:47 +0000 From: Tim Chown To: multi6@ops.ietf.org Subject: Re: Longer prefixes Message-ID: <20030325003145.GH1763@login.ecs.soton.ac.uk> Mail-Followup-To: multi6@ops.ietf.org References: <7t5vfy9wrvk.fsf@mrwint.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7t5vfy9wrvk.fsf@mrwint.cisco.com> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-32.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk So do you filter the /35's and above? On Mon, Mar 24, 2003 at 12:05:51AM +0000, Ole Troan wrote: > > As there was some discussions in Atlanta on wether longer prefixes is > > actually in use today. This is just the first page of sh ipv6 route on > > one of my home routers : > > ipv6-lab-gw>show ipv6 route summary > IPv6 Routing Table Summary - 730 entries > 167 local, 84 connected, 38 static, 6 RIP, 435 BGP 0 IS-IS, 0 OSPF > Number of prefixes: > /8: 1, /10: 1, /16: 1, /24: 47, /28: 49, /32: 207, /33: 2, /34: 2 > /35: 54, /36: 2, /40: 6, /42: 1, /44: 4, /48: 94, /64: 85, /96: 1 > /112: 1, /125: 1, /126: 4, /127: 1, /128: 166 > > /ot From owner-multi6@ops.ietf.org Tue Mar 25 04:40:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04796 for ; Tue, 25 Mar 2003 04:40:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xkst-0001cc-00 for multi6-data@psg.com; Tue, 25 Mar 2003 01:38:19 -0800 Received: from smtp03.uc3m.es ([163.117.136.123] helo=smtp.uc3m.es) by psg.com with esmtp (Exim 3.36 #1) id 18xksN-0001WO-00 for multi6@ops.ietf.org; Tue, 25 Mar 2003 01:37:47 -0800 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id CA759431B1; Tue, 25 Mar 2003 10:37:26 +0100 (CET) Received: from presto.it.uc3m.es (presto.it.uc3m.es [163.117.139.134]) by smtp03.uc3m.es (Postfix) with ESMTP id AF81E99EA5; Tue, 25 Mar 2003 10:37:23 +0100 (CET) Subject: Re: Architectural approaches to multi6 From: marcelo bagnulo To: RJ Atkinson Cc: Kurt Erik Lindqvist , multi6@ops.ietf.org In-Reply-To: <58FEE084-5E3E-11D7-983D-00039357A82A@extremenetworks.com> References: <58FEE084-5E3E-11D7-983D-00039357A82A@extremenetworks.com> Content-Type: text/plain Organization: uc3m Message-Id: <1048585029.733.6.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 25 Mar 2003 10:37:09 +0100 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-32.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_XIMIAN autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Ran, On Mon, 2003-03-24 at 22:19, RJ Atkinson wrote: > On Monday, Mar 24, 2003, at 16:09 America/Montreal, Kurt Erik Lindqvist > wrote: > > But in principal the division of solution space could be > > > > - multiaddress > > - Mobility based > > Does "Mobility-based" mean MIPv6 or something very similar ? > > I would say that MIPv6 is an instance of Locator/Identifier > separation. I am not so sure about that. I would say that in MIP identifier and locators are not separated. I mean, a given address can work both as a locator and as an identifier, depending on the situation. Perhaps, I would say that the identifier role and the locator role are separated. Please, note that this is not related to the fact that locator space and address space are the same (IP addresses) but that sometimes a given address is used as a locator and other times as an identifier. This is true also when considering transport layer solution such as the modifications to TCP to support multiple addresses per connection. This is different from the LIN6 case, where there is a specific type of addresses reserved to serve as identifiers, in which case identifiers and locators are clearly separated. Thanks, marcelo > I'd guess there are lots of potential instances > of any given approach. I was trying to take a much higher > altitude perspective on the potential approaches that are > fundamentally different from each other, then work top down. > > > - Location/Identifier separation > > - Based on today (basically improved routing, but I haven't seen any > > real proposals on this). > > I'm not sure what "based on today" means. So if someone > does have a proposal for this, a high-level outline would > be pleasant. > > Ran -- marcelo bagnulo uc3m From owner-multi6@ops.ietf.org Tue Mar 25 08:16:59 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09082 for ; Tue, 25 Mar 2003 08:16:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xoHX-00082Z-00 for multi6-data@psg.com; Tue, 25 Mar 2003 05:15:59 -0800 Received: from gnat.inet.org ([63.108.254.91]) by psg.com with esmtp (Exim 3.36 #1) id 18xoGk-0007zD-00 for multi6@ops.ietf.org; Tue, 25 Mar 2003 05:15:10 -0800 Received: from extremenetworks.com (unknown [10.0.8.137]) by gnat.inet.org (Postfix) with ESMTP id 5112D6712B; Tue, 25 Mar 2003 08:33:15 -0500 (EST) Date: Tue, 25 Mar 2003 08:14:40 -0500 Subject: Re: Architectural approaches to multi6 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: multi6@ops.ietf.org To: marcelo bagnulo From: RJ Atkinson In-Reply-To: <1048585029.733.6.camel@presto.it.uc3m.es> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-21.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tuesday, Mar 25, 2003, at 04:37 America/Montreal, marcelo bagnulo wrote: > I am not so sure about that. I would say that in MIP identifier and > locators are not separated. I mean, a given address can work both as a > locator and as an identifier, depending on the situation. Perhaps, I > would say that the identifier role and the locator role are separated. Marcelo, As the Subject: line of the thread indicates, my comment was from a high-level architectural perspective. Architecturally, MIPv6 separates the locators from the identifiers. Sure the implementation details might vary, but I'm not interested (right now) in any implementation details. I'm only trying to sort out the *architectural* or highest-level differences between different approaches, for now. If/after there is convergence on an architecture, then would be a better time (IMHO), to sort through implementation details. Ran From owner-multi6@ops.ietf.org Tue Mar 25 10:09:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16510 for ; Tue, 25 Mar 2003 10:09:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xq2s-000D5N-00 for multi6-data@psg.com; Tue, 25 Mar 2003 07:08:58 -0800 Received: from smtp03.uc3m.es ([163.117.136.123] helo=smtp.uc3m.es) by psg.com with esmtp (Exim 3.36 #1) id 18xq2L-000D4Z-00 for multi6@ops.ietf.org; Tue, 25 Mar 2003 07:08:25 -0800 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 421F343152; Tue, 25 Mar 2003 16:08:02 +0100 (CET) Received: from presto.it.uc3m.es (presto.it.uc3m.es [163.117.139.134]) by smtp03.uc3m.es (Postfix) with ESMTP id AFB5299EAC; Tue, 25 Mar 2003 16:08:01 +0100 (CET) Subject: Re: Architectural approaches to multi6 From: marcelo bagnulo To: RJ Atkinson Cc: multi6@ops.ietf.org In-Reply-To: References: Content-Type: text/plain Organization: uc3m Message-Id: <1048604871.734.35.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 25 Mar 2003 16:07:52 +0100 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-32.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_XIMIAN autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Ran, I am wondering if these two approaches are the same or not: - The first case is where there is clear separation between locators and identifiers. In this case, a binding between an identifier and one more locators is needed. - The other case is where multiple addresses are used for reaching the other end. I am not sure that you need an identifier, all you need to know is that there is a set of possible locators for reaching the other end of this communication. (Perhaps the identifier is the set of locators?) Do you think that there is a difference between this two approaches? Thanks, marcelo On Tue, 2003-03-25 at 14:14, RJ Atkinson wrote: > On Tuesday, Mar 25, 2003, at 04:37 America/Montreal, marcelo bagnulo > wrote: > > I am not so sure about that. I would say that in MIP identifier and > > locators are not separated. I mean, a given address can work both as a > > locator and as an identifier, depending on the situation. Perhaps, I > > would say that the identifier role and the locator role are separated. > > Marcelo, > > As the Subject: line of the thread indicates, my comment > was from a high-level architectural perspective. Architecturally, > MIPv6 separates the locators from the identifiers. > > Sure the implementation details might vary, but I'm > not interested (right now) in any implementation details. > I'm only trying to sort out the *architectural* or > highest-level differences between different approaches, > for now. > > If/after there is convergence on an architecture, then > would be a better time (IMHO), to sort through implementation > details. > > Ran -- marcelo bagnulo uc3m From owner-multi6@ops.ietf.org Tue Mar 25 10:43:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18831 for ; Tue, 25 Mar 2003 10:43:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xqbV-000EZ8-00 for multi6-data@psg.com; Tue, 25 Mar 2003 07:44:45 -0800 Received: from d12lmsgate-3.de.ibm.com ([194.196.100.236]) by psg.com with esmtp (Exim 3.36 #1) id 18xqap-000EWe-00 for multi6@ops.ietf.org; Tue, 25 Mar 2003 07:44:04 -0800 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.8/8.12.8) with ESMTP id h2PFhNEO092990; Tue, 25 Mar 2003 16:43:25 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h2PFhNWX209572; Tue, 25 Mar 2003 16:43:23 +0100 Received: from [9.91.16.250] by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA35730 from ; Tue, 25 Mar 2003 16:43:20 +0100 Message-Id: <3E8078D7.5771556D@hursley.ibm.com> Date: Tue, 25 Mar 2003 16:42:15 +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: "J. Noel Chiappa" Cc: multi6@ops.ietf.org Subject: Re: Start running References: <200303241929.h2OJTe46002452@ginger.lcs.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-22.8 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Noel, I agree with what you say about the facts, but I think it did amount to a technical "deep dive". Unfortunately, we never resurfaced. Brian "J. Noel Chiappa" wrote: > > > From: Brian E Carpenter > > > the 8+8 experience was that you have to go a long way into the > > details to find out if a solution is really useable. > > No. It was instantly clear to people who are used to thinking at an > architectural level that the 8+8 approach (as outlined by Mo) would do what > he wanted, but had two areas of concern: > > - how to protect the binding between location and address > - for "full-on" 8+8 (as originally posited by Mo), where/how the RG was > added/modified > > Solutions to the first problem were instantly obvious (either don't allow a > change in the binding for the duration of a connection, or crptographically > secure it). I will concede that solutions to the second problem weren't as > obvious, and I'm not sure this was ever looked at thoroughly. > > Later discussion served to illuminate these points a bit (although not in > the case of the famed analysis I-D, which was severely flawed), but not in > any significant way. > > There were also other areas of what I will call "interest", which are to > say areas where 8+8 offered the *potential* of improved functionality (over > the baseline IPv4/v6 architecture), provided appropriate mechanisms could > be developed. > > An example would be using 8+8 as part of a mobility solution - you still > have to deal with all the tricky bits like "what happens if you want to > contact a mobile host and the current identity/location binding you have > for it is not current". > > It's only when you look at the mechanisms needed to handle that case > (mechanisms which will depend on how you handle other things) that you can > decide whether that that case is not worth solving - i.e. that the > mechanism is too complex/expensive compared to the cost of just ignoring > that case. > > It should be self-obvious that only when you have detailed mechanisms in > hand can you evaluate whether the mechanisms used to handle particular > cases are cost-effective. > > Perhaps this is more what you were thinking of in your comments above? > > Noel From owner-multi6@ops.ietf.org Tue Mar 25 11:14:10 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19819 for ; Tue, 25 Mar 2003 11:14:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xr4Y-000Fn9-00 for multi6-data@psg.com; Tue, 25 Mar 2003 08:14:46 -0800 Received: from gnat.inet.org ([63.108.254.91]) by psg.com with esmtp (Exim 3.36 #1) id 18xr41-000Fko-00 for multi6@ops.ietf.org; Tue, 25 Mar 2003 08:14:13 -0800 Received: from extremenetworks.com (unknown [10.0.8.153]) by gnat.inet.org (Postfix) with ESMTP id 59D5867130; Tue, 25 Mar 2003 11:32:24 -0500 (EST) Date: Tue, 25 Mar 2003 11:13:48 -0500 Subject: Re: Architectural approaches to multi6 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: multi6@ops.ietf.org To: marcelo bagnulo From: RJ Atkinson In-Reply-To: <1048604871.734.35.camel@presto.it.uc3m.es> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-21.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tuesday, Mar 25, 2003, at 10:07 America/Montreal, marcelo bagnulo wrote: > I am wondering if these two approaches are the same or not: > > - The first case is where there is clear separation between locators > and identifiers. In this case, a binding between an identifier > and one more locators is needed. A binding is *always* needed between any identifier and its set of locators, even when the identifier happens to be the permanent home address (using MIPv6 as an example) and the other addresses are the locators. The *nature* of that binding changes depending on implementation details, but the need for some binding does not change. > - The other case is where multiple addresses are used for reaching the > other end. I am not sure that you need an identifier, all you need to > know is that there is a set of possible locators for reaching the > other end of this communication. (Perhaps the identifier is the > set of locators?) If one considers MIPv6, there is only one IPv6 address that is used for the TCP session state. The address used in that way is functionally an identifier. The other addresses (i.e. those not in the TCP session state) are functionally locators. > Do you think that there is a difference between this two approaches? At a high-level, no. In gory implementation details, of course yes. As noted before, my goal (and I suspect tli's goal) pro tempore is to discuss the high-level aspects only. If/when/after some consensus emerges at that level, it would then make sense to dig one level deeper. IMHO, it would not make sense to dig deeply prematurely -- for fear that we'd be unable to see the forest because of focus on individual trees. Cheers, Ran From owner-multi6@ops.ietf.org Tue Mar 25 11:15:35 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19875 for ; Tue, 25 Mar 2003 11:15:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xr6a-000Fss-00 for multi6-data@psg.com; Tue, 25 Mar 2003 08:16:52 -0800 Received: from d12lmsgate.de.ibm.com ([194.196.100.234]) by psg.com with esmtp (Exim 3.36 #1) id 18xr63-000Fqa-00 for multi6@ops.ietf.org; Tue, 25 Mar 2003 08:16:20 -0800 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (8.12.8/8.12.3) with ESMTP id h2PGFtSo057930 for ; Tue, 25 Mar 2003 17:15:55 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h2PGFtWX234046 for ; Tue, 25 Mar 2003 17:15:55 +0100 Received: from [9.91.16.250] by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA32252 from ; Tue, 25 Mar 2003 17:15:52 +0100 Message-Id: <3E808077.E8332228@hursley.ibm.com> Date: Tue, 25 Mar 2003 17:14:47 +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: multi6@ops.ietf.org Subject: Re: Architectural approaches to multi6 References: <20030324232618.N95912-100000@sequoia.muada.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-23.4 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > > On Mon, 24 Mar 2003, Bound, Jim wrote: > > > > 3: remove addresses from all places in the protocol stack above the IP > > > layer. If higher layers are unaware of addresses and the addresses > > > follow the topology, IP can route around failures by changing > > > addresses. > > > Wearing my IP stack product developer hat. Errrrr maybe in the year > > 2050 if we start now. The entire stack on end systems and routing code > > on embedded systems I have worked with have addresses not only embedded > > but permeated through all layers. I see the vision but don't have to be > > real here? > > Yes, we have to be real at some point but not just yet. First we have to > determine if 3. has merit. We've been preaching against exposing addresses above the transport layer since RFC 1900 (dated 1996) at least. Little has changed in the real world. > > And I have reason to believe transition won't be as hard as it may seem > at first glance. Not sure I understand that statement. Brian From owner-multi6@ops.ietf.org Tue Mar 25 13:27:48 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24229 for ; Tue, 25 Mar 2003 13:27:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xt9G-000LwQ-00 for multi6-data@psg.com; Tue, 25 Mar 2003 10:27:46 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18xt8E-000LsA-00 for multi6@ops.ietf.org; Tue, 25 Mar 2003 10:26:42 -0800 Received: from muada.com (sunflower.muada.com [213.156.3.171]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2PIPHE06848; Tue, 25 Mar 2003 19:25:20 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Tue, 25 Mar 2003 19:25:00 +0100 Subject: Re: Architectural approaches to multi6 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: multi6@ops.ietf.org To: Brian E Carpenter From: Iljitsch van Beijnum In-Reply-To: <3E808077.E8332228@hursley.ibm.com> Message-Id: <171D6146-5EEF-11D7-B701-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-21.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On dinsdag, maa 25, 2003, at 17:14 Europe/Amsterdam, Brian E Carpenter wrote: >>>> 3: remove addresses from all places in the protocol stack above the >>>> IP >>>> layer. If higher layers are unaware of addresses and the >>>> addresses >>>> follow the topology, IP can route around failures by changing >>>> addresses. > We've been preaching against exposing addresses above the transport > layer since RFC 1900 (dated 1996) at least. Little has changed in the > real world. As far as I can tell, most people/applications use names rather than addresses most of the time. The trouble is that protocols such as TCP use the addresses in the IP header in their processing. If we make these protocols look at something else (the FQDN, an address that's not in the IP header, ...) we are free to change addresses at any time without breaking sessions. >> And I have reason to believe transition won't be as hard as it may >> seem >> at first glance. > Not sure I understand that statement. Changing all references to addresses everywhere except in the IP layer is a huge undertaking. However, I think multihoming benefits can be achieved before this process has been completed. From owner-multi6@ops.ietf.org Tue Mar 25 14:25:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26856 for ; Tue, 25 Mar 2003 14:25:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xu3v-000Ooq-00 for multi6-data@psg.com; Tue, 25 Mar 2003 11:26:19 -0800 Received: from teldanex.hiit.fi ([212.68.5.99] helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 3.36 #1) id 18xu3O-000Omg-00 for multi6@ops.ietf.org; Tue, 25 Mar 2003 11:25:46 -0800 Received: from nomadiclab.com (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id E071F1C; Tue, 25 Mar 2003 21:35:24 +0200 (EET) Message-ID: <3E80AD32.8090801@nomadiclab.com> Date: Tue, 25 Mar 2003 21:25:38 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030310 X-Accept-Language: en-us, en MIME-Version: 1.0 To: RJ Atkinson Cc: multi6@ops.ietf.org Subject: Re: Architectural approaches to multi6 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-15.7 required=5.0 tests=IN_REP_TO,REFERENCES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ran, > Does anyone else have any other architectural approaches > (besides the two mentioned so far) that the WG should > consider ?? > > Existing architectural approaches seem to be: > 1: identity/location separation; with the locator > following the actual network topology & the > identifier being quite independent of topology. > 2: tunneling to create a virtual topology > that matches the addressing Well, a number of people have suggested to work on addresses. The various PI schemes may be unworkable given the current hierarchical addressing and routing structure; I don't know. But I think that there might be some benefits to be found if we took a deeper look at the interplay between addressing and routing. I am definitely not an expert in the area, but I have heard people speaking about clustering based addressing etc. instead of hierarchically assigned addresses. Assigning the addresses somewhat dynamically based on the real network topology, perhaps combined with an identity/location separation, may be something worth considering in the long run. But that is probably too far fetched for this WG. --Pekka Nikander From owner-multi6@ops.ietf.org Tue Mar 25 14:32:11 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27329 for ; Tue, 25 Mar 2003 14:32:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xuAH-000P9o-00 for multi6-data@psg.com; Tue, 25 Mar 2003 11:32:53 -0800 Received: from mailout.zma.compaq.com ([161.114.64.103] helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 3.36 #1) id 18xu9j-000P66-00 for multi6@ops.ietf.org; Tue, 25 Mar 2003 11:32:20 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id F2E0E21A8; Tue, 25 Mar 2003 14:31:56 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 25 Mar 2003 14:31:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Architectural approaches to multi6 Date: Tue, 25 Mar 2003 14:31:56 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCE34@tayexc13.americas.cpqcorp.net> Thread-Topic: Architectural approaches to multi6 Thread-Index: AcLy/k6zjMegH83/SYy2JC5mXsMTyQABrEKA From: "Bound, Jim" To: "Iljitsch van Beijnum" , "Brian E Carpenter" Cc: X-OriginalArrivalTime: 25 Mar 2003 19:31:56.0777 (UTC) FILETIME=[32852D90:01C2F305] X-Spam-Status: No, hits=-3.2 required=5.0 tests=QUOTED_EMAIL_TEXT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA27329 No one uses FQDN's above IP till one gets to the Application layer. Why do you say this? Also we need a solution that does not assume this at all. Doing this would at best be nice to have long term. THere is also no way to enforce it. /jim > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: Tuesday, March 25, 2003 1:25 PM > To: Brian E Carpenter > Cc: multi6@ops.ietf.org > Subject: Re: Architectural approaches to multi6 > > > On dinsdag, maa 25, 2003, at 17:14 Europe/Amsterdam, Brian E > Carpenter > wrote: > > >>>> 3: remove addresses from all places in the protocol > stack above the > >>>> IP > >>>> layer. If higher layers are unaware of addresses and the > >>>> addresses > >>>> follow the topology, IP can route around failures by changing > >>>> addresses. > > > We've been preaching against exposing addresses above the transport > > layer since RFC 1900 (dated 1996) at least. Little has > changed in the > > real world. > > As far as I can tell, most people/applications use names rather than > addresses most of the time. The trouble is that protocols such as TCP > use the addresses in the IP header in their processing. If we make > these protocols look at something else (the FQDN, an address > that's not > in the IP header, ...) we are free to change addresses at any time > without breaking sessions. > > >> And I have reason to believe transition won't be as hard as it may > >> seem > >> at first glance. > > > Not sure I understand that statement. > > Changing all references to addresses everywhere except in the > IP layer > is a huge undertaking. However, I think multihoming benefits can be > achieved before this process has been completed. > > > From owner-multi6@ops.ietf.org Tue Mar 25 15:00:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28720 for ; Tue, 25 Mar 2003 15:00:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xucb-0001F2-00 for multi6-data@psg.com; Tue, 25 Mar 2003 12:02:09 -0800 Received: from mail3.microsoft.com ([131.107.3.123]) by psg.com with esmtp (Exim 3.36 #1) id 18xuc4-0001An-00 for multi6@ops.ietf.org; Tue, 25 Mar 2003 12:01:36 -0800 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Tue, 25 Mar 2003 12:01:11 -0800 Received: from 157.54.5.25 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 25 Mar 2003 12:01:11 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by INET-HUB-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3765.0); Tue, 25 Mar 2003 12:01:08 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 25 Mar 2003 12:01:10 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Tue, 25 Mar 2003 12:01:08 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Architectural approaches to multi6 Date: Tue, 25 Mar 2003 12:01:14 -0800 Message-ID: Thread-Topic: Architectural approaches to multi6 Thread-Index: AcLy/k6zjMegH83/SYy2JC5mXsMTyQABrEKAAADsMsA= From: "Christian Huitema" To: "Bound, Jim" , "Iljitsch van Beijnum" , "Brian E Carpenter" Cc: X-OriginalArrivalTime: 25 Mar 2003 20:01:08.0010 (UTC) FILETIME=[465620A0:01C2F309] X-Spam-Status: No, hits=-3.2 required=5.0 tests=QUOTED_EMAIL_TEXT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA28720 The way I see it, applications are evolving to use IP addresses more, not less. There are many reasons, such as the flakiness of the DNS resolution process, but there are also many applications (or transports) that actually want to reason over IP addresses in an attempt to control or organize network usage. In a multi-homing scenario, applications are likely to treat the address on the GPRS interface different from the Wifi or the Ethernet interface; they also will want to know whether they need to open the firewall to reach a specific address, etc. > -----Original Message----- > From: Bound, Jim [mailto:Jim.Bound@hp.com] > Sent: Tuesday, March 25, 2003 11:32 AM > To: Iljitsch van Beijnum; Brian E Carpenter > Cc: multi6@ops.ietf.org > > No one uses FQDN's above IP till one gets to the Application layer. Why > do you say this? > > Also we need a solution that does not assume this at all. Doing this > would at best be nice to have long term. > > THere is also no way to enforce it. > > /jim > > > > > > -----Original Message----- > > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > > Sent: Tuesday, March 25, 2003 1:25 PM > > To: Brian E Carpenter > > Cc: multi6@ops.ietf.org > > Subject: Re: Architectural approaches to multi6 > > > > > > On dinsdag, maa 25, 2003, at 17:14 Europe/Amsterdam, Brian E > > Carpenter > > wrote: > > > > >>>> 3: remove addresses from all places in the protocol > > stack above the > > >>>> IP > > >>>> layer. If higher layers are unaware of addresses and the > > >>>> addresses > > >>>> follow the topology, IP can route around failures by changing > > >>>> addresses. > > > > > We've been preaching against exposing addresses above the transport > > > layer since RFC 1900 (dated 1996) at least. Little has > > changed in the > > > real world. > > > > As far as I can tell, most people/applications use names rather than > > addresses most of the time. The trouble is that protocols such as TCP > > use the addresses in the IP header in their processing. If we make > > these protocols look at something else (the FQDN, an address > > that's not > > in the IP header, ...) we are free to change addresses at any time > > without breaking sessions. > > > > >> And I have reason to believe transition won't be as hard as it may > > >> seem > > >> at first glance. > > > > > Not sure I understand that statement. > > > > Changing all references to addresses everywhere except in the > > IP layer > > is a huge undertaking. However, I think multihoming benefits can be > > achieved before this process has been completed. > > > > > > > From owner-multi6@ops.ietf.org Tue Mar 25 15:23:37 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01316 for ; Tue, 25 Mar 2003 15:23:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xuyY-0002kG-00 for multi6-data@psg.com; Tue, 25 Mar 2003 12:24:50 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18xuxe-0002do-00 for multi6@ops.ietf.org; Tue, 25 Mar 2003 12:23:55 -0800 Received: from muada.com (sunflower.muada.com [213.156.3.171]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2PKMME07010; Tue, 25 Mar 2003 21:22:22 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Tue, 25 Mar 2003 21:22:05 +0100 Subject: Re: Architectural approaches to multi6 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Brian E Carpenter" , To: "Bound, Jim" From: Iljitsch van Beijnum In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCE34@tayexc13.americas.cpqcorp.net> Message-Id: <722D338E-5EFF-11D7-94AB-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-21.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On dinsdag, maa 25, 2003, at 20:31 Europe/Amsterdam, Bound, Jim wrote: > No one uses FQDN's above IP till one gets to the Application layer. > Why > do you say this? I don't think I was saying that people are doing this today. > Also we need a solution that does not assume this at all. Why not? > Doing this would at best be nice to have long term. THere is also no > way to enforce it. So there we have our long term goal. If we can get there by using 16 byte values that look enough like IPv6 addresses to fool existing implementations for a while but label them "identifier - not to be used in routing" I don't have a problem with that. From owner-multi6@ops.ietf.org Tue Mar 25 15:34:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02056 for ; Tue, 25 Mar 2003 15:34:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xv85-0003L3-00 for multi6-data@psg.com; Tue, 25 Mar 2003 12:34:41 -0800 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by psg.com with esmtp (Exim 3.36 #1) id 18xv7Y-0003HG-00 for multi6@ops.ietf.org; Tue, 25 Mar 2003 12:34:08 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 503036682; Tue, 25 Mar 2003 15:33:45 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 25 Mar 2003 15:33:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Architectural approaches to multi6 Date: Tue, 25 Mar 2003 15:33:40 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03241087@tayexc13.americas.cpqcorp.net> Thread-Topic: Architectural approaches to multi6 Thread-Index: AcLzDI3+xElfSBdVTX2s8g7IxMPTdQAAGW3w From: "Bound, Jim" To: "Iljitsch van Beijnum" Cc: "Brian E Carpenter" , X-OriginalArrivalTime: 25 Mar 2003 20:33:45.0074 (UTC) FILETIME=[D4D66520:01C2F30D] X-Spam-Status: No, hits=-3.8 required=5.0 tests=QUOTED_EMAIL_TEXT,QUOTE_TWICE_1 autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA02056 > > No one uses FQDN's above IP till one gets to the Application layer. > > Why > > do you say this? > > I don't think I was saying that people are doing this today. Hmmm thought you did. I misunderstood then. My apologies then. > > > Also we need a solution that does not assume this at all. > > Why not? WHen I say assume let me clarify. By "assume" I mean, solution we end up with won't work if all *sockaddr_DL references to Network Byte Order addresses MUST become references to *char_foo_identifier strings. I will assume you know the ramfications to the stack above IP "virtual" layer in the IP stack and then to what we often call "user" space where the applications reside. That is a non-starter. > > > Doing this would at best be nice to have long term. THere is also no > > way to enforce it. > > So there we have our long term goal. If we can get there by using 16 > byte values that look enough like IPv6 addresses to fool existing > implementations for a while but label them "identifier - not > to be used > in routing" I don't have a problem with that. Yep that is what I was thinking architecturally. But have not gone down the affect to code yet. That being said I believe Christian's point was quite valid. Regards, /jim > > From owner-multi6@ops.ietf.org Tue Mar 25 19:33:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12871 for ; Tue, 25 Mar 2003 19:33:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18xypL-000Ftd-00 for multi6-data@psg.com; Tue, 25 Mar 2003 16:31:35 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18xypI-000FtM-00 for multi6@ops.ietf.org; Tue, 25 Mar 2003 16:31:32 -0800 Received: from muada.com (sunflower.muada.com [213.156.3.171]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2Q0USE07315; Wed, 26 Mar 2003 01:30:29 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Wed, 26 Mar 2003 01:30:10 +0100 Subject: Re: Architectural approaches to multi6 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: "Bound, Jim" From: Iljitsch van Beijnum In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03241087@tayexc13.americas.cpqcorp.net> Message-Id: <1A923834-5F22-11D7-9C73-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-21.6 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On dinsdag, maa 25, 2003, at 21:33 Europe/Amsterdam, Bound, Jim wrote: >>> Also we need a solution that does not assume this at all. >> Why not? > WHen I say assume let me clarify. By "assume" I mean, solution we end > up with won't work if all *sockaddr_DL references to Network Byte Order > addresses MUST become references to *char_foo_identifier strings. I > will assume you know the ramfications to the stack above IP "virtual" > layer in the IP stack and then to what we often call "user" space where > the applications reside. That is a non-starter. Yes, we need both a very long transition period during which certain parts can handle the new paradigm while others can't and first rate backward compatibility. >>> Doing this would at best be nice to have long term. THere is also no >>> way to enforce it. >> So there we have our long term goal. If we can get there by using 16 >> byte values that look enough like IPv6 addresses to fool existing >> implementations for a while but label them "identifier - not >> to be used in routing" I don't have a problem with that. > Yep that is what I was thinking architecturally. But have not gone > down > the affect to code yet. There are lots of issues to consider before that. > That being said I believe Christian's point was quite valid. I'm not convinced by his example. Yes, applications will want to know something about the connectivity properties in order to adapt their behavior. But I don't see how access to the IP addresses is going to do that. An application can't tell if 3ffe:2500:310:1:203:93ff:fec5:2d28 is an address used on a low-bandwidth, high-delay GPRS link or a high-bandwidth, low-delay fast ethernet link. The application needs to know which interface is going to be used, the address is immaterial. If the IP layer can move a session from one interface to another some additional glue is needed to provide this information on an ongoing basis. However, there is another reason why people work around the DNS that I think may be a bigger problem: while the domain name system isn't open to trivial fakery like some other protocols (SMTP...) its security isn't stellar either. The trouble with hardcoding addresses in configuration files is that invariably the addresses change and invariably it is next to impossible to find all the places they're stored beforehand. What we need here is something that isn't as fixed as a configuration file, but also isn't as ephemeral as information learned from the DNS. From owner-multi6@ops.ietf.org Wed Mar 26 07:39:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23862 for ; Wed, 26 Mar 2003 07:39:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18yABx-000EAy-00 for multi6-data@psg.com; Wed, 26 Mar 2003 04:39:41 -0800 Received: from batch15.uni-muenster.de ([128.176.188.113]) by psg.com with esmtp (Exim 3.36 #1) id 18yABq-000EAh-00 for multi6@ops.ietf.org; Wed, 26 Mar 2003 04:39:35 -0800 Received: from zivlnx01.uni-muenster.de (ZIVLNX01.UNI-MUENSTER.DE [128.176.188.24]) by batch15.uni-muenster.de (Postfix) with ESMTP id 60FF1111B for ; Wed, 26 Mar 2003 13:39:32 +0100 (MEZ) Received: from localhost (localhost.uni-muenster.de [127.0.0.1]) by zivlnx01.uni-muenster.de (Postfix with Virus Detection) with ESMTP id A2536312D7 for ; Wed, 26 Mar 2003 13:39:32 +0100 (CET) Received: from lemy.uni-muenster.de (LEMY.UNI-MUENSTER.DE [128.176.184.238]) by zivlnx01.uni-muenster.de (Postfix with Virus Detection) with ESMTP id 11D2C312CF for ; Wed, 26 Mar 2003 13:39:32 +0100 (CET) Content-Type: text/plain; charset="us-ascii" From: Christian Schild Reply-To: schild@uni-muenster.de Organization: Westfaelische Wilhelms-Universitaet To: Subject: Failover for a multihomed site with unreachable ISP Date: Wed, 26 Mar 2003 13:39:32 +0100 User-Agent: KMail/1.4.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200303261339.32863.ipng@uni-muenster.de> X-Virus-Scanned: by AMaViS 0.3.12pre7 X-Spam-Status: No, hits=-12.2 required=5.0 tests=BAYES_10,USER_AGENT_KMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Hi ho, inspired by the 'dual homing experiment' document of Christian Huitema, we (JOINers) thought about a solution to offer robustness for a site that is multihomed and multiaddressed and that we like to discuss here. Exteral connectivity of such a site is affected by failures of - the sites border router - the sites uplink - the ISPs infrastructure (spec. the router with the link to the customer) - the ISPs global border router - the ISPs global uplink To recover from such a failure in the fist three cases, the site could communicate with the ISP a set of possible prefixes and connectivity could get reestablished via a tunnel technology. We already thought about this, but the solution is quite complex to explain it in short. It is not discussed here. The approach I try to explain here is a solution for the last two cases, where there the ISP is no longer reachable and a tunneled solution is not possible. First, we consider a failure a seldom and abnormal event. Only if a direct connect fails, the network (or the ISP) has to take some failover action. This means that - if you think of the size of the global routing table - in default behaviour the table is small (only /32 prefixes) and only in case of a failure a more specific prefix (/48 or shorter) is neccessary. +----------------------------+ | 'Global Internet'/'DFZ' | +--+-----------------------+-+ | | | | +-----------+--+ +--+-----------+ | ISP A | | ISP B | | Prefix PA/32 | | Prefix PB/32 | +-----------+--+ +--+-----------+ | | | | ++-----------------------++ | Customer C | | Prefix PAC/48 | | Prefix PBC/48 | +-------------------------+ In this scenario customer C gets a /48 from every ISP (PAC/48 from ISP A and PBC/48 from ISP B) and communicates the existance of these prefixes to every provider (as mentioned earlier, how this is done is not explained here). Thus, e.g. ISP A knows that it has a multihomed route to customer C with prefix PBC/48. Usually, all traffic from the outside to PBC/48 will go through ISP B. If ISP B detaches from the DFZ now, ISP A has to announce to the DFZ somehow, that it has a valid route to PBC/48. This can be done in two different ways within (e)BGP: Approach 1: When ISP B detaches, it's BGP announcement of PB/32 will vanish from the global routing table. ISP A's border router could use this as a trigger to announce PBC/48 to the DFZ. It will remove this announcement when PA/32 reappears. The advantage here is that the /48 will only be present in the DFZ, when the usual routes fail. The disadvantages are bad convergence and possible multiple routes. If ISP A and ISP B are very distant, it may take some time until the /48 is known everywhere. If ISP B detaches from the DFZ only for a split second - or even flaps - both prefixes will be visible in the DFZ for some time. Approach 2: The second approach is more severe and requires a change in BGPs default routing behaviour. Usually BGP choses the route for a packet based on the longest prefix match calculation. The suggestion here is, that (e)BGP - despite this rule - chooses the _shortest_ prefix in the DFZ. This behaviour has to be restricted to prefixed between /32 and /48. This restriction is neccessary, because we only want this to happen in the routing area. Within a site, longest prefix match should still be possible. And, shortest match needs to be prevented for prefixes shorter than /32, else anyone could create a _real_ black hole by announcing an /<32 to the DFZ. Assuming this behaviour of (e)BGP, in the above scenario ISP A could simply announce PBC/48 to the DFZ. It will get announced to everyone, but it should not get used in the forwarding table, cause the (now) better prefix PB/32 exists. If now ISP B detaches and the prefix PB/32 is retrieved from the routing table, every node in the DFZ will add the PBC/48 to the forwarding table and the new route to the customer establishes. Advantages here are the faster convergence. A disadvantage is the major change in BGPs behaviour. This 'shortest path' criteria may be critical, because calculation of the best route might get complex and expensive. Also, again the routing table may grow large, but in return the forwarding table will stay small. It is not know what other impact a 'shortest prefix' selection will have. So long, Christian (Schild :-) -- JOIN - IP Version 6 in the WiN Christian Schild A DFN project Westfaelische Wilhelms-Universitaet Muenster http://www.join.uni-muenster.de Zentrum fuer Informationsverarbeitung Team: join@uni-muenster.de Roentgenstrasse 9-13 Priv: schild@uni-muenster.de D-48149 Muenster / Germany GPG-/PGP-Key-ID: 6EBFA081 Fon: +49 251 83 31638, fax: +49 251 83 31653 From owner-multi6@ops.ietf.org Wed Mar 26 10:20:52 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00442 for ; Wed, 26 Mar 2003 10:20:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18yChc-000KpO-00 for multi6-data@psg.com; Wed, 26 Mar 2003 07:20:32 -0800 Received: from smtp01.uc3m.es ([163.117.136.121] helo=smtp.uc3m.es) by psg.com with esmtp (Exim 3.36 #1) id 18yChV-000KoK-00 for multi6@ops.ietf.org; Wed, 26 Mar 2003 07:20:25 -0800 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 8068A4321A; Wed, 26 Mar 2003 16:20:22 +0100 (CET) Received: from presto.it.uc3m.es (presto.it.uc3m.es [163.117.139.134]) by smtp01.uc3m.es (Postfix) with ESMTP id 0C2D299E78; Wed, 26 Mar 2003 16:20:22 +0100 (CET) Subject: Re: Failover for a multihomed site with unreachable ISP From: marcelo bagnulo To: schild@uni-muenster.de Cc: multi6@ops.ietf.org In-Reply-To: <200303261339.32863.ipng@uni-muenster.de> References: <200303261339.32863.ipng@uni-muenster.de> Content-Type: text/plain Organization: uc3m Message-Id: <1048692020.737.34.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 26 Mar 2003 16:20:21 +0100 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_XIMIAN autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Cristian Wouldn't this be somehow similar to RFC 2260? Regards, marcelo On Wed, 2003-03-26 at 13:39, Christian Schild wrote: > Hi ho, > > inspired by the 'dual homing experiment' document of Christian Huitema, > we (JOINers) thought about a solution to offer robustness for a site that > is multihomed and multiaddressed and that we like to discuss here. > Exteral connectivity of such a site is affected by failures of > > - the sites border router > - the sites uplink > - the ISPs infrastructure (spec. the router with the link to the customer) > - the ISPs global border router > - the ISPs global uplink > > To recover from such a failure in the fist three cases, the site could > communicate with the ISP a set of possible prefixes and connectivity could > get reestablished via a tunnel technology. We already thought about this, > but the solution is quite complex to explain it in short. It is not > discussed here. > > The approach I try to explain here is a solution for the last two cases, > where there the ISP is no longer reachable and a tunneled solution is not > possible. > > > First, we consider a failure a seldom and abnormal event. Only if a direct > connect fails, the network (or the ISP) has to take some failover action. > This means that - if you think of the size of the global routing table - > in default behaviour the table is small (only /32 prefixes) and only in > case of a failure a more specific prefix (/48 or shorter) is neccessary. > > +----------------------------+ > | 'Global Internet'/'DFZ' | > +--+-----------------------+-+ > | | > | | > +-----------+--+ +--+-----------+ > | ISP A | | ISP B | > | Prefix PA/32 | | Prefix PB/32 | > +-----------+--+ +--+-----------+ > | | > | | > ++-----------------------++ > | Customer C | > | Prefix PAC/48 | > | Prefix PBC/48 | > +-------------------------+ > > In this scenario customer C gets a /48 from every ISP (PAC/48 from ISP A > and PBC/48 from ISP B) and communicates the existance of these prefixes to > every provider (as mentioned earlier, how this is done is not explained > here). Thus, e.g. ISP A knows that it has a multihomed route to > customer C with prefix PBC/48. > > Usually, all traffic from the outside to PBC/48 will go through ISP B. > If ISP B detaches from the DFZ now, ISP A has to announce to the DFZ > somehow, that it has a valid route to PBC/48. This can be done in two > different ways within (e)BGP: > > > Approach 1: > When ISP B detaches, it's BGP announcement of PB/32 will vanish from the > global routing table. ISP A's border router could use this as a trigger to > announce PBC/48 to the DFZ. It will remove this announcement when PA/32 > reappears. > > The advantage here is that the /48 will only be present in the DFZ, when > the usual routes fail. The disadvantages are bad convergence and possible > multiple routes. If ISP A and ISP B are very distant, it may take some > time until the /48 is known everywhere. If ISP B detaches from the DFZ > only for a split second - or even flaps - both prefixes will be visible > in the DFZ for some time. > > > Approach 2: > The second approach is more severe and requires a change in BGPs default > routing behaviour. > > Usually BGP choses the route for a packet based on the longest prefix > match calculation. The suggestion here is, that (e)BGP - despite this > rule - chooses the _shortest_ prefix in the DFZ. This behaviour has to > be restricted to prefixed between /32 and /48. This restriction is > neccessary, because we only want this to happen in the routing area. > Within a site, longest prefix match should still be possible. And, > shortest match needs to be prevented for prefixes shorter than /32, else > anyone could create a _real_ black hole by announcing an /<32 to the > DFZ. > > Assuming this behaviour of (e)BGP, in the above scenario ISP A could simply > announce PBC/48 to the DFZ. It will get announced to everyone, but it > should not get used in the forwarding table, cause the (now) better prefix > PB/32 exists. If now ISP B detaches and the prefix PB/32 is retrieved from > the routing table, every node in the DFZ will add the PBC/48 to the > forwarding table and the new route to the customer establishes. > > Advantages here are the faster convergence. A disadvantage is the major > change in BGPs behaviour. This 'shortest path' criteria may be critical, > because calculation of the best route might get complex and expensive. > Also, again the routing table may grow large, but in return the > forwarding table will stay small. It is not know what other impact a > 'shortest prefix' selection will have. > > So long, > Christian (Schild :-) -- marcelo bagnulo uc3m From owner-multi6@ops.ietf.org Wed Mar 26 17:11:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17883 for ; Wed, 26 Mar 2003 17:11:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18yJ78-000JuZ-00 for multi6-data@psg.com; Wed, 26 Mar 2003 14:11:18 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18yJ6U-000Jsw-00 for multi6@ops.ietf.org; Wed, 26 Mar 2003 14:10:38 -0800 Received: from muada.com (sunflower.muada.com [213.156.3.171]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2QM9bb09379; Wed, 26 Mar 2003 23:09:37 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Wed, 26 Mar 2003 23:09:20 +0100 Subject: Re: Failover for a multihomed site with unreachable ISP Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: schild@uni-muenster.de From: Iljitsch van Beijnum In-Reply-To: <200303261339.32863.ipng@uni-muenster.de> Message-Id: <98177E00-5FD7-11D7-8027-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Christian, On woensdag, maa 26, 2003, at 13:39 Europe/Amsterdam, Christian Schild wrote: > First, we consider a failure a seldom and abnormal event. Only if a > direct > connect fails, the network (or the ISP) has to take some failover > action. > This means that - if you think of the size of the global routing table > - > in default behaviour the table is small (only /32 prefixes) and only in > case of a failure a more specific prefix (/48 or shorter) is > neccessary. I see two problems with this: 1. An ISP's aggregate route (the /32) disappearing from the global routing table is an extremely rare event. Last mile problems are infinitely more common, and after that there is the class of partial ISP failures (for instance, a single POP is partitioned from the network) where the aggregate remains visible. 2. Conditional announcement makes the global routing system less predictable, which is dangerous. The sudden appearance of thousands of more specific /48s could easily break systems that could just about cope with the regular aggregated situation. From owner-multi6@ops.ietf.org Thu Mar 27 01:57:47 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05890 for ; Thu, 27 Mar 2003 01:57:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18yRKX-000BQA-00 for multi6-data@psg.com; Wed, 26 Mar 2003 22:57:41 -0800 Received: from batch13.uni-muenster.de ([128.176.188.111]) by psg.com with esmtp (Exim 3.36 #1) id 18yRKT-000BPM-00 for multi6@ops.ietf.org; Wed, 26 Mar 2003 22:57:37 -0800 Received: from zivlnx01.uni-muenster.de (ZIVLNX01.UNI-MUENSTER.DE [128.176.188.24]) by batch13.uni-muenster.de (Postfix) with ESMTP id 5A6E312DC; Thu, 27 Mar 2003 07:57:36 +0100 (MEZ) Received: from localhost (localhost.uni-muenster.de [127.0.0.1]) by zivlnx01.uni-muenster.de (Postfix with Virus Detection) with ESMTP id 76233312D7; Thu, 27 Mar 2003 07:57:31 +0100 (CET) Received: from lemy.uni-muenster.de (LEMY.UNI-MUENSTER.DE [128.176.184.238]) by zivlnx01.uni-muenster.de (Postfix with Virus Detection) with ESMTP id D9923312CF; Thu, 27 Mar 2003 07:57:30 +0100 (CET) Content-Type: text/plain; charset="iso-8859-1" From: Christian Schild Reply-To: schild@uni-muenster.de Organization: Westfaelische Wilhelms-Universitaet To: multi6@ops.ietf.org Subject: Re: Failover for a multihomed site with unreachable ISP Date: Thu, 27 Mar 2003 07:57:31 +0100 User-Agent: KMail/1.4.3 References: <200303261339.32863.ipng@uni-muenster.de> <1048692020.737.34.camel@presto.it.uc3m.es> In-Reply-To: <1048692020.737.34.camel@presto.it.uc3m.es> Cc: marcelo bagnulo MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200303270757.31435.ipng@uni-muenster.de> X-Virus-Scanned: by AMaViS 0.3.12pre7 X-Spam-Status: No, hits=-33.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_KMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Hi Marcelo, Am Mittwoch, 26. März 2003 16:20 schrieben Sie: > Hi Cristian > > Wouldn't this be somehow similar to RFC 2260? Hm, I don't think so. RFC 2260 seems to be similar but isn't the same. In fact, it could be used to help in one of the first three cases of failures I talked about. But RFC2260 talks about connecting a site to an ISP (e.g. by extending BGP to the customer). In my mail I talk about how an ISP A could inject a customers prefix (that is part of another ISP B's /32) to the DFZ, without endangering the size of the routing table. This is not solved by RFC2260. Christian > > On Wed, 2003-03-26 at 13:39, Christian Schild wrote: > > Hi ho, > > > > inspired by the 'dual homing experiment' document of Christian Huitema, > > we (JOINers) thought about a solution to offer robustness for a site that > > is multihomed and multiaddressed and that we like to discuss here. > > Exteral connectivity of such a site is affected by failures of > > > > - the sites border router > > - the sites uplink > > - the ISPs infrastructure (spec. the router with the link to the customer) > > - the ISPs global border router > > - the ISPs global uplink > > > > To recover from such a failure in the fist three cases, the site could > > communicate with the ISP a set of possible prefixes and connectivity could > > get reestablished via a tunnel technology. We already thought about this, > > but the solution is quite complex to explain it in short. It is not > > discussed here. > > > > The approach I try to explain here is a solution for the last two cases, > > where there the ISP is no longer reachable and a tunneled solution is not > > possible. > > > > > > First, we consider a failure a seldom and abnormal event. Only if a direct > > connect fails, the network (or the ISP) has to take some failover action. > > This means that - if you think of the size of the global routing table - > > in default behaviour the table is small (only /32 prefixes) and only in > > case of a failure a more specific prefix (/48 or shorter) is neccessary. > > > > +----------------------------+ > > | 'Global Internet'/'DFZ' | > > +--+-----------------------+-+ > > | | > > | | > > +-----------+--+ +--+-----------+ > > | ISP A | | ISP B | > > | Prefix PA/32 | | Prefix PB/32 | > > +-----------+--+ +--+-----------+ > > | | > > | | > > ++-----------------------++ > > | Customer C | > > | Prefix PAC/48 | > > | Prefix PBC/48 | > > +-------------------------+ > > > > In this scenario customer C gets a /48 from every ISP (PAC/48 from ISP A > > and PBC/48 from ISP B) and communicates the existance of these prefixes to > > every provider (as mentioned earlier, how this is done is not explained > > here). Thus, e.g. ISP A knows that it has a multihomed route to > > customer C with prefix PBC/48. > > > > Usually, all traffic from the outside to PBC/48 will go through ISP B. > > If ISP B detaches from the DFZ now, ISP A has to announce to the DFZ > > somehow, that it has a valid route to PBC/48. This can be done in two > > different ways within (e)BGP: > > > > > > Approach 1: > > When ISP B detaches, it's BGP announcement of PB/32 will vanish from the > > global routing table. ISP A's border router could use this as a trigger to > > announce PBC/48 to the DFZ. It will remove this announcement when PA/32 > > reappears. > > > > The advantage here is that the /48 will only be present in the DFZ, when > > the usual routes fail. The disadvantages are bad convergence and possible > > multiple routes. If ISP A and ISP B are very distant, it may take some > > time until the /48 is known everywhere. If ISP B detaches from the DFZ > > only for a split second - or even flaps - both prefixes will be visible > > in the DFZ for some time. > > > > > > Approach 2: > > The second approach is more severe and requires a change in BGPs default > > routing behaviour. > > > > Usually BGP choses the route for a packet based on the longest prefix > > match calculation. The suggestion here is, that (e)BGP - despite this > > rule - chooses the _shortest_ prefix in the DFZ. This behaviour has to > > be restricted to prefixed between /32 and /48. This restriction is > > neccessary, because we only want this to happen in the routing area. > > Within a site, longest prefix match should still be possible. And, > > shortest match needs to be prevented for prefixes shorter than /32, else > > anyone could create a _real_ black hole by announcing an /<32 to the > > DFZ. > > > > Assuming this behaviour of (e)BGP, in the above scenario ISP A could simply > > announce PBC/48 to the DFZ. It will get announced to everyone, but it > > should not get used in the forwarding table, cause the (now) better prefix > > PB/32 exists. If now ISP B detaches and the prefix PB/32 is retrieved from > > the routing table, every node in the DFZ will add the PBC/48 to the > > forwarding table and the new route to the customer establishes. > > > > Advantages here are the faster convergence. A disadvantage is the major > > change in BGPs behaviour. This 'shortest path' criteria may be critical, > > because calculation of the best route might get complex and expensive. > > Also, again the routing table may grow large, but in return the > > forwarding table will stay small. It is not know what other impact a > > 'shortest prefix' selection will have. From owner-multi6@ops.ietf.org Thu Mar 27 02:12:51 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17100 for ; Thu, 27 Mar 2003 02:12:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18yRb7-000D6R-00 for multi6-data@psg.com; Wed, 26 Mar 2003 23:14:49 -0800 Received: from batch16.uni-muenster.de ([128.176.188.114]) by psg.com with esmtp (Exim 3.36 #1) id 18yRb0-000D3V-00 for multi6@ops.ietf.org; Wed, 26 Mar 2003 23:14:42 -0800 Received: from zivlnx01.uni-muenster.de (ZIVLNX01.UNI-MUENSTER.DE [128.176.188.24]) by batch16.uni-muenster.de (Postfix) with ESMTP id 1280E15BA; Thu, 27 Mar 2003 08:14:40 +0100 (MEZ) Received: from localhost (localhost.uni-muenster.de [127.0.0.1]) by zivlnx01.uni-muenster.de (Postfix with Virus Detection) with ESMTP id 18A13312CF; Thu, 27 Mar 2003 08:14:40 +0100 (CET) Received: from lemy.uni-muenster.de (LEMY.UNI-MUENSTER.DE [128.176.184.238]) by zivlnx01.uni-muenster.de (Postfix with Virus Detection) with ESMTP id 3924D312DB; Thu, 27 Mar 2003 08:14:39 +0100 (CET) Content-Type: text/plain; charset="iso-8859-1" From: Christian Schild Reply-To: schild@uni-muenster.de Organization: Westfaelische Wilhelms-Universitaet To: Iljitsch van Beijnum Subject: Re: Failover for a multihomed site with unreachable ISP Date: Thu, 27 Mar 2003 08:14:39 +0100 User-Agent: KMail/1.4.3 Cc: References: <98177E00-5FD7-11D7-8027-00039388672E@muada.com> In-Reply-To: <98177E00-5FD7-11D7-8027-00039388672E@muada.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200303270814.39663.ipng@uni-muenster.de> X-Virus-Scanned: by AMaViS 0.3.12pre7 X-Spam-Status: No, hits=-32.4 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_KMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Hi Iljitsch, Am Mittwoch, 26. März 2003 23:09 schrieb Iljitsch van Beijnum: > Christian, > > On woensdag, maa 26, 2003, at 13:39 Europe/Amsterdam, Christian Schild > wrote: > > > First, we consider a failure a seldom and abnormal event. Only if a > > direct > > connect fails, the network (or the ISP) has to take some failover > > action. > > This means that - if you think of the size of the global routing table > > - > > in default behaviour the table is small (only /32 prefixes) and only in > > case of a failure a more specific prefix (/48 or shorter) is > > neccessary. > I see two problems with this: > > 1. An ISP's aggregate route (the /32) disappearing from the global > routing table > is an extremely rare event. Last mile problems are infinitely more > common, Well, rare is not zero :). We just want to cover that case. > and after that there is the class of partial ISP failures (for > instance, > a single POP is partitioned from the network) where the aggregate > remains > visible. Hm, if just one POP disappears, the ISP (and the customer) is still rachable, we don't have a loss of connectivity and no action has to be taken. > 2. Conditional announcement makes the global routing system less > predictable, > which is dangerous. The sudden appearance of thousands of more > specific > /48s could easily break systems that could just about cope with the > regular > aggregated situation. I see. But in our approach 2, the longer prefix is already present in the routing table. Only if the shorter prefix disappears, it will be added to the forwarding table. It is some kind of 'automatic aggregation'. Do you think it will be that extremely costly? Moreover I think, systems 'that could just about cope' should be replaced, and they shouldn't be a concern here. So long, Christian From owner-multi6@ops.ietf.org Thu Mar 27 02:44:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18924 for ; Thu, 27 Mar 2003 02:44:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18yS5W-000G9F-00 for multi6-data@psg.com; Wed, 26 Mar 2003 23:46:14 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18yS5Q-000G92-00 for multi6@ops.ietf.org; Wed, 26 Mar 2003 23:46:08 -0800 Received: from muada.com (sunflower.muada.com [213.156.3.171]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2R7j7b10355; Thu, 27 Mar 2003 08:45:07 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Thu, 27 Mar 2003 08:44:50 +0100 Subject: Re: Failover for a multihomed site with unreachable ISP Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: schild@uni-muenster.de From: Iljitsch van Beijnum In-Reply-To: <200303270814.39663.ipng@uni-muenster.de> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On donderdag, maa 27, 2003, at 08:14 Europe/Amsterdam, Christian Schild wrote: >> 1. An ISP's aggregate route (the /32) disappearing from the global >> routing table is an extremely rare event. Last mile problems are >> infinitely more common, > Well, rare is not zero :). We just want to cover that case. Maybe a better solution would be a backup organization that announces the /32 if it disappears and tunnels the packets to the customers over the secondary ISPs. >> and after that there is the class of partial ISP failures (for >> instance, >> a single POP is partitioned from the network) where the aggregate >> remains visible. > Hm, if just one POP disappears, the ISP (and the customer) is still > rachable, > we don't have a loss of connectivity and no action has to be taken. ??? If the POP the customer connects to goes down, the customer isn't reachable over the addresses from that ISP anymore. >> 2. Conditional announcement makes the global routing system less >> predictable, which is dangerous. The sudden appearance of thousands >> of more >> specific /48s could easily break systems that could just about cope >> with the >> regular aggregated situation. > I see. But in our approach 2, the longer prefix is already present in > the > routing table. Only if the shorter prefix disappears, it will be added > to the > forwarding table. It is some kind of 'automatic aggregation'. Do you > think it > will be that extremely costly? Not costly, dangerous. > Moreover I think, systems 'that could just > about cope' should be replaced, and they shouldn't be a concern here. If the routers must be able to handle the full set of unaggregated prefixes anyway, why bother aggregating? Maybe this can work in theory but not in practice. Many people will just filter the /48s to avoid problems. From owner-multi6@ops.ietf.org Thu Mar 27 03:50:03 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20249 for ; Thu, 27 Mar 2003 03:50:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18yT5b-000NTv-00 for multi6-data@psg.com; Thu, 27 Mar 2003 00:50:23 -0800 Received: from batch14.uni-muenster.de ([128.176.188.112]) by psg.com with esmtp (Exim 3.36 #1) id 18yT5D-000NSY-00 for multi6@ops.ietf.org; Thu, 27 Mar 2003 00:50:00 -0800 Received: from zivlnx01.uni-muenster.de (ZIVLNX01.UNI-MUENSTER.DE [128.176.188.24]) by batch14.uni-muenster.de (Postfix) with ESMTP id 603EF11BA; Thu, 27 Mar 2003 09:49:58 +0100 (MEZ) Received: from localhost (localhost.uni-muenster.de [127.0.0.1]) by zivlnx01.uni-muenster.de (Postfix with Virus Detection) with ESMTP id 82FC0312E1; Thu, 27 Mar 2003 09:49:57 +0100 (CET) Received: from lemy.uni-muenster.de (LEMY.UNI-MUENSTER.DE [128.176.184.238]) by zivlnx01.uni-muenster.de (Postfix with Virus Detection) with ESMTP id E64BA312DE; Thu, 27 Mar 2003 09:49:56 +0100 (CET) Content-Type: text/plain; charset="iso-8859-1" From: Christian Schild Reply-To: schild@uni-muenster.de Organization: Westfaelische Wilhelms-Universitaet To: Iljitsch van Beijnum Subject: Re: Failover for a multihomed site with unreachable ISP Date: Thu, 27 Mar 2003 09:49:57 +0100 User-Agent: KMail/1.4.3 References: In-Reply-To: Cc: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200303270949.57525.ipng@uni-muenster.de> X-Virus-Scanned: by AMaViS 0.3.12pre7 X-Spam-Status: No, hits=-32.4 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_KMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Am Donnerstag, 27. März 2003 08:44 schrieben Sie: > On donderdag, maa 27, 2003, at 08:14 Europe/Amsterdam, Christian Schild > wrote: > > >> 1. An ISP's aggregate route (the /32) disappearing from the global > >> routing table is an extremely rare event. Last mile problems are > >> infinitely more common, > > > Well, rare is not zero :). We just want to cover that case. > > Maybe a better solution would be a backup organization that announces > the /32 if it disappears and tunnels the packets to the customers over > the secondary ISPs. I'm not sure if I got your point here. Are you suggesting that another ISP has to take over all the traffic for the disconnected ISP? I hardly believe this will ever happen in the real world :) Things like this could only be done administratively and we want a protocol-based solution. > >> and after that there is the class of partial ISP failures (for > >> instance, > >> a single POP is partitioned from the network) where the aggregate > >> remains visible. > > > Hm, if just one POP disappears, the ISP (and the customer) is still > > rachable, > > we don't have a loss of connectivity and no action has to be taken. > > ??? If the POP the customer connects to goes down, the customer isn't > reachable over the addresses from that ISP anymore. Oh, this is our failure case 3 and shouldn't be considered here. A tunneled solution could handle this. (Please note that we are preparing a draft for a protocol based solution that could handle cases 1-3. Later :-). > >> 2. Conditional announcement makes the global routing system less > >> predictable, which is dangerous. The sudden appearance of thousands > >> of more > >> specific /48s could easily break systems that could just about cope > >> with the > >> regular aggregated situation. > > > I see. But in our approach 2, the longer prefix is already present in > > the > > routing table. Only if the shorter prefix disappears, it will be added > > to the > > forwarding table. It is some kind of 'automatic aggregation'. Do you > > think it > > will be that extremely costly? > > Not costly, dangerous. > > > Moreover I think, systems 'that could just > > about cope' should be replaced, and they shouldn't be a concern here. > > If the routers must be able to handle the full set of unaggregated > prefixes anyway, why bother aggregating? Well, a large routing table is only a memory/msg-size problem. A large forwarding table also slows down the forwarding process. With automatic aggregation at least the latter is solved. > Maybe this can work in theory > but not in practice. Many people will just filter the /48s to avoid > problems. Well, if BGP's behaviour would change to aggregation, filtering of /48 is done automatically, and configured filtering of /48 is no longer neccessary. Christian From owner-multi6@ops.ietf.org Thu Mar 27 04:36:30 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21078 for ; Thu, 27 Mar 2003 04:36:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18yTpa-0002ut-00 for multi6-data@psg.com; Thu, 27 Mar 2003 01:37:54 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18yTpE-0002p4-00 for multi6@ops.ietf.org; Thu, 27 Mar 2003 01:37:32 -0800 Received: from muada.com (sunflower.muada.com [213.156.3.171]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2R9aVb10525; Thu, 27 Mar 2003 10:36:31 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Thu, 27 Mar 2003 10:36:15 +0100 Subject: Re: Failover for a multihomed site with unreachable ISP Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: multi6@ops.ietf.org To: schild@uni-muenster.de From: Iljitsch van Beijnum In-Reply-To: <200303270949.57525.ipng@uni-muenster.de> Message-Id: <8E391A1B-6037-11D7-B753-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On donderdag, maa 27, 2003, at 09:49 Europe/Amsterdam, Christian Schild wrote: >> Maybe a better solution would be a backup organization that announces >> the /32 if it disappears and tunnels the packets to the customers over >> the secondary ISPs. > I'm not sure if I got your point here. Are you suggesting that another > ISP > has to take over all the traffic for the disconnected ISP? I hardly > believe > this will ever happen in the real world :) It could. An ISP could set up a related, but independent backup network. Since this network would only have to peer or buy transit in a couple of locations and maintain a bunch of tunnels, this wouldn't be too costly. >> If the routers must be able to handle the full set of unaggregated >> prefixes anyway, why bother aggregating? > Well, a large routing table is only a memory/msg-size problem. Memory scales linear so that's not the biggest problem. Processing scales worse than linear so in the end that will be the downfall of huge routing tables. > A large > forwarding table also slows down the forwarding process. With automatic > aggregation at least the latter is solved. This isn't a protocol issue. Vendors can implement this today, but they choose not to. From owner-multi6@ops.ietf.org Thu Mar 27 06:10:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23224 for ; Thu, 27 Mar 2003 06:10:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18yVI2-000CWi-00 for multi6-data@psg.com; Thu, 27 Mar 2003 03:11:22 -0800 Received: from smtp01.uc3m.es ([163.117.136.121] helo=smtp.uc3m.es) by psg.com with esmtp (Exim 3.36 #1) id 18yVHm-000CWG-00 for multi6@ops.ietf.org; Thu, 27 Mar 2003 03:11:06 -0800 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 7918743373; Thu, 27 Mar 2003 12:11:05 +0100 (CET) Received: from presto.it.uc3m.es (presto.it.uc3m.es [163.117.139.134]) by smtp01.uc3m.es (Postfix) with ESMTP id 4438299E79; Thu, 27 Mar 2003 12:11:05 +0100 (CET) Subject: Re: Failover for a multihomed site with unreachable ISP From: marcelo bagnulo To: schild@uni-muenster.de Cc: multi6@ops.ietf.org In-Reply-To: <200303270757.31435.ipng@uni-muenster.de> References: <200303261339.32863.ipng@uni-muenster.de> <1048692020.737.34.camel@presto.it.uc3m.es> <200303270757.31435.ipng@uni-muenster.de> Content-Type: text/plain; charset=ISO-8859-1 Organization: uc3m Message-Id: <1048763462.739.15.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 27 Mar 2003 12:11:03 +0100 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_XIMIAN autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit On Thu, 2003-03-27 at 07:57, Christian Schild wrote: > Hi Marcelo, > > Am Mittwoch, 26. März 2003 16:20 schrieben Sie: > > Hi Cristian > > > > Wouldn't this be somehow similar to RFC 2260? > > Hm, I don't think so. RFC 2260 seems to be similar but isn't the same. In > fact, it could be used to help in one of the first three cases of failures I > talked about. > Agree, specially the tunnel part of the solution. > But RFC2260 talks about connecting a site to an ISP (e.g. by extending BGP to > the customer). In my mail I talk about how an ISP A could inject a customers > prefix (that is part of another ISP B's /32) to the DFZ, I understand that the difference would be that RFC 2260 proposes that the end-site injects the alternative route information and in the other case is the ISP that injects the address space assigned by the other ISP to the end-site. However, i am not sure that this is a feature of the alternative proposal. I mean RFC 2260 does not requires coordination between ISPs while the other proposal does. > without endangering > the size of the routing table. This is not solved by RFC2260. > I do not see any difference between the two proposals in this point (probably i am failing to understand something) I both cases a more specific prefix in injected when an outage occurs, so both proposal contribute with an additional entry in the DFZ routing table during the outage (and no longer than that) Am i missing something? Regards, marcelo > Christian > > > > > On Wed, 2003-03-26 at 13:39, Christian Schild wrote: > > > Hi ho, > > > > > > inspired by the 'dual homing experiment' document of Christian Huitema, > > > we (JOINers) thought about a solution to offer robustness for a site that > > > is multihomed and multiaddressed and that we like to discuss here. > > > Exteral connectivity of such a site is affected by failures of > > > > > > - the sites border router > > > - the sites uplink > > > - the ISPs infrastructure (spec. the router with the link to the customer) > > > - the ISPs global border router > > > - the ISPs global uplink > > > > > > To recover from such a failure in the fist three cases, the site could > > > communicate with the ISP a set of possible prefixes and connectivity could > > > get reestablished via a tunnel technology. We already thought about this, > > > but the solution is quite complex to explain it in short. It is not > > > discussed here. > > > > > > The approach I try to explain here is a solution for the last two cases, > > > where there the ISP is no longer reachable and a tunneled solution is not > > > possible. > > > > > > > > > First, we consider a failure a seldom and abnormal event. Only if a direct > > > connect fails, the network (or the ISP) has to take some failover action. > > > This means that - if you think of the size of the global routing table - > > > in default behaviour the table is small (only /32 prefixes) and only in > > > case of a failure a more specific prefix (/48 or shorter) is neccessary. > > > > > > +----------------------------+ > > > | 'Global Internet'/'DFZ' | > > > +--+-----------------------+-+ > > > | | > > > | | > > > +-----------+--+ +--+-----------+ > > > | ISP A | | ISP B | > > > | Prefix PA/32 | | Prefix PB/32 | > > > +-----------+--+ +--+-----------+ > > > | | > > > | | > > > ++-----------------------++ > > > | Customer C | > > > | Prefix PAC/48 | > > > | Prefix PBC/48 | > > > +-------------------------+ > > > > > > In this scenario customer C gets a /48 from every ISP (PAC/48 from ISP A > > > and PBC/48 from ISP B) and communicates the existance of these prefixes to > > > every provider (as mentioned earlier, how this is done is not explained > > > here). Thus, e.g. ISP A knows that it has a multihomed route to > > > customer C with prefix PBC/48. > > > > > > Usually, all traffic from the outside to PBC/48 will go through ISP B. > > > If ISP B detaches from the DFZ now, ISP A has to announce to the DFZ > > > somehow, that it has a valid route to PBC/48. This can be done in two > > > different ways within (e)BGP: > > > > > > > > > Approach 1: > > > When ISP B detaches, it's BGP announcement of PB/32 will vanish from the > > > global routing table. ISP A's border router could use this as a trigger to > > > announce PBC/48 to the DFZ. It will remove this announcement when PA/32 > > > reappears. > > > > > > The advantage here is that the /48 will only be present in the DFZ, when > > > the usual routes fail. The disadvantages are bad convergence and possible > > > multiple routes. If ISP A and ISP B are very distant, it may take some > > > time until the /48 is known everywhere. If ISP B detaches from the DFZ > > > only for a split second - or even flaps - both prefixes will be visible > > > in the DFZ for some time. > > > > > > > > > Approach 2: > > > The second approach is more severe and requires a change in BGPs default > > > routing behaviour. > > > > > > Usually BGP choses the route for a packet based on the longest prefix > > > match calculation. The suggestion here is, that (e)BGP - despite this > > > rule - chooses the _shortest_ prefix in the DFZ. This behaviour has to > > > be restricted to prefixed between /32 and /48. This restriction is > > > neccessary, because we only want this to happen in the routing area. > > > Within a site, longest prefix match should still be possible. And, > > > shortest match needs to be prevented for prefixes shorter than /32, else > > > anyone could create a _real_ black hole by announcing an /<32 to the > > > DFZ. > > > > > > Assuming this behaviour of (e)BGP, in the above scenario ISP A could > simply > > > announce PBC/48 to the DFZ. It will get announced to everyone, but it > > > should not get used in the forwarding table, cause the (now) better prefix > > > PB/32 exists. If now ISP B detaches and the prefix PB/32 is retrieved from > > > the routing table, every node in the DFZ will add the PBC/48 to the > > > forwarding table and the new route to the customer establishes. > > > > > > Advantages here are the faster convergence. A disadvantage is the major > > > change in BGPs behaviour. This 'shortest path' criteria may be critical, > > > because calculation of the best route might get complex and expensive. > > > Also, again the routing table may grow large, but in return the > > > forwarding table will stay small. It is not know what other impact a > > > 'shortest prefix' selection will have. -- marcelo bagnulo uc3m From owner-multi6@ops.ietf.org Thu Mar 27 07:06:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24360 for ; Thu, 27 Mar 2003 07:06:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18yWBX-000IpL-00 for multi6-data@psg.com; Thu, 27 Mar 2003 04:08:43 -0800 Received: from batch13.uni-muenster.de ([128.176.188.111]) by psg.com with esmtp (Exim 3.36 #1) id 18yWBR-000InF-00 for multi6@ops.ietf.org; Thu, 27 Mar 2003 04:08:37 -0800 Received: from zivlnx01.uni-muenster.de (ZIVLNX01.UNI-MUENSTER.DE [128.176.188.24]) by batch13.uni-muenster.de (Postfix) with ESMTP id 783611288; Thu, 27 Mar 2003 13:08:36 +0100 (MEZ) Received: from localhost (localhost.uni-muenster.de [127.0.0.1]) by zivlnx01.uni-muenster.de (Postfix with Virus Detection) with ESMTP id DD68E312DE; Thu, 27 Mar 2003 13:08:34 +0100 (CET) Received: from lemy.uni-muenster.de (LEMY.UNI-MUENSTER.DE [128.176.184.238]) by zivlnx01.uni-muenster.de (Postfix with Virus Detection) with ESMTP id 4C1B1312DB; Thu, 27 Mar 2003 13:08:34 +0100 (CET) Content-Type: text/plain; charset="iso-8859-1" From: Christian Schild Reply-To: schild@uni-muenster.de Organization: Westfaelische Wilhelms-Universitaet To: marcelo bagnulo Subject: Re: Failover for a multihomed site with unreachable ISP Date: Thu, 27 Mar 2003 13:08:34 +0100 User-Agent: KMail/1.4.3 Cc: multi6@ops.ietf.org References: <200303261339.32863.ipng@uni-muenster.de> <200303270757.31435.ipng@uni-muenster.de> <1048763462.739.15.camel@presto.it.uc3m.es> In-Reply-To: <1048763462.739.15.camel@presto.it.uc3m.es> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200303271308.34957.ipng@uni-muenster.de> X-Virus-Scanned: by AMaViS 0.3.12pre7 X-Spam-Status: No, hits=-33.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_KMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Am Donnerstag, 27. März 2003 12:11 schrieb marcelo bagnulo: > > > But RFC2260 talks about connecting a site to an ISP (e.g. by extending BGP to > > the customer). In my mail I talk about how an ISP A could inject a customers > > prefix (that is part of another ISP B's /32) to the DFZ, > > I understand that the difference would be that RFC 2260 proposes that > the end-site injects the alternative route information and in the other > case is the ISP that injects the address space assigned by the other ISP > to the end-site. > However, i am not sure that this is a feature of the alternative > proposal. I mean RFC 2260 does not requires coordination between ISPs > while the other proposal does. No, neither does our proposal. The ISP A reacts on signals from the DFZ (vanishing of PB/32), the other ISP B is not directly involved. A feature may be, that it is not nesseccary to establish a BGP peering to the customer and therefore the customer doesn't need to have a non-private ASN. > > > without endangering > > the size of the routing table. This is not solved by RFC2260. > > > > I do not see any difference between the two proposals in this point > (probably i am failing to understand something) > I both cases a more specific prefix in injected when an outage occurs, > so both proposal contribute with an additional entry in the DFZ routing > table during the outage (and no longer than that) > Am i missing something? You are right, I missed the conditional clause, that the customer injects a prefix _only_ when the other connection fails. But this may be a problem, as the customer may not always be able to detect a failure in the other ISP's global uplink (e.g. cause the BGP session customer<->ISP B is still established), while our proposal could handle that. So long, Christian > > > On Wed, 2003-03-26 at 13:39, Christian Schild wrote: > > > > Hi ho, > > > > > > > > inspired by the 'dual homing experiment' document of Christian Huitema, > > > > we (JOINers) thought about a solution to offer robustness for a site that > > > > is multihomed and multiaddressed and that we like to discuss here. > > > > Exteral connectivity of such a site is affected by failures of > > > > > > > > - the sites border router > > > > - the sites uplink > > > > - the ISPs infrastructure (spec. the router with the link to the customer) > > > > - the ISPs global border router > > > > - the ISPs global uplink > > > > > > > > To recover from such a failure in the fist three cases, the site could > > > > communicate with the ISP a set of possible prefixes and connectivity could > > > > get reestablished via a tunnel technology. We already thought about this, > > > > but the solution is quite complex to explain it in short. It is not > > > > discussed here. > > > > > > > > The approach I try to explain here is a solution for the last two cases, > > > > where there the ISP is no longer reachable and a tunneled solution is not > > > > possible. > > > > > > > > > > > > First, we consider a failure a seldom and abnormal event. Only if a direct > > > > connect fails, the network (or the ISP) has to take some failover action. > > > > This means that - if you think of the size of the global routing table - > > > > in default behaviour the table is small (only /32 prefixes) and only in > > > > case of a failure a more specific prefix (/48 or shorter) is neccessary. > > > > > > > > +----------------------------+ > > > > | 'Global Internet'/'DFZ' | > > > > +--+-----------------------+-+ > > > > | | > > > > | | > > > > +-----------+--+ +--+-----------+ > > > > | ISP A | | ISP B | > > > > | Prefix PA/32 | | Prefix PB/32 | > > > > +-----------+--+ +--+-----------+ > > > > | | > > > > | | > > > > ++-----------------------++ > > > > | Customer C | > > > > | Prefix PAC/48 | > > > > | Prefix PBC/48 | > > > > +-------------------------+ > > > > > > > > In this scenario customer C gets a /48 from every ISP (PAC/48 from ISP A > > > > and PBC/48 from ISP B) and communicates the existance of these prefixes to > > > > every provider (as mentioned earlier, how this is done is not explained > > > > here). Thus, e.g. ISP A knows that it has a multihomed route to > > > > customer C with prefix PBC/48. > > > > > > > > Usually, all traffic from the outside to PBC/48 will go through ISP B. > > > > If ISP B detaches from the DFZ now, ISP A has to announce to the DFZ > > > > somehow, that it has a valid route to PBC/48. This can be done in two > > > > different ways within (e)BGP: > > > > > > > > > > > > Approach 1: > > > > When ISP B detaches, it's BGP announcement of PB/32 will vanish from the > > > > global routing table. ISP A's border router could use this as a trigger to > > > > announce PBC/48 to the DFZ. It will remove this announcement when PA/32 > > > > reappears. > > > > > > > > The advantage here is that the /48 will only be present in the DFZ, when > > > > the usual routes fail. The disadvantages are bad convergence and possible > > > > multiple routes. If ISP A and ISP B are very distant, it may take some > > > > time until the /48 is known everywhere. If ISP B detaches from the DFZ > > > > only for a split second - or even flaps - both prefixes will be visible > > > > in the DFZ for some time. > > > > > > > > > > > > Approach 2: > > > > The second approach is more severe and requires a change in BGPs default > > > > routing behaviour. > > > > > > > > Usually BGP choses the route for a packet based on the longest prefix > > > > match calculation. The suggestion here is, that (e)BGP - despite this > > > > rule - chooses the _shortest_ prefix in the DFZ. This behaviour has to > > > > be restricted to prefixed between /32 and /48. This restriction is > > > > neccessary, because we only want this to happen in the routing area. > > > > Within a site, longest prefix match should still be possible. And, > > > > shortest match needs to be prevented for prefixes shorter than /32, else > > > > anyone could create a _real_ black hole by announcing an /<32 to the > > > > DFZ. > > > > > > > > Assuming this behaviour of (e)BGP, in the above scenario ISP A could > > simply > > > > announce PBC/48 to the DFZ. It will get announced to everyone, but it > > > > should not get used in the forwarding table, cause the (now) better prefix > > > > PB/32 exists. If now ISP B detaches and the prefix PB/32 is retrieved from > > > > the routing table, every node in the DFZ will add the PBC/48 to the > > > > forwarding table and the new route to the customer establishes. > > > > > > > > Advantages here are the faster convergence. A disadvantage is the major > > > > change in BGPs behaviour. This 'shortest path' criteria may be critical, > > > > because calculation of the best route might get complex and expensive. > > > > Also, again the routing table may grow large, but in return the > > > > forwarding table will stay small. It is not know what other impact a > > > > 'shortest prefix' selection will have. From owner-multi6@ops.ietf.org Thu Mar 27 07:43:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25277 for ; Thu, 27 Mar 2003 07:43:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18yWkS-000Mrf-00 for multi6-data@psg.com; Thu, 27 Mar 2003 04:44:48 -0800 Received: from smtp01.uc3m.es ([163.117.136.121] helo=smtp.uc3m.es) by psg.com with esmtp (Exim 3.36 #1) id 18yWkP-000MrS-00 for multi6@ops.ietf.org; Thu, 27 Mar 2003 04:44:45 -0800 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 58B4643370; Thu, 27 Mar 2003 13:44:44 +0100 (CET) Received: from presto.it.uc3m.es (presto.it.uc3m.es [163.117.139.134]) by smtp01.uc3m.es (Postfix) with ESMTP id 4611099E7B; Thu, 27 Mar 2003 13:44:44 +0100 (CET) Subject: Re: Failover for a multihomed site with unreachable ISP From: marcelo bagnulo To: schild@uni-muenster.de Cc: multi6@ops.ietf.org In-Reply-To: <200303271308.34957.ipng@uni-muenster.de> References: <200303261339.32863.ipng@uni-muenster.de> <200303270757.31435.ipng@uni-muenster.de> <1048763462.739.15.camel@presto.it.uc3m.es> <200303271308.34957.ipng@uni-muenster.de> Content-Type: text/plain Organization: uc3m Message-Id: <1048769078.739.24.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 27 Mar 2003 13:44:38 +0100 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-32.9 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_XIMIAN autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [...] > > > > I understand that the difference would be that RFC 2260 proposes that > > the end-site injects the alternative route information and in the other > > case is the ISP that injects the address space assigned by the other ISP > > to the end-site. > > However, i am not sure that this is a feature of the alternative > > proposal. I mean RFC 2260 does not requires coordination between ISPs > > while the other proposal does. > > No, neither does our proposal. The ISP A reacts on signals from the DFZ > (vanishing of PB/32), the other ISP B is not directly involved. Ok. But the ISPB has to know which prefix to inject, but this may be acceptable i guess... > > A feature may be, that it is not nesseccary to establish a BGP peering to the > customer and therefore the customer doesn't need to have a non-private ASN. > Yes, i think so. However, the end-site needs some mechanisms to known how to route packets. I mean, if there is an outage above ISPa, the end-site needs to know that it must send packets through ISPb, how do you achieve that if you do not use BGP? Regards, marcelo From owner-multi6@ops.ietf.org Thu Mar 27 08:48:53 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28812 for ; Thu, 27 Mar 2003 08:48:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18yXlC-0004qZ-00 for multi6-data@psg.com; Thu, 27 Mar 2003 05:49:38 -0800 Received: from batch16.uni-muenster.de ([128.176.188.114]) by psg.com with esmtp (Exim 3.36 #1) id 18yXl9-0004qI-00 for multi6@ops.ietf.org; Thu, 27 Mar 2003 05:49:35 -0800 Received: from zivlnx01.uni-muenster.de (ZIVLNX01.UNI-MUENSTER.DE [128.176.188.24]) by batch16.uni-muenster.de (Postfix) with ESMTP id 07CB011B8; Thu, 27 Mar 2003 14:49:33 +0100 (MEZ) Received: from localhost (localhost.uni-muenster.de [127.0.0.1]) by zivlnx01.uni-muenster.de (Postfix with Virus Detection) with ESMTP id D1D00312DE; Thu, 27 Mar 2003 14:49:32 +0100 (CET) Received: from lemy.uni-muenster.de (LEMY.UNI-MUENSTER.DE [128.176.184.238]) by zivlnx01.uni-muenster.de (Postfix with Virus Detection) with ESMTP id 6800C312CF; Thu, 27 Mar 2003 14:49:31 +0100 (CET) Content-Type: text/plain; charset="iso-8859-1" From: Christian Schild Reply-To: schild@uni-muenster.de Organization: Westfaelische Wilhelms-Universitaet To: marcelo bagnulo Subject: Re: Failover for a multihomed site with unreachable ISP Date: Thu, 27 Mar 2003 14:49:32 +0100 User-Agent: KMail/1.4.3 Cc: multi6@ops.ietf.org References: <200303261339.32863.ipng@uni-muenster.de> <200303271308.34957.ipng@uni-muenster.de> <1048769078.739.24.camel@presto.it.uc3m.es> In-Reply-To: <1048769078.739.24.camel@presto.it.uc3m.es> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200303271449.32136.ipng@uni-muenster.de> X-Virus-Scanned: by AMaViS 0.3.12pre7 X-Spam-Status: No, hits=-32.4 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_KMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Am Donnerstag, 27. März 2003 13:44 schrieb marcelo bagnulo: > [...] > > > A feature may be, that it is not nesseccary to establish a BGP peering to the > > customer and therefore the customer doesn't need to have a non-private ASN. > > > > Yes, i think so. > However, the end-site needs some mechanisms to known how to route > packets. I mean, if there is an outage above ISPa, the end-site needs to > know that it must send packets through ISPb, how do you achieve that if > you do not use BGP? Ok, well. This can be done with some kind of multihoming information exchange protocol, that signals failures and simultanously securely exchanges prefix information between the customer and the ISP, opens and closes secure tunnels between them and sets proper ingress filters. Don't worry, should we write it down in detail? :-) Christian From owner-multi6@ops.ietf.org Thu Mar 27 09:13:29 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29498 for ; Thu, 27 Mar 2003 09:13:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18yY9o-0008A4-00 for multi6-data@psg.com; Thu, 27 Mar 2003 06:15:04 -0800 Received: from smtp02.uc3m.es ([163.117.136.122] helo=smtp.uc3m.es) by psg.com with esmtp (Exim 3.36 #1) id 18yY9i-00089J-00 for multi6@ops.ietf.org; Thu, 27 Mar 2003 06:14:59 -0800 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 92B4743394; Thu, 27 Mar 2003 15:14:57 +0100 (CET) Received: from presto.it.uc3m.es (presto.it.uc3m.es [163.117.139.134]) by smtp02.uc3m.es (Postfix) with ESMTP id 8289F99F4D; Thu, 27 Mar 2003 15:14:57 +0100 (CET) Subject: Re: Failover for a multihomed site with unreachable ISP From: marcelo bagnulo To: schild@uni-muenster.de Cc: multi6@ops.ietf.org In-Reply-To: <200303271449.32136.ipng@uni-muenster.de> References: <200303261339.32863.ipng@uni-muenster.de> <200303271308.34957.ipng@uni-muenster.de> <1048769078.739.24.camel@presto.it.uc3m.es> <200303271449.32136.ipng@uni-muenster.de> Content-Type: text/plain; charset=ISO-8859-1 Organization: uc3m Message-Id: <1048774494.738.30.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 27 Mar 2003 15:14:54 +0100 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_XIMIAN autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit On Thu, 2003-03-27 at 14:49, Christian Schild wrote: > Am Donnerstag, 27. März 2003 13:44 schrieb marcelo bagnulo: > > [...] > > > > > A feature may be, that it is not nesseccary to establish a BGP peering to > the > > > customer and therefore the customer doesn't need to have a non-private > ASN. > > > > > > > Yes, i think so. > > However, the end-site needs some mechanisms to known how to route > > packets. I mean, if there is an outage above ISPa, the end-site needs to > > know that it must send packets through ISPb, how do you achieve that if > > you do not use BGP? > > Ok, well. This can be done with some kind of multihoming information exchange > protocol, that signals failures and simultanously securely exchanges prefix > information between the customer and the ISP, I would say that this can be done using BGP, what advantages do find in providing a new tool? > opens and closes secure tunnels > between them and sets proper ingress filters. I think this may be interesting... Christian's Host centric proposal deals with ingress filtering problems, but i do not recall that this possibility is considered, perhaps it would be interesting to study it (IMHO). Regards, marcelo > Don't worry, should we write it > down in detail? :-) > > Christian > -- marcelo bagnulo uc3m From owner-multi6@ops.ietf.org Thu Mar 27 17:15:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21956 for ; Thu, 27 Mar 2003 17:15:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18yffI-0002e9-00 for multi6-data@psg.com; Thu, 27 Mar 2003 14:16:04 -0800 Received: from pcp744791pcs.reston01.va.comcast.net ([68.49.138.160] helo=mail.krioukov.net) by psg.com with esmtp (Exim 3.36 #1) id 18yff8-0002ZH-00 for multi6@ops.ietf.org; Thu, 27 Mar 2003 14:15:55 -0800 Received: from DIMA1 (dhcp-host-017.pcp744791pcs.reston01.va.comcast.net [192.168.1.17]) by mail.krioukov.net (8.11.6/8.11.6) with SMTP id h2RMFpO23909 for ; Thu, 27 Mar 2003 17:15:51 -0500 From: "Dmitri Krioukov" To: Subject: RE: Architectural approaches to multi6 Date: Thu, 27 Mar 2003 17:15:48 -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.2911.0) In-Reply-To: <1A923834-5F22-11D7-9C73-00039388672E@muada.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Status: No, hits=-14.3 required=5.0 tests=BAYES_01,IN_REP_TO,MSGID_GOOD_EXCHANGE,RCVD_IN_RFCI autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit After browsing through this thread I'd like to ask the following question: how many people on this list would agree that a scalable *engineering* solution to the multihoming problem can be based neither on routing as we know it today nor on any future improved and superior routing architecture (if such an architecture is based on the graph-theoretical network representation)? (I assume that any address binding mechanisms (similar to DNS) are not considered as a part of routing.) Also, a somewhat related question: is handling failures beyond the links between the multihomer and its transit provider (such as failures of links between providers and the rest of the world) a requirement? That it is not is an implicit assumption of my first question. If it is (like it seemingly follows from the requirement ID but not from Christian's experiment), then a solution can only be routing-based, and, hence (how many would agree?), it cannot be scalable. thanks, -- dima. From owner-multi6@ops.ietf.org Thu Mar 27 18:02:55 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23247 for ; Thu, 27 Mar 2003 18:02:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ygQT-000AdZ-00 for multi6-data@psg.com; Thu, 27 Mar 2003 15:04:49 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18ygQQ-000Acb-00 for multi6@ops.ietf.org; Thu, 27 Mar 2003 15:04:46 -0800 Received: from muada.com (sunflower.muada.com [213.156.3.171]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2RN3jb11671; Fri, 28 Mar 2003 00:03:45 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Fri, 28 Mar 2003 00:03:28 +0100 Subject: Re: Architectural approaches to multi6 Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: "Dmitri Krioukov" From: Iljitsch van Beijnum In-Reply-To: Message-Id: <52762CA1-60A8-11D7-BC5C-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-19.4 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On donderdag, maa 27, 2003, at 23:15 Europe/Amsterdam, Dmitri Krioukov wrote: > After browsing through this thread I'd like > to ask the following question: how many people > on this list would agree that a scalable > *engineering* solution to the multihoming > problem can be based neither on routing as we > know it today nor on any future improved and > superior routing architecture I wouldn't: http://www.ietf.org/internet-drafts/draft-van-beijnum-multi6-isp-int- aggr-00.txt There's also the current practice of announcing a more specific out of A's aggregate to B. Even if the more specific is filered so traffic ends up with A, if A and B peer it can still reach the destination over B. > Also, a somewhat related question: is handling > failures beyond the links between the multihomer > and its transit provider (such as failures of links > between providers and the rest of the world) a > requirement? For some users: yes. > That it is not is an implicit assumption > of my first question. If it is (like it seemingly > follows from the requirement ID but not from Christian's > experiment), then a solution can only be routing-based, > and, hence (how many would agree?), it cannot be > scalable. I don't see how your conclusion follows from your premise. Adding a level of indirection (such as the identifier/locator separation) would handle this nicely. From owner-multi6@ops.ietf.org Thu Mar 27 19:59:04 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29269 for ; Thu, 27 Mar 2003 19:59:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18yiDJ-0004Y1-00 for multi6-data@psg.com; Thu, 27 Mar 2003 16:59:21 -0800 Received: from jazz-1.trumpet.com.au ([203.5.119.62]) by psg.com with esmtp (Exim 3.36 #1) id 18yiDF-0004Xo-00 for multi6@ops.ietf.org; Thu, 27 Mar 2003 16:59:17 -0800 Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id LAA22425; Fri, 28 Mar 2003 11:59:09 +1100 (EST) Date: Fri, 28 Mar 2003 11:59:09 +1100 (EST) From: Peter Tattam To: Dmitri Krioukov cc: multi6@ops.ietf.org Subject: RE: Architectural approaches to multi6 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-22.6 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTE_TWICE_1, USER_AGENT_PINE autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 27 Mar 2003, Dmitri Krioukov wrote: > After browsing through this thread I'd like > to ask the following question: how many people > on this list would agree that a scalable > *engineering* solution to the multihoming > problem can be based neither on routing as we > know it today nor on any future improved and > superior routing architecture (if such an > architecture is based on the graph-theoretical > network representation)? (I assume that any > address binding mechanisms (similar to DNS) > are not considered as a part of routing.) I do, based on the premise that multihoming information to end points cannot be transmitted via a broadcast or via a routing protocol without the transmission being unscalable. The goal of transmitting the information conflicts with the goal of maintaining stability of the core. We see the results of this in BGP by the instability caused by route flapping and other similar events. In my opinion, BGP represents an unstable feedback loop or system. Mathematically, I believe it can probably be modelled by differential equations which ultimately have perioidic functions as solutions. I am not even sure that BGP can cope fully with unstable links between nodes even in a fully aggregated network. However an aggregated network eliminates two areas of instability. The first is that in an unaggregated BGP network, when a link becomes degraded the traffic being redirected via another path is likely to add components to the differential equation that result in positive feedback loops. The second is that in an unaggregated BGP network, minor changes to the topology need to be propagated (i.e. broadcast) to the entire network. Aside from the problem of all nodes requiring enough resources to process the quantity of information, it is this widespread broadcasting which further adds to excessive data passing from node to node and adding further complications to the differential equation representing the whole network. That's my opinion. The analysis may be flawed, so feel free to criticize. > > Also, a somewhat related question: is handling > failures beyond the links between the multihomer > and its transit provider (such as failures of links > between providers and the rest of the world) a > requirement? That it is not is an implicit assumption > of my first question. If it is (like it seemingly > follows from the requirement ID but not from Christian's > experiment), then a solution can only be routing-based, > and, hence (how many would agree?), it cannot be > scalable. > > thanks, > -- > dima. > > > > -- 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 Mar 28 00:07:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04841 for ; Fri, 28 Mar 2003 00:07:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ym5R-000KMH-00 for multi6-data@psg.com; Thu, 27 Mar 2003 21:07:29 -0800 Received: from dmz1.procket.com ([65.174.124.36]) by psg.com with esmtp (Exim 3.36 #1) id 18ym5O-000KM5-00 for multi6@ops.ietf.org; Thu, 27 Mar 2003 21:07:26 -0800 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 31BCC23C4F; Thu, 27 Mar 2003 20:57:23 -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 h2S57PYB009145; Thu, 27 Mar 2003 21:07: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="us-ascii" Subject: RE: Architectural approaches to multi6 Date: Thu, 27 Mar 2003 21:07:25 -0800 Message-ID: Thread-Topic: Architectural approaches to multi6 Thread-Index: AcL0sgOM4RtmkbQjSDCcFbDHcX4eqgANTgEw From: "Tony Li" To: "Dmitri Krioukov" , X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA04841 I would NOT agree that there are no solutions in routing. That said, I think that a solution MUST involve having the transport NOT use the locator as a portion of the pseudo-header. So at the very least, there must be host changes. I believe that we must solve the failure of non-last-mile links, including ISP links or even site-internal links. We cannot do this through signaling our routing and be scalable, so there must be some way for the correspondent host to try multiple locators and figure out which locators currently work. Tony | -----Original Message----- | From: Dmitri Krioukov [mailto:dima@krioukov.net] | Sent: Thursday, March 27, 2003 2:16 PM | To: multi6@ops.ietf.org | Subject: RE: Architectural approaches to multi6 | | | After browsing through this thread I'd like | to ask the following question: how many people | on this list would agree that a scalable | *engineering* solution to the multihoming | problem can be based neither on routing as we | know it today nor on any future improved and | superior routing architecture (if such an | architecture is based on the graph-theoretical | network representation)? (I assume that any | address binding mechanisms (similar to DNS) | are not considered as a part of routing.) | | Also, a somewhat related question: is handling | failures beyond the links between the multihomer | and its transit provider (such as failures of links | between providers and the rest of the world) a | requirement? That it is not is an implicit assumption | of my first question. If it is (like it seemingly | follows from the requirement ID but not from Christian's | experiment), then a solution can only be routing-based, | and, hence (how many would agree?), it cannot be | scalable. | | thanks, | -- | dima. | | | | From owner-multi6@ops.ietf.org Fri Mar 28 10:29:45 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03691 for ; Fri, 28 Mar 2003 10:29:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18yvnY-0005MD-00 for multi6-data@psg.com; Fri, 28 Mar 2003 07:29:40 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18yvnV-0005Lv-00 for multi6@ops.ietf.org; Fri, 28 Mar 2003 07:29:37 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2SFTYt30375 for ; Fri, 28 Mar 2003 17:29:34 +0200 Date: Fri, 28 Mar 2003 17:29:33 +0200 (EET) From: Pekka Savola To: multi6@ops.ietf.org Subject: plug: thesis on site multihoming Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-11.5 required=5.0 tests=BAYES_10,USER_AGENT_PINE autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Hi, Sorry for a plug, but it seems relevant and may be interesting for lots of people. I'm about to submit a MSc thesis on the subject of "Examining Site Multihoming in Finnish Networks", first looking at IPv4 and then IPv6. If you're interested, it's available at: http://staff.csc.fi/psavola/di.ps (.pdf is also there but quality is worse) There's some minor work to be done still (like writing the abstract, making a few pictures clearer and actually reading it properly myself ;-), but it should pretty close to done (submitting for review in the beginning of next week, making small modifications up until about 2 weeks from now). Even if you don't have the time, I intend to split off a modified section (likely based on sections 6.1 and 6.2) and submit it as an I-D in a week or two. By breaking down the sites by a few different types and looking at which multihoming requirements they have, we seem to be able to solve almost all problems at least to some extent quite nicely. Of course, with long term, things can be improved a lot. Comments etc. are of course really appreciated; off-list is probably best at least for the most of them. In another w.g. I made a joke about most thesis's being non-relevant and useless (for the IETF). Hopefully this doesn't fall into that category :-). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Fri Mar 28 11:11:54 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05340 for ; Fri, 28 Mar 2003 11:11:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ywUA-000DmH-00 for multi6-data@psg.com; Fri, 28 Mar 2003 08:13:42 -0800 Received: from zmamail05.zma.compaq.com ([161.114.64.105]) by psg.com with esmtp (Exim 3.36 #1) id 18ywU8-000Dm4-00 for multi6@ops.ietf.org; Fri, 28 Mar 2003 08:13:40 -0800 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 55AECA933; Fri, 28 Mar 2003 11:13:39 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 28 Mar 2003 11:13:35 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: Architectural approaches to multi6 Date: Fri, 28 Mar 2003 11:13:35 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCEC0@tayexc13.americas.cpqcorp.net> Thread-Topic: Architectural approaches to multi6 Thread-Index: AcL0sgOM4RtmkbQjSDCcFbDHcX4eqgANTgEwABdU0fA= From: "Bound, Jim" To: "Tony Li" , "Dmitri Krioukov" , X-OriginalArrivalTime: 28 Mar 2003 16:13:35.0933 (UTC) FILETIME=[FC4DBED0:01C2F544] X-Spam-Status: No, hits=-10.4 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1 autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA05340 > > I would NOT agree that there are no solutions in routing. > That said, I think that a solution MUST involve having > the transport NOT use the locator as a portion of the > pseudo-header. So at the very least, there must be host changes. With MHAP this would not be needed as the PI would enter the Host Node with the identifier in the header and could be used for the checksum, in that architecture view. The use of the HOA with a MIPv6 architecture would also avoid this problem. Looking at GFN and HIP currently. > > I believe that we must solve the failure of non-last-mile > links, including ISP links or even site-internal links. We > cannot do this through signaling our routing and be scalable, > so there must be some way for the > correspondent host to try multiple locators and figure > out which locators currently work. This is more complex. /jim From owner-multi6@ops.ietf.org Fri Mar 28 11:12:02 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05356 for ; Fri, 28 Mar 2003 11:12:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ywUN-000Dmd-00 for multi6-data@psg.com; Fri, 28 Mar 2003 08:13:55 -0800 Received: from mail5.microsoft.com ([131.107.3.121]) by psg.com with esmtp (Exim 3.36 #1) id 18ywUK-000DmR-00 for multi6@ops.ietf.org; Fri, 28 Mar 2003 08:13:52 -0800 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Fri, 28 Mar 2003 08:13:51 -0800 Received: from 157.54.8.109 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 28 Mar 2003 08:13:51 -0800 Received: from RED-IMC-02.redmond.corp.microsoft.com ([157.54.9.107]) by INET-HUB-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Fri, 28 Mar 2003 08:14:15 -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); Fri, 28 Mar 2003 08:13:52 -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.3788.0); Fri, 28 Mar 2003 08:13:50 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Architectural approaches to multi6 Date: Fri, 28 Mar 2003 08:13:54 -0800 Message-ID: Thread-Topic: Architectural approaches to multi6 Thread-Index: AcL0sgOM4RtmkbQjSDCcFbDHcX4eqgANTgEwABcZL6A= From: "Christian Huitema" To: "Tony Li" , "Dmitri Krioukov" , X-OriginalArrivalTime: 28 Mar 2003 16:13:50.0176 (UTC) FILETIME=[04CB0E00:01C2F545] X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA05356 > I would NOT agree that there are no solutions in routing. > That said, I think that a solution MUST involve having > the transport NOT use the locator as a portion of the > pseudo-header. So at the very least, there must be host > changes. I disagree with Tony. There is a known solution, which is to use multiple addresses per endpoint. This effectively provides a solution to the aggregation/routing load dilemma by representing the routing graph as the superposition of several trees, all rooted in the DFZ. I would contend that this is the only solution in case of host multi-homing (e.g. GPRS+WIFI): in this case, the independent trees are joined at their leaves. This is a suboptimal but workable solution in case of site multi-homing, as the independent trees are joined at the "site" branch. How suboptimal depends on the size of that branch vs. the size of the tree. In practice, this is not an issue for very small sites, e.g. single subnet sites, as the branch is tiny. It is not a real issue either for very large branches, e.g. sites such as IBM or Microsoft, as the branch is so large that it can be considered "close to the root" and given its own number. We have an issue for the medium size branches, which can be solved either by a routing solution (find a way to route more prefixes) or by a site engineering solution (better management to make medium sites look like large sites). -- Christian Huitema From owner-multi6@ops.ietf.org Fri Mar 28 13:54:22 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12027 for ; Fri, 28 Mar 2003 13:54:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18yz0I-000FZi-00 for multi6-data@psg.com; Fri, 28 Mar 2003 10:55:02 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18yz0E-000FZF-00 for multi6@ops.ietf.org; Fri, 28 Mar 2003 10:54:58 -0800 Received: from muada.com (sunflower.muada.com [213.156.3.171]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2SIrub13663; Fri, 28 Mar 2003 19:53:56 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Fri, 28 Mar 2003 19:53:40 +0100 Subject: Re: Architectural approaches to multi6 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: "Christian Huitema" From: Iljitsch van Beijnum In-Reply-To: Message-Id: <9738A8C0-614E-11D7-AAB6-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On vrijdag, maa 28, 2003, at 17:13 Europe/Amsterdam, Christian Huitema wrote: > This is a suboptimal but workable solution in case of site > multi-homing, > as the independent trees are joined at the "site" branch. How > suboptimal > depends on the size of that branch vs. the size of the tree. I'd like to take this opportunity to remark that internet addressing doesn't look like a tree. It's more like a field full of weed. There are just two levels in the hierarchy: ISPs and customers. There is no level above the ISPs. With a /8 worth of /32s that makes for a potential of 512M bonsais rather than a single tree. That's a shame really, because a tree would allow interesting new routing mechanisms. From owner-multi6@ops.ietf.org Fri Mar 28 14:14:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12973 for ; Fri, 28 Mar 2003 14:14:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18yzL1-000KiX-00 for multi6-data@psg.com; Fri, 28 Mar 2003 11:16:27 -0800 Received: from zmamail03.zma.compaq.com ([161.114.64.103]) by psg.com with esmtp (Exim 3.36 #1) id 18yzKy-000KiC-00 for multi6@ops.ietf.org; Fri, 28 Mar 2003 11:16:24 -0800 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id E6BC4343D; Fri, 28 Mar 2003 14:15:57 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 28 Mar 2003 14:15:56 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: Architectural approaches to multi6 Date: Fri, 28 Mar 2003 14:15:56 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCEE7@tayexc13.americas.cpqcorp.net> Thread-Topic: Architectural approaches to multi6 Thread-Index: AcL1XZO6z9Qvsrg8QzqbEPnqoJ0MSgAANTgg From: "Bound, Jim" To: "Iljitsch van Beijnum" , "Christian Huitema" Cc: X-OriginalArrivalTime: 28 Mar 2003 19:15:56.0502 (UTC) FILETIME=[75641760:01C2F55E] X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA12973 This was also my architectural point about the Internet being chaos :--) /jim > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: Friday, March 28, 2003 1:54 PM > To: Christian Huitema > Cc: multi6@ops.ietf.org > Subject: Re: Architectural approaches to multi6 > > > On vrijdag, maa 28, 2003, at 17:13 Europe/Amsterdam, > Christian Huitema > wrote: > > > This is a suboptimal but workable solution in case of site > > multi-homing, > > as the independent trees are joined at the "site" branch. How > > suboptimal > > depends on the size of that branch vs. the size of the tree. > > I'd like to take this opportunity to remark that internet addressing > doesn't look like a tree. It's more like a field full of weed. There > are just two levels in the hierarchy: ISPs and customers. There is no > level above the ISPs. With a /8 worth of /32s that makes for a > potential of 512M bonsais rather than a single tree. > > That's a shame really, because a tree would allow interesting new > routing mechanisms. > > > From owner-multi6@ops.ietf.org Fri Mar 28 14:47:14 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14364 for ; Fri, 28 Mar 2003 14:47:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18yzqc-0001vP-00 for multi6-data@psg.com; Fri, 28 Mar 2003 11:49:06 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18yzqZ-0001qM-00 for multi6@ops.ietf.org; Fri, 28 Mar 2003 11:49:03 -0800 Received: from muada.com (sunflower.muada.com [213.156.3.171]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2SJm1b13800; Fri, 28 Mar 2003 20:48:01 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Fri, 28 Mar 2003 20:47:44 +0100 Subject: Re: Architectural approaches to multi6 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: "Bound, Jim" From: Iljitsch van Beijnum In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03ABCEE7@tayexc13.americas.cpqcorp.net> Message-Id: <24FD4A7C-6156-11D7-AAB6-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On vrijdag, maa 28, 2003, at 20:15 Europe/Amsterdam, Bound, Jim wrote: > This was also my architectural point about the Internet being chaos > :--) In the end entropy will get the better of us, but that doesn't mean we can create some order in the chaos for the time being. Any opinions as to whether it's worth the trouble to try to create a hierarchy? With the right renumbering tools it could be done. From owner-multi6@ops.ietf.org Fri Mar 28 17:35:07 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22240 for ; Fri, 28 Mar 2003 17:35:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18z2RI-0009z0-00 for multi6-data@psg.com; Fri, 28 Mar 2003 14:35:08 -0800 Received: from pcp744791pcs.reston01.va.comcast.net ([68.49.138.160] helo=mail.krioukov.net) by psg.com with esmtp (Exim 3.36 #1) id 18z2RC-0009uN-00 for multi6@ops.ietf.org; Fri, 28 Mar 2003 14:35:02 -0800 Received: from DIMA1 (dhcp-host-017.pcp744791pcs.reston01.va.comcast.net [192.168.1.17]) by mail.krioukov.net (8.11.6/8.11.6) with SMTP id h2SMZ3O29626 for ; Fri, 28 Mar 2003 17:35:03 -0500 From: "Dmitri Krioukov" To: Subject: RE: Architectural approaches to multi6 Date: Fri, 28 Mar 2003 17:35:01 -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.2911.0) In-Reply-To: <24FD4A7C-6156-11D7-AAB6-00039388672E@muada.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-Spam-Status: No, hits=-14.3 required=5.0 tests=BAYES_01,IN_REP_TO,MSGID_GOOD_EXCHANGE,RCVD_IN_RFCI autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Thanks for replies so far. I'd just like to note that I used the term "routing" in a very narrow sense. To be precise, I meant the "routing function." The definition can be found, for example, in: http://citeseer.nj.nec.com/gavoille01routing.html For example, separation of "locators" and "identificators", and then using various dynamic binding mechanisms, is not routing in this sense. With these definitions, I guess more people would agree with my initial assertion since the multihomer is necessarily a node on the graph and the shortest path routing was found to be incompressible on generic graphs (see the above link but note that it deals with the ideal world (static and centralized), yet it provides valuable information on the fundamental limitations of any routing (even not yet invented)). -- dima. From owner-multi6@ops.ietf.org Fri Mar 28 17:35:15 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22259 for ; Fri, 28 Mar 2003 17:35:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18z2RR-0009zP-00 for multi6-data@psg.com; Fri, 28 Mar 2003 14:35:17 -0800 Received: from pcp744791pcs.reston01.va.comcast.net ([68.49.138.160] helo=mail.krioukov.net) by psg.com with esmtp (Exim 3.36 #1) id 18z2RC-0009ug-00 for multi6@ops.ietf.org; Fri, 28 Mar 2003 14:35:02 -0800 Received: from DIMA1 (dhcp-host-017.pcp744791pcs.reston01.va.comcast.net [192.168.1.17]) by mail.krioukov.net (8.11.6/8.11.6) with SMTP id h2SMZ3O29629; Fri, 28 Mar 2003 17:35:03 -0500 From: "Dmitri Krioukov" To: "Christian Huitema" Cc: Subject: RE: Architectural approaches to multi6 Date: Fri, 28 Mar 2003 17:35:01 -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.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-Spam-Status: No, hits=-17.5 required=5.0 tests=BAYES_01,IN_REP_TO,MSGID_GOOD_EXCHANGE,QUOTED_EMAIL_TEXT, RCVD_IN_RFCI autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Christian, A near optimal bounds of the number of trees required for tree-cover routing were found in http://www.cs.tau.ac.il/~zwick/papers/route-SPAA.ps.gz It follows that if no path inflation is allowed (stretch k=1), then this number scales as O(N) on generic graphs, so you do not gain anything (which is, of course, just a consequence of the more general fact that the shortest path routing is incompressible). But the Internet topology is not generic, it's scale-free. So, has there any analysis been done on tree-covers of Internet-like topologies (with the hope for better scaling)? Also, given the dynamic version of the problem, how do I know what tree to use to reach a specific destination at a specific moment of time? thanks, -- dima. > -----Original Message----- > From: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]On > Behalf Of Christian Huitema > Sent: Friday, March 28, 2003 11:14 AM > To: Tony Li; Dmitri Krioukov; multi6@ops.ietf.org > Subject: RE: Architectural approaches to multi6 > > > > I would NOT agree that there are no solutions in routing. > > That said, I think that a solution MUST involve having > > the transport NOT use the locator as a portion of the > > pseudo-header. So at the very least, there must be host > > changes. > > I disagree with Tony. There is a known solution, which is to use > multiple addresses per endpoint. This effectively provides a solution to > the aggregation/routing load dilemma by representing the routing graph > as the superposition of several trees, all rooted in the DFZ. I would > contend that this is the only solution in case of host multi-homing > (e.g. GPRS+WIFI): in this case, the independent trees are joined at > their leaves. > > This is a suboptimal but workable solution in case of site multi-homing, > as the independent trees are joined at the "site" branch. How suboptimal > depends on the size of that branch vs. the size of the tree. In > practice, this is not an issue for very small sites, e.g. single subnet > sites, as the branch is tiny. It is not a real issue either for very > large branches, e.g. sites such as IBM or Microsoft, as the branch is so > large that it can be considered "close to the root" and given its own > number. > > We have an issue for the medium size branches, which can be solved > either by a routing solution (find a way to route more prefixes) or by a > site engineering solution (better management to make medium sites look > like large sites). > > -- Christian Huitema > From owner-multi6@ops.ietf.org Fri Mar 28 20:02:38 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27265 for ; Fri, 28 Mar 2003 20:02:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18z4kq-000HV8-00 for multi6-data@psg.com; Fri, 28 Mar 2003 17:03:28 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18z4kn-000HRr-00 for multi6@ops.ietf.org; Fri, 28 Mar 2003 17:03:25 -0800 Received: from muada.com (sunflower.muada.com [213.156.3.171]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2T12Nb14200; Sat, 29 Mar 2003 02:02:23 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Sat, 29 Mar 2003 02:02:07 +0100 Subject: Re: Architectural approaches to multi6 Content-Type: text/plain; charset=EUC-KR; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: "Dmitri Krioukov" From: Iljitsch van Beijnum In-Reply-To: Message-Id: <102FC764-6182-11D7-AAB6-00039388672E@muada.com> X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-19.4 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA27265 On vrijdag, maa 28, 2003, at 23:35 Europe/Amsterdam, Dmitri Krioukov wrote: > http://citeseer.nj.nec.com/gavoille01routing.html > With these definitions, I guess more > people would agree with my initial > assertion since the multihomer is > necessarily a node on the graph and > the shortest path routing was found > to be incompressible on generic graphs > (see the above link but note that it > deals with the ideal world (static > and centralized), yet it provides > valuable information on the fundamental > limitations of any routing (even > not yet invented)). I'm not so sure. I'm sure the math guys are really good at what they do, however it often doesn't have much to do with the real world. I have to admit that I can't decode a good deal of the math, but regardless of what omega is here, the following doesn't make sense: "The current lower bound is only ¥Ø(¡în) bits for strategies optimizing shortest paths" (talking about local memory) I believe that in a strictly hierarchical routing system it's possible to suffice with d+log(d)+3*log(3) bits of memory. Sure, you need something like n*log(n) routers that way, but that's another story... In a hierarchical system, you can aggregate away more and more information as you get higher in the hierarchy. However, when a node moves to another part of the hierarchy, you break aggregation for part of the tree. The farther the node moves, the more aggregation suffers. But we can move nodes short distances in the hierarchy without causing many problems. So if we align our addressing hierarchy with the possible movements of nodes and/or the other way around, routing-based and scalable multihoming becomes possible. Hence my proposal for geographic aggregation. Then, when a site moves from one ISP to another as the result of a rehoming event, aggregation is still intact from the closest place where the ISPs interconnect and up. From owner-multi6@ops.ietf.org Fri Mar 28 21:26:01 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29183 for ; Fri, 28 Mar 2003 21:26:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18z63p-0007yl-00 for multi6-data@psg.com; Fri, 28 Mar 2003 18:27:09 -0800 Received: from pcp744791pcs.reston01.va.comcast.net ([68.49.138.160] helo=mail.krioukov.net) by psg.com with esmtp (Exim 3.36 #1) id 18z63m-0007yZ-00 for multi6@ops.ietf.org; Fri, 28 Mar 2003 18:27:06 -0800 Received: from DIMA1 (dhcp-host-017.pcp744791pcs.reston01.va.comcast.net [192.168.1.17]) by mail.krioukov.net (8.11.6/8.11.6) with SMTP id h2T2QxO30555; Fri, 28 Mar 2003 21:26:59 -0500 From: "Dmitri Krioukov" To: "Iljitsch van Beijnum" Cc: Subject: RE: Architectural approaches to multi6 Date: Fri, 28 Mar 2003 21:26:55 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <102FC764-6182-11D7-AAB6-00039388672E@muada.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-Spam-Status: No, hits=-16.7 required=5.0 tests=BAYES_10,IN_REP_TO,MSGID_GOOD_EXCHANGE,QUOTED_EMAIL_TEXT, RCVD_IN_RFCI autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Iljitsch, This is not math but CS :) You probably refer to some place in the overview where generic graphs are discussed. Sure, routing on special types of graphs can be much more compact. For example, it's O(1) for rings. For trees, the best known result requires only ~O(log(N)) bits of memory to store node IDs, and nothing else, -- based only on its node ID plus source and destination node IDs, the node can make its routing decisions in constant time. All known constructions with multiple levels of abstraction are inferior to more recent findings. In addition, you cannot seriously speak about "locality" on the Internet inter-domain graph since there are very few "remote" vertices -- the average AS path length is between 3 and 4 with a very narrow width of the distance distribution. The main problem with applicability of those generic results to the Internet is that they are too generic. The Internet is not a ring or a tree, of course, but it has its specific topology, which is scale-free (power-law) and for which exact bounds are not known yet (at least to me). -- dima. > -----Original Message----- > From: owner-multi6@ops.ietf.org > [mailto:owner-multi6@ops.ietf.org]On Behalf Of Iljitsch van Beijnum > Sent: Friday, March 28, 2003 8:02 PM > To: Dmitri Krioukov > Cc: multi6@ops.ietf.org > Subject: Re: Architectural approaches to multi6 > > > On vrijdag, maa 28, 2003, at 23:35 Europe/Amsterdam, Dmitri Krioukov > wrote: > > > http://citeseer.nj.nec.com/gavoille01routing.html > > > With these definitions, I guess more > > people would agree with my initial > > assertion since the multihomer is > > necessarily a node on the graph and > > the shortest path routing was found > > to be incompressible on generic graphs > > (see the above link but note that it > > deals with the ideal world (static > > and centralized), yet it provides > > valuable information on the fundamental > > limitations of any routing (even > > not yet invented)). > > I'm not so sure. I'm sure the math guys are really good at what they > do, however it often doesn't have much to do with the real world. I > have to admit that I can't decode a good deal of the math, but > regardless of what omega is here, the following doesn't make sense: > > "The current lower bound is only ¥Ø(¡în) bits for strategies optimizing > shortest paths" (talking about local memory) > > I believe that in a strictly hierarchical routing system it's possible > to suffice with d+log(d)+3*log(3) bits of memory. Sure, you need > something like n*log(n) routers that way, but that's another story... > > In a hierarchical system, you can aggregate away more and more > information as you get higher in the hierarchy. However, when a node > moves to another part of the hierarchy, you break aggregation for part > of the tree. The farther the node moves, the more aggregation suffers. > But we can move nodes short distances in the hierarchy without causing > many problems. So if we align our addressing hierarchy with the > possible movements of nodes and/or the other way around, routing-based > and scalable multihoming becomes possible. Hence my proposal for > geographic aggregation. Then, when a site moves from one ISP to another > as the result of a rehoming event, aggregation is still intact from the > closest place where the ISPs interconnect and up. From owner-multi6@ops.ietf.org Sun Mar 30 09:47:17 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27727 for ; Sun, 30 Mar 2003 09:47:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ze4R-0004nX-00 for multi6-data@psg.com; Sun, 30 Mar 2003 06:46:03 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18ze4O-0004lx-00 for multi6@ops.ietf.org; Sun, 30 Mar 2003 06:46:00 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2UEjvr26037 for ; Sun, 30 Mar 2003 17:45:57 +0300 Date: Sun, 30 Mar 2003 17:45:56 +0300 (EEST) From: Pekka Savola To: multi6@ops.ietf.org Subject: Re: plug: thesis on site multihoming In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-18.7 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,USER_AGENT_PINE autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk An update, 1) yes, the thesis _is_ in English ;-) 2) the files have been updated slightly, mainly editorial updates but I've also added the abstract and some other relatively minor changes. For the curious, the abstract is below. Thanks for interest. ====== Site multihoming means end-sites connecting to multiple separate network service providers; currently, no IPv6 site multihoming mechanism has been widely accepted yet. This thesis studies both IPv4 and IPv6 site multihoming mechanisms using literature, other similar studies, analysis of route advertisements at the Finnish exchange point FICIX, and queries on multihoming practices to major ISPs in Finland. Currently in IPv4, there seem to be three-four main mechanisms which are used to achieve at least some of the multihoming benefits: obtaining own address space and AS number and advertising those, advertising more specific routes with different path, using multi-connecting and leveraging NAT. In IPv6, the first two of IPv4 mechanisms which are considered architecturally unscalable have been operationally prevented for now and the fourth does not exist. Based on a tentative roadmap introduced in this thesis, organizations are split to four categories: minimal, small, large and international; each have different multihoming requirements which can be met in different ways. Focusing on immediate and short term solutions, minimal organizations do not seem to require a solution, small ones could use multi-connecting, host-centric multihoming or multihoming at site exit routers approaches, large ones the same or possibly separate provider independent address allocations, and international ones either provider independent allocations or be broken down to multiple large organizations and using those techniques. It is apparent that only a limited amount of work is needed to enable sufficiently good multihoming mechanisms which should provide the required features. However, as the mechanisms are unarguably more difficult for the end-site, while taking the global Internet routing architecture better into the account, it is unclear whether they might be adopted. ====== On Fri, 28 Mar 2003, Pekka Savola wrote: > Hi, > > Sorry for a plug, but it seems relevant and may be interesting for lots of > people. > > I'm about to submit a MSc thesis on the subject of "Examining Site > Multihoming in Finnish Networks", first looking at IPv4 and then IPv6. > > If you're interested, it's available at: > > http://staff.csc.fi/psavola/di.ps (.pdf is also there but quality is > worse) > > There's some minor work to be done still (like writing the abstract, > making a few pictures clearer and actually reading it properly myself ;-), > but it should pretty close to done (submitting for review in the beginning > of next week, making small modifications up until about 2 weeks from now). > > Even if you don't have the time, I intend to split off a modified section > (likely based on sections 6.1 and 6.2) and submit it as an I-D in a week > or two. By breaking down the sites by a few different types and looking > at which multihoming requirements they have, we seem to be able to solve > almost all problems at least to some extent quite nicely. Of course, with > long term, things can be improved a lot. > > Comments etc. are of course really appreciated; off-list is probably best > at least for the most of them. > > In another w.g. I made a joke about most thesis's being non-relevant and > useless (for the IETF). Hopefully this doesn't fall into that category > :-). > > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Sun Mar 30 11:16:57 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00309 for ; Sun, 30 Mar 2003 11:16:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18zfVd-0008pl-00 for multi6-data@psg.com; Sun, 30 Mar 2003 08:18:13 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18zfVb-0008pZ-00 for multi6@ops.ietf.org; Sun, 30 Mar 2003 08:18:11 -0800 Received: from muada.com (sunflower.muada.com [213.156.3.171]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2UGH9b19633; Sun, 30 Mar 2003 18:17:09 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sun, 30 Mar 2003 18:16:54 +0200 Subject: Re: plug: thesis on site multihoming Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: multi6@ops.ietf.org To: Pekka Savola From: Iljitsch van Beijnum In-Reply-To: Message-Id: <05A07AFE-62CB-11D7-A2C0-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On zondag, maa 30, 2003, at 16:45 Europe/Amsterdam, Pekka Savola wrote: > 1) yes, the thesis _is_ in English ;-) > 2) the files have been updated slightly, mainly editorial updates but > I've > also added the abstract and some other relatively minor changes. 3) It's 97 pages. Do they pay you by the word? :-) I'm afraid that my geo proposal has again been mangled beyond recognition. Let me say it once more: NOBODY announces the aggregates (except maybe to customers). They are local to each ISP network, hence the "provider-internal aggregation" part. (The draft is going to expire soon, but it will remain available at http://www.muada.com/drafts/draft-van-beijnum-multi6-isp-int-aggr- 00.txt ) Iljitsch BTW, what makes the PDF look so ugly?? From owner-multi6@ops.ietf.org Sun Mar 30 11:21:42 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00425 for ; Sun, 30 Mar 2003 11:21:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18zfb4-00096O-00 for multi6-data@psg.com; Sun, 30 Mar 2003 08:23:50 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18zfb2-00096C-00 for multi6@ops.ietf.org; Sun, 30 Mar 2003 08:23:48 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2UGNi226611; Sun, 30 Mar 2003 19:23:44 +0300 Date: Sun, 30 Mar 2003 19:23:44 +0300 (EEST) From: Pekka Savola To: Iljitsch van Beijnum cc: multi6@ops.ietf.org Subject: Re: plug: thesis on site multihoming In-Reply-To: <05A07AFE-62CB-11D7-A2C0-00039388672E@muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sun, 30 Mar 2003, Iljitsch van Beijnum wrote: > On zondag, maa 30, 2003, at 16:45 Europe/Amsterdam, Pekka Savola wrote: > > > 1) yes, the thesis _is_ in English ;-) > > > 2) the files have been updated slightly, mainly editorial updates but > > I've > > also added the abstract and some other relatively minor changes. > > 3) It's 97 pages. Do they pay you by the word? :-) Nope, and even then I had to leave stuff out .. when you can't expect the readers to be aware of anything related to multihoming, things will get noisy. > I'm afraid that my geo proposal has again been mangled beyond > recognition. Let me say it once more: NOBODY announces the aggregates > (except maybe to customers). They are local to each ISP network, hence > the "provider-internal aggregation" part. And as I've said before, I fail to see how it actually solves the relevant multihoming problem then :-). Clearly this seems to be somethng that needs to be said more clearly.. Having geographical addresses that are specific to an ISP is a complete non-solution, we aren't worried about the scalability of provider-internal geo more specifics... > BTW, what makes the PDF look so ugly?? The use of fonts which are not included by default in PDF. I'd have to put that through Adobe Distiller or do some tricks, which I didn't bother yet. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Sun Mar 30 11:36:46 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00593 for ; Sun, 30 Mar 2003 11:36:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18zfpe-0009oG-00 for multi6-data@psg.com; Sun, 30 Mar 2003 08:38:54 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18zfpZ-0009o2-00 for multi6@ops.ietf.org; Sun, 30 Mar 2003 08:38:50 -0800 Received: from muada.com (sunflower.muada.com [213.156.3.171]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2UGblb19689; Sun, 30 Mar 2003 18:37:48 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sun, 30 Mar 2003 18:37:32 +0200 Subject: Re: plug: thesis on site multihoming Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: multi6@ops.ietf.org To: Pekka Savola From: Iljitsch van Beijnum In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On zondag, maa 30, 2003, at 18:23 Europe/Amsterdam, Pekka Savola wrote: >> I'm afraid that my geo proposal has again been mangled beyond >> recognition. Let me say it once more: NOBODY announces the aggregates >> (except maybe to customers). They are local to each ISP network, hence >> the "provider-internal aggregation" part. > And as I've said before, I fail to see how it actually solves the > relevant > multihoming problem then :-). Clearly this seems to be somethng that > needs to be said more clearly.. Having geographical addresses that are > specific to an ISP is a complete non-solution, You don't say. "To make multihoming (as we know it today) possible, individual routes must be present in the global routing table. But in order to fit the routing table into a router, there must be aggregation. These requirements seem at odds with each other. This is because there is an unspoken assumption: the full global routing table must be present in all routers that are part of the default-free zone. Dropping this requirement makes everything much more complex, but it is possible. The global routing table can then be split into several parts, where individual routers all handle one (or a few) of those parts. This works as long as traffic for a certain subset of the destination networks present in the global routing table is always sent to a router containing that part of the global routing table. The obvious way to accomplish this is for each router to announce an aggregate covering the part of the global routing table it serves. For instance, if a network has four routers and wants to divide routing information for the IPv6 global unicast address space over those routers, it could have router A handle 2000::/5, router B 2800::/5, router C 3000::/5 and router D 3800::/5. So if this network peers with another network that announces 2200:abc::/35 and 3ffe:def::/35, all routers except router A filter out the first route, and all routers except router D filter out the second route. When router C then has a packet for 2200:abc:1:2::1, it sends the packet to router A (because router A announces the 2000::/5 aggregate) and router A delivers the packet to the right peer. Note that this behavior is completely hidden from the peer: the aggregates are only used within the local network, they are not announced to peers. To avoid confusion with regular provider aggregatable routes, the term "pilot routes" will be used for this type of private aggregates." From owner-multi6@ops.ietf.org Sun Mar 30 11:49:41 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00819 for ; Sun, 30 Mar 2003 11:49:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18zg1j-000AU5-00 for multi6-data@psg.com; Sun, 30 Mar 2003 08:51:23 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18zg1h-000ATs-00 for multi6@ops.ietf.org; Sun, 30 Mar 2003 08:51:21 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2UGpIf26800; Sun, 30 Mar 2003 19:51:18 +0300 Date: Sun, 30 Mar 2003 19:51:17 +0300 (EEST) From: Pekka Savola To: Iljitsch van Beijnum cc: multi6@ops.ietf.org Subject: provider-int geo aggr [Re: plug: thesis on site multihoming] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sun, 30 Mar 2003, Iljitsch van Beijnum wrote: > "To make multihoming (as we know it today) possible, individual routes > must be present in the global routing table. But in order to fit the > routing table into a router, there must be aggregation. These > requirements seem at odds with each other. This is because there is an > unspoken assumption: the full global routing table must be present in > all routers that are part of the default-free zone. Dropping this > requirement makes everything much more complex, but it is possible. The > global routing table can then be split into several parts, where > individual routers all handle one (or a few) of those parts. All routers inside an ISP certainly don't need to have full routing table, but if *one* or those with external connections to DFZ don't, you might end up in problems. If you want to remove full routing table from an AS that's in routing table -- well, that may be doable to an extent, but I'm not sure how it helps, and that's not explicitly stated. On the other hand, if you want to reduce the number of routes in the full routing table inside your AS, that's a non-goal. > This works as long as traffic for a certain subset of the destination > networks present in the global routing table is always sent to a router > containing that part of the global routing table. The obvious way to > accomplish this is for each router to announce an aggregate covering the > part of the global routing table it serves. For instance, if a network > has four routers and wants to divide routing information for the IPv6 > global unicast address space over those routers, it could have router A > handle 2000::/5, router B 2800::/5, router C 3000::/5 and router D > 3800::/5. So if this network peers with another network that announces > 2200:abc::/35 and 3ffe:def::/35, all routers except router A filter out > the first route, and all routers except router D filter out the second > route. When router C then has a packet for 2200:abc:1:2::1, it sends the > packet to router A (because router A announces the 2000::/5 aggregate) > and router A delivers the packet to the right peer. Note that this > behavior is completely hidden from the peer: the aggregates are only > used within the local network, they are not announced to peers. To avoid > confusion with regular provider aggregatable routes, the term "pilot > routes" will be used for this type of private aggregates." A,B,C,D are part of one AS. If you try to expand that so that they aren't, you get into trouble. In the same way, if you don't expand it, you are just solving the provider-internal problem -- and are requiring the propagation of more specifics in DFZ. Could you work out an example of AS's rather than routers? It seems to me that there's some huge confusion somewhere. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Sun Mar 30 12:14:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01108 for ; Sun, 30 Mar 2003 12:14:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18zgQY-000Bd0-00 for multi6-data@psg.com; Sun, 30 Mar 2003 09:17:02 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18zgQW-000BbQ-00 for multi6@ops.ietf.org; Sun, 30 Mar 2003 09:17:00 -0800 Received: from muada.com (sunflower.muada.com [213.156.3.171]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2UHFwb19762; Sun, 30 Mar 2003 19:15:58 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sun, 30 Mar 2003 19:15:43 +0200 Subject: Re: provider-int geo aggr [Re: plug: thesis on site multihoming] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: multi6@ops.ietf.org To: Pekka Savola From: Iljitsch van Beijnum In-Reply-To: Message-Id: <3D3BB28C-62D3-11D7-A2C0-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On zondag, maa 30, 2003, at 18:51 Europe/Amsterdam, Pekka Savola wrote: >> if a network >> has four routers and wants to divide routing information for the IPv6 >> global unicast address space over those routers, it could have router >> A >> handle 2000::/5, router B 2800::/5, router C 3000::/5 and router D >> 3800::/5. So if this network peers with another network that announces >> 2200:abc::/35 and 3ffe:def::/35, all routers except router A filter >> out >> the first route, and all routers except router D filter out the second >> route. When router C then has a packet for 2200:abc:1:2::1, it sends >> the >> packet to router A (because router A announces the 2000::/5 aggregate) >> and router A delivers the packet to the right peer. > A,B,C,D are part of one AS. If you try to expand that so that they > aren't, you get into trouble. And that's exactly the point: we aggregate inside provider networks. > In the same way, if you don't expand it, > you are just solving the provider-internal problem -- and are requiring > the propagation of more specifics in DFZ. Yes. But since no single router has to keep a copy of the entire DFZ routing table, this is no longer a problem. It all boils down to the question: why would someone in Europe need more specifics for people in the US, or vice versa? From owner-multi6@ops.ietf.org Sun Mar 30 12:35:43 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01394 for ; Sun, 30 Mar 2003 12:35:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18zgk5-000Caj-00 for multi6-data@psg.com; Sun, 30 Mar 2003 09:37:13 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18zgk3-000CaW-00 for multi6@ops.ietf.org; Sun, 30 Mar 2003 09:37:11 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2UHb8R27141; Sun, 30 Mar 2003 20:37:08 +0300 Date: Sun, 30 Mar 2003 20:37:07 +0300 (EEST) From: Pekka Savola To: Iljitsch van Beijnum cc: multi6@ops.ietf.org Subject: Re: provider-int geo aggr [Re: plug: thesis on site multihoming] In-Reply-To: <3D3BB28C-62D3-11D7-A2C0-00039388672E@muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-31.7 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sun, 30 Mar 2003, Iljitsch van Beijnum wrote: > > A,B,C,D are part of one AS. If you try to expand that so that they > > aren't, you get into trouble. > > And that's exactly the point: we aggregate inside provider networks. > > > In the same way, if you don't expand it, > > you are just solving the provider-internal problem -- and are requiring > > the propagation of more specifics in DFZ. > > Yes. But since no single router has to keep a copy of the entire DFZ > routing table, this is no longer a problem. Ok -- now I think I understand the concept. If the max number of routes a router implementation can handle is N and more-or-less-complete routing table (non-existant but as a concept) would be Y (>N), you require that each ISP would have at least Y/N (rounded up) routers each connected separately to the Internet -- that, between operators you'd have at least Y/N (rounded up) interconnections if you wish to have optimal paths, etc. Forgive me saying this, but this kind of model which requires a lack of aggregates in the core, and sets requirements for ISPs' border routers just doesn't seem to fly. My argument as an operator is that unless you can divide & conquer the the full routing table to such proportions that it can't be uniform in one AS, there's something very broken in the design of the internet routing architecture, or the definition of the AS. Certainly, the basic concepts of how these different routers with partial knowledge interact with peers' and upstreams' routers of partial knowledge seems quite fuzzy .. and this is one thing that seems critical to have clarified (some pictures might be illustrative). But as this seems a different proposal than Tony's, I'll remove the reference. > It all boils down to the question: why would someone in Europe need > more specifics for people in the US, or vice versa? Depends on the level of interconnection and how the routes are set up, there. Currently, there is no abstraction, so it's difficult to estimate.. But if there was, people would probably very much like *their* pretty little route going through optimal paths and being in the full routing table of all the routers. I haven't really been able to form a picture in my head how the proposal would have to be practically enabled for example through a path from an European ISP to U.S. ISP, in between having or maybe not having transits and ISP's which may or may not honor this model. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Sun Mar 30 14:13:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02745 for ; Sun, 30 Mar 2003 14:13:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ziG2-000Hi6-00 for multi6-data@psg.com; Sun, 30 Mar 2003 11:14:18 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18ziFy-000Hht-00 for multi6@ops.ietf.org; Sun, 30 Mar 2003 11:14:14 -0800 Received: from muada.com (sunflower.muada.com [213.156.3.171]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2UJDBb19923; Sun, 30 Mar 2003 21:13:11 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sun, 30 Mar 2003 21:12:56 +0200 Subject: Re: provider-int geo aggr [Re: plug: thesis on site multihoming] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: multi6@ops.ietf.org To: Pekka Savola From: Iljitsch van Beijnum In-Reply-To: Message-Id: <9D539028-62E3-11D7-A2C0-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On zondag, maa 30, 2003, at 19:37 Europe/Amsterdam, Pekka Savola wrote: > If the max number of routes a router implementation can handle is N and > more-or-less-complete routing table (non-existant but as a concept) > would > be Y (>N), you require that each ISP would have at least Y/N (rounded > up) > routers each connected separately Yes. > to the Internet Each separately connected to peers. If they are "connected to the internet" that would be a default route which you can have in just one location if you want. > -- that, between > operators you'd have at least Y/N (rounded up) interconnections if you > wish to have optimal paths, etc. Yes. So it doesn't scale forever but one order of magnitude is no problem at all and a second one (20 or so interconnects per continent) should be doable. > Forgive me saying this, but this kind of model which requires a lack of > aggregates in the core, and sets requirements for ISPs' border routers > just doesn't seem to fly. Why not? > My argument as an operator is that unless you can divide & conquer the > the > full routing table to such proportions that it can't be uniform in one > AS, > there's something very broken in the design of the internet routing > architecture I'm not entirely sure what you're saying. Is it "if you can't hold the entire DFZ in a single router your architecture is broken"? That's one view. I'd say it's the other way around: if your architecture requires you to keep information about the entire world in all routers, you've painted yourself into a corner. Forget current practices for a moment. Doesn't it make sense to keep detailed information about local stuff and not so detailed information about what happens farther away? > Certainly, the basic concepts of how these different routers with > partial > knowledge interact with peers' and upstreams' routers of partial > knowledge > seems quite fuzzy .. and this is one thing that seems critical to have > clarified (some pictures might be illustrative). I'm considering an update to the draft, but as far as I can tell everything is in there. > But as this seems a different proposal than Tony's, I'll remove the > reference. Actually Tony's draft is just an addressing scheme which doesn't automatically solve routing. My geo proposal could use Tony's addressing scheme. (But Michel and me have written a draft of our own for this, you can find it under "GAPI".) >> It all boils down to the question: why would someone in Europe need >> more specifics for people in the US, or vice versa? > Depends on the level of interconnection and how the routes are set up, > there. Fortunately, the days of transatlantic routing between two places in Europe are long gone. In other parts of the world this still happens, but I believe this will sort itself out for the most part before multihoming in those places becomes so popular the multihomed prefixes must be aggregated. > Currently, there is no abstraction, so it's difficult to estimate.. > But > if there was, people would probably very much like *their* pretty > little > route going through optimal paths and being in the full routing table > of > all the routers. If someone in Asia wants to connect through European ISPs, that's their problem. I did some messing around with BGP yesterday. 4000 routes are responsible for 60% of all our traffic, 6000 routes for another 25%. So that means I can have optimal routing for 85% of all traffic with just 10% of all routes. That's good enough for me. > I haven't really been able to form a picture in my head how the > proposal > would have to be practically enabled for example through a path from an > European ISP to U.S. ISP, in between having or maybe not having > transits > and ISP's which may or may not honor this model. Cooperation from other ISPs is not needed: everyone can implement or not implement this as desired, just as long as the RIRs give out the addresses based on geography. From owner-multi6@ops.ietf.org Sun Mar 30 14:38:24 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02990 for ; Sun, 30 Mar 2003 14:38:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18zifQ-000J9W-00 for multi6-data@psg.com; Sun, 30 Mar 2003 11:40:32 -0800 Received: from [2001:670:86:3001::1] (helo=netcore.fi ident=root) by psg.com with esmtp (Exim 3.36 #1) id 18zifN-000J9J-00 for multi6@ops.ietf.org; Sun, 30 Mar 2003 11:40:29 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2UJePX28050; Sun, 30 Mar 2003 22:40:25 +0300 Date: Sun, 30 Mar 2003 22:40:25 +0300 (EEST) From: Pekka Savola To: Iljitsch van Beijnum cc: multi6@ops.ietf.org Subject: Re: provider-int geo aggr [Re: plug: thesis on site multihoming] In-Reply-To: <9D539028-62E3-11D7-A2C0-00039388672E@muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-32.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sun, 30 Mar 2003, Iljitsch van Beijnum wrote: > > Forgive me saying this, but this kind of model which requires a lack of > > aggregates in the core, and sets requirements for ISPs' border routers > > just doesn't seem to fly. > > Why not? Can you require all of these things from all the folks? But really, the problem is that I'm having hard time (and based on the lack of enthuasiasm from the others, the rest as well) figuring out whether the model could be useful and whether it could actually work. It just doesn't seem to be enough fleshed out to say much other than "ouch! I don't really understand the idea, but it still gives me creeps!". If you want to avoid that feeling, you must warm up the folks properly :-) > > My argument as an operator is that unless you can divide & conquer the > > the > > full routing table to such proportions that it can't be uniform in one > > AS, > > there's something very broken in the design of the internet routing > > architecture > > I'm not entirely sure what you're saying. Is it "if you can't hold the > entire DFZ in a single router your architecture is broken"? That's one > view. If you note, I explicitly did not say that. I said (or tried to, I was not precise), that: "if you can't have the same routing table in all of your routers in a single AS while being part of the DFZ, your architecture or the definition of AS is broken" In your proposal, what is the thing you're worried of? International transits which are part of all the different continents and regions? In the proposal, where are the more specific advertisements hidden? Being advertised between different AS's at peering points but hidden in your that particular peering router by an internally advertised aggregate? > I'd say it's the other way around: if your architecture requires > you to keep information about the entire world in all routers, you've > painted yourself into a corner. I can agree with that (which is the addressing model Tony is proposing with his geo proposal, btw.) -- if it's required, but I'd like to avoid it. > Forget current practices for a moment. Doesn't it make sense to keep > detailed information about local stuff and not so detailed information > about what happens farther away? Yep. .. Whether "geographic" split makes sense is a different thing though. > > Certainly, the basic concepts of how these different routers with > > partial > > knowledge interact with peers' and upstreams' routers of partial > > knowledge > > seems quite fuzzy .. and this is one thing that seems critical to have > > clarified (some pictures might be illustrative). > > I'm considering an update to the draft, but as far as I can tell > everything is in there. Doesn't seem to be particularly unenlightened-friendly.. :-/ > > But as this seems a different proposal than Tony's, I'll remove the > > reference. > > Actually Tony's draft is just an addressing scheme which doesn't > automatically solve routing. I'd be very very careful of any mechanism which claimed would solve routing automatically. > My geo proposal could use Tony's > addressing scheme. (But Michel and me have written a draft of our own > for this, you can find it under "GAPI".) Yep, been through it. > >> It all boils down to the question: why would someone in Europe need > >> more specifics for people in the US, or vice versa? > > > Depends on the level of interconnection and how the routes are set up, > > there. > > Fortunately, the days of transatlantic routing between two places in > Europe are long gone. .. with current topology-derived addressing... > > Currently, there is no abstraction, so it's difficult to estimate.. > > But if there was, people would probably very much like *their* pretty > > little route going through optimal paths and being in the full routing > > table of all the routers. > > If someone in Asia wants to connect through European ISPs, that's their > problem. Well, once the routes hit the dfz, it becomes your problem too. > I did some messing around with BGP yesterday. 4000 routes are > responsible for 60% of all our traffic, 6000 routes for another 25%. So > that means I can have optimal routing for 85% of all traffic with just > 10% of all routes. That's good enough for me. Nice to get some figures, however, I can already hear the 10% yelling quite loudly.. I also made a rough sketch on more specifics (it's in 5.3.1). In an exchange in Finland, 1661 prefixes were advertised some time ago. 50% of them were /24's. Those only covered 1.7% of all the advertised address space though. Interesting figure, eh? I guess it's no wonder that less than 5% of folks eat up at least 75% of the routing table entries. I guess that shows something about routing tables. > > I haven't really been able to form a picture in my head how the > > proposal > > would have to be practically enabled for example through a path from an > > European ISP to U.S. ISP, in between having or maybe not having > > transits > > and ISP's which may or may not honor this model. > > Cooperation from other ISPs is not needed: everyone can implement or > not implement this as desired, just as long as the RIRs give out the > addresses based on geography. Forgive me for sounding skeptic, but I'm not as sure without further analysis that no cooperation would be required. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Mon Mar 31 02:19:36 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27801 for ; Mon, 31 Mar 2003 02:19:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18ztZH-000GEE-00 for multi6-data@psg.com; Sun, 30 Mar 2003 23:18:55 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 18ztZE-000GDz-00 for multi6@ops.ietf.org; Sun, 30 Mar 2003 23:18:52 -0800 Received: from muada.com (sunflower.muada.com [213.156.3.171]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h2V7Hmb21171 for ; Mon, 31 Mar 2003 09:17:49 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Mon, 31 Mar 2003 09:17:33 +0200 Subject: Re: provider-int geo aggr [Re: plug: thesis on site multihoming] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Iljitsch van Beijnum To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.551) X-Spam-Status: No, hits=-29.1 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_APPLEMAIL autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On zondag, maa 30, 2003, at 21:40 Europe/Amsterdam, Pekka Savola wrote: > But really, the problem is that I'm having hard time (and based on the > lack of enthuasiasm from the others, the rest as well) figuring out > whether the model could be useful and whether it could actually work. It allows around ten million multihomed networks, so that answers the useful part. Nobody has ever pointed out any aspect that presumably wouldn't work (just stuff they aren't real comfortable with) so either I am as smart as I think or nobody wants to take the time to carefully read the draft. > It just doesn't seem to be enough fleshed out to say much other than > "ouch! I don't really understand the idea, but it still gives me > creeps!". What's so hard to understand??? In the US you create an aggregate route for the US address block and you accept /48s for US destinations. In Europe, you create an aggregate for the European address block and accept /48s for European destinations. So when you have a packet in the US that needs to go to a European destination, you don't have a /48 route so the packet is routed to Europe by means of the aggregate. In Europe, the packet is routed further as per the /48 that is in the routing tables of European routers. Rinse, repeat. > If you want to avoid that feeling, you must warm up the folks properly > :-) So how do I do that? Buy everyone drinks at the IETF meetings? > "if you can't have the same routing table in all of your routers in a > single AS while being part of the DFZ, your architecture or the > definition > of AS is broken" Ok, then OSPF and IS-IS explicitly support broken networks... > In your proposal, what is the thing you're worried of? International > transits which are part of all the different continents and regions? I'm not worried. > In the proposal, where are the more specific advertisements hidden? > Being advertised between different AS's at peering points but hidden in > your that particular peering router by an internally advertised > aggregate? Not sure what you're getting at. >> I'd say it's the other way around: if your architecture requires >> you to keep information about the entire world in all routers, you've >> painted yourself into a corner. > I can agree with that (which is the addressing model Tony is proposing > with his geo proposal, btw.) -- if it's required, but I'd like to avoid > it. But just now you said you wanted to be able to have the same routing info in all routers! You can't have it both ways. >> Forget current practices for a moment. Doesn't it make sense to keep >> detailed information about local stuff and not so detailed information >> about what happens farther away? > Yep. > .. Whether "geographic" split makes sense is a different thing though. If you have a better idea, I'd like to hear it. The trouble with a situation where routers only hold a partial table is that the traffic has to physically move to the place where the routing information is. This is incredibly inefficient, _unless_ the place where the routing information is happens to be in the right direction of where the traffic has to go to anyway. >> I'm considering an update to the draft, but as far as I can tell >> everything is in there. > Doesn't seem to be particularly unenlightened-friendly.. :-/ Tell me what's missing and I'll put it in. >> Actually Tony's draft is just an addressing scheme which doesn't >> automatically solve routing. > I'd be very very careful of any mechanism which claimed would solve > routing automatically. I don't mean solving all routing problems forever, just that Tony's scheme needs additional routing stuff to do something useful. >> If someone in Asia wants to connect through European ISPs, that's >> their >> problem. > Well, once the routes hit the dfz, it becomes your problem too. Not if I filter them out. :-) >> I did some messing around with BGP yesterday. 4000 routes are >> responsible for 60% of all our traffic, 6000 routes for another 25%. >> So >> that means I can have optimal routing for 85% of all traffic with just >> 10% of all routes. That's good enough for me. > Nice to get some figures, however, I can already hear the 10% yelling > quite loudly.. Your milage may vary. If you mainly host websites in the local language this is going to be very different from a situation where you connect the rooms of a big convention hotel. > I also made a rough sketch on more specifics (it's in 5.3.1). In an > exchange in Finland, 1661 prefixes were advertised some time ago. 50% > of > them were /24's. Those only covered 1.7% of all the advertised address > space though. > Interesting figure, eh? I guess it's no wonder that less than 5% of > folks > eat up at least 75% of the routing table entries. I guess that shows > something about routing tables. What really annoys me to no end is the people who announce 10, 20, 100, 200 /20s that could easily be aggregated. Some of the people announcing /24s are doing this for good reasons, but people filter on the /20 boundary and hurt exactly the wrong people. I don't understand why the large networks don't do anything about this. I would simply de-peer. >> Cooperation from other ISPs is not needed: everyone can implement or >> not implement this as desired, just as long as the RIRs give out the >> addresses based on geography. > Forgive me for sounding skeptic, but I'm not as sure without further > analysis that no cooperation would be required. What exactly would another ISP have to do so I can aggregate within my own network??? If I want to accept all routes within 195.0.0.0/8 in Amsterdam, all routes within 196.0.0.0/8 in London and so on, I can do that without cooperation. (I have to deaggregate if I don't peer in London with someone who announces 196.12.34.0/24, though, but that's still something I can do on my own.) From owner-multi6@ops.ietf.org Mon Mar 31 04:56:58 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00549 for ; Mon, 31 Mar 2003 04:56:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18zw3j-000OMi-00 for multi6-data@psg.com; Mon, 31 Mar 2003 01:58:31 -0800 Received: from d12lmsgate-2.de.ibm.com ([194.196.100.235]) by psg.com with esmtp (Exim 3.36 #1) id 18zw3f-000OMN-00 for multi6@ops.ietf.org; Mon, 31 Mar 2003 01:58:27 -0800 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (8.12.8/8.12.8) with ESMTP id h2V9wL33096558 for ; Mon, 31 Mar 2003 11:58:21 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h2V9wLNt257432 for ; Mon, 31 Mar 2003 11:58:21 +0200 Received: from dhcp21-82.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA59080 from ; Mon, 31 Mar 2003 11:58:20 +0200 Message-Id: <3E8810F9.31CDC089@hursley.ibm.com> Date: Mon, 31 Mar 2003 11:57:13 +0200 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: multi6@ops.ietf.org Subject: Re: provider-int geo aggr [Re: plug: thesis on site multihoming] References: <9D539028-62E3-11D7-A2C0-00039388672E@muada.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-29.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: ... > > >> It all boils down to the question: why would someone in Europe need > >> more specifics for people in the US, or vice versa? Because of money, policy, and AUPs, traditionally. I doubt if this will go away, but it shouldn't be visible outside the sites concerned. Brian From owner-multi6@ops.ietf.org Mon Mar 31 05:50:23 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01356 for ; Mon, 31 Mar 2003 05:50:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 18zwtd-0000UN-00 for multi6-data@psg.com; Mon, 31 Mar 2003 02:52:09 -0800 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by psg.com with esmtp (Exim 3.36 #1) id 18zwta-0000Tw-00 for multi6@ops.ietf.org; Mon, 31 Mar 2003 02:52:06 -0800 Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id LAA19275 for ; Mon, 31 Mar 2003 11:52:04 +0100 (BST) Received: from login.ecs.soton.ac.uk (login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3p2/8.9.3) with ESMTP id LAA26438 for ; Mon, 31 Mar 2003 11:52:04 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h2VAq4O07261 for multi6@ops.ietf.org; Mon, 31 Mar 2003 11:52:04 +0100 Date: Mon, 31 Mar 2003 11:52:04 +0100 From: Tim Chown To: multi6@ops.ietf.org Subject: Re: provider-int geo aggr [Re: plug: thesis on site multihoming] Message-ID: <20030331105204.GB6426@login.ecs.soton.ac.uk> Mail-Followup-To: multi6@ops.ietf.org References: <9D539028-62E3-11D7-A2C0-00039388672E@muada.com> <3E8810F9.31CDC089@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E8810F9.31CDC089@hursley.ibm.com> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-38.0 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, Mar 31, 2003 at 11:57:13AM +0200, Brian E Carpenter wrote: > Iljitsch van Beijnum wrote: > > ... > > > > >> It all boils down to the question: why would someone in Europe need > > >> more specifics for people in the US, or vice versa? > > Because of money, policy, and AUPs, traditionally. I doubt if this will > go away, but it shouldn't be visible outside the sites concerned. As a real example happening now(ish): In the context of IPv6 experiments between Abliene and 6NET, we would wish to have some experiments run over 6NET infrastructure and 6NET partner (native) links to Abilene, while regular production IPv6 traffic goes via GEANT (via its imminently native link to Abilene). Thus we would advertise a specific /64 (where the test equipment resides) to Abilene via the 6NET partner path, which would not be propogated outside Abilene. So it's a private agreement between two networks which have a private link outside their regular production path. Tim From owner-multi6@ops.ietf.org Mon Mar 31 13:29:19 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18097 for ; Mon, 31 Mar 2003 13:29:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.36 #1) id 1903zg-000OMv-00 for multi6-data@psg.com; Mon, 31 Mar 2003 10:26:52 -0800 Received: from ebola-50.psc.edu ([128.182.50.124] helo=localhost) by psg.com with esmtp (Exim 3.36 #1) id 1903ze-000OMj-00 for multi6@ops.ietf.org; Mon, 31 Mar 2003 10:26:50 -0800 Received: from ebola-50.psc.edu (localhost [127.0.0.1]) by localhost (8.12.7/8.12.2) with ESMTP id h2VIQvv2002553; Mon, 31 Mar 2003 13:26:58 -0500 (EST) Date: Mon, 31 Mar 2003 13:26:53 -0500 From: "Michael H. Lambert" To: Iljitsch van Beijnum cc: multi6@ops.ietf.org Subject: Re: provider-int geo aggr [Re: plug: thesis on site multihoming] Message-ID: <7082477.1049117213@ebola-50.psc.edu> X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=-9.8 required=5.0 tests=BAYES_01,QUOTED_EMAIL_TEXT autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch, --On Monday, 31 March 2003 09:17 +0200 Iljitsch van Beijnum wrote: > What's so hard to understand??? In the US you create an aggregate route > for the US address block and you accept /48s for US destinations. In > Europe, you create an aggregate for the European address block and accept > /48s for European destinations. So when you have a packet in the US that > needs to go to a European destination, you don't have a /48 route so the > packet is routed to Europe by means of the aggregate. In Europe, the > packet is routed further as per the /48 that is in the routing tables of > European routers. Rinse, repeat. Do you think it reasonable to have (at least) two DFZs--one using PA addresses and the other using PI addresses? Presumably, there would be a large number of interconnects between the DFZs. Even if there are known problems in multihoming with PA addresses, I think there is too large a base to get rid of them. Michael