From owner-multi6@ops.ietf.org Wed Jun 12 07:17: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 HAA23122 for ; Wed, 12 Jun 2002 07:17:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17I65O-000PHH-00 for multi6-data@psg.com; Wed, 12 Jun 2002 04:14:46 -0700 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 17I65L-000PH6-00 for multi6@ops.ietf.org; Wed, 12 Jun 2002 04:14:43 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23003; Wed, 12 Jun 2002 07:14:07 -0400 (EDT) Message-Id: <200206121114.HAA23003@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: multi6@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-multi6-multihoming-requirements-03.txt Date: Wed, 12 Jun 2002 07:14:07 -0400 X-Spam-Status: No, hits=0.8 required=5.0 tests=NO_REAL_NAME,TO_MALFORMED,EXCUSE_6 version=2.20 Sender: owner-multi6@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Site Multihoming in IPv6 Working Group of the IETF. Title : Requirements for IPv6 Site- Multihoming Architectures Author(s) : B. Black, V. Gill, J. Abley Filename : draft-ietf-multi6-multihoming-requirements-03.txt Pages : 12 Date : 11-Jun-02 Site-multihoming, i.e. connecting to more than one IP service provider, is an essential component of service for many sites which are part of the Internet. Existing IPv4 site-multihoming practices, described in a companion draft [1], provides a set of capabilities that must be accommodated by the adopted site-multihoming architecture in IPv6, and a set of limitations that must be overcome, relating in particular to scalability. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-multi6-multihoming-requirements-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-multi6-multihoming-requirements-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-multi6-multihoming-requirements-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020611122903.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-multi6-multihoming-requirements-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-multi6-multihoming-requirements-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020611122903.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-multi6@ops.ietf.org Thu Jun 20 17:55:35 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13884 for ; Thu, 20 Jun 2002 17:55:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17L9rl-000LvY-00 for multi6-data@psg.com; Thu, 20 Jun 2002 14:53:21 -0700 Received: from host217-37-202-105.in-addr.btopenworld.com ([217.37.202.105] helo=ab.use.net) by psg.com with esmtp (Exim 3.36 #1) id 17L9rg-000Lv6-00 for multi6@ops.ietf.org; Thu, 20 Jun 2002 14:53:16 -0700 Received: by ab.use.net (Postfix, from userid 3005) id DFFB970B; Thu, 20 Jun 2002 21:53:09 +0000 (GMT) To: multi6@ops.ietf.org Subject: draft-ietf-multi6-multihoming-requirements-03 Message-Id: <20020620215309.DFFB970B@ab.use.net> Date: Thu, 20 Jun 2002 21:53:09 +0000 (GMT) From: smd@ab.use.net (Sean Doran) X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-multi6@ops.ietf.org Precedence: bulk Hi - Joe has done some updates to the draft, and has been met with silence from the WG. Would anyone like to comment on draft-ietf-multi6-multihoming-requirements-03? Failing that, please feel free to make meta-comments on whether we should start the last call process and move the document along. (Remember this is a gating issue, as this document will be used within the working group when evaluating proposed multihoming solutions, so this draft is important, and deserving of a few minutes of reading and commenting time). Sean. From owner-multi6@ops.ietf.org Thu Jun 20 19:53: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 TAA15947 for ; Thu, 20 Jun 2002 19:53:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17LBiz-000NbF-00 for multi6-data@psg.com; Thu, 20 Jun 2002 16:52:25 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 17LBiu-000Nag-00 for multi6@ops.ietf.org; Thu, 20 Jun 2002 16:52:21 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g5KNqb242785; Fri, 21 Jun 2002 01:52:37 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Fri, 21 Jun 2002 01:52:37 +0200 (CEST) From: Iljitsch van Beijnum To: Sean Doran cc: Subject: Re: draft-ietf-multi6-multihoming-requirements-03 In-Reply-To: <20020620215309.DFFB970B@ab.use.net> Message-ID: <20020621013132.L41712-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 20 Jun 2002, Sean Doran wrote: > Would anyone like to comment on draft-ietf-multi6-multihoming-requirements-03? Since you ask... The requirements all seem very reasonable to me. (Many pretty much go without saying.) I only have two problems: - multihoming gets blamed for the global routing table bloat, while the number of active routes vs the number of active ASNs clearly shows this is only a small factor at this time - what happens when there is no multihoming solution that meets all requirements? We then forego multihoming in IPv6, or ...? There is only a perfunctory division of the listed requirements into the classes "must be supported" and "additional requirements" > Failing that, please feel free to make meta-comments on whether > we should start the last call process and move the document along. Maybe we should have a look at the "goals and milestones" section of the charter for guidance. Iljitsch van Beijnum From owner-multi6@ops.ietf.org Thu Jun 20 20:23: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 UAA16480 for ; Thu, 20 Jun 2002 20:23:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17LCDC-000O26-00 for multi6-data@psg.com; Thu, 20 Jun 2002 17:23:38 -0700 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.36 #1) id 17LCD8-000O1o-00 for multi6@ops.ietf.org; Thu, 20 Jun 2002 17:23:34 -0700 From: Masataka Ohta Message-Id: <200206210002.JAA03111@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id JAA03111; Fri, 21 Jun 2002 09:02:11 +0900 Subject: Re: draft-ietf-multi6-multihoming-requirements-03 In-Reply-To: <20020620215309.DFFB970B@ab.use.net> from Sean Doran at "Jun 20, 2002 09:53:09 pm" To: Sean Doran Date: Fri, 21 Jun 2002 09:02:07 +0859 () CC: multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2 version=2.20 Sender: owner-multi6@ops.ietf.org Precedence: bulk Sean; > Joe has done some updates to the draft, and has been met with > silence from the WG. > > Would anyone like to comment on draft-ietf-multi6-multihoming-requirements-03? I agree with Brian; My opinion: ship it. We need to get done with requirements so that we can proceed to look at solutions. Twiddling the requirements to achieve universal consensus isn't productive. > (Remember this is a gating issue, as this document will be used > within the working group when evaluating proposed multihoming solutions, > so this draft is important, and deserving of a few minutes of reading > and commenting time). However, the result based not on the universal consensus should not be used to evaluate proposals. IMHO, in other words, attempts to ship requirement drafts was not productive. Simply listing up all the requirements, some of which contradicts each other, could have been a better approach, as the result contains contradicting ones, anyway. Masataka Ohta From owner-multi6@ops.ietf.org Fri Jun 21 09:50:52 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12647 for ; Fri, 21 Jun 2002 09:50:52 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17LOmJ-000B9Z-00 for multi6-data@psg.com; Fri, 21 Jun 2002 06:48:43 -0700 Received: from d12lmsgate-3.de.ibm.com ([195.212.91.201]) by psg.com with esmtp (Exim 3.36 #1) id 17LOmG-000B9N-00 for multi6@ops.ietf.org; Fri, 21 Jun 2002 06:48:40 -0700 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5LDm8cK018092; Fri, 21 Jun 2002 15:48:13 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with SMTP id g5LDm4T113626; Fri, 21 Jun 2002 15:48:04 +0200 Received: from gsine02.us.sine.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA39048 from ; Fri, 21 Jun 2002 15:47:56 +0200 Message-Id: <3D132443.83B037E@hursley.ibm.com> Date: Fri, 21 Jun 2002 15:04:03 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Iljitsch van Beijnum Cc: Sean Doran , multi6@ops.ietf.org Subject: Re: draft-ietf-multi6-multihoming-requirements-03 References: <20020621013132.L41712-100000@sequoia.muada.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: ... > - what happens when there is no multihoming solution that meets all > requirements? We then forego multihoming in IPv6, or ...? There is only > a perfunctory division of the listed requirements into the classes "must > be supported" and "additional requirements" I'd certainly expect that there is no perfect solution. The requirements are just a checklist for evaluating solutions. That's why I said "ship it". Get it out as Informational so that we can move on. Brian From owner-multi6@ops.ietf.org Mon Jun 24 17:49: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 RAA03588 for ; Mon, 24 Jun 2002 17:49:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17MbgK-000FsA-00 for multi6-data@psg.com; Mon, 24 Jun 2002 14:47:32 -0700 Received: from urda.heanet.ie ([193.1.219.124]) by psg.com with esmtp (Exim 3.36 #1) id 17MbgE-000Frv-00 for multi6@ops.ietf.org; Mon, 24 Jun 2002 14:47:26 -0700 Received: (from davew@localhost) by urda.heanet.ie (8.9.3/8.9.3) id WAA21935 for multi6@ops.ietf.org; Mon, 24 Jun 2002 22:47:24 +0100 Date: Mon, 24 Jun 2002 22:47:24 +0100 From: Dave Wilson To: multi6@ops.ietf.org Subject: Re: draft-ietf-multi6-multihoming-requirements-03 Message-ID: <20020624224724.A17646@urda.heanet.ie> References: <20020620215309.DFFB970B@ab.use.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20020620215309.DFFB970B@ab.use.net>; from smd@ab.use.net on Thu, Jun 20, 2002 at 09:53:09PM +0000 X-How-Many: Fifty or sixty X-NCC-Regid: ie.heanet X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-multi6@ops.ietf.org Precedence: bulk > Would anyone like to comment on draft-ietf-multi6-multihoming-requirements-03? Question about sections 3.1.2-3.1.4. During the discussions on global-v6, a scenario came up that caused trouble. Imagine network A does not (under current RIR rules) qualify for a /35. Network A has routes to network B via (a) a high speed direct connection, (b) a high-speed network and (c) an ordinary commodity internet connection. Network A provides connectivity to a number of sites (< 200) not under its direct control. In IPv4, where Network A has an ASN and allocation from a RIR, BGP localprefs enforce a routing policy which uses the high-speed connects in preference to the commodity internet. Does section 3.1.4 require a solution to this scenario? "class of traffic" might just mean a protocol or could be wider, so I am not sure. The reason I bring this up is that it is not an unusual configuration for a national research network. If the answer is "no" then it is not necessarily a problem with the document :) but if the group [does|does not] plan to address it, I think it would be useful feedback for the policy groups. Best regards, Dave -- dave.wilson@heanet.ie ------- DW238-RIPE ------- GPG key: davew+pgp@heanet.ie HEAnet Limited, Brooklawn House, Crampton Ave, Ballsbridge, D4 p:353-1-6609040 "A reload a day keeps the TAC away" - Roger Gottsponer RIPE-40 f:353-1-6603666 HEAnet's National Networking Conference http://www.heanet.ie/conferences/2001/ From owner-multi6@ops.ietf.org Tue Jun 25 03:40: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 DAA25337 for ; Tue, 25 Jun 2002 03:40:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17MkvV-0002qr-00 for multi6-data@psg.com; Tue, 25 Jun 2002 00:39:49 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 17MkvR-0002qg-00 for multi6@ops.ietf.org; Tue, 25 Jun 2002 00:39:45 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g5P7e3i52548; Tue, 25 Jun 2002 09:40:03 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Tue, 25 Jun 2002 09:40:03 +0200 (CEST) From: Iljitsch van Beijnum To: Dave Wilson cc: Subject: Re: draft-ietf-multi6-multihoming-requirements-03 In-Reply-To: <20020624224724.A17646@urda.heanet.ie> Message-ID: <20020625085749.G51646-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-5.3 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT version=2.30 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Mon, 24 Jun 2002, Dave Wilson wrote: > Imagine network A does not (under current RIR rules) qualify for a /35. > Network A has routes to network B via (a) a high speed direct connection, > (b) a high-speed network and (c) an ordinary commodity internet connection. > Network A provides connectivity to a number of sites (< 200) not under its > direct control. > In IPv4, where Network A has an ASN and allocation from a RIR, BGP localprefs > enforce a routing policy which uses the high-speed connects in preference to > the commodity internet. Only for outgoing traffic. Balancing incoming traffic is much harder, unless the networks sending the traffic cooperate. > Does section 3.1.4 require a solution to this scenario? "class of traffic" > might just mean a protocol or could be wider, so I am not sure. > The reason I bring this up is that it is not an unusual configuration for a > national research network. If the answer is "no" then it is not necessarily > a problem with the document :) but if the group [does|does not] plan to > address it, I think it would be useful feedback for the policy groups. A multihoming solution that doesn't provide for a way to make a higher-bandwidth connection to be more preferred than a lower-bandwidth connection won't fly, because it doesn't address real-world needs. There are still many places in the world where bandwidth is expensive enough wasting a significant amount of it is not an option. Route selection and load balancing are mainly a problem with solutions that require hosts to make decisions that ultimately determine routing. (Ie. where a host must select one address out of several to communicate with.) At some point, routing and routing policy information has to reach those hosts. Since this doesn't exist yet, we are free to introduce all the features we think are necessary. However, this requires multi6 to start looking at solutions. IPv6 adoption doesn't seem to happen at a break-neck pace, but at some point operational needs will make multihoming happen one way or another. (How long will the RIRs refrain from giving themselves provider independent address space, for instance?) That genie will be hard to put back in the bottle. Iljitsch van Beijnum From owner-multi6@ops.ietf.org Tue Jun 25 03:57:00 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25740 for ; Tue, 25 Jun 2002 03:57:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17MlCH-00036I-00 for multi6-data@psg.com; Tue, 25 Jun 2002 00:57:09 -0700 Received: from d12lmsgate-3.de.ibm.com ([195.212.91.201]) by psg.com with esmtp (Exim 3.36 #1) id 17MlCD-000366-00 for multi6@ops.ietf.org; Tue, 25 Jun 2002 00:57:05 -0700 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5P7uUcK006050; Tue, 25 Jun 2002 09:56:31 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with SMTP id g5P7uTY48884; Tue, 25 Jun 2002 09:56:29 +0200 Received: from dhcp23-199.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA50412 from ; Tue, 25 Jun 2002 09:56:25 +0200 Message-Id: <3D18225E.ABA2B886@hursley.ibm.com> Date: Tue, 25 Jun 2002 09:57:18 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Dave Wilson Cc: multi6@ops.ietf.org Subject: Re: draft-ietf-multi6-multihoming-requirements-03 References: <20020620215309.DFFB970B@ab.use.net> <20020624224724.A17646@urda.heanet.ie> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.30 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I think "class of traffic" would certainly include diffserv codepoints as well as (or instead of) protocol numbers. If traffic has been classified by a diffserv classifier before it hits the multihoming logic, that could imply that the source and/or destination address helped to determine the diffserv codepoint and hence the multihoming policy. Are you suggesting any change to the text? Brian Dave Wilson wrote: > > > Would anyone like to comment on draft-ietf-multi6-multihoming-requirements-03? > > Question about sections 3.1.2-3.1.4. > > During the discussions on global-v6, a scenario came up that caused trouble. > > Imagine network A does not (under current RIR rules) qualify for a /35. > Network A has routes to network B via (a) a high speed direct connection, > (b) a high-speed network and (c) an ordinary commodity internet connection. > Network A provides connectivity to a number of sites (< 200) not under its > direct control. > > In IPv4, where Network A has an ASN and allocation from a RIR, BGP localprefs > enforce a routing policy which uses the high-speed connects in preference to > the commodity internet. > > Does section 3.1.4 require a solution to this scenario? "class of traffic" > might just mean a protocol or could be wider, so I am not sure. > > The reason I bring this up is that it is not an unusual configuration for a > national research network. If the answer is "no" then it is not necessarily > a problem with the document :) but if the group [does|does not] plan to > address it, I think it would be useful feedback for the policy groups. > > Best regards, > Dave > > -- > dave.wilson@heanet.ie ------- DW238-RIPE ------- GPG key: davew+pgp@heanet.ie > HEAnet Limited, Brooklawn House, Crampton Ave, Ballsbridge, D4 p:353-1-6609040 > "A reload a day keeps the TAC away" - Roger Gottsponer RIPE-40 f:353-1-6603666 > HEAnet's National Networking Conference http://www.heanet.ie/conferences/2001/ From owner-multi6@ops.ietf.org Tue Jun 25 19:15: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 TAA02986 for ; Tue, 25 Jun 2002 19:15:56 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17MzVF-000L8I-00 for multi6-data@psg.com; Tue, 25 Jun 2002 16:13:41 -0700 Received: from urda.heanet.ie ([193.1.219.124]) by psg.com with esmtp (Exim 3.36 #1) id 17MzV6-000L83-00 for multi6@ops.ietf.org; Tue, 25 Jun 2002 16:13:33 -0700 Received: (from davew@localhost) by urda.heanet.ie (8.9.3/8.9.3) id AAA06501 for multi6@ops.ietf.org; Wed, 26 Jun 2002 00:13:31 +0100 Date: Wed, 26 Jun 2002 00:13:31 +0100 From: Dave Wilson To: multi6@ops.ietf.org Subject: Re: draft-ietf-multi6-multihoming-requirements-03 Message-ID: <20020626001331.A4899@urda.heanet.ie> References: <20020620215309.DFFB970B@ab.use.net> <20020624224724.A17646@urda.heanet.ie> <3D18225E.ABA2B886@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <3D18225E.ABA2B886@hursley.ibm.com>; from brian@hursley.ibm.com on Tue, Jun 25, 2002 at 09:57:18AM +0200 X-How-Many: Fifty or sixty X-NCC-Regid: ie.heanet X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-multi6@ops.ietf.org Precedence: bulk > I think "class of traffic" would certainly include diffserv codepoints as well > as (or instead of) protocol numbers. If traffic has been classified by a diffserv > classifier before it hits the multihoming logic, that could imply that the source > and/or destination address helped to determine the diffserv codepoint and hence > the multihoming policy. Ok, thanks. > Are you suggesting any change to the text? No. Even if the text fails to include the scenario I mentioned, I am not sure that it would be a problem. However I'd like to make sure that multihoming expectations in the policy groups match expectations here. Regards, Dave -- dave.wilson@heanet.ie ------- DW238-RIPE ------- GPG key: davew+pgp@heanet.ie HEAnet Limited, Brooklawn House, Crampton Ave, Ballsbridge, D4 p:353-1-6609040 "A reload a day keeps the TAC away" - Roger Gottsponer RIPE-40 f:353-1-6603666 HEAnet's National Networking Conference http://www.heanet.ie/conferences/2001/ From owner-multi6@ops.ietf.org Wed Jun 26 08:06:49 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14131 for ; Wed, 26 Jun 2002 08:06:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17NBYn-000FzR-00 for multi6-data@psg.com; Wed, 26 Jun 2002 05:06:09 -0700 Received: from d12lmsgate-3.de.ibm.com ([195.212.91.201]) by psg.com with esmtp (Exim 3.36 #1) id 17NBYi-000FzA-00 for multi6@ops.ietf.org; Wed, 26 Jun 2002 05:06:04 -0700 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5QC5VcK033552; Wed, 26 Jun 2002 14:05:31 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with SMTP id g5QC5VC109542; Wed, 26 Jun 2002 14:05:31 +0200 Received: from dhcp23-199.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA40456 from ; Wed, 26 Jun 2002 14:05:27 +0200 Message-Id: <3D19AE3C.11CF3CE5@hursley.ibm.com> Date: Wed, 26 Jun 2002 14:06:20 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Dave Wilson Cc: multi6@ops.ietf.org Subject: Re: draft-ietf-multi6-multihoming-requirements-03 References: <20020620215309.DFFB970B@ab.use.net> <20020624224724.A17646@urda.heanet.ie> <3D18225E.ABA2B886@hursley.ibm.com> <20020626001331.A4899@urda.heanet.ie> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.30 X-Spam-Level: * Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In fact you made me think of one possible unexpected consequence. If we allow diffserv code points to influence multihoming policy, it would be possible for someone who thought they were setting QOS policy to accidentally influence multihoming policy. That's not a very welcome side effect, but it may be inevitable. Brian Dave Wilson wrote: > > > I think "class of traffic" would certainly include diffserv codepoints as well > > as (or instead of) protocol numbers. If traffic has been classified by a diffserv > > classifier before it hits the multihoming logic, that could imply that the source > > and/or destination address helped to determine the diffserv codepoint and hence > > the multihoming policy. > > Ok, thanks. > > > Are you suggesting any change to the text? > > No. Even if the text fails to include the scenario I mentioned, I am not sure > that it would be a problem. However I'd like to make sure that multihoming > expectations in the policy groups match expectations here. > > Regards, > Dave > > -- > dave.wilson@heanet.ie ------- DW238-RIPE ------- GPG key: davew+pgp@heanet.ie > HEAnet Limited, Brooklawn House, Crampton Ave, Ballsbridge, D4 p:353-1-6609040 > "A reload a day keeps the TAC away" - Roger Gottsponer RIPE-40 f:353-1-6603666 > HEAnet's National Networking Conference http://www.heanet.ie/conferences/2001/ -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland From owner-multi6@ops.ietf.org Wed Jun 26 09:34: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 JAA18241 for ; Wed, 26 Jun 2002 09:34:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17NCvZ-000ARq-00 for multi6-data@psg.com; Wed, 26 Jun 2002 06:33:45 -0700 Received: from host217-37-202-105.in-addr.btopenworld.com ([217.37.202.105] helo=ab.use.net) by psg.com with esmtp (Exim 3.36 #1) id 17NCvQ-000ARH-00 for multi6@ops.ietf.org; Wed, 26 Jun 2002 06:33:37 -0700 Received: by ab.use.net (Postfix, from userid 3005) id AB52F821; Wed, 26 Jun 2002 13:33:35 +0000 (GMT) To: multi6@ops.ietf.org Subject: Re: draft-ietf-multi6-multihoming-requirements-03 Message-Id: <20020626133335.AB52F821@ab.use.net> Date: Wed, 26 Jun 2002 13:33:35 +0000 (GMT) From: smd@ab.use.net (Sean Doran) X-Spam-Status: No, hits=-1.9 required=5.0 tests=X_NOT_PRESENT version=2.30 Sender: owner-multi6@ops.ietf.org Precedence: bulk Brian Carpenter writes: | In fact you made me think of one possible unexpected consequence. If we allow | diffserv code points to influence multihoming policy, it would be possible for | someone who thought they were setting QOS policy to accidentally influence | multihoming policy. That's not a very welcome side effect, but it may be | inevitable. How should this be reflected within the multi6 reqs document (if at all)? Should one do anything about the doors separating IPv6-global-unicast-format from extensions of various flavours, including encoding destination information in places other than strictly the destination address? In particular, there is an obvious *MAY* requirement looming in this discussion, and I'm glad it originated with someone other than me. -:) Sean. P.S.: in whose opinion is it unwelcome? isn't this is a shade of grey? consider: source | . . | upstream / \ transit-l transit-r \ / dest. "dest." would like to have inbound traffic through upstream choose between transit-l and transit-r based on the DSCP rather than on strictly the destination address. is this something evil that MUST not be allowed, something gross that SHOULD NOT be done in practise, or something the parties themselves should negotiate on their own? what if transit-l is low-bandwidth/low-delay and transit-r is high-bandwidth/high-delay? "dest." might be a national research network with a number of universities connected, each with people wanting to receive all sorts of traffic from elsewhere in the Internet, some of it bulk transfer (post-napster?) and some of it delay-sensitive (sshing back home from an IETF meeting?). the argument in the past has been that since there is no dynamic routing protocol currently supporting upstream's left-or-right decision in the event of failure along either path towards dest, this would best be addressed (ahem), if at all, in someplace like IDR, or perhaps wherever one puts interdomain MPLS routing support. on the other hand, in the earlier days of the PRDB, one could also have observed the evolution of systems to allow the selection of exit ENSSes towards a particular destination and conclude that they could easily have wound up supporting exactly this sort of thing. indeed, some old people around here recall *several* ad hoc methods of supporting *exactly* this kind of multihoming in the distant past. i'm sure our requirements draft editor is open to suggestions for new text, if anyone cares to make one. From owner-multi6@ops.ietf.org Wed Jun 26 12:20: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 MAA26936 for ; Wed, 26 Jun 2002 12:20:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17NFVf-0009MY-00 for multi6-data@psg.com; Wed, 26 Jun 2002 09:19:11 -0700 Received: from d12lmsgate-3.de.ibm.com ([195.212.91.201]) by psg.com with esmtp (Exim 3.36 #1) id 17NFVW-0009MM-00 for multi6@ops.ietf.org; Wed, 26 Jun 2002 09:19:02 -0700 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5QGImcK030212; Wed, 26 Jun 2002 18:18:53 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with SMTP id g5QGIWC112816; Wed, 26 Jun 2002 18:18:32 +0200 Received: from dhcp23-199.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA50254 from ; Wed, 26 Jun 2002 18:18:28 +0200 Message-Id: <3D19E988.CD569E0F@hursley.ibm.com> Date: Wed, 26 Jun 2002 18:19:20 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Sean Doran Cc: multi6@ops.ietf.org Subject: Re: draft-ietf-multi6-multihoming-requirements-03 References: <20020626133335.AB52F821@ab.use.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.30 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Sean, all good points. I'm not sure I would change the requirements at all, or that there is anything very evil here; but unexpected side effects are always worth noting. Brian Sean Doran wrote: > > Brian Carpenter writes: > > | In fact you made me think of one possible unexpected consequence. If we allow > | diffserv code points to influence multihoming policy, it would be possible for > | someone who thought they were setting QOS policy to accidentally influence > | multihoming policy. That's not a very welcome side effect, but it may be > | inevitable. > > How should this be reflected within the multi6 reqs document (if at all)? > > Should one do anything about the doors separating IPv6-global-unicast-format > from extensions of various flavours, including encoding destination information > in places other than strictly the destination address? > > In particular, there is an obvious *MAY* requirement looming in this > discussion, and I'm glad it originated with someone other than me. -:) > > Sean. > > P.S.: in whose opinion is it unwelcome? isn't this is a shade of grey? > consider: > > source > | > . > . > | > upstream > / \ > transit-l transit-r > \ / > dest. > > "dest." would like to have inbound traffic through upstream choose > between transit-l and transit-r based on the DSCP rather than on > strictly the destination address. is this something evil that MUST > not be allowed, something gross that SHOULD NOT be done in practise, > or something the parties themselves should negotiate on their own? > what if transit-l is low-bandwidth/low-delay and transit-r is > high-bandwidth/high-delay? "dest." might be a national research > network with a number of universities connected, each with people > wanting to receive all sorts of traffic from elsewhere in the > Internet, some of it bulk transfer (post-napster?) and some of it > delay-sensitive (sshing back home from an IETF meeting?). > > the argument in the past has been that since there is no dynamic > routing protocol currently supporting upstream's left-or-right > decision in the event of failure along either path towards dest, > this would best be addressed (ahem), if at all, in someplace like IDR, > or perhaps wherever one puts interdomain MPLS routing support. > > on the other hand, in the earlier days of the PRDB, one could also > have observed the evolution of systems to allow the selection of > exit ENSSes towards a particular destination and conclude that they > could easily have wound up supporting exactly this sort of thing. > indeed, some old people around here recall *several* ad hoc methods > of supporting *exactly* this kind of multihoming in the distant past. > > i'm sure our requirements draft editor is open to suggestions for new text, > if anyone cares to make one. From owner-multi6@ops.ietf.org Wed Jun 26 15:33: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 PAA07386 for ; Wed, 26 Jun 2002 15:33:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17NIUV-0007XE-00 for multi6-data@psg.com; Wed, 26 Jun 2002 12:30:11 -0700 Received: from evrtwa1-ar8-4-65-028-011.evrtwa1.dsl-verizon.net ([4.65.28.11] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #1) id 17NIUG-0007WQ-00 for multi6@ops.ietf.org; Wed, 26 Jun 2002 12:29:56 -0700 Received: from eagleswings (127.0.0.1) by localhost (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Wed, 26 Jun 2002 12:30:58 -0700 From: "Tony Hain" To: "Brian E Carpenter" , "Sean Doran" Cc: Subject: RE: draft-ietf-multi6-multihoming-requirements-03 Date: Wed, 26 Jun 2002 12:29:45 -0700 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3D19E988.CD569E0F@hursley.ibm.com> Importance: Normal X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit While I believe this document still assumes too much in terms of affecting policy outside the domain of direct administrative control, I have to agree it is time to ship it. There is one comment about the IESG in 3.2.7 that simply doesn't belong in any I-D, so I wouldn't be surprised when the IESG asks to have it changed or removed. If the words 'within the IESG' were removed, the sentence would stand and makes much more sense than worrying about IETF process in a mechanism requirements doc. Tony > -----Original Message----- > From: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]On > Behalf Of Brian E Carpenter > Sent: Wednesday, June 26, 2002 9:19 AM > To: Sean Doran > Cc: multi6@ops.ietf.org > Subject: Re: draft-ietf-multi6-multihoming-requirements-03 > > > Sean, all good points. I'm not sure I would change the > requirements at all, > or that there is anything very evil here; but unexpected side effects > are always worth noting. > > Brian > > Sean Doran wrote: > > > > Brian Carpenter writes: > > > > | In fact you made me think of one possible unexpected > consequence. If we allow > > | diffserv code points to influence multihoming policy, it > would be possible for > > | someone who thought they were setting QOS policy to > accidentally influence > > | multihoming policy. That's not a very welcome side > effect, but it may be > > | inevitable. > > > > How should this be reflected within the multi6 reqs > document (if at all)? > > > > Should one do anything about the doors separating > IPv6-global-unicast-format > > from extensions of various flavours, including encoding > destination information > > in places other than strictly the destination address? > > > > In particular, there is an obvious *MAY* requirement looming in this > > discussion, and I'm glad it originated with someone other > than me. -:) > > > > Sean. > > > > P.S.: in whose opinion is it unwelcome? isn't this is a > shade of grey? > > consider: > > > > source > > | > > . > > . > > | > > upstream > > / \ > > transit-l transit-r > > \ / > > dest. > > > > "dest." would like to have inbound traffic through upstream choose > > between transit-l and transit-r based on the DSCP rather than on > > strictly the destination address. is this something evil that MUST > > not be allowed, something gross that SHOULD NOT be done in practise, > > or something the parties themselves should negotiate on their own? > > what if transit-l is low-bandwidth/low-delay and transit-r is > > high-bandwidth/high-delay? "dest." might be a national research > > network with a number of universities connected, each with people > > wanting to receive all sorts of traffic from elsewhere in the > > Internet, some of it bulk transfer (post-napster?) and some of it > > delay-sensitive (sshing back home from an IETF meeting?). > > > > the argument in the past has been that since there is no dynamic > > routing protocol currently supporting upstream's left-or-right > > decision in the event of failure along either path towards dest, > > this would best be addressed (ahem), if at all, in > someplace like IDR, > > or perhaps wherever one puts interdomain MPLS routing support. > > > > on the other hand, in the earlier days of the PRDB, one could also > > have observed the evolution of systems to allow the selection of > > exit ENSSes towards a particular destination and conclude that they > > could easily have wound up supporting exactly this sort of thing. > > indeed, some old people around here recall *several* ad hoc methods > > of supporting *exactly* this kind of multihoming in the > distant past. > > > > i'm sure our requirements draft editor is open to > suggestions for new text, > > if anyone cares to make one. > From owner-multi6@ops.ietf.org Wed Jun 26 16:00:02 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08529 for ; Wed, 26 Jun 2002 16:00:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17NIxf-0008IO-00 for multi6-data@psg.com; Wed, 26 Jun 2002 13:00:19 -0700 Received: from buffoon.automagic.org ([208.185.30.208]) by psg.com with smtp (Exim 3.36 #1) id 17NIxX-0008IA-00 for multi6@ops.ietf.org; Wed, 26 Jun 2002 13:00:11 -0700 Received: (qmail 77699 invoked by uid 0); 26 Jun 2002 20:00:09 -0000 Received: from unknown (HELO hyperion) (127.0.0.1) by 0 with SMTP; 26 Jun 2002 20:00:09 -0000 Date: Wed, 26 Jun 2002 16:00:02 -0400 Subject: Re: draft-ietf-multi6-multihoming-requirements-03 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: "Brian E Carpenter" , "Sean Doran" , To: "Tony Hain" From: Joe Abley In-Reply-To: Message-Id: <4D6AEC77-893F-11D6-8825-00039312C852@automagic.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, June 26, 2002, at 03:29 , Tony Hain wrote: > While I believe this document still assumes too much in terms of > affecting policy outside the domain of direct administrative control, I > have to agree it is time to ship it. There is one comment about the IESG > in 3.2.7 that simply doesn't belong in any I-D, so I wouldn't be > surprised when the IESG asks to have it changed or removed. If the words > 'within the IESG' were removed, the sentence would stand and makes much > more sense than worrying about IETF process in a mechanism requirements > doc. I have made that change in my working copy. Joe From owner-multi6@ops.ietf.org Wed Jun 26 18:08: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 SAA13365 for ; Wed, 26 Jun 2002 18:08:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17NKxD-000J0c-00 for multi6-data@psg.com; Wed, 26 Jun 2002 15:07:59 -0700 Received: from sequoia.muada.com ([213.156.1.123]) by psg.com with esmtp (Exim 3.36 #1) id 17NKx8-000J0P-00 for multi6@ops.ietf.org; Wed, 26 Jun 2002 15:07:55 -0700 Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g5QM89655566; Thu, 27 Jun 2002 00:08:09 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Thu, 27 Jun 2002 00:08:09 +0200 (CEST) From: Iljitsch van Beijnum To: Sean Doran cc: Subject: Re: draft-ietf-multi6-multihoming-requirements-03 In-Reply-To: <20020626133335.AB52F821@ab.use.net> Message-ID: <20020626230242.U51646-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-5.3 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT version=2.30 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 26 Jun 2002, Sean Doran wrote: | In fact you made me think of one possible unexpected consequence. If we allow | diffserv code points to influence multihoming policy, it would be possible for | someone who thought they were setting QOS policy to accidentally influence | multihoming policy. That's not a very welcome side effect, but it may be | inevitable. I don't think this will be much of a problem in practice. If traffic reaching the "multihomer/load balancer" doesn't have a code point yet, the multihomer will have to set in order to achieve load balancing. For instance, if there is an OC3 low delay circuit and an OC12 high delay circuit, it may set the a code point that has the effect the OC3 circuit is selected for 20% of all packets, and another code point that has the effect the OC12 circuit is selected for the remaining 80% of all packets. If a packet already has a diffserv code point asking for a certain phb, the multihomer can do two things: 1. grant the request and forward and leave the code point alone (or translate it into another to achieve the desired effect) 2. refuse the request and overwrite the code point Always doing 1 frustrates load balancing, and always doing 2 frustrates the application. Some adaptability is needed here. For instance, if 10% of the traffic asks for a "low delay" service, the multihomer/load balancer will simply select the OC3 code point for 11% of the remaining traffic, so 20% of the traffic (10% by request, 10% randomly selected to balance the load) goes over the OC3 and the rest over the OC12 circuit. And what happens when the OC3 line goes down? Simple: the device that previously forwarded packets over either the OC3 or OC12 circuit should be smart enough to not forward data over a broken circuit, so now all traffic flows over the OC12 circuit, disregarding the traffic classification efforts of both the source and the multihoming/load balancing device. > How should this be reflected within the multi6 reqs document (if at all)? Is there anything to be required? I earn part of my living by telling people how to multihome. They are willing to part with a decent sum of money for this advice. The same isn't true for differentiated services: end users don't care. So I don't think diffserv problems should be show stopper for multihoming. And anything that isn't a show stopper shouldn't be in a requirements document. (Sure, we can make it a "nice to have" document...) > Should one do anything about the doors separating IPv6-global-unicast-format > from extensions of various flavours, including encoding destination information > in places other than strictly the destination address? Do we really want NAT in v6? > source > | > . > . > | > upstream > / \ > transit-l transit-r > \ / > dest. Isn't this a bit oversimplified? This assumes there is a single place where all decisions can be taken. If this is true, then we haven't achieved full multihoming (there is still a single point of failure.) In reality, things will look more like: Source / \ A B / \ / \ C D--E F \ / \ / G H \ / Destination Since selecting the link over AS H to the destination rather than the link over AS G means (potentially) influencing the routing decisions made in A, B, and E (and of course the source), this goes directly against the current distance path routing and hop-by-hop forwarding paradigms. However, IDPR should be able to handle this quite nicely. From owner-multi6@ops.ietf.org Wed Jun 26 20:28:49 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16858 for ; Wed, 26 Jun 2002 20:28:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17NN8y-000MiM-00 for multi6-data@psg.com; Wed, 26 Jun 2002 17:28:16 -0700 Received: from evrtwa1-ar8-4-65-028-011.evrtwa1.dsl-verizon.net ([4.65.28.11] helo=tndh.net) by psg.com with esmtp (Exim 3.36 #1) id 17NN8u-000Mi9-00 for multi6@ops.ietf.org; Wed, 26 Jun 2002 17:28:12 -0700 Received: from eagleswings (127.0.0.1) by localhost (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Wed, 26 Jun 2002 17:29:13 -0700 From: "Tony Hain" To: "Iljitsch van Beijnum" , "Sean Doran" Cc: Subject: RE: draft-ietf-multi6-multihoming-requirements-03 Date: Wed, 26 Jun 2002 17:27:56 -0700 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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <20020626230242.U51646-100000@sequoia.muada.com> Importance: Normal X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO version=2.30 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > ... > > source > > | > > . > > . > > | > > upstream > > / \ > > transit-l transit-r > > \ / > > dest. > > Isn't this a bit oversimplified? This assumes there is a single place > where all decisions can be taken. If this is true, then we haven't > achieved full multihoming (there is still a single point of > failure.) In > reality, things will look more like: > > Source > / \ > A B > / \ / \ > C D--E F > \ / \ / > G H > \ / > Destination > > Since selecting the link over AS H to the destination rather > than the link > over AS G means (potentially) influencing the routing > decisions made in A, > B, and E (and of course the source), this goes directly against the > current distance path routing and hop-by-hop forwarding paradigms. And perpetuating the idea that Dest has any influence on routing beyond G & H where it is paying for service, amounts to a fraud on the scale of the current accounting scandals. If Src prefers A who in turn chooses to prefer C, there is nothing Dest can do to change that. Any requirement that states one AS MUST be able to affect the policy of another AS will simply be ignored, if not by the implementations, certainly by the target AS where the policy is attempting to be overridden. > However, IDPR should be able to handle this quite nicely. > > To be seen. From owner-multi6@ops.ietf.org Thu Jun 27 06:43:06 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09935 for ; Thu, 27 Jun 2002 06:43:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17NWiw-000BVw-00 for multi6-data@psg.com; Thu, 27 Jun 2002 03:42:02 -0700 Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by psg.com with esmtp (Exim 3.36 #1) id 17NWir-000BVk-00 for multi6@ops.ietf.org; Thu, 27 Jun 2002 03:41:58 -0700 Received: from roadrunner.ecs.soton.ac.uk (roadrunner.ecs.soton.ac.uk [152.78.68.161]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id LAA02841 for ; Thu, 27 Jun 2002 11:41:56 +0100 (BST) Received: from login (IDENT:/0rouc1WCLu44sVtQpSnaX71eVkm7kpc@login.ecs.soton.ac.uk [152.78.68.149]) by roadrunner.ecs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id g5RAftnt025317 for ; Thu, 27 Jun 2002 11:41:55 +0100 Date: Thu, 27 Jun 2002 11:41:55 +0100 (BST) From: Tim Chown To: multi6@ops.ietf.org Subject: Re: draft-ietf-multi6-multihoming-requirements-03 In-Reply-To: <20020626230242.U51646-100000@sequoia.muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.2 required=5.0 tests=IN_REP_TO,X_NOT_PRESENT,DOUBLE_CAPSWORD version=2.30 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 27 Jun 2002, Iljitsch van Beijnum wrote: > I don't think this will be much of a problem in practice. If traffic > reaching the "multihomer/load balancer" doesn't have a code point yet, the > multihomer will have to set in order to achieve load balancing. For > instance, if there is an OC3 low delay circuit and an OC12 high delay > circuit, it may set the a code point that has the effect the OC3 circuit > is selected for 20% of all packets, and another code point that has the > effect the OC12 circuit is selected for the remaining 80% of all packets. I assume from this discussion that there is little hope that schemes such as Scavenger (less than best effort) will become widely used outside of the academic research networks? Such schemes have the attraction that there is no deployment effort required per se except that DSCP values should be passed unaltered if the intervening network does not utilise the DSCP (which is not uncommon where currently the academic backbone networks are not congested, but the MANs and edges are). I see no reason why IPv6 and LBE couldn't be used together, but an IPv6 multihoming model based on DSCPs would break this. What's the current stance on global significance of DSCP values (in this instance, Scavenger uses DSCP 8, a value adopted by US and European research networks). Tim From owner-multi6@ops.ietf.org Thu Jun 27 07:49:58 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12515 for ; Thu, 27 Jun 2002 07:49:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 17NXmF-000Dj3-00 for multi6-data@psg.com; Thu, 27 Jun 2002 04:49:31 -0700 Received: from d12lmsgate.de.ibm.com ([195.212.91.199]) by psg.com with esmtp (Exim 3.36 #1) id 17NXmB-000Diq-00 for multi6@ops.ietf.org; Thu, 27 Jun 2002 04:49:27 -0700 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.3/8.12.3) with ESMTP id g5RBmlAu018438; Thu, 27 Jun 2002 13:48:48 +0200 Received: from etzel.zurich.ibm.com (etzel.zurich.ibm.com [9.4.64.140]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.1) with SMTP id g5RBmkZ35728; Thu, 27 Jun 2002 13:48:47 +0200 Received: from dhcp23-199.zurich.ibm.com by etzel.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA19498 from ; Thu, 27 Jun 2002 13:48:44 +0200 Message-Id: <3D1AFBD1.4322D650@hursley.ibm.com> Date: Thu, 27 Jun 2002 13:49:37 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Tim Chown Cc: multi6@ops.ietf.org Subject: Re: draft-ietf-multi6-multihoming-requirements-03 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.30 X-Spam-Level: * Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tim Chown wrote: ... > What's the current stance on global > significance of DSCP values (in this instance, Scavenger uses DSCP 8, a > value adopted by US and European research networks). Exactly what it's always been. They are locally mappable in every domain. This isn't going to change, but it doesn't prevent a RECOMMENDED value if the scavenger PHB or one of its relatives gets standardised. There's nothing special about the scavenger PHB in this respect. The same issue of mapping at domain boundaries arises for any DSCP. Let's not have that particular flamefest here. The diffserv-interest list is the place for that. brian