From owner-multi6@ops.ietf.org Fri Feb 1 12:46:15 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05557 for ; Fri, 1 Feb 2002 12:46:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Whh7-0002hS-00 for multi6-data@psg.com; Fri, 01 Feb 2002 09:41:49 -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.33 #1) id 16Whh6-0002hM-00 for multi6@ops.ietf.org; Fri, 01 Feb 2002 09:41:48 -0800 content-class: urn:content-classes:message Subject: (multi6) 53rd IETF Meeting Date: Fri, 1 Feb 2002 09:41:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405DE8C@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: (multi6) 53rd IETF Meeting thread-index: AcGrPvazm0LK/J1sR6mExsxJRhVWMQAB/SRg From: "Michel Py" To: , , "Sean Doran" Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA05557 Could the chairs give a clue to the WG if they intend to call a WG meeting in Minneapolis? If they do, I volunteer a short 10 min to discuss the open topics (currently 10) about the requirements draft edits. Thanks Michel. From owner-multi6@ops.ietf.org Mon Feb 4 09:45:08 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23869 for ; Mon, 4 Feb 2002 09:45:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16XkJD-000Khk-00 for multi6-data@psg.com; Mon, 04 Feb 2002 06:41:27 -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.33 #1) id 16XkJC-000Khe-00 for multi6@ops.ietf.org; Mon, 04 Feb 2002 06:41:26 -0800 Received: by ab.use.net (Postfix, from userid 3005) id A1C9A630; Mon, 4 Feb 2002 14:41:25 +0000 (GMT) To: michel@arneill-py.sacramento.ca.us, multi6@ops.ietf.org, narten@us.ibm.com, smd@ebone.net Subject: Re: (multi6) 53rd IETF Meeting Message-Id: <20020204144125.A1C9A630@ab.use.net> Date: Mon, 4 Feb 2002 14:41:25 +0000 (GMT) From: smd@ab.use.net (Sean Doran) Sender: owner-multi6@ops.ietf.org Precedence: bulk Michel - | Could the chairs give a clue to the WG if they intend to call a WG | meeting in Minneapolis? If they do, I volunteer a short 10 min to | discuss the open topics (currently 10) about the requirements draft | edits. At the moment, this would be the only item on the WG meeting agenda. Or am I missing something? Sean. From owner-multi6@ops.ietf.org Mon Feb 4 10:54: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 KAA26548 for ; Mon, 4 Feb 2002 10:54:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16XlRH-000Nyy-00 for multi6-data@psg.com; Mon, 04 Feb 2002 07:53:51 -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.33 #1) id 16XlRG-000Nym-00 for multi6@ops.ietf.org; Mon, 04 Feb 2002 07:53:50 -0800 content-class: urn:content-classes:message Subject: RE: (multi6) 53rd IETF Meeting MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 4 Feb 2002 07:53:45 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405DE96@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: (multi6) 53rd IETF Meeting thread-index: AcGtiie2Ky9vNHwrQ7+772LDCFs+GQACUYXg From: "Michel Py" To: "Sean Doran" , , , Cc: , "Christian Huitema" Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA26548 Sean, >> Michel Py Wrote: >> Could the chairs give a clue to the WG if they intend to call a WG >> meeting in Minneapolis? If they do, I volunteer a short 10 min to >> discuss the open topics (currently 10) about the requirements draft >> edits. > Sean Doran wrote > At the moment, this would be the only item on the WG meeting agenda. > Or am I missing something? > Sean. Pasted below is the text that I posted to the WG mailing two weeks ago (on 11/21). I also emailed it to you on 1/27 requesting feedback. There as been no opposition to that text and repeated support for parts of it, at least issuing the WG last call and possibly re-chartering. Correct me if I am wrong, my understanding of the way it works is that the agenda and WG last calls are the privilege of the chairs. I suppose that I could take care of the agenda, and that between Randy, Christian and myslef we could come with a pre-release of the re-charter. Is that what you want us to do? It would be nice, four weeks before the deadline, for the WG members to know if the WG last call agreed in SLC is going to be issued, if we are going or not to have a meeting in Minneapolis, if we are going to re- charter, etc. Time goes fast, and I was hoping we could have a more productive meeting than the one we had in SLC, wich means it needs to be prepared some time in advance, don't you agree? Michel. ---[ Posted Jan 21 2001 ] ------------------------------------------- Multi6 folk: The following text is from the multi 6 charter: Goals and Milestones: (I added the year, 2001). Apr 01 2001 Begin consideration of approaches and proposals that could be pursued. Aug 01 2001 Evaluate approaches and select those to be worked on. Sep 01 2001 Submit requirements ID to IESG for publication as Informational RFC. Sep 01 2001 Submit 'how multihoming is done today' ID to IESG for publication as Informational RFC. Sep 01 2001 Evaluate progress, recharter or shutdown We are late. Considering and evaluating approaches and select those to be worked on should have been done after London. Does anyone think that there is a reason to delay furthermore: 1. The WG last call for the requirements documents as discussed in SLC. I believe that Joe is ready to modify the draft to include the edits. I thank the people that have taken time to participate and renew the call to send comments/text to complement v1.05 of the edits I posted earlier today. 2. The submission for the requirements documents as Informational RFC BEFORE Minneapolis. 3. The selection of approaches/proposals to become WG working documents as mentionned in the WG charter. I nominate: draft-huitema-multi6-hosts-00.txt to become a WG working document. 4. The re-chartering of the WG; a text could be produced for Minneapolis and proposed to vote by the floor. 5. The discussion of proposal-specific issues in Minneapolis, as mentionned in the new charter to be. This implies a WG meeting in Minneapolis, and I think we need a two-hour one. I hope that we can collectively have a more productive meeting than we had in SLC. This also implies that the proposal selection MUST be done before the deadline to give authors a chance to submit their latest and greatest and prepare their slides. The deadline is March 1, 2002; it is in six weeks which is not a lot of time. Comments welcomed, as usual. Michel. From owner-multi6@ops.ietf.org Mon Feb 4 11:31:50 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27834 for ; Mon, 4 Feb 2002 11:31:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Xm1b-000Pwr-00 for multi6-data@psg.com; Mon, 04 Feb 2002 08:31:23 -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.33 #1) id 16Xm1a-000Pwi-00 for multi6@ops.ietf.org; Mon, 04 Feb 2002 08:31:22 -0800 Received: by ab.use.net (Postfix, from userid 3005) id 7C8D075F; Mon, 4 Feb 2002 16:31:21 +0000 (GMT) To: michel@arneill-py.sacramento.ca.us, multi6@ops.ietf.org Subject: RE: (multi6) 53rd IETF Meeting Cc: randy@psg.com Message-Id: <20020204163121.7C8D075F@ab.use.net> Date: Mon, 4 Feb 2002 16:31:21 +0000 (GMT) From: smd@ab.use.net (Sean Doran) Sender: owner-multi6@ops.ietf.org Precedence: bulk Michel - | There as been no opposition to that text and repeated support for parts | of it, at least issuing the WG last call and possibly re-chartering. There is little point in discussing a rechartering when the items in the present charter are as yet incomplete. These items can be completed in email right here on this list, as you have ably demonstrated with your accumulation of suggested changes. Thank you. Thomas and I shortly will be discussing ways to progress the documents, and how to get the proposed changes edited into the draft. | I suppose that I could take care of the agenda, and that between Randy, | Christian and myslef we could come with a pre-release of the re-charter. | Is that what you want us to do? No. My comment was maybe too terse: there is as yet no reason to schedule a live meeting in Minneapolis, since as of now there is no known potential agenda item, short of discussing your suggested changes. Since those discussions are happening on the list, there is therefore no point (that I see) in having a live meeting, since there is no practical way I know of to make it (to use your words) "more productive" than the last meeting. I hope that is clearer. If you disagree, or need further clarification, please let me and Thomas know, here on the list, or directly. Sean. From owner-multi6@ops.ietf.org Mon Feb 4 14:22: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 OAA03656 for ; Mon, 4 Feb 2002 14:22:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16XogO-0008Qz-00 for multi6-data@psg.com; Mon, 04 Feb 2002 11:21:40 -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.33 #1) id 16XogO-0008Qs-00 for multi6@ops.ietf.org; Mon, 04 Feb 2002 11:21:40 -0800 content-class: urn:content-classes:message Subject: RE: (multi6) 53rd IETF Meeting MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 4 Feb 2002 11:21:37 -0800 Message-ID: <2B81403386729140A3A899A8B39B046406C2D3@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: (multi6) 53rd IETF Meeting thread-index: AcGtmYdCcoUhkGKWRwq1U2TOK+y8lwAFzpoQ From: "Michel Py" To: "Sean Doran" , Cc: Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA03656 >> Sean Doran Wrote: >> If you disagree, or need further clarification, please >> let me and Thomas know, here on the list, or directly. > [from multi6 charter] > Sep 01, 2001 Evaluate progress, recharter or shutdown Just curious, How many YEARS behind schedule do you plan on being? Today's date is February 4, 2002. Michel. From owner-multi6@ops.ietf.org Mon Feb 4 14:33:17 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03872 for ; Mon, 4 Feb 2002 14:33:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16XorN-0008yx-00 for multi6-data@psg.com; Mon, 04 Feb 2002 11:33:01 -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.33 #1) id 16XorM-0008y8-00 for multi6@ops.ietf.org; Mon, 04 Feb 2002 11:33:00 -0800 Received: by ab.use.net (Postfix, from userid 3005) id CEF586BE; Mon, 4 Feb 2002 19:32:58 +0000 (GMT) To: michel@arneill-py.sacramento.ca.us, multi6@ops.ietf.org, smd@ab.use.net Subject: RE: (multi6) 53rd IETF Meeting Cc: randy@psg.com Message-Id: <20020204193258.CEF586BE@ab.use.net> Date: Mon, 4 Feb 2002 19:32:58 +0000 (GMT) From: smd@ab.use.net (Sean Doran) Sender: owner-multi6@ops.ietf.org Precedence: bulk Michel Py writes: | Just curious, How many YEARS behind schedule do you plan | on being? Today's date is February 4, 2002. How quickly can you complete the document? Remember: it is unpaid volunteer labour from writers that produces documents. NO ONE in this working group is being paid to take "why are you so late with your deliverables?" catcalls. Try to contain your impatience, unless you consider the document ready for WG last call and handover to the IESG. Sean. From owner-multi6@ops.ietf.org Mon Feb 4 15:26: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 PAA05152 for ; Mon, 4 Feb 2002 15:26:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Xpfy-000AJq-00 for multi6-data@psg.com; Mon, 04 Feb 2002 12:25: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.33 #1) id 16Xpfw-000AJh-00 for multi6@ops.ietf.org; Mon, 04 Feb 2002 12:25:17 -0800 content-class: urn:content-classes:message Subject: RE: (multi6) 53rd IETF Meeting MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 4 Feb 2002 12:25:13 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405DE97@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: (multi6) 53rd IETF Meeting thread-index: AcGts44ozVckNd3hQAC9hK7Yq1LppwAAyeWQ From: "Michel Py" To: "Sean Doran" , , "Joe Abley" Cc: Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA05152 > Sean Doran wrote: > How quickly can you complete the document? Joe, how many minutes do you need? > Remember: it is unpaid volunteer labour from writers that > produces documents. NO ONE in this working group is being > paid to take "why are you so late with your deliverables?" > catcalls. Remember: it is unpaid volunteer labour from editors (me, in this case) to produce the edits. It also is unpaid volunteer labour from authors (a few people, including me) to produce drafts. Before you try to sell me that one, why don't you assess who here has produced work for this WG? And, I am not whinning about the authors. I have been exchanging emails with Joe Abley from time to time, and I do not feel that the process is stuck on his side. > Try to contain your impatience, unless you consider the > document ready for WG last call and handover to the IESG. The document was ready for last call in Salt Lake, as voted by the floor. There has been numerous postings to the mailing lists asking for last call. I have exchanged several emails off the mailing list with people that agree with that. Converning the agenda, I strongly suggest that you re-read the CHARTER of the working group you chair. The CHARTER contains items such as "Begin consideration of approaches and proposals that could be pursued." and "Evaluate approaches and select those to be worked on". The CHARTER lists these items BEFORE submiting the requirements documents. The fact that you are the chair does not give you the right to read the CHARTER backwards to push your own agenda neither to prevent volunteers to make it happen. Michel. From owner-multi6@ops.ietf.org Mon Feb 4 15:48: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 PAA05617 for ; Mon, 4 Feb 2002 15:48:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Xq2I-000AjM-00 for multi6-data@psg.com; Mon, 04 Feb 2002 12:48:22 -0800 Received: from mx1out.umbc.edu ([130.85.253.51]) by psg.com with esmtp (Exim 3.33 #1) id 16Xq2H-000AjG-00; Mon, 04 Feb 2002 12:48:22 -0800 Received: from gl.umbc.edu (vijay@irix2.gl.umbc.edu [130.85.60.11]) by mx1out.umbc.edu (8.12.0/8.12.0/UMBC-Central 1.7 mxout 1.2.2.2 $) with ESMTP id g14KmIvb017150; Mon, 4 Feb 2002 15:48:18 -0500 (EST) Received: from localhost (vijay@localhost) by gl.umbc.edu (8.9.0/8.9.0) with ESMTP id PAA3026906; Mon, 4 Feb 2002 15:48:18 -0500 (EST) X-Authentication-Warning: irix2.gl.umbc.edu: vijay owned process doing -bs Date: Mon, 4 Feb 2002 15:48:18 -0500 From: Vijay Gill X-X-Sender: To: Michel Py cc: , Subject: RE: (multi6) 53rd IETF Meeting In-Reply-To: <2B81403386729140A3A899A8B39B046406C2D3@server2000.arneill-py.sacramento.ca.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 4 Feb 2002, Michel Py wrote: > >> Sean Doran Wrote: > >> If you disagree, or need further clarification, please > >> let me and Thomas know, here on the list, or directly. > > > [from multi6 charter] > > Sep 01, 2001 Evaluate progress, recharter or shutdown > > Just curious, How many YEARS behind schedule do you plan > on being? Today's date is February 4, 2002. Please try to restrain the hysterics to a minimum. Day jobs do sometimes come up and take a chunk of time out of our ietf efforts. /vijay From owner-multi6@ops.ietf.org Mon Feb 4 16:18:56 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06162 for ; Mon, 4 Feb 2002 16:18:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16XqVa-000BEb-00 for multi6-data@psg.com; Mon, 04 Feb 2002 13:18:38 -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.33 #1) id 16XqVZ-000BEV-00 for multi6@ops.ietf.org; Mon, 04 Feb 2002 13:18:37 -0800 content-class: urn:content-classes:message Subject: RE: (multi6) 53rd IETF Meeting MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 4 Feb 2002 13:18:33 -0800 Message-ID: <2B81403386729140A3A899A8B39B046406C2D6@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: (multi6) 53rd IETF Meeting thread-index: AcGtvVmcYEMLmKlLR7KSMvp922D56wAA/DhA From: "Michel Py" To: "Vijay Gill" Cc: , Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA06162 >> Just curious, How many YEARS behind schedule do you plan >> on being? Today's date is February 4, 2002. > Vijay Gill wrote: > Please try to restrain the hysterics to a minimum. Day jobs > do sometimes come up and take a chunk of time out of our > ietf efforts. I have a day job, too. We already are six MONTHS behind and a YEAR is twelve (12) MONTHS. Michel. From owner-multi6@ops.ietf.org Mon Feb 4 16:41:55 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06496 for ; Mon, 4 Feb 2002 16:41:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16XqrW-000Bh6-00 for multi6-data@psg.com; Mon, 04 Feb 2002 13:41:18 -0800 Received: from h00d0b71b83ad.ne.mediaone.net ([65.96.132.240] helo=perdition.linnaean.org) by psg.com with esmtp (Exim 3.33 #1) id 16XqrW-000Bgz-00 for multi6@ops.ietf.org; Mon, 04 Feb 2002 13:41:18 -0800 Received: by perdition.linnaean.org (Postfix, from userid 31013) id 6C55B1BA0B; Mon, 4 Feb 2002 16:41:17 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Michel Py" Cc: "Vijay Gill" , , Subject: RE: (multi6) 53rd IETF Meeting In-Reply-To: <2B81403386729140A3A899A8B39B046406C2D6@server2000.arneill-py.sacramento.ca.us> References: <2B81403386729140A3A899A8B39B046406C2D6@server2000.arneill-py.sacramento.ca.us> X-Mailer: VM 6.34 under Emacs 20.7.1 Reply-To: Daniel Hagerty From: Daniel Hagerty Date: Mon, 4 Feb 2002 16:41:17 -0500 Message-Id: <20020204214117.6C55B1BA0B@perdition.linnaean.org> Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > From: "Michel Py" > Date: Mon, 4 Feb 2002 13:18:33 -0800 > > > Please try to restrain the hysterics to a minimum. Day jobs > > do sometimes come up and take a chunk of time out of our > > ietf efforts. > > I have a day job, too. We already are six MONTHS behind and a > YEAR is twelve (12) MONTHS. Which part of "keep the hysterics to a minimum" did you fail to understand? Cajoling people about schedules on something they volunteer towards isn't likely to make progress towards meeting "the schedule" any easier. From owner-multi6@ops.ietf.org Mon Feb 4 17:20:14 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07085 for ; Mon, 4 Feb 2002 17:20:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16XrSr-000CZr-00 for multi6-data@psg.com; Mon, 04 Feb 2002 14:19:53 -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.33 #1) id 16XrSq-000CZi-00 for multi6@ops.ietf.org; Mon, 04 Feb 2002 14:19:52 -0800 content-class: urn:content-classes:message Subject: RE: (multi6) 53rd IETF Meeting MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 4 Feb 2002 14:19:46 -0800 Message-ID: <2B81403386729140A3A899A8B39B046406C2D7@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: (multi6) 53rd IETF Meeting thread-index: AcGtxMptrvdn7mNER/GNf6J/BoC5YgABTQqA From: "Michel Py" To: "Daniel Hagerty" Cc: , Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA07085 > Daniel Hagerty wrote: > Which part of "keep the hysterics to a minimum" did you fail > to understand? Cajoling people about schedules on something > they volunteer towards isn't likely to make progress towards > meeting "the schedule" any easier. Talking about which, can you remind me of any work you have produced for this working group? Michel. From owner-multi6@ops.ietf.org Mon Feb 4 17:46:38 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07514 for ; Mon, 4 Feb 2002 17:46:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16XrrM-000D47-00 for multi6-data@psg.com; Mon, 04 Feb 2002 14:45:12 -0800 Received: from h00d0b71b83ad.ne.mediaone.net ([65.96.132.240] helo=perdition.linnaean.org) by psg.com with esmtp (Exim 3.33 #1) id 16XrrM-000D3z-00 for multi6@ops.ietf.org; Mon, 04 Feb 2002 14:45:12 -0800 Received: by perdition.linnaean.org (Postfix, from userid 31013) id 909241BA0B; Mon, 4 Feb 2002 17:45:11 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Michel Py" Cc: , Subject: RE: (multi6) 53rd IETF Meeting In-Reply-To: <2B81403386729140A3A899A8B39B046406C2D7@server2000.arneill-py.sacramento.ca.us> References: <2B81403386729140A3A899A8B39B046406C2D7@server2000.arneill-py.sacramento.ca.us> X-Mailer: VM 6.34 under Emacs 20.7.1 Reply-To: Daniel Hagerty From: Daniel Hagerty Date: Mon, 4 Feb 2002 17:45:11 -0500 Message-Id: <20020204224511.909241BA0B@perdition.linnaean.org> Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Talking about which, can you remind me of any work you have > produced for this working group? Did I make any claim to have done so? I'm young, and I'm generally ghosting. When my very limited experience can actually contribute something, I do so. In this case, my limited experience suggests that your behavior is counter-productive to the goal you claim to wish to reach. My reading of mail on this list in the last 24 hours suggests that others think so as well. I'm pretty sure that anyone on this list can get paid to have people yell at them about meeting or not meeting schedules. I suspect that people volunteering to help the IETF aren't signing up because they miss this aspect of the job. So can you tell me (privately) how publicly bitching about the amount of work you've done that others haven't furthers the working group? I'd be fascinated to hear it. From owner-multi6@ops.ietf.org Mon Feb 4 17:54:50 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07681 for ; Mon, 4 Feb 2002 17:54:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Xrzv-000DGK-00 for multi6-data@psg.com; Mon, 04 Feb 2002 14:54:03 -0800 Received: from inet.org ([63.108.254.91] helo=gnat.inet.org) by psg.com with esmtp (Exim 3.33 #1) id 16Xrzu-000DFU-00 for multi6@ops.ietf.org; Mon, 04 Feb 2002 14:54:03 -0800 Received: from mosquito.inet.org (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id E343367103; Mon, 4 Feb 2002 18:10:20 -0500 (EST) Date: Mon, 4 Feb 2002 17:53:48 -0500 Subject: Re: (multi6) 53rd IETF Meeting Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v480) Cc: To: "Michel Py" From: RJ Atkinson In-Reply-To: <2B81403386729140A3A899A8B39B046406C2D6@server2000.arneill-py.sacramento.ca.us> Message-Id: <0CD9A26C-19C2-11D6-A5ED-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.480) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Michael, The fact that you have an "issues" list circulating on the list is a pretty compelling argument that we don't have a document ready for WG Last Call. Now if the WG thinks those issues are now "resolved" and they should be put into the document, that is fine, but such has not been crystal clear to me at least. Normally an IETF document is not ready for WG Last Call until after the document has all updates and stops changing for weeks/months. And there is no requirement that an IETF WG ever meet in person. Experience is that the more productive WGs often meet less in person, because they are productive in using email. Cheers, Ran rja@extremenetworks.com From owner-multi6@ops.ietf.org Mon Feb 4 22:20: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 WAA11761 for ; Mon, 4 Feb 2002 22:20:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Xw8N-000Ihl-00 for multi6-data@psg.com; Mon, 04 Feb 2002 19:19: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.33 #1) id 16Xw8N-000Ihd-00 for multi6@ops.ietf.org; Mon, 04 Feb 2002 19:19:03 -0800 content-class: urn:content-classes:message Subject: RE: (multi6) 53rd IETF Meeting MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 4 Feb 2002 19:19:00 -0800 Message-ID: <2B81403386729140A3A899A8B39B046406C2DC@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: (multi6) 53rd IETF Meeting thread-index: AcGtzuz3jn1meiOnQ3SRddh9RdFxlwAJMrog From: "Michel Py" To: "RJ Atkinson" Cc: Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA11761 Ran, > RJ Atkinson wrote: > The fact that you have an "issues" list circulating on the list > is a pretty compelling argument that we don't have a document ready > for WG Last Call. Now if the WG thinks those issues are now > "resolved" and they should be put into the document, that is fine, > but such has not been crystal clear to me at least. That document was supposed to be the edits of the WG last call. Since you have contributed to it I think you will agree that the proposed changes are cosmetic, and the new requirements are not anywhere near the audience they need to actually become new requirements, except for maybe for topic 3. > Normally an IETF document is not ready for WG Last Call until > after the document has all updates and stops changing for > weeks/months. Maybe this needs to be balanced with the fact that this workgroup has not reached any of the milestones mentioned in its charter since London. Michel. From owner-multi6@ops.ietf.org Tue Feb 5 00:05:54 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14620 for ; Tue, 5 Feb 2002 00:05:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Xxma-000LWs-00 for multi6-data@psg.com; Mon, 04 Feb 2002 21:04:40 -0800 Received: from roam.psg.com ([147.28.4.2]) by psg.com with esmtp (Exim 3.33 #1) id 16XxmZ-000LWk-00 for multi6@ops.ietf.org; Mon, 04 Feb 2002 21:04:39 -0800 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16XxmF-0001Mb-00; Tue, 05 Feb 2002 05:04:19 +0000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Michel Py" Cc: "Vijay Gill" , Subject: RE: (multi6) 53rd IETF Meeting References: <2B81403386729140A3A899A8B39B046406C2D6@server2000.arneill-py.sacramento.ca.us> Message-Id: Date: Tue, 05 Feb 2002 05:04:19 +0000 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>> Just curious, How many YEARS behind schedule do you plan >>> on being? Today's date is February 4, 2002. >> Please try to restrain the hysterics to a minimum. Day jobs >> do sometimes come up and take a chunk of time out of our >> ietf efforts. > I have a day job, too. We already are six MONTHS behind and a > YEAR is twelve (12) MONTHS. if we spent the time working as opposed to shouting at eachother, we might inch along faster. day job overload can be worse for ops folk and wgs with heavy ops components. vendors are paid to influence standards, operators are not. randy From owner-multi6@ops.ietf.org Tue Feb 5 08:15:33 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28999 for ; Tue, 5 Feb 2002 08:15:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Y5P2-0004cl-00 for multi6-data@psg.com; Tue, 05 Feb 2002 05:12:52 -0800 Received: from inet.org ([63.108.254.91] helo=gnat.inet.org) by psg.com with esmtp (Exim 3.33 #1) id 16Y5P1-0004ce-00 for multi6@ops.ietf.org; Tue, 05 Feb 2002 05:12:51 -0800 Received: from mosquito.inet.org (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id DB31067107; Tue, 5 Feb 2002 08:29:26 -0500 (EST) Date: Tue, 5 Feb 2002 08:12:49 -0500 Subject: Re: (multi6) 53rd IETF Meeting Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v480) Cc: To: "Michel Py" From: RJ Atkinson In-Reply-To: <2B81403386729140A3A899A8B39B046406C2DC@server2000.arneill-py.sacramento.ca.us> Message-Id: <0D8C7CB4-1A3A-11D6-98E5-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.480) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Monday, February 4, 2002, at 10:19 , Michel Py wrote: >> Normally an IETF document is not ready for WG Last Call until >> after the document has all updates and stops changing for >> weeks/months. > > Maybe this needs to be balanced with the fact that this workgroup > has not reached any of the milestones mentioned in its charter > since London. I'm hard pressed to think of ANY IETF WG that met its milestones. I'm not saying that missing milestones is good, but rather that missing milestones is not, by itself, unusual. IMHO, procedurally we need to get the document edited to reflect the changes currently circulating (provided no one on the list objects at this point to the proposed changes), then determine that no more changes are appropriate, then do a WG Last Call. And I think all that is possible to resolve via email on the list, which seems to be the chair's preferred approach. Ran rja@extremenetworks.com From owner-multi6@ops.ietf.org Wed Feb 6 06:58:09 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17841 for ; Wed, 6 Feb 2002 06:58:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16YQgI-0002Bj-00 for multi6-data@psg.com; Wed, 06 Feb 2002 03:56:06 -0800 Received: from viap111.atea.be ([194.78.143.111] helo=hrtades9.atea.be) by psg.com with esmtp (Exim 3.33 #1) id 16YQgH-0002Bb-00 for multi6@ops.ietf.org; Wed, 06 Feb 2002 03:56:06 -0800 Received: from hrtades10.atea.be (siemens.atea.be [139.10.143.141]) by hrtades9.atea.be with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DF4YRD42; Wed, 6 Feb 2002 12:55:51 +0100 Received: by siemens.atea.be with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Feb 2002 12:56:16 +0100 Message-ID: From: Coene Lode To: "Transport Area wg (E-mail)" , "SIGTRAN (E-mail)" , "'multi6@ops.ietf.org'" Subject: SCTP multihoming issues draft Date: Wed, 6 Feb 2002 12:53:46 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-multi6@ops.ietf.org Precedence: bulk Previous week, the draft on SCTP multihoming issues was published. Apart from some editorial changes concerning author list and missing/wrong page numbers, the only major change is a sentence added at the end of paragraph 2.3 SCTP multihoming and Network Adress Translators(NAT): "It should be noted that the NAT box becomes a single point-of-failure in this case, as ALL the paths of the SCTP association have to go through that single NAT box." Theoretical it is possible to let all the different paths run through different NAT boxes, but then the NAT boxes would never know exactly when to teardown/terminate the association as the terminate or abort takes only one of the paths(and there are other difficulties, such as the heartbeats ...etc...) So in practical terms this sentence should be correct. If you feel otherwise, please let me know and I'll remove or add something to it to make everything clear. The draft can be found at the IETF draft directory: Multihoming issues in the Stream Control Transmission Protocol If by then end of next week, no further issues have been identified, then I would ask for this draft to be moved to informational. yours sincerly Lode Coene From owner-multi6@ops.ietf.org Wed Feb 6 09:31:50 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20978 for ; Wed, 6 Feb 2002 09:31:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16YT5u-0004x4-00 for multi6-data@psg.com; Wed, 06 Feb 2002 06:30:42 -0800 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by psg.com with esmtp (Exim 3.33 #1) id 16YT5t-0004wv-00 for multi6@ops.ietf.org; Wed, 06 Feb 2002 06:30:41 -0800 Received: from hawk.ecs.soton.ac.uk (hawk.ecs.soton.ac.uk [152.78.68.142]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id OAA15173; Wed, 6 Feb 2002 14:30:39 GMT Received: from login.ecs.soton.ac.uk (IDENT:tjc@login.ecs.soton.ac.uk [152.78.68.149]) by hawk.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id OAA22751; Wed, 6 Feb 2002 14:30:44 GMT Date: Wed, 6 Feb 2002 14:30:38 +0000 (GMT) From: Tim Chown To: Coene Lode cc: "Transport Area wg (E-mail)" , "SIGTRAN (E-mail)" , "'multi6@ops.ietf.org'" Subject: Re: SCTP multihoming issues draft In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 6 Feb 2002, Coene Lode wrote: > If by then end of next week, no further issues have been identified, then I > would ask for this draft to be moved to informational. Does the draft have to only consider two network interfaces for the multihoming issues? In IPv6, as you point out, each interface can have more than one IPv6 address (and addresses of many scopes), so the simplest multihoming case for IPv6 is a host (endpoint) with one interface, recieving two different /64 prefix RAs, and thus having two IPv6 addresses from two different providers. The dual interface scenario may be useful of course, e.g. when considering wired and air interfaces. When you say "it is recommended that IP addresses in a multihomed endpoint be assigned IP endpoints from different TLA's to ensure against network failure", this would be the default case for IPv6. For IPv6, delete section 2.3 :-) In general, more consideration could be given for IPv6, perhaps? (you did cc multi6 :-) If I've misinterpreted the text, perhaps the title of the draft needs revision? Best wishes, Tim From owner-multi6@ops.ietf.org Wed Feb 6 10:25:30 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23019 for ; Wed, 6 Feb 2002 10:25:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16YTvk-00067c-00 for multi6-data@psg.com; Wed, 06 Feb 2002 07:24:16 -0800 Received: from viap111.atea.be ([194.78.143.111] helo=hrtades9.atea.be) by psg.com with esmtp (Exim 3.33 #1) id 16YTvk-00067U-00 for multi6@ops.ietf.org; Wed, 06 Feb 2002 07:24:16 -0800 Received: from hrtades10.atea.be (siemens.atea.be [139.10.143.141]) by hrtades9.atea.be with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DF4YRGY1; Wed, 6 Feb 2002 16:24:03 +0100 Received: by siemens.atea.be with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Feb 2002 16:24:29 +0100 Message-ID: From: Coene Lode To: "'Tim Chown'" Cc: "'multi6@ops.ietf.org'" Subject: RE: SCTP multihoming issues draft Date: Wed, 6 Feb 2002 16:21:58 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-multi6@ops.ietf.org Precedence: bulk -----Original Message----- From: Tim Chown [mailto:tjc@ecs.soton.ac.uk] Sent: Wednesday, February 06, 2002 3:31 PM To: Coene Lode Cc: Transport Area wg (E-mail); SIGTRAN (E-mail); 'multi6@ops.ietf.org' Subject: Re: SCTP multihoming issues draft >On Wed, 6 Feb 2002, Coene Lode wrote: > >> If by then end of next week, no further issues have been identified, then I >> would ask for this draft to be moved to informational. > >Does the draft have to only consider two network interfaces for the >multihoming issues? In IPv6, as you point out, each interface can have >more than one IPv6 address (and addresses of many scopes), so the simplest >multihoming case for IPv6 is a host (endpoint) with one interface, >recieving two different /64 prefix RAs, and thus having two IPv6 addresses >from two different providers. The dual interface scenario may be useful >of course, e.g. when considering wired and air interfaces. It considers any configuration with multiple interface cards or one interface card with multiple addresses(in both cases possibly going to infinity:-) The examples are for multiple interface cards as that was the first use we thougth of. > >When you say "it is recommended that IP addresses in a multihomed endpoint >be assigned IP endpoints from different TLA's to ensure against network >failure", this would be the default case for IPv6. > Great, that is a plus for letting SCTP run on IPv6 > > >For IPv6, delete section 2.3 :-) Unfortunaly, I have also to describe the present situation with IPv4 which as you can derive from paragraph 2.3 is less than ideal. The last sentence is a gentle push for people NOT to use IPv4 NAT boxes if people really want to use multihoming. The result should be to use IPv6 for such cases. > >In general, more consideration could be given for IPv6, perhaps? (you >did cc multi6 :-) If I've misinterpreted the text, perhaps the title >of the draft needs revision? Well, this draft has to address all possibilities whether I(and my comrades-in-arms) like them or not. And the issue of multihoming of SCTP in IPv4 networks together with NAT's is one of them. That's why the TSVWG and SIGTRAN are on also. And if this issue list makes that more people would use IPv6 networks in real situation, ,that would certainly make IPv6 proponents happy.(besides the SCTP folks) > >Best wishes, >Tim > yours sincerly, Lode From owner-multi6@ops.ietf.org Thu Feb 7 14:50: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 OAA07525 for ; Thu, 7 Feb 2002 14:50:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16YuVQ-0005lV-00 for multi6-data@psg.com; Thu, 07 Feb 2002 11:46:52 -0800 Received: from buffoon.automagic.org ([208.185.30.208]) by psg.com with smtp (Exim 3.33 #1) id 16YuVP-0005lI-00 for multi6@ops.ietf.org; Thu, 07 Feb 2002 11:46:51 -0800 Received: (qmail 39714 invoked by uid 1000); 7 Feb 2002 19:46:49 -0000 Date: Thu, 7 Feb 2002 14:46:49 -0500 From: Joe Abley To: Michel Py Cc: Sean Doran , multi6@ops.ietf.org, randy@psg.com Subject: Re: (multi6) 53rd IETF Meeting Message-ID: <20020207144648.S24173@buffoon.automagic.org> References: <2B81403386729140A3A899A8B39B046405DE97@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2B81403386729140A3A899A8B39B046405DE97@server2000.arneill-py.sacramento.ca.us> User-Agent: Mutt/1.3.22.1i Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, Feb 04, 2002 at 12:25:13PM -0800, Michel Py wrote: > > Sean Doran wrote: > > How quickly can you complete the document? > > Joe, how many minutes do you need? If there is general agreement that the set of changes you have collated is reasonable, I can make edits quite quickly. The main reason I haven't done so already is that I haven't seen vocal support for the changes in the mailing list. Note that this is quite possibly because I have not been looking very hard; I have been busy for some time now with work for my employer which has left very little space in the standard 18-hour day for less directly revenue-generating activities. Perhaps the chairs could hazard an opinion as to whether the most recent list of changes floated by Michel seems to reflect the wg's opinion? Like I said, doing the edits is quick and easy. It's having an opinion on the proposed changes that I have been struggling to find time for. Joe From owner-multi6@ops.ietf.org Thu Feb 7 14:53:50 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07671 for ; Thu, 7 Feb 2002 14:53:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Yuc3-00060J-00 for multi6-data@psg.com; Thu, 07 Feb 2002 11:53:43 -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.33 #1) id 16Yuc2-00060D-00 for multi6@ops.ietf.org; Thu, 07 Feb 2002 11:53:43 -0800 Received: by ab.use.net (Postfix, from userid 3005) id 87BCE6FF; Thu, 7 Feb 2002 19:53:35 +0000 (GMT) To: jabley@nlri.org, multi6@ops.ietf.org Subject: please indicate whether you are content with the proposed edits [was: : (multi6) 53rd IETF Meeting] Message-Id: <20020207195335.87BCE6FF@ab.use.net> Date: Thu, 7 Feb 2002 19:53:35 +0000 (GMT) From: smd@ab.use.net (Sean Doran) Sender: owner-multi6@ops.ietf.org Precedence: bulk Joe - | Perhaps the chairs could hazard an opinion as to whether the most | recent list of changes floated by Michel seems to reflect the wg's | opinion? I would like to see a positive expression of consensus on this, rather than just accepting a possible silence as consent. If there are at least five "yes, it's OK" messages to the list, and zero "no" messages, I would take that as an expression of WG consensus. If there is a combination of "yes" and "no" votes, we will have to discuss things further in an effort to build a clear consensus. All - please register your opinion, or even a meta-opinion on this opinion-gathering, on the multi6 list. Sean. From owner-multi6@ops.ietf.org Thu Feb 7 16:01:31 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09787 for ; Thu, 7 Feb 2002 16:01:31 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16YveN-0008hs-00 for multi6-data@psg.com; Thu, 07 Feb 2002 13:00:11 -0800 Received: from evrtwa1-ar8-4-60-069-053.evrtwa1.vz.dsl.gtei.net ([4.60.69.53] helo=tndh.net) by psg.com with esmtp (Exim 3.33 #1) id 16YveM-0008hm-00 for multi6@ops.ietf.org; Thu, 07 Feb 2002 13:00:10 -0800 Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Thu, 07 Feb 2002 13:00:03 -0800 From: "Tony Hain" To: "Sean Doran" , , Subject: RE: please indicate whether you are content with the proposed edits [was: : (multi6) 53rd IETF Meeting] Date: Thu, 7 Feb 2002 13:00:02 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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: <20020207195335.87BCE6FF@ab.use.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I suspect this will amount to a NO, because I can't tell that Michel's summary will actually change the document. There are extensive comments in his note, with no clear statement about what will happen in each case. If we are going to last call the document, we need to see it, not a summary of changes that might or might not be made to it. Tony > -----Original Message----- > From: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]On > Behalf Of Sean Doran > Sent: Thursday, February 07, 2002 11:54 AM > To: jabley@nlri.org; multi6@ops.ietf.org > Subject: please indicate whether you are content with the > proposed edits > [was: : (multi6) 53rd IETF Meeting] > > > Joe - > > | Perhaps the chairs could hazard an opinion as to whether the most > | recent list of changes floated by Michel seems to reflect the wg's > | opinion? > > I would like to see a positive expression of consensus on this, > rather than just accepting a possible silence as consent. > > If there are at least five "yes, it's OK" messages to the list, > and zero "no" messages, I would take that as an expression of > WG consensus. > > If there is a combination of "yes" and "no" votes, we will have > to discuss things further in an effort to build a clear consensus. > > All - please register your opinion, or even a meta-opinion on this > opinion-gathering, on the multi6 list. > > Sean. > From owner-multi6@ops.ietf.org Thu Feb 7 16:33:39 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10551 for ; Thu, 7 Feb 2002 16:33:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16YwAY-000ARw-00 for multi6-data@psg.com; Thu, 07 Feb 2002 13:33:26 -0800 Received: from mailc.microsoft.com ([131.107.3.121] helo=mail5.microsoft.com) by psg.com with esmtp (Exim 3.33 #1) id 16YwAX-000ARk-00 for multi6@ops.ietf.org; Thu, 07 Feb 2002 13:33:25 -0800 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.148]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.4617); Thu, 7 Feb 2002 13:33:04 -0800 Received: from 157.54.6.150 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 07 Feb 2002 13:33:18 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 7 Feb 2002 13:33:04 -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.2966); Thu, 7 Feb 2002 13:33:03 -0800 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0); Thu, 7 Feb 2002 13:30:51 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6132.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: please indicate whether you are content with the proposed edits [was: : (multi6) 53rd IETF Meeting] Date: Thu, 7 Feb 2002 13:30:51 -0800 Message-ID: Thread-Topic: please indicate whether you are content with the proposed edits [was: : (multi6) 53rd IETF Meeting] Thread-Index: AcGwG0oJv+05JU4qQgaotFvEPe6B+QAAQbPg From: "Christian Huitema" To: "Tony Hain" , "Sean Doran" , , X-OriginalArrivalTime: 07 Feb 2002 21:30:51.0894 (UTC) FILETIME=[B79A6160:01C1B01E] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA10551 I agree with Tony. Michel's e-mail is a list of options, and as such a yes-no vote is meaningless. We need a consensus about which options to retain. Michel in in latest summary (1.08, sent January 30) lists 10 issues: Topics: ------- 1) About 3.1.2 2) About multihoming classes 3) About DNS 4) About EIDs 5) About cooperation 6) About 3.1.3 Performance 7) About 3.2.5 8) About 4. Security Considerations 9) comment on 3.2.2, and 3.2.3 10) Reverse Path Forwarding / filtering From the discussion it seems that we have consensus on almost all points: 2) Adopt the text proposed by Ran, complemented by the caveat proposed by Rob. 3) I believe there is consensus to add the text proposed by Ran. 4) I seem to be the only one proposing this edit. I agree to drop it. 5) Consensus to adopt the proposed edit. 6) Rough consensus to remove the reference to "manual" processing, i.e. delete the last sentence in the paragraph 7) Consensus to amend the text in the sense of a requirement "to retain the ability to extract routing information from the router". 8) Adopt the text proposed by Rob Rockwell. 9) Only Rob Rockell voiced an opinion. I think there is a default consensus to keep the original text. 10) Adopt the text that Ran proposed. The point of non-consensus is point 1, for which there are diverse opinion, and perhaps a weak consensus to adopt a restricted version of the requirement, i.e. state that sites must have a way to load balance their "outbound" traffic, saying nothing about "inbound." If we want to vote, I suggest that we take separate votes on the first proposed edit (the load balancing requirement), stating a preference, and that we then take a block vote on the 9 others. My vote is "outbound only" on 1, Yes on 2-9. -- Christian Huitema From owner-multi6@ops.ietf.org Thu Feb 7 17:25: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 QAA10566 for ; Thu, 7 Feb 2002 16:33:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16YwAK-000ARH-00 for multi6-data@psg.com; Thu, 07 Feb 2002 13:33:12 -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.33 #1) id 16YwAJ-000AR9-00 for multi6@ops.ietf.org; Thu, 07 Feb 2002 13:33:11 -0800 Received: by ab.use.net (Postfix, from userid 3005) id B140F6FF; Thu, 7 Feb 2002 21:33:10 +0000 (GMT) To: alh-ietf@tndh.net, jabley@nlri.org, multi6@ops.ietf.org, smd@ab.use.net Subject: RE: please indicate whether you are content with the proposed edits [was: : (multi6) 53rd IETF Meeting] Message-Id: <20020207213310.B140F6FF@ab.use.net> Date: Thu, 7 Feb 2002 21:33:10 +0000 (GMT) From: smd@ab.use.net (Sean Doran) Sender: owner-multi6@ops.ietf.org Precedence: bulk Tony - I assume your "no" is to the question of whether Joe should put all the proposed edits into the current draft, which then we could advance or discuss further. How would you propose we proceed then? Ask Michel for a clarification? Or to have him do the edits himself so that the WG can compare one and the other using diff(1) or eyeballs? Personally, I'm not sure that either is really necessary... do you have problems with specific proposed edits? If your no is to a last call, rest assured that there has not yet been a last call. This is merely a question of what should be in the document when it undergoes last call, given a set of edits. Sean. From owner-multi6@ops.ietf.org Thu Feb 7 17:40: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 RAA11811 for ; Thu, 7 Feb 2002 17:40:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16YxCi-000Dih-00 for multi6-data@psg.com; Thu, 07 Feb 2002 14:39:44 -0800 Received: from evrtwa1-ar8-4-60-069-053.evrtwa1.vz.dsl.gtei.net ([4.60.69.53] helo=tndh.net) by psg.com with esmtp (Exim 3.33 #1) id 16YxCh-000DiT-00 for multi6@ops.ietf.org; Thu, 07 Feb 2002 14:39:43 -0800 Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Thu, 07 Feb 2002 14:39:41 -0800 From: "Tony Hain" To: "Sean Doran" , , Subject: RE: please indicate whether you are content with the proposed edits [was: : (multi6) 53rd IETF Meeting] Date: Thu, 7 Feb 2002 14:39:41 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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: <20020207213310.B140F6FF@ab.use.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The NO is really a 'I can't tell what edits are expected' because after each issue is a list of 'possible modifications'. How do we answer Yes/No to a multiple choice question? As far as how to proceed, I don't believe we need to edit the full document right now, but I would like to see the list reduced to the specific change on each issue. Tony > -----Original Message----- > From: Sean Doran [mailto:smd@ab.use.net] > Sent: Thursday, February 07, 2002 1:33 PM > To: alh-ietf@tndh.net; jabley@nlri.org; multi6@ops.ietf.org; > smd@ab.use.net > Subject: RE: please indicate whether you are content with the proposed > edits [was: : (multi6) 53rd IETF Meeting] > > > Tony - > > I assume your "no" is to the question of whether Joe should > put all the proposed edits into the current draft, which then > we could advance or discuss further. > > How would you propose we proceed then? > > Ask Michel for a clarification? Or to have him do the edits himself > so that the WG can compare one and the other using diff(1) or > eyeballs? > Personally, I'm not sure that either is really necessary... do you > have problems with specific proposed edits? > > If your no is to a last call, rest assured that there has not > yet been a last call. This is merely a question of what should > be in the document when it undergoes last call, given a set of > edits. > > Sean. From owner-multi6@ops.ietf.org Thu Feb 7 17:46: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 RAA11876 for ; Thu, 7 Feb 2002 17:46:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16YxJ3-000E0X-00 for multi6-data@psg.com; Thu, 07 Feb 2002 14:46:17 -0800 Received: from evrtwa1-ar8-4-60-069-053.evrtwa1.vz.dsl.gtei.net ([4.60.69.53] helo=tndh.net) by psg.com with esmtp (Exim 3.33 #1) id 16YxJ3-000E0R-00 for multi6@ops.ietf.org; Thu, 07 Feb 2002 14:46:17 -0800 Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Thu, 07 Feb 2002 14:46:15 -0800 From: "Tony Hain" To: "Christian Huitema" , "Sean Doran" , , Subject: RE: please indicate whether you are content with the proposed edits [was: : (multi6) 53rd IETF Meeting] Date: Thu, 7 Feb 2002 14:46:16 -0800 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 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Actually I believe Christian has captured what I was looking for. Assuming the editor interprets concensus the same way he does here, I will change my response to Yes. Tony > -----Original Message----- > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > Sent: Thursday, February 07, 2002 1:31 PM > To: Tony Hain; Sean Doran; jabley@nlri.org; multi6@ops.ietf.org > Subject: RE: please indicate whether you are content with the proposed > edits [was: : (multi6) 53rd IETF Meeting] > > > I agree with Tony. Michel's e-mail is a list of options, and as such a > yes-no vote is meaningless. We need a consensus about which options to > retain. Michel in in latest summary (1.08, sent January 30) lists 10 > issues: > > Topics: > ------- > 1) About 3.1.2 > 2) About multihoming classes > 3) About DNS > 4) About EIDs > 5) About cooperation > 6) About 3.1.3 Performance > 7) About 3.2.5 > 8) About 4. Security Considerations > 9) comment on 3.2.2, and 3.2.3 > 10) Reverse Path Forwarding / filtering > > > From the discussion it seems that we have consensus on almost all > points: > > 2) Adopt the text proposed by Ran, complemented by the caveat proposed > by Rob. > 3) I believe there is consensus to add the text proposed by Ran. > 4) I seem to be the only one proposing this edit. I agree to drop it. > 5) Consensus to adopt the proposed edit. > 6) Rough consensus to remove the reference to "manual" > processing, i.e. > delete the last sentence in the paragraph > 7) Consensus to amend the text in the sense of a requirement > "to retain > the ability to extract routing information from the router". > 8) Adopt the text proposed by Rob Rockwell. > 9) Only Rob Rockell voiced an opinion. I think there is a default > consensus to keep the original text. > 10) Adopt the text that Ran proposed. > > The point of non-consensus is point 1, for which there are diverse > opinion, and perhaps a weak consensus to adopt a restricted version of > the requirement, i.e. state that sites must have a way to load balance > their "outbound" traffic, saying nothing about "inbound." > > If we want to vote, I suggest that we take separate votes on the first > proposed edit (the load balancing requirement), stating a preference, > and that we then take a block vote on the 9 others. > > My vote is "outbound only" on 1, Yes on 2-9. > > -- Christian Huitema From owner-multi6@ops.ietf.org Thu Feb 7 17:54:39 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12038 for ; Thu, 7 Feb 2002 17:54:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16YxQf-000ERW-00 for multi6-data@psg.com; Thu, 07 Feb 2002 14:54:09 -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.33 #1) id 16YxQR-000EQW-00 for multi6@ops.ietf.org; Thu, 07 Feb 2002 14:53:56 -0800 content-class: urn:content-classes:message Subject: RE: please indicate whether you are content with the proposed edits w/1.09 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 7 Feb 2002 14:53:50 -0800 Message-ID: <2B81403386729140A3A899A8B39B046406C2F9@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: please indicate whether you are content with the proposed edits w/1.09 thread-index: AcGwKg9TXwwUHVf1R+qFWoHShCiPKQAABWuA From: "Michel Py" To: "Tony Hain" , "Sean Doran" , , Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA12038 Would something like the table below help? If you think so, please check/send your vote (I voted for a few of you based on your comments). ---------------------------------------------------------------- Tentative summary of edits to the requirements documents v1.09 ---------------------------------------------------------------- +----------------------------------------+ ! Topic ! +---+---+---+---+---+---+---+---+---+----+ ! 1 ! 2 ! 3 ! 4 ! 5 ! 6 ! 7 ! 8 ! 9 ! 10 ! +-------------------+---+---+---+---+---+---+---+---+---+----+ ! Christian Huitema ! 4 ! 5 ! 3 ! 2 ! 1 ! ! ! ! ! ! +-------------------+---+---+---+---+---+---+---+---+---+----+ ! Michel Py ! 1 ! 5 ! 6 ! 2 ! 1 ! 1 ! ! ! 2 ! 4 ! +-------------------+---+---+---+---+---+---+---+---+---+----+ ! Rob Rockell ! 1 ! 5 ! 3 ! 2 ! ! 1 ! ! ! ! ! +-------------------+---+---+---+---+---+---+---+---+---+----+ ! RJ Atkinson ! ! ! 3 ! 2 ! 1 ! ! ! ! ! ! +-------------------+---+---+---+---+---+---+---+---+---+----+ ! Tony Hain ! 4 ! ! ! ! ! ! ! ! ! ! +-------------------+---+---+---+---+---+---+---+---+---+----+ ! Eliot Lear ! ! ! ! ! ! ! ! ! ! 4 ! +-------------------+---+---+---+---+---+---+---+---+---+----+ ! Brian Carpenter ! 4 ! ! ! ! ! ! ! ! ! ! +-------------------+---+---+---+---+---+---+---+---+---+----+ ! Vijay Gill ! ! ! ! ! ! 3 ! ! ! ! ! +-------------------+---+---+---+---+---+---+---+---+---+----+ ! ! ! ! ! ! ! ! ! ! ! ! +-------------------+---+---+---+---+---+---+---+---+---+----+ ! ! ! ! ! ! ! ! ! ! ! ! +-------------------+---+---+---+---+---+---+---+---+---+----+ ! ! ! ! ! ! ! ! ! ! ! ! +-------------------+---+---+---+---+---+---+---+---+---+----+ ! ! ! ! ! ! ! ! ! ! ! ! +-------------------+---+---+---+---+---+---+---+---+---+----+ ! Gathered 5 votes ! ! ! ! ! ! ! ! ! ! ! +-------------------+---+---+---+---+---+---+---+---+---+----+ Revision history: ----------------- 1.09 Feb-07-2002 Added 5. in Topic 1. 1.08 Jan-30-2002 Added Eliot Lear's comments for topic 10. 1.07 Jan-29-2002 Replaced topic 10 text with RJ Atkinson's text. 1.06 Jan-29-2002 Added new requirement (RPF). 1.05 Jan-21-2002 Added comments and text from Rob Rockell. 1.04 Jan-10-2002 Added comments from Brian Carpenter and Michel Py. 1.03 Jan-07-2002 Added text from Masataka Ohta. 1.02 Jan-05-2002 Added RJ Atkinson's comments. 1.01 Jan-03-2002 Added Eliot Lear's comments. 1.00 Jan-03-2002 Based on Christian Huitema's summary, Michel Py's comments. Topics: ------- 1) About 3.1.2 2) About multihoming classes 3) About DNS 4) About EIDs 5) About cooperation 6) About 3.1.3 Performance 7) About 3.2.5 8) About 4. Security Considerations 9) comment on 3.2.2, and 3.2.3 10) Reverse Path Forwarding / filtering 11) Time to go to last call 1) About 3.1.2 -------------- > Christian Huitema wrote: > Tony Hain sent several detailed comments, one of which generated a > strong debate, i.e. his objection to a part of section 3.1.2 that > stated that "a site MUST be able to distribute ... outbound traffic > between multiple transit providers," arguing that this was a site > policy matter. Possible modifications: 1. Leave 3.1.2 as-is. 2. Suppress 3.1.2. 3. Replace with following text from Masataka Ohta "A proposal MAY allow site weakly control inbound traffic but it MUST NOT increase the amount of global routing/signalling information traffic." 4. replace "both inbound and outbound" with "outbound". 5. Please send text. Opinions about it: Christian Huitema: I personally don't agree with Tony, and believe the solution must enable the site to balance traffic, and must also enable the site to not do so if it chooses. Michel Py: I am opposed to deleting the load balancing requirement, but removing the ingress part that stirred up all this discussion seems acceptable to me, if it does speed up the requirements draft process (although I would vote to keep it as it is now). Load balancing is one of the building blocks of multihoming. Brian Carpenter: What is clear is that no RFC (especially a requirements RFC) will settle this. It will be settled in the real world as IPv6 routing and load balancing practices emerge. I suggest that we either delete the language, or make it so vague as to avoid the argument. Deleting it seems simpler. #2 (after (4) was proposed): (4) above is a good compromise. Rob Rockell: Whether a site policy matter or not, the ability to load-balance must be retained, bi-directionally... Granted, this is tricky with global aggregation of ones prefixes, but it seems obvious that this requirement MUST stay. I vote to keep it as is. I like the verbage as is. Add yours here: 2) About multihoming classes ---------------------------- > Christian Huitema wrote: > I pointed out that different classes of solutions have different > scaling properties, which implies that the solution for multi-homing > my home network to cable and DSL may not be the same as the solution > for multi-homing Microsoft's network. Possible modifications: 1. Reference in new charter. 2. Add the following text from RJ Atkinson: "There might be more than one multihoming approach, provided the several approaches address different segments of the site multihoming problem." 3. Please send text. 4. Do nothing 5. Add the following text combined from RJ Atkison and Rob Rockell: "There might be more than one multihoming approach, provided the several approaches address different segments of the site multihoming problem. adopted solutions SHOULD attempt to cover as many multi-homing scenarios as possible". Opinions about it: Christian Huitema: Don't know whether that should be part of the requirement document. Michel Py: I think this should be part of the new charter rather than the requirements documents. The new charter could say something like: "Since it is unlikely that a proposal will cover all possible IPv6 multihomed sites, the working group will consider solutions targeted at a certain class of sites, and foster interoperability between the different proposed solutions". Rob Rockell: Multiple Solutions=ok. Just a management nightmare for IESG and our Chairs. Add verbage to draft to this effect, with MAY. However, something to the effect of "adopted solution SHOULD attempt to cover as many multi-homing scenarios as possible" (prettied up for RFC, of course, but you get the point). Add yours here: 3) About DNS ------------ > Christian Huitema wrote: > The discussion on renumbering and EID pointed out the need to add a > requirement that "the solution shall not depend on instant updating of > the domain name system", or if you prefer that "the solution should be > compatible with the observed dynamics of the current DNS system." Possible modifications: 1. Add the following requirement from Brian Carpenter: "The solutions must include an analysis of their effects, if any, on DNS updates, including consideration of load for the global updating of the DNS, and interactions with DNS TTL and caching". 2. Add the following requirement from Christian Huitema: "The solution should be compatible with the observed dynamics of the current DNS system". 3. Add the following requirement from RJ Atkinson: "The multihoming approach should be compatible with the current DNS system and technology xor the proposed approach needs to have convincing rationale on why a modified name resolution system to support that approach is readily deployable". 4. Please send text. 5. Concatenate 1 and 2. 6. Concatenate 1 and 3. 7. Do nothing. Opinions about it: Brian Carpenter: I think we have a missing requirement: The solutions must include an analysis of their effects, if any, on DNS updates, including consideration of load for the global updating of the DNS, and interactions with DNS TTL and caching. Michel Py: I am not sure that I would go as far as Christian does. Although I do agree that each solution MUST clearly document the impact on DNS, and I also think as he does that the solution should be compatible with DNS as we know it today, I do not think that we should block future developments based on a new breed of DNS. I like RJ's text. RJ Atkinson: The underlying issue really is not whether an approach compatible with the current DNS. The real issue is deployability. Something compatible with the current DNS (including DNS Dynamic Update, which is current technology) is more easily believed to be deployable. Something incompatible needs to have a convincing argument that the DNS- incompatible approach could realistically be built and deployed. Rob Rockell: In full concurence of RJA's proposed Text add (#3 above). Add yours here: 4) About EIDs ------------- > Christian Huitema wrote: > 4) Naïve implementations of EID and MIPv6 tend to introduce a > dependency on a name server or a home agent, i.e. another point of > failure. If people want to pursue this path, we should make sure > they do it the smart way, i.e. do not introduce a dependency on > another system beside the site-exit router and the multiple providers. > That may be worth spelling out in a requirement. Possible modifications: 1. Please send text 2. Do nothing Opinions about it: Michel Py: I think I will take the words out of Brian Carpenter's mouth here and say that there is no reason to specifically forbid it in the requirements draft. Let's not close doors we might need later. RJ Atkinson: Concur that there is no reason to add Christian's proposed text, because it closes options off prematurely. Rob Rockell: Agreed with Py and Atkinson. Add yours here: 5) About cooperation -------------------- > Michel Py proposes to change 3.2.6 Cooperation between Transit > Providers Possible modifications: 1. change 3.2.6 from: A multihoming strategy MAY require cooperation between a site and its transit providers, but MUST NOT require cooperation directly between the transit providers. to: A multihoming strategy MAY require cooperation between a | site and its transit providers, but MUST NOT require SITE-SPECIFIC cooperation directly between the transit providers. Inspired by Pekka Savola's definition of cooperation. 2. Please send text 3. Do nothing. Opinions about it: RJ Atkinson: Above proposal (1) seems reasonable. Rob Rockell: I am ok with Either. Proposal (1) above seems to keep things as flexible as possible. Add yours here: 6) About 3.1.3 Performance -------------------------- > For example, suppose site E obtains transit from transit providers > T1 and T2, and there is long-term congestion between T1 and T2. The > multihoming architecture MUST allow E to ensure that in normal > operation none of its traffic is carried over the congested > interconnection T1-T2. The process by which this is achieved MAY be > a manual one. > Eliot Lear wrote: > Why are we adding the caveat of the last sentence? Manual anything > is bad. Possible modifications: 1. Remove last sentence 2. Please send text 3. Do nothing Opinions about it: Vijay Gill: Unfortunately, while we may like to say manual anything is bad, there always will be circumstances where some tweaking will have to be done. There are just no getting around that fact. Michel Py: Although I agree with Vijay above, I think the last sentence should be removed. Let's try to define things right, if tweaking is needed we can close our eyes. Rob Rockell: Agree with Michel here. Add yours here: 7) About 3.2.5 -------------- > Eliot Lear Wrote: > Section 3.2.5 also sounds either redundant or unworkable. If what > you mean is that you must be able to retrieve routing information from > a router, then fine. If what you mean is that administrators should > be able to remotely manage and monitor end systems for purposes of > multihoming, that's a whole other kettle of fish. Possible modifications: 1. Please send text 2. Do nothing Opinions about it: Michel Py: I'm fine with the existing text, I read it as "you must be able to retrieve routing information from a router". Rob Rockell: I would be more explicit here. If the requirement is to retain the ability to extract routing information from the router, then explicitly say that. Add yours here: 8) About 4. Security Considerations ----------------------------------- > Eliot Lear Wrote: > This seems overly broad. I think what you mean is the following: It > MUST be theoretically possible to deploy a multihomed site that is no > less secure than a single-homed site. Anytime a routing protocol is > involved there are bound to be more sensitive points of attack (like > DDOS, for instance). Just like anything else, multihoming can be > done poorly. Possible modifications: 1. Please send text 2. Do nothing 3. Replace with the following text inspired by Rob Rockell "An IPv6 multihomed site MUST NOT be more vulnerable to security breaches and security problems than a traditionaly IPv4 multi-homed site". Opinions about it: Vijay Gill: I'm fine with this. Michel Py: I'm fine with the existing text. #2 (after Rob's contribution): Favors (3) above. Rob Rockell: The addition of dynamic routing protocols (like BGP in today's IPv4 world) makes ALL multi-homed sites more susceptible to DOS or security problems than singly-homed sites (think about faking BGP packets). Might be nice to make this more explicitly stated that the topology and the mechanism MUST NOT make the multi-homed site more vulnerable to security problems than a traditionaly IPv4 multi-homed site.... Add yours here: 9. Comment on 3.2.2 and 3.2.3. ------------------------------ > Rob Rockell wrote: > The concept of "minor" change is too qualitative for IETF... Something > along the lines of RJA's comments about "any major structural change > to router implementation or host stack MUST have convincing rationale > to justify it, and SHOULD be implemented as separate functions added > to the existing functions" Not sure of this text, but some bounds > should be put on the requirement, while allowing the possibility to > exist for something radical. We don't want to hold back the right > solution because people are lazy to rebuild implementations.. :) Possible modifications: 1. Please send text 2. Do nothing Opinions about it: Add yours here: 10. Reverse Path Forwarding / filtering --------------------------------------- > Michel Py proposes to add a new requirement [original text] "IPv6 multihoming solutions MUST be compatible with sites that implement RPF checks or filtering that prevents traffic to be sent back from a different interface it came in." After reading Ran's text Michel decides to withdraw his and support Ran's text that is a lot better. Text from RJ Atkinson: "IPv6 multihoming solutions MUST NOT preclude filtering out packets with obviously forged Source IP Address values at the administrative boundary of the multi-homed site. The details of how such filtering is implemented MAY vary depending on the IPv6 multihoming solution, provided there is some mechanism for performing such filtering that works with the multihoming solution proposed." Possible modifications: 1. Please send text 2. Do nothing 3. add new requirement per RJ Atkinson's text. 4. add new requirement without the word "obviously" Opinions about it: RJ Atkinson: The above text [refers to Michel's original proposal] is too specific and thus unduly narrows the range of solutions to the underlying issue. The underlying issue in this case is blocking obviously forged source addresses from leaving/entering an given administrative domain. Michel Py: Concur with Ran. Eliot Lear: I agree with Ran's comment, with the exception that I would strike the word "obviously". If you can tell that it's forged, whether it's obvious or not, that's good enough for me ;-) Add yours here: From owner-multi6@ops.ietf.org Fri Feb 8 03:27:27 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01073 for ; Fri, 8 Feb 2002 03:27:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Z6Ly-000FEA-00 for multi6-data@psg.com; Fri, 08 Feb 2002 00:25:54 -0800 Received: from internet-gateway2-x.zurich.ibm.com ([195.212.119.243] helo=internet-gateway2.zurich.ibm.com) by psg.com with esmtp (Exim 3.33 #1) id 16Z6Lx-000FE1-00 for multi6@ops.ietf.org; Fri, 08 Feb 2002 00:25:53 -0800 Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id JAA13084; Fri, 8 Feb 2002 09:25:45 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA42394 from ; Fri, 8 Feb 2002 09:25:42 +0100 Message-Id: <3C638B84.D017AB2E@hursley.ibm.com> Date: Fri, 08 Feb 2002 09:25:40 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Christian Huitema Cc: Tony Hain , Sean Doran , jabley@nlri.org, multi6@ops.ietf.org Subject: Re: please indicate whether you are content with the proposed edits [was: : (multi6) 53rd IETF Meeting] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I agree with Christian. I'd also like to see a complete new draft ASAP, since it will be less confusing than this discussion. Brian Christian Huitema wrote: > > I agree with Tony. Michel's e-mail is a list of options, and as such a > yes-no vote is meaningless. We need a consensus about which options to > retain. Michel in in latest summary (1.08, sent January 30) lists 10 > issues: > > Topics: > ------- > 1) About 3.1.2 > 2) About multihoming classes > 3) About DNS > 4) About EIDs > 5) About cooperation > 6) About 3.1.3 Performance > 7) About 3.2.5 > 8) About 4. Security Considerations > 9) comment on 3.2.2, and 3.2.3 > 10) Reverse Path Forwarding / filtering > > >From the discussion it seems that we have consensus on almost all > points: > > 2) Adopt the text proposed by Ran, complemented by the caveat proposed > by Rob. > 3) I believe there is consensus to add the text proposed by Ran. > 4) I seem to be the only one proposing this edit. I agree to drop it. > 5) Consensus to adopt the proposed edit. > 6) Rough consensus to remove the reference to "manual" processing, i.e. > delete the last sentence in the paragraph > 7) Consensus to amend the text in the sense of a requirement "to retain > the ability to extract routing information from the router". > 8) Adopt the text proposed by Rob Rockwell. > 9) Only Rob Rockell voiced an opinion. I think there is a default > consensus to keep the original text. > 10) Adopt the text that Ran proposed. > > The point of non-consensus is point 1, for which there are diverse > opinion, and perhaps a weak consensus to adopt a restricted version of > the requirement, i.e. state that sites must have a way to load balance > their "outbound" traffic, saying nothing about "inbound." > > If we want to vote, I suggest that we take separate votes on the first > proposed edit (the load balancing requirement), stating a preference, > and that we then take a block vote on the 9 others. > > My vote is "outbound only" on 1, Yes on 2-9. > > -- Christian Huitema From owner-multi6@ops.ietf.org Fri Feb 8 05:24:26 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02519 for ; Fri, 8 Feb 2002 05:24:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Z8Bo-000Kur-00 for multi6-data@psg.com; Fri, 08 Feb 2002 02:23:32 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.33 #1) id 16Z8Bn-000Kul-00 for multi6@ops.ietf.org; Fri, 08 Feb 2002 02:23:31 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g18AMm706105; Fri, 8 Feb 2002 12:22:48 +0200 Date: Fri, 8 Feb 2002 12:22:47 +0200 (EET) From: Pekka Savola To: Coene Lode cc: "Transport Area wg (E-mail)" , "SIGTRAN (E-mail)" , "'multi6@ops.ietf.org'" Subject: Re: SCTP multihoming issues draft In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 6 Feb 2002, Coene Lode wrote: > Previous week, the draft on SCTP multihoming issues was published. > > The draft can be found at the IETF draft directory: > Multihoming issues in the Stream Control Transmission Protocol > > > If by then end of next week, no further issues have been identified, then I > would ask for this draft to be moved to informational. This is not a multi6 issue as such, as SCTP does not really provide site multihoming (however, SCTP may enable site multihoming with multiple addresses per node, so this may be in the scope of wg even though it most probably doesn't meet the requirements in the requirements document). But anyway, I read the draft on a flight. A few comments: (first a few editorial nits) Abstract This document describes issues of the Stream Control Transmission Protocol (SCTP)[RFC2960] in regard to multihoming on the Internet. It explores cases where through situations in the internet, single points-of-failure can occur even when using multihoming and what the impact is of multihoming on the host routing tables. ==> what are "host routing tables" ? 1 Introduction SCTP[RFC2960] is a transport protocol that uses multihoming. This draft is a attempt at identifying the issues that may arise in the layers below SCTP when multihoming is used by SCTP. Some issues are already being addresses in various other WG and this document will try to highlight them. If the solutions would resolve the issues presented in this document then the problem presented is no longer an issue. This document will also try to gauge the effectiveness of the present multihoming architecture. ==> s/a attempt/an attempt/, s/WG/WGs/ 2.1 Interaction with routing Under the assumption that every IP address will have a different, seperate paths towards the remote endpoint, (this is the responsibility of the routing protocols or of manual configuration) ==> s/paths/path/, s/endpoint,/endpoint/ It might be usefull to explore ways where no routing tables are ==> s/usefull/useful/ ==> on a generic note: it seems to me there is a need for routing tables on hosts only if one wants to optimize the paths: one is used by default, and if it fails, just (try to) switch to the next one, right? 2.3 SCTP multihoming and Network Adress Translators(NAT) ==> this very same problem will come up with single-homed NAT's too (need to be able to do ALG translation), right? Can be deleted. 2.4 SCTP multihoming and IPsec A much better implementation approach is to simply use groups of addresses instead of single ones. ==> note: all SCTP+IPSEC implementations would have to do this to be compatible, it appears. 3 Security considerations As such the use of multihoming does not provide security risks. The solutions needed for allowing multihoming may provide security risks. ==> this seems like a circular argument: SCTP is such a solution. ==> consider the security of introducing new addresses to the association and capturing traffic: granted, this is an SCTP concern but is highlighted by multihoming. This cannot be handwaved by IPSEC unless IPSEC is required for all SCTP. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-multi6@ops.ietf.org Fri Feb 8 08:15: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 IAA05464 for ; Fri, 8 Feb 2002 08:15:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16ZAqj-0003GQ-00 for multi6-data@psg.com; Fri, 08 Feb 2002 05:13:57 -0800 Received: from viap111.atea.be ([194.78.143.111] helo=hrtades9.atea.be) by psg.com with esmtp (Exim 3.33 #1) id 16ZAqi-0003Fm-00 for multi6@ops.ietf.org; Fri, 08 Feb 2002 05:13:56 -0800 Received: from hrtades10.atea.be (siemens.atea.be [139.10.143.141]) by hrtades9.atea.be with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DF4YR84T; Fri, 8 Feb 2002 14:13:45 +0100 Received: by siemens.atea.be with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Feb 2002 14:14:09 +0100 Message-ID: From: Coene Lode To: "'Pekka Savola'" , Coene Lode , "Andreas Jungmayer (E-mail)" Cc: "Transport Area wg (E-mail)" , "SIGTRAN (E-mail)" , "'multi6@ops.ietf.org'" Subject: RE: SCTP multihoming issues draft Date: Fri, 8 Feb 2002 14:11:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-multi6@ops.ietf.org Precedence: bulk I'll reply to all mailing lists (..crosssposting be dammed...) > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: vrijdag 8 februari 2002 11:23 > To: Coene Lode > Cc: Transport Area wg (E-mail); SIGTRAN (E-mail); > 'multi6@ops.ietf.org' > Subject: Re: SCTP multihoming issues draft > > > On Wed, 6 Feb 2002, Coene Lode wrote: > > Previous week, the draft on SCTP multihoming issues was published. > > > > The draft can be found at the IETF draft directory: > > Multihoming issues in the Stream Control Transmission Protocol > > > > > > If by then end of next week, no further issues have been > identified, then I > > would ask for this draft to be moved to informational. > > This is not a multi6 issue as such, as SCTP does not really > provide site > multihoming (however, SCTP may enable site multihoming with multiple > addresses per node, so this may be in the scope of wg even > though it most > probably doesn't meet the requirements in the requirements document). Not sure that we are part of the solution space. Am waiting for a release of the requirements document to see if any of the requirements make live hard for SCTP multihoming. > > But anyway, I read the draft on a flight. A few comments: > > (first a few editorial nits) > > Abstract > > This document describes issues of the Stream Control Transmission > Protocol (SCTP)[RFC2960] in regard to multihoming on the > Internet. It explores cases where through situations in the > internet, single points-of-failure can occur even when using > multihoming and what the impact is of multihoming on the host > routing tables. > > ==> what are "host routing tables" ? selecting the correct outgoing link is a routing descision. See also Andreas comments (with which I agree). > > 1 Introduction > > > SCTP[RFC2960] is a transport protocol that uses > multihoming. This > draft is a attempt at identifying the issues that may > arise in the > layers below SCTP when multihoming is used by SCTP. Some > issues are > already being addresses in various other WG and this document will > try to highlight them. If the solutions would resolve the issues > presented in this document then the problem presented is no longer > an issue. This document will also try to gauge the > effectiveness of > the present multihoming architecture. > > ==> s/a attempt/an attempt/, s/WG/WGs/ Fixed > > 2.1 Interaction with routing > > Under the assumption that every IP address will have a different, > seperate paths towards the remote endpoint, (this is the > responsibility of the routing protocols or of manual > configuration) > > ==> s/paths/path/, s/endpoint,/endpoint/ fixed > > It might be usefull to explore ways where no routing tables are > > ==> s/usefull/useful/ fixed > > ==> on a generic note: it seems to me there is a need for > routing tables > on hosts only if one wants to optimize the paths: one is used > by default, > and if it fails, just (try to) switch to the next one, right? > See previous remark on routing tables. > 2.3 SCTP multihoming and Network Adress Translators(NAT) > > ==> this very same problem will come up with single-homed > NAT's too (need > to be able to do ALG translation), right? Can be deleted. The single home case is rather straight forward(and works nicely together with NAT's as Andreas points out), but it is a multihomed SCTP association which will make live (very) difficult for NAT boxes, esspecially if the NAT box doesn't want to be the single point of failure. So this paragraph is rigth to the point. What this paragraph says(between the lines) is: do not use NAT boxes if you ever want true multihoming. > > 2.4 SCTP multihoming and IPsec > > A much better > implementation approach is to simply use groups of > addresses instead > of single ones. > > ==> note: all SCTP+IPSEC implementations would have to do this to be > compatible, it appears. We'll add a note(above is a good line). > > 3 Security considerations > > As such the use of multihoming does not provide security > risks. The > solutions needed for allowing multihoming may provide security > risks. > > ==> this seems like a circular argument: SCTP is such a solution. I'll remove the first sentence. Then it isn't a circular argument. The second sentence would then say that SCTP migth provide security risks when using multihoming(but we don't know them yet) > > ==> consider the security of introducing new addresses to the > association > and capturing traffic: granted, this is an SCTP concern but > is highlighted > by multihoming. This cannot be handwaved by IPSEC unless IPSEC is > required for all SCTP. adding(or removing) addresses to a association is not part of the baseline SCTP spec. That is a addition in the works (see http://search.ietf.org/internet-drafts/draft-ietf-tsvwg-addip-sctp-04.txt This document only talks about the present SCTP capabilities. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > Thanks for the remarks. They have been helpfull. yours sincerly, Lode Coene From owner-multi6@ops.ietf.org Fri Feb 8 10:02: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 KAA09723 for ; Fri, 8 Feb 2002 10:02:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16ZCXI-0009G9-00 for multi6-data@psg.com; Fri, 08 Feb 2002 07:02:00 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.33 #1) id 16ZCXH-0009FC-00 for multi6@ops.ietf.org; Fri, 08 Feb 2002 07:01:59 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g18F1ED08259; Fri, 8 Feb 2002 17:01:14 +0200 Date: Fri, 8 Feb 2002 17:01:13 +0200 (EET) From: Pekka Savola To: Coene Lode cc: "Andreas Jungmayer (E-mail)" , "Transport Area wg (E-mail)" , "SIGTRAN (E-mail)" , "'multi6@ops.ietf.org'" Subject: RE: SCTP multihoming issues draft In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 8 Feb 2002, Coene Lode wrote: > > This document describes issues of the Stream Control Transmission > > Protocol (SCTP)[RFC2960] in regard to multihoming on the > > Internet. It explores cases where through situations in the > > internet, single points-of-failure can occur even when using > > multihoming and what the impact is of multihoming on the host > > routing tables. > > > > ==> what are "host routing tables" ? > > selecting the correct outgoing link is a routing descision. See also Andreas > comments (with which I agree). "the routing table on hosts" would be better, perhaps. > > ==> on a generic note: it seems to me there is a need for routing > > tables on hosts only if one wants to optimize the paths: one is used > > by default, and if it fails, just (try to) switch to the next one, > > right? > > > > See previous remark on routing tables. See my reply to Andreas. (note to others: multi6 was stripped from Cc:). In short, routing table is naturally required, but the draft talks about the need to "download" a fuller table from edge routers on hosts. IMO this is unnecessary. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-multi6@ops.ietf.org Fri Feb 8 10:30:45 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11179 for ; Fri, 8 Feb 2002 10:30:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16ZCyf-000AxQ-00 for multi6-data@psg.com; Fri, 08 Feb 2002 07:30:17 -0800 Received: from buffoon.automagic.org ([208.185.30.208]) by psg.com with smtp (Exim 3.33 #1) id 16ZCye-000AxK-00 for multi6@ops.ietf.org; Fri, 08 Feb 2002 07:30:16 -0800 Received: (qmail 48567 invoked by uid 1000); 8 Feb 2002 15:30:14 -0000 Date: Fri, 8 Feb 2002 10:30:14 -0500 From: Joe Abley To: Brian E Carpenter Cc: Christian Huitema , Tony Hain , Sean Doran , multi6@ops.ietf.org Subject: Re: please indicate whether you are content with the proposed edits [was: : (multi6) 53rd IETF Meeting] Message-ID: <20020208103013.E24173@buffoon.automagic.org> References: <3C638B84.D017AB2E@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C638B84.D017AB2E@hursley.ibm.com> User-Agent: Mutt/1.3.22.1i Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, Feb 08, 2002 at 09:25:40AM +0100, Brian E Carpenter wrote: > I agree with Christian. I'd also like to see a complete new draft ASAP, > since it will be less confusing than this discussion. I also think that incorporating my interpretation of michael's edit list into a fresh rev would give us something concrete to argue about. Does that make five? Joe From owner-multi6@ops.ietf.org Sat Feb 9 10:26:11 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16108 for ; Sat, 9 Feb 2002 10:26:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16ZZL8-000MpY-00 for multi6-data@psg.com; Sat, 09 Feb 2002 07:22:58 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.33 #1) id 16ZZL7-000MpR-00 for multi6@ops.ietf.org; Sat, 09 Feb 2002 07:22:57 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g19FNnK71365; Sat, 9 Feb 2002 16:23:50 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Sat, 9 Feb 2002 16:23:48 +0100 (CET) From: Iljitsch van Beijnum To: Michel Py cc: Subject: RE: please indicate whether you are content with the proposed edits w/1.09 In-Reply-To: <2B81403386729140A3A899A8B39B046406C2F9@server2000.arneill-py.sacramento.ca.us> Message-ID: <20020209152607.I64519-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id KAA16108 I just read 3 months worth of email on this list... Is draft-ietf-multi6-multihoming-requirements-02.txt the most recent text? On Thu, 7 Feb 2002, Michel Py wrote: > 1) About 3.1.2 > -------------- > > Christian Huitema wrote: > > Tony Hain sent several detailed comments, one of which generated a > > strong debate, i.e. his objection to a part of section 3.1.2 that > > stated that "a site MUST be able to distribute ... outbound traffic > > between multiple transit providers," arguing that this was a site > > policy matter. > Possible modifications: > 1. Leave 3.1.2 as-is. > 2. Suppress 3.1.2. > 3. Replace with following text from Masataka Ohta > "A proposal MAY allow site weakly control inbound traffic but it > MUST NOT increase the amount of global routing/signalling > information traffic." > 4. replace "both inbound and outbound" with "outbound". > 5. Please send text. A situation where the receiving site has absolutely no say over which interface traffic comes in over wouldn't be acceptable: a slow backup connection may receive all the traffic. Performance would be worse with than without the backup. I'd change it to: By multihoming, a site MUST be able to distribute both inbound and outbound traffic between multiple transit providers, such that the majority of traffic flows over the desired transit provider. More fine-grained control SHOULD be available. This requirement is for concurrent use of the multiple transit providers, not just the usage of one provider over one interval of time and another provider over a different interval. > 2) About multihoming classes > ---------------------------- > > Christian Huitema wrote: > > I pointed out that different classes of solutions have different > > scaling properties, which implies that the solution for multi-homing > > my home network to cable and DSL may not be the same as the solution > > for multi-homing Microsoft's network. [...] > Add yours here: Obviously, Microsoft can afford to multihome, whatever we do. Any solution that doesn't allow at least a million multihomers with current hardware and linear growth after that isn't good enough, and more multihomers now coupled with less growth in hardware requirements is better. > 3) About DNS > ------------ > > Christian Huitema wrote: > > The discussion on renumbering and EID pointed out the need to add a > > requirement that "the solution shall not depend on instant updating of > > the domain name system", or if you prefer that "the solution should be > > compatible with the observed dynamics of the current DNS system." > Possible modifications: > 1. Add the following requirement from Brian Carpenter: > "The solutions must include an analysis of their effects, if any, on > DNS updates, including consideration of load for the global updating of > the DNS, and interactions with DNS TTL and caching". > 2. Add the following requirement from Christian Huitema: > "The solution should be compatible with the observed dynamics of the > current DNS system". > 3. Add the following requirement from RJ Atkinson: > "The multihoming approach should be compatible with the current DNS > system and technology xor the proposed approach needs to have convincing > rationale on why a modified name resolution system to support that > approach is readily deployable". > 4. Please send text. "The solution SHALL NOT depend on dynamic DNS updates." I see no harm in using the DNS to find out static information which may be required at the beginning of a session, but the DNS must be able to cache, otherwise the system will break down. > 4) About EIDs > ------------- > > Christian Huitema wrote: > > 4) Naïve implementations of EID and MIPv6 tend to introduce a > > dependency on a name server or a home agent, i.e. another point of > > failure. If people want to pursue this path, we should make sure > > they do it the smart way, i.e. do not introduce a dependency on > > another system beside the site-exit router and the multiple providers. > > That may be worth spelling out in a requirement. > Possible modifications: > 1. Please send text > 2. Do nothing > Opinions about it: > Michel Py: > I think I will take the words out of Brian Carpenter's mouth here and > say that there is no reason to specifically forbid it in the > requirements draft. Let's not close doors we might need later. > RJ Atkinson: > Concur that there is no reason to add Christian's proposed text, because > it closes options off prematurely. > Rob Rockell: Agreed with Py and Atkinson. > Add yours here: Good point. Still, we don't want SINGLE points of failure. So if any dependency should be necessary, it must relate to something that is very robust in its own right (without depending on multihoming), such as the DNS system. > "IPv6 multihoming solutions MUST NOT preclude filtering out packets with > obviously forged Source IP Address values at the administrative boundary > of the multi-homed site. The details of how such filtering is implemented > MAY vary depending on the IPv6 multihoming solution, provided there is > some mechanism for performing such filtering that works with the > multihoming solution proposed." We shouldn't refer to the RPF check since that one doesn't always work (asymmetric routing). A side note: it occurs to me when a user holds an IP address, he has the "right" to use it, even over a connection which wouldn't normally be associated with this IP address. But we need filtering to prevent address spoofing. The solution could be a protocol the user could use to show ISP B he got ISP A's address legitemately so he can use it as the source address for packets going out over B. Shouldn't we say a bit more about mobility? It pretty much solves a lot of the problems we need to solve for a host-based solution, but it can't work around failures to the degree we need. And how about this: "If there is any processing associated with being multihomed or interacting with multihomed hosts, it SHOULD be possible to offload this processing to one or more proxy devices in such a manner a current IPv6 implementation can be multihomed and/or interact with multihomed hosts with full multihoming benefits. If several proxy devices are used, failure of a single device MUST NOT terminate ongoing communication." Iljitsch van Beijnum From owner-multi6@ops.ietf.org Mon Feb 11 10:55:46 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06945 for ; Mon, 11 Feb 2002 10:55:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16aIkL-000PMc-00 for multi6-data@psg.com; Mon, 11 Feb 2002 07:52:01 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.33 #1) id 16aIkK-000PMP-00 for multi6@ops.ietf.org; Mon, 11 Feb 2002 07:52:00 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g1BFr1n74390 for ; Mon, 11 Feb 2002 16:53:01 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Mon, 11 Feb 2002 16:53:01 +0100 (CET) From: Iljitsch van Beijnum To: Subject: BALTS: Better At Least Than Singlehomed Message-ID: <20020211160718.S64519-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk Since "the" solution seems more elusive than ever, maybe this is the time to get a "better than nothing" effort off the ground. The idea is very simple: when everything is working, send regular packets and do everything just like in a single homed environment. As soon as the source host learns it can no longer send information to the destination host using regular means, it starts encapsulating the packets into IP packets. It then transmits these packets using a different source interface, gateway and/or destination address. The exact interface, gateway and destination address choices are determined by local configuration or heuristics. At the destination address, the packets are de-encapsulated and processed like regularly received packets. In essence, this means creating on demand dynamic tunnels. A good way to publish secondary addresses would be in a new resource record in the ip6.int domain, or as an IP option in the first packet of a stream. The main problem would be detecting failures. If source address filtering is configured correctly (or rather: in the way that suites us best) local link failures will generate a "administratively blocked" ICMP message, which can be used to trigger a change of source adddress. Host unreachables can trigger a change of destination address, but there are many failure modes that fail to provide these. Advantages: * simple * changes limited to IP layer, no higher layer changes necessary * a lot of potential for improvement down the road Iljitsch van Beijnum From owner-multi6@ops.ietf.org Mon Feb 11 11:15: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 LAA07651 for ; Mon, 11 Feb 2002 11:15:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16aJ75-0000GX-00 for multi6-data@psg.com; Mon, 11 Feb 2002 08:15:31 -0800 Received: from h00d0b71b83ad.ne.mediaone.net ([65.96.132.240] helo=perdition.linnaean.org) by psg.com with esmtp (Exim 3.33 #1) id 16aJ74-0000GP-00 for multi6@ops.ietf.org; Mon, 11 Feb 2002 08:15:30 -0800 Received: by perdition.linnaean.org (Postfix, from userid 31013) id 7E82D1BA15; Mon, 11 Feb 2002 11:15:29 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Iljitsch van Beijnum Cc: Subject: BALTS: Better At Least Than Singlehomed In-Reply-To: <20020211160718.S64519-100000@sequoia.muada.com> References: <20020211160718.S64519-100000@sequoia.muada.com> X-Mailer: VM 6.34 under Emacs 20.7.1 Reply-To: Daniel Hagerty From: Daniel Hagerty Date: Mon, 11 Feb 2002 11:15:29 -0500 Message-Id: <20020211161529.7E82D1BA15@perdition.linnaean.org> Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > At the destination address, the packets are de-encapsulated and processed > like regularly received packets. Your proposal is missing a "security" analysis. If you spend a few moments on that, you're going to note some "issues" with this approach. From owner-multi6@ops.ietf.org Mon Feb 11 12:02:55 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10313 for ; Mon, 11 Feb 2002 12:02:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16aJpf-0001xP-00 for multi6-data@psg.com; Mon, 11 Feb 2002 09:01:35 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.33 #1) id 16aJpe-0001xJ-00 for multi6@ops.ietf.org; Mon, 11 Feb 2002 09:01:34 -0800 Subject: RE: BALTS: Better At Least Than Singlehomed Date: Mon, 11 Feb 2002 09:01:32 -0800 Message-ID: <2B81403386729140A3A899A8B39B046406C312@server2000.arneill-py.sacramento.ca.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: BALTS: Better At Least Than Singlehomed Thread-Index: AcGzFgWR+AparlerThmSMCUUjg/61AAB2MYg From: "Michel Py" content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 To: "Iljitsch van Beijnum" , Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA10313 > Iljitsch van Beijnum wrote: > Since "the" solution seems more elusive than ever, maybe > this is the time to get a "better than nothing" effort > off the ground. It certainly does not hurt talking about it. A bad solution is better than no solution. Michel. From owner-multi6@ops.ietf.org Mon Feb 11 12:16:45 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11208 for ; Mon, 11 Feb 2002 12:16:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16aK48-0002WM-00 for multi6-data@psg.com; Mon, 11 Feb 2002 09:16:32 -0800 Received: from mailc.microsoft.com ([131.107.3.121] helo=mail5.microsoft.com) by psg.com with esmtp (Exim 3.33 #1) id 16aK47-0002WC-00 for multi6@ops.ietf.org; Mon, 11 Feb 2002 09:16:32 -0800 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.148]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.4617); Mon, 11 Feb 2002 09:16:08 -0800 Received: from 157.54.6.197 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 11 Feb 2002 09:16:30 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 11 Feb 2002 09:16:08 -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.2966); Mon, 11 Feb 2002 09:16:07 -0800 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0); Mon, 11 Feb 2002 09:13:58 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6132.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: BALTS: Better At Least Than Singlehomed Date: Mon, 11 Feb 2002 09:13:57 -0800 Message-ID: Thread-Topic: BALTS: Better At Least Than Singlehomed Thread-Index: AcGzFgWR+AparlerThmSMCUUjg/61AAB2MYgAACPyoA= From: "Christian Huitema" To: "Michel Py" , "Iljitsch van Beijnum" , X-OriginalArrivalTime: 11 Feb 2002 17:13:58.0216 (UTC) FILETIME=[7DFCC480:01C1B31F] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA11208 > > Iljitsch van Beijnum wrote: > > Since "the" solution seems more elusive than ever, maybe > > this is the time to get a "better than nothing" effort > > off the ground. > > It certainly does not hurt talking about it. A bad > solution is better than no solution. Actually, for better or worse, this group is bound to follow process, which means completing the requirements' draft before considering solutions. -- Christian Huitema From owner-multi6@ops.ietf.org Mon Feb 11 14:39:37 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15041 for ; Mon, 11 Feb 2002 14:39:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16aMFf-0007Yg-00 for multi6-data@psg.com; Mon, 11 Feb 2002 11:36:35 -0800 Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by psg.com with esmtp (Exim 3.33 #1) id 16aMFe-0007Ya-00 for multi6@ops.ietf.org; Mon, 11 Feb 2002 11:36:34 -0800 Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g1BJaOZ04220 for ; Mon, 11 Feb 2002 11:36:25 -0800 (PST) Received: from SBRIM-W2K (sjc-vpn2-442.cisco.com [10.21.113.186]) by airborne.cisco.com (Mirapoint) with SMTP id AAN25062; Mon, 11 Feb 2002 11:36:33 -0800 (PST) Received: by SBRIM-W2K (sSMTP sendmail emulation); Mon, 11 Feb 2002 14:36:30 -0500 Date: Mon, 11 Feb 2002 14:36:30 -0500 From: Scott Brim To: multi6@ops.ietf.org Subject: Re: BALTS: Better At Least Than Singlehomed Message-ID: <20020211143630.I1740@SBRIM-W2K> Mail-Followup-To: Scott Brim , multi6@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, Feb 11, 2002 04:53:01PM +0100, Iljitsch van Beijnum wrote: > As soon as the source host learns it can no longer send information to > the destination host using regular means, it starts encapsulating the > packets into IP packets. It then transmits these packets using a > different source interface, gateway and/or destination address. The > exact interface, gateway and destination address choices are > determined by local configuration or heuristics. Compare draft-moskowitz-hip-* From owner-multi6@ops.ietf.org Tue Feb 12 03:26:39 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06078 for ; Tue, 12 Feb 2002 03:26:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16aYF2-000DgF-00 for multi6-data@psg.com; Tue, 12 Feb 2002 00:24:44 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.33 #1) id 16aYF1-000Dg9-00 for multi6@ops.ietf.org; Tue, 12 Feb 2002 00:24:44 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g1C8Phs75964; Tue, 12 Feb 2002 09:25:43 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Tue, 12 Feb 2002 09:25:43 +0100 (CET) From: Iljitsch van Beijnum To: Daniel Hagerty cc: Subject: Re: BALTS: Better At Least Than Singlehomed In-Reply-To: <20020211161529.7E82D1BA15@perdition.linnaean.org> Message-ID: <20020212090742.N64519-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk First, thanks to all for replying so quickly. On Mon, 11 Feb 2002, Daniel Hagerty wrote: > > At the destination address, the packets are de-encapsulated and processed > > like regularly received packets. > Your proposal is missing a "security" analysis. If you spend a > few moments on that, you're going to note some "issues" with this > approach. If a system de-encapsulates tunnelled packets without prior tunnel configuration, this could be used by attackers to bypass firewalls. This can be remedied by either: 1. Disallow the encapsulation protocol, so tunnelled packets can't enter (or leave) the system, 2. De-encapsulate incoming packets first, then apply filters / first apply filters and then perform the multihoming processing for outgoing packets, or 3. Look inside the encapsulating packet and apply filter rules to the encapsulated packet. Discovery of the backup address through the DNS wouldn't be as secure as it could be, but since single homed communication depends on the DNS in the first place, I don't see this as a fatal flaw. A good later addition would be a mechanism for hosts to determine the reachability status and other information (such as backup addresses) dynamically and in a secure way. Did you have any other issues in mind? Iljitsch van Beijnum From owner-multi6@ops.ietf.org Tue Feb 12 03:26:42 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06090 for ; Tue, 12 Feb 2002 03:26:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16aYGQ-000Dic-00 for multi6-data@psg.com; Tue, 12 Feb 2002 00:26:10 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.33 #1) id 16aYGP-000DiS-00 for multi6@ops.ietf.org; Tue, 12 Feb 2002 00:26:09 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g1C8R7A75968; Tue, 12 Feb 2002 09:27:07 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Tue, 12 Feb 2002 09:27:07 +0100 (CET) From: Iljitsch van Beijnum To: Scott Brim cc: Subject: Re: BALTS: Better At Least Than Singlehomed In-Reply-To: <20020211113910.A1740@SBRIM-W2K> Message-ID: <20020212092549.D64519-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 11 Feb 2002, Scott Brim wrote: > > As soon as the source host learns it can no longer send information to the > > destination host using regular means, it starts encapsulating the packets > > into IP packets. It then transmits these packets using a different source > > interface, gateway and/or destination address. The exact interface, > > gateway and destination address choices are determined by local > > configuration or heuristics. > Compare draft-moskowitz-hip-* Hm, this seems to be something quite different: "This memo describes the Host Identity Payload (HIP) described in the HIP architecture [HIPARCH] and the Host Layer Protocol (HLP) that uses it to establish a rapid authentication between two hosts and continuity between those hosts independent of the Networking Layer." Iljitsch van Beijnum From owner-multi6@ops.ietf.org Tue Feb 12 03:35: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 DAA06177 for ; Tue, 12 Feb 2002 03:35:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16aYP7-000EGK-00 for multi6-data@psg.com; Tue, 12 Feb 2002 00:35:09 -0800 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.33 #1) id 16aYP6-000EGE-00 for multi6@ops.ietf.org; Tue, 12 Feb 2002 00:35:08 -0800 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g1C8a6Z75982; Tue, 12 Feb 2002 09:36:06 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Tue, 12 Feb 2002 09:36:06 +0100 (CET) From: Iljitsch van Beijnum To: Christian Huitema cc: Michel Py , Subject: RE: BALTS: Better At Least Than Singlehomed In-Reply-To: Message-ID: <20020212092728.D64519-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 11 Feb 2002, Christian Huitema wrote: > > > Since "the" solution seems more elusive than ever, maybe > > > this is the time to get a "better than nothing" effort > > > off the ground. > > It certainly does not hurt talking about it. A bad > > solution is better than no solution. The solution is not supposed to be "bad", just limited. If we can get basic host multihoming off the ground, we can then explore mechanisms to improve on it, such as combining it with Mobile IP, implement multihoming proxy agents to multihome entire sites in one go, and find good ways to detect reachability information. > Actually, for better or worse, this group is bound to follow process, > which means completing the requirements' draft before considering > solutions. I by no means meant to yell "stop the presses" on the requirements draft. Iljitsch van Beijnum From owner-multi6@ops.ietf.org Tue Feb 12 06:22:10 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07855 for ; Tue, 12 Feb 2002 06:22:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16aazN-000Lvw-00 for multi6-data@psg.com; Tue, 12 Feb 2002 03:20:45 -0800 Received: from viap111.atea.be ([194.78.143.111] helo=hrtades9.atea.be) by psg.com with esmtp (Exim 3.33 #1) id 16aazM-000Lvq-00 for multi6@ops.ietf.org; Tue, 12 Feb 2002 03:20:44 -0800 Received: from hrtades10.atea.be (siemens.atea.be [139.10.143.141]) by hrtades9.atea.be with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DF4YSNXA; Tue, 12 Feb 2002 12:20:36 +0100 Received: by siemens.atea.be with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Feb 2002 12:20:59 +0100 Message-ID: From: Coene Lode To: "'Randall Stewart'" , Arun Prasad Cc: Coene Lode , "Transport Area wg (E-mail)" , "'multi6@ops.ietf.org'" Subject: RE: [Tsvwg] SCTP multihoming issues draft Date: Tue, 12 Feb 2002 12:18:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-multi6@ops.ietf.org Precedence: bulk Hello Randy, > -----Original Message----- > From: Randall Stewart [mailto:randall@stewart.chicago.il.us] > Sent: maandag 11 februari 2002 14:54 > To: Arun Prasad > Cc: Coene Lode; Transport Area wg (E-mail); 'multi6@ops.ietf.org' > Subject: Re: [Tsvwg] SCTP multihoming issues draft > > > Arun: > > I don't think we need to have a host become > routing aware as section 2.2 seems to imply to > some degree. Some clever work with the routing > system in the host can alleviate the problem that > Lode is mentioning here I think.. Maybe the section is not clear enough. And a bit biased too. At least, I need to rephrase "downloading the routing tables" sentences. Stay tuned for the next iteration. > > For example in our BSD work we have now the ability > of the routing system to have multiple default routes > and a method to lookup a route via an alternate interface. > We probably need to expand this to actually look at the gateway > and not the interface.. but for now we use interface :/ > > This allows the sctp stack to call > > rtalloc_alternate(dst,old_route); > > which then trys to give a route out a different interface if > necessary hunting up the routing tree. > > With this change we then get: > > A) The host only needs to know about the edge routes available > via its multiple default routes. > > B) Full use of the multi-homing provided without injection > of static routes as the v4 side does now... > > C) Host only knows about the default routes and possibly > some special routes applied by the local administrator... > > R yours sincerly, Lode > > Arun Prasad wrote: > > > > hi Coene, > > Regarding the below section in the draft, > > 2.2 SCTP multihoming and the size of routing tables > > what are we trying to achieve.... section 2.1 basically > > explained the restrictions > > of SCTP's multihoming feature due to existing IP > architecture.... The > > problems > > are well sorted out, and one solution I get from that is, changing > > the Source > > Ip address for the packets send ( periodically, if the > acknowledgemnet > > for it is > > not reaching the endpoint,) from a multihomed endpoint.... > > But regarding section 2.2, SCTP could do nothing about it ( > > because its > > basically IP's restriction or the restriction of the currect routing > > architecture....) > > SCTP defines some rules or features, using them properly is the > > responsiblity of the > > Application which uses it (it may the administrator of the system > > also...) .. This > > each of them using it can implement their own ways to get > the maximum > > from use > > of multihoming feature of SCTP...... > > Will it not make SCTP more heavy, if we try to load > it with more > > and more > > sub features like this... and it will make it more dependent on the > > existing architecture > > which will make the maintanance tough..... > > But definitely we should be spelling out the problems or > > restrictions of the > > multihoming feature of SCTP, with which the users of SCTP users will > > do > > appropriate action to use it best.... > > > > Is the observation valid?? > > > > Thanks > > -arun > > > > Coene Lode wrote: > > > > > Previous week, the draft on SCTP multihoming issues was published. > > > > > > Apart from some editorial changes concerning author list and > > > missing/wrong > > > page numbers, > > > the only major change is a sentence added at the end of paragraph > > > 2.3 SCTP > > > multihoming and Network Adress Translators(NAT): > > > "It should be noted that the NAT box becomes a single > > > point-of-failure in this case, as ALL the paths of the SCTP > > > association have to go through that single NAT box." > > > Theoretical it is possible to let all the different paths run > > > through > > > different NAT boxes, but then the NAT boxes would never > know exactly > > > when to > > > teardown/terminate the association as the terminate or abort takes > > > only one > > > of the paths(and there are other difficulties, such as the > > > heartbeats > > > ...etc...) So in practical terms this sentence should be > correct. If > > > you > > > feel otherwise, please let me know and I'll remove or add > something > > > to it to > > > make everything clear. > > > > > > The draft can be found at the IETF draft directory: > > > Multihoming issues in the Stream Control Transmission Protocol > > > > > > > > > If by then end of next week, no further issues have been > identified, > > > then I > > > would ask for this draft to be moved to informational. > > > > > > yours sincerly > > > Lode Coene > > > > > > _______________________________________________ > > > tsvwg mailing list > > > tsvwg@ietf.org > > > https://www1.ietf.org/mailman/listinfo/tsvwg > > > > -- > > **************************************************************** > > V.Arun Prasad > > HCL Technologies Ltd. > > 51, Jawaharlal Nehru Road, > > Ekkattuthangal, > > Guindy Industrial Estate, > > Chennai - 600097. > > > > Contact # : 9144 - 2334174 > > 9144 - 2334181 > > extn : 233 > > **************************************************************** > > > > -- > Randall R. Stewart > randall@stewart.chicago.il.us 815-342-5222 (cell phone) > From owner-multi6@ops.ietf.org Tue Feb 12 06:22:14 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07867 for ; Tue, 12 Feb 2002 06:22:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16aazF-000Lvo-00 for multi6-data@psg.com; Tue, 12 Feb 2002 03:20:37 -0800 Received: from viap111.atea.be ([194.78.143.111] helo=hrtades9.atea.be) by psg.com with esmtp (Exim 3.33 #1) id 16aazE-000Lvi-00 for multi6@ops.ietf.org; Tue, 12 Feb 2002 03:20:36 -0800 Received: from hrtades10.atea.be (siemens.atea.be [139.10.143.141]) by hrtades9.atea.be with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DF4YSNW7; Tue, 12 Feb 2002 12:20:28 +0100 Received: by siemens.atea.be with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Feb 2002 12:20:51 +0100 Message-ID: From: Coene Lode To: "'Arun Prasad'" , Coene Lode Cc: "Transport Area wg (E-mail)" , "'multi6@ops.ietf.org'" Subject: RE: [Tsvwg] SCTP multihoming issues draft Date: Tue, 12 Feb 2002 12:18:09 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-multi6@ops.ietf.org Precedence: bulk Hello Arun, >-----Original Message----- >From: Arun Prasad [mailto:arun@netlab.hcltech.com] >Sent: maandag 11 februari 2002 6:50 >To: Coene Lode >Cc: Transport Area wg (E-mail); 'multi6@ops.ietf.org' >Subject: Re: [Tsvwg] SCTP multihoming issues draft > > >hi Coene, > Regarding the below section in the draft, > 2.2 SCTP multihoming and the size of routing tables > what are we trying to achieve.... section 2.1 basically explained the restrictions >of SCTP's multihoming feature due to existing IP architecture.... The problems >are well sorted out, and one solution I get from that is, changing the Source >Ip address for the packets send ( periodically, if the acknowledgemnet for it is >not reaching the endpoint,) from a multihomed endpoint.... > But regarding section 2.2, SCTP could do nothing about it ( because its >basically IP's restriction or the restriction of the currect routing architecture....) >SCTP defines some rules or features, using them properly is the responsiblity of the >Application which uses it (it may the administrator of the system also...) .. This >each of them using it can implement their own ways to get the maximum from use >of multihoming feature of SCTP...... > Will it not make SCTP more heavy, if we try to load it with more and more >sub features like this... and it will make it more dependent on the existing architecture >which will make the maintanance tough..... That is true. But some of the features would be far more usable if some things(like NAT's) didn't exist in the first place. And according to the end-to-end pricniple, it is better to put some complexity in the the endnode, than to put it in the network: I concede that this is more a filosofical discussion, but as the NAT section shows, such boxes are not that helpfull. > But definitely we should be spelling out the problems or restrictions of the >multihoming feature of SCTP, with which the users of SCTP users will do >appropriate action to use it best.... >Is the observation valid?? That is indeed a correct observation. This draft tries to spell out problems or restrictions of the multihoming feature of SCTP. Some of those problems can be evaded in SCTP but others need to be solved in IP (or somewhere else). That is not my call to make. yours sincerly, Lode >Thanks >-arun >Coene Lode wrote: >The draft can be found at the IETF draft directory: >Multihoming issues in the Stream Control Transmission Protocol > From owner-multi6@ops.ietf.org Fri Feb 15 08:06:24 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04180 for ; Fri, 15 Feb 2002 08:06:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16bhyx-000F5I-00 for multi6-data@psg.com; Fri, 15 Feb 2002 05:00:55 -0800 Received: from viap111.atea.be ([194.78.143.111] helo=hrtades9.atea.be) by psg.com with esmtp (Exim 3.33 #1) id 16bhyv-000F5C-00 for multi6@ops.ietf.org; Fri, 15 Feb 2002 05:00:54 -0800 Received: from hrtades10.atea.be (siemens.atea.be [139.10.143.141]) by hrtades9.atea.be with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DF4YTJS4; Fri, 15 Feb 2002 14:00:43 +0100 Received: by siemens.atea.be with Internet Mail Service (5.5.2653.19) id <19TAJQH8>; Fri, 15 Feb 2002 14:01:05 +0100 Message-ID: From: Coene Lode To: "Transport Area wg (E-mail)" , "SIGTRAN (E-mail)" Cc: "Multi6 (E-mail)" Subject: updated text SCTP Multihoming issues Date: Fri, 15 Feb 2002 13:58:09 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-multi6@ops.ietf.org Precedence: bulk Folks, Thanks for all the commentaries received so far. The only remaining issue was the text of of paragraph 2.3 "SCTP multihoming and the size of routing tables" This is the new version. As multihoming means that more than one destination address is used on the host, that would mean that a routing descision must be made on the host in IP. The host does not know beforehand to which other host it is going to send something, so that would in theory require that all possible paths to all possible destinations should be known on that host. This amounts to the host being a part of the distribution of the routing information in the network. Possible solutions would require to ask only for the paths to host that are actually in use(meaning a association is about to be setup with that particular host). This is a viable solution for hosts with a small number of associations to different hosts. If the host has many associations with a lot of different host then then this becomes cumbersome(getting the specific paths from the routers and the updates and all) and leads in practice to same problem of distributing prefixes from the edge router(s) to the host. It might be useful to explore ways where no distribution of routing information to the host for using multihoming is needed or where the interface/link selection is not based on the use of different prefixes. Not all hosts have facilities for containing possible large routing tables/databases. The document draft-coene-sctp-multihome-02.txt can be found at: http://search.ietf.org/internet-drafts/draft-coene-sctp-multihome-02.txt Suggestion, clarification, corrections, are welcome. I'll publish the updated(-03) draft wednesday 20/02/02 Yours sincerly, Lode Siemens atea atealaan 34 2200 Herentals, Belgium E-mail: lode.coene@siemens.atea.be Tel: +32-14-252081 Fax: +32-14-253212 From owner-multi6@ops.ietf.org Tue Feb 26 20:07:26 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26852 for ; Tue, 26 Feb 2002 20:07:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.35 #1) id 16fsWT-0004Xs-00 for multi6-data@psg.com; Tue, 26 Feb 2002 17:04:45 -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.35 #1) id 16fsWS-0004Xm-00 for multi6@ops.ietf.org; Tue, 26 Feb 2002 17:04:44 -0800 Subject: (multi6) New MHTP draft. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 26 Feb 2002 17:04:38 -0800 content-class: urn:content-classes:message Message-ID: <2B81403386729140A3A899A8B39B046406C3AB@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: (multi6) New MHTP draft. Thread-Index: AcG/KrniTxb3XXvFRaqT2EKJXrP7rQ== From: "Michel Py" To: Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA26852 multi6 folk, I just posted release 02a here: http://arneill-py.sacramento.ca.us/ipv6mh/draft-py-mhtp-02a.txt Note that the multi6 mailing is not a place to discuss it. > Abstract: > This document describes a protocol for IPv6 Network Layer multihoming > (MHTP) that does not affect the size of the routing table in the IPv6 > DFZ (Default Free Zone) and does not use tunnels. MHTP is a router > solution and covers home/soho to very large environments. Enjoy, Michel.