From owner-multi6@ops.ietf.org Wed Jan 2 21:02: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 VAA14022 for ; Wed, 2 Jan 2002 21:02:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Lx9U-0001vR-00 for multi6-data@psg.com; Wed, 02 Jan 2002 17:58:40 -0800 Received: from relay1.nexsi.com ([66.35.205.133]) by psg.com with esmtp (Exim 3.33 #1) id 16Lx9T-0001vL-00 for multi6@ops.ietf.org; Wed, 02 Jan 2002 17:58:39 -0800 Received: from mail.nexsi.com (unknown [66.35.212.41]) by relay1.nexsi.com (Postfix) with ESMTP id 763893F67; Wed, 2 Jan 2002 18:01:15 -0800 (PST) Received: from khonsu.sw.nexsi.com ([172.17.212.34]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id SAA00985; Wed, 2 Jan 2002 18:02:15 -0800 Date: Wed, 2 Jan 2002 18:02:13 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <120543238435.20020102180213@nexsi.com> To: "Michel Py" Cc: "J. Noel Chiappa" , multi6@ops.ietf.org Subject: Re: Missing DNS reqt? [was Re: (multi6) requirements draft comments] In-Reply-To: <2B81403386729140A3A899A8B39B046403D5BB@server2000.arneill-py.sacramento.ca.us> References: <2B81403386729140A3A899A8B39B046403D5BB@server2000.arneill-py.sacramento.ca.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Michel, I'm catching up on the discussion after holidays, so bear with me if I'm missing something... > It does not need to be a centralized directory. If the endpoint "name" > is addressable (I do not like "name" in this context as it implies > DNS but I will keep it for consitency) the endpoint itself can answer > queries about its own locations <== (more than one). > In the concept I propose, what you call name is a PI address, and > its locations are several PA addresses. The key is to make the name > itself addressable. If you make EID (your PI address) "addressable" and expect it to be usable by the endpoint to tell its routing names, then EID needs to be routable (and assumably under any possible connectivity scenarios), hence we seem to end up with the same problem---the routing system has to handle non-connectivity-based addresses. My understanding is that separating routing names from EIDs makes sense if the routing system does not need to know anything about EIDs. Regarding the question of whether EID->routing name mapping should be done through DNS together with DN->EID mapping or through a separate packet exchange. I think it is important to keep in mind node mobility, where the node's routing name changes dynamically. The relatively static nature of [at least] today DNS does not converge well with possible dynamics of the routing name. Alex. From owner-multi6@ops.ietf.org Wed Jan 2 22:42: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 WAA16731 for ; Wed, 2 Jan 2002 22:42:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Lyke-0003py-00 for multi6-data@psg.com; Wed, 02 Jan 2002 19:41:08 -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 16Lykd-0003ph-00 for multi6@ops.ietf.org; Wed, 02 Jan 2002 19:41:07 -0800 content-class: urn:content-classes:message Subject: RE: Missing DNS reqt? [was Re: (multi6) requirements draft comments] Date: Wed, 2 Jan 2002 19:41:01 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405DE19@server2000.arneill-py.sacramento.ca.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: Missing DNS reqt? [was Re: (multi6) requirements draft comments] Thread-Index: AcGT+jt8IkEwT2K8TFeqp9eSRm8YZgABmuEA From: "Michel Py" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 To: "Alex Zinin" 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 WAA16731 Alex, >> Michel Py Wrote: >> It does not need to be a centralized directory. If the endpoint "name" >> is addressable (I do not like "name" in this context as it implies >> DNS but I will keep it for consitency) the endpoint itself can answer >> queries about its own locations <== (more than one). >> In the concept I propose, what you call name is a PI address, and >> its locations are several PA addresses. The key is to make the name >> itself addressable. > Alex Zinin wrote: > If you make EID (your PI address) "addressable" and expect it to be > usable by the endpoint to tell its routing names, then EID needs to > be routable (and assumably under any possible connectivity scenarios), Yes. If it is addressable it needs to be routable and routed. And, in the case of Tony's geo PI, it also needs to be aggregated. > hence we seem to end up with the same problem---the routing system > has to handle non-connectivity-based addresses. I am not sure I fully understand what you mean here. I would not call a PI address a non-connecticity-based address. > My understanding is that separating routing names from EIDs makes > sense if the routing system does not need to know anything about EIDs. Although I agree, I think that this topic would be better addressed by looking at the specifics of each solution. For my model, I think that it would be appropriate to say: resolve(name) = EID = PI address locations = PA addresses > Regarding the question of whether EID->routing name mapping > should be done through DNS together with DN->EID mapping or > through a separate packet exchange. This is why it is a good idea for each solution to precisely describe the impact it has on DNS, so we can evaluate if it could possibly fly with DNS or needs son-of-DNS. > I think it is important > to keep in mind node mobility, where the node's routing name > changes dynamically. The relatively static nature of [at least] > today DNS does not converge well with possible dynamics of the > routing name. That is quite another story. The title of this working group is: "Site Multihoming in IPv6" which implies that a site is not moving too often. This would be better answered by the chairs, but I personally think that multihoming for mobile IPv6 is out of scope here. Not that we don't like it, but we have a big enough problem. Michel. From owner-multi6@ops.ietf.org Wed Jan 2 23:51: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 XAA17583 for ; Wed, 2 Jan 2002 23:51:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16LzpK-00057b-00 for multi6-data@psg.com; Wed, 02 Jan 2002 20:50:02 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.33 #1) id 16LzpJ-00057G-00 for multi6@ops.ietf.org; Wed, 02 Jan 2002 20:50:01 -0800 Received: from [128.177.194.119] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id A82C13190D; Wed, 2 Jan 2002 20:50:00 -0800 (PST) User-Agent: Microsoft-Entourage/10.0.0.1331 Date: Wed, 02 Jan 2002 20:50:03 -0800 Subject: Re: Missing DNS reqt? [was Re: (multi6) requirements draft comments] From: David Conrad To: Alex Zinin , Michel Py Cc: "J. Noel Chiappa" , multi6 Message-ID: In-Reply-To: <120543238435.20020102180213@nexsi.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, On 1/2/02 6:02 PM, "Alex Zinin" wrote: > If you make EID (your PI address) "addressable" and expect it to be > usable by the endpoint to tell its routing names, then EID needs to > be routable Not necessarily. If you have some mechanism that maps between the EID and the locator, you can route on the locator independently of the routability of the EID. Numerous mechanisms can be imagined which could provide such a mapping service (DNS among them). > Regarding the question of whether EID->routing name mapping should > be done through DNS together with DN->EID mapping or through a > separate packet exchange. I think it is important to keep in mind > node mobility, where the node's routing name changes dynamically. > The relatively static nature of [at least] today DNS does not > converge well with possible dynamics of the routing name. My feeling is that any mobility solution that relies on the variability of an EID is doomed given current name to address translation technology. Not only do you have to worry about stuff like DNS TTLs, but you must deal with the fact that applications themselves cache addresses (that is, application data structures know what an address is). If, however, the EID is separated from the locator, you can vary the locator according to topology changes (be they provider driven or the fact you've roamed between one cell tower to another) without changing the bucket o' bits applications have memcpy'd from the struct hostent returned by gethostbyname(). In this model, DNS TTLs become relevant (assuming the locators are looked up via DNS), but that is relatively easy to deal with. Rgds, -drc From owner-multi6@ops.ietf.org Wed Jan 2 23:58:32 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17646 for ; Wed, 2 Jan 2002 23:58:32 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Lzvc-0005GP-00 for multi6-data@psg.com; Wed, 02 Jan 2002 20:56:32 -0800 Received: from shell.nominum.com ([128.177.192.160]) by psg.com with esmtp (Exim 3.33 #1) id 16Lzvb-0005GI-00 for multi6@ops.ietf.org; Wed, 02 Jan 2002 20:56:31 -0800 Received: from [128.177.194.119] (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 66BD73190D; Wed, 2 Jan 2002 20:56:31 -0800 (PST) User-Agent: Microsoft-Entourage/10.0.0.1331 Date: Wed, 02 Jan 2002 20:56:34 -0800 Subject: Re: Missing DNS reqt? [was Re: (multi6) requirements draft comments] From: David Conrad To: Michel Py , Alex Zinin Cc: multi6 Message-ID: In-Reply-To: <2B81403386729140A3A899A8B39B046405DE19@server2000.arneill-py.sacramento.ca.us> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, On 1/2/02 7:41 PM, "Michel Py" wrote: > The title of this working group is: > "Site Multihoming in IPv6" which implies that a site is not moving > too often. I didn't see that implication. > This would be better answered by the chairs, but I > personally think that multihoming for mobile IPv6 is out of scope > here. While I tend to agree that it is out of scope for the working group, I personally see multi-homing, mobility, and renumbering as facets of the same problem, namely the use of the end point identifier as the routing locator. A solution that addresses (pun intended) the multi-homing requirement may also address the mobility/renumbering problem. Rgds, -drc From owner-multi6@ops.ietf.org Thu Jan 3 03:23: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 DAA27616 for ; Thu, 3 Jan 2002 03:23:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16M33f-0009DA-00 for multi6-data@psg.com; Thu, 03 Jan 2002 00:17:03 -0800 Received: from relay1.nexsi.com ([66.35.205.133]) by psg.com with esmtp (Exim 3.33 #1) id 16M33e-0009D4-00 for multi6@ops.ietf.org; Thu, 03 Jan 2002 00:17:02 -0800 Received: from mail.nexsi.com (unknown [66.35.212.41]) by relay1.nexsi.com (Postfix) with ESMTP id BACE33F63; Thu, 3 Jan 2002 00:19:38 -0800 (PST) Received: from khonsu.sw.nexsi.com (cscovpn4.nexsi.com [172.16.213.4]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id AAA02124; Thu, 3 Jan 2002 00:20:39 -0800 Date: Thu, 3 Jan 2002 00:20:39 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <68565940719.20020103002039@nexsi.com> To: "Michel Py" Cc: multi6@ops.ietf.org Subject: Re: Missing DNS reqt? [was Re: (multi6) requirements draft comments] In-Reply-To: <2B81403386729140A3A899A8B39B046405DE19@server2000.arneill-py.sacramento.ca.us> References: <2B81403386729140A3A899A8B39B046405DE19@server2000.arneill-py.sacramento.ca.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Michel, >> If you make EID (your PI address) "addressable" and expect it to be >> usable by the endpoint to tell its routing names, then EID needs to >> be routable (and assumably under any possible connectivity scenarios), > Yes. If it is addressable it needs to be routable and routed. And, in the > case of Tony's geo PI, it also needs to be aggregated. >> hence we seem to end up with the same problem---the routing system >> has to handle non-connectivity-based addresses. > I am not sure I fully understand what you mean here. I would not call > a PI address a non-connecticity-based address. My bad. The term was induced by some next gen addr/rtg architecture ideas, much in line with Noel's where the addresses are derived from the routing structure. PA would then be connectivity-based, while PI would not. To ensure efficient abbreviation of reachability information as it is distributed through a routing system, it is important to minimize (ideally eliminate) non-connectivity based information. Splitting the routing name and EID notions (routing and transport names) allows the routing system to bother with connectivity-based addresses only. Requiring EIDs to be routable essentially defeats the purpose of split---the same old problem is applicable to EIDs now. >> My understanding is that separating routing names from EIDs makes >> sense if the routing system does not need to know anything about EIDs. > Although I agree, I think that this topic would be better > addressed by looking at the specifics of each solution. > For my model, I think that it would be appropriate to say: > resolve(name) = EID = PI address > locations = PA addresses Still, in your case PIs need to be routable and routable through multiple SPs... >> I think it is important >> to keep in mind node mobility, where the node's routing name >> changes dynamically. The relatively static nature of [at least] >> today DNS does not converge well with possible dynamics of the >> routing name. > That is quite another story. The title of this working group is: > "Site Multihoming in IPv6" which implies that a site is not moving > too often. This would be better answered by the chairs, but I > personally think that multihoming for mobile IPv6 is out of scope > here. Not that we don't like it, but we have a big enough problem. Whether this is within the WG charter or not, as well as whether we like it or not, mobility is essentially a very dynamic case of multihoming. I would hate seeing us producing an architecture for any of them that would ignore the presence of the other. Alex. From owner-multi6@ops.ietf.org Thu Jan 3 03:29:04 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27644 for ; Thu, 3 Jan 2002 03:29:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16M3Es-0009S2-00 for multi6-data@psg.com; Thu, 03 Jan 2002 00:28:38 -0800 Received: from relay1.nexsi.com ([66.35.205.133]) by psg.com with esmtp (Exim 3.33 #1) id 16M3Es-0009Rw-00 for multi6@ops.ietf.org; Thu, 03 Jan 2002 00:28:38 -0800 Received: from mail.nexsi.com (unknown [66.35.212.41]) by relay1.nexsi.com (Postfix) with ESMTP id 5C9603F63; Thu, 3 Jan 2002 00:31:14 -0800 (PST) Received: from khonsu.sw.nexsi.com (cscovpn4.nexsi.com [172.16.213.4]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id AAA02137; Thu, 3 Jan 2002 00:32:13 -0800 Date: Thu, 3 Jan 2002 00:32:14 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <108566635719.20020103003214@nexsi.com> To: David Conrad Cc: Michel Py , "J. Noel Chiappa" , multi6 Subject: Re: Missing DNS reqt? [was Re: (multi6) requirements draft comments] In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit David, >> If you make EID (your PI address) "addressable" and expect it to be >> usable by the endpoint to tell its routing names, then EID needs to >> be routable > Not necessarily. If you have some mechanism that maps between the EID and > the locator, you can route on the locator independently of the routability > of the EID. Numerous mechanisms can be imagined which could provide such a > mapping service (DNS among them). Generally yes. In fact, I would even say the routing system should know nothing about EIDs. This is not they case with Michel's proposal, though. >> Regarding the question of whether EID->routing name mapping should >> be done through DNS together with DN->EID mapping or through a >> separate packet exchange. I think it is important to keep in mind >> node mobility, where the node's routing name changes dynamically. >> The relatively static nature of [at least] today DNS does not >> converge well with possible dynamics of the routing name. > My feeling is that any mobility solution that relies on the variability of > an EID is doomed given current name to address translation technology. Not > only do you have to worry about stuff like DNS TTLs, but you must deal with > the fact that applications themselves cache addresses (that is, application > data structures know what an address is). Agree. That's why I think DNS should provide DN->EID mapping where EID should stay static regardless of the nodes's location/connectivity, and this is the EID->locator (routing name) mapping that should account for dynamic changes in it. > If, however, the EID is separated from the locator, you can vary the locator > according to topology changes (be they provider driven or the fact you've > roamed between one cell tower to another) without changing the bucket o' > bits applications have memcpy'd from the struct hostent returned by > gethostbyname(). Agreed. > In this model, DNS TTLs become relevant (assuming the > locators are looked up via DNS), but that is relatively easy to deal with. Frankly, I'm having trouble imagining a DNS-based system used to provide the EID->location mapping dynamic enough and scalable at the same time to work for mobile nodes. That's another story though... Alex. From owner-multi6@ops.ietf.org Thu Jan 3 03:30:16 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27661 for ; Thu, 3 Jan 2002 03:30:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16M3GM-0009Uj-00 for multi6-data@psg.com; Thu, 03 Jan 2002 00:30:10 -0800 Received: from relay1.nexsi.com ([66.35.205.133]) by psg.com with esmtp (Exim 3.33 #1) id 16M3GL-0009Ua-00 for multi6@ops.ietf.org; Thu, 03 Jan 2002 00:30:09 -0800 Received: from mail.nexsi.com (unknown [66.35.212.41]) by relay1.nexsi.com (Postfix) with ESMTP id 00D073F63; Thu, 3 Jan 2002 00:32:45 -0800 (PST) Received: from khonsu.sw.nexsi.com (cscovpn4.nexsi.com [172.16.213.4]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id AAA02142; Thu, 3 Jan 2002 00:33:50 -0800 Date: Thu, 3 Jan 2002 00:33:51 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <76566732498.20020103003351@nexsi.com> To: David Conrad Cc: Michel Py , multi6 Subject: Re: Missing DNS reqt? [was Re: (multi6) requirements draft comments] In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> This would be better answered by the chairs, but I >> personally think that multihoming for mobile IPv6 is out of scope >> here. > While I tend to agree that it is out of scope for the working group, I > personally see multi-homing, mobility, and renumbering as facets of the same > problem, namely the use of the end point identifier as the routing locator. > A solution that addresses (pun intended) the multi-homing requirement may > also address the mobility/renumbering problem. Agree completely. Alex. From owner-multi6@ops.ietf.org Thu Jan 3 07:35:04 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00016 for ; Thu, 3 Jan 2002 07:35:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16M74C-000DW8-00 for multi6-data@psg.com; Thu, 03 Jan 2002 04:33:52 -0800 Received: from zeus.anet-chi.com ([207.7.4.6]) by psg.com with esmtp (Exim 3.33 #1) id 16M74B-000DW2-00 for multi6@ops.ietf.org; Thu, 03 Jan 2002 04:33:51 -0800 Received: from RepliGate (as1b-45.chi.il.dial.anet.com [198.92.157.45]) by zeus.anet-chi.com (8.12.1/8.12.0) with SMTP id g03CXX8j017545; Thu, 3 Jan 2002 06:33:34 -0600 (CST) Message-ID: <054701c1946b$787946f0$0100a8c0@RepliGate> From: "Jim Fleming" To: "Alex Zinin" , "David Conrad" Cc: "Michel Py" , "J. Noel Chiappa" , "multi6" References: <108566635719.20020103003214@nexsi.com> Subject: Re: Missing DNS reqt? [was Re: (multi6) requirements draft comments] Date: Thu, 3 Jan 2002 07:29:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Do you use a 2002 prefix ? Jim Fleming 2002:[IPv4]:000X:03DB http://www.IPv8.info ----- Original Message ----- From: "Alex Zinin" To: "David Conrad" Cc: "Michel Py" ; "J. Noel Chiappa" ; "multi6" Sent: Thursday, January 03, 2002 12:32 AM Subject: Re: Missing DNS reqt? [was Re: (multi6) requirements draft comments] > > David, > > >> If you make EID (your PI address) "addressable" and expect it to be > >> usable by the endpoint to tell its routing names, then EID needs to > >> be routable > > > Not necessarily. If you have some mechanism that maps between the EID and > > the locator, you can route on the locator independently of the routability > > of the EID. Numerous mechanisms can be imagined which could provide such a > > mapping service (DNS among them). > > Generally yes. In fact, I would even say the routing system should > know nothing about EIDs. This is not they case with Michel's proposal, > though. > > >> Regarding the question of whether EID->routing name mapping should > >> be done through DNS together with DN->EID mapping or through a > >> separate packet exchange. I think it is important to keep in mind > >> node mobility, where the node's routing name changes dynamically. > >> The relatively static nature of [at least] today DNS does not > >> converge well with possible dynamics of the routing name. > > > My feeling is that any mobility solution that relies on the variability of > > an EID is doomed given current name to address translation technology. Not > > only do you have to worry about stuff like DNS TTLs, but you must deal with > > the fact that applications themselves cache addresses (that is, application > > data structures know what an address is). > > Agree. That's why I think DNS should provide DN->EID mapping where > EID should stay static regardless of the nodes's location/connectivity, > and this is the EID->locator (routing name) mapping that should account > for dynamic changes in it. > > > If, however, the EID is separated from the locator, you can vary the locator > > according to topology changes (be they provider driven or the fact you've > > roamed between one cell tower to another) without changing the bucket o' > > bits applications have memcpy'd from the struct hostent returned by > > gethostbyname(). > > Agreed. > > > In this model, DNS TTLs become relevant (assuming the > > locators are looked up via DNS), but that is relatively easy to deal with. > > Frankly, I'm having trouble imagining a DNS-based system used to > provide the EID->location mapping dynamic enough and scalable at > the same time to work for mobile nodes. That's another story though... > > Alex. > > > From owner-multi6@ops.ietf.org Thu Jan 3 10:33: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 KAA03950 for ; Thu, 3 Jan 2002 10:33:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16M9pW-000G8N-00 for multi6-data@psg.com; Thu, 03 Jan 2002 07:30: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 16M9pV-000G8G-00 for multi6@ops.ietf.org; Thu, 03 Jan 2002 07:30: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 QAA08846; Thu, 3 Jan 2002 16:30:44 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA19772 from ; Thu, 3 Jan 2002 16:30:42 +0100 Message-Id: <3C347922.FC47EBA0@hursley.ibm.com> Date: Thu, 03 Jan 2002 16:30:42 +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: Alex Zinin Cc: David Conrad , Michel Py , "J. Noel Chiappa" , multi6 Subject: Re: Missing DNS reqt? [was Re: (multi6) requirements draft comments] References: <108566635719.20020103003214@nexsi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Alex Zinin wrote: > > David, ... > Agree. That's why I think DNS should provide DN->EID mapping where > EID should stay static regardless of the nodes's location/connectivity, > and this is the EID->locator (routing name) mapping that should account > for dynamic changes in it. This sounds exactly like a description of mobility, and exactly like a description of multihoming. I don't think we should be scared of common solutions (which is not the same as saying MIPv6 is the solution for multihoming). Brian From owner-multi6@ops.ietf.org Thu Jan 3 10:42:12 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04086 for ; Thu, 3 Jan 2002 10:42:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16M9zl-000GGf-00 for multi6-data@psg.com; Thu, 03 Jan 2002 07:41:29 -0800 Received: from sean.ebone.net ([195.158.227.211]) by psg.com with esmtp (Exim 3.33 #1) id 16M9zl-000GGZ-00 for multi6@ops.ietf.org; Thu, 03 Jan 2002 07:41:29 -0800 Received: by sean.ebone.net (Postfix, from userid 1113) id 6856984C; Thu, 3 Jan 2002 16:41:27 +0100 (CET) To: azinin@nexsi.com, brian@hursley.ibm.com Subject: Re: Missing DNS reqt? [was Re: (multi6) requirements draft comments] Cc: david.conrad@nominum.com, jnc@ginger.lcs.mit.edu, michel@arneill-py.sacramento.ca.us, multi6@ops.ietf.org Message-Id: <20020103154127.6856984C@sean.ebone.net> Date: Thu, 3 Jan 2002 16:41:27 +0100 (CET) From: smd@ebone.net (Sean Doran) Sender: owner-multi6@ops.ietf.org Precedence: bulk | This sounds exactly like a description of mobility, and exactly like | a description of multihoming. I don't think we should be scared of | common solutions (which is not the same as saying MIPv6 is the | solution for multihoming). Remember that this WG is charterd to solve SITE multihoming, rather than host multihoming. If the former, which implies simultaneous connectivity and/or migration for a collection of hosts from a few to a vast number, can be done using the mechanisms of the latter (e.g. multi-addressed hosts, MIP6), that's fine and dandy. However, first, the charter documents need to be pushed along the standards track, as discussed in SLC. Sean. From owner-multi6@ops.ietf.org Thu Jan 3 11:10: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 LAA04965 for ; Thu, 3 Jan 2002 11:10:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16MARy-000GhO-00 for multi6-data@psg.com; Thu, 03 Jan 2002 08:10:38 -0800 Received: from zeus.anet-chi.com ([207.7.4.6]) by psg.com with esmtp (Exim 3.33 #1) id 16MARy-000GhH-00 for multi6@ops.ietf.org; Thu, 03 Jan 2002 08:10:38 -0800 Received: from RepliGate (as1b-45.chi.il.dial.anet.com [198.92.157.45]) by zeus.anet-chi.com (8.12.1/8.12.0) with SMTP id g03G9g8j013861; Thu, 3 Jan 2002 10:09:43 -0600 (CST) Message-ID: <079801c19489$aaed66c0$0100a8c0@RepliGate> From: "Jim Fleming" To: , , "Sean Doran" Cc: , , , References: <20020103154127.6856984C@sean.ebone.net> Subject: Remember that this WG is charterd to solve SITE multihoming Date: Thu, 3 Jan 2002 11:05:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Sean Doran" > Remember that this WG is charterd to solve SITE multihoming, OK, what is your solution ? Jim Fleming 2002:[IPv4]:000X:03DB http://www.IPv8.info From owner-multi6@ops.ietf.org Thu Jan 3 11:15: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 LAA05184 for ; Thu, 3 Jan 2002 11:15:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16MAWE-000Gm0-00 for multi6-data@psg.com; Thu, 03 Jan 2002 08:15:02 -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 16MAWD-000Gla-00 for multi6@ops.ietf.org; Thu, 03 Jan 2002 08:15:01 -0800 content-class: urn:content-classes:message Subject: RE: Missing DNS reqt? [was Re: (multi6) requirements draft comments] Date: Thu, 3 Jan 2002 08:14:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <2B81403386729140A3A899A8B39B046403D5E2@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: Missing DNS reqt? [was Re: (multi6) requirements draft comments] Thread-Index: AcGUMPQmoiHPi8yHTyW/oqbpc9FKuAAPuAjA From: "Michel Py" To: "Alex Zinin" , "David Conrad" Cc: "multi6" Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA05184 >>> Michel Py wrote: >>> This would be better answered by the chairs, but I >>> personally think that multihoming for mobile IPv6 is >>> out of scope here. >> David Conrad wrote: >> While I tend to agree that it is out of scope for the working group, >> I personally see multi-homing, mobility, and renumbering as facets of >> the same problem, namely the use of the end point identifier as the >> routing locator. I agree with this. >> A solution that addresses (pun intended) the multi-homing >> requirement may also address the mobility/renumbering problem. > Alex Zinin wrote: > Agree completely. At this time, I disagree with that. It is indeed a good idea, what I called a slam dunk before, "THE" multihoming solution that solves all three of the aspects of multihoming which are big honkin' setup, home/soho and mobile. The reason I disagree is that nobody has provided a clue in how to make it work so far. As several other people mentionned before, we have a collective responsibility in delivering something that will get IPv6 multihoming started, especially the part that is multihomed in IPv4 already. Pursuing that elusive universal solution is definitely interesting, but unless we see a draft that appears it can fly is IMHO out of scope here. Michel. From owner-multi6@ops.ietf.org Thu Jan 3 11:30:25 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05521 for ; Thu, 3 Jan 2002 11:30:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16MAkj-000H3d-00 for multi6-data@psg.com; Thu, 03 Jan 2002 08:30:01 -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 16MAkh-000H3U-00 for multi6@ops.ietf.org; Thu, 03 Jan 2002 08:30:00 -0800 content-class: urn:content-classes:message Subject: RE: Missing DNS reqt? [was Re: (multi6) requirements draft comments] Date: Thu, 3 Jan 2002 08:29:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <2B81403386729140A3A899A8B39B046405DE1A@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: Missing DNS reqt? [was Re: (multi6) requirements draft comments] Thread-Index: AcGUMMGmg8bn78v4TlCoUD23N3O1swAQW7Pg From: "Michel Py" To: "Alex Zinin" , "David Conrad" Cc: "multi6" Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA05521 >>> Alex Zinin wrote: >>> If you make EID (your PI address) "addressable" and expect it to be >>> usable by the endpoint to tell its routing names, then EID needs to >>> be routable >> David Conrad wrote: >> Not necessarily. If you have some mechanism that maps between the EID >> and the locator, you can route on the locator independently of the >> routability of the EID. Numerous mechanisms can be imagined which could >> provide such a mapping service (DNS among them). > Alex Zinin wrote: > Generally yes. In fact, I would even say the routing system should > know nothing about EIDs. This is not they case with Michel's proposal, > though. Actually, in the existing draft the routing system knows very little about PI addresses (a /16 aggregate) except for a small number of routers (The MHTP rendezvous points). I have in the works a version that will include non-centrally assigned PI addresses such as Tony's draft. Even in that situation, the vast majority of routers would know PI addresses only by very broad aggregates, wich will effectively rid us of the routing goop as we know it. > Frankly, I'm having trouble imagining a DNS-based system used to > provide the EID->location mapping dynamic enough and scalable at > the same time to work for mobile nodes. That's another story though... I have trouble imagining that one too. If it can be done, be it but I'd like to see something. Let's keep in mind that the most immediate problem at hand here is to avoid creating the same routing mess we have in v4. Michel. From owner-multi6@ops.ietf.org Thu Jan 3 11:59:23 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06040 for ; Thu, 3 Jan 2002 11:59:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16MBCY-000HbS-00 for multi6-data@psg.com; Thu, 03 Jan 2002 08:58:46 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.33 #1) id 16MBCX-000HbI-00 for multi6@ops.ietf.org; Thu, 03 Jan 2002 08:58:45 -0800 content-class: urn:content-classes:message Subject: RE: Missing DNS reqt? [was Re: (multi6) requirements draft comments] Date: Thu, 3 Jan 2002 08:58:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <2B81403386729140A3A899A8B39B046403D5E5@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: Missing DNS reqt? [was Re: (multi6) requirements draft comments] Thread-Index: AcGULxdInasbeg8wRtiAKb4AOE2lWQARPKMg From: "Michel Py" To: "Alex Zinin" 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 LAA06040 Alex, > Alex Zinin wrote: > My bad. The term was induced by some next gen addr/rtg architecture > ideas, much in line with Noel's where the addresses are derived > from the routing structure. PA would then be connectivity-based, > while PI would not. Reading it again, I would say it applies to my draft as well, since the PI addresses are designed to carry topology requests and the PA addresses the end-to-end traffic. Connectivity-based more or less equates to end-to-end traffic, I think. > To ensure efficient abbreviation of reachability information as > it is distributed through a routing system, it is important to > minimize (ideally eliminate) non-connectivity based information. Agreed. > Splitting the routing name and EID notions (routing and transport > names) allows the routing system to bother with connectivity-based > addresses only. Requiring EIDs to be routable essentially defeats > the purpose of split---the same old problem is applicable to > EIDs now. >> Michel Py wrote: >> For my model, I think that it would be appropriate to say: >> resolve(name) = EID = PI address >> locations = PA addresses > Alex Zinin wrote: > Still, in your case PIs need to be routable and routable > through multiple SPs... Yes, but they will not carry heavy traffic so the problem is somehow not as bad as it is today (latency would not really matter). There are two types of PI addresses: (1) Centrally assigned PI addresses, much like what we have today. (2) Tony's geo PI. Note that Tony's geo PI are not mentionned in the version of the MHTP draft you currently have. The reason I kept centrally assigned PI addresses (1) is market reality. Whatever we do, there will always be some people that will get their prefix advertised into the DFZ. Instead of putting our heads in the sand and pretend it will never happen, let's state that it should be reserved to large multinational corporations and put a very high price and hassle to get one of these and let's not make it part of the DFZ but rather keep it separate (in the MHTP routing table). Concerning Tony's PI (2), it can fly only if it is strongly aggregated. Given the scope of these, there is not even a possibility not to aggregate them. In this situation, a few geo aggregates in the DMZ would not bother anybody. Michel From owner-multi6@ops.ietf.org Thu Jan 3 12:03: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 MAA06129 for ; Thu, 3 Jan 2002 12:03:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16MBH9-000Hgt-00 for multi6-data@psg.com; Thu, 03 Jan 2002 09:03:31 -0800 Received: from mail1.microsoft.com ([131.107.3.125]) by psg.com with esmtp (Exim 3.33 #1) id 16MBH8-000Hgn-00 for multi6@ops.ietf.org; Thu, 03 Jan 2002 09:03:30 -0800 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.4617); Thu, 3 Jan 2002 09:03:28 -0800 Received: from 157.54.5.25 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 03 Jan 2002 09:03:28 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 3 Jan 2002 09:03:28 -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, 3 Jan 2002 09:03:28 -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, 3 Jan 2002 09:01:35 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6115.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Requirement document last call (let's focus!) Date: Thu, 3 Jan 2002 09:01:35 -0800 Message-ID: Thread-Topic: Requirement document last call (let's focus!) Thread-Index: AcGUbkWO8e1TAGPSQ8ydMOArC4iePwABlS4A From: "Christian Huitema" To: "Sean Doran" Cc: X-OriginalArrivalTime: 03 Jan 2002 17:01:35.0822 (UTC) FILETIME=[4D602EE0:01C19478] Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA06129 > | This sounds exactly like a description of mobility, and exactly like > | a description of multihoming. I don't think we should be scared of > | common solutions (which is not the same as saying MIPv6 is the > | solution for multihoming). > > Remember that this WG is charterd to solve SITE multihoming, > rather than host multihoming. If the former, which implies > simultaneous connectivity and/or migration for a collection of > hosts from a few to a vast number, can be done using the mechanisms > of the latter (e.g. multi-addressed hosts, MIP6), that's fine and > dandy. However, first, the charter documents need to be pushed > along the standards track, as discussed in SLC. Seconded! Let's first achieve the goal of the current charter, which is to publish the requirement document. And let's not try to tailor the requirement to a specific solution: this is the known way to not make progress. Could someone summarize the actual modifications to the requirement document that surfaced during this last call? I seem to recall the following: 1) 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. 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. 2) 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. Don't know whether that should be part of the requirement document. 3) 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." 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. Do you agree that this is a fair summary of the discussion on the requirements draft? I yes, we should maybe have a short editing pass, and then proceed towards publication of the requirements and rechartering of this group. -- Christian Huitema From owner-multi6@ops.ietf.org Thu Jan 3 13:57: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 NAA08207 for ; Thu, 3 Jan 2002 13:57:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16MD1Z-000Juf-00 for multi6-data@psg.com; Thu, 03 Jan 2002 10:55:33 -0800 Received: from cyphermail.sandelman.ottawa.on.ca ([192.139.46.78] helo=noxmail.sandelman.ottawa.on.ca) by psg.com with esmtp (Exim 3.33 #1) id 16MD1X-000JuY-00 for multi6@ops.ietf.org; Thu, 03 Jan 2002 10:55:32 -0800 Received: from marajade.sandelman.ottawa.on.ca ([2001:410:402:2:204:76ff:fe2d:8c]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id g03I2h700339 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Thu, 3 Jan 2002 13:02:46 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (localhost [[UNIX: localhost]]) by marajade.sandelman.ottawa.on.ca (8.11.6/8.11.0) with ESMTP id g03HmD417592 for ; Thu, 3 Jan 2002 12:48:18 -0500 (EST) Message-Id: <200201031748.g03HmD417592@marajade.sandelman.ottawa.on.ca> To: multi6@ops.ietf.org Subject: Re: Missing DNS reqt? [was Re: (multi6) requirements draft comments] In-reply-to: Your message of "Thu, 03 Jan 2002 08:58:44 PST." <2B81403386729140A3A899A8B39B046403D5E5@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 03 Jan 2002 12:48:13 -0500 From: Michael Richardson Sender: owner-multi6@ops.ietf.org Precedence: bulk >>>>> "Michel" == Michel Py writes: Michel> The reason I kept centrally assigned PI addresses (1) is market Michel> reality. Whatever we do, there will always be some people that will Michel> get their prefix advertised into the DFZ. Instead of putting our heads Michel> in the sand and pretend it will never happen, let's state that it Michel> should be reserved to large multinational corporations and put a Michel> very high price and hassle to get one of these and let's not make it Michel> part of the DFZ but rather keep it separate (in the MHTP routing table). Why "corporations" here? Why not "organizations"? Certainly the "Mars Colony" would have a very clear reason to have something in the DFZ. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From owner-multi6@ops.ietf.org Thu Jan 3 14:17:13 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08687 for ; Thu, 3 Jan 2002 14:17:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16MDLQ-000KNg-00 for multi6-data@psg.com; Thu, 03 Jan 2002 11:16:04 -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 16MDLP-000KNa-00 for multi6@ops.ietf.org; Thu, 03 Jan 2002 11:16:03 -0800 content-class: urn:content-classes:message Subject: RE: Missing DNS reqt? [was Re: (multi6) requirements draft comments] Date: Thu, 3 Jan 2002 11:16:03 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <2B81403386729140A3A899A8B39B046403D5E9@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: Missing DNS reqt? [was Re: (multi6) requirements draft comments] Thread-Index: AcGUimU3Vw4kTvhMSH+9m8H3R5NguAAANsLg From: "Michel Py" To: "Michael Richardson" , Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA08687 >> Michel Py wrote: >> The reason I kept centrally assigned PI addresses (1) is market >> reality. Whatever we do, there will always be some people that will >> get their prefix advertised into the DFZ. Instead of putting our eads >> in the sand and pretend it will never happen, let's state that it >> should be reserved to large multinational corporations and put a >> very high price and hassle to get one of these and let's not make it >> part of the DFZ but rather keep it separate (in the MHTP routing table). > Michael Richardson wrote: > Why "corporations" here? > Why not "organizations"? > Certainly the "Mars Colony" would have a very clear reason to > have something in the DFZ. Agreed, "organizations" is much better. Michel. From owner-multi6@ops.ietf.org Thu Jan 3 14:37: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 OAA09231 for ; Thu, 3 Jan 2002 14:37:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16MDfV-000KuN-00 for multi6-data@psg.com; Thu, 03 Jan 2002 11:36: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 16MDfS-000KuG-00 for multi6@ops.ietf.org; Thu, 03 Jan 2002 11:36:46 -0800 content-class: urn:content-classes:message Subject: (multi6) Requirement document last call /edit (let's focus!) Date: Thu, 3 Jan 2002 11:36:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <2B81403386729140A3A899A8B39B046405DE1B@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: (multi6) Requirement document last call /edit (let's focus!) Thread-Index: AcGUbkWO8e1TAGPSQ8ydMOArC4iePwABlS4AAAISljA= From: "Michel Py" To: "Christian Huitema" , "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 OAA09231 multi6 folk, I tried to summarize below the possible changes to the requirements document, based on Christian's last postingl hoping that I do not step on the authors' toes. PLEASE DO send changes/comments/opinions. >> Sean Doran wrote: >> Remember that this WG is charterd to solve SITE multihoming, >> rather than host multihoming. If the former, which implies >> simultaneous connectivity and/or migration for a collection of >> hosts from a few to a vast number, can be done using the mechanisms >> of the latter (e.g. multi-addressed hosts, MIP6), that's fine and >> dandy. However, first, the charter documents need to be pushed >> along the standards track, as discussed in SLC. > Christian Huitema wrote: > Seconded! > Let's first achieve the goal of the current charter, which is to > publish the requirement document. And let's not try to tailor the > requirement to a specific solution: this is the known way to not > make progress. Agreed! > Could someone summarize the actual modifications to the requirement > document that surfaced during this last call? I will try to do that below, and you just summarized the discussion about it, for the most part. > Do you agree that this is a fair summary of the discussion on the > requirements draft? I yes, we should maybe have a short editing pass, > and then proceed towards publication of the requirements and > rechartering of this group. Agreed. There is something else we have to deal with in the current charter: "Produce a document describing how multihoming is done today, including an explanation of both the advantages and limitations of the approaches". I do not intend to send a blow to the authors in any way, but does anybody really care about it? I wonder how the chairs and the WG would feel about taking that one out as part of the re-chartering. It never seemed to trigger much interest. In SLC there was not even a handful of people that raised their hand when asked if they have read it. Michel. ------------------------------------------------------------- Tentative summary of edits to the requirements documents: ------------------------------------------------------------- 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. Please send text Opinions on 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 don't think 3.1.2 should be changed. 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. Please send text. 3. Do nothing Opinions on 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". 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. Please send text 4. Do nothing Opinions on 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. 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 on 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. 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 on it: Add yours here: From owner-multi6@ops.ietf.org Thu Jan 3 14:46: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 OAA09523 for ; Thu, 3 Jan 2002 14:46:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16MDoi-000L7d-00 for multi6-data@psg.com; Thu, 03 Jan 2002 11:46:20 -0800 Received: from lint.cisco.com ([171.68.224.209]) by psg.com with esmtp (Exim 3.33 #1) id 16MDoi-000L7W-00 for multi6@ops.ietf.org; Thu, 03 Jan 2002 11:46:20 -0800 Received: from ELEAR-W2K1.cisco.com (sjc-vpn3-240.cisco.com [10.21.64.240]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA13155; Thu, 3 Jan 2002 11:45:46 -0800 (PST) Message-Id: <5.1.0.14.2.20020103114239.01d65658@lint.cisco.com> X-Sender: elear@lint.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 03 Jan 2002 11:45:55 -0800 To: "Christian Huitema" From: Eliot Lear Subject: Re: Requirement document last call (let's focus!) Cc: "Sean Doran" , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-multi6@ops.ietf.org Precedence: bulk At 09:01 AM 1/3/2002 -0800, Christian Huitema wrote: >Do you agree that this is a fair summary of the discussion on the >requirements draft? I yes, we should maybe have a short editing pass, and >then proceed towards publication of the requirements and rechartering of >this group. As I previously wrote: Section 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. Why are we adding the caveat of the last sentence? Manual anything is bad. In section 3.2.1: 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. Section 4 Security Considerations 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. Eliot From owner-multi6@ops.ietf.org Thu Jan 3 15:00: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 PAA09841 for ; Thu, 3 Jan 2002 15:00:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16ME13-000LQH-00 for multi6-data@psg.com; Thu, 03 Jan 2002 11:59:05 -0800 Received: from mx3out.umbc.edu ([130.85.253.53]) by psg.com with esmtp (Exim 3.33 #1) id 16ME12-000LQ8-00 for multi6@ops.ietf.org; Thu, 03 Jan 2002 11:59:04 -0800 Received: from gl.umbc.edu (vijay@irix2.gl.umbc.edu [130.85.60.11]) by mx3out.umbc.edu (8.12.0/8.12.0) with ESMTP id g03JxRva012903; Thu, 3 Jan 2002 14:59:27 -0500 (EST) Received: from localhost (vijay@localhost) by gl.umbc.edu (8.9.0/8.9.0) with ESMTP id OAA265216; Thu, 3 Jan 2002 14:59:01 -0500 (EST) X-Authentication-Warning: irix2.gl.umbc.edu: vijay owned process doing -bs Date: Thu, 3 Jan 2002 14:59:00 -0500 From: Vijay Gill X-X-Sender: To: Eliot Lear cc: Subject: Re: Requirement document last call (let's focus!) In-Reply-To: <5.1.0.14.2.20020103114239.01d65658@lint.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 3 Jan 2002, Eliot Lear wrote: > As I previously wrote: > > Section 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. > > Why are we adding the caveat of the last sentence? Manual anything is bad. 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. > 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. I'm fine with this. /vijay From owner-multi6@ops.ietf.org Thu Jan 3 15:46:29 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10940 for ; Thu, 3 Jan 2002 15:46:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16MEj0-000MTW-00 for multi6-data@psg.com; Thu, 03 Jan 2002 12:44:30 -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 16MEix-000MTQ-00 for multi6@ops.ietf.org; Thu, 03 Jan 2002 12:44:27 -0800 content-class: urn:content-classes:message Subject: (multi6) Requirements document last call / edit v1.01 Date: Thu, 3 Jan 2002 12:44:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <2B81403386729140A3A899A8B39B046405DE1E@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: (multi6) Requirements document last call / edit v1.01 Thread-Index: AcGUkpz+JEbfPYBuSrGJaJl+cD088gABG5nA From: "Michel Py" To: "Vijay Gill" , "Eliot Lear" 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 PAA10940 ---------------------------------------------------------------- Tentative summary of edits to the requirements documents v1.01 ---------------------------------------------------------------- 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 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. 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 don't think 3.1.2 should be changed. 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. Please send text. 3. Do nothing 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". 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. Please send text 4. 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. 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. 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: 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. 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 this, I read it as "you must be able to retrieve routing information from a router". 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 Opinions about it: Vijay Gill: I'm fine with this. Michel Py: I'm fine with this. Add yours here: From owner-multi6@ops.ietf.org Thu Jan 3 15:48: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 PAA11016 for ; Thu, 3 Jan 2002 15:48:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16MEkQ-000MWd-00 for multi6-data@psg.com; Thu, 03 Jan 2002 12:45:58 -0800 Received: from lint.cisco.com ([171.68.224.209]) by psg.com with esmtp (Exim 3.33 #1) id 16MEkQ-000MWW-00 for multi6@ops.ietf.org; Thu, 03 Jan 2002 12:45:58 -0800 Received: from ELEAR-W2K1.cisco.com (sjc-vpn2-209.cisco.com [10.21.112.209]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA00236; Thu, 3 Jan 2002 12:45:45 -0800 (PST) Message-Id: <5.1.0.14.2.20020103123427.027b1420@lint.cisco.com> X-Sender: elear@lint.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 03 Jan 2002 12:44:09 -0800 To: Vijay Gill From: Eliot Lear Subject: Re: Requirement document last call (let's focus!) Cc: In-Reply-To: References: <5.1.0.14.2.20020103114239.01d65658@lint.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-multi6@ops.ietf.org Precedence: bulk At 02:59 PM 1/3/2002 -0500, Vijay Gill wrote: > > > 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. > > > > Why are we adding the caveat of the last sentence? Manual anything is bad. > >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. In today's world, if both sides announce an aggregation and not a specific route for E, this will happen. But if the problem is congestion, that is solved with more bandwidth and or less customers (i.e., letting the market decide). Why does this need to be written into a requirements document? Or maybe I misunderstand the point you are making. What are you thinking of that needs to be manual? Is it the coordinated injection of a specific during congestion? Eliot From owner-multi6@ops.ietf.org Thu Jan 3 16:28: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 QAA11736 for ; Thu, 3 Jan 2002 16:28:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16MFOn-000NTb-00 for multi6-data@psg.com; Thu, 03 Jan 2002 13:27:41 -0800 Received: from relay1.nexsi.com ([66.35.205.133]) by psg.com with esmtp (Exim 3.33 #1) id 16MFOm-000NTV-00 for multi6@ops.ietf.org; Thu, 03 Jan 2002 13:27:40 -0800 Received: from mail.nexsi.com (unknown [66.35.212.41]) by relay1.nexsi.com (Postfix) with ESMTP id A53EE3F62; Thu, 3 Jan 2002 13:30:16 -0800 (PST) Received: from khonsu.sw.nexsi.com ([172.17.212.34]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id NAA05980; Thu, 3 Jan 2002 13:31:20 -0800 Date: Thu, 3 Jan 2002 13:31:20 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <15911746170.20020103133120@nexsi.com> To: smd@ebone.net ((Sean Doran)) Cc: brian@hursley.ibm.com, david.conrad@nominum.com, jnc@ginger.lcs.mit.edu, michel@arneill-py.sacramento.ca.us, Subject: Re: Missing DNS reqt? [was Re: (multi6) requirements draft comments] In-Reply-To: <20020103154127.6856984C@sean.ebone.net> References: <20020103154127.6856984C@sean.ebone.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Sean, Agreed. Let's concentrate on the WG items, i.e., requirements. Discussions on specific approaches do seem premature, though related and interesting. -- Alex Zinin Thursday, January 03, 2002, 7:41:27 AM, Sean Doran wrote: > | This sounds exactly like a description of mobility, and exactly like > | a description of multihoming. I don't think we should be scared of > | common solutions (which is not the same as saying MIPv6 is the > | solution for multihoming). > Remember that this WG is charterd to solve SITE multihoming, > rather than host multihoming. If the former, which implies > simultaneous connectivity and/or migration for a collection of > hosts from a few to a vast number, can be done using the mechanisms > of the latter (e.g. multi-addressed hosts, MIP6), that's fine and > dandy. However, first, the charter documents need to be pushed > along the standards track, as discussed in SLC. > Sean. From owner-multi6@ops.ietf.org Thu Jan 3 17:01:12 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12283 for ; Thu, 3 Jan 2002 17:01:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16MFun-000OFo-00 for multi6-data@psg.com; Thu, 03 Jan 2002 14:00:45 -0800 Received: from mx1out.umbc.edu ([130.85.253.51]) by psg.com with esmtp (Exim 3.33 #1) id 16MFun-000OFh-00 for multi6@ops.ietf.org; Thu, 03 Jan 2002 14:00:45 -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) with ESMTP id g03M0dgQ017676; Thu, 3 Jan 2002 17:00:39 -0500 (EST) Received: from localhost (vijay@localhost) by gl.umbc.edu (8.9.0/8.9.0) with ESMTP id RAA276940; Thu, 3 Jan 2002 17:00:39 -0500 (EST) X-Authentication-Warning: irix2.gl.umbc.edu: vijay owned process doing -bs Date: Thu, 3 Jan 2002 17:00:39 -0500 From: Vijay Gill X-X-Sender: To: Eliot Lear cc: Subject: Re: Requirement document last call (let's focus!) In-Reply-To: <5.1.0.14.2.20020103123427.027b1420@lint.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 3 Jan 2002, Eliot Lear wrote: > At 02:59 PM 1/3/2002 -0500, Vijay Gill wrote: > > > > 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. > > > Why are we adding the caveat of the last sentence? Manual > > > anything is bad. > In today's world, if both sides announce an aggregation and not a specific > route for E, this will happen. But if the problem is congestion, that is > solved with more bandwidth and or less customers (i.e., letting the market > decide). Why does this need to be written into a requirements document? This doesn't need to be in a requirements document, but the option for E to manually decide what links to dump traffic over should not be precluded. There are many games being played in networks that I'm operating right now that rely on some of these sort of tricks. > Or maybe I misunderstand the point you are making. What are you thinking > of that needs to be manual? Is it the coordinated injection of a specific > during congestion? See above. I hope I'm not misunderstanding something here. /vijay From owner-multi6@ops.ietf.org Fri Jan 4 04:55: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 EAA29958 for ; Fri, 4 Jan 2002 04:55:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16MR2O-000E95-00 for multi6-data@psg.com; Fri, 04 Jan 2002 01:53:20 -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 16MR2N-000E8z-00 for multi6@ops.ietf.org; Fri, 04 Jan 2002 01:53:19 -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 KAA09870; Fri, 4 Jan 2002 10:53:17 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA55960 from ; Fri, 4 Jan 2002 10:53:14 +0100 Message-Id: <3C357B8A.A0F0D664@hursley.ibm.com> Date: Fri, 04 Jan 2002 10:53:14 +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: Sean Doran , multi6@ops.ietf.org Subject: Re: Requirement document last call (let's focus!) References: 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 EAA29958 Correct. I had proposed adding 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. which people seemed to agree with. Brian Christian Huitema wrote: > > > | This sounds exactly like a description of mobility, and exactly like > > | a description of multihoming. I don't think we should be scared of > > | common solutions (which is not the same as saying MIPv6 is the > > | solution for multihoming). > > > > Remember that this WG is charterd to solve SITE multihoming, > > rather than host multihoming. If the former, which implies > > simultaneous connectivity and/or migration for a collection of > > hosts from a few to a vast number, can be done using the mechanisms > > of the latter (e.g. multi-addressed hosts, MIP6), that's fine and > > dandy. However, first, the charter documents need to be pushed > > along the standards track, as discussed in SLC. > > Seconded! > > Let's first achieve the goal of the current charter, which is to publish the requirement document. And let's not try to tailor the requirement to a specific solution: this is the known way to not make progress. > > Could someone summarize the actual modifications to the requirement document that surfaced during this last call? I seem to recall the following: > > 1) 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. 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. > > 2) 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. Don't know whether that should be part of the requirement document. > > 3) 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." > > 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. > > Do you agree that this is a fair summary of the discussion on the requirements draft? I yes, we should maybe have a short editing pass, and then proceed towards publication of the requirements and rechartering of this group. > > -- Christian Huitema > > From owner-multi6@ops.ietf.org Fri Jan 4 09:44: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 JAA03936 for ; Fri, 4 Jan 2002 09:44:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16MVYh-000Kr3-00 for multi6-data@psg.com; Fri, 04 Jan 2002 06:42:59 -0800 Received: from zeus.anet-chi.com ([207.7.4.6]) by psg.com with esmtp (Exim 3.33 #1) id 16MVYg-000Kqw-00 for multi6@ops.ietf.org; Fri, 04 Jan 2002 06:42:58 -0800 Received: from RepliGate (as1b-45.chi.il.dial.anet.com [198.92.157.45]) by zeus.anet-chi.com (8.12.1/8.12.0) with SMTP id g04EgB0F013644; Fri, 4 Jan 2002 08:42:12 -0600 (CST) Message-ID: <0c1301c19546$9d91ec40$0100a8c0@RepliGate> From: "Jim Fleming" To: "Brian E Carpenter" , "Christian Huitema" Cc: "Sean Doran" , References: <3C357B8A.A0F0D664@hursley.ibm.com> Subject: Re: Requirement document last call (let's focus!) Date: Fri, 4 Jan 2002 09:38:24 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Brian E 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. > DNS AAAA records are a good starting point http://www.dot-biz.com/INFO/Papers/IPv4Plus6/ Jim Fleming 2002:[IPv4]:000X:03DB http://www.IPv8.info From owner-multi6@ops.ietf.org Sat Jan 5 16:59: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 QAA07682 for ; Sat, 5 Jan 2002 16:59:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16MynP-000G2D-00 for multi6-data@psg.com; Sat, 05 Jan 2002 13:56:07 -0800 Received: from inet.org ([63.108.254.91] helo=gnat.inet.org) by psg.com with esmtp (Exim 3.33 #1) id 16MynO-000G1U-00 for multi6@ops.ietf.org; Sat, 05 Jan 2002 13:56:06 -0800 Received: from mosquito.inet.org (unknown [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 480FC67103; Sat, 5 Jan 2002 17:08:03 -0500 (EST) Message-Id: <5.1.0.14.2.20020105164358.00a87dc0@10.30.15.3> X-Sender: rja@10.30.15.3 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 05 Jan 2002 16:45:43 -0500 To: "Michel Py" From: RJ Atkinson Subject: Re: (multi6) Requirement document last call /edit (let's focus!) Cc: In-Reply-To: <2B81403386729140A3A899A8B39B046405DE1B@server2000.arneill- py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-multi6@ops.ietf.org Precedence: bulk At 14:36 03/01/02, Michel Py wrote: >There is something else we have to deal with in the current charter: >"Produce a document describing how multihoming is done today, including an explanation of both the advantages and limitations of the approaches". > >I do not intend to send a blow to the authors in any way, but does anybody >really care about it? I wonder how the chairs and the WG would feel about >taking that one out as part of the re-chartering. It never seemed to trigger >much interest. In SLC there was not even a handful of people that raised >their hand when asked if they have read it. It is important to document the currently deployed multihoming approach. This is useful for this WG as a baseline reference. It has broader value in documenting existing practice AND (perhaps more importantly) the limitations and scaling issues of the currently deployed approach. Lack of reading generally just means that folks are busy -- particularly so during this past Autumn given the various unfortunate events in the world. Ran From owner-multi6@ops.ietf.org Sat Jan 5 17: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 RAA07768 for ; Sat, 5 Jan 2002 17:06:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Mywe-000GFS-00 for multi6-data@psg.com; Sat, 05 Jan 2002 14:05:40 -0800 Received: from inet.org ([63.108.254.91] helo=gnat.inet.org) by psg.com with esmtp (Exim 3.33 #1) id 16Mywd-000GFM-00 for multi6@ops.ietf.org; Sat, 05 Jan 2002 14:05:40 -0800 Received: from mosquito.inet.org (unknown [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id D0A8167103; Sat, 5 Jan 2002 17:17:48 -0500 (EST) Message-Id: <5.1.0.14.2.20020105164625.00a91e40@10.30.15.3> X-Sender: rja@10.30.15.3 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 05 Jan 2002 16:55:29 -0500 To: "Michel Py" From: RJ Atkinson Subject: Re: (multi6) Requirement document last edit Cc: In-Reply-To: <2B81403386729140A3A899A8B39B046405DE1B@server2000.arneill- py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit At 14:36 03/01/02, Michel Py wrote: >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. Please send text. >3. Do nothing > >Opinions on 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". Option 2) Proposed additional text: "There might be more than one multihoming approach, provided the several approaches address different segments of the site multihoming problem." (edit to taste) >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. Please send text Option 3) "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." (edit to taste) 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. >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. > >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. Concur that there is no reason to add Christian's proposed text, because it closes options off prematurely. >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. Above proposal (1) seems reasonable. Ran rja@inet.org From owner-multi6@ops.ietf.org Sat Jan 5 18:20: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 SAA08160 for ; Sat, 5 Jan 2002 18:20:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16N06E-000Hu2-00 for multi6-data@psg.com; Sat, 05 Jan 2002 15:19: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 16N06B-000Htw-00 for multi6@ops.ietf.org; Sat, 05 Jan 2002 15:19:35 -0800 content-class: urn:content-classes:message Subject: RE: (multi6) Requirement document last edit 1.02 Date: Sat, 5 Jan 2002 15:19:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <2B81403386729140A3A899A8B39B046403D5F9@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: (multi6) Requirement document last edit 1.02 Thread-Index: AcGWNT+8bsQvMr2HTIipQkolK+5pZAACnLKw 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 SAA08160 ---------------------------------------------------------------- Tentative summary of edits to the requirements documents v1.02 ---------------------------------------------------------------- Revision history: ----------------- 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 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. 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 don't think 3.1.2 should be changed. 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 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". 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. 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. 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. 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. 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". 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 Opinions about it: Vijay Gill: I'm fine with this. Michel Py: I'm fine with the existing text. Add yours here: From owner-multi6@ops.ietf.org Mon Jan 7 05:32: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 FAA12670 for ; Mon, 7 Jan 2002 05:32:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16NX0U-000CQJ-00 for multi6-data@psg.com; Mon, 07 Jan 2002 02:27: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 16NX0T-000CQB-00 for multi6@ops.ietf.org; Mon, 07 Jan 2002 02:27:54 -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 LAA14210; Mon, 7 Jan 2002 11:27:42 +0100 Received: from dhcp30_20.lagaude.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA30032 from ; Mon, 7 Jan 2002 11:27:37 +0100 Message-Id: <3C397819.1BF2A52A@hursley.ibm.com> Date: Mon, 07 Jan 2002 11:27:37 +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: RJ Atkinson Cc: Michel Py , multi6@ops.ietf.org Subject: Re: (multi6) Requirement document last call /edit (let'sfocus!) References: <5.1.0.14.2.20020105164358.00a87dc0@10.30.15.3> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit RJ Atkinson wrote: > > At 14:36 03/01/02, Michel Py wrote: > >There is something else we have to deal with in the current charter: > >"Produce a document describing how multihoming is done today, including an explanation of both the advantages and limitations of the approaches". > > > >I do not intend to send a blow to the authors in any way, but does anybody > >really care about it? I wonder how the chairs and the WG would feel about > >taking that one out as part of the re-chartering. It never seemed to trigger > >much interest. In SLC there was not even a handful of people that raised > >their hand when asked if they have read it. > > It is important to document the currently deployed multihoming approach. > This is useful for this WG as a baseline reference. It has broader value > in documenting existing practice AND (perhaps more importantly) the > limitations and scaling issues of the currently deployed approach. > > Lack of reading generally just means that folks are busy -- particularly > so during this past Autumn given the various unfortunate events in the world. I agree that this document needs to get finished. I don't remember whether I raised my hand or not, since I didn't read the draft in every detail, but at a superficial level it seems fine. Brian From owner-multi6@ops.ietf.org Mon Jan 7 17:43: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 RAA29872 for ; Mon, 7 Jan 2002 17:43:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16NiRK-000LZO-00 for multi6-data@psg.com; Mon, 07 Jan 2002 14:40:22 -0800 Received: from evrtwa1-ar8-4-60-070-162.vz.dsl.gtei.net ([4.60.70.162] helo=tndh.net) by psg.com with esmtp (Exim 3.33 #1) id 16NiRJ-000LZI-00 for multi6@ops.ietf.org; Mon, 07 Jan 2002 14:40:22 -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 ; Mon, 07 Jan 2002 14:40:33 -0800 From: "Tony Hain" To: "Christian Huitema" , "Sean Doran" Cc: Subject: RE: Requirement document last call (let's focus!) Date: Mon, 7 Jan 2002 14:40:19 -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) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Christian Huitema wrote: > 1) 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. 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. I was arguing that outbound traffic balancing is a local site policy matter, and nothing we do will change that. The site will send the bits out whichever interface it chooses, and the only thing this group could do to influence that would be to define a negotiation protocol (PNI like) to automate changes in site policy. The other point is that for inbound load balancing, the receiving site only has control as long as it does not conflict with origin site policy, or the topology is deep enough that an intermediary abstracts out the differences. The receiver can advertise detailed routes over each specific link, but if the origin ignores those and defaults to its prefered low-cost provider, the traffic is not likely to balance the way the receiver wants. Yes we can require an approach that allows a receiver to balance in the abstract, but there is no way to achieve fine-grained absolute control without signalling/negotiation between the endpoint sites, likely to be followed by some form of path establishment protocol. Tony From owner-multi6@ops.ietf.org Mon Jan 7 18:53: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 SAA01362 for ; Mon, 7 Jan 2002 18:52:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16NjYO-000MXl-00 for multi6-data@psg.com; Mon, 07 Jan 2002 15:51:44 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.33 #1) id 16NjYM-000MXf-00 for multi6@ops.ietf.org; Mon, 07 Jan 2002 15:51:43 -0800 From: Masataka Ohta Message-Id: <200201072335.IAA11181@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id IAA11181; Tue, 8 Jan 2002 08:35:07 +0900 Subject: Re: Requirement document last call (let's focus!) In-Reply-To: from Tony Hain at "Jan 7, 2002 02:40:19 pm" To: Tony Hain Date: Tue, 8 Jan 2002 08:35:06 +0859 () CC: Christian Huitema , Sean Doran , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-multi6@ops.ietf.org Precedence: bulk Tony; > Christian Huitema wrote: > > 1) 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. 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. > > I was arguing that outbound traffic balancing is a local site policy > matter, and nothing we do will change that. The site will send the bits > out whichever interface it chooses, and the only thing this group could > do to influence that would be to define a negotiation protocol (PNI > like) to automate changes in site policy. I agree with you. A site CAN NOT be prohibitted to control outbound traffic. Any proposal automatically allows sites distribute ... outbound traffic between multiple transit providers. So, the requirement is meaningless and should be removed. > The other point is that for inbound load balancing, the receiving site > only has control as long as it does not conflict with origin site > policy, or the topology is deep enough that an intermediary abstracts > out the differences. Again, I agree with you. > The receiver can advertise detailed routes over > each specific link, but if the origin ignores those and defaults to its > prefered low-cost provider, the traffic is not likely to balance the way > the receiver wants. Yes we can require an approach that allows a > receiver to balance in the abstract, but there is no way to achieve > fine-grained absolute control without signalling/negotiation between the > endpoint sites, likely to be followed by some form of path establishment > protocol. But, it will make routing/signalling information not to scale, which destroys the purpose of multi6. So, the requirement should be A proposal MAY allow site weakly control inbound traffic but it MUST NOT increase the amount of global routing/signalling information traffic. My feeling is that, in a sense, BGP already is an overkill. Masataka Ohta From owner-multi6@ops.ietf.org Tue Jan 8 02:24:01 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16993 for ; Tue, 8 Jan 2002 02:24:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Nqah-00021a-00 for multi6-data@psg.com; Mon, 07 Jan 2002 23:22: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 16Nqag-00021U-00 for multi6@ops.ietf.org; Mon, 07 Jan 2002 23:22:34 -0800 content-class: urn:content-classes:message Subject: RE: Requirement document last call (let's focus!) Date: Mon, 7 Jan 2002 23:22:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <2B81403386729140A3A899A8B39B046405DE34@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: Requirement document last call (let's focus!) Thread-Index: AcGX15+NPx9bwcNlRHy22Lmqet5FogAOppyA From: "Michel Py" To: "Masataka Ohta" , "Tony Hain" 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 CAA16993 Gentlemen, I would appreciate if you could be a little more specific in what you would like to go into the edit doc that in a moment of brain malfunction I volunteered to maintain. Please take example in what Ran posted yesterday. I will add the following as proposed text from Otha-san: > So, the requirement should be > A proposal MAY allow site weakly control inbound traffic but it > MUST NOT increase the amount of global routing/signalling > information traffic. >>> Christian Huitema wrote: >>> 1) 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. 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. >> Tony Hain wrote: >> I was arguing that outbound traffic balancing is a local site policy >> matter, and nothing we do will change that. The site will send the bits >> out whichever interface it chooses, and the only thing this group could >> do to influence that would be to define a negotiation protocol (PNI >> like) to automate changes in site policy. > Masataka Ohta wrote: > I agree with you. > A site CAN NOT be prohibitted to control outbound traffic. > Any proposal automatically allows sites distribute ... outbound traffic > between multiple transit providers. > So, the requirement is meaningless and should be removed. I'm afraid I have to disagree with both Tony and Masakata here. Although the goal is not easy to achieve, a good proposal will try to send The traffic over the "best" path. I am not saying that we should prohibit policy routing for egress traffic, but it would be more elegant to let the multihoming solution decide instead of having the site try to control it. >> Tony Hain wrote: >> The other point is that for inbound load balancing, the receiving site >> only has control as long as it does not conflict with origin site >> policy, or the topology is deep enough that an intermediary abstracts >> out the differences. > Masataka Ohta wrote: > Again, I agree with you. I disagree with both of you here as well. The receiving site does not have much control over the traffic it receives, but let's not forget that a solution includes BOTH the sender and the receiver, which means that indeed inbound load balancing can be controlled, not by the receiver but by the sender..... > Masataka Ohta wrote: > The receiver can advertise detailed routes over > each specific link, but if the origin ignores those and defaults to its > prefered low-cost provider, the traffic is not likely to balance the way > the receiver wants. There are ways around that. > Yes we can require an approach that allows a > receiver to balance in the abstract, but there is no way to achieve > fine-grained absolute control without signalling/negotiation between the > endpoint sites, likely to be followed by some form of path establishment > protocol. Yes, and then what? > But, it will make routing/signalling information not to scale, > which destroys the purpose of multi6. I think that Tony's addressing scheme, although not very optimal, can be made very scalable. Michel. From owner-multi6@ops.ietf.org Tue Jan 8 02:28:13 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17032 for ; Tue, 8 Jan 2002 02:28:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Nqfj-00025k-00 for multi6-data@psg.com; Mon, 07 Jan 2002 23:27:47 -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 16Nqfg-00025c-00 for multi6@ops.ietf.org; Mon, 07 Jan 2002 23:27:44 -0800 content-class: urn:content-classes:message Subject: RE: (multi6) Requirement document last edit 1.03 Date: Mon, 7 Jan 2002 23:27:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <2B81403386729140A3A899A8B39B046403D60E@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: (multi6) Requirement document last edit 1.03 Thread-Index: AcGX15+NPx9bwcNlRHy22Lmqet5FogAPoEBg From: "Michel Py" To: "Masataka Ohta" 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 CAA17032 ---------------------------------------------------------------- Tentative summary of edits to the requirements documents v1.03 ---------------------------------------------------------------- Revision history: ----------------- 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 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. 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 don't think 3.1.2 should be changed. 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 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". 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. 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. 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. 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. 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". 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 Opinions about it: Vijay Gill: I'm fine with this. Michel Py: I'm fine with the existing text. Add yours here: From owner-multi6@ops.ietf.org Tue Jan 8 13:17:16 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03348 for ; Tue, 8 Jan 2002 13:17:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16O0m3-000Arm-00 for multi6-data@psg.com; Tue, 08 Jan 2002 10:14:59 -0800 Received: from evrtwa1-ar8-4-60-070-162.vz.dsl.gtei.net ([4.60.70.162] helo=tndh.net) by psg.com with esmtp (Exim 3.33 #1) id 16O0m2-000Arg-00 for multi6@ops.ietf.org; Tue, 08 Jan 2002 10:14:58 -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 ; Tue, 08 Jan 2002 10:15:09 -0800 From: "Tony Hain" To: "Michel Py" , "Masataka Ohta" Cc: Subject: RE: Requirement document last call (let's focus!) Date: Tue, 8 Jan 2002 10:14:53 -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) Importance: Normal In-Reply-To: <2B81403386729140A3A899A8B39B046405DE34@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Michel Py wrote: > I'm afraid I have to disagree with both Tony and Masakata here. > Although the goal is not easy to achieve, a good proposal will try to > send > The traffic over the "best" path. This approach is doomed to fail. "Best" is a function of where you are looking from, what your goals are, and how many distinct policies get applied along each path. > I am not saying that we should > prohibit > policy routing for egress traffic, but it would be more elegant to let > the > multihoming solution decide instead of having the site try to control > it. I am sorry, but there is no way I am going to allow a destination site to dictate that I send my traffic over my highest cost path. It is unfortunate that BGP has fostered the complete fantasy that a site can control the traffic towards itself. The holder of the packet is always in control of where it gets sent, and that is true for each hop along the path. > inbound load balancing can be controlled, not by the receiver > but by the > sender..... This makes no sense. Tony From owner-multi6@ops.ietf.org Tue Jan 8 14:22:18 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06289 for ; Tue, 8 Jan 2002 14:22:17 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16O1oA-000BzD-00 for multi6-data@psg.com; Tue, 08 Jan 2002 11:21:14 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.33 #1) id 16O1o9-000Bz7-00 for multi6@ops.ietf.org; Tue, 08 Jan 2002 11:21:13 -0800 From: Masataka Ohta Message-Id: <200201081907.EAA16351@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id EAA16351; Wed, 9 Jan 2002 04:07:06 +0900 Subject: Re: Requirement document last call (let's focus!) In-Reply-To: <2B81403386729140A3A899A8B39B046405DE34@server2000.arneill-py.sacramento.ca.us> from Michel Py at "Jan 7, 2002 11:22:33 pm" To: Michel Py Date: Wed, 9 Jan 2002 04:07:05 +0859 () CC: Tony Hain , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-multi6@ops.ietf.org Precedence: bulk Michel; > Gentlemen, I'm not. I'm not a lady, either. :-) > I'm afraid I have to disagree with both Tony and Masakata here. > Although the goal is not easy to achieve, a good proposal will try to > send > The traffic over the "best" path. I am not saying that we should > prohibit > policy routing for egress traffic, but it would be more elegant to let > the > multihoming solution decide instead of having the site try to control > it. Assume that a site is connected to ISP A and B. If the site negotiate with ISP A and B individually, egress routing is fully controlled by the site. Otherwise, ISP A and B must cooperate for the welfare of the site even if they are hostile competiters. > >> Tony Hain wrote: > >> The other point is that for inbound load balancing, the receiving > site > >> only has control as long as it does not conflict with origin site > >> policy, or the topology is deep enough that an intermediary abstracts > >> out the differences. > > Masataka Ohta wrote: > > Again, I agree with you. > > I disagree with both of you here as well. The receiving site does not > have > much control over the traffic it receives, but let's not forget that a > solution includes BOTH the sender and the receiver, which means that > indeed > inbound load balancing can be controlled, not by the receiver but by the > sender..... Are you saying "EITHER"? > > Masataka Ohta wrote: > > The receiver can advertise detailed routes over > > each specific link, but if the origin ignores those and defaults to > its > > prefered low-cost provider, the traffic is not likely to balance the > way > > the receiver wants. > > There are ways around that. It's not my statement, but, anyway... Constructive proof on exsitense of scalable ways is required here. > > But, it will make routing/signalling information not to scale, > > which destroys the purpose of multi6. > > I think that Tony's addressing scheme, although not very optimal, can be > made very scalable. "very" is not a proper wording to discuss scalability. "very scalable" = "poorly scalable" Masataka Ohta From owner-multi6@ops.ietf.org Wed Jan 9 00:56:28 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21196 for ; Wed, 9 Jan 2002 00:56:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16OBgX-000Ljo-00 for multi6-data@psg.com; Tue, 08 Jan 2002 21:54:01 -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 16OBgW-000Ljd-00 for multi6@ops.ietf.org; Tue, 08 Jan 2002 21:54:00 -0800 content-class: urn:content-classes:message Subject: (multi6) control / load balancing of ingress traffic. Date: Tue, 8 Jan 2002 21:53:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <2B81403386729140A3A899A8B39B046405DE35@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: (multi6) control / load balancing of ingress traffic. Thread-Index: AcGYeyYNBqWSuUAATKu1vCu6R8r2GAAN8YLQ From: "Michel Py" To: "Masataka Ohta" Cc: "Tony Hain" , Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA21196 Masataka and Tony, > Masataka Ohta wrote: > Assume that a site is connected to ISP A and B. > If the site negotiate with ISP A and B individually, egress routing > is fully controlled by the site. Not necessarily, see below. Or maybe, this might be true as of today but the multihoming solution we want for IPv6 is not what we have today for v4. > Otherwise, ISP A and B must cooperate for the welfare of the site > even if they are hostile competiters. Not necessarily either, see below. >>>> Tony Hain wrote: >>>> The other point is that for inbound load balancing, the receiving site >>>> only has control as long as it does not conflict with origin site >>>> policy, or the topology is deep enough that an intermediary abstracts >>>> out the differences. >>> Masataka Ohta wrote: >>> Again, I agree with you. >> Michel Py wrote: >> I disagree with both of you here as well. The receiving site does not >> have much control over the traffic it receives, but let's not forget >> that a solution includes BOTH the sender and the receiver, which means >> that indeed inbound load balancing can be controlled, not by the receiver >> but by the sender. > Tony Hain wrote: > This makes no sense. See below if it does. > Masataka Ohta wrote: > Are you saying "EITHER"? Yes, see just below. Let me try to explain this. - Site S is multihomed to providers A,B and C. - Site S has received aggregatable PA addresses from all three providers. - The multihoming solution is a multi-address one, which means that each host on site S has several addresses, one for each provider and possibly a PI address as well. - In the cloud, during the transport of the packet, one of the PA addresses is going to be used. This effectively assures load balancing among the different providers by the choice of the destination address by the source. - So, the provider used at the destination is controlled by the source when the multihoming protocol chooses among the different possible destinations. - If that multihoming protocol bases its decisions on info provided by the destination, you can truly says that the destination controls its own ingress traffic. DESTINATION ADDRESS SELECTION is the key here, not routing. So, the ingress traffic to a given site can be controlled by the source, or by the destination site itself if if the multihoming protocol feeds the source with the correct info, or by both. Note that my model calls for selection of the path by the destination, in most cases, which is, indeed, load balancing for ingress traffic. Tony, this is not a routing decision but a destination address selection decision. > Tony Hain wrote: > I am sorry, but there is no way I am going to allow a destination site to > dictate that I send my traffic over my highest cost path. I am sorry to say it, but there is nothing you can do about that. If the host or router on your site picks a PA address that goes over your highest cost path, though. > It is unfortunate that BGP has fostered the complete fantasy that a site > can control the traffic towards itself. The holder of the packet is always > in control of where it gets sent, and that is true for each hop along the > path. As of today, it is a fantasy because hosts have only one address. In a multi-address multihoming scenario, this becomes true. Christian, correct me if I'm wrong, but your draft is all about host selection among multiple possible choices. Like it or not, part of the multihoming solution is a multiple PA address without a PI that this company in Redmond, WA and some other people are working on. Bottom line is: multiple-address solutions do not give a hoot to routing. I don't like the idea because of the added complexity, but multi-address solutions are, IMHO, unavoidable especially dealing with the kind of scalability that multihomes cable and DSL personal setups. The point I am trying to make here is that we collectively need to unlearn the fact that a host has only one address that does not change. > Masataka Ohta wrote: > "very" is not a proper wording to discuss scalability. > "very scalable" = "poorly scalable" My english is not very scalable, I'm afraid :-) >> Gentlemen, > I'm not. I'm not a lady, either. :-) Hehe. Looks like me. I am fully reassured, now. Michel. From owner-multi6@ops.ietf.org Wed Jan 9 13:14: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 NAA08720 for ; Wed, 9 Jan 2002 13:14:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16ONCX-0006lw-00 for multi6-data@psg.com; Wed, 09 Jan 2002 10:11:49 -0800 Received: from evrtwa1-ar8-4-60-070-162.vz.dsl.gtei.net ([4.60.70.162] helo=tndh.net) by psg.com with esmtp (Exim 3.33 #1) id 16ONCW-0006lp-00 for multi6@ops.ietf.org; Wed, 09 Jan 2002 10:11:48 -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 ; Wed, 09 Jan 2002 10:12:02 -0800 From: "Tony Hain" To: "Michel Py" , "Masataka Ohta" Cc: Subject: RE: (multi6) control / load balancing of ingress traffic. Date: Wed, 9 Jan 2002 10:11:46 -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) Importance: Normal In-Reply-To: <2B81403386729140A3A899A8B39B046405DE35@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Michel Py wrote: > Not necessarily, see below. Or maybe, this might be true as of today > but the multihoming solution we want for IPv6 is not what we have > today for v4. I get the impression from comments on the list that there are different opinions on what the goal is. Some people want exactly what they have today, some people want a network / centrally managed approach, some people want a host / distributed approach, and others want a mix of the above. The current requirements draft tries to give each group what they want, even though the totally network centric and the totally host centric approaches are mutually exclusive. Until we have agreement on what we want for an IPv6 solution, no progress will be made. > - If that multihoming protocol bases its decisions on info provided by > the > destination, you can truly says that the destination controls its own > ingress traffic. DESTINATION ADDRESS SELECTION is the key here, not > routing. Are you proposing to tie the DNS response to a system which keeps track of probable paths from the current requestor and current load distribution policy so the source can only pick the destination address you want??? In any case routing is part of the key, and destination address only plays a role for those parts of the infrastructure that route on that rather than a default. If a source site defaults to a particular ISP which the destination is also connected to, there is nothing in the destination address selection that will change the way traffic flows. > Like it or not, part of the multihoming solution is a multiple PA > address > without a PI that this company in Redmond, WA and some other > people are > working on. I happen to be one of the people that believes that host address selection is part of the answer to the long term problem. That does not mean that a destination site can micro-manage its incoming load balancing though, unless there is a connection to the DNS response which limits the sources choices to current load balancing policy and the concept of a default route is completely removed from the system. > Bottom line is: multiple-address solutions do not give a hoot to > routing. Yes they do, they are just a mechanism to try and 'best-guess' what the routing system will be doing. While it is possible for policy to say select from any available address, most implementations will default to longest matching between available source and available destination addresses, because that approach is most likely to take the shortest path through the infrastructure. In any case once the packet leaves the host it is the routing system that determines the packet path, not address selection. Maybe the problem is the assumption that a single approach can be found for very different functional requirements. If a site multi-homes for resiliency, host based address selection approaches are appropriate, while if a site multi-homes with the intent of micro-managed load balancing, those are inappropriate and route injection mechanisms make more sense (but I still maintain that a destination has limited control over the absolute path). Tony From owner-multi6@ops.ietf.org Wed Jan 9 16:50:29 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17075 for ; Wed, 9 Jan 2002 16:50:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16OQa4-000AOa-00 for multi6-data@psg.com; Wed, 09 Jan 2002 13:48:20 -0800 Received: from sean.ebone.net ([195.158.227.211]) by psg.com with esmtp (Exim 3.33 #1) id 16OQa3-000AOU-00 for multi6@ops.ietf.org; Wed, 09 Jan 2002 13:48:19 -0800 Received: by sean.ebone.net (Postfix, from userid 1113) id 4E78984D; Wed, 9 Jan 2002 22:48:18 +0100 (CET) To: alh-ietf@tndh.net, michel@arneill-py.sacramento.ca.us, mohta@necom830.hpcl.titech.ac.jp Subject: RE: (multi6) control / load balancing of ingress traffic. Cc: multi6@ops.ietf.org Message-Id: <20020109214818.4E78984D@sean.ebone.net> Date: Wed, 9 Jan 2002 22:48:18 +0100 (CET) From: smd@ebone.net (Sean Doran) Sender: owner-multi6@ops.ietf.org Precedence: bulk Tony Hain writes: | The current requirements draft tries to give each group what they | want, even though the totally network centric and the totally host | centric approaches are mutually exclusive. Until we have agreement on | what we want for an IPv6 solution, no progress will be made. You are quite right: without clear and solid requirements, we can make an architectural approach which does not meet people's real needs. Hence the work on the requirements document as a key part of the current charter. Please feel free to suggest improvements to the editor & the list, and as is the case in dealing with busy operator types, if you feel there's been a packet lost, retry. :-) Unfortunately, while the editors are clever people, they are not psychic or all-knowing, so the document likely will improve with people's shared insights. I am not certain there is a clear consensus that the document is finished, however, as discussed in SLC, we will do a WG last call as a motivation tool if people don't chime in with their ideas on the list and/or to the editors. (I've just moved countries this week & there is little that is more distracting than buying and selling properties in different parts of the world. Add that to my and Thomas's busy schedules (he is an AD too...), and I guess you might forgive us for not having done the WG last call already.) | Maybe the problem is the assumption that a single approach can be found | for very different functional requirements. This need not happen. If one considers the address format bits of the IPv6 address as a way to "hack in" an OSI AFI-like semantic, you could end up with different addresses being routed by separate (even S.I.N.) routing systems. So if there turns out to be a real need for multiple parallel IPv6 routing systems, there is at least one way of accomplishing this, that makes the question of which address to use possibly interesting. Note that we do this already for IPv4: unicast and multicast routing systems are in some places completely independent, and in some places fairly tightly related, and a packet is exposed to one system or the other based on the setting of the first few bits of the address. An application doing the equivalent of "ping ntp.mcast.net" or "ping all-routers.mcast.net" with a long-ish ttl might or might not expect the possibility of multiple responses, for example. Consider that there is no protocol reason that a DNS query on any given domain name could give back *both* a unicast and a multicast IPv4 address. The application may have the smarts to choose one versus the other, or it may get "assistance" (e.g. an error) from the operating system. Likewise, if the DNS returns an address which will be routed with the current CIDR system (with attendant protocols like BGP4), and an address which will be routed with a completely different one (which may have a different addressing structure and set of semantics). An application may choose to use one or the other based on its own needs, or may lean on the operating system for assistance, or may choose one at random. The packet in flight would be handled by a "FIB" of the appropriate type by forwarding components along the way. These FIBs in turn are essentially tables constructed after processing information learned from routing protocols. Different protocols accumulate different RIBs, which in turn may produce very different FIBs. Abstractly speaking. (RIBs and FIBs are discussed in detail in e.g. RFC 1771). So, a question is: should it be a requirement that we have ONE single routing system for everyone using IPv6? Are there site-multihoming requirements that fall out of the possibility of having several interdomain routing protocols? (Wearing my IRTF Routing RG hat, I'd like to hear "no" to the first question :-) ) Sean. From owner-multi6@ops.ietf.org Wed Jan 9 17:22:47 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17882 for ; Wed, 9 Jan 2002 17:22:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16OR6G-000AzZ-00 for multi6-data@psg.com; Wed, 09 Jan 2002 14:21:36 -0800 Received: from zeus.anet-chi.com ([207.7.4.6]) by psg.com with esmtp (Exim 3.33 #1) id 16OR6F-000AzQ-00 for multi6@ops.ietf.org; Wed, 09 Jan 2002 14:21:35 -0800 Received: from RepliGate (as1-112.chi.il.dial.anet.com [198.92.156.112]) by zeus.anet-chi.com (8.12.1/8.12.0) with SMTP id g09MLEPf000585; Wed, 9 Jan 2002 16:21:15 -0600 (CST) Message-ID: <274201c19974$9f9a7340$0100a8c0@RepliGate> From: "Jim Fleming" To: , , , "Sean Doran" Cc: References: <20020109214818.4E78984D@sean.ebone.net> Subject: "ONE single routing system for everyone using IPv6?" Date: Wed, 9 Jan 2002 17:17:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Sean Doran" > > So, a question is: should it be a requirement that we have ONE > single routing system for everyone using IPv6? Are there > site-multihoming requirements that fall out of the possibility of > having several interdomain routing protocols? > > (Wearing my IRTF Routing RG hat, I'd like to hear "no" to the > first question :-) ) > "ONE single routing system for everyone using IPv6?" Just like with the ICANN one true root, I would imagine the answer will be YES....and the IETF will produce papers to tell everyone why it is their way or the highway.... Most people are taking the highway....BTW.... Jim Fleming 2002:[IPv4]:000X:03DB http://www.IPv8.info From owner-multi6@ops.ietf.org Thu Jan 10 00:28:01 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01124 for ; Thu, 10 Jan 2002 00:28:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16OXjG-000IEN-00 for multi6-data@psg.com; Wed, 09 Jan 2002 21:26:18 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.33 #1) id 16OXjF-000IEH-00 for multi6@ops.ietf.org; Wed, 09 Jan 2002 21:26:17 -0800 content-class: urn:content-classes:message Subject: RE: (multi6) control / load balancing of ingress traffic. Date: Wed, 9 Jan 2002 21:26:12 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <2B81403386729140A3A899A8B39B046405DE38@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: (multi6) control / load balancing of ingress traffic. Thread-Index: AcGZV38qsfEzl2wvRT+L7Y7Wf/r5QAAO8Vng 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 AAA01124 Sean, > Sean Doran wrote: > and I guess you might forgive us for not having done the > WG last call already.) I took the liberty to begin to compile the edits. If any of The authors want it back, I'm happy to give it back :-) > I am not certain there is a clear consensus that the document > is finished, however, as discussed in SLC, we will do a WG last > call as a motivation tool if people don't chime in with their > ideas on the list and/or to the editors. Defining requirements for something that does not exist yet is tricky, and there is some guesswork involved. There is a fine line to walk here. Any document can always be perfected, and months more working on it needs to be balanced with the fact that the lack of this document is blocking work from being done on actual solutions. The reason that we have decided to go to a WG last call in SLC is because the majority thinks that, at this point in time, the possible improvements that could hypothetically be made to the requirements document do not outweigh the need of moving ahead. Another thing is that we already are 4 months behind... > So, a question is: should it be a requirement that we have > ONE single routing system for everyone using IPv6? Certainly not, has anyone actually suggested that? > Are there site-multihoming requirements that fall out of > the possibility of having several interdomain routing protocols? I think that his question is premature. The amount of time required to develop a new interdomain routing is not compatible with the responsibility we have to deliver something. My personal opinion on this is that BGP will not live forever, and will either get a major upgrade or be replaced, but we are looking at a 10+ year time frame. Michel From owner-multi6@ops.ietf.org Thu Jan 10 01:43: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 BAA02499 for ; Thu, 10 Jan 2002 01:43:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16OYuq-000JbO-00 for multi6-data@psg.com; Wed, 09 Jan 2002 22:42:20 -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 16OYun-000JbH-00 for multi6@ops.ietf.org; Wed, 09 Jan 2002 22:42:17 -0800 content-class: urn:content-classes:message Subject: (multi6) more control / load balancing of ingress traffic. Date: Wed, 9 Jan 2002 22:42:15 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <2B81403386729140A3A899A8B39B046405DE39@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: (multi6) more control / load balancing of ingress traffic. Thread-Index: AcGZOTWu9l6z49isTyS3Y1F5T8qnsgAXnKog From: "Michel Py" To: "Tony Hain" 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 BAA02499 Tony, > Tony Hain wrote: > Maybe the problem is the assumption that a single approach > can be found for very different functional requirements. I don't think it is the case anymore. It seems to me that there is now a consensus that no single solution is going to address the problem (finally..) >> Michel Py wrote: >> Not necessarily, see below. Or maybe, this might be true as of today >> but the multihoming solution we want for IPv6 is not what we have >> today for v4. > Tony Hain wrote: > Some people want exactly what they have today These people are dreamers. The routing goop otherwise called BFM for Big F.. Mess is exactly what we don't want. If we did, there will no purpose for this WG. I encourage people that want what we have today to read the following text from the WG charter: " Specifically, the WG will prefer multi-homing solutions that tend to minimise adverse impacts on the end-to-end routing system and limit the number of prefixes that need to be advertised in the Default-Free Zone (DFZ)." So let's nail that issue one time for good and say that people that want to keep what we have today have no place here. The main reason I have been pushing the requirements forward is that we avoid the market deciding to implement the v4 solution in v6 (hence the collective responsibility we have to provide a solution before it is too late). > Tony Hain wrote: > I get the impression from comments on the list that there are different > opinions on what the goal is. Some people want exactly what they have > today, some people want a network / centrally managed approach, some > people want a host / distributed approach, and others want a mix of the > above. The current requirements draft tries to give each group what they > want, even though the totally network centric and the totally host > centric approaches are mutually exclusive. Actually, this is a sound process, IMHO. The requirement draft should be flexible enough (some would say vague...) to allow different solutions to be developed. The choice between solutions is the next phase. > Until we have agreement on > what we want for an IPv6 solution, no progress will be made. I am not sure about that. There needs to be a requirements document, but the other side of that coin is that no progress will actually be made until we begin to work on SOLUTIONS. >> Michel Py wrote: >> - If that multihoming protocol bases its decisions on info provided by >> the destination, you can truly says that the destination controls its >> own ingress traffic. DESTINATION ADDRESS SELECTION is the key here, >> not routing. > Tony Hain wrote: > Are you proposing to tie the DNS response to a system which keeps > track of probable paths from the current requestor and current > load distribution policy so the source can only pick the > destination address you want??? Absolutely not (I am sure some people are, though). DNS has absolutely nothing to do with my proposal. > In any case routing is part of the key, I agree with that. My proposal is based on BGP. > and destination address only plays a role for those parts of the > infrastructure that route on that rather than a default. If a source > site defaults to a particular ISP which the destination is also > connected to, there is nothing in the destination address selection > that will change the way traffic flows. This is a very small part of traffic, and the only one that we don't have to bother with. Same ISP to same ISP traffic is a non issue. > I happen to be one of the people that believes that host address > selection is part of the answer to the long term problem. I know that, and so do I. > That does not mean that a destination site can micro-manage its > incoming load balancing though, unless there is a connection to > the DNS response which limits the sources choices to current load > balancing policy and the concept of a default route is completely > removed from the system. No. I think you have missed part of my previous posting. Let's try again: A site has three different PA addresses from three different transit providers. The selection of the destination address among these three DOES INDEED change the way the traffic flows, because each different PA address will flow to a different provider and finally reach the destination site by a different circuit and interface. The source, obviously, makes the choice of the destination address. If the destination hints the source on the choice of one of its own PA addresses, it can indeed micro-manage its own ingress. I believe you could call that route injection, to some extent. RTFD (1) http://search.ietf.org/internet-drafts/draft-py-multi6-mhtp-01.txt > While it is possible for policy to say select from any available > address, most implementations will default to longest matching > between available source and available destination addresses That is why my draft calls for a fixed size of /48 for all multihomed prefixes. AAMOF, I suggested privately to you to incorporate that in your own draft. > Because that approach is most likely to take the shortest path > through the infrastructure. In any case once the packet leaves > the host it is the routing system that determines the packet path, > not address selection. Correct, address selection has influenced the path BEFORE it leaves the host by specifying which of the multiple providers to use at the destination. > If a site multi-homes for resiliency, host based address selection > approaches are appropriate, while if a site multi-homes with the > intent of micro-managed load balancing, those are inappropriate and > route injection mechanisms make more sense Definitely. MHTP can be indeed be considered a route injection mechanism as well as a NAT one. I don't see why address selection and route injection are incompatible, though. I think they are complementary. > but I still maintain that a destination has > limited control over the absolute path). For sure, it can't control the traffic going out a default route, and it can't control the path among transit providers unrelated to either the source or the destination, but it can have control of which one, among all its own providers, is going to receive the traffic; again this is micro-managing the inbound traffic, which where it needs to be managed since there is nothing to do about the vast majority of hosts that will stay single homed with a default route outside. Michel. (1) Read This Fine Draft From owner-multi6@ops.ietf.org Thu Jan 10 08:41: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 IAA14483 for ; Thu, 10 Jan 2002 08:41:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16OfPE-0000Lw-00 for multi6-data@psg.com; Thu, 10 Jan 2002 05:38:08 -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 16OfPD-0000Lo-00 for multi6@ops.ietf.org; Thu, 10 Jan 2002 05:38:07 -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 OAA09604; Thu, 10 Jan 2002 14:38:00 +0100 Received: from dhcp222-86.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA40826 from ; Thu, 10 Jan 2002 14:37:56 +0100 Message-Id: <3C3D9933.E3786AA8@hursley.ibm.com> Date: Thu, 10 Jan 2002 14:37:55 +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: Masataka Ohta Cc: Michel Py , Tony Hain , multi6@ops.ietf.org Subject: Re: Requirement document last call (let's focus!) References: <200201081907.EAA16351@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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. Brian Masataka Ohta wrote: > > Michel; > > > Gentlemen, > > I'm not. I'm not a lady, either. :-) > > > I'm afraid I have to disagree with both Tony and Masakata here. > > Although the goal is not easy to achieve, a good proposal will try to > > send > > The traffic over the "best" path. I am not saying that we should > > prohibit > > policy routing for egress traffic, but it would be more elegant to let > > the > > multihoming solution decide instead of having the site try to control > > it. > > Assume that a site is connected to ISP A and B. > > If the site negotiate with ISP A and B individually, egress routing > is fully controlled by the site. > > Otherwise, ISP A and B must cooperate for the welfare of the site > even if they are hostile competiters. > > > >> Tony Hain wrote: > > >> The other point is that for inbound load balancing, the receiving > > site > > >> only has control as long as it does not conflict with origin site > > >> policy, or the topology is deep enough that an intermediary abstracts > > >> out the differences. > > > Masataka Ohta wrote: > > > Again, I agree with you. > > > > I disagree with both of you here as well. The receiving site does not > > have > > much control over the traffic it receives, but let's not forget that a > > solution includes BOTH the sender and the receiver, which means that > > indeed > > inbound load balancing can be controlled, not by the receiver but by the > > sender..... > > Are you saying "EITHER"? > > > > Masataka Ohta wrote: > > > The receiver can advertise detailed routes over > > > each specific link, but if the origin ignores those and defaults to > > its > > > prefered low-cost provider, the traffic is not likely to balance the > > way > > > the receiver wants. > > > > There are ways around that. > > It's not my statement, but, anyway... > > Constructive proof on exsitense of scalable ways is required here. > > > > But, it will make routing/signalling information not to scale, > > > which destroys the purpose of multi6. > > > > I think that Tony's addressing scheme, although not very optimal, can be > > made very scalable. > > "very" is not a proper wording to discuss scalability. > > "very scalable" = "poorly scalable" > > Masataka Ohta From owner-multi6@ops.ietf.org Thu Jan 10 10:57: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 KAA17107 for ; Thu, 10 Jan 2002 10:57:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16OhYL-0002pO-00 for multi6-data@psg.com; Thu, 10 Jan 2002 07:55:41 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.33 #1) id 16OhYK-0002pI-00 for multi6@ops.ietf.org; Thu, 10 Jan 2002 07:55:40 -0800 content-class: urn:content-classes:message Subject: RE: Requirement document last call (let's focus!) Date: Thu, 10 Jan 2002 07:55:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <2B81403386729140A3A899A8B39B046405DE3A@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: Requirement document last call (let's focus!) Thread-Index: AcGZ3C9Da7hWqZ/fRrqyVB2+ph5UrgAEENUw From: "Michel Py" To: "Brian E Carpenter" , "Masataka Ohta" Cc: "Tony Hain" , Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA17107 Brian, > Brian E Carpenter wrote: > 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 concur with this. > I suggest that we either delete the language, or make it so > vague as to avoid the argument. Deleting it seems simpler. Arguing about is is not necessarily bad. I still think this requirement (ingress multihoming in 3.12) is good. When I designed my stuff, it was part of the design. I am not sure that I would have come to the same result without it. After all, the bulk of the traffic is likely to remain from a singlehomed site at the source to a multihomed site at the destination. Since there is nothing to be done about load balancing at the source, it must be done at the destination, and preferably both egress and ingress. 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. Since that draft is not officially in last call yet, the argument that has taken place about it was good for clarification so far, IMHO. This is topic #1 in the edit document, I will post 1.04 soon. Please do send comments. Michel. From owner-multi6@ops.ietf.org Thu Jan 10 10:58: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 KAA17138 for ; Thu, 10 Jan 2002 10:58:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16OhaO-0002ss-00 for multi6-data@psg.com; Thu, 10 Jan 2002 07:57:48 -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 16OhaL-0002sm-00 for multi6@ops.ietf.org; Thu, 10 Jan 2002 07:57:45 -0800 content-class: urn:content-classes:message Subject: (multi6) Requirements document edit 1.04 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 10 Jan 2002 07:57:44 -0800 Message-ID: <2B81403386729140A3A899A8B39B046403D628@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: (multi6) Requirements document edit 1.04 Thread-Index: AcGZ79B7+Xh9W8sUSUKMgBeuxo8AtQ== 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 KAA17138 ---------------------------------------------------------------- Tentative summary of edits to the requirements documents v1.04 ---------------------------------------------------------------- Revision history: ----------------- 1.04 Jan-10-2002 Added supplemental comments from Brian Carpenter and Michel Py about 3.1.2 (topic 1). 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 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. 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 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". 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. 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. 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. 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. 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". 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 Opinions about it: Vijay Gill: I'm fine with this. Michel Py: I'm fine with the existing text. Add yours here: From owner-multi6@ops.ietf.org Thu Jan 10 11:31: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 LAA18222 for ; Thu, 10 Jan 2002 11:31:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Oi6Y-0003al-00 for multi6-data@psg.com; Thu, 10 Jan 2002 08:31:02 -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 16Oi6X-0003ae-00 for multi6@ops.ietf.org; Thu, 10 Jan 2002 08:31:02 -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 RAA10080; Thu, 10 Jan 2002 17:30:55 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA67038 from ; Thu, 10 Jan 2002 17:30:53 +0100 Message-Id: <3C3DC1BE.8DBE1CCB@hursley.ibm.com> Date: Thu, 10 Jan 2002 17:30:54 +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: Michel Py Cc: Masataka Ohta , Tony Hain , multi6@ops.ietf.org Subject: load balancing [Re: Requirement document last call (let's focus!)] References: <2B81403386729140A3A899A8B39B046405DE3A@server2000.arneill-py.sacramento.ca.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > 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 Good compromise. Brian Michel Py wrote: > > Brian, > > > Brian E Carpenter wrote: > > 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 concur with this. > > > I suggest that we either delete the language, or make it so > > vague as to avoid the argument. Deleting it seems simpler. > > Arguing about is is not necessarily bad. > I still think this requirement (ingress multihoming in 3.12) > is good. When I designed my stuff, it was part of the design. > I am not sure that I would have come to the same result > without it. After all, the bulk of the traffic is likely to > remain from a singlehomed site at the source to a multihomed > site at the destination. Since there is nothing to be done > about load balancing at the source, it must be done at the > destination, and preferably both egress and ingress. > > 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. > Since that draft is not officially in last call yet, the > argument that has taken place about it was good for clarification > so far, IMHO. > > This is topic #1 in the edit document, I will post 1.04 soon. > Please do send comments. > > Michel. From owner-multi6@ops.ietf.org Thu Jan 10 13:02:44 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20418 for ; Thu, 10 Jan 2002 13:02:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16OjVl-0005co-00 for multi6-data@psg.com; Thu, 10 Jan 2002 10:01:09 -0800 Received: from evrtwa1-ar8-4-60-070-162.vz.dsl.gtei.net ([4.60.70.162] helo=tndh.net) by psg.com with esmtp (Exim 3.33 #1) id 16OjVj-0005ch-00 for multi6@ops.ietf.org; Thu, 10 Jan 2002 10:01:08 -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, 10 Jan 2002 10:01:22 -0800 From: "Tony Hain" To: "Michel Py" , "Brian E Carpenter" , "Masataka Ohta" Cc: Subject: RE: Requirement document last call (let's focus!) Date: Thu, 10 Jan 2002 10:01:05 -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) Importance: Normal In-Reply-To: <2B81403386729140A3A899A8B39B046405DE3A@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Michel Py wrote: > ... After all, the bulk of the traffic is likely to > remain from a singlehomed site at the source to a multihomed > site at the destination. What reality do you live in? The vast majority of the traffic flows from a small set of multi-homed sources (web servers) to a very large set of single-homed (dial) destinations. > I am opposed to deleting the load balancing requirement, but > removing the ingress part that stirred up all this discussion > seems acceptable to me ... That is all I was looking for. Tony From owner-multi6@ops.ietf.org Thu Jan 10 13:26:13 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20724 for ; Thu, 10 Jan 2002 13:26:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16OjtF-00067n-00 for multi6-data@psg.com; Thu, 10 Jan 2002 10:25:25 -0800 Received: from zeus.anet-chi.com ([207.7.4.6]) by psg.com with esmtp (Exim 3.33 #1) id 16OjtE-00067g-00 for multi6@ops.ietf.org; Thu, 10 Jan 2002 10:25:24 -0800 Received: from RepliGate (as1-112.chi.il.dial.anet.com [198.92.156.112]) by zeus.anet-chi.com (8.12.1/8.12.0) with SMTP id g0AIPBnE014762; Thu, 10 Jan 2002 12:25:12 -0600 (CST) Message-ID: <2cec01c19a1c$d220a0c0$0100a8c0@RepliGate> From: "Jim Fleming" To: "Tony Hain" , "Michel Py" , "Brian E Carpenter" , "Masataka Ohta" Cc: References: Subject: "The vast majority of the traffic flows" Date: Thu, 10 Jan 2002 13:21:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit "The vast majority of the traffic flows..." IPv4 traffic or IPv6 traffic ? Jim Fleming 2002:[IPv4]:000X:03DB http://www.IPv8.info ----- Original Message ----- From: "Tony Hain" To: "Michel Py" ; "Brian E Carpenter" ; "Masataka Ohta" Cc: Sent: Thursday, January 10, 2002 10:01 AM Subject: RE: Requirement document last call (let's focus!) > Michel Py wrote: > > ... After all, the bulk of the traffic is likely to > > remain from a singlehomed site at the source to a multihomed > > site at the destination. > > What reality do you live in? The vast majority of the traffic flows from > a small set of multi-homed sources (web servers) to a very large set of > single-homed (dial) destinations. > > > I am opposed to deleting the load balancing requirement, but > > removing the ingress part that stirred up all this discussion > > seems acceptable to me ... > > That is all I was looking for. > > Tony > > > > From owner-multi6@ops.ietf.org Thu Jan 10 14:09: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 OAA21646 for ; Thu, 10 Jan 2002 14:09:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16OkX5-0006r8-00 for multi6-data@psg.com; Thu, 10 Jan 2002 11:06: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 16OkX4-0006r2-00 for multi6@ops.ietf.org; Thu, 10 Jan 2002 11:06:34 -0800 content-class: urn:content-classes:message Subject: RE: Requirement document last call (let's focus!) Date: Thu, 10 Jan 2002 11:06:32 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <2B81403386729140A3A899A8B39B046405DE3B@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: Requirement document last call (let's focus!) Thread-Index: AcGaAP9cRUcmuOd6T1upGhEuddk5rQACFU2A From: "Michel Py" To: "Tony Hain" , "Brian E Carpenter" 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 OAA21646 >> Michel Py wrote: >> ... After all, the bulk of the traffic is likely to >> remain from a singlehomed site at the source to a multihomed >> site at the destination. > Tony Hain wrote: > What reality do you live in? The vast majority of the traffic > flows from a small set of multi-homed sources (web servers) to > a very large set of single-homed (dial) destinations. DOH. I must have been emailing to someone down under when I wrote this. Or maybe I was configuring a conduit on a Pix. Michel. From owner-multi6@ops.ietf.org Thu Jan 10 19:24: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 TAA26629 for ; Thu, 10 Jan 2002 19:24:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16OpRn-000Ccc-00 for multi6-data@psg.com; Thu, 10 Jan 2002 16:21:27 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.33 #1) id 16OpRm-000CcN-00 for multi6@ops.ietf.org; Thu, 10 Jan 2002 16:21:26 -0800 From: Masataka Ohta Message-Id: <200201110006.JAA00873@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id JAA00873; Fri, 11 Jan 2002 09:06:10 +0900 Subject: Re: (multi6) control / load balancing of ingress traffic. In-Reply-To: <2B81403386729140A3A899A8B39B046405DE35@server2000.arneill-py.sacramento.ca.us> from Michel Py at "Jan 8, 2002 09:53:55 pm" To: Michel Py Date: Fri, 11 Jan 2002 09:06:06 +0859 () CC: Tony Hain , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-multi6@ops.ietf.org Precedence: bulk Michel; > Let me try to explain this. > - Site S is multihomed to providers A,B and C. > - Site S has received aggregatable PA addresses from all three > providers. > - The multihoming solution is a multi-address one, which means that each > host on site S has several addresses, one for each provider and possibly > a PI address as well. > - In the cloud, during the transport of the packet, one of the PA > addresses > is going to be used. This effectively assures load balancing among the > different providers by the choice of the destination address by the > source. > - So, the provider used at the destination is controlled by the source > when > the multihoming protocol chooses among the different possible > destinations. > - If that multihoming protocol bases its decisions on info provided by > the > destination, you can truly says that the destination controls its own > ingress traffic. DESTINATION ADDRESS SELECTION is the key here, not > routing. Looking at your proposal, I feel we should add one more requirement that: A proposal must be for large scale policy rich Internet with highly assymmetric routing. Namely, routing informaion at a source gives no information or hint about how or whether the source can be reached from destination. Masataka Ohta From owner-multi6@ops.ietf.org Thu Jan 10 19:56: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 TAA26864 for ; Thu, 10 Jan 2002 19:56:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16OpzF-000DGO-00 for multi6-data@psg.com; Thu, 10 Jan 2002 16:56:01 -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 16OpzE-000DGI-00 for multi6@ops.ietf.org; Thu, 10 Jan 2002 16:56:00 -0800 content-class: urn:content-classes:message Subject: RE: (multi6) control / load balancing of ingress traffic. Date: Thu, 10 Jan 2002 16:55:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: <2B81403386729140A3A899A8B39B046405DE3E@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: (multi6) control / load balancing of ingress traffic. Thread-Index: AcGaN3UE3PIjDAHLT/WUgcbksEOZLgAAcSFw From: "Michel Py" To: "Masataka Ohta" Cc: "Tony Hain" , Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA26864 Masataka, > Masataka Ohta wrote: > Looking at your proposal, I feel we should add one more > requirement that: > A proposal must be for large scale policy rich Internet > with highly assymmetric routing. > Namely, routing information at a source gives no > information or hint about how or whether the source can > be reached from destination. I am not sure I completely understand what you mean above, Could you please develop it a little bit? Thanks Michel. From owner-multi6@ops.ietf.org Fri Jan 11 11:04:13 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19269 for ; Fri, 11 Jan 2002 11:04:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16P47x-0005XO-00 for multi6-data@psg.com; Fri, 11 Jan 2002 08:01:57 -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 16P47x-0005XH-00 for multi6@ops.ietf.org; Fri, 11 Jan 2002 08:01:57 -0800 Subject: (multi6) the nonsense paragraph is back Date: Thu, 10 Jan 2002 23:16:02 -0800 Message-ID: <2B81403386729140A3A899A8B39B046403D63E@server2000.arneill-py.sacramento.ca.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Thread-Topic: (multi6) the nonsense paragraph is back Thread-Index: AcGab9MqazXhdgxxRg23szpzFPjdXg== From: "Michel Py" content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 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 LAA19269 multi6 folk, I finally figured out what I meant when I wrote that paragraph that apparently makes no sense. It would make sense if it was not the complete opposite of reality. The offending paragraph was: > Michel Py wrote: > After all, the bulk of the traffic is likely to > remain from a singlehomed site at the source to > a multihomed site at the destination. Since there > is nothing to be done about load balancing at the > source, it must be done at the destination, and > preferably both egress and ingress. This, indeed, does not make sense because the bulk of the traffic is from the multihomed site to the singlehomed site. The sentence meant to be from the requester's perspective and SHOULD have been: After all, the bulk of the traffic is likely to | remain THE RETURN TRAFFIC from a singlehomed site at the source to a multihomed site at the destination. Since there is nothing to be done about load balancing at the source, it must be done at the destination, and preferably both egress and ingress. Which is consitent with another part of my posting that said that it would be ok to drop the ingress load balancing part because it is unsignificant compared to the rest of the traffic, although I personally think that this requirement should be maintained. Michel. From owner-multi6@ops.ietf.org Fri Jan 11 11:52:12 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21276 for ; Fri, 11 Jan 2002 11:52:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16P4uC-0006g1-00 for multi6-data@psg.com; Fri, 11 Jan 2002 08:51:48 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.33 #1) id 16P4uB-0006fv-00 for multi6@ops.ietf.org; Fri, 11 Jan 2002 08:51:47 -0800 From: Masataka Ohta Message-Id: <200201111638.BAA08772@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id BAA08772; Sat, 12 Jan 2002 01:38:21 +0900 Subject: Re: (multi6) control / load balancing of ingress traffic. In-Reply-To: <2B81403386729140A3A899A8B39B046405DE3E@server2000.arneill-py.sacramento.ca.us> from Michel Py at "Jan 10, 2002 04:55:58 pm" To: Michel Py Date: Sat, 12 Jan 2002 01:38:21 +0859 () CC: Tony Hain , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-multi6@ops.ietf.org Precedence: bulk Michel; > > Masataka Ohta wrote: > > Looking at your proposal, I feel we should add one more > > requirement that: > > A proposal must be for large scale policy rich Internet > > with highly assymmetric routing. > > Namely, routing information at a source gives no > > information or hint about how or whether the source can > > be reached from destination. > > I am not sure I completely understand what you mean above, > Could you please develop it a little bit? For example, your selection of addresses at a source may randomly distribute return traffic but unlikely balance it. The destination may know, from routing information, some return path is temporaliry unavailable or some return path is five times more favourable than others. Masataka Ohta From owner-multi6@ops.ietf.org Fri Jan 11 20:38: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 UAA04263 for ; Fri, 11 Jan 2002 20:38:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16PD4h-000JOI-00 for multi6-data@psg.com; Fri, 11 Jan 2002 17:35:11 -0800 Received: from relay1.nexsi.com ([66.35.205.133]) by psg.com with esmtp (Exim 3.33 #1) id 16PD4g-000JO7-00 for multi6@ops.ietf.org; Fri, 11 Jan 2002 17:35:10 -0800 Received: from mail.nexsi.com (ripper1.nexsi.com [66.35.212.35]) by relay1.nexsi.com (Postfix) with ESMTP id CDCFD3F65; Fri, 11 Jan 2002 17:37:53 -0800 (PST) Received: from khonsu.sw.nexsi.com ([172.17.212.34]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id RAA29889; Fri, 11 Jan 2002 17:38:51 -0800 Date: Fri, 11 Jan 2002 17:34:11 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <70717772792.20020111173411@nexsi.com> To: "Michel Py" Cc: multi6@ops.ietf.org Subject: Most recent version? In-Reply-To: <2B81403386729140A3A899A8B39B046403D63E@server2000.arneill-py.sacramento.ca.us> References: <2B81403386729140A3A899A8B39B046403D63E@server2000.arneill-py.sacramento.ca.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Michel, Since you assumed the role of the document editor, could you send the latest version to the list (or is there a URL?) I'm lost with all the changes. Thanks. -- Alex Zinin From owner-multi6@ops.ietf.org Fri Jan 11 23:13: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 XAA07645 for ; Fri, 11 Jan 2002 23:13:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16PFWa-000N13-00 for multi6-data@psg.com; Fri, 11 Jan 2002 20:12:08 -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 16PFWZ-000N0w-00 for multi6@ops.ietf.org; Fri, 11 Jan 2002 20:12:07 -0800 Subject: RE: Most recent version (of requirements doc edits) is 1.04 Date: Fri, 11 Jan 2002 20:12:05 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405DE40@server2000.arneill-py.sacramento.ca.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: Most recent version (of requirements doc edits) is 1.04 Thread-Index: AcGbCXhXqs3RvlIgQiKftZLOitdqFAAFRHog content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 From: "Michel Py" To: "Alex Zinin" 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 XAA07645 > Alex Zinin wrote: > Michel, > Since you assumed the role of the document editor, > could you send the latest version to the list (or is > there a URL?) I'm lost with all the changes. Certainly, here it is. Multi6 folk, please note that the fact I assumed the role of the document editor does NOT mean that three other fellows and myself should be the only ones contributing to it. Actually, I am strongly thinking about abusing my position of document editor to add a new requirement that people that did NOT contribute to the document MUST be flogged in Minneapolis. Michel. ---------------------------------------------------------------- Tentative summary of edits to the requirements documents v1.04 ---------------------------------------------------------------- Revision history: ----------------- 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 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. 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 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". 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. 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. 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. 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. 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". 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 Opinions about it: Vijay Gill: I'm fine with this. Michel Py: I'm fine with the existing text. Add yours here: From owner-multi6@ops.ietf.org Fri Jan 11 23:55: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 XAA08435 for ; Fri, 11 Jan 2002 23:55:58 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16PGBt-000O1h-00 for multi6-data@psg.com; Fri, 11 Jan 2002 20:54: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 16PGBs-000O1T-00 for multi6@ops.ietf.org; Fri, 11 Jan 2002 20:54:48 -0800 Subject: RE: (multi6) control / load balancing of ingress traffic. Date: Fri, 11 Jan 2002 20:54:49 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405DE42@server2000.arneill-py.sacramento.ca.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Thread-Topic: (multi6) control / load balancing of ingress traffic. Thread-Index: AcGawGD+O8rTjF8VTJql40Sc9QydMQAYuucQ content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 From: "Michel Py" To: "Masataka Ohta" 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 XAA08435 Masataka, > Masataka Ohta wrote: > For example, your selection of addresses at a source may > randomly distribute return traffic but unlikely balance it. > The destination may know, from routing information, some return > path is temporaliry unavailable or some return path is five > times more favourable than others. Could you come up with a text for a new requirement that does not appear to be a blatant advertisement for my draft? I appreciate your feedback. However, there are at least two reasons that would make me feel that this would not be appropriate for a new requirement: 1. As the acting document editor, I have trouble putting in a new requirement that is favoring my own draft. 2. I am not even sure that this would be a good requirement. Although it is too early to tell, there is some potential for solutions that address the largest numbers of multihomed sites, such as personal setups that are dualhomed to DSL and Cable, or possibly mobile, to provide a multihoming solution that does not get any feedback from the routing system. Thanks, Michel. From owner-multi6@ops.ietf.org Sat Jan 12 08:43: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 IAA20448 for ; Sat, 12 Jan 2002 08:43:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16POO7-000Btv-00 for multi6-data@psg.com; Sat, 12 Jan 2002 05:39:59 -0800 Received: from netcore.fi ([193.94.160.1]) by psg.com with esmtp (Exim 3.33 #1) id 16POO6-000Btn-00 for multi6@ops.ietf.org; Sat, 12 Jan 2002 05:39:59 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g0CDdZF18498; Sat, 12 Jan 2002 15:39:35 +0200 Date: Sat, 12 Jan 2002 15:39:34 +0200 (EET) From: Pekka Savola To: Masataka Ohta cc: Michel Py , Tony Hain , Subject: Re: (multi6) control / load balancing of ingress traffic. In-Reply-To: <200201111638.BAA08772@necom830.hpcl.titech.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sat, 12 Jan 2002, Masataka Ohta wrote: > For example, your selection of addresses at a source may > randomly distribute return traffic but unlikely balance it. > > The destination may know, from routing information, some return > path is temporaliry unavailable or some return path is five > times more favourable than others. A problem with this 'destination address selection'... When sending a packet, the source must pick _one_ source address; it cannot store more of them. When the destination replies, it might know which path is best but this cannot be done unless the transport protocols are changed (or something else rather radical is done) so all addresses are tagged in the packets. -- 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 Mon Jan 14 23:07: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 XAA03591 for ; Mon, 14 Jan 2002 23:07:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16QKnz-000AuN-00 for multi6-data@psg.com; Mon, 14 Jan 2002 20:02:35 -0800 Received: from necom830.hpcl.titech.ac.jp ([131.112.32.132]) by psg.com with esmtp (Exim 3.33 #1) id 16QKny-000AuH-00 for multi6@ops.ietf.org; Mon, 14 Jan 2002 20:02:34 -0800 From: Masataka Ohta Message-Id: <200201150345.MAA08662@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id MAA08662; Tue, 15 Jan 2002 12:45:35 +0900 Subject: Re: (multi6) control / load balancing of ingress traffic. In-Reply-To: from Pekka Savola at "Jan 12, 2002 03:39:34 pm" To: Pekka Savola Date: Tue, 15 Jan 2002 12:45:34 +0859 () CC: Michel Py , Tony Hain , multi6@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-multi6@ops.ietf.org Precedence: bulk Pekka; > > For example, your selection of addresses at a source may > > randomly distribute return traffic but unlikely balance it. > > > > The destination may know, from routing information, some return > > path is temporaliry unavailable or some return path is five > > times more favourable than others. > > A problem with this 'destination address selection'... > > When sending a packet, the source must pick _one_ source address; it > cannot store more of them. When the destination replies, it might know > which path is best but this cannot be done unless the transport protocols > are changed (or something else rather radical is done) so all addresses > are tagged in the packets. That is not a problem at all. Masataka Ohta From owner-multi6@ops.ietf.org Mon Jan 21 11:42: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 LAA16075 for ; Mon, 21 Jan 2002 11:42:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16ShSJ-000Az5-00 for multi6-data@psg.com; Mon, 21 Jan 2002 08:37:59 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.33 #1) id 16ShSG-000Ayz-00 for multi6@ops.ietf.org; Mon, 21 Jan 2002 08:37:56 -0800 content-class: urn:content-classes:message Subject: Requirements document edit 1.05 Date: Mon, 21 Jan 2002 08:37:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <2B81403386729140A3A899A8B39B046406C243@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: Requirements document edit 1.05 Thread-Index: AcGiiG1+8IzSHL5cQ8K4bUDWTJ2BOwAES12w From: "Michel Py" To: "Robert J. Rockell" 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 LAA16075 ---------------------------------------------------------------- Tentative summary of edits to the requirements documents v1.05 ---------------------------------------------------------------- Revision history: ----------------- 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 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 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: From owner-multi6@ops.ietf.org Mon Jan 21 19:53: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 TAA29133 for ; Mon, 21 Jan 2002 19:53:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Sp9P-000Li0-00 for multi6-data@psg.com; Mon, 21 Jan 2002 16:50:59 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.33 #1) id 16Sp9O-000Lhu-00 for multi6@ops.ietf.org; Mon, 21 Jan 2002 16:50:58 -0800 content-class: urn:content-classes:message Subject: (multi6) It's all about timing. The deadline to submit for Minneapolis is in six weeks. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 21 Jan 2002 16:50:58 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405DE5F@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: (multi6) It's all about timing. The deadline to submit for Minneapolis is in six weeks. Thread-Index: AcGi3ttYkCP3bwt5T4yy5/PHYF4kxA== 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 TAA29133 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 Tue Jan 29 11:28: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 LAA08299 for ; Tue, 29 Jan 2002 11:28:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Vb40-000Htn-00 for multi6-data@psg.com; Tue, 29 Jan 2002 08:24:52 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.33 #1) id 16Vb40-000Htc-00 for multi6@ops.ietf.org; Tue, 29 Jan 2002 08:24:52 -0800 content-class: urn:content-classes:message Subject: RE: Need for N-homedness (was Re: asymmetric routing) Date: Tue, 29 Jan 2002 08:24:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046406C29E@server2000.arneill-py.sacramento.ca.us> Thread-Topic: Need for N-homedness (was Re: asymmetric routing) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 thread-index: AcGosRISD33n1fGSQw6y6hitOzwlDgALPXVA From: "Michel Py" To: "Pim van Pelt" , "Michael Kjorling" Cc: "6bone" <6bone@ISI.EDU>, Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA08299 Pim, > Pim van Pelt wrote: > (fear my ascii art - best viewed in xterm, not in Outlook et al :) Actually, it displays OK in Outlook. > TRANSIT1-(R1)----fiber-to-customer-----(R3)---\ > | | |------network at customer > TRANSIT2-(R2)---backup-E1-to-customer--(R4)---/ This setup is good enough for most. Unfortunately, it is not available everywhere, and it does not provide redundancy if something happens to R1-R2 that are located in the same building. > I fail to see any need for more than one prefix per customer, I assume you mean more than one provider independant (PI) prefix. The main driving force behind that is the elimination of (PI) addresses, One of the animals that clog the IPv4 DFZ today. It is too early to know if there will be ANY IPv6 PI addresses at all. > and still say that IF a customer has more than one prefix, his R3/R4 > should preform source based policy routing, sending traffic from prefixA > through the circuits to ISPA and traffic from prefixB to ISPB. Definitely. However, this is not enough. There are two other problems with this scheme (that is likely to become part of the IPv6 multihoming solution): 1. Address selection by the source that has to choose between ISPA ans ISPB. 2. Make sure that the host (server) that has two addresses, uses the correct one to return the traffic (the one that the traffic was sent to). Michel. P.S. I think that this thread should be switched to the multi6 mailing list. From owner-multi6@ops.ietf.org Tue Jan 29 12:20:28 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10011 for ; Tue, 29 Jan 2002 12:20:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16VbvL-000JfW-00 for multi6-data@psg.com; Tue, 29 Jan 2002 09:19:59 -0800 Received: from adsl-209-233-126-65.dsl.scrm01.pacbell.net ([209.233.126.65] helo=server2000.arneill-py.sacramento.ca.us) by psg.com with esmtp (Exim 3.33 #1) id 16VbvI-000JfN-00 for multi6@ops.ietf.org; Tue, 29 Jan 2002 09:19:56 -0800 content-class: urn:content-classes:message Subject: Requirements documents: edits v 1.06 Date: Tue, 29 Jan 2002 09:19:54 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <2B81403386729140A3A899A8B39B046406C2A1@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: Requirements documents: edits v 1.06 thread-index: AcGo6SshLVmc3zjvQiCYwoFWuF/jZg== 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 MAA10011 Multi6 folk, Following a discussion currently going on the 6bone mailing list, I added a new proposed requirement, see topic 10. Please comment. Michel. ---------------------------------------------------------------- Tentative summary of edits to the requirements documents v1.06 ---------------------------------------------------------------- Revision history: ----------------- 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 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 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 "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." Possible modifications: 1. Please send text 2. Do nothing 3. add new requirement. Opinions about it: Add yours here: From owner-multi6@ops.ietf.org Tue Jan 29 13:29:47 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12661 for ; Tue, 29 Jan 2002 13:29:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Vczs-000LsF-00 for multi6-data@psg.com; Tue, 29 Jan 2002 10:28:44 -0800 Received: from inet.org ([63.108.254.91] helo=gnat.inet.org) by psg.com with esmtp (Exim 3.33 #1) id 16Vczr-000Ls5-00 for multi6@ops.ietf.org; Tue, 29 Jan 2002 10:28:43 -0800 Received: from mosquito.inet.org (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id 8516567103; Tue, 29 Jan 2002 13:44:09 -0500 (EST) Date: Tue, 29 Jan 2002 13:28:31 -0500 Subject: Re: Requirements documents: edits v 1.06 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: <2B81403386729140A3A899A8B39B046406C2A1@server2000.arneill-py.sacramento.ca.us> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.480) Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tuesday, January 29, 2002, at 12:19 , Michel Py wrote: > 10. Reverse Path Forwarding / filtering > --------------------------------------- >> Michel Py proposes to add a new requirement > > "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." > > Possible modifications: > 1. Please send text > 2. Do nothing > 3. add new requirement. > > Opinions about it: The above text 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. Therefore, I object to the current text and propose the following replacement text: 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. Ran rja@extremenetworks.com From owner-multi6@ops.ietf.org Tue Jan 29 15:07:28 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19402 for ; Tue, 29 Jan 2002 15:07:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16VeWN-000P0u-00 for multi6-data@psg.com; Tue, 29 Jan 2002 12:06:23 -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 16VeWL-000P0k-00 for multi6@ops.ietf.org; Tue, 29 Jan 2002 12:06:21 -0800 content-class: urn:content-classes:message Subject: Requirements document: edits v 1.07 Date: Tue, 29 Jan 2002 12:06:15 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <2B81403386729140A3A899A8B39B046406C2A3@server2000.arneill-py.sacramento.ca.us> Thread-Topic: Requirements document: edits v 1.07 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 thread-index: AcGo8tq6S4tPId4SRkSEF5XUuUgBYAADWRtQ 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 PAA19402 ---------------------------------------------------------------- Tentative summary of edits to the requirements documents v1.07 ---------------------------------------------------------------- Revision history: ----------------- 1.07 Jan-29-2002 Replaced topic 10 text with RJ Atkinson's text. 1.06 Jan-29-2002 Added new requirement (topic 10) (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 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 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. 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. Add yours here: From owner-multi6@ops.ietf.org Wed Jan 30 04:29:47 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13155 for ; Wed, 30 Jan 2002 04:29:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16Vr1l-000HFX-00 for multi6-data@psg.com; Wed, 30 Jan 2002 01:27:37 -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 16Vr1l-000HFR-00 for multi6@ops.ietf.org; Wed, 30 Jan 2002 01:27:37 -0800 content-class: urn:content-classes:message Subject: (multi6) Possible new requirement: PA address filtering Date: Wed, 30 Jan 2002 01:27:34 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <2B81403386729140A3A899A8B39B046405DE7D@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: (multi6) Possible new requirement: PA address filtering thread-index: AcGpcFkxOyquWnnaTeiSP5QHeaG3Rw== 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 EAA13155 multi6 folk, Following the new topic 10 on the edits, it came to me that there would be some value in adding a new requirement to enforce PA address filtering as well. In a nutshell: Customer receives two PA prefixes, one from ISP A and one ISP B. Should/must/whatever/don't care ISP A deny traffic that does not belong to itself (read my lips: that belongs to ISP B) and vice versa? Note that this is about PA addresses, PI addresses are another story. Comments AND text welcomed. Michel. From owner-multi6@ops.ietf.org Wed Jan 30 09:14:34 2002 Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19353 for ; Wed, 30 Jan 2002 09:14:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16VvTE-000KVB-00 for multi6-data@psg.com; Wed, 30 Jan 2002 06:12:16 -0800 Received: from sj-msg-core-2.cisco.com ([171.69.24.11]) by psg.com with esmtp (Exim 3.33 #1) id 16VvTD-000KV5-00 for multi6@ops.ietf.org; Wed, 30 Jan 2002 06:12:15 -0800 Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g0UECEd19833; Wed, 30 Jan 2002 06:12:14 -0800 (PST) Received: from ELEAR-W2K1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id g0UECCY03644; Wed, 30 Jan 2002 06:12:12 -0800 (PST) Message-Id: <5.1.0.14.2.20020130060911.04cabb10@lint.cisco.com> X-Sender: elear@lint.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 30 Jan 2002 06:12:09 -0800 To: RJ Atkinson From: Eliot Lear Subject: Re: Requirements documents: edits v 1.06 Cc: "Michel Py" , In-Reply-To: References: <2B81403386729140A3A899A8B39B046406C2A1@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-multi6@ops.ietf.org Precedence: bulk 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 ;-) Eliot From owner-multi6@ops.ietf.org Wed Jan 30 13:32: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 NAA28388 for ; Wed, 30 Jan 2002 13:32:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 3.33 #1) id 16VzVD-000O4R-00 for multi6-data@psg.com; Wed, 30 Jan 2002 10:30: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 16VzVA-000O4K-00 for multi6@ops.ietf.org; Wed, 30 Jan 2002 10:30:32 -0800 content-class: urn:content-classes:message Subject: (multi6) Requirement documents: edits v 1.08 Date: Wed, 30 Jan 2002 10:30:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <2B81403386729140A3A899A8B39B046406C2AA@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: (multi6) Requirement documents: edits v 1.08 thread-index: AcGpqA6b7Deria06QdinKGhMc/6v7gAE/X+A From: "Michel Py" To: "Eliot Lear" , "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 NAA28388 ---------------------------------------------------------------- Tentative summary of edits to the requirements documents v1.08 ---------------------------------------------------------------- Revision history: ----------------- 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 (topic 10) (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 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 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: