From owner-multi6@ops.ietf.org Mon Jul 1 12:48:07 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17881 for ; Mon, 1 Jul 2002 12:48:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17P4JS-000Dpx-00 for multi6-data@psg.com; Mon, 01 Jul 2002 09:46:06 -0700 Received: from lucy.automagic.org ([204.152.186.102]) by psg.com with smtp (Exim 3.36 #1) id 17P4IT-000Dej-00 for multi6@ops.ietf.org; Mon, 01 Jul 2002 09:45:08 -0700 Received: (qmail 16055 invoked by uid 0); 1 Jul 2002 16:45:04 -0000 Received: from unknown (HELO hyperion) (127.0.0.1) by 0 with SMTP; 1 Jul 2002 16:45:04 -0000 Date: Mon, 1 Jul 2002 12:45:08 -0400 Subject: Re: draft-ietf-multi6-multihoming-requirements-03 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) From: Joe Abley To: multi6@ops.ietf.org Content-Transfer-Encoding: 7bit In-Reply-To: <4D6AEC77-893F-11D6-8825-00039312C852@automagic.org> Message-Id: X-Mailer: Apple Mail (2.482) X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, June 26, 2002, at 04:00 , Joe Abley wrote: > On Wednesday, June 26, 2002, at 03:29 , Tony Hain wrote: > >> While I believe this document still assumes too much in terms of >> affecting policy outside the domain of direct administrative control, I >> have to agree it is time to ship it. There is one comment about the >> IESG >> in 3.2.7 that simply doesn't belong in any I-D, so I wouldn't be >> surprised when the IESG asks to have it changed or removed. If the >> words >> 'within the IESG' were removed, the sentence would stand and makes much >> more sense than worrying about IETF process in a mechanism requirements >> doc. > > I have made that change in my working copy. Does anybody have any other proposed changes to this document, or should I roll a -04 with that change only, ready for wg last call? Joe From owner-multi6@ops.ietf.org Mon Jul 1 14:04:22 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22833 for ; Mon, 1 Jul 2002 14:04:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17P5Wg-000L7H-00 for multi6-data@psg.com; Mon, 01 Jul 2002 11:03:50 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 17P5Wb-000L4p-00 for multi6@ops.ietf.org; Mon, 01 Jul 2002 11:03:45 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g61I43X66495; Mon, 1 Jul 2002 20:04:03 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Mon, 1 Jul 2002 20:04:03 +0200 (CEST) From: Iljitsch van Beijnum To: Joe Abley cc: Subject: Re: draft-ietf-multi6-multihoming-requirements-03 In-Reply-To: Message-ID: <20020701195634.X66288-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-5.3 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT version=2.30 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 1 Jul 2002, Joe Abley wrote: > >> If the words > >> 'within the IESG' were removed, the sentence would stand and makes much > >> more sense than worrying about IETF process in a mechanism requirements > >> doc. > Does anybody have any other proposed changes to this document, or should > I roll a -04 with that change only, ready for wg last call? There seems to be a discrepancy between the requirements listed in the draft and the fact that everyone assumes there won't be a solution that can meet all of them. I'm afraid this opens up the possibility of problems down the road when people can easily dismiss otherwise promising multihoming solutions by pointing out it doesn't meet one or more requirements. Some text indicating which requirements are absolutely essential and which are also important, but can be dropped if there aren't any multihoming solutions that satisfy them would be good, I think. On the other hand: I certainly don't want to slow down the whole process. Iljitsch van Beijnum From owner-multi6@ops.ietf.org Mon Jul 1 14:04:43 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22881 for ; Mon, 1 Jul 2002 14:04:41 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17P5Y7-000LEB-00 for multi6-data@psg.com; Mon, 01 Jul 2002 11:05:19 -0700 Received: from lucy.automagic.org ([204.152.186.102]) by psg.com with smtp (Exim 3.36 #1) id 17P5Y3-000LDz-00 for multi6@ops.ietf.org; Mon, 01 Jul 2002 11:05:15 -0700 Received: (qmail 16225 invoked by uid 0); 1 Jul 2002 18:05:15 -0000 Received: from unknown (HELO hyperion) (127.0.0.1) by 0 with SMTP; 1 Jul 2002 18:05:15 -0000 Date: Mon, 1 Jul 2002 14:05:19 -0400 Subject: Re: draft-ietf-multi6-multihoming-requirements-03 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: To: Iljitsch van Beijnum From: Joe Abley In-Reply-To: <20020701195634.X66288-100000@sequoia.muada.com> Message-Id: <1A6AF343-8D1D-11D6-A05F-00039312C852@automagic.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Monday, July 1, 2002, at 02:04 , Iljitsch van Beijnum wrote: > Some text indicating which requirements are absolutely essential and > which > are also important, but can be dropped if there aren't any multihoming > solutions that satisfy them would be good, I think. Do you have such text to incorporate? > On the other hand: I certainly don't want to slow down the whole > process. Joe From owner-multi6@ops.ietf.org Mon Jul 1 14:05:48 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22977 for ; Mon, 1 Jul 2002 14:05:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17P5Z7-000LKK-00 for multi6-data@psg.com; Mon, 01 Jul 2002 11:06:21 -0700 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 17P5Z3-000LK8-00 for multi6@ops.ietf.org; Mon, 01 Jul 2002 11:06:17 -0700 From: Masataka Ohta Message-Id: <200207011753.CAA00663@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id CAA00663; Tue, 2 Jul 2002 02:53:24 +0900 Subject: Re: draft-ietf-multi6-multihoming-requirements-03 In-Reply-To: from Joe Abley at "Jul 1, 2002 12:45:08 pm" To: Joe Abley Date: Tue, 2 Jul 2002 02:53:23 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2 version=2.30 Sender: owner-multi6@ops.ietf.org Precedence: bulk Joe Abley; > Does anybody have any other proposed changes to this document, or should > I roll a -04 with that change only, ready for wg last call? Can't we simply admit the fact that none of us have any operational experience to be able to discuss multi6 requirement document to be used later to evaluate proposals and move on without it? Masataka Ohta From owner-multi6@ops.ietf.org Mon Jul 1 14:06:18 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23002 for ; Mon, 1 Jul 2002 14:06:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17P5Zj-000LQN-00 for multi6-data@psg.com; Mon, 01 Jul 2002 11:06:59 -0700 Received: from lucy.automagic.org ([204.152.186.102]) by psg.com with smtp (Exim 3.36 #1) id 17P5Zf-000LQB-00 for multi6@ops.ietf.org; Mon, 01 Jul 2002 11:06:55 -0700 Received: (qmail 16236 invoked by uid 0); 1 Jul 2002 18:06:54 -0000 Received: from unknown (HELO hyperion) (127.0.0.1) by 0 with SMTP; 1 Jul 2002 18:06:54 -0000 Date: Mon, 1 Jul 2002 14:06:58 -0400 Subject: Re: draft-ietf-multi6-multihoming-requirements-03 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: multi6@ops.ietf.org To: Masataka Ohta From: Joe Abley In-Reply-To: <200207011753.CAA00663@necom830.hpcl.titech.ac.jp> Message-Id: <55BA512E-8D1D-11D6-A05F-00039312C852@automagic.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Monday, July 1, 2002, at 01:54 , Masataka Ohta wrote: > Joe Abley; > >> Does anybody have any other proposed changes to this document, or >> should >> I roll a -04 with that change only, ready for wg last call? > > Can't we simply admit the fact that none of us have any operational > experience to be able to discuss multi6 requirement document > to be used later to evaluate proposals and move on without it? Are you suggesting there are no network operators here? From owner-multi6@ops.ietf.org Mon Jul 1 14:23:19 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24022 for ; Mon, 1 Jul 2002 14:23:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17P5pw-000MyV-00 for multi6-data@psg.com; Mon, 01 Jul 2002 11:23:44 -0700 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 17P5ps-000My4-00 for multi6@ops.ietf.org; Mon, 01 Jul 2002 11:23:40 -0700 From: Masataka Ohta Message-Id: <200207011808.DAA00782@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id DAA00782; Tue, 2 Jul 2002 03:07:46 +0859 Subject: Re: draft-ietf-multi6-multihoming-requirements-03 In-Reply-To: <55BA512E-8D1D-11D6-A05F-00039312C852@automagic.org> from Joe Abley at "Jul 1, 2002 02:06:58 pm" To: Joe Abley Date: Tue, 2 Jul 2002 03:07:45 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2 version=2.30 Sender: owner-multi6@ops.ietf.org Precedence: bulk Joe Abley; > >> Does anybody have any other proposed changes to this document, or > >> should > >> I roll a -04 with that change only, ready for wg last call? > > > > Can't we simply admit the fact that none of us have any operational > > experience to be able to discuss multi6 requirement document > > to be used later to evaluate proposals and move on without it? > > Are you suggesting there are no network operators here? No, I am not, as I am involved in operation of mobile IPv6 network with more than 150 routers. Masataka Ohta From owner-multi6@ops.ietf.org Mon Jul 1 14:24:58 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24104 for ; Mon, 1 Jul 2002 14:24:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17P5rj-000NGV-00 for multi6-data@psg.com; Mon, 01 Jul 2002 11:25:35 -0700 Received: from lucy.automagic.org ([204.152.186.102]) by psg.com with smtp (Exim 3.36 #1) id 17P5rf-000NGI-00 for multi6@ops.ietf.org; Mon, 01 Jul 2002 11:25:31 -0700 Received: (qmail 16333 invoked by uid 0); 1 Jul 2002 18:25:30 -0000 Received: from unknown (HELO hyperion) (127.0.0.1) by 0 with SMTP; 1 Jul 2002 18:25:30 -0000 Date: Mon, 1 Jul 2002 14:25:33 -0400 Subject: Re: draft-ietf-multi6-multihoming-requirements-03 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: multi6@ops.ietf.org To: Masataka Ohta From: Joe Abley In-Reply-To: <200207011808.DAA00782@necom830.hpcl.titech.ac.jp> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Monday, July 1, 2002, at 02:08 , Masataka Ohta wrote: > Joe Abley; > >>>> Does anybody have any other proposed changes to this document, or >>>> should >>>> I roll a -04 with that change only, ready for wg last call? >>> >>> Can't we simply admit the fact that none of us have any operational >>> experience to be able to discuss multi6 requirement document >>> to be used later to evaluate proposals and move on without it? >> >> Are you suggesting there are no network operators here? > > No, I am not, as I am involved in operation of mobile IPv6 network > with more than 150 routers. Ah, I understand the point you were making, then. Sorry for my confusion. Joe From owner-multi6@ops.ietf.org Mon Jul 1 14:32:40 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24491 for ; Mon, 1 Jul 2002 14:32:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17P5z9-000O2M-00 for multi6-data@psg.com; Mon, 01 Jul 2002 11:33:15 -0700 Received: from roxanne.org ([216.243.33.138]) by psg.com with esmtp (Exim 3.36 #1) id 17P5z4-000O27-00 for multi6@ops.ietf.org; Mon, 01 Jul 2002 11:33:10 -0700 Received: (from eric@localhost) by roxanne.org (8.11.0/8.11.0) id g61IX8R09609 for multi6@ops.ietf.org; Mon, 1 Jul 2002 14:33:08 -0400 Date: Mon, 1 Jul 2002 14:33:08 -0400 From: Eric Gauthier To: multi6@ops.ietf.org Subject: Re: draft-ietf-multi6-multihoming-requirements-03 Message-ID: <20020701143308.A9525@roxanne.org> References: <200207011753.CAA00663@necom830.hpcl.titech.ac.jp> <55BA512E-8D1D-11D6-A05F-00039312C852@automagic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <55BA512E-8D1D-11D6-A05F-00039312C852@automagic.org>; from jabley@automagic.org on Mon, Jul 01, 2002 at 02:06:58PM -0400 X-Spam-Status: No, hits=-5.3 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT version=2.30 Sender: owner-multi6@ops.ietf.org Precedence: bulk > >> Does anybody have any other proposed changes to this document, or > >> should > >> I roll a -04 with that change only, ready for wg last call? > > > > Can't we simply admit the fact that none of us have any operational > > experience to be able to discuss multi6 requirement document > > to be used later to evaluate proposals and move on without it? > > Are you suggesting there are no network operators here? Ok, I've been lurking for a while, but here are my $0.02. I'm a network architect at a large university. We're testing IPv6 on our campus and intend to multihome with our pTLA. We currently multihome with our IPv4 address space and had issues that we've solved regarding multihoming, especially in cases of Internet 1 versus Internet 2 traffic. So, just in case anyone is worried, there are people lurking here that do ops and not just people who are curious about the theoretical workings of IPv6. Secondly, IMHO, we've laid out what we think are requirements and there doesn't appear to be anything in there that's unreasonable to hope for and expect. Its now up to the brainiac's in round two to come up with a solution. Just because I can't think of one doesn't mean that someone else won't. But, if it turns out that someone does a proof that our requirements are mutually exclusive or no one is able to come up with a solution, we'll then have the experience of those who tried to work it out to determine what, specifically, is the largest subset of our draft that can be implemented or where we went wrong. Until we get that concrete feedback, we're only guessing at what can and cannot be done. I think we've written our exam question as best we can. Its time to ship it to the students for them to solve and hope/pray that they can... Eric :) From owner-multi6@ops.ietf.org Mon Jul 1 14:53:57 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25784 for ; Mon, 1 Jul 2002 14:53:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17P6JT-00005q-00 for multi6-data@psg.com; Mon, 01 Jul 2002 11:54:15 -0700 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 17P6JQ-00005e-00 for multi6@ops.ietf.org; Mon, 01 Jul 2002 11:54:12 -0700 Received: by ab.use.net (Postfix, from userid 3005) id C27857E2; Mon, 1 Jul 2002 18:54:10 +0000 (GMT) To: jabley@automagic.org, mohta@necom830.hpcl.titech.ac.jp Subject: Re: draft-ietf-multi6-multihoming-requirements-03 Cc: multi6@ops.ietf.org Message-Id: <20020701185410.C27857E2@ab.use.net> Date: Mon, 1 Jul 2002 18:54:10 +0000 (GMT) From: smd@ab.use.net (Sean Doran) X-Spam-Status: No, hits=-1.9 required=5.0 tests=X_NOT_PRESENT version=2.30 Sender: owner-multi6@ops.ietf.org Precedence: bulk | Can't we simply admit the fact that none of us have any operational | experience to be able to discuss multi6 requirement document | to be used later to evaluate proposals and move on without it? I would hope that whatever forum evaluates any proposals from any body dealing with the IPv6 site multihoming problem, that "working code" is weighted at least as heavily as "rough consensus". If you think you have working code that might not survive scrutiny based on the emerging rough consensus over the requirements drafts, *now* is the time to suggest changes. Sean. From owner-multi6@ops.ietf.org Mon Jul 1 14:59:49 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26288 for ; Mon, 1 Jul 2002 14:59:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17P6PU-0000ho-00 for multi6-data@psg.com; Mon, 01 Jul 2002 12:00:28 -0700 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 17P6PQ-0000hT-00 for multi6@ops.ietf.org; Mon, 01 Jul 2002 12:00:24 -0700 Received: by ab.use.net (Postfix, from userid 3005) id 229A97E2; Mon, 1 Jul 2002 19:00:23 +0000 (GMT) To: eric@roxanne.org, multi6@ops.ietf.org Subject: Re: draft-ietf-multi6-multihoming-requirements-03 Message-Id: <20020701190023.229A97E2@ab.use.net> Date: Mon, 1 Jul 2002 19:00:23 +0000 (GMT) From: smd@ab.use.net (Sean Doran) X-Spam-Status: No, hits=-1.9 required=5.0 tests=X_NOT_PRESENT version=2.30 Sender: owner-multi6@ops.ietf.org Precedence: bulk | We're testing IPv6 on our campus and intend to multihome with our pTLA. I (personally speaking) love text that describes actual operational experience when it comes to describing things in the context of the Ops area. I am sure that if you wrote something up and posted it here, the audience would be appreciative, even if it's unclear whether this could be a venue for a formal publishing of some of your experiences as a multi-homed site. Sean. From owner-multi6@ops.ietf.org Mon Jul 1 16:56:57 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02699 for ; Mon, 1 Jul 2002 16:56:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17P8DY-000C2F-00 for multi6-data@psg.com; Mon, 01 Jul 2002 13:56:16 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 17P8DT-000C20-00 for multi6@ops.ietf.org; Mon, 01 Jul 2002 13:56:11 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g61KuRq66827; Mon, 1 Jul 2002 22:56:27 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Mon, 1 Jul 2002 22:56:27 +0200 (CEST) From: Iljitsch van Beijnum To: Sean Doran cc: Subject: Re: draft-ietf-multi6-multihoming-requirements-03 In-Reply-To: <20020701185410.C27857E2@ab.use.net> Message-ID: <20020701224707.O66288-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-5.3 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT version=2.30 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 1 Jul 2002, Sean Doran wrote: > I would hope that whatever forum evaluates any proposals from > any body dealing with the IPv6 site multihoming problem, that > "working code" is weighted at least as heavily as "rough consensus". What about proposals that work without code? From owner-multi6@ops.ietf.org Mon Jul 1 17:07:05 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03216 for ; Mon, 1 Jul 2002 17:07:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17P8OP-000D93-00 for multi6-data@psg.com; Mon, 01 Jul 2002 14:07:29 -0700 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 17P8OL-000D8r-00 for multi6@ops.ietf.org; Mon, 01 Jul 2002 14:07:26 -0700 Received: by ab.use.net (Postfix, from userid 3005) id 217B97F2; Mon, 1 Jul 2002 21:07:25 +0000 (GMT) To: iljitsch@muada.com, smd@ab.use.net Subject: Re: draft-ietf-multi6-multihoming-requirements-03 Cc: multi6@ops.ietf.org Message-Id: <20020701210725.217B97F2@ab.use.net> Date: Mon, 1 Jul 2002 21:07:25 +0000 (GMT) From: smd@ab.use.net (Sean Doran) X-Spam-Status: No, hits=-1.9 required=5.0 tests=X_NOT_PRESENT version=2.30 Sender: owner-multi6@ops.ietf.org Precedence: bulk | On Mon, 1 Jul 2002, Sean Doran wrote: | | > I would hope that whatever forum evaluates any proposals from | > any body dealing with the IPv6 site multihoming problem, that | > "working code" is weighted at least as heavily as "rough consensus". | | What about proposals that work without code? "code" is an abstract shorthand which can be read as "recipe" or anything else used to describe actions to be undertaken by human beings in the process of cooking up a solution. it does not mean actual snippets of C or APL. Sean. From owner-multi6@ops.ietf.org Mon Jul 1 17:40:20 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05267 for ; Mon, 1 Jul 2002 17:40:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17P8uR-000GUF-00 for multi6-data@psg.com; Mon, 01 Jul 2002 14:40:35 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 17P8uJ-000GU3-00 for multi6@ops.ietf.org; Mon, 01 Jul 2002 14:40:27 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g61LekC66888; Mon, 1 Jul 2002 23:40:46 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Mon, 1 Jul 2002 23:40:46 +0200 (CEST) From: Iljitsch van Beijnum To: Joe Abley cc: Subject: Re: draft-ietf-multi6-multihoming-requirements-03 In-Reply-To: <1A6AF343-8D1D-11D6-A05F-00039312C852@automagic.org> Message-ID: <20020701225636.S66288-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-5.3 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT version=2.30 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 1 Jul 2002, Joe Abley wrote: > > Some text indicating which requirements are absolutely essential and > > which > > are also important, but can be dropped if there aren't any multihoming > > solutions that satisfy them would be good, I think. > Do you have such text to incorporate? 3.1 Capabilities of IPv4 Multihoming The following capabilities of current IPv4 multihoming practices MUST be supported by an IPv6 multihoming architecture. IPv4 multihoming is discussed in more detail in [1]. Would be replaced by: 3.1 Capabilities of IPv4 Multihoming The following capabilities of current IPv4 multihoming practices MUST be supported by an IPv6 multihoming architecture to a similar level as current IPv4 multihoming does. None of them is optional, but they can be omitted or only partially supported if an architecture supporting the capability to at least current IPv4 levels is unfeasible or doesn't meet the additional requirements listed in section 3.2. IPv4 multihoming is discussed in more detail in [1]. Then there is: 3.1.4 Policy A customer may choose to multihome for a variety of policy reasons beyond technical scope (e.g. cost, acceptable use conditions, etc.) For example, customer C homed to ISP A may wish to shift traffic of a certain class or application, NNTP, for example, to ISP B as matter of policy. A new IPv6 multihoming proposal MUST provide support for site-multihoming for external policy reasons. I don't think this is the intention, but it _can_ be read as if IPv4 multihoming has the capability to direct traffic for certain applications over one link and traffic for other applications over another link. Since this is certainly not the case, at least the example should go, possibly the whole thing. (Does it require anything useful anyway?) Iljitsch van Beijnum From owner-multi6@ops.ietf.org Mon Jul 1 23:29:03 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15404 for ; Mon, 1 Jul 2002 23:29:02 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17PEKg-0001Hl-00 for multi6-data@psg.com; Mon, 01 Jul 2002 20:28:02 -0700 Received: from felix.automagic.org ([204.152.186.101]) by psg.com with smtp (Exim 3.36 #1) id 17PEKb-0001HT-00 for multi6@ops.ietf.org; Mon, 01 Jul 2002 20:27:58 -0700 Received: (qmail 32263 invoked by uid 0); 2 Jul 2002 03:27:56 -0000 Received: from unknown (HELO hyperion) (127.0.0.1) by 0 with SMTP; 2 Jul 2002 03:27:56 -0000 Date: Mon, 1 Jul 2002 23:27:55 -0400 Subject: Re: draft-ietf-multi6-multihoming-requirements-03 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: To: Iljitsch van Beijnum From: Joe Abley In-Reply-To: <20020701225636.S66288-100000@sequoia.muada.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Monday, July 1, 2002, at 05:40 , Iljitsch van Beijnum wrote: > Then there is: > > 3.1.4 Policy > > A customer may choose to multihome for a variety of policy reasons > beyond technical scope (e.g. cost, acceptable use conditions, etc.) > For example, customer C homed to ISP A may wish to shift traffic of a > certain class or application, NNTP, for example, to ISP B as matter > of policy. A new IPv6 multihoming proposal MUST provide support for > site-multihoming for external policy reasons. > > I don't think this is the intention, but it _can_ be read as if IPv4 > multihoming has the capability to direct traffic for certain > applications > over one link and traffic for other applications over another link. > Since > this is certainly not the case, at least the example should go, possibly > the whole thing. (Does it require anything useful anyway?) The example I have used for this before concerns people who operate networks in places where satellite communications are substantially cheaper than terrestrial communications (this is most of the planet, by area). It is common practice to number news, mail, and HTTP proxy servers (tuned for retrieval of objects over satellite-like latencies) within subnets which can be advertised such that inbound traffic from the rest of the world arrives on those servers via a satellite link, whereas all other traffic (including traffic directly aimed at subscriber addresses) arrives via terrestrial fibre. This crude approach takes the traffic load of asynchronous, latency-tolerant services off the expensive terrestrial fibre, and leaves it (the fibre) for use by more interactive, latency-intolerant traffic. Costs are reduced, performance for customers remains acceptable. Often, satellite bandwidth is bundled by satellite operators with transit. ISPs who buy such satellite transit are very unlikely to use the satellite provider for their terrestrial transit. Being multi-homed in this fashion is common practice today in many parts of the world. I agree that existing IPv4 multihoming practices/CIDR abuse do not inherently provide mechanisms for making routing decisions based on criteria encapsulated *within* IP. However, changing the requirements to specify something else (like segregation of different parts of an address space over different transit circuits) seems to me a bit too much like presupposing a solution. I think the basic requirement should stay. I am not married to the words currently in 3.1.4, however, so if you have better ones I'd be glad to hear them. Joe From owner-multi6@ops.ietf.org Tue Jul 2 04:33:21 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28545 for ; Tue, 2 Jul 2002 04:33:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17PJ4V-000Bik-00 for multi6-data@psg.com; Tue, 02 Jul 2002 01:31:39 -0700 Received: from d12lmsgate-2.de.ibm.com ([195.212.91.200]) by psg.com with esmtp (Exim 3.36 #1) id 17PJ4Q-000BiT-00 for multi6@ops.ietf.org; Tue, 02 Jul 2002 01:31:35 -0700 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.3/8.12.3) with ESMTP id g628VFu9018276; Tue, 2 Jul 2002 10:31:25 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with SMTP id g628VCj129340; Tue, 2 Jul 2002 10:31:13 +0200 Received: from dhcp23-199.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA72298 from ; Tue, 2 Jul 2002 10:30:26 +0200 Message-Id: <3D2164D4.3A558648@hursley.ibm.com> Date: Tue, 02 Jul 2002 10:31:16 +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: Iljitsch van Beijnum Cc: Joe Abley , multi6@ops.ietf.org Subject: Re: draft-ietf-multi6-multihoming-requirements-03 References: <20020701225636.S66288-100000@sequoia.muada.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.30 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > > On Mon, 1 Jul 2002, Joe Abley wrote: > > > > Some text indicating which requirements are absolutely essential and > > > which > > > are also important, but can be dropped if there aren't any multihoming > > > solutions that satisfy them would be good, I think. > > > Do you have such text to incorporate? > > 3.1 Capabilities of IPv4 Multihoming > > The following capabilities of current IPv4 multihoming practices MUST > be supported by an IPv6 multihoming architecture. IPv4 multihoming > is discussed in more detail in [1]. > > Would be replaced by: > > 3.1 Capabilities of IPv4 Multihoming > > The following capabilities of current IPv4 multihoming practices MUST > be supported by an IPv6 multihoming architecture to a similar level as > current IPv4 multihoming does. None of them is optional, but they can > be omitted or only partially supported if an architecture supporting > the capability to at least current IPv4 levels is unfeasible or > doesn't meet the additional requirements listed in section 3.2. > > IPv4 multihoming is discussed in more detail in [1]. I wonder why we are using MUST (upper case) terminology in any case. It isn't the IETF tradition to have strict requirements documents and require mathematical conformance; this whole thing amounts to a strong recommendation, not a standards-track MUST. Also "None of them is optional, but they can be omitted..." makes my head hurt. Why not just change the language in the whole document to must/should (lower case)? (This also answers Masataka's point, I think.) > > Then there is: > > 3.1.4 Policy > > A customer may choose to multihome for a variety of policy reasons > beyond technical scope (e.g. cost, acceptable use conditions, etc.) > For example, customer C homed to ISP A may wish to shift traffic of a > certain class or application, NNTP, for example, to ISP B as matter > of policy. A new IPv6 multihoming proposal MUST provide support for > site-multihoming for external policy reasons. > > I don't think this is the intention, but it _can_ be read as if IPv4 > multihoming has the capability to direct traffic for certain applications > over one link and traffic for other applications over another link. Since > this is certainly not the case, at least the example should go, possibly > the whole thing. (Does it require anything useful anyway?) Yes. Today this sort of policy is generally implemented by fiddling with DNS entries and addresses. Maybe we can do better for IPv6 if we think about it. The example is a valid *requirement* but it should be cited in the IPv6 context. Brian From owner-multi6@ops.ietf.org Tue Jul 2 09:10:16 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07601 for ; Tue, 2 Jul 2002 09:10:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17PNOe-000HRk-00 for multi6-data@psg.com; Tue, 02 Jul 2002 06:08:44 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 17PNOT-000HRY-00 for multi6@ops.ietf.org; Tue, 02 Jul 2002 06:08:33 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g62D8pV68313; Tue, 2 Jul 2002 15:08:51 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 2 Jul 2002 15:08:51 +0200 (CEST) From: Iljitsch van Beijnum To: Joe Abley cc: Subject: Re: draft-ietf-multi6-multihoming-requirements-03 In-Reply-To: Message-ID: <20020702145758.P68223-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-5.3 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT version=2.30 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 1 Jul 2002, Joe Abley wrote: > The example I have used for this before concerns people who operate > networks in places where satellite communications are substantially > cheaper than terrestrial communications (this is most of the planet, by > area). > It is common practice to number news, mail, and HTTP proxy servers > (tuned for retrieval of objects over satellite-like latencies) within > subnets which can be advertised such that inbound traffic from the rest > of the world arrives on those servers via a satellite link, whereas all > other traffic (including traffic directly aimed at subscriber addresses) > arrives via terrestrial fibre. Ok, nothing wrong with that. But BGP doesn't provide any functionality to really help with this. Since it can be done now without help from BGP, there is no reason an IPv6 solution should specifically cater to this need. Just not getting in the way of more specific routes or policy routing should be enough. > I think the basic requirement should stay. I am not married to the words > currently in 3.1.4, however, so if you have better ones I'd be glad to > hear them. "Existing IPv4 multihoming practices can coexist with policy-based routing and forwarding mechanisms. An IPv6 multihoming architecture should retain this capability." From owner-multi6@ops.ietf.org Tue Jul 2 09:18:01 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08179 for ; Tue, 2 Jul 2002 09:18:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17PNXe-000IRa-00 for multi6-data@psg.com; Tue, 02 Jul 2002 06:18:02 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 17PNXW-000IQg-00 for multi6@ops.ietf.org; Tue, 02 Jul 2002 06:17:54 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g62DIDT68323; Tue, 2 Jul 2002 15:18:13 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 2 Jul 2002 15:18:13 +0200 (CEST) From: Iljitsch van Beijnum To: Brian E Carpenter cc: Subject: Re: draft-ietf-multi6-multihoming-requirements-03 In-Reply-To: <3D2164D4.3A558648@hursley.ibm.com> Message-ID: <20020702150856.Y68223-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-5.3 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT version=2.30 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 2 Jul 2002, Brian E Carpenter wrote: > I wonder why we are using MUST (upper case) terminology in any case. Don't ask me, I think there are too many caps in the world anyway. > Also "None of them is optional, > but they can be omitted..." makes my head hurt. It was the best I could come up with. It's your turn now. :-) > Why not just change the > language in the whole document to must/should (lower case)? I'm all for that. But that doesn't mean the sentence above can be omitted. > > I don't think this is the intention, but it _can_ be read as if IPv4 > > multihoming has the capability to direct traffic for certain applications > > over one link and traffic for other applications over another link. Since > > this is certainly not the case, at least the example should go, possibly > > the whole thing. (Does it require anything useful anyway?) > Yes. Today this sort of policy is generally implemented by fiddling with > DNS entries and addresses. Maybe we can do better for IPv6 if we think about > it. The example is a valid *requirement* but it should be cited > in the IPv6 context. I am currently multihomed in IPv6 (you have to practive what you preach) by having two tunnels, each with address space associated with them. I am only allowed to send out packets with source addresses A over tunnel A, and source addresses B over tunnel B. This makes some sense, but it breaks the hop-by-hop forwarding paradigm. It would be good if there were something better to say about this than "if you do, I'll just filter them, ha ha". And if we require routers to look at source addresses, why not protocols, ports and diffserv code points as well? But I'm pretty sure this isn't something that should be solved in this document at this time. From owner-multi6@ops.ietf.org Tue Jul 2 11:28:00 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22170 for ; Tue, 2 Jul 2002 11:27:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17PPYp-0004dT-00 for multi6-data@psg.com; Tue, 02 Jul 2002 08:27:23 -0700 Received: from felix.automagic.org ([204.152.186.101]) by psg.com with smtp (Exim 3.36 #1) id 17PPYl-0004dI-00 for multi6@ops.ietf.org; Tue, 02 Jul 2002 08:27:19 -0700 Received: (qmail 29226 invoked by uid 0); 2 Jul 2002 15:27:18 -0000 Received: from unknown (HELO hyperion) (127.0.0.1) by 0 with SMTP; 2 Jul 2002 15:27:18 -0000 Date: Tue, 2 Jul 2002 11:27:16 -0400 Subject: Re: draft-ietf-multi6-multihoming-requirements-03 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: To: Iljitsch van Beijnum From: Joe Abley In-Reply-To: <20020702145758.P68223-100000@sequoia.muada.com> Message-Id: <30A164B9-8DD0-11D6-8D41-00039312C852@automagic.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tuesday, July 2, 2002, at 09:08 , Iljitsch van Beijnum wrote: > On Mon, 1 Jul 2002, Joe Abley wrote: > >> It is common practice to number news, mail, and HTTP proxy servers >> (tuned for retrieval of objects over satellite-like latencies) within >> subnets which can be advertised such that inbound traffic from the rest >> of the world arrives on those servers via a satellite link, whereas all >> other traffic (including traffic directly aimed at subscriber >> addresses) >> arrives via terrestrial fibre. > > Ok, nothing wrong with that. But BGP doesn't provide any functionality > to > really help with this. Well, BGP plus CIDR abuse does. If I operate 203.97.0.0/17, and I obtain transit from two providers as vaguely described, I can hang all my satellite-tolerant gear in (say) 203.97.2.0/24 and advertise just 203.97.2.0/24 over the satellite circuit. The fact that I am able to advertise covered routes to make things work is central to the way that multi-homing is made to work with v4, and is one example of things we are trying to provide core-safe alternatives for in v6. > Since it can be done now without help from BGP, > there is no reason an IPv6 solution should specifically cater to this > need. Just not getting in the way of more specific routes or policy > routing should be enough. It seems feasible to me that there will be solutions to the requirement as currently stated on the draft that do not need to rely on policy routing or the advertisement of covered routes. I do not have such a solution in mind, but I don't see why we should discount the possiblity that one might exist. >> I think the basic requirement should stay. I am not married to the >> words >> currently in 3.1.4, however, so if you have better ones I'd be glad to >> hear them. > > "Existing IPv4 multihoming practices can coexist with policy-based > routing > and forwarding mechanisms. An IPv6 multihoming architecture should > retain this capability." As I said, I think that presupposes a solution. Joe From owner-multi6@ops.ietf.org Tue Jul 2 18:22:52 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19297 for ; Tue, 2 Jul 2002 18:22:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17PW2O-0006L1-00 for multi6-data@psg.com; Tue, 02 Jul 2002 15:22:20 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 17PW2J-0006Ko-00 for multi6@ops.ietf.org; Tue, 02 Jul 2002 15:22:16 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g62MMTT68920; Wed, 3 Jul 2002 00:22:30 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 3 Jul 2002 00:22:29 +0200 (CEST) From: Iljitsch van Beijnum To: Joe Abley cc: Subject: Re: draft-ietf-multi6-multihoming-requirements-03 In-Reply-To: <30A164B9-8DD0-11D6-8D41-00039312C852@automagic.org> Message-ID: <20020703000512.J68848-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-5.3 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT version=2.30 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 2 Jul 2002, Joe Abley wrote: > > Ok, nothing wrong with that. But BGP doesn't provide any functionality > > to really help with this. > Well, BGP plus CIDR abuse does. If I operate 203.97.0.0/17, and I obtain > transit from two providers as vaguely described, I can hang all my > satellite-tolerant gear in (say) 203.97.2.0/24 and advertise just > 203.97.2.0/24 over the satellite circuit. And you must also make sure the servers you communicate with are routed over the satellite link. If you don't, you'll have to use policy routing. > The fact that I am able to > advertise covered routes to make things work is central to the way that > multi-homing is made to work with v4, and is one example of things we > are trying to provide core-safe alternatives for in v6. Basically you are using two different address ranges here, one multihomed and one single homed. (The fact that they overlap in this particular instance is not important.) This is such a basic capability that I can't even imagine a multihoming solution that conflicts with it. > > Since it can be done now without help from BGP, > > there is no reason an IPv6 solution should specifically cater to this > > need. Just not getting in the way of more specific routes or policy > > routing should be enough. > It seems feasible to me that there will be solutions to the requirement > as currently stated on the draft that do not need to rely on policy > routing or the advertisement of covered routes. I do not have such a > solution in mind, but I don't see why we should discount the possiblity > that one might exist. Making scalable multihoming work is difficult enough without overloading it with extra nice to have features. But since I think this functionality can be provided regardless of the multihoming solution, and there is little harm in looking to optimize things, I'm not going to object very strongly. > > "Existing IPv4 multihoming practices can coexist with policy-based > > routing > > and forwarding mechanisms. An IPv6 multihoming architecture should > > retain this capability." > As I said, I think that presupposes a solution. I didn't have one in mind when I wrote it. From owner-multi6@ops.ietf.org Tue Jul 2 21:31:59 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27269 for ; Tue, 2 Jul 2002 21:31:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17PYz6-000IZT-00 for multi6-data@psg.com; Tue, 02 Jul 2002 18:31:08 -0700 Received: from felix.automagic.org ([204.152.186.101]) by psg.com with smtp (Exim 3.36 #1) id 17PYz0-000IXx-00 for multi6@ops.ietf.org; Tue, 02 Jul 2002 18:31:02 -0700 Received: (qmail 31474 invoked by uid 1000); 3 Jul 2002 01:31:02 -0000 Date: Tue, 2 Jul 2002 18:31:01 -0700 From: Joe Abley To: Iljitsch van Beijnum Cc: multi6@ops.ietf.org Subject: Re: draft-ietf-multi6-multihoming-requirements-03 Message-ID: <20020703013101.GA31442@felix.automagic.org> References: <30A164B9-8DD0-11D6-8D41-00039312C852@automagic.org> <20020703000512.J68848-100000@sequoia.muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020703000512.J68848-100000@sequoia.muada.com> User-Agent: Mutt/1.5.1i X-Spam-Status: No, hits=-5.3 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT version=2.30 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, Jul 03, 2002 at 12:22:29AM +0200, Iljitsch van Beijnum wrote: > On Tue, 2 Jul 2002, Joe Abley wrote: > > > > "Existing IPv4 multihoming practices can coexist with policy-based > > > routing > > > and forwarding mechanisms. An IPv6 multihoming architecture should > > > retain this capability." > > > As I said, I think that presupposes a solution. > > I didn't have one in mind when I wrote it. I was talking about the solution which involves "policy-based routing and forwarding mechanisms". Seems to me that the requirement in the document right now could be met without using those. For example, suppose the pure aggregation/no hole-punching addressing and route advertisement scheme is strictly adhered to, and the effect of multi-homing is to number each interface with an address from each transit provider. Further suppose that the TCP endpoint address selection algorithm can be influenced by some hierarchical policy signalling mechanism. In that case, inbound traffic towards a TCP endpoint could be moved between transit providers without resorting to CIDR abuse. I'm not saying that such a scheme would feature in a multihoming architecture v6, or that it is not without other substantial problems, but it does sound to me like a solution to the specific requirement in question which does not rely on advertising covering supernets (or other disparate routes) to different transit providers in order to achieve the desired goal. More generally, you seem to be saying that the requirement as stated reduces to something trivial, which of course should be supported by any adequate multihoming architecture. If I have got that right, then what's the harm in letting the requirement stand in the document? Joe From owner-multi6@ops.ietf.org Wed Jul 3 07:50:13 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07327 for ; Wed, 3 Jul 2002 07:50:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17PidL-0005E5-00 for multi6-data@psg.com; Wed, 03 Jul 2002 04:49:19 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 17PidB-0005BH-00 for multi6@ops.ietf.org; Wed, 03 Jul 2002 04:49:10 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g63BnQe70125; Wed, 3 Jul 2002 13:49:26 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 3 Jul 2002 13:49:26 +0200 (CEST) From: Iljitsch van Beijnum To: Joe Abley cc: Subject: Re: draft-ietf-multi6-multihoming-requirements-03 In-Reply-To: <20020703013101.GA31442@felix.automagic.org> Message-ID: <20020703133335.S68848-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-5.3 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT version=2.30 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 2 Jul 2002, Joe Abley wrote: > > > As I said, I think that presupposes a solution. > > I didn't have one in mind when I wrote it. > I was talking about the solution which involves "policy-based > routing and forwarding mechanisms". Seems to me that the requirement > in the document right now could be met without using those. Ah, I see. I was thinking about: 1. Both ends have the special applications use different addresses that are routed over just one connection (probably better to use PA space for this rather than a more specific in BGP) 2. Policy routing based on application characteristics such as IP address or protocol/port number 3. Diffserv code point that has the effect a specific connection is selected Are there additional ways to accomplish this? > For example, suppose the pure aggregation/no hole-punching addressing > and route advertisement scheme is strictly adhered to, and the effect > of multi-homing is to number each interface with an address from each > transit provider. Further suppose that the TCP endpoint address > selection algorithm can be influenced by some hierarchical policy > signalling mechanism. In that case, inbound traffic towards a TCP > endpoint could be moved between transit providers without resorting > to CIDR abuse. You still need either: - BOTH ends to have their IP address for this application in a separate range, or - use policy routing based on address or protocol/port to select the right exit connection The former is workable for things like NNTP, where the traffic flow is easily predicted and some optimization in IP addressing is well worth it. The latter is a dirty hack IMO, because it breaks hop-by-hop forwarding. When we get basic multihoming working for IPv6, there is probably a lot we can do to optimize load balancing while providing differentiated services (and/or the other way around). > More generally, you seem to be saying that the requirement as stated > reduces to something trivial, which of course should be supported by > any adequate multihoming architecture. If I have got that right, then > what's the harm in letting the requirement stand in the document? There is not much harm. Still, my original point remains: the wording could lead to confusion about current IPv4 capabilities. Iljitsch van Beijnum From owner-multi6@ops.ietf.org Wed Jul 3 11:03:00 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17423 for ; Wed, 3 Jul 2002 11:02:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17Ple4-000IjM-00 for multi6-data@psg.com; Wed, 03 Jul 2002 08:02:16 -0700 Received: from felix.automagic.org ([204.152.186.101]) by psg.com with smtp (Exim 3.36 #1) id 17Pldy-000Ihj-00 for multi6@ops.ietf.org; Wed, 03 Jul 2002 08:02:10 -0700 Received: (qmail 41924 invoked by uid 0); 3 Jul 2002 15:02:08 -0000 Received: from unknown (HELO hyperion) (127.0.0.1) by 0 with SMTP; 3 Jul 2002 15:02:08 -0000 Date: Wed, 3 Jul 2002 11:02:09 -0400 Subject: Re: draft-ietf-multi6-multihoming-requirements-03 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: To: Iljitsch van Beijnum From: Joe Abley In-Reply-To: <20020703133335.S68848-100000@sequoia.muada.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, July 3, 2002, at 07:49 , Iljitsch van Beijnum wrote: >> For example, suppose the pure aggregation/no hole-punching addressing >> and route advertisement scheme is strictly adhered to, and the effect >> of multi-homing is to number each interface with an address from each >> transit provider. Further suppose that the TCP endpoint address >> selection algorithm can be influenced by some hierarchical policy >> signalling mechanism. In that case, inbound traffic towards a TCP >> endpoint could be moved between transit providers without resorting >> to CIDR abuse. > > You still need either: > > - BOTH ends to have their IP address for this application in a separate > range, or This happens by virtue of the fact that each transit provider delegates a block of space to the multi-homed site. If the site is single-homed, it only has one transit provider, and hence only one IP address. The fictional address selection criteria might apply to both ends of the session. Yes, there are big holes in this approach :) > - use policy routing based on address or protocol/port to select the > right > exit connection > > The former is workable for things like NNTP, where the traffic flow is > easily predicted and some optimization in IP addressing is well worth > it. > The latter is a dirty hack IMO, because it breaks hop-by-hop forwarding. I have usually seen this deployed without policy routing to manipulate the path of outbound traffic. Frequently the satellite channels used are uni-directional in order to save money on (or avoid regulatory hassles with) an uplink from the multi-homed site. > When we get basic multihoming working for IPv6, there is probably a lot > we > can do to optimize load balancing while providing differentiated > services > (and/or the other way around). > >> More generally, you seem to be saying that the requirement as stated >> reduces to something trivial, which of course should be supported by >> any adequate multihoming architecture. If I have got that right, then >> what's the harm in letting the requirement stand in the document? > > There is not much harm. Still, my original point remains: the wording > could lead to confusion about current IPv4 capabilities. I will look at the words. The requirement I was trying to describe is most certainly met by the current v4 regime; it's a description of an approach which is already in widespread use. There is actually a separate (probably now expired) v4 capabilities draft which requires content. It needs more work, but I've had zero contributions to it; I will try to review it and propose a path forward with it in the next week or so. Joe From owner-multi6@ops.ietf.org Wed Jul 3 13:51:23 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23790 for ; Wed, 3 Jul 2002 13:51:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17PnAV-000MDR-00 for multi6-data@psg.com; Wed, 03 Jul 2002 09:39:51 -0700 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 17PnA1-000MD2-00 for multi6@ops.ietf.org; Wed, 03 Jul 2002 09:39:21 -0700 From: Masataka Ohta Message-Id: <200207031623.BAA04234@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id BAA04234; Thu, 4 Jul 2002 01:23:17 +0900 Subject: Re: draft-ietf-multi6-multihoming-requirements-03 In-Reply-To: <20020701185410.C27857E2@ab.use.net> from Sean Doran at "Jul 1, 2002 06:54:10 pm" To: Sean Doran Date: Thu, 4 Jul 2002 01:23:16 +0859 () CC: jabley@automagic.org, multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2 version=2.30 Sender: owner-multi6@ops.ietf.org Precedence: bulk Sean; > | Can't we simply admit the fact that none of us have any operational > | experience to be able to discuss multi6 requirement document > | to be used later to evaluate proposals and move on without it? > > I would hope that whatever forum evaluates any proposals from > any body dealing with the IPv6 site multihoming problem, that > "working code" is weighted at least as heavily as "rough consensus". Code of end to end multihoming is already running over the mobile IPv6 network with more than 150 routers, which is one of the largest IPv6 network in the world. So? > "code" is an abstract shorthand which can be read as "recipe" > or anything else used to describe actions to be undertaken by > human beings in the process of cooking up a solution. it does > not mean actual snippets of C or APL. It is often the case that a good solution is not to undertake any actions. > If you think you have working code that might not survive > scrutiny based on the emerging rough consensus over the > requirements drafts, *now* is the time to suggest changes. What I have been seeing is not consensus but tiredness on abstract discussion based on CURRENT operational environment with bloating routing table. So, if there is one thing to be added as an requirement: The solution MUST somehow change the current operational environment, which may make some or most of the requirements based on the current operational practice meaningless. Masataka Ohta